Can someone please explain how I can correct these double setpoints on my Zen Thermostat. I can’t find an answer and the team at Zen is unsure themselves. Any help would be appreciated. In this picture, I have the heat set to turn on at 5am for 72. It’s triggered, but then followed by a Setpoint of 65, which is for another time.
maybe one setpoint is cooling setpoint and the other is heating.
Are we zen yet?
Check the logs in ST and Zen to see if there is a rule firing setting the set point.
Is the setpoint 65 before it goes to 72? The setting of the temp to 72 could be failing, and on polling it is pulling the 65 again.
Does changing temps through ST device handler change the temp on the thermostat? Making sure that everything is integrated.
Disclaimer: Don’t own a Zen thermostat
Don’t have it set up for cooling. Only using it for heating.
Yes, at night it’s 65, then programmed to change to 72 in the morning. It works at times, but has its moments like this one. When I request it to change, it can sometimes do the same as mentioned above. How would I be able to check the rules at firing a Setpoint?
I am guessing that the 72 is never really set. Working on Nest Manager we ran into this issue.
So here is the flow.
- Temp is 65
- Change temp to 72 is sent, DH updated
- Change temp fails
- Next repoll sees that the temp on the Zen is 65 and updates the temp in the DH
Open up live logging in the IDE, and try changing the temps through the DH and through rules. See if there are any errors coming from the Zen DH.
In the IDE you can go to My Devices->Zen Thermostat-> List Events, you may be able to see what happen.
There are problems with the Zen DTH. The challenge is that the setpoint can be controlled from SmartThings or directly on the thermostat. The DTH gets confused and overwrites the SmartThings update with the local thermostat setpoint.
To see it really fail, try to tap the set temperature arrows a few times, you’ll see that your change is quickly overridden.
I think adding some kind of smart delay in the DTH would fix the issue.
Know anywhere that might be able to direct me to implement this. I’m kind of new navigating this.
You’ve got to edit the code for the DTH (device type handler). I’ve done a little coding in SmartThings but not an expert.
You could try to use a different DTH, like the Centralite or the Fidure one. Theoretically all ZigBee HA thermostats should use a common interface.
1 Like
I have this same problem I think, just using the standard Zen DTH and no routines. If I tap ‘down’ on the Zen ‘device’ in the iOS app a couple of times to drop the heating set point temperature, after a few minutes something puts it back to the original temperature. I need to spend some time looking at what the physical Zen thermostat says during that period and what the logs in the IDE say. I’m somewhat suspicious of the way the clearly fahrenheit oriented DTH ends up trying to set 20.2C, 20.7C etc. as set points (I guess converted from F to C) when my Zen is in C and shows 20, 20.5, 21, 21.5 etc. on its display. Is it perhaps rejecting a request for 20.7c?
Anyone with any further updates on this? I’m still having this problem where heating setpoints are overwritten a few minutes later. Very frustrating.
Zen support says there’s a new firmware being tested but it still hasn’t been released and no one at ST can confirm it exists let alone give any more info on when it might be released.
My unit reports in the Smartthings IDE as having version 0x204. What does everyone else have?
I am having the same issues and have the same firmware. Has anyone heard anything from SmartThings support?
Current Version: 0x00000204
It looks like the latest firmware update yesterday fixed my issue with the Zen thermostat. Anyone else see that it corrected the problem even though the firmware notes didn’t make any mention of it?
1 Like
My CT100 Thermostats no long connect. All 4 of them are now off line.
I’ve had a support ticket open with ST since early December. They are/were still working on it (as of an update late December) but it sounds like there’s no definitive issue that’s been found. He said Zen are also looking into it at their end. I get the impression that it’s not the highest priority - that’s unfortunate but I guess there are lots of other devices and features that affect more people.
Being “down under” I have no need to heating at the moment so I’ll just cross my fingers it’s fixed in the next few months…
Really?! I’m not really using the Zen at the moment but it’s fantastic if they have fixed it. I’m on the hub firmware beta and one of the earlier builds mentioned “fixing occasional zigbee message corruption” or words to that effect.