Automation on home assistant restart

Hi, I have and integration with a bug and while I wait for a fix I need and automation that every time I restart home assistant should trigger a switch.

That’s what I tried but do not work. If I try the automation manually the switch turn on but not when the system restart. There is another way to trigger and automation on HA restart.

Thanks in advance.

alias: Activar oscilación ventilador salón
description: >-
  Corrige el error de no haber icono oscilación en la tarjeta del ventilador del
  salón
trigger:
  - platform: homeassistant
    event: start
condition: []
action:
  - delay:
      hours: 0
      minutes: 2
      seconds: 0
      milliseconds: 0
  - service: switch.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: switch.ventilador_salon_horizontally_oscillating
mode: single

It looks OK, and the restart trigger is correct. I’m wondering if the 2 minute delay on the action is getting canceled by something during the startup - perhaps the automation isn’t quite loaded and it cancels out your delay. Have you tried making the action immediate at all?

What is shown in the automation’s trace?

I know that Milliseconds are supported in delay, but I always had a “bad feeling” using them.

Please try with this: delay: '00:02:00' and report back. :slight_smile:


Edit:

:warning: Please be aware

As @123 posted downwards, this isn’t a real solution to the problem!

Most likely it is something, that was resolved due to a restart/reload or something else. Unfortunately we don’t have an automation trace in this case, that could possibly solve the mystery.

Anyway, leaving out the milliseconds might solve the problem at hand, but it is not the solution, it’s more of a coincidence, that it worked for me and the OP!

Please read the post from Taras downwards to get a more detailed explanation!

Thank you! :slight_smile:

Yes, I added the waiting time because when it didn’t work I thought that maybe the automation was activated and the integration was not yet fully loaded

I’ ll try thank you

Finally working. Thank you always the more silly thing :sweat_smile:

1 Like

The following variations are all valid and functionally equivalent:

  - delay:
      hours: 0
      minutes: 2
      seconds: 0
      milliseconds: 0
  - delay: '00:02:00'
  - delay:
      minutes: 2

Changing it to

delay: '00:02:00'

is not a solution because it’s functionally equivalent to what you already had.

Whatever problem the automation experienced was not caused by how you originally configured the delay statement. Its trace is likely to provide clues about the root cause.

I tested your automation on my system and it worked perfectly on the first try. I restarted Home Assistant and 2 minutes later it turned on a switch.

alias: test delayed startup
trigger:
  - platform: homeassistant
    event: start
condition: []
action:
  - delay:
      hours: 0
      minutes: 2
      seconds: 0
      milliseconds: 0
  - service: switch.turn_on
    target:
      entity_id: switch.counter_light
mode: single

Here is its Trace Timeline shortly after Home Assistant restarted and shows it is waiting for the 2 minute delay to expire.
image

Here it is after completion. Note its runtime is 120.11 seconds (2 minutes).


To all others reading this topic, don’t be misled into believing the configuration of the delay statement, shown in the first post, is incorrect and/or responsible for the reported problem. It’s valid and works as advertised.

3 Likes

I agree, it was an apples-to-apples change, which means something else is at play. Maybe it’s another automation that is canceling the timer on this one or an integration that isn’t playing nice, but better to get to the root cause now rather than deal with this again later.

While what you state is true, I found that using millieconds in delays had not worked for me all the time. Since I’m avoiding them, I hadn’t had any problems in my automations.

That’s what my experience says, so now to what the documentation says, and what your examples show - it should work, but in some cases it doesn’t.

But you as well misunderstood the point - it’s leaving out the milliseconds and not how to write it. :slight_smile: Sorry, if that was confusing.

That’s why I suggested to leave out the milliseconds. Because this

- delay:
      hours: 0
      minutes: 2
      seconds: 0
      milliseconds: 0

is something different to your following examples, where you don’t set the milliseconds.

I do know, that how you write it isn’t a factor, or at least shouldn’t be. But that was not the point of my suggestion - it is leaving out the milliseconds!

A while ago I did some research in the code on that topic (led me nowhere, unfortunately), but if you take a look what is in the code
delay = delay_delta.total_seconds()
I wouldn’t be so sure, that milliseconds aren’t a factor! :slight_smile:

EDIT: to clarify, I didn’t follow that bit of code backwards, so total_seconds() could be something totally different, on what I assume it is, but it made me change my delays to a format without milliseconds. If someone wants to dig deeper, here’s the line, where I started: https://github.com/home-assistant/core/blob/e0b98551605ae3e1073068cd5cdebe4f3943b18d/homeassistant/helpers/script.py#L633

1 Like

The example automation I created specified zero milliseconds, just like the OP’s original example did, and it worked correctly on the first try. It’s an apples to apples comparison, demonstrating the presence of milliseconds: 0 has no bearing on the reported issue.

In fact, when you specify a delay action, using the Automation Editor in Visual mode, its YAML version is displayed exactly like in the OP’s example (i.e. includes milliseconds: 0). It’s normal.

All this to say that specifying a zero-value milliseconds option (or other time unit option) is perfectly valid and wasn’t responsible for the automation’s reported failure.

The automation’s trace may hold clues as to what was the root cause. For example, if no trace was produced on startup then that’s very telling (i.e. wasn’t triggered on startup). If a trace was produced then it was triggered on startup and the focus of our attention would be on the two actions.

I am; it’s a red herring.

Good you’re, I’m not, and my experience says otherwise. :slight_smile: If you find the cause, I’m happy to agree, until then, I’ll happily leave out milliseconds in my automations. :wink:

Feel free to “leave them out” but they’re a natural part of every delay statement created via Automation Editor and haven’t been causing a wide-spread problem for users of delay.

You have focused on milliseconds being suspect yet the OP said the automation works fine when triggered manually (i.e. the delay executed correctly). Therefore it’s not an action problem, it’s a triggering problem and the answer lies in the automation’s trace (presence or absence of it would be revealing).

FWIW, changing the automation’s code, if done via the Automation Editor, caused an automatic reload of that specific automation. That in itself may have cleared whatever cobwebs interfered with its triggering but I admit that’s speculation; the trace is needed to understand the root cause.

All this to say that milliseconds isn’t the culprit in this situation. However I am willing to retract that if you can demonstrate that the example I used (posted above) repeatedly fails to work on your system.

Because if it does fail then we need to dig deeper and understand why it works flawlessly on some systems but not others.

We’re running in circles here! :slight_smile: Let’s see, what the trace shows, and go from there. :slight_smile:

That’s why I immediately asked the OP for the trace. However, now that time has passed and at least one other trace has been produced, we will have to rely on the OP’s ability to find the trace produced when the problem occurred … assuming one was ever created because the absence of it would indicate a triggering problem. All this to say, the trail of clues is cold and getting colder.

Plus we overlooked to ask if any errors were logged but that’s moot now that the system has been restarted.