It’s kinda frustrating for me that timers don’t survive restarts.
I worked on a fix for this, but life happened and I still haven’t found time to finish the tests to get it integrated. I have a custom_component that at the moment still works:
The issue I see with having timers survive restarts is that HA will have no idea how long it was offline, so the timer value becomes irrelevant. HA could have simply restarted (in my case less than a minute) or there may have been a 2 hour power outage… what value should the timer restart on?
The balance of its duration minus elapsed time when Home Assistant stopped and restarted.
- A 60 minute timer starts.
- 15 minutes into its countdown, Home Assistant stops.
- The timer has 45 minutes remaining.
- Home Assistant restarts 30 minutes later.
- The timer has 45-30=15 minutes left.
- The timer is restored and finishes the balance of its countdown (15 minutes).
I posted an automation and python_script that restores active timers in that fashion.
1 Like
I guess I wasn’t thinking of HA being able to relate the timer value to actual current time of day. 
I just found this topic and thought it worth recording my thoughts here as it’s a Month of WTH post and has some votes on it, and therefore one day may get some traction.
One option for handling timers that expire during an HA outage is to fire a (new) Event “timer.expired” during the restore sequence, which would allow the user to deal with the expiry event however they choose to rather than have the integration decide how to handle that for them. Timers that haven’t expired would be restored with their original finishes_at time, and fire the timer.restarted event as expected.
The only downside I see (there will be others, I have no doubt) is that it requires any automation to fire on an Event rather than a specific State, which seems to be less common to do based on forum posts. However, if the user is already dealing with different actions or sequences based on timer.finished vs timer.cancelled or timer.restarted, this is trivial. It is not correct to have the timer object go into an expired state for a small period and then revert to idle so there’s no other way to deal with it (there’s no cancelled state for the same reason). There is no logbook entry when a timer is restarted (just a “Time Name changed to Active by User”) or cancelled (“changed to Idle”) so it’s definitely a thing for more advanced users and use-cases, but I think that’s OK. Largely speaking, it will be transparent to the average user and if they are interested in handling expired timers after HA restarts in the same way as the timer naturally ending, a simple edit to the existing automation event trigger is all that is required;
alias: Event test
description: ''
trigger:
- platform: event
event_type:
- timer.finished
- timer.expired
event_data:
entity_id: timer.wait_15_minutes
condition: []
action:
- service: switch.turn_off
target:
entity_id: switch.garage_power_switch
mode: single
If the user is triggering their automation based on the timer state then they will have to change to Event driven instead (which is arguably more correct anyway).
For anyone using the timer state as part of a condition (which is what I do) then the timer is still either idle or active (or paused) so no change to any logic, and now an HA restart doesn’t impact things.
Yup they finally added this however it seems buggy when saving.
I have about 20 timers that I use. I was going though toggling them to restore and I need to go into each timer.* entity several times, check the “Restore” then click update… like 5+ times on each one till it FINALLY stays checked and saved. Sometimes it just won’t save at all.
1 Like