IRL experiment: a room lamp with a service heartbeat

I wanted one fun experiment that taught something useful. So I built a tiny lamp that blinks when local services report status changes.

It was part science project, part practical exercise in not overengineering.

Rules for myself before starting

I wrote this down so I stayed practical:

• one hardware platform (no overload of boards),
• one message path (MQTT topic per event),
• one failure test (simulate outage and confirm fallback),
• no internet dependency during the core loop.

Setup I used

1. Reused one ESP32 module and a desk-lamp base.
2. Chose a local MQTT broker.
3. Sent three event states: ok, warn, and error.
4. Added a script that publishes only when health state flips.

The minimal shell loop

# check service status and publish each minute
if curl -fsS http://127.0.0.1:3000/health >/dev/null; then
  mosquitto_pub -h 192.168.1.20 -t room/lamp/state -m ok
else
  mosquitto_pub -h 192.168.1.20 -t room/lamp/state -m error
fi

I ran this manually first, then as a timer loop, then as an environment timer in my setup.

What I tested on purpose

• Latency: how fast does lamp state update after failure?
• False positives: how often does a tiny DNS hiccup turn red?
• Recovery behavior: does it return to green after one healthy sample?

I kept notes with a simple checklist and used a two-failure threshold before red state.

The practical failure I hit

On day one, the lamp flickered randomly because I published too aggressively. I had told the script to publish on every failed attempt.

I fixed it by:

• adding debounce state tracking,
• limiting publish frequency,
• and requiring two failures for error, three successes for ok.

What I learned

This was a tiny project, but it proved two real things:

• “cheap reliability” is still reliable if behavior is explicit,
• local automation is useful only when observable and bounded,
• and fun experiments still need a checklist.

The lamp is still in place. It is not beautiful. It works enough to be useful.