Nested Areas

[wildekek]

Describe your core improvement

I would like to nest Areas in Areas. This way we can make devices and entities easier to find and simplify naming. Let's get rid of names like 'Guesthouse Bedroom Walk-in Closet Light' but nest areas like so:
Area: Guesthouse > Bedroom > Walk-in Closet
Device name: Light

Current limitations

Currently, I can't group areas per building, nor can I add a specific place inside an area. For example, when I have an open plan living room with a kitchen, the architecture does not allow easy control. Hence, I have to:

• compound area names eg "Living Room" and "Living Room Kitchen"
• or, have "Living Room" and "Kitchen".
  When I turn off all lights in the living room, I want the kitchen to be included. Not possible in this way.

Technical benefits

• Better naming schemes, which benefits (auto-generated) dashboards and cards
• Easier to find entities and devices
• Easier automations, since nested areas can contain more devices to be targeted at once

Additional context

Looking at the new device pickers and the focus on areas for automated dashboards, this would be a logical next step imo.

[chefdeit]

I. Prior Art

As Jörg W pointed out on the 2020 Why the heck can’t areas be nested? , @balloob has weighed in on nesting Areas in 2018-19 home-assistant/architecture#94

I don't think that's a good idea. We should keep it simple as it would complicate every interaction with areas to a point where it becomes inefficient to deal with them.
...
Let's see how that evolves Home Assistant first. There is no need to make it complicated from day 1

Further discussion by the devs took place at 2023-24 Add the concept of floors #1021

Related from the HA community:

• https://community.home-assistant.io/t/wth-why-can-t-home-assistant-handle-nested-areas-like-properties-houses-and-gardens/817904
• https://community.home-assistant.io/t/ability-to-group-areas-into-a-larger-area/682101

II. Argument

In light of the robust arguments by no less than the Founder and President of HA and key devs against Nested Areas made earlier, it made sense to keep the Areas simple for a time to see where the community takes it. Having assigned everything to its respective areas, I was able to massively reduce the number of redundant automations (same stuff, different room) by targeting "same area as the trigger was in":
target: area_id: "{{ area_id(trigger.entity_id) }}"

That lowly little template hints at the much bigger notion: Areas hold the key to make automations MUCH more portable & reusable among us! Which, for the most common use cases, can shift us users away from blank-slate, one-off tinkering, solving the same problem 1000 different ways 600 of which are legacy, and towards more collaboration opportunities, putting our heads together refining common blueprints.

Imagine a new user spinning up their fresh new HA for the first time, and instead of a blank slate being asked "Is this for a House, an Apartment, an Office, a Restaurant - or start blank?". Based on selection, a template / super-blueprint is loaded with common automations already in place - just add your devices to the correct areas. Once you do, they just start doing the right thing, effortlessly, based on the best of the HA community experience encapsulated in those blueprints. The user can take it from there, not from a blank slate but "standing on the shoulders of ... a bunch of other guys and gals who've done this before & put their heads together".

But why nested areas? Because it enables semantics and context and lay of the land - it enables a smart home to actually know itself. In a flat list implementation I can name my kitchen area kitchen or pantry or ktichen [sic.] or abcxyz - and it won't matter to the code one way or another. But once smart home becomes aware of pretty granular areas (same level of granularity as mw radar sensor presence detection areas - in fact those should be one and the same as the baseline level HA Areas) and their spatial relationship to each other and how they roll up to rooms and floors, a lot of smarts become possible that thanks to such an Area hierarchy are defined in a very abstract way (hence less maintenance intensive and more transferable user to user / blueprint-friendly - compared to relying on e.g. hard-coded light or sensor groups).
Such spatial (and other area context) awareness can make AI that much more useful also. It as well as radar motion sensors that don't just detect presence but can interpret the direction where a user is going, can help smart home to better infer the user's intent and anticipate.

We're talking having the lowest-level areas defined pretty granularly: down to parts of the livingroom, work stations in the kitchen, individually-lit sections of a walkway, or even steps on the stairway, with spatial relationships between them & their peers (what peer area is to my South - SW - West - NW - ... or up the stairs / down the stairs) - being one and the same with the motion radar detection areas. On top of those baseline mlost granular areas, have 3-4 levels of area hierarchy roll-ups to the top level "Everywhere" this HA instance manages. The higher Area levels would be semantically tagged - am I a complete room, a suite of rooms or a floor, a flight of stairs; am I indoor or outdoor; am I public-access or guest-access or family/team-access or restricted area, etc.

YES, a "Floor" would be a type of area - that HA understands is a floor. Potentially, a Zone might also be folded into the hierarchical Area paradigm.

Imagine your home inferring your intent-in-context based on past patterns, and lighting your way ahead of you even including areas that don't have motion detectors because it knows you'll likely pass there. The more granular the areas, the more fidelity those patterns will have - meaning, confidence on the detection side and finesse on the action side. But without the less granular roll-up / parent areas, it becomes tedious for the humans. I don't want to manually turn off the lights in all 15 sub-areas of the kitchen that are one and the same with the mw radar motion sensor areas, much less list them individually in an automation (goodbye, those blueprints).

So we need to have it both ways (very granular areas AND room / suite or floor / house-level parent area roll-up). We're asking to have it both ways. I support this Nested Areas feature request by @wildekek .

[chefdeit]

This post https://www.reddit.com/r/homeassistant/comments/1hkkcv9/virtual_or_nested_areas/ highlights some of the reasons limiting the use of "flat" Areas as implemented in HA currently.

Nested Areas can help the smart home to "know itself" if the areas are semantically tagged, including:

• Is it a room section | full room | suite / collection of rooms | floor | whole house | zone/region beyond house? What Area is its roll-up parent?
• What peer Areas are neighbors to this Area's South / SW / West / NW / North / NE / East / SE? For each such neighbor, is it directly accessible/navigable or just spatially adjacent but behind a wall with no door / direct passage?
• Is it indoors or outdoors?
• Is it for admin/staff access only | family | guests | public?
• Is it a piece of furniture, a work station, or empty?
• Is it for work | rest | play/recreation | eating and food prep | day | night | morning | evening | storage | seasonal use?
• Is it normally used to stay in or just to transit between areas where people stay?

This metadata that lets HA actually understand the Area's intended use, can enable automations that create useful smart home behaviors purely based on Areas (whatever the sensors or lights or media players etc assigned to those areas, without hard-coding those devices' entities either in Triggers or Actions). That'll make those automations reusable between the rooms, and, more importantly, among the HA user community, whereby we can collectively refine the blueprints vs individually reinventing the bike for each room.

Related: https://discord.com/channels/330944238910963714/1351529028112224359/1391476666978668737

[elentophanes]

As a new user (in the first few days of using HA) this was the first thing that struck me. The lack of a Home wrapper into which Areas could be put. This was apparent to me as the first thing I did after launching and seeing the easy discoverable devices was start the Tuya integration as I have many Tuya compatible devices already deployed in 4 properties.

I've read much of the debate and I see the complexity, but I can also see a clear need for a layer representing a Property or Home, underneath which are areas. While I understand the concept that each property might have a home assistant instance locally which might be accessible remotely, some of the integrations break this concept as soon as you do them.

Tuya supports a concept of a Home and in the Tuya app these are separated. So if you have a HA instance with Tuya integration then the devices appear in a flat hierarchy. I tried using labels to separate them but it was not great so then I separated them by making an Area for each home and making that part of the device config. Then I used the Area dashboard to separate them. But it would have been more elegant if HA could have imported the Home label. A counter example is the MyDlink app where there is no such hierarchy. So the cameras for all the homes appear together. But the count is low compared to sensors and other items so it mostly works. For these I used the generic camera integration to import into the local instances of HA. HA can become the Master over many integrations, offering a clear added value to provide a 'one pane of glass' view which would be enhanced with some form of nesting.

I agree with the concerns of many deep nestings, granularity and overlaps. But a Property or Home is a thing with a clear role in a hierarchy, placeable on a map. Just something to consider, so I support this feature request. And added my own request in the Tuya integration to allow for import of the Home tag.

[roooodcastro]

Piggybacking into this idea, we should also be able to have floors act as a parent area of all the areas within that floor. Reason why is that sometimes we have devices or automations that are in, or target an entire floor, rather than a single area. For example, I can have a scene or automation that sets up night lights for upstairs, or downstairs.

[wildekek]

Piggybacking into this idea, we should also be able to have floors act as a parent area of all the areas within that floor. Reason why is that sometimes we have devices or automations that are in, or target an entire floor, rather than a single area. For example, I can have a scene or automation that sets up night lights for upstairs, or downstairs.

I already have multiple situations where I misuse floors, for example:

• Garden (floor) -> Greenhouse (area)
• Guesthouse (floor) -> Kitchen (area)
  These hacks could just be solved by nesting the areas and getting rid of floors. Floors could just be migrated to an area imo.

[wildekek]

Again a new reason why we need this: Purpose-specific automation triggers & conditions.

When selecting a purpose specific trigger, areas become first class citizens in your trigger now. Trigger example that was in the live stream for release 2026.4: Smoke detected > Area = House. The house area does not exist at the moment though and was just an area made for the demo, so in practice this does not work. The use case is excellent though.

It would be great to have a root area based on the name in Settings > Home information > Home Name. EG "My house". Then all subsequent areas could fall under this root.

[Hedda]

It would be great to have a root area based on the name in Settings > Home information > Home Name. EG "My house". Then all subsequent areas could fall under this root.

Would it not be more logical for the root to be ”My Property” since you can have several buildings on your property other than your main house?

Should you then be able to have multiple root areas so if you have for example a detached garage then it can also have areas for example bike shed, storage room, and workshop.

I am sure others have other types of detached buildings as well, like maybe a barn, a growhouse, a conservatory or winter-garden, a play-house, or different types of sheds or outhouses, etc.

That is, you could have ”the main house” then other smaller standalone buildings on your property, and those are not ”floors” inside the main house.

Then many people with houses have an outdoor garden, with can alao have subareas, which you do want to define as separate areas in order to automate automated watering of the lawn or direct the lawnmower robot or other type of garden robot.

There are also snow-blower robots now so maybe you want your driveway as a separate area from your parking spots so you can direct a snowblower robot to clear the parkingspot when the car is away.

[Hedda]

I think another good use case nested areas would be to direct vacuum robot (or lawn robot) to a specific sub-areas within rooms (i.e. a sub-area inside a room).

The would allow for example to give voice command for vacuum robot to ”clean in front of the cat litterbox” or ”clean the babys spot in the dining room”.