i have set up an extremely over complicated alarm system as i am terrible at getting up
i have a repeat to send Alexa notifications and then a delay to wait before resending them, of course this means if i restart home assistant it gets cancelled in its tracks - so i have managed to set up a timer system for it to start a timer wait for it to complete and then continue the repeat
i thought since timers survive restarts if i reset home assistant midway through the delay timer it would have no issue pausing the timer and then when its all restarted continuing the timer and continuing the alarm (or at least being re-triggered by a state change from active to idle) but everything i do just does not survive a reboot
its only a 10 second delay and i had thought having a restore timer would pause it and then resume it on reboot but after watching a test 5 minute timer it just keeps ticking so i think that could be an issue?
any help would be appreciated - i will post the yaml if anyone needs it but lie i said its extremely over complicated so it may just be a big mess
(i do have a very simple workaround of just retriggering when home assistant boots but i would like to know if i can do it this way or at least understand why it isnt working)
As posted above, with a literal backslash character and letter tee, it corrupts the event’s name.
My understanding is that you probably had a literal tab character and, during the copy-paste operation, it was represented as \t. It exists within the double-quotes so it’s interpreted as part of the entire string (thereby defining a non-existent event name).
Ensure the timer’s restore option is enabled and you understand how it causes an active timer to behave after being interrupted (notably its finished_at property).
If an interrupted active timer fails to automatically resume its remaining countdown after a restart, then you may need to report it as an Issue in Home Assistant’s Github Core repository. In fact, there appears to be an existing open Issue about a failure to resume.
i removed the backslash and cleaned it up to be identical to the .finished trigger (which does work fine) and it still does nothing, and the timer is selected to restore, i dont know much about timers and at a glance through the wiki and such i cant find anything helping me out so that’s why I’m asking here,
i may be missing something with how the timer works or how the automation is set up all i know is that a 5 minute timer does continue after restart but the 10 second one wont so it wont retrigger the alarm when home assistant starts up and I’m unsure why or any ways to work around this to get the automation to restart using a timer after i reboot home assistant
I have alot of complicated scenarios that are in any one of various states when home assistant is restarted. For each different thing that might be going on when HA is restarted, I have automations that run on start. For example, for a light that goes off when a timer is finished, I have this sort of thing in an automation that runs at sartup: If automation “x” has enabled drop-down = “Enabled” and the light is on but timer is inactive then restart the timer with the duration specified by the slider… If the timer is active but the light is off and automation enabled then just cancel the timer, or if the timer is active but the automation is marked as disabled just cancel the timer, etc., etc…
This way I can be sure that when HA is restarted, everything is back up and running in the proper state.
Hope that helps
BTW the trigger for when HA is shut down - I have never been able to use, seems like it is a weird unuseable one-off (as you might be trying to trigger an automation with devices that are unavailable - because HA is shutting down!).
Probably because your system takes more than 10 seconds to restart. The timer is considered to have finished during the startup phase. Review the docs about finished_at.
From the documentation:
If an active timer was supposed to end while Home Assistant is stopped, the timer.finished event will fire on startup for that timer. The finished_at property in the event data will provide you with the time that the timer was actually supposed to fire which you can use in automation conditions to decide whether or not to act on it.
If the 10 second timer was supposed to finish while Home Assistant was in the process of restarting, on startup the timer.finished event will fire. If it doesn’t then it’s a bug (all of this assumes the timer’s restore option is enabled).
i had a feeling it had to do with the short time and how long ha took to restart as far as i am aware timer.finished does not trigger after a restart (but does when run normally) i’ll give this a quick recheck and verify
Then it’s not behaving according to its documentation and is a bug; report it as a new Issue or, if there’s an existing open Issue that describes the exact same faulty behavior, add a comment to it describing your observed failure scenario.
The bug might be something simple like the timer.finished event fires before Home Assistant finishes loading all automations. In other words, the Timer integration is loaded before the Automation integration. So by the time your automation is loaded, it’s too late to detect the timer’s event.
I tried to reproduce this, and the timer.finished only seems to be ignored if the timer is finished while HA is not running/in the process of restarting. Which is according to the documentation I think
Automations using the timer.finished event will not trigger on startup if the timer expires when Home Assistant is not running.
If HA is not running and a timer runs out, there should be some indication in the state or state attributes that makes it possible to trigger on that situation.
Without this, those interested in being notified that this happens will basically have to add another helper (e.g. a boolean) whenever a timer is started, clear the boolean when timer is finished, and then trigger on that boolean either after reboot or when it is true while the timer is idle. Yuk/ugg…
This is important, especially due to the frequency that reboots are required in the HA ecosystem, often due to updates of HA itself, updates of integrations or other components, and also, notably, during development (of automations, etc…) by the end user.
To make my setup more robust I added a huge number of automations (all very simple) that run in parallel when HA starts. That inadvertently resolves this problem automatically. My paradigm is to have all automations as simple as possible and only do one thing and whatever an automation changes may or may not trrigger another automation. This asynchronous way of altering device behavior is much more elegant and I find this universally MUCH easier for debugging. A little tedious setting up but that is only a one-time issue. Also all of them are named with the same naming convention (starting with the room, then the device, then a quick blurb such as “Living Room If Motion detected if → do this” - but that is getting off the subject.
So let me explain my solution. For instance, motion starts a dedicated timer. A separate automation will turn on a light when that timer is started. Another separate automation will turn the light off when the timer is finished or cancelled. You get the idea. This makes things much simpler and more elegant for example, if you just retart (or stop) that timer you know what will happen.
Long story short, with this setup I have, I also have separate automations that run on HA starting up, extending the above example, with HA restarting as the trigger - if the light is on and the timer is not running, then restart the timer, another one is if the timer is running and the light is not on the turn on the light, etc…
Each example is specific to the situation with what should be proper behavior etc. Then I also have a script attached to a dasboard button that will just run all those startup automations, so I can do some quick housekeeping (I never really need to use it though, since everything is “corrected” on HA startup anyway)…