Let users exclude individual entities from resolved targets in automations/blueprints/scripts

[nielsrowinbik]

Problem statement

When users target entities through an area, floor, or label, there is no way to refine the resolved set. If a user wants to trigger on all current and future motion sensors in the living room except one, they can't. The same applies to actions: turning on all lights in the kitchen except two is not possible today. Users who need this level of precision must either list every entity individually, losing the dynamic benefits of area or label targeting, or accept a target that is broader than intended.

Community signals

• This Discord conversation on the new triggers and conditions discusses how useful the target picker would be on the entity state trigger, with exclusion as an implied need.
• 9 out of 189 (~5%) users who have provided feedback on purpose-specific triggers and conditions have specifically asked for this feature.
• This feature request specifically asks for the ability to exclude entities from targets. This Discord message does the same.

Scope

In scope

• Allowing users to un-select individual entities from the resolved entity list within a target

Not in scope

• Introducing a rule-based or filter system with arbitrary AND, OR, and NOT conditions
• Rolling out the target picker to triggers and conditions that do not yet support it (see opportunity 2, blocked by this one)
• Wildcard-based targeting

Foreseen solution

Within the tree view of which exact entities are being targeted, the user can choose to exclude some of them by unticking the entity. The exclusion is stored and persists as the resolved target changes over time, for example when entities are added to or removed from an area.

This is what it will look like (full design available here):

When clicking through to the target details, the user will see this:

The excluded entities will be stored in the YAML so that this feature is also available to YAML-only users. This is what the configuration shape will be:

target:
  area_id:
    - living_room
    - bedroom
  exclude:
    entity_id:
      - light.living_room_pendant
      - light.bedroom_left_bedside_lamp

The shape of exclusions in the YAML is intentionally similar to targets. This way we can easily expand into target-based exclusion in the future without breaking changes if we want to.

Because users can move entities in and out of areas freely, we may end up with "dangling" exclusions. These will be flagged in the UI:

Risks & open questions

1. How do we handle the dynamic nature of exclusions over time? If a user excludes an entity from an area target and that entity is later moved out of the area and then back in, does the exclusion persist or reset? We need a clear and predictable mental model here.

Appetite

2 weeks. This should be a fairly simple change with some dependency between frontend and core.

Execution issues

No response

Decision log

Date	Decision	Outcome

[nielsrowinbik]

@marcinbauer-ohf, you've previously created a prototype (as demoed in the video in the issue). Would you like to look over the design once more or is this the way to go? If it's done as far as you're concerned then I think we can go ahead and move this into the getting approval phase.

[marcinbauer-ohf]

Design is ready here: https://www.figma.com/design/vyu7aRdcAbdBS3OhxSxgIH/GH-79?node-id=4002-495&t=dHVErhsC42WHytw6-11

There is a remaining issue when a user excludes an entity from an aggregate target (e.g. an area) the exclusion is stored in YAML. If that entity is later removed from the area or its entity_id changes, the exclusion becomes an orphan that no longer maps to anything real. I've added an example how we could do this in the design.

[AlexHunterScot]

Probably out of scope for this ticket, but it would be nice if the target-based selector exclusion list was itself another target-based selector.

That way, you could make automations and selections to do things like: turn off all lights upstairs except those labelled "nightlight"

Then the issue of dangling/orphaned excluded entities and dynamic exclusion could be solved. Or I suppose Spook could alert if there are broken references.

[marcinbauer-ohf]

That's an interesting solution @AlexHunterCodes, but one issue I see is that you have to do logical math between two sets of targets. The current approach is just one set with explicit (valid) exclusions if the target exists, and invalid ones if something has been deleted or changed its ID.

[AlexHunterScot]

@marcinbauer-ohf Yeah, it would need to be a broader architectural change. I come from a gamedev/backend background, where these kinds of Boolean operations are trivial in 2D/3D graphics and SQL to the point where we can take them for granted.

EDIT: The maths could be made easier if the exclusions were limited to a subset of the dynamic inclusions. To avoid users creating situations where they are AND/OR-ing potentially their entire home against itself repeatedly. So the exclusions selector would only show the targets valid at the time of creation. I don't know if the selector front end component allows filtering or scoping like that.

Only suggested it because a few other issues, discussions, and PRs are basically reimplementing bits of my suggestion piecemeal. I've noticed this issue is much more widespread on HACS where code standards aren't enforced. Only one I could find quickly in my GitHub inbox was the HomeKit Bridge integration proposing room/label-based configuration with inclusion/exclusion/filtering based on labels.

home-assistant/feature-requests#3061

A unified approach that encourages most integrations to adopt the target-based selector instead of rolling dozens of unique homegrown workaround patterns is desirable.