[RELEASE] Xiaomi Mijia Smart Light Sensor GZCGQ01LM (Zigbee 3.0)

⚙️ Custom Apps and Drivers
1

NOTE: Xiaomi / Aqara Zigbee devices are NOT officially supported or guaranteed to work on HE, with that said, many users use them very successfully and without issues.

Introduction

This is a driver for the Xiaomi Lux sensor, I received this device 3 days ago and wrote the driver the next day. As such, this is not well tested. It is however very close to feature complete. I release this earlier than I had planned since I see people are asking for a working driver.
Please report any issues in this thread.

CURRENT VERSION: v0.6.1.0501

Installation

  1. Make sure you have a good and stable Zigbee Mesh.
  2. Install the driver from here. There are general instruction here.
  3. Pair the device with HE. After having put HE in Discovery Mode, press the button on the sensor for 5 seconds. If it doesn't pair, try again. Holding for over 10 seconds will reset the device.
  4. Once the device is installed, go to the device page.
  5. Double-click the device button (on the device), then WAIT a few seconds, if battery status appear, then wait a bit longer for illuminance to display under Current States. Cover the device with your hand for a few seconds to generate a change.
  6. If illuminance doesn't show and about 20 seconds has passed, go back to step 4.
  7. You should now have a working devices. If you change "Minimum Update Time" you need to double click the device button a few times after saving that preference change.

NOTE: Minimum update time DOESN'T mean you will get an update every X seconds, if the change is not significant there will be no update. For details of what significant means, read the code :stuck_out_tongue:

Feature requests

If you have good ideas for feature requests, post them in the thread :wink:

Final Notes

This driver has been written from scratch and is NOT based on any other driver, some inspiration may have been derived from others, but the code is mine.

Calibration

There is NO offset setting in the driver since these sensors really are not stable enough over their full range to be possible to calibrate with just an offset. For a usable calibration you would need a good reference measurement as well as something like a linear regression calibration algorithm. Not even this may yield good results, but if you have the instruments to calibrate this, let me know and we can see about that linear regression.

FAQ

  1. "Your idea is stupid and slow and I don't like it" - Don't use the code
  2. "Your app/driver is crashing my Hub. I submitted a support ticket" - Don't do that, the fine folks at Hubitat Inc. do NOT maintain this code. This software is given free of charge with no support, implied or otherwise. I may still help...
  3. "The latest update broke it, FIX IT" - I do this for fun, please don't make it un-fun.
  4. "I have a great idea for a feature" - Go ahead and post it, I might get around to it...
  5. "You ignored my great idea" - See #2
  6. "I hate you for getting my hopes up, your app/driver is awful/buggy/stupid" - Ok, please write a better one so I can use it
  7. "Please fix your code, it's broken" - I write this because I enjoy coding. I will continue to support and provide updates as long as that remains the case.
  8. "I stole your code and made it soooo much better" - Thanks. Please post it so I can start using it.
  9. "You are awfully sarcastic, I don't like you" - That's ok, I don't need you to
    (thank you @thomas.c.howard for the original FAQ this one was based on)

ENJOY AND REPORT YOUR PROGRESS!

12 Likes
2

2020-04-28_10-36-33
2020-04-28_10-36-33945×1030 48.7 KB

Install Log:

2020-05-01_19-21-39
2020-05-01_19-21-391136×670 39.9 KB

3

Thanks for the driver!
I've got the following error pushing the button:

dev:11542020-04-28 10:20:43.869 errorjava.text.ParseException: Unparseable date: "1588058705536" on line 677 (parse)

1 Like
4

You replaced an existing driver which had epoch stored in that attribute. I will add a check to make sure the value is correct. Really want to avoid try - catch since code inside that can't be optimized.

5

Yes. Reinstalled it. It works now without errors. Thank you

1 Like
6

Next release will have a check for this and overwrite the value if in an unknown format.

7

Thanks for sharing your skills.

FYI - Have installed and removed a few times, device is discovered but illuminance does not show up.

Firstly using a repeater (innr power socket) and then within a few meters of the hub.

Will keep trying and feedback.

Hubitat Elevation Platform Version 2.2.0.122/Hardware Version Rev C-5

8

I've made some changes to the pairing and configuration process to make it easier, check the logs when pairing, the logs should look like this:

2020-05-01_19-21-39
2020-05-01_19-21-391136×670 39.9 KB

If you don't see the LUX, BIND and BATTERY events, follow the pressing of the button install instructions.

9

Thank you.

An anecdotal update:

  • I had an Innr Zigbee Power Socket near (5m) the hub. After powering this off and loading your new driver I can now see the illuminance setting.
  • I also have an Innr Zigbee Power Socket at the other end of the house that I use as a repeater. I paired the other light sensor (I bought 2) from this location, again using your new driver. Illuminance again is shown, however, rather than an out for example of 3 I see 3400000 (made up numbers.
  • I then remove the device from Hubitat, paired it next to the hub, with the new driver and th illuminance value was a-ok. I then moved this sensor back to the end of house location and to my surprise the hub still picks it up (not via repeater) and the illuminance values are ok and changing as you would expect.

Thanks again for sharing.

10

Hi Really hoping you can help. Been using 1 of these devices with out issue for a month now, driver has worked perfectly. Tried again today with a new sensor (same model, and it refuses to work) I get this in the logs but no battery or luminance will show. Got this from my hubs logs. Cant work out why one works fine and the other refuses too, have 6 more devices all showing the same issue, have tried removing and reading, double clicking the button but will not work. Hoping you can help me work out what's wrong as your driver has been brilliant.

dev:11232020-05-27 19:19:23.748 debugrefresh cmd: []

dev:11232020-05-27 19:19:23.742 debugdirty model = lumi.sen_ill.mgl01, clean model=lumi.sen_ill.mgl01

dev:11232020-05-27 19:19:23.557 infogetDriverVersion() = v0.6.1.0521b

dev:11232020-05-27 19:19:23.552 debugrefresh() model='lumi.sen_ill.mgl01'

dev:11232020-05-27 19:19:23.542 infoupdated()

sys:12020-05-27 19:18:31.511 infoZigbee Discovery Stopped

sys:12020-05-27 19:18:00.711 infoCreated Zigbee Device Zigbee - Xiaomi Mijia Smart Light Sensor (Zigbee 3.0)

dev:11232020-05-27 19:18:00.488 infogetDriverVersion() = v0.6.1.0521b

dev:11232020-05-27 19:18:00.480 infoinstalled()

sys:12020-05-27 19:17:58.556 infoInitializing Zigbee Device 04CF8CDF3C78C726, 9B5D

sys:12020-05-27 19:17:31.657 infoZigbee Discovery Running

--- Live Log Started, waiting for events ---

11

Asan update got 1 to work below are logs, showed an error that it suggests reporting.

ev:11532020-05-27 21:10:11.710 infoSending lux event (lux: 1.0, change: -6.0)

dev:11532020-05-27 21:10:01.789 infoSending lux event (lux: 7.0, change: -4.0)

dev:11532020-05-27 21:06:30.291 infoSending lux event (lux: 11.0, change: 11.0)

dev:11532020-05-27 21:06:20.231 infoSending lux event (lux: 0.0, change: -11.0)

dev:11532020-05-27 21:05:56.072 infoBattery voltage received - description:read attr - raw: 295C0100010A2000201F, dni: 295C, endpoint: 01, cluster: 0001, size: 0A, attrId: 0020, encoding: 20, command: 01, value: 1F | parseMap:[raw:295C0100010A2000201F, dni:295C, endpoint:01, cluster:0001, size:0A, attrId:0020, encoding:20, command:01, value:1F, clusterInt:1, attrInt:32, valueParsed:31]

dev:11532020-05-27 21:05:55.917 infoSending lux event (lux: 11.0, change: null)

dev:11532020-05-27 21:05:55.891 infoDevice confirmed BATTERY Report configuration ACCEPTED by the device

dev:11532020-05-27 21:05:55.608 infoDevice confirmed LUX Report configuration ACCEPTED by the device

dev:11532020-05-27 21:05:55.512 infoReceived BIND Confirmation with sequence number 0x12 (a total minimum of FOUR unique numbers expected, same number may repeat).

dev:11532020-05-27 21:05:55.277 infoReceived BIND Confirmation with sequence number 0x11 (a total minimum of FOUR unique numbers expected, same number may repeat).

dev:11532020-05-27 21:05:55.085 infoReceived BIND Confirmation with sequence number 0x10 (a total minimum of FOUR unique numbers expected, same number may repeat).

dev:11532020-05-27 21:05:55.064 infoReceived BIND Confirmation with sequence number 0x0F (a total minimum of FOUR unique numbers expected, same number may repeat).

dev:11532020-05-27 21:05:54.875 infoReceived BIND Confirmation with sequence number 0x0E (a total minimum of FOUR unique numbers expected, same number may repeat).

dev:11532020-05-27 21:05:54.706 infogetDriverVersion() = v0.6.1.0521b

dev:11532020-05-27 21:05:54.535 infoconfigureAdditional()

dev:11532020-05-27 21:05:01.459 infoNo VALID lastCheckin event available! This should be resolved by itself within 1 or 2 hours and is perfectly NORMAL as long as the same device don't get this multiple times per day...

dev:11532020-05-27 21:05:01.435 warnUnhandled Event PLEASE REPORT TO DEV - description:catchall: 0000 8005 00 00 0040 00 295C 00 00 0000 00 00 06005C290101 | msgMap:[raw:catchall: 0000 8005 00 00 0040 00 295C 00 00 0000 00 00 06005C290101, profileId:0000, clusterId:8005, clusterInt:32773, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:295C, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[06, 00, 5C, 29, 01, 01]]

dev:11532020-05-27 21:05:00.722 infogetDriverVersion() = v0.6.1.0521b

dev:11532020-05-27 21:05:00.708 infoinstalled()

12

You may have to pair the device again without removing it from HE. When pairing it is important the mesh is very good and stable since if all configuration commands are not received the device will not work. The warning is fine, I'll add that event to the driver, but it doesn't affect usage.

13

Hi @markus - hoping you can help me debug this.

I bought four of these. All of them paired okay. Two of them report battery & lux. The other two only report battery. I've tried re-pairing them, or removing and pairing several times. So far, no luck.

Here are the logs from the last pairing attempt for one of them.

Untitled
Untitled943×189 66.8 KB

I think the log shows that lux readings should work.

OTOH, the device page doesn't show lux at all ....

device-1892
device-1892877×291 26.8 KB

I've tried pairing close to the HE, close to different repeaters.

Any suggestions?

Thanks!

14

It does, the device has responded with an acceptance packet for that setting and once that is done it is supposed to work. It might take take a bit of time for the first reading to arrive, but shouldn't be more than a few minutes.
When you short press the button on the device it sends all configuration commands again, you could try that instead of re pairing.
If you do re pair, there is never a reason to first delete the device, that just makes it less likely the commands will run as expected. Holding the button until the device is fully reset and then pair again might be worth trying though.

Since lux readings should arrive early on I never set an initial value on these devices, so until you receive an actual reading nothing will show.

If this doesn't solve it I will see if I can reproduce this issue, I have three lux readers I don't use for anything yet.

15

I have waited overnight on one of them for lux readings to show - no go.

But I will try your other suggestions right now (re-pair after reset but without deleting the device, and short press of the button)

16

So I tried re-pair after reset, but without deleting the device. I am seeing a ridiculously high lux value that is not changing (if I cover it with my hand), and also an impossible battery value ...... :rofl:

Not sure what is going on. Anyway, here's the pairing log and the current states.

Untitled-2
Untitled-21203×218 81 KB

Untitled-3

17

That really doesn't look right, and there is one confirmation that is not received in that log. Now after pairing, try the short press of the button. Wait a few seconds between each press to not flood the device.

As for that LUX value, that is a first. Have you tried pairing these close to the hub? Some packets are not arriving as expected.
Do you have a Zigbee sniffer you can run with Wireshark?

18

Thank you very much :joy:

Yes. I am right on top of the hub.

Unfortunately not.

I also tried the short press of the button after pairing. Single press - did not help. I will re-pairing and try a single short press every 10 seconds.

19

Have you tried changing the batteries? There have been instances when Aqara devices have arrived with depleted/faulty batteries.

Yeah, I know, not much help there... :stuck_out_tongue:

Then we will switch to debug logs if we can't see what is wrong without them, that will have to do. A Zigbee sniffer would be able to say if packets are sent but ignored by the hub/a repeater. I have seen repeaters not forwarding packets due to routing issues. Not something you would see directly on the hub.

20

No. Will do right now.

Sorry to be taking up your time like this. I will also turn on debug logging.