@tom_l Isn’t the restore option for a timer covering the use case? If you start a timer and after that you restart HA, if HA restarts after the planned finish time, it fires a timer.finished. Otherwise it will reactivate the timer.
So, if you have a not critical need, like a light, you can use a timer.
But if you are managing something critical (eg. you are running a pump to add bleach to your pool), you cannot rely on a timer restore.
Honestly I haven’t looked at timers for a while. Do they restore after a restart now?
For a non critical application (i.e. you don’t mind if the off automation is missed) the easiest way would just be a delay in the automation. That definitely will be interrupted by a restart but if it is not critical that does not matter 
It’s relatively easy to store a fixed or variable time offset to be used in another time trigger, e.g
The off trigger is simple:
trigger:
platform: time
at: input_datetime.lounge_dehumidifier_stop_time
To set this to a fixed delay from now:
action:
- service: input_datetime.set_datetime
data:
datetime: "{{ now() + timedelta(hours=4) }}" # 4 hours from now
target:
entity_id: input_datetime.lounge_dehumidifier_stop_time # the entity used in the off time trigger
Of if you want to set the delay from a dashboard, use an input_number to hold the delay:
- service: input_datetime.set_datetime
data:
datetime: "{{ now() + timedelta(hours=states('input_number.lounge_dehumidifier_run_time')|int(1)) }}"
target:
entity_id: input_datetime.lounge_dehumidifier_stop_time
Yes, but they’re meant to serve as examples of the technique where delays and timers are replaced by methods that aren’t affected by restarting/reloading. FWIW, all of my time-based automation use the described technique and are unaffected by restarts/reloads. The calculated stop time I had mentioned is essentially what you demonstrated in your post.
If rzulian can provide a concrete example of an application (as opposed to pseudo-code), I can demonstrate how to adapt it to use the technique I described.
Yes (optionally); it was added recently although I haven’t experimented with it yet (because I converted most of my automations away from using timers and the few I still have are restored using the scripts I developed a long time ago). Eventually I’ll get around to it.
I guess the upshot is if the application is truly non-critical then it means it doesn’t matter if it uses a delay that is not given the opportunity to complete. For my purposes, anything that shouldn’t be left indefinitely in the wrong state is “critical” and doesn’t employ a delay.
Below a critical automation that is executed by another automation.
- alias: bleach_inject
id: "1559149426435"
initial_state: true
trigger: []
condition: []
action:
- entity_id: switch.pompa_orp
service: switch.turn_on
- data_template:
message: "{{now().strftime('%H:%M')}}[{{now().day}}/{{now().month}}]"
title: "Bleach injection: ({{states('input_number.bleach_inject')}} ml)!!!"
service: notify.SERVIZIO
- delay: "{{ [0 , 60 * states('input_number.bleach_inject')|float/ states('input_number.bleach_speed')|float ]|max|int }}"
- entity_id: switch.pompa_orp
service: switch.turn_off
- service: input_number.set_value
data_template:
entity_id: input_number.bleach_inject
value: 0
- data_template:
message: "{{now().strftime('%H:%M')}}[{{now().day}}/{{now().month}}]"
title: "Bleach injection end!!!"
service: notify.SERVIZIO
@tom_l Thank you for your examples!
Ok, for a start that is not how you are supposed to use automations (manually triggering them from other automations). That should be a script (a script is an automation without a trigger) that your other automation can call.
The way you are doing it will work, it’s just not best practice.
So ignoring the delay issue for the moment. You would write it like this:
script:
bleach_inject:
sequence:
- entity_id: switch.pompa_orp
service: switch.turn_on
- data_template:
message: "{{now().strftime('%H:%M')}}[{{now().day}}/{{now().month}}]"
title: "Bleach injection: ({{states('input_number.bleach_inject')}} ml)!!!"
service: notify.SERVIZIO
- delay: "{{ [0 , 60 * states('input_number.bleach_inject')|float/ states('input_number.bleach_speed')|float ]|max|int }}"
- entity_id: switch.pompa_orp
service: switch.turn_off
- service: input_number.set_value
data_template:
entity_id: input_number.bleach_inject
value: 0
- data_template:
message: "{{now().strftime('%H:%M')}}[{{now().day}}/{{now().month}}]"
title: "Bleach injection end!!!"
service: notify.SERVIZIO
And you would call it like this:
action:
- service: script.bleach_inject
Or like this:
action:
- service: script.turn_on
target:
entity_id: script.bleach_inject
The first example waits for the script to complete before moving to the next action. The second version runs the script in parallel with the next action, see https://www.home-assistant.io/integrations/script/#waiting-for-script-to-complete
For when you do it works great! I have a few timers I was using in places and my own custom restore state automation that handles all the things that I wish had restore capability (timers, trigger template entities, custom device trackers and alerts). After that update I removed timers from the list and used the native restore then fully tested it and found no issues.
Of note it is a little different then your logic (assuming that’s still accurate for your setup). If the timer finished while HA was shut down then it fires the timer.finished event on startup anyway.
As explained by tom_l, that’s not really an automation (it has no trigger). Post the other automation.
I’ve added the trigger that is starting the automation
- alias: Piscina New Measurement Update
trigger:
platform: event
event_type: ifttt_webhook_received
event_data:
action: pool_new_measurement
condition: []
action:
- entity_id: switch.pompa_orp
service: switch.turn_on
- data_template:
message: "{{now().strftime('%H:%M')}}[{{now().day}}/{{now().month}}]"
title: "Bleach injection: ({{states('input_number.bleach_inject')}} ml)!!!"
service: notify.SERVIZIO
- delay: "{{ [0 , 60 * states('input_number.bleach_inject')|float/ states('input_number.bleach_speed')|float ]|max|int }}"
- entity_id: switch.pompa_orp
service: switch.turn_off
- service: input_number.set_value
data_template:
entity_id: input_number.bleach_inject
value: 0
- data_template:
message: "{{now().strftime('%H:%M')}}[{{now().day}}/{{now().month}}]"
title: "Bleach injection end!!!"
service: notify.SERVIZIOYour modified automation doesn’t specify a mode so that means it uses the default and runs in single mode. Is that correct or does it actually have mode set to something else like restart or queued?
It’s correct, it runs in single mode
The reason I prefer timers for longer delays is:
Given that you are a proponent of timers, perhaps you can help rzulian modify the automation to employ a timer.
To recap.
Solution 1
using a timer with restore: true
alias: automation_using_timer
trigger: your_trigger
condition: []
action:
- entity_id: my_entity
service: switch.turn_on
- service: timer.start
data:
duration: "{{ 60 * states('input_number.minutes')|int }}"
target:
entity_id: timer.my_timer
initial_state: true
mode: single
alias: my_timer_finished
trigger:
- platform: event
event_type: timer.finished
event_data:
entity_id: timer.my_timer
condition: []
action:
- service: switch.turn_off
target:
entity_id: my_entity
mode: single
Solution 2
using an automation with a delay and , if needed for critical entities, an automation to manage the HA restart and automation reload.
alias: automation_using_delay
trigger: your_trigger
condition: []
action:
- entity_id: my_entity
service: switch.turn_on
- delay: "{{ 60 * states('input_number.minutes')|int }}"
- entity_id: my_entity
service: switch.turn_off
initial_state: true
mode: single
alias: automation_for_critical_entities
trigger:
- platform: homeassistant
event: shutdown
id: HA restart
- platform: event
event_type: automation_reloaded
id: Automation reload
condition: []
action:
- entity_id: my_entity
service: switch.turn_off
initial_state: true
mode: single
Solution 3
similar to solution 1 but setting a input_datetime to store when the second automation have to trigger.
I’m not sure what happens if a restart or reload occurs during the my_stop_time. Does the trigger run after the restart?
alias: automation_using_input_datetime
trigger: your_trigger
condition: []
action:
- entity_id: my_entity
service: switch.turn_on
- service: input_datetime.set_datetime
data:
datetime: "{{ now() + timedelta(minutes= states('input_number.minutes')) }}"
target:
entity_id: input_datetime.my_stop_time
initial_state: true
mode: single
alias: my_stop_time
trigger:
platform: time
at: input_datetime.my_stop_time
condition: []
action:
- service: switch.turn_off
target:
entity_id: my_entity
mode: single
Solution 1 - This looks good. Should work and be restart/reload proof
Solution 2 - I mean it works but your switch may shut off early. If you restart HA it’ll immediately shut off your switch. So if input_number.minutes is set to 120 and it turned off 30 seconds after you turned it on because you happened to restart HA I’d consider that a bug.
Solution 3 - This is a slightly less resilient version of the timer. For the most part it works just as well unless HA happens to be restarting or automations reloading at exactly the time set to input_datetime.my_stop_time. Which admittedly is pretty unlikely, its not a huge flaw. But there’s really no advantage to it over Solution 1: both require two automations, both require an extra helper. The only difference is Solution 1 is completely restart/reload proof whereas this one is 99% restart/reload proof. Therefore I don’t know why someone would pick this over Solution 1.
Another option for the turn off automation is to use a time pattern trigger (/5, /10, /15 minutes as desired), and then a state condition (not a trigger) to check and see if the pump has been on for more than 30(or whatever) minutes.
It removes the need for any helpers. It won’t be as precise, and may not fit if you want xx minutes and not approximately xx minutes.
The pump may run for a full xx minutes after a restart, but will shut off and not run all day.
It may not be appropriate for this use case if there are non-automated times the pump should be running more than xx minutes at a time.
The following single automation:
input_datetime.pompa_orp
on duration is controlled by input_number.pompa_orp
alias: Piscina New Measurement Update
trigger:
- platform: event
event_type: ifttt_webhook_received
event_data:
action: pool_new_measurement
- platform: time
at: input_datetime.pompa_orp
- platform: homeassistant
event: start
condition: []
action:
- variables:
switch: switch.pompa_orp
- choose:
- conditions: "{{ trigger.platform in ['event', 'time'] }}"
sequence:
- service: "switch.turn_{{ iif(trigger.platform == 'event', 'on', 'off') }}"
target:
entity_id: '{{ switch }}'
- service: input_datetime.set_datetime
target:
entity_id: input_datetime.pompa_orp
data:
timestamp: "{{ (now() + timedelta(minutes = states('input_number.pompa_orp')|int(0) * iif(trigger.platform == 'event', 1, -1))).timestamp() }}"
- conditions: "{{ trigger.platform == 'homeassistant' }}"
sequence:
- service: "switch.turn_{{ 'on' if now() < states('input_datetime.pompa_orp') | as_datetime else 'off' }}"
target:
entity_id: '{{ switch }}'
default: []
It’s based on the same principle I have used, for a over a year, for all of my scheduled automations to ensure they aren’t affected by restarts. A Time Trigger is controlled by an input_datetime that is dynamically set to a time in the future representing when the device should be turned off. The automation is also triggered by a restart and then determines if the device should be turned on or off.
Correct typos.
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.
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).
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.
I didn’t realize your experience level was the de facto measuring stick for complexity. 
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.