I've lost count of how many sites I've walked where the LUX sensor is treated as an afterthought. Someone wires up a multi-parameter unit, checks that CO2 and temperature look sane, and then ignores the light reading for the next three years. That's a mistake.
Here's the thing: LUX isn't just for dimming schedules. In industrial settings, light levels change for physical reasons—and those reasons often precede mechanical or electrical failure. I've used LUX trends to catch failing motor bearings, dirty filters, and even a failing UPS that was about to take down a whole control cabinet.
Let me walk you through how this works in practice, and why the OHTS1060's LUX channel (range 0 ~ 200000Lux) is more useful than most engineers give it credit for.
The Physics Behind the Trick
Every rotating machine vibrates. That vibration moves things—slightly. A motor base shifts, a belt tensioner drifts, a cooling fan blade bends. When that happens, the angle of incident light on a nearby sensor changes. Not by much, but by enough to show up as a slow drift in LUX readings over days or weeks.
Same story with filters. A clogged HVAC filter doesn't just raise static pressure—it changes how much light passes through the return air grille if the sensor is positioned near the airflow path. Dust accumulation on a sensor window does the same thing, but that's a linear decay. A sudden step change in LUX is usually mechanical.
The OHTS1060 measures illuminance up to 200000Lux, which covers everything from a dim corridor to direct sunlight. That range matters because you need headroom to see trends, not just absolute values.
What a Failure Signature Looks Like
Here's a real pattern I've seen three times now:
- Baseline: LUX reads steady at 480–520 for two weeks (indoor, artificial lighting).
- Slow drift: Over four days, it creeps up to 560. Then 590.
- Step change: On day five, it jumps to 720 in one hour.
- Failure: Day six, the motor seizes.
The drift was the motor base shifting, changing the angle of the sensor relative to the light source. The step change was the bearing cage breaking and the shaft moving laterally.
Key point: You don't need to know why the light changed. You just need to know that it did, and that it correlates with something you care about.
How to Set This Up on the OHTS1060
The OHTS1060 outputs all six parameters over RS485/ModBus-RTU. You're already polling CO2 and temperature—just add the LUX register to your poll cycle. It costs nothing extra.
Here's a typical register read sequence for a poll cycle:
| Parameter | Modbus Register (example) | Data Type | Unit |
|---|---|---|---|
| CO2 | 0x0001 | UINT16 | ppm |
| Temperature | 0x0002 | INT16 | 0.1°C |
| Humidity | 0x0003 | UINT16 | 0.1%RH |
| LUX | 0x0004 | UINT32 | Lux |
| Noise | 0x0006 | UINT16 | 0.1dB |
| Pressure | 0x0007 | UINT16 | 0.1kPa |
Register addresses are illustrative—refer to the OHTS1060 datasheet for the exact map.
Poll LUX once per minute. Store it in a rolling buffer. Calculate a 24-hour moving average and compare it to the 7-day average. If the difference exceeds 15%, flag it for inspection.
The Gotchas I've Hit
Sensor window contamination — The OHTS1060 has a louvered radiation shield design, which helps with solar loading and rain. But dust still settles. If you see a slow, monotonic decline in LUX over months, that's probably dirt, not a failing machine. Clean the window first, then re-baseline.
Light source aging — Fluorescent tubes and LEDs both lose output over time. A 10% drop over a year is normal. That's why you compare to your own 7-day average, not to an absolute threshold.
Time of day — If the sensor sees any daylight, you need to timestamp your readings. Compare LUX at the same time of day, not raw values. I've seen engineers chase a "fault" that was just the sun coming through a window at a different angle in spring.
Baud rate — The OHTS1060 supports 1200 ~ 115200 bit/s. I run mine at 9600 for long cable runs. At 115200, you'll get more CRC-16 errors on marginal wiring. If you see intermittent read failures, drop the baud rate before you blame the sensor.
The Procedure That Works
Here's the field procedure I use for LUX-based failure prediction:
- Install the OHTS1060 so the LUX sensor faces the dominant light source in the area—typically a ceiling fixture or a window. Avoid direct sun if possible; the 200000Lux range handles it, but you'll get better resolution indoors.
- Baseline for 7 days. Log LUX every minute. Compute the daily average.
- Set an alert when the 1-hour rolling average deviates more than 15% from the 7-day average at the same time of day.
- When the alert fires, physically inspect the area. Look for: loose mounts, belt wear, bearing noise, filter condition.
- If nothing's wrong, clean the sensor window and re-baseline. If the trend returns, you have a real mechanical issue.
I've caught two bearing failures and one loose motor mount this way. Each time, the LUX trend gave me 3–5 days of lead time before the actual failure. That's enough to schedule a replacement during a planned shutdown instead of an emergency one.
The Bottom Line
The LUX channel on the OHTS1060 isn't just for lighting control. It's a free vibration and alignment indicator that costs you zero extra hardware. If you're already polling the unit for CO2 and temperature, you're one register read away from a predictive maintenance signal that most sites completely ignore.
Start logging LUX today. In a week you'll have a baseline. In a month you'll have a trend. And the first time it catches a failing bearing, you'll wonder why you didn't do this years ago.
If you're setting up a new monitoring point and want to talk through sensor placement or Modbus polling strategy, get in touch—I've got opinions on both.