search

shimmeringbee / zda

Adapter to convert ZCL frames and queries into Shimmering Bee abstractions, written in Go.
Apache License 2.0
1 stars 2 forks source link

Serialize/Deserialize node/device state #2

Closed pwood closed 4 years ago

pwood commented 4 years ago

At the moment zda can not be used accross program restarts - as the internal database has to be rebuilt each time. As such while NodeJoinEvents may reintroduce Zigbee devices, if they are end devices, there is a distinct possibility that an enumeration may fail on them. As such we need a way to save the ZDA state between runs.

A semi sane way to do this might be to abstract the node and device store to a seperate structure, and provide a way to store/load that. Which can then be passed into the zda when it is created. Further this may get us towards a stage where we reduce the need on the mutexes - which would be nice to bring the code to being more Go idomatic.

pwood commented 4 years ago

We only need to serialize certain information that can not be calculated upon load.

Technically the presence of devices can be calcualted from the node - but subidentifiers can not, as calculated identifiers may change in the unlikely event of new endpoints/devices appearing. - Do we not bother about this? OTA Firmware updates don't dictate a leave/join in the zigbee spec... so yes.

Do capabilities need to store data - or is everything a capability does calculated? No - HasProductInformation is queried from the device, capabilities might want to store the last state of the device (queried, or reported).

Capabilities may need to store data at both the node level and device level - capability of APS ack is a Node level piece of data (though probably a calculatable one).

Capabilities need to be offered saved data, as an alternative to enumeration (or addition?). A data blob also needs to be retrievable from the capability.

pwood commented 4 years ago

Do we want DeviceAdded/DeviceRemoved events for loaded devices? We either expect consumers to poll us on load for devices and their capabilities, then respond to events... or just send everything as an event (thus on load we'd need to announce EnumerateCapabilitiesFinished).

Presumably most consumers are going to have their own state - which works better as a pattern? If we follow Tell Dont Ask - then sending events seems like a better approach.

pwood commented 4 years ago

So this is done, but OnOff and HasProductInformation have not been moved over to it, this job has morphed into improving the interface between ZDA and implemented Capabilities. As such, I'm closing this and opening another to track.