Quand je redémarre Jeedom, ou après un nettoyage du cache, j’ai un certain nombre de commandes info qui n’ont pas de valeur et cela peut provoquer des erreurs dans les scénarios qui utilisent ces commandes.
Je voudrais savoir s’il existe une autre solution que d’initialiser soi -même toutes ces commandes au démarrage de jeedom via un scénario.
En fait j’aurais aimé pourvoir définir une valeur par défaut à une commande info au lieu d’avoir à faire cette initialisation explicite.
Comment avez-vous résolu cette question de l’initialisation des commandes info ?
Excuse moi, mais la question n’est pas de savoir comment on lance un scénario au démarrage de jeedom, la question est de savoir comment chacun fait pour initialiser les commandes infos et s’il existe une autre solution que de faire un scénario.
Enfin la suggestion est que les commandes infos pourraient disposer d’une valeur par défaut au lieu d’être à vide…
Il n’y a actuellement qu’une solution pour changer la valeur des commandes infos : event donc ça limite grandement les solutions. C’est ce qu’utilise le core et c’est disponible pour les scénarios (normaux ou code)
Combiné avec les déclencheurs, c’est la solution la plus simple et accessible à tous. On peut à la rigueur discuter ses optimisations autour du scénario mais pas beaucoup plus…
Jeedom c’est surtout une mécanisme type « programmation événementielle », ça veut intrinsèquement dire que rien n’est prévisible. Alors comme c’est pas la philosophie, imaginer et mettre en place un mécanisme de valeur par défaut, ça pose plus de questions que de solution :
Quelle amélioration ça apporte en plus par rapport à un scénario ? c’est plus simple ?
Combien de commandes tu as besoin d’initialiser par rapport à toutes celles existantes ? => ça vaut le coup de généraliser une fonction pour un petit pourcentage ?
A quel moment ça prends la valeur par défaut: au démarrage seulement ? Après 10 minutes sans valeur… A l’arrêt de jeedom ?
Comment tu fais la différence entre la valeur issue de celle par défaut et celle issue d’un véritable changement ?
il faut aussi repenser l’interface graphique…
Et je mets de coté volontairement le temps qu’il faudrait pour intégrer tout ça dans le code et les bugs que ça introduirai…
Alors je me trompe peut-être mais j’ai pas trop de mal à imaginer la réponse de Loic à une telle évolution
C’est juste impossible pour le core de savoir. Cela dépend de chaque plug-in.
Sachant que même la ça dépend du matos derrière : prenons comme exemple une bête sonde de température en rfx ou zwave qu’importe : jeedom ne reçoit la temp que lorsque la sonde l’annonce, ce qui dépend de son réveil…
Sinon en situation normal, le cache est persisté avant le reboot donc tes commandes sont à jours.
Si tu vides toi même ton cache, ce n’est pas normal de faire cela.
Je comprends que la suggestion de valeur par défaut non prévue dans jeedom représenterait une grosse évolution. A noter néanmoins que cette notion existe un peu avec la capacité de définir une valeur dite de retour d’état après un certain délai et qu’elle est aussi présente mais pour les variables.
Si cette évolution devait se faire, ce serait uniquement au démarrage de jeedom et il ne serait pas possible de faire la distinction sur le moyen utilisé pour changer la valeur…
Voici ce qui m’est arrivé : j’étais dans mon appartement un soir et les lumières se sont éteintes, la musique s’est arrêtée, les volets se sont fermés. J’ai tout de suite compris que l’appartement était passé à tort en mode absent, …
J’ai regardé les scénarios qui activent ce mode absence, et je me suis aperçu que j’avais codé un test sur une commande info de type binaire : la valeur de cette commande ne valait ni 1, ni 0 mais rien car elle n’avait pas été initialisée, suite à un redémarrage de Jeedom.
J’avais effectivement oublié de coder dans le script de démarrage de jeedom d’initialiser cette commande…
L’absence d’info a été considérée comme la valeur 0, alors qu’il aurait fallu que cette info soit à 1 et donc Jeedom a passé l’appartement en mode absent.
Je donne cet exemple pour expliquer à quoi cela peut servir d’initialiser une commande info.
Les plus développeurs d’entre-nous confirmeront l’intérêt de pouvoir donner une valeur par défaut.
Je pense qu’il est préférable d’indiquer une valeur par défaut à la création d’une nouvelle commande, plutôt que d’avoir un scénario qui les initialise au lancement de jeedom, car le risque d’oubli est plus faible, et la maintenance facilitée.
Vos retours d’expérience sur ce sujet m’intéressent.
C’est typiquement une exception :1 variable, avec 1 erreur de programmation, à traiter lors d’1 reboot
C’est exactement le « bon » exemple, où on tente d’inclure dans le core une fonction qui vise à pallier à une erreur de programmation. A première vue, c’est facile, mais les effets sont dévastateurs à termes : On n’est rapidement même plus sûr de ce que fais jeedom. Et dans le cas où le besoin est légitime, Jeedom corrige quand même…
Et ajouter toute cette mécanique par rapport à un scénario d"une ligne qui fait le boulot… ben n’importe lequel des plus développeurs d’entre-nous te dira que ça n’a pas de sens dans ce cas précis.
Pour les variables ça existe mais à la différence de tous le reste, c’est pas un événement, là on est dans de la pure programmation, c’est une habitude/un standard et donc c’est complémentent logique que ça existe.
Pour ma part j’ai aussi de temps en temps des soucis d’info qui ne sont pas initialisées : en cas de restauration ! Et en plus pour mes consignes de chauffage… Comme le cache n’est pas là à la restauration ben les valeurs sont vides…
Par contre à la différence de toi, c’est valeurs ne disposent pas d’une valeur par défaut… J’ai besoin qu’elles soient la valeur la plus récente… Donc si on suit l’idée de mettre tout ça en dur en dur dans le core, on complexifie encore plus cette notion de valeur par défaut.
Et c’est sans compter le fait, que je pourrai aussi passer par autre chose pour retrouver mes valeurs à la restauration : les variables justement puisqu’elles sont dispo en base. Adieu les cas d’anomalie…
Finalement j’ai choisi de faire un scénario de quelques lignes de codes, qui traite tout ça automatiquement (sauvegarde/restaure automatique).
Bref, sans un véritable cas d’usage (que perso je ne vois pas)… c’est plus d’ennnuis que de solution pour l’instant