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

Configuration Zigbee
375

I use hass 0.71.0 and zha component, Elelabs ZigBee RPi Shield and some xiaomi devices (door sensor). Zha component is loaded, zha.permit is started, device joined the network but not listed into HA (the zigbee.db is empty). I have temporarily resolved issuse as follows:

  • Downgrade Home Assistant to version 0.69.1
  • Delete zigbee.db
  • Restart HA for setup component zha again.
  • Call zha.permit service and pair xiaomi device again
  • Device joined the network but error: Message on unknown endpoint 1 (The zigbee.db looks as follows after the device has been joined. There is only an entry in the devices table since it does not respond to the endpoint discovery)
  • Manual create the endpoint entry and entries for the output clusters
    • INSERT INTO “endpoints” VALUES(‘xx:xx:xx:xx:xx:xx:xx:xx’,1,260,0,1);
    • INSERT INTO “output_clusters” VALUES(‘xx:xx:xx:xx:xx:xx:xx:xx’,1,4);
    • INSERT INTO “output_clusters” VALUES(‘xx:xx:xx:xx:xx:xx:xx:xx’,1,5);
    • INSERT INTO “output_clusters” VALUES(‘xx:xx:xx:xx:xx:xx:xx:xx’,1,6);
  • Restart HA and it working fine
  • Upgrade Home Assistant to version 0.71.0

But after a few hours not updated status, the device seems to have left the network (listed in HA but not responding)

376

I just tested Keen smartvent and unfortunately they show up as switches (for which commands fail) with a temperature and pressure sensor. Is there anyway to make it a dimmer (analog output)?

the device has the following cluster IDs:
0 basic
1 power config
3 identify
4 groups
5 scene
6 on/off
8 level
32 polling control
1026 temperature sensing
1027 pressure sensing
2821 ??
64513 likely proprietary
64514 likely proprietary

Would be great to add a dimmer device to hass upon detection of cluster ID 8. This should make it functional.

377

Banging my head wondering why a device which has clusters 4,5,6 and 8 shows up as a switch on Home assistant. It should be either a dimmable light or a level control switch. Anybody have an idea?

378

Successful inclusion and fully functional, reliable use of Sengled Element Classic (Sengled E11-G13) bulbs, and OSRAM Lightify (A19 RGBW) bulbs directly to my HUSBZB-1. Can restart bulbs and HA without issues. Nice work!

Please let me know if you want more detailed info

379

6 is on/off and 8 is level control. the handling of dimmers, remotes and buttons is a bit suspect at the moment. I am working on several fixes to clean this up. when you list clusters, can you include whether they are input or output clusters? That makes a big difference in how the device can be handled.

380

What device is it? I mean is it an actual dimmable bulb/switch or is it a remote? And what do you get for the device type? Any chance you can get output of bellows devices ?

Currently, unless device type is not a DIMMABLE_LIGHT or similar, zha component will probe by clusters and since there’s on/off cluster present it would treat it as a “on/off switch”, regardless of the presence of the LevelControl cluster.
eg this “KingofFan” Zigbee device shown as

Device:
  NWK: 0x4e6b
  IEEE: 00:22:a3:00:00:16:d0:18
  Endpoints:
    1: profile=0x104, device_type=14
      Input Clusters:
        KofBasic (0)
        KofIdentify (3)
        KofGroups (4)
        KofScenes (5)
        On/Off (6)
        Level control (8)
        Fan Control (514)

will show as a “switch”, even though I’d prefer it to show up as a dimmable light.

If I’m reading the code correctly, there may be a way to override the device type. You need to know the IEEE address of the device and Enpoint # and then create the following config entry under zha configuration in your configuration.yaml
eg for IEEE address 7c:b0:3e:aa:00:a4:55:95 and endpoint #3 create the following:

zha:                                                                                                   
  baudrate: 57600                                                                                      
  usb_path: /dev/ttyS1                                                                               
  database_path: /zigbee.db                                                           
  device_config:                                                                                       
    7c:b0:3e:aa:00:a4:55:95-3:                                                                         
       type: 'light'
2 Likes
381

Thank, that explains it. I thought the component would have been smart enough to see there is more than an on/off endpoint It is actually a motorized vent. It is setup on the vera as a dimmable light or as a window covering. See here:

382

Attempting to manually configure did not work. Actually nothing changed…

383

exact output

Endpoints:
1: profile=0x104, device_type=DeviceType.LEVEL_CONTROLLABLE_OUTPUT
Input Clusters:
Basic (0)
Power Configuration (1)
Identify (3)
Groups (4)
Scenes (5)
On/Off (6)
Level control (8)
Poll Control (32)
Temperature Measurement (1026)
Pressure Measurement (1027)
Diagnostic (2821)
Manufacturer Specific (64513)
Manufacturer Specific (64514)
Output Clusters:
Ota (25)

384

hmm, maybe check formatting? I’m running this on stock HA 0.72.1 and I have a color light which normally shows as a color light in hass
image

and has the following in bellows devices (The lines of interest are device_config: and everything bellow it):

Device:
  NWK: 0xe945
  IEEE: 7c:b0:3e:aa:00:a4:55:95
  Endpoints:
    3: profile=0x104, device_type=DeviceType.COLOR_DIMMABLE_LIGHT
      Input Clusters:
...
        On/Off (6)
        Level control (8)

modifying my configuration.yaml to contain

zha:
  baudrate: 57600
  usb_path: /dev/ttyS1
  database_path: /zigbee.db
  device_config:
    7c:b0:3e:aa:00:a4:55:95-3:
       type: 'switch'

makes it appear in HA as a regular switch:
image

I was looking into those smart vents. Need to get a few to try.

385

I tried both switch and light and the device comes up as a binary switch every time. The binary works in one direction but not the other. Meaning I can close the vent by turning it off but I cannot open it as the vent expects a value at end point 8 to open…

386

hi, i have a lott off mct-340e. but what zigbee stick are you using to be able to see them?
and can you share you conf how to add them to home-assistant?

//Regards

387

most popular I use HUSBZB-1 (not to be confused with husbz-1 which is zwave only) alternatively you could use (XBee S2C)[https://www.amazon.com/XBee-2mW-Wire-Antenna-ZigBee/dp/B007R9U1QA) (cheaper on digikey or mouser) which requires a serial port connector https://www.waveshare.com/wiki/XBee_USB_Adapter or any other FTDI or similar USB-to-com adapters. I’m pretty sure you could plug XBee to Raspeberry PI and use its onboard com part.

This is what I’ve tried and use, but there’re some other alternatives with a “hub” like approach:

388

and let’s say Zigbee support has been improving a lot later, in other words: “your mileage may vary”

389

Zigbee support is SO bad right now… SO bad…

Unless you’re willing to suffer… associate them with something that actually understands Zigbee devices (like a SmartThings) and MQTT the data across between the two.

I have every faith that someday ZHA will be as good as Zwave on HA, but it’s not even in the same ballpark today.

390

I have several IRIS zigbee motion and open close sensors, as well as a couple of older smartthings open close and motion sensors. I did have to buy an IRIS plug to improve signal quality (its a zigbee repeater as well), and since then I have had zero problems for month+. I’m also using HUSBZB-1

1 Like
391

@ptdalen, do you have any bulbs on your zigbee network? ZHA has been really, really rough for me lately.

RANT TIME:

After a reboot everything works - but then in a day or so all my lights (and a switched outlet) stop responding reliably, and eventually they stop responding at all. The lights are all Osram/Sylvania Lightify at the moment - five are RGBW and two are two are Warm/Cool White. The switched outlet is an IRIS v2 plug (reads as CentraLite 3210-L, with the odd dual z-wave/zigbee radios). I’m not sure what the issue is, because ZHA had been pretty darn reliable for a good number of months. (I also have a Tradfi bulb that I was able to include months ago, but I have since reset it, nuked my zigbee.db, and attempted to re-add, and it will no longer show up.)

I also have one and three Visonic MCT-340E door/window sensors spread around a very large house. Even after the bulbs (and the IRIS plug) quit responding, the door sensors still work and are very reliable. The built-in temperature sensors work too.

The five RGBW lights and the IRIS plug are all within 10 feet of the HUSBZB-1 stick, most of them line-of-sight. And yet they drop off just as quickly as the ones further away.

Here’s what an error in the log looks like after the lights stop responding:

Mon Jul 09 2018 00:10:40 GMT-0400 (EDT)
Error executing service ServiceCall light.turn_off: entity_id=['light.osram_lightify_a19_rgbw_00a3342d_3']
Traceback (most recent call last):
File "/usr/src/app/homeassistant/core.py", line 1021, in _event_to_service_call
await service_handler.func(service_call)
File "/usr/src/app/homeassistant/components/light/__init__.py", line 362, in async_handle_light_service
await light.async_turn_off(**params)
File "/usr/src/app/homeassistant/components/light/zha.py", line 127, in async_turn_off
await self._endpoint.on_off.off()
File "/usr/local/lib/python3.6/site-packages/zigpy/device.py", line 89, in request
expect_reply=expect_reply,
File "/usr/local/lib/python3.6/site-packages/bellows/zigbee/application.py", line 213, in request
assert sequence not in self._pending
AssertionError

Any input welcome!

My proposed next step is to try to update the firmware on the bulbs:

  • Exclude/reset all seven bulbs,

  • Add them into the Lighify network (I have a gateway and account already) and do the updates,

  • Exclude/Reset them all again,

  • Add them all back to ZHA and see what happens. If they retain their IEEE addresses after the updates, at least this part should be easy.

Ugh. :roll_eyes: I’m also thinking I need to pick up a Tradfri gateway to update that bulb, since I bought it fairly early in their availability.

There’s got to be a better way. Z-wave stuff just WORKS.

392

I will say that i dont have any zigbee bulbs. I do have some Hue bulbs, but use the hue hub for control of them. From what I’ve read I it does seem like other seem to have more problems with some bulbs as well. Bulbs should be repeaters which seems like it should strengthen your zigbee network. Other than my plug (same as yours), all my zigbee devices are battery powered (not repeaters), which is why I needed the plug.

I have one zwave bulb, but mostly went zwave switches, vs bulbs. And as you said, the zwave stuff does always work.

393

The AssertionError means a pending request is still in the stack somewhere to the device. If those keep happening continually then the only thing that works for me is to restart Home Assistant.

I have about 25 bulbs and some sensors and probably get stuck in the AssertionError loop once every two weeks or so.

I did build a flow in Node-RED that will automatically monitor for ZHA/Zigbee requests that failed and automatically try again. It also monitors for the the AssertionErrors and will restart Home Assistant if 50 errors have occurred and the AssertionErrors don’t go away.

394

Not sure if someone answered this I was out of town.
HUSBZB-1 plugged into a raspberry pi 3
This one does Zwave & Zigbee devices

Entry in configration.yaml running on HASSIO v0.73.1

You want the ZHA setting for this not the zigbee that is commented out
uncomment the Zwave if you want it. I only run zigbee devices.

#-------------------------------------
#---- Setup Z-Wave Zigbee USB Adapter
#-------------------------------------

#Nortek/GoControl Z-Wave & Zigbee USB Adapter HUSBZB-1
zha:
  usb_path: /dev/ttyUSB1
  database_path: /config/zigbee.db
#  database_path: /home/homeassistant/.homeassistant/zigbee.db

#zwave:
#  usb_path: /dev/ttyUSB0

#zigbee:

Hope this helps.