Automatisation écrite :
Si la prise NOUS A1Z est désactivée, l’appui court du bouton SONOFF SNZB-01P déclenche l’activation de la prise NOUS A1Z pendant une temporisation de 5mn. A l’issue de cette temporisation, la prise NOUS A1Z est désactivée.
Le problème est que cette automatisation est interrompue de façon aléatoire à la 1ère étape, des fois elle est OK et va jusqu’à la fin et des fois elle est NOK et s’interrompe après la première étape.
Ci-après la Chronologie de l’exécution.
Chronologie de l’exécution :
Déclenché par mqtt topic zigbee2mqtt/Bouton Salle de Bain/action le 21 juillet 2025 à 08:27:11
Tester Prise 220V boucle ECS est désactivé
Arrêté, car une seule exécution est autorisée à la fois le 21 juillet 2025 à 08:27:11 (durée d’exécution : 0.00 secondes) »
<<<
Je ne comprends pas ce qui s’exécute en parallèle ? J’ai modifié l’automatisation en utilisant des triggers (ID), mais ça n’a rien changer.
Mais je ne vois pas comment peut on identifier deux exécutions en même temps sur mon automatisation qui est on ne peut plus simple et basique, et je suis bloqué.
Donc si quelqu’un peut m’expliquer pourquoi cela arrive ou donner les moyens d’investigation afin de comprendre et remédier à ce problème.
Merci par avance.
Cordialement,
Johndalar
Ma configuration
Home Assistant sur barre metal sur mini PC dédié Lenovo ThinkCentre
Clé SONOFF ZBDongle-E Zigbee2MQTT
Bouton SONOFF SNZB-01P
Prise NOUS A1Z
La troisième: peut être que l’usage d’un timer serait plus robuste. Ton automatisation déclencherait un timer, alumerait la prise et s’arrêterait. La même automatisation (ou une autre) éteindrait la prise à la fin du timer. Avantage, on peut relancer le timer en cours de route, et en cas de reboot ou autre, l’action de fin de timer est exécutée au redémarrage (il y a des exemples avec détecteur de mvt dans ma presentation si tu veux.)
Là, c’est clair, tu appuis 1 fois sur le bouton ça lance l’automatisation qui ‹ bloque › pendant 5 minutes. Et avant les 5 minutes, tu appuis une 2ème fois.
La deuxième exécution ne peut pas se lancer, puisque la première est toujours en cours et qu’elle est en mode single (donc 1 seul possible)
Merci pour la précision, donc c’est à la dernière ligne de code que je remplace mode: single par mode: restart
Concernant les timers versus delays, j’ai cherché dans la présentation BBE je n’ai pas trouvé pour essayer de comprendre la différence et comment utiliser les timers. Ces derniers, sont ils des objets gérables de HA ou signifies tu qu’il s’agit du timer disponible sur la prise NOUS A1Z ? Car j’ai essayé le timer/NOUS ça ne fonctionne pas à 100%. Où trouve t on de la littérature sur les timers ? Merci.
En gros les timers (dans HA) sont comme des chrono, tu le lances, tu le mets en pause, tu l’arrêtes, tu le reset ou tu le reprendss comme tu veux. Ils résistent même à une redémarrage de HA.
Et donc tu peux créer une automatisation qui lance la boucle au début du timer. Qui arrête la boucle à la fin du timer. Et tu peux gérer par exemple un reset si tu vois un bouton avant sa fin.
Du coup l’automatisation ne reste pas en pause 5min comme là…
La doc fournie par @WarC0zes est explicite également.
Le principal avantage du timer c’est bien ça:
Tu le lances, le pause, le relance comme tu veux dans tes automations, et il “vit sa propre vie” en dehors des automatisations.
Lorsqu’il se termine il lance un event que tu peux utiliser comme trigger dans une automatisation.
Si HA se reset avant la fin du timer, l’event de fin de timer sera généré:
a l’heure prévue de fin du timer si HA a redémarré avant
au redémarrage de HA si l’heure prévue de fin du timer est dépassée.
Alors qu’avec un delay, les actions de fin de timer n’ont jamais lieu…
Bref le delay c’est tres bien pour des attentes courtes, mais pour des attentes longues il vaut mieux un timer.
Autre avantage (que j’utilise dans l’exemple ci dessus pour les lumières), un timer a un état, tu peux donc le tester pour savoir s’il est actif (dans mon exemple ça m’économise la gestion d’un booléen).
Merci Pulpy-Luke et BBE. Je commence à comprendre la philo du timer versus le delay. Mais sans vos explications et même en analysant spécifications et tutos, pas évident de comprendre, depuis 2/3 jours j’y ai passé quelques heures, créé un timer mais tout passe à travers …
Je vais donc tout reprendre, revoir vos exemples, prendre en compte les event, etc et je vous tiens au courant.
Pour faire ce que tu faisais avant avec une seule automatisation:
trigger: ton trigger
condition : tes conditions (facultatives)
actions:
actions au moment du trigger
delay de xx min
actions a la fin du delay
Pour faire LA MËME CHOSE avec un trigger il te faut:
Avant toute chose définir un trigger dans les entrées (paramètres/ appareils et services/ entrées) il te faudra un timer par automatisation utilisant le delay:
conditions: (facultatives, normalement celles de l’activation doivent suffire)
actions:
actions a la fin du delay: les mêmes qu’avant
C’est plus complexe pour la même chose mais:
tu peux mettre les deux automatisations dans la même automatisation avec un choose et des triggers id si tu maitrises pour n’en avoir qu’une.
ton fonctionnement est robuste aux redémarrages de HA (si tu as coché la case).
tu peux enrichir tes automatisations avec les actions timer.pause, timer.cancel. Tu peux aussi dans certains cas utiliser ton timer avec une durée différente en passant en data la durée que tu souhaites dans l’action timer.start (sinon il utilise la durée par défaut définie à la création)
tu peux tester l’état de ton timer pour savoir s’il est en cour, en pause, inactif.
tu peux utiliser ton timer dans ton dashboard pour afficher la durée restante ou l’état.
Je reviens pour vous remercier infiniment pour vos conseils car tout fonctionne correctement depuis deux semaines en utilisant les timers (et non pas les delays) et avec deux automatisations distinctes.
Pour celles et ceux qui lisent ce post j’explique ci-dessous l’utilité et la destination de ces automatisations :
dans le sous sol de ma maison, l’Eau Chaude Sanitaire (ECS) est produite par un ballon électrique standard à accumulation qui chauffe en heure creuse. L’ECS est propagée par un double circuit et un circulateur situé au sous-sol,
ce circulateur est programmable afin de donner des créneaux horaires de distribution d’ECS,
mais cette programmation est inutile car la circulation d’ECS est “imposée” à priori car on ne sait jamais à l’avance quand on a besoin de tirer de l’eau chaude dans la journée. Par ailleurs, faire tourner de l’eau chaude dans le double circuit refroidit énormément la température dans le ballon et réchauffe la maison inutilement,
par ailleurs, tirer de l’ECS depuis l’étage demande au moins 10 litres d’eau froide avant d’obtenir de l’eau chaude,
d’où un bouton poussoir à l’étage, là où il y a besoin d’eau chaude, qui commande un commutateur 220V alimentant le circulateur; il suffit de penser à appuyer sur le bouton dans la salle de bain. Moins de 5mn de circulation d’ECS suffisent pour obtenir l’eau chaude sans gaspillage d’eau froide.
Je communique ci-dessous les deux automatisations.
L’automatisation pour détecter l’appui bouton poussoir, démarrer le circulateur, démarrer un timer :
alias: Un appui bouton Salle de Bain
description: ""
triggers:
- domain: mqtt
device_id: 6ea08141b3ac6c99edc5250f73696797
type: action
subtype: single
trigger: device
id: Appui_court_SdB
conditions: []
actions:
- type: turn_on
device_id: 938bafa9dd044b2ea5dde60a90dfe399
entity_id: 47d541a947cedc8b446554005f9d5a58
domain: switch
- action: logbook.log
metadata: {}
data:
name: Un appui sur Bouton Salle de Bain
message: Démarrage de la boucle Eau Chaude Sanitaire pendant 5mn
entity_id: switch.0x94a081fffe575b53
- action: timer.start
metadata: {}
data: {}
target:
entity_id: timer.timer_boucle_ecs
area_id: buanderie
mode: single
L’automatisation pour détecter la fin du timer de 5mn et arrêter le circulateur :
alias: Detection fin timer boucle ECS
description: "Detection fin time boulce ECS et arret prise 220V boucle ECS "
triggers:
- event_type: timer.finished
event_data:
entity_id: timer.timer_boucle_ecs
trigger: event
conditions: []
actions:
- type: turn_off
device_id: 938bafa9dd044b2ea5dde60a90dfe399
entity_id: 47d541a947cedc8b446554005f9d5a58
domain: switch
- action: logbook.log
metadata: {}
data:
message: "Detection fin time boulce ECS et arret prise 220V boucle ECS "
name: Fin timer boucle ECS
entity_id: switch.0x94a081fffe575b53
mode: single
Enfin, un petit retour d’expérience me montre que les prises connectées Tretakt Ikea (7,99€ sans CTRL de puissance) sont plus sensibles d’au moins 30% à la forme d’onde Zigbee 2,4GHz (même en intercalant les canaux Zigbee/WIFI2,4GHz) que les prises connectées NOUS AZ1 plus chères.
