Plug-In Voltage and Outage Logger for Mapping Neighbourhood Power Quality

The problem: everyone knows the power is bad, nobody has the numbers

In many South Asian cities, power cuts are routine, and voltage can sag low enough to stall fridges and air conditioners or surge high enough to damage them. Households buy stabilisers and UPS units, shopkeepers replace burnt motors, and complaints to the utility go nowhere because nobody has a record. Utilities often do not know either: their systems see the feeder, not what reaches each house.

Measuring this is not hard. A small device in a wall socket can log voltage and outages continuously. Many of them across a city can show which areas suffer most, how actual outages compare with announced schedules, and whether things improve after the utility invests.

What already exists and the gap

• Utility systems measure feeders and substations; their data is rarely public.
• Load-shedding schedule apps show announced outage times, not what actually happened.
• Smart plugs and energy monitors measure appliance use; few log power quality events, and their data stays in the vendor's app.
• nLine, a company that grew out of the University of California, Berkeley research, deploys sensor networks to measure grid reliability for utilities and development agencies.

The gap is an open, low-cost design that students, consumer groups or journalists can build and deploy themselves, producing a shared, citable dataset.

Inspiration

Klugman and colleagues' paper "Watching the Grid: Utility-Independent Measurements of Electricity Reliability in Accra, Ghana" (IPSN 2021) describes PowerWatch: 462 sensors in homes and businesses for over a year, measuring outages and voltage independently of the utility. They found nearly twice as many outages as the utility had recorded. Your project is a smaller, student-scale version of PowerWatch for a South Asian city.

What you build

• The device plugs into a socket, measures voltage and frequency through an enclosed metering module, and keeps a timestamped log.
• When power fails, a supercapacitor or small battery keeps the microcontroller alive long enough to record the exact time, and the real-time clock keeps time until power returns.
• The server receives buffered logs, detects events and stores them per location.
• The public dashboard shows a map of outage hours and voltage quality by area, without revealing any household's identity.

The technically interesting part

• Recording an outage when the power is gone. Detect the loss of mains quickly, write the event to flash, and shut down cleanly. Measure how long your backup supply lasts.
• Time you can trust. Combining logs from many homes requires accurate clocks. Sync with network time when online, keep a real-time clock otherwise, and measure drift.
• Event definitions. Decide what counts as a dip, a surge or an outage, following common power quality definitions, and make thresholds configurable.
• Comparing with schedules. Match measured outages to announced load-shedding slots and quantify unscheduled outages.
• Privacy. Report locations at neighbourhood level, never exact addresses.
• Feeder inference. When several devices lose power at the same second, they probably share a feeder or transformer. Group simultaneous outages to sketch which homes share supply, and check the guess with the utility or residents where you can.
• Device health. A device that stops reporting may be unplugged rather than in an outage. Send a heartbeat, and distinguish a missing device from a power cut before counting outage hours.

How to evaluate it

• Voltage accuracy: compare readings with a calibrated multimeter at several voltages.
• Outage timing: start and end times against a second device or a manual log, to the second.
• Data completeness: share of expected data received from each device.
• Findings: outage hours and unscheduled outages per neighbourhood over the deployment.

Suggested plan

• Weeks 1 to 3: learn about power quality, read the PowerWatch paper, test the metering module.
• Weeks 4 to 6: firmware, outage detection, backup supply, clock.
• Weeks 7 to 9: server, event detection, dashboard.
• Weeks 10 to 13: deploy five or more devices for several weeks.
• Weeks 14 to 15: analysis, report and demo.

Path to a product

Consumer groups, journalists, regulators, solar and UPS companies, and development agencies funding grid improvements all want independent reliability data. A low-cost device with an open dataset is valuable on its own, and a paid analytics service for utilities and funders is a realistic next step. The project is an excellent beginner introduction to embedded systems with real impact.

Scope warning

Work with mains voltage only through an enclosed, certified metering module and a properly built plug-in enclosure, under the supervision of a lab engineer. Never open a powered device. Do not publish household addresses or anything that identifies a home. Keep the first deployment small, five to ten devices with hosts you know, so that you can visit them when something goes wrong.

Learn what you need on Sefism

• Embedded systems and IoT roadmap: microcontrollers, sensors and connectivity.
• Embedded systems and IoT cheat sheet: UART modules, timers and storage.
• Arduino Documentation: a beginner-friendly start on the ESP32.
• PostgreSQL Documentation: storing time series events.
• Grafana Documentation: the reliability dashboard.

Get help with this idea

The value here is trustworthy timestamps and a clean dataset. Tauseef can help you plan the safe hardware setup, the deployment and the analysis you present at the end. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session