I have experienced this. I always set my initial state to true now. I don’t use the automation config but can see how the true/false option would be useful for those that do.
Do you recall the circumstances that caused it?
Sadly not. It was after a restart and not a single automation was switched on.
Sorry I can’t be of more help.
FWIW, when the restore feature was added to Home Assistant (I no longer recall the version; possibly as far back as 0.84), after upgrading, everyone’s automations were turned off. That’s because the feature was brand new and had no way of determining an automation’s state prior to the upgrade. The solution was to manually turn on all automations (you can use the Services page to do that). Afterwards, the new feature would restore automations to their previous state after a restart.
However, many people latched on to the idea that the solution was to add initial_state: true to each and every automation. It definitely works but initial_state is designed to override the restore feature. As I explained above, that may be desirable/undesirable behavior.
I’ll give one example where initial_state: true would be undesirable. You have an automation that runs on demand. When you need it, you enable it manually, when you don’t you disable it. If you disable it, but it has initial_state: true, the next time you restart Home Assistant the automation will be re-enabled. What you had disabled days or weeks ago is now enabled again. You may not even notice the change until the automation executes.
In a perfect world, there should be no need to manually enable/disable an automation. Its trigger/conditions should be sophisticated enough to know when it should and should not run. In this ideal situation, one could use initial_state: true with confidence.
If one wanted to still have a manual override in this so-called ideal situation, the automation’s conditions could monitor the state of an input_boolean. Now you can use initial_state: true with the knowledge that you still have ability to manually suppress the automation (with the input_boolean) and it won’t be countermanded by the restore feature.
Very good and very well made points.
I’ll review my strategy.
In a perfect world, there would be a master setting which says “automatically set all automations to initial_state: true” (or false, depending on your desire), unless I specify otherwise. For whatever reason, the restore feature just doesn’t seem to love me.
In a perfect world, the restore feature would not set all automations to off after a bad restart. 
this is not completely correct. It used to work perfectly before, and relied on recorder.
the move from recorder to the .storage ‘broke’ it. Ever since that move, every once in a while all automations lose the state they were in, and one has to reset manually.
I reentered the initial_state for the ones I need to always be on at startup, and several to false (apparently ‘off’ isn’t allowed any longer) for the automations I need only in certain situations.
All in all, restore state has lost its use for automation because of that…
Throughout this thread, I’ve been referring to the current restore feature (using .storage), as implemented in 0.84 (or whatever version it was) and not whatever may have existed prior to it.
This form of state-restoration was indeed “new” since it no longer worked the same way as its predecessor (for better or worse). Because it worked differently, after performing the upgrade, it had no knowledge of an automation’s previous state, so it defaulted to off. That seemingly simple design decision caused the user-community a lot of confusion after upgrading (and still causes confusion).
Ideally, the new restore feature shouldn’t be influenced by a bad startup and default to setting all automations to off. The chance of this happening is low but low is not never so it causes users to add initial_state: true. The irony is that the option effectively overrides the new restore feature! What should have been an improvement (using .storage) only became more complicated and ultimately disabled by using initial_state: true. 
Just a suggestion to help those who don’t want to use initial state true… ive had this happen to me a couple times, usually after multiple reboots or upgrades etc. I ended up making an automation that alerts me if the group.all_automations is off for 2 minutes … because then I know it has erroneously set all my automatons to off… again just a suggestion so people don’t troubleshoot why their automations aren’t working for 10 minutes before they realize they all got turned off again, because that’s what happened to me.
I assume this automation has initial_state: true? 
Neat idea … and its very purpose is indicative of the complications introduced by a restore feature that runs the risk of not restoring.
1 Like
I should probably check 
WAit… now it won’t work …lol one would be on … I’ll have to do a template or something to exclude that one automaton . Thanks
Yes, I share your final conclusion. Unfortunately though, hope it will be adjusted to work as desired.
Did you quit the startup process halfway? Or didn’t you close HA entirely (meaning force closed by killing the process?). I find that when I stop the startup process at the exact moment the automations get loaded all automations will turn to the off state. (I do this because sometimes I forget to add something and it is faster to just force quit it than to wait till it is fully startup and then close again). Or if the startup process could not complete (because of any breaking changes) this could happen too. (at least that is my experience). So you could do multiple things:
- Set initial state to ‘on’ for each automation you want to be ‘on’ at startup.
- Create a group/button that you could turn on/off whenever you please, for example with an input boolean.
- Create an automation with initial ‘on’ to turn on all other automations (seems a bit stupid but hey it is possible).
If there are 0 automations that need to be off at the start you could just turn all automations on/off via the group.all_automations entity (which is always present by default). Go to the dev-tools and open the services panel. Use for example the homeassistant.turn_on service and then the entire group. In my case I was lazy and just made a single button which does exactly this (so if the automations are off I just need to press this button.) not the most ideal situation, but saves some time if you have over 50 automations like I do 
Yes, the group functionality is a great one. Instead of setting initial_state: true for these automations (that always need to be on) one could also create a group with these automations and use that in the unfortunate situation HA didn’t restore their state, and even automate that process at startup… using the all option Group - Home Assistant
could be a nice go between, and I use it for that purpose only. (far over 50 automatons here, so it was kind of a pain to reset all of them over and over again)
I’m just going to make a group with a handful of automations that I never turn off or would want off (door alerts etc) maybe 5 or so and if those are ever all off at once I will know something is up… lol thanks for questioning it or I never would have realized it wasn’t gonna work.
something like this:
# use the `all: on` option for this group to force the group to be only on when all automations are on
- alias: 'Secure automations on at startup'
id: 'Secure automations on at startup'
initial_state: 'true'
trigger:
platform: homeassistant
event: start
condition: []
action:
- condition: template
value_template: >
{{states('group.automations_always_on') != 'on' }}
#- service: homeassistant.turn_on
# entity_id: group.automations_always_on
- service: notify.notify
data:
title: 'Check automations!'
message: Not all automations were restored, please secure your system..
I’m not gonna have it turn them on automatically I’m just gonna have it notify me that they are all off so I can go turn on the rest that should be on… it’s only happened 2 or 3 times so I don’t mind checking and then I will be aware it messed up.
I have a start up script that enables or disables all my automations depending on the state of an ‘automation mode’ input select (all off, away, home, guest etc…). The start up script is one of the few scripts that have the initial state set to true. The others are hidden automations that work in the background (e.g. monitoring for manual change of ‘automation mode’ input select).