Hedda
commented
2 years ago FYI, zigpy developer puddly has begun preliminary work on a new radio API for zigpy as well as on merging radio libraries respective high-level functions and command-line tools into zigpy-cli. Still very early on thus now would be a great time for Zigbee radio developers to start giving your feedback and input on the design of this new unified Zigbee CLI for zigpy which is meant as a common support for all radio manufacturers. See:
https://github.com/zigpy/zigpy-cli/ (and https://github.com/zigpy/zigpy-cli/issues plus there zigpy/zigpy-cli#5)
At the moment he is focusing on completely exposing the low-level network and node info, (for example energy scanning already works with TI ZNP and the deCONZ ConBee/RaspBee using the same code however the zigpy-znp command line tool just needs to be transplanted into zigpy-cli), so if you want a chance to influence what should go into that zigpy CLI versus what should go into the separate zigpy radio libraries for each manufacturer then now would be the best time to begin contributing.
- This new CLI as a standard radio settings API is primarily being discussed here -> [RFC] Standard radio settings API #842
- Development started here -> New radio API #848
- Cross-radio backup and restore -> Implement new radio API zigpy-cli#2
- pully mentioned that he is eventually planning on trying to add a similar shell using IPython for sending commands interactively ("since it has autocompletion and is async-friendly").
- pully also mentioned that bootloader commands are low on the priority list, "since that code is often pretty complex and uses internal radio library code. A plugin system could work, but since the existing bootloader tools are synchronous, it'd take either a complete rewrite to work with zigpy-cli, or the tools would essentially be run externally in a separate thread, which is no easier than directly running the original tools."
FYI, puddly has now merged the new radio API so all of zigpy radio libraries should now use the new unified API.
chshu
Not sure if this feature request belongs here for ESP-IDF or should be posted to https://github.com/espressif/esp-protocols/issues
Read Espressif has joined "ZBOSS Open Initiative (ZOI)" so ESP32-H2 will use the ZBOSS Zigbee stack by the DRS Corporation.
https://components.espressif.com/component/espressif/esp-zboss-lib
https://www.esp32.com/viewtopic.php?t=24624
https://dsr-iot.com/news/78
Therefore like to request DRS and Espressif make a ZBOSS radio library (written in Python) for the zigpy project (a Zigbee integration library) + add a TCP serial proxy/bridge component so that ESP32-H2 with ESP ZBOSS can in combination with it be used as a remote Zigbee Coordinator adapter by multiple third-party Zigbee gateway host implementations without modification:
https://github.com/zigpy/zigpy
https://github.com/zigpy/zigpy-cli
zigpy is an open-source Python library implementing Zigbee ZDO and ZDO integration with a unified serial API/CLI hardware-independent abstraction interface for different radio manufacturers and it is today used as a dependency by a few very popular DIY home automation application projects, including ZHA interaction for Home Assistant, Zigbee plugin for Domoticz, and Zigbee plugin for Jeedom, which allow the Zigbee host application implementation in those project to support different Zigbee stacks using the same interface/API.
https://www.home-assistant.io/integrations/zha
https://www.domoticz.com/wiki/ZigbeeForDomoticz
https://doc.jeedom.com/en_US/plugins/automation%20protocol/zigbee/
From the end-user point-of-view the appeal is by using zigpy the Zigbee application/integration implementation on the host side can in practice support almost all Zigbee Coordinator adapters from any manufacturer, and they can today for example be used out-of-the-box with Home Assistant ZHA, Domoticz, and Jeedom, as long there is a matching Zigbee stack radio library for zigpy (Zigbee application/integration implementation just need to depend on zigpy and its radio libraries instead of adding direct support for only a specific manufacturers API and Zigbee Coordinator adapter hardware):
https://github.com/zigpy/zigpy-znp
https://github.com/zigpy/zigpy-deconz
https://github.com/zigpy/bellows
https://github.com/zigpy/zigpy-zigate
https://github.com/zigpy/zigpy-xbee
Before looking at the code should first read this document:
https://github.com/zigpy/zigpy/blob/dev/CONTRIBUTING.md
For reference, also read this somewhat related discussion about creating a similar (but not same) new radio library for zigpy:
https://github.com/zigpy/zigpy/issues/394
PS: Might also be interested to read through these blog-posts by Jeedom which explain why they choose to depend on zigpy:
https://blog.jeedom.com/6107-parlons-zigbee/
https://blog.jeedom.com/5183-tout-ce-quil-faut-savoir-sur-le-plugin-officiel-zigbee/
PPS: Please understand that those zigpy libraries are free and open-source projects, (licensed so they can be used by the most popular open-source home automation applications), and developed by volunteers from the DIY home automation software communities in their spare time so unfortunately there is not a lot of development documentation, instead, if you (or DSR or other ZOI members) are interested in taking on this project to cretae a ZBOSS radio library for zigpy then you would primarily have to look at the code of all the existing radio libraries, like for example the zigpy-znp radio library (alternatively bellows or zigpy-deconz are among the best maintained) to see how their hardware serial API/CLI translation is done from proprietory serial API to the zigpy radio API/CLI which is meant to be unified for all zigpy radio APIs and CLIs. Then of course create an issue or discussion to post questions on specific problems if you get stuck or need feedback.
https://github.com/zigpy/zigpy/discussions
https://github.com/zigpy/zigpy/issues