Trigger() en 4.0 ne renvoi pas le nom de la commande

Polymere · Mai 5, 2020, 10:31

Pour faire simple j’ai un scénario qui gère les ordes de ma porte de garage à partir de Key Fob Gen5. En fonction du bouton, l’action est différente. Pour réutiliser ce code, d’autres boutons simule cette télécommande via la variable.
Le scénario de test prend les différentes méthodes (#trigger# trigger() triggerValue() variable() ) pour comparer les résultats.
Je pense que le traitement du message dans le plugin Telegram doit être différent.

Salvialf · Mai 5, 2020, 10:45

J’suis ko mais comme ça je dirai qu’il faut faire des
SI trigger(#[commandeKeyFob]#) ==(ou matches) 'BoutonXXX' ALORS faire telle action,
SINON SI trigger(#[commandeKeyFob]#) ==(ou matches) 'BoutonYYY' ALORS faire telle autre action,
Etc…

Fabrice · Mai 6, 2020, 7:51

J’ai donné cet exemple hier à un débutant :

ovomaltin · Mai 6, 2020, 12:29

Merci pour l’exemple mais mon cas est un peu différent à la base, je voudrais pouvoir utiliser #trigger# dans mon scenario pour implementer de la logique qui est identique à tous les triggera.
Si le scenario verifie qui est le trigger il me semble plus simple de créer des scenario séparés (un pour chaque commande).
Par exemple j’ai des ping sur différents matériels.
En cas de ping a 0 pou rl’un d’entre eux je démarre un scenario.
Et la je ne veux pas savoir exactement qui est le trigger mais avoir une logique globale.
Genre des calcules lastChangeStateDuration(#trigger#,0) ou lastChangeStateDuration(tirgger(),0).
Créer des messages en récuperant construisant des string à partir du nom de la commande genre:
strtolower(substr(#trigger#,1,strpos(#trigger#, ‹ ] ›)-1))
Ce qui est bizarre c’est que #trigger# ou trigger() n’est pas toujours interpreté de la même maniere.
Dans le scenario suivant:

J’obtiens le log suivant:

[2020-05-06 14:07:05][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Equipements IT][Ping Panneaux Solaire][Etat].
[2020-05-06 14:07:05][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-05-06 14:07:05][SCENARIO] Mise à jour du tag #equipement# => 1
[2020-05-06 14:07:05][SCENARIO] Affectation de la variable equipementVar => 1 = 1
[2020-05-06 14:07:05][SCENARIO] Log : DEBUG0 0=2 1=1
[2020-05-06 14:07:05][SCENARIO] Commande introuvable : trigger
[2020-05-06 14:07:05][SCENARIO] Log : DEBUG2 triggeFct0=-2 triggerFct1=-2
[2020-05-06 14:07:05][SCENARIO] Log : DEBUG3 triggerValue=1 triggerFct=1 triggerTag=[Equipements IT][Ping Panneaux Solaire][Etat]

Donc je n’ai pas l’impression que trigger() renvoi le nom de la commande responsable du démarrage du scenario.Je comprenais que justement l’utilisation du trigger permettait d’abstraire le nom de la commande responsable du démarrage du scenario.

scotty92fr · Mai 6, 2020, 1:37

Bonjour à tous,
Voyant ce sujet et la nouvelle doc que je viens de relire.

j’ai donc fait un test et je confirme qu’en version 4.0.54, contrairement à ce qui est marqué dans la doc la fonction « trigger() » ne renvoie pas le nom de la commande mais sa valeur.

Salvialf · Mai 6, 2020, 1:50

Dans les exemples la commande est renseignée entre parenthèses:

trigger(commande) : Permet de connaître le déclencheur du scénario ou de savoir si c’est bien la commande passée en paramètre qui a déclenché le scénario.

triggerValue(commande) : Permet de connaître la valeur du déclencheur du scénario.

ovomaltin · Mai 6, 2020, 2:09

@Salvialf la doc dit aussi que sans la commande en parametre trigger() elle doit renvoyer le nom de la commande.
C’est d’ailleurs aussi ce qui est dans le code comme indiqué plus haut.
Et c’est ce que faisait #trigger# (qui est censé devenir obsolete).

Donc comment récuperer le nom de la commande qui a declenché le scenario si trigger() ne le fait pas?

Phil56 · Mai 6, 2020, 2:14

Bonjour,

ça toujours été « obscure » ces fonctions. Et dans le temps il y a eu des changements de comportement.

Aujourd’hui si je regarde les 2 doc (3et4) je devrais avoir plein de scénario en carafe, c’est peut être ce qui va arriver lors de mon passage en V4.

Par exemple j’utilise beaucoup les :

trigger()

sans paramètre pour obtenir la valeur du déclencheur. Visiblement il ne faut plus le faire (depuis quand je ne sais pas), il est préférable d’utiliser :

triggerValue()

Pourquoi pas j’ai du taff mais pourquoi pas, là où je ne comprends plus c’est que dans la doc il y a ça:

triggerValue(commande) : Permet de connaître la valeur du déclencheur du scénario.

Dans ce cas d’utilisation c’est quoi la commande ??
J’imagine que c’est une erreur dans la doc (copier/coller)

Ce qui me rassure … ou pas c’est qu’en v4 trigger() sans paramètre retourne toujours sa valeur.

Bref pour mon cas si on pouvait confirmer que la méthode triggerValue ne prend aucun paramètre je commencerais la modification de mes scénarios.

ken@vo
Phil

Salvialf · Mai 6, 2020, 2:21

Pour ma part j’ai des scénarios avec plusieurs triggers imbriqués dans des SI et ça fonctionne très bien avec les exemples de la doc:

trigger(#[Chambre][Radiateur][Température]#) || trigger(#[Chambre][Radiateur][Température consigne]#)

Et le déclencheur correspondant:

#[Chambre][Radiateur][Température]# <= #[Chambre][Radiateur][Température consigne]#-0.2

cela permet de lancer le bloc du SI au changement de température ou au changement de consigne

retour booléen de la fonction comme ça a été dit plus haut:

[SCENARIO] Exécution du sous-élément de type [condition] : if
[SCENARIO] Evaluation de la condition : [1 || 0] = Vrai
[SCENARIO] Exécution du sous-élément de type [action] : then

Salvialf · Mai 6, 2020, 3:05

Effectivement j’ai fait quelques tests du coup.

trigger() ou triggerValue() vides retournent tous les 2 la valeur de la commande.

trigger(#[commande]#) renvoie 1 ou 0.
triggerValue(#[commande]#) renvoie la valeur de la commande.

Donc je dirais qu’il est bien nécessaire de renseigner une information entre les parenthèses.

Je ne suis pas d’accord, c’est peut-être sujet à interprétation de la manière dont c’est rédigé mais la doc dit bien qu’il faut renseigner une info entre parenthèses:

trigger() : Peut être le nom de la commande qui a déclenché le scénario :
‘api’ si le lancement a été déclenché par l’API,
‘schedule’ si il a été lancé par une programmation,
‘user’ si il a été lancé manuellement,
‘start’ pour un lancement au démarrage de Jeedom.

Donc un retour 1 ou 0 selon ce qui est renseigné entre parenthèses qui peut être le nom de la commande ou ‘api’ ou ‘schedule’ ou ‘user’ ou ‘start’.

Après il faudrait étudier la fonction en détail pour plus de précisions mais en l’état ça correspond bien à ce qui est écrit dans la doc.

ovomaltin · Mai 6, 2020, 3:20

trigger() : Peut être le nom de la commande qui a déclenché le scénario :
‘api’ si le lancement a été déclenché par l’API,
‘schedule’ si il a été lancé par une programmation,
‘user’ si il a été lancé manuellement,
‘start’ pour un lancement au démarrage de Jeedom.
Pour moi ca veut dire que trigger() renvoi le nom de la commande et pas 1 ou 0.
D’ailleurs quand on utilise trigger() avec un démarrage manuellement on a bien user qui est renvoyé.

Si je regarde le code de scenarioExpression.class la fonction trigger renvoi (return $_scenario->getRealTrigger();) s’il n’y a aucun parametre (name = ‹ ›).
Et quand je regarde dans le code de scenario.class getRealtrigger devrait renvoyer le nom de la commande. Donc pas de retour 0 ou 1 mais la chaine #[commande]#

Enfin c’est ma compréhension du code

scotty92fr · Mai 6, 2020, 3:26

oui @Salvialf, mais il y a aussi ce passage qui est troublant dans la doc :

#trigger# (deprecié, mieux vaut utiliser trigger()) : Peut être le nom de la commande qui a déclenché le scénario :
‘api’ si le lancement a été déclenché par l’API,
‘schedule’ si il a été lancé par une programmation,
‘user’ si il a été lancé manuellement,
‘start’ pour un lancement au démarrage de Jeedom.
#trigger_value# (deprecié, mieux vaut utiliser triggerValue()) : Pour la valeur de la commande ayant déclenché le scénario

Salvialf · Mai 6, 2020, 3:35

C’est le même effectivement il manque des « ou » entre chaque.

Peut être le nom de la commande qui a déclenché le scénario ou ‘api’ si le lancement a été déclenché par l’API ou ‘schedule’ si il a été lancé par une programmation ou etc…

Salvialf · Mai 6, 2020, 3:57

Ce n’est pas ce que j’en comprends du peu que j’arrive à déduire car ça se complique au niveau de getRealTrigger() pour moi.

La fonction getRealTrigger() récupère le déclencheur qui a lancé le scénario.

Si tu regardes bien les 2 fonctions trigger() et triggerValue() :

trigger() attend 2 paramètres: $_name et le scénario en cours(&$_scenario).
– Si $_name est vide il renvoie $_scenario->getRealTrigger()
– Si $_name est renseigné il compare $_name avec $_scenario->getRealTrigger() et envoie 1 s’ils sont égaux.

alors que

triggerValue() n’attend que le paramètre du scénario en cours &$_scenario qu’il récupère automatiquement. La fonction exécute la commande déclencheur et renvoie sa valeur $_scenario->getRealTrigger()

Je pense que la démonstration est faite je m’arrête là de toute façon il est tout à fait possible d’obtenir le résultat que vous voulez du scénario grâce à cette fonction en l’utilisant comme attendu.

D’autant plus que les déclencheurs sont forcément connus !

Phil56 · Mai 6, 2020, 3:58

Salvialf:

Pour ma part j’ai des scénarios avec plusieurs triggers imbriqués dans des SI et ça fonctionne très bien avec les exemples de la doc:
trigger(#[Chambre][Radiateur][Température]#) || trigger(#[Chambre][Radiateur][Température consigne]#)
Et le déclencheur correspondant:

Salvialf, je n’ai pas dit le contraire, je l’utilise aussi souvent comme cela.
D’ailleurs souvent j’ai un bloc if avec plusieurs tests comme les tiens et en plus un trigger() ==1 sans paramètre pour vérifier si c’est un passage à 1 d’un des déclencheurs.

Donc visiblement c’est quelque chose qu’il faut « maintenant » proscrire, je vais utiliser TriggerValue à la place, mais si à cette méthode il faut passer la commande je ne vois pas l’intérêt, au tant juste mettre la commande dans le test. C’est pour cela que je me dis que c’est une erreur de Doc

ken@vo
Phil

Salvialf · Mai 6, 2020, 3:59

Non triggerValue tu n’as pas besoin de lui passer le commande pour récupérer la valeur du déclencheur.

Phil56 · Mai 6, 2020, 4:00

nos message se sont croisés, c’est bien une erreur dans la Doc

Salvialf · Mai 6, 2020, 4:02

Par contre oui y’a un truc que je ne comprends pas tout à fait effectivement c’est que triggerValue() éxécute la commande pour récupérer la valeur à priori alors que trigger() non et pourtant le retour est identique…

Phil56 · Mai 6, 2020, 4:05

ça explique peut être, surement, les différences de comportement de ces fonctions suivant le type de commande (plugin) utilisé…

Edit : je vais donc faire mes migrations vers triggerValue petit à petit…

Salvialf · Mai 6, 2020, 4:23

Bon allez la solution pour récupérer la commande (ID ou Nom) déclencheur sans rien renseigner :

Bloc Code scénario:

$realTriggerID = $scenario->getRealTrigger();
$scenario->setLog($realTriggerID);

$realTriggerName = cmd::cmdToHumanReadable($scenario->getRealTrigger());
$scenario->setLog($realTriggerName);