Improve information architecture for Home Assistant

[balloob]

Dec 21, 2023: This proposal was initially called area responsibilities. I have updated the proposal to include floors and structures.

Dec 22, 2023: Structures has been reduced to just a single "Home" structure.

Context

Home Assistant allows sensors to indicate with a device class what kind of data they represent. However, this indication is not specific enough. A sensor could indicate that it represents a temperature but it doesn't represent what this is a temperature of. Is it the temperature of the room, your 3D printer nozzle or your computer's CPU ?

At an area level, we currently cannot automatically detect what entities should be used for this. This is causing issues with automatic creation of dashboards or responding to voice queries (what is the current temperature solely relies on climate entities because of this issue). It also limits the type of automations that we can offer.

Currently we only offer areas to create area infrastructure. Areas are currently used in different ways. Here are some frequent ones:

• define an area in your house (kitchen, living room etc)
• define as "system service": this service is for the house, doesn't belong to something specific, ie weather or Spotify. It can also be tied to an area but really offer something for the whole house, like measuring energy used at a home level
• define a person: this device belongs to person X
• define as "junk". Devices not currently in use
• areas outside the home (garage, front yard, backyard)

Proposal

We should define a more formal infrastructure for your house, and a way for things to hook into that. We should add/update the concepts:

• Home: A collection of floors.
• Floor: A collection of areas. It's kept separate from area and can only contain areas, not devices/entities. Existing proposal
• Area: updated with a new boolean if it is outside or inside the home.

Although interesting to solve too, People, Junk, Services are not part of the scope of this proposal.

Once we have such structure in place, we can define level properties (ie temperature) that span multiple layers in the infrastructure with each level property their own aggregating behavior.

Entities can define how they are be used in their EntityDescription using the new field responsibility. Weather entity would set it to level="structure", property="weather".

It is important that when an entity is first discovered, that it is automatically assigned to the right part of the information architecture if possible. If ambigious, we could ask the user when a device is added to Home Assistant.

We would store this information in the entity registry. A user would be able to override the responsibility of an entity. It can set it to none or to any other qualifying responsibility.

Example level properties (as examples, not part of this proposal perse)

Some examples of how the new structure could be leveraged by different level properties. Each property here is shown to force us how the concept can be beneficial. Adding/changing properties would require their own architecture issue.

Note that each property needs to be defined in advance and requires its own code to show/use it. This allows us to add specific logic for each property.

Weather

Weather is an easy one and would be defined on the structure level. There would only be a single entity allowed to be assigned to it.

Current Temperature/humidity

• Area level: Current temperature can be read from both climate entities and temperature sensors. Each area will allow defining multiple of such entities and it would take the average of all.
• Floor level: it would take the average of the temperatures in indoor areas on that floor.
• Home level: it would take the average of the temperatures in floors

This allows us to query, show and automate temperature on each level.

Motion

• Area level: Multiple motion sensors can be defined. An area has motion if any motion sensor defines motion.
• Floor level: a floor has motion if any area has motion
• Home level: a home has motion if any floor has motion

Climate

This is a tricky one as it can go many places. Some people have both AC and heat integrated in 1 unit. Others have window ACs and a heating system. Others have just heating or AC. This can also be defined at different levels.

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

At each level, the "current" climate entity is the one that is active. If a user has both heating and cooling active, we should send them a warning and select the first active one.

Energy

Energy consumption can be measured by measuring one or more groups of power going towards an area, or come from devices itself. For every level, if the level below has energy sensors, we could display the accounted and unaccounted energy usage.

• Area level: one or more energy sensors.
• Floor level: sum of all areas
• Home level: one or more energy sensors.

Media player

This one would include both an entity for source selection and for output. Each can be picked only at an area level.

Consequences

We will be able to start reasoning on a home/floor/area level about parts of the home. This unlocks a whole list of cool things:

• Floor trigger: trigger when motion detected on first floor
• Floor action: turn off all lights on first floor
• Area action: reduce volume in the living room
• Dashboard can include area cards and show temperature, motion etc
• Voice can answer "how hot is it here" for each room
• Suggest entity ID renaming based on purpose

Example Home architecture

