ZHA Zigbee Tested Devices...Please add your device results

For all those with lights going into “unavailable” state, enable debug logging for

  • zigpy
  • bellows
  • zigpy_deconz
  • homeassistant.components.zha

and do the following tests:

  1. While light is “unavailable”, go to Configuration -> ZHA -> Pick the light from the Device Picker -> Select “OnOff Cluster (type: In)” -> select “On_Off (id:0x0000)” attribute of the selected cluster and click on “Get Zigbee Attribute”. Do you get a value or do you get None

  2. From Configuration -> ZHA -> pick the light from the device picker and note device NWK address and Light’s entity_id, for example in my case nwk is 0xae8e and entity_id is light.dwn_garage_entrance_2. Filter home-assistant.log like egrep '(0xae8e|light.dwn_garage_entrance_2) home-assistant.log >filtered-log.txt`

THe filtered log is still going to be noisy, but what are you looking for is:

  • light being polled every hour
  • whether the poll is successful or not

here’s an example of my log. It was noisy and lines might not be next to each other. In my case there were a few other lines and these three lines of interest:

2019-08-09 00:08:33 DEBUG (MainThread) [custom_components.zha.entity] light.dwn_garage_entrance_2: polling current state
2019-08-09 00:08:33 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xae8e, <EmberApsFrame profileId=260 clusterId=6 sourceEndpoint=3 destinationEndpoint=3 options=320 groupId=0 sequence=74>, 74, b'\x00J\x00\x00\x00')
2019-08-09 00:08:33 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, <EmberApsFrame profileId=260 clusterId=6 sourceEndpoint=3 destinationEndpoint=3 options=0 groupId=0 sequence=152>, 255, -88, 0xae8e, 255, 255, b'\x08J\x01\x00\x00\x00\x10\x00']

the 1st line tells you that light.dwn_garage_entrance_2 entity is being polled by ZHA. During polling, ZHA will try to read On_Off cluster (cluster id: 6), LevelControl cluster (cluster id: 8) and maybe Color cluster (cluster id: 768)
The 2nd line EmberOutgoingMessageType.OUTGOING_DIRECT this is the request being sent to the light. In that line you should see:

  1. NWK address of the light – 0xae8e
  2. clusterId=6 – On_Off cluster being polled
  3. Data bytes: b'\x08J\x01\x00\x00\x00\x10\x00' for those familiar with python bytes representation, note the 2nd byte J – that is transaction sequence number and it should be the same in the response.

The third line EmberIncomingMessageType.INCOMING_UNICAST is incoming traffic and make sure it matches NWK address 0xae8e and clusterId=6. And in the response bytes – b'\x08J\x01\x00\x00\x00\x10\x00' the 2nd byte (represented by J) is the transaction seq # and it should be exactly the same as in outgoing requests data bytes

So all of you should see polling current state and EmberOutgoingMessageType.OUTGOING_DIRECT log lines and either you should get a response INCOMING_UNICAST usually very shortly after a request or a DeliveryError [0xae8e:<endpoint id may vary here>:0x0006]. The delivery error message is going to be somewhere between 6 and 36 seconds later after the requests. You are not going to get delivery error immediately.
If you get DeliveryErrors with matching NWK and 0x0006, then the light is off the network. Either physically off or fell off the network.

Another question, with the affected lights, are they powered on all time or are they controlled by physical switches as well?

Also, filter the log for No such devicegrep 'No such device' home-assistant.log do you get any hits?


Well, good news! I upgraded to 0.97 and almost all of my “unavailable” are now working. There was still one device that didn’t work, and it turns out it was too close to another Zigbee device. I guess the RF transmitter would overwhelm the receiver, I could see on my packet sniffer that there were many resends and packets lost to that one device. Moving them apart by about a meter fixed it.

Is there anywhere that I can find information on how to put together a device handler? It seems that there are many devices that partly work or don’t work at all and I am keen to help out by creating handlers for them. I have created a few for SmartThings but am new to Home Assistant and Python so I am looking for some basic information to get me started. My environment is a Raspberry Pi3 with Home Assistant in a Docker container. As an example, I have written a device handle for a Osram/Sylvania four button switch for SmartThings which correctly sets it up so all buttons are used but bringing the switch into Home Assistant does not configure the switch and only the left two buttons do anything as all. In addidtion I have several devices that cannot be found. This is what SmartThings was doing before I wrote my handler so I would like to do the same for Home Assistant.
What I need is basic architecture istructions so I can follow the existing code to see what I need to do. With some fairly basic documentation I am pretty sure a lot mor people could be contributing and in no time we would be able to cover most of the devices on the market.

As you may know, ZHA is much more structured than SmartThings. So devices need to conform to strict parameters that meet the Zigbee standards, whereas with SmartThings each device was basically custom written.

If the device is similar to an existing device, but something in the implementation is a bit off from the Zigbee standard, the right place to fix this is with a “quirk” from here: https://github.com/dmulcahey/zha-device-handlers

If the device has some functionality that is not currently implemented, ideally that needs to be added to ZHA in Home-Assistant itself, and it must conform to the Zigbee standard. It’s possible to add this functionality to zha-device-handlers but only limited things are allowed there.

Can you share the SimpleDescriptor for all the endpoints on that four button switch? I have noticed that ZHA requires a Basic cluster for every endpoint, and I’m not sure if this is according to Zigbee standard. I’m curious if your device has a Basic cluster for every endpoint.

I just added my hue lights to zha control last week, and this happened to me as well. I lost one of my 9 bulbs, and had to reset it, remove it and re-add it to get it back. If this happens again, I’ll definitely follow these steps and provide feedback.

