Scénario gestion de la concurrence du bloc dans

zeenlym · Janvier 4, 2021, 2:46

Bonjour à tous,

J’ai créé un scénario qui réalise une tâche planifié avec le bloc « dans ». Ce scénario est lui même appelé depuis plusieurs sources. Le problème c’est que si deux appels sont trop proche je perds la définition du bloc « dans » de la précédente exécution du scénario.

Voici l’illustration de mon problème:

------------------------------------
[2021-01-04 11:52:19][SCENARIO] Start : Lancement provoque par le scenario  : [Test concurrence][concurrence aaaa]. Tags : {"#aTag#":"aaaa"}
[2021-01-04 11:52:19][SCENARIO] Exécution du sous-élément de type [condition] : in
[2021-01-04 11:52:19][SCENARIO] Evaluation de la condition : [1] = 1
[2021-01-04 11:52:19][SCENARIO] Tâche : 61 programmée à : 2021-01-04 11:53:19 (+ 1 min)
[2021-01-04 11:52:19][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-01-04 11:52:28][SCENARIO] Start : Lancement provoque par le scenario  : [Test concurrence][concurrence bbbb]. Tags : {"#aTag#":"bbbb"}
[2021-01-04 11:52:28][SCENARIO] Exécution du sous-élément de type [condition] : in
[2021-01-04 11:52:28][SCENARIO] Evaluation de la condition : [1] = 1
[2021-01-04 11:52:28][SCENARIO] Tâche : 61 programmée à : 2021-01-04 11:53:28 (+ 1 min)
[2021-01-04 11:52:28][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-01-04 11:53:03][SCENARIO] ************Lancement sous tâche**************
[2021-01-04 11:53:03][SCENARIO] Tags : {"#aTag#":"bbbb"}
[2021-01-04 11:53:28][SCENARIO] Exécution du sous-élément de type [action] : do
[2021-01-04 11:53:28][SCENARIO] Log : aTag = bbbb
[2021-01-04 11:53:28][SCENARIO] ************FIN sous tâche**************

Comment je peux m’assurer de garder les deux sous-tâches programmées aaaa et bbbb ?

Note a: il s’agit de jeedom 4.0
Note b: pour ceux qui veulent plus d’information sur ma problématique complète:

J’ai créé un scénario pour m’assurer de l’application d’un paramètre pour mes thermostat ZWave.
Le déroulement est le suivant:

vérification de l’arrêt du thermostat (avec un certain nombre de check)
si ce n’est pas le cas:
** application du paramètre d’arrêt
** planification de l’appel de ce scénario avec les mêmes tags dans 3 minutes

Cependant j’utilise ce scénario sur mes 7 thermostat et de temps en temps il arrive que 2 d’entre eux nécessitent de planifier l’application de la commande a peut près en même temps et le deuxième appel écrase le premier.

mich0111 · Janvier 4, 2021, 2:57

Bonjour,
Comme tu le fais, ce ne pourra pas marcher.
Une exécution d’un bloc DANS annule forcément le précédent dans le moteur de tâches.
Pour faire ce que tu veux, à part plusieurs scénarios différents ou une utilisation de tags, je ne vois pas.
Tu pourrais créer autant de blocs DANS différents que de tags. De la sorte, le précédent ne sera pas annulé par le suivant.

zeenlym · Janvier 4, 2021, 3:10

Arf du coup je perds un peu le coté générique.

Je le garde en tête si je ne trouve pas mieux.

mich0111 · Janvier 4, 2021, 3:24

D’un autre côté, il vaut mieux que ça marche comme ça sinon les empilements de tâches en cas de mauvais codage risqueraient de faire mal.

kiboost · Janvier 4, 2021, 4:04

Sinon tu fait des blocs SI en fonction de la source avec les DANS dans chaque si.

Bad · Janvier 4, 2021, 4:17

Hello @zeenlym,

J’ai bien compris le coté « sexy » du scenario générique, mais je peux te propose une autre approche que j’utilisait à l’époque où mes rads étaient instables :
Toutes les 3 minutes (c’est un peu bourrin, chez moi c’était toutes les 30 minutes, à 58 et 23) : Test Rad par Rad, s’il doit être allumé → tu forces l’allumage, sinon l’extinction.
L’état sous-jacent du Rad est géré par un autre scénario, ou un virtuel, ou le plugin thermostat, en fonction des conditions que tu souhaites y appliquer (fenêtre, présence, température exterieure, etc).

Qu’en dis tu ?

zeenlym · Janvier 4, 2021, 4:34

En fait mes radiateurs sont pilotés par le plugin thermostat.

En action de chauffe le thermostat met la consigne du radiateur au niveau le plus chaud + 1°C.
En action d’arrêt le thermostat met la consigne 10°C au radiateur et appel le scénario qui vérifie que la consigne a bien été appliquée.

J’ai vu qu’il est possible de mettre un cron de répétition mais je ne voulais pas surcharger mon réseau ZWave de commande inutiles. D’où mon scénario.

Bad · Janvier 4, 2021, 5:26

Ok, je comprends et c’est plutôt sympa comme façon d’utiliser les scénario.

Du coup j’ai eu envie de voir si on peut jouer avec des sleeps pour laisser les scénarios se dérouler en parallèle.

Je te présente donc pouet :

Et ses appelants pouet_chapeau30 :

Et pouet_chapeau16 :

L’idée est d’utiliser les tags pour dire à pouet de se relancer (ou non) au bout d’un certain temps (ou non).

Je lance pouet à vide pour vérifier qu’il ne fait rien à vide, puis chapeau16 et 10 secondes après chapeau30, les messages et les logs de pouet montrent bien les 5 lancements :

