Incohérence dans scénario. Besoin d'aide

doudou56 · Août 17, 2026, 6:54

Bonjour à tous.

Au retour de vacances, j’ai un scénario qui bug, et ça commence a râler dans la chaumière :-).
Tout d‘abord, je suis en 4.6.1 sur RPI5 avec clef zwave et rfxcom.
Je m’explique j’ai un scénario qui me permet de dire si présent ou absent via une télécommande rfxcom (ou un virtuel). Si présent ça désactive l’alarme et on gère l’ouverture des volets de la maison. Si absent, ça active l’alarme et ca ouvre les volets avec le lever du soleil.
Cela a très bien fonctionné lorsque nous étions absent, mais mon problème et que maintenant étant présent, les volets continuent à s’ouvrir tout seul, et je ne comprends pas pourquoi. Je vous met une copie des logs et capture des scénarios.

Je pense que mon soucis vient de là; mais je ne sais pas pourquoi et comment le résoudre….

log ouverture volet.txt (63,2 Ko)

log activation désactivation alarme.txt (12,5 Ko)

DanielJ · Août 17, 2026, 1:01

Bonjour,
L’analyse de vos logs donne la réponse pourtant…
Regardez ce qu’il se passe le 16/08 à 21h11 lors de l’activation de l’alarme sur le scénario déclenchant l’ouverture des volets :

[2026-08-16 21:11:39][SCENARIO] -- Début : . Tags : {"#trigger#":"virtualCmd","#trigger_name#":"[maison][activation de lalarme][Etat]","#trigger_id#":673,"#trigger_message#":"Scénario exécuté automatiquement sur événement venant de : [maison][activation de lalarme][Etat] (1)","#trigger_value#":1}
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [condition] : if #[maison][activation de lalarme][Etat]# == 1  
[2026-08-16 21:11:39][SCENARIO] Evaluation de la condition : [1 == 1] = Vrai
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [action] : then
[2026-08-16 21:11:39][SCENARIO] Exécution d'un bloc élément : 218
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [condition] : at time_op(#[terrain][heliotrope][Lever du Soleil]#,+10)

Le scénario est donc lancé par la commande [maison][activation de lalarme][Etat] qui passe à 1 (activation de l’alarme).
Ensuite, puisque l’alarme est activée, il va programmer le lancement des actions prévues au lever du soleil + 10’, +15’ et +20’ (l’ouverture des volets).
Jusque là, rien d’anormal…

Ensuite :

[2026-08-17 03:00:02][SCENARIO] -- Début : . Tags : {"#trigger#":"heliotropeCmd","#trigger_name#":"[terrain][heliotrope][Lever du Soleil]","#trigger_id#":277,"#trigger_message#":"Scénario exécuté automatiquement sur événement venant de : [terrain][heliotrope][Lever du Soleil] (708)","#trigger_value#":708}
[2026-08-17 03:00:02][SCENARIO] - Exécution du sous-élément de type [condition] : if #[maison][activation de lalarme][Etat]# == 1  
[2026-08-17 03:00:02][SCENARIO] Evaluation de la condition : [0 == 1] = Faux
[2026-08-17 03:00:02][SCENARIO] - Exécution du sous-élément de type [action] : else
[2026-08-17 03:00:02][SCENARIO] Fin correcte du scénario

A 03h00, ce scénario est relancé mais cette fois avec le déclencheur ‹ [terrain][heliotrope][Lever du Soleil] › qui, je suppose, correspond à l’heure de mise à jour du lever de soleil pour le 17/08 par le plugin ‹ Heliotrope ›.
Mais l’alarme a visiblement été désactivée entre-temps :

[2026-08-17 03:00:02][SCENARIO] - Exécution du sous-élément de type [condition] : if #[maison][activation de lalarme][Etat]# == 1  
[2026-08-17 03:00:02][SCENARIO] Evaluation de la condition : [0 == 1] = Faux

et #[maison][activation de lalarme][Etat]# == 0.

[EDIT]
En effet, l’alarme a bien été désactivée à 21h11, mais automatiquement ?

[2026-08-16 21:11:39][SCENARIO] -- Début : . Tags : {"#trigger#":"virtualCmd","#trigger_name#":"[maison][activation de lalarme][Etat]","#trigger_id#":673,"#trigger_message#":"Scénario exécuté automatiquement sur événement venant de : [maison][activation de lalarme][Etat] (1)","#trigger_value#":1}
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [condition] : if #[maison][telecommande dio][bt1]# == 1  
[2026-08-16 21:11:39][SCENARIO] Evaluation de la condition : [0 == 1] = Faux
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [action] : else
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [condition] : if #[maison][telecommande dio][bt1]# == 0  
[2026-08-16 21:11:39][SCENARIO] Evaluation de la condition : [0 == 0] = Vrai
[2026-08-16 21:11:39][SCENARIO] - Exécution du sous-élément de type [action] : then
[2026-08-16 21:11:39][SCENARIO] Exécution de la commande [salle à manger][prise detecteur de mvt][Off]
[2026-08-16 21:11:39][SCENARIO] Désactivation du scénario : Scenario alarme
[2026-08-16 21:11:39][SCENARIO] Exécution de la commande [maison][activation de lalarme][desactiver]

Reprenons : #[maison][activation de lalarme][Etat]# change d’état et passe à 1. Il provoque l’exécution du scénario de l’ouverture des volets pour le lendemain comme on vient de le voir. Mais aussi, et en parallèle, l’exécution du scénario ‹ activation désactivation alarme ›. Or comme la condition :

#[maison][telecommande dio][bt1]# == 0
est vrai, du coup ce scénario va désactiver l’alarme. CQFD…
A mon avis, il y a quelque chose à faire à ce niveau là… Certes, ça marche, mais ça me paraît un peu bancal…
[/EDIT]

Donc, ce scénario ne fait plus rien derrière, et c’est sans doute le comportement attendu lorsque l’alarme est sensée ne pas/plus être activée.

Sauf que…

Les blocs sont toujours programmés à Lever de soleil + 10, 15 et 20’ : ils ne sont pas inactivés pour autant, quand bien même l’alarme est désormais désactivée !
Résultat : les volets s’ouvrent, puisque programmés par l’exécution du scénario à 21h11, aux horaires prévus le lendemain matin.

Pour éviter cela, je vous conseille de placer une instruction ‹ remove_inat › qui va désactiver l’ensemble de l’exécution à postériori des blocs programmés ultérieurement.
Je n’ai pas la vision globale sur votre scénario (il manque une partie ? quels sont les déclencheurs ?), mais voici une correction possible, ou en tous cas une proposition :

Dans le scénario ouverture des volets :
Déclencheurs :

#[maison][activation de lalarme][Etat]# (Note important : ne pas mettre d’égalité, ce déclencheur doit provoquer l’exécution du scénario lorsque la valeur passe indifféremment à 1 ou 0).
et les autres s’il y en a, comme #[terrain][heliotrope][Lever du Soleil]#

Dans le scénario :
Le bloc

SI #[maison][activation de lalarme][Etat]# == 1 ALORS [...]

ne change pas.

Par contre, développez le bloc SINON (la flèche vers le bas)

pour ajouter :

SINON remove_inat [scénario courant]

Ce qui donne quelque chose comme ça :

(remplacer par votre scénario bien sûr)

Au résultat, lorsque l’alarme sera désactivée (#[maison][activation de lalarme][Etat]# == 0), l’instruction ‹ remove_inat › viendra désactiver toutes les futures occurrences programmées de ce scénario.
Et les volets resteront fermés… Bonne nuit !

doudou56 · Août 17, 2026, 7:32

Bonjour Daniel, merci d’avoir pris le temps d’analyser mon problème. à 21h11 le 16/08, ca correspond au moment où j’ai désactivé l’alarme.
Quand j’appuie sur le bouton de la télécommande, ça désactive l’alarme, ça active le mode présent; et ça m’envoie bien un sms pour me valider tout cela.

on voit bien que j’ai bien appuyé sur le bon bouton car on à bien 0=0 à 21h11m39s.

Par contre effectivement dans le log ouverture, on voit bien que 1=1 a cette même heure. Je vais regardé cela et faire des test.

Je vais aussi bien analyser ta réponse et insérer un remove inat. dans le doute pour ce soir je le désactive et je me penche dessus demain

Merci, belle soirée.

rom.jou · Août 17, 2026, 7:49

Pense a vérifier aussi la configuration de ta commande état et qu’est-ce qui pourrait influer dessus, autrement que la télécommande.

doudou56 · Août 18, 2026, 7:30

en analysant le log et en prenant mon temps je pense avoir trouvé ma coquille.

Activation alarme est un virtuel que j’ai créer pour pouvoir activer l’alarme a partir du dashboard.

Quand j’ai construit mon scénario, je voulais 2 solutions pour activer l’alarme. Soit la télécommande, soit via le dashboard sur la tablette.

En fait, j’ai mis dans mon scénario, quand j’active avec l’un ou l’autre, ca passe mon virtuel en activé, et après ça déroule le scénario. jusque là c’est ok.

Par contre quand je rentre, et que je désactive avec la télécommande, que j’appuie sur le bt0 (ce que j’ai fait le 15.08 à 19:56:15, j’ai eu les deux conditions à 1 car mon virtuel etait toujours=1 logique puisque la désactivation n’arrive qu’après dans mon scénario….

donc comme les deux conditions = vrai, il a activé dans mon scénario ouverture volet la tache programmé pour l’ouverture des volets le lendemain.

et le lendemain, ne comprenant pas, j’ai fait des test, et j’ai réactivé ce processus…..
Je vais regarder ce que tu m’as dit Daniel pour voir si cela changerai mon problème.

doudou56 · Août 18, 2026, 7:34

en fait tu avais déjà trouvé et déjà dit la même chose Daniel, mais j’avais pas pris le temps de bien lire. désolé.

je vais donc vraiment prendre le temps de te lire…..

doudou56 · Août 18, 2026, 7:58

Est ce que d’après toi cela est ok? Si je place le remove_inat a la fin de ma désactivation de l’alarme sur mon scénario d’ouverture de volet

car quand je fait test, je ne vois rien en rapport avec remove_inat dans les logs.

DanielJ · Août 18, 2026, 7:59

Bonjour,
Oui, c’est en effet mon analyse : l’utilisation d’un virtuel et d’un bouton physique pour commander la même chose peut poser des problème de synchronisation si on ne met pas en place un garde-fou.
C’est un exemple très représentatif où le paramètre timing est très important et doit être intégré dans la logique de fonctionnement…

DanielJ · Août 18, 2026, 8:12

Ca devrait… Le scénario a bien été sauvegardé avant d’être testé ?

doudou56 · Août 18, 2026, 8:20

oui bien sauvegardé

DanielJ · Août 18, 2026, 8:26

Ok… Je continue de regarder de mon côté…
Quels sont les déclencheurs des deux scénarios [ouverture volet] et [activation désactivation alarme] ?

doudou56 · Août 18, 2026, 8:34

DanielJ · Août 18, 2026, 9:24

Pour les déclencheurs, ok, c’est conforme à ce que je supposais. Pas de surprise donc et ça me paraît correct…

Dans le log du scénario Activation alarme, j’ai fait quelques tests de mon côté et le fait que le log ne montre rien ne prouve pas qu’il n’a pas supprimé l’exécution prévu des blocs.
Aussi, pour moi c’est correct et ça devrait fonctionner tel quel.

Pour en être sûr, il suffit de regarder dans le moteur de tâche (Réglages-Système-Moteur de tâches) :

Les occurrences programmées (qu’il faudra retrouver…) ne devraient plus apparaître.

Ou alors changer l’heure pour la fixer à 11h45 par exemple, au lieu du lever de soleil + 10,15 et 20’, et voir ce que ça donnerait…

doudou56 · Août 18, 2026, 4:55

Je ne sais pas trop comment interpréter ce que je vois.

J’ai normalement la fermeture de mes volet qui elle se fait automatiquement avec le couché du soleil au alentour des 22h, que je ne retrouve pas dans la liste des choses programmées ci dessous

DanielJ · Août 18, 2026, 5:01

Programmé par un scénario ?
Ce ne serait pas les deux dernières lignes, programmées pour le 18/08 à 21h41 et 21h43 ? ?

Ceci dit, le plus simple pour retrouver les bonnes lignes serait d’activer l’alarme, détecter les process programmés pour le lendemain à l’heure de lever du soleil (donné par le plugin héliotrope) + 10/15/20’, et de désactiver l’alarme pour vérifier que ces lignes aient bien disparues…

doudou56 · Août 18, 2026, 7:24

ah oui très bonne idée.
Je viens d’activer l’alarme.
Ouverture volets prévus le 19.08 à 7h20.

Par contre je n’ai rien demain a cette heure là dans les taches.

Henri · Août 19, 2026, 7:11

Bonjour
Connaissez-vous les fonctions « trigger » dans les scénarios ?
Si ce n’est pas le cas, je vous invite à y jeter un œil car elles sont ultra puissantes et vont vous simplifier la vie sur ce type de scénario.
La logique est assez différente. Plutôt que de réfléchir en terme d’État, on se concentre sur « qui lance le scénario et avec quelle valeur »
Ce qui est un peu votre but ici
Le scénario est lancé par une télécommande / un virtuel ? Avec la valeur on ou off ?
Alors je fais ceci ou cela.
(Les déclencheurs du scénario seront alors l’état du virtuel et de la télécommande sans test de valeur / pas de ==1 dans les déclencheurs)

Bref, perso j’aurais utilisé les trigger
Bonne journée / découverte

DanielJ · Août 19, 2026, 8:08

Bonjour,

@Henri
Vous avez tout à fait raison. Et c’est le sens de ma remarque !

D’ailleurs, les logs montrent bien que le scénario ‹ activation alarme › s’auto-déclenche lui-même lorsqu’il modifie l’état du virtuel #[maison][activation de lalarme][Etat]#. Et c’est pas terrible, parce que du coup pour désactiver l’alarme par exemple, il va commencer par l’activer (?).

La seconde étape sera donc soit d’utiliser la fonction trigger en effet, soit (plus simple peut-être ?) de dissocier ce scénario en deux scénarios bien distincts :

le premier réagit uniquement à la télécommande (déclencheur = #[maison][telecommande dio][bt1]#), et va changer l’état de #[maison][activation de lalarme][Etat]# (et on peut utiliser la fonction ‹ event › pour ce faire),
le second va, en fonction de #[maison][activation de lalarme][Etat]# (qui est donc en déclencheur) et qui peut être modifié soit par le premier scénario, soit par une des commandes du virtuel (action/désactivation), provoquer les actions requises en fonction de sa valeur 1 ou 0 (c’est quasiment le même scénario mais sans le OU #[maison][telecommande dio][bt1]# dans la condition, et surtout sans toucher à l’état (ce n’est plus lui qui le détermine avec #[maison][activation de lalarme][activer]# ou #[maison][activation de lalarme][desactiver]#).

Mais tout d’abord, mieux vaut se concentrer sur le ‹ remove_inat › pour être sûr qu’au moins cette partie fonctionne…