Add the concept of floors

[balloob]

Context

Today we have the notion of areas, devices and entities. Areas represents spaces in your house. We didn't call them rooms on purpose, as rooms imply that there is a physical wall, but a kitchen and living room can be a continuing space yet be each their own.

Devices can have an area, and this area is then inherited by each linked entity. Users can choose to override the area on a per-entity level if needed (some devices can control devices in other rooms, like extension cords).

Areas are also used for other things. Users might have a "Junk" area, a "system" area or an area per person.

In the physical world there is another level of organisation in a house: floors. A house can be multuple floors, and a floor consists of 1 or more areas.

Being able to reason at a floor level is useful in different scenarios:

• Thermostat per floor
• Turn lights off downstairs floor when you go upstairs to sleep

One approach for floors could be to allow nested areas. I think that this would result in a very messy situation as it would allow anything to be done today with an area, to be done with a floor. But a device and entity should be tied to areas, not floors.

Decision

We introduce a new "Floor Registry". Each floor has a name. Areas will be updated to be able to reference the floor that they are part of.

Consequences

• Allow services to target floors
• Allow voice to target floors
• Help with organising dashboards or other parts of the UI
• This is the first building block in case we want to consider floorplans or better integration with robot vacuum maps

[cgarwood]

Allowing nested areas was my initial thought reading this. You mention that it could be messy because it would allow anything that can be done with an area to be done with a floor. What kind of tasks can be done to an area that we wouldn't necessarily want possible with a floor?

[iridris]

I also like the idea of nested areas. I can envision a few scenarios where nested areas would be useful rather than being limited to floors. One such scenario could be grouping all bedrooms together - some bedrooms may be on different levels of the house.

Having typed out that scenario though, I could also envision simply extending the group integration to be able to cover areas. I could then group areas into floors, bedrooms, inside/outside, etc.

[balloob]

A device is always in an area, and not directly in a floor. If you merge the two types, all code dealing with areas/floors will need an if-check to make sure it's a floor. Then why not split it out?

[tetele]

There's nothing stopping us from adding a direct flag for service call targets.

Also, i will argue that I have lots of devices without an area.

[balloob]

Devices without an area are out of scope of floor/area discussion.

Floors are about predictability. This doesn't work if we put the cognitive burden on a user to understand why and when to use direct when calling a service. It would also mean a new flag on every service call in the UI, another cognitive burden.

[tetele]

It would also mean a new flag on every service call in the UI, another cognitive burden.

Only for target selectors, so it would be the same across the board.

[tetele]

I have areas for Frontyard, Backyard, Parking etc. Obviously, there's no floor definition (in the literal sense) which could support that.

These are prime material for nested areas, if you ask me, particularly for voice (e.g. I have a voice satellite assigned to the "upstairs" area, one in the "kitchen" area and one in the "yard" = "frontyard"+"backyard" area).

I do realize a lot of complexity comes with nesting an entity in itself, but given even the generic name "area", I think fits like a glove to nesting and solves a lot of problems.

[balloob]

I think that a ground floor could support frontyard. It will require a new feature for area called outside. If set to true, it's part of the floor but not considered inside the house.

[DenisMir]

And what about a garage? This does not make any sense. Please allow nesting.

[steverep]

Also agree that nested areas is the most desirable approach, but if creating a single nest possibility like this is far more achievable, so be it. It would still cover many use cases.

However, I'd strongly advise against using the term "floors". It implies a style of home that certainly not everyone has (e.g. eliminates most apartments, ranch/bungalow houses, etc.). It would also confuse common use cases like grouping, for example, porch, driveway, and backyard into an outside umbrella area.

BTW, the topic of nested areas is also a largely voted for and discussed request:

• 2022 WTH
• 2020 WTH

[OnFreund]

What you're describing is actually a level, not a floor. A floor can potentially have steps, but a climate device or a boiler, for example, can span a floor.

[Madelena]

Sure, "Level" is a good name, too.

However, when in context of all the other nouns we had introduced in HA, the word "level" can be used in other context such as the radon level in your Geiger counter sensor.

[OnFreund]

The name is just a symptom - it's an arbitrary hierarchy that works for a very limited number of users. Additionally, since it can't contain devices/entities, I don't see the real benefit from it. I could see floors with devices as a temporary step in figuring out the right information hierarchy, but device-less floors seem useless to me.

[steverep]

For a robot vacuum (or anything that rolls around the house for that matter), it needs to know that the rooms are connected and in the same elevation with no steps in between. Robot vacuums are the number 1 recommended smart home devices, so proper support for such concept is needed. With lawnmowers and security robots becoming more and more prevalent, there is a need for knowing the elevation.

A few points of reply here:

• Robots, vacuum or any other, can be carried from one floor to another and probably will be climbing stairs on their own in the not too distant future. By today's common technology, they are about the only thing I can think of that truly cares what floor they are on.
• Lawnmowers work outside on ground that may or may not be level so I sure hope they don't need to know the elevation. One corner of my property is at the main floor level and the other is at the basement, and my lawnmower doesn't care.

[parautenbach]

One corner of my property is at the main floor level and the other is at the basement, and my lawnmower doesn't care.

This person would...

[OnFreund]

How does this proposal address the thermostat-per-floor use case if devices and entities are not allowed in floors?

Side note: I'm also in the nested areas rather than floors camp

[balloob]

That's solved by #1017

[OnFreund]

I'm not sure I follow this. This proposal says that floors don't have devices or entities, but in the other proposal it says:

• Floor level: one climate entity can be defined for heating and one for cooling

Let's say I have one AC unit for the entire floor - it doesn't belong to any area. How would I represent that?

[balloob]

The linked proposal is about configuring what devices have impact on what level of the home (whole home, floor, room). It is not about where a device physically is.

Floors and areas are where a device physically is.

[shbatm]

Would it be possible to just enable devices and entities to be added to multiple areas (with or without the area_class / area_type addition)? This could be done with a multi-select in the UI and tweaking the data structure in the back-end to have reference to multiple area_ids for the device and entity,

To me that seems like a reasonable compromise enabling all the flexibility being asked for here and still enable everything referenced in the original proposal.

For example, for me I have a 2 floor home, with a Family and Kitchen area that are physically one room, but I keep most devices separate in their "room" area, although I need to control ones that cover both rooms frequently. Multiple areas would let me create [Family, Kitchen, West Wing, Main Floor] areas and add the devices I need to trigger in each one--without having to "nest" the areas. For example: Family Room Ceiling Lights->[Family Room, West Wing, Main Floor], Kitchen Ceiling Lights->[Kitchen, West Wing, Main Floor] == "Turn off all Main Floor Lights" still turns off all Kitchen and Family Room lights. You could even add the ability to set a "default"/"primary" area for a device, and use that when generating the dashboards.

[OnFreund]

I'm sorry but I still don't understand. This proposal says:

Being able to reason at a floor level is useful in different scenarios:

With "Thermostat per floor" as an example, yet I don't see how this or the other proposal actually addresses this.

[tetele]

I fail to understand the contrast between the intentional vagueness of the term area (so as not to be necessarily a room, which I agree with 100%) and the very literal meaning of a floor, which is the sum of all spaces at a certain altitude in a home.

If devices are assigned to areas, why do we restrict users to only mass-targeting devices/entities which are physically at the same altitude?

Also, this is in the proposal:

Areas are also used for other things. Users might have a "Junk" area, a "system" area or an area per person.

I haven't seen the use case, but I don't have any visibility to the telemetry data, so I will take that fact for granted. If so, the question is: to which floor should one assign the areas "Junk" or "System"?

The beauty of areas is precisely that you can have a grouping of devices/entities based on topology without defining what that topology is, as each home has its particularities (e.g. open space living/dining areas, outside areas, open areas etc.). The introduction of floors (as an optional container for areas, but specifically connected to altitude) seems limiting at the very least. Not to mention, every single user can use nested areas, but only those with multi-story homes can use floors, which I imagine is only a fraction of the userbase.

I'll try to list a few cases where nested areas would be far more useful than the current concept proposal of floors.

1

Imagine a common, open-space living room and dining room, with an array of spotlights running the whole length, controlled by a single switch. One can't say that the lights are either in the living space or in the dining space. HA knows of the 2 areas (living space and dining space) as there is a "living room TV", "dining table light" etc.
A voice assistant is assigned to the common open space (a parent area). User says "turn on the lights" and expects all spots to be turned on.

2

A frontyard and a backyard, tied together by a narrow corridor outside, plus a "patio" area next to the backyard. Lamp posts in both areas and a light on the patio. A patio heater (climate) on the patio. A parent area called "outside" including the 3 areas.
Imagine the following sentences:

• "turn on the lights outside"
• "how cold is it outside"

3

A house with 2 floors, a groud floor and a first floor. The master bedroom is on the ground floor and kids' bedrooms are on the upper floor. A user goes to bed in the master bedroom to do some reading before sleep and wants to "turn off the lights downstairs" (i.e. in the rest of the groud floor). Obviously floors won't help, whereas a parent area named "downstairs" which includes all ares except the master bedroom would be helpful.

[balloob]

There will always be use cases that are not covered.

I think that the notion between inside/outside could be solved by adding classes to areas. (initially I thought about an outside flag, but system could be a category too).

For 3, I think that it would be ambiguous no matter what. In that case that user would need to set a scene that they activate. I wouldn't want our core architecture to be influenced by an edge case.

[tdejneka]

FWIW, five years ago, I switched from home automation software created 23 years ago (Premise) to Home Assistant. Premise allowed for nested locations (areas). In addition, it allowed for an area_class parameter so you can identify each area's purpose (building/floor/room/yard/bathroom/bedroom, etc). This allowed you to do things like:

• Select all lights in all areas nested within a given area.
• Select all lights in all areas that are bedrooms.

The concept of nested areas (plus area_class) was implemented two decades ago; it's flexible and a great fit for home automation purposes.

---

Regarding this:

Thermostat per floor
Turn lights off downstairs floor when you go upstairs to sleep

Nested areas, where an area can have an area_class, would allow:

• Set all thermostats upstairs, or only the ones in bedroom areas, to a desired target temperature.
• Turn off all lights downstairs and all exterior areas.
• Get average temperature from all temperature sensors in the house.
• Turn on drip irrigation in all garden areas within the backyard area .

[Particpant]

How about this, since some don't like recursion/nesting?
Home->structure->floor->room->area + area & room classes.
I think that might be flexible enough for a lot more setups without causing distress or off-label usage of the various parent and child objects.
A home may have multiple structures (outside could be a 'structure' for this purpose.) Separate garages, sheds, outbuildings, patios, decks, etc.
Each structure can have 1-N floors, each with N rooms.
Rooms can be subdivided into areas. This covers the open-floorplan case where one large room may contain a living /sitting area + kitchen, etc, or even something as simple as a walk-in closet or bathroom that's part of a suite.
Classes would allow for categorization of rooms and areas.

[Petro31]

Not sure why you guys are focusing on my comment. I was offering a possible reason why Frenck may have aversion to it.

[Madelena]

Not only will it be messy in code, it will also be very messy for the UI design as well as the voice commands, if there is more than one level of hierarchy.

Essentially, we will likely need to design and develop something specifically for displaying and controlling deeply nested areas, and that will complicate the UX for the rest of the users who don't need this level of organization.

All that work will delay the feature further, so I'd recommend we go with an MVP first.

[OnFreund]

I think the "messiness" is overstated here. As noted above, the Composite pattern is very common, and has common UI representations.

[frenck]

@isabellaalstrom @AllardKatan I've cleared that up that in this response: #1021 (comment)

[AllardKatan]

@balloob,what exactly is the question here? Is it meant to gather opinions about this concept from the community? Personally, I think nested areas is a much better solution, since I have areas that are part of other areas, and devices that span multiple areas, as well as devices that span multiple floors. The concept of floors would be a sort of nice to have thing in Ha, since my house does have floors, but it would be unnecessary if we had nested areas, which in my view are necessary anyway.

[cvroque]

I find "floor" to be a bad name and definition for this, it would make more sense for most users to call this an "area group". Groups are already understood by the users and also avoids the whole nested area deal.

Otherwise, great idea!

[parautenbach]

Small contribution: I think it should be called level. Floors make sense inside a building, but say your yard has terraces, and hypothetically you want to indicate where the pool is, or if the garden has different levels. I don't think this concept should be limited to only what can be inside.

[OnFreund]

That's even more tricky - floor and level is not exactly the same thing. Some houses have floors that consist of two levels. Some devices belong to an area, some to a level, and some to the entire floor...

[parautenbach]

I actually thought of that case, since I grew up in a home like that. I think this whole concept plus #1017 need more thought.

[Jc2k]

I like the idea of a rigid well defined model. Inevitably not everything will fit. That is just abstractions. But if we weaken the abstraction too much, it makes the abstraction much less capable. Eg I think the proposed information architecture unlocks a lot of potential for the default dashboards. A looser architecture doesn't necessarily rule that out, but I think it does make it harder.

Floors are useful within a house. But what is the expected usage for spaces that aren't on a floor in the house? I wouldn't want the shed, garage, drive or back garden to be in the same floor as my living room.

From an implementation point of view, I can see why nested areas would be a problem. I wonder what are the use cases for doing it anyway, is nesting the only solution? The only use case I have for nesting doesn't need infinite nesting - I want to treat my living room and dining room as a single space in some situations (mainly heating).

[AllardKatan]

I see the point of knowing the relationship between areas, I don't think the proposed structure is optimal in achieving this, since it is limited and doesn't work for the large group of users in apartments and bungalows. If there were more levels, and the levels could have a user-specific 'friendly name', I think it would help users to make the structure of their Ha instance reflect the physical structure of their home. Six levels of hierarchy should cover the vast majority of use cases I think, in my case I would only use five (property, building/yard, floor, room, area). If I had only floors and areas, it would be difficult to reflect that the garage is much more separate from my living room than the open kitchen.

[OnFreund]

I think it's not just about the hierarchy, but also the ability to have devices and entities in other levels and not just the leaves. Even the perfect hierarchy is going to be lacking if floors/levels/etc will not be able to contain devices.
And since it's very clear from the comments here that people want devices not just in leaves, they'll find a way to do it, and it's going to be even messier (e.g. a "misc" area in every floor for the thermostats, boilers, etc...)

[isabellaalstrom]

I don't see the problem with having a floor and an area with the same name to contain all devices that spans the whole floor, or as you said a "misc" area for those things? But the hierarchy would be kind of put out of play when you have a thing that might span several floors (stairs, facade lights) or the entire house (ventilation). If you have a "house" area for those things for example, it would be outside of the hierarchy since it doesnt belong on any floor.

[AllardKatan]

If I understood this correctly, the other proposal (#1017) should cover the devices that affect multiple areas, and this would be decoupled from the hierarchy. What isn't covered by that (or this) proposal AFAICS, are devices that physically extend over multiple areas and areas that physically extend over multiple floors.

[OnFreund]

Right, that's why I think a good hierarchy is also important.
I do think the "misc" area feels like a hack though, and using the same name as the floor could cause confusion when used over voice, etc...
Maybe it could be implemented behind the scenes as a separate area, but only exposed to the user and assistants as a composite.

[elupus]

With area class, and allowing things to belong to multiple area classes, that mostly solves the most idea no?

[balloob]

Area classes can help with some of the use cases that users have brought up as a reason not to add floors. I am hoping someone wants to write up a proposal to explore this idea as this seems like it can help solve issues that people are experiencing.

I would be against having something be part of multiple classes. It would cause the abstraction and Home Assistant to become very complicated to reason about and would not be a benefit to our users.

[isabellaalstrom]

@balloob The concept of area class seems to be able to solve many of the problems. I was going to open a discussion about that, but then I saw that the intention of the person opening a discussion should be to implement and I do not have the time of knowledge to do so. But it also seems to be off topic in this discussion?

[isabellaalstrom]

What would be a good way of handling this scenario:
A house with an area each for:

• Backyard
• Patio
• Entrance
• Driveway

Ideally I would like to have the area class "outside" for all the areas, since they are indeed outside and there are a lot of cases where I would like to control for example all outside lights. But I would also like to have the Patio and Backyard have a class for "living space" or something like that, and the Entrance and Driveway in another class that I can't come up with a name for right now. Since I don't hang out in the entrance or in the driveway, there is a lot of cases where I would like to be able to control all the lights, or music or whatever in the living space of the outside, and also a lot of cases where I would like to control only lights that are not in the living spaces.

I feel like this is a common scenario, and not only for outside areas of course, so I don't believe this would be solvec by both area class and outside boolean for example. The example of an open area, that are quite common these days I think, indoors where kitchen, dining area, living room and maybe even a small office space shares the same room.

This would be a complement to the floor idea, not a substitute, even if floors too could be achieved with only a multiple select area class (that you could yourself pick names for, just like areas).

[OnFreund]

I guess it depends on whether areas belong exclusively to one "floor". If they don't, then you can have a "floor" called Outside that includes all 4 of these areas, a "floor called Living Space that includes the Patio and Backyard, etc...

[OnFreund]

What I think is clear though, through your use case and others mentioned here, is that at some point there has to be a many <> many relationship. Whether its floors <> areas, or area classes <> areas, or nested areas.
Many to many relationships are complicated and hard to comprehend, so I get the apprehension, but I don't think they're avoidable in this case, so acknowledging that we need them and discussing the best way to reduce the complexity would be a more fruitful way to conduct this. Otherwise we're just stuck in the floors vs nested areas debate and neither side will be able to convince the other.

[isabellaalstrom]

This is a really disappointing step for me. I don't know how many of Home assistants users that actually have more then one floor at home at all, but this is really a change that will only cater to a specific type of home. Excludes almost all users in apartments (except the few that has two floor apartments). I am really disappointed, when the change could be more generic and cater to almost all users instead (with some other kind of area grouping). I will most probably try to use the floor feature for something in my one floor apartment, but it will be ugly and not as intended. I realize not all changes will be usable to all users, but this could, with not a lot of design changes, give so much more functionality to a broader user base.

[parautenbach]

I've only followed the discussion until now – with interest – and my impression is that this should be parked for a little while to allow the ideas to simmer. If an implementation was to go ahead where there isn't strong concensus (and I know one cannot demand concensus here), I would bet on some breaking changes soon after.

Is there really no existing taxonomy one can base this on? I'll have a look (search)...

[cogneato]

I can see the concern but after thinking about it more: all homes have a floor. The fact that some homes have more than one should not mean that a more amorphous nest of vague things should replace the concept of a floor. Whether a single floor or multiple, it could add value for suggesting organization of automating tasks where it makes sense. As long as it doesn't box anyone into a corner, adding the concept of floors would apply to all homes.

[parautenbach]

My point is not everything you control is inside your house/home.

[isabellaalstrom]

@cogneato Sure it applies to all homes, but it doesn't add any value as far as I can see to everyone with only one floor. Of course everything doesn't need to give value to all users, most things probably don't. But the reason why ppl are upset by this I think is that it seems so close to something else that would give a tremendous value to a lot more users, but is not quite there.

[zyberzero]

I think a floor with areas connected to a specific floor is a bit too rigid to be honest. It semi-works for those of us who actually live in a building with several stories, but probably makes less sense for apartments.

I think that some kind of nesting is needed - perhaps not nesting per se but in some way make an area more... aware. One part of my house is very open (Dining room, TV room and an entrance hall are connected) - areas is somewhat limited as I sometimes want to use them as one room (for instance, turning off all lights if someone sleeps on the sofa and lowering all blinds), and sometimes I just want to control the devices in the TV room part.

I like the area_class idea mentioned earlier, and towards that I think that annotating devices would be awesome! For instance, to be able to classify a light as ceiling light - wouldn´t it be awesome to be able to instruct HA to turn off all ceiling lights in all bedrooms on the 2nd floor?

An alternative would be to be able to give an area multiple annotations, for instance (floor 1, kitchen), (floor 1, TV room, open space) and (floor 2, bedroom). This also solves problems with multiple buildings on a property - for example a garage, a guest house and shed). Then one can assign a label "unpopulated" to those areas, and have automations target all motion sensors in those "unpopulated areas" for instance. And the best thing; It has a lot of flexibility built into it! By limiting it to "just" floors I think users would need to "shoe horne" their homes to fit the HA model.

TL;DR: I think the initial problem can be solved without introducing another concept, altering an existing one is probably enough (without me knowing a single bit of the actual implementation mind you - the devil is in the details so there might be technical reasons that I am not aware of)

[MacDada]

I'm still reading the whole discussion, but I want to point a name to this concept: tags ;-)

Or it can be groups. Anyway: the point being: a more general term than floor, that allows a device to belong to multiple spacial categories. And not only spacial! What about like morning routine devices tag? Or party gadgets tag?

Tags are flexible. With tags I don't need areas anymore, btw :P Just rename areas and allow multiple, haha! Yep.

[parautenbach]

I too like the idea of tags, but I think people here want an explicit structure that can be traversed.

Btw, you can actually tag any entity today through your customize.yaml. It's not necessarily easy or elegant, but just want to mention it.

[OnFreund]

Tags are useful if they can be the target of service calls. Does your customize.yaml solution support that?

[parautenbach]

Good point, that would be useful.

You can technically find all entities with a specific tag – using selectattr – and loop over it (repeat) to make the service calls.

[Nornode]

To set things clear, I'm the corner Nested-areas/group's of areas or something different...

I live in a three level house.
I would be a prime user of the "floor" concept. - Awesome!

However, immediately I see several troubles with the idea.

1. Vastly different areas on the same floor: I have the garage on basement floor.
   I do not want to involve anything in the garage while switching the living/entertainment space. Garage is still part of the same floor.
2. Stairs: I have stairs between the floors which is exactly in between floors, to which floor am I supposed to add those?
3. Spaces outside: Patio, garden, driveway, front-garden, terrace... They are all defined areas and are technically on the same "floor" but also have very defined sub-groups: [patio,terrace],[garden-patio],[driveway,front-garden],[garden,front-garden]...
4. We have an open living room, kitchen, hall way and library area. It's too big for one area, I still not the whole floor.

These are a few use cases that leaves me to wonder:

How should I use the "floor" concept? 🤷‍♂️

Im afraid that the concept description by @balloob there are some real-world examples that are missing from actual use-cases and the notion of "floor" is not perfect.

The suggestion about area_classes might interesting that would be even more flexible and useful (but a complex concept for beginners, yes). Continuing on that thought and adjusting "area_class" to become "tags" instead would be an even more flexible way of organising your devices, entities and areas, but I think I get ahead of myself here❓

With this message, I hope to express that the concept of "floors" does not seem well thought through and is not covering all intended use cases. I hope and wish that it'll be brought up for discussion again taking all above comments in mind.

[frenck]

Ok, my response was requested; let me write up my thoughts and start with a quick TL;DR, as this story became bigger and more extensive than I initially thought it would be.

Let me be clear: This post reflects my personal opinion and vision.

I tried to write it in an extensive, serious, but also a little fun way, which I hope can be appreciated; but I also realize this is quite a long brain dump. Anyways... here it goes.

---

TL;DR: In my opinion, most responses here in this architectural discussion are missing the point of this proposal. I support this proposal for floors very much and think the whole area discussion (nested or with classes or not) mostly derails this proposal. It is an entirely different discussion, and such a proposal doesn't exclude this floor proposal from being invalid at all.

---

Now you've read that (and maybe even feel jumpy to respond to that negatively), let's dive deeper...

Type of organization

When it comes to categorization/organization of your smart home, we could roughly distinguish two types:

• Physical representation
• Non-physical representation

The physical representation reflects the actual physical location of your home where the device resides.

A non-physical representation could be anything you can think of, maybe some kind of categorization of the type of battery a device uses, or the "sort of lighting" the light fixtures in your home provide.

Another critical difference between those two is that an object can only be physically in a single location at the time (yeah, science!). At the same time, a non-physical representation isn't bound to such limits (well, except for those of your imagination).

With this in mind, let's look at the current situation of Home Assistant before we dive into these subjects further.

The current situation

When looking at our current organizational/categorization structure of Home Assistant (as part of the larger information architecture), boils down to the following things:

• The home
• Areas
• Devices
• Entities

"Frenck, you forgot about integrations and groups!" Oh, yes, I did. I'll return to that later, but let's forget about those momentarily.

Home Assistant represents your physical house, which has physical areas where your physical devices are in that provide one or more sensors/controls for physical devices in the form of entities.

Are you catching a theme there?

Let's dive deeper into each of them, keeping areas for last (as that is the hot item here 😅).

The home

The biggest, top-level category Home Assistant provides is your actual home, and it does so by being there.

Everything in Home Assistant represents "stuff" in and around your house. Your house is physical; it is in a location somewhere on this planet. One exception might be an RV you drive around (but hey, we even support that!)

Sure, you could create an imaginary castle in the skies, but let's be honest, for the general use case, Home Assistant represents your physical house (and its surroundings) digitally.

Well, to a certain extent, of course, as it is limited to your smart devices and services.

Devices

Devices represent the physical smart home devices you have in your home. This can be your AC, HAVC installation systems, solar panels, covers, lights, and many more.

These devices are all pretty much real. You can hold them and place them around your house. They are thus a physical representation.

"But, Frenck, what about the weather? The sun? Or the garbage collection schedule services"

You are right; this is an oddity in Home Assistant. Hence, we call it "Devices and services".

Internally, those are the same things for Home Assistant. Weather service is internally considered just as much a device as your Hue blub; Home Assistant does, however, represent it as a "service" (which is an internal flag on the device to represent it as such).

Yet, these still provide information and data bound to your physical home. Remember, I wrote above Home Assistant represents "stuff" in and around your house.

The sun data is tailored to your actual home location, the garbage collection is bound to the schedule when they pick things up from your home, and the weather is aimed at providing information about a physical location as well.

Entities

A device provides one or more entities. Entities are the most detailed/smallest/finest representation in Home Assistant. You could see them as the actual data point.

Entities provide the information and controls for the different properties of a device. This can be the sensor entity that tells you your home's temperature or the switch that turns on your TV.

They represent the devices' properties and controls in your home.

Area

OK, ready? Time for areas.

Areas represent the physical spaces in and around your home and are groupings of the devices within your house (and thus also your entities).

Areas represent the physical location of physical devices. As these are physical representations, it means a device can only be in a single area at a time.

Entities, by default, inherit the area the device is in. But, we do allow overriding those on an entity level. The reason for this is that some devices extend to different areas. For example, a wall switch could provide a switch entity that controls a light in a different area than the switch device itself is actually in.

Fun fact: most other systems out there call these "Rooms". When introducing areas, the term "rooms" was very much considered.

But we didn't go for "room" as a term, as not all homes have clear spaces that are rooms. For example, if you ever watched me live on YT, you might have noticed I have my office in my living room. I also have an open kitchen, making my kitchen, office, and living room basically one big single open room.

That is why we called them "areas" and not "rooms". (Please note, this wasn't modeled after my home; I didn't even have this house at the time).

But, no matter if they are rooms, spaces, or areas, they represent the same physical spaces.

I can already hear you think by now: "Frenck, I use areas to group persons", "Frenck, I have an area for my system-related entities and devices", or "So, what has this to do with nesting or floors?". Hold on, this story/writing isn't done yet 😉

What about integrations?

So, integrations integrate Home Assistant with devices and services and bring them into Home Assistant. For example, a Philips Hue hub brings in multiple devices (and their entities). Each of those can be in different areas within your home.

Integrations, while bringing in multiple physical devices, are a non-physical categorization. Primarily by brand, protocol, or whatever reason, there is to be a separate integration for those devices or services.

An integration can provide multiple devices & entities, and multiple integration can also provide multiple entities for the same devices.

Let's chat about groups

A group in Home Assistant (documentation), allows you to bundle different entities into a new entity you control and monitor as a whole.

This can either be a replacement of multiple other entities (e.g., a light fixture with three bulbs you control as one), or an additional control to control a group while maintaining individual control as well.

Groups work only on the entity level. You can't group devices.

Groups can be either a physical or a non-physical representation. You decide how you use them. Maybe you have a group of lights called romantic lights or something? Things like that are fine.

What is wrong with the current situation?

Nothing! However, there is a bigger request/need for more ways to organize our systems. Various forum topics and feature requests show this over and over again.

The biggest example of this might be the request for folders, categories, maps, directories, or labels to categorize one's automation. This is about the highest vote request out there right now.

Looking at the current situation, Home Assistant mostly tries to represent your physical home. While there is a clear need for non-physical as well.

As a workaround, most of us have started to use areas to work around the problem (I admit, I have areas for persons, systems, unused stuff, and other things myself as well).

Honestly, I think if "areas" were to be called "rooms" from the start, it would have been more clear in its purpose, but I honestly also think the intention of calling it "areas" still make a lot of sense.

Floors

So, this discussion is about floors. Floors are also a physical representation of your home and represent a group of areas (or rooms) in your house.

Floors are not areas; you cannot assign devices or entities to them. The devices or entities on a floor are inherited by the areas a floor has.

It helps Home Assistant to know more about your physical home. For example, turn off the lights upstairs or in the future, being able to represent things like temperatures on floors as well.

Let's face it: many homes have multiple floors. Sure, many are in apartments or bungalows and thus will have a single floor.

For the latter, this feature/proposal will not have much benefit. But it is a more correct representation of the physical world.

Having floors is a good and matching representation of reality that can help us in the future (A.I. stuff, maybe?), things like voice control, but also helping us improve things like automatically generating or suggestion dashboards to make.

Additionally, floors are an excellent target for automations. For example, turn off all the downstairs lights as part of a bed routine.

Anyways, floors provide additional information about your physical home.

Area classifications

It was mentioned short a few times in this discussion already. We need to learn more about what areas are useful for them. I fully agree!

For example, an area outside, like a garden, might need different handling. Hence, Paulus mentioned the outside flag on an area above. This was briefly in a PR, which I've reverted for now. I think there is some really good feedback & ideas in this discussion around this.

I fully support the idea of classifications of areas. I can think of "bedroom," "living space," "kitchen," "garage," "shed," "balcony," "garden," and many more as a nice way to give more intent/hint on how the space/areas are used.

We could do a lot of smart things with those!

Is the same as floors? No, not really. A floor could be a larger area with other areas in it, with a "floor" classification. This will quickly bring us to the topic of nesting, which I will dive into in a second. That said, assigning entities or devices to a floor instead of areas on a floor seems wrong to me.

Nested areas

Alright, still with me? Time for the hot topic! Wassup with nested areas?

Honestly: I don't know. 😁

From a software perspective, in general, I think nesting is always tricky and prone to unexpected behavior or issues and should be avoided. But... that doesn't exclude them from being a viable option in the long run.

I've really tried understanding why people want nested areas, and the main reason I've found was: Dividing rooms into even smaller areas.

One of the best examples I've found was: Having a "desk" area in your "office" area.

I think this example makes a lot of sense from just that perspective. But the question is: Why is that extra division needed? Is it for controlling just the lights around your desk as a way to group? Why not use a group in that case? or something else?

What I do know is that this is a separate discussion from having floors. I don't think floors kill the option of having nested areas in the future (which is a different architectural proposal/discussion). I do question its validity, but again, different discussion 😉

More non-physical categorization

As already shortly pointed out above, there is a clear, bigger need for more non-physical categorization. Organizing stuff the way you want, freely as you see fit.

The biggest example of this might be the request for folders, categories, maps, directories, tags, oor labels to categorize one's automation. This is about the highest-voted request out there right now.

There are plans to address those; the challenge is making the UX for stuff like these work well. That is being looked into! (Promise!)

Personally, I would love to organize my automations, scripts, scenes, and even zones into some kind of folders or categories that I can use as a non-physical way to organize the way I see fit for my mind.

I've also have a POC open for labels that could be put on basically any physical thing in the home (areas, devices, entities), which would give me a non-physical categorization/organization that is fully flexible and usable as a target even (turn off all the devices marked with the label "energy-inefficient" when the solar power is dropping below a certain value and things like that).

All of this... still... doesn't make the concept of floors less viable (or any of the other many, many cool suggestions in this discussion).

As a matter of fact, I think floors are a really good physical property of many homes in the world that will fit a Home Automation platform really well. It might not fit everybody and every use case, but it will definitely fit a larger group of users.

../Frenck

PS: I spoiled it a little bit above a bit, but I will do it explicitly here now too: We are actively working on making categorization/folders and labeling happen (in a few releases it should become available).

[Particpant]

Could the solution to this big debate be as simple as introducing Room and / or Space? Area can contain these.

My suggestion was that areas are a child of a room / space.

Combined with tagging/classes "area / room x is a bedroom / bathroom / garage / kitchen" I think that covers a lot of what folks have requested. There's certainly a lot more, but it would cover a lot more of what people are asking for. The ability to subdivide a contiguous space/room (via areas), the ability to classify a space/room/area by purpose.

[AllardKatan]

Thanks for the extensive reply Frenck. I was a bit busy with other stuff the past few day, but I still wan to react. There's something that you write that I think is a mistake. You say: "As these are physical representations, it means a device can only be in a single area at a time." . I disagree. And not just because I work at a Quantum Physics department :-) . I have devices that span multiple areas, and areas that span multiple floors. I even have devices that span multiple floors. I think it is a an unphysical thing to say that devices can only be in one area.

[forensium]

Tags or labels.

Make the location into tags or labels.
Allow things to be associated with multiple location tags.
Allow location tags to be associated with other location tags.

This would take care of the rigidity of hierarchy, without losing the functionality of the structure.

[EDelsman]

A major question to be asked is at what level the additional grouping is required. Although there's something to say for devices spanning multiple area's, the implication is that every device or entity needs to be categorized. I would advise against it for that reason alone. I would apply the proposed new categorization applies to areas, which is much easier to understand and maintain.

Frenck's description of HA boils down to named hierarchy levels: every level of the hierarchy has a well defined name and purpose. It adds structure that for instance voice assistants can use, but it at the same time has all the limitations of hierarchies. Floors are a logical extension to this structure, but with the disadvantages of a limiting definition and being bound by the same downsides of hierarchies. An area class has a less limiting definition but still all characteristic of a named hierarchy level.

Adding a free form hierarchy loses the benefit of named levels, but keeps the limitations of hierarchies. Although it was my initial favorite, thinking about Frenks post it is no longer. It dilutes the clarity of the current conceptual design. A named hierarchy level allows for the concepts of e.g. the current floor. Almost all other options do not make this easy.

Adding labels/tags to areas lifts the limitations of hierarchies by adding the many to many properties at the loss of a defined structure for the labels themselves. That is not to say there is no structure to them. Structure is only implied by name, making sense to the user and still enough to be useful for voice control. To me that is both the most flexible, and cleanest solution that would still make sense to users. It covers floors, levels, area classes, and the like, and adds a true new flexible concept to HA without diluting the beauty of the current named hierarchy levels.

The concept of area groups is very much comparable to labels, and a concept already present. That would be an argument in favor. However it makes it hard to see what groups an area belongs to.

[tdejneka]

I support the idea of labels/tags.

It was proposed, over 3 years ago, as a means of categorizing/organizing many things (devices, entities, areas, automations, etc). It was forward-thinking at the time and still is.

https://community.home-assistant.io/t/put-automations-scripts-in-folders-groups/219510/5?u=123

[eliasisrael]

Simple question: What floor is my staircase on? ;)

I once worked on a smart buildings project, and I can tell you that dividing physical spaces logically and reliably takes a lot of careful thought.

A "big picture" breakdown goes something like this:

• Portfolio (a collection of disconnected but related properties)
  • Site (a single contiguous piece of land with interesting things on it)
    • Structure (a single building. perhaps a house, or a shed, or an office building)
      • Floor
        • Hallway
        • Suite
          • Room
      • Staircase (an interior, pedestrian passage for traversing two or more floors)
      • Elevator (a motorized staircase connecting exactly two floors)
      • Escalator (any room that travels between two or more floors)
    • Vehicular Path (roads, driveways, ...)
    • Vehicular Parking
    • Pedestrian Path
    • Open Space (forest, park, lawn)
    • Water (lake, river, pond, etc)

That's off the top of my head. I'm pretty sure the actual map was much more complex. Of course, not all of this makes sense for a residential space, but more of it does than you might think.

Everyone pictures their own house when they try to think about this problem, but people live in all kinds of arrangements and a simple "floor" abstraction is far short of what they actually use.

[UKenGB]

I think frenck's explanation was most helpful. But…

As he admits, Floors do not solve the larger problem of FLEXIBLE categorisation. I emphasise that word as all the comments here show that a lot of people have very different ideas about how they want to be able to categorise.

IMO, nested Areas would be the ultimate solution, in which any Area can be nested in, or contain any other Areas and/or also contain actual devices as they currently can. In this way it is not restricted to any physical hierarchy, but instead can represent the home in any way the user wants and becomes as flexible as labels/tags.

That would also provide inheritance, so that adding a device to an Area, would automatically add it to any containing Areas, which is something I cannot imagine labels/tags (or any other form of categorisation) being able to provide, yet is so important. Not just for initial setup, but for ongoing adaptation and maintenance.

Personally I would then have no need for Floors as nested Areas would be able to provide all that functionality and more. Whether Floors and/or labels/tags are implemented or not, I think nested Areas would be the ultimate form of categorisation as they would provide the most flexibility and lowest ongoing maintenance for all users.

[frenck]

The basic concept for floors has been merged in: home-assistant/core#110741

Closing one for that reason.

[potelux]

Thank you, Frenck, for all of your work on this issue. I see that you have committed thousands of lines of code to this issue (as well as Labels and Categories).

It seems that the biggest debate on Areas is whether or not they should be limited to purely physical lines. Clearly, the HA team has decided that Areas are physical and should remain physical. Many have provided examples (such as stairs) that span multiple Areas, but, by the definition provided above, these are not Areas (some may disagree with the definition, but it is the decided definition). If an Area is a physical delineation, then a staircase is not both upstairs and downstairs, it is in neither location. Yes, the staircase connects the two floors, but it is effectively floor 1.5 as it floats between the two.

On the other hand, the need for groupings that are not delineated purely by physical lines is clearly a great desire in the community. An HVAC system is physically in the basement, as are the zone controllers, but the zones affected by the system are spread throughout the house. Some of the zones may fit neatly into an Area, while others may span multiple Areas or even an entire Floor. A kitchen island in an open concept is physically in the kitchen, but the lighting on the backside may be more fitting as part of the living room. While you could change the entity location for those lights, that would not be their physical location and therefore be inconsistent with the ideology of Areas. Lastly, as mentioned above, the goal of HA is to be an automation system, so it makes the most sense to have the setup of new devices be automated. The manual addition of entities to existing groups is inherently not automatic.

In other words, we need to divide the concepts that Frenck mentioned earlier more clearly. Areas are meant to be physical, but there is no sufficient logical (non-physical) alternative. Perhaps this distinction warrants a new naming scheme. Areas become Rooms, and Spaces are introduced.

Currently, Categories and Labels are both under development with registries for each. I suggest we all wait to see if these can be used to sufficiently achieve the logical delineations/groupings.

[potelux]

For those looking for a more immediate solution, I have an approximate workaround. I call it the "Template Area".

I creating template sensors for each sensor type (only sensors are supported). Each template automatically groups the sensors values based on an area, and then I assign all those template sensors to an Area of their own.

In other words, I have an open kitchen/dining room/living room that are Areas, as well as an Area that represents the "Great Room" (which is a combination of all three areas). The "Great Room" is mostly comprised of template sensors that automatically gather the data from the sensors in the respective Areas. For example, my "Great Room Temp" sensor is a template that loops through all entities in the Kitchen, Dining Room, and Living Room that provide a temperature and averages their value. This sensor is assigned to the "Great Room" area. I also assign real devices directly to the "Great Room" Area if they span the whole Area (like my in-ceiling speakers).

The benefit of this approach is that any new sensor added to any of the real Areas is automatically reflected in the sensor value of the "Template Area".

[frenck]

Clearly, the HA team has decided that Areas are physical and should remain physical.

Yes.

Many have provided examples (such as stairs) that span multiple Areas, but, by the definition provided above, these are not Areas (some may disagree with the definition, but it is the decided definition).

Yup, and it is not in the scope of this architectural discussion, as pointed out many times before :) None of this proposal excludes any such possible discussion/change in the future.

Currently, Categories and Labels are both under development with registries for each. I suggest we all wait to see if these can be used to sufficiently achieve the logical delineations/groupings.

Yup, that is the current aim :)

../Frenck