[2021-01-04 18:12:42][SCENARIO] Start : Scenario lance manuellement.
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [action] : action
[2021-01-04 18:12:42][SCENARIO] Exécution d'un bloc élément : 952
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:12:42][SCENARIO] Evaluation de la condition : [0 != 0] = Faux
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [action] : else
[2021-01-04 18:12:42][SCENARIO] Exécution d'un bloc élément : 953
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:12:42][SCENARIO] Evaluation de la condition : ["" != ""] = Faux
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [action] : else
[2021-01-04 18:12:42][SCENARIO] Exécution d'un bloc élément : 954
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:12:42][SCENARIO] Evaluation de la condition : [0] = 0
[2021-01-04 18:12:42][SCENARIO] Exécution du sous-élément de type [action] : else
[2021-01-04 18:12:42][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-01-04 18:13:04][SCENARIO] Start : Lancement provoque par le scenario  : [pouet_chapeau30]. Tags : {"#sleepy#":"30","#relaunch#":"1","#msg#":"30 step1"}
[2021-01-04 18:13:04][SCENARIO] Exécution du sous-élément de type [action] : action
[2021-01-04 18:13:04][SCENARIO] Exécution d'un bloc élément : 952
[2021-01-04 18:13:04][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:04][SCENARIO] Evaluation de la condition : [30 != 0] = Vrai
[2021-01-04 18:13:04][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:04][SCENARIO] Pause de 30 seconde(s)
[2021-01-04 18:13:14][SCENARIO] Start : Lancement provoque par le scenario  : [pouet_chapeau16]. Tags : {"#sleepy#":"16","#relaunch#":"1","#msg#":"16 step1"}
[2021-01-04 18:13:14][SCENARIO] Exécution du sous-élément de type [action] : action
[2021-01-04 18:13:14][SCENARIO] Exécution d'un bloc élément : 952
[2021-01-04 18:13:14][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:14][SCENARIO] Evaluation de la condition : [16 != 0] = Vrai
[2021-01-04 18:13:14][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:14][SCENARIO] Pause de 16 seconde(s)
[2021-01-04 18:13:30][SCENARIO] Exécution d'un bloc élément : 953
[2021-01-04 18:13:30][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:30][SCENARIO] Evaluation de la condition : ["16 step1" != ""] = Vrai
[2021-01-04 18:13:30][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:30][SCENARIO] Ajout du message suivant dans le centre de message : 16 step1
[2021-01-04 18:13:30][SCENARIO] Exécution d'un bloc élément : 954
[2021-01-04 18:13:30][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:30][SCENARIO] Evaluation de la condition : [1] = 1
[2021-01-04 18:13:30][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:30][SCENARIO] Lancement du scénario : pouet options : {"#sleepy#":"10","#relaunch#":"0","#msg#":"16 step1 step2"}
[2021-01-04 18:13:30][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-01-04 18:13:31][SCENARIO] Start : Lancement provoque par le scenario  : [pouet]. Tags : {"#sleepy#":"10","#relaunch#":"0","#msg#":"16 step1 step2"}
[2021-01-04 18:13:31][SCENARIO] Exécution du sous-élément de type [action] : action
[2021-01-04 18:13:31][SCENARIO] Exécution d'un bloc élément : 952
[2021-01-04 18:13:31][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:31][SCENARIO] Evaluation de la condition : [10 != 0] = Vrai
[2021-01-04 18:13:31][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:31][SCENARIO] Pause de 10 seconde(s)
[2021-01-04 18:13:34][SCENARIO] Exécution d'un bloc élément : 953
[2021-01-04 18:13:34][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:34][SCENARIO] Evaluation de la condition : ["30 step1" != ""] = Vrai
[2021-01-04 18:13:34][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:35][SCENARIO] Ajout du message suivant dans le centre de message : 30 step1
[2021-01-04 18:13:35][SCENARIO] Exécution d'un bloc élément : 954
[2021-01-04 18:13:35][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:35][SCENARIO] Evaluation de la condition : [1] = 1
[2021-01-04 18:13:35][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:35][SCENARIO] Lancement du scénario : pouet options : {"#sleepy#":"10","#relaunch#":"0","#msg#":"30 step1 step2"}
[2021-01-04 18:13:35][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-01-04 18:13:35][SCENARIO] Start : Lancement provoque par le scenario  : [pouet]. Tags : {"#sleepy#":"10","#relaunch#":"0","#msg#":"30 step1 step2"}
[2021-01-04 18:13:35][SCENARIO] Exécution du sous-élément de type [action] : action
[2021-01-04 18:13:35][SCENARIO] Exécution d'un bloc élément : 952
[2021-01-04 18:13:35][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:35][SCENARIO] Evaluation de la condition : [10 != 0] = Vrai
[2021-01-04 18:13:35][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:35][SCENARIO] Pause de 10 seconde(s)
[2021-01-04 18:13:41][SCENARIO] Exécution d'un bloc élément : 953
[2021-01-04 18:13:41][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:41][SCENARIO] Evaluation de la condition : ["16 step1 step2" != ""] = Vrai
[2021-01-04 18:13:41][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:41][SCENARIO] Ajout du message suivant dans le centre de message : 16 step1 step2
[2021-01-04 18:13:41][SCENARIO] Exécution d'un bloc élément : 954
[2021-01-04 18:13:41][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:41][SCENARIO] Evaluation de la condition : [0] = 0
[2021-01-04 18:13:41][SCENARIO] Exécution du sous-élément de type [action] : else
[2021-01-04 18:13:41][SCENARIO] Fin correcte du scénario
------------------------------------
[2021-01-04 18:13:45][SCENARIO] Exécution d'un bloc élément : 953
[2021-01-04 18:13:45][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:45][SCENARIO] Evaluation de la condition : ["30 step1 step2" != ""] = Vrai
[2021-01-04 18:13:45][SCENARIO] Exécution du sous-élément de type [action] : then
[2021-01-04 18:13:46][SCENARIO] Ajout du message suivant dans le centre de message : 30 step1 step2
[2021-01-04 18:13:46][SCENARIO] Exécution d'un bloc élément : 954
[2021-01-04 18:13:46][SCENARIO] Exécution du sous-élément de type [condition] : if
[2021-01-04 18:13:46][SCENARIO] Evaluation de la condition : [0] = 0
[2021-01-04 18:13:46][SCENARIO] Exécution du sous-élément de type [action] : else
[2021-01-04 18:13:46][SCENARIO] Fin correcte du scénario
------------------------------------

Donc je pense que tu dois pouvoir travailler avec des sleep, 180-240 secondes ne devrait pas poser de pb sur un scenario en multi lancement.

On pourrait aussi imaginer décrémenter relaunch pour gérer un nombre de relancement ou une commande (virtuel ou non) dont t’on testerait depuis combien elle a été mise à jour pour arrêter le scenario dans tous les cas.

Bon je me suis bien amusé, maintenant on me demande de faire à manger, et ça Jeedom ne le faire pas encore lol

mich0111 · Janvier 4, 2021, 5:46

Sauf que le sleep est la pire des fonctions puisqu’elle est bloquante.

Bad · Janvier 4, 2021, 7:12

Bloquante certes, mais uniquement pour le thread d’exécution en cours.
C’est pas comme si Jeedom s’arrêtait de faire autre chose en attendant, on est pas dans le process principal d’un daemon ou dans un système temps réel, qui doit toujours pouvoir traiter des entrées.

Il y a des alternatives certes, je cherchais juste une façon de garder l’élégance de scenario générique de zeenlym et trouvais ça fun de réussir à utiliser les scenarios de cette façon.

Je ne suis même pas sur que ce scénario soit 100% utile dans la cas de l’utilisation du plugin thermostat, il devrait détecter automatiquement une défaillance si le chauffage ne se coupe pas.
Une bonne idée serait plutôt de demander une amélioration sur le plugin pour prendre en compte le retour d’état Zwave, comme sur le plugin sunshutter, afin de détecter une déviance par rapport à l’ordre et alerter s’il n’arrive pas à corriger (ex module ne réponds pas après 3 tentatives).

mich0111 · Janvier 4, 2021, 7:25

Je ne vois pas en quoi l’utilisation d’un DANS ou d’un A serait moins élégant qu’un sleep.
Autant laisser le core gérer le séquencement des tâches dans son moteur.

Bad · Janvier 4, 2021, 7:51

Dans le cas présent on ne peut pas utiliser de bloc DANS / A :

Et on d’accord, un bloc DANS / A est bien plus élégant qu’un sleep. Je parlais de l’élégance d’un scénario, de gestion des problèmes de chauffage, générique.

zeenlym · Janvier 5, 2021, 10:27

Merci pour cette solution,

Effectivement dans ce cas je préfère utiliser sleep en mode multi lancement. Ce sera mieux que d’envoyer 300 commandes par jour à chaque équipement ZWave ou de risquer de laisser le chauffage tourner trop longtemps.

Je vous tiens au courant si j’ai encore des soucis

Bad · Janvier 5, 2021, 10:29

De rien, mais je répète :

zeenlym · Janvier 5, 2021, 10:38

Je comprends mais le problème c’est que j’ai un plancher chauffant radiant électrique qui a beaucoup d’inertie, le temps que le plugin me remonte une défaillance du chauffage il s’est écoulé environ 2h avec une température déjà trop élevé. Exemple pour la consigne ECO à 19°C et le max configuré à 21°C c’est dommage de détecter la défaillance à 21,1. Si cela arrive dans la chambre de ma fille en pleine nuit je suis bon pour les pleurs, la changer car elle aura transpirer et aérer la chambre pour faire baisser la température. Sans oublier qu’après avoir refermer la fenêtre la température va se remettre à monter.

En gros le plugin thermostat est bien mais la détection de la défaillance est trop tardive pour un chauffage à fort inertie. Je ne pense que mon problème nécessite de modifier le plugin car ma solution d’appeler un scénario de contrôle n’est pas intrusive et en plus est totalement dans les capacités de Jeedom.

Bad · Janvier 5, 2021, 10:50

Je comprends mieux moi aussi. Merci d’avoir pris le temps de détailler !

Du coup une autre suggestion serait peut être de contrôler l’état en lançant un scenario après l’action de changement d’état pour valider le retour, et on garde ce beau coté générique :

That was my lasts 2 cents

system · Janvier 6, 2021, 10:50

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.