I installed my first Mijia Lux sensor today. Everything went smoothly once I read your instructions 
Thanks so much for writing and sharing this code 
John
2 Likes
Thanks! I just moved one of these over from SmartThings and this seems to be working fine. In fact, I had an easier time pairing it here than over there.
2 Likes
I got two of them, and both have -500% battery, and 3576843.0 Lux.
Tried a few times, already. no luck so far.
dev:3152020-08-29 01:48:26.724 pm infoReceived BIND Confirmation with sequence number 0xA8 (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:26.613 pm infoBattery voltage received - description:read attr - raw: F1AA0100010A20002000, dni: F1AA, endpoint: 01, cluster: 0001, size: 0A, attrId: 0020, encoding: 20, command: 01, value: 00 | parseMap:[raw:F1AA0100010A20002000, dni:F1AA, endpoint:01, cluster:0001, size:0A, attrId:0020, encoding:20, command:01, value:00, clusterInt:1, attrInt:32, valueParsed:0]
dev:3152020-08-29 01:48:26.425 pm infoDevice confirmed LUX Report configuration ACCEPTED by the device
dev:3152020-08-29 01:48:26.317 pm infoReceived BIND Confirmation with sequence number 0x9F (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:25.824 pm infoReceived BIND Confirmation with sequence number 0xB3 (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:25.718 pm infoReceived BIND Confirmation with sequence number 0xB1 (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:25.516 pm infoReceived BIND Confirmation with sequence number 0xA7 (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:25.441 pm infoSending lux event (lux: 3576843.0, change: null)
dev:3152020-08-29 01:48:25.253 pm infoDevice confirmed BATTERY Report configuration ACCEPTED by the device
dev:3152020-08-29 01:48:25.252 pm infoReceived BIND Confirmation with sequence number 0x7F (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:25.106 pm infoDevice confirmed LUX Report configuration ACCEPTED by the device
dev:3152020-08-29 01:48:24.899 pm infoReceived BIND Confirmation with sequence number 0x9F (a total minimum of FOUR unique numbers expected, same number may repeat).
dev:3152020-08-29 01:48:24.836 pm infoReceived BIND Confirmation with sequence number 0x9E (a total minimum of FOUR unique numbers expected, same number may repeat).
I was pairing them next to the environment sensor repeater, so only 3 out of the 4 bind confirmation were received.
when I moved closer to the hub, they paired and got both battery and lux correctly.
2 Likes
I had trouble with one of these. First it joined but I never got the battery or illuminance. Tried rejoining with the same result. Deleted the device from HE and tried rejoining but it would hang up on "Initializing" and never finish. Tried placing the device next to the nearest repeater and got the same result, namely stuck on "Initializing".
Finally placed the device right by my hub, did the long press reset (about 10 secs) and then started the Zigbee join and it found the device and initialized it right away. A single short press click and the battery and lux came through right away.
Just something to try. Thanks for the driver Markus. I was happy when I saw that it was you who wrote it.
Markus, just as an aside I was hoping I could get a sub-second response rate on these to lux changes. My idea was to have the action of a regular light bulb turning on\off act as the trigger for turning other smart devices on\off. In practice I get a response time of about 3 seconds when "Minimum Update Time" is set to 1. I looked at the driver and it seems that the "secondsMinLux" must be an integer in the range of 1 to 3600.
Is there any way to make the response faster? Just curious. I don't have a specific plan but these were only $10 on AliExpress so I bought a couple for the fun of it.
I think something funky is going on, because I get exactly the same thing now - though previously I had the device paired and working perfectly. I would even have described it as my most reliable Xiaomi device!
I will break my own rules and take it to the hub to re-pair, as described by @garyjmilne, to see what happens. 
Different from my symptoms as I never got any reading for battery or lux but I hope it works for you.
mine worked perfectly so far after directly paired with hub.
Thanks, folks. Because it's a battery-powered end point device I don't it being on my security mesh, so I tried again on that. Didn't take it anywhere, it just paired through the Trådfri repeater closest to the hub. Took the button-press to get it to start reporting, but it does appear to be back in action.
1 Like
My turn, also bought a three pack from Aliexpress, also had issues pairing correctly.
Initially all three were not showing illuminance or battery levels.
Pressed for 10 sec. and re-paired, one good and the others were sort of working.
Noticed that the two that weren't working correctly, the short push on the side button didn't get the led to flash.
Tried again and all's good.
Thanks again Markus.
1 Like
Hi @markus,
I am trying to have the sensor report lux every 3 minutes (if there is a change). I thought perhaps this would do that.
The reports are occurring sometimes several times a minute to any time in between 1 and 2 minutes.
I think I need some schooling as to what this setting does.
@markus,
Just wanted to say thanks for a great drive. I installed my first 2 sensors a month ago and they have been working so well I just added 2 more. Knowing the light level in a room makes the automation so much better.
1 Like
This was a temporary issue in that release, the latest one this should not occur.
1 Like
This is hard to achieve properly, it doesn't really take these settings as expected, there is no true pattern to what it really does with the settings, they do change the interval and behaviour, just not as expected. I don't think I have a good answer to you regarding this. It was a rather long while since I worked on this device type and I can't remember more without checking again.
Not surprised that the device can't do it. I'm using RM repeat every 3 minutes to sample. Doesn't seem to be overly cpu intensive. I hoped that doing this in the device handler would be more efficient. PS. This is not a feature request.
Unless the device wakes up to listen for a request there won't be an update, mostly it will just get any updates that would be there anyway, the limits are more in terms of amount changed and not time. I don't know what exactly you need the constant updates for, but I don't think it will work from RM to get them any faster than they are sent anyway. The only true solution would be to figure out how exactly these devices behave when sending these settings, they are most definitely not following the standard.
@markus,
I have the sensor in an east pointing window pointing up into the sky. I am using the lux reading as a poor man's CT sensor. As the lux changes through the day the CT of the room lights change.
The Xiaomi Lux sensor is impressively sensitive detecting small changes over a wide range of lux values. My problem is too many events in too short of time. I need to filter the events down.
The 3 minute interval is fast enough, I don't need to have the CT change any quicker. I have 2 more layers of filters before any command hits the bulbs. All these filters in an attempt to not overload the hub and mesh. The setup seems to be working well enough.
And for kicks I have another sensor measuring the room lux. That one controls which lights are on and how bright they are.
