[Published to DEV.to | Target: Charlyn]
You read the voltage from your LDR. It says 842. Is that light? Dark? Your code has an if reading > 500 and it works, so... the sensor knows, right?
Wrong.
The sensor is just a resistor that changes with light. It doesn't know anything. And the moment you start writing if is_day(), you've already smuggled in a human concept that no electrons inside your hardware can find.
Let me show you what I mean — and what actually bridges that gap.
The Sensor Is Just a Pronoun
An LDR (Light Dependent Resistor) does exactly one physical thing: its resistance drops when photons hit it. That's it. No concept of "day." No concept of "night." Not even a concept of "light" in any meaningful sense — just a material whose lattice electrons get energized enough to conduct more current.
The voltage you read is a consequence of that resistance, divided through whatever circuit you built. If you used a simple voltage divider with a 10kΩ fixed resistor, your ADC sees something proportional to R_ldr / (R_ldr + 10000). The number 842 (on a 10-bit ADC with 3.3V reference) means the LDR's resistance was somewhere around 20kΩ.
That's a number. Not a statement. Not a judgment. Not "it's daytime."
When you write:
if adc.read() > 500:
print("It's day!")
You have made a claim. The sensor made a measurement. These are categorically different things.
Where the Meaning Gets Injected
Every layer between the electrons and your is_day() function is a layer of interpretation. Strip them back:
Layer 1 — Physical: Photons hit semiconductor. Electrons jump to conduction band. Resistance drops.
Layer 2 — Electrical: Resistance becomes voltage via a divider. Voltage becomes a digital count via ADC.
Layer 3 — Threshold: You (or someone) decide that count 500 means something. This threshold is your inference, not a fact the sensor produced.
Layer 4 — Label: You call above-threshold "day" and below "night." The label is your language, not the sensor's.
A physicist would say the LDR only occupies layers 1 and 2. Everything from layer 3 onward is information you added, not information the sensor extracted.
This is not a philosophical nitpick. It has practical teeth.
Why This Matters When It Breaks
Imagine your outdoor sensor suddenly thinks it's nighttime at noon. What happened?
Possibilities:
- Dirt accumulated on the LDR (reduced effective light)
- Cloud cover rolled in (real change, but not "night")
- Your voltage divider reference drifted (electronics, not light)
- The ADC pin is starting to fail (hardware fault)
- A bug in your threshold comparison (software)
Only one of those is actually about day vs. night. The rest are physical or electrical phenomena that look like a light-level change but aren't "day" or "night" at all.
If your entire system is built on reading > 500, you can't distinguish any of these cases. They all produce the same output: False.
This is what happens when you confuse measurement with judgment. Your system doesn't know when it's day. It only knows when the voltage is above 500. These are correlated, not identical.
The Real Question: What Does "Know" Even Mean Here?
When Charlyn says "the sensor should know if it's day or night," what she's really asking is: can I build a system that reliably maps "time of day" onto "sensor behavior"?
That's a legitimate engineering question. It just has nothing to do with the sensor knowing anything.
What you can actually build is a system where:
- You define "day" operationally (threshold, time window, sliding average, whatever)
- You acknowledge that your sensor measures light, not day
- You design your thresholds and logic to be robust to noise, drift, and edge cases
- You know that any mapping from light → day is a model, and models can be wrong
A night/day detector is not a sensor feature. It's a system design decision with a sensor as one input.
What Actually "Knows" Then?
If not the sensor, what actually knows?
The system knows, in the way systems know things: through design.
Here's the full chain:
Sun position (physical)
→ photons hit LDR (physical)
→ resistance changes (physical)
→ voltage divider output changes (electrical)
→ ADC converts to count (digital)
→ YOUR CODE tests against threshold (logical)
→ YOUR CODE calls it "day" (linguistic)
→ YOUR SYSTEM behaves accordingly (functional)
Every step from "YOUR CODE" onward is a decision made by a person. The sensor participates in the chain, but it's not where the knowledge lives.
This is why IoT "intelligence" is almost always intelligence in the interpretation layer, not in the sensor itself. The $2 LDR measures photons. The $5 microcontroller runs your threshold logic. The cloud service applies a weather correction. The app displays "Night Mode Active." That's where the "knowing" is.
A More Honest Architecture
If you need reliable day/night behavior, here's what the full stack looks like:
LDR (raw light measurement)
↑
Threshold / hysteresis (noise filtering)
↑
Time-windowed average (temporal smoothing)
↑
Optional: explicit time-of-day override (you know sunrise 6:14am today)
↑
State machine: DAWN | DAY | DUSK | NIGHT (or whatever your system needs)
↑
Action layer: dim_display(), activate_lights(), log_nightfall()
The LDR is the input. The state machine is where "day" and "night" actually exist as categories. The sensor never enters those categories — only numbers that feed into them.
The Takeaway for Charlyn
Your LDR is a wonderful, simple component. It does exactly what physics promises: changes resistance when photons hit it. That's genuinely useful.
But it doesn't know day from night. It doesn't know anything. The knowing happens in the system you build around it — in the logic you write, the thresholds you pick, the edge cases you handle.
So next time your "day detector" fires at 3am under a bright porch light, you'll know exactly what happened: the sensor measured a voltage. You decided it meant something. The porch light had other plans.
That's not a sensor failure. That's a reminder that sensors measure. Systems interpret.
Build accordingly.
No email. No subscription. One-time access to more hardware philosophy whenever you need it.
Top comments (0)