For many users, it is very desirable to use Zigbee within HA through ZHA.
Unfortunately, ZHA supports far fewer devices and significantly less functionality than Z2M.
Are there any ideas on how to get closer to Z2M here?
Could it be a possibility to use the Z2M converter files (Device Definitions) directly in ZHA or at least to create a mechanism that provides a first draft for a Quirk from the Device Definitions.
Are there any further approaches to establishing a database of supported devices like Z2M has?
As a final idea, it might be helpful in this context to provide more developer documentation and tooling to motivate more developers to engage in Quirk development.
Actually, it’s much of a wash. ZHA simply doesn’t document what does work, which makes it hard to know.
There’s been many attempts to do this, but they’re all incomplete and most are abandoned.
To be fair, now that Z2M has opportunistic support like ZHA it suffers from the same problem - you only have a database of the ones that needed effort to make them work.
The number one issue here is Tuya devices IMO. Most of the open device support requests are related to Tuya. It would be possible to create a tool to scrape Tuya Datapoints from z2m converters, not something in my wheelhouse though. And honestly not sure how much more support that would really get us.
Absolutely agree on the docs, the docs are terrible and mostly we point people to look at existing quirks. If you have experience in documentation, we can use all the help we can get there.
Other things that would help with Tuya devices.
We need people to gather Tuya Datapoints and include them in their support requests. The default template asks for a device signature, but it’s little help with Tuya.
People willing to help build quirks and test them. I’ve provided a few only to never get any feedback or be told they already moved to Z2M.
Help reviewing quirk PRs, there are 76 open PRs right now and almost all need reviewed.
I’m biassed I admit, but that’s due to my history. My first steps in home automation were with Domoticz. Next came MQTT (mosquitto), Influx, Tasmota, NodeRed and most recently z2m. All of which came years after I began dabbling with Raspberry Pis.
HA came along last. HA wants to own everything and assumes it comes first. The easy way to use HA on a Pi is HAOS, core on an exiting pi as far more poorly supported. The easy way to use HA and MQTT is to add the MQTT broker to HAOS, HA comes first and the other way round (an external broker) seems far less supported. The easy way to use HA and Zigbee is to add the ZHA broker to HAOS, HA comes first and the other way round (Z2M) seems far less supported. I have not even looked to see if HA is attempting to Borg NodeRed as well.
@Tinkerer is correct, the blackadder list is incorrect and really could never be correct. I can point to at least 5 devices that are supported in ZHA that aren’t listed there. In addition, the way manufacturers, specifically Tuya, will change clusters around or update the device manufacturer and model on a whim, yet still sell it as the same device, makes any list almost always out of date.
HA supports external brokers without issue, I’ve never ran it any other way.
As would be expected, ZHA was made for HA, z2m is a third party.
I have yet to come across a zigbee device that doesn’t work with ZHA, and don’t feel like setting up MQTT just for Z2M. Not due to effort, it’s like 3 clicks! I just don’t see the point when ZHA works fine.
I used the Aqara Cube and just had to handle the ZHA events.
There’s been many cases of people adding a “supported” device to that page, only to discover that it really isn’t. Plus of course there’s an unknown number of supported devices that nobody’s added.
Not at all, you just need a bit more skill
Not at all, it’s just not a couple of UI clicks
I’ll half give you this. The HA team doesn’t support Z2M, no. But they don’t need to, Z2M has a whole community that supports it
It also works well, and is used by one of the core HA developers, so if HA somehow broke Z2M support (which is highly improbable) it’d get attention pretty fast.
Agree that would be awesome to have a detailed device database similar to Zigbee2MQTT’s supported devices database regardless of how ZHA actually works under the hood.
I believe that Paulus mentioned in a podcast interview from earlier this year that that kind of official device database was on their future plans for Home Assistant. Not seen anything more written about since then.
I guess however that would probably not be made specifically for Zigbee or ZHA but instead perhaps only for all devices that are part of the ”Works with Home Assistant” (Home Assistant’s partnership program), or maybe with just devices tested with integrations included Home Assistant core.
That is already in place now with the new ZHA Device Handlers version 2 (ZHA-Quirks V2) API and architectural design which makes creating a ZHA Device Handler (zha-quirk) much simpler than before with the now old ZHA-Quirks V1 API and
architecture that most existing ZHA Device Handlers uses today, see:
Zigbee2MQTT’s zigbee-herdsman converter files are programmed in TypeScript/JavaScript so it is not possible to use those as ZHA Device Handlers (zha-quirks) files because those are programmed in Python, (same as the zigpy library that all ZHA is programmed in), …but it might be possible to use some AI to help porting the code, (though not looked into that myself).
PS: Note that making quirks/converters as device handlers for devices manufactured by Tuya is still a huge pain for both ZHA/zigpy and for Zigbee2MQTT/zigbee-herdsman because they do not follow the standard Zigbee specification and have instead implemented propriatory costumization.
