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


Product: Visonic MCT-340 E
Hass.io 0.79.3

Only the open/close sensor is working.
Temperature sensor is not working. Need an official support for the temperature.


If you can patch bellows, try https://github.com/zigpy/bellows/pull/135 in your environment


Do you know if that patch is included in 0.80.0
Going to update tonight



It’s not included – 0.80 doesn’t have any zha/bellows updates and that pull request for bellows just came out today


Correct. It has to be merged in bellows, pushed to pypi and then HA dependencies updated, so it is going to take a while. But, if more people could test it and provide feedback, then owners might be inclined to push it more quickly.


Hey, i’ve bought an ikea dimmer kit to try it out with zha (i’m using ha 0.80.3, elelabs ezusb stick).
I’ve unpaired the dimmer from the bulb and successfully paired the dimmer to zha but can’t get the bulb to pair - tried first turning on and then issuing zha.permit and the other way around.
Are there any tricks one has to do?
I’ve successfully paired my xiaomi aqara temperature sensor too.


Make sure it’s really close to the zigbee hub. I’ve successfully paired a bunch.


I’ve added devices, all listed already, but lowed gen 2 contact and motion sensors, centralite wall outlet dimmer, and a Samsung wall outlet. Still need to try the water sensor from Samsung and their push button.

I’m wondering if there are plans to improve zha. The UI like leave would be nice, to pair and unpair. Also, a good zigbee log like the zwave one, where do I get logs? Battery level, shouldn’t that be pretty easy to add? Then custom handlers support, like keypads and other devices, it was pretty easy in smart things to override and get zigbee events and add device support.

Last, to remove a device, having to stop, and open a sqllite database, manually delete rows from 5 tables, and then turn back on is a little much to remove a device.


thanks, managed to do it - turned out i didn’t unpair/remove it successfully before. I had to turn it on 6 times to reset. This video from ikea helped (timing): https://www.youtube.com/watch?v=mJm9YpPrGzk


I’m still a HA novice, but I have recently migrated all my zwave and zigbee devices to HA (hass.io) and I am uing the HUSBZB-1 device.
Prior to my migration, I was just using the vera component, but I wanted to eliminate it.
Through vera, my zigbee bulbs appeared to get polled and status updated correctly on my Sengled LED bulbs. With ZHA, those bulbs no longer appear to be polled, and HA is not aware of their status when operated at the switch. HA also assumes the bulbs are off after a reboot of hass.io.

Reading around, it seems like I may not be alone, but some of the posts are old, and I thought that maybe polling was working at one point, and now its not.

I’m running 80.3. Is this the intended operation with zigbee devices that they aren’t polled?
Is there configuration I can change that will tell ZHA to poll the devices?


Not the configuration change, but you could try changing the last line of homeassistant/components/light/zha.py file to return True so HA polls for the status. So it should be something like

    def should_poll(self) -> bool:
        """Return True if entity has to be polled for state.
        False if entity pushes its state to HA.
        return True


How do I do this using Hass.io?
I tried (find / -name zha.py) in SSH but no results were returned.


Actually in reading, it looks like I can’t edit it in Hassio, I have to duplicate it into a custom component and nest it in my config folder.
Testing that now.


Looks like that worked with one exception.

If a device loses power, HA keeps the last state it saw.
So say a zigbee bulb running in a lamp was ‘on’, if that lamp was manually turned off, HA appears to keep the ‘on’ state until the bulb can be polled again.
At least thats what I have found in my testing over the last 15 minutes.

Is there a per device configuration that can be made to provide an assumed state if the device can’t be contacted?


The best you could do is to update async def async_update(self): method and change line self._state = result.get(‘on_off’, self._state) toself._state = result.get('on_off', None), in this case the state would become Unknown if HA couldn’t read state from the bulb.


That worked a treat! You rock.
Now if I can figure out why zha tends to crash daily forcing me to restart HA, I’ll be all set.


Welcome to the club :frowning: One of the common factors between most of the reports is Raspberry PI/ARM board and hassio. EZSP seems to be sensitive to UART timing and looks like Raspberry cannot keep up the pace.


I was really excited about HA when I decided to move from Vera. All my zwave stuff works great. Zigbee is another story :frowning:.
I wonder if I can at least automate the HA restart when zha crashes.


There are some untrapped exceptions in the async zha code that exhausts the 256 sequence IDs. You can see the issue here if you want:


@Quatuor and @tbrock47 can confirm that I had the same issue with zha crashes on my Raspberry Pi as soon as I moved to more powerful hardware that issue disappeared and I never saw it again. If you can get something like a NUC you will be very happy with everything. The pi is cool and all but can’t keep up the more your HA system grows in size. You will be happier with HA when you move away from a pi :wink: