Layered states to simplify complex automations

[LordMike]

Hi,

I've been struggling for a while with an issue I've been trying to solve for my outdoor lights. I want many things of them to make them as helpful as possible, without immense amounts of logic to achieve it.

The issue

For example, I want:

• the outdoor lights (of which there are many) need to turn on/off at night
• the brightness of all the lights should generally be the same
• some of the lights need to be brighter when the front door is opened
• i have logic to determine a color scheme for the lights, making my house the most colorful on the block (yay)
• when the front door opens though, some of the lights must become warm white (and bright), as I need to see when I walk
• i want to override this at will (colors, brightness, on/off), without an automation kicking in adjusting for circadian brightness or on/off at times

I've achieved this using an automation that triggers on all the possible changes, and then using a large choose: to filter down through the most likely to least likely options until finally arriving at a fallback (off). This works great for single lights or sets of lights that are all the same, but the moment I introduce things like overrides or wanting to turn off some lights at night because they're in the yard, it becomes very complex.

Second issue

Another example is I have LEDs internally on my wall switches which show state, like "lights are on". If I click these buttons, the lights turn off and the LED also turns off, reflecting that lights have indeed been turned off. Great for shutting down at night.

Now, I have many LEDs, showing various things around the house. I also want these LEDs to be less bright at night, so they themselves don't light up the rooms too much. I've solved this now with a central brightness helper (a number), and then an automation for each LED button I have, that controls that individual light. At present, I have 15 of these automations that are mostly similar, and they all reference this central brightness helper (and trigger on it).

I originally wanted brightness controlled outside these automations, as to not litter them with this concept, but I couldn't do it cleanly. I ended on this design as the least of many worries. But if I in the future want to add, say, security blinking lights, I then need to go back to all these automations and add a trigger and a choose: condition for "security triggered", which enables blinking. And if I add a new LED, I need to ensure its automation(s) have the same logic as the others.

Layered states

I've arrived at "layered states", and also found this post on HA forums referencing "BACnet" which I had no idea what was. That post dives into the "security alert" situation where a lot of entities have to be overridden for a short while, ignoring whatever automations they might have, but still allowing to go "back" to the original state once the security incident is over.

In my layered states thinking, I could simplify my previous issues down to a series of layers, which control aspects of the entities. Each layer is accumulated to arrive at a final state. For example, a light might have on/off, brightness and color as parts of its state. The layers could then say:

• { state: On, brightness: 10% }
• { brightness: 40% }
• { color: red }

If we accumulate this, in order, we arrive at { state: On, brightness: 40%, color: red }. But if we then remove the layer setting brightness to 40%, we arrive at { state: On, brightness: 10%, color: red }, letting us revert back to a "previous" state - its not lost.

If we take the example with the outdoor lights, my layers could be, in order of lowest priority to highest:

• on or off based on time
  • This could be two different ones, or the same, for the various lights I have ensuring that some are "always" on while others are only on for a short while
• A base brightness which could be a circadian rythm, or a fixed low level
• A color scheme can be applied as I want it
• Front door is opened: the brightness is set to a high level and the color to warm white. When the door has been closed for a minute or two, the brightness is set to null for this layer
• An override, e.g. a light.turn_on call from me, the user - anything set here overrides the rest

This thinking really shows its value when I want a layer to apply to many entities, and another layer to only a few. Then I can centrally define my indoor LEDs as having a brightness that follows the day/night cycle, but their colors are controlled by more specific automations. And finally, I can centrally have some overarching override that makes them all blink red.

A possible solution?

One way I've arrived at, inspired by Christopher Piggott, was that a service call could embed a priority value, making whatever it sets be applied to that priority:

action: light.turn_on
data:
  priority: 2 # high priority
  brightness_pct: 80
  rgb_color: [255, 0, 0]
  effect: blink
target:
  entity_id: group.all_lights

action: light.turn_on
data:
  priority: 10 # low priority
  rgb_color: [100, 124, 221]
target:
  entity_id: light.outdoor_light_1

action: light.turn_on
data:
  priority: 13   # lower priority
  brightness_pct: 20
target:
  entity_id: group.outdoor_lights

These calls set up a series of layers for the light.turn_on service, with the final state arriving at all lights blinking bright red, but once that priority 2 (the "security" incident) has been cleared, we're back at a low brightness blue color on some of the lights, while other lights ideally turn off.

