Automation not correct, <strike>and killing Hassio at startup

Installation Home Assistant OS
1

Hi,

my input_selects use restore_state at startup fine. This is an automation I have to use for setting several details in dev-mode at startup, when left in startup before reboot, since the settings are only applied when actually set and aren’t restored_state.

  - alias: 'set Dev Mode at startup'
    id: 'set Dev Mode at startup'
    initial_state: 'on'
    trigger:
      platform: homeassistant
      event: start
    condition:
      condition: template
      value_template: >
        {{ is_state('input_select.mode', 'Developer') }}
    action:
      - service: script.dev_on
      - service: notify.notify
        data:
          message: >
            Dev mode is on at startup

However, the automation’s condition doesnt work correctly, since it also runs when {{ is_state(‘input_select.mode’, ‘Developer’) }} isnt True at startup, setting the dev-mode anyways, and notifying the message.

Somehow the state of the input_select isnt read (correctly), or at all at startup i guess. Maybe it isnt restored yet before it is read?

How can i prevent this from happening, and even better, correct the automation please?

btw, is a small automation like this capable of killing Hassio? Somehow it keeps failing to initialize, but refuses to indicate why…whish Hassio error logging would start to be somewhat more conclusive to the why’s and what’s

Thanks,
Marius

2

Did you create this automation from the panel or write it straight into yaml?

3

you’re referring to the Hassio automation editor https://hassio.local/config/automation? No, I’ve never used that, write the automations myself in Yaml indeed.
The issue seems to have disappeared though, no more auto-dev-modes at startup…
maybe it was an issue of the system having entered a loop of timing errors created by another issue.

4

Sounds like the issue I’m seeing with the hassio component think this is resolved with 0.72.1

5

@petro
please have a look at the automation i started this thread with.

Though my previously mentioned reason has resolved somehow, no more automatic developer-mode setting at startup, I suspect to hav another issue with this automation.

As you can see, it reads the state of the input_select.mode and checks if that is set to Developer. If so it needs to run a script. Which is does.

The thing is, if the the input_select.mode is set to another option, it appears to bug the system at startup and prevents Hassio from connecting and initializing at startup. Could that be?

If so, how could I add an ‘else’ in this automation so it runs fine, even when not in input_select.mode = Developer ? Or should I add another condition maybe?
As discussed elsewhere, do i need a ‘Null’ here too?

Ive had issues with automations with:

trigger:
  platform: homeassistant
  event: start

before, and they all had templates in them. removing these took care of the errors. This one is the only one left, but I really need it…

6

I don’t think there is a way to make it properly choose dev mode from your input if the input hasn’t been set up. That would be a fix to the system. Startup should fire after everything is set up anyways, so this issue should never actually occur. @jimpower what PR has the bug you are talking about?

7

When I first started using HA I noticed that the homeassistant start event seemed to happen too soon. I analyzed the home-assistant.log to see when it came relative to other things (like restoring states from the recorder) and decided I would need a delay. So this is what I use:

automation:
  - alias: Delayed Startup
    trigger:
      platform: homeassistant
      event: start
    action:
      - delay: 00:00:15
      - event: DELAYED_HOMEASSISTANT_START

Then in automations I want to run “at startup” I use this new event instead, like this:

automation:
  - alias: Do something at startup
    trigger:
      platform: event
      event_type: DELAYED_HOMEASSISTANT_START
    condition:
      condition: template
      value_template: >
        {{ is_state('input_select.mode', 'Developer') }}
    action:
      <your_actions_here>

If you only had one thing you wanted to do, then you could combine them like this:

automation:
  - alias: Do something at startup
    trigger:
      platform: homeassistant
      event: start
    action:
      - delay: 00:00:15
      - condition: template
        value_template: >
          {{ is_state('input_select.mode', 'Developer') }}
      <your_actions_here>
2 Likes
8

btw, the killing of the Hassio bit of this thread is solved.

turned out trusting discovery: to find Hassio was too uncertain. With even the smallest of errors or unknown other issues (maybe time-outs, disconnections (on Hue eg)) Hassio would fail to get connected.

By coincidence read another post on the discovery: component where disabling that would require hassio: to be explicitly configured in configuration.yaml.

Wish I had known that before… It has never been so stable and responsive. It might be imagination taking the better of me, but I really feel the whole system benefits from this simple addition to configuration.yaml.

Hassio has come up with even quite complex misconfigured test settings. My lights and switches are very responsive. As if disabling the discovery: component frees a lot of system resources. Prove of that is this:

32 which I hadn’t seen going under the high 20’s since forever.

So, to get back here: no more fear for incorrect automations, Hassio seems to be here to stay!

btw how does one strike a thread title in this editor?