I found this recent WTH post discussing automatic light groups, but I think the problem goes deeper than just auto-generating helpers, which in itself feels like a kludge.
The Core Problem: I have organized my home meticulously into Areas (e.g., “Child’s Room”). Home Assistant knows exactly which lights, switches, and sensors are in that room. Yet, I cannot ask Home Assistant “Is Child’s Room On?”
To get a simple dashboard button that glows yellow when the room is occupied/lit and allows long-press dimming, I have to manually duplicate my work by creating a light.group helper. This is redundant maintenance. If I add a lamp to the Area, I shouldn’t have to also add it to the Group.
Why “Target Area” isn’t enough: People might say “Just use the Area card” or “Target the Area in automation,” but that misses the UI/State requirement:
No State Feedback: A Button Card pointing to an Area doesn’t show state. I want an icon on my dashboard that lights up to show lights/devices are on in that area. This should be configurable per area (whether all or one device lights it) just like a custom group is.
No Feature Control: You cannot long-press an Area card button to get the brightness slider or color wheel.
Inconsistent Logic: The backend supports target: area_id, but the frontend treats Areas as second-class citizens.
The Solution: Areas as Entities (Virtual Proxies) Instead of cluttering our systems with (manually or automatically created) additional Groups that we have to manage, Home Assistant should expose virtual entities for populated domains within an Area.
light.area_evans_room
switch.area_kitchen
Addressing the “Christmas Tree” / “Screen Light” Problem: In the other thread, users rightly pointed out that we don’t want every light (like a router LED or a monitor) controlling the room state. Solution: Add a toggle in the Device Settings for “Contribute to Area State.” We already have “Exclude from Recorder” and “Hide.” Just let us exclude the Christmas Tree from the Area Entity logic.
Let’s stop manually glueing devices together that are already sitting in the same virtual room.
Along the way, we discovered something interesting: many of you take a “target-first” approach when building automations. You think about what you want to automate (a device, an entity, or an area) before thinking about how to automate it (which action to perform or which trigger to use).
This release introduces a completely new way to build automations. Intuitive triggers and conditions are now provided directly by domains like Light, Climate, Fan, and others, covering the most common automation use cases.
These new triggers and conditions fully support targeting. This means you can trigger an automation when any light in your living room turns on, without having to list them one by one or create a group beforehand. Targeting an area keeps things simple: it’s always aligned with how your home is organized, and you don’t have to update anything when you add or remove devices.
You are absolutely right. Asking if a temperature sensor is “on” makes no sense. That is exactly why I am not proposing a single, generic area.childs_room state, but rather Domain Proxies for the Area.
If an Area contains devices of a specific domain, the system should simply expose a virtual entity for that domain:
Lights present? Expose light.area_childs_room. (Aggregates on/off and brightness).
Locks present? Expose lock.area_childs_room.
Sensors present? Expose sensor.area_childs_room_temperature (if averaging is enabled).
My frustration is that right now, if we want to control the Lights in the Child’s Room, we have to manually create a light.group Helper. The system already knows which lights are in that Area; it should just expose that group logic natively as light.area_childs_room so we don’t have to double-enter everything.
Currently, to answer “Are the lights on in the Child’s Room?”, I have to manually create and maintain a light.group. The system already knows which lights are in that Area; it should just expose that aggregate state natively so the dashboard (and voice assistants) can use it without manual configuration.
And if the example I posed was a literal question to an LLM, the LLM should know to either ask for more clarification, or perhaps more usefully report the status as, “The lights are on and other devices are off.” So in the case of the example question, an LLM might respond, “all devices are off” or “the space heater is on and the lights are off.”