Refactor implementation of capabilities.

[pwood]

My initial approach to zda was to assume that devices would support the zigbee specification, while I knew this not to be true I believed that the exceptions could be managed well.

Further many Capabilities that merely monitor an attribute in a cluster (Temperature, Humidity, etc) are essentially duplicates, even though they reuse functionality.

I want to refactor to acheive two main goals:

1. For well behaved clusters that only monitor attributes (set up reporting, or periodicly poll) implement a new generic capability.
   • Provide a Cluster ID, AttributeID, functions to convert values to events, etc.
   • Would still require wiring up to Capability methods.
   • Need to figure out how Commands would fit into this.
2. More generically, make ZDA support multiple providers for the same capability.
   • Default to ClusterIDs being present on Endpoints, and automatically attach a ZCL based approach, i.e. ZCLTemperature for the Temperature Cluster existing.
   • Allow rules.json to specify that a specific implementation should be used, for example XiaomiTemperature can be added based on device type.

Solving both of these things would allow much more rapid development of ZDA.

[pwood]

This resulted in the creation of the from-scratch branch - after a long break due to having a child I'm back to solve this.

from-scratch as the name suggests is a complete rewrite of the zda code base, though it's importing reusable pieces of code from the existing master and reimplemeting pieces that have become untennable.

Working on this has made me realise that the concept of fetching a Capabiltiy object from a Gateway to operate on a Device is a bit crazy. It has some real limitations, such as making it difficult to have multiple implementations of the same Capability in one DA.

For example in the case of zda this would come up for ZCLTemperatureSensor and TuYaTemperatureSensor - the assumption now from da is that a new Capability object will be created for each Device, and is retrieved from the Device not the Gateway. This simplifies the actual implementation of the Capabiltiy as it no longer has to track which Device is being worked upon.

If there is the need for a one capability structure to serve all devices, this can effectively be done by small structs that just hold enough binding data, which proxies to the singleton capabiltiy. In zda this is used for enumerateDevice.

I started a lot of this rework without thinking to track the work in this ticket, so I'll now create the todo list to keep track of what needs doing.

[pwood]

Todo:

• [x] Finish enumeration of node and device, including creating/destroying capabilities.
• [x] Peristence of data
• [x] Reloading at zda start.
• [x] ZCL message handling and serving to capabilities.
• [x] Reimplement capabilities, use a common framework for simple clusters that have 1..n attributes to surface.
• [x] Send Events from enumeration.
• [x] Attach enumeration shim to newly created devices.
• [x] Outbound event handling gateway.ReadEvent()
• [x] Implement device discovery capability.
• [x] Add onNodeLeave() use to tidy up capabiltities, Detach() on ZDACapability probably required.
• [x] Evaluate logging and add more back to places its been removed.
• [x] Reimplement device removal capabiltiy.
• [x] If enumeration fails first time, EnumerateDevice and DeviceRemoval are never attached.
• [x] Device with Subidentifier of zero, never has a deviceId.
• [x] Add DeviceAdded, DeviceRemoved, CapabilityAdded and CapabilityRemoved events.

[pwood]

Thoughts about persistance:

zstack, zda and the need to store data in a somewhat simplistic for, kinda equivilent to maybe the windows registry or a large ini file.

Specifically for zda, we might need to store data about a node, a device and a capability on a device. In each case the data store is likely to be a simplistic key value store. Can we input some kind of persistence store interface which can be provided at init time.

We'd need to be able to add/delete/list devices/nodes, get and set values (maybe as maps, rather than individual values).

[pwood]

• [x] Refactor how Capabilities are added or removed from Devices to allow an singular place to send events about it.

[pwood]

• [x] Fix the way sub devices are created from nodes, at current we split on deviceId, this is incorrect, we should just split on endpoint.

[pwood]

I'm drawing the line on the reimplementation of capabilites, I've opened #22 and #23 to cover them. For the sake of my energy on this project, I need to get the whole stack implemented all the way through to the controller. Which will require significant zstack and controller work.