[Architecture] Remove the "zigpy parts" from bellows to make it consistent with the other radio libraires?

[Hedda]

Would it be a good idea to remove the "zigpy parts" from bellows to make it consistent with the other radio libraries for zigpy?

As I understand, the bellows library duplicates some of the zigpy library functionally from an architectural design as it stands today.

The bellows library duplicate ZCL (Zigbee Cluster Library) plus ZDO (Zigbee Device Object) and application state management (application framework with device state persistence) functionality that is also available in zigpy. The other "radio libraries" for zigpy does not have a copy of those "zigpy parts" themselves but instead depend on zigpy. This makes bellows the only radio library which can be used stand-alone without the zigpy library.

I know this design is because of historical reason as bellows itself existed before the zigpy library was created and that the zigpy library was created as a modular split from the bellows library in order to act as hardware abstraction so that radio libraries can be independently maintained and updated separately.

Question is if it would not be better for the zigpy project as a whole to remove the ZCL, ZDO, and application state management functionality from bellows and instead depend on the zigpy library to do those parts and thus no longer making it possible to use bellows stand-alone?

Reference:

https://github.com/zigpy/zigpy/blob/dev/README.md

zigpy contains common code implementing Zigbee ZCL, ZDO and application state management which is being used by various radio libraries implementing the actual interface with the radio modules from different manufacturers. The separate radio libraries interface with radio hardware adapters/modules over USB and GPIO using different native UART serial protocols.

https://github.com/zigpy/bellows/blob/dev/README.md

Currently implemented features are:

• EZSP UART Gateway Protocol
• EZSP application protocol
• CLI wrapping basic ZigBee network operations (eg, scanning and forming a network)
• ZDO functionality (with CLI)
• ZCL functionality (with CLI)
• An application framework with device state persistence

[Hedda]

This might be the same issue as #96 request to clean-up the bellows CLI and database stuff that belongs in zigpy?

[Adminiuga]

It was already done, like 2-3 years ago. That's how zigpy came to be, split away from bellows.

[Hedda]

So the bellows readme is wrong or at least not clear? https://github.com/zigpy/bellows/blob/dev/README.md

Currently implemented features are:

• EZSP UART Gateway Protocol
• EZSP application protocol
• CLI wrapping basic ZigBee network operations (eg, scanning and forming a network)
• ZDO functionality (with CLI)
• ZCL functionality (with CLI)
• An application framework with device state persistence

If those are features of zigpy and not bellows then maybe they should not be mentioned in the bellows readme?

[Adminiuga]

Bellows can tell the device to leave a network. That's ZDO functionallity. Readme is correct.