En es-tu sûr ?
Moi je l’utilise pour connaitre le déclencheur de mon scénario et je mets le nom du déclencheur en paramètre de la fonction. Ça marche très bien comme ça.
D’ailleurs, comme c’est indiqué dans ce que tu as posté.
Voici le début de mon scénario :
Je ne suis pas sûr que cocher !a solution à cette endroit aide les autres lecteurs.
Je ne l’ai jamais utilisé comme ça, merci pour l’exemple.
En fait, je l’ai toujours utilisé comme ça.
J’espère que je ne suis pas tombé sur un bug qui sera corrigé et qui fera que ça ne marche plus à terme.
Bonjour,
Il n’y a rien à mettre entre parenthèse à la fonction triggerValue().
L’argument ne sera pas utilisé par le core et donc pour l’instant cela n’a aucun impact mais ca ne sert à rien.
Si un jour un argument optionnel est ajouté, cela vous causerait un bug.
Pour trigger() c’est optionnel:
Ok, donc c’est donc cohérent avec mon usage.
Pour triggervalue, je ne l’utilise pas
… pour le.moment.
Merci pour ces précisions. Ceci étant, il serait peut-être judicieux de les apporter aussi dans la doc.
Bonne journée.
je ne pensais pas que la discussion allait continuer et tant mieux si elle continue
quelle est donc la différence entre triggerValue() et trigger(#commande#)?
triggerValue() c’est pour une autre valeur que 0 ou 1 ? ex un mode jour / nuit ?
Dans le cas d’une température comme déclencheur la valeur du déclencheur peut être différent de 0 ou 1.
Trigger(#commande#) renvoie en fait vrai ou faux. Qui peut aussi s’exprimer par 1 ou 0.
donc dans le cas d’une température on utilisera triggerValue()
Si tu veux savoir la valeur de la température qui a déclenché, et non pas savoir si c’est le déclencheur température qui a déclenché.
Trigger retourne le nom du trigger, pas sa valeur !
Triggervalue retourne la valeur.
C’est pas ce que je comprends quand je lis ça .
tout seul , je suis d’accord
Pour résumer, si le scénario est lancé par un déclencheur :
trigger() retourne le nom du trigger.
trigger(#[ma][commande][info]#) retourne vrai ou faux.
triggerValue() retourne la valeur de la commande info.
Je vous remercie tous pour toutes ces explications, tout est clair maintenant.je pense que ça éclairera beaucoup de monde.
Petite question :
En rapidité d’exécution, il est préférable d’appeler dans un scénario , des scénarios tagués (comme des fonctions un peu) qui accomplissent des « petites taches » ou tout faire dans 1 ?
Dans le même principe quand on a beaucoup de test "si " à faire , il vaut mieux les imbriquer avec des « sinon » ou faire des « si » séparés. Je pense qu’il vaut mieux faire des « si » imbriqués car une fois qu’il a fait l’action , il sort et ne parcourt pas le reste non ?
exemple concret : j’ai 5 volets motorisés. Actuellement 1 scénario par volet qui en fonction de certaines actions , ouvre, ferme ou entrebâille.
En gros 5 scénarios qui font la même chose , avec le nom des actionneurs / commande qui changent
je veux donc optimiser. Je me disais de faire un scenario ouverture pour les 5, 1 fermeture; 1 entrebaille avec des tags suivant le volet
Faire un global avec des triggers en fonction des actionneurs qui appellent scenario tagué
Quelle solution est la plus optimisée ?
D’une façon générale, en informatique, il vaut mieux privilégier l’écriture de petites routines faciles à lire que de grandes illisibles.
Si tu as la possibilité de faire des scénarios qui peuvent se lancer avec des tags (des paramètres d’appel) différents, fais-le.
D’une part, la lisibilité en sera bien meilleure, d’autre part, si tu dois modifier le code, tu n’auras à le faire qu’une fois.
Quant à la rapidité d’exécution, c’est la même.
Pour les SI, il n’y a pas de réponse unique, cela dépend complètement de la logique que tu veux mettre en place.
Oui ,j’ai la même logique que toi, c’est la logique /pratique jeedom que je commence à m’approprier. Au départ, j’ai essayé surtout de faire du « qui marche », maintenant j’essaie que cela soit plus optimisé / lisible.
C’est surtout ce que je voulais savoir jeedomement parlant 
merci
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.
