Why the heck can't areas be nested?

Month of "What the heck?!"
#3

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.

Screenshot from 2020-09-06 13-57-41

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.

3 Likes
#4

I don’t use areas as it is now but I have wanted this feature.

But what happens if you put light.light1 in livingroom
light.light2 in livingroom
light.light3 in kitchen

then group them all and put group.downstairs in downstairs area.
Or is that not possible?

#5

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.

10 Likes
#6

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.

1 Like
#7

Having ‘nested areas’ or ‘tags’ would be good… having neither isn’t

3 Likes
#8

Then @xAPPO you should probably vote. :wink:

#9

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.

3 Likes
#10

This is similar too why-the-heck-cant-we-make-areas-of-areas

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.

1 Like
#11

This post prompted me to put another WTH in for areas
wth-areas-not-assignable-to-all-entities-in-ha

I did some reading of all the WTH posts that mention areas and the tag concept has come up a few times. I think it could be a powerful addition to HA.

#12

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

4 Likes
#13

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.

1 Like
#14

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!

1 Like
#15

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.

#16

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.

#17

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.

#18

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.

2 Likes
#19

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).

Premise - Create new location
Premise - Create new location965×251 26.9 KB

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):

Premise - Type - 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’.

Premise - Type - Recessed Light

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).

5 Likes
Garage Door Opener - Best brand motor and controller
#20

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.

5 Likes
#21

@tboyce1, I agree, both concepts are in place to add attributes to entities. With areas specifically dedicated to location and groups more general purpose. Still both are there to add attributes to entities, in order to deal with related entities in some sort of unified way.
While nesting is good because an entity can inherit attributes and thus save a lot of time for users with many entities (maybe think of it as auto-tags), individual tags could be a good addition for attributes used by few entities. These would pollute a tree view. Think of a bot (inspired by github) tagging entities which are frequently unavailable or have a high power consumption so these can be manually or automatically be dealt with.
But as @frenck would probably put it: Tags and groups need to be brought to use. So this needs support in automations (triggers and actions) and the visualization in the UI. This will be quite some effort.

A term could be ‘selector’, where a group of entities is selected by hierarcal group (auto-tag) or individual tag, together with a logic function how (and=all, or=any, xor=exactly one, … ) they shall be combined.

At least this could become the common underlying concept which could be used by frontend features like areas or groups. And so reduce advanced queries/selections in templates and such things to a unified approach.

Sorry for the lengthy article, but reading the whole stream here was enlightening for me. First I would have preferred tags only, but now it gets clearer. Hope it’s helpful at all though.

2 Likes
#22

I have seen some discussion of groups as an alternative to areas, and that groups have some functionality. I have posted previously but didn’t get much traction on nesting groups, has anyone successfully nested groups for any purpose? In my case I am having issues nesting groups of persons. But I imagine improvements in nesting could be made across the board.