[critical] Real-Time Resource Contention (PWM vs. IR-Modulation)

[Smart-real]

During the integration of the Active IR Tripwire and the Smart LED Controller, a critical timing conflict emerged on the ESP8266’s single-core architecture. The hardware was tasked with maintaining a constant 38kHz carrier wave for presence detection while simultaneously "bit-banging" precise IR packets for light control.

[Smart-real]

The Conflict:

Background Task: The Tripwire utilized analogWrite() to generate a high-frequency PWM signal, triggering constant CPU interrupts.

Foreground Task: The LED Controller required microsecond-perfect timing to transmit NEC-encoded IR signals.

The Result: The PWM interrupts periodically "stepped on" the IR data pulses, leading to corrupted packets and intermittent unresponsiveness from the LED receiver.

The Solution:

Implementing a Software-Level Mutex (Mutual Exclusion)
To resolve this, I engineered a "Safe-Send" wrapper that creates an atomic window for IR transmission.

Atomic Pause: The firmware now explicitly halts the 38kHz PWM heartbeat immediately before firing an IR command.

Timing Optimization: Since the IR command duration is minimal (~60ms), the pause is invisible to the Door Node’s signal-processing logic, preventing false "beam break" triggers.

Automatic Resumption: The system re-engages the 38kHz PWM immediately after the packet is sent, restoring the room's presence-detection "heartbeat" with zero perceived downtime.

had to tweak the esp32 side too as it was too sensitive to a beam not present. will add greater relaxation time by updating the time of our watchdog timer