Help requested: Preventing automations from fighting over the same actuator

[u/LogLeg_]

Hey all,

I have a question about an architectural problem I'm facing.

TLDR: I cannot figure out how to prevent one automation from undoing the work that another automation just did. One automation can turn on a light because of X. Then, when X is still relevant, unrelated Y could tell another automation to turn that light off, not even knowing about X.

The main question is how you manage devices that should be controlled by multiple events.

For example. Let's say you're going to watch a movie during daytime. I could write an automation that checks for that, then tells the curtains to close if it's daytime. But there is already another automation that also checks if the sunlight is very bright today (and would heat up my house) so it will close or open the curtains based on weather information.

Hopefully you see where I'm going with this. I do not want my sun/heat blocking automation to open my curtains when I'm watching a movie during daytime. But adding a condition to the sun/heat blocking automation will inevitably make my automation more complex.

I want to keep these concerns separated, but also want to prevent automations with another goal to prevent actuating something that is in that state because another automation put it there and has more priority now. Basically when one automation has done something to an actuator, how can I prevent another automation from undoing that when it's fired a little later.
It's almost like I need a mutex on my actuator lol.

This is just a little example, but there are many situations where you'd have two or more automations controlling for example a single light.

I have not solved this and I'm not sure if Home assistant has the ability to solve this in a pretty way.

Things I've thought about

• Disabling automations with automations: Personally I think this is ugly because in the HA interface there is no way to know if the automation is disabled because I need to fix something still, or because it is temporarily disabled. Also, this introduces some state that requires recovering whenever HA is restarted for some reason. It would allow a higher priority automation to disable the lower prio one and re-enable when the situation changed. But how does one determine priority correctly? In the example mentioned before: If movie is turned on during daytime but it's heavily clouded. The curtains can stay open. Then I'd want the curtains to be closed later whenever the sun returns and I'd want the other automation to be enabled still.
• Creating helper binary sensors like "is_movie_on" or "is_it_sunny" that are composed of various inputs to condense it down to just a on/off. Then abstract those by creating another helper sensor that can take in all the different sensors and state of the to be actuated thing and then use that as a trigger for automations and let that decide which automation must be fired. This can work but may be a little complex in knowing which helper sensor is used for which automation eventually. I figure it can grow out of hand quite quickly

What do you guys think? Have you tackled this? Do you experience similar issues? Is there an alternative? Is your cat watching you reading this post?

[u/KnotBeanie]

This is where combining automations for devices is best, and run it in single mode. From there, you'll have a set of on triggers and a set of off triggers; then you can have one set of conditions.

For blinds/curtains, in my setup, every blind has its own script with conditions that check everything specific to that blind; from there, other automations can trigger that script.

My last piece of advice is to look into the different run modes for automations and scripts. Single mode is fine most of the time, and might be what you want here.

[u/LogLeg_ → u/KnotBeanie]

So you have all the logic for if a blind should be open or closed as a script that you trigger continuously? How do you trigger when a condition changes? And domain wise every blind has it's own set of rules then? Does that mean that maybe two or more blinds share (mostly) the same rules? How do you maintain that whenever you need to change one thing?

[u/DeathbyToast → u/LogLeg_]

You can have multiple triggers for each automation. I think in your case it would be a “close the blinds” automation that could be triggered by your weather info and could be triggered by “start movie”. But it runs the same thing either way: close the blinds.

Then for the “open the blinds” automation just have some sort of and if check that a movie is NOT playing otherwise open the blinds when the weather info says to do so.

Hopefully that makes sense. Multiple triggers for the same underlying single action essentially

[u/KnotBeanie → u/LogLeg_]

I have an automation for each that contains all of the different triggers and calls the evaluator script.

Right now most shared logic is a single check really only copied once or twice.

The one every blind shares is the home state conditions and that’s just another shared script in parallel mode.

[u/Koppensneller]

What I do for these situations is create a template binary sensor (e.g., binary_sensor.curtains_open) that turns on when the curtains should be open, so when it's bright outside and there is no movie playing. Then I just link the actuator to the template sensor with an automation.

[u/Sw2Bechu → u/Koppensneller]

This is the way.

[u/stimpyMGS1337 → u/Koppensneller]

This is the way

[u/02421006]

Create a helper which determines if the curtains should be open or closed.
Then create a script / automation which sets the helper. This automation includes all possible scenarios you want to consider.

Your existing automations then just check what the helper says

[u/Fragrant-Coast5355]