Thank you for the intro. I will try and grab the descriptors as soon as I can and let you know but from memory this is what I found when I was trying to set up these switches in Smartthings.
The Osram 4 button switch has four endpoints for the buttons plus one for the battery. There may be more I am not sure. Each button end point is essetntially the same and supports the same cluster set. On initial configuration from a factory reset the device is configured to send an “All On” message when button 1 is pressed and an “All Off” message when button 3 is pressed but nothing on buttons 2 and 4. If the switch is bound to a light bulb using the ZLL join procedure it will then control only that bulb . I do not know if buttons 2 and 4 then do anything. Using the Osram gateway and their iPhone application with a wireshark trace running I found that to configure each button a string of attributes was being sent to the switch. By changing the attributes for each button the switch can be made to send a button pressed, button held and button released message. I also found that, for Smartthings, I needed to then bind the button to the hub for the button to send the message to the hub and not simply send the All On / All Off messages. All this was done in the configuration section of the Smartthings device handler and then I was able to write automations based on the events being triggered by the button actions.
This is what I am trying to achieve in Home Assistant.
I will read throught the documentation and try to work out how to do it. One pointer that would be extremely useful would be to where the files concerned might be located in my Home Assistant instance. I am relatively competent but a little help with these sort of things can save hours of hunting around, especially in a Docker environment where access to stuff is so much less intuitive. Perhaps I should reinstall Home Assistant in the host and not bother with docker at this point. My primary reason for using it was because I thought it would simplify recovery from problems and coexistence with NodeRed which is what I propose to use for automation. What would you recommend? As you can tell I am interested in becoming a fisherman not simply a diner.

It does sound to me like the right place to implement that switch device is in zha-device-handlers. You can override the bind method so that when ZHA binds the device, it will also send the attributes to put the switch into the mode that you want. This will get you started: https://github.com/dmulcahey/zha-device-handlers/blob/91489d73cdd053f5da5e92d8b50f54e37a78c94d/CONTRIBUTING.md

I am using Hass.io for my main instance, and the zha-device-handlers are located at /usr/local/lib/python3.7/site-packages/zhaquirks. It’s a bit tricky to get there though, with Docker. I use docker exec -it homeassistant /bin/bash to log in.

To be honest I do my development on a separate HA instance so I don’t get negative WAF points. This is on a virtual machine with a separate USB coordinator, and not using Docker or Hass.io. Only after something is working do I move it over.

Excellent advice. I will study up and try to become productive as quickly as I can. I think I will stick with Docker for a bit. I worked out how to bind mount to effectively shift the files I am working on out to the host once I know where they are located. This way, if it all stops working I can remove the mount and my system is back to ‘out of the box’ state and I can recover easily.

Thank you very much for all your help.

Do you have discord? I’m the author (well one of them) of the device handlers lib. I can help you and then maybe we can even write a proper contribution guide. Also, can you share the traces that you spoke of? And a link to your SmartThings handler that provides the functionality that you spoke of? I’d love to look it over.

Quick question guys,

Does anybody know what zigbee channel the HUSBZB-1 uses? I have 2 separate networks in my house

  1. Asus mesh for main internet on mobile devices, PC’s and media players. This is the network my HA server is on (wired)
  2. 2nd wireless network on a separate Asus router just for my WiFi security cameras which consist of 3 x 720P and 1 x 1080P cameras (all are Amcrest)

I want to re evaluate the WiFi channels I’m using to ensure I’m not getting any WiFi interference from either of my networks. I thought I had read online that the zigbee channel of this device was 25

Bellows, the library the HUSBZB-1 uses, is set to default to channel 15. It’s possible to change the channel as I explain here: ZHA Zigbee change channel

My WiFi is on channel 6, I wonder if that could be part of my problem, my main router and HUSBZB-1 are in the same room as each other. I’ll have a look at the link you sent.

Is zigbee channel 25 the best one? I’d then put the router on channel 1

Please forgive what maybe a “Newbie Question”

How exactly do I run the command “bellows -d /dev/ttyUSB0 form -c 19”

You could just leave Zigbee on 15 and put your WiFi on 11 I suppose. Here is something I found on the web about selecting a channel. It looks like it has some good information.

This depends on your OS and installation. It would generally be run from the terminal, aka command line. This is pretty off topic for the Zigbee discussion but if you are using a Pi this might help you out:

Thank you, that is exactly what I did, my main Wireless router is on Channel 11 and my secondary router is on channel 1. Channel 6 is now wide open where I live. I did come across the link you sent as well.

I am runnin HA on Ubuntu Mate on a HP Elite 8200 Ultra Small Form Factor. For now I will try and see if moving my main wireless router to a different channel helps

So, I am trying to add the Tradfri on/off button that comes with the outlet. When it is paring, two panels show up. One for the battery status and one for, what I assume, is the actual button. Unfortunately, the button itself will not finish pairing and only the battery stays available. What can I do so I can use this Tradfri on/off remote button?

I got a Paulmann Gent zigbee remote control with 3 group buttons and a color control field. I can pair the remote with HA and I get a binary_sensor and a switch. If I pair the remote via touchlink with a bulb that was paired to HA, the bulb becomes engaged with the remote control and no longer listens to HA. Another bulb stays with HA and does not want to mate with the remote. Quiet confusing…

Touchlink uses ZLL which is a different standard than ZHA. Some bulbs support both standards. I’d recommend using the “Device Binding” option in the ZHA configuration panel. You will see this option at the bottom of the page once you select your remote control. This should allow you to retain control of the bulb in HA, but also control the bulb with your remote.

Ok I have paired the remote and the bulb with HA, then I go into ZHA to the remote and select “bind” and as bindable device the bulb, and then?

All you should have to do is click the “BIND” button after you have selected the bulb. If the remote does not control the bulb at that point, look in your logs, maybe there is some clue.