There's a version of this conversation that ends in thirty seconds. Light sensors measure light. You put one in a room, you write an automation, your lamps come on when it's dim. Done. That's the take most coverage of lux-based lighting leads with, and it's not wrong, it's just the brochure. Because the moment you actually try to do it, you discover that the hard part was never the sensor. It's everything around the sensor.
And Daniel knows that better than most.
Daniel has asked us about home automation plenty of times, and his feelings about it are famously mixed. Years of Home Assistant have shown him both the brittleness and the genuine wonder, and he says outright that the thing he feels most positive about is using automation to sync lighting with the natural rhythm of the sun. The simple version works beautifully. Sunrise and sunset times are free for every location on earth, and he's got an automation that turns on the toilet night lights a few hours after dark and kills them at sunrise. No complaints.
But then Ireland.
Then Ireland. He grew up there, and he remembers the depth-of-winter storm days where even daytime was pretty dark. A clock-based automation cannot know that. So he wants the more nuanced approach, actually measuring light levels instead of offsetting from sun events. And then he asks the real question. What does the category of lux sensors actually look like? Which ecosystems are covered, Matter, Zigbee, whatever else. How do you position them, how do you bind the readings to automations. His example, instead of triggering the living room lights on sunset, you trigger on a specific lux value, so on a very dark winter day you get light exactly when it's needed, and you step off when it isn't. And he wonders whether that adds up to an energy-saving technique.
So the whole chain. Device, ecosystem, placement, calibration, automation logic, and the savings claim at the end.
The whole chain. And here's the tension I want to sit in for a second, because he calls this the aspect of home automation he feels most positive about, and it is also a perfect specimen of the thing that drives him mad. Measuring light sounds like the simplest possible job. Doing it well turns out to involve device selection, placement decisions, calibration, and one specific bug that will bite every single person who tries this.
The bug is the best part. We'll get there.
Hardware first. What's actually out there?
The community standard is the Aqara Light Sensor T1, model GZCGQ11LM. Zero to eighty-three thousand lux, which is a wide range. Accuracy is plus or minus two percent under incandescent light, plus or minus five percent for other visible sources. It runs on a CR2450 coin cell, one to two years. And critically, it pairs directly to any Zigbee2MQTT coordinator with no Aqara hub, no cloud, no account.
Which is the whole reason people love it.
It exposes four entities. Illuminance, battery, voltage, and a configurable detection period, one to fifty-nine seconds, default somewhere around ten to thirty. And it's event-driven, meaning it only reports on a change in light level. Which produces a confusing first experience, because right after you pair it, the illuminance entity just says unavailable until the light in the room actually changes.
So the sensor is working fine and the dashboard is telling you it's broken.
Every time. Wave your hand over it and it wakes up.
What's the catch?
Supply. There's a Home Assistant community thread from March of last year where a user says the T1 and its predecessor seem to be harder to get by the minute, wonders if they might be discontinued, and says they haven't found a similar alternative. That's a real risk if you're standardizing a whole house on one device.
One device, whole house, and the manufacturer quietly walks away. That's not a sensor problem, that's a procurement problem.
There's also the Xiaomi Mijia Light Intensity Sensor, the GZCGQ01LM. Small round Zigbee puck, one of the cheapest ways to get a real lux reading into Home Assistant without touching the Mi Home app. Community reports it caps around ten thousand lux, and it's frequently out of stock.
Ten thousand is fine for a living room. That's direct sun territory.
It's fine for light control. It is not fine if you want to grow anything, and that's where the cheap end of the market really shows its hand. The AliExpress and Tuya Zigbee lux sensors commonly cap at zero to one thousand lux.
One thousand.
Which is perfectly adequate for deciding whether to turn a lamp on, and completely useless for agriculture, because a plant in a window sees numbers that sensor will never report. If you're buying a lux sensor, the range is the first spec to check and the one nobody advertises clearly.
Here's the thing that surprised me when I went looking. Dedicated lux sensors are rare. Most lux readings in Home Assistant don't come from a lux sensor at all. They come bundled into motion sensors.
That's the common path, yes. The IKEA VALLHORN motion sensor constantly reports illuminance in lux, every few seconds. Philips Hue motion sensors report lux. The SONOFF SenseGuard Motion Gen2 advertises an independent lux sensor with precise lux conditions and up to six months of illumination history. The Fantem ZB003-X exposes illuminance plus a percentual calibration offset, though you can only set that calibration when it's powered over USB. There's a Haozee Zigbee PIR plus lux two-in-one marketed as native Home Assistant and Zigbee2MQTT compatible.
And then there's the FP1E.
The Aqara FP1E presence sensor has no lux sensor at all. There's a forum post from December 2024 where a user says they hadn't realized it, and that since most lux is built into motion and presence sensors, they weren't sure why the FP1E omitted one. They had to add a separate device.
A presence sensor that knows you're in the room and has no idea whether the room is lit. That's a strange thing to ship.
It's a cost decision, I assume. But it tells you where the category sits. Lux is treated as a bonus feature on a motion sensor, not as a product in its own right.
Which brings us to Matter, where the standard exists and the products mostly don't.
Matter defines the Illuminance Measurement cluster, zero x zero four zero zero. It's been in the spec since Matter 1.0. It's mandatory for the Light Sensor device type. Reporting is in lux, and the range the Espressif SDK implements goes from one lux up to three point five seven six million lux.
Three and a half million lux. What is that measuring, the surface of the sun?
It's a range field, not a claim about any real device. But here's the number that matters. As of the Matter survey updated in August, twenty-seven devices implement that cluster. Twenty-seven. And when you go through the list, it's the IKEA MYGGSPRAY, the Aqara FP300, the Aqara P2, the FP400, Eve Motion, a Lafaer radar occupancy sensor, a Heiman motion sensor, the Philips Hue Bridge, the DIRIGERA hub, various Aqara hubs. Almost all of them are motion or presence sensors with lux bolted on.
So Matter standardized the cluster and did not create the product category.
Exactly that. There is one that comes close to a dedicated device. A CSA-certified Light Sensor from a company called What's Matter, hardware model WM-2025-LS1.0. Its marketing is explicitly about turning lights on and off and adjusting blinds according to indoor brightness to improve energy efficiency.
The pitch is the episode.
It is. And there's the Eve Motion and Illuminance Sensor, Matter over Thread, one hundred twenty degree field of view, up to nine meters, motion plus ambient light in one device. Plus the THIRDREALITY Smart Night Light-T, Matter over Thread, three-in-one RGB night light with motion and an illumination sensor, local control, works with Home Assistant, Apple, Alexa, Google, Homey.
And if none of that suits you, you build one.
Espressif's ESP32 SDK now ships a MatterLightSensor class and a ZigbeeIlluminanceSensor class. So a DIY Matter or Zigbee lux sensor is a straightforward afternoon project now, which was not true a few years ago.
What about the rest of the ecosystem map? Z-Wave, EnOcean?
EnOcean has the EnoSense LUX, a battery-powered wireless illuminance sensor, CR2032, five years or more of life, eighty-one by forty-one by nine millimeters. Z-Wave, I could not find a current dedicated lux sensor. It shows up in an old comment about logging temperatures and light levels per room, but nothing current. The category is Zigbee and Matter over Thread, and that's essentially it.
One more piece of plumbing, because it explains why some sensors are chatty and some are quiet. Zigbee has the same illuminance cluster, zero x zero four zero zero, and it's configurable. Minimum and maximum reporting intervals, plus a delta threshold, a minimum change before it bothers to report.
That delta is the whole personality of the device. Set it low and your sensor talks constantly and eats its battery. Set it high and it misses the slow dimming of an overcast afternoon, which is precisely the thing you bought it to catch.
So we've got the hardware. Now what do you actually do with it? Placement first, because I think this is where most people get it wrong immediately.
The guidance is blunt. Avoid direct sunlight. The T1 can read up to eighty-three thousand lux without saturating, but if you put it in unobstructed sun, it will spend most of its time reporting maximum illuminance and give you no useful gradient for automation. You want it measuring the ambient light in the room, not the sun itself.
And orientation matters, because the light-sensitive element is on the face of the device.
Right. You face the sensor toward the light source you want to measure. Ceiling-mounted, facing down. Window-mounted, facing into the room. And a lot of people run more than one and combine them. There's a user on the forum who runs two sensors in the living room and takes the maximum of the two, and says it doesn't need to be incredibly accurate for them to determine whether they need to turn the lights on. Which is the correct attitude.
That's the sentence that should be printed on the box. It does not need to be incredibly accurate.
There's also a calibration offset available, a percentual adjustment, if the sensor sits behind glass or a filter. Most people don't need it given the plus or minus two to five percent spec.
Now the automation itself. What does binding a lux reading to a light actually look like?
The canonical pattern is a numeric state trigger on the illuminance entity. Trigger below fifty lux, with a time condition, say after two in the afternoon and before eleven at night, so it doesn't fire at three in the morning when the house is dark because everyone's asleep.
Give me the reference values, because fifty lux means nothing to me.
Fifty lux is a dim room. Two hundred lux is typical indoor ambient. Below ten lux is dark. One hundred to two thousand lux is diffuse indoor daylight. Ten thousand lux is direct bright sun.
So the trigger is basically "the room has gotten dim, and it's an hour when that's a problem."
And then you hit the bug. This is the one. If you turn the lights on at fifty lux, the lights themselves raise the reading above fifty. Which triggers the off. Which drops the reading back below fifty. Which triggers the on.
Forever.
Forever. It's a feedback loop, and it's the single most common way this automation fails. The fixes are an input boolean that tracks whether the lights were turned on by the automation, or a sustained condition on the trigger, requiring the reading to stay below the threshold for a full minute before it fires.
A minute of patience solves what a smarter sensor cannot.
That's the honest summary, yes.
And the inverse pattern, for anyone with blinds?
Trigger above ten thousand lux for two minutes to close the roller shades in direct sun. Same logic, opposite direction. And there's a widely used blueprint in the community, the Sensor Light Blueprint, that supports a lux value condition alongside motion, door, sun elevation, and time triggers. That's the standard way people gate motion lighting on ambient light rather than on a schedule.
So here's where I want to push, because Daniel asked whether this is an energy-saving technique, and I think the honest answer is more interesting than a yes.
The commercial numbers are real and they're big. Electric lighting accounts for twenty-six percent of all electricity used in United States commercial office buildings. That's the single largest category of use in those buildings. Daylight harvesting savings are estimated somewhere between twenty and sixty percent.
Twenty to sixty is a huge spread.
It is, and it's a spread because it depends enormously on the building. There's a field evaluation of five advanced lighting control systems where average site-level lighting energy savings came out at sixty-six percent, but when you break out what daylighting contributed at the controls level, it's an average of seven percent. Occupancy sensing was twenty-nine. Other controls six.
So the headline number is the whole system, and daylighting is a slice of it.
A slice. There's a California study of an office building showing twenty-six percent savings from task tuning alone, and a further forty-four percent from full advanced lighting control functionality. The Department of Energy estimates connected lighting is under one percent of United States luminaires but represents up to forty-five percent of total lighting energy savings potential. And by 2035, more than a third of installed commercial luminaires are expected to be connected.
Every one of those numbers is about office buildings.
Every one. Dimmable fixtures, photosensors, a facilities budget, and a lighting designer. And I looked for a residential equivalent, a study on lux-triggered lighting in homes, and I could not find one. I don't think it exists in any rigorous form.
So the honest answer to Daniel is that the energy-saving claim is real but borrowed. You're importing numbers from a completely different context.
Yes. Turning a lamp on at fifty lux instead of at sunset is a smaller, harder-to-quantify win. It might save something. Nobody has measured it in a way I'd cite.
Which is fine, because I don't think energy saving is actually why anyone does this. I think the reason is the Irish winter.
It's the emotional core of the whole topic, and it's not just Ireland. There's a comment from someone in northern Europe describing a day where at two in the afternoon they had to turn the lights on because it was so cloudy and dark, and their ten kilowatt solar array produced two kilowatt hours that entire day.
Two kilowatt hours from a ten kilowatt array. That's a panel system performing like a nightlight.
And there's a second problem that's even more specific. A commenter in Boston pointing out that the sun sets at four thirty in the afternoon there, but that's far too early to be sending your body signals that it's time to go to bed. That complaint is what pushed the Adaptive Lighting integration to add a maximum sunrise time and minimum sunset time, so you can clamp the virtual sun and stop the automation from dimming your house at half past four.
The clock says evening. Your body says it is the middle of the afternoon. The automation believes the clock.
And that's the argument for measuring instead of scheduling, in one line.
There's a market angle here too, and it's bleak.
There's a founder who started a company pursuing circadian lighting, called Twist, and said they felt they were twenty years too early, and that they didn't think average users would ever pay for a solution to this problem.
Twenty years too early and possibly forever too early. Which tells you who this is for. It's for the people who read the forum threads, not the people who buy a lamp.
The people who care about this are hobbyists. That's the market.
I want to go back to the accuracy spec for a second, because I think there's something hiding in it.
The plus or minus two percent.
It's under incandescent light. Plus or minus five percent for other visible light sources. Which means the accuracy figure you see quoted is the accuracy under a light source almost nobody uses anymore.
That's a real observation, and it points at something deeper than the spec sheet. The limitation of a cheap sensor isn't its lux range, it's its spectral response. How sensitive it is to different wavelengths doesn't match the human eye's photopic response. A sensor can read fifty lux under LED and seventy lux under daylight at the same actual illuminance, because its sensitivity curve is simply shaped differently than yours.
So the number is right and the meaning is wrong.
The number is right for a photodiode. It's wrong for a person.
Which is a strange thing to build an automation on. You're measuring the sensor's opinion of the light, not the light.
And that's why the calibration offset exists, and why most people skip it and take the maximum of two sensors instead. If you're deciding whether a room feels dim, you don't need photometric precision. You need a threshold that works in your house.
So the practical guidance survives the technical objection. Position it out of direct sun, face it at what you want to measure, combine two if you can, and don't chase accuracy you don't need.
Right. The accuracy matters if you're doing something scientific. It doesn't matter if you're deciding whether to turn on a lamp.
Which leaves the hysteresis problem as the real lesson. The sensor is fine. The light is fine. The automation is where it breaks.
The automation is where it always breaks.
Hilbert: The two percent is under incandescent. Five percent for everything else.
We said that.
Hilbert: You said it like it was a footnote. It's the whole thing. I spent a year doing light surveys for a firm that did daylighting retrofits, and the spectral response of a cheap sensor is what gets you, not the range. We had a meter that read fifty lux under the fluorescents in the office and seventy under daylight coming through the same window at the same actual illuminance. Same room, same time of day, two numbers seventy percent apart. The sensor's curve doesn't match the eye's. You can calibrate it out for one light source and you've just moved the error somewhere else.
So the calibration offset isn't a fix, it's a relocation.
Hilbert: And the placement problem is worse. I saw a system in a corner office where the sensor was mounted by the window. Sunny winter day, the sensor sees bright light, the automation kills the lights, and the room is still dark, because the light was coming from behind the sensor and the desk was in shadow. The sensor was measuring the window. Nobody in that room cared about the window.
It measured the thing it could see, not the thing that mattered.
Hilbert: That's what they do. You put it on the ceiling facing down and it measures the ceiling's opinion of the room. We used to mount them at desk height, facing away from the glass, and take a reading at nine in the morning and again at three in the afternoon, and if those two numbers were close, the placement was right. If they weren't, you moved the sensor. That was the whole method. Two readings a day and a decision about where to put a piece of plastic.
That's a better calibration procedure than anything in the documentation.
Hilbert: It's not a procedure. It's just looking at the room twice.
Which is the thing the automation can't do.
Hilbert: The automation can't look at anything. That's why you have to.
About spectral response, and it connects to the broader tension here. The sensor's number and the person's experience are two different measurements, and the automation only ever sees one of them.
And that's the real argument for why this is harder than it looks. The measure-don't-schedule thesis is correct. It's just that measurement drags in a whole set of problems that scheduling never had.
Let's land the thing Daniel actually asked about, which is whether dedicated lux sensors are going to become normal or stay a niche inside a niche.
The category is thin and it's getting thinner. The leading dedicated device may be going out of production. Matter standardized the cluster in version 1.0 and made it mandatory for the Light Sensor device type, and almost every device implementing it is a motion sensor with lux bolted on. Twenty-seven devices, and you can count the dedicated ones on one hand.
The standard is ahead of the products.
Years ahead. And the demand signal is weak, because the people who want this are the people who read forum threads, and there aren't enough of them to sustain a product line.
Which brings me to the thing I keep circling. The idea here is beautiful. Your house notices that the day went dark and turns the lights on, and it notices when the light comes back and steps off. That's the version of home automation that made Daniel feel wonder instead of frustration.
The implementation is device selection, placement, spectral response, calibration, hysteresis handling, and a supply chain where the best device might be discontinued.
The wonder is real. The fiddliness is real. And they're the same feature, not two different things.
The most common wrong belief about this whole topic is that a lux sensor is a lux sensor, and that a good accuracy spec means the number is trustworthy.
The number is trustworthy about the sensor. It's not trustworthy about the room, and it's definitely not trustworthy about the person sitting in it. Plus or minus two percent under a light source that's been obsolete for fifteen years.
Check the range, check the placement, and then check it again at three in the afternoon.
One open question to leave you with. If Matter has had the cluster since version 1.0 and the product category still hasn't materialized, what would actually have to change for dedicated lux sensors to become a normal thing to buy? Because right now the answer looks like nothing, and that's the interesting part.
The high-latitude problem isn't going away, though. The Irish winter is still going to be dark at two in the afternoon, and for the people who live with that, turning the lights on when it's dark rather than when the clock says sunset is a real improvement in a real day.
Thanks to Hilbert Flumingtop, our producer, who has measured more rooms than the rest of us have been in.
This has been My Weird Prompts.
If you want to send us something, email us at show at my weird prompts dot com. We'll be back soon.
