Zen Thermostat driver broken in 2.3.4.x

Ever since 2.3.4 was released, my zen thermostat’s have been broken. The driver reports status's that dont match reality. eg:

However it's actually off:

At first I thought my rules that drive my 2x Zens were broken, but this has kept happening day after day.

@gopher.ny @bobbyD

I doubt this is a 2.3.4 issue. Can you revert to 2.3.3 and verify?

1 Like

I'd rather not, I've already ported a number of devices to the new Apple HK integration.

Steps I've taken to date:

  • gracefully shutdown and powered off my C7,
  • changed batteries in the Zen's
  • and even rebuilt my TSTAT RM 5.0 rules in RM 5.1.

This leaves me thinking something in 2.3.4.x is the culprit - especially as both Zen's are doing the exact same thing.

If you set the thermostat modes from the driver does it operate correctly?

Then can you enable debug logging, then from the thermostat set the mode to heat wait a few seconds then set it to off and post those live logs.

I tried it just then on the Upstairs unit which I had intentionally left alone - it was showing "heat" in the Dashboard etc but was in fan only mode: It changed via the driver as commanded:

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:39:03.658 AM[debug](http://192.168.1.170/logs#)getThermostatRunningModeResult:4

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:39:03.655 AM[debug](http://192.168.1.170/logs#)descMap: [raw:BF91010201081E003004, dni:BF91, endpoint:01, cluster:0201, size:08, attrId:001E, encoding:30, command:0A, value:04, clusterInt:513, attrInt:30]

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:39:03.333 AM[info](http://192.168.1.170/logs#)Upstairs thermostatMode is heat

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:39:03.332 AM[debug](http://192.168.1.170/logs#)getThermostatModeResult:4

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:39:03.330 AM[debug](http://192.168.1.170/logs#)descMap: [raw:BF91010201081C003004, dni:BF91, endpoint:01, cluster:0201, size:08, attrId:001C, encoding:30, command:0A, value:04, clusterInt:513, attrInt:28]

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:39:02.910 AM[trace](http://192.168.1.170/logs#)heat()

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:38:48.379 AM[warn](http://192.168.1.170/logs#)description logging is: true

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:38:48.378 AM[warn](http://192.168.1.170/logs#)debug logging is: true

[dev:879](http://192.168.1.170/logs#)2022-12-01 10:38:48.376 AM[info](http://192.168.1.170/logs#)updated...

[dev:879](http://192.168.1.170/logs#)2022-12-01 08:58:20.882 AM[info](http://192.168.1.170/logs#)Upstairs thermostatOperatingState is fan only

[dev:879](http://192.168.1.170/logs#)2022-12-01 08:58:17.009 AM[info](http://192.168.1.170/logs#)Upstairs thermostatFanMode is on

[dev:879](http://192.168.1.170/logs#)2022-12-01 07:36:32.374 AM[info](http://192.168.1.170/logs#)Upstairs battery is 100%

Just in case this is my fault (always possible) - here is my DS rule:

and I noticed both US and DS Zen's are showing this in the logs at 6am (when the house changes from Night to Home modes):

Im not sure if this is related to my rules being triggered multiple times?

EDIT: I do have a rule that turns them off as a way to reset them at 6am. I've never had this issue in the past and it seems like because the Zen's aren't reporting back correctly, the 2 rules are overlapping?

A side issue I've been having with the Zen, is when I am running fan only (on) thermostat mode (off) and use the dashboard to turn the fan off (auto) it seems to put also put the thermostat mode to (auto) as well when I want it to stay off. I have also noticed this occurring from selecting fan (auto) on the device page itself turning the thermostat mode to (auto) when it was previously set to off.

I do use a mix of virtual devices on one hub that has the dashboard connecting to the zigbee hub via node red, haven't spent much time investigating but it used to work fine as intended a few updates back but has been acting this way for a few update cycles now.

Have been making due with adding more "refresh" and "thermostat off" nodes to my flow to keep from going to auto mode.

I've got rules managing my fan - eg "Fan on for 1 hour", so I haven't noticed that issue myself.

I needed you to change the mode from heat to off, im not seeing that in the logs. Is that the operation that you performed at the thermostat?

Oops, I'll learn to read! :man_facepalming:

That worked fine:

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:30.782 AM[debug](http://192.168.1.170/logs#)getThermostatRunningModeResult:0

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:30.774 AM[debug](http://192.168.1.170/logs#)descMap: [raw:BF91010201081E003000, dni:BF91, endpoint:01, cluster:0201, size:08, attrId:001E, encoding:30, command:0A, value:00, clusterInt:513, attrInt:30]

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:30.454 AM[info](http://192.168.1.170/logs#)Upstairs thermostatMode is off

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:30.449 AM[debug](http://192.168.1.170/logs#)getThermostatModeResult:0

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:30.443 AM[debug](http://192.168.1.170/logs#)descMap: [raw:BF91010201081C003000, dni:BF91, endpoint:01, cluster:0201, size:08, attrId:001C, encoding:30, command:0A, value:00, clusterInt:513, attrInt:28]

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:30.079 AM[trace](http://192.168.1.170/logs#)off()

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:12.794 AM[debug](http://192.168.1.170/logs#)getThermostatRunningModeResult:4

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:12.788 AM[debug](http://192.168.1.170/logs#)descMap: [raw:BF91010201081E003004, dni:BF91, endpoint:01, cluster:0201, size:08, attrId:001E, encoding:30, command:0A, value:04, clusterInt:513, attrInt:30]

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:12.487 AM[info](http://192.168.1.170/logs#)Upstairs thermostatMode is heat

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:12.481 AM[debug](http://192.168.1.170/logs#)getThermostatModeResult:4

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:12.476 AM[debug](http://192.168.1.170/logs#)descMap: [raw:BF91010201081C003004, dni:BF91, endpoint:01, cluster:0201, size:08, attrId:001C, encoding:30, command:0A, value:04, clusterInt:513, attrInt:28]

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:08.241 AM[warn](http://192.168.1.170/logs#)description logging is: true

[dev:879](http://192.168.1.170/logs#)2022-12-01 11:19:08.229 AM[warn](http://192.168.1.170/logs#)debug logging is: true

Then the driver isnt broke....

Ok, I’ll tweak my rules and see if that’s the issue.

Can you see if you can replicate the issue I mentioned above.

Start with Thermostat Mode = Off Fan Mode On

Turn Fan Mode from On to Auto and see if that also changes Themostat Mode from Off to Auto.

I'm seeing this from the driver page itself along with the dashboard mentioned above.

Please go through that process using the driver and post the live debug logs, be sure any apps that use the thermostat are paused...

Both Thermostat Mode Off and Fan Auto (off)

Then Turning Fan to On

Switch Fan back to Auto (off) this happens

1 Like

interesting, this isn't a driver issue, the device itself is doing this.
you can see the 4th line from last in the log where the thermostat is returning a value of 01 which is auto...
This is a device firmware bug.

That seems logical as it did the same thing when trying to use the Generic Zigbee Thermostat driver as well.

Thanks for the info, you would happen to know if there is a zen thermostat firmware update that can be pushed through the zigbee firware updater?

we don't have one, we'll upload it if they provide one to us.

2 Likes

Thread from ST forum - there was an update in 2019, at least, doesn't sound like it would address the issues discussed here.

Instructions to update (assuming you have access to a ST hub). I had these in some notes I'd saved, no idea if below works or not...

Aha! Discovered the instructions were from @dJOS - so we know he's already applied the update. His post here:

  1. Take your Zen off the wall, wake up the screen if it isnt already on.
  2. Press the network button 10 times to remove it from your HE Zigbee network - this is only done on the device, your HE device won't be removed unless you run that process on the HE (so dont).
  3. On your SmartThings app, select add a device and pick the Zen Thermostat
  4. Press the network button 5 times to add it to your SmartThings
  5. follow the instruction HERE to check your Device FW version
    a. Take your Zen off the mount
    b. Select "prefs"
    c. Scroll right to "info" and the first item when you scroll down is your current FW version.
  6. pull the batteries out of your Zen for a minute
  7. Wait for up to 10 mins and it should auto-update - you'll know it's doing this as a symbol will start randomly flashing around the screen. It's done when the display goes back to showing "prefs".
  8. make sure the Zen is responding in the ST app then power down your ST HUB
  9. Press the network button 10 times to remove it from SmartThings
  10. On your Hubitat Hub, go to discover Zigbee new device and start the discovery process
  11. Press the network button 5 times to re-add it to your Hubitat - you'll see it say something along the lines of "found an existing device". This means you succeeded!
3 Likes

Thanks for that, I don't have access to smartthings.

Download the Hubitat app