Bonjour.
J’ai créé un scénario pour démarrer/stopper ma chaudière et mon circulateur (avec une temporisation pour ce dernier). Il s’active automatiquement lorsque la température est atteinte dans toutes les pièces.
Je n’ai pas activé le multi-lancement ni le mode synchrone mais, malgré cela, le scénario démarre de manière intempestive alors qu’il est en pause (temporisation), cela se voit au niveau des logs.
Est-ce un bug? Y a-t-il quelque chose que je n’ai pas compris?
Merci d’avance
Bonjour,
Difficile de comprendre sans voir les scénarios.
Une copie d’écran aiderai 
1 « J'aime »
Voici le scenario que j’exécute (j’ai entre temps changé sleep en wait) mais cela donne une erreur à l’exécution.
Et voici les paramètres associés au scénario:
On voit au niveau des logs que le scénario s’arrête quelques dizaines de secondes après la temporisation (le wait) et il est marqué en « erreur ».
Bonjour,
Le wait attention une condition comme la case l’indique.
Si la condition est atteinte le scénario se poursuit.
Mais même si la condition n’est toujours pas atteinte au bout des 300s que tu as mis, le scénario se poursuit.
Si tu n’as pas de conditions à attendre alors utilise la fonction sleep.
Mais avec le sleep, une autre instance du scénario est lancée avant que le scenario se termine.
Avec le wait, apparemment moins de 300 secondes fonctionne mais plus de 300 secondes d’attente ne fonctionne pas (scenario en erreur).
Je n’ai pas compris, il faudrait voir les logs du scénario.
Sinon autre erreur, le premier SI doit utiliser un opérateur de comparaison donc == et pas =
Idem dans les évènements déclencheur
2 « J'aime »
Bonjour,
Non ceci n’est pas correcte.
A tout le moins que l’opérateur de comparaison soit « = » ou « == », la comparaison fonctionne. Là n’est pas le souci!
Mon soucis est qu’un wait de 240 secondes sans condition, provoque une erreur dans le scénario qui s’arrête.
Voici le log de mon scenario avec un wait de 240 secondes à l’issue du wait (le scénario étant marqué « erreur »)
Et donc ?
J’ai indiqué qu’il ne fallait pas utiliser de wait sans mettre de conditions donc pourquoi ne pas changer ça ??
Soit tu as un état associé pour vérifier que le OFF1 a bien fonctionné et tu l’indique dans la condition soit tu dois utiliser un sleep et non un wait pour attendre avant poursuite du scénario.
1 « J'aime »
Que ce soit avec un sleep ou un wait, le résultat est le même, le scénario s’arrête à l’issue du sleep:
Alors refait le scénario, pour une raison que j’ignore il doit être cassé car il n’y a plus de raisons au fait qu’il passe en erreur.
Non c’est faux, il y a un soucis!
= est une assignation, donc le résultat sera toujours vrai.
Si vous venez demander de l’aide, veillez à suivre les indications que l’on vous donne => cela ne sert à rien d’investiguer un possible problème si il y a d’autres problèmes ou incohérences identifiées dans votre scénario.
Il faut d’abord le « nettoyer » pour ensuite voir si on reproduit.
D’autres part, veuillez fournir les logs au format texte et pas dans une capture d’écran pour plus de lisibilité en copiant/collant le contenu dans un Texte préformaté comme ceci:
saisissez ou collez du code ici
S’il y a une erreur, il faudrait voir le log « scenario_execution » pour avoir plus de détails probablement.
4 « J'aime »
Bonjour,
Tu ne fais pas de comparaison. Puisque :
= c’est de l’assignation
== c’est de la comparaison.
A=1
B=2
A=B donc A vaut 2
A==B c’est faux puisque 1 est différent de 2
Donc si A=B sera toujours vrai ! Puisque 2=2 !
Mais il n’y a effectivement aucun souci. Tout dépend du résultat attendu et de ce que l’on veut faire.
1 « J'aime »
Hello,
Si je peux donner mon avis : il faut éviter de laisser des scenarios tourner trop longtemps.
Pourquoi ne pas utiliser un bloc « DANS 4 minutes », avec en condition d’entrée un test sur la variable EtatChaudière ?
Du genre :
Le « remove_inat » s’assure qu’il n’y a pas de sous-scenario qui se lancera intempestivement si le scenario est relancé dans l’intervale.
En passant, plutôt qu’une variable, j’utiliserai un virtuel avec une info/binaire à la place d’EtatChaudiere et une autre info/binaire pour simplifier la condition d’entrée du scenario et le piloter :
3 « J'aime »
En fait non, Jeedom remplace l’operateur d’affectation = par l’opérateur == dans les expression :
& 
C’est réalisé ici en stable :
1 « J'aime »
En fait non, pas dans le comportement des scénarios Jeedom :
En effet, c’est une permission (hélas) tolérée par Jeedom.
Ce qui n’empêche pas que la bonne pratique reste bien entendu : SI : variable(mavar) == 2
1 « J'aime »
Génial votre méthode fonctionne … le « Dans » semble plus robuste que mon « wait » ou « sleep ».
Je vais creuser pour utiliser un virtuel.
Merci pour le conseil.
bonjour,
rien à voir avec ta question
J’ai créé un scénario pour démarrer/stopper ma chaudière et mon circulateur (avec une temporisation pour ce dernier)
dans ton profil tu utilises zwave
ton equipement n’a pas un stop auto au bout de x minute ?
beaucoup de relai l’ont en paramètre
chaque relance prolonge et tu te fiche du stop
Oui donc en fait les effets de bords permettent des écritures aberrantes.
Donc le jour ou un fix correcte est fait ce genre de pratique va donner lieu à des :
Avant ca marchait !
Je ne conais cela que trop bien. Hélas
Curieusement, depuis quelques jours, j’ai un scénario assez basique qui plante également avec un « sleep 500 ». C’est un sécanrio que je n’ai pas touché depuis longtemps. Dans le log, le scénario s’arrête lors du sleep… Est-ce un problème de format d’une variable dans le core jeedom ? (je n’ai pas fait de mise à jour php). Je remplace par un for 1 à 50 d’un sleep de 50s. On verra demain mais c’est curieux et cela ressemble au problème décrit…