Arrêté, car une seule exécution est autorisée à la fois

[Johndalar]

Bonjour,

Mon problème

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.

J’ai lu dans des forums français et anglais sur des PB similaires, par exemple : Un simple test dans automation script qui ne marche comme prevu - #22 par afawaz

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

---

System Information

version	core-2025.6.0
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.13.3
os_name	Linux
os_version	6.12.23-haos
arch	x86_64
timezone	Europe/Paris
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	2186
Downloaded Repositories	1

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 15.2
update_channel	stable
supervisor_version	supervisor-2025.05.5
agent_version	1.7.2
docker_version	28.0.4
disk_total	234.0 GB
disk_used	27.7 GB
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	false
ntp_synchronized	true
virtualization
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	Terminal & SSH (9.17.0), Mosquitto broker (6.5.1), Zigbee2MQTT (2.4.0-1), ZeroTier One (0.20.0)

Dashboards

dashboards	2
resources	1
views	1
mode	storage

Network Configuration

adapters	lo (disabled), enp0s31f6 (enabled, default, auto), docker0 (disabled), hassio (disabled), ztks5suueh (disabled), veth685f689 (disabled), veth1c0c998 (disabled), veth34e296e (disabled), vethd4c31de (disabled), veth185671b (disabled), vetha16902f (disabled), veth20a736c (disabled), veth06aefc2 (disabled)
ipv4_addresses	lo (127.0.0.1/8), enp0s31f6 (192.168.111.23/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), ztks5suueh (192.168.192.231/24), veth685f689 (), veth1c0c998 (), veth34e296e (), vethd4c31de (), veth185671b (), vetha16902f (), veth20a736c (), veth06aefc2 ()
ipv6_addresses	lo
announce_addresses	192.168.111.23, xxxx

Recorder

oldest_recorder_run	24 juin 2025 à 07:35
current_recorder_run	24 juin 2025 à 09:35
estimated_db_size	189.95 MiB
database_engine	sqlite
database_version	3.48.0

___

[BBE]

Primo: sans le yaml de ton automatisation, difficile de t’aider et de voir ce qui cloche dans le code

Trois pistes pour moi pour améliorer les choses:

• La première revoir le code car il y a peut être un bug qui stoppe l’automatisation quelque part (poste le yaml pour voir…).
• La deuxième sur l’automatisation elle même, tu as plusieurs mode pour un script ou une automatisation dans ton cas le mode « restart » serait peut être adapté
• 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.)

[Johndalar]

Bonjour,

Merci pour ton retour. Ci-dessous le code yaml.

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:
  - condition: device
    type: is_off
    device_id: 3cf46b414eb4f7b05fef9662081e822d
    entity_id: 103a9d40c4f71acc2c724b194ba839e8
    domain: switch
actions:
  - type: turn_on
    device_id: 3cf46b414eb4f7b05fef9662081e822d
    entity_id: 103a9d40c4f71acc2c724b194ba839e8
    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.prise_220v_boucle_ecs
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - type: turn_off
    device_id: 3cf46b414eb4f7b05fef9662081e822d
    entity_id: 103a9d40c4f71acc2c724b194ba839e8
    domain: switch
  - action: logbook.log
    metadata: {}
    data:
      message: Arrêt de la boucle Eau Chaude Sanitaire
      name: 5mn écoulé depuis l'appui sur Bouton de Salle de Bain
      entity_id: update.prise_220v_boucle_ecs
mode: single

[Johndalar]

Pour la 2ème piste, si j’ai bien compris dans yaml, je remplace dans le subtype: triggers aujourd’hui “single” par “restart” c’est bien ça ?

[Pulpy-Luke]

Salut

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)

Les modes d'automatisations

Bonjour, j’ai une des mes automatisations qui n’a fonctionnée qu’un fois , apres avoir cherché un moment j’ai vu qu’il y avait un mode restart or jusqu’à present toutes mes automatisations en mode single ont fonctionnée correctement d’où ma question : comment savoir si une automatisation a besoin d’un restart et pourquoi ? merci

Bref le restart serait une solution

mais il y a mieux

[Johndalar]

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.

[Pulpy-Luke]

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à…

[WarC0zes]

@Johndalar

Où trouve t on de la littérature sur les timers ?

Bonjour,
dans la doc :

Timer

Tu peux le créer dans paramètres / appareils et services , onglet entrée.

[BBE]

@Johndalar

j’ai cherché dans la présentation BBE je n’ai pas trouvé

Dans ce message il y a des exemples d’utilisation de timer dans la gestion d’une lumière avec détecteur de mouvement… Présentation + [Mon Dashboard] BBE - #3 par BBE

La doc fournie par @WarC0zes est explicite également.

@Pulpy-Luke

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à…

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).