Zigbee reporting, multiple endpoint same cluster

Developer Programs Writing Device Types
1

Hi,

Im working on a DTH for an in wall switch with two inputs and two outputs. Trying to figure out how to set up the reporting for on/off: 0x0006 cluster. The outputs can be found on endpoint 1 and 2.

I have setup the reporting like this:

configCmds += zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 300, null, [destEndpoint: 0x01]) +     			  
			  zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 300, null, [destEndpoint: 0x02])

I can see in the logs that the reporting have been setup successfully:

903c7fa1-fff6-412f-9826-c97d7faa7636 14:58:39: debug On/Off reporting successful
903c7fa1-fff6-412f-9826-c97d7faa7636 14:58:39: trace parse: map is [raw:0104 0006 01 01 0140 00 8DDB 00 00 0000 07 01 00, profileId:0104, clusterId:0006, sourceEndpoint:01, destinationEndpoint:01, options:0140, messageType:00, dni:8DDB, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00], clusterInt:6, commandInt:7]

903c7fa1-fff6-412f-9826-c97d7faa7636 14:58:43: debug On/Off reporting successful
903c7fa1-fff6-412f-9826-c97d7faa7636 14:58:43: trace parse: map is [raw:0104 0006 02 01 0140 00 8DDB 00 00 0000 07 01 00, profileId:0104, clusterId:0006, sourceEndpoint:02, destinationEndpoint:01, options:0140, messageType:00, dni:8DDB, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00], clusterInt:6, commandInt:7]

So, now to the problem, the reports that are sent doesn’t seem to carry the endpoint or the endpoint has been stripped somewhere:

These are the incomming reports in the log:

903c7fa1-fff6-412f-9826-c97d7faa7636 15:03:50: trace parse: event is [name:switch, value:off]
903c7fa1-fff6-412f-9826-c97d7faa7636 15:03:50: trace parse: description is on/off: 0 //No endpoint here
903c7fa1-fff6-412f-9826-c97d7faa7636 15:03:47: trace parse: event is [name:switch, value:off]
903c7fa1-fff6-412f-9826-c97d7faa7636 15:03:47: trace parse: description is on/off: 0 //No endpoint here

The reports doesn’t include the endpoint so I don’t know which childDevice to update…

Does anybody know how to setup this so that I can get reporting for both endpoints with the same cluster?, so that I can tell the reports a part…a bit unusable otherwise. (Well could be used to trigger reads of both endpoints but it doesn’t seem right)

//Tomas

2

Sigh. Multi endpoint zigbee devices are unfortunately something that we don’t support very well currently. We continue to work toward exposing a more sane and complete zigbee interface for DTHs to use, but right now it is a little limited. The only way you can get this information currently is by issuing a read attribute command (attribute reports go through an interpretation layer at one point and we lose some information). So, you can support this by manually sending read attribute commands on the on/off cluster on/off attribute when you receive an “on/off” description. Those read attributes should then come back as “catchall” descriptions that include the endpoint information.

Obviously this will add a lot of latency to the update and will add load to your zigbee network with additional messages. However, I think this will work, and it is the only way to get the information you are looking for at the moment. So unfortunately, while I agree with your feeling that having to manually read the attributes isn’t “right”, it is currently the only way to do this.

1 Like
3

Hi Zach,

Thank you for a quick answer, did suspect that a little. Saw some discussions on this topic from 2015 but no concrete answers. Did already implement exactly what you are suggesting and it works although with a little more latency. I guess with a little device health/reporting optimization the overall penalty will be under control.

Do you see multichannel improvements for the zigbee interface in a forseeable future?

if (description?.startsWith("on/off")) {
	//Trigger read of cluster 6 ep 1/2
    def cmds = zigbee.readAttribute(0x0006, 0x0000, [destEndpoint: 0x01]) + zigbee.readAttribute(0x0006, 0x0000, [destEndpoint: 0x02])		
	return cmds.collect { new physicalgraph.device.HubAction(it) }        
}

and

if (map.clusterInt == 0x0006 && map.attrInt == 0x00 && map.commandInt == 0x01) {
		log.debug "parse: switch read from $map.sourceEndpoint"
        if(map.sourceEndpoint == "01") {            	
        	return createEvent(name: "switch", value: map.value == "01" ? "on" : "off")
        } else if(map.sourceEndpoint == "02") {            	
        	return childDevices[0].sendEvent(name: "switch", value: map.value == "01" ? "on" : "off")
        }            
    }
4

That code looks good. What work gets prioritized and when things get scheduled is above my pay grade. But I can tell you it’s something we would like to do, along with a variety of other quality of life improvements like proper cluster and attribute constants to avoid all the magic numbers in everyone’s code. It can be hard to change our reporting interface as we support custom DTHs any change could potentially break people’s homes.

5

Hi Zack, would it be possible to make a non breaking change(explicit setting…) for this? Can understand that a lot of code will break if the reporting attribute pre-parsing is changed for all.

A non breaking change could be(Im just wildly guessing here, maybe the structure is in such a way that these parts doesn’t know of eachother):

def configCmds = zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 600, null, [destEndpoint: 0x01, rawReport: true]) +
				 zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 600, null, [destEndpoint: 0x02, rawReport: true]) +
                 zigbee.configureReporting(0x0702, 0x0400, 0x2A, 1, 600, 0x01, [destEndpoint: 0x05])
6

We have considered a lot of potential solutions to the backward compatibility problem, but getting into a design discussion about potential SmartThings implementations is not something I can really do on the forums. I can say we know this is an obstacle to properly supporting many zigbee devices, and we would like to better support it in the future. For now you will have to continue to use this workaround.

7

Quite a long time since @Zach_Varberg said

we know this is an obstacle to properly supporting many zigbee devices, and we would like to better support it in the future

I understand that there may be other priorities, but in that case there are multiple ways to support delevopers in the interim: it is quite easy to provide a non-intrusive, backward compatible way for DHs to get access to the original, not-preparsed message, either by:

  1. API call for the DH to indicate it does not want the message to be preparsed:

def configure() { // or wherever needed
requestUnparsed(true)
}

// Then wherever in the backend check if this was called and just don’t pre-parse

  1. Attribute:

attribute doNotPreparse, “number”

// Then wherever in the backend check if the DH has the attribute set to whatever true value

  1. Save the last unparsed message:

// Wherever in the backend, before preparsing the message, save it in an accesible attribute, or somewhere available from an API call (may be tricky if there is concurrency in the DH calls)
def parse() {
// …
def unparsed = getLastUnparsedMessage()
// …
}

And surely many other clean-and-fast options, so agreeing that the forum may not the place for you to enter into an API change discussion, it should not have been so difficult so far to provide a solution.

While “real” zigbee support is provided, i.e. endpoint support (having today hundreds-to-thousands IoT things currently on the arena), or parsing of attributes not working when the device reports several attributes in a single message, and probably others needed looking at the forums, at least we should have a clean way to access the device unparsed event from the DH if needed to correctly workaround these while your development cycle moves forward

8

Hi,
I’m trying to do the same by sending a readattribute so I can update on/off correctly on multiple buttons switch.

So Im trying to do read attribute and it shows on device the it has done the read attribute but nothing happens, can you help me or may be send me an example if you ever has managed to achieve this?

9

Hi Marwan, I did this with child devices. You could have a look at: S2 Switch.