Reduce the maintenance burden of groups with target-based membership

[frenck]

Problem statement

Group helpers in Home Assistant currently require users to manually select individual entities as members. This makes groups static: whenever you add a new device to a room, assign a new label, or reorganize your home, you have to remember to manually update every affected group. This is tedious, error prone, and fundamentally at odds with the dynamic organizational model we've built around areas, floors, labels, and devices.

Automations already support targeting by area, device, floor, and label, and the purpose specific triggers and conditions project (currently in Home Assistant Labs) is extending that same target concept to triggers and conditions. Groups are the missing piece: they remain locked to a flat list of entity IDs while the rest of the platform has moved on.

This creates real friction for users who want to, for example, create a light group for "all lights in the kitchen" (area), a "Christmas lights" group (label), or a "media players on the ground floor" group (floor), without having to maintain those lists by hand. It also limits how useful groups are for voice assistants and dashboards, where a dynamic group entity would make Assist commands and area controls far more powerful and predictable.

This opportunity supports the goal of making Home Assistant more approachable: groups are one of the first helpers new users discover, and the inability to populate them dynamically from existing organizational primitives is a source of confusion and maintenance burden that makes the platform feel harder than it needs to be.

Scope & Boundaries

In scope

• Add target support (area, device, floor, label, entity) to group helpers, mirroring how targets work in automation actions
• Dynamic membership: when entities matching the target criteria change (e.g., a new light is added to an area, a label is assigned/removed), the group membership updates automatically
• For platforms that support device classes (sensor, binary sensor, cover, etc.), add a device class selector that limits which entities the target resolves to. For example, a sensor group set to device class "temperature" targeting the "kitchen" area would only include temperature sensors, not humidity, battery, or power sensors in that area. This field should come before the target selector in the UI, as it defines the scope of what the target will match.
• Support for all existing group types (light, switch, cover, media player, binary sensor, sensor, fan, lock, event, notification)
• UI support for configuring targets in the group helper creation/edit dialog
• YAML support for target based group configuration

Not in scope

• Exclusion filters (e.g., "all lights in kitchen except X"); this could be a future enhancement
• Combining targets with boolean logic (AND/OR); union of all targets is the initial scope
• Template based dynamic membership (Jinja); the target system is the mechanism here
• Changes to how groups calculate their combined state
• Dashboard or card changes (groups already work as entities everywhere)

Foreseen solution

Extend the group helper configuration to accept targets alongside (or instead of) a static entity list. The target selector already exists in the frontend and supports areas, devices, floors, labels, and entities. The group would resolve its membership dynamically based on the configured targets, limited to the domain appropriate for the group type (e.g., a light group only picks up light.* entities from the targeted area).

For platforms where device classes exist (sensor, binary sensor, cover, etc.), the group configuration includes a device class selector before the target. This is essential to make target based groups practical: a sensor group targeting "kitchen" without a device class would mix temperature, humidity, battery, and power sensors into one meaningless combined state. By selecting device class first, the user defines the kind of entity they want, then the target defines where to find them.

When the underlying registry changes (entity added/removed from an area, label assigned/unassigned, device added/removed), the group recalculates its members. The purpose specific triggers and conditions project has already tackled the problem of listening for registry changes to dynamically resolve targets; we can reuse the same patterns and infrastructure.

The static entity list remains supported for backward compatibility, and users can mix static entities with target based membership if needed.

Community signals

This is a frequently and consistently requested capability, spanning multiple years and forums:

• Automatic groups from labels (Feature Requests, Dec 2025): requests groups that auto populate from labels
• Revised groups logic: members based on Entity, Area, Label, Device (Community Forum, Apr 2024): proposes exactly the target based group approach with mockups
• Dynamic Groups Based on Labels (Community Forum, Nov 2024): multiple users describing maintenance pain of static groups
• WTH: Why can't I create a button on a dashboard that actions labels rather than entities? (WTH 2024): users want label based control, which a dynamic group would enable
• WTH: Trigger automation by label (WTH 2024): related desire for label aware automation primitives
• Why the heck don't we have templates/glob for groups? (WTH 2020): this request goes back years
• Exclude label/entity/device etc from action (Feature Requests): related request for target exclusions, mentions groups
• A community Blueprint for dynamic group membership exists as a workaround, highlighting that users are building this themselves with significant complexity

Risks & open questions

• Performance of dynamic resolution: Groups that target large areas or broad labels could contain many entities. Need to ensure membership recalculation on registry changes is efficient and doesn't cause state storms on startup.
• Interaction with purpose specific triggers: The Labs project for triggers and conditions has solved similar dynamic target resolution. How tightly should we couple group resolution with that infrastructure? We should reuse where possible but ensure groups work independently of the Labs flag.
• Mixed membership (static + target): Allowing both static entities and targets in a single group adds flexibility but also complexity. Should we support this from the start or keep it simple with either/or?
• Entity resolution edge cases: When a user targets an area for a light group, should it pick up switch entities that have been converted via Switch as X? The device class selector addresses the sensor/binary sensor challenge, but domain boundary edge cases like these still need clarification.
• Device class filtering for sensor and binary sensor groups: Targeting an area for a sensor group would pull in temperature, humidity, battery, illuminance, and power sensors all at once, which is meaningless for a combined state. Sensor and binary sensor groups will likely need a device class filter as part of the target configuration to be useful. This adds UI and configuration complexity that the other group types (light, switch, cover, etc.) don't need.
• Migration of existing configurations: Existing groups are all static entity lists. We need to decide whether to offer a migration path (e.g., suggesting target based equivalents for groups whose members all share an area or label) or simply leave existing groups untouched. Either way, the transition needs to be smooth and not break anyone's setup.

Appetite

Medium: roughly 1 to 2 cycles of focused work across core and frontend. The target selector UI already exists; the main effort is in core (dynamic membership resolution, registry change listeners) and ensuring the group helper UI surfaces the target selector. Learnings from the purpose specific triggers and conditions project should reduce the discovery phase significantly.

Execution issues

Populated once a bet is approved.

Decision log

Date	Decision	Outcome
2026-03-12	Opportunity created for betting table consideration	Awaiting outcome