It’s incomplete, contains syntax errors, some pseudo-code, and is needlessly split into two automations. Anyway, CentralCommand has already stepped up with a good example.
Good point. I haven’t found the need for it (yet) in my own automations because the duration of Reload Automations is so brief (relative to a restart). Nevertheless, you’re right; for full protection it should trigger on that event as well.
I think a timer might also be susceptible to a Reload Timers that occurs precisely at a timer event (like finished). It’s a narrow window of opportunity for failure but, just like for automation_reloaded, there’s no obvious way to mitigate it for timers.
Dear Reader,
Just to clarify, I am not opposed to employing a timer. The fact is that I used timers extensively in Premise (home automation software I used for over a decade prior to Home Assistant). However, historically, Home Assistant’s timer could not survive a restart (unless you implemented a workaround like this one).
The ability to restore a previously active/paused timer on restart was introduced as a native feature very recently (April 2022) Before that, a restart would cancel an active/paused timer thereby making it unsuitable for time-critical applications. Necessity is the mother of invention and so the job was handled by an input_datetime (and a little bit of date arithmetic).
Now that a timer can be configured to survive a restart, it becomes a viable means of handling time-critical applications. The caveat is that it still has one or two chinks in its armor (reload events) that have the potential to negatively impact it. In fairness, for most applications the odds are small but one should be aware they exist when designing a failure-resistant automation.
FWIW, most of my time-critical applications use the input_datetime technique but a few use a timer (wherever I need to see a countdown in the UI) with the workaround mentioned above (I have yet to convert to using the new native method of restoring timers). It’s good to have choices.