Also for reference, the history behind the current longer integration/component name of “Zigbee Home Automation” and “ZHA” actually came from one of the old Zigbee 1.2 application profiles specifications which had/has an application profile that was called “Zigbee Home Automation” (or specifically “Zigbee Home Automation 1.2”) which is/was abbreviated as “ZHA” in the code and was at the time then used up by the original developer of Home Assistant’s ZHA integration as a name when it again at that time the only supported application profile, but that is not really valid any longer as Home Assistant’s ZHA integration now also support many other Zigbee application profiles that are included in the newer Zigbee 3.0 standard.
ZWaveJS being renamed makes sense, because ZWaveJS is the server - it’s the only supported way to use ZWave since OpneZWave was deprecated.
With Zigbee though, there are a number of options for using Zigbee, and unlike ZWave where the ZWaveJS server actually handles talking to the stick, and the integration options all communicate with the ZWaveJS server to work. With Zigbee, each add-on talks directly to the Zigbee radio, there is no middle man.
Eg - I use Zigbee2MQTT on a remote Pi, so all my Zigbee stuff just appears in Home Assistant under MQTT.
I think that ZHA naming should be changed for the exact same reasons that Z-Wave JS was changed.
While it is true that end-users do have many other options via alternative indirect ways to get Zigbee devices into Home Assistant, and the exact same goes for Z-Wave, however as far as I know, there is only the one native Zigbee implementation exclusive to Home Assistant that does not use some kind of middleman implementation(s), as all the others are integrations are for third-party (non-native) Zigbee gateways/hubs/bridges/applications that actually abstract Zigbee behind different third-party interfaces meaning they are middlemen that then use abstraction layers and APIs for integrations that could really also be used to present any other type of devices that do not necessarily need use the Zigbee protocol, (and while not all do, some do in fact also present non-Zigbee devices through the same API, including Z-Wave, Bluetooth, and Wi-Fi devices).
So yes I am aware that; there are for example; Philips Hue, SmartThings, IKEA TRÅDFRI, Tuya, Xiaomi Gateway (Aqara), deCONZ (Phoscon), Zigbee2MQTT, (or others via MQTT and HomeKit capable gateways/hubs/bridges/applications), etc., can also present Zigbee devices to Home Assistant, however as far as Home Assistant is concerned they could in turn also be abstracting devices that use any other protocols behind their interface, and many of those do that, plus being third-party (non-native) Zigbee gateways/hubs/bridges/applications as they are, not any of those are exclusive to Home Assistant.
When devices proxy through a third-party gateways/hubs/bridges/applications then it does not matter to Home Assistant which protocol each device that hides behind the integration you use actually uses.
By the way, I personally think Zigbee2MQTT is great, however, it is still not even listed on the official integration list so you either have to add via MQTT or install add-on via HACS → https://www.home-assistant.io/integrations
Support confusion do not differ for Z-Wave as you will always need to ask exactly which integration user use as there too some will instead of the native integration for example connect their Z-Wave devices via; SmartThings, Telldus, Z-Wave.Me, Fibaro, Leviton Z-Wave, Somfy, or other third-party gateways/hubs/bridges via MQTT and HomeKit capable gateways/hubs/bridges/applications), etc…
Specifics when in comes to which integration is used will remain important; e.g.
Forum user 1: “My Z-Wave devices aren’t connecting”.
I think that having the existing integration called “Zigbee Home Automation” or “ZHA” is also confusing.
Simply assume just “Z-Wave” always mean Z-Wave JS and just “Zigbee” always mean ZHA in context.
Just see how “Add Z-Wave device” and “Add Zigbee device” is in there at the top in the UI now when click “+ ADD INTEGRATION” in UI if the user have already installed Z-Wave JS and ZHA integrations.
It all makes sense to me when thinking about idea of “streamlining experiences” means for new users.
I might be biased since I originally migrated from using the Samsung SmartThings Hub which since many years back has a similar setup to Home Assistant integrations where their official SmartThings hubs can natively support connecting directly to many Zigbee, Z-Wave, Bluetooth, and Wi-Fi devices while still also support connecting indirectly by integrating to a few other ecosystem platforms via their third-party gateways/hubs/bridges, such as example Philips Hue Bridge and IKEA Tradfri Gateway.
Yeah that’s a big “no” from me too, it’s not the only ZigBee option as said above, only adds more confusion and then the “zha” abbreviation also doesn’t make sense, what’s it a 3 letter abbreviation for?
I don’t use zha for my ZigBee devices, I’m sure that the only “yes” votes for this will come from zha users
I’ve had the same thought myself, so a big “yes” from me.
I totally agree the “HA” part of ZHA makes no sense. It never did. I can’t imagine why it was added.
If it means “Home Automation,” well, Duh. Everything we’re doing is home automation.
We don’t name other integrations with an acronym ending in the “HA” suffix. Why just this one?
Same argument if you say it stands for “Home Assistant.” No matter how I look at it, this acronym is the outlier and doesn’t make any sense in the context of all the other names we use.
Zigbee to MQTT (Z2M) is a separate thing. To HA, the data is just MQTT. ZHA is a native integration to HA.
The analogy of Z-Wave is a great example. I don’t know if there’s a Z-Wave to MQTT option available, but if so that wouldn’t be an argument for changing the Z-Wave integration to an acronym ending in “HA.”
Maybe this isn’t an urgent issue. But neither are all the other recent UI changes. The goal is to make the user experience streamlined, logical and easy to grasp. When looking for the native Zigbee integration, I should see that word, not an acronym. Especially not one that’s inconsistent with the naming of all the other integrations.
Right but the argument is that ZHA is the only ZigBee integration in the list. But that’s not true - search for Deconz in the integration list - and then you’ll understand. Both Deconz and ZHA are popular ways of interacting with ZigBee, and Deconz is in the official add-on store - so it’s not like it’s difficult for a new user to end up using Deconz
That is a long history lesson in itself which goes back to when the Zigbee Coordinator USB adapters were commonly available on the market used an older Zigbee stack in its firmware that did not support the new Zigbee 3.0 standard (like for example the now legacy CC2530/CC2531 based adapter with “Z-Stack Home 1.2” firmware) because they older revisions of the Zigbee PRO specification at that time did not use one common application layer and instead was split into many different Zigbee application profiles (device type profiles if you will) that was purposely designed to be used in specialized types of industries and there was originally only of those Zigbee application profiles that were specifically designed for consumer home automation.
That is, the ZHA integration originally just got its name because when the ZHA integration was actually first created it initially only supported the “Zigbee Home Automation 1.2” application profile (device profile) which is just one out of several Zigbee sub-specifications in the Zigbee standard, but nowadays if you use a Zigbee Coordinator with Zigbee 3.0 NCP firmware then the ZHA integration also supports most of the old Zigbee application profiles (device profiles) as well as the latest Zigbee 3.0 profile, so even if that ZHA name once made sense it does no longer make in the UI.
Also for reference, the history behind the current longer integration/component name of “Zigbee Home Automation” and “ZHA” actually came from one of the old Zigbee 1.2 application profiles specifications which had/has an application profile that was called “Zigbee Home Automation” (or specifically “Zigbee Home Automation 1.2”) which is/was abbreviated as “ZHA” in the code and was at the time then used up by the original developer of Home Assistant’s ZHA integration as a name when it again at that time the only supported application profile, but that is not really valid any longer as Home Assistant’s ZHA integration now also support many other Zigbee application profiles that are included in the newer Zigbee 3.0 standard.
Zigbee 3.0 unites most (but not all) of the previous different Zigbee application profiles when they updated Zigbee PRO stack specification to Revision 21 (i.e. “Zigbee R21” stack, also known as “Zigbee Pro 2015”) they actually included a requirement to support all the previous Zigbee profiles, with the exception of the profile for Zigbee Smart Energy (ZSE, also known as “Zigbee SE”.), as well as added the new Zigbee 3.0 profile.
Zigbee 3.0 (ZB3), which today is more commonly known as just “Zigbee”.
Zigbee Home Automation (ZHA), also known as “Zigbee HA”.
Zigbee Light Link (ZLL), also known as “Zigbee LL”.
Zigbee Green Power (ZGP), also known as “Zigbee GP” or “Zigbee GreenPower”.
Zigbee Remote Control (ZRC), also known as “Zigbee RC”.
Zigbee Building Automation (ZBA), also known as “Zigbee BA”.
Zigbee Retail Services (ZRS), also known as “Zigbee RS”.
Zigbee Health Care (ZHC), also known as “Zigbee HC”.
Zigbee Telecommunication services (ZTS), also known as “Zigbee TS”.
Products with firmware that use the old Zigbee application profiles are today referred to as “Legacy Devices” and products that use the old Zigbee application profiles can still join a Zigbee 3.0 network as such but do not get any of the benefits of Zigbee 3.0 which other than unifying the different Zigbee application profiles also adds much better security.
Other than the exception of Zigbee Smart Energy (ZSE) which is not part of the Zigbee 3.0 standard, also note that Zigbee Green Power (ZGP) is the only profile that should be a part of Zigbee 3.0 that Home Assistant’s ZHA integration is still missing because support for Zigbee Green Power (ZGP) has not yet been implemented in the zigpy library that it depends on, however, that is separate off-topic discussion but more information can be found here → https://github.com/zigpy/zigpy/issues/341
Interesting! Thank you for the history lesson. I always like to hear how things developed from the beginning.
It also bolsters the argument that it’s time to move beyond past names which are no longer meaningful and streamline this integration’s name to better reflect how people use and reference it today.
By the way, In related news noticed that forum moderators just now removed the whole ZHA subforum and migrated all the threads/posts into the main Zigbee subforum:
Voted yes too. The “HA” in the “name” doesn’t help to distinguish it from the others which already have completely different names. It just adds confusion and redundancy.
There are so many aspects of Home Assistant that exist in a certain way because “that’s the way it’s always been” - but I’m happy to see that so many are being revisited to be refactored in a way to make them more accessible, intuitive or simply more functional.
As well see that the Zigbee brand logo “zigbee” is also for that even if it says “Zigbee Home Automation”, and notice there that highlight frontpage for integrations also shows Philips Hue which as you probably know is for their external third-party bridge/gateway/hub Zigbee capable, just as deCONZ/Phoscon and Zigbee2MQTT are other external third-party bridges/gateways/hubs that are Zigbee capable:
Bump this as more people are posting every day in the Zigbee forum about problems with Zigbee devices instead of third party integrations when they have issues with XYZ gateway/bridge/hub/controller (like ex. Philips Hue Bridge, IKEA Trådfri Gaterway, Samsung SmartThings Hub, or Zigbee2MQTT), and not even actually using the ZHA integration.
That is, people there are confusing any generic Zigbee solution with the built-in ZHA integration today:
Descrptiopn makes it more confusing: “This section is dedicated to all topics around Zigbee/ZHA”:
openHAB also has other Zigbee add-ons like deCONZ, so the reasoning that there are also other integration in Home Assistant for Zigbee devices is why we need to have “home automation” suffix for Zigbee integration is not convincing in my opinion.