I have some troubles reconciling the final state from the actions nature. By nature, an action (a service call) is a mutation of the state of an entity, and not a state in itself we can simply "apply". For example, light.turn_on and light.turn_off are mutually exclusive, so we can't simply store all turn_ons in a big list and aggregate them. We also have some service-specific things like color, color_name etc, which are also mutually exclusive.

So I hope this could work in the service call level, as its a very natural way to express intent, and that this issue could be resolved. :)

Resources:

• Post on HA forums on "bacnet"

[LordMike]

Use case, night light:

I have two concerns in a night light scenario: a dimmed down light that's on to help kids sleep or people navigate. In one instance, the light has to be at a low level if it's on. It must only turn on at this level, or be off. We could do this by at night time setting a high priority state that says "brightness: 2%", but not turn it on (light.set_state ?). When it does come on by any light.turn_on call, its forced to a low brightness lighting.

The inverse of this is my ceiling lights in the bedroom must not turn on at night. I've done this by mistake a few times and its never popular. So specifically for this room, at night, that light must be off at a high priority.

[parautenbach]

Interesting proposal, and to latch onto this specific point: I have a case where I have a light group for all living area lights (i.e. excluding bedrooms and bathrooms). My hallway's light is part of this group, and it's almost always on. So, when I want to turn on all other lights, I want to use the group, and as part of that, should the hallway's light not be on, then it should turn on too. Now, that works just fine today, but the inverse logic I need doesn't: When I turn off the group, I'd like everything except the hallway light to turn off. This can be solved by having a second group, but on a UI this becomes trickier than it needs to be, since you cannot simply toggle a single group connected to a button. Same for automations.

[dxmnkd316]

I must be missing something, how is this not just a scene?

I've done similar things with my ecobee where I wanted to implement a "pause" while windows are open. You basically just set an input_text to the existing ecobee state, pause the ecobee, then when resolved you set the ecobee state to be the stored input_text. A similar concept could work for states here.

[LordMike]

This is amazing. It's not possible as a custom component, right? It requires changing core.

Also. What happens for calls that specify no priority? How do they interact with calls that do?

.. and what about domain specifics. Were there none ? In my assessment I found that light fex has a service for on/off/toggle. Here, on/off can override each other and thus need something that merges or consolidates what they mean into something .. I couldn't, from what you wrote, determine how this was resolved ..

Like. What happens if a priority:1 On comes in, then a priority:2 Off ...

.. or are you capturing the service calls and then replaying them, so in the above, if the Off is relinquished, you replay the On call ?

[triosniolin]

Thanks. Taking these in order.

Is it possible as a custom component?

It is, and it is one; it has been running my whole house for a few days, every arbitrated domain,
no per-entity opt-in list.

You are half right though, and the half you are right about is the reason this thread should
exist. There is no supported way to do it. It works by pulling each registered Service out of
hass.services.async_services_internal(), keeping the original (its job, schema and
supports_response), and registering a wrapper over the same name, which overwrites in place.
EVENT_SERVICE_REGISTERED catches integrations that load later. Unload puts every original back.

All of that is core internals, not public API. It can change in any release, and the failure mode
is "every supported entity stops responding until you delete the config entry". I keep a contract
test that asserts every internal it leans on, and CI runs it weekly against current HA, so a break
shows up as one obvious failure naming what moved rather than eighty confusing ones. That is
mitigation, not a fix.

So: a custom component can do this, but only by reaching into places it has no business being.
That seems like the actual argument for doing it properly in core.

Calls that specify no priority

They are treated as priority 5 (Default), and that includes automations.

Writes at the same level replace each other, so if you never mention priority anywhere, the
system behaves exactly as it does today: last command wins, and you can always countermand an
automation from the app. Install it and touch nothing, and it is a no-op. That property is the
one I would defend hardest, because it is the answer to "what does this break".

They interact the obvious way: a call with no priority is just a call at level 5. It loses to
anything currently held above it, and either way it is recorded into slot 5, so it is still there
to fall back to later.

Worth flagging one thing I would push back on in your original proposal: defaulting automations
to a higher level than people is the faithful BACnet reading, and I think it is wrong for Home
Assistant. HA automations fire and forget; there is no relinquish idiom. That level fills up and
never drains, and every entity an automation has ever touched goes permanently deaf to the UI.
Arbitration has to be opt-in per command, not something that accumulates behind your back.

Domain specifics, and the on/off merge problem

This is the question I would most like to answer, because I think the premise dissolves.

A slot holds a whole service call, not a value. (domain, service, data). So level 2 might
hold light.turn_off{} while level 4 holds
light.turn_on{brightness: 80, rgb_color: [255, 0, 0]}. Nothing has to merge or consolidate them
because they never interact with each other. The lowest occupied level wins wholesale and is
dispatched as it stands; everything below it just sits there intact, waiting.

The consequence is that there is no per-domain code anywhere in the arbitration. Climate,
cover, fan, lock, valve and water_heater worked the day the light domain did, because nothing in
the arbitration layer knows what a light is. That was the single best decision in the design and
I would not have predicted it going in.

The one genuine exception is toggle, which has no stable meaning inside an array: replaying it
later would flip the device rather than restore it. It is resolved against current state into a
concrete turn_on or turn_off at the moment the call arrives, exactly once, before it ever
enters the array.

Since you will spot it anyway: the cost of slots holding whole calls is that there is no
per-attribute blending. If level 4 holds brightness and colour, and level 2 writes brightness
only, level 2 wins outright; you do not get level 4's colour underneath level 2's brightness.
True BACnet fidelity would be a per-attribute array. I decided domain-agnosticism was worth more
than blending for a house, and the storage format keeps a per-slot data dict so per-attribute
arrays could be added later without a migration.

Your priority:1 ON, then priority:2 OFF

Level 1 wins, so the device is on. The level 2 turn_off is recorded into slot 2 and not
dispatched; that part matters for what happens next.

Add your five minute lease to the level 1 command and nothing else changes for five minutes. Then
the lease expires, slot 1 clears, the array is re-evaluated, and the level 2 turn_off is
dispatched. The device goes off. Nothing had to remember it or schedule it; it was simply the
next thing in the array.

(The lease is priority_ttl, an optional expiry on any command above Default. It is the thing I
actually wanted out of all this. "Turn this on for twenty minutes and then put it back" has never
had a clean answer in HA, and here it is just an override that stops overriding.)

One honest caveat while we are on this scenario: the suppressed call still returns successfully to
its caller. There is no error, so a script or a voice assistant will look like it worked. For a
light that is mildly confusing; for lock it is worth thinking about.

Capturing and replaying

Yes, exactly that, with one important difference from the capture-and-restore pattern people
hand-roll today.

When a level is released or expires, the next level down is re-issued as it currently stands,
not as a snapshot taken when the override began. If an automation rewrote level 4 while level 2
was holding, releasing level 2 falls through to the new level 4 command. Nothing has to remember
a previous state, so nothing can restore a stale one. That is the failure every guard-boolean and
scene-restore approach eventually hits, and it is the reason I think this belongs at the command
layer rather than in userspace.

Replay does not go back through hass.services.async_call; it invokes the captured original job
directly, which makes recursion structurally impossible rather than something a guard flag has to
catch, and keeps one relinquish to exactly one dispatch.

---

Happy to walk through any of it in more detail. The code is Apache-2.0 to match core, specifically
so it can be lifted rather than reimplemented if this ever goes anywhere.

[triosniolin]

https://community.home-assistant.io/t/priority-arbitration-let-a-manual-action-and-an-automation-disagree-without-one-clobbering-the-other/1020842

Some screenshots here as well of how the system looks and some examples of how I use it.

[LordMike]

Slightly adjacent. I made this discussion a while back which is another thing I'd want to do in the same area this integration touches on. In this discussion, I argued for an extension point in HA, which allows for hooking pre/post service calls.

https://community.home-assistant.io/t/service-filter-firewall-feature-prevent-bedroom-light-turn-on-during-nighttime/609846/6

That solution is probably 1:1 what you're thinking about when it comes to tweaking the core.

[LordMike]

Besides toggle, which is a good example, you also have states on the device. Since we're capturing mutations, this can happen. Say you have:

level 1 (most important): light.turn_on, brightness: 50, color: red
level 2: light.turn_on, brightness: 100
level 3: light.turn_on, brightness: 20, color: green

Here, level 1 applies, so the light is red 100%. Then, level 1 disappears for some reason, and no the light is 100% bright, but still red. Level 2 disappears, and now the light is 20% green. Level 2 is reapplied (maybe its an automation), and now the light is 100% green.

Now. This is in no way new here, its just also apparent. Automations have always had this issue, that if you don't come with all the state in your service call, you'll inherit what was on the device.