Since the last major update this has been the temperature in my house according to my honeywell thermostat on HA. I can assure you all it is not 22f in my dining room. It is in fact 72. And actually this error only occurs at 72 as well. as soon as it goes above to say 73 it is fine. The temperature is displayed correctly on the t-stat its self. And all was working great until the most recent monthly update.
22c is 71.6 F
I just noticed that, but why, since the last update has HA been reading it as that is what I want to know? :s
it’s probably a display bug
Possibly, but why only at that specific temperature… As soon as it goes up a little it is fine. I’m curious if I raise the temp to 73.4 if it will display 23f instead.
Time to find out I guess. Full steam ahead! I’ll have to watch the graph because the odds of me getting a stable temperature of exactly 73.4 are pretty low.
That’s the nature of bugs, gotta figure out why it’s doing that. I have that thermostat and it has the same issue. i.e. it’s probably just a bug that needs to be written up against the frontend.
It’s not really new. This issue has been reported many times before, esp. for Honeywell models. Maybe you just never noticed it before. Or, maybe there is some unrelated change that makes it happen more often.
Either way, switch to ZUI and set the preferred temp scale to F and it will be less likely to occur, but not 0% of the time (HA does not support this feature). These devices decide to send temperature values in different units (F one time, C another), and HA doesn’t recognize the change in units. That’s a bug in the integration. If you wait long enough it will fix itself.
Seems like it does it every time it gets to a whole number in celsius. And while it maybe an old bug for other people I’ve never seen it. And I doubt it was for a lack of looking. Something had to have changed to expose it with the most recent patch.
What are you referring to as “the most recent patch”?
Anyways, perhaps a new occurrence for you, but generally not new:
Simply has to do with the units switching.
It started for me with version 2023.4. like I said something changed recently for it to rear its head now.
Regardless, it’s the same problem others have experienced over the last two years. HA determines the temperature unit based on the first setpoint’s unit, which is F. The current temperature value is based on multilevel sensor temperature reports. The device will typically report in F, but when it switches reports to C, as these Honeywell ones are known to do, HA does not do the temperature conversion, thus you see values in C (like 23) reported as they are F.
If you’d like to see it fixed, I’d capture integration and driver debug logs during the time it reports incorrectly, and submit an issue to HA, attaching the logs. It’s unlikely to be addressed without these logs.
I had this pop up again recently. zwavejs was reading the temperature as centigrade but setpoints were fahrenheit. i had forgotten about it but it seemed to work itself out.
It doesn’t solve it, but reduces the likelihood. Preferred scales only controls how ZJS queries the device, either on interview or refresh. The device may send with other units regardless.
As a workaround, you can manually refresh the air temperature value with the correct scale.
From HA, service:
service: zwave_js.invoke_cc_api
data:
command_class: "49"
method_name: get
parameters:
- 1 # sensorType: Air temperature
- 1 # scale: F
target:
entity_id: climate.z_wave_thermostat
From ZUI, click the refresh button in the control panel for Multilevel Sensor
The HA method will only refresh temperature. The ZUI method will refresh all sensors supported.
For another perspective that probably doesn’t apply in your situation since the behaviour changed after an update. But for those curious:
“the odds of me getting a stable temperature of exactly 73.4 are pretty low”
Except that thermostats lie. Especially Honeywell ones.
They’ll undershoot by a degree and then overshoot by a degree during their heating cycle 3x~ per hour. Your reading of 73.4 (23C) may be reporting as very consistent although in reality it’s all over the place. This is by design.
If you change the setpoint, often the thermostat’s “reading” will instantly change to read the same as the setpoint as long as it’s within a degree or two.
Not to mention, thermostats are often placed next to return ducts so that they’ll get a half decent reading since they’re not in motionless air, but this only goes so far. Often the reading can be consistently higher or lower by a couple degrees depending on placement and air dynamics. If you do 24/7 circulation this can even-out heat inconsistencies due to windows, motionless air and such, but can be not worth the cost (and don’t even think of circulating a lot if you have an old PSC motor, only if you have a modern ECM motor which have better lifetime and efficiency)
Thanks for this!
Trying the Service call on mine and set up as an automation to run every 2 hours.
How did you determine the command_class?
Since the thermostat data is flakey, why not kludge a fix: If the value is less than 40, it’s Celsius. Otherwise it’s Fahrenheit. Those two scales should never overlap in a home, especially one that has a home automation thermostat.
Shouldn’t be a problem anymore, for this device at least. There indeed was a recent bug that caused this problem to appear more often than before, and it is now fixed in Z-Wave JS v10.23.0. The driver was defaulting to using Celsius as a preferred scale if it was not configured, instead of requesting the same scale as the last report. While setting the preferred scale in Z-Wave JS UI is a solution, it shouldn’t be necessary if the device is already reporting in the correct scale.
The official add-on does not yet have the fix, but ZUI and the ZUI add-on both do.
There is still a bug in HA as it does not handle scale changes, but for this device it should report correctly.
