Automations with timer or delay

Configuration
21

The problem with this approach is that, as far as I can tell, you cannot stop this automation from interfering with the switch when you do not want it to. At startup, it either turns the switch on or off, regardless if an event has happened to warrant switch operation. If you also want manual operation, you need to manipulate the input helper to prevent it from undoing the manual switch.

Besides that, it is hard to read. You could compensate for the downsides, but that makes it even more complex.

A timer is simple, and when it isn’t running, it doesn’t interfere. That keeps automations clean, especially if there are multiple automations operating the same switch.

22

Your comment suggests you may not have understood its operating principle.

It’s a choose with two choices. The first choice controls the switch under normal conditions and the second one only when Home Assistant restarts.

The most complex part of it is the arithmetic it performs to set the input_datetime’s value (and it’s not all that complicated).

23

What did I not understand? You have a trigger at startup. That executes a choose that either turns the switch on or off. Even if that is a week after the time in your input helper, it will still perform an action. I think that it is not ok for a home assistant reboot to always operate switches. So maybe you do not understand me?

A timer will only execute if it was started before the reboot. This will always act, regardless what happened before the reboot. It needlessly repeats an action that has already happened in the past, and is maybe undoing something else alltogether, that has nothing to do with the automation at hand. It is an unwanted side effect i.m.o.

You wrote it, you understand, but I apparently misunderstood something. The fact that you need to explain to me it is right proves that it is complex.

24

I didn’t realize your experience level was the de facto measuring stick for complexity. :man_shrugging:

As for your commentary regarding perceived deficiencies, I haven’t encountered any in a year’s worth of real-world operations. I prefer my automations to be, on startup, very deterministic and fail-safe so, yes, I want scheduled critical devices to be explicitly set to on or off. Given that this application involves a bleach pump, I assumed rzulian would want the same behavior.

I encourage you, again, to apply your knowledge of timers and compose an automation for rzulian that employs it.

25

I’ve been a professional software developer for over 20 years, so it is not that I do not understand what it does. I know that if something is hard to read, it is prone to errors.

This is your preference and you are entitled to it. I expressed my preference, and explained why.

It is up to the person copying your code to decide to use it or not. But for those who do are not fluent in jinja2 I hope it is now clear that if you manually toggle the switch and reboot, HA will toggle it back.

26

Excellent, so you should have no difficulty supplying rzulian with a functional example, employing a timer, to control the bleach pump.

27

The answers to the questions are there, above your post.

28

Effectively this is solution 3 as proposed above. You can consolidate solution 1 into one automation in the same way like so:

alias: Piscina New Measurement Update
trigger:
- id: pool_new_measurement
  platform: event
  event_type: ifttt_webhook_received
  event_data:
    action: pool_new_measurement
- id: timer_finished
  platform: event
  event_type: timer.finished
  event_data:
    entity_id: timer.pompa_orp
condition: []
action:
  if: "{{ trigger.id == 'pool_new_measurement' }}"
  then:
    - service: switch.turn_on
      target:
        entity_id: switch.pompa_orp
    - service: timer.start
      data:
        entity_id: timer.pompa_orp
        duration: "{{ states('input_number.pompa_orp') | int(0) * 60 }}"
  else:
    service: switch.turn_off
    target:
      entity_id: switch.pompa_orp

Since the trigger platform is the same for both triggers now I used trigger IDs to separate but same idea.

This should be as resilient as what you are showing but using a timer instead. Because the way the new timers with restore work is if HA is restarting when the timer is supposed to finish then the timer.finished event fires on startup. So they both are able to handle HA restarts at any time without issue.

Although come to think of it neither can deal with an automation reload at exactly the wrong time. You might want to consider adding a trigger for the automation_reloaded event to cover that. The timer approach unfortunately doesn’t have a good way to handle an automation reload exactly when the timer is finishing. I didn’t think that through initially, if an automation reload causes this to miss the timer.finished trigger then it won’t get another chance.

29

It’s incomplete, contains syntax errors, some pseudo-code, and is needlessly split into two automations. Anyway, CentralCommand has already stepped up with a good example.

Good point. I haven’t found the need for it (yet) in my own automations because the duration of Reload Automations is so brief (relative to a restart). Nevertheless, you’re right; for full protection it should trigger on that event as well.

I think a timer might also be susceptible to a Reload Timers that occurs precisely at a timer event (like finished). It’s a narrow window of opportunity for failure but, just like for automation_reloaded, there’s no obvious way to mitigate it for timers.

Dear Reader,

Just to clarify, I am not opposed to employing a timer. The fact is that I used timers extensively in Premise (home automation software I used for over a decade prior to Home Assistant). However, historically, Home Assistant’s timer could not survive a restart (unless you implemented a workaround like this one).

The ability to restore a previously active/paused timer on restart was introduced as a native feature very recently (April 2022) Before that, a restart would cancel an active/paused timer thereby making it unsuitable for time-critical applications. Necessity is the mother of invention and so the job was handled by an input_datetime (and a little bit of date arithmetic).

Now that a timer can be configured to survive a restart, it becomes a viable means of handling time-critical applications. The caveat is that it still has one or two chinks in its armor (reload events) that have the potential to negatively impact it. In fairness, for most applications the odds are small but one should be aware they exist when designing a failure-resistant automation.

FWIW, most of my time-critical applications use the input_datetime technique but a few use a timer (wherever I need to see a countdown in the UI) with the workaround mentioned above (I have yet to convert to using the new native method of restoring timers). It’s good to have choices.