Automation using delay and reboots

I have this simple automation setup to turn on a fan at 8:30pm, let it run for 5 hours, then turn it off. I am using the “delay” action to accomplish this. This works without issue but I am afraid there is a limitation.

What happens if my HA machine reboots at 9:30pm, will my fan still turn off at 1:30am?

This is one of my first automation :slight_smile:

alias: Fan_Timer
  description: Turn ON/OFF fan
  trigger:
  - at: '20:30:00'
    platform: time
  condition: []
  action:
  - data:
      entity_id: switch.03200168dc4f22847b44
    service: switch.turn_on
  - delay: '5:00:00'
  - data:
      entity_id: switch.03200168dc4f22847b44
    service: switch.turn_off

Is there a more robust way of writing this automation tasks?

I want to avoid creating two separate automatons for ON and another for OFF at specific times.

No.

Yes, write two automations. :slight_smile:

You can write this in one automation with multiple triggers and a service_template in the action, and it would also be best to add a homeassistant start trigger to make sure the switch is on or off as appropriate when HA does start (in case it was not running when one of the two times happened.)

Thx.

Would you (or anyone else) take my simple example and show how to use the service_template
and homeassistant start to make this more robust?

Thank and appreciate the help.

It’s quite a bit of code to get there.

In short, your first automation should look like the one you have above, up to, but not including, the delay. Next (instead of the delay) you want to write the time 5 hours from now into an input_datetime.

Then make a second automation with a “time_pattern” trigger and a condition to check that the current time is equal to the time you set in the input_datetime. This automation should turn off the fan and also empty the input_datetime so it’s ready for the next round.

Then again, since you’re always starting this at exactly 20:30:00, you’ll always be turning it off at exactly 01:30:00. So you could just write an automation that triggers at 01:30:00 and not mess with the input_datetime. The input_datetime is more useful in cases when you don’t know exactly when it’s going to start (like, turn on a fan when humidity is high and turn it off an hour later type scenarios).

alias: Fan_Timer
  description: Turn ON/OFF fan
  trigger:
  - at: '20:30:00'
    platform: time
  - at: '01:30:00'
    platform: time
  - platform: homeassistant
    event: start
  condition: []
  action:
  - data:
      entity_id: switch.03200168dc4f22847b44
    service_template: >
      {% set n = now() %}
      {% if n.hour >= 21 or n.hour == 20 and n.minute >= 30 or
            n.hour < 1 or n.hour == 1 and n.minute < 30 %}
        switch.turn_on
      {% else %}
        switch.turn_off
      {% endif %}

Does your “switch” retain it’s state through a restart ?
Do your fans ALWAYS switch on at this time and off at that time ?
Just set two automations for those times

Need to adjust ? Well get the times from inpt_datetimes without an initial value set (HA will remember any adjustments through restarts)

Having said all that … Phil’s solution is very elegant :angry: :rofl:

It’s possible, even if the switch retains its state, and HA sees that when it restarts, if HA was not running when one of the time-based events was supposed to happen that the switch will be in the wrong state when HA (re)starts. That’s the point of the homeassistant start trigger. I use this technique for many of my automations to make sure everything is in the correct state when HA starts.

:smiley: It’s not a contest. haha!

Maybe not for you :rofl: (just kidding)

I generally now subscribe to Petro’s view of making regular automations as transparent as possible (cept I trust my users more).
For a switch with a use like this (it’s actually halfway between one of my speaker switches (goes off when I leave the house but remembers whether it was switched on manually, switched on manually with a timer, automated on in time slot 1 or ditto with time slot 2) - And a normal switch (same as above but doesn’t switch off when I leave and therefore doesn’t need to remember).
BUT … I’d use a binary sensor here to look at the two time values (or more if there’s two or a manual option) this would be true if required on. And the automation just follows the binary sensor.
Saves all those is it/isn’t it and what happens at reboot questions.
This way the sensor time only evaluates the sensor rather than the 4 time values and the delay expiry for the manual timer. (a more difficult calc but surely less overhead than 5 different comparisons ???
‘May’ have been something else but my CPU usage halved (4% to 2%) when I implemented this.

Thanks everyone. Great advice & excellent solution.