Store temperature and humidity entity IDs on areas

[balloob]

This is an extract from #1017 to start kicking off an initial implementation.

Context

We want to know the temperature and humidity throughout the house. Home Assistant contains a lot of data points but it's not clear what they represent. Is the temperature sensor in the office the ambient temperature or the 3D printer nozzle temperature?

Proposal

To solve this, I propose 2 new properties for the area registry:

• temperature_entity_id: str | None: entity ID that contains the room temperature. Sensor entity with TEMPERATURE device class
• humidity_entity_id: str | None: entity ID that contains the room humidity. Sensor entity with HUMIDITY device class

Value resolution:

• None: Resolve on the fly. We will use the oldest (using created_at) entity that is allowed for the values.
• One value: we use that value

Configuration

Since it's stored in the area registry, we would expand the existing area create/edit dialogs to allow setting these values.

Potential Uses

• Area cards on an automatically generated dashboard (ie default dashboard) can show these values in badges instead of tiles.
• Give correct answers when a user asks Assist for the temperature in a room
• We could offer area automation triggers

Changes

Sept 29, v3:

• Changed back to single entity. User can use groups (frontend can help with this). That way we always can show history for temp/humidity
• Dropped websocket API. This can be included in area registry API
• Removed climate entity from temperature sensor. It is too annoying to extract the history for current temperature. We can add this later, or it can become a default once we get heating floor/area entities

[BradleyFord]

This is good and I fully support, but I feel the initial implementation is quite limited. Could/should it be expanded to include CO2 and presence? Presence is fundamental to know if any of these other data points (temp, humidity, etc) actually matter. Ok the temp is high... But it nobody is in the room it's ok. CO2 is fundamental to knowing how healthy it is to be in a room.

…

On Thu, Sep 12, 2024, 03:24 Paulus Schoutsen ***@***.***> wrote: *This is an extract from #1017 <#1017> to start kicking off an initial implementation.* Context We want to know the temperature and humidity throughout the house. Home Assistant contains a lot of data points but it's not clear what they represent. Is the temperature sensor in the office the ambient temperature or the 3D printer nozzle temperature? Proposal To solve this, I propose 2 new properties for the area registry: - temperature_entity_id: str | None: entity ID that contains the room temperature. Either a sensor entity with TEMPERATURE device class or a climate entity (current temperature entity) - humidity_entity_id: str | None: entity ID that contains the room humidity. Sensor entity with HUMIDITY device class When this data is to be used, and it is not set (value is None), we will use the oldest (using created_at) entity that is allowed for those values. Configuration Since it's stored in the area registry, we would expand the existing area create/edit dialogs to allow setting these values. Potential Uses - Area cards on an automatically generated dashboard (ie default dashboard) can show these values in badges instead of tiles. - Give correct answers when a user asks Assist for the temperature in a room - We could offer area automation triggers — Reply to this email directly, view it on GitHub <#1135>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOZ736IYGWATRCQUD3HDDZWCRHXAVCNFSM6AAAAABOBXNQWOVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGE3TAMRZGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[emontnemery]

Presence is an interesting case, because it's likely some areas need more than a single sensor

[farmio]

Should multiple (presence) sensors be configurable directly, or with help of a helper entity?

[AJediIAm]

Looking at the intended use, it's a way to organize and identity data. There is no logic involved like taking the average from multiple temperature sensors.

It is my understanding that Occupancy is intended for a room. It is deferred from, for example, one or more motion sensors. Since it is not the integration to apply logic here, a blueprint or template sensor should be used to defer occupancy from the applicable sensors.

Looking forward to this feature. I already use helpers to define certain values per room. Being able to refer to an area property would be even better.

[elupus]

In regards to temperature, that sort of seem our device class is limited. Nozzle temperature and room temperature is two rather different things. Maybe a device subclass would make sense?

Or a attribution of the value.

area_attribute
device_attribute
floor_attribute
house_attribute

[balloob]

Having a device indicate what a value should be used for can be solved by device types (some people are prepping a proposal for this). However, the user will still want to be able to pick and choose what values to actually use, and that should be stored somewhere.

[Jc2k]

What about a scope attribute on the entity? For a lot of these we could have an _attr_default_scope. For a hue motion sensor we'd default it to Scope.AREA. For something like an internal temperature, nozzle temperature etc we'd default it to Scope.DEVICE.

I think there are cases where a device might default to area but the user might want to force it to device (I have inkbird temperature sensors in my fridge and freezer).

[balloob]

This can be helpful in providing better defaults. However, in the end, the user will still need to have a place where they can decide which one is their preferred one.

I also think that the idea of device types, which is floating around, would be a better solution for this.

[balloob]

I have updated the proposal. We now allow storing multiple temperature and humidity values. It should be averaged when used. If a user wants something else than an average, they can use a template sensor.

btw, it will open up the door to get area sensor entities, in case a user wants to see the average temperature of their area, or automate on it.

[parautenbach]

If area A has temperature sensors X and Y, then with this proposal, the temperature of the area will be the average of X and Y – good. Let's say, one wants to pick the minimum instead and creates template sensor Z for that purpose. Let's say entities X, Y and Z are all associated with area A – this cannot be under this proposal. You will need to associate only Z with the area, but users will likely want to associate all three. Wouldn't it be better to instead specify a method for an area for how to treat multiple temperature sensors (simply, mean, min or max, for starters)?

[AJediIAm]

It is my understanding that the temperature of an area is different from the area of an entity.
Both can be chosen independently of each other.

