For such long delays I personally prefer to use a input_datetime as the trigger for the delayed action, and set the value of the input_datetime to “two hours from now” by the initial automation.
That will ensure that the delayed action will survive restarts of HA, and keep scripts and automations from hanging around waiting for a timeout.
Until the latest fixes regarding parallel and queued running of scripts and automations it was also a better way to handle exactly the kind of issues you face here.
Just ensure that you set the input_datetime to some time in the past when you get home, and that ensures that the “two hours later” automation is never triggered.
The use case is as follows:
you have two automations. one that you call when you want to start a movie session and one that you call when you end a movie session.
The first one closes the blinds, dims the lights and unfolds the projector screen.
The second is doing the opposite but in reverse order.
If I want to cancel the first one during the run I should call stop from the second (in the first step).
But according to your description, it is doable. I should just call automation.turn_off and that should do the job.
This will apply to all automations with delays that have actions in a specific order. If you want to roll back the changes you must stop the first action as the first step in the second. (hope this description makes sense )
I’m waiting for the equipment and will try the suggested service (automation.turn_off).
What you’re describing sounds more like scripts than automations. Scripts are “called”, whereas automations are “triggered.” More than just semantics, an automation has triggers whereas scripts do not. Automations, although they can be manually triggered (like a “call”), are really designed to run automatically when certain events occur, whereas scripts need to be called to run.
So, yes, if you have two (automations or scripts) for this scenario, it would definitely make sense that the first thing either does is to stop the other. For scripts that would be simply script.turn_off. But for automations, that would require two steps: automation.turn_off followed by automation.turn_on. Why the difference? Well, for scripts the turn off service just stops running scripts. But for automations, it also disables the triggers, so you have to turn them back on to get the triggers re-enabled.
An alternative is to have one script or automation that is configured in restart mode, which does one or the other set of actions based on how it was called or triggered. The mode will take care of stopping what it was doing for you.
Not sure why, but when I try to cancel a running automation it keeps running. It’s an automation running in restart mode with a 30min wait_template in it.
Tried stop-start the automation, reloading the automation config and even restarting HA. There seems no way to stop it in version 2021.6.2.
Let’s take the scenario where you have two automations:
Automation A: which can take some time to execute (eg. turning on devices in a particular order with a delay between each)
Automation B: which should terminate automation A before running it’s own actions (eg. turning off all devices immediately)
One of the main advice here seems to be to use automation.turn_off (which stops the executing automation and disables it’s triggers) followed by automation.turn_on (which re-enables the triggers again).
This seems to be a horrible workaround.
What if Automation A was already disabled manually by the user?
At that point Automation B will incorrectly enable Automation A again.
Why not just have an automation.stop command?
This would solve a lot of problems.
We should not be forced to use a script unless we actually want to use a script.
Turning the Automation Off and On does not work if you want to Stop the current runs of the self automation itself. That’s because when it calls Turn Off, it will stop itself and never call Turn On again.
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.