Pb à l'utilisation de #trigger_name# (en remplacement de #trigger#) / Montée en version 4.5

[Piloo]

Bonjour la communauté,

Suite à la bascule en 4.5 je rencontre un problème à l’utilisation de #trigger_name# (en remplacement de #trigger#).

J’ai mis à jour ma condition pour remplacer #trigger# par #trigger_name# dans mes scenarios
#trigger_name# matches "[Etat Luminosité]".

La condition fonctionne lorsqu’il y a une valeur #trigger_name# (un déclenchement via événement du plugin z2m) mais lorsqu’il n’y a pas de valeur j’ai une erreur « Expression non valide » :
**Expression non valide** : #trigger_name# matches "[Etat Luminosité]"

Je pourrais faire des conditions « SI » mais j’aimerais rester dans qqch de simple !

Merci d’avance

[Madcow]

Bonjour,

Dans quelle condition #trigger_name# peut être vide ?

[Piloo]

En lancement provoqué (depuis la condition « Valeur à X depuis Y » sur une commande de type Etat)

[Madcow]

Bonjour,

Je n’avais pas envisagé ce cas de figure.

Essayer de réaliser un test avant le matches du genre :

SI #trigger_name# != ""

[Bison]

Salut,

Moi j’ai même le cas du plugin-smartthings avec lequel on a une possibilité de faire une configuration sur la commande de notification (pour traquer un évènement particulier d’un équipement du plugin) afin déclencher une action.

En configurant pour appeler un scénario, le tag #trigger_name# n’existe même pas ce qui évidemment plante le scénario

[2025-12-29 01:10:06][SCENARIO] -- Début : . Tags : {"#notif#":"Cycle terminé","#dateNotif#":"2025-12-29 01:09:56","#trigger#":"other","#trigger_message#":"Lancement provoqué"}

[Madcow]

Salut,

C’est comme si tu déclenchais sur une commande donc le même cas si j’ai bien compris ?

Cela confirmerait que dans Jeedom :

• il n’est pas prévu que #trigger_name# puisse être vide
• ce cas de lancement de scénario a été oublié pour donner une valeur à #trigger_name#.

Je viens de rédiger un issue sur le github.

[Bison]

@Madcow

C’est comme si tu déclenchais sur une commande donc le même cas si j’ai bien compris ?

Oui, en effet, j’avais un doute mais c’est j’ai vérifié, c’est le cas également des commandes « normales » (issue du plugin-virtual) qui déclenchent des scénarios

#trigger_name# n’existe pas dans ce cas.

[2026-01-02 12:55:04][SCENARIO] -- Début : . Tags : {"#CommandeEtatECS#":"off","#trigger#":"other","#trigger_message#":"Lancement provoqué"}
[2026-01-02 12:55:04][SCENARIO] - Exécution du sous-élément de type [action] : action
[2026-01-02 12:55:04][SCENARIO]    Log : Trigger : other
[2026-01-02 12:55:04][SCENARIO]    Log : TriggerName : #trigger_name#
[2026-01-02 12:55:04][SCENARIO]    Log : TriggerValue : #trigger_value#

[Madcow]

Oui ça paraît logique que ce soit n’importe quel type de commande.
Dans l’issue j’ai juste indiqué « commande » au sens large.

[Bison]

OK merci pour l’issue ouverte

[Piloo]

Merci pour vos retours ;

J’ai fait différent mais dire qu’une condition ne peut pas être évaluée car #trigger_name# n’existe pas je ne trouve pas ça « idéal » je m’attendrais juste à ce que le résultat de l’évaluation soit « FAUX » tout simplement … et pas que ça fasse « planter » le scénario.

Faut-il ouvrir un « bug » / « issue » officiellement sur le sujet ?

[Bison]

@Piloo

Faut-il ouvrir un « bug » / « issue » officiellement sur le sujet ?

C’est ce que Madcow a fait il y a quelques minutes :

@Madcow

Je viens de rédiger un issue sur le github.

[Piloo]

Je pensais que l’issue évoquée était sur le virtuel alors que pour moi j’étais sur le « core »

[Piloo]

Je mets le lien vers l’issues sur GitHub : [BUG] #trigger_name# non-existent when a Scenario is launched by a command · Issue #3177 · jeedom/core · GitHub

[Mips]

PR pour corriger: fix: Merge setTags method to append tags instead of replacing them by Mips2648 · Pull Request #3198 · jeedom/core · GitHub

si vous voulez tester pour confirmer que ca résout dans votre cas également c’est assez simple: il n’y a qu’une ligne à modifier

edit: le problème se produisait si le scénario était appelé avec des tags.
Dans ce cas, l’entièreté de la liste des tags était remplacée par la nouvelle liste mais donc si certains tags (standard) n’existaient pas dans la liste « appelant »), alors ils manquaient à l’exécution

[Piloo]

J’ai fait la modif en local pour checker le comportement.

[Mips]

La correction est également disponible pour test dans la branche 4.5.3:

Attention, comme indiqué, plus de support possible;
la 4.5.3 n’est pas stable et l’utiliser en production comporte un risque

[Piloo]

L’erreur disparait car les tags sont bien là Merci pour la correction.