What happens with long automation if HA restarts?

Hello, I have automations with long wait timeouts, like for hours. What happens if the HA server reboots in the meantime? Does the automation get killed, or will it continue where it was waiting before restart?

Yes.

You can get around this by instead of waiting setting a input_datetime with the end time and trigger on this.

Would not work for me - in automation I need to run one event, wait for some hours, run next event, wait for exact time, run event etc… So times are relative not absolute.

So in what way is a delay of 2 hours more relative than setting an input_datetime with now() + 2 hours?

Thanks I did not know it was that easy! Can you please help me with yaml example? I am always getting lost in quotes, barckets etc…

As action something like:

service: input_datetime.set_datetime
target:
  entity_id: input_datetime.next_event_of_automation
data:
  timestamp: {{ now().timestamp() + 3600 }}

This should set the helper with one hour from now.

Then you create an automation that triggers when this time has passed.

OK, so let me know if I understand this correctly please. I have 4 different events in time (the trigger, then after 3 hours, then after 10 minutes etc.). According to your guide, I will create one scheduling automation, that is triggered by the same event as before, but instead toher events and wait times, I will put 3 scheduling events that will run immediately after the trigger and this automation will immediately end, right?

Then I will create three other automations, that have empty trigger, but will be scheduled by MAIN automation from previous paragraph. These automation will run at scheduled time and will survive reboots, right?

Thanks a lot, Jan

As always, it’s better to post what you have and we can help you much easier.

But yes, if I understand you correctly the first automation sets an input_datetime with the time the next event should occur.
The second automation triggers on the input_datetime and sets the input_datetime to the next time, and so on.

If the first automation sets all times then one action could be skipped if the duration of an event is to small or the restart is slow.

FWIW, I use two different methods for ensuring a time delay survives a restart:

  1. The one Hellis81 described (future-dating an input_datetime used by a Time Trigger).

  2. Timers that survive restarts using this system.

The method I use depends on whichever one is easier to implement for a given application.

Sorry but I cannot get it working. First automation that should be scheduled is:

alias: run_timed_test
description: ''
trigger: []
condition: []
action:
  - service: mqtt.publish
    data:
      topic: shell
      payload: timer-test
mode: single

this one I could create

Second automation that should schedule the first one is like this and I am not able to save it because malformed not valid number:

alias: schedule_timed_test
description: ''
mode: single
trigger: []
condition: []
action:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.automation.run_timed_test
    data: 
      timestamp: {{ now().timestamp() + 60 }}

Can you help please? I did it as you instructed, or not?

You have no trigger.

I trigger manually so I do not need it right? There is other problem, I can save now, but the timestamp: is not saved and is replaced by empty data. The saved result looks like this:

alias: schedule_timed_test
description: ''
trigger: []
condition: []
action:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.run_timed_test
    data: {}
mode: single

and automation throws an error:
Stopped because an error was encountered at 21. listopadu 2021 17:21:20 (runtime: 0.01 seconds)

expected float for dictionary value @ data[‘timestamp’]

An automation needs a trigger. That is the point of an automation.
If you want to trigger manually, that is a script

I am just testing. The automation that is scheduled has not trigger either or what it should be? After I am able to schedule first automation by the second, I will add trigger to the second. I think the problem I need to solve is why timestamp is not saved.

I have no problems saving the automation with a trigger and a input datetime that exists.


But I haven’t tested it since I don’t want to mess with my entities, and I don’t want to create a new entity just for this.

Thanks for help, there must be something wrong, because I even cannot run this service manually. There is error that some value is expected float The run_timed_test is name of automation entity without automation.:

service: input_datetime.set_datetime
target:
  entity_id: input_datetime.run_timed_test
data:
  timestamp: {{ now().timestamp() + 60 }}

got it running. The timestamp must be in quotes.

got it running. The timestamp must be in quotes. But now the other problem. The first automation that should get scheduled does not run… I copy both automations again here:

Scheduled one (not running):

alias: run_timed_test
description: ''
trigger: []
condition: []
action:
  - service: mqtt.publish
    data:
      topic: shell
      payload: timer-test
mode: single

Scheduling one (not scheduling):

alias: schedule_timed_test
description: ''
trigger: []
condition: []
action:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.run_timed_test
    data:
      timestamp: '{{ now().timestamp() + 60 }}'
mode: single

any advice?

You need to trigger on the time or when the time has passed.
I suggest the latter since when the time is could be during a restart.

trigger:
  - platform: time
    at: input_datetime.run_timed_test
  - platform: template
    value_template: >-
      {{ as_timestamp(states('input_datetime.run_timed_test')) >
      now().timestamp() }}

I have modified the code as you advise but is is still not running:

alias: run_timed_test
description: ''
trigger:
  - platform: template
    value_template: >-
      {{ as_timestamp(states('input_datetime.run_timed_test')) >
      now().timestamp() }}
condition: []
action:
  - service: mqtt.publish
    data:
      topic: shell
      payload: timer-test
mode: single