@mayker that’s it, mystery solved 
I appreciate the example but the only way the garage door would open on startup is if the automation was explicitly written to do that (by design, not by accident). initial_state restores the automation’s previous state (enabled/disabled), not the previous state of the entities handled by the automation.
I’ll try to find the PR that implemented this feature and see if it explains why this change was needed
What would be an example of a failing automation? If it’s a syntactic error, Home Assistant logs it and ignores the automation (just like an incorrectly written entity). If it’s a logical error, it only reveals itself after Home Assistant has already started (because most automations are triggered by other events; far fewer are triggered by homeassistant.start).
Even if one could write an automation that caused Home Assistant to fail on startup, why would Home Assistant restart? In my case, Home Assistant halts and does not ‘reboot’. You’d need to have a watchdog monitoring Home Assistant (like in docker-compose) to restart it upon failure. That’s a very unique failure scenario to justify the need for an initial_state parameter.
Defaulting to false is always going to be safer than true. In the previous example if the automation trigger is something like wifi presence then the situation is still valid. I can think of a few automations in my setup that I wouldn’t want to trigger based on presence, etc without my knowledge.
Most of my automation are in node-red but I had a few that are simple that I kept in hass. I first noticed this when the lights outside did not come on at sunset.Looked and everything was off. I just wondered when this change happened because it seem to start with .85
Except we’ve agreed it doesn’t work this way, it defaults to using the previous state (as per the documentation). It defaults to false only if the last startup was interrupted.
You’ve made my point. You’re describing an automation that will execute its action if trigger and conditions are fulfilled. If they are fulfilled upon startup, so be it, that’s by design. If you don’t want them to be fulfilled upon startup, modify the automation. This behavior is independent of the initial_state feature which normally restores the automation to its previous state (if enabled, then it’s stays enabled).
This is the portion I am talking about and defending. Anything else is irrelevant as you can set the initial_state
I still don’t see a use-case for disabling all automations after an interrupted startup.
Prior to when it was implemented, were users inconvenienced by automations that remained enabled after an interrupted startup? Were they providing examples of how it caused them problems? Were they asking for it to be changed so they could specify the initial_state of each automation?
I don’t recall seeing any threads about it so I’m wondering what is the problem that is fixed, or enhancement, by the introduction of this feature.
I absolutely do and think my prior example shows a pretty good use-case.
Why would they wait for it to be a problem first?
You now get to choose the behavior, so I’d say that’s both a problem fixed and an enhancement.
Please explain how your example would behave in versions prior to 0.84 and how it differs from 0.84+.
Jesus, man. I honestly don’t understand why you’re so upset by the addition of features that give you more control over the thing your complaining about. Have a good one.
Edit: I must have been having a bad day, but I took what you were saying in totally the wrong way. Very sorry about that.
Upset? No, not at all. Curious to understand this feature? Yes.
Thanks for your input and have a great day as well.
BTW, I found the PR (it was part of 0.84 release) and is part of a wider effort to preserve entity states to survive a restart. However, its implementation for automations is somewhat unique when compared to entities.
Well this finally explains a couple of occasions recently where all my automations were disabled. At least I now have a course of action to fix it (though it’s a pain to edit over 100 automations spread across dozens of yaml files)
My main question though, is how did this not rate “breaking change”? It certainly broke things here!
I appreciate the dedication to making things load previous state, that’s a big positive. Future note though, the behaviour I think most people expect is:
- obey initial state if defined
- if no initial state is defined, load previous state
- if no initial state is defined, and unable to load previous state, default to on. (as opposed to what it does now which is default to off)
This behaviour would ensure priority given to manual initial state definitions and previous states, but would behave as people are used to if those fail.
Nobody is upset, but the feature does give a lot of people a lot of headache, this thread is just one example.
How about this
And isn’t it a valid question
I personally was hit by this stuff only yesterday after upgrading my Hass.io from 0.88.0 to 0.88.1 - some of my automations that used to work suddenly stopped. Some claim that it changed in 0.85, but I didn’t miss any major upgrade since then and it kicked in only now - very odd and annoying.
And looking at the description of initial state it says nothing about what happens if there is no initial_state in config and one starts HA for the first time.
It’s not obvious and I believe needs to be updated.
Here is how it works:
If initial_state: is used, then the automation will be either on or off based on what is coded in the event of HA restating.
If initial_state: is not used, then the automation will be restored to whatever state it was in before HA restarted. (Remember: having recorder: is required to enable state restoration)
Pretty simple guys.
It would also be nice if you could simply toggle the automations back on from the UI. But the need, as you mentioned, to edit the YAML file for all of the automations to just be turned back on, and then to edit the YAML file again to get back to “normal” is really a mess. I’m debating to do a complete wipe of HA and do a complete rebuild. All my automations, scenes and scripts are locked down. And we all know editing YAML files takes about 3 reboots before we finally got “every line of code/routine” fixed. This really is a horrible implementation of a recovery from a poor shutdown. Couldn’t HA simply prompt on reboot, “RECOVERY MODE: Would you like to reactivate all Automations?”
A year has passed since this issue was reported. Using current versions of Home Assistant, are you still experiencing all automations turned off on startup?
Yes!
Yes!
Yes!
This is a meaningless sentence so that it will post the reply…
Sorry to hear that. Have you determined why it is experiencing bad shutdowns? Is the power being interrupted?
I can offer you a small convenience. Create a script that enables all automations. Whenever all automations are disabled after a bad shutdown, manually run the script to re-enable them.
Ideally, prevent your server from experiencing bad shutdowns. My server is an old laptop donut can run on its battery if there’s a short power failure.
More than likely, I got distracted while editing YAML files and did a restart within multiple tabs being displayed on multiple monitors. Not uncommon for me to have a variety of HA screens being displayed side by side as I learn HA and play around with automations, scenes, YAML and the editors. Been known to have at least 10 tabs open simultaneously. My assumption is that I did a reset in one tab, flipped over to reading a post while it was rebooting, copied text from the post, went to another tab to paste the code and initiated another reset. That’s about the time this went sideways. All of it was all because friggin’ scenes weren’t working as described. Things are so bad at this point that I am now in the process of backing up the files and about to do a reflash and start over. Hopefully that will reset the multiple issues I’ve been experiencing.