Three prototypes can all seem to be "about brightness" while needing different information. A desk control needs to know where the user left a slider. An automatic indicator may only need a repeatable dark-versus-light decision. A display that claims a light level needs a measurement with a defined scale.
An Arduino forum project combining a photoresistor with a DHT sensor and a display shows the decision that follows the first reading: what should the number make the prototype do? On our bench we tried three inputs, a slide potentiometer, a GL5516 photoresistor module and a BH1750 light sensor, on RP2040 boards with MicroPython programs built in BIPES.
Start with a value you can control by hand
The slider program read ADC on GPIO26 once per second. Moving the slider produced a series of raw values: around 46800, then 30903, then values near 300. That shows a changing physical input reaching the program. It is a raw count, not brightness, volume or a percentage, and it is not a calibrated full-range control.
To use the slider as a brightness control, the next step is to measure the usable endpoints on the real part and map that span to an output command. We have not done that mapping or driven a lamp from this reading. Keep the raw input and the chosen output scale separate in the code, and decide what should happen if the slider is disconnected.
A photoresistor gives a relative input
The GL5516 module used the same ADC26 reading pattern. Covering or lighting the sensor changed the counts; readings around twelve thousand and twenty-two thousand appeared in the log. There was no conversion to lux and no comparison with a reference meter.
For a simple dark/light interaction, relative readings may be enough once you have tested the intended conditions. A threshold close to normal fluctuation can make an output chatter on and off. A common remedy is separate switch-on and switch-off thresholds, but that rule needs testing with the real sensor position and enclosure; we have not run it.
The BH1750 adds a digital measurement path
The BH1750 module talked over I2C0 with SDA on GPIO4 and SCL on GPIO5, after its driver library was installed. The module has an address-select switch for 0x23 or 0x5C; our code initialized address 35, which is 0x23 in decimal. If the switch and the code disagree, the sensor simply does not answer.
The driver reports values on a lux scale. Our log included roughly 25, 80.8, 305.8 and 2407.5 as the light changed. Those are more interpretable than an unlabeled ADC count. They still do not establish accuracy behind a tinted cover or next to a light source inside a product, because the module was open on the bench with no window fitted. The program printed values; it did not control an LED.
Choose the simplest input that answers the question
| Product question | Input to start with | What still has to be tested |
|---|---|---|
| Where did the user set it? | Slider or knob | Usable endpoints, mapping, disconnection |
| Is it dark enough to switch? | Photoresistor threshold | Threshold and hysteresis in the real enclosure |
| How bright is it, in units? | Digital light sensor | Accuracy through the window, nearby light sources |
Then verify the installed optical arrangement. A light sensor inside an enclosure sees what the window, the housing and any internal LEDs allow it to see. Put the sensor behind the actual window material, record readings in the lighting conditions the product will meet, and compare them with the open-bench values before setting thresholds.
Finally, decide what a display should say. A screen should communicate the resulting meaning, such as "too dark to read," rather than exposing more decimal places of a number nobody has calibrated.