There’s a related architecture discussion here: Improve information architecture for Home Assistant · home-assistant/architecture · Discussion #1017 · GitHub that lays out the justifications, probably worth reading.
Both discussions have the same deficiency in common, they fail to show how the concept of floors is superior to nested areas (especially if an area can be assigned a category).
My automations control locations on my property that are outside of my house (pool, patio, gardens, lawns, etc). The floors concept cannot model those areas in a meaningful way. Similarly, it can’t model a bedroom’s walk-in closet or ensuite bathroom whereas nested areas can.
1 Like
I didn’t say I agreed with the justifications, or thought them good.
I posted a very long reply disagreeing with the rationale in the discussion.
1 Like
One can hope that this addition of ‘floors’ is a first step towards creating nested areas, which I understand could lead to unforeseen complications. Some of these complication might be dealt with after the introduction of ‘floors’, making the troubleshooting later less involved. I see no indication that this is the intended path, though
1 Like
It’s more than likely will be the opposite effect with the way it appears to be implemented.
- Adding a flag to areas as a workaround to handle indoor / outdoor cases
- Hard coding the types (Floor, Structure)
So, the areas in the future would then have to be its own little nesting thing, which seems very unlikely since that would definitively make everything more complex.
Or remove/replace the flag, floor and structure without breaking what people will inevitably have built around all this at that point.
I’m a bit worried that once this is done, we are going to be kind of stuck with it or we will have something else with groups that just makes everything more complex that it would originally have been with just the nested areas.
1 Like
I never said you did; your rebuttal to the proposed use of “floors” is convincing. In contrast, the justification for using “floors” is not.
Unfortunately, the key person who remains unconvinced is the author of the “floors” proposal … which now appears to have progressed from proposal to implementation.
I agree this appears to be shaping up to be a lost opportunity.
FWIW, the home automation software I used before Home Assistant was created 23 years ago and it organized locations using a hierarchy where each location had a “type” based on an extensive list of types (building/yard/floor/bedroom/hall/etc). More recently, the developers of openHAB also came to the same conclusion and use a hierarchy for organizing locations and devices.
From openHAB - Tutorial Semantic Model
Nested areas (with an assigned type) allow for organizing all areas of one’s property including exterior/outdoor areas. It’s more flexible and powerful than a dedicated “floor” or “house” area-grouper.
4 Likes
If you go into a parking garage with your Ha connected smart car , does it change floors? Inquiring minds want to know.
1 Like
Yeah, the concept of using “floor” to group areas is prone to producing some nonsensical arrangements. For example, it wouldn’t make sense to represent a backyard as a “floor” containing pool and patio areas. “Floor” has a very specific meaning and is therefore self-limiting in what it can (logically) describe to contain.
In contrast, nested areas would have no problem creating sensible groupings (i e. backyard area contains pool, patio, lawn, and garden areas).
1 Like
As I have written in the discussion post I am really disappointed with this change. It will only give extra functionality to a limited user base, when the functionakity could easyli be catering to more (all?) users with kind of small design changes.
I would feel the same if I still lived in a two story home, since this would give only a small limited functionality compared to other types of area grouping.
This will inevitably leed to a lot of floors being created to fill the void of not being able to group areas. I know even when I lived in a two story home, I would probably have created a “floor” for my open space living area, that contained living room, kitchen and dining room, without any good way of grouping them as to target “turn of lights in the open space living area”, and then probably another floor for the rest of downstairs and then a couple of floors for upstairs too.
2 Likes
On another note - would it be possible to make some kind of custom component to achive something more similar to what this WTH post addresses?
In theory, you can nest areas right now w/ templating. But the UI won’t reflect that, but your service calls can be tailored to handle it. I’m not sure this is what people actually want. Outside that, I’m not sure how this could be added without custom frontend stuff as well.
2 Likes
Yeah, you are probably right. It would be almost impossible to make something custom that is good and easy enough.
I’m not too good with templating - how do you mean that works?
You just make areas that are not nested. Then you have a macro that knows your nesting hierarchy. Make a few template macros that work from your nesting hierarchy. An example would be a get_entities_from_nested_area macro that looks at all the nested areas and provides a list of entities that are in all the areas. The macro would traverse your hierarchy, collect the entities in a list, remove duplicates, then output the result.
1 Like
I still have not heard a good reasoning why tagging or labeling is not a better path forward.
Create a label and make it “basement” and now that tag, irrelevant of where it is can be attached to any other entity or object in the structure. It could even be attached to an other label.
Create an other label “wall”, and suddenly that “wall” can be attached to “basement” and also to … an other object, say device “motion sensor”.
Now the device “motion sensor” has two labels, “wall”, “basement”.
Move the device to somewhere else, say onto a bookshelf, and the only thing to be done is remove “wall” add “bookshelf” label, but it is still has the “basement” label.
I can go on and on. There is zero chance that a hierarchical structure can replicate the strength and flexibility of tags/labels.
To be more succinct, allow creation of a pool of labels.
The “textual content” of a label is irrelevant to HA. It is simply a “human readable index”.
Want to create a hierarchy of location?
Create label “location”
create label “first floor”, “second floor”, “third floor”. Assign all three to label “location”.
Now any object can have an assigned label of “first floor”.
HA now can group by label items. All items with label “first floor” are at the same location. Not only that, things that move (smart vacuum?) can be tagged based on what other objects around them are. e.g., any time an object enters this cameras view, it is labeled “first floor”, as soon as it is out of it, or if it appears on an other camera the label is removed. Options are endless.
You want to deal with plants?
“watering” → “weekly”, “monthly”, “never”, “sits in a puddle”
“sunflower” → “weekly”
and, so on.
What everyone here keeps missing is that floors is being added, but tags and/or a labeling system is also being added.
Everyone keeps focusing on floors instead of the multiple posts saying “we are still trying to figure out how to do tags and/or labeling” said multiple times by Balloob and Frenck.
A system for organization is coming. Be patient. Adding floors is not taking away the development time from tags or labels. Also keep in mind that it may not be named tags/labels when it is introduced.
TLDR: Relax and read the responses from the development team.
2 Likes
Thanks. Now it is just waiting time. If I was any more relaxed, I would be in a coma. 
I have to start by saying I am completely new to HA. I’ve been using HomeKit (with HomeBridge) and Tado for heating. Neither are satisfactory and so I’m taking the plunge and moving to HA and first step is to create rooms and zones - or so I thought.
However I am somewhat dismayed to discover HA has very little functionality with regard to spatial organisation. I understand the reason for using the word ‘Area’ instead of ‘Room’, but I disagree with the decision. The big issue though is that there needs to be some way to ‘group’ areas. Tado use the word Zone which makes huge sense to me as it’s pretty accurate. Unfortunately, HA use ‘Zone’ to describe a geolocation area which I also think a bad choice. Am I to assume this new ‘Floor’ concept is a way to group areas? In which case, I again think it’s a poor choice of word, but if that’s what it does, I can live with that.
Might I suggest though that rather than upset almost everyone by choosing the wrong (to them) word, make the words a user configurable option. So e.g. I could specify I want to use ‘Room’ not ‘Area’ and ‘Zone’, not ‘Floor’ and ‘GeoLocaton’ instead of ‘Zone’. So everyone gets to choose the word that makes the most sense to them, rather than having to put up with they consider very poor choices made by developers. It’s impossible to please everyone, unless you let everyone make their own choices and in this case, I cannot believe this level of abstraction would be too hard to implement.
Tags can be extremely useful I agree, but in the case of both ‘Floors’ and ‘Tags’, will we be able to direct actions to/at them or are they just a method of visual grouping in the HA GUI?
The problem I see with any method of grouping is inheritance, or lack of. For example, with heating, when grouping rooms/areas together, it should be possible to apply a single schedule to that Group (Floor? Tag?), meaning all included rooms/areas operate on that schedule. Not only does this make setup simpler, but also maintenance, so when change is desired, only one schedule needs adjusting and everything that runs to that schedule automatically runs to the new schedule. If everything has its own schedule which is simply copied multiple times, trying to change that schedule will be a nightmare.
Sticking to our heating example, every TRV needs to not only follow the applicable schedule, but also follow a thermostat (either internal or external) independently of any other TRV, otherwise inconsistent temperatures will result in any groups of more than one TRV (yes Tado, looking at you).
As I said, it was surprising to find that even now, HA is so severely lacking in this regard and hence I’m rather interested to know what the timescale is for the introduction of ‘Floors’ and ‘Tags’. Will I be wasting my time trying to shoehorn what is required into what HA currently provides, only to find all the new functionality drops next week? Or are we not going to see anything this year? If the latter, then I need to get on with the shoehorning. 
I’ve been thinking more about this and I am convinced nested Areas are the way forward.
So an Area could contain and/or be contained by any other Areas and/or also Devices.
That would provide a totally flexible system, with no need for ‘Floors’ or ‘Tags’. Anyone could then set up hierarchical Areas if they desired, or simply horizontal groupings. Whatever makes sense and works for the user without the unnecessary rigidity of ‘Floors’ (which have VERY limited usefulness) or the anarchic nature of ‘Tags’.
I really hope the developers can see this. However they are obviously steeped in the intricacies of the inner workings of HA. I come from a (database) developer background with no pre-conceived notions about how HA currently works. I’m just looking at it completely fresh, from a user perspective and how mapping the real world of the home to HA’s virtual reality would best work.
I cannot imagine a scenario that couldn’t be perfectly handled by nested Areas. If anyone can think of anything that could not be resolved in this way, mention it here and let’s see if it could be.
Imagine a North American or Central European three floor/ground & two floor townhouse.
What areas are the following building parts are in? Stairs, windows, doors, walls, roof, chimney, and so on.
They are in two or more.
With “tags” or “labels” we can throw caution to the wind, and for example the window can be [upstairs bedroom]. Or, both [upstairs bedroom], and [North exterior wall]. It doesn’t have to be but it can. If I was super pedantic, throwing anarchy into the wind , I can have the window labeled [upstairs], [North], [wall], [upstairs], [bedroom]. It is up to me. Labeling allows exactly what you want, and it also allows me to do what I want.
How would you do it with your Areas structure? As an example, how would that work for this bedroom window?
(and, in case you wondering why to have so many labels, why not? I can think of scenarios where I would like to be uniquely control/sense just walls, just North facing things, just… and so on. 
)