Home Assistant founders believe there is currently around 50,000 installations of ZHA integration, what do you Zigbee users in the community think about those statistics?

Ah, haha! For me, it was more my principles against vendor lock-in and preferring the idea of a modular architectural design that ZHA achieves indirectly by using zigpy which has separate radio libraries.

I do wish however that the ZHA integration itself was made more modular using a client-server model similar to the new Z-Wave JS integration so could have the option to run the ZHA component as an stand-alone application server on a dedicated computer and then perhaps even be able control that from other front-ends.

That way my Zigbee network wold continue to be up and running even when the Home Assistant core appplication is down. That is where Zigbee2MQTT still has a major advantage over ZHA in my opinion.

2-years ago Zigbee2MQTT was way more popular than ZHA, and today they both have much more users than either of them did back then, though ZHA has probably taken on more new users than Z2M.

Support for the cc2531 in ZHA has been added in 0.106. I was using the CC2530 already a long time then with Zigbee2MQTT.

Yes, ZHA initially only supported EZSP (Silicon Labs) via bellows, then parts of it were split to into zigpy to add support for additional radio libraries. After that it first got the zigpy-cc radio library for Z-Stack 1.2 (for CC253x) and then later it got the zigpy-znp which initially only came with Z-Stack 3.x support (for CC26x2/CC13x2). Then for a while, both zigpy-cc and zigpy-znp supported all Z-Stack versions, but more lately zigpy-cc was made obsolete and recently it was removed completely.

Interesting. Of course it could be that people who use the app generally have it on multiple devices. Each family members’ phone, and maybe a kiosk device in the home.

I never found the need for the app. I don’t do presence detection and the web site works fine for me. It’s possible there are others like me, which would skew the numbers the other way. But no matter which estimates you use, there are a LOT of HA users!

My experience exactly. I tried it. It works, and it’s native to HA. It’s really the only integration I’ve used which required no setup, no learning curve, no configuration, no firmware updates, no router changes. I’ve seen no breaking changes with it in years. It’s been totally plug-and-play. What’s not to like?

I use zigbee2mqtt because I have a Hampton Bay Fan that works better with it - the fan has 4 speeds and a breeze mode which are controllable in zigbee2mqtt, but in ZHA the slider only controls 3 of the speeds. I also found the dashboard of zigbee2mqtt allows for more customization of the settings. If it wasn’t for the fan though I probably would have went with ZHA because it was easier to setup being included right in Home Assistant.

I don’t use the addon zigbee2mqtt though and run it through docker. The devices then just pull in through the MQTT integration. I’m probably in the minority of users that run it this way, but I would think the analytics would have trouble capturing me as a zigbee user with this setup.

It is the same for us, we don’t use the HA mobile app (and I use other methods for presence detection).

We instead all use the “Google Home” app since it’s easier for me to support as other friends and family members who don’t use Home Assistant have other home automation stuff working with Google Home.

Totally agree that ZHA’s “it just works” approach is a great entry point for any Home Assistant beginner.

…though I think more “it just works” and “plug and play” features could make entry to it even easier. Ex:

1 Like

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.