Custom ZHA Device Handlers (ZHA custom quirks handler implementation)

I am quite a newbie in HA. So please pardon me if I say something technically incorrect.

Before HA, I had a setup around smartthings. I live in Down Under and home automation market here is pretty small. Most of the AU certified zigbee stuff I got from the local market don’t work with smartthings out of the box. I had to spend a lot of time writing custom device handlers. Although everything worked eventually, the execution using mqtt-smartthings bridge is sort of laggy. The smartthings cloud has also failed me a few times. So I decided to move on to an HA + zigbee local solution.

I preferred ZHA becuase of its simplicity. So I bought an HUSBZB-1 and started testing. As expected the pairing is not an issue. However, most of the devices do require further implementation to function fully and correctly. Since I’ve got all the cluster and endpoint infomation from the smartthings experience, I thought it could be quite straightforward for my existing devices. However, after reading all the relevant threads I could possbily find, I am still unsure on how I can code some custom zha quirks and test in the hassos (home assistant standard image) environment. Can someone please help me with the right steps? Any help would be appreciated.

Btw would it be nice if the custom zha quirks can be dropped in like custom components? Then we can easily share them here to enrich the supported device list.

3 Likes

I’m sorry, I don’t have the answer to this. However, if you do find one, or if someone does, I would love an answer. I’ve been attempting to get a Lutron Aurora working directly with HA’s Zha implementation, but it seems like to get full functionality I’d have to write my own device handler.

Are you able to get button events out of this @GodOf_war.
It seems very inconsistent for me. I can listen for zha_events and see all the reports as I turn the dial. But I only see the button push event on occasion.

I think I can write an automation that captures the zhaevents and send the values to a light but I really need the button events to work as well. Any thoughts?

Edit:
Nevermind. I just read your post in the other ZHA thread. :disappointed:

I have the HUSBZB-1 and tested zha. It isn’t simple. I never made the full switch to it. As a Smartthings ex user myself, I’d recommend using Hubitat. Then connect them via the integration. You get the local control and the power of home assistant with the ease of Hubitat.

Thanks for your suggestion. I’ve actually considered this solution before. It looks quite promising. Though I recently had a plan to build an home automation hub with a Pi 4B. So it would be great to have something just plugged in. Since I’ve also built a 3D floorplan, a 32-inch touch screen will be connected to the Pi 4B to displan the HA interface. Then maybe 3d print a case to wrap them up…

I guess I’ll purchase a CC2531 and give zigbee2mqtt a go.:slight_smile:

1 Like

ZHA device handler quirks are developed here:

I know Pull Requests are welcome.

Thanks buddy. I would be happy if I could contribute too.
I am currently running hassos. Does it mean I’ll have to setup a separate dev enviroment to code and test zha quirks?

I’m not a programer, but test things out from time to time to help out the dev. I run HA (old name: hassio) on Ubuntu.

What I do, is copy or update the quirk in the Home-Assistant container in docker, it will get written on any update, but it suffices for testing.

The simplistic way I do this, is to use the Portainer Addon (unhide the HA containers) and use it to open a console in the container.

I’ll have the new/modified quirk in the config directory and just copy it over to the appropriate folder in the quirks directory:
/usr/local/lib/python3.7/site-packages/zhaquirks/

2 Likes

Thanks for the info. :slight_smile:

Although things might be different for me since my setup is on the hassos (official image), now I understand how it works. I will enable the debug mode and give it a go.

Hassos and what I run similar docker images mine difference is architecture only really. so both containers should share same structure. (Actually I run hassos on a rpi3 at work and have done this there).

Good luck.

I’ve actually tried the add-on and got lost…

The home page shows:

The dashboard shows:

After I clicked “Containers” menu

Couldn’t find homeassistant there.
Sorry I am quite new to this…

No worries. we all start somewhere…

by default the homeassistant and addon on containers are hidden, so you need to go into settings and go to the bottom and you should see a section about hidden containers. Just it the remove button from each to remove it from the hidden listings. then they will show up in the container list.

Thanks so much. I just realised how much I’ve got to learn in HA. :slight_smile:

So haven’t really seen anything what I’ve been trying to do but this thread seems to be the closest and I would like people’s input on the matter (I’ve been gathering bits and pieces of information so I’m not sure if what I’m saying is entirely accurate).

Basically what I am trying to do is see if having many routes that are more prone to packet loss is actually worse than having fewer routes that have a lesser chance of packet loss. The scenario in which this is applicable is when you have many zigbee smart lights (in my case the sylvania rgb bulbs, I have 28) that all have a small buffer which can lead to dropped packets if there is network flooding. I assume network flooding is also more likely to happen when the zigbee network is doing a multicast broadcast over several routes (so perhaps having too many bad routes would decrease network performance)?

Why I am here is I’m thinking of modifying my ledvance a19 quirk to not show up as a router. Ive been reading up on this information (GitHub - zigpy/zha-device-handlers) and what I am trying to figure out is if simply modifying the node descriptor attributes for is_end_device to true, is_router to false, and logical_type to end device. I am not even sure if what I’m trying to do is possible and even if it is, would having a mains powered end device with the active when idle attribute set to true still cause the device to go to sleep.

@tube0013 have you heard of any changes like this before or would I be better off starting a new thread for this?

You cannot do this in a quirk. The device (FW) itself determines if it is a router or not, and will do as it programed. the quirk is only a translation layer to ZHA in HA.

1 Like

Thanks for the info, there goes my idea lol. Guess I’ll just have to either live with these or switch out these bulbs.

@jerryz This new feature might be of interest to you and other ZHA custom device handler developers:

1 Like

@abhi08638 tip is to read and follow this link for recommendations about Zigbee router and pairing, etc.

1 Like

FYI, started a new Zigbee device guide thread specifically how-to setup local custom ZHA Device Handlers (zha-quirks) in the ZHA integration and it also contains some tips on how-to post requests if there are no existing ZHA Device Handler (zha quirk) for a specific device, including some information and links about the new “Quirks V2” specification:

1 Like