[REQUEST] Zigpy integration supporting different Zigbee adapter brands using same unified radio API?

[Gamester17]

I like to suggest to Domoticz plugin developers look into Zigbee implementation via zigpy libraries in a similar way to Home Assistant's ZHA integration?

• https://github.com/zigpy/zigpy

• https://github.com/zigpy/zigpy-cli

• https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md

• https://github.com/zigpy/bellows/tree/dev/bellows/cli

• https://github.com/zigpy/zigpy/wiki

• https://www.home-assistant.io/components/zha/

• https://github.com/home-assistant/core/ ... onents/zha

UPDATE! Jeedom's new official Zigbee Plugin is now also based on the Zigpy library and shared the same dependencies as Home Assistant's ZHA code:

• https://doc.jeedom.com/en_US/plugins/au ... ol/zigbee/

• https://blog.jeedom.com/5183-tout-ce-qu ... el-zigbee/

• https://market.jeedom.com/index.php?v=d ... ay&id=4050

• https://compatibility.jeedom.com/index. ... col=Zigbee

Zigpy and its radio libraries can act as low-level open source Zigbee stack that abstracts/translate third-party Zigbee stacks with common API and CLI.

The main benefit of implementing a Zigbee implementation via Zigpy library is that it has support for several different hardware via its dependencies.

This means that if developers create a zigpy based plugin for Domoticz using zigpy's unified radios serial API then could relatively easily extend to support all different Zigbee stacks from several manufacturers which does not use the same serial APIs and CLIs at all.

Zigpy library abstract Zigbee stacks and acts as a common framework CLI/API so that support for different Zigbee adapters integrates the same way.

That is, there are many different Zigbee radio libraries for the zigpy library but they all used in unified way sharing the same CLI/API in a common way:

• Silicon Labs EmberZNet (EZSP) radios like EFR32MG1x/EFR32MG2x (and obsolete EM35x/ETRX35x) https://github.com/zigpy/bellows
• Texas Instruments Z-Stack (ZNP) radios like CC2652 and CC1352 (as well as obsolete CC2531, CC2531, CC2538) https://github.com/zigpy/zigpy-znp
• Dresden Elektronik deCONZ based radios like ConBee 2 and RaspBee 2 (and obsolete ConBee/RaspBee) https://github.com/zigpy/zigpy-deconz
• XBee (Digi XBee Zigbee) based adapters like Digi XBee 3 Zigbee 3 RF modules https://github.com/zigpy/zigpy-xbee
• ZiGate (and ZiGate+ / ZiGate Plus) based adapters and modules https://github.com/zigpy/zigpy-zigate

It also has a centralized Zigbee device handler/converter library which can help convert/translate non-standard attributes to workaround quirks/deviations in devices that do not follow the Zigbee standards, that way each device is presented to the application as presenting only standard ZCL specifications.

• https://github.com/zigpy/zha-device-handlers

zigpy radio libraries also support a common "open Zigbee coordinator backup format" making it possible to migrate between Zigbee hardware/stacks:

• https://github.com/zigpy/open-coordinator-backup

The long-term idea with this "open Zigbee coordinator backup format" is that you will not only be able to backup a Zigbee USB adapter that is based on for example Silicon Labs Zigbee stack and then restores it to a Zigbee USB adapter that is based on other like Texas Instruments Zigbee stack, but as well that you will be able to do a backup of your Zigbee network in one Zigbee solution that supports "open Zigbee coordinator backup format" like for example Zigbee2MQTT and then restore it to the other Zigbee solution which also supports it, like for example Home Assistant's ZHA integration or Jeedom, and hopefully even more Zigbee solutions in the future.

There is no zigpy SDK but I believe a Zigbee implementation based on zigpy could be made to act similar to how Z-Wave already works in Domoticz(?).

With that, my understanding is that any developer building an implementation based on zigpy will need to first learn how Zigbee works at a low-level.

What do you developers working on different Python-based Zigbee implementation plugins for Domoticz think about this idea?

[Thorgal789]

Lol "unified way" in zigbee ? Even devices/Manufacture are not "unified", it's not Zwave.

Just by curiosity, in Home assitant there is 2 components "Zigbee Home Automation" and "deconz", for an user that have a conbee which one will you advise for better support, more features and better stability ?

Just to joke, even in deconz their devs have sometime problems to "unifiy" their own API just for Philips HUE and other manufacture in same time, and they are using only 1 hardware, their.

Realy nice project, but (on my side) if one day I use it, it will be in 5/6 years.

[Gamester17]

Lol "unified way" in zigbee ? Even devices/Manufacture are not "unified", it's not Zwave.

Since directing my request to Python plugin developers who are probably already familiar with some different Zigbee implementations I thought it obvious that I did not mean that the actual Zigbee devices/sensors were supported in a unified way in the application, as Zigbee devices not following standards will still need customization.

I only meant that that support for different "Zigbee Coordinator" adapters (as in Zigbee radio dongles/sticks) from different manufacturers can be implemented in a unified way when using zigpy radios common serial API. That is, the unified zigpy radios serial API and the zigpy library acts as a Zigbee stack abstraction middleware wrapper that translates and converts APIs for different Zigbee stacks into a shared common radio API so should only have to talk its language, so to speak.

The plugin for Domoticz would integrate with zigpy radio libraries (and the zigpy library) and in theory really only have to know how zigpy's common radios serial API works, while the upstream zigpy radio libraries and other zigpy library dependencies (read radio wrapper module libraries, zigpy library for ZCL, ZDO and application state management, as well as ZHA Device Handlers for conversion of deviating Zigbee devices) would together take care of the huge mess that is talking to different Zigbee devices/sensors where many if not most manufacturers deviate from the standard Zigbee specifications.

You should note though that the Zigbee stack implementation in the Zigpy library is much more structured than for example that of Samsung SmartThings Hub. So for devices to fully work properly out-of-the-box with Zigpy they really do need to conform to the strict parameters of the official Zigbee standards as set by the Zigbee Alliance, (whereas with Samsung SmartThings Hub each device has basically been custom written). However, if the device is similar to an existing device, but something in the implementation is a bit off from the Zigbee standard, developers can fix this deviation by writing a custom ZHA Device Handler (a.k.a. “quirk”) for the quirks project which Home Assistant uses to work around Zigbee devices that deviate from or do not fully conform to the standard specifications, those are collected in its own project that can be found here:

https://github.com/zigpy/zha-device-handlers

You might, however, be pleasantly surprised how many (none-Chinese) Zigbee devices that actually do conform with the official Zigbee standards as set by the Zigbee Alliance and thus work fine out-of-the-box without having the need of a custom ZHA Device Handler (also known as a "quirk").

https://www.home-assistant.io/components/zha/

ZHA exception and deviation handling

Zigbee devices that deviate from or do not fully conform to the standard specifications set by the Zigbee Alliance may require the development of custom ZHA Device Handlers (ZHA custom quirks handler implementation) to for all their functions to work properly with the ZHA integration in Home Assistant. These ZHA Device Handlers for Home Assistant can thus be used to parse custom messages to and from Zigbee devices.

The custom quirks implementations for zigpy implemented as ZHA Device Handlers for Home Assistant are a similar concept to that of Hub-connected Device Handlers for the SmartThings Classics platform as well as that of Zigbee-Shepherd Converters as used by Zigbee2mqtt, meaning they are each virtual representations of a physical device that expose additional functionality that is not provided out-of-the-box by the existing integration between these platforms.

Just by curiosity, in Home assitant there is 2 components "Zigbee Home Automation" and "deconz", for an user that have a conbee which one will you advise for better support, more features and better stability?

Sorry but I think that question is off-topic for this specific thread and that discussion would be better in a separate thread (and that probably in the Home Assistant forum instead if that really is your question), but for your information; That "ZHA" (Zigbee Home Automation) implementation via that Zigpy library is the only 'native' solution in Home Assistant which can is fully integrated into the GUI to directly support Zigbee by just plugging in any compatible Zigbee USB adapter (from an end-user point-of-view the interface is very similar to how Z-Wave USB adapters work in Domoticz and Home Assistant).

All other solutions to control Zigbee from Home Assistant rely on external third-party gateways/bridges/hubs which most of the time have to be administered separate from Home Assistant itself, and that includes all non-native integration components for different third-party "hubs" like deCONZ/Phoscon gateway software, Philips Hue Bridge, IKEA Trådfri Gateway, Samsung SmartThings Hub, and the Xiaomi Smart Home Gateway, as well as many other multi-protocol hubs/gateways/bridges. Those will convert/translate Zigbee and abstract it behind another API or CLI (which may be proprietary or open but regardless it is no longer the Zigbee protocol that they present in those APIs and CLIs. Thus they can not really count as native Zigbee implementations.

While the Zigpy based ZHA integration component in Home Assistant can still be considered to be in relatively early development its 'native' integration implementation in Home Assistant still makes it the most intuitive to quickly get started with as an end-users, because it is almost as simple as to just plugin in one of the many compatible Zigbee USB adapters and then start pairing adapters, again similar to how Z-Wave USB adapters works in Domoticz and Home Assistant. What is currently missing is the fully automatic detection of exactly which Zigbee USB adapter type you have plugged-in and in which port, however, I believe that is being worked on to make it work automagically in a more fully plug-and-play installation flow?

As mentioned there are several other ways for an end-user to get Zigbee support in Home Assistant or Domoticz via external third-party applications and hubs/gateways but you must manage those separately; such as deCONZ, Zigbee2mqtt, Philips Hue Hub, Ikea Trådfri Gateway, Aqara Smart Home Gateway plugin, etc. and most important to note is that all those external third-party applications and hubs/gateways/bridges are stand-alone platforms which can work without Home Assistant or Domoticz, they are not fully integrated making them less intuitive to use for end-users. Again, I think that deeper discussions about those other solutions are off-topic for this specific thread.

[Thorgal789]

Just by curiosity, in Home assitant there is 2 components "Zigbee Home Automation" and "deconz", for an user that have a conbee which one will you advise for better support, more features and better stability?

Sorry but I think that question is off-topic for this specific thread and that discussion would be better in a separate thread (and that probably in the Home Assistant forum instead if that really is your question), but for your information; ZHA (Zigbee Home Automation) implementation via Zigbee is the only 'native' solution in Home Assistant which can be fully integrated to directly support by just plugging in a Zigbee USB adapter (from an end-user point-of-view the interface is similar to how Z-Wave USB adapters works in Domoticz and Home Assistant),

For me it' s a good question, it's the more important one.
So first It's just my personnal opinion, I m just a domoticz lambda user, and I m agree,I m extremist.

You are in a Home automation forum, here you can find 2 kinds of users
1 - Thoses who just want the light turn on when they press the switch on.
2 - Thoses motived to make code for the firsts ones, and them ofc.

ATM just with zigbee2mqtt+deconz+zigate you can cover more than 85% of zigbee request (and a lot just with zigbee2mqtt) and probably more, it's just my estimation.
If someone want to make a code using your lib
1 - Lot of works, It s something new.
2 - The result will be just "one more zigbee plugin", and futures users will choose between for exemple Zigate plugin and Zigpy plugin.
3 - More dependency.
4 - Like I have said, it's not zwave, the amount of work is huge.

On my side I m not masochistic, why I will make a new plugin, for few users (most of them don't need it or will prefer existing plugin). Existing plugin are realy good, some of them are already "plug and play" or 'intuitive", a new plugin need to be BETTER than them, not to unify the existing HARDWARE solutions. All existing solutions are differents and have advantage and inconvenient, users prefer one of other because of that, to unify them means to delete this difference.

I m the dev of the deCONZ plugin, do you think I have used serial protocol to make it ? I have used their API, realy hight level API, so powerfull that I have made the first version of my code in less than 2 days. Users who make code want other thing too, something reliable to have less support possible to do.

It's a good project, I realy like it, and I will probably use it in 5 years, but ATM, not usefull for me ( But I'm not a reference)

Sorry for my agressivity, but like I have said, I realy think you have a good idea but too optimistic in actual situation.

such as deCONZ, Zigbee2mqtt, Philips Hue Hub, etc. and most important to note is that all those external third-party applications and hubs are stand-alone platforms which can work without Home Assistant or Domoticz

Zigate only works with serial connexion, and it's something possible with other hardware too, but noone want to spend time on that, and It's not an advantage, depend of situation.

[pipiche]

I like to suggest to developers look into native Zigbee implementation via Zigpy library in a similar way to Home Assistant's ZHA integration?

• https://github.com/zigpy/zigpy
• https://www.home-assistant.io/components/zha/
• https://pypi.org/project/zigpy-homeassistant/ (https://github.com/zigpy/zigpy/issues/190)

The main benefit of a native Zigbee implementation via Zigpy library is its support for several different Zigbee USB adapters via modules:

• Telegesis / Elelabs / Linear / Nortek / GoControl (EmberZNet EZSP) https://github.com/zigpy/bellows
• ConBee / RaspBee (Dresden-Elektronik deCONZ) https://github.com/zigpy/zigpy-deconz
• XBee (Digi) https://github.com/zigpy/zigpy-xbee
• ZiGate https://github.com/doudz/zigpy-zigate

Zigpy library acts as a Zigbee protocol stack and a framework so that support for all different Zigbee USB adapters integrates the same way.

I had a look to zigpy project, but it is probably obvious for the HA developers but not for other. I didn't see any documentation on how to use the library for instance!

[Gamester17]

I had a look to zigpy project, but it is probably obvious for the HA developers but not for other. I didn't see any documentation on how to use the library for instance!

I see that you posted question about the lack of development documentation to zigpy developers here:

https://github.com/zigpy/zigpy/issues/452

As per the replies there. As you probably already know and understand, zigpy developers are volunteers and like with most open-source hobby projects like this, the code will be the documentation. Usually an open source project needs to hit critical mass of more developers before someone will start to document library and code usage, (today not even ZHA end-user usage is well documented, though they more recently made the installation flow in the UI very easy to a degree that end-users almost do not need any documentation to get started with Zigbee in Home Assistant when using the ZHA integration component)..

What I do know is that while the zigpy library is not dependent on Home Assistant, the fact still remains that Home Assistant's ZHA integration component is the reference implementation of the zigpy library, and as far as I know currently also the only active implementation, so the best approach would probably be to look at and copy at the how the code from Home Assistant's ZHA integration component has implemented zigpy and then try to do something similar. That is of course besides asking and getting answers to specific question from developers in an issue discussion like you already started with the zigpy developers.

https://github.com/home-assistant/core/ ... onents/zha

If more developers and more independently operated projects use zigpy then odds are that it will become better documented over time

Regardless it is very cool to hear that someone is interested in this idea for Domoticz!

[pipiche]

@Gamester17 thanks for the nice words.

I share your point on the mass development are around HA, and I think that probably Domoticz should take care of that, as I do not see a lot enhancement coming around the Domoticz UI. I saw already a number of users who move to HA for that reason.

As regards to zigpy, I'm starting to have a very early POC working with Domoticz , which give the green light for more However as for Domoticz, the lack of internal documentation makes the things very hard to go in and I think this is really the shame of most of the Open Source Development which are lacking Development Guide.

[Gamester17]

I think this is really the shame of most of the Open Source Development which are lacking Development Guide.

What can be suggested to the zigpy developers is to start using inline documentation in the code, as that way documentation does not have to be maintained separately (which would normally quickly be outdated) and can instead be generated live at any time from the latest code three using documentation generator tools. However, for that, the developers do need to follow a standard for inline documentation in the code, with Doxygen probably being the most popular from what I understand

https://www.doxygen.nl/index.html

CodeDocs will then generate and publish documentation for you, using Doxygen, (free and easy to setup with your public GitHub repositories).

https://codedocs.xyz/

For example, you can check out the Kodi code documentation generated on codedocs.xyz

https://codedocs.xyz/AlwinEsch/kodi/

https://codedocs.xyz/AlwinEsch/kodi/_do ... addon.html

There are of course many different standards for inline code documentation and also many documentation generation tools

https://wiki.python.org/moin/DocumentationTools

[Gamester17]

As regards to zigpy, I'm starting to have a very early POC working with Domoticz , which give the green light for more However as for Domoticz, the lack of internal documentation makes the things very hard to go in and I think this is really the shame of most of the Open Source Development which are lacking Development Guide.

Did you also look at how https://github.com/daniel17903/ZigCoHTTP and https://github.com/Seluxit/qzig implements/uses the bellows library?

If you look at those then I think you can substitute the bellows library with both the zigpy library and the zigpy-zigate library instead, this as bellows contain all the same parts as he zigpy library and the zigpy-zigate library do together, it is therefore you can use bellows without the zigpy library but not use zigpy-zigate without the zigpy library.

As someone wrote, the zigpy library was priginally forked from the bellows library and bellows was meant to be refactored to also need the zigpy library as a dependacy (just like all the other radio libraries for zigpy) but the parts that was split out to the zigpy was never removed from the bellows library, which is why you can still use that as a standalone library today but all the other zigpy radio libraries does require the zigpy library as a dependecy.

[pipiche]

Thanks for all those inputs.
As of now, I'm a bit stuck as the zigpy-zigate lib seems not to be ready. I'll be waiting.


https://github.com/pipiche38/Domoticz-Zigpy

[Gamester17]

Thanks for all those inputs.
As of now, I'm a bit stuck as the zigpy-zigate lib seems not to be ready. I'll be waiting.

https://github.com/pipiche38/Domoticz-Zigpy

That is cool, but have you thought about getting other zigpy compatible adaptera that are not a ZiGate so can test zigpy with different hardware?

If nothing less that should work as a workaround since I understand all zigpy radio libraries use the same API from your application point-of-view.

You live in Europe right? If so I might have one or two spare CC2531 USB adapter laying around which I could post to you if PM your postal-address.

You might also want to consider buying the Sonoff ZBBridge WiFi Bridge and flash with new tasmota-zbbridge Tasmota Zigbee Bridge firmware:

https://www.digiblur.com/2020/07/how-to ... -with.html

It is relativly inexpensive and can be found locally in Europe now, it is also very practical to have your Zigbee adapter in a WiFi Bridge format!

[pipiche]

Why not, but then I would have an issue, as if zigpy is making an abstract layer but at then it doesn't support ZiGate (which is the HW that I used for the Domoticz plugin I developed), I do not really see a personal interest there.

For now, anyway I'm stuck in a Domoticz issue (segmentation fault) which looks pretty strange and which might be a blocking issue for the zigpy plugin

[Gamester17]

Why not, but then I would have an issue, as if zigpy is making an abstract layer but at then it doesn't support ZiGate (which is the HW that I used for the Domoticz plugin I developed)

The zigpy hardware abstract layer is the main feature that is what is great about the concept behind the zigpy library. Since all radio libraries made for zigpy has the same API on the application-side you as an integration developer can a different adapter manufacturer and another radio library to develop the integration for zigpy in Domotiz, at least that is the idea. A single framework and API that can control all Zigbee hardware.

Because all those radio libraries use the same API, once you have added integration in Domoticz support for zigpy and only one of its radio library then you should, in theory, have no problem in adding support all the other radio libraries for zigpy as well. That will then allow Domoticz end-user to pick and choose from any zigpy compatible radio library and adapter manufactuer using the same integration.

It also allows you or other developers to in the future relatively add support for additional radio libraries if someone makes new ones for zigpy, (puddly is, for example, currently working on an alternative radio library for Texas Instruments Z-Stack 3.x based adapters, and there is also still missing a zigpy radio library for Nordic Semiconductor based adapters with the ZBOSS Zigbee stack).

So I would not worry about that zigbe radio library compatibility. You could not have to restart development if you use hardware from a other supported manufacturer, again in theory, you should only have to substitute the zigpy-zigate for a other of the supported radio library and you should then be able to use one of the hardware adapters that is supported by that radio library instead.

This is how the ZHA integration component in Home Assistant can support so many adapters from different manufacturers, just checkout the list at https://www.home-assistant.io/integrations/zha/

One API to rule them all!

[pipiche]

So for now, I have been able to duplicate the issue with a little piece of code with wich I crash Domoticz everytime.
Looks like using sqlite3 with Domoticz Python Framework create some issues.

https://www.domoticz.com/forum/viewtopi ... 42#p254488

Either, what I'm doing in the plugin is not correct, either the zigpy usage of sqlit3 is not correct or there is an issue in the Python Framework.

stay tunes

[pipiche]

@Gamester17 for your information I'm putting the project on hold. Behind that decision they are several points which makes be to reach that

1/ SQLITE3 issue ( https://github.com/domoticz/domoticz/issues/4312 ). I have duplicated the problem with a short plugin. I have found that is related to a conflict between Domoticz sqlite3 usage and the embedded python framework. By linking domoticz with one common single standard sqlite3 the problem doesn't exist. However no real support.

2/ zigpy is hardly design to work with Home Automation. Not much documentation ( as for Domoticz) , quiet often pointing to the Home Automation code to understand and see what to do.

3/ From a Domoticz standpoint @gizmocuz pointed out that they are already 4 Zigbee hardware.

From that,

[2] will required a lot of investment in understanding how zigpy works, how zigpy provides event to the above layer ... For exemple just the implementation of the Motion Sensor looks not as simple as I would expect from a library. It looks like quiet a number of stuff have to be done at the application level (seting listeners ...).
In addition [1] is puting the risk that the investment to be made in order to understand how zigpy works and how to design the plugin to deal with the Domoticz environment, will be simply waste if the SQLITE3 is notr fixed.

The project is available here https://github.com/pipiche38/Domoticz-Zigpy for reference

[pipiche]

Unfortunately no real support to make progress on the blocking SQLITE3 issue, which prevent us to continue on the Domoticz-zigpy project.

On one side, we have demonstrated the issue , we have also reported

to sqlite-amalgamation ( https://github.com/azadkuh/sqlite-amalgamation/issues/5 )
to Domoticz https://github.com/domoticz/domoticz/issues/4312

Unfortunately this issue required much more skills on compilation/linking ... than the python skills and the willingness to move forward

Without anymore support, I'm afraid that I'm on a deadlock

[Gamester17]

Reply to post from other thread Subject: Zigbee2Tasmota

It's s shame that the zigpy library could not be integrated which may be a good way to integrate zigbee within domoticz. I saw the discussion about an obscure crash related to sqlite3 usage, maybe i'll take a look closer to see if i can think about a elegant solution about dynamic /static linking against the sqlite3 library.

@dgrostoto it now sounds as if there might have be some progress on that topic in here(?) -> https://github.com/domoticz/domoticz/co ... 8740d5d4eb

[Gamester17]

Jeedom Zigbee plugin is another Zigbee application implementation now publicly released that depends on the Zigpy libraries.

Tip! Check out Google translation of the linked announcement blog post from French to English -> https://translate.google.com/translate? ... el-zigbee/

Much more information about this new zigpy based plugin and links posted here -> https://github.com/zigpy/zigpy/discussions/725

FYI, just read the news that Jeedom Official Zigbee Plugin based on zigpy have now been listed as "stable" and as such is no longer in "beta":

https://blog.jeedom.com/5183-tout-ce-qu ... el-zigbee/ <- **This announcement blog post is really a great read!**

https://market.jeedom.com/index.php?v=d ... ay&id=4050

https://doc.jeedom.com/en_US/plugins/au ... ol/zigbee/

"_The Zigbee plugin for Jeedom builds on the excellent work done around the open-source Zigpy library to offer a general compatibility with different Zigbee hardware. It allows communication with the following Zigbee controllers_"

https://doc.jeedom.com/en_US/plugins/au ... /changelog

https://community.jeedom.com/t/plugin-o ... gbee/58321

https://community.jeedom.com/t/plugin-zigbee-beta/40301

https://community.jeedom.com/t/plugin-z ... abla/53420

https://community.jeedom.com/tag/plugin-zigbee

@zoic21 Any idea if and when the source code for that zigpy based "plugin-zigbee" for Jeedom will become available in a public repo?

https://github.com/jeedom

https://github.com/jeedom/zigpy

i.e. https://github.com/jeedom/plugin-zigbee now leads to "404 page not found message" while other plugins have public repos.

PS: Downside to that "official" Jeedom Zigbee plugin is that they charge for the plugin and therefore they chose not to publish the source code for it on their public GitHub, but that plugin is still open source however you need you to buy the plugin from the Jeedom Market and install it to get access to the code (as it is Python the code will be available as the application in the installation directory). This choice to not host the implementation application source code of the plugin in a publically available GitHub repository obviously makes it harder to collaborate with Jeedom developers, though maybe not impossible, at least the code is available to those who bought it so should not violate the GPL license.

[pipiche]

I do not really see where is the issue. Do you miss some functionalities from the mqtt1zigbee, deConz and ZiGate plugins ? Is there any particular devices which currently are managed under zigpy and not by those 3 plugins ?

I just have a bad feeling as the quirk are still focusing on ZHA , and for instance even doesn't want to change their names to become a more open minded one.

[pipiche]

to come back to the previous post on Jeedom zigpy, for having the source code, I think it is a pitty that the zigpy code is not fully used and indeed Jeedom is redoing a lot of work as regards to Device on boarding.

I have spend the week to get zigpy moving on the device on boarding , but unfortunately they are reluctant , which I could understand as it will obsolete some part of the ZHA code.

So for me the Zigbee Domoticz eco-system is pretty good and zigpy in the current context will not provide any benefits as this will represent a lot of rework.

Just hope that they will reconsider it, last year I was mentioning some weaknesses that they finaly implement.

So let see how it evolve