Nearly every day someone comes to the forum to ask why their automations no longer work even though they used to. The answer is nearly always that the automations were turned off for some reason: manual, database issues, upgrades, etc. I have used initial_state: true in each automation which seems to have solved this issue for me, but I find that I never actually have a use case for turning my automations off. It would be nice to have the option to force all automations to be always on as I could still accidentally turn them off or some other user could turn them off manually.
I’ve thought about creating yet another automation to check for automations that are off and then turn them back on, but this one could be turned off too.
I’m not proposing on by default, but for the option for the automations to be always on. For automations that are not always needed, I find that it is best to set up the triggers and conditions so that they don’t run when not needed. I’m also not asking for all automations to be always on either. Just the option to do so.
There was one release, I think around 0.85, that refactored some things around state restore for automations, and the result was people’s automations did reset to off. But I think this was only an issue on the first restart after the upgrade to 0.85+. From that point on, there shouldn’t be anything causing automations to turn themselves off, unless you explicitly set an automation to initial_state: false. More information here:
@apop If the database is ever purged or gets corrupted, etc. You can, and I have, had all my automations set to off. This has happened at least twice to me until I realized how initial_state: true can fix this from occurring in this case.
@anon34565116 I’m asking for there to an option via yaml so that not only are they on by default, but they CANNOT be turned off. I see no compelling use case to turn off any of my automations ever, so why would I want there to be an option to turn them off? I could accidentally turn off my automation that alerts me when my basement floods when I’m tinkering around with purging my database for something , and miss that notification when it occurs.
My proposal only enables this for those who want it, it wouldn’t affect the way you use automations.
I will say that in the meantime, if you are looking for a way to monitor and address turned off automations without such a feature in place, you could use AppDaemon or Node-Red just to monitor for disabled automations and turn them back on. (I’d be happy to write up something for you in AppDaemon if you’re interested.)
I’m not sure. I’ve had issues in the past where I’ve had to clean out either the database, or one of these .storage files, so you are probably right. I just assumed it was the database since it would store the state of the automation as well. Although now that you’ve asked, it only stores the state if you’ve included (or not excluded) the automation in the recorder.
Edit: and now that I actually read your post a bit finer that if this was changed in 0.85, I’ve been using it since about v0.50ish. So who knows?
Since version 0.85 (or thereabouts) Home Assistant’s restore feature was revised and it stores the current state of automations and a few other entities in core.restore_state. Basically, it defaults to always restoring an automation to whatever was its previous state. So if the automation was on then, after a restart, it is restored to on. If it was off, it is restored to off.
The restore feature is not infallible. If the startup process is prematurely halted (perhaps because it encountered an error) the restore feature can become derailed. The next time Home Assistant can start successfully, the restore process has lost track of the previous state of automations … so it defaults to setting them all off. Personally, I’ve never had this happen but I’ve read several posts from people who claim it has happened to them so apparently it’s not a rare or impossible event.
There is a way to force the hand of the restore feature. Add the initial_state: true option to each automation that must be set to on when Home Assistant starts. Alternately, you can use initial_state: false for an automation that absolutely must not be on when Home Assistant starts. Effectively, the inclusion of initial_state overrides the restore feature’s behavior for that particular automation.
It’s important to emphasize that initial_state is used on a per automation basis. It’s not a global setting.
I see that I greatly muddied the waters with database, .storage, and initial_state. Even with all these factors, I still would prefer to have the option to NEVER turn off my automations.