Power Outage Alert Projects That Record Duration

A power outage alert is useless if the outage kills the alert before it leaves the house. The useful design keeps sensing and reporting alive on stored energy, uses a communication path that does not share the failed infrastructure, and records duration rather than a bare on/off event.

What a useful outage monitor must survive

Start by drawing the failure boundary. A monitor powered by the same mains supply as the load can detect that power disappeared, but it cannot deliver an alert after its own supply fails unless it has another energy source. A monitor that sends through the same internet connection has the same weakness: an outage alert that depends on the same mains supply and the same internet connection cannot be delivered.

Our basic architecture is:

• an isolated mains-presence signal, normally produced by a certified low-voltage AC adapter or an appropriately rated isolated sensing module
• a controller powered through a changeover or power-path circuit
• stored energy sized for the required reporting and logging period
• a clock that continues through the outage
• a communications path with independent power and a different dependency from the failed mains and internet service
• a return-to-mains event, so the device can report both edges

Do not connect a hobby board directly to mains. The sensing side, creepage, clearance, fusing, enclosure, strain relief, and test procedure depend on the voltage system and applicable electrical rules. For many makers, the safest project is a low-voltage monitor connected to a certified plug-in power supply whose output disappears during the outage.

Battery sizing is not just capacity divided by current. Measure the controller's sleep current, active current, modem transmit peaks, regulator losses, battery voltage across discharge, and the time spent awake. A cellular radio can draw short high-current bursts that reset a weak supply even when the average current looks harmless. Add a local capacitor near the modem, but do not use that capacitor to hide an undersized battery or regulator.

Project 1: A local outage logger with a real end time

Problem solved: You need to know whether a tool controller, network cabinet, aquarium, or freezer lost power, even if no remote alert is required.

Main parts: A low-power microcontroller, isolated mains-presence input, rechargeable battery or primary cells, real-time clock with backup retention, non-volatile memory, status LED, enclosure, and a short cable or plug-in adapter for the sensed supply.

The controller records a timestamp when mains presence disappears and another when it returns. Store an event record such as start time, end time, duration, minimum battery voltage, and firmware reset count. A circular log limits wear and makes recovery predictable. FRAM is convenient for frequent small records; an SD card is useful for larger histories but adds filesystem failure modes and higher active current.

The hard part is preserving trustworthy time. A real-time clock may drift, lose its backup supply, or begin with an unset date. Set it from a known reference during commissioning, record whether the clock was valid, and keep the clock powered during controller resets. If the device has no accurate time source, duration can still be measured with a monotonic counter, but the event will not have a reliable calendar timestamp.

Use a defined debounce period for both transitions. Brief supply dips can create false outages, while a long debounce hides short interruptions. The right value depends on what you are monitoring. Log raw transition timing during testing before deciding which events to merge.

This is the project we would pick first for most benches. It is cheap, useful, and does not need a radio subscription or remote service. The honest limitation is that it cannot tell you anything while you are away unless somebody reads the log later.

Project 2: A cellular power outage alert that survives the router

Problem solved: You need a message during an outage at a site where the mains supply, router, broadband connection, or local Wi-Fi may all be down.

Main parts: A microcontroller, cellular modem and suitable SIM service, cellular antenna, battery-backed regulator, isolated mains-presence input, non-volatile event storage, real-time clock, enclosure, and an external or well-positioned antenna connection if the enclosure blocks radio performance.

The modem must be powered from the backup side, not from the failed mains adapter. The alert path should also be independent of the local internet connection. Cellular SMS is easy to understand and often adequate for a short event message. Cellular data can send to an application endpoint, but that adds server availability, credentials, retry logic, and a way to distinguish a device that is offline from one that has not yet sent its queued event.

A first alert might say that mains disappeared at a recorded time. A second message after restoration should include the calculated outage duration. We prefer a small retry schedule with increasing intervals, then a local record that remains authoritative even if every remote attempt fails. Sending every few minutes wastes battery and can create a flood during a network problem; sending only once risks losing the message if the modem cannot register at that moment.

The difficult part is modem power integrity and network recovery. Cellular modules can take a much larger current pulse while transmitting than their idle figure suggests. A regulator with the right nominal voltage can still fail because its transient response, wiring resistance, battery voltage, or thermal limit is wrong. Test with the actual antenna, enclosure, cable length, and weakest battery condition you expect.

