Problem statement
Home Assistant currently models physical space using two distinct concepts: floors and areas, where floors are essentially groups of areas. While useful for basic organisation and dashboard grouping, this two-level hierarchy is too rigid for the wide variety of real-world setups users have.
The limitations are becoming more visible as we make location-based targeting easier. Recent improvements in #2 have made it simpler to target areas, but users now run into the ceiling of what the current model supports:
- No way to target an entire home (or: "structure"). Users with multi-floor setups cannot target everything at once. If they add a floor later (in HA, not physically), they must update all affected automations manually.
- No support for multiple buildings (or: "structures"). Users managing a house, garage, garden shed, or guest house from a single HA instance have no meaningful way to model this.
- No sub-areas. There is no way to define a closet inside a bedroom, a coffee nook inside a kitchen, or any other partial or nested spatial concept.
- Floors are a separate concept, which adds conceptual overhead and limits flexibility. The distinction between "floor" and "area" is arbitrary from a modelling perspective.
As we lower the barrier to location-aware automations, this structural rigidity makes Home Assistant feel less capable, not more.
Community signals
- This Discord thread sparked from the 2026.4 release party chat
- This feature request asking specifically for nested areas (which is also, at the time of writing, the third most upvoted feature request in the "core functionality" category)
Scope & Boundaries
In scope
- Replacing the floors + areas model with a single unified area concept and nesting
- Introducing the concept of Area type (e.g. structure, floor, room, outdoor space) — exact taxonomy TBD
- Inside/outside designation
- Level field for floor-type areas
- Migration of existing floors and areas
Not in scope
- Changes to how devices and entities are assigned to areas
- Dashboard layout changes beyond what is needed to support nested areas
Foreseen solution
Replace the current floors + areas model with a single, unified area concept that supports nesting. Floors, rooms, buildings, gardens, and sub-spaces all become areas, distinguished by metadata rather than by type in the data model.
Key aspects of the proposed direction:
- Remove floors as a separate concept. Everything becomes an area. Existing floors migrate to areas automatically.
- Area nesting. An area can contain other areas, enabling structures like: Home → Floor 1 → Kitchen → Coffee Nook, or Property → House → Garden → Shed.
- Area type. Similar to device class, users can specify what kind of area it is (e.g. structure, floor, room, outdoor space, garden). The exact taxonomy needs to be defined, this is an open question.
- Inside/outside designation. Areas can be marked as interior or exterior, enabling automations and dashboards to reason about this distinction. How we achieve this is an open question; we might use the area types for this, or have a separate setting on each area.
- Level for floor-type areas. When an area is typed as a floor, users can optionally define its level (e.g. -1, 0, 1, 2) to preserve ordering and context.
This approach preserves the utility of floors while making the model extensible enough to handle the full range of real-world setups.
Risks & open questions
- Migration path. Existing automations, dashboards, and scripts that reference floors need to continue working. The migration from floors to areas must be seamless and ideally automatic.
- Area type taxonomy. What is the right set of area types? Too few and it's not useful; too many and it becomes overwhelming. This needs input from the community and potentially from UX research.
- Performance and query complexity. Unlimited nesting could affect how efficiently HA resolves area membership for automations and dashboards, especially in large setups. Perhaps we should limit this, but then the question becomes: what is a reasonable limit?
- Dashboard and UI complexity. The current area-based dashboard and device organisation UI was designed for a flat model. Nesting adds complexity that needs careful design work.
Appetite
No response
Execution issues
No response
Decision log
Problem statement
Home Assistant currently models physical space using two distinct concepts: floors and areas, where floors are essentially groups of areas. While useful for basic organisation and dashboard grouping, this two-level hierarchy is too rigid for the wide variety of real-world setups users have.
The limitations are becoming more visible as we make location-based targeting easier. Recent improvements in #2 have made it simpler to target areas, but users now run into the ceiling of what the current model supports:
As we lower the barrier to location-aware automations, this structural rigidity makes Home Assistant feel less capable, not more.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Replace the current floors + areas model with a single, unified
areaconcept that supports nesting. Floors, rooms, buildings, gardens, and sub-spaces all become areas, distinguished by metadata rather than by type in the data model.Key aspects of the proposed direction:
This approach preserves the utility of floors while making the model extensible enough to handle the full range of real-world setups.
Risks & open questions
Appetite
No response
Execution issues
No response
Decision log