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


ahh the -1 did the trick. I tried end points 3 and 8 and neither worked. Thank you!


yep, the “key” for the devices like light, outlet is in the form of <IEEE_ADDRESS>-<Endpoing #> and for single cluster devices, like temperature, pressure sensor the key for the device is in the form of <IEEE_ADDRESS>-<Endpoint #>-<Cluster #>


Now if someone could tell how one can change the zigbee channel with such a setup, it would be great.


@rafale77 not sure it is possible to change the channel, currently. I think coordinator picks a channel
when it forms a network, but I don’t know what are the conditions to force it to jump onto another channel during operation. From Silabs materials I was reading: don’t use channel bonding in 802.11n WiFi, use only 20MHz channels, not the 40MHz ,
I’m running three APs on channel 1, 6 & 11, so was expecting quite the interference from WiFi, but even the furthest zigbee router does report the coordinator in its neighbor table, which surprised me, because coordinator is in the metal rack in the basement.


How are you querying the neighbor table?


@wixoff My Zigbee setup has been going nuts lately - similar issues as you. Have you had any luck?

I have the HUSBZB-1 and Senled LED Bulbs and a few Iris outlets (as repeaters). My error log is full of “Updating zha sensor took longer than the scheduled update interval 0:00:30” and “Unexpected message send notification” that pops up 2-3 times a minute. I’m unable to control any zigbee devices as well. If I reset HA, the bulbs work again for a bit, but then this same error pops up. I just tried deleting my zigbee.db and re-added all the bulbs after a factory reset. Hopefully that does the trick. Anyone else encounter this?


There is an ongoing issue on the Bellows side that has dozens and dozens of responses all with similar symptoms. The consensus there seems to be a large batch of faulty adapters. In your case, as you were working for a while, I would try reverting back to an older home assistant version which will give you an older version of bellows. If you don’t have the issue there then it’s a software issue but if you do have the issue there it’s a hardware issue.



Things did work flawlessly from version 59 of Home assistant thru 66 or so for a number of months. That leads me to think it’s software related. When I updated to version 69 or so, problems immediately surfaced. It’s right about the same time zigbee devices started returning wattage usage.

I did try deleting my zigbee database and re-adding all my devices. That seemed to have helped but my error log is still getting slammed.


Yeah, I have gone through the reset-delete-repermit dance a couple of times. Reset all the bulbs and sensors, delete zigbee.db, and add everything back. It doesn’t seem to help me.

Honestly, I have never had 100% luck with zha (one device or another will become unresponsive after days or weeks), but what I had before was MILES better than what I’m seeing now. And yes, I think it started for me around the bulb-wattage feature addition too.

Next steps: (1) try to update the firmware on all my Lightify bulbs; and (2) try to minimize overlap between 2.4 GHz WiFi and Zigbee via channel selection.

I should look at the bellows commits between a couple of months ago and now, too, to see if anything jumps out at me.


Anyone know if battery level for zigbee devices will be supported in the near future. I think I saw something in some of the posts above that required changing some lines of code, just wondering if there are plans for it to be officially supported? For me I have two main brands of zigbee devices (Iris, and some older Smartthings sensors). They all work well, but would love to get battery, one of batteries died, and I did not notice. Its an old motion sensor I just use in my garage fridge for temp readings, so I missed it.


I downgraded to v0.67.1 and zigbee appears to be working better. In version 0.68.0 bellows was updated to v5.2 hence I chose 0.67. I’m getting some other random errors, but I think that may be due to the downgrade. I’ll report back with additional feedback.


Thanks. That might be worth a try too. (But I have been using some other components upgraded since then, not to mention the 0.73.2 security patch, so it’s no long-term solution.)


Hello, I’ve just started using HA in the past week. I have v0.74.0 running a rpi3b+ using raspbian stretch lite. I’ve setup a husbzb-1 and got my first sengled element bulb installed. I noticed there is also a sensor monitor when the bulb is installed. Also, if I restart HA while the bulb is off, HA reports the state as on even though it is off.

Is the added sensor monitor normal?
Anything to do about the incorrect state upon a restart?

Sorry if this is the wrong place for this. I wasn’t sure where to ask about this.


is it possible to select the zigbee channel in HA? (I’m using Hass.io so don’t really have easy access to the underlying bellows support.

I am starting to think I have major interference issues in my home.


Not positive, but to me it looks like bellows hard-codes the channel to 15 (see bellows/zigbee/application.py, line 81). Per this article ZigBee channel 15 potentially conflicts with 2.4 GHz Wifi Channels 1-6 (maybe even 7-8).

So I was going to try, at some point, to change the ZigBee channel to 26 and force my access points to WiFi channels 1 and 6, just to see what happens. I haven’t tried that yet.


I believe a lot of old ZHA gear won’t support channel 26 so your success there may be mixed. I use WiFi channel 11 and haven’t had any issues with Zigbee channel 15.


Thanks. Interesting.

I have three access points and they’re (naturally) on channels 1, 6, and 11. I’m going to try to move the furthest-apart ones to both be on channel 1, with the other on channel 6, then try the high-numbered Zigbee channels 24-26.

If that works, maybe I could add WiFi channel 11 back into the mix, but only on the garage AP that’s far away from the ZigBee stuff and with reduced power.


I use a native Hue bridge as well, and was having some issues with bulbs showing as non-responsive, it was using zigbee channel 11, my wifi is on wifi 1 and 6 so there was def. overlap. Hue let me change the channel (it chose what to change it too) and now it’s on 20 and seems much more stable. I was hoping to move bellows up higher as well…


same here. have three APs on channels 1,6 & 11. One AP is next to HUSBZB-1 in the rack and have no issues. One of the recommendations is not to use 802.11n channel bonding (40MHz channels) as those kill the gap were zigbee tries to live.


Eh, it didn’t work anyway. I edited application.py to change the ZigBee channel to 25, made sure none of my APs were on WiFi channel 11, and sure enough – everything worked after restarting Hass, then bulbs started dropping off over time. Same exact result.

It’s different bulbs each time, too, that drop off soonest.