Average will be good for most cases. It will also allow for an initiative roll-up to floors or house in the future.

[balloob]

@parautenbach we should not make it over complicated. Supporting every edge case means that we just move complexity into user space.

[balloob]

One other thing to note: the assignment of an area to a device/entity will not impact this calculation. We are specifically allowing the user to set the entities to use for the room temperature, regardless if they are linked to that area.

[parautenbach]

we should not make it over complicated. Supporting every edge case means that we just move complexity into user space.

I agree with the general sentiment. I thought in this case providing a few options other than average would be in line with some other platforms, but average is probably fine (at least as a start). It's just the kind of thing that if you change your mind later, then it will be a breaking change.

It is my understanding that the temperature of an area is different from the area of an entity.
Both can be chosen independently of each other.

Yes, I assumed as much. For me it was just inclear what the automatic average calculation would entail, but this answers it for me:

We are specifically allowing the user to set the entities to use for the room temperature, regardless if they are linked to that area.

[arturpragacz]

This proposal seems unnecessarily limited and not generic enough to my taste.
Every time we want to add another sensor type, we would need to create another attribute in area entry.

Instead we could simply provide preferred_entities attribute, which allows user to choose from all available entities in the system.
Then if some area is specified (via voice, or to show in the UI), and there are e.g. temperature sensors in the preferred_entities we simply use those in preference to others, and otherwise default to (the average of) all temperature sensors in the area.

That way we support all the possible sensor types immediately.

In fact we could even consider extending the support in this way to other entities, like light entities. If light entity would be added to preferred_entities it would serve as a default light for the area.

[arturpragacz]

Well, I guess what I question is the need to do this:

temperature_entity_id: list[str] | None
humidity_entity_id: list[str] | None
# etc...

instead of simply doing this:

preferred_entity_ids: list[str] | None

And then using this generically in a function like async_match_targets.

[balloob]

Well you want to know what the entity is preferred for. For example, a climate entity can be the source of the current temperature or the one controlling the heat in a room (or both).

[arturpragacz]

This is a good example and I thought about this one too.

But as far as I know, this is the only example. I can't think of any other entity other than climate, that has a dual purpose like that.

So I would rather enforce some kind of policy like: for every climate entity the integration has to create the current temperature sensor entity too. Then we can use the sensor for sensing and the climate for control. Some integrations in fact already do that, due to how they work, an example here would be zwave.

So if there were multiple complex entities like that, I would agree with you. But in this instance I would rather just change climate, than to engineer our whole solution around it.

Maybe I didn't present the case here for the generic solution well enough. So let me list the downsides of the proposed approach compared to the generic idea:

1. For each sensor type you have to create separate attribute, this will obviously lead to clutter.
2. For each attribute you have to write (or probably copy-paste) the logic handling it.
3. Because of the above, every time we will have a discussion: is it worth adding? At some point we decide that some sensor is too niche and leave users needing it without it.
4. There will by definition never be support for things like custom intents.

Au contraire the generic solution supports all of the above automatically. We write the logic once and we use it for everything.

[AJediIAm]

My interest in this topic is because I happen to do something similar using helpers. When I read the proposal, I immediately recognized it as something I tried to archive myself. I don't have an opinion on how it is implemented exactly, but I do prefer the area to be the center of attention.

I hope my perspective is useful for you to choose and justify the right direction which is best for the majority of the users (even if it differs from my preferences). I will not answer all questions, but I hopes it helps.

I created helpers to capture the properties of a room while the devices were named and managed more oriented to the integration. Being able to assign explicate properties to an area has the following advantages:

• It allows the household administrator to manage the entities based on the device or integration with a consistent naming convention based on the device.
• It allows casual users to quickly identify the right entity based on room/area independently of the underlaying technology or devices.
• Area-based properties often consist of the average of multiple entities or an entity can cover multiple areas. The casual user does not need to know these details and can easily search for entities related to an area.
• It makes it very easy to add/remove/relocate a sensor without the need to update any dashboards.

Some examples of area-based properties which I like to use:

• Climate: Temperature, Humidity, CO2.
• Occupancy / presence detection: This includes motion sensors, mmWave, media player. I'd like to add computers in the future.
• Doors / Windows: Most doors are shared between areas.
• Power / Energy: Only "user controlled power consumption" is included in the area overview.

A similar approach can be taken for lights, climate control, media players and covers. There is more potential here.

None of this is revolutionary. Managing these things from the perspective of an area proved to be very intuitive for casual users and I like to work with it on a daily basis. I think it is because it is so explicate in terms of real-world context and complementary to how entities and devices are normally managed.
The best argument in favor of the area-based approach may be to give choice to the user on how they want to manage their entities. A more distinct approach gives a more meaningful choice.

[balloob]

@arturpragacz defining it well with types and logic is the point. Avoiding ambiguity is good, as it will be a foundational piece for a lot of parts in Home Assistant. By being explicit, it also means that if a sensor would ever fit 2 properties, it is crystal clear which one, or both, it belongs to. It also allows people in templates to easy iterate etc. A single list means that the logic to split it has to be accessible everywhere where it will be used, and it also means it's computed on the fly.

[ScottG489]

Will these values be accessible via templates? Something like:

area_prop('bedroom', 'temperature')

[balloob]

Yes, all attributes of area registry entries are accessible.

[frenck]

We've approved this proposal in the architectural meeting. ✅

../Frenck

[frenck]

Implemented and merged into core.