Also test loss of service separately from loss of mains. Confirm that the device queues the alert and sends it after registration returns. A successful desk test proves almost nothing if it was performed beside a strong tower with a full battery.

The cheap way is good enough here: if an alert only needs to reach one or two people, SMS may be preferable to building a dashboard. A web application is an upgrade only if you need fleet history, acknowledgements, user management, or charts.

Projects 3 and 4: Temperature and heating-system monitors

A freezer monitor needs to know whether frozen contents stayed within an acceptable temperature range, not just whether the freezer lost power. Its main parts are a temperature probe suited to the expected range, a low-power logger, backup battery, isolated mains-presence input, non-volatile storage, real-time clock, insulated probe mount, and optional independent alert path.

Record three different facts: mains state, air or product-proxy temperature, and elapsed time. They should not be collapsed into one alarm. A freezer may warm slowly during a short outage, while a temperature-sensitive process may become unacceptable before the room feels different. A probe hanging in free air responds quickly and can exaggerate door-opening effects; a probe mounted against a thermal mass better represents stored contents but can hide a brief warm excursion. Pick the location to answer the decision you will make later.

Compare the assembled probe against a reference at several relevant temperatures. Record sensor faults as faults; do not convert a disconnected probe into a plausible temperature. A practical record contains outage timestamps and duration, temperature at fixed intervals, lowest battery voltage, probe and controller faults, storage status, and whether an alert was acknowledged. Add cellular reporting only if the temperature decision must be made before someone can inspect the freezer.

A heating-system monitor distinguishes a general mains outage from a heating fault. Its parts include a battery-backed controller, isolated mains-presence input, isolated or manufacturer-approved heating call input, temperature sensor, optional pipe or room sensor, real-time clock, non-volatile storage, and a separate alert path if remote notification is required.

Do not infer heating performance from house mains state alone. A system can have power while its controller, pump, fuel supply, safety interlock, or thermostat circuit has failed. Give each input its own logged state: building mains, heating call or controller status, and resulting temperature. An isolated dry-contact input may be appropriate, but the interface must match the equipment's voltage, current, switching method, and approval requirements.

The useful failure definition is “heat requested but room temperature falling,” not simply “heat off,” which may be normal when the setpoint is satisfied. Build a baseline from logged states before setting an alarm. This project is not worth building if the only question is whether the building lost mains; the local logger answers that with fewer parts.

Choosing and testing the finished design

Size the design for the decision, not for an impressive feature list. A local logger with a good clock beats a remote alert that cannot prove when the outage ended. A cellular message beats a Wi-Fi notification if the router is on the failed supply. A temperature trace beats both if the real concern is whether stored contents crossed a limit.

Test the complete failure path with the load disconnected from danger and the enclosure closed. Remove mains power at the point the monitor actually senses, not by unplugging only the controller's backup charger. Check that the device detects the transition, stays alive, records the time, and attempts the intended report.

Then test the awkward cases: restore mains before the first alert retry, cut power during a modem transmission, remove the network while mains remains present, reset the controller during an outage, let the battery reach its low-voltage cutoff, fill the event log, and return power after a long interval. Measure voltage at the controller and modem during transmission, not only at the battery terminals. Confirm the clock after a reset and after the backup battery has been disconnected.

The final acceptance test should answer one sentence without interpretation: “Power was absent from this monitored circuit from this timestamp until that timestamp, and the alert path either delivered or failed for this recorded reason.” If the device cannot answer that, it is an indicator, not yet a useful outage monitor.

Frequently asked questions

Can Wi-Fi send a power outage alert?

Only while the access point, router, internet connection, and monitor remain powered and available. A Wi-Fi monitor on the same mains supply and same internet connection cannot reliably report that supply failure. Use a battery-backed cellular path, or accept that the device will log the event for later inspection.

How long should the backup battery last?

Long enough to cover the outage duration you need to observe, plus startup, retries, modem registration, battery aging, and conversion losses. Measure the assembled device in its highest-current state and test it at the lowest battery voltage it will encounter. Do not size it from the controller's sleep-current figure alone.

Is an outage timestamp enough for a freezer?

No. The timestamp tells you how long mains was absent, not how warm the contents became. Log temperature at a probe location chosen to represent the stored load, and keep the outage duration as a separate field so the two measurements can be interpreted together.

The Boss Factory builds this kind of work to order through Custom Electronics & Smart Systems and Smart Home Integration.