You have my vote but, as mentioned, the development team has already made their decision.
FWIW, here’s a screenshot from another system I’ve been using since 2007.
Each area is able to aggregate certain entities. For example, if I have temperature sensors in Foyer, Dining, and Living then the aggregate average temperature is available in First. Obviously, House contains the aggregate average temperature of all temperature sensors in all areas.
Occupancy works the same way. If occupancy is detected in Family, it is also reported in the aggregate occupancy for First.
I don’t like nesting. It is both very limited and complicated to maintain. What would be great would be “tags”, and allow a zone to have multiple tags.
That way, you could create your own nests (kitchen and hallway both have the tag “first floor”), but you could also have multiple rooms with the tag “bathrooms”, “bedrooms” etc. even if they are on different floors or different wings.
As mentioned, I’ve been using it since 2007 and have neither found it to be limited nor difficult to maintain.
In the screenshot I posted above, right-clicking a node presents a menu of available area types (rooms, floors, interior, exterior, public spaces, etc). I can re-arrange any area via drag and drop.
Once I’m satisfied with the arrangement, there’s little need to change it dramatically (unless you completely remodel your house or move to a different one).
Plus these areas are aware of the entities within them (dynamically) and can automatically aggregate certain values (temperature, powerstate, etc). If I want to turn on all lights in a given area, I don’t need a group for it, the area can be used for that purpose.
Good point @Tinkerer. I am a dev myself in real life. So I know very well that dev decisions have to take into account not only what is desirable but also associated cost and available resources.
As WTH is purely about user experience I still think it is valid to post pain points here - even if they have been discussed and rejected before.
IMHO areas in their current form are of rather limited use and the work that already went into their development does not pay back very much.
I personally like the tag idea as this will give more flexibility. Might be less preferred by those who wanted deep nested structures though.
I would be happy with something. I think the whole concept of areas needs some work in HA.
The request for “nested areas” includes this ability to represent hierarchy, namely the relationship of one area with respect to another. This parent-child relationship allows for easier rendering as tree-views and, more importantly, to allow for automatic aggregation of areas and entity values within areas. It’s more difficult to achieve this with simple tags (relying exclusively on string matching).
In my case, four levels is adequate to represent every room in my home. For example: House.Second.MasterBedroom.MasterBathroom
My issue with trees in general is that they are unable to represent entites that should be part of more than one branch. You can’t have your “MasterBathroom” be part of both the “MasterBedroom” area and the “Bathrooms” area at the same time.
I know we have groups already, and I am not a heavy user of the “area” concept anyway, so this is not a very important matter to me. But having worked a lot with metadata in a number of different scopes for many years, I have been more and more convinced that the old fashioned directory hierarchy and tree structures you find everywhere in the digital world, is a limiting factor in so many cases.
Why would you need a bathrooms tag?
I mean in what case is that useful?
“Hey Google, turn off the lights in bathrooms”?
Or bedrooms?
Why is that useful?
I have never felt the need to switch on or off something based on the “type” of room.
However upstairs/ downstairs, yes!
Another thing to keep in mind with tags is that you’ll need to designate a “primary” tag (to send to Google Assistant, etc…). With nesting, you still have a single area for a device, so nothing breaks.
Can you explain, why you think that trees cannot handle that scenario? We are not talking about binary search trees here. A tree structure can very well hold multiple references to the same object. Many file systems do just that with their symlinks or junctions. The task at hand for HA entities is even simpler. File systems need to track how may references to an object exist at any given time (so they can delete the target object when the last reference is gone). An area tree in HA would not need to do that math. When there is no reference left in the area tree to a given entity than that entity just exists on. For an entity there is no need to always be part of an area.
I do exactly that through Google and HA both. If my wife and I are sitting on the couch and one of our dogs decides to go wandering through the house turning lights on, it’s nice to be able to either tell Google or use the HA app to turn off those rooms quickly.
But from HA, I have to edit the groups.yaml to add the device to the kitchen group. Then I have to go to my kitchen tab in Lovelace (provided I remembered to create a kitchen tab), hit a toggle (provided I setup a card for that toggle) just to turn off the lights in an area.
That’s too many steps and honestly, it makes adding devices a pain: Add the device, add it to a group, if it’s in a new “area”, make sure I create a Lovelace tab for it, create or edit an entities card so I can control it. It takes what should be a 5 minute process of adding a device to HA and to an area in HA to more like 15 minutes just to be able to control the device.
The most basic thing I want out of areas is simply an “area.[area_name]” that can quickly be used to turn things on and/or off. If I add a device to an area, I want an area entity created to control that device and others that are in that area.
But do you ask to switch of bedroomS or bedroom?
As I understand the “tag” thing is that bedroom can be in several rooms which is true. As I see it switching off several rooms at the time is when you have left that area, like went downstairs.
If you have bedrooms on both floors then switching of bedrooms means you switch off downstairs too.
I don’t see any benefit of tags actually.
If you instead create lights in “some kids bedroom”, “upstairs” then you can call out upstairs if you want to shut down everything upstairs or “some kids bedroom”.
If you want to switch rooms then all you need to do is to replace upstairs with downstairs for example.
However, if you use tags then you have “bedroom” and “upstairs” tagged to every entity in that room.
Even worse if you have east wing or such also. Nesting means fewer places to change if I understand it all.
Conversely, tags are unable to represent parent-child relationships. It doesn’t mean both tags and hierarchies are fundamentally flawed, just that they serve different purposes (with some minor overlap).
The screenshot I posted above comes from home automation software called Premise Home Control (a.k.a. Premise) and it offers both concepts. For example, to create a new location, you right-click the tree-view, wherever you wish to insert the new Location (its term for Area), and then select the Location’s Type (a new ‘Bathroom’ in this screenshot).
I can name it whatever I want (‘Guest_Bathroom’) and its parent-child relationship may be something like House.Second.Guest_Bathroom but its Type remains ‘Bathroom’. That means that I can turn off all lights in all areas whose Type is ‘Bathroom’ (i.e. the ‘tags’ concept).
The following screenshot shows the Type of an existing bathroom in my house (House.Second.Master.Bathroom):
The support for both concepts isn’t just for areas but is also used for entities. For example, this screenshot shows an entity called ‘CeilingLight’ in the bathroom (parent-child relationship) and its Type is ‘RecessedLight’.
Because all entities have types, it allows you to, for example, turn on all ‘TableLamp’ entities in a given area (but not any RecessedLight or Sconces or etc).
If I create a new light in that bathroom, I don’t have to create tags such as House, Second, Master, Bathroom. Its placement within the hierarchy takes care of its relationship with respect to locations (and other entities). All I need to do is indicate its Type (i.e. Light > Sconces).
What’s really weird is that groups can already accomplish some of those things that areas can’t, so WTH is even the point of areas? Why couldn’t we have just added a nice UI on top of groups? They can already be nested, applied to every entity, and entities can be in more than one group at a time.
Personally, I’d just like to see a nice UI on top of groups and potentially add tags to further expand the options for indicating entity relationships.
