ZigBee ZCL default response 0x0b

[martyn]

I've been working on my own driver for various Hue devices in particular the motion sensors - nothing against the official driver but mine allows setting of sensitivity, led and various reporting intervals.

I've come up against an issue which also seems to be present in the official driver and that is that the devices frequently leave and rejoin the network.

I think that I've tracked this down to some similar behavior that was seen on another platform (deconz) where it was found that the devices were expecting a ZCL default response (0x0b) to be sent in response to the attribute report message (0x0a). If it didn't get this then the device resent the report as a broadcast ... and then eventually the device leaves and rejoins, which may or may not result in a new 16-bit address.

In the HE raw ZigBee logs I see this for all my Hue motions over time:

P62019-02-27 11:27:43.933 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:255 , groupId:0, lastHopLqi:255, lastHopRssi:-58

P62019-02-27 11:27:42.425 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-58

P62019-02-27 11:27:33.973 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:255 , groupId:0, lastHopLqi:255, lastHopRssi:-58

P62019-02-27 11:27:32.362 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-58

I can see this happening with my ZigBee sniffer i.e. after several iterations of the unicast report / broadcast report the device will leave and rejoin, but I'm still learning ZigBee so I may be way off in my understanding of this being the same issue as was seen on deconz.

Rather than hassle HE staff to diagnose further, my rather simplistic idea is to send a default response success message to these incoming reports and see if the leave / rejoin problem goes away.

So my question is how to do that? Is there a way to send a raw ZCL default response reply to an incoming message?

Maybe @mike.maxwell or @chuck.schwer can point me in the right direction?

[chuck.schwer]

You'll want to build a raw zigbee message to send:

he raw [16 bit address] [source endpoint] [destination endpoint] [cluster id] {[payload]} {[profile id]}

can you post the capture of the attribute report message? I can probably give you a couple more pointers on what the message should look like.

[martyn]

Thanks Chuck,

My ZigBee sniffing abilities are a little rough at the moment, but from what I can see the Hue Motion sends an 0x0a report and I am positing that because HE doesn't (?) send a ZCL default response back, it thinks the message hasn't got through and therefore sends the same 0x0a report as a broadcast.

This then eventually after some time leads to the device doing a leave and rejoin.

Of course I may be way off in this, as it's based on the deconz thread I linked to before and some chatter on the Hue developer forum, but it does seem to fit with the behavior I see on my Hue motions.

As mentioned my quick fix to test if it is indeed the case would be to reply to the unicast 0x0a with a ZCL default response, see if the subsequent broadcast 0x0a stops and see if the leave and rejoin behavior goes away.

[chuck.schwer]

Is the message making it to the driver? can you post what the message looks like coming into parse?

[martyn]

Yes both the unicast and the broadcast end up in parse.

P62019-02-27 16:11:37.154 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:255 , groupId:0, lastHopLqi:254, lastHopRssi:-53

P62019-02-27 16:11:35.538 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:254, lastHopRssi:-52

unicast:

dev:1172019-02-27 16:11:35.473 infoP6 eventMap name: motion value: active

dev:1172019-02-27 16:11:35.472 debugP6 Got raw value 01

dev:1172019-02-27 16:11:35.470 debugP6 Got reporting attribute

dev:1172019-02-27 16:11:35.469 debugP6 Got occupancy sensing (1030) cluster

dev:1172019-02-27 16:11:35.468 debugP6 Got Read Attributes Response or Report Attributes

dev:1172019-02-27 16:11:35.466 debugP6 descMap: [raw:E2F50204060800001801, dni:E2F5, endpoint:02, cluster:0406, size:08, attrId:0000, encoding:18, command:0A, value:01, clusterInt:1030, attrInt:0]

dev:117#dev117)2019-02-27 16:11:35.465 debugP6 description is read attr - raw: E2F50204060800001801, dni: E2F5, endpoint: 02, cluster: 0406, size: 08, attrId: 0000, encoding: 18, command: 0A, value: 01

dev:1172019-02-27 16:11:35.462 debugP6 Parse() Called!

a few seconds later the broadcast (which I suppress from sending an event):

dev:1172019-02-27 16:11:37.134 debugP6 duplicate event suppressed eventMap name: motion value: active lastSend: 1663

dev:1172019-02-27 16:11:37.130 debugP6 Got raw value 01

dev:1172019-02-27 16:11:37.127 debugP6 Got reporting attribute

dev:1172019-02-27 16:11:37.125 debugP6 Got occupancy sensing (1030) cluster

dev:1172019-02-27 16:11:37.123 debugP6 Got Read Attributes Response or Report Attributes

dev:1172019-02-27 16:11:37.120 debugP6 descMap: [raw:E2F50204060800001801, dni:E2F5, endpoint:02, cluster:0406, size:08, attrId:0000, encoding:18, command:0A, value:01, clusterInt:1030, attrInt:0]

dev:1172019-02-27 16:11:37.116 debugP6 description is read attr - raw: E2F50204060800001801, dni: E2F5, endpoint: 02, cluster: 0406, size: 08, attrId: 0000, encoding: 18, command: 0A, value: 01

dev:1172019-02-27 16:11:37.113 debugP6 Parse() Called!

[chuck.schwer]

ok cool, I would try sending a raw message like this when you get that message in parse:

return "he raw ${device.deviceNetworkId} 1 2 0x406 {0B 00}"

Then check your sniffer to see if it is going out correctly. This mostly off the top of my head so you might have to make some changes to get it going out right.

[martyn]

I had a play around with that but couldn't see anything in the sniffer to indicate it was being sent

Is there a way in HE to see raw outbound ZigBee logs to see if the command is valid and actually reaches the radio?

[chuck.schwer]

@martyn

Is there a way in HE to see raw outbound ZigBee logs to see if the command is valid and actually reaches the radio?

No, but like I said I did that by memory,, I'll try it out and see if I can see any errors.

[martyn]

Thanks Chuck,

Just to prove that I think I am on the right track with this (and possibly for other Hue endpoint devices), I've added a Hue Motion to a deconz install.

Here you can see that deconz replies to the report 0x0a message with a default response 0x0b message each time. You then don't see any subsequent broadcasts from the device AND the device doesn't go through the leave / rejoin dance.

I've shown captures for an occupancy report but it's the same for illuminence, temperature, etc.

[chuck.schwer]

OK, yes the frame was wrong, however it was still being sent to the radio with my test. so there is something else going wrong for yours.

Here is my updated command that is captured correctly

return "he raw ${device.deviceNetworkId} 1 2 0x406 {08 01 0B 0A 00}"

The problem being that the default response message is supposed to have the same sequence number as the incoming message. So this is going to require some platform changes to work.

[martyn]

Ah, our messages crossed

I actually wonder now (based on the deconz captures above) that this may be a platform level thing anyway, as opposed to being something that should be returned from parse() in the driver?

Do you think my hypothesis is correct? I know that @mike.maxwell has played with Hue devices, just in case he has any comments.

[chuck.schwer]

@martyn

that this may be a platform level thing anyway,

yes it may be. we will look into it.

[martyn]

Great, thanks for sticking with it!

Happy to test anything or provide any more information if needed.

[mike.maxwell]

platform 2.0.8 should fix this issue, can you verify?

[martyn]

I've not yet upgraded to 2.0.8 but will hopefully get a chance to in the next week or so.

That said, based on the other thread it does sound like the issue is resolved.

If I momentarily have your attention Mike, would you mind taking a look at my query about Hue here if you get a second?

[Rxich]

Hi Martyn, did you still see this issue? I have 5 Hue motion sensors and they all do this, change 16 bit address constantly