Automation will not longer trigger (0.85.0)

Configuration
1

I have all up to v.0.85.0 been able to use the following automation, but after upgrading to 0.85.0, Im not able to trigger this anymore.
I dont get anything in the log (I have set all relevant component loggings to debug), and the individual triggers like input_boolean and switc works.
I really have noe idea how this could happen.

 # Activate Stue Normal mode
- alias: 'Stue Scene Normal'
  trigger:
    - platform: state
      entity_id: switch.stue_mode_normal_mem
      from: 'off'
      to: 'on'
    - platform: state
      entity_id: input_boolean.enable_stue_normal
      from: 'off'
      to: 'on'
  action:
    # Notify
    - service: script.google_home_say
      data: 
        google_home_entity: media_player.stue
        volume: 0.2
        message: 'Normal modus aktiveres.'
    # Activate Light scenes
    - service: scene.turn_on
      entity_id: scene.stue_normal
    # Reset (modeflags in Dimmer 2)
    - service: homeassistant.turn_off
      entity_id: switch.stue_mode_normal_mem
    # Reset UI switch
    - service: input_boolean.turn_off
      data:
        entity_id: input_boolean.enable_stue_normal
    # Log
    - service: script.logbook_entry
      data:
        entry_name: 'Stue mode:'
        entry_message: 'Normalmode is activated'
2

add

initial_state: 'on'
3

initial_state: ‘on’ on the automation?
Will this trigger the automation everytime I restart Hass?

4

You shouldn’t need to do initial_state to on, I don’t have that on any of my automations.

Do you see the automation on/off switch on the front end? Is it turned on after reboot? It should be, if it was turned on before the reboot, even without initial_state being set.

If it’s on, but not triggering, then it’s probably not initial_state.

I’d look to see if any recent breaking changes affected something. But not all are always decremented - I just had an automation break because the IMAP component changed naming policy, didn’t see that documented anywhere.

5

Hi,
In the UI development tools, all my automations state are off. I have never needed to turn them on in any way.

6

Automations need to be in the on state otherwise they won’t fire.

7

I did a quick test now, and set the automation to “on”.
This solved my problem!
I have nnever needed to turn them on before, so I didnt realize that this was expected.
This has hapened after the upgrade to 0.85.0.
I guess I have to set the initial state to on, as @Klagio
Thanks for the help!

8

You missed the Breaking Changes on 0.84.0. Simply call service „automation.turn_on“ without an entity once. That will bring them back on, even after HA restarts.

1 Like
9

@m0wlheld Haha funny…I skipped 0.84.0 since the telldus and volvooncall had bugs in them, so I didnt pay to much attention to that release.
Wish I had seen your post earlier, I just finishe settings initial_state: ‘on’ on all 30 automation…
Thanks for the tip

10

No you don’t…

And you really shouldn’t unless you really want them all to be turned every single time you restart HA.

Let’s say for example that you have an automation that you only want on under certain conditions. Sometimes you might turn it off for some reason. (I have some of those right now). Then the next time you restart HA or reload your automations the automation will automatically be turned back on. This could be undesirable.

If you leave out the initial state then the automation state will be remembered across restarts and after the restart it will still be in the same state that it was in before restarting.

I wish the documentation was better at explaining this so people would stop advising others to do the wrong thing.

11

Then change the documentation.

12

I tried once and it was a 3 week back & forth between 2 or 3 admins nitpicking every detail and it eventually wasn’t incorporated anyway.

Kind of left a bad taste bin my mouth for wanting to try again.

But yes, I agree, i probably should give it one more try. Maybe this will be more straightforward so not as much to nitpick about.

13

I think 99% of user case is to have automation to “on” all the time.

The automation should fire because of what is inside the trigger, not because of the initial state, otherwise its not an “automation”

14

Yep but once a change was made, it was a better option to turn them all off rather than turn them all to on. No developer wants to be responsible for a house burning down because a heater came on because a default changed,

Anway now there are three perfectly sensible options:

initial_state: on - automation will be on when HA starts - you are right, this is probably what most people want.

initial_state: off - automation will be off when HA starts - you are also right, I am not sure why you would want this, but some people may be trialling stuff and not actually want some testing version to be on by default.

no initial_state defined - automation on/off state is preserved across reboots. This in fact what most people want, they just don’t know it!

1 Like
15

I use this for some notification automation because on a HA restart I was getting notified in error since the devices hadn’t initialized completely. It was easier to have those off initially and have another automation turn them on 5 minutes later than to create a more complex trigger/condition template for a bunch of automations.

And I think you are exactly right on this.

And thanks for nudging me to make the change to the docs for this. I submitted the change request and it`s been incorporated already. It was way easier this time.