NightMare · 3 min · System overview
Controlling an old AC without modifying it
I built Adler to control a window AC through infrared commands, using a separate sensor to regulate room temperature. Watson adds an acoustic observer: a way to follow the appliance’s activity when commands alone cannot tell the whole story.
One installation: a Consul CCN07GB. Acoustic detection has been implemented and evaluated; the current Adler state-recovery controller is still being rebuilt.
Back to NightMareKeep the appliance, add control around it
The AC stays intact. Adler sends commands through an IR transmitter; a DS18B20 measures room temperature. The user chooses the room target rather than relying only on the temperature displayed by the AC.
View full-size image
Useful automation, dependent on synchronization
The original controller switched the AC on and off around the measured room target, with a small hysteresis band to avoid toggling at every fluctuation. Mycroft supplied door state: after 90 seconds open, cooling paused. Closing the door allowed it to resume, unless the door had stayed open for more than 30 minutes. A daily shutdown at 05:30 moved to 08:30 when sleep-in was enabled.
Adler already had feedback about room temperature. Its record of the AC’s power and setpoint, however, depended on the commands it believed had taken effect. Another remote or the physical buttons could invalidate that record.
Manual recovery meant entering the actual power state and setpoint. A fallback tried to infer power from the temperature trend over ten minutes, then sent a sequence of temperature commands intended to establish 24°C. It was slow and uncertain: the room’s temperature could change for reasons other than the AC.
Sources and evidence: [1]
Listening to the remote still left gaps
Adding an IR receiver let Adler capture commands from the original remote. At its mounted position, coverage did not reliably reach the whole room, so some presses still went unheard. Physical buttons on the AC remained outside IR reception altogether.
Separate commands from physical observations
Watson listens near the AC and publishes fan activity, compressor activity and beep events through NightMare Network. Adler retains the command history. That separation gives the controller evidence beyond its own transmissions, including activity changed by someone else.
- Adler → AC
IR commands sent; remote commands received when in range.
- AC → Watson
Sound: fan, compressor and acknowledgement tones.
- Watson → Adler
Observations through NightMare Network, with availability and freshness.
| Evidence | Meaning and limit |
|---|---|
| Command sent or heard | An instruction occurred; reception by the AC is not established. |
| Beep near a command | A possible acknowledgement; it does not identify every resulting setting. |
| Fan / compressor detected | Observed acoustic activity, subject to interference; not a temperature or mode reading. |
| Unavailable or stale input | Unknown evidence, not proof that the appliance is off. |
What exists today
Watson’s single-microphone ESP32 implementation detects and publishes the three observations. Adler accepts IR events and has a pending-command mechanism that associates a subsequent beep or timeout with a command. That association is deliberately narrower than verifying the resulting appliance state.
The higher-level controller is being rebuilt. Observation callbacks and command tracking still need integration work before automatic state recovery can be presented as complete. A change in sound can expose a missed action; it cannot reconstruct every temperature setting or silent mode change.
Sources and evidence: [2]
Sources and evidence
Implementation details and evaluation reports are linked to fixed source revisions.