There are still many undocumented parts which need to be discussed and added there and in further wiki pages.
Note that the current Device code is a prototype to explore the basic ideas and not set in stone in terms how things are done or structured, we should discuss, refactor and shape the hell out of it in order to make it maintainable and be understandable where needed :)
Already working but undocumented:
Polling of ZCL attributes in Operating/Idle state based on what the DDF specifies;
Device Tick which controls the timing/pace of device state machines during setup and idle handling — device_tick.cpp;
Database store and reload of devices — database.h;
Device controlled setup and maintenance of Bindings and ZCL Reporting;
Writing ZCL attributes during setup.
It would be cool if we can schedule a meeting before the next developer meeting to figure out how we can proceed. Perhaps if we pick a device everybody has, and try to get the code running is a good starting point to experiment and discuss the DDF and Device code topic?
Hi everyone, I've started a wiki page to provide an overview of how generic handling is approached in current
Devicecode:https://github.com/dresden-elektronik/deconz-rest-plugin-v2/wiki/Device-Classhttps://dresden-elektronik.github.io/deconz-dev-doc/modules/class-device
There are still many undocumented parts which need to be discussed and added there and in further wiki pages.
Note that the current Device code is a prototype to explore the basic ideas and not set in stone in terms how things are done or structured, we should discuss, refactor and shape the hell out of it in order to make it maintainable and be understandable where needed :)
Already working but undocumented:
It would be cool if we can schedule a meeting before the next developer meeting to figure out how we can proceed. Perhaps if we pick a device everybody has, and try to get the code running is a good starting point to experiment and discuss the DDF and Device code topic?