Merci pour le retour, et tu mets le doigt sur une vraie limite de l’implémentation actuelle 
Techniquement, le bloc « Attendre » c’est juste un timer en mémoire dans le process Gladys. Rien n’est stocké en base : ni le fait qu’une scène soit en cours, ni où elle en est dans sa liste d’actions. Du coup au moindre redémarrage (mise à jour, reboot, coupure de courant), tout ce qui vient après le Attendre part à la poubelle. C’est pas un bug de ton côté, c’est comme ça aujourd’hui.
Et oui, le déclencheur « Gladys démarre » existe bien, tu le trouveras dans la liste des déclencheurs.
Mais je te conseillerais plutôt de t’organiser pour ne pas en avoir besoin.
Le truc le plus malin dans ton cas, c’est de ne pas faire tenir le chrono par Gladys du tout, mais par la prise elle-même. La plupart du matériel sait faire « allume-toi et coupe-toi tout seul dans X secondes ». Ça dépend de ce que tu as :
- Shelly, avec l’action Requête HTTP :
http://<ip>/relay/0?turn=on&timer=10800 (Gen1) ou http://<ip>/rpc/Switch.Set?id=0&on=true&toggle_after=10800 (Gen2+)
- Zigbee2MQTT, avec l’action Zigbee2MQTT : sur
zigbee2mqtt/<ta_pompe>/set, tu envoies {"state":"ON","on_time":10800,"off_wait_time":0}. Ça marche sur pas mal de prises et modules Tuya/Moes/Aqara.
- Tasmota :
PulseTime 10900; Power ON (au-delà de 111, PulseTime vaut valeur − 100 en secondes)
Ta scène devient une seule action, plus aucun Attendre. Et l’avantage énorme pour une pompe de piscine : même si ton Gladys est coupé ou que le mini-PC ne redémarre pas, la pompe s’arrête quand même.
Si ton matériel ne sait pas faire ça, la deuxième approche c’est un décompte plutôt qu’une attente.
Tu crées une feature nombre via MQTT, genre minutes_restantes_pompe. Ta scène de démarrage allume la pompe et met la valeur à 180. À côté, tu fais une scène de surveillance avec un déclencheur planifié en mode intervalle toutes les 5 minutes, qui récupère la valeur, continue seulement si elle est > 0, la réécrit avec la formule {{0.last_value}} - 5, et si elle tombe à 0 elle coupe la pompe. Le mode formule marche aussi bien sur « Définir une valeur » que dans les conditions, donc tout se fait à la souris.
L’intérêt c’est que ça se répare tout seul : pas besoin de script au boot ni du déclencheur au démarrage, le prochain passage du cron rattrape la situation. Au pire tu perds les 5 minutes du tick en cours.
Et si tu peux t’en contenter, le plus simple reste deux scènes planifiées, départ à 10h et arrêt à 13h. Pour une pompe de piscine c’est souvent suffisant et c’est increvable. Si tu adaptes la durée à la température de l’eau, tu peux même faire 3 scènes d’arrêt (12h, 13h, 14h) avec chacune une condition sur la température, c’est un peu bourrin mais ça marche toujours.
Le principe à retenir : le Attendre est fait pour des délais courts à l’intérieur d’une séquence, genre 2 secondes entre deux commandes ou 30 secondes avant de vérifier un état. Dès que tu dépasses quelques minutes, et surtout quand c’est une action de coupure qui est en jeu, il faut soit déporter le minuteur sur le matériel, soit passer par un état stocké et relu régulièrement.
Ceci dit, ta demande de base reste légitime : persister les Attendre longs pour les replanifier au démarrage, c’est faisable. Si tu veux ouvrir une demande de fonctionnalité dessus, n’hésite pas.
