I would love it if there were a simple way to calibrate entities. For instance, I have a few humidity sensors, and I’ve tested them so I can match up their offsets, but there’s no easy way to tell Home Assistant that (this humidity sensor should read 5% higher). Such a thing would be amazing!
This could done through helpers kind of like switch → light replacement works, creating a new, calibrated entity. It could also be built into the entity model, but that seems less consistent with HA’s approach.
It does not support offsets (degree 0 compensation) like “add 5%”. To accomplish that, you have to fake data by giving it at least two pairs of comparison points.
It’s not configurable through the GUI.
Even if it supported degree 0, without additional changes you’d need to give it a target point and a measurement point (e.g., show 55% for 50% measurement) rather than the offset (5%), which is non-intuitive.
You may already know this, but just in case. You can use a template helper sensor to ingest the state of the original humidity or temp and then offset it by whatever you like. You could even create a seperate input number helper to set whatever you would like the offset to be dynamically.
{{ (states('sensor.my_hunidity_sensor') | float) * 1.05 }} would give you the sensor value + 5%.
Or create a input number helper and pull the offset from there: {{ (states('sensor.my_hunidity_sensor') | float) * (states('input_number.my_hunidity_sensor_offset') | float) }}
Thanks! Good point that that’s another useful workaround. I’ve gone that route too, and it works. I’ve also done the compensation integration with two “fake” points to create an offset. They’re a similar amount of work, both with upsides and downsides; I was just hoping for something a little less clunky.
Funny re the 4th downside being creating a new entity. Totally agree—I originally had 4 points, but I decided to drop that one because my suggestion of making it like switch → light conversations also creates a new entity (and hides the old one). But a totally fair point!
It creates a polynomial, you can get any offset you want. e.g.
offset of five, provide
0, 5
1, 6
as your points.
Yes, it’s not a single field, but it can be done pretty easily.
Lastly, It may be coming to the UI soon, waiting on a few outstanding core PRs to get it there. Basically waiting on a Selector that allows for an endless list of 2 numerical pair values.
Thanks! As you note, that (creating two pairs of fake data points to create 1st-degree polynomial) is the workaround I was referring to. At a minimum, I’m just not all clear why it doesn’t support a 0th-degree polynomial with a single pair of points. This would still require “fake” data but would fit the current model fine. If the polynomial handling gets complicated for 0th order, you could have a 0th-dgree polynomial with point [x, y] simply internally fake a 1st order polynomial with a second point, [x+1, y+1] with identical results.
I realize the single-value offset is a special case, but it’s such a common one that I think it might be worth some special handling. For instance, if the integration supported 0th order polynomials, you could add an “offset” parameter which, if set, internally creates the “fake” point through you, which could just be [0, 0+offset]. (And presumably it would not allow both data_points and offset to be set.) I suspect this would allow it to be added without much extra effort and with no breaking changes.
Regardless, I really love that y’all are improving the UI with such a selector and that configuring this through the UI will be possible at some point—thanks!
A zero degree poly is just a single value y = b. What you’re asking for is just an offset. Y = x + b, which is a 1 degree poly, which is doable the way I described.
My apologies! I did misuse the terminology at the top and that probably means the first part of my post is unnecessary. As you suggest, the offset is 1st-order, not 0th—but with a fixed coefficient of 1 for the x^1. This means you could do what it says and fake the second data point for an offset, but that’s less useful than just handling the offset. So with that clarified, here’s a fixed and simplified version of the above post. I think the core point is still valid—and probably easier to implement—though let me know if I’m wrong:
Thanks! As you note, that (creating two pairs of fake data points to create 1st-degree polynomial with an offset) is the workaround I was referring to.
I realize the single-value offset is a special case, but it’s such a common one that I think it might be worth some special handling. For instance, you could add an “offset” parameter which, if set, internally creates the “fake” points, which could just be [[0, 0+offset], [1, 1+offset]], similar to your example. (And presumably it would not allow both data_points and offset to be set.) I suspect this would allow it to be added without much extra effort and with no breaking changes.
Regardless, I really love that y’all are improving the UI with such a selector and that configuring this through the UI will be possible at some point—thanks!