Ongoing Zigbee woes on C-8

Ever since migrating from a C-7 to a C-8, my Zigbee network has been less than functional - devices kept falling off completely or just stopped reporting some of their attributes. I’ve reset and re-paired the problematic devices multiple times to no improvement.

Today I finally bit the bullet and reset the Zigbee radio and spent the morning rebuilding my mesh (following best practices and including all devices in their respective locations, starting with mains-powered devices from the hub out and then finally adding battery-powered devices). All devices paired pretty much immediately (other than the Sonoff temp/humidity sensors which took a couple of tries each).

However, none of my Sengled Zigbee 3.0 contact sensors are happy ( model E2D-G73). They all paired as generic “device” but even after changing them to “Generic Zigbee Contact Sensor (no temp)” and hitting “Configure” they fail to report any events.

Any suggestions? This all is with the latest FW on the hub.

Try doing a power down for a few of the hub. It could be that they're stuck trying to find a hop to get through.

Powered the hub off for 25 minutes. No change.

I was having similar issues. Come to find out, the repeaters used to make the mesh stronger had the opposite effect. I swapped the repeaters and 24 hours later, everything started working. My C8 had been reliable and problem free since.

I had a similar issue with Zigbee repeaters prior to the C8 and had to get rid of a bunch of Sonoff S31. Zigbee mesh is much better now.

1 Like

Which repeaters did you remove?

2 Likes

Sonoff S31. For what it’s worth, they worked flawlessly on the C8, they never failed once, but they did prevent nearly everything else from working.

1 Like

I was on a C-5 and a very similar experience with the S31. Took the purchase of an Xbee to figure out what was going on.

1 Like

:scream: I do have a Sonoff S31 - as well as a couple of S40. Does the S40 have the same issue? I’m actually using them to control things rather than just as repeaters so losing them would suck. FWIW, the S31 is listed on the Hubitat compatible devices list…

I like the Sonoff plugs, but I think they should be removed from the compatibility list. I don’t think you can stop them from repeating. Once I removed them from my setup, my C8 problems disappeared (about 24 hours). Sonoff were the only Zigbee devices that worked reliably on the C8 when they were paired. I have quite a few that I can’t use.

Could the issue with the S31 be due to the mesh network?
I have several S31s on my C7 (no mesh, only 1 hub) and they have worked perfectly for the last year.
Just a thought....

The S31’s worked great. The devices routing through them failed. Yes, it is a mesh issue with S31.

1 Like

This is from this thread I wrote about a year ago.


The two 'Cam Plug' and the one near 'Siren' are all S31's and all have poor link quality. Devices further away like Patio 1 and Garage 1 have much better link quality.
Conclusion, the S31 is detrimental to the quality of your mesh.

1 Like

Even after removing my Sonoff S31 Lite, those Sengled contact sensors don't behave correctly:

Using the "Generic Zigbee Contact Sensor (no temp)" driver, it doesn't seem to want to actually configure the thing - all I get is the following:


16:02:23.624 descMap: [raw:886A0100010A210020C8, dni:886A, endpoint:01, cluster:0001, size:0A, attrId:0021, encoding:20, command:01, value:C8, clusterInt:1, attrInt:33]
16:02:15.949 configure...

If I use "Generic Zigbee Contact Sensor" instead, I get a lot more when configuring (not surprised about the failure to configure the temperature reporting):

16:01:29.209 skipped:[raw:catchall: 0104 0402 01 01 0040 00 886A 00 00 0000 07 01 86000000, profileId:0104, clusterId:0402, clusterInt:1026, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[86, 00, 00, 00]]
16:01:29.202 reporting configuration for Temperature Measurement (cluster 0x0402), attribute 0x0000 failed, unsupported attribute
16:01:29.194 descMap: [raw:catchall: 0104 0402 01 01 0040 00 886A 00 00 0000 07 01 86000000, profileId:0104, clusterId:0402, clusterInt:1026, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[86, 00, 00, 00]]
16:01:29.188 descMap: [raw:catchall: 0000 8021 00 00 0040 00 886A 00 00 0000 00 00 D300, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[D3, 00]]
16:01:29.156 skipped:[raw:catchall: 0104 0001 01 01 0040 00 886A 00 00 0000 07 01 00, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
16:01:29.151 reporting configuration for Power Configuration (cluster 0x0001) succeeded
16:01:29.146 descMap: [raw:catchall: 0104 0001 01 01 0040 00 886A 00 00 0000 07 01 00, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
16:01:29.119 descMap: [raw:catchall: 0000 8021 00 00 0040 00 886A 00 00 0000 00 00 D100, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[D1, 00]]
16:01:27.068 skipped:[raw:catchall: 0104 0001 01 01 0040 00 886A 00 00 0000 07 01 00, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
16:01:27.064 reporting configuration for Power Configuration (cluster 0x0001) succeeded
16:01:27.058 descMap: [raw:catchall: 0104 0001 01 01 0040 00 886A 00 00 0000 07 01 00, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
16:01:27.042 descMap: [raw:catchall: 0000 8021 00 00 0040 00 886A 00 00 0000 00 00 CF00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[CF, 00]]
16:01:27.034 descMap: [raw:886A0100010A2000201E, dni:886A, endpoint:01, cluster:0001, size:0A, attrId:0020, encoding:20, command:01, value:1E, clusterInt:1, attrInt:32]
16:01:24.966 descMap: [raw:catchall: 0104 0500 01 01 0040 00 886A 00 00 0000 04 01 00, profileId:0104, clusterId:0500, clusterInt:1280, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:886A, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[00]]
16:01:23.923 configure...

I don't understand why those two device handlers behave so differently - neither of them actually seems to work correctly. @support_team - why the difference and what driver should I use for this? I bought those sensors after consulting the compatible devices list and they yet have to actually work for me :cry:

Did you factory reset and rejoin the sensor?
You use the driver that is selected during inclusion

1 Like

I've reset them multiple times and even completely rebuild my Zigbee mesh as outlined above. The driver that gets automatically selected during installation is "device" which doesn't do anything.

can you post the fingerprint that is sent to the live logs when it joins with Device?, I'll add it to the correct driver, then when it joins it should work as expected.


08:20:06.950 info  fingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0003,0500,0B05,FC57,FC11", outClusters:"0019", model:"E2D-G73", manufacturer:"sengled"
08:20:05.903 trace ZCL version:08
08:20:05.901 trace Software Build Id:unknown
08:20:05.898 trace Model:E2D-G73
08:20:05.895 trace Manufacturer:sengled
08:20:04.900 debug getting  info  for unknown Zigbee device...
08:19:59.883 trace Manufacturer:sengled
08:19:58.064 trace Model:E2D-G73
08:19:57.804 trace Manufacturer:sengled
08:19:56.848 info  Zigbee parsed:[raw:catchall: 0000 0006 00 00 0040 00 0179 00 00 0000 00 00 0300000401000157FC, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:0179, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[03, 00, 00, 04, 01, 00, 01, 57, FC]]
08:19:56.085 trace Model:E2D-G73
08:19:55.817 info  Zigbee parsed:[raw:catchall: 0000 0006 00 00 0040 00 0179 00 00 0000 00 00 0200000401000157FC, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:0179, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[02, 00, 00, 04, 01, 00, 01, 57, FC]]
1 Like

added, will be in the next release.

3 Likes

I've updated to 2.3.5.138, hoping to finally get things working. However, now I am completely unable to pair the device, regardless which of the three pairing options I try - it never goes beyond the initialization stage:

sys:1 2023-05-12 17:34:30.164 info Zigbee Discovery Stopped
sys:1 2023-05-12 17:33:06.846 info Initializing Zigbee Device B0CE18140022A7EB, 803C
sys:1 2023-05-12 17:32:50.942 info Zigbee Discovery Running