Sorry, maybe I misunderstood the discussion. But anyway, if someone needs an answer to the title question “Once automation is triggered, can it be stopped?”, the link might help. I sometimes use “stop:” to terminate automations.
Can you explain how you terminate a running automation that contains the stop feature?
Use the example in the first post; the automation contains a 2-hour delay and, before it has finished its countdown, you want to terminate the automation.
If you have to do it using “delay” it might be difficult.
I have not tested the following, but I think it should work.
The automation waits for someone to come home or for two hours to pass.
mode: single
trigger:
- platform: state
entity_id:
- binary_sensor.someone_at_home
to: "off"
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id:
- binary_sensor.someone_at_home
to: "on"
timeout:
hours: 2
continue_on_timeout: true
- if:
- condition: state
entity_id: binary_sensor.someone_at_home
state: "on"
then:
- stop: ""
else:
- event: turn_off_power
event_data: {}
Ok… You won’t even need a stop in this case…
Sry, I just saw this approach is the same anon supposed above.
I see. Still…
The title question is: “Once automation is triggered, can it be terminated?”. I think stop can do this.
I would use stop if, for example, the automation would be much longer and/or would have multiple branches but has conditions under which further code should not be processed (as in the example above). “Stop” is in my opinion a way to keep the code clean. It can also be helpful for debugging, e.g. when analyzing the trace paths.
Often there are several ways to archive this. “Stop” is just another option.
You’re free to think whatever you want but you have yet to post an example proving how stop would solve the topic author’s problem. The reason you can’t is because it’s not the solution for this particular situation.
Personally I do not like automations with long delays in them because you cannot see what actions are pending. Also, however many changes are made to relieve this, they will not survive a HA restart.
The solution that is seldom mentioned: timers. You can set an option to restore a timer on restart. You can see if a timer is running so you know what actions are planned ahead and when. You can have conditions test if they are running. You can pause them, reset them to their original time or cancel them. You can also start them from more than one place.
I have a auto entities card showing me all running timers too, so I can see which events are scheduled ahead.
For scripts that run for a certain amount of time (although even a few minutes can be “too” long), you could query conditions (again) before executing the action. Then you do not necessarily have to cancel a running script, but make sure that it does not continue to run when it is no longer needed.
Just for the sake of completeness: I faced the same challenge of stopping a running automation; from within that very automation. I also wanted the automation to be self-contained (i.e. without a second automation just for stopping it), such that it can be distributed as a blueprint.
The (so far working) solution I came up with is as follows:
Set the automation mode: restart
Add a trigger event: stop_it
Add a first action to stop if triggered by the event
Fire the event as appropriate in the else branch
The restarted automation will kill the previous run. The stop action will make sure, the main script of the automation will not actually be restarted.
I know, it is quite involved. But the only idea I could come up with to achieve the requirements set out above. (Oh what a blessing it would be, if blueprints could actually create more than just a single automation. But that is another story…)