Thanks for the feedback, and you’re pointing out a real limitation of the current implementation 
Technically, the « Wait » block is just a timer in memory in the Gladys process. Nothing is stored in the database: neither the fact that a scene is running, nor where it is in its list of actions. So, at the slightest restart (update, reboot, power outage), everything after the Wait is lost. It’s not a bug on your side, it’s just how it is today.
And yes, the « Gladys starts » trigger does exist, you’ll find it in the list of triggers.
But I would rather advise you to organize yourself so that you don’t need it.
The smartest thing in your case is to have the timer handled not by Gladys at all, but by the outlet itself. Most hardware can do « turn on and turn off by itself after X seconds ». It depends on what you have:
- Shelly, with the HTTP Request action:
http://<ip>/relay/0?turn=on&timer=10800 (Gen1) or http://<ip>/rpc/Switch.Set?id=0&on=true&toggle_after=10800 (Gen2+)
- Zigbee2MQTT, with the Zigbee2MQTT action: on
zigbee2mqtt/<your_pump>/set, you send {"state":"ON","on_time":10800,"off_wait_time":0}. It works on many Tuya/Moes/Aqara outlets and modules.
- Tasmota:
PulseTime 10900; Power ON (beyond 111, PulseTime equals value − 100 in seconds)
Your scene becomes a single action, no more Wait. And the huge advantage for a pool pump: even if your Gladys is cut off or the mini-PC doesn’t restart, the pump still stops.
If your hardware can’t do that, the second approach is a countdown rather than a wait.
You create a number feature via MQTT, like pool_pump_minutes_remaining. Your startup scene turns on the pump and sets the value to 180. Next to it, you make a monitoring scene with a scheduled trigger in interval mode every 5 minutes, which retrieves the value, continues only if it is > 0, rewrites it with the formula {{0.last_value}} - 5, and if it drops to 0 it turns off the pump. The formula mode works just as well on « Set a value » as in conditions, so everything is done with the mouse.
The interest is that it repairs itself: no need for a boot script or the startup trigger, the next cron run catches up on the situation. At worst, you lose the 5 minutes of the current tick.
And if you can settle for that, the simplest solution is two scheduled scenes, start at 10:00 a.m. and stop at 1:00 p.m. For a pool pump, this is often sufficient and it’s foolproof. If you adjust the duration to the water temperature, you can even have 3 stop scenes (12:00 p.m., 1:00 p.m., 2:00 p.m.) each with a condition on the temperature, it’s a bit brute force but it always works.
The principle to remember: the Wait is for short delays within a sequence, like 2 seconds between two commands or 30 seconds before checking a state. As soon as you exceed a few minutes, and especially when a shutdown action is involved, you need to either offload the timer to the hardware or use a stored state that is read regularly.
That said, your original request remains legitimate: persisting long Waits to reschedule them on startup is doable. If you want to open a feature request about it, don’t hesitate.
