Automations not working - 1 month now

All of my automations have stopped working since late April and I can’t figure out why. I know it must be something basic but I can’t spot it. Please help.

I’ve even tried making the most simple automation and it doesn’t work:

- alias: 'Living room playing - Subwoofer On'
  trigger:
        platform: state
        entity_id: input_boolean.media_player_living_room
        to: 'on'
  action:
        service: homeassistant.turn_on
        entity_id: switch.subwoofer

But when I manually toggle input_boolean.media_player_living_room nothing happens. Full config below - thanks in advance for any help:

 homeassistant:
  name: Home
  latitude: !secret latitude
  longitude: !secret longitude
  # Impacts weather/sunrise data (altitude above sea level in meters)
  elevation: 155
  unit_system: metric
  time_zone: Europe/London
  customize: !include customize.yaml

frontend:
    javascript_version: latest

config:

http:
   api_password: !secret http_password
  # Uncomment this if you are using SSL/TLS, running in Docker container, etc.
   base_url: !secret base_url
#   trusted_networks:
    #- 172.30.12.0/24
    #- 192.168.10.0/24
    #- 192.168.20.0/24
    #- 192.168.30.0/24
    #- 192.168.50.0/24


# Checks for available updates
# Note: This component will send some information about your system to
# the developers to assist with development of Home Assistant.
# For more information, please see:
# https://home-assistant.io/blog/2016/10/25/explaining-the-updater/

updater:
  # Optional, allows Home Assistant developers to focus on popular components.
  # include_used_components: true

discovery:
    ignore:
        - roku

conversation:
# Allows you to issue voice commands from the frontend in enabled browsers

history:
# View all events in a logbook

logbook:

map:

sun:

sensor weather:
  - platform: yr
    forecast: 24
    name: Weather
    monitored_conditions:
      - temperature
      - symbol
      - precipitation
      - windSpeed
      - pressure
      - windDirection
      - humidity
      - fog
      - cloudiness
      - lowClouds
      - mediumClouds
      - highClouds
      - dewpointTemperature

tts:
  - platform: google_translate
    service_name: google_say

group: !include groups.yaml

#automation: !include automations.yaml

automation: !include_dir_merge_list automation/
script: !include scripts.yaml
zone: !include zones.yaml
alarm_control_panel: !include alarm.yaml
panel_custom: !include panel_custom.yaml

##############   Trackers     ################################

device_tracker:
  - platform: unifi
    username: !secret unifi_username
    password: !secret unifi_password
    host: 172.30.12.97
    verify_ssl: false
    track_new_devices: no

######################## 3RD PARTY  #################################
     
ifttt:
    key: !secret ifttt_key

google_assistant:
    project_id: !secret project_id
    api_key: !secret api_key    
    expose_by_default: false
    exposed_domains:
    - switch
    - light
    - media_player
    - climate
    entity_config:
      script.alarm_arm:
            name: Alarm Arm
            aliases:
                - Alarm Arm
            room: Hallway
      script.alarm_disarm:
            name: Alarm Disarm
            aliases:
                - Alarm Disarm
            room: Hallway
      media_player.chrome_9:
        expose: false
      media_player.kitchen_tv:
        expose: false
      media_player.plex_fire_tv_molly:
        expose: false  
      media_player.yamaha_zone_2:
        expose: false
      media_player.max_google_mini:
        expose: false
      media_player.plex_web_chrome_4:
        expose: false
      climate.hot_water:
            room: Hallway
      climate.heating:
            room: Hallway
      media_player.yamaha:
            name: Living Room Speakers
            aliases:
                - Yamaha
            room: Living Room
      switch.alarm_siren:
            name: Alarm Siren
            aliases:
                - Alarm
            room: Hallway
      switch.living_room_tv:
            name: Living Room TV
            aliases:
                - Living Room TV
                - Front Room TV
            room: Living Room
      switch.clear_lamp:
            name: Clear Lamp
            room: Living Room
      switch.silver_lamp:
            name: Silver Lamp
            aliases:
                - Window Lamp
            room: Living Room
      switch.playroom_tv:
            name: Playroom TV
            aliases:
                - Playroom TV
                - Kids TV
            room: Play Room
      switch.molly_tv:
            name: Molly TV Plug
            aliases:
                - Molly TV
            room: Molly Bedroom
      switch.subwoofer:
            name: Subwoofer
            aliases:
                - Subwoofer
                - Sub
            room: Living Room
      light.landing_lamp:
            name: Landing Lamp
            aliases:
                - upstairs lamp
            room: Upstairs
      light.hallway_middle:
            name: Hallway Middle Light
            room: Hallway
      light.hallway_stairs:
            name: Hallway Middle Light
            room: Hallway
      light.hallway_entrance:
            name: Hallway Entrance Light
            room: Hallway
      switch.wardrobe_lamp:
            name: Wardrobe Lamp
            aliases:
                - Wardrobe Lamp
                - Daddy's Light
                - Guest Light
            room: Upstairs

