It would be nice to have only one ZigBee to control them all. Why zigbee2mqtt is not officially “part” of HA same way has zwavejs ?
Zigbee2mqtt is a third party addon, not an integration. It is maintained by a third party developer. They have shown no desire to have it included in the community or core addons.
ZHA is the core integration.
It is nice to have choice available.
4 Likes
Calling it no desire would not be fair, given that it is independent of home assistant, there is also no need to merge into HA. Moreover, ZigBee2mqtt is mainly running on node, contrary to python for HA, it would require lots rework. And then, we will have another zha inside home assistant with no benefit 
3 Likes
That’s a bit of a non-sequitur. The desire has nothing to do with the third party nature of the project. There are plenty that do aspire to be part of the core but also plenty that don’t.
What I meant was that I have seen no comment that they wish to do so.
1 Like
As a user, simplicity is very important and hence ZHA is the way to go for new users. That said, I use z2m since it supported way more devices and coordinator hardware since the beginning. ZHA is catching up though and ZHA and z2m already at least benefit from each other, since developers can cross reference and use the gained insights of the underlying zigbee architecture of different device manufacturers.
1 Like
I can understand your comment, calling out they don't have desire might be misleading, there is no need to have a desire or not to have. It is what it is, an independent layer running as a docker.
2 Likes
And to make it even more precise…
zwavejs is also an add-on. There are at least two add-ons that I know of - one maintained “officially” and another third-party one that gives the extra control panel functionality.
But there is a zwavejs integration that consumes the zwavejs add-on data making it available to HA.
so they are basically functionally equivalent:
-
zwavejs add-on (supervised or third-party docker container) → zwavejs integration → HA
-
zigbee2mqtt (third-party docker container) → mqtt integration → HA
So what the OP is asking for is not even comparable since they are really comparing an integration with a docker container.
1 Like
I don’t think you do.
And there is no indication of wanting to change that. That’s all I’m saying.
1 Like
So, here i am, seeing an irrelevant comment about what i am capable to understand which doesn’t contribute anything to the topic. You are the great power (!!!) of these forums, continue delivering great nonsense comments.
1 Like
Common, play nice. Completely unnecessary.
2 Likes
Getting back to the original question, I look at it differently. ZHA is the native way HA talks to Zigbee devices. MQTT is a whole 'nother world. If you use it, it’s great that you can run Zigbee stuff through it. And from what I hear, you get more functionality ZHA doesn’t support.
But from the perspective of HA, that’s not Zigbee any more. It’s just MQTT.
1 Like
Based on the title and first post, I would down vote this if I could. Keep both products separate.
I’m all for an easier to install z2m, but that’s not the title of the thread.
I’ve thought an integration or add-on needs the ability to script adding in needed dependencies, Basically eliminate the need for an install tutorial in most cases.
A z2m “integration” could be essentially a “virtual integration” of sorts. Give the UI a simple cut and paste entry point (ideally no ssh or yaml ) to paste a third party integration URL. Then allow config flow prompting to automatically install and configure things like the z2m add-on, mqtt broker add-on and mqtt integration. Details and security concerns to work out, but a have a structure to simplify the third party world beyond z2m.
Also keep in mind that z2m supports also Domoticz integration so it is not HA specific. So no surprise there is no desire to have it included in HA.
1 Like
Personally, I went with Z2M (about a week ago) purely because I wanted a separate process for zigbee that didn’t impact Home assistants startup time.
5 Likes
Not to mention I don’t want the zigbee coordinator process to restart when I restart HA. It is nice that it is separate.
1 Like
+1 And the great thing about Z2M is that it can run remotely on a Rpi that is better located for connectivity to devices in the home than the server that runs my HA. I run zwavejs2mqtt on the same pi in fact, with the sticks separated by about 3 feet using USB cables. Works great.
So nice to not have to reset my (large) zigbee mesh when I restart HA, which I do a lot for HACS and other updates. I very much dislike the centralized integration model of ZHA for that reason.
As long as a restart of HA triggers mesh network restarts, the ZHA model is going to be suboptimal, even if the stick is remoted by ser2net etc…
3 Likes