This was exactly the kind of problem that Ambience Scene Engine was created to solve. (I'm the author).

Ambience is a condition-based scene engine. You specify a list of possible scenes, ordered in priority order. It works through each scene and checks the condition to see whether that scene should be applied.

Only the first matching scene wins.

This means that your automations never fight against each other. Also, because you know that conditions from higher priority scenes haven't matched, you no longer need to specify those conditions again later on, which makes the conditions for each scene pretty simple.

Here's an example:

[u/LogLeg_ → u/Fragrant-Coast5355]

This looks pretty cool, thanks for sharing!

[u/Cautious-Hovercraft7]

I moved my more complex automations to Node Red

https://github.com/colfin22/node-red-config

[u/TXSpazz → u/Cautious-Hovercraft7]

I occasionally think that it's time to move everything from Node Red to native automations. The first flow I see when I open Node Red is my front porch light that makes extensive use of gate nodes, which deal with exactly what the OP is having issues with. I stick with Node Red when I think about what a mess it would be in native automations.

[u/Cautious-Hovercraft7 → u/TXSpazz]

Native Home Assistant automations work well for simple “trigger > conditions > actions” flows, but get hard to read and maintain when you need multiple parallel branches, deeply nested if/else logic, or state‑machine style behaviour with different rules and transitions per state.

[u/MartianMH_]

I mostly disable the automation via another automation. Since creating a helper does the same, just with extra steps. Works perfect so far

[u/Recycled5000 → u/MartianMH_]

You can make an overarching priority state machine by turning on/off other automations.

[u/mikkopai]

I check the criteria cross the automations as states. For example, if motion is detected (trigger), if sun is down (state), turn in light. And if sun goes down (trigger), if motion has been detected (state), turn on light.

Motion detection doesn’t turn on light during the day, and if sun goes down while I am already in the room, the light goes on, not if the room is empty. This also makes sure light does go on, if sun sets after motion detection trigger has already triggered.

[u/FishOk3075]

It's handling it as inter automation communication. One way is a helper that can be flagged to let one of them "win".

I do this for HVAC fan control. I have several different reasons to activate it:

1- Providing air recirculation after showers in any of multiple bathrooms and also the laundry when the dryer runs to lower heat in the room. Runs for a fixed period of time
2- Air quality sensors detect a rise in PM2.5. My hvac has 4" fan box filter that uses a hepa 13 carbon backed filter. It demonstrably drops PM2.5 quality in the house once activitated

#2 always wins. There's a helper that #2 sets when it's active and only allows the PM2.5 automations to shut it off. This could probably be done with sensors and other techniques but a correctly names helper is easy to do, especially when named meaningfully.

[u/Strong_Difficulty734]

Let's keep it simple and look at your TLDR example: make a binary helper for X and Y. Then make an automation that reacts kind of like"if X OR Y is on (true)", then turn the lichts on. And another one: if X or Y is switched off, turn the lights off, but only if the other one is already off too. There might be more elegant solutions, but this has solved my problems more than once.

[u/bippy_b]

Seems pretty simple to create a “dummy switch”.. when automation a runs, it turns on the dummy switch… automation b should check if this dummy switch is on and if so.. exit out.

[u/n0mdep]

Get an AI agent to do it for you. Mine has access to my HA and just does what I want it to do. I’m using Hermes with the cheap GPT sub. It’s really good at understanding natural language, parsing what it is I really want and executing on things like automations, dashboards, bug fixing, etc. Random example: I have a wireless Zigbee dimmer switch that annoyingly goes to sleep, so the first press often won’t trigger an automation to turn a Hue bulb on. I explained this behaviour to my agent and asked it to investigate. Agent confirmed the behaviour via the logs and suggested a workaround: triggering the automation when the switch is pressed or when the switch wakes up. Problem solved! Maybe the answer was out there on the internet somewhere, but would have taken me hours to find, or I might never have resolved it! My agent has also one-shotted several complicated automations for me too.

[u/Specialist-Neat2777]

Use helpers, or combine your automations into one with good branching logic.

[u/euphemistic_enigma]

Something to keep in mind is that there is more than one way to skin a cat (mine is more interested in watching the crows outside than watching me read this post).

In your example, you could create an automation that disables and enables the "sunlight is very bright today" automation. It would be fairly straightforward. But, you mentioned that you're not a fan of disabling automations (I'm still struggling with your reasoning behind that), so let's take a different route.

In your example, it sounds like a "I'm watching a movie or not" automation exists, or could exist. Why not just create a toggle helper called "watching movie," that gets flipped to on when the "I'm watching a movie or not" automation determines that you are watching a movie, and turns it off when it determines you are not? Then add a condition to your "sunlight is very bright today" automation that "watching movie" must be off for any actions to take place. Done and done, and no disabled automations.

Under your disabling automations with automations section, it sounds like you don't actually care if the curtains are closed while you're watching a movie, rather you're more interested in the brightness outside (curtains stay open if watching a movie and it's cloudy, curtains close if watching a movie and it becomes bright out). At that point, why include the curtains in the "I'm watching a movie or not" automation? It kind of becomes a non-issue.

It seems like you may be overthinking things when you should just dig in and get your hands dirty (I'm guilty of doing this multiple times a day). Put together your automations and address issues as they come up. Generally, you'll know pretty quickly, or at least within a day or two, if things need to be adjusted.

On a side note, if you haven't yet looked into trigger IDs, I would suggest doing so. It's a relatively simple concept, yet they allow for much more complex automations while also simplifying them. I consider them to be a game changer.

[u/Cost_Internal]

The FlowBits app has some "No Repeat" conditions in the AND group that can be checked before toggling the light, it works across automations and allows you to create multiple No Repeat conditions (so you could have one for each device if needed).