Core takeaway: Daylight & occupancy adaptive lighting combines measured ambient lux (ALS) with reliable presence detection (PIR/radar) so a luminaire can stay comfortable, energy-efficient, and stable using evidence-based control (logs, thresholds, ramps, and state transitions).

Decision entry (engineering-first)

This page is chosen when the goal is not just “auto on/off,” but stable closed-loop brightness under changing daylight and robust occupancy intent without nuisance switching. The design problem is a control problem: measure correctly, decide predictably, and actuate smoothly.

Two behaviors, one unified policy

• Daylight harvesting (ALS-driven): adjusts the dimming level so the measured ambient lux tracks a target. Best when daylight varies across hours, weather, or window exposure.
• Occupancy adaptive (PIR/radar-driven): enables or relaxes brightness only when the space is used. Best when “lights on for empty zones” is the dominant waste driver.
• Why fuse both: ALS alone can chase reflections and self-illumination; occupancy alone cannot keep consistent task lux. Fusion allows occupancy to gate the control loop and ALS to set the level.

Key constraints that make or break UX

• Response vs comfort: fast turn-on for motion is good; fast brightness oscillation is not. Separate “occupancy response” from “lux loop response.”
• False-trigger tolerance: avoid nuisance events from HVAC drafts, sunlight patches, thermal drift, or multipath reflections. This is solved with thresholds, debounce, hysteresis, and health flags.
• Minimum light floor: enforce a non-zero safety floor (and a stable dim-to-low behavior) so the system never “hunts” into darkness during measurement noise.
• Fade/ramp discipline: a controlled ramp prevents perceptible stepping and prevents control-loop “chatter” when daylight changes quickly.
• Anti-hunting budget: define deadbands and hold-times so a passing cloud does not cause repeated dimming cycles.

Evidence fields (loggable + testable)

A design is debuggable only if decisions are explainable. The following fields should be measurable on the bench and recordable in firmware logs:

• lux_setpoint, estimated_lux, als_gain_state, als_saturation_count
• occ_state, occ_confidence, hold_time_s, debounce_rejects
• target_level, actual_level (if available), ramp_time_ms, clamp_hits
• event_ts (timestamp), fault_flags, sensor_health_flags

Architecture goal: explainable decisions

A reliable adaptive node is not “sensor-to-output wiring.” It is a pipeline that converts raw signals into two stable estimates—ambient lux and occupancy confidence—then drives a protocol-agnostic dimming abstraction with ramps, clamps, and failsafe behavior.

Inputs: roles and failure modes (design for degradation)

• ALS: best for slow daylight trend; fails by saturation, reflections, and self-illumination from the luminaire. Needs gain state + saturation flag.
• PIR: best for fast “someone entered” motion; fails by thermal drift, HVAC drafts, and vibration/EMI coupling. Needs debounce + blanking window.
• Radar AFE: best for “still occupant” presence; fails by multipath and environmental reflections. Needs confidence scoring + false-alarm counters.

MCU policy as 3 layers (keeps the system debuggable)

1. Sampling layer: schedules sensor reads and timestamps events. Prevents aliasing and captures duty-cycle/power behavior.
2. Estimation layer: converts raw counts into estimated_lux and occ_confidence with smoothing and health flags.
3. Strategy layer (state machine): chooses states (Vacant/Occupied/Hold/Fade), applies hysteresis, and outputs target level + ramp parameters.

Outputs: dimming abstraction (keeps interfaces out of the policy)

Interfaces vary, but control intent should not. The recommended output contract is:

• target_level (0–100% or normalized), ramp_time_ms (slew limit), min/max_clamp (safety & comfort), failsafe_level (sensor fault).
• Occupancy should gate whether the node is allowed to chase lux; ALS should set the level when chasing is enabled.
• Every executor should report interface_error_count so failures are distinguishable from bad sensor policy.

Minimum logging contract (recommended)

For stable behavior and fast field isolation, every adaptive node should be able to answer: what was measured, what was believed, and what was commanded. That is the fastest path to separating sensor issues from policy issues from executor issues.

Treat ALS as an instrument, not a “lux oracle”

Stable daylight harvesting starts with a stable measurement chain. ALS behavior is the sum of optical stack (what light reaches the sensor), analog front-end (what current becomes voltage), ADC (how it is sampled), and a lux estimator (how raw codes become a usable lux estimate). When brightness “hunts,” the root cause is often measurement distortion (saturation, noise floor, reflections, or self-illumination), not the policy layer.

Optical stack: the first stability filter

• Shielding & field-of-view (FOV): avoid direct sun and reduce “seeing the luminaire.” A narrow, controlled FOV reduces reflections and self-illumination coupling.
• Spectral shaping (IR suppression): ambient lux tracking should be consistent across light sources. IR leakage can bias lux estimates and produce day/night discontinuities.
• Angular response awareness: window-side daylight arrives from steep angles; wall reflections arrive diffusely. Angle-dependent response can look like “lux drift” even when the space is stable.

AFE chain: photodiode → TIA → ADC (where range and noise are decided)

• TIA gain sets usable range: too high → frequent saturation in daylight; too low → night-time codes become noise-dominated and step-like.
• Saturation is not subtle: it can be TIA output rail-clamping or ADC full-scale. Without a saturation flag, the estimator may keep “chasing” an impossible lux error.
• Noise should be measured: define an ALS noise metric (RMS of filtered codes under stable illumination). It becomes the knob for deadband and averaging decisions upstream.

Dynamic range extension: auto-range / dual gain (make it a state machine)

Auto-ranging must be predictable. A robust implementation uses gain hysteresis and cooldown so the gain does not chatter at boundaries.

• Gain-down trigger: saturation counter rising or codes nearing full-scale for a sustained window.
• Gain-up trigger: estimated signal-to-noise is poor (noise RMS becomes a large fraction of code magnitude), for a sustained window.
• Publish health, not just lux: the policy layer benefits from als_gain_state and sensor_health_flags to avoid overreacting to borderline measurements.

Self-illumination and reflections: the closed-loop trap

When the luminaire’s own output contributes to ALS readings, the loop can “chase itself.” Practical isolation uses optical separation (shield/FOV), correlation checks (compare output_dim_level vs estimated_lux), and measurement validity flags (saturation/noise-limited states) so policy decisions remain stable.

Evidence fields (bench + firmware logs)

• ADC code: detect quantization steps and proximity to full-scale.
• TIA gain state: explain range behavior and step size changes.
• Saturation counter: prove strong-light or self-illumination rail-clamping.
• Lux estimate: the only value the policy layer should chase.
• Temperature reading: correlate drift with heating (sun patch, enclosure rise).
• ALS noise RMS: quantify noise-limited operation and guide deadband/averaging.

PIR is a change detector (motion), not a presence meter

A pyroelectric sensor responds strongly to changes in infrared energy (movement across zones) and weakly to still occupants. The AFE therefore focuses on extracting motion energy in a target band while rejecting slow thermal drift and high-frequency noise. Most “mystery triggers” become explainable once the chain is instrumented and thresholds are tied to measurable peaks.

AFE chain: low-offset amp → band-pass → window comparator

• Low-offset / chopper amp: improves baseline stability so slow drift does not masquerade as motion.
• Band-pass filtering: keeps motion-related content while rejecting slow environmental shifts and switching spikes.
• Window (dual-threshold) comparator: reduces chatter near the threshold and produces a clean event signal for the MCU.

False-trigger sources: classify by evidence

• HVAC drafts / warm air: correlates with temperature and airflow timing; looks like slow baseline modulation.
• Sun patches: time-of-day dependent; can drive large low-frequency swings and saturate the front-end.
• Luminaire heat: correlates with output level and enclosure temperature; appears after ramp-ups.
• Vibration: coincides with door slams, fans, or mechanical resonance; often repeatable with the same stimulus.
• EMI coupling: coincides with switching or actuator events; visible as short spikes that should be rejected by debounce/blanking.

Firmware pairing: debounce, retrigger, blanking window

• Debounce: rejects short spikes and near-threshold chatter; track debounce_rejects to verify it is doing useful work.
• Retrigger rules: avoid repeated on/off cycling during continuous movement; combine with hold-time in the policy layer.
• Blanking window: temporarily ignore PIR events after large output ramps or known disturbances, preventing self-induced triggers.

Evidence fields (bench + firmware logs)

• PIR raw amplitude: indicates baseline drift and slow environmental modulation.
• Band-pass output peak: indicates true motion-band energy and threshold margin.
• Trigger count: quantifies nuisance frequency (night-time patterns, fan cycles).
• Debounce rejects: confirms spike filtering vs overly aggressive thresholds.
• Temperature correlation: distinguishes thermal drift from real motion events.

Radar’s advantage over PIR: Presence detection

Radar provides continuous presence detection, even for small movements like breathing or finger motions, which PIR struggles to pick up. This makes radar a great solution for detecting still occupants, something PIR fails at. However, radar has its own challenges, such as multipath interference and reflections from metal surfaces, which can cause false positives.

Motion vs Presence: The key difference

• Motion: Large movements or sudden changes in position. Easily detectable with PIR and radar.
• Presence: Subtle motions, like breathing or slight movements, which need more sensitive detection like radar’s low-frequency I/Q path.
• The ability to detect presence reliably is crucial for energy-efficient lighting control in spaces where people may remain still (e.g., offices, meeting rooms).

Radar AFE: Key components in the chain

• TX/RX: Radar uses FMCW (Frequency Modulated Continuous Wave) to transmit and receive signals. This allows for measuring the distance of an object by observing the Doppler shift of the returning signal.
• I/Q Path: The signal is mixed down to baseband, separating in-phase (I) and quadrature (Q) components. These provide the basis for distance and motion detection.
• ADC: The I/Q signals are converted into digital data, which can then be processed by the DSP (Digital Signal Processor).

DSP Summary: Range FFT and Doppler

The DSP performs range FFT to convert the received signal into a frequency domain, assigning energy to distance bins. The Doppler effect, which measures the frequency shift caused by motion, helps distinguish movement from stationary presence. This is essential for differentiating between a moving object and a stationary occupant.

• Range FFT: Measures the distance to the detected object by allocating energy into frequency bins.
• Doppler: Identifies movement by calculating the shift in frequency, allowing detection of motion even if the person remains stationary in the radar’s field of view.

Environmental Challenges: Multipath, Reflections, and False Alarms

Radar performance can degrade in certain environments, especially with multipath interference and metal reflections. These effects lead to false positives, especially in areas with a lot of metal surfaces or in corridors with reflections off walls. The system must be designed to reject these false signals.

• Multipath: Signals bounce off multiple surfaces, leading to inaccurate readings.
• Metal reflections: Large metal surfaces can reflect radar signals and create false detections.
• Corridors: Radar can mistakenly detect motion through walls or doors, leading to false occupancy.

Evidence Fields: What to Log for Debugging

• I/Q Power: Logs the signal strength of the I/Q components, which helps identify issues like poor signal quality or excessive noise.
• Range Bin Energy: Shows how energy is distributed across distance bins, which is useful for detecting multipath and range errors.
• Presence Score: The score used to quantify the likelihood of occupancy based on radar measurements.
• False Alarm Rate: Tracks how often false positives occur, especially in environments with high multipath interference.
• CFAR Threshold Hit Count: Monitors the threshold hits in the Constant False Alarm Rate (CFAR) algorithm, which adjusts the detection threshold based on ambient conditions.

Unify outputs: lux_estimate + occ_confidence

A robust adaptive lighting system should not rely on raw sensor “ifs.” Instead, expose two stable, policy-ready signals: lux_estimate (from ALS) and occ_confidence (from PIR + radar). The policy layer then acts on continuous evidence with timers and hysteresis, producing smooth dimming behavior and predictable logging.

Role split: PIR triggers fast, radar sustains, ALS sets the level

• PIR (motion): fast “wake-up” trigger to avoid delayed turn-on; best for quick detection at entry and movement bursts.
• Radar (presence): sustain occupancy when movement is minimal (desk work, meetings); reduce “lights-off while still occupied.”
• ALS (daylight): determine how bright to drive the luminaire for the target lux setpoint; apply deadband and rate limits upstream.

Occ_confidence: continuous evidence, not binary events

Model occupancy as a confidence value that rises quickly on strong evidence and decays slowly when evidence fades. This prevents event chatter from causing lighting oscillation.

• Fast-rise: PIR trigger (motion) pushes occ_confidence upward immediately.
• Sustain: radar presence score keeps confidence elevated during low-motion periods.
• Slow-decay: when evidence stops, confidence decays with a time constant; state transitions should depend on threshold + hold time.

Degradation & fallback: explicit, logged, and reversible

Each sensor can become unreliable (ALS saturation/noise floor, PIR false triggers, radar multipath). The fusion layer should downgrade a sensor’s influence via health flags and enter a controlled fallback mode. Every fallback must be logged with a reason code so field issues can be diagnosed without guesswork.

• ALS unhealthy: freeze or slow-rate the daylight loop; clamp brightness to a safe range; keep ramp smooth.
• Radar false-alarm high: reduce radar weight or constrain valid range bins; rely more on PIR for trigger + hold timers.
• PIR noisy: increase debounce/blanking; rely on radar presence for sustain to avoid rapid cycling.

Evidence fields (must be in logs)

• occ_confidence: continuous occupancy evidence (avoid binary toggles).
• state transitions: prove stability (too many flips indicates poor hysteresis/timers).
• sensor health flags: explain why a sensor was down-weighted (ALS sat/noise, PIR noisy, radar false alarm).
• fallback reason code: precise root-cause label (e.g., ALS_SAT, RADAR_FA, PIR_NOISE).

Why MCU strategy matters

Daylight & occupancy adaptive lighting fails more often due to poor scheduling than poor sensors. The MCU must enforce a predictable timing budget: fast turn-on when occupancy appears, stable hold when presence persists, and slow daylight correction without flicker or oscillation.

Sampling cadence: slow / medium / fast (no fixed numbers)

• ALS: slow updates; treat as a “level correction” signal, not an event trigger. Use deadband + rate limiting.
• PIR: medium cadence with event capture; optimized for fast motion-trigger response.
• Radar: fast internal updates; optimized for continuous presence scoring and low-motion sustain.
• Key rule: fast sensors should not force fast dimming changes; only occupancy events should cause rapid ramps.

Event-driven vs periodic polling

• Event-driven path: PIR interrupt → immediate policy wake → start ramp to a safe “occupied baseline.”
• Periodic path: ALS loop runs on a slower timer → nudges target level in small steps.
• Presence sustain: radar presence updates should influence occ_confidence and state, not directly command large level jumps.
• Scheduling rule: occupancy transition logic must preempt daylight correction logic.

Low power modes: sleep/wake + sensor gating + duty cycle

Power efficiency comes from keeping the MCU asleep and minimizing sensor on-time. Use sensor gating and staged wakeups: minimal always-on detection for “possible occupancy,” then elevate to full sensing only when needed.

• Sleep state: keep the dimming output stable; avoid waking for minor ALS noise.
• Sensor gating: reduce radar duty cycle when confidence is low or environment is known noisy.
• Staged wake: quick wake for PIR trigger, longer active window for radar presence confirmation, slow ALS updates.

Evidence fields: schedule health and latency

• task runtime: per-task execution time (sensor read, fusion, output update).
• wakeups/min: indicates whether the system is thrashing (too many wakes → noise or bad policies).
• sensor duty cycle: on-time ratio for PIR/radar/ALS.
• latency (trigger → output change): validates “fast on” requirement without forcing flicker.

Keep policy independent from the actuator

The lighting policy should never be tied to a particular dimming interface. Treat the physical output as an actuator behind a stable command contract. This avoids re-writing control logic when the output stage changes, and makes debugging consistent.

The output “quadruple” (policy-ready contract)

• target_level: desired light level (normalized or in application units).
• ramp_time: how fast to reach the target (prevents step changes).
• min/max clamp: safety and comfort bounds (avoid too dim / too bright).
• failsafe_level: safe fallback output when the interface is unhealthy or sensors are unreliable.

Deep dimming stability: small steps, slew limits, anti-chatter

• Small step updates: apply incremental level changes to avoid visible flicker and quantization artifacts.
• Slew-rate limit: enforce a maximum rate of change per unit time (comfort + stability).
• Debounce / deadband: ignore tiny lux_estimate noise; only act when deviation exceeds a threshold.
• Ramp status: a single “ramp active” flag simplifies debugging and prevents competing commands.

Evidence fields: prove commands, clamps, and interface health

• commanded level: what policy requested (after clamp).
• actual level feedback (if available): what the actuator reports or what the driver senses.
• ramp active flag: whether a ramp is in progress.
• clamp hits: how often min/max clamp applied (indicates bad setpoints or unstable sensors).
• interface error count: actuator/driver errors (wiring, output stage faults, bus errors).

Stability is a control design problem, not a sensor problem

User complaints typically come from “hunting”: frequent small brightness changes near windows and repeated on/off transitions near doors. The fix is layered control: occupancy decides on / hold / off with timers, then daylight control sets the target level with filtering and deadband, and the output layer enforces ramps and slew limits.

Daylight loop: low-pass + deadband + rate limit

• Low-pass filtering: suppress short-term lux fluctuations (cloud edges, reflections, measurement noise).
• Deadband: ignore small lux deltas around the setpoint to prevent constant micro-corrections.
• Rate limit: even when lux error is large, limit how fast target_level can move to keep changes imperceptible.
• Rule: ALS should nudge target_level in small steps; it should never behave like an event trigger.

Occupancy loop: hold-time + retrigger window + interruptible fade-out

• Hold-time: minimum time to keep lights on after occupancy evidence fades; prevents door-area flicker.
• Retrigger window: if new evidence arrives during Hold/Fade-out, return to Occupied without restarting from zero.
• Fade-out policy: ramps must be smooth and interruptible; avoid repeated start/stop ramps from noisy evidence.
• Rule: occupancy state changes preempt daylight adjustments; do not let ALS force off/on decisions.

Typical hunting patterns and rule-based fixes

• Doorway ping-pong: increase hold-time and enable retrigger window; keep fade-out slow and interruptible.
• Cloud edge oscillation: strengthen low-pass + deadband; enforce slew limits on target_level changes.
• Headlight / flashlight spikes: ignore short peaks or use asymmetric response (fast brighten, slow dim) in the daylight loop.
• Reflective surfaces: widen deadband and reduce correction gain; verify ALS placement in commissioning.

Evidence fields: quantify “hunting” and validate improvements

• lux_delta: how often measured lux crosses correction thresholds.
• deadband_hits: frequency of “ignored” events inside deadband (should increase after tuning).
• state_dwell_time: time spent in Occupied/Hold/Vacant (detect rapid toggling).
• fade_cycles_per_hour: direct user-experience metric; too high indicates chatter or noisy evidence.

Commissioning turns a good design into a stable installation

Misplacement and missing calibration are the fastest paths to false triggers and unstable daylight response. Commissioning must be treated as an engineering procedure with recorded baselines, versioned threshold tables, and scenario verification before saving configuration.

Placement checklist (common failure modes)

• ALS placement: avoid self-illumination from the luminaire; avoid direct sun/glare; ensure FOV represents the task plane.
• PIR placement: cover entry paths and motion corridors; avoid HVAC vents, heaters, mechanical vibration sources.
• Radar placement: minimize multipath from large metal surfaces; watch doorway/corridor false alarms; check for occlusion by furniture/partitions.

Calibration flow: baseline → thresholds → daylight mapping

• Baseline capture (empty space): record noise floor and steady-state behavior for ALS/PIR/radar.
• Presence thresholds: set “on” and “off” logic using observed baseline + acceptable false alarm rate.
• Daylight mapping: build a lux→level curve (piecewise/curve) with clamps and rate limits to prevent hunting.

Verification scenarios (minimum set)

• Enter: fast on with smooth ramp.
• Stay seated: no accidental off (radar sustain works as intended).
• Leave: hold then fade-out; no rapid off/on chatter near the boundary.
• Daylight change: stable trims under cloud/glare events (deadband + filtering effective).

Evidence fields: traceability and rollback

• baseline_logs: recorded empty-space signatures (noise floor, stability) used for threshold decisions.
• threshold_table_version: versioned threshold set (supports compare/rollback across installs).
• calibration_timestamp: indicates when commissioning was completed and when re-check is required.
• placement_notes: recorded mounting location/orientation and environmental notes for future troubleshooting.

White Light Flickering: ALS Hunting vs Reflections

• Measure: lux estimate trend, lux delta
• How to distinguish: A) ALS hunting: rapid fluctuations; B) Reflections: large oscillations in lux estimate
• First fix: A) Increase low-pass filtering and deadband for ALS hunting; B) Adjust ALS placement to avoid direct reflections

Material Number: TSL2561 (ALS Sensor), BH1750FVI (ALS Sensor)

Lights Off Despite Occupants: PIR Thresholds or Radar Occlusion

• Measure: occupancy confidence trend, sensor health flags
• How to distinguish: A) PIR threshold too high, B) Radar occlusion or failure to transmit data
• First fix: A) Lower PIR threshold for more sensitive detection; B) Ensure proper radar placement to avoid occlusions

Material Number: HC-SR501 (PIR Sensor), RCWL-0516 (Radar Sensor)

Lights Won’t Turn Off: Radar False Presence or Hold-Time Too Long

• Measure: occupancy confidence trend, state dwell time
• How to distinguish: A) Radar false presence: confidence too high, B) Long hold-time: state persists without new evidence
• First fix: A) Increase occupancy confidence threshold; B) Decrease hold-time to allow faster state transitions

Material Number: HRS-RF-2401 (Radar Sensor)

False Triggering: Temperature Drift, Air Currents, Noise Coupling

• Measure: sensor health flags, PIR raw amplitude
• How to distinguish: A) Environmental changes affecting sensor data, B) Thermal issues or noise coupling in wiring
• First fix: A) Move sensor away from heat sources, B) Implement noise filtering for wiring

Material Number: AM312 (PIR Sensor)

Cloud Variations Causing Dimming Issues: ALS Filtering/Deadband

• Measure: lux delta, deadband hits
• How to distinguish: A) ALS too sensitive, B) Deadband too wide, slow response
• First fix: A) Increase deadband to suppress minor fluctuations, B) Strengthen ALS low-pass filtering to handle cloud shadow

Material Number: TSL2561 (ALS Sensor)

Motion Detection Issues in Hallways: Multipath/FOV

• Measure: lux estimate trend, occupancy confidence trend
• How to distinguish: A) Multipath interference, B) Wide FOV causing motion detection errors
• First fix: A) Adjust radar installation to minimize reflections, B) Narrow FOV and adjust sensor angles

Material Number: RCWL-0516 (Radar Sensor)

Flickering During Deep Dimming: Output Rate Limiting/Step Size

• Measure: commanded level, ramp active flag
• How to distinguish: A) Large step size causing flicker, B) Lack of output rate limiting causing instability
• First fix: A) Decrease step size for smoother dimming; B) Implement rate limiting to slow down changes

Material Number: IRLZ44N (MOSFET), LM3914 (LED driver)

Post-Reboot Strategy Failures: Configuration Not Saved/Default Values

• Measure: interface error counters, lux estimate trend
• How to distinguish: A) Default settings after reboot, B) Interface errors preventing configuration saving
• First fix: A) Verify configuration save mechanism; B) Check communication lines for interface issues

Material Number: ESP32 (MCU), Fluke 87V (Digital Multimeter)