WTH - Bring ZHA closer to Z2M

Month of "What the heck?!"
, ,
1

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.

2

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.

1 Like
3

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.

  1. 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.
  2. 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.
  3. Help reviewing quirk PRs, there are 76 open PRs right now and almost all need reviewed.
2 Likes
4

https://zigbee.blakadder.com/all.html disagrees

Again, https://zigbee.blakadder.com/all.html disagrees

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.

5

@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.

3 Likes
6

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.

Where are these devices that only work with Z2M?

7

Again, incomplete - and not always accurate.

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 :stuck_out_tongue:

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.

8

A migration tool from ZHA to Z2M would be welcome.

9

Agree that would be awesome to have a detailed device database for Zigbee products similar to Zigbee2MQTT’s supported devices database regardless of how the ZHA integration 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, a.ka. Quirk 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 have used until recently, see:

Zigbee2MQTT’s zigbee-herdsman converter files are programmed in TypeScript/JavaScript so it is therefore 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 you porting the code from specific converters, (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 via custom clusters in a non-standard way.

10

Not true, Blackadder is not comprehensive on what devices are supported by ZHA.

I persisted with ZHA for a loooong time. Last week finally went to Z2M because requests first support were aged out by the bot.

11

So many. All devices that use custom clusters. ZHA for most ignores that Zigbee was designed to be an extendable protocol.

12

I’m not following your logic here, what should ZHA do better?

13

In ZHA it is very hard to support all the Zigbee devices features as entities and/or attribute by the means of quirks. AFAIK quirks are originally meant to be only an adapter for Zigbee devices that do not adhere to the Zigbee standard.

But to make a device work that has custom clusters for custom features you need to be a rocket scientist. IMHO this is a main reason why ZHA supports far fewer devices than MQTT which of course stands on the shoulders of giants. Or rather doesn’t shy away from using a widely uesed Node library to get things done.

14

Ok, I have to disagree with you on that one. When devices don’t follow the standard, you can’t add support without some sort of conversion. In z2m you have herdsman converters, for ZHA it’s a quirk. With quirks v2, I’d argue that it’s easier to support new devices in ZHA then it is in z2m. Really it just comes down to the user base, you have to have people willing to build and submit them, and the user base of z2m is just larger.

2 Likes
15

For me ZHA needs to be moved out of HA core and into its own addon docker like Z-Wave JS has and like zigbee2mqtt does.

Restarting the zigbee network and controller every time HA reboots is very slow and disruptive.

16

Good news, that’s currently in development.

5 Likes
17

I don’t see where we disagree. z2m has a huge user base and that will always mean support of more devices.

If ZHA wouldn’t stick to the Python paradigm of HA it could - I imagine - somehow make use of Herdsman.

What you maybe misunderstood is that I understand the need for a quirks to “fix broken devices”. What I meant is that with quirks v1 is not easy to get features of devices working that are covered by the standard that are not basic “elements”.

Eg a device may expose a tilt sensor. There is nothing explicit for this in te standard. But the device uses custom clusters as described by the standard. So nothing is broken, yet it is hard in quirks v1 to add an extra entitiy for that device.

18

With quirks v1 that was absolutely the case, primarily because you had to PR HA originally, now the external ZHA repo to add an entity in addition to adding the quirk. With v2 we can expose entities directly in the quirk.

This is Tuya, so not quite the same as something that might make half an attempt to conform to the standard, but it shows what a v2 quirk can look like.

(
    TuyaQuirkBuilder("_TZE200_bjawzodf", "TS0601")
    .applies_to("_TZE200_zl1kmjqx", "TS0601")
    .tuya_temperature(dp_id=1, scale=10)
    .tuya_humidity(dp_id=2, scale=10)
    .tuya_battery(dp_id=4)
    .skip_configuration()
    .add_to_registry()
)

And here’s an example of a non Tuya device.

(
    QuirkBuilder("Signify Netherlands B.V.", "SOC001")
    .replaces(PhilipsContactCluster, endpoint_id=2)
    .binary_sensor(
        "tamper",
        PhilipsContactCluster.cluster_id,
        endpoint_id=2,
        device_class=BinarySensorDeviceClass.TAMPER,
        entity_type=EntityType.DIAGNOSTIC,
        fallback_name="Tamper",
    )
    .add_to_registry()
)

We need better documentation for sure, but there has been a ton of effort in making quirks easier to work with
I think we will start to see feature parity as people get used to writing v2 quirks.

1 Like
19

I am not up-to-data when it comes to v2. Last I heard of it was in planning stage and the whole Zigbee stack in a kind of flux.

Your examples look so much easier then I what I knew. Awesome!

Now I might actually be able to write a quirks myself. Hope to find the time to squeeze the extra bit of some devices I own.