I wanted to know, if an automation was triggered in the last 30 minutes. As you may know, the last_triggered timestamp doesn’t survive a restart of ha, i.e. the attribute stays unset (“None”) after every restart until the automation was triggered the first time. Thus, I tried to use a history_stats sensor for this purpose:
- platform: history_stats
name: my automation triggered in the last 30 mins
entity_id: automation.my_automation
state: 'on'
type: count
duration: 00:30
end: '{{ now() }}'
But this sensor doesn’t behave as expected. The value of this sensor doesn’t change after the automation was triggered. It’s always at least 1 and it increases by 1 on every HA restart in the last 30 minutes. In fact, as configured above this sensor virtually acts as a “number of HA restarts in the last 30 minutes” sensor, but it’s not counting anything related to the “automation.my_automation” automation.
But I’m still curious, why the history_stats sensor doesn’t work as expected, as I’d like to count other state changes as well with this method, not only automations triggered.
BTW: Actually I’m using initial_state: true intentionally in all my automations, to prevent HA from “randomly” and unnoticed disabling my automations on frequent restarts. Which is a feature, that always caused more trouble than benefit for me. I never, i.e. not a single time, had a problem with an automation running wild on startup. But I’ve already torn my hair out several times because of things not working as expected, until I noticed, that HA turned off some automation a while ago, for which I forgot to set initial_state: true…
Read my linked post. When the restore feature disables automations on startup, it’s a symptom of an underlying problem.
If the startup process encounters a problem (configuration error, unresponsive component or device, corrupted database, etc etc) causing an interruption, then the restore feature may be unable to perform its function. In that specific situation, all automations default to off.
Instead of hunting down the cause of the startup failure, and eliminating it, users are being told (by other users) to add initial_state: true to all their automations. So instead of understanding what causes the pain, the remedy being offered is an opioid to mask it.
FWIW, I have two instances of Home Assistant. One of them is a test system that I use to test various things in the course of assisting community members. It gets restarted several times a day. None of my automations use initial_state: true. Restarts have been clean and I’ve never experienced the problem of all automations defaulting to off.
If I did experience the problem, I would:
Examine the log to understand what just happened.
Examine what I did prior to the restart that may have caused the startup problem.
Attempt to isolate the issue and mitigate it.
If I could not isolate it then I would create a special-purpose automation:
Create an automation that uses initial_state: true.
Trigger: Home Assistant’s startup event.
Action: Turn on all automations.
This one automation would ensure all other automations are on. It’s still a kludge and the optimal solution is to identify and correct the source of the startup problem.
Sorry, no offense, but you completely misunderstood, what I wrote.
In my case there is no “underlying problem”. While working on my HA configs, I intentionally restart HA frequently to put recent changes into effect. And sometimes this happens in less than three minutes from the last restart, which causes this security feature to trigger. Unfortunately even without mentioning this in the log file (yes, I’m actually reading the log files on every restart of HA), which would at least prevent this “feature” from firing unnoticed.
So, again no offense, but I hope everything that has to be said about the pitfalls of the initial_state: true attribute for automations is said now and we can return to the initial question.
Thus I’m still curious, if someone can reproduce, or even better, actually explain, why my history_stats sensor behaves this strange?
Having all automations turned off after a restart is not normal behavior. Normal behavior is the restore feature sets each automation back to its state prior to the restart. Using initial_state: true overrides this behavior and causes last_triggered to be reset.
You find yourself using the history_stats sensor because you’ve lost last_triggered as a result of the blanket usage of initial_state: true.
Hey @tom_l! Why did you withdraw your posting? I was curios about this and read the change history. The first sentence hits the nail on the head and actually explains the behaviour of this sensor perfectly. I hope you don’t mind me quoting this anyways:
Of course this is causing the sensor to increase by one on every restart and don’t caring for the automation actually being triggered.
Unfortunately this also means I can’t use this sensor as intended. Bummer!
Edit: Ok, meanwhile you posted your initial comment again. Thanks for the clarification!
I can’t remember, from where I got the “three minutes”, maybe this was a false memory. But this is, what regularly caused my automations to turn off, even if I intentionally (!) restarted HA “too fast” two times in a row:
Especially on a slow device like the RPi3 I used until some weeks ago it was easy as pie to interrupt an already running startup process with a second restart, as with my (rather complex) config it sometimes took up to a minute before HA finished restarting.
But as said before, I’ll give it another shot without initial_state: true. Since I moved my HA installation to a mini pc with actual (i7) power under the hood, HA restarts finish in a matter of seconds now.
Even myself however am not capable of “realising, that I forgot something, running nano, changing the config, saving, exiting, restarting container again” in less than ten seconds.
So I hope, this interrupted startup problem is much less likely to happen now. Time will tell…
Edit: As I think of it, maybe a template sensor and an alert rule to monitor my automations being enabled would come in handy. This would once and for all prevent my automations from turning off silently.
Bingo! You’ve described an environment that is vulnerable to having its startup process interrupted: a slow host machine. If it take many minutes to complete the startup process and it is interrupted (whether due to a configuration/device error or impatience) there’s a chance the restore feature will not have had the opportunity to do its job.
I offer you the automation I described in my previous post. I just tested it and it appears to work as expected. Upon startup, it will be turn on all automations.
- alias: 'Start All Automations'
initial_state: true
trigger:
- platform: homeassistant
event: start
action:
- service: automation.turn_on
entity_id: all
Now you can remove initial_state: true from all your other automations, secure in the knowledge that they will always be turned on at startup by automation.start_all_automations.
What you will gain is that all your automations (now without initial_state: true) will retain their last_triggered value after a restart.
Don’t get me wrong, but I was quite sure, you couldn’t resist to blame my former humble and hard working RPi3 as the “underlying problem” in the end.
Thanks for the offer, I appreciate it. But sometimes I also turn off automations temporarily for good reasons. With initial_state: true as used before, they sometimes actually re-enabled unintended on restart.
The more I think about this matter, my main goal is to prevent automations from changing their state (in any direction) unnoticed.
Thus, just monitoring them and don’t automatically tamper with their states anymore will be the best solution in my case.
Anyways, thanks guys! I learned two things today:
enabled != triggered (ok, I knew that before, but obviously suffered from some kind of tunnel vision earlier today…)
I’ll definitely reconsider my attitude regarding the uselessness of the last_triggered attribute.
Edit: Becoming a bit off-topic now, but tbh I still can’t wrap my head around the fact, that the last_triggered timestamp for an automation is dumped on restart just because the automation sets an initial_state. I mean: Why? What’s the technical (or logical) reason for this behavior?
even more, ‘triggered’ alone is not ‘triggered’… only ‘triggered’, And ‘evaluate the condition part to true’ sets the last_triggered… many automations are triggered constantly, eg by sensor.time, but they only set the last_triggered when the action takes place.
Agree with @123 that there’s an underlying issue with HA to lose all automations state at startup (had in many times). Don’t like the solution to turn them all on by automation at all though, since my system has many automatons that set other automations on/off which are set to initial_state: ‘off’. Using the turn_on: all automation would be even worse than use initial_state on the few automations that Must be on at all times. see also: All automations getting disabled automatically · Issue #24310 · home-assistant/core · GitHub
In my case, after many restarts with wronged automations, I know just fine which are the ones, and I quickly turn them on manually. Ive added the important ones to several groups they belong to, so I don’t need to go to the all_automations group (which wil be gone soon).
Of course I could easily group these in an extra group, and use @123’s All automation on that group…
All in all, each ALL strategy has its downsides, and a true solution will always need to be tailor-made.
this seems a very relevant question indeed, particularly On topic I would say. Please suggest this in the relevant GitHub issue tracker?