• Home
  • Weather: weather.home
  • Floors:
    • First floor:
      • Climate Heat: climate.first_floor_heat
      • Areas:
        • Living Room:
          • Motion: binary_sensor.living_room_motion
          • Temperature: sensor.living_room_temperature
          • Media Player input: media_player.living_room_apple_tv
          • Media Player output: media_player.living_room_receiver
        • Kitchen:
          • Motion: binary_sensor.kitchen_motion
          • Temperature: sensor.kitchen_temperature
    • Second floor:
      • Climate Heat: climate.second_heat
      • Areas:
        • Bedroom Parents:
          • Motion: binary_sensor.bedroom_parents_motion
          • Temperature: sensor.bedroom_parents_temperature
        • Bedroom Kid 1:
          • Motion: binary_sensor.bedroom_kids_motion
          • Temperature: sensor.bedroom_kids_temperature

[BradleyFord]

I noticed the points about Averaging temperature, etc.

One of the challenges with the energy dashboard it the huge level of detail.

I wonder if power consumption should also be summed at the area level.

[Madelena]

Summarizing power consumption at area level can be helpful. For example, I can see the impact it may have on my HVAC costs vs my usage of a room or whether its windows are open.

Personally though, I group power consumption by circuits, because I don't want to trip the fuse of those circuits. :)

Some power consumption measurement kits, such as Emporia Vue, are installed right inside the electrical fuse box and have sensors for each circuit. It would be nice to know if the total of all the power consumption outlets that I have adds up to the circuit sensor.

And sometimes we also get power usage sensors for an entire power strip and its individual outlets. That led to duplicated amounts in the calculation of the total power usage.

[Particpant]

Unless the Energy dashboard gains the ability to understand that some measurements are also nested. Smart plugs in a room are part of the load reported by the monitor in the breaker box for a particular circuit. Right now, if you try to track both on the dash it treats them as purely additive.

[TheFes]

I had a similar issue when I wanted to get the area temperature and humidity for my Dasboard, I solved it by hiding the entities which I didn't need, and is is_hidden_entity in my templates. It was mostly internal device temperature sensors which were messing things up (like for Shelly devices)
But it would be nice to have this as a core functionality.

[jlpouffier]

I struggle to understand the link between the problem "We do not know if sensor s is purely internal to device d or can be extended to area a" and the solution of adding more structure to the areas.

This architecture proposal seems to hide two proposals into one

• One that adds this responsibility field and solves the initial problem (With our current area structure)
  • for example, my temperature sensor entity coming from my temperature sensor would have a level="area"
  • And my CPU temperature sensor entity coming from my NAS would have a level="none" (or "device")
• And one that adds more structure to our areas (Structure, floor, etc)

Both seem independant

[balloob]

The reason both are in the same proposal is because I want to make sure that we're thinking of the bigger picture. Once that is agreed upon, we can split it in smaller parts and build it.

[jlpouffier]

area today is a very generic word. If you want to nudge integrators to put a responsibility field in their entities, maybe we should pivot to a simpler concept

Something like this:

• We keep area for the things cannot control .. like a technical area or a don't care area
• But we introduce a new type of model called room.
• We prohibit the responsibility level to be set to area

When you think about it, it would be very complex for an entity to state "I am responsible for an area" if we cannot even explain what's an area.

[BradleyFord]

This idea is really key.

It seems quite a few people are against having Floors (although I personally think they are the correct approach). But maybe we just have:
"Areas" but enable "Areas" to reside within "Areas".
Then we can assign a Type to each area; ie Floors, Bedrooms, Offices, etc. Then we could write an automation that targets all types of rooms.

Finally the tagging idea that @frenck has mentioned a few times , in which we can also use "tags" like in Gmail. So for example portions of the house that area serviced by one AC unit, or one VRV can be tagged. Enabling automations or rollups based on tags. So for example we might have an average temp for rooms that are tagged with "Air Conditioner 1", then we control based on the average.

Hence we then have the capability for:

• Flexible deliniation of zones/heirarchy
• Tagging areas that are serviced by a single piece of equipment that cross the hierarchy.

(I have 2 VRVs; both serve one side of the house. Both upstairs and downstairs...)

[jlpouffier]

Reading all the examples, I initially struggled to understand the benefits of defining specifically a floor
Because it's complicated to find something responsible for a floor in a house.

Anyway: you should add Vacuums to the example list.
Vacuums are the perfect example of a device responsible for a floor.
Vacuum can roam free across rooms, not across floors.

[EnochPrime]

I would say climate entities is another example. I have 3 thermostats (hence 3 climate entities) and each is responsible for heating a floor. However the temperature sensors could either be the area they are in or the whole floor if there is only one. To complicate things further one thermostat controls the AC for the whole home which would mean the responsibility should change based on the HVAC mode.

[jlpouffier]

From what I understand, by default, I'll have a house structure with floors and rooms.
If I follow that concept, I'll create a second structure for my exterior, maybe with a few areas like patio, pool and workshop.

Where do I attach weather?
Technically, I should attach it to the exterior structure (It's not raining in my house structure)

But if I do that, without hacking something weird on voice side, will I be able to ask for the current weather?
My voice assistants won't be on the same structure as the weather

[Particpant]

This floors (and associated infrastructure concept) seems too rigid in the face of diversity in home architecture and needs.

Current Temperature/humidity

• Floor level: it would take the average of the temperatures in indoor areas on that floor.
• Home level: it would take the average of the temperatures in floors
  It's not uncommon to have a floor that is made of (indoor!) areas that are a mix of living space and not-living space.

• partially finished basements
• storage and utility rooms
• workshops
• exercise rooms

If 'elevation' or height is the discriminator that end users are to use to define a floor, but they've put climate sensors in all those ares, are they likely going to get the result they expect or want from an 'average' of all climate sensors for the floor (or for the home containing that floor)?
I think you'd see a lot of people deliberately marking non-living space (but indoor) areas as 'outdoor' as a workaround, or defining floors that are just a nesting of areas rather than representing a literal floor.

Climate

This is a tricky one as it can go many places. Some people have both AC and heat integrated in 1 unit. Others have window ACs and a heating system. Others have just heating or AC. This can also be defined at different levels.

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

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

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

At each level, the "current" climate entity is the one that is active. If a user has both heating and cooling active, we should send them a warning and select the first active one.

I think overlapping climate controls are not as uncommon as you'd expect. A floor might be partially served by a central forced air system, partially by mini-split heat pumps, baseboard heaters or wall furnaces... the systems may or may not serve overlapping areas. This is really common on homes that have had additions made over many years. Even in the same room, say a bathroom, it might have a central HVAC duct, but also a radiant heat system in the floor. Heated tile floors often operate in opposition to guarantee a particular floor temp regardless of the air temp.
Within the same floor, depending on the layout, neighboring architecture, geography and the path of the sun, there are parts of a single floor that might quite likely require cooling while the other side is getting heat or is off (think a room with large windows facing east, a kitchen that's in-use, or row homes where part, but not all of the roof is shaded by neighboring structures.)
In the opposite case, an older multi-story home might have a single thermostat controlling a single-zone system. How would this represent that one entity across floors?

For the media player example, someone might be watching the game with headphones on the TV while their partner has got the AV Receiver that'd normally play the TV audio streaming music over the speakers. Hiding the controls for either wouldn't be a good result for the end users.

Even weather might not really be a singleton. Sure, if someone is pulling cloud weather data, a singleton makes sense. But a person living in a big city, with a back yard/patio that's shaded by a tall building? Sure, if it's raining or windy, it'll be rainy or windy all over. On a hot day, though, the outside weather in that shaded yard is likely quite a bit different versus what's out the front door.

I guess the point I'm making here is that this all seems very rigid for what has been a very flexible and customizable platform.

• Areas would need more flags than just interior/exterior. At minimum, they should be tag-able as 'living space/not living space'
• Climate entities should probably own tagging the areas/floors they're responsible for heating/cooling/humidifying, rather than a floor or area assuming a single device.
• • does the person looking at the average temperature want the whole floor, or the average temp of the rooms served by the same climate entity? I don't know.
• Just like areas don't always have clear bounds (open plan kitchens/living rooms) the devices in them don't, either (the simultaneous, divergent use of TV/AVR as described above.)

I wasn't sure if my comment was best placed here or in the proposal for floors, so happy to move if to the other discussion if preferred.

[AllardKatan]

I really don't get why a 'floor' concept would be a good idea in absence of a more flexible method of grouping areas and assigning devices' location. And I still have a house with several vertical levels, I don't think that will be the case the next time I move house. I certainly see merit in the idea of larger structures, but for me they would need to be less rigid and less tied to the vertical level. Some examples, mostly from my own situation so likely just a fraction of the issues that the userbase faces:

• My mechanical ventilation system has a central unit that is located on the 2nd floor, but it has no inlets there, while it has inlets in the bathroom (1st floor), kitchen (ground floor) and toilet (ground floor). What area and floor is my ventilation in would you say?
• I have a physical switch in my (open plan) kitchen that because of its arrangement I operate while standing in the living room, and it controls the light in the first floor hallway. What floor and area do you suggest that switch is in?
• What about areas that span multiple floors, e.g. stairwells, mezzanines, the facade with Christmas lights?
• What about the front shed, the garage and the garden house?
• How about the large amount of people that live in single floor housing like apartments and bungalows? How should they create structure?
• How do you suggest I make a structure that contains all the bedrooms, which are not all on the same floor but functionally similar to each other and different from e.g. bathrooms or storage rooms on the same floors

I know several areas in my house that I would like to make groups of and nest together into a larger structure. None of these groups would contain all the areas on one floor, and several of them would contain areas and/or devices spread over different floors.

[tetele]

Could the root node at least be "building" instead of "home"? I see no point i ln having a single, immuable root node.

[tdejneka]

FWIW, screenshot from 23 year-old home automation software (Premise).

It models an entire property using nested areas. Each area has a "type" selected from a list containing about 100 types.

Root node's type is "Property". Other node's have types like:

• House
• Floor
• Bathroom
• Outside Area
• Lawn
• Attached Garage

It was easy to model my entire property with it (openHAB offers something similar). It allowed me to select entities based on membership in a nested area (sprinkers in the FrontYard area and its sub-areas) or membership by area type (temperature sensors in all Bedroom areas).

Basically, an area is whatever location you need it to be; by specifying its type it can be a bedroom, bathroom, closet, floor, house, shed, lawn, patio, etc. Areas can be nested in order to accurately model an entire property, having multiple buildings and exterior areas, all while preserving spatial relationships such as a bedroom and its ensuite bathroom and walk-in closet.

If I understood the proposed Home architecture correctly, it uses a dedicated "Floor" to group areas (no area nesting) and a separate "House" to group Floors. These two purpose-built features still fall short of being able to accurately model an entire property, or preserve the more sophisticated spatial relationships that can exist inside a house. Enhancing the existing "area" feature seems to offer more 'bang for the buck' and builds on something that users already know and use.

[MissMusic]

The whole platform is called Home Assistant so I'm fine with "Home" as the base level instead of "Property", that's just semantics and I don't care about what it's called, I just want the functionality.
I totally agree that not being able to freely nest areas is a big issue. I too don't understand why a fixed limited hierarchy would be the preferable approach. The only issue I can see would be that less advanced users might get confused on how to set it up, but that could be solved by creating a default structure like the one @balloob suggests, all without limiting the possibility to build your own custom hierarchy.
My "Home" in Home Assistant manages devices spread between six different buildings + outside areas. Sure it would be one step better if I can add each building as a separate "floor" in the proposed design, but for the buildings that have multiple floors, the set hierarchy fails me instantly.

[mburr88]

I don't know about you, but I define my entire property as my home. What if I had a detached building (external garage with additional rooms etc), would I then need to create a whole new instance of home assistant? The idea of using floors vs areas seems silly and would not need that much of a change to allow for a much higher level of customization for those users that could take advantage of it. Nested objects (areas, zones, whatever you want to call them, they are objects at the end of the day) with an assigned type would accomplish everything people are looking for.
Need to turn off all bathroom lights (not sure why you would, but you can). Iterate through all objects (property.buildinga.floor2.bathroom.kidsbath and property.buildinga.floorbasement.mastersuite.masterbath for example) and turn off the light. Need to turn off an entire floor -> property.buildinga.floor1.

Why impose an artificial limitation when this can be expandable for not that much effort.

Personally I'm just starting to convert everything over to smart devices, however, I'm not far enough into it that jumping ship is a hard decision, and this is definitely a huge deciding factor.

[knipknap]

Why even give each level in the hierarchy a dedicated type? Couldn't everything just be an "area" object (or whatever name) that allows for arbitrary nesting? Users could still assign a type or label for visual classification if needed, but why complicate things with specific types?