Support of Server Cluster

Developer Programs Writing Device Types
1

I currently have a couple of Zigbee devices I would like to support that have either a local UI for setting temperature. Some of these have their own thermostat actuator, some need to be remote bound. These are sleepy devices, so they are not constantly writeable/

As these devices are in principle and implementation Thermostat Cluster clients, what I would like to do is be able to respond to read attribute requests from these devices when they are bound to the Hub, in order that I can allow them to read the latest intended state of the thermostat from the hub.

I can process the read attribute request incoming, however the implementation of the zigbee controller chip seems to always respond with “not supported” (0x86), and not provide a means for my application to send the response back.

Is there a way that I can register support of a server cluster and/or attributes in a DTH so that my client devices can correctly read values?

2

Hi! Can you share with me more details about this, please?
For example:

  • If you’re using a SmartApp or DTH, share its source code
  • Screen captures of the error logs and how the devices appear in the mobile app so far.
3

Hi,

The product (known shorthand as an RTS) I am trying to support is this: https://www.se.com/fr/fr/product/EER51000/wiser---thermostat/

It is both a temperature sensor (so has the Temperature Measurement Server Cluster) and an interface for thermostat actuators such as this: https://download.schneider-electric.com/files?p_enDocType=User+guide&p_File_Name=Wiser-HACT_S1B23264-06_EER5000x_10-2016_DA-EN-FR-IT-SV.pdf&p_Doc_Ref=Wiser-HACT_S1B23264-06_EER5000x_10-2016_DA-EN-FR-IT-SV

This interface presents as a Thermost Client cluster, as it should read the current setpoint from the actuator before allowing the user to change it, and then write or command it to the new if it is changed…

My code is here, and I have managed to bind the RTS to the HACT with a simple smartapp, and this works ok.

What I would like to extend it to do is also be able to read the setpoint FROM the hub, by emulating thermostat cluster server commands (in particular read and write attribute responses).

Currently in testing what I see is while I can bind the RTS’s thermostat client to the hub via a ZDO Bind command, and I can receive the actual read attribute requests, I am unable to respond to them, and the Hub always responds to the read requests with error code 0x86 (unsupported attribute).

It appears as though the hub just automatically defaults to unsupported on any attribute read/write requests it recieves on a server cluster… is there some way to register support for an attribute in the hub itself, so I can handle the attribute requests?

The reason I would like this is that with this mechanism I can support control of either virtual group thermostats, or sleepy thermostat actuators such as battery operated radiator thermostats. This would actually make the capabilities of the smarthub more powerful than the Wiser gateway it would replace. :slight_smile:

Thanks in advance for your assistance.