Then create a script have 2 automations to turn on/off the script based on your presence.
Actually this doesn’t stop current runs of the action section. I’ve considered adding an automation.stop service just for this reason.
This would be the current work around.
The only other time an automation’s action section will stop is when HA shutsdown.
4 Likes
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.
2 Likes
… Or just move the delay to the trigger instead of having it in the action.
trigger:
platform: state
entity_id: group.everyone
to: 'not_home'
for:
hours: 2
6 Likes
This is called the KISS principle
@qjiang888
I would ask to see the automation in question, but i think Marc has nailed it.
1 Like
FYI, see related Issue #38143 – Repeat automation in single mode still runs after reload.
EDIT: And PR #38174 – Stop automation runs when turned off or reloaded
EDIT 2: Change is now available in 0.113.2.
What about automation.stop service? I think it would be very useful.
2 Likes
No longer necessary because you can just turn the automation off and back on. That’s the same thing you would do to stop a running script.
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. 
3 Likes
Can you marked this topic solved, since the feature you requested has been implemented? E.g., go to this post and click: 
Thank you, this helped me a lot 
1 Like
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.
5 Likes
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.
But you can do this.
- alias: Stop Automation
mode: parallel
trigger:
- platform: event
event_type: stop_automation
condition:
- condition: template
value_template: >
{{ trigger.event.data.automation is defined states(trigger.event.data.automation) not in ['unknown', 'unavailable'] }}
action:
- service: automation.turn_off
target:
entity_id: "{{ trigger.event.data.automation }}"
- service: automation.turn_on
target:
entity_id: "{{ trigger.event.data.automation }}"
Then using this in your automation…
- event: stop_automation
event_data:
automation: "{{ this.entity_id }}"
6 Likes
Got it. Yeah, that’s true. Thank you.
I know I’m late…
But just in case someone is looking for a different (easy) solution:
Script Syntax - Home Assistant (home-assistant.io)
The stop feature you linked to serves a different purpose and doesn’t achieve what qjlang88 originally requested.