At the moment most capabilities are overly complicated for the task that they do, that is:
Be able to issue ZCL Commands.
Periodically read attributes, and/or wait for attribute reports.
The current system of having attribute monitors attempts to hide much of the ZCL, that it does, but they are cumbersome to use. This results in overly complicated EnumerateDevice callbacks that should be relatively simple.
Further, because the aim is to support any device that supports a ZCL Cluster correctly, we must store details such as the endpoint and if polling is required (when a report attribute set up fails).
But there is some proprietary support that does not really need to make use of this, such as knowing that a device will always report an attribute on the Basic cluster on endpoint 0 of a device. If we know the device for example, we don't need to store that it requires its proprietary support, we can just assume that based on the device identity.
Ideally we need to simplify this, and make use of the configuration objects consistent.
pwood
commented
10 months ago
At the moment most capabilities are overly complicated for the task that they do, that is:
The current system of having attribute monitors attempts to hide much of the ZCL, that it does, but they are cumbersome to use. This results in overly complicated EnumerateDevice callbacks that should be relatively simple.
Further, because the aim is to support any device that supports a ZCL Cluster correctly, we must store details such as the endpoint and if polling is required (when a report attribute set up fails).
But there is some proprietary support that does not really need to make use of this, such as knowing that a device will always report an attribute on the Basic cluster on endpoint 0 of a device. If we know the device for example, we don't need to store that it requires its proprietary support, we can just assume that based on the device identity.
Ideally we need to simplify this, and make use of the configuration objects consistent.