All automations are off on restart

[faspina (Frank Spina)]

Just upgraded to .85.0 and noticed all my automation are off when hass starts , thus no working.

How do I fix this. I am Run hass in a docker, but not hass.io

[tom_l]

Automation initial state

[123 (Taras)]

I have failed to understand the purpose of this relatively new setting, initial_state. It seems to me you would always want an automation to be active upon Home Assistant’s startup (initial_state: true). Can someone explain why you would set initial_state to false?

Is it to (temporarily) disable the automation? If so, then it would seem neater to make initial_state: true the default state (thereby eliminating the need to specify it for each automation).

[tom_l]

I have a number of automations that are only active if there are guests staying. So most of the time they are disabled. Similarly if I am away there are some automations I do not want to run.

I don’t use initial state though. I select a script at start up that enables or disables the relevant automations depending on the state of an ‘automation mode’ input select.

- id: hass_startup
  alias: 'Hass startup'
  trigger:
    platform: homeassistant
    event: start
  action:
  - service_template: >
      {% if is_state('input_select.automation_mode', 'Away') %} script.away_mode
      {% elif is_state('input_select.automation_mode', 'Guest Away') %} script.guest_away_mode
      {% elif is_state('input_select.automation_mode', 'Guest Home') %} script.guest_home_mode
      {% elif is_state('input_select.automation_mode', 'Normal') %} script.normal_mode
      {% elif is_state('input_select.automation_mode', 'All Off') %} script.off_mode
      {% endif %}
  - service: notify.ios_iphonex
    data:
      message: Home Assistant has started.

[123 (Taras)]

Given that your automation example lacks initial_state: true, wouldn’t it fail to execute regardless of input_select's state? (In version 0.84+)

[mayker (maykar (pronounced "maker" with a southern accent))]

From the link above:

If you don’t set this the previous state is restored. If you shut Home Assistant down before it finishes starting, the automation will be stored as being off, and your automations will be disabled at the next startup.

[123 (Taras)]

Thanks. I’ve read that line several times and it only adds to my confusion as to the intended purpose of initial_state.

Why in the world would this be considered the desirable default behavior for Home Assistant: Disable all automations upon restart after an aborted startup. To prevent this behavior, the user must add initial_state: true to each automation.

It seems to me the desired default behavior ought to be automations are always enabled unless they are explicitly tagged with initial_state: false. In other words, initial_state: true is the default.

[mayker (maykar (pronounced "maker" with a southern accent))]

@123

In other words, initial_state: true is the default.

But it’s not. The default is the automation’s previous state. Though I do agree that the handling of automations during a premature shutdown is a bit strange, it seems like that would be a rare situation.

[sjee]

@123

In other words, initial_state: true is the default.

I kind of agree but the way it is right now is in line with the other components which restore state on reboot like input_boolean.

https://www.home-assistant.io/components/input_boolean/#restore-state

[mayker (maykar (pronounced "maker" with a southern accent))]

Correct me if I’m wrong, but from what I understand if I set initial_state:true then the automation will be on after every restart, but if I don’t set it then it will return to its previous state even if it was off.

How then is that the same as initial_state: true? It seems you’re implying they are the same by saying initial_state: true is default.

[123 (Taras)]

@mayker

But it’s not. The default is the automation’s previous state.

You’re right; the default is neither true or false but whatever was the previous state.
Except if the the previous restart was interrupted and then “previous state” is considered to be false!

@sjee

is in line with the other components which restore state on reboot like input_boolean.

You propose it was done to maintain parity with other components? So if a restart is interrupted, on the next startup is an input_boolean’s state forced to false? Because that’s the documented behavior for automations.

[sjee]

@123

Except if the the previous restart was interrupted and then “previous state” is considered to be false !

I didn’t realize that, seems strange indeed. Are your sure about this?

[123 (Taras)]

@mayker

Correct me if I’m wrong, but from what I understand if I set initial_state:true then the automation will be on after every restart, but if I don’t set it then it will return to its previous state even if it was off.

Yes, I agree, this is what the documentation says is the behavior of initial_state.

How then is that the same as initial_state: true ? It seems you’re implying they are the same by saying initial_state: true is default.

No, I am not implying they are the same. I provided a proposal. I suggested it ought to behave like initial_state: true is the default. In other words, upon startup (whether the last startup was aborted or not) all automations would be enabled by default. You’d have to add initial_state: false to change the behavior. Again, this was just a proposal (and not how it currently works).

[123 (Taras)]

@sjee

seems strange indeed. Are your sure about this?

I agree it seems strange. I’m not 100% sure because I’m still using 0.80 . However, that’s what the documentation says:

If you don’t set this the previous state is restored. If you shut Home Assistant down before it finishes starting, the automation will be stored as being off, and your automations will be disabled at the next startup.

Perhaps I’ve simply misinterpreted the purpose of initial_state and that’s why its behavior seems so awkward. On the surface, I fail to see why it was needed. All it seems to do is cause threads like this one where users report all of their automations have become disabled (after upgrading). Now they have to add initial-state: true to every automation to ensure it works like it used to do before they upgraded.

[sjee]

If you shut Home Assistant down before it finishes starting, the automation will be stored as being off ,

To me this seems somethings which happens very rarely however I also do not see why is not true by default. Maybe it’s to avoid endless rebooting loops caused by failing automations.

[mayker (maykar (pronounced "maker" with a southern accent))]

I see it as playing it safe. For a (poor) example: you have an automation that opens the garage door and your power goes out while you’re sleeping then again during startup, upon restart your garage is wide open if it resets to true.

[sjee]

@mayker that’s it, mystery solved

[123 (Taras)]

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

@sjee

Maybe it’s to avoid endless rebooting loops caused by failing automations.

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.

[mayker (maykar (pronounced "maker" with a southern accent))]

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.

[faspina (Frank Spina)]

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