Recently purchased this thermostat for use within openhab (only as a room stat and not with the Drayton wiser system/binding).
I can see only see the below channels, but zigbee2mqtt says I should expect many more.
Is there way to manually add them or is that not possible.
At the moment my options seem to be send it back or to change to zigbee2mqtt.
I’m relatively new to zigbee but now have every room light switched via zigbee switch and also boiler. All devices so far have worked flawlessly on zigbee binding so kind of reluctant to change.
Does anyone have any resources I could use to read up on zigbee communication to try and understand how zigbee2mqtt and domoticz have implemented support and porrt this into zigbee binding
What channels are you missing? From what I can tell, the only significant channel that’s missing is the “occupied heating setpoint” - this should be supported by the binding so should show up. Can you use the zigbee fingerprint command from the command line to get a list of what the device actually supports - maybe it does something a little different for the heating setpoint.
The only other channel I see is “keypad lockout” which I don’t think is currently supported by the binding.
I tried a few things but I tihnk the time investment i’d need to learn ins and outs of zigbee aren’t worth it so I’ve given up with it. Sending the thermostat back.
Don’t suppose you know of any battery powered thermostats that are fully supported by zigbee binding?
I did consider running zigbee2mqtt at the same time as zigbee binding with another usb zigbee donlge but i only have one of the same ones and they seem to conflict.
I could setup another VM but feels like a lot of work for one device.
Seems like Zigbee binding might not be the option for me, I just need to invest the time to migrate everything over.
If you still want to get more involved with the Zigbee protocol, a good starting point for the returned device would be:
But there are also Zigbee devices that are supported by the openHAB Zigbee Binding but not by Zigbee2MQTT, e.g.
The device looks like a Neo NAS-PD07 control via MQTT | Zigbee2MQTT, but it is a pure motion sensor (no temperature/humidity sensor). Zigbee2MQTT tries to configure the non-existent sensors and fails.
Therefore I use the Zigbee Binding and Zigbee2MQTT in parallel - and openHAB is the Z2Z bridge in between.
The binding doc lists the channels that are supported.
Adding this probably is quite easy though so I could probably do that if needed.
Well, I have about 5 different ones at home that were/are used by a company I supported. They are all from the US though and I’m not sure where you are located (I’m also currently flying back from the UK to NZ so am not at home so can’t check the models).
The binding should support all standard thermostats. To be honest I’m quite surprised that the Schneider one isn’t using the standard clusters. I do some work with them and while they do have non-standard functionality on devices, most functions are using the standard feature set. I’ve currently only been supporting their lights and sensors though and haven’t come across the thermostat.
@Matt_Jayne I wonder if you can post the output of the zigbee fingerprint command for this device before sending it back. I’ve not been able to find anything that shows that this isn’t following the standard, so it would be good to see what this returns.
Hmm, so it looks like this device is not a thernostat as such - well - it’s a thermostat but it requires another device to actually do the controlling. From the fingerprint, we can see that the Thermostat cluster is an “output” cluster - this means that it’s designed to control other devices (eg a HVAC system, or radiator valve). This is why the binding doesn’t provide a channel as the binding is designed to also configure HVAC systems or radiator valves.
Thanks for taking a look Chris (and Happy Christmas).
I believe you’re right it is meant for use within a wider system Drayton Wiser system, however I was hoping it would work as a solo zigbee thermostat/temp setting device. As I already have smart switch functionality in my heating system to manage the control side of things.
I went with this thermostat after suggestion from Joris elsewhere on the forum however I foolishly didnt think to confirm if they were using binding. I’ve since confirmed with them that they’re using zigbee2mqtt not the binding, so might be a case that Zigbee2mqtt is implementing some additional work around to spoof the missing elements of the system you mentioned.
(Wireless Zigbee (or alternative) thermostat Battery - #5 by joriskofman).
So can you confirm how you want to use this? Do you want to be able to use it to send a command to OH to set the temperature, and then use that to trigger a rule to command other devices to actually control the temperature?
Or, are you wanting to use it to directly set the temperature on the other control devices (eg a radiator thermostat)?
If it’s the first one, that would require an update to the binding - probably quite a simple one. If it’s the second one, then that can be done now (through the console).
I was looking for a battery powered device that allowed some family members (who are very against using an app) to set heating set point temperature. This was my compromise where they’d be able to set the temp on the Wiser/Schneider device and that would be linked to the set temp item I have within Openhab.
I’m not 100% sure that it will work, so if it doesn’t I’ll need to see some debug logs to see what the device sends. I’ve been unable to test this since I don’t currently have any thermostats, and certainly don’t have any that provide the client side like this device.
You will need to reinitialise the device - there is a config option to do this in the thing configuration. This should configure the device to send the reports…
Now, it seems that the master branch of OH has now been configured for OH4 which requires a newer version of Java, and it doesn’t look like older builds to support OH3.4 are now being built by CI. I’ll try and check what’s happening with that…