hive:
  username: !secret hive_username
  password: !secret hive_password

##############   NOTIFICATION     ################################
notify:
  - name: pushover
    platform: pushover
    api_key: !secret pushover_api_key
    user_key: !secret pushover_user_key

  - name: html5
    platform: html5
    gcm_api_key: !secret gcm_api_key
    gcm_sender_id: !secret gcm_sender_id

  - platform: nfandroidtv
    name: nfandroidtv_mibox3
    host: 192.168.30.21
    duration: 10
    interrupt: 2

  - name: !secret my_devices
    platform: group
    services:
      - service: html5_unnamed_device_11
      - service: html5_unnamed_device_9
      - service: html5_unnamed_device_2
    
  - name: Kids Devices
    platform: group
    services:
      - service: nfandroidtv_mibox3
        data:
            duration: 10
            intterupt: 2
      - service: nfandroidtv_playroomtv
        data:
            duration: 10
            intterupt: 2
    
##############   MEDIA PLAYERS     ################################

media_player:
  - platform: plex
    entity_namespace: 'plexserver'
    include_non_clients: true
    scan_interval: 5
    show_all_controls: false
    use_custom_entity_ids: true
    use_episode_art: true
    remove_unavailable_clients: true
    client_remove_interval: 600

  - platform: yamaha
    name: Yamaha
    host: 192.168.30.7
    source_names:
        AV1: "Android TV"
        AV2: "HDMI Cable"

########################### SENSORS #############################

sensor:
  - platform: darksky
    api_key: !secret darksky
    monitored_conditions:
      - summary
      - icon
      - nearest_storm_distance

########################### Input Booleans #############################

input_boolean:
    yamaha:
        name: 'Living Room speakers'
        initial: off
    
    media_player_living_room:
        name: 'Living Room Media Activity'
        initial: off

    media_player_play_room:
        name: 'Play Room Media Activity'
        initial: off

    guests_visiting:
        name: 'Guests Visiting'
        initial: off

    molly_max_manual:
        name: 'Molly & Max (Manual)'
        initial: off
    
    home_occupied:
        name: 'Home Occupied'
        initial: on

    disable_alarm:
        name: 'Disable Alarm'
        initial: off

########################### Alerts #############################

#alert:
#  garage_door:
    #name: "Front Door is open"
    #done_message: "Front door is closed"
    #entity_id: binary_sensor.front_door_open
    #state: 'on'
    #repeat: 5
    #can_acknowledge: True
    #skip_first: True
    #notifiers:
      #- html5
      #- pushover
1 Like

First question is, are the automations enabled (on).
Check in Dev Tools/states.

2 Likes

Wow that was easy. I just had to add initial_state: true to my automations. Thanks

I’ve been using HA for around 2 years and I never did that before - did something change to make this mandatory?

1 Like

No.

initial_state is probably the most misunderstood and misused option in Home Assistant.

It is NOT mandatory. It is optional. (I don’t use it, at all).

If you discover your automations are all off, go to the Services page and turn them on. The service is automation.turn_on and the service data is all.

Many versions ago, Home Assistant’s restore feature was upgraded. After performing that upgrade, all automations were set to off. All one needed to do was turn them on. However, someone suggested using initial_state: true and then that bad advice became the most popular way to fix the “problem”. Why? Because it’s easy to say “add initial_state: true” without understanding what it does, what it suppresses, and what you lose in the bargain. It’s a ‘stick a penny in the fuse box’ remedy (for those old enough to know what’s a fuse box).

What it does is it overrides Home Assistant’s restore feature. It also resets an automation’s last_triggered attribute after each restart (you lose the record of the last time the automation was triggered).

If your automations periodically get turned off after a restart, that’s a symptom of an underlying problem with your system. If Home Assistant’s startup is interrupted, it may cause the restore feature to be interrupted and so it cannot restore various entities to their previous state. Therefore they, including automations, are set to off. So if automations are not restored to their previous state, that’s a sign your startup failed. You need to fix that and not simply mask its effects by adding initial_state: true to every automation.

8 Likes

I use initial_state for one automation that I always want enabled - my ‘home assistant has started’ automation.

Some of my other automations are set to enabled or disabled by this start up automation depending on an ‘automation mode’ (home, away, guests, party, etc) input select.

I did this as restore once failed after a power outage that lasted longer than my UPS could provide power for.

Hard coding the initial state has it’s uses but as someone who has been guilty of blindly recommending initial state as a solution I agree with your arguments and have bookmarked it for future use :slight_smile:

I agree with everything you said.

I started seeing that bad advice pop up after that change was made and tried to fight it every time I saw it.

I even went as far as to put in a change to the documentation to clarify the situation. It was accepted and implemented but I went back and looked recently and my changes were removed and replaced again with different ones. I personally don’t think the docs are as specific as they need to be given all of the persistent confusion on the topic.

Looks like there’s something going on.
https://github.com/home-assistant/home-assistant/issues/24310

Not just different but completely false:

When you create a new automation, it will be disabled (and therefore won’t trigger) unless you explicitly add initial_state: true to it or turn it on manually via UI/another automation/developer tools.

That statement is demonstrably false. I use VS Code and have created dozens of new automations that are all enabled by default; I never use initial_state: true.

The only possible way it’s true is if the built-in Automation Editor works like that. I never use it so I can’t confirm.

I appended a comment to the PR recommending the documentation revisions it made should be reversed.

3 Likes

I read the GitHub comments and I’m surprised that anyone there is surprised about this behavior. Defaulting to off has been known since the revised restore feature was introduced (I believe it was in version 0.84).

If the restore feature is unable to execute during startup then automations default to off. When they introduced the revised restore feature (which changed from saving the automation’s state in the recorder’s database to a separate JSON store) they even explained that after performing the software upgrade, all automations would be off and that this could happen again if the startup process is botched.

I pointed out that mistake on the documentation discord ages ago and asked if I should submit a PR to fix it. ‘Sound of crickets’ ensused. It was completely ignored.

It would appear the author of the PR has dug their heels in and refused to budge. Moreover, they’ve made this preposterous observation:

You are referring to your personal experience. That’s great, but not enough to prove the fact I’m afraid.

Further more, they took umbrage to my rhetorical question about how did this completely incorrect PR ever get through the vetting process.

And using sentences like “How did such an utterly invalid statement every pass the vetting process?” is a bit offensive of be honest.

No, offensive would be to say “This is total bull$hit.” It’s completely valid to question a vetting process that allowed the misinformation blatantly false information to pass.

It’s quite clear the author is more concerned about appearances than correcting falsehoods that are misleading the user community. I’ll be creating a PR to correct the documentation.

1 Like

Not that you needed my validation to tell you what you already know but as another point of data…

I just created a new automation using Notepad++ and upon reloading my automations the automation has defaulted to ‘on’ without specifying the “initial_state:” option.

- alias: New Test
  #initial_state: 'on'
  trigger:
    - platform: state
      entity_id:
        - switch.camping_room_light
        - switch.yard_sale_room_light
      to: 'on'
      for:
        minutes: 2
  action:
    - service: homeassistant.turn_off
      data_template:
        entity_id: "{{ trigger.entity_id }}"

ex

So that is another point of verification that the “default” state for an automation is “on”.

I know it used to be that way (default = on) before the change in the recording method and I thought that the default had been changed to “off” after that based on a few threads that I was involved in on the subject. Either I was wrongly convinced of that by those threads (likely…) or it has been changed back to “on” at some point since then.

This is such a ridiculously basic functionality to have so much confusion promulgated over.

1 Like

This.

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

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:

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.

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.

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

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

You got my seal.

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