par contre, on ne peut pas commencer à « corriger » en 4.4 ?
Non en effet parce que certains tag n’existaient pas et surtout le fameux #trigger# ne renvoi pas la même chose entre la 4.4 et la 4.5
1 « J'aime »
avec le précédent changement concernant les trigger, pour le début de tous mes scenarios, j’ai une ligne qui génère un log, j’avais mis un peu des 2 méthodes : Commande=#trigger#, déclencheur=trigger()/trigger(#trigger#), valeur=triggerValue()/triggerValue(#trigger#)
avec un peu de chance certains vont fonctionner lors du passage à la 4.5 
Bonjour,
Je reviens vers vous car je suis passé en 4.5 et…j’ai un souci (le seul apparemment) avec trigger
voila mon scénario:
il est provoqué par
#[fenêtres][117 Door Sensor bureau1][Porte]#==0
en exécution provoquée par le menu il fonctionne mais en ouverture/fermeture de la porte le log est vide et la commande n’est pas executée.
Par ailleurs dans le log du scénario (en execution directe) je peux lire
« #trigger_value# »:« naif02fr »} c’est mon identifiant de connection Jeedom
Merci pour votre aide
Bonsoir,
Il y a un paquet de problèmes…
Si ton déclencheur est
Il ne servira à rien de tester la valeur de la commande dans le SI, ce sera forcément 0
On écrit pas & mais &&
On écrit pas "trigger_value" mais #trigger_value# (qui ne sera jamais égal à 1 à cause du déclencheur)
Il n’y a aucune action dans le SI, pourquoi faire un scénario comme ça ?
parce que je tatonne pour essayer de trouver la solution seul !
Je t’ai indiqué l’ensemble de tes erreurs, il te reste donc plus qu’à corriger
Ma question de pourquoi faire un scénario comme ça était uniquement concernant le fait d’avoir un SI sans action
Ok je m’y attelle dès demain merci et bonne soirée
Bonjour,
je reviens car je n’avance pas faute de compréhension. Voilà mon scénario:
le déclencheur:
#[fenêtres][117 Door Sensor bureau1][Porte]#
à l’ouverture/la fermeture je n’ai rien dans le log
si je clique sur « executer » voici le log:
[2025-12-08 15:16:43][SCENARIO] -- Début : . Tags : {"#trigger#":"user","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"Scénario lancé manuellement","#trigger_value#":"naif02fr"}
[2025-12-08 15:16:43][SCENARIO] - Exécution du sous-élément de type [action] : action
[2025-12-08 15:16:43][SCENARIO] - Exécution du sous-élément de type [condition] : if #trigger_name# == "[fenêtres][117 Door Sensor bureau1][Porte]" ET #trigger_value# == 1
[2025-12-08 15:16:43][SCENARIO] Evaluation de la condition : ["" == "[fenêtres][117 Door Sensor bureau1][Porte]" ET "naif02fr" == 1] = Faux
[2025-12-08 15:16:43][SCENARIO] - Exécution du sous-élément de type [action] : else
[2025-12-08 15:16:43][SCENARIO] Exécution d'un bloc élément : 1180
[2025-12-08 15:16:43][SCENARIO] Fin correcte du scénario
merci pour toute votre aide
version Jeedom 4.5
Bonjour,
Il n’y a pas de #trigger_name# car c’est toi qui a lancé le scénario.
Regarde la 1ère ligne.
Et si cela ne fonctionne pas avec ton déclencheur c’est qu’il est incorrect, sinon s’il était déclenché tu verrais un log.
effectivement, dans un libellé il y avait « bureau » et dans l’autre « bureau1 » j’ai confondu le 1 avec un crochet dans la commande 
mes yeux commencent à se fatiguer.
Merci pour ton aide ainsi que celle de @Bison
Bonjour à tous,
j’essaye de mon coté d’appliquer les nouvelles règles trigger sans succès…j’ai pourtant bien tout lu mais après de multiples tests j’ai des comportement que je ne comprends pas.
Quelqu’un pourrait-il faire une synthèse avant après de ce qui a changé ?
Merci beaucoup
Ca parait quand même un peu vaste et vague comme question.
Mais en gros, au lieux d’utiliser la fonction
trigger(#[objet][equipement][commande]#) pour tester si cette commande était le déclencheur du scenario, il faut désormais utiliser :
#trigger_name" == '[objet][equipement][commande]'
Salut,
Bison a déjà tout dis non? Merci à lui.
1 « J'aime »
Bonsoir,
Tu lis en suivant et tu teste au fur et à mesure tu verras cela plus simple j’étais dans ton cas et grâce aux réponses tout fonctionne 
Et du coup je voudrais profiter de ce fil pour poser une question à la communauté.
On sait que le « repassage » à la syntaxe #trigger# en 4.5 a été faite pour de très bonne raison qui permet (si j’ai bien tout suivi) d’avoir des tags spécifiques à chaque scénarios en cas de multilancement.
Cependant, j’avais déjà échangé sur une régression importante, et avant de modifier touuuuus mes scenarios avec la nouvelle syntaxe, je voudrais savoir si vous voyez un contournement ou une astuce pour annuler cette régression.
Je m’explique :
Avant on avait comme test de trigger dns nos scenario: trigger(#[objet][equipement][commande]#)
Donc lorsque le code exécute cette commande, il transforme en son Id. Si l’envie me prenait de modifier le nom de cette commande, mon test de trigger dans le scénario suivait tout seul, quand j’avais découvert ça j’avais trouvé ça ‹ magique › !
J’ai par exemple béni cette fonctionnalité quand je suis passé d’openZwave à ZwaveJS puisque j’ai fait dû dupliqué tous les équipement puis faire des remplacer à gogo.
Bref.
En 4.5 on a désormais :
#trigger_name" == '[objet][equipement][commande]'
Et là c’est pas pareil, désormais si on modifie le nom de la commande, ce test de trigger dans le scenario ne suivra pas.
Les dev de Jeedom sont tout à fait conscient de cette régression et je comprends que le gain sur les tags en multilancement était un must, je ne fais donc aucune critique sur ce choix.
Cependant je souhaite savoir si dans la communauté, certains d’entre vous ont réfléchi à un moyen de rétablir cette flexibilité ?
Merci à tous !
Bonjour,
Toute cette partie trigger est bien plus flexible en 4.5 justement.
Documentation Jeedom - Tags de scénarios :
Dans ton cas il faut utiliser #trigger_id# :
#trigger_id#: Si c’est une commande qui a déclenché le scénario alors ce tag à la valeur de l’id de la commande qui l’a déclenché. Exemple :#trigger_id# == 19
Je me répète mais tout est expliqué dans la documentation, il suffit de la lire.
Merci Aurélien pour ta réponse, en effet tu as raison, j’avais bien identifié #trigger_id# comme une solution valide, et j’aurais dû le préciser dans ma demande.
Cependant cette solution nous prive selon moi de la lisibilité du code qu’on avait auparavant. On pourra éventuellement rétablir cette lisibilité en prenant le temps de commenter toutes les utilisation de #trigger_id#, mais ça alourdit un peu le code. Bref ce n’est pour moi pas la panacée.
Evidemment j’y viendrai si aucune autre option n’existe.
J’ai posé la question ici dans l’espoir que des bidouilleurs astucieux aient réussi à maintenir la flexibilité et la lisibilité.
Merci à tous !
Hello @Jeandhom,
Si je comprends bien, tu as ajouté toi-même une fonction cmdGetId().
Et ensuite, en reprenant mon exemple, au lieu de mettre :
#trigger_name" == '[objet][equipement][commande]'
Tu mets :
#trigger_id" == cmdGetId(#[objet][equipement][commande]#)
Ca a l’air intéressant, j’avais suivi ta proposition sur le lien que tu mets mais je ne savais pas si tu l’avais implémentée.
D’ailleurs en terme d’implémentation, tu fais ça comment ? Y a t’il un moyen d’ajouter des fonction perso qui ne soient pas écrasé par le core en cas de mise à jour ?
Merci beaucoup