Zigbee thermostat mode reporting

Can someone please confirm how I should get a driver to ask for reports on the thermostatMode - off, heat, cool, auto etc?

Numerous drivers do something like this in their configure:
"zcl global send-me-a-report 0x201 0x001C 0x30 5 300 {}", "delay 500", // report system mode

or, translating to the function method:
cmds += zigbee.configureReporting(0x0201, 0x001C, 0x30, 5, 300, null, [:], 500)

I've tried both in a driver for the Zen that I'm modifying/learning with, and I never get any reports at all for that attribute. Everything else reports in OK - operating mode, temperature, set points etc.

If I use the Hubitat driver and turn on debug in preferences I see it parsing the exact same report:

dev:72 2019-08-10 03:01:15.658 pm info Zen Thermostat thermostatMode is heat
dev:72 2019-08-10 03:01:15.652 pm debug getThermostatModeResult:4
dev:72 2019-08-10 03:01:15.648 pm debug descMap: [raw:3F47010201081C003004, dni:3F47, endpoint:01, cluster:0201, size:08, attrId:001C, encoding:30, command:0A, value:04, clusterInt:513, attrInt:28]

So I know that the thermostat itself is working. Can anyone suggest what I'm doing wrong, or what magic the Hubitat driver might be doing? Perhaps @mike.maxwell?

The first three parameters are correct, the fourth minimum reporting interval should be 0 in this case, the fifth, maximum reporting interval is set to 300 seconds, so unless you actually want to see this attribute report every 5 minutes whether it changes or not i would set it to 0xFFFE.

1 Like

I've tried that, but I'm still not getting a report on the mode. Here's my full code for the configure() function:

def configure() {
log.debug "configure() - binding & attribute report"
sendEvent(name: "checkInterval", value: 60 * 12, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID])
// send configure commad to the thermostat
def cmds = [
        //Set long poll interval to 2 qs
        "raw 0x0020 {11 00 02 02 00 00 00}", 
        "send 0x${device.deviceNetworkId} 1 1",
        //Thermostat - Cluster 201
        "zdo bind 0x${device.deviceNetworkId} 1 1 0x201 {${device.zigbeeId}} {}", "delay 500",
        "zcl global send-me-a-report 0x201 0 0x29 5 300 {3200}", "delay 500",      // report temperature changes over 0.5°C (0x3200 in little endian)
        "send 0x${device.deviceNetworkId} 1 1", "delay 500",
        "zcl global send-me-a-report 0x201 0x0011 0x29 5 300 {3200}", "delay 500", // report cooling setpoint delta: 0.5°C
        "send 0x${device.deviceNetworkId} 1 1", "delay 500",
        "zcl global send-me-a-report 0x201 0x0012 0x29 5 300 {3200}", "delay 500", // report heating setpoint delta: 0.5°C
        "send 0x${device.deviceNetworkId} 1 1", "delay 500",
        //"zcl global send-me-a-report 0x201 0x001C 0x30 5 300 {}", "delay 500",     // report system mode
        //"send 0x${device.deviceNetworkId} 1 1", "delay 500",
        "zcl global send-me-a-report 0x201 0x0029 0x19 5 300 {}", "delay 500",     // report running state
        "send 0x${device.deviceNetworkId} 1 1", "delay 500",
        //Fan Control - Cluster 202
        "zdo bind 0x${device.deviceNetworkId} 1 1 0x202 {${device.zigbeeId}} {}", "delay 500",
        "zcl global send-me-a-report 0x202 0 0x30 5 300 {}", "delay 500",          // report fan mode
        "send 0x${device.deviceNetworkId} 1 1",
    ]
// System Mode
//cmds += zigbee.configureReporting(THERMOSTAT_CLUSTER, ATTRIBUTE_SYSTEM_MODE, TypeENUM8, 5, 300)
cmds += zigbee.configureReporting(0x0201, 0x001C, 0x30, 0, 0xFFFE, null, [:], 500)
//Power Control - Cluster 0001 (report battery status)
cmds += zigbee.batteryConfig()
//sendZigbeeCmds(cmds)
// Delay polling device attribute until the config is done
runIn(15, "pollDevice", [overwrite: true])
	
return cmds
}

As you may tell, this is based on the ST driver that I've converted and made some of my own changes in.

There is no need to poll this device, other than that not sure what to tell you, this is why I capture frames when writing drivers...

If you are trying to learn about zigbee drivers, a thermost is one of the more difficult devices to start off with, if not, what is lacking in the stock driver that's sending you down this path?

Yes, I'm beginning to realise that. I don't doubt my programming ability, but not having tools like a sniffer is making me wonder if this is the right thing to do :slight_smile:

Initial reasons to convert/tweak a driver for the Zen:

  • My thermostat is configured for heat only (config 10A). I wanted to add support for supportedThermostatModes which my Zen does report correctly, but then I noticed that the thermostat tile in the dashboard doesn't respect that anyway
  • my OCD doesn't like the title "pending heat" for mode 4, they're all just "heat" in the ST driver, and mode 4 is all mine ever does
  • Minor OCD of seeing temperatures in C rounded to 1 dp, whereas the physical Zen only ever shows 18, 18.5, 19, 19.5 etc on its display

But most importantly, the built-in driver has issues setting set points correctly, which is something I fought with in ST for a couple of years :frowning:

I only noticed it a couple of times but it was enough to try the ST code, which had been running for a couple of weeks without missing one single change driven by Thermostat Scheduler.

I just switched back to the Hubitat driver - selected the driver, Save Device, Configure, pulled Zen batteries, hit Configure again. In the Edit Device page I entered 18.5 into the field for Set Heating Setpoint and clicked the button. The previous heating value was 20.5. This is what was logged:

dev:72 2019-08-13 08:51:28.288 am info Zen Thermostat temperature is 19.8°C
dev:72 2019-08-13 08:51:28.281 am debug getTemperatureResult:19.8
dev:72 2019-08-13 08:51:28.276 am debug descMap: [raw:3F470102010A000029BC07, dni:3F47, endpoint:01, cluster:0201, size:0A, attrId:0000, encoding:29, command:0A, value:07BC, clusterInt:513, attrInt:0]
dev:72 2019-08-13 08:51:08.382 am info Zen Thermostat coolingSetpoint was set to 22.5°C
dev:72 2019-08-13 08:51:08.332 am debug getCoolingSetpointResult:21
dev:72 2019-08-13 08:51:08.314 am debug descMap: [raw:3F470102010A1100293408, dni:3F47, endpoint:01, cluster:0201, size:0A, attrId:0011, encoding:29, command:0A, value:0834, clusterInt:513, attrInt:17]
dev:72 2019-08-13 08:51:08.078 am info Zen Thermostat thermostatSetpoint was set to 20.5°C
dev:72 2019-08-13 08:51:08.073 am info Zen Thermostat heatingSetpoint was set to 20.5°C
dev:72 2019-08-13 08:51:08.018 am info Zen Thermostat thermostatSetpoint was set to 18.5°C
dev:72 2019-08-13 08:51:08.013 am info Zen Thermostat heatingSetpoint was set to 18.5°C
dev:72 2019-08-13 08:51:07.996 am debug getHeatingSetpointResult:18.5
dev:72 2019-08-13 08:51:07.990 am debug descMap: [raw:3F470102010C1200293A07, dni:3F47, endpoint:01, cluster:0201, size:0C, attrId:0012, encoding:29, command:01, value:073A, clusterInt:513, attrInt:18]
dev:72 2019-08-13 08:51:07.972 am debug getHeatingSetpointResult:18.5
dev:72 2019-08-13 08:51:07.965 am debug descMap: [raw:3F470102010A1200293A07, dni:3F47, endpoint:01, cluster:0201, size:0A, attrId:0012, encoding:29, command:0A, value:073A, clusterInt:513, attrInt:18]
dev:72 2019-08-13 08:51:06.938 am trace setHeatingSetpoint(18.5)
dev:72 2019-08-13 08:50:33.329 am debug refresh
dev:72 2019-08-13 08:50:33.323 am debug configure

In other words, the value was set and then completely overridden again - classic Zen (for me)... and for whatever reason, the way the ST driver does it with delays etc. this problem happens very, very rarely.

Do you think this is because my device only uses Heat and does not use Cool?

However, as I typed this the 9am Thermostat Scheduler kicked in and successfully set heating to 15C:

dev:72 2019-08-13 09:00:23.124 am info Zen Thermostat thermostatSetpoint was set to 15.0°C
dev:72 2019-08-13 09:00:23.111 am info Zen Thermostat heatingSetpoint was set to 15.0°C
dev:72 2019-08-13 09:00:23.070 am info Zen Thermostat coolingSetpoint was set to 22.5°C
dev:72 2019-08-13 09:00:23.055 am info Zen Thermostat thermostatSetpoint was set to 15.0°C
dev:72 2019-08-13 09:00:23.050 am info Zen Thermostat heatingSetpoint was set to 15.0°C

But again, why the double reporting? - I think this is part of the issue, perhaps setting the cooling point sends back a status with the heating value, but the heating setpoint hasn't had a chance to be applied by the Zen? Something like that, anyway.

There have been reports of issues with setpoints on this thermostat and thermostat scheduler, I've been working with another customer privately testing some Zen driver changes.
Double reporting is just text logging, double events are an issue, and unless you see them in device events aren't going to cause any issues, the text logging is meant for convienence, I normally turn it off after automations are complete.
If you hack the driver into a heating only device and do not maintain cooling set point and thermostat set point, you won't be able to use it with Google home.