Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HAL (Hardware Abstraction Layer) to support Zigbee adapters from different manufacturers? #150

Closed
Gamester17 opened this issue Mar 3, 2020 · 2 comments
Labels

Comments

@Gamester17
Copy link

Gamester17 commented Mar 3, 2020

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

@Koenkk
Copy link
Owner

Koenkk commented Mar 3, 2020

In order to add support for a new adapter the following interface has to be implemented: https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/adapter.ts

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

@stale
Copy link

stale bot commented Jun 21, 2020

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.

@stale stale bot added the stale label Jun 21, 2020
@stale stale bot closed this as completed Jun 28, 2020
@Gamester17 Gamester17 mentioned this issue Nov 3, 2020
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants