Scénario "function" : passer une commande à un scénario via tag

Bonjour, j’ai besoin d’un conseil de programmation.

Contexte : J’ai un problème récurrent avec mes scénarios : de l’information se perd dans la nature. C’est-à-dire qu’une action n’est pas appliquée (par ex. commande « allumer une lampe » non exécutée) ou son retour d’état est trop long à revenir (commande « allumer une lampe » --> ok la lampe s’allume --> ok l’actionneur renvoie un état « allumé » --> état lu sur Jeedom : 7 secondes…) ou le retour d’état correct ne parvient pas à Jeedom. C’est du matériel Fibaro en Zwave, donc plutôt réactif ? Dans tous les cas, j’entends que ces protocoles « sans fil » ne sont pas parfaits, j’ai plein de métal dans le béton des murs. Bref, j’essaie de rendre le plus « robuste » possible chaque scénario, en insistant sur une commande jusqu’à ce que l’état correct soit renvoyé.

Je trouve un peu idiot de réécrire toujours les mêmes séquences pour répéter les vérifications. Comme je ne souhaite pas bloquer un scénario pendant ces vérifications, j’ai pensé faire office de « function » avec des petits scénarios génériques pour lesquels je passe en tag des commandes. Déjà : est-ce la bonne idée ?

Ensuite, j’ai essayé le petit test suivant pour « externaliser » une action wait until #[Hall][Plafonnier][Etat]# == 0 with timeout of 5 sec:
test_-_Jeedom
avec le scénario « function » [Script][verifState] suivant :
verifState_-_Jeedom
Dans ce dernier, la concaténation de chaine ne marche pas, et j’hésite sur value()?

Merci :slight_smile:

Bonjour,
je ne saurais pas te répondre pour la concaténation la, mais tu devrais peut être essayer avec le framework SC très utile pour ce genre de scénario dynamique :slight_smile:


http://rulistaff.free.fr/sc/doc/

Je l’utilie pour mes chauffages (fil pilote z-wave) car j’ai aussi parfois des ordres qui se perdent. L’inconvénient de ce framework c’est qu’il faut programmer ton scénario en php mais ça vaut le coup :wink:

Curieux, il est ok chez moi…

Merci @pifou, je ne connaissais pas.
Impressionnant boulot @dJuL :sunglasses:
Y’en a qui maîtrisent leur sujet ! Je te souhaite d’être intégré dans Jeedom… La construction par bloc des scénarios est en effet un peu trop limitante.

Du coup vous faites comment ? N’y a-t-il pas dans Zwave, ou Zigbee, ou… un moyen de forcer le module à confirmer qu’il a bien entendu la commande ? Comment faites vous dans vos scénarios ?

En suivant les recommandations précédentes, j’essaie de passer par PHP :
verifState_-_Jeedom
Dans un premier temps, cela m’a effectivement permis de récupérer l’état associé à ma commande :

// return the state of command
$tags = $scenario->getTags();
$cmdName = trim($tags['#cmdName#'],'\"');
$cmd = cmd::byString("#$cmdName#");
$tags['#stateCmd#'] = $cmd->execCmd();
$scenario->setTags($tags);

Le pop-up s’ouvre convenablement.
Mais du coup, si je retourne l’état dans un tag, je ne vais pas vraiment pouvoir exécuter un bloc « wait » ? Du coup je n’ai pas vraiment avancé :confused:

Je tente d’évoquer « wait » directement dans PHP en complétant le code précédent par :

// execute wait until command state or timeout are reached
$state = $tags['#state#'];
$condition = "#$cmdName# == $state";
$timeout = $tags['#timeout#'];
$scenario->setLog('__ Condition : '.$condition);
$scenario->setLog('__ Timeout : '.$timeout);
$time_start = microtime(true);
scenarioExpression::wait($condition,$timeout);
$scenario->setLog('__ Time to wait : '.(microtime(true)-$time_start));

Tout a l’air correct, sauf que le wait ne s’arrête que quand le timeout est atteint comme on le voit dans ces logs :

------------------------------------
[2020-04-20 02:39:10][SCENARIO] Start : Lancement provoque par le scenario  : [Script][test]. Tags : {"#cmdName#":"\"[Hall de nuit 1er][Plafonnier][Etat]\"","#state#":"0","#timeout#":"10"}
[2020-04-20 02:39:10][SCENARIO] Exécution du sous-élément de type [action] : code
[2020-04-20 02:39:10][SCENARIO] Exécution d'un bloc code
[2020-04-20 02:39:10][SCENARIO] __ Condition : #[Hall de nuit 1er][Plafonnier][Etat]# == 0
[2020-04-20 02:39:10][SCENARIO] __ Timeout : 10
[2020-04-20 02:39:21][SCENARIO] __ Time to wait : 11.017964839935
[2020-04-20 02:39:21][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-04-20 02:40:18][SCENARIO] Start : Lancement provoque par le scenario  : [Script][test]. Tags : {"#cmdName#":"\"[Hall de nuit 1er][Plafonnier][Etat]\"","#state#":"0","#timeout#":"60"}
[2020-04-20 02:40:18][SCENARIO] Exécution du sous-élément de type [action] : code
[2020-04-20 02:40:18][SCENARIO] Exécution d'un bloc code
[2020-04-20 02:40:18][SCENARIO] __ Condition : #[Hall de nuit 1er][Plafonnier][Etat]# == 0
[2020-04-20 02:40:18][SCENARIO] __ Timeout : 60
[2020-04-20 02:41:19][SCENARIO] __ Time to wait : 61.035176038742
[2020-04-20 02:41:19][SCENARIO] Fin correcte du scénario

Qu’est-ce que je ne fais pas bien ?


Sources :

Il faut faire un boucle qui répète la commande tant que l’état n’est pas atteint.

Là j’ai pas le temps mais je vais essayer de te répondre plus tard avec un exemple.

Pour mes chauffages: j’ai une variable que je met à jour en même temps que les chauffages (0 ou 1 donc), et j’ai un scénario qui vérifie toutes les 30 minutes que mes chauffages sont bien dans le même état que la variable!
Ce scénario met un message, et renvoie un ordre aux chauffages pour les aligner avec la variable… Je n’ai pas encore trouvé mieux.
Ton idée serait donc de faire un scénario « générique » qu’on utilise avec le nom et l’état d’une commande en tag, et qui boucle tant que l’état souhaité n’est pas atteint ?

Tout à fait : je veux pouvoir l’évoquer depuis tous mes scénarios en passant la commande d’action, la commande de retour d’état, la valeur de l’état attendu, et le timeout histoire de ne pas boucler à l’infini.

Là où je ne vois pas comment faire c’est quand l’état renvoyé est tout simplement incorrect à la base. Si par exemple c’est le « timeout » qui a fait sortir de la boucle de forçage. Là je perds tout contrôle.

C’est assez énervant, car si je fais actualiser la lecture de l’état en manuel, en général, ca se remet à la valeur réelle ?

État incorrect :
Plugin_-_Jeedom
État correct après avoir forcé manuellement la mise à jour :
Plugin_-_Jeedom2
Je n’ai pas trouvé comment forcer cette mise à jour, que Jeedom sait faire, depuis un scénario :frowning:

Bonjour, je me permets de te relancer… :wink:

bonjour
si c’est toujours ton soucis viens
de l’onglet association lifetime
Screenshot_20200531-181441_Chrome
sinon

ACTUALISER LA VALEUR D’UN PARAMÈTRE

ou si tu veux tous savoir et possibilités sur le zwave : nechry
exemple

Bonjour @sdrulhe,

As-tu trouvé la solution?
Je suis dans ton cas et je butte.

J’ai posté la discussion Fonction scenarioExpression::wait() attend toujours le timeout sans réponse :frowning: