[RELEASE] Xiaomi Drivers with Health Status and Zigbee2MQTT

[PunchCardPgmr]

I hear ya. And that's my experience and feeling about some other less popular sensors I have in use which some other folks have on the shelf.

I guess I'm just saying.... there's a certain consistent across-the-board "resume of reliability" that should come with the sensors we support with our collective time and money. Buying ONE of these wasn't a bad dice roll and I will keep trying.

[birdslikewires]

Okay, there's a v1.06 of this driver now. Either update manually or through Hubitat Package Manager.

You will need to short-tap the reset button to wake up the light sensor, then click the Configure button within a couple of seconds (before it goes back to sleep). If all is well, and you have the Info log turned on, you should see this in your log:

Configuration : Received by device.

I won't be around in a few hours, but drop a message back here and let me know how it goes. It's safe to do this multiple times, so if it doesn't work the first time, try again. The log message should be received within 5 seconds of hitting the Configure button.

[PunchCardPgmr]

[PunchCardPgmr]

re-paired and getting more now...

Well, I've been through quite a two step. Had the above data...thought re-pairing was the charm and if it worked once after your instructions it would work even better a second time. This time I was back to nothing, including even the button not working. On C5 updated to latest HE SW.
+++
Decided to take the sensor to a second hub (on C5 on older SW 2.2.8.156).

Same deal, back to nothing. Did some resets on the unit, got the button working again, did your instructions, got set/received...no outcome. So, I removed the device from HE, reset the device, repaired and boom...all the above data reappeared...no lux tho. I'm leaving it alone for the night to see if that shows up. Most flaky temperamental device I've ever tried to pair.

--------------------FYI logs from C5 running 2.2.8.156 -----------------------

dev:2552022-02-19 19:52:03.683 infoLUM28C : Preferences Updated

dev:2552022-02-19 19:52:03.630 infoLUM28C : Configuration : Hub settings complete.

dev:2552022-02-19 19:51:53.388 infoLUM28C : Trigger : Button Pressed

dev:2552022-02-19 19:51:52.996 errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 266 (method parse)

dev:2552022-02-19 19:51:48.037 errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 266 (method parse)

dev:2552022-02-19 19:51:37.865 infoXiaomi Mijia Smart Light Sensor GZCGQ01LM : Trigger : Button Pressed

dev:2552022-02-19 19:51:29.218 infoXiaomi Mijia Smart Light Sensor GZCGQ01LM : Configuration : Received by device.

dev:2552022-02-19 19:51:28.894 infoXiaomi Mijia Smart Light Sensor GZCGQ01LM : Trigger : Button Pressed

and another slice of log after turning on debug/trace

dev:2562022-02-19 20:16:57.708 traceLUM28D : parse() : catchall: 0104 0001 01 01 0040 00 9BFA 00 00 0000 07 01 00

dev:2562022-02-19 20:16:57.206 errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 266 (method parse)

dev:2562022-02-19 20:16:57.198 traceLUM28D : processMap() : [raw:9BFA0104000A0000210642, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:4206, clusterInt:1024, attrInt:0]

dev:2562022-02-19 20:16:57.195 debugLUM28D : Parse : Processing against Zigbee cluster specification.

dev:2562022-02-19 20:16:57.193 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000210642, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 0642

dev:2562022-02-19 20:16:55.998 debugLUM28D : Skipped : Bind Response

dev:2562022-02-19 20:16:55.995 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 9000, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[90, 00]]

dev:2562022-02-19 20:16:55.992 debugLUM28D : Parse : Processing against Zigbee cluster specification.

[PunchCardPgmr]

OK I have spent a good deal of time in an old thread that the post linked below was in. It is OBVIOUS that everything I have been experiencing is on the same road a lot of other folks have been down.

For comparison I thought I would just see what this driver did ...and I got a changing lumen number intermediately after a simple driver change (no reset or re-pairing of the device). Donno how valid they are yet.

I'm not sure the author is even maintaining this or even intended it to have legs beyond his own use. I have not spent enough time to really know how I feel about using/trusting it long term. But I'd love to know what's different to cause this to work. The bloomin fingerprint coded in doesn't even have the correct manufacture name if that matters much.

Anyway, thought you'd appreciate knowing about this before you did anything more. The key may be in his code. OR...on the other hand, as I've read 100 times over, it may be in the flippin sequence of handling/resetting/button pushing of the dang device. Who knows.

Xiaomi smart light sensor

Please find here following. Please consider also it is still to clean up and to refine. Even more the value is illuminance not lux. I'll post again here asap it is finished. But .. it works. pure illuminance device. fast and precise. it is possible to configure min and max time for reporting (illuminance reading) that is the minimum and maximum interval between value readings. In my driver it is configurable (but it is only for debug) /** * My Xiaomi Mijia Smart Light Sensor * * Li…

[birdslikewires]

Okay, there's a v1.08 now. Please give that a shot if you have the patience.

The change in this version is a complete guess. I have no idea why the error doesn't appear on my system; or more precisely, I don't know why it does appear on yours, because after showing us a message containing illuminance data in the log, the error goes on to contradict this by complaining that the value is null.

This new version grabs any value early, catches the fault condition and generates a warning rather than bombing out with an error.

[PunchCardPgmr]

OK, thanks for YOUR patience. Maybe the outcome will help others.

I'm giving you a couple things here. First is a screen capture of the Status screen for the device AFTER switching to your driver. That was pretty much the immediate display except for the Config: set/received text. The illuminance : 228.03 has not changed since it all came up under your driver.

I'm also giving you the log with the stream of info from just before changing to your driver, and then after.....through short pressing the button and hitting config. As you can see his driver was throwing an error as well. I will note I am currently running this testing on a C-5 with FW 2.2.8.156 whereas when we first started this journey I had upgraded my other C-5 to the latest.

By the way both in your driver and this other one this is always the State Variable of rawlLux : 0

dev:2562022-02-20 12:57:59.373 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

dev:2562022-02-20 12:57:29.501 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

dev:2562022-02-20 12:56:59.627 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

TIME BREAK - Above shows example slice of logged errors coming in now.

dev:2562022-02-20 12:31:50.887 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

dev:2562022-02-20 12:31:21.012 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

dev:2562022-02-20 12:30:47.959 infoLUM28D : Configuration : Received by device.

dev:2562022-02-20 12:30:47.146 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

dev:2562022-02-20 12:30:45.794 traceLUM28D : Trace Logging : false

dev:2562022-02-20 12:30:45.792 debugLUM28D : Debug Logging : false

dev:2562022-02-20 12:30:45.791 infoLUM28D : Info Logging : true

dev:2562022-02-20 12:30:45.789 infoLUM28D : Preferences Updated

dev:2562022-02-20 12:30:45.724 infoLUM28D : Configuration : Hub settings complete.

dev:2562022-02-20 12:30:44.968 infoLUM28D : Trigger : Button Pressed

dev:2562022-02-20 12:29:47.482 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)

DRIVER CHANGED AT THIS POINT

dev:2562022-02-20 12:29:17.539 infoLUM28D: Illuminance is 228.03 lux

dev:2562022-02-20 12:28:47.660 infoLUM28D: Illuminance is 226.04 lux

dev:2562022-02-20 12:28:17.779 infoLUM28D: Illuminance is 228.03 lux

CUT OUT A BUNCH OF LUX MSGS FOR BREVITY

dev:2562022-02-20 12:24:18.762 infoLUM28D: Illuminance is 219.04 lux

dev:2562022-02-20 12:23:58.873 errororg.codehaus.groovy.runtime.InvokerInvocationException: groovy.lang.MissingMethodException: No signature of method: java.lang.String.div() is applicable for argument types: (java.lang.Integer) values: [1000]
Possible solutions: drop(int), is(java.lang.Object), wait(), trim(), size(), size() (method parse)

dev:2562022-02-20 12:23:48.881 infoLUM28D: Illuminance is 195.02 lux

dev:2562022-02-20 12:23:19.006 infoLUM28D: Illuminance is 211.03 lux

CUT OUT A BUNCH OF LUX MSGS FOR BREVITY

dev:2562022-02-20 12:20:49.622 infoLUM28D: Illuminance is 213.04 lux

dev:2562022-02-20 12:20:40.056 errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_r_brunialti_My_Xiaomi_Mijia_Smart_Light_Sensor_634.checkPresence() is applicable for argument types: () values: [] (method checkPresence)

dev:2562022-02-20 12:20:20.720 infoLUM28D: Illuminance is 194.03 lux

[PunchCardPgmr]

Thought a more detailed log w/ debug & trace on might help you.

[bobbles]

Hi @PunchCardPgmr
Just something you probably already know but if you highlight the logs and then click on the </> symbol it puts the highlighted text into it's own 'block' which can be scrolled up and down.
It keeps the post smaller.

[aaiyar]

@bobbles

if you highlight the logs and then click on the </> symbol it puts the highlighted text into it's own 'block' which can be scrolled up and down.

@PunchCardPgmr

Good suggestion from @bobbles. Also, sometimes, a screenshot of the logs is easier to read than a cut & paste of text.

[PunchCardPgmr]

Ahhh, no didn't know that trick yet.

Thanks.

Edit: OK guys, call me blind or old....either works, but I'm not getting the cut html block step you described.

Whoops, nevermind....got it.

dev:2562022-02-20 13:13:20.549 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)
dev:2562022-02-20 13:13:20.541 traceLUM28D : processMap() : [raw:9BFA0104000A000021565E, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:5E56, clusterInt:1024, attrInt:0]

Oh man, watch out boys...old dog learns new tricks !

[birdslikewires]

Oh, I see what's happening here - thank you for the debug and trace logs, that's the ticket! We've fixed one problem and bumped into the next, caused by the previous driver, I believe.

You were using Markus's driver before? Regardless, whichever driver it was reported the lux values with a decimal point, which is incompatible with what's expected in HE. This previous lux value was retained even when the driver is switched and caused updating of the lux reading on my driver to fail as the variable types are not the same.

All this is a longwinded way of saying "try v1.09". It should deal with the issue by resetting the previous value to zero when receiving a decimal lux reading. If for some reason it errors out again, hit Configure one more time and the illuminance values should be forcibly reset to zero.

[PunchCardPgmr]

Whoohoooo !!! Now we're talkin !

Thanks!

Now you're going to be sorry you got this working on mine as I come up with a short list to get this to quiet down to less frequent reporting and work only on a delta/threshold, and do so quickly enough to catch the flash of a flashlight or headlights passing through the sensor's field of view. From what I have seen so far I think I had too high an expectation for that.

Thanks a bunch for sticking with this for me. Such a good feeling to not have this have been a waste of time and money. Not to mention the collegial collaboration of folk across the pond to make it work! Great stuff in this Community.

----------------for your full cycle look back---------------------------
Leaving you the log from the last lux posting from that other driver (Markus spinoff) through the change over to yours.

dev:2562022-02-21 09:50:26.809 debugLUM28D : Lux : Darkening from 8 to 7 lux.
dev:2562022-02-21 09:50:26.806 traceLUM28D : processMap() : [raw:9BFA0104000A0000214723, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2347, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:50:26.804 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:50:26.801 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214723, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4723
dev:2562022-02-21 09:50:02.046 traceLUM28D : checkPresence() : Report interval is 3600000 ms, timeout is 8400000 ms.
dev:2562022-02-21 09:50:02.044 traceLUM28D : checkPresence() : 1645462202025 - 1645462137193 = 64832
dev:2562022-02-21 09:50:02.042 debugLUM28D : Presence : Last presence report 64 seconds ago.
dev:2562022-02-21 09:48:57.212 debugLUM28D : Lux : Brightening from 7 to 8 lux.
dev:2562022-02-21 09:48:57.201 traceLUM28D : processMap() : [raw:9BFA0104000A0000214725, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2547, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:48:57.198 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:48:57.196 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214725, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4725
dev:2562022-02-21 09:48:27.328 debugLUM28D : Lux : Darkening from 8 to 7 lux.
dev:2562022-02-21 09:48:27.325 traceLUM28D : processMap() : [raw:9BFA0104000A0000214723, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2347, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:48:27.322 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:48:27.320 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214723, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4723
dev:2562022-02-21 09:47:42.517 debugLUM28D : Lux : Variance of 0 (previously 9543, now 9543) is within tolerance.
dev:2562022-02-21 09:47:42.515 traceLUM28D : processMap() : [raw:9BFA0104000A0000214725, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2547, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:47:42.512 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:47:42.510 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214725, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4725
dev:2562022-02-21 09:46:12.840 traceLUM28D : Splurge! : [raw:catchall: 0000 0006 00 00 0040 00 9BFA 00 00 0000 00 00 DDFDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DD, FD, FF, 04, 01, 01, 19, 00, 00]]
dev:2562022-02-21 09:46:12.838 warnLUM28D : Received : endpoint: null, cluster: null, clusterId: 0006, attrId: null, command: 00 with value: null and 9 bits of data: [DD, FD, FF, 04, 01, 01, 19, 00, 00]
dev:2562022-02-21 09:46:12.836 warnLUM28D : UNKNOWN DATA! Please report these messages to the developer.
dev:2562022-02-21 09:46:12.829 traceLUM28D : processMap() : [raw:catchall: 0000 0006 00 00 0040 00 9BFA 00 00 0000 00 00 DDFDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DD, FD, FF, 04, 01, 01, 19, 00, 00]]
dev:2562022-02-21 09:46:12.827 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:46:12.825 traceLUM28D : parse() : catchall: 0000 0006 00 00 0040 00 9BFA 00 00 0000 00 00 DDFDFF040101190000
dev:2562022-02-21 09:45:43.015 debugLUM28D : Lux : Darkening from 14 to 8 lux.
dev:2562022-02-21 09:45:42.999 traceLUM28D : processMap() : [raw:9BFA0104000A0000214725, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2547, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:45:42.996 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:45:42.994 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214725, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4725
dev:2562022-02-21 09:45:13.056 debugLUM28D : Lux : Brightening from 10 to 14 lux.
dev:2562022-02-21 09:45:13.053 traceLUM28D : processMap() : [raw:9BFA0104000A000021F12D, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2DF1, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:45:13.050 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:45:13.048 traceLUM28D : parse() : read attr - raw: 9BFA0104000A000021F12D, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: F12D
dev:2562022-02-21 09:44:43.182 debugLUM28D : Lux : Brightening from 0 to 10 lux.
dev:2562022-02-21 09:44:43.179 traceLUM28D : processMap() : [raw:9BFA0104000A000021AE28, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:28AE, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:44:43.176 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:43.174 traceLUM28D : parse() : read attr - raw: 9BFA0104000A000021AE28, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: AE28
dev:2562022-02-21 09:44:17.239 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:17.236 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 2100, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[21, 00]]
dev:2562022-02-21 09:44:17.234 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:17.232 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 2100
dev:2562022-02-21 09:44:15.112 infoLUM28D : Configuration : Received by device.
dev:2562022-02-21 09:44:15.105 traceLUM28D : processMap() : [raw:catchall: 0104 0001 01 01 0040 00 9BFA 00 00 0000 07 01 00, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
dev:2562022-02-21 09:44:15.102 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:15.101 traceLUM28D : parse() : catchall: 0104 0001 01 01 0040 00 9BFA 00 00 0000 07 01 00
dev:2562022-02-21 09:44:13.645 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.642 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1E00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1E, 00]]
dev:2562022-02-21 09:44:13.640 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.638 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1E00
dev:2562022-02-21 09:44:13.505 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.502 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1D00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1D, 00]]
dev:2562022-02-21 09:44:13.500 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.498 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1D00
dev:2562022-02-21 09:44:13.475 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.472 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1C00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1C, 00]]
dev:2562022-02-21 09:44:13.470 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.468 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1C00
dev:2562022-02-21 09:44:13.240 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.237 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1B00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1B, 00]]
dev:2562022-02-21 09:44:13.234 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.232 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1B00
dev:2562022-02-21 09:44:12.967 traceLUM28D : Trace Logging : true
dev:2562022-02-21 09:44:12.966 debugLUM28D : Debug Logging : true
dev:2562022-02-21 09:44:12.965 infoLUM28D :  Info Logging : true
dev:2562022-02-21 09:44:12.964 infoLUM28D : Preferences Updated
dev:2562022-02-21 09:44:12.905 infoLUM28D : Configuration : Hub settings complete.
dev:2562022-02-21 09:44:12.844 traceLUM28D : sendZigbeeCommands received : [zdo bind 9BFA 0x01 0x01 0x0000 {54EF4410000C218C} {}, zdo bind 9BFA 0x01 0x01 0x0001 {54EF4410000C218C} {}, zdo bind 9BFA 0x01 0x01 0x0003 {54EF4410000C218C} {}, zdo bind 9BFA 0x01 0x01 0x0400 {54EF4410000C218C} {}, zdo bind 0x9BFA 0x01 0x01 0x0001 {54EF4410000C218C} {}, delay 2000, he cr 0x9BFA 0x01 1 32 32 3600 3600 {} {}, delay 2000, zdo bind 0x9BFA 0x01 0x01 0x0400 {54EF4410000C218C} {}, delay 2000, he cr 0x9BFA 0x01 1024 0 33 3 3600 {C800} {}, delay 2000]
dev:2562022-02-21 09:44:11.864 infoLUM28D : Trigger : Button Pressed
dev:2562022-02-21 09:44:11.861 traceLUM28D : processMap() : [raw:catchall: 0104 0003 01 FF 0040 00 9BFA 01 00 0000 01 00 , profileId:0104, clusterId:0003, clusterInt:3, sourceEndpoint:01, destinationEndpoint:FF, options:0040, messageType:00, dni:9BFA, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:00, data:[]]
dev:2562022-02-21 09:44:11.858 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:11.857 traceLUM28D : parse() : catchall: 0104 0003 01 FF 0040 00 9BFA 01 00 0000 01 00 
dev:2562022-02-21 09:44:08.354 debugLUM28D : Lux : Darkening from 100 to 0 lux.
dev:2562022-02-21 09:44:08.343 traceLUM28D : processMap() : [raw:9BFA0104000A0000210000, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:0000, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:44:08.340 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:08.338 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000210000, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 0000
dev:2562022-02-21 09:43:38.495 debugLUM28D : Lux : Brightening from 0 to 100 lux.
dev:2562022-02-21 09:43:38.482 traceLUM28D : processMap() : [raw:9BFA0104000A0000214C4E, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:4E4C, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:43:38.469 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:43:38.466 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214C4E, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4C4E
dev:2562022-02-21 09:43:35.383 traceLUM28D : Trace Logging : true
dev:2562022-02-21 09:43:35.382 debugLUM28D : Debug Logging : true
dev:2562022-02-21 09:43:35.380 infoLUM28D :  Info Logging : true
dev:2562022-02-21 09:43:35.379 infoLUM28D : Preferences Updated
dev:2562022-02-21 09:42:33.738 infoLUM28D: Illuminance is 101.02 lux

[PunchCardPgmr]

Questions:

1. Can the device be told to only report upon reaching a delta value from current value (or recent average). In my case I might not care to hear from the device unless say a 25 point increment or decrement has been indicated.

This appears to be discussed in this other thread from this point down:

Xiaomi smart light sensor

In your code I noticed you are using a variance value in order to avoid refresh illuminance display for small change values. Why do not use reportableChange parameter of the zigbee.configureReporting ? It should trigger the report only for changes bigger than reportableChange values (if I understood correctly...)

2. Experimenting I have seen the device screen update the lux value in as short as about 8 seconds and as high as about 15 seconds. What do you all know about what may be going on within the device with respect to sampling rate, and reporting. Do you think it is seeing every little flash (increment/decrement) and then either sending on a fixed sampling rate, waiting for stability, or averaging across a period.

I'm also a little confused by this discussion, when I had this driver in there I didn't see these interval settings having any effect:

Xiaomi smart light sensor

@markus May be I'm wrong but it seems to work (it reports only chages equal o higher than a trigger level). My report is as following: zigbee.configureReporting(0x0400, 0x0000, 0x21, (secondsMinLux == null ? 3000 : MinLux).intValue(), (MaxLux == null ? 30000 : secondsMaxLux).intValue(), 200, [:], msDelay) and the logs are: [image] the lux are not real lux but raw illuminance values(I have some problems using maths in groovy...)

I bring these questions up seeking to understand if everything that can be orchestrated on board this device is being taken advantage of.

Why?

Well, I realize most are using these devices to sense not-so-brief instances of lux changes dawn/sunset transitions, daylight, overcast, or even approximating cumulative luminance (i.e. light exposure per day in a greenhouse)... and step changes like lights being on.

BUT WHAT IF these could be used as preemptive or corroborating security alerts along with other sensors. Think of them like motion sensors for light. For example, picking up the brief flash of headlights down a drive, shining onto a building, or at gate at a time there shouldn't be (ignore having to deal with lightening for now but even that is an interesting application in itself, i.e. "flash counter"). Or how about triggering on a flashlight beam "spuriously illuminating" the interior of a building where complete darkness is the norm between hours x to y.

[jlv]

@birdslikewires

You were using Markus's driver before? Regardless, whichever driver it was reported the lux values with a decimal point, which is incompatible with what's expected in HE.

Yes, I hit that problem when I first tried to use them in a Rule. I set the "number of decimals" setting to 0. Later on I changed away from that driver.

[jlv]

@birdslikewires Do you know if this driver works with the similar looking Xiaomi Mi light sensor? People have reported not being able to get them to work in this other thread:

Does anyone know if there are Xiaomi Mi light sensor drivers?

Hi there. I've looked in the Xiaomi driver list but didn't see any driver for the Xiaomi Mi light sensor, so am hoping that someone out there knows of some (or any trick to get them going)? I've tried the Mijia drivers but I don't get any reading. I stupidly bought this in a rush and didn't realise I bought the wrong one. It's from Banggood so not going to bother sending back. If need be I'll get the Mijia one. Thanks Alan

(Especially since the Mijia light sensor seems discontinued)

[birdslikewires]

@PunchCardPgmr

Can the device be told to only report upon reaching a delta value from current value (or recent average).

Well, yes, in theory - though in practice it's something I'd prefer to avoid dealing with in the driver. My take on a driver is that the device should report in with the best, most accurate and timely data that it can and only "degrade" this if it clearly has a negative impact, say on the battery life of the device, or if the device needs "debouncing" in way that can't be handled by its firmware.

In this instance I'd say the delta is best dealt with in an app or rule. That way end users can have rules which are very responsive and ones that are more tolerant, all running from the same device.

@PunchCardPgmr

Experimenting I have seen the device screen update the lux value in as short as about 8 seconds and as high as about 15 seconds. What do you all know about what may be going on within the device with respect to sampling rate, and reporting. Do you think it is seeing every little flash (increment/decrement) and then either sending on a fixed sampling rate, waiting for stability, or averaging across a period.

As these are powered by one CR2450 cell my guess is that there's a sample-compare-transmit-sleep cycle going on. I think we're already at the limit of the transmission frequency (the driver asks for reports every 3 seconds, but the highest frequency I've ever seen is similar to yours, maybe every 6-8 seconds if the light level is constantly changing).

I don't think the GZCGQ01LM does see every change, but rather checks its sensor on a fixed interval. As radio transmission is likely the most energy demanding task it performs, it probably uses the tolerance and reporting interval to determine if it should bother "shouting out" the new value. If you flash a bright light at the sensor at just the right moment (when it takes its sample) then you'll get that big momentary jump in reported lux. But it is possible to shine a bright light at it for two or three seconds, remove the source and see no transmitted report at all.

@PunchCardPgmr

Think of them like motion sensors for light.

I think you could achieve something approaching this, so long as your source was present for at least 5 seconds, and assuming any of my supposition above is correct. There's definitely a hysteresis to the light sensor, so a bright source shone and then removed may well be sampled as a small ~200 lux variation.

So, headlights coming up a dark driveway? Yes, I think it would be reliable. Lightning? No chance. That's beyond the granularity the device can handle given the choices made in circuit design and firmware to achieve the very impressive battery life.

[birdslikewires]

@jlv

Do you know if this driver works with the similar looking Xiaomi Mi light sensor?

It should work perfectly with the one I can see in that thread. Mijia and Mi are one and the same; all of mine say "Mi" on the back. From Xiaomipedia:

Sadly I do suspect they've discontinued the sensor, I couldn't find any more on AliExpress, which is usually a sign, though they could simply be manufacturing higher volume items right now. Also, Mi/Mijia are not solely about home automation, perhaps it's a device they want to roll in to the Aqara ecosystem. Just guessing though.

Nice they're still in stock somewhere, though.

[marcaronson408]

@birdslikewires

Sadly I do suspect they've discontinued the sensor, I couldn't find any more on Aliexpress

I just ordered a couple of the the Xiaomi light sensors from here.

I have never ordered from techinn.com before, so I can't vouch for them. I placed the order on Sunday and received notification today (Monday) that they have shipped. I'll update this thread once they arrive and I've had a chance to test them.

Marc

[PunchCardPgmr]

@marcaronson408

I just ordered a couple of the the Xiaomi light sensors from here.

I have never ordered from techinn.com before

I'm curious where they will ship from and at what shipping charge.