Better way to stop running Automation from another Automation

Configuration
1

I need to stop running Automation form another Automation.

I see there are “Automation: Turn off” and “Automation: Turn on” blocks to enable and disable automation. You can use them together like this:

  - action: automation.turn_off
    metadata: {}
    target:
      entity_id: automation.[]
    data:
      stop_actions: true
  - action: automation.turn_on
    metadata: {}
    target:
      entity_id: automation.[]
    data: {}

It works, but feels wrong because I don’t want to disable Automation, I just need to stop it.

“Automation: Turn off” has Stops currently running actions toggle, but I can’t use it separately.

Is there a way to solve this?

found similar feature request Automation stop running instances

2

If you have to… move the actions from the first automation to a script and have the automation call the script. Then the second automation can use the script.turn_off action.

Though, I would suggest reevaluating what you are actually trying accomplish… post your automation(s) config with a clear explanation of your goals and someone here will likely be able to help.

1 Like
3

Don’t design automations that control other automations; it’s an anti-pattern.

2 Likes
4

Not sure if it would work if I move actions to the script. But will try, thanks.

5

Well, I haven’t found a better solution. One Automation affects the other Automation.
At least we have “Automation: Turn off” as workaround.

6

Only because you designed it to work that way.

If you want one automation to influence the behavior of another automation, use a helper to act as a intermediary. As a basic example, one automation sets the state of an Input Boolean and the other automation checks the Input Boolean’s state (for on).

7

WTH? I swear I responded here asking you to show us the automations in question so that we could see why you feel you need to stop them.

8

I saw :innocent:
I posted to Feature request thread also…

9

@HappyCadaver

Here are 2 automations:

  1. The core Automation that lower music player volume when Assist is triggered and set it back to initial volume (using variable) when Assist state became idle

  2. 2nd Automation that sets volume when I say “set volume 20%”.

You see that both automations are running at the same time and 2nd one would fail because 1st one would set initial volume back every time. :slightly_smiling_face:

10

Your decision to separate volume control into two separate automations is proving itself to be problematic. Each handles a specific case of volume control but together they conflict.

I suggest you consider designing a single automation containing logic that handles all cases of volume control.

11

Exactly!

I was thinking about it. Haven’t figured out how to do it :thinking:

12

I think you might be looking at multiple triggers and trigger id’s for a single automation at this point, and using the choose script syntax.

1 Like
13

I already used multiple triggers id’s in some other automation. I give it a try, thanks!

Will it work for -trigger: conversation and - trigger: state as I need to use both?

And I also have And if condition but for - trigger: state only…
Looks like I can.

Let’s say I have everything in a single automation, how do you prevent state trigger (that is running every time) to set volume in the end?

14

I just tried it and it works. I think I like this solution more than turn off and on automation method. Thanks!

1 Like
15

Hi, good that it got solved!

Also: please take the time to mark the post that holds the solution.
You do that by selecting the three dots under the post:

image

Then select the check box:

image
By doing so:

  • this thread can be useful to other users as well (this thread comes up as solution when starting a thread which is similar to yours).
  • this prevents that someone else steps in trying to help

Thanks for giving back to the community! :+1:

16

done!

I hope that this feature request will be implemented - Automation stop running instances

17

Be advised that Feature Requests are now (as of June 2025) logged in Github, where developers are more likely to see them.

The Feature Request section in this forum is deprecated and its existing requests are effectively moot (of historical interest but no longer active).

18

I have a question then.

  • I have an automation to turn off all the lights when I leave my house.
  • I also have another automation to tell a bunch of different light in different rooms to go on and/or off based on time of the day & sunrise/sunset.
  • So I thought, OK, if I leave the house, shouldn’t I tell the 2nd automation to not bothering turning the light on or off…?

So, if we cannot tell automation #2 to stop, and turn the automation back on when I get back home… what is the alternative / what’s the better design approach here?
What is the recommendations here?

Geneuine question here. I learned about anti-pattern just now so not sure what else I should consider…? Do I merge the 2 automations into one?

19

No, it is not. Think of them like controlling a particular state in an FSM (Finite State Machine). I use this pattern a lot and i like how it is performing.

20

It’s an anti-pattern. Your frequent usage of it doesn’t change that fact.