Many pieces of functionality are standardised accross Zigbee devices, however there are also many exceptions, through either non standard approaches, partial implementations or broken behaviour.
By design ZDA should automatically work with a piece of equipment that implements functionality in a standard way. Basic On/Off for example, if advertised via a Cluster on an Endpoint, will be enumerated as a capability and made available.
However, many devices misbehavour, an example is the Xiaomi WSDCGQ01LM, it advertises cluster ids it does not actually support (for example Groups, Scenes, Identify and MultistateInputBasicId), perhaps more egregiously it doesn't advertise Temperature and Humidity (their entire purpose). On three endpoints! See xaiomi-temp.txt
This ticket is to implement a first pass at a system that permits configuration to control which clusters, endpoints, etc are actually used by the ZDA (always defaulting to the codes behaviour if none present).
Most other implementation of Zigbee controllers hard code this information, for good reason, this is a complicated approach, but it benefits users by allowing them to change support for new devices without shimmering bee authors. We can also distribute the rule list seperately from the source tree.
Requirements
Selection - A rule should be able to filter on, manufacturer code, product manufacturer, product name, endpoint, zcl cluster id. Simple equality with negation, wildcard missing.
Heirachical - Rules should be nestable to support heirachies of rules, for example, all IKEA Tradfri can be set to suport APS ACK.
Last Match - Rules in the same level are all executed, the last result wins. This permits building general rules with exceptions.
Flag Based - Rules list a set of flag assertions, true or false. Absense of flag infers zdas default behaviour.
Problem
Many pieces of functionality are standardised accross Zigbee devices, however there are also many exceptions, through either non standard approaches, partial implementations or broken behaviour.
By design ZDA should automatically work with a piece of equipment that implements functionality in a standard way. Basic On/Off for example, if advertised via a Cluster on an Endpoint, will be enumerated as a capability and made available.
However, many devices misbehavour, an example is the Xiaomi WSDCGQ01LM, it advertises cluster ids it does not actually support (for example Groups, Scenes, Identify and MultistateInputBasicId), perhaps more egregiously it doesn't advertise Temperature and Humidity (their entire purpose). On three endpoints! See xaiomi-temp.txt
This ticket is to implement a first pass at a system that permits configuration to control which clusters, endpoints, etc are actually used by the ZDA (always defaulting to the codes behaviour if none present).
Most other implementation of Zigbee controllers hard code this information, for good reason, this is a complicated approach, but it benefits users by allowing them to change support for new devices without shimmering bee authors. We can also distribute the rule list seperately from the source tree.
Requirements