J’observe dans un scénario un comportement troublant quand j’essaye de lancer des scénarios avec des tags.
Le tag « scene_id » passé dans la 1ère commande de lancement de scénario n’est pas effacé dans la 2ème commande de lancement de scénario (qui n’est pas le même scénario que dans la 1ère commande). Du coup ca se passe pas bien du tout car scénario en multi-lancement normalement
Ah oui en effet c’est curieux tu as raison. Même le tag custom « commande » n’est pas repris.
Est-ce ma façon de passer le tag « scene_id » qui engendre cet effet ? Ou alors que ce tag fasse partie du déclencheur du scénario ? Je penche pour la 2ème raison il faudrait que je teste.
je pense que j’ai identifié au moins une raison mais le seul façon que j’arrive à reproduire c’est quand j’ai un scénario qui se relance lui-même;
dans ce cas, dans le code on garde la même instance, et donc on garde les tags déjà existant (car c’était le fix précédent qui évitait d’écraser le tags par défaut et donc de se retrouver avec des scénarios sans le tag #trigger_name# par exemple (fix: Merge setTags method to append tags instead of replacing them by Mips2648 · Pull Request #3198 · jeedom/core · GitHub)
si c’est ca, je pense que la solution sera de « simplement » ne pas réutiliser l’instance en cours mais bien d’en créer une nouvelle dès qu’on veut faire une action sur un scénario;
Et oui le scénario courant est « Gestion Robot ». Quand je lance une routine de nettoyage de mon Roborock je reboucle sur le même scénario et selon le tag « status » il vient augmenter la fréquence de refresh du status du robot.
ok c’est clair, je vais proposer ma correction, on verra si qlqun à une meilleur idée
le bout code servait à optimiser les appels DB, clairement c’était bien, mais à présent que le scope d’execution des scénarios est revus pour les rendre plus indépendants, ca n’est probablement plus judicieux
Merci pour ton analyse.
Je me rappelle en effet maintenant du fix.
Moi j’aime bien relancer un scénario sur lui-même avec des tags. J’en ai même d’autres que celui-ci dans le même style. Je trouve que cela facilite la maintenance dans le temps de tout avoir au même endroit (d’où mon autre passion pour les triggers).
Je vois sans problème plusieurs solution pour « faire avec ». Dont une modification de mon IF qui, après test rapide, semble fonctionner (j’ai rajouté && status !== 1). Car mon LXC avec la bibliothèque python-roborock n’appréciait pas du tout les appels toutes les 8 secondes (je suis en multi lancement).
Je dois par contre vérifier les autres comportant le même type de programmation.
Pourrais-tu me donner un exemple simple mais complet ou tu arrives à reproduire le problème?
pcq je croyais avoir reproduit mais là j’y arrive plus donc c’est p-e pas ce que je pensais
J’ai notamment une interrogation sur le fait que le tag scene_id soit à l’origine dans le déclencheur du scénario. En fait que je ne fais que le passer dans mon appel au scénario Interface.
Quand je relance mon scenario X (= « Gestion Roborock ») sur lui-même, il hérite des tags qui lui avaient été passés à son déclenchement. Or dans mon cas j’initie bien le scénario avec un tag scene_id, que je reprends d’ailleurs dans mon lancement du scénario Y = « interface Roborock »).
Il aurait fallu que je ne désigne pas le tag d’appel du même nom que le tag que le scénario Y attend.
[2026-04-13 10:36:42][SCENARIO] -- Début : . Tags : {"#trigger#":"scenario","#trigger_name#":"[Aucun][Aucun][TITI]","#trigger_id#":196,"#trigger_message#":"Lancement provoqué par le scénario : [Aucun][Aucun][TITI]","#trigger_value#":"","#scene_id#":"test"}
[2026-04-13 10:36:42][SCENARIO] - Exécution du sous-élément de type [action] : action
[2026-04-13 10:36:42][SCENARIO] Lancement du scénario : TOTO options : {"#trigger#":"","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"","#trigger_value#":"","#commande#":"scene","#scene_id#":"test"}
[2026-04-13 10:36:42][SCENARIO] Lancement du scénario : TEST_TAG options : {"#trigger#":"scenario","#trigger_name#":"[Aucun][Aucun][TITI]","#trigger_id#":196,"#trigger_message#":"Lancement provoqu\u00e9 par le sc\u00e9nario : [Aucun][Aucun][TITI]","#trigger_value#":"","#scene_id#":"test","#status#":"1"}
[2026-04-13 10:36:42][SCENARIO] Fin correcte du scénario
oui c’est ce que je pensais avoir trouvé en lisant le code, ca je vois pourquoi potentiellement.
mais je voulais d’abord reproduire pour m’assurer que si je change, ca ne se produit plus
et donc je pensais avoir reproduis puis j’y arrivais plus… et en fait maintenant je me rend compte que j’avais initialement testé sur une machine deb11/php7, sur laquelle je reproduis, et ensuite sur une deb12/php8, sur laquelle le problème ne se pose pas (mais je ne comprend pas encore pq car d’après le code ca devrait)
comme quoi… la page santé c’est toujours nécessaire et utile pour chaque demande…
du coup t’es sur quoi? deb11? je peux avoir la page santé?
c’est qd meme super dangereux ton système de scénario qui se rappelle lui même en boucle, je me suis fait avoir qlq fois en testant, mon scénario a juste bouclé pcq j’ai oublié de mettre une condition de sortie
je n’ai pas bien compris le vrai besoin (même si ca change rien au potentiel problème de tag à résoudre) mais ca serait pas un candidat au bloc « Tant que » ?
Oui le « Tant Que » pourrais faire très majoritairement l’affaire. Mais en ce moment j’ai du taff par-dessus la tête et des pépins de santé donc je n’ai pas testé ta nouveauté qui semble très prometteuse
Je procède ainsi pour avoir un unique scénario pour 1 fonction (ici la gestion du Roborock), et je trie par trigger ou tag l’ation à réaliser.
Cela me sert en particulier ici à augmenter la fréquence de refresh des données du Roborock quand je lance une séquence de nettoyage.
Dans d’autres scénarios par exemple vigilance météo cela me sert à refresh les horaires de la vigilance pour envoi Telegram alors que le niveau de vigilance est constant (et est le trigger). Mais dans ce cas c’est en multi-lancement car le même scénario gère 4 vigilances différentes. Voir fichier Template joint car c’est compliqué à expliquer pour moi.
Bonjour,
Je fais exactement le même genre d’auto-appel de scénario.
Pour mon réseau Zigbee, si l’état d’un actionneur n’est toujours pas dans celui voulu suite à modification de consigne et premier changement, je relance le scénario dans une minute pour réessayer.
Un bon candidat pour le nouveau « tant que » de Mips, bien que j’ai un doute sur l’attente active à l’intérieur de ce tant que, attente de quelques secondes pour mon cas.
