Support the label, area, zone, room target selectors

[jeyrb]

Resolve these as part of target selection, along with group expansion

Configure if deliveries should resolve within supernotify or pass along to the transport integration

[lollox80]

Interested in helping here. Two design questions before writing code:

1. Resolution location - should expansion happen inside SuperNotify (so transports always receive a flat list of entity_ids), or be passed through to the transport integration via HA-native target selectors? Some transports (e.g. mobile_push, elegram_bot) already handle some of these natively, others do not.

2. Source of truth for membership - �rea_registry, label_registry, zone integration, and device_registry give different views. Should SuperNotify rely on HA's arget_data (passing them straight to call_service) or resolve them locally via the registries?

Once you pick a direction I can sketch a design doc and a PR.

[jeyrb]

The design questions are a bit tricky, mainly for group expansion, which is why I've left this for now.

Some integrations and some people will want resolution prior to action call, and others leave the resolution to inside the action call. The supernotify approach is generally to respect the underlying integrations and only add what they're missing, which suggests defaulting to not resolving.

There might be a half-way case too, where you want to resolve say for the purpose of filtering in or out, or to make sure there's not multiple action calls for the same entity, but not resolve the actual entities as passed to the actions.

Also, its going to be a need to combine these - select all devices in area X of category Y - with the complexity of boolean logic and nested conditions, though maybe all of that could be delegated to HA Conditions.

Resolution location seems a good use of TransportFeature, so if a transport can take a group or area_id then that's an option, otherwise it always gets bare list of entities, which then means using the registries as a source of truth.

Chime would be an obvious use case for this.

Catergory is the missing one in my original list

[lollox80]

Thanks, that gives me enough to work with. Aligning on what I'm hearing:

Default behavior: don't resolve locally — pass selectors straight through to the underlying integration / call_service.
Opt-in resolution via TransportFeature: new flags (e.g. TARGET_AREA, TARGET_LABEL, TARGET_GROUP) signal a transport can consume native selectors. Transports without the flag get a flat entity_id list expanded by SuperNotify against the registries.
Filter-only resolution as a middle path: resolve internally for dedup / per-entity dispatch limits, but still hand the original selector to the action. Probably a separate per-delivery option rather than a TransportFeature flag.
Boolean / nested logic (e.g. "all devices in area X of category Y") → delegate to HA Conditions rather than reinventing.
Chime as the canonical use case for local resolution (no native selector support → needs flat media_player list).

Two clarifications before I sketch the design doc:

Category — do you mean HA's entity_category (config / diagnostic), device class, or a custom tag concept? It changes the registry lookup quite a bit.
Zone vs room — HA has area_id, floor_id (2024.x+), and zone.* entities (geofencing). Are you treating area_id as "room" and including floor_id in scope, or did you have something else in mind for "zone/room"?

Once those are pinned I'll put up a design doc covering the TransportFeature additions, the resolver pipeline, and the schema changes for delivery.yaml. Targeting Chime as the first transport to consume the new resolver since you flagged it as the obvious fit.

[jeyrb]

Are there any transports at all that can handle any of these other than group? Maybe there's no need for the target flags now if it's a theoretical problem at present.

Categories - I meant https://www.home-assistant.io/docs/organizing/categories/ which have their own registry now. Don't quite understand why HA has those and labels. Might only apply to scripts in a notification context, in which case could be left out for now.

I wasn't thinking at all about geofencing zones, and that seems very advanced. only area and floor