Comme première action : mémorise le triggerValue dans un tag
tag : Mon triggerValue = triggerVale()
puis tu utilises dans tes tests tag(Mon triggerValue)
(Mais on progresse ! 
tu as maintenant la bonne info pour commencer !
Je croix que tu peux en profiter pour décocher la réponse du sujet !!??)
Bonjour,
En 4.3 lorsqu’on utilise triggervalue() c’est comme si tu demandais la valeur actuel de la commande qui a déclenché le scénario, ce n’est donc pas du tout révélateur sachant que celle-ci a peut-être évolué entre le moment ou le scénario c’est lancé et le moment ou tu fait appelle a cette fonction.
Exemple :
Scénario se lance sur changement de valeur = 1
triggervalue() renverra 1
En 4.4, il me semble que sa ne changera rien, sauf si le scénario est en mode Synchrone.
J’avait déjà testé une méthode qui consiste a créer un tag permanent, récupérable avec la méthode traditionnelle, je proposerai sans doute un PR…
@Henri comme ça du coup :
J’ai rien coché.
@Phpvarious ,
Franchement, il serait bien d’avoir la valeur de la commande lors du déclenchement.
La documentation laisse penser cela, d’où mon erreur.
Dans mon cas, il y a peut-être une autre solution, mais j’ose pas trop y toucher, c’est dans la configuration de l’équipement (télécommande) dans cet onglet:
Si le triggerValue est fixé : ce qui a des avantage comme ici, mais qui peut être ennuyant si l’on souhaite suivre la valeur d’un déclencheur quand on en a plusieurs.
Peux-tu me donner la technique ?
(je vais essayer ce soir, mais par exemple est-ce que l’on pourra la suivre en utilisant la fonction
value(trigger())
ou il faudra passer par un bloc code ??
PS: (j’avais fais une boulette en écrivant d’abord « value(triggerValue()) ». Je voulais évidement dire « value(trigger()) » sinon, ça n’a pas de sens…)
(réponse précedente : Exactement )
Edit : NON #mon tag# est déprécié
il faut utiliser tag(mon tag)
Je teste sur plusieurs jours et je vous dis
Pas forcement :
triggerValue(): Permet de connaître la valeur du déclencheur du scénario.
Le déclencheur du scenario est une commande, il n’est pas dit que c’est la valeur au moment du déclenchement du scenario, mais juste la valeur de la commande correspondante … Pas c’est pas hyper claire, je vous l’accorde, il y aurait un vrai besoin d’avoir une commande qui permet d’avoir la valeur qui a déclenché le scenario (et pas la valeur du déclencheur)
Et ainsi avoir dans la doc :
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(): Permet de connaître la valeur qui a déclenché le scenario (donc au moment du declenchement)value(trigger()): Permet de connaître la valeur du déclencheur du scénario (à l’instant T)
Cette commande fonctionne!
Oui, mais aujourd’hui, c’est exactement la même chose que triggerValue()
Et demain ? 
Et voilà, cela ne marche plus 
Je crois que je vais faire des conditions uniquement sur les trigger.
#[Itinérant][8 - Fibargroup Keyfob FGKF601 Mathieu][CentralScene-1]# == 4Mathieu
Comme déjà dit, des valeurs sont remises à jour trop rapidement par ta télécommande … Le fait de mettre un tag ne fera que réduire la prévalence du pb !
La seule solution est de ne pas utiliser le triggerValue et de découper des scenarios
oui et non,
tu pourrais aussi faire triggerValue(#le nom du déclencheur#, "autre chose", "ca ne sert a rien", "toujours a rien") que ca « fonctionnera » toujours (ou toujours pas)
la réponse à la question d’origine a déjà été donnée, vous pouvez tourner ca dans tous les sens mais la seule solution c’est plusieurs scénarios.
Oui, c’est ce que je vais finalement faire.
Merci à tous.
Si tout le monde est ok, je ferme le sujet en mettant la réponse de @mich0111 en solution.
Mathieu
C’est juste un avis perso 
, mais si besoin de suivre la valeur, triggerValue n’est plus approprié, il faut , comme déja cité, scinder les scénarios et simplement utiliser le nom de la commande …
Mais pour éviter de toucher les users qui utilisent cette fonction dans cette optique, je créerai plutôt un nouveau tag qui serait permanent et qui ne bougerait plus tout au long du scénario.
Edit :
Voila 1 ligne rajouté dans le core et hop un tag #mytrigger_value# qui ne bouge plus :
Je pense qu’il faut aussi penser à limiter le nombre d’option/fonction/comportement sinon ça devient incompréhensible pour un utilisateur (qui ne va pas forcément comprendre toutes les subtilités) et trop complexe à gérer tous les cas pour le dev.
Ici le but est « avoir la valeur qui a déclenché » donc faut changer la fonction actuelle.
Surtout qu’en fait les cas où la valeur de déclenchement n’est plus la valeur de la commande parce que celle ci a déjà changé entre temps reste un pourcentage faible des cas d’usage… la plupart du temps une valeur ne change pas si vite donc évitons de complexifier pour tout le monde pour un cas limite.
Ça c’est mon avis 
C’est mon avis aussi
C’est ce que j’aurai évité, sinon on risque d’avoir des retour de cas inverse.(mon scénario marchait mais il marche plus …)
Tout a fait d’accord, d’ailleurs je n’est jamais eu ce cas.
Tout a fait d’accord aussi, mais je sais que c’est pas la 1ère fois que je voit cette demande.
Je pense que le « fonctionnement normal » de cette fonction est d’avoir la valeur qui a declenché … sinon, on n’utilise pas la fonction triggervalue !
Donc les cas ou un scenario attend une autre valeur que celle qui a declenché devraient etre hyper hyper minoritaires, et si ca arrive, la fonction value(trigger()) pourra facilement se substituer à la commande triggervalue()
Le tag en debut de scenario me semble etre un pansement.
donc je plussoie la demande de modif de @Mips mais comme je ne sui spas dev, je ne peux que plussoiyer 
Norbert
Mais moi je décide de rien , en tous cas , il est sûr que je ne ferai de PR qui modifierai le fonctionnement actuelle d’une fonction, minoritaire ou pas.
Bonjour
Effectivement il n’est pas possible de faire ce genre de changement qui même si il est potentiellement justifiable ferait que je serais encore clouer au pilori pour amateurisme (entre autres)
Le mieux pour ce genre de cas et de faire plusieurs scénarios avec le test de la valeur dans le trigger.
