FYI, ZHA developers are also working on separating the ZHA component from Home Assistant core in order to make it more flexible and modular to allow separate updating/lifecycle from Home Assistant core. That implementation will use similar websocket interface and addon as the Z-Wave JS integration:
https://github.com/zigpy/zha-websocket-server
https://github.com/zigpy/zhaws-addon
FYI, you can still use Raspberry Pi GPIO header as a serial interface for Zigbee and Z-Wave adapters.
I shouldn’t have used the phrase “core functionality” in relation to HA, where the word “core” means something different. I’m all for making things more modular. I think all integrations which support external hardware should be separate, and updated outside the core HA update cycle. One time I couldn’t update HA for two cycles because a core integration I depended on was changed and that change introduced bugs.
What I meant was that HA devs need to prioritize maintaining key functionality, even if that’s not as exciting as developing new, flashy features. My concern was that ZHA become one of those boring maintenance jobs that nobody wants to work on, and pressure builds to abandon it.
Which is why I mentioned the GPIO integration. It was sort of kicked to the curb by the dev team, and it is only because someone who needed it, and who had the skill to do so, took over support that it’s still even available. I use it now, and I’m very happy that it’s not part of the HA “core” any more. I just hope it, and ZHA, and all the other foundational elements of HA, remain well supported.
Going this route makes sense, as they did it for zwave, but I could see it causing some heartburn for some who appreciate the ease of the current setup of zha.
There’s been some frustration from openzwave users who recently had to move to the zwavejs addon. Hopefully there would be some “conversion wizard” that could help with this potential zha migration to make it as smooth as possible.
Also, for core/container users of homeassistant without access to the addons, would there be consideration for a standalone, “non-addon” zha in docker, similar to zwavejs2mqtt?
I guess I should enable to analytics if it helps the devs.
ZHA works fine most of the time. I think my only issue is some devices may be too far from my USB stick, but other than that I have no issues at all.
FYI, Home Assistant founder Paulus Schoutsen mentioned in a recent Home Assistant 2022.4 Release Party video that they are considering aiming to get Home Assistant both Z-Wave certified and Zigbee certified (and also Matter over Thread certification in the future), so if and when they decide to set such a goal for sure then they will need to choose which one Zigbee implementation solution to certify for it.
As I understand it both Z-Wave and Zigbee certifications require that you certify the whole chain as one complete solution including UI and all dependecies as a whole gateway experience, which I think must mean either certifying Home Assistant with either ZHA or Zigbee2MQTT;
Home Assistant as application → ZHA integration as Zigbee gateway (with zigpy libs as dependencies)
or
Home Assistant as application → MQTT → Zigbee2MQTT Addon → Zigbee2MQTT as Zigbee gateway
If that is certified then removing or changing any component means having to recertify whole solution.
So it will either be “Home Assistant powered by ZHA” or “Home Assistant powered by Zigbee2MQTT”.
I believe that ZHA has a head start there as natively and tightly integrated into Home Assistant and I understand that zigpy is more designed to comply with the latest official Zigbee specifications.
That question would better asked to ZHA devs here - > https://github.com/zigpy/zigpy/discussions
Interesting, thank you for the heads-up.
I agree that ZHA is the natural choice to start this certification process, for all the reasons you explained. My fear is that we tinkerer types tend to prefer more complex (and hence, more fragile) solutions. Going down the wrong path with certification may backfire.
I have nothing against Z2M. By all accounts, it’s a great solution for lots of people, and in some ways more functional than ZHA. But for those of us who don’t need the extra functionality, don’t already need MQTT for something else, and don’t want to take the maintenance and performance hit of installing yet another component, having a Zigbee solution that’s native to HA is ideal.
I think it makes HA more competitive in the marketplace of home automation systems.
Discussion about certification of Z-Wave and Zigbee (and Matter) start at around 32:35 minutes in here:
https://www.youtube.com/watch?v=wOrJUWYYWdY&t=1955s
Yeah I think that with official Home Assistant Yellow hardware coming and part of the streamling concept the Home Assistant founders are striving for new users to be able to walk into retail electronics stores and buy an Home Assistant appliance similar to how beginners can buy a Philips Hue Bridge today.
https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/
https://www.home-assistant.io/blog/2022/01/19/streamlining-experiences/
I guess goal is to at least compete with commercial gateways like SmartThings hubs and Athom Homey.
Do you ever think we’ll see that day? I’ve made peace with the fact that I have to spend many hours every week tweaking HA, adding functionality, updating, backing out updates, learning new YAML constructs, changing things around in response to breaking changes and scanning these forums to learn about new, ongoing and upcoming problems.
I’m not complaining. Home automation is just such a dynamic environment I can’t see HA ever getting to a “set it and forget it” stage. Remember when there was talk about a “Version 1?” We’ve apparently given up on that idea. There is no destination. It will always be a journey.
HA in its current state is a hobbyist product.
HA would be a support nightmare as a “retail” product, if by “retail” you mean an average consumer walking into a Best Buy, Home Depot, etc and grabbing a Yellow box off the shelf.
They tried that with zwavejs and it’s success was, let’s say…limited.
I would be surprised if a ZHA migration tool would be much better.
I do like the idea of a separate websocket driven zigbee solution like zwavejs.
The biggest issue I have with moving to zigbee2mqtt is that they don’t support my zigbee stick (hubszbz-1).
And even if it did it would better to support websockets and not only mqtt.
I don’t really ever have any issues with ZHA tho.
They’ll have the advantage of it being the same code base instead of reinventing the wheel. For all-on-the-same-box installs, it should be a transparent process if the internal APIs are sane.
It’s probably different devs doing that kind of back end work, but if not I’d prefer more focus on the device support side.
Yes I definitely just have more questions then answers on this. I watched the video and they talk about zwave and matter certification for Home Assistant. My understanding of those standards are they are device/hardware standards. Since Home Assistant is open source software that can run on any hardware, with other integrated zwave/zigbee open source software that can run with any number of zwave and zigbee sticks/hubs, I’m not sure what exactly is getting certified. Are they trying to certify the Home Assistant Yellow (or similar) hardware device? If so that would make more sense to me.
Yes, that definitely did not go smoothly. Hopefully any potential conversion would work better though because you would be going from ZHA in core to ZHA in an addon, so it would be the same code base at least. Automating the conversion from openzwave to zwavejs was like trying to fit a square peg in a round hole.
My concern though is a user like yourself, on Home Assistant container, and with an incompatible zstick for zigbee2mqtt, could be “left out in the cold” by ZHA going into just a supported addon, without any standalone docker version. I’ve rarely seen an addon that wasn’t available in standalone docker, but there is at least one example with airsonos - AirSonos docker plugin - #12 by frenck - ie someone who wants AirSonos needs a supervised or HAOS install to use it.
FYI, latest official newsletter for Home Assistant has a section about a roadmap to Z-Wave certification:
https://building.open-home.io/why-the-open-home-is-important/
That included link to Z-Wave JS project list on all prerequisite tasks needed before they can certify it:
https://github.com/orgs/zwave-js/projects/1
They also talk more about certification in new Home Assistant 2022.5 Release Party video at 1:44:08
https://youtu.be/HV4D-Fx-mlU?t=6248
Yes and no, or at least kind of. If a Zigbee certificate requires the whole chain including all the individual hardware components to be specified for Zigbee then yes they would need to choose a specific reference hardware platform to certify, like the Home Assistant Yellow or a similar setup as could just as well be a standard Raspberry Pi 4 + a specific brand and model of Zigbee USB dongle/adapter), and if Nabu Casa will be paying for the whole certification process then it obviously makes perfect sense for them to focus on using the Home Assistant Yellow as the reference hardware for Zigbee certification.
Home Assistant Yellow however just contain a standard MGM210P module from Silicon Labs and use a standard EmberZNet Zigbee stack application firmware build on it. That module in turn is based on Silabs EFR32MG21 SoC which is very common and that same firmware can also be built for many other Silabs SoC, and that Zigbee stack is abstracted by the zigpy library anyway, so even if technically not the exact same hardware most users could put together a very similar hardware setup using the most commonly available products, (as zigpy is compatible with most Zigbee adapters/dongles today).
It sounds promising and certification at any level I’m sure will help Home Assistant with marketing/attracting users.
In that video they mentioned zigbee and zwave certification. I know historically zigbee certification was always much loser then zwave certification. I believe many “zigbee certified” devices usually are a self certification. This looser certification has lead to some zigbee products, like many xiaomi devices, not fully conforming to standards and having compatibility issues with other zigbee devices. With zigbee merging with Matter, I’m not sure how it changes that certification process. It looks like with Matter you can actually certify the platform, and I see the EFR32MG21x module on this list already - Certified Products Search | IOT - CSA-IOT
The zwave certification process was always stricter, with licensing fees and needing to send the product for actual testing of the device, with them ultimately deciding to issue final certification approval or not.
I don’t think the Home Assistant yellow has a built in zwave device either, so I really don’t know how that process will work. I would assume the matter/zigbee certification will be much easier to obtain.
Zigbee is not merging with Matter, so Matter existence does not change the Zigbee certification at all.
While the Matter (Project CHIP) standard is governed by the Connectivity Standards Alliance which was formerly the Zigbee Alliance, the Zigbee standard will remain and be kept separate, however unclear if and how it will be further developed in the future. There is no plan for Zigbee and Matter to merge and their protocol specifications even differ so much that it is not really technically possible for them to be merged.
Matter architecture design only takes partial inspiration from the Zigbee Cluster Libary Specification for device classes and attributes for different types of devices but Matter itself is otherwise a higher-level application layer that relies on existing IPv6 support for the communication layers, as such could in theory be made to work over other transport layer media in the future as long as it supports IPv6, though now at the beginning Matter will only include support over Ethernet, Wi-Fi, and Thread (OpenThread via Thread Border Routers as a transport layer gateways/bridges). Noting that as Zigbee does not support IPv6 so can never be supported as a Matter transport layer media.
Thread based Matter products and Zigbee 3.0 based products do however use the same type of radio modules/chips (including Silicon Labs EFRMG2x and Texas Instruments CC26x2/CC13x2), and many companies are still invested in Zigbee and already using compatible chips so we will probably keep seeing new Zigbee 3.0 variants of each Thread based Matter product being released, and vice versa, they will not be a huge amount of effort for a company to make two variant models when the same hardware has the capability of supporting either protocol with just different application firmware, (some Zigbee modules chips even come pre-certified tested and surly the same will also happen for Matter too).
I think that Zigbee certification will probably relativly less strict, but believe Matter certification can be be strict. Do however not confuse Zigbee with Matter or vice versa as other being supported on the same type of chip they really have nothing to do with each other. Again, Zigbee will never merge with Matter.
Home Assistant Yellow do not come with Z-Wave so it will need a USB adapter or GPIO-header serial module, so guess they will use an already certified Z-Wave radio adapter or module. like example: Aeotec Z-Stick 7 USB stick (ZWA010) and Aeotec Z-Pi 7 Raspberry Pi HAT/Shield (ZWA025) Z-Wave 700 Controllers with Z-Wave JS · zwave-js/node-zwave-js · Discussion #2549 · GitHub
I thought with it being run by the same organization there was some plan to merge the zigbee/matter standards together, but that doesn’t seem to be the case. Thanks for the clarifications.
Much faster than expected ZHA integration now has more users than the Philips Hue integration and has thus currently taken 10th place from it, (though both look be overtaken in ranking by Tuya soon:.
It is also worth noting that the ZHA should now with 16.1% of the “opt-in” userbase probably have at least 125,000 installations/users if “opt-in” statistics actually only account for less than 20% of all users.
That is based on “Active Home Assistant Installations” (those who have “opted in” for analytics) have risen to 153,679 according to the statistics. Again that is if Home Assistant founders estimate in their original blog post about analytics still holds true and less than 20% of all users have chosen to electively “opt-in” for analytics in Home Assistant to enable Home Assistant founders to collect statistics.
Update: the ZHA integration is now increased to 17% of the user base over the summer but has been moved down to the 13th position on that chart due to fact they added default internal integrations “Repairs” and “Home Assistant Alerts” to that list.
Well at least ZHA gained around 3000 users over the summer who chose to opt-in for analytics, so guess that the new estimate is now about 139,151 ZHA installations out there today if the guestimate of only 20% of Home Assistant users has chosen to “opt-in” for analysis still holds true.
Wow! The release of the official Home Assistant SkyConnect USB radio dongle has made the Zigbee userbase boom, with the ZHA integration now at 20% and once again again in the Top-10 integrations:
https://analytics.home-assistant.io/integrations/
Today there are 37,862 ZHA integration users who choose to opt-in for analytics, which is almost exactly double the amount of users since just 12-months ago! And with 234,362 Active Home Assistant Installations who opt-in, we can guesstimate that there is probably a total amount of that many ZHA users as well (if we once more assume that only 20% of Home Assistant users have chosen to “opt-in” for analysis still holds true).
In related news, Nabu Casa has recently hired someone to work full-time on the ZHA (Zigbee Home Automation) integration (and its dependencies) for Home Assistant:
https://www.nabucasa.com/about/
PS: Be sure to subscribe to the Home Assistant Cloud service to sponsor their development of ZHA:
FYI, noticed that the rank of the ZHA integration has changed on Home Assistant Analytics as they added a lot of helper integrations and others coming preinstalled when using Home Assistant Operating System, but at least the install base for the ZHA integration has risen and has now passed userbases of ESPHome and DLNA Digital Media Server :
