Indeed. Multiple HA instances, 0 App installations.
1 Like
I think the opposite is also true. For example I have one HA installation and multiple app installs for different family members.
On the topic of zigbee, I have found Z2M very reliable and not tied to updates of HA. I prefer the separated architecture. It’s for the same reason that I use zwave2mqtt as well.
1 Like
You bring up a good point. Although for me, ZHA has been working flawlessly, there are other integrations I’ve wished weren’t coupled with the base HA updates. Sometimes a new version can introduce some features you want, but a bug in some key integration you need. You’re stuck, unable to update anything until the developer of the failing integration gets around to rolling in the fix. If the bug only affects a portion of the users of that integration, it may be low on the priority list.
I submitted a feature request to allow integrations to be updated (or not) independently of the core HA.
Feel free to up-vote this feature request if you agree.
1 Like
FYI, it looks like ZHA developers started working on a zha-websocket-server and HA Addon for ZHAWS:
https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws/homeassistant/components/zhaws
https://github.com/zigpy/zha-websocket-server
https://github.com/zigpy/zhaws-addon
I have not read any news about this but it seems to indicate that the ZHA component might get broken out of Home Assistant’s core. If so guessing it will mimic client-server model architecture of Z-Wave JS?
https://github.com/home-assistant/core/tree/dev/homeassistant/components/zwave_js
https://github.com/zwave-js/zwave-js-server
https://github.com/home-assistant/addons/tree/master/zwave_js
https://github.com/home-assistant-libs/zwave-js-server-python
zha is at least one of the most popular integration components integrated into Home Assistant’s core:
https://analytics.home-assistant.io/#integrations
https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha
Hopefully, that will mean that will later be able to choose if and when to upgrade the server part of ZHA?
Btw, here is an architecture discussion → Decouple integration releases from core · Issue #202 · home-assistant/architecture · GitHub
Same here. When I was doing my original research I chose ZHA because of the core support, and my goal was stability over additional features. My goal (which I achieved) was to go 6+ months without tinkering or fixing. Maybe z2m could allow that, but I assessed core Nabu Casa full-time dev support as superior.
I’m into year three with my ZHA implementation. It’s the only thing in HA I’ve never had to mess with. It just works. I don’t currently use MQTT and really don’t want to add another layer I’d have to support.
2 Likes
Those will not add an MQTT layer to ZHA, just WebSocket server and client for tunnelling over TCP/IP.
https://github.com/home-assistant/core/tree/dev/homeassistant/components/zwave_js
https://github.com/zigpy/zha-websocket-server
https://github.com/zigpy/zhaws-addon
Breaking out some pars of ZHA and moving to WebSocket server and client would not only allow it to be updated separately from Home Assistant’s core but also allow running ZHA on a separate computer.
https://en.wikipedia.org/wiki/WebSocket
https://en.wikipedia.org/wiki/Client%E2%80%93server_model
This client-server model concept is also known as a “distributed computing” or “distributed system”:
https://en.wikipedia.org/wiki/Distributed_computing
" Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. The components interact with one another in order to achieve a common goal. Three significant characteristics of distributed systems are: concurrency of components, lack of a global clock, and independent failure of components. It deals with a central challenge that, when components of a system fails, it doesn’t imply the entire system fails. Examples of distributed systems vary from SOA-based systems (service-oriented architecture) to massively multiplayer online games to peer-to-peer applications."
https://en.wikipedia.org/wiki/Service-oriented_architecture
“In software engineering, service-oriented architecture (SOA) is an architectural style that supports service orientation. By consequence, it is as well applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.”
PS: Such models could in theory also allow other third-party apps to use/control ZHA WebSocket server, as similarly, Z-Wave JS WebSocket server allows many different UI clients to connect / control it.
FYI, just now noticed ZHA integration hit 15% of HA’s userbase and as such made Top-10 for first time:
https://analytics.home-assistant.io/#integrations
I think that is a quite significant percentage growth in 4-months as up from 13% 16th November 2021:
Thanks! I hope this sends a message: Don’t mess with ZHA!
Looking at the big picture, there are three main protocols to choose from for end devices: IP, Z-Wave and Zigbee. I’ve already crossed IP-based devices off my list. They’re too much hassle. Static addresses, proprietary vendor cloud solutions which change with the winds, network design issues, etc. Z-Wave looks nice but I’ve already invested in Zigbee.
Much has been said about Zigbee to MQTT. It sounds like that’s been a great solution for some users, and I won’t argue with that. But it’s yet another layer on top of HA. Another component I need to install, maintain, and worry about with every version update.
Not sure if all are new users of it users are migrating from some other integrations with Zigbee capable bridges/hubs/gateway/controllers but FYI these others can also abstract/hide Zigbee devices and users;
- Zigbee Home Automation at 15.6 % (17838 installs of those who chose to opt-in for analytics)
- Philips Hue at 15.8 % (18158 installs of those who chose to opt-in for analytics)
- deCONZ at 5.7 % (6563 installs of those who chose to opt-in for analytics)
- IKEA TRÅDFRI at 3.3 % (3785 installs of those who chose to opt-in for analytics)
- Xiaomi Gateway (Aqara) at 2.1 % (2410 installs of those who chose to opt-in for analytics)
- Xiaomi Miio at 9.5 % (10818 installs of those who chose to opt-in for analytics)
- Tuya at 14.9 % (17068 installs of those who chose to opt-in for analytics)
- SmartThings at 3.7 % (4211 installs of those who chose to opt-in for analytics
- Amazon Alexa at 12.6 % (14384 installs of those who chose to opt-in for analytics)
Also, Zigbee2MQTT usage in Home Assistant is probably not possible to get from analytics today since abstracted behind MQTT and that can also be by many other integrations and devices as well. MQTT is today used by 38.7 % (44309) of active installations who chose to opt-in for Home Assistant analytics.
There is no doubt overlap between the users as well.
I started with ZHA, but moved my last device to Z2M a couple days ago. I will continue to leave my ZHA stick installed and active, so will show in both columns.
Very hopeful to see that ZHA integration is now close to overtaking Philips Hue integration in popularity:
https://analytics.home-assistant.io/#integrations
- Zigbee Home Automation at 15.8 % (18703 installs of those who chose to opt-in for analytics)
- Philips Hue at 15.9 % (18879 installs of those who chose to opt-in for analytics)
The ZHA integration has in 45-days got another 865 installs with analytics opt-in enabled, and during those same 45-days the Philips Hue Bridge integration has only gotten another 721 installs with opt-in
If a similar trend continues then can predict that ZHA will probably have more installs by August 2022.
Though it can be noted that ZHA might not take 10th place then before the Tuya integration overtakes it.
Thank you for the update. Good to see ZHA is still getting some love.
I’m a bit uneasy about using these statistics however. Every app has core functions which need to work natively, even if there are other things which gain popularity. In the case of HA, I think those things include the three basic smart device protocols; IP, Zigbee and Z-Wave. Z2M is great for people who already use MQTT, or who want to try it out. But it shouldn’t be required just to get HA to talk Zigbee.
This isn’t idle speculation. HA is marketed as easy to install on a Raspberry Pi. One of the core functions of the RPi is its GPIO pins. HA dropped native support for GPIO pins with the justification that there weren’t enough people using them. When challenged, the developers walked that back and came up with other excuses. But that’s where the discussion began, and we know those numbers ARE looked at.
I’d hate to see HA become something different because of a focus on the popularity of add-on features, at the expense of core functionality.
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.
1 Like
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
2 Likes
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.