Heating Set Point off by 0.2°F

Same here with our zwave thermostats. I’ve messaged with ST support in circles. So far they’ve told me I needed to update the app, which is what got me in this situation. I did and same issue. Going in circles with them. Frustrating. Seems to only be the heat doing .2 and then out of range.

.2 for me too

I even linked this thread in my last error report. All I get is to delete the app and reinstall. Super frustrating!

ST support told me a couple of weeks ago that an iOS app update (1.7.26) was coming and to watch for it.
I am on that version now with no change in behavior. I guess it was silly of me to assume that it was going to fix it.

1 Like

Which specific driver should I choose from your channel? I see a few named z wave. Thanks!

You’re looking for his zwave thermostat driver? It’s called “Z-Wave Thermostat Mc”

Mariano is likely not to respond for a while. He’s taking a long break away from the community for a bit.

Ah thank you. Unfortunately it isnt working me either. So frustrated with ST.

1 Like

I had this issue with my zigbee thermos, but ST managed to get the .2 issue resolved with that driver, thankfully. Sorry to hear this is still happening on the zwave driver.

I have Zigbee Thermostats and I still have the issue.

And you’re using ST’s edge driver?

No, I’m using Mariano’s driver, I will switch to the ST driver and see what happens.

Any chance someone who already has a driver release channel set up could clone the zwave-thermostat driver and update the heatingSetpoint values in some device profiles for Fahrenheit users?

For base-thermostat.yml and base-thermostat-without-battery.yml, it looks like the following values would work well when converted from C to F:

  - id: thermostatHeatingSetpoint
    version: 1
    config:
      values:
        - key: "heatingSetpoint.value"
          range: [ 3.9, 27.8 ]

Or this may be another way to fix it:

  - id: thermostatHeatingSetpoint
    version: 1
    config:
      values:
        - key: "heatingSetpoint.value"
          range: [ 4, 28 ]
          step: 0.1

This is on my wish list too !! Over two months since ST broke this and I am extremely disappointed with the lack of support from them, Its bad enough that it takes 1-2 days for them to acknowledge a problem report with a message simply stating they have received it and it will take a look, and when they respond days later (if Im lucky), its either requesting info that I’ve allready sent to them, or they treat my submission of the info they requested like a "new’ issue and start telling me to uninstall the device, reset the hub, yada yada. I worked in IT for decades…I did that before I asked them for help and several times at their request. It looks like a simple fix and I now realize it would have been more efficient if I researched what was involved in making a custom driver version of the current ST driver. The entire support process is FLAWED.

I made your first suggested change for the base-thermostat.yml and base-thermostat-nobattery.yml profiles. You can subscribe to my test driver channel here and try out the modified driver. If there are other profiles that need to be updated, let me know and I’ll update those as well.

Thanks for helping chase this down.

I switched one of my 3 Trane Z-Wave thermostats (fingerprinted to base-thermostat-without-battery) over to the test driver. At first it wouldn’t connect, but a hub reboot through the advanced web interface brought it back. Unfortunately, it’s still not working correctly - but it’s broken in a slightly different way. Instead of showing the correct setpoint of 69.0 momentarily before changing to 69.2 then “Out of range”, it changes to 41.0 then Out of range.

Would you mind trying the second suggested change? I’d also recommend adding something like “F Only” to the driver name in case this breaks something for Celsius folks.

Done and published.

OK, so this is a partial success - the automatic jump up 0.2° and then Out of range no longer occurs - however, the temp slider is now unusable because setting the value to anything other than a whole integer results in “Out of range” and a heatingSetpoint of 2F being pushed to the thermostat.

Could you please implement both fixes for now? I’d like to try a few things to see if I can get the app to reset the start point for the adjustment slider. If I am successful, the first fix we tried should take care of it.

edit: Actually, let’s try 5C as the first value in the range. That’s exactly 41F, so there shouldn’t be any issues with decimals.

Updated and published.

I’m both less and more confused now. First off, I figured out how to force an update of the slider temperature range without excluding and re-adding the thermostat. I switched to the Z-Wave Explorer driver and back, and the change in capabilities seems to trigger a reset of the starting temperature. However, there’s also some weirdness around temps below 40 degrees, as there’s a routine in init.lua that converts any value under 40 from C to F. Can you try setting the start point to 5C to avoid the range starting below that point? That converts cleanly to 41F, so no decimal issues.

I have no idea if that’s the cause, but now both thermostats I’ve switched to this test driver keep dropping to very low F values shortly after I set a new temperature. The setpoint drops from 69 to 41 to 16 degrees. I’m going to switch back to the default driver for now, but I’ll test again after you’re able to update it to a 5C start point. Also, you can get rid of the “step: 0.1” line now, since I’ve figured out how to reset the slider range.

Step removed and range set to:

range: [ 5, 27.8 ]