@bobbyD This has been in the driver for the last few releases but I kept forgetting to raise it. It only seems to impact my AC / Heat Pump thermostat, but basically it shows the Heat setpoint as 20.5c when it's actually 20.0c.
Driver:
Actual:
If I manually change the temp to 21c and then back to 20c, the driver does correct itself. This happens every day without fail when my morning rule sets the setpoint to 20c.
PS, I've tried re-adding it to the Zigbee network and this made no difference.
you have more than one zen thermostat?
Yep, downstairs I have one running a simple 2 wire Gas heating system.
Edit: they are both running the same FW (latest version):
Upstairs:
Downstaris:
If the other is reporting as expected then its unlikely a driver issue...
I've factory reset the Thermostat and re-paired it with no change - you might be correct, however this started from (iirc) 2.3.4.139. I just kept forgetting to report the issue.
@mike.maxwell I just did some more testing and found the following:
I used the driver setpoint functions and the UI still reported 20.5c instead of 20.0c:
However, If I send 21.0c and then 20.0c it reports the correct setpoints for both.
dev:8792023-09-21 09:51:29.004 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:51:28.996 AMtraceupdateSetpoints params- sp:null, hsp:20.0, csp:null, os:heat
dev:8792023-09-21 09:51:28.988 AMdebuggetHeatingSetpointResult:20
dev:8792023-09-21 09:51:28.973 AMdebugdescMap: [raw:DF270102010A120029D007, dni:DF27, endpoint:01, cluster:0201, size:0A, attrId:0012, encoding:29, command:0A, value:07D0, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:51:20.015 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:51:20.008 AMtraceupdateSetpoints params- sp:null, hsp:20.0, csp:null, os:heat
dev:8792023-09-21 09:51:20.000 AMdebuggetHeatingSetpointResult:20
dev:8792023-09-21 09:51:19.993 AMdebugdescMap: [raw:DF270102010C120029D007, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:07D0, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:51:19.870 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:51:19.862 AMtraceupdateSetpoints params- sp:null, hsp:20.0, csp:null, os:heat
dev:8792023-09-21 09:51:19.855 AMdebuggetHeatingSetpointResult:20
dev:8792023-09-21 09:51:19.848 AMdebugdescMap: [raw:DF270102010C120029D007, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:07D0, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:51:19.566 AMinfoUpstairs thermostatSetpoint was set to 20.0°C
dev:8792023-09-21 09:51:19.559 AMinfoUpstairs heatingSetpoint was set to 20.0°C
dev:8792023-09-21 09:51:19.551 AMtracechanged?- sp:false, hsp:true, csp:false, os:false
dev:8792023-09-21 09:51:19.544 AMtraceupdateSetpoints params- sp:null, hsp:20.0, csp:null, os:heat
dev:8792023-09-21 09:51:19.537 AMdebuggetHeatingSetpointResult:20
dev:8792023-09-21 09:51:19.530 AMdebugdescMap: [raw:DF270102010C120029D007, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:07D0, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:51:16.306 AMinfosetHeatingSetpoint(20)
dev:8792023-09-21 09:51:08.169 AMinfosetHeatingSetpoint(20)
dev:8792023-09-21 09:51:04.888 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:51:04.880 AMtraceupdateSetpoints params- sp:null, hsp:21.0, csp:null, os:heat
dev:8792023-09-21 09:51:04.873 AMdebuggetHeatingSetpointResult:21
dev:8792023-09-21 09:51:04.858 AMdebugdescMap: [raw:DF270102010C1200293408, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:0834, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:50:57.754 AMtracechanged?- sp:false, hsp:false, csp:false, os:true
dev:8792023-09-21 09:50:57.740 AMtraceupdateSetpoints params- sp:null, hsp:null, csp:null, os:heating
dev:8792023-09-21 09:50:57.730 AMinfoUpstairs thermostatOperatingState is heating [stage 1]
dev:8792023-09-21 09:50:57.719 AMdebuggetThermostatOperatingStateResult: 5
dev:8792023-09-21 09:50:57.709 AMdebugdescMap: [raw:DF270102010A2900190500, dni:DF27, endpoint:01, cluster:0201, size:0A, attrId:0029, encoding:19, command:0A, value:0005, clusterInt:513, attrInt:41]
dev:8792023-09-21 09:50:57.671 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:50:57.662 AMtraceupdateSetpoints params- sp:null, hsp:21.0, csp:null, os:heat
dev:8792023-09-21 09:50:57.645 AMdebuggetHeatingSetpointResult:21
dev:8792023-09-21 09:50:57.636 AMdebugdescMap: [raw:DF270102010C1200293408, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:0834, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:50:56.156 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:50:56.149 AMtraceupdateSetpoints params- sp:null, hsp:21.0, csp:null, os:heat
dev:8792023-09-21 09:50:56.139 AMdebuggetHeatingSetpointResult:21
dev:8792023-09-21 09:50:56.132 AMdebugdescMap: [raw:DF270102010C1200293408, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:0834, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:50:56.076 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:50:56.066 AMtraceupdateSetpoints params- sp:null, hsp:21.0, csp:null, os:heat
dev:8792023-09-21 09:50:56.055 AMdebuggetHeatingSetpointResult:21
dev:8792023-09-21 09:50:56.048 AMdebugdescMap: [raw:DF270102010C1200293408, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:0834, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:50:55.863 AMtracechanged?- sp:false, hsp:false, csp:false, os:false
dev:8792023-09-21 09:50:55.835 AMtraceupdateSetpoints params- sp:null, hsp:21.0, csp:null, os:heat
dev:8792023-09-21 09:50:55.804 AMdebuggetHeatingSetpointResult:21
dev:8792023-09-21 09:50:55.785 AMdebugdescMap: [raw:DF270102010C1200293408, dni:DF27, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:0834, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:50:55.709 AMinfoUpstairs thermostatSetpoint was set to 21.0°C
dev:8792023-09-21 09:50:55.701 AMinfoUpstairs coolingSetpoint was set to 23.0°C
dev:8792023-09-21 09:50:55.690 AMinfoUpstairs heatingSetpoint was set to 21.0°C
dev:8792023-09-21 09:50:55.682 AMtracechanged?- sp:false, hsp:true, csp:false, os:false
dev:8792023-09-21 09:50:55.674 AMtraceupdateSetpoints params- sp:null, hsp:21.0, csp:null, os:heat
dev:8792023-09-21 09:50:55.666 AMdebuggetHeatingSetpointResult:21
dev:8792023-09-21 09:50:55.659 AMdebugdescMap: [raw:DF270102010A1200293408, dni:DF27, endpoint:01, cluster:0201, size:0A, attrId:0012, encoding:29, command:0A, value:0834, clusterInt:513, attrInt:18]
dev:8792023-09-21 09:50:51.965 AMinfosetHeatingSetpoint(21)
Notice how the thermostat setpoint now matches the heating setpoint and it didnt previously. The cooling setpoint also updated and I didnt touch that.
My Downstairs stat only controls heating, vs upstairs which does heating and cooling (reverse cycle AC) so I dont think it is a fair comparision.
We run our upstairs system in Auto mode overnight, when it's been a warm day and it'll be a cool night, with a min/max temp and im wondering if this has anything to do with it. As in, the driver isn't handling the changeover properly.
@bobbyD @mike.maxwell there is definitely still an issue with the Zen driver.
I installed a new Zen Thermostat, with different FW, today and am still seeing issues with the driver not correctly updating the Thermostat Set point after it's been changed via HE.
eg I sent 22.0c to the Thermostat:
Thermostat updated:
But driver still thinks set point is 22.5:
Here are the details of this Zen Unit:
Does the device display even have the ability to show the decimal .5 degrees?
It does look like in the log that the device is responding back with "22", so not sure why the driver would be setting it to 22.5
It sure does (I just manually changed it to 22.5c for this photo):
The driver is missing a step in some circumstances - as a result the HE dashboard and others (HomeKit, Alexa etc) frequently don't show the correct value. If I update from the Thermostat, it usually does reflect the correct value in HE.
The driver is only displaying the wrong set point info, it usually does set it correctly.
Its on the thermostat to report any changes.
Out of interest is the setpoint uodated when refreshed ?
I didn’t try hitting refresh at the time, it’s going to be hot later on so I’ll try it then.
And if I change the set point from the thermostat, it does. So that’s why I think there is a driver issue.
I had this discussion with Brian C I think, where I was critical of the approach used in the Hubitat Thermostat controller app.
My feedback was, I can’t trust a system that sends commands and doesn’t bother to check that they have been received and implemented.
The same seems to apply here, in the logs I can see set point commands being sent, but there is no verification to confirm. Hence the driver not displaying the current set point.
IMO, especially when dealing with battery powered thermostats, this is a must have. Many of us do not have a C wire option, for many different reasons.
It isnt. Other zigbee and z-wave thermostats do not behave this way.
So in your opinion, what is the solution?
I dont have one. This issue does seem to be worse when running on batteries.
And not all of them seem to have the issue on the first place.
Can we just add set point etc verification to the driver please? This would greatly improve reliability and render any quirks in the Zen moot.
PS I do see this on my other Zen, but not as often as it only runs heating for downstairs and doesn’t get used as much.
@mike.maxwell Just to add another 2c, I’ve managed data centres and worked with the engineering teams that manage massive mail and parcel sorting machines for Australia Post.
All of those systems are automated to the maximum extent possible using SCADA and other similar systems.
While I don’t claim to know the nuts and bolts of how they work, one thing I do know is that NOTHING is ever assumed. Every command sent, no matter how minor, is verified by the target device. If the target device doesn’t respond to the controller, it’s sent again until it’s acknowledged.
If it isn’t acknowledged within specified time windows or number of retries, an alert is raised for it to be investigated.
Now I don’t expect home automation systems to be as robust as industrial automation systems, however, I think it’s madness for Hubitat to assume 100% of commands sent are received and acted upon.
How about some sensible levels of “trust but verify” being implemented across the board?
Which driver are you using? I've had my share of issues with the Zen thermostat I have.
endpointId: 01
firmwareMT: 1158-0002-00000210
lastRunningMode: cool
softwareBuild: 00000210
However, since I switched to the built-in Zen driver instead of the user driver, my thermostat has been behaving. I don't use the thermostat scheduler or controller apps. Instead, I have a set of rules that I run for mode changes and for behavior when we leave or arrive home as well as at night. I have other rules that run periodically and verify that the thermostat setpoints are correct for the current situation (home, away, or night).
In my rules, I did find that I needed to add a 15 second delay between setting the cooling setpoint and setting the heat setpoint. Once I did that, the setpoint changes became reliable. I have not had the issues I had before finalizing my rules.
I honestly didn’t know there was a user driver for Zen thermostats. So I’m using the Hubitat developed driver.
Same here. But sometimes we still want to adjust the set point manually via HomeKit or Hubitat dashboard. It’s just not possible to automate all scenarios.
So frustrating, I can’t replicate the issues today. 
Honestly, I would just love for Hubitat drivers to have some command verification. I think trusting our devices to behave 100% of the time is just not realistic.
Download the Hubitat app
