Automations broke after 0.84.1 update

Configuration
1

For som reason all State Change triggered automations have stopped functioning after the latest update of HASS.OI

All triggers work as expected motion sensors, input selects or input numbers. It calls appropriate service and motions change state on the entity, but the action fails to execute.

The simplest of automations fails to execute the action:

  • alias: Lys Loft på
    trigger:
    platform: state
    entity_id: binary_sensor.motion_sensor
    to: ‘on’
    action:
    • service: light.turn_on
      data:
      entity_id: light.light_1
      brightness: 150

Anyone seens this?

2

Take a look at your automations in Dev Tools/States if they are ‘on’.
Since 0.84 there’s a new way to store the last state.


3

This is in fact a very critical detail not very well explained in the release notes…

You must add the line:

initial_state: true

to ALL your automations to get them working properly…

I’ve struggled all night now even did a rollback with way too many complications and lost lots of stuff implemented lately, however I managed to recover… (note to self: backup before upgrade)

1 Like
4

You don’t must add this line.
If you turn an automation on or off, the last state will be saved on restart.

1 Like
5

Yes, that’s true…until the next update to the DB loses all of the automation states and you have to start over from scratch remembering to check the state of the automations.

I never have put the initial_state line in any of my automations unless I wanted direct control over when they were on or off but it might be worth it from now on to specify this in case things get jacked around with again later.

6

Here’s the relevant excerpt from 0.84’s release notes:

Improved state restoring

We have a new more reliable way of state restoration introduced by @armills. Instead of relying on the database it will now leverage the storage helper to keep track of states that need to be tracked. This should improve reliability and startup speed.

This comes with a downside: we will be unable to restore states the first time you start 0.84.

The nitty-gritty details are in the following PR. Basically, the state is now stored in what I facetiously call configuration.yaml 2.0, namely those ever-growing JSON files in the .storage directory.

7

so upgrade to 0.84, check states of all automations, and restart?

8

That’s the theory. I can’t confirm if it’s true because I have not upgraded to 0.84 yet.

9

all mine are on and working… I think in one of the Betas I noticed they were all off and just turned them on again. Sometimes if you restart too many times close together they also turn off and I probably blamed that at the time but they are all solidly on for me…

10

Well, turning the automation on/off made no difference whatsoever for my part.
It never fired the requested Action for whatever reason.

After I finally got it back to live again, the problem persisted UNTIL I added initial_state=true.

I tried this on one of my automations, didn’t work before, worked after. Other automations without did not work prior, but after I added this.

See other have had similar issues around, however there are some inconsistencies around.

Not sure I want to go through these hickups no more. Every upgrade breaks something causing me hours of frustration. Not sure it’s worth the effort…

1 Like
11

My automations are dead too

12

initial_state: true => not helping?

13

which is a good thing (a least in theory, hope practice will prove to be as designed)

would this mean we can take automations out of recorder (I had them there specifically for restore_state, as several other components like input_boolean etc etc)
Might alleviate the recorder issue people have.

14

It worked for me after I included this.
No issues seen after.

15

Me too, after included, all automations works fine