You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is feature request / general architecture design discussion as a follow-up to reading #72 which state that zigbee-herdsman will likely also gain support for deCONZ based adapters like the ConBee.
Summary: This is at its essence just a request for making it easier for new developers to add support for additional Zigbee coordinator hardware from different manufacturers that use other firmware.
Background: I think zigbee-herdsman would gain greater popularity among both users and developers if it not only supported Zigbee coordinator hardware from Texas Instruments and Dresden Elektronik but also Zigbee coordinator hardware chips/firmware from more manufacturers, like Silicon Labs, ZiGate, and Nordic Semiconductor.
What I believe support for more Zigbee coordinator hardware chips/firmware from different manufacturers would achieve is it that more developers would join the development of zigbee-herdsman, something which in turn would indirectly benefit all users of zigbee-herdsman.
Therefore, I want to ask/request and discuss if it would maybe be a good idea for the zigbee-herdsman project to now implement some kind of unified HAL (Hardware Abstraction Layer) in order to in a common way abstract support for all types of Zigbee USB dongles from different manufacturers that communicate with the application using different protocols / APIs?
Presumably, you would probably also want the code for each type of different protocol to be kept separate in it own code library modules with its own revision and version control so that it can be maintained and updated separately from the zigbee-herdsman core?
The main point of this request is to open an architecture best practice discussion on wheater or not implementing a HAL would make it easier for new developers could in a simple way add support new Zigbee USB dongles from different manufacturers without really having to have any knowledge about zigbee-herdsman core structure.
Could zigbee-herdsman devs, in theory, port the zigpy library to use as a Hardware Abstraction Layer?
If you do not want to specifically use the zigpy library as a base then perhaps refactor zigbee-herdsman to use some other type of common Hardware Abstraction Layer in order to abstract and break-out hardware communication into separately maintained modules for each hardware protocol support that can be updated/released on their own?
The zigpy library was itself at one point refactored into such architecture design that is now capable of communicating with Zigbee adapters from different manufacturers using radio module libraries:
zigpy (which I guess is short for "Zigbee for Python") is a open-source hardware-independent Zigbee stack library written in Python that currently can communicate with a multitude of different Zigbee coordinator adapters, meaning it via radio modules supports Zigbee coordinator adapters from different manufacturers that all using different APIs, such as XBee based devices, EmberZNet based devices by Silicon Labs, Conbee/RaspBee by Dresden-Elektronik, ZiGate by fairecasoimeme, and recently even Z-Stack by Texas Instrument.
zigpy does this by depending on several Python modules which in turn each communicates directly with different USB radios native serial protocol (UART) for zigpy. For more on those modules see:
Coincidentally, I understand that the zigpy radio module library support for Z-Stack by Texas Instrument is implemented in the zigpy-cc library today is done via a zigbee-herdsman wrapper.
PS: By the way, the zigpy project also has a quirks library called zha-device-handlers that are similar to zigbee-herdsman-converters
Coincidentally, I understand that the zigpy radio module library support for Z-Stack by Texas Instrument is implemented in the zigpy-cc library today is done via a zigbee-herdsman wrapper.
AFAIK this is not true, they just rewrote it based on the zigbee-herdsman code, herdsman = javascript, zigpy-cc = python
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is feature request / general architecture design discussion as a follow-up to reading #72 which state that zigbee-herdsman will likely also gain support for deCONZ based adapters like the ConBee.
Summary: This is at its essence just a request for making it easier for new developers to add support for additional Zigbee coordinator hardware from different manufacturers that use other firmware.
Background: I think zigbee-herdsman would gain greater popularity among both users and developers if it not only supported Zigbee coordinator hardware from Texas Instruments and Dresden Elektronik but also Zigbee coordinator hardware chips/firmware from more manufacturers, like Silicon Labs, ZiGate, and Nordic Semiconductor.
What I believe support for more Zigbee coordinator hardware chips/firmware from different manufacturers would achieve is it that more developers would join the development of zigbee-herdsman, something which in turn would indirectly benefit all users of zigbee-herdsman.
Therefore, I want to ask/request and discuss if it would maybe be a good idea for the zigbee-herdsman project to now implement some kind of unified HAL (Hardware Abstraction Layer) in order to in a common way abstract support for all types of Zigbee USB dongles from different manufacturers that communicate with the application using different protocols / APIs?
Presumably, you would probably also want the code for each type of different protocol to be kept separate in it own code library modules with its own revision and version control so that it can be maintained and updated separately from the zigbee-herdsman core?
The main point of this request is to open an architecture best practice discussion on wheater or not implementing a HAL would make it easier for new developers could in a simple way add support new Zigbee USB dongles from different manufacturers without really having to have any knowledge about zigbee-herdsman core structure.
Could zigbee-herdsman devs, in theory, port the zigpy library to use as a Hardware Abstraction Layer?
If you do not want to specifically use the zigpy library as a base then perhaps refactor zigbee-herdsman to use some other type of common Hardware Abstraction Layer in order to abstract and break-out hardware communication into separately maintained modules for each hardware protocol support that can be updated/released on their own?
The zigpy library was itself at one point refactored into such architecture design that is now capable of communicating with Zigbee adapters from different manufacturers using radio module libraries:
https://github.com/zigpy/zigpy
zigpy (which I guess is short for "Zigbee for Python") is a open-source hardware-independent Zigbee stack library written in Python that currently can communicate with a multitude of different Zigbee coordinator adapters, meaning it via radio modules supports Zigbee coordinator adapters from different manufacturers that all using different APIs, such as XBee based devices, EmberZNet based devices by Silicon Labs, Conbee/RaspBee by Dresden-Elektronik, ZiGate by fairecasoimeme, and recently even Z-Stack by Texas Instrument.
zigpy does this by depending on several Python modules which in turn each communicates directly with different USB radios native serial protocol (UART) for zigpy. For more on those modules see:
https://github.com/zigpy/bellows
https://github.com/zigpy/zigpy-znp
https://github.com/zigpy/zigpy-deconz
https://github.com/zigpy/zigpy-xbee
https://github.com/zigpy/zigpy-cc
https://github.com/zigpy/zigpy-zigate
Coincidentally, I understand that the zigpy radio module library support for Z-Stack by Texas Instrument is implemented in the zigpy-cc library today is done via a zigbee-herdsman wrapper.
PS: By the way, the zigpy project also has a quirks library called zha-device-handlers that are similar to zigbee-herdsman-converters
https://github.com/zigpy/zha-device-handlers
The text was updated successfully, but these errors were encountered: