Automations not working - 1 month now

Configuration
13

This.

Worst of all, we invite novices to read the documentation … only to discover it contains whoppers like that one.

14

Ok, I’ve learnt something here…
And to show that I am not being difficult on the basis of this I fully intend to remove comment out* all my initial_state: off

But,
A while ago, possibly as much as a year, I do remember there being some issue (misunderstanding?) over this and some inconsistency with the way HA (appeared) to work. At the time some automations seemed to be initially on or off at random after restart. I used to have an automation that ran on HA start to set all my automations to on in order to stop this. And just because I think he might be interested, because for some reason I remember him being involved in at least one thread on this, I am tagging @anon43302295.

But thanks for the clarification on how things work (now?).

*You can’t be too careful :grin:

15

I use initial_state because I expect all my automations to be on when homeassistant starts, and it covers the potential that someone has accidentally switched one/some off.

In fact, I would feel like I had failed if I had to remember the state of the automations, as it would mean that I am switching automations on and off for different circumstances, and that’s rubbish. All automations should be on always, and if you don’t want them to fire in certain circumstances you should use conditions. Turning automations on and off, then remembering the state, then hoping that the state shouldn’t have changed whilst the system was off is poor skills IMO.

PS - I didn’t read the thread before I replied to @klogg, so I don’t know whether what I’m saying is relevant to the discussion really, but a quick browse up and AFAIK initial_state behaviour has always been ‘on’ = automation on at start, ‘off’ = automation off at start, ommited from config = remember the previous state. It’s just that the latter used to balls up a lot.

16

That’s not always true. I use some automations on certain occasions. For instance my automation to speak the daily weather forecast and daily news triggers with motion at the front door. And I want to hear that message only once. So when it triggers, it turns itself off. And turns it back on at 4 am next morning. In the weekends another message automation is triggered. Some automations also need to override others. For instance someone has entered home is overriden if that someone is me. The system takes its time to understand it is me who entered the house so the other automations is temporarly disabled to not be triggered by the door etc. I am sure there are other ways to get the sam functionality but it is working fine for me.

17

Before this thread veers too far off course, the initial_state option definitely has a useful purpose except it has been overly recommended as a remedy for the “my automations are off” affliction. This folk remedy comes with no warnings about its side-effects:

  • If you temporarily turn off an automation, “temporarily” translates into the “until the next restart”. That might be perfectly fine for some users but for others “temporarily” ends when they choose to end it and not when Home Assistant restarts.
  • Your automation loses its last_triggered value upon startup. Maybe you don’t care about this attribute now but you will if you ever need a reliable record of the last time the automation was executed.
  • Nausea, dry mouth, disorientation, vomiting, spasms, and rectal bleeding.

The documentation does everyone a disservice by making the false claim that all new automations are disabled by default and you have to use initial_state: true. That’s bull$hit.

If you don’t trust the restore feature and want to ensure your automations are always turned on at startup, yes, you can add initial_state: true to all of them with the understanding you will be giving up the two things mentioned above.

Alternately, if you don’t trust the restore feature but also don’t want your automations to have their last_triggered attribute erased on startup, use a ‘startup automation’ like this:

- alias: 'Start All Automations'
  initial_state: true
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: automation.turn_on
      entity_id: all

Remove initial_state: true from all other automations except the one above. Now your automations will be always be turned on at startup but won’t lose their last_triggered value.

3 Likes
18

EDIT

The following draft documentation is no longer needed. It is left here for no other reason than to prevent breaking the thread’s continuity.

If nothing else, it served to start a discussion that resulted in a significant bug fix in version 0.94.1 and another fix (breaking change) that will come in version 0.95. In addition, documentation errors concerning the initial_state option have been corrected by frenck.

--------------------------------------------------------------------------------------------

Here’s my first draft of the new documentation for Automation Initial State. I invite the community to review it before I submit it as a PR.

Automation initial state

During startup, Home Assistant attempts to restore an automation’s last recorded state (on or off). This restoration feature works like this:

  • If the automation was on it will be restored to on.
  • If it was off it will be restored to off.

You can optionally override the restoration feature by adding the initial_state option to an automation.

The option can be set to one of two states:

  • Use true or 'on' to always set the automation to on at startup.
  • Use false or 'off' to always set the automation to off at startup.

Examples:

  • initial_state: 'on' will set the automation to on at startup.
  • initial_state: false will set the automation to off at startup.

Be advised that this option currently has two drawbacks:

  1. Upon startup, the automation’s last_triggered attribute is reset (set to None). Therefore it loses its previous datetime value.
  2. If you temporarily turn off an automation (via the Services page or the Lovelace UI) it will automatically be turned back on at startup. Effectively, you lose the ability to temporarily turn off an automation for a period longer than the next restart.

There is a way to mitigate the first drawback. Create the following automation:

- alias: 'Start All Automations'
  initial_state: true
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: automation.turn_on
      entity_id: all

This will be the only automation that requires initial_state: true. Exclude the option from all your other automations.

Now when Home Assistant starts, it will trigger automation.start_all_automations and set all automations to on no matter what the state was prior to start-up. Each automation’s last_triggered attribute will not be reset and its previous value (if any) will be preserved.

EDIT
Added suggested modifications.

3 Likes
19

You got my seal.

20

Me too but I wonder if you need to add another advisory that by using that automation you lose the ability to have individual automations set to off at startup.

I know it seems obvious but it is kind of the the corollary to

21

True. That’s drawback #2.

As stated in the draft documentation, the suggested automation only mitigates drawback #1.

The automation forces all automations to on, just like adding initial_state: true to all automations, except it doesn’t cause the last_triggered attribute to be reset (drawback #1).

Would it be clearer if I reduced the second drawback to this:

You lose the ability to temporarily turn off an automation for a period longer than the next restart. At startup, the automation is always set to on regardless of its previous state.

22

I was thinking more of the drawback of using the automation being that you lose the ability of using initial_state: false for those automations you want to default to off at start up.

For example I have a couple of automations I turn on for testing purposes so I have initial_state: false but that means I could not use the automation to turn on all my automations at start up so I’d have to either trust the HA restore of list every one individually.

23

I really like that. Great option.

24

An interesting philosophy but not one I subscribe to. e.g. seeing that my climate control automations have been disabled when I am away for an extended period is far more reassuring than leaving them on and relying on conditions. Using enable/disable allows for quick and easy feedback.

Also it allows for easy experimentation. Just last week I was trialling the use of my downstairs heat pump’s ability to heat the whole house. This heating source is automated but is disabled unless that area of the house is in use. Using your proposed system would have required altering a lot of conditions and reloading automations. Using my system all I had to do was toggle off the upstairs automations and enable the downstairs ones. It turned out that the heat pump was not up to the task so returning to the original setup was likewise just as easy.

25

I have an input_boolean called home and away and as a condition in my automations, it checks if that is on or off and then does the action depending on that. Using an automation on/off is a poorer way of doing this and can have other consequences…
image
So Home means all my automations I want on when I am home will activate…
Similarly:
image
If I’m away they won’t run. Overtime means my wife is doing overtime and it adjusts the time some of my automations are activated via conditions as well and Holiday mode similarly adjusts times (so my coffee maker does not turn off during the day for example)

I find this approach superior to turning an automation on or off.

I also used to find that I have a lighting automation and if I’m away at night, I used to turn that off and then turn it back on that night but that would then trigger the automation and turn the lights on (and I would do that when I remembered to do it otherwise I would likely forget to turn it back on tomorrow and no lights) But the in-you-face input_booleans, colour coded… well that hasn’t happened. I can also turn those on/off via Google Assistant…

Anyway… my 2c

26

I use an input select to set my automation ‘mode’ as there are more states than just home and away. I also have two guest modes and an ‘all off’ mode for HA-haywire-emergencies (which TBH I have never used and will probably remove). Automations are automatically enabled and disabled depending on the state of this input select. I could add conditions to each automation to check the state of this input select but I prefer having the list of which automations are enabled and disabled all in the one place (in the ‘mode’ automation).

Like what?

I’m open to change just not yet convinced of the convenience.

27

I had some discussions with balloob when he was seeking feedback for removing the auto-generated groups like all automations and he said then to use an input_boolean condition was better so I switched at that time.

Other consequences like outlined in my post with unpredictable things happening when you re-enable the automation and then it triggers when you don’t expect it to.

In your case I would just use the input_select as a condition and expose that on a lovelace button but each to their own.

1 Like
28

Only because you didn’t write them to that system in the first place :wink:

1 Like
29

I think the answer is no, but I just want to check…
Is it possible to use any kind of wild cards?

For example if you name all your lights automations beginning with the word ‘lights’ could you do something like this?

- alias: 'Start All Automations'
  initial_state: true
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: automation.turn_on
      entity_id: automation.lights*
30

True but the suggested automation, as stated in the draft documentation, is designed to address one of the two drawbacks of using initial_state: true. It is not described as a solution for anything else.

It is beyond the documentations’s scope to offer an automation that handles both initial_state: true and false. That would involve a considerably more sophisticated automation (involving groups and/or templates). That seems too advanced for a documentation page that introduces users to automations.

31

I agree, I was just suggesting that to give some balance it could be pointed out as a drawback to using the startup automation.

But I’m easy, and for what it’s worth I’m happy to back your doc change as you have it.

32

Hi!

Thanks for all discussion. We are currently looking into this and discussing on how to resolve the general issues around this subject.

In short: the documentation is currently wrong, but there is a misconception on what initial_state does/is.
initial_state is the state the entity/automation has on startup of Home Assistant and overrides anything.
Without an initial_state, it will always try to restore the state from storage. If restoring of a state fails, the state for automation = ON/True/Enabled.

For other platforms/integrations, the state after restoring the state failed, depends on the implementation of that specific integration.

The confusion probably comes from the fact with people looking to set a default state in case restore has failed. It is not possible to change that specific behaviour and, in case of automations, will always be on.

Nevertheless, we are internally verifying everything and considering options to resolve the confusion around this.

:+1:

5 Likes