Zigbee Binding fails to initialize dimmer

flashbac · November 21, 2019, 11:49pm

Hi everyone,
I have a custom Zigbee dimmer device that registers just fine with OH2 M4, the problem is that I get the error below when I add the device. Switch cluster works fine, but for whatever reason the Level Control cluster fails to initialize. Logs attached.

Thanks in advance.

2019-11-21 17:37:40.392 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0013A20041A406E7: No handler found for zigbee:device:9caa92e7:0013a20041a406e7:0013A20041A406E7_3_dimmer

2019-11-21 18:13:20.389 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 0013A20041A406E7: Channel zigbee:device:9caa92e7:0013a20041a406e7:0013A20041A406E7_3_dimmer failed to initialise device

2019-11-21 18:13:20.658 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 0013A20041A406E7: Channel zigbee:device:9caa92e7:0013a20041a406e7:0013A20041A406E7_4_dimmer failed to initialise device

2019-11-21 18:13:20.840 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 0013A20041A406E7: Channel zigbee:device:9caa92e7:0013a20041a406e7:0013A20041A406E7_3_dimmer failed to initialise converter

2019-11-21 18:13:20.851 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 0013A20041A406E7: Channel zigbee:device:9caa92e7:0013a20041a406e7:0013A20041A406E7_4_dimmer failed to initialise converter

Andrew_Rowe · November 22, 2019, 3:37am

we need your version and platform to even begin to help you

chris · November 22, 2019, 7:47am

It’s caused by the device not supporting reporting -:

2019-11-21 15:07:08.956 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ConfigureReportingCommand [Level Control: 0/0 -> 61048/3, cluster=0008, TID=24, records=[AttributeReportingConfigurationRecord: [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, direction=0, minimumReportingInterval=1, maximumReportingInterval=900, reportableChange=1]]]
2019-11-21 15:07:09.130 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: DefaultResponse [Level Control: 61048/3 -> 0/1, cluster=0008, TID=24, commandIdentifier=6, statusCode=UNSUP_GENERAL_COMMAND]

The device should still work ok, but as it doesn’t support reporting, it won’t update when you change the state.

flashbac · November 22, 2019, 1:26pm

Thanks for the quick response. I’ve never had reporting implemented in my code yet this used to work in previous versions of OH. Is this a new requirement from the previous version or milestones?

So the device is sorta working. the on/off EP works fine, OH sends the command to the device whenever i press the button in the OH Control page, yet OH does not send the command for the level control EP when i move the slider.

The other thing is that this device will be asleep most of the time until a button/slider is pressed, is OH expecting the device to wake up every 900secs to send a report? What are the expectations of the Coordinator and the End Device in this scenario?

Thanks again!

chris · November 22, 2019, 2:48pm

No - it’s the same. The logging might have changed though, but clearly without reporting, state updates will not work.

If the device sleeps, then OH will not be able to send any commands to it.

Well, normally in ZigBee a sleepy device should wake up at least once every 7.8 seconds. On top of this, OH will expect to receive data from the polling - I’m not sure what the duration of this is though as it normally would use reporting on most devices (these days, it’s mandatory for ZB compliance).

flashbac · November 22, 2019, 6:31pm

Ok, my device (XBee3) wakes up every 3 secs to check for any commands waiting in the Coordinator’s queue, without waking up the rest of the components. If there is a command waiting, it wakes everything up and processes the command.

But the question still remains, if my device does not support reporting, why does OH works with the on/off EP but not with the level control EP?

chris · November 22, 2019, 6:33pm

Ok, but that’s not related to reporting configuration - that’s just the standard MAC polling… That means that at least it should respond to polls in a reasonable timeframe at least.

flashbac · November 22, 2019, 8:50pm

Ok cool, so at least I’m doing that part right

So why does OH works with the on/off EP without reporting but not with the level control EP?

chris · November 22, 2019, 8:51pm

I don’t know - it should not matter. I guess if these are different endpoints, then it will provide separate channels, but they should work similarly.

flashbac · November 22, 2019, 9:27pm

Could this be a bug? It should work.

Also I just got done implementing reporting, at least device is responding with a ConfigureReportingResponse. But OH still does not initialize the dimmer channels. Log attached.
openhab-snip.log (278.8 KB) This is on Openhabian OH2.5.M4 running on Raspberry Pi 3 Model B Rev 1.2

chris · November 22, 2019, 9:46pm

What endpoints/clusters does this device support?

flashbac · November 22, 2019, 9:49pm

It supports a bunch, but what I’m currently testing is:
EP1 - Basic cluster (0x0000)
EP2 - On/Off Cluster (0x0006)
EP3 - Level Control Cluster (0x0008)
EP4 - Level Control Cluster (0x0008)

chris · November 22, 2019, 9:49pm

And are these clients or servers?

chris · November 22, 2019, 9:50pm

Or can you provide the simpleDescriptor?

flashbac · November 22, 2019, 9:53pm

Right now my code only supports Input Clusters. From the log:

	Line 292: 2019-11-22 16:13:09.217 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: SimpleDescriptorResponse [47036/0 -> 0/0, cluster=8004, TID=--, status=SUCCESS, nwkAddrOfInterest=47036, length=10, simpleDescriptor=SimpleDescriptor [endpoint=1, profileId=0104, deviceId=0, deviceVersion=0, inputClusterList=[0], outputClusterList=[]]]
	Line 315: 2019-11-22 16:13:09.474 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: SimpleDescriptorResponse [47036/0 -> 0/0, cluster=8004, TID=--, status=SUCCESS, nwkAddrOfInterest=47036, length=10, simpleDescriptor=SimpleDescriptor [endpoint=2, profileId=0104, deviceId=0, deviceVersion=1, inputClusterList=[6], outputClusterList=[]]]
	Line 341: 2019-11-22 16:13:09.738 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: SimpleDescriptorResponse [47036/0 -> 0/0, cluster=8004, TID=--, status=SUCCESS, nwkAddrOfInterest=47036, length=10, simpleDescriptor=SimpleDescriptor [endpoint=3, profileId=0104, deviceId=1, deviceVersion=1, inputClusterList=[8], outputClusterList=[]]]
	Line 364: 2019-11-22 16:13:10.004 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: SimpleDescriptorResponse [47036/0 -> 0/0, cluster=8004, TID=--, status=SUCCESS, nwkAddrOfInterest=47036, length=10, simpleDescriptor=SimpleDescriptor [endpoint=4, profileId=0104, deviceId=1, deviceVersion=1, inputClusterList=[8], outputClusterList=[]]]

flashbac · November 22, 2019, 9:56pm

Also same behavior is observed whether the device responds with UNREPORTABLE_ATTRIBUTE or SUCCESS

chris · November 22, 2019, 9:57pm

What command are you talking about?

flashbac · November 22, 2019, 9:59pm

RX CMD: ConfigureReportingResponse [Level Control: 47036/4 -> 0/1, cluster=0008, TID=8C, status=null, records=[Attribute Status Record: status=SUCCESS, direction=false, attributeIdentifier=0]]

chris · November 22, 2019, 10:01pm

The issue is caused by the fact that the binding expects the device to support the OnOff cluster, and yours doesn’t. Probably it shouldn’t assume that, but that’s the issue and most if not all devices do this.

flashbac · November 22, 2019, 10:02pm

OK, I can try that real quick, EP5 is configured that way