Everyday application · Reading an older appliance
Watching an old boiler: a camera reads, a model checks
Two cameras turn an old appliance’s display and lights into a running record. Follow its real frames, readings and disagreements to see the roles of pixel rules, Claude and human calibration.
Developer ndroo shared the project October 16. On October 18, BitShovel checked the public dashboard, pinned code and original images. These are the maker’s operating records; we did not access accounts, run models or operate the boiler.

An old display gains a history you can inspect
Instead of replacing the boiler, the project points two Tapo C100 cameras at its LCD and a zone controller’s LEDs. Processing turns the images into temperature, mode, burner and pump records on a web page and timeline. The 00:19 UTC sample records 100°F and idle, with separate fields for pixel readings and model contributions.
Connecting observations lets a person look back at heat calls, pump activity and missing readings. The current loop targets 900 seconds, or 15 minutes, for the cameras. The README and some workflow labels still say 30 minutes, so they are not a reliable description of the current cadence.
Sources and further reading
- ndroo · Boiler Monitor dashboardMaker’s operating display · changes over timeRead October 18, 2026: camera views, sampling coverage, a timeline and readings, rather than independent accuracy validation.
- ndroo · Pinned project versionMaker’s public code · version checked this roundPinned at 85a3a7e. The README’s 30-minute cadence and older cost estimate lag the current script. No code license file was found; public visibility does not establish unrestricted reuse rights.
- Pinned reading inspected this roundMaker’s log · October 18, 2026, 00:19 UTC100°F, idle, and separate pixel/model fields. The sampling time, device clock and camera timestamp are separate clocks.
- The actual camera sampling loopSource script · 15-minute target intervalCAM_EVERY=900; job duration, scheduling and networking can still leave gaps.
Start with pixels where fixed rules are enough
Zone LEDs do not need a language-model call on every cycle. The program measures bright white pixels at fixed positions and asks a model when the result is ambiguous or power looks abnormal. For the LCD it corrects perspective, aligns a reference, measures icon darkness and decodes seven-segment digits. These rules rely on calibration for this appliance and viewpoint.
Models handle the difficult cases: error codes, misaligned or unreadable frames, unconfirmed icons, state changes and temperature jumps. The current workflow uses Sonnet 5.5 for a first check and can ask Opus 5.5 to arbitrate disagreements. The result depends on that division of work, rather than a photo alone producing a reliable appliance state.

Sources and further reading
- ndroo · Pinned project versionMaker’s public code · version checked this roundPinned at 85a3a7e. The README’s 30-minute cadence and older cost estimate lag the current script. No code license file was found; public visibility does not establish unrestricted reuse rights.
- LCD pixel reading and calibrationSource code · a method for this calibrated screenPerspective correction, reference alignment, icon thresholds and seven-segment digits depend on this camera position and display layout.
- Model checks, disagreement handling and alertsSource code · monitoring, not appliance controlSonnet 5.5 verification, Opus 5.5 arbitration, per-field trust counts and two-hour audits. An arbiter’s choice is not external ground truth.
A trust counter is not a measured accuracy rate
The code maintains trust counts for five key fields. At 200 accumulated under its verification and arbitration rules, it reduces routine model checks while retaining triggers and at least a two-hour audit. A first-pass disagreement can still increment the count when arbitration selects pixels, so this is not 200 strictly independent agreements or human-confirmed readings. The pinned snapshot has only 25 cycles and 25 first-pass checks. That design does not yet demonstrate sustained low-call or zero-call operation.
The log retains five disagreement events, including pixels detecting flame or pump symbols that the first model classified as off. Its arbiter selected the pixel reading in those cases. This reveals more than a success claim, but arbitration remains another model judgment. Without frame-by-frame human ground truth it does not establish comparative accuracy.

Sources and further reading
- LCD pixel reading and calibrationSource code · a method for this calibrated screenPerspective correction, reference alignment, icon thresholds and seven-segment digits depend on this camera position and display layout.
- Model checks, disagreement handling and alertsSource code · monitoring, not appliance controlSonnet 5.5 verification, Opus 5.5 arbitration, per-field trust counts and two-hour audits. An arbiter’s choice is not external ground truth.
- Per-field trust and disagreement logMaker’s operating state · pinned snapshotThis snapshot records 25 cycles, 25 first-pass model checks and five disagreement events, not a large accuracy study.
The useful next step is knowing when a person should look
The dashboard shades periods without data, distinguishing a missed capture from an appliance being off. Alert records distinguish sent, failed, unconfigured and suppressed attempts. The code can use Twilio for error codes, unreadable screens or suspect readings, but configuration and networking affect delivery; preparing an alert does not mean a person received it.
This project observes and alerts; it does not adjust temperature, ignite the appliance or repair it. Camera position, icon examples, a device manual, accounts and cloud services are prerequisites that must be revisited for another device. The maker’s older monthly estimate is not a current invoice. The useful connection is how AI can help bridge an existing display and an inspectable history, giving a person a clearer reason to look.
Sources and further reading
- ndroo · Boiler Monitor dashboardMaker’s operating display · changes over timeRead October 18, 2026: camera views, sampling coverage, a timeline and readings, rather than independent accuracy validation.
- ndroo · Pinned project versionMaker’s public code · version checked this roundPinned at 85a3a7e. The README’s 30-minute cadence and older cost estimate lag the current script. No code license file was found; public visibility does not establish unrestricted reuse rights.
- Model checks, disagreement handling and alertsSource code · monitoring, not appliance controlSonnet 5.5 verification, Opus 5.5 arbitration, per-field trust counts and two-hour audits. An arbiter’s choice is not external ground truth.
- The actual camera sampling loopSource script · 15-minute target intervalCAM_EVERY=900; job duration, scheduling and networking can still leave gaps.