DASHBOARDS

pi4SPARK

The first physical device — a Raspberry Pi 4 with a Sense HAT, where dev-00 is the synthetic stand-in. It runs two apps side by side: senseMon reads the Sense HAT, lifeMon drives the LED matrix. Live values update over SSE as readings arrive. Temperature is corrected toward ambient from the Sense HAT’s CPU-adjacent reading.

One box, two producing devices, and neither holds a credential. Both publish over plain HTTP to piF451 on the local network, which submits them under the fleet’s only key and attributes each reading to the app that produced it. So these arrive as pi4spark and lifemon rather than as whatever carried them: the readout below streams both ids, and the two tables under it are each device’s own record. That attribution is also what lets the server notice lifeMon dying: a device it can name is a device it can alarm on, and until lifeMon had an identity its going quiet looked like nothing at all.

The point of pushing rather than publishing directly is what it makes possible next. A device that talks to this API needs a TLS stack, a certificate store, a credential to rotate and a clock correct enough to use it — affordable on a Raspberry Pi, and not on a microcontroller whose HTTPS is a co-processor validating against certificates baked into firmware. Those devices can manage an unencrypted POST to a box on the same LAN, and piF451 does the rest.

POP and GEN are the Conway world’s live cell count and generation. The other four are what the room is doing to it: HUE follows temperature, SAT the gyroscope, RATE the barometer, SEED the humidity. FEED reads BLIND, and the panel turns red, if lifeMon stops seeing the sensor snapshot.

LIVE READOUT pi4spark · lifemon
TEMP -- °C
RH -- %
POP --
GEN --
HUE --
SAT --
RATE -- s
SEED --
FEED --
LAST CONTACT --
RECENT READINGS pi4spark
TIME (UTC)METRICVALUE
awaiting readings
RECENT READINGS lifemon
TIME (UTC)METRICVALUE
awaiting readings