I’ve seen a few posts about this, but all the ones I was able to find in GitHub issues and in here either aren’t related to what I’m asking, the post just goes stale, or they found some workaround. If this is a duplicate, my apologies…I looked around, but there’s a lot of results when searching for temp…offset, calibration, adjustment, etc.
This feature request is to add a simple offset setting for temperature entity sensors, where it does not require creating a new sensor.
When I was on SmartThings, they had this option, you could open the sensor, go into settings and just set a static offset value. It was very simple.
I have since had to build my own solution for this. I’ve seen the solutions using the compensation integration and wasn’t really a fan of it, so I built my own over complicated one.
This is irrelevant to the feature request, but just to explain what I’m doing now…
For espHome sensors, you do it with a lambda in the firmware itself.
For other sensors, it is either done with the mfg’s instructions, or creating a template sensor to to the math using the compensation integration or some other conversion.
Do you have specifics in mind?
TL;DR HA itself only reports the numbers it is given, and the integration has to be adjusted or you have to feed it thru another integration that will do the compensation (template sensor).
The issue I’m seeing is the current advice/solution is…either determine if the integration you are using happens to support this capability (ESPHome, ZHA, Zigbee2MQTT, etc), or create a new sensor (template, compensation, etc).
Having to handle this on an integration by integration basis seems like it defeats the goal of using Home Assistant in the first place. I realize you can use Templates, but that starts to feel like overkill for what I feel is a pretty common need.
I’m asking for an integration agnostic solution, a feature built into Home Assistant at the entity level which allows configuring a custom offset value for temperature sensors in the same way that SmartThings handles it. This way it doesn’t matter what integration you’re using because it’s at the entity level.
If it’s not possible based on the Home Assistant internal architecture, so be it. But I feel it’s at least worth asking.
The integration is responsible for reporting the physical sensor’s value.
What you’re requesting is for something that doesn’t exist; a middleman that processes all data from all integrations prior to committing it to the state-machine.
The odds for modifying Home Assistant’s architecture to support such a middleman are low.
That’s why Template, Filter, Derivative, Statistics and other data processing integrations exist.
There is precedence for streamlining something similar in the interface. I’m thinking specifically about changing a device class (switch to a light etc). I could imagine a calibration feature that would work in a similar way, hiding the original sensor and creating a calibrated one, connected to the same device, everything clean and easy to set up.
It’s a change that results in a new entity being added automatically and the original one being hidden automatically. That’s how it is similar to what I suggested. Of course it’s different in that the entity state is not being changed.
But the principle would be the same here: an interface feature to streamline setting up the template or whatever method to calibrate the sensor.
The original entity’s underlying integration remains responsible for supplying the new entity’s state value. The switch’s boolean value remains boolean. The UI for "change device type of a switch’ has no influence over the values generated by the underlying integration. It’s just a convenient way of rearranging some configurational furniture.
The FR is asking for the entity’s domain to remain unchanged but for “something” to sit between any integration (that creates sensors) and the state-machine. This middleman would perform optional processing of the values reported by the integration.
To be fair, you’re looking at this from the perspective of an engineer and not a product owner. And I’m posting this feature request as an end-user and not an engineer.
As the end-user, I’ve identified a problem that I run into that I would like to see resolved by way of a new feature.
The way I envision that feature is how I’ve explained it…but at the end of the day, I am not an HA engineer.
So it’s up to those acting as product owners to read and interpret that request, determine its value/priority and it’s up to the engineers to determine how to implement that feature request based on the current architecture…whether that be utilizing existing architecture or determining whether it’s worth changing the architecture.
Those two people may be the same person.
Since I am not an HA engineer, I have no say In exactly how this should be implemented. So there’s no reason to strictly abide by how I’ve envisioned it would work.
