WTH: Why Can’t Home Assistant Handle Nested Areas Like Properties, Houses, and Gardens?

Month of "What the heck?!"
1

I love Home Assistant, but I’ve always felt like the concept of areas is missing a crucial element: proper hierarchy and nesting.

Here’s my real-world example:

  • I have a property that contains a house, a garden, and a parking lot.
  • The house is made up of different floors, and each floor contains various rooms.
  • The garden has multiple zones, like a front yard, backyard, and vegetable patch.
  • The parking lot is another distinct area, with its own devices like lights, sensors, or even an EV charger.

In Home Assistant, areas are flat and unstructured. There’s no way to define a property as the top-level entity, then have a house, garden, and parking lot within it, and further nest floors, rooms, or zones under those.

Why does this matter?

This lack of nesting creates practical challenges:

  • Context: It’s hard to understand where a device or automation belongs in the bigger picture of the property. A nested structure would make navigation and device organization more intuitive.
  • Automations: While Home Assistant supports area-based automations, the lack of nested areas makes it difficult to apply automations to hierarchical groups. For instance, there’s no easy way to apply an automation to “everything in the garden” (including all zones) or to “all rooms on the first floor.” The same issue applies to managing all devices in the parking lot.
  • Scalability: For larger setups, managing a flat list of areas becomes unwieldy. Nesting would make it easier to organize complex setups like properties with multiple distinct areas.

Suggestion: Nested Areas

I propose introducing nested areas in Home Assistant. This would allow users to:

  1. Define top-level areas (e.g., Property).
  2. Nest sub-areas within them (e.g., House, Garden, Parking Lot).
  3. Add finer subdivisions (e.g., Floors, Rooms, Garden Zones).

How this could work:

  • Hierarchical Grouping: Devices and automations could inherit attributes and properties from their parent areas, simplifying configuration.
  • Automation Flexibility: A nested structure would allow targeting broader groups (e.g., “all devices on the first floor” or “all devices in the parking lot”) while still enabling precise control over individual rooms, zones, or sub-areas.
  • Improved UI: A tree-like view of areas would make the Home Assistant interface more intuitive and aligned with how we naturally think about physical spaces.

Closing Thoughts:

It feels like the current implementation of areas was designed without this kind of hierarchy in mind. A more flexible, nested approach would better reflect how people think about and organize their homes.

What do others think? Is this a “WTH” moment for you too?

2

This has been discussed at length by the devs. The conclusion from the devs was that nesting causing too many issues and is, for now, not happening. It may be revisited in the future.

For now, labels and categories are your “nesting” tools.

3

Labels, categories, and floors.

4

I agree as they are all zones and you call them ‘nested areas’ but as a basic database construct they are just parent-child records that likely 3 tiers is all that is needed.
The key (index) of the parent is the foriegn key of a child and that is a 101 for standard parent child records.
They are all zones and its just choice what you might name them.
Skyscraper->Floors->Rooms for example
They are just one thing and that is a zone, that you name

5

Thank you for your good arguments, I didn’t think of if from the database perspective, but more from the actual architecture point of view on how the property is built, so I can think of area as a container with info vs an actual landscape drawing. I will make it work.

6

Related WTH:
WTH: Area groups
WTH: Why aren't areas structured like tags (to add devices/entities to multiple areas)?
WTH: Why can't we classify areas as Interior or Exterior? 🏡

1 Like