Expose Areas as Virtual Domain Entities for State Aggregation

[glenviewjeff]

Describe your core improvement

I propose that the Core architecture be updated so that Areas automatically expose virtual/proxy entities for supported domains (specifically light, switch, binary_sensor, and lock) based on the devices assigned to them.

For example, if an Area named "Kids Room" (area_id: kids_room) contains three light entities, Core should automatically expose light.area_kids_room.

This virtual entity would function identically to a Light Group:

1. State: Reports on if any non-excluded entity in the Area is on.
2. Attributes: Reports aggregated brightness/color (average) if applicable.
3. Control: Toggling this entity controls the targeted Area (which service: light.turn_on target: area_id already supports).

To handle edge cases (e.g., a router LED that shouldn't trigger the room state), a simple boolean toggle "Exclude from Area State" should be added to the Entity Registry settings, similar to the existing "Hide" or "Exclude from Recorder" options.

Current limitations

Currently, Areas are effectively "backend-only" concepts.

1. The Backend/Frontend Disconnect: While the backend supports targeting an area_id for service calls, the frontend has no way to visualize the state of an Area. You cannot bind a standard Button Card or Tile Card to an Area to see if the room is "On" or "Off."
2. Redundancy (Violation of DRY): To achieve basic UI functionality (like a dashboard button that glows when a room is occupied), users must manually create and maintain Helper Groups (e.g., light.kids_room_group) that duplicate the list of devices already assigned to the Area.
3. Maintenance Burden: If a user adds a device to an Area, they must remember to also add it to the Helper Group. This double-entry bookkeeping is prone to user error and unnecessary configuration.

Technical benefits

True "Zero Config" Dashboards: Users could drag a Tile Card onto a dashboard, select an Area, and immediately have full state feedback and control (dimming/color) without creating intermediate helpers.

Architectural Consistency: It bridges the gap between the Service layer (which respects Areas) and the State Machine (which currently ignores them).

Simplified Logic: Automations could trigger based on light.area_living_room state changes without needing complex templates or manual groups.

Additional context

This addresses the root cause of "WTH" posts regarding automatic grouping. Previous requests for "Automatic Groups" often get bogged down by edge cases (e.g., "I don't want my printer screen turning on the room lights").

By treating this as an Area Entity with an Exclusion property on the child devices, we solve the edge cases without forcing the user to maintain manual groups.

This is similar to how HomeKit and Google Home handle rooms: they automatically aggregate the state of devices within a room assignment. Home Assistant is currently the outlier in requiring manual grouping for room-level state visibility.

Also see: https://github.com/orgs/home-assistant/discussions/1731

[mik-laj]

Have you seen the new Intuitive triggers and conditions from the latest beta? I think it solves some of your problems without the need to create artificial entities?
https://rc.home-assistant.io/blog/2025/11/26/release-202512/#intuitive-triggers-and-conditions
https://www.youtube.com/watch?v=cFaB4rdTCZI