The idea
A small box that plugs into a wall socket and does one thing: keep an accurate, timestamped record of your mains supply. It logs when the power goes out, when it comes back, how long the gap was, and the brownouts and voltage sags that never quite become an outage. It keeps running for ten minutes after the power dies — long enough to record the event that just killed it — and uploads the log when the network returns.
Why build this
Most people have no evidence about their own electricity. You know the router rebooted at some point last night, and you suspect the freezer thawed a little, but you can't say when or for how long. That matters in three situations: claiming against a utility or landlord for spoiled food and dead appliances, deciding whether a UPS is worth buying and how big it needs to be, and diagnosing the equipment that keeps failing for no visible reason. Utility outage maps are coarse, retrospective, and silent about sags — the thing that actually browns out a fridge compressor.
The hardware side is now trivially cheap. A microcontroller with WiFi costs a few dollars, and the safe way to sense mains voltage — an isolated AC-AC plug-in transformer, the approach OpenEnergyMonitor has used for years — means you never touch a live conductor. Grid quality is also getting genuinely worse in a lot of places as more intermittent generation and more heat-pump and EV load lands on distribution networks built for neither.
Stack sketch
- Sensor node: Seeed XIAO ESP32-C3. Cheap, WiFi, deep-sleep friendly.
- Voltage sensing: a 9V AC-AC plug-in adapter (the Ideal Power 77DE-06-09 is the usual one) powers the node and provides a scaled, isolated copy of the mains waveform. Divide it into the ESP32's ADC, sample at ~2 kHz, compute true RMS per mains cycle and frequency from zero crossings.
- Ride-through: two 10F supercapacitors and a buck converter, so the node keeps logging after the supply drops. This is what makes the record trustworthy — the outage start is measured, not inferred from a missing heartbeat.
- Clock: DS3231 RTC, disciplined by NTP when online. Without it your timestamps are worthless exactly when you need them.
- On-device buffer: a fixed-size LittleFS ring buffer of events, so a week-long network outage doesn't lose the data.
- Collector: a FastAPI service writing to SQLite, fed over MQTT to Mosquitto. Small enough to run on the same Pi as everything else.
- UI: a single-page summary — events table, monthly uptime figure, a voltage histogram — plus a CSV export written to be pasted into a claim.
Scope for v1
In:
- One node, one household.
- Four event types: outage start, outage end, sag below a configurable threshold, frequency excursion.
- Supercap ride-through and offline buffering.
- Web summary page and CSV export.
Out:
- Current measurement and energy cost. CT clamps are a different product and a much bigger install story.
- Three-phase and industrial supplies.
- Any claim of metrology-grade accuracy. You are reporting relative behaviour, not certifying a meter.
Where it could go
The obvious next step is more than one node. Put boxes in five houses on a street and you can tell whether a sag is your wiring or your feeder — a distinction neither the homeowner nor the utility call centre can usually make, and one that moves a complaint from anecdote to evidence. A neighbourhood view is a genuinely new dataset.
After that, act on the log rather than just keeping it. The collector already knows, to the second, how long your outages run and how deep your sags go, which is exactly the input for a UPS runtime recommendation. The same signal can trigger a graceful NAS shutdown over the network the moment mains drops, using the ride-through window the node already has. Longer term, a public archive of anonymised sag and frequency data per postcode would be useful to regulators and to anyone choosing where to put a home lab.
Watch out for
Anything near mains invites people to improvise, so the design has to make the isolated AC-AC adapter the only supported sensing path and say so loudly in the build guide. The other trap is the ESP32's ADC: it is nonlinear and noisy, so calibrate per unit against a known reference and present voltages as trends rather than absolute readings you'd defend in court.