Heads up on the pairing. Pair this device as close to your hub as possible. Leave it there for a little while (minutes) and make sure that all the state data is correctly populated on the device page, before moving it to its final location.
1 Like
I'm out there now JUST about to ! Thanks.
EDIT:
What a P-I-T-A pairing.
So I take it if my Ikea Repeater happened to pick this up in the pairing step, that going through it is a No-No. I still don't see anything besides the data below when placed close to hub.
Doing as I'm told and reporting to developer 
@birdslikewires
Paired and sitting w/in a foot of hub. Got button push to register.
This seems to be an odd entry in the Schedule Field ?
EDIT:
Changed 3.06v battery (as delivered) to fresh 3.17v
Updated HE to latest SW which I really wasn't ready to do but...
And...no change. OK button press registers, nothing else yet.
Hmm, not in my experience. These are honestly the most reliable Xiaomi devices on my network. I don't want to go against the advice of @aaiyar but "pair in place" has always been my mantra. Here's my routing right now:
Parent child parameters
EzspGetParentChildParametersResponse [childCount=10, parentEui64=0000000000000000, parentNodeId=65535]
Child Data
child:[Living Room Lower Stairs Switch, 9DC8, type:EMBER_SLEEPY_END_DEVICE]
child:[01LM Left, 7D6E, type:EMBER_SLEEPY_END_DEVICE]
child:[Study Switches, B4C1, type:EMBER_SLEEPY_END_DEVICE]
child:[Hallway Central Switches, 4D1C, type:EMBER_SLEEPY_END_DEVICE]
child:[Cloakroom Back Door Switches, C3E3, type:EMBER_SLEEPY_END_DEVICE]
child:[Bedroom Switches, B6DF, type:EMBER_SLEEPY_END_DEVICE]
No information for Child 6
No information for Child 7
No information for Child 8
No information for Child 9
Neighbor Table Entry
[Secondary Repeater, 509F], LQI:253, age:4, inCost:3, outCost:7
[Primary Repeater, B441], LQI:255, age:4, inCost:1, outCost:1
Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [01LM Right, 59D6] via [Primary Repeater, B441]
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Secondary Repeater, 509F] via [Primary Repeater, B441]
status:Unused
status:Unused
status:Unused
These two ("01LM Left" and "01LM Right") are test GZCGQ01LM sensors sat on my desk, one going through an E1746 repeater, the other directly talking to the hub. The reponse-to-change time is the same for both and is set in their firmware (I've not attempted to change it in the driver nor seen anyone else do so). They usually communicate lux changes within about 5-8 seconds.
Thanks, that's just an Active End Point Response packet, which in my understanding is supposed to go from the device. Anyway, it shouldn't be causing any problems here.
Hmm, so when you short-press the reset button you see a "Button Pressed" message, but no lux messages? But you're getting battery reports?
1 Like
OK, I won't give up then. Below is the BEST I have gotten after multiple pairing and config attempts. Truth be told I tried "the other driver" and got pretty much the same.
I have wondered if I have done everything to "take this sensor to it's birth" such as hold button and replace battery or some such dance. Most I have done is a long press until blinking and the short presses of course. Did replace battery but did nothing special before/during/after that other than the long press that I thought was a ground level reset prep for pairing.
Was this a fresh-out-of-the-box sensor? Because I wonder... the ones I have were all previously used. Perhaps there's a once-only command which needs to be sent in order begin their light level reading.
In testing the driver I reset them by long-pressing the reset button until the little internal LED starts flashing - that's as reset as I know how to get them.
Well it was sold as fresh-out-of-box-new, and seemed so...but you never know. The first thing I did WAS a long press tho.
Here's the data that comes up on it:
- endpointId: 01
- model: lumi.sen_ill.mgl01
- application: 1B
- manufacturer: XIAOMI
Interesting. Mine are slightly different:
- endpointId: 01
- application: 15
- driver: v1.0.1.1123
- softwareBuild: 00000015
- model: lumi.sen_ill.mgl01
- firmwareMT: 126E-2388-00000015
- manufacturer: LUMI
FWIW, I didn't pair mine with this driver, but with Markus' driver. But I don't think that should make a difference.
Oh, I'm gonna go out on a limb and say that's a BOATLOAD different...as in something isn't totally/completely picked up or communicated. Hummm
So like back to trying to get a good pairing ! Thanks.
I was just thinking about the manufacturer field being different.
Sometimes takes a while for all of the values to be sent and the driver knows about the two variants from LUMI and XIAOMI. Interesting that your "application" IDs are different... even to mine! Again, not critical though.
- endpointId: 01
- model: lumi.sen_ill.mgl01
- application: 1A
- firmwareMT: 126E-2388-0000001A
- softwareBuild: 0000001A
- manufacturer: XIAOMI
That's one of mine.
Honestly, if you've got it to the point of reliably seeing when you press that button, just leave the device for an hour and see if it kicks into life. I'll make a note to check the initialisation when I next get chance.
2 Likes
OK guys, sounds like a good plan to leave it be.
I just reset and re-paired and realized THIS is what comes up in the discovery and initialization.
ID: 02A5
Manufacturer: XIAOMI
Product Name:
Model Number: lumi.sen_ill.mgl01
deviceTypeId: 568
manufacturer : XIAOMI
idAsInt : 1
inClusters : 0000,0400,0003,0001
endpointId : 01
profileId : 0104
application : 1B
outClusters : 0003
initialized : true
model : lumi.sen_ill.mgl01
stage : 4
But to be clear, that is NOT what is showing in the DATA field on the Device page.
That's great, the driver will have matched to it just fine. Don't worry about the content of the device data section, that'll sort itself out as the device reports in. Only other thing I'd try is holding the device up to a light, then covering it with your hand so it detects a large variation.
2 Likes
Well, so far it's working really reliably & fast as a ZigBee button, and I did need one of those albeit its small... 
Did the "light level shock treatment" and still no wakey wakey.
Such a bummer to get a new sensor delivered and not have that instant gratification of it working the way EVERYBODY ELSE'S DOES 
And let's not even talk about the hours of twiddling hoping on "just one more try". It's one thing to twiddle on a errant rule which you pretty much KNOW is your fault, this is different somehow LOL.
------------------------------ For Further Info --------------------------------
dev:2522022-02-18 16:46:46.930 infoLUM2 : Trigger : Button Pressed
dev:2522022-02-18 16:46:46.926 traceLUM2 : processMap() : [raw:catchall: 0104 0003 01 FF 0040 00 B06E 01 00 0000 01 00 , profileId:0104, clusterId:0003, clusterInt:3, sourceEndpoint:01, destinationEndpoint:FF, options:0040, messageType:00, dni:B06E, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:00, data:[]]
dev:2522022-02-18 16:46:46.924 debugLUM2 : Parse : Processing against Zigbee cluster specification.
dev:2522022-02-18 16:46:46.922 traceLUM2 : parse() : catchall: 0104 0003 01 FF 0040 00 B06E 01 00 0000 01 00
dev:2522022-02-18 16:46:33.000 traceLUM2 : Trace Logging : true
dev:2522022-02-18 16:46:32.999 debugLUM2 : Debug Logging : true
dev:2522022-02-18 16:46:32.997 infoLUM2 : Info Logging : true
dev:2522022-02-18 16:46:32.996 infoLUM2 : Preferences Updated
dev:2522022-02-18 16:46:13.570 infoLUM2 : Trigger : Button Pressed
sys:12022-02-18 16:46:05.538 Zigbee Discovery Stopped
dev:2522022-02-18 16:45:07.106 warnLUM2 : Received : endpoint: null, cluster: null, clusterId: 0013, attrId: null, command: 00 with value: null and 12 bits of data: [D3, 6E, B0, 8C, 21, 0C, 00, 10, 44, EF, 54, 84]
dev:2522022-02-18 16:45:07.103 warnLUM2 : UNKNOWN DATA! Please report these messages to the developer.
sys:12022-02-18 16:45:07.036 Found Previously Joined Zigbee Device LUM2
You should try software development one day. 
Hour seven, will this run be just another waste of time? 
2 Likes
Quick, send it out.
Every other vendor does.
(Now go to bed)
2 Likes
It's a new day....and there's nothing more to say.
Except, maybe, this....
(Vent on)
if a series of devices from a particular vendor...
garners THIS MUCH "it's a bear to get workin" talk in the Community,
and you experience that first hand at an "hobby hourly rate" 
of $xx/hr of screwin with it,
and not even "The Maxwell Man" sees a means to include/adopt the series as HE compatible,
(no matter the value in cool form factor and small price)
Then maybe it's not worth messing with. The ironic thing is, I've already spent the time equivalent of what it would have cost to buy a sensor 2-3x what I'd paid for this one. I thought I was gettin-a-deal !
Now I KNOW you guys have gotten this working...and let's say I got some lemon or some variant that makes mine different. I'm not going to throw shade on your fortune...
but my misfortune has me thinkin....it's often hard enough for a mainstream player like a Phillips, GE, Leviton, Sylvania, etc. to "get it right" how can we expect vendor X whose products are "here today/gone tomorrow" to "get it anywhere close/consistent" enough to write battle hardy drivers for. I mean just the fact that there's what....4-5 different driver initiatives that have been made for this vendor's stuff says something no?
(Vent off)
There is a reason the Aqara & Mijia devices are not on the Hubitat list of compatibility devices.
I've gotten mine cheap and have gotten them to work (with some effort), and I'm sorry you can't get them to work. Maybe you could send it to @birdslikewires to see if he can update the driver to make yours work.
2 Likes
FWIW, while I have used Xiaomi devices, including this sensor on Hubitat, I also have a separate zigbee network for Xiaomi Aqara/Mijia devices using zigbee2mqtt for the coordinator. I use mqtt/Node-RED/virtual devices to bring them into Hubitat for automations. This setup has been rock stable for ~2 years now. It even withstood the coordinator being offline for ~10 days during Hurricane Ida.
1 Like
Thanks for the thoughts and this idea...but.. I now feel like we're contributing to the delinquency of Xiaomi
Give me a few ticks. I have an idea.
2 Likes
