Ongoing Zigbee woes on C-8

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

I’m on 2.3.5.152 and I can add the Sengled E2D-G73, but they don’t report out a status. Any update here?

Which type of hub? C-8 or other? (I can't get them to connect to my C-8 with the latest FW, they do connect to the C-7 though)

Have you tried fully removing the sensor(s) from your hub (red Remove button at the bottom of the device page) and then resetting re-adding them? I have had some devices that have required that to report properly.

If you have the sensor in apps for automations, you can use Swap Apps Device (Settings>Swap Apps Device) to temporarily swap the Sengled with a virtual contact sensor you create, then swap the real device back in after you've re-join the real sensor. That way you won't break your automations by removing the sensor.

Rev C-5

I reset them and re-added them “successfully”, but same experience. I let them sit for an hour to see if they will report…nothing. Maybe my Hubitat unit is too old as a C-5.

1 Like

After I paired them with my C-7 it wouldn’t report contact events either. They don’t put at all with my C-8

Age/model of your C5 should not be an issue...