Binding should NOT require an endpoint with Level Control to also support the OnOff cluster.
Opened this issue · 3 comments
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.
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
After troubleshooting with @cdjackson (link) we found out that the issue is caused by the fact that the binding expects the Level Control endpoint to also support the OnOff cluster.
Although most if not all devices that support Level Control also support OnOff cluster, OH probably it shouldn’t assume that given that the zigbee specification clearly specifies handling both Level Control by itself and Level Control with On/Off support.
This makes OH less flexible and also previous versions of OH 2.x did not have this restriction.
From the ZCL Specification:
3.10.2.1 Dependencies
For many applications, a close relationship between this cluster and the OnOff cluster is needed. This section describes the dependencies that are required when an endpoint that implements the Level Control server cluster also implements the On/Off server cluster (see section 3.8).
The OnOff attribute of the On/Off cluster and the CurrentLevel attribute of the Level Control cluster are intrinsically independent variables, as they are on different clusters. However, when both clusters are implemented on the same endpoint, dependencies MAY be introduced between them. Facilities are provided to introduce dependencies if required.3.10.2.1.1 Effect of On/Off Commands on the CurrentLevel Attribute
The attribute OnLevel (see 3.10.2.3.4) determines whether commands of the On/Off cluster have a permanent effect on the CurrentLevel attribute or not. If this attribute is defined (i.e., implemented and not 0xff) they do have a permanent effect, otherwise they do not. There is always a temporary effect, due to fading up / down.
So according to the ZCL specs, the current behavior should happen if the following two conditions are met:
- The endpoint implements BOTH the On/Off server cluster and the Level Control server cluster.
- The endpoint implements the OnLevel attribute with a value that is not equal to 0xff.
If those conditions are not met, the OH should revert to the way OH2.4 behaves (not requiring the On/Off server cluster to enable the Level Control handler).
I agree that this needs to change - there's an open issue and it will be addressed at some stage in the future.
This issue has been mentioned on openHAB Community. There might be relevant details there: