Separate precisions for climate measurements and setpoints

[jjlawren]

As seen in home-assistant/core#51536, there can be a mismatch between the precision required for measured values (current temperature) when compared to setpoints (target temperature). Too precise and it can lead to invalid values read/written to the setpoint(s). Too imprecise and more accurate temperature readings are lost.

I'd like to add an optional attribute (suggestion: _attr_setpoint_precision/setpoint_precision) for ClimateEntity instances which would override the precision applied to setpoint-related temperatures:

• ATTR_MAX_TEMP
• ATTR_MIN_TEMP
• ATTR_TARGET_TEMP_HIGH
• ATTR_TARGET_TEMP_LOW
• ATTR_TEMPERATURE

This optional attribute which would fall back to the existing precision attribute to avoid breaking changes.

[Jc2k]

One thing i'd like to get a better handle of is what the precision attribute means to the HA core. HomeKit devices are always in celsius. In this case the Ecobee does indeed report supporting increments of 0.1 C. But that's not the same of 0.1F, so can we really say its precision is PRECISION_TENTHS? The steps are like every 0.18 F. Should it be using PRECISION_HALVES in F and PRECISION_TENTHS in C?

[jjlawren]

In the specific case of Ecobee, its native scale is 0.1F but internally it converts those values into 0.1C increments when communicating via HomeKit. Even with losses in precision when converting, we know the intention of the values where the conversions don't land on expected temperatures.

If we know that the setpoint should always be in 1.0F (or 0.5F) increments, it's relatively easy to read & set the setpoint attributes with that in mind, even when converting from C->F (and back to C). The rounding will always be close enough to land on the desired temperature.

[Jc2k]

That's useful context for the team but doesn't really answer the question I have. PRECISION_HALVES seems to indicate values go up by 0.5 at a time. PRECISION_TENTHS therefore should go up by 0.1 at a time. But in this case technically (and remember homekit_controller isn't just for ecobee) we have temperatures that go up in steps of 0.18. Are we breaking the spirit of the data model here? The other interpration of the interface is that it just controls how the rounding happens, but that is a less useful data model if you were e.g. making a range slider from the data.

[Jc2k]

Does your suggestion solve the edge case where the UI looks like it hasn't reached the target temperature but the device thinks it has? Leaving the user confused why the device is idling below/above target temp?

In home-assistant/core#51536, if the user requests 74 F, the value sent to the device is 23.3 C. When the value is reported back to HA this becomes 73.9 F.

In my mind, having a different precision for the set point doesn't help with this case. The setpoint will show as 74 and the sensor will show as 73.9, and the climate entity will report it is idle because it reached the target temp of 23.3 C.

[Jc2k]

But that is exactly what is happening in the source ticket? Worse, temperature of 74F on thermostat comes through as 73.9F via HomeKit. So I don't think it's theoretical.

[jjlawren]

That margin of error is acceptable in the measured temperatures reported back to HA. It is not acceptable if the controllable setpoint does not align to expected values. This would be 1.0F increments for Ecobee, but may be 0.5F (at most) in other Fahrenheit thermostats. Separate precisions for measurements vs setpoint controls should address this.

[Jc2k]

It took some doing but I understand where my disconnect with your idea is. This idea solves the case where the target temperature is set to 74, but when it round trips through HomeKit it gets flipped to 73.9.

It does not try to address the case where the sensor value is rounded differently to the target temp. So under your proposal, even if the raw value from homekit for both the target temperature and the actual temperature was the same, one would be rounded to whole values (for example) and one would be not.

Your view is that given the target temperature is never that precise, it is fine to round it. I agree with that.

Your view is that 0.1 is a rounding error, and its fine for the measured value to be wrong by that much. I agree with that too.

The bit I have struggled to let go of is that I do think it is an unfortunate step backwards for the UI here where the target temperature can show as 74, the actual temperature as 73.9 and the state can be idle. Under the hood these numbers are the same, and technically everything is working. Yet to the user who doesn't even know their Ecobee has a secret double conversion under the hood, this is just going to look broken. Even though it still works, it will look broken to some users.

I assumed you were trying to fix both cases with this, hence my confusion.

[jjlawren]

Even if it reported more accurately, comparing the current temp to the setpoint cannot be used to know if the system is active. There is a (usually configurable) buffer range where the measured temperature and setpoint may cross before the system calls for heat/cool. This is calculated on the thermostat side and is difficult or impossible to reproduce on our side even now. For example, Ecobee conditionally averages readings across multiple sensors depending on schedule to make this decision. We should not try to emulate this as it already tells us the current activity with the hvac_action attribute.

[Jc2k]

Just like I was missing part of your point I think you are missing part of mine here.

I am not suggesting showing both temperatures at their original precision nor am I suggesting emulating hvac_action.

You have repeatedly said that 0.1 F precision isn't a thing on consumer grade thermostats.

So why show it with that much precision on the Lovelace card against a number that is rounded differently.

I think showing it rounded to 0.5 or even 1 in the UI is fine. At least in those particular cards.

I do support the idea of having the raw values available for graphs though.

[Jc2k]

Maybe we should step back and look at the problem we are trying to solve (with home-assistant/core#50415). You don't seem to actually care about 0.1 precision, as you've said a couple of times nothing consumer grade is that good. And to feel comfortable in our homes we don't need it to be that good. So what is the use case? Why is this better than how it was?

Should we store the raw values in the state machine and round appropriately in the frontend? Would that help your use case?

[jjlawren]

The measured temperatures are not exact, but higher precision is still useful if those values are used in a graph, for example.

The higher precision is not needed for the setpoint but they are currently tied together.

[Jc2k]

I thought it would be that, but we hadn't actually captured it.

I have a slightly different take, ny gut feeling is that we should round the data before we present it, and store the actual raw data in the state machine. That we the rounding can be appropriate for the context the data is being used in. Though I imagine that will be quite hard to change now!

[PeteRager]

This is a problematic and difficult as we have UOM conversion confounding the rounding. It’s also device dependent as noted. For example on the Lennox S30 I’m creating and integration for, increments are 1F or 0.5c. HA seems to fine with allowing the setpoint methods to take any value (-100 F). As a result I’ve implemented range checking and the 1F/0.5C rounding - to prevent bad data from going to the HVAC controller - because while Lennox should reject the data - they may not have tested this and I don’t want to brick the controller....anyways...I don’t have an answer yet, but here is my understanding:

1. Controller UOM. Represents the native units used by the controller. Could be C, F or both. The Ecobee uses C. Lennox allows either - for example heat setpoint - hsp or hspC - subject to that rounding rule and you have to send both.
2. User UOM. What the user sees
3. User Precision. The precision the user wants to see
4. Controller precision. Allowable setpoint values.

I believe everything works when Controller UOM = User UOM and User Precision = Controller Precision.

When the UOMs do not match, I believe HA converts/rounds the entity value / setpoint values on the way in/out to the integration. The integration may further round or truncate based on its rules. And it’s in this translation where precision is being lost and/or not representable (eg the 0.18 steps noted in this thread)

Is that an accurate summary of the issue?

[Jc2k]

Broadly i think your summary is correct. But an additional complication for homekit_controller is that the HomeKit protocol mandates C (presumably to absolve itself of responsibility for UOM issues), but the underlying device may not natively support C. In our case, the Ecobee natively seems to use F internally and on the device UI, but the HomeKit layer forces a UOM conversion to C, and then Home Assistant converts it back to F, which makes it even worse.

In the case of the Lennox S30 with homekit_controller, the homekit protocol would force it to use C for comms between HA and the device regardless of it supporting both. So the device UI might be in F, and the HA UI might be in F. So there are potentially UOM conversions on both ends there too.

As i'm in UK I haven't experienced any of these, my heating is in C, HomeKit is in C and my HA is in C, so I am fortunately conversion free. But makes it hard to fully test things!

Given 0.1 F setpoints aren't actually valuable to the user, the approach we have settled on for our specific issue (home-assistant/core#50415) is just to create a sensor entity in addition to the climate entity. The sensor entity shows the raw data from HomeKit without any precision loss. But equally, it doesn't cause any weird behaviour in the climate UI because of mismatches caused by precision loss. Hoping to have some time to work on this approach very soon.

[PeteRager]

got it, so a double conversion and 1 degree precision.

On the Lennox s30 I’m going after the cloud api, because their HomeKit integration is very minimal. The API sends information in both units. Right now I’m always reporting F, so sounds like I may have a variation of this issue and should return the C values when HA is in Metric so the values match the 0.5 Celsius quantization.