Numeric sensor offset

[Shulyaka]

We already have unit conversion and display precision configuration, and the next thing towards user friendliness could be the sensor calibration. Ok, nothing complicated (we've got template sensors for that), just a user-configurable offset that could be set in the ui is a good start.

Proof of user requests:
https://community.home-assistant.io/t/sensor-value-offsets/260840

What do you think?

UPD: See the below comment for the suggested solution design: #947 (comment)

[Shulyaka]

Any update on this?
There are more than 150 votes for this on community forum already.
Any chance you could give a go ahead for this one?

[felixschndr]

Might be a stupid question, but where do you see the 150 votes? I only see 19 "likes"

I remember there was a vote button once...

[Petro31]

Click the community link in the main post.

[Shulyaka]

All these humidity sensors are literally next to each other:

[Shulyaka]

As advised on the forum by @Petro31, let me suggest a solution design for your comments.

1. Update frontend to be able to configure the new offset sensor option in entity registry.
2. Update RegistryEntry._as_display_dict() to include the offset sensor option.
3. Add SensorEntity._offset_or_none() function that reads the offset sensor option from the entity registry and casts it to float.
4. Call the above function in SensorEntity._async_read_entity_options() and save the offset in SensorEntity._sensor_option_offset property.
5. Update SensorEntity._numeric_state_expected() to return True when SensorEntity._sensor_option_offset is not None.
6. In SensorEntity.state() function, after calculating the numeric state but before the unit conversion, add (or substract?) the SensorEntity._sensor_option_offset from the numerical_value if the former is not None.
7. Optionally, add the new attribute ATTR_OFFSET = "offset" with the applied offset value from SensorEntity._sensor_option_offset.
8. Later, do the similar thing to the number entity.

I am willing to implement this feature if confirmed.

[allenporter]

This generally isn't a feature request discussion forum but a design discussion forum, so good to see an actual technical proposal rather than a feature request in the last post. 👍🏼

The goal to so solve the user problem of configuration from the UI makes sense to explore. I'm not an expert in sensor entities, but my initial feeling would be that SensorEntity model changes would not be the way to go here. The template entity approach, which composes and existing sensor value and exposes another sensor value seems much preferred from an architecture perspective.

My initial thought is that template sensors from the UI just got a lot easier https://www.home-assistant.io/blog/2023/09/06/release-20239/#template-sensors-from-the-ui which means users no longer have to write yaml to create an offset sensor. However, it will involve a small amount of templating. In the future this could be simplified with a blueprint as that work progresses.

A "Helper" could be another consideration, similar to the group, derivative, integration, threshold. However, it seems very similar to template sensor from the UI and may not provide enough differentiation.

[Shulyaka]

You are right, I should have shared the design earlier.
A template sensor / helper, or compensation integration can be a workaround.
However apart from not having the UI, the other problem with them is that they create a separate entity, which is disconnected from the device (no device registry linking the sensor to other entities of the same device) and introduces a sort of entity pollution, I mean it doubles the number of sensors you want to calibrate, requires hiding the main sensors and a rewrite of all references in automations and scripts, increases DB size, etc.
So I thought that adding an offset is a thing common enough (just like display precision calculation) that it would worth adding to the SensorEntity.

[allenporter]

I'm not sure that changes the concerns around entity model additions.

There was already a design pattern with other helpers that they work as separate entities and so I'm not sure this deserves a separate design pattern.

Entities can be hidden from the UI reducing the impact of entity pollution, and my impression is that some of those cases (groups for example?) even have hiding the original entity as part of the helper flow, but I may be remembering the detail wrong.

Said another way, from an architectural perspective I believe entity explosion has been declared as a UI problem ( then some amount of UI solutions have been added to manage and improve things).

[Shulyaka]

Why do you think that enhancing SensorEntity is bad from the architectural perspective? We are not making it more complex than it already is, considering the unit conversion and display precision. Also I am not proposing to pack every possible feature in it - only the basic and common ones, which I truly believe an offset is.

[allenporter]

Nothing different than what I said before: My opinion is that this is not a compelling use case for entity model changes given there is already a design standard that can do this (template entity, a helper) which is accessible from the UI and can continue to be improved from a UI perspective if needed. I acknowledge that you have a different opinion.