Core: Automations fire on hass startup

[cmsimike]

Home Assistant release (hass --version):
.40.2

Python release (python3 --version):
3.5.2

Component/platform:
Automation

Description of problem:
Ever since upgrading to .40, the automations that are hooked up to fire when events happen (for instance, I arrive home and or gf arrives at job). This was never the case before.

Expected:
Hmm - not sure if this is a bug or just an unexpected change, or there is something I'm doing wrong, but I wouldn't expect these automations to fire on startup of hass.

Additional info:

If there is anything I can provide, please let me know

[Danielhiversen]

Are your automations triggered by a change in input_boolean, input_slider or input_select components?
From 0.40 the state of the these components are restored on start up and that will trigger connected automations. It might be other components that also are restored during start up.

[ttrushin]

I am experiencing the same behavior. If you have any device_tracker-based automations, those fire too...

[Danielhiversen]

Seems that the state is restored for device_trackers too: https://github.com/home-assistant/home-assistant/blob/2650c73a899bf867a23972031de7c4ddea6fb8c2/homeassistant/components/device_tracker/__init__.py#L582

[cmsimike]

The automations that fire for meinclude device trackers within zones and various input selects

[tyler-public]

I am having this issue as well, specifically for automations that involve device_tracker entities

Here is an example:

- alias: "Device Status"
  initial_state: 'off'
  trigger:
    platform: state
    entity_id:
      - device_tracker.huehub
      - device_tracker.ir2ip
      - device_tracker.odin
      - device_tracker.router
  action:
    service: notify.pushbullet
    data_template:
      title: "Jarvis"
      target: "device/phone"
      message: "{{ trigger.to_state.attributes.friendly_name }} is now {{ trigger.to_state.state }}"

This automation is turned on immediately after boot, despite having an initial state key being set to off.

Traditionally the state of this automation is changed to "on" 5 minutes after HA boots up. I think that since the state of the automation is on when HA turns off, it gets restored to "on" upon next boot up, and doesn't obey the initial_state key.

On top of that since the automation deals with any time those device_trackers change state, I get a bunch of notifications when their state is restored upon boot. This was originally solved by staggering the turning on of the automation by a few minutes.

Here is a warning I got in the log after restarting the home-assistant.service using systemctl:

17-03-23 13:37:28 WARNING (Recorder) [homeassistant.components.recorder] Ended unfinished session (id=11 from 2017-03-23 17:33:01.270586)

Could it be possible that recorder doesn't record the device state in time before shutting down, causing the restore state functionality to get out of sync or corrupt?

[tyler-public]

Doing some testing I was able to find a workaround (and verify the issue) by deleting the home-assistant_v2.db and exluding the automation/device_tracker entities from recorder (preventing the state store/restore)

[Danielhiversen]

@pvizeli is there any way that we can make the restore state functionality to not trigger any automation?

I have a similar problem where an automation is triggered when an input_slider is changed, the restore state make this automation trigger each time I start HA.

[pvizeli]

The restore do not change things. Before it would be init with None and now we init with old state. So it will be write once to state machine.

For device tracker. It is the same. On end of the bootstrap is a device is tracked on and not seen from a tracker it will be write with old state to device tracker instead 'not home'.

I think it is the new bootstrap they change it. Mabye we need a flag on automation to disable trigger on startup? @balloob

[balloob]

Yes, I think it would be a good idea to only start listening for automations on HOMEASSISTANT_START.

[Danielhiversen]

Yes, I think that would be a good idea.

[pvizeli]

Okay, I make a fix for 0.41

[cmsimike]

Thank you!