Categories
General Research

RedWatch – Detecting a Heater Fault Light with a Raspberry Pi

When my home’s gas heater throws a fault, a tiny red LED lights up — and nothing else happens until I press the reset button. Since this can happen while I’m away, I wanted a small system that notices that red light, notifies me, and (eventually) presses the button automatically.

Enter RedWatch — a simple, Python-based monitoring setup that uses a USB webcam and a Raspberry Pi 3 Model B to detect that LED in real time.


💡 Concept

The idea is straightforward:

  1. A USB camera points at the heater’s control panel.
  2. OpenCV analyzes each frame for red pixels in a given HSV color range.
  3. When the red LED appears, the Pi:
    • logs the event,
    • takes a snapshot,
    • sends an email or push notification to my phone.

Later I’ll add a small servo actuator to physically press the reset/acknowledge button once I confirm the alarm remotely.


🧠 Tech Overview

  • Hardware: Raspberry Pi 3 Model B, any USB webcam, stable 5 V power.
  • Software: Python 3, OpenCV, NumPy, tmux, and systemd.
  • Notifications: SMTP (email) or ntfy.sh push messages.
  • Display: A dedicated fullscreen dashboard on tty8 showing
    current IP addresses and live logs.

The entire setup runs automatically on boot — no desktop required.


🧰 Implementation Highlights

  • The Python script continuously monitors for red hue clusters (two HSV bands to cover both ends of the red spectrum).
  • A debounce timer filters out flicker or reflections.
  • Snapshots and timestamps are stored in /home/heater/redwatch/capture/.
  • All messages go into redwatch.log.
  • Two systemd services manage startup:
    • redwatch.service runs the OpenCV monitor.
    • redwatch-dashboard.service launches a tmux session on TTY 8 with:
      • a dynamic banner (hostname, timestamp, IP addresses),
      • live log streaming via journalctl -fu redwatch.service.

You can return to your normal KDE desktop with Ctrl + Alt + F2,
and back to the RedWatch dashboard with Ctrl + Alt + F8.


🧩 Typical Use Case

Whenever the heater locks out, the LED lights up — RedWatch detects it within a second or two, sends me an email like:

“Red light detected on heater – 2025-10-16 15:42:21”

…and saves a photo of the panel.
From there I can confirm remotely and, in the next phase, trigger a small stepper or servo motor wired to the heater’s reset switch.


🚀 Results

  • Reliable detection even under variable lighting.
  • No false alarms after HSV tuning.
  • Email alerts arrive in < 2 s.
  • Dashboard visible on HDMI monitor for local diagnostics.

It’s a surprisingly robust little IoT maintenance sentinel — and the groundwork for a fully automated recovery loop.


🔧 Next Steps

  • Add servo/solenoid actuator to press the reset button.
  • Optional: MQTT integration for home-automation systems (e.g. Home Assistant).
  • Log heater uptime, restart counts, and runtime temperatures.

🏁 TL;DR

RedWatch is a Raspberry Pi-based vision sensor that watches a heater’s fault LED, logs it, alerts you, and can later clear the error automatically.

Source code and setup guide are available in the project’s README (includes full Python, systemd units, and dashboard scripts).

Categories
Development High Stakes Research

Research: MCO .frd file format

1. File Type: .FRD in MCO

  • Format name: .FRD (same extension as in NFS3/NFS4)
  • Purpose: Contains 3D geometry, instance data, and object references for complete tracks

2. Core Structure: DEADBEEF Blocks

  • Marker: Every significant block starts with the 4-byte value 0xDEADBEEF
  • Immediately following:
    • +4 bytes → block_type (typically 0x00000000, exact meaning unknown)
    • +8 bytes → object_id (4 bytes, varies; likely a unique identifier)
  • Block size: Minimum of 12 bytes (often 32–64 bytes or more)
  • Occurrences: Numerous, regularly spaced throughout the file
  • Interpretation: These blocks likely define objects, instances, or spatial elements within the track

3. basename from info.ini

TrackbasenameHexOccurrences in .FRD
Tr112000x04B025
Tr213000x051429
Tr311000x044C18
  • Every track’s info.ini defines a basename=XXXX value
  • This value (as 16-bit Little Endian) appears multiple times inside the .FRD file
  • Each occurrence is embedded in structured binary patterns
  • Nearby bytes show repetitive layouts and fixed patterns, suggesting instancing or referencing logic

4. Structure Around basename Values

  • Multiple references per track
  • Repeated binary layout:
    • Frequent values like 00 00, 05 00, 38 00, 88 00, etc.
    • Patterns suggest 2-, 4-, or 16-byte groups
  • Likely represents an instance or placement table for objects using the basename ID

5. Structural Consistency Across Tracks

  • DEADBEEF blocks appear in all .FRD files analyzed
  • basename values always referenced multiple times
  • Block structure, layout, and repetition are consistent across all three tracks

Summary of Confirmed Roles

ElementRole / Purpose
info.iniDeclares basename, which is used as a reference in .FRD
.FRDBinary container for objects, references, geometry
DEADBEEFMarker indicating start of significant block
block_type(Mostly 0x00) — possibly object class or type flag
object_idUnique object or instance identifier
basenameKey identifier used throughout the binary for object grouping or lookup