Zigpy developer(s) begun work on external zha library to allow for stand-alone implementations

Configuration Zigbee
,
1

For your information; it looks like a zigpy developer now started work on an breakout external zha library (as a Zigbee Gateway class library) splitting the the ZHA integration into internal and externals parts (i.e. the built-in native Zigbee gateway implementation for Home Assistant) which could potentially also allow for stand-alone versions:

https://github.com/zigpy/zha (see zigpy/zha#6 if want to get an developers overview)

And this matching fork of a new ZHA integration component for Home Assistant broken out and using said stand-alone and external implementation of “ZHA Gateway”:

https://github.com/dmulcahey/home-assistant/tree/dm/zha-external-zha

Note! It is very much a work-in-progress. Initial port seams done but “things will be broken for a while”.

Still it looks like they have come along far with this new concept, and looks initially to be a forked and restructured variant of Home Assistant’s zha component that is converted into a standalone program:

https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha

For reference; the ZHA integration depends on libraries from the zigpy project but the Zigbee gateway implementation that is the is ZHA integration is today a built-into Home Assistant core, which means it can not be updated or maintained separately and it stops running when to stop or restart the Home Asistant core.

I guess this idea to split out the ZHA component from Home Assistant core has grown from a previous concept that the same developer(s) began working on couple years ago with a zha-websocket-server and zha-ws client addon/plugin for Home Assistant.

zigpy/zigpy#1207

https://github.com/zigpy/zha-websocket-server

https://github.com/zigpy/zhaws-addon

https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws

https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws/homeassistant/components/zhaws

I assume the goal will to breakout the zha component from Home Assistant core and make it an external Zigbee gateway application that can be updated separately from Home Assistant core and in theory also enable it to be used as a stand-alone and/or external version of ZHA as Zigbee gateway implementations by others in other third-party projects which then could make their own integrations and/or different UI frontends for that stand-alone version of zha, (probably accessed via websocket).

As splitting the Zigbee gateway application implemnentation part in the zha component away from the Home Assistant core will allow you to run “ZHA Gateway” externally, either as an addon or even stand-alone on a different computer, with it only communicating with the new ZHA integration in Home Assistant using websocket (which can be done over a local network). Today this is probably the most common argument why you might still want to recommend Zigbee2MQTT instead of Home Assistant’s built-in native ZHA integration to a brand new Zigbee user (as Z2M and ZHA today otherwise compare equally in features and functions).

Another bonus is that it could potentially in the future also eanble users to have multiple instanses of external ZHA Gateway servers (each with its own Zigbee Coorinator radio adapter only controlling its own seperate Zigbee network), allowing users to for example have a “production Zigbee network” and a “test Zigbee network” (to seperate the testing of new and troublesome Zigbee devides).

PS: If this case the result will likely become very similar to the “Z-Wave JS” (node-zwave-js) project which uses a similar client–server model (also known as “frontend-backend model”) distributed application structure architecture for its different implementations which depends on an addon (plugin) and external server program that can also be used as a stand-alone application. For reference check out the Z-Wave JS integration and related projects :

https://www.home-assistant.io/integrations/zwave_js/

https://github.com/home-assistant/addons/tree/master/zwave_js

https://github.com/zwave-js/node-zwave-js

https://github.com/zwave-js/zwave-js-server

https://github.com/zwave-js/zwave-js-ui

5 Likes
2

Well that’s awesome!

3

UPDATE: FYI, it sounds as if ZHA/zigpy developers are making progress and are almost ready to implement the first phase which is to split ZHA core out of the ZHA component core in the Home Assistant Core in order to separate ZHA as an external library, which once merged is also something that should make it easier for new/more developers who might want to help with the development of the ZHA integration:

Check out this initial pull request and description of the proposed change:

Proposed change

Today, ZHA is the largest integration in terms of lines of code (33% larger than the second-largest, MQTT). Chart showing how ZHA dropping from the number one integration in terms of lines of code to about number ten:

image
image1979×1180 217 KB

dmulcahey, TheJulianJES, and puddly have spent a long time migrating the core logic of ZHA into a self-contained library. The end result is huge improvement in terms of code quality in both the Home Assistant half and the library half. With this change (and others in the future), we aim to make ZHA reusable outside of Home Assistant, easier to understand, and pave the path to a more streamlined model for contributing device support code to ZHA and Home Assistant (when necessary).

There should be no functional changes with this PR: everything is intended to work exactly as it did before.

This is an initial pass and we aimed to modify as little as possible in this split. You will notice that the terminology currently in use within the library (and thus the rewritten integration) mirrors that of Core. This is intentional and will diverge as we see fit.

4

FYI, Home Assistant Core developers have now that merged that initial PR that split and moves ZHA into an external library:

While ”zha core” will still keep Home Assistant cutomizations so development for that continue in Home Assistant Core, but you can now follow ZHA library development in the GitHub repository for that new external ZHA library:

1 Like
5

FYI, it looks like changes passed beta-stage and will be included in Home Assistant 2024.8 release:

"The Zigbee Home Automation (ZHA) integration has seen lot of improvements and love from @dmulcahey, @puddly, and @TheJulianJES this release.

What this means for you? Well… basically nothing! And this sounds odd, but is is a good thing!

The whole integration has been split into a separate codebases, making it easier to maintain and improve. This is a huge step forward for the integration that took months of work to get done.

You will not notice anything different right now, but this change will make it easier to maintain and improve the integration in the future, including the ability for code contributors to contribute to the integration more easily."

Again, this new external “zha” library is designed to be a higher-level Zigbee Gateway library (which on turn depending on the other lower-level zigpy libraries), and is as such meant to help streamline both zha development and make easier for new developers to contribute higher level functions to the zha and zigpy projects without having to learn all the underlying code.

This new external zha library is also not only meant to be used by application-level implementions such as the Zigbee Home Automation integration) in Home Assistant. It can potentially potentially also be used by other projects or could even be used in a stand-alone Zigbee Gateway application (similar in the architecture to that of Zigbee2MQTT)

Back-story is that this new zha class library started as an initial migration of the core logic from ZHA integration to breakout and move the Zigbee Gateway part away from the zha intégration component inside Home Assistant’s core repository into a self-contained external library.

The end result of this split (and other further changes to come) should be a huge improvement in terms of code quality in both the Home Assistant half and the library half of zha.

The ultimate goal of having zha as a separate library is to eventually make ZHA reusable outside of Home Assistant, easier to understand, and pave the path to a more streamlined model for contributing device support code to ZHA and Home Assistant (when necessary).

Note that this is an initial pass where the aim was to modify as little as possible in this split. Future changes will hopefully enable zha to work with other stand-alone applications as well.

You will notice that the terminology currently in use within this new external zha library (and thus also the rewritten ZHA integration) mirrors that of Home Assistant’s Core. This is intentional and will diverge as we see fit.

1 Like
6

FYI, this major underlying change to ZHA architecture made it into Home Assistant 2024.8 release so be aware that it is possible this change broken some stuff in ZHA even though it should not do so by design.

So if you see any new problems with ZHA specifically in the Home Assistant 2024.8 release that was not a problem in the Home Assistant 2024.8 release then I would highly recommend that you guys open a new issue for the ZHA integration in the Home Assistant core repository on GitHub and repost same there in more details with debug logs + diagnostics for better tracking, see:

Probably better safe than sorry when this change to underlysing ZHA architecture was so huge :wink: