Nested areas could be very powerful. This also means they have the power to produce unexpected weird outcomes of coding. From the discussion on GitHub, I gathered that this is the main objection of the devs to nested areas (in the narrow sense where there is no inherent hierarchy and everything is an area but can contain areas too). I think a hierarchical structure with a fixed number of levels and user-configurable names for each level would be a very good compromise. Especially if tags can be added as well (itās not one or the other, thatās been mentioned quite explicitly). Floors could be a first step towards this, although the name is quite poorly chosen in my opinion.
An area is a space that can be occupied. You could occupy an attic or crawlspace (temporarily) but not a wall or chimney (unless youāre a mouse).
Areas do not represent an inventory of building components (wall, floor, ceiling, door, window, etc); theyāre livable spaces. Had areas supported nesting from the very start (like group entities) the majority of needs, for modelling the livable spaces of oneās property, would have been met. The conversation now would be to add labels/tags for additional organizational flexibility (and not just for areas but for any entity). Because labels alone have no inherent hierarchy like nested areas.
Anyway, the discussion is largely moot because the decision has already been made to implement floors and some form of labels/tags. Time will tell if the combination makes any sense to use for modelling exterior areas (yard, patio, pool, lawn, shed, garden, etc).
1 Like
I think I understand what you wrote and why you think your structure would make sense.
You are assuming living space and presence. I do not. I have devices in some buildings (and out in the middle of nowhere, and in rivers, and bottom of canals) that are not living spaces, and there are sensors and actuators through that facility, outside of living space, and outside where even a mouse could go to.
Alas, as you noted we will have to wait for what the devs do.
Itās not an assumption itās what the area feature was designed for. Check the PR that implemented it (and Release Notes).
You chose to use software intended for home automation so itās likely that some of its features will never meet your requirements.
I donāt think Iām missing anything. Iām evaluating the floors proposal on its own merit, and my conclusion is that itās flawed with a minimal set of usage examples that are easily broken by average users.
And the notion that it doesnāt take time away from other things is naive. Of course it takes time to develop and maintain. That comment also misses the fact that each of these things adds complexity to the overall design, and therefore adds cognitive load to users to understand.
1 Like
I think you are not grasping what nested areas would provide. They are not simply hierarchical. An Area is a āvirtualā concept and doesnāt have to be an actual enclosed building structure. An Area could indeed be a chimney, or a closet etc. and they might each be nested in the respective Bedroom Area. However, an Area named āUpstairsā could also include those aforementioned areas plus perhaps the stairs (which might also be nested in a āDownstairsā Area). You might also define a Closet Area in which are nested any closets you want to group together. Basically however you want. It would provide EVERYTHING that any label/tagging scheme might. But alsoā¦
It would provide inheritance, so in the above example, you add a device to the Closet Area and that is automatically then also in any area that contains the Closet Area (like the Bedroom) and also ALL Areas that contain those containers (like the Upstairs Area) and so on. No limit to the levels of nesting. I cannot imagine any label/tagging scheme being able to offer such functionality. You add a new device and add e.g. the appropriate closet label/tag, but does it then automatically get tagged for that bedroom, or the upstairs or any other labels/tags with which it should be tagged? No, it cannot since there is no āstructureā to indicate what āparentā labels/tags should also be added. With nested Areas, that inheritance is implicit in how Areas contain and/or are contained by other Areas.
Donāt be fixated on the word Area and thinking of it as a Room. It may indeed be used to represent an actual Room, but really it is a virtual grouping of devices (and hence their entities) and being able to nest them provides ALL the functionality ever required. If it apparently does not, then you havenāt defined the right Areas.
Everything we deal with in the home, with regard to home automation, is grouped in some way (probably many ways) with others. Whether that is grouped in a physical structure, like a room, or more flexibly like HA decided some time ago, using the word Area as that was not limited to physical walls. I originally thought that a daft decision, but came to realise they were right. However, to take it to its logical conclusion, it needs to be possible to nest Areas in other Areas. In that way, every user will be able to represent their home exactly as they want, with everything grouped as they require and controllable as a group.
Labels/tags are a cop out, used when you canāt be bothered to write the code to provide nesting. So is Floors because a rigid structure is always easier to code, BUTā¦
The code to handle nesting only needs to be written once and then can be employed for ALL nesting. The code for singular Areas has been written, but now they are talking about Floors and that code needs to be created, written from scratch. When they think up some other essential rigid categorisation, that code will have to be written, again, from scratch. Instead, write the code to handle nested Areas, once and never again and it will handle ALL possible scenarios.
The concept of Floors is fundamentally very badly flawed (sorry, just had to say that 
). Why not create Roofs or Bathrooms, and Bedrooms. In fact why not write specific code for all the fixed and rigid room types that the devs think might be used? Because they will NEVER be able to imagine all the possible variations of how a user wishes to represent their home. It has already been pointed out (and admitted) that the Floors concept offers NOTHING for anyone in an apartment. How could it handle outside areas. Define a Floor called Garden? Can that contain other Floors called Front and Back? What about the rear patio. Nested Areas could handle all that with ease.
Creating something as limiting as Floors is a waste of coding time as it will satisfy/help only a fraction of the user base, whereas nested Area could satisfy everybody.
Well, I say satisfy, but there will be some diehards that insist on preferring some other concept that they believe suits their use case, but what I mean is that nested Areas would be able to provide ALL the actual functionality anyone requires.
The more I think about it, the more I realise what a crummy solution Floors and Labels/Tags will be. As I said, they are the ācheap fixā. The real solution is nested Areas.
Having long been a database developer, I have spent a lot of time analysing data concepts and determining the best structure and sometimes, the many to many relationship (even back to the same table) is the only real solution and Iāve often written the code so a record can link to one or more other records in the same table. THAT is a nested structure and itās not hard. A bit more effort maybe than some other half baked solution, but thatās what Floors is. Half baked.
HA uses SQLite to store its data, so as a fully relational database system, itās ideal for the implementation of nested Areas. The code to iterate through the levels of nesting only needs to be written once and everyone will be able to represent their home however suits them. Even if they have no other Floors.
With nested Areas, HA would be GREAT. With just Floors, itāll be meh!
2 Likes
Thank you! Thank you! For those of you who have not downloaded the 2024.4 beta. You are in for a treat. We all got our wishes, floors, categories, labels (tags) Oh My!!!
Cāmon. Create a simple JSON/YAML like this and load it into a sensor:
myhouse:
- name: area_1
entities:
- entity_1
- entity_2
- entity_3
- name: area_2
included_areas:
- area_1
entities:
- entity_1
- entity_3
- entity_10
- name: area_3
included_areas:
- area_1
- area_2
entities:
- entity_5
- entity_8
- entity_9
Then handle it on your own. Write something that given some ānameā walks it and gets all the entities and eliminates duplicates. You are asking that this should be solved at the ācoreā level. You should solve the problem first and then maybe it can be brought back into the ācoreā ā¦ but what I posted above and 20 lines of code would do the same thing (and donāt ask me to do it because I do not need it).
Do that, prove it works, present it all, show the value and only then post the enhancement request,
Like āgive me area_2ā ā¦ should be:
- entity_1
- entity_2
- entity_3
- entity_1
- entity_3
- entity_10
where two are repeated and one eliminated (auto-entities would do that actually).
You can already do what youāre proposing with old school groups. And next release has floors, labels, and categories. With labels, you can do anything. They work the same way as floors and areas with less restrictions, but you can assign them to your hearts content.
3 Likes
I actually new that because i still use old school groups for this very reason. Good to hear about the update.
Try out the beta, youāll quickly find out that itās very easy to understand how to use floors, labels, and categories. And thereās not much learning to any of them.
2 Likes
People have already explained that tagging is powerful but has deficiencies
The most glaring is management.
You can easily end up with an explosion of tags that are unwieldy to manage reliably.
With hierarchical areas you automatically will have the correct areas for any new entity once itās added to a single area. Eg adding a humidity sensor to the walkincloset will automatically also mark it as being in the master bedroom on the X floor, indoors.
People continue making that point and you ignore it because you are excited about the freedom of tags 
I donāt know how many entities you have in HA and how nearly they are organized but I have hundreds and it is painfully obvious that you need another layer of abstraction on top.
In reality tagging is more powerful and i would ideally like to see support for both. Hierarchical areas will handle 99% of cases automatically and tags can be the powerful extra degree of freedom. Not to mention internally they can use tags to implement hierarchical areas.
Btw I have a pretty good guess why they donāt want to touch areas. Too much code and too many assumptions about entities being in a single area at once.
The classic way to avoid a huge migration in a nontrivial project is to just create a new abstraction sadly - as that is simpler upfront but over time creates semantic complexity.
Instead of creating floors they should just:
-
add support for tagging as a first class citizen abstraction - they seem to be doing this
-
add support for say nestable ācontainerā (hate the name so needs a way better one) which is internally implemented by tags but the tags are auto added for you based on the container definition. This can be entirely hidden from users or not. . Vast majority of users and use cases will be covered by ācontainersā. People donāt need to even look at it manage the tags if they donāt want to.
-
eventually retire areas because they become a duplicative and confusing container that is not nestable
Of course the ideal is for them to just change the behavior of areas but this is not going to happen based on what Iāve seen. Really unfortunate.
The addition of floors is the worst of all worlds because it will solve an even smaller subset of the problem unless you are comfortable using that word for something that is clearly not a floor (tags are most general but unwieldy, containers solve a subset of problems but way easier to manage, floors are specialized containers with a name that will cause issues).
I suspect people are bent on floors because it feels like the requests here might be coming from a more hardcore community and the average user just coming to HA can benefit from floors and get āmostā use cases solved. There is def a focus on making HA friendlier to the new comer. While thatās a good general strategy I think in this case anyone doing even very simple things hits the issue with areas and will do so with floors but you know. ā¦ humans disagree and whoever is in charge makes the call hehe. I think itās a mistake but that doesnāt matter much.
1 Like
I couldnāt have explained the issue with the now chosen solution better myself. Now we have 2 things in the system (areas, floors) that should just have been built around the same concept of tags/labels to begin with. That way new user would have an easy and understandable way to build the house hierarchy and with the flexibility to expand upon it in the future.
Tags AND Floors, along with a few other requests are in 2024.4.
I think the combination of Tags and Floors should cover pretty much everything people want with regard to rooms within rooms, to be honest.
Before replying to a month old post, did you take the time to read the latest replies?
Yes, the entire thing. It is a discussion, not asking about a solution nor anything else where duplicative posting will be bad. I was responding to info who has repeatedly said we should just have tags and ignored the points others have made on why hierarchical areas are also needed and why tags have some shortcomings.
I think your comment on the other hand adds 0 value and is actually quite rude. My 2c.
1 Like
Wait 5 days and get back to me. Weāll both know whose post adds 0 value once the next release is out.
Iāll disengage here. But if we bump into each other on another theads donāt be a stranger. Always happy to chat and Iāve found the community on here to be by far and large super accommodating, positive and helpful. I can totally it get if you are frustrated though. Have a good weekend friend. (Not being sarcastic in any of the above, I know tone is hard to read, I mean it genuinely)