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


#463

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.


#464

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


#465

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

Thanks…


#466

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


#467

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.


#468

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.


#469

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


#470

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.


#471

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


#472

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?


#473

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

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

#474

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


#475

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.


#476

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?


#477

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.


#478

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.


#479

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.


#480

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


#481

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:


#482

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