ST broke the Zigbee Illuminance Sensor Edge driver

Devices & Integrations
1

Today at 4:48pm EST this driver was updated on my hub, and ever since then my hub is flooded with device events and RAW messages from the device. Everything was working great until that happened. Heads up to anyone using the Zigbee Illuminance Sensor edge driver for the Xiaomi Mijia Smart Light Sensor. Mine has been working flawlessly with this edge driver up until now.

Rebooting the hub does nothing, and I have’t tried removing the device and rejoining it yet.

image

image

image
image1172×189 17.8 KB

image
image1172×189 18.8 KB

EDIT:

Rebooting the hub does nothing, and rejoining the device made it worse. Now it reports nothing at all, not even catchall messages when the button is pressed. It’s broke broke.

I checked my other light sensor, and it’s completely dead and not reporting and I didn’t reset and rejoin that one. It just stopped working the second the updated driver showed up.

2

Hi, Could you let me know the exact model name of your sensor device?
I wondering if it is Aqara Illuminance Sensor T1 / GZCGQ11LM or not.
Or
If you’re familir with SmartThings CLI,
You can see the fingerprint from smartthings devices {deviceId} -y command.
The you can see deviceManufacturerCode and modelName. Could you kindly let me know those?

It should be some like

deviceManufacturerCode: LUMI
manufacturerName: SmartThingsCommunity
deviceModel: lumi.sen_ill.agl01
3

Hi @kwanghui , I have two of these that were working great until the last driver update:

image
image494×797 20.7 KB

1 Like
4

It’s exactly this scenario why I suggested that there must be an option for the user to “freeze” a given driver and exempt it from automatic updating. This very same problem happens on all other software, so there was never a reason to believe it wouldn’t happen in Smartthings, too.
Maybe Samsung will listen to this request if more people demand it!

4 Likes
5

This is a strange behavior, as your model (lumi.sen_ill.mgl01) doesn’t match with the recent commit (lumi.sen_ill.agl01)

Also, I don’t know why this PR was accepted as it uses custom zigbee cluster (0xFCC0).
Maybe they are starting to accept it for certified devices.

Submission Criteria

Pull requests will be denied if they contain any of the following:

  • Multiple devices per certification request.
  • Custom Capabilities, such as those that are not in the SmartThings namespace.
  • Custom Preferences, such as those that are not in the SmartThings namespace.
  • The device uses a custom Zigbee, Z-Wave, Matter cluster.
  • A duplicate fingerprint already in use by another SmartThings Edge Driver
  • When possible, manufacturer-specific names should not be used in naming a profile.

Source: Certify Your Device | Developer Documentation | SmartThings

Anyway, I wasn’t able to identify just looking the code how this commit could affect your model. Everything seems ok.

6

I haven’t looked at the code to see why either, but I plan to look through that over the next day or two.

7

I’m not seeing anything in your hub logs or the code that might explain this (they may have cut off too soon, not sure). I’ve put up a channel that has the prior version of the driver (what’s currently on the default channel) and you can switch your driver over to that one and see if it fixes your problem. If it does we’ll have to figure out what the issue is, but we can at least know not to release the changes to the default channel.

Channel invite:

1 Like
8

Awesome, thank you! I’ll get to this as soon as I get through a few meetings this afternoon and I’ll let you know.

1 Like
9

@steven.green one of my sensors automatically switched to your driver without me having to do a thing and it’s back to working. This is the one that I haven’t touched this whole time:

image
image493×801 21.1 KB

image

The one I posted originally went offline when I switched it, so give me a few minutes to finish up a few things and I’ll go investigate.

10

Based on what you posted, the driverId is still the same as the broken one from earlier (a8…75), so it doesn’t look like it’s actually switched.

11

Yeah, i literally just saw that. Puzzling…

EDIT. Last meeting finished. I can focus on this a lot better. Let me see what’s up with the other sensor.

12

Is there any significance in PROVISIONED v TYPED for the devices? I don’t know too much about PROVISIONED but I know zilch about TYPED. I just wondered why they would be different.

1 Like
13

Hi @steven.green , ok got the other one back online:

image

Note that the one I’ve never touched doesn’t have battery capability listed, which the previous version didn’t have either:

image

I’m not sure what changed to get these working again, but something changed.

14

Since you deleted and re-added, the profile they fingerprint to might have changed.

i.e., you added before we had a generic fingerprint that assumed battery support for devices that support the power management cluster, which happened in July of last year.

I’m happy to hear everything is working again, though I don’t think anything has changed on our end. Hopefully this doesn’t happen for you again, but please raise the issue again if it does.

2 Likes
15

Thanks for your help Steven. This is the first device I ever had do this when a driver updated, so I’m not too worried. Things on my end have been working so well lately that this one took me off guard.

2 Likes