Power Control: Keeping My Work Alive Through Outages
I built a local system that watches my UPS, safely hibernates my workstation during an outage, and lets me pick up where I left off.
01 It started with the power cuts
I live in Pakistan. Power outages here have a habit of turning up in the middle of whatever you’re doing, and for a long time they meant watching my computer switch off without warning.
I’d be working on something, the power would go out, and there went whatever I hadn’t saved. It started to feel personal. More importantly, I didn’t like the thought of repeatedly cutting power to equipment I’d spent quite a bit on.
I looked at generators and conventional UPS options. The sticking point for me was the changeover from one power source to another. I wanted the workstation to carry on without even a brief interruption.
That’s how I came across online, double-conversion UPS systems. In normal double-conversion operation, the inverter supplies the output continuously, so a mains failure doesn’t need the usual output transfer. I found a unit that suited my setup and ordered it.
When it arrived, I unwrapped it like a child who’d finally got the toy they’d been asking for all year. Yes, I was that excited about a UPS.
And it worked. The power would go out and the computer wouldn’t even flicker. I could save my work, shut down calmly, or sometimes let the UPS carry the entire outage. For a while, I thought I’d solved it.
02 Then the displays went dark
The next problem was different. The UPS kept the PC running, but the monitors lost mains power. Within seconds, remote desktop could connect without giving me a usable image. Sometimes I’d get a waiting screen. Other times, just black.
The computer still had battery power for tens of minutes. It was my view of the computer that disappeared in seconds. If an outage lasted long enough, the battery could still run out before I got back to the machine.
I could’ve taken a simpler route. Enable SSH and send a shutdown command, put a monitor on the UPS, or try a dummy or virtual display so the remote-capture software always had something to show. Those were all reasonable options. Some are still worth exploring.
Instead, I decided to build a power-control system. Possibly a little overkill, but I had another problem that those options didn’t fully solve.
03 The problem while I was asleep
I sometimes leave AI coding agents working overnight. On a good morning, I wake up and see what they finished. On a bad one, I wake up to a dead PC that may as well be asking, “How could you do this to me?”
SSH only helps if somebody sends the command. A working remote display only helps if somebody is there to use it.
I wanted two things: when I’m around, let me see the UPS and control the workstation from my phone; when I’m asleep, protect the running Windows session automatically without needing the phone, remote desktop, ChatGPT or an internet connection.
That’s the reason I kept going beyond the simpler fixes.
04 How the system works
The online UPS has a USB management connection. Using Network UPS Tools (NUT), my Raspberry Pi 4 can read whether mains power is present, battery charge, UPS load, estimated runtime and other available readings.
The Pi runs the local protection policy. It asks a small Windows service to perform native power actions, and it reports status to a Flutter Android app. I can use the phone for manual controls, but the automatic safety path doesn’t depend on it.
- Online UPSUSB / NUT
- Android appManual controls
- From Online UPS + Android appRaspberry Pi 4Policy controller
- From Raspberry Pi 4Windows serviceSigned actions
- From Windows serviceWorkstationPower operations
I defined the problem, chose the system boundaries and coordinated the testing on the real hardware. AI coding agents helped implement and review the software. My part was making sure the decisions, handoffs and finished behavior held up outside the code editor.
05 Three ways to power down, and one way back
Hibernate
Saves the Windows session to disk, then powers down into S4. This became the preferred way to protect my active work.
Graceful shutdown
Asks Windows to shut down normally when I actually want to end the session.
Force shutdown
A last-resort OS shutdown that can lose unsaved work. It requires a hold-to-confirm action on the phone. Automatic Force stays disabled.
Wake
After stable mains power returns, the phone can request a guarded Wake-on-LAN through the Pi to resume a hibernated workstation. Wake is manual today.
The app also shows UPS status, connection freshness, PC state and a limited list of visible applications called Active Work. That list gives me some context before acting, but it doesn’t promise that an application has saved its files.
Technical Delivery
Making it one testable piece at a time
I split the implementation into UPS telemetry, the Windows agent, the Pi controller and finally the Android interface. Each part had a clear contract. We tested signed status and dry-run requests before allowing any real power action.
I also kept acceptance separate from implementation. A passing build wasn’t the finish line. The milestone had to work from phone to Pi to Windows, and the machine had to recover afterward.
Systems Reliability
Keeping the failure paths separate
The Pi makes the automatic decision locally. Windows owns the native power action. The phone can disappear without stopping the protection policy.
Power commands also need more care than normal API calls. A lost acknowledgment doesn’t necessarily mean the command failed. We used authenticated requests, durable request IDs and conservative recovery so an uncertain result wouldn’t cause another destructive command to be sent blindly.
Product Experience
Showing what the system actually knows
I wanted the phone to make sense even when something went wrong. Fresh, stale and missing readings need to look different. A button shouldn’t be available just because it fits on the screen.
The backend supplies the permitted actions, and the UI follows that state. Hibernate and normal shutdown use straightforward confirmations. Force needs a deliberate hold. The interface helps me make a decision without becoming the safety controller.
06 The test that changed the plan
The first idea for unattended protection was Force Shutdown before the UPS ran out. That would’ve prevented an uncontrolled loss of power, but it could still have ended the work I was trying to protect.
Then we tested Hibernate.
In one attended test, Windows entered genuine S4 and the workstation powered down in about 16 seconds. When it came back, an unsaved Notepad test, browser tabs and my terminal were still there. The Pi kept reading UPS data while the PC was hibernated.
The UPS had reported about 6% load with the workstation running. After Hibernate, it displayed 0%, which means the load fell below its reporting resolution, rather than literally zero watts. I couldn’t turn that into an exact number of extra backup minutes, but the reduction was clear.
So I changed the automatic policy to Hibernate first. Manual Force stayed available as a separate last-resort action.
That made Wake-on-LAN worth investigating. An older network driver hadn’t exposed the needed wake capability. After updating the driver and checking the firmware configuration, we tested waking from S4 and got the same Windows session back.
- 5 Oct 2026
Defined the actual problem
Separate display/remote-access loss from UPS-backed workstation runtime
- 6 Oct 2026
Qualified the real controls
UPS transitions, native Hibernate, shutdown, manual Force, Wake and recovery tests
- 6 Oct 2026
Proved automatic Hibernate
An attended battery-threshold test caused one Hibernate and a later manual Wake
- 7 Oct 2026
Accepted the operational system
Automatic Hibernate enabled, automatic Force and automatic Wake left disabled
07 What happened when we tested it
We did dry-run integration first, then tested real actions on the workstation. The observed power-down times were roughly 16 seconds for Hibernate, 10–12 seconds for the final accepted graceful Shutdown, and 15 seconds for manual Force. Those are individual test observations, not guaranteed response times.
We also tested the parts that tend to get missed. One restricted Windows helper couldn’t establish the right service identity. After the first graceful Shutdown, the workstation booted but the agent still treated its old request as unresolved, so new controls stayed blocked. We fixed the recovery logic and repeated the real shutdown test.
Automatic Hibernate received a separate attended proof. The battery-percentage trigger sent one Hibernate request during an outage. After mains returned, I manually Woke the PC. The elapsed-time and UPS low-battery trigger paths were tested without performing live power actions, so I wouldn’t call those separate real-outage proofs.
Technical Delivery
Testing the result, not just the feature
The important failures surfaced during integration and recovery. A real shutdown uncovered behavior that a build or an isolated unit test couldn’t establish.
That’s why I kept the work in stages and checked the final path on actual hardware. A feature that works once but leaves the system unusable after restart still needs work.
Systems Reliability
Unknown has to remain unknown
The difficult cases were stale status, lost acknowledgments, restarts during a power action and an old request still present after boot.
I wanted the controller to distinguish accepted, pending, unknown and completed states. When it couldn’t prove an action was safe, it withheld it. I preferred that to guessing or escalating automatically to Force.
Product Experience
The recovery state belongs in the interface too
When the Windows agent was unsure after a reboot, the app correctly offered no new power actions. After we fixed the recovery path, the normal controls became available again.
The phone now distinguishes a request being accepted from the machine finishing the action. That makes the display more useful when something doesn’t go exactly to plan.
08 What happens when nobody is watching
At project close, the Pi was configured to request one automatic Hibernate per outage when any of these conditions is reached after its safety checks: battery charge at or below 50%, an outage lasting at least 10 minutes, or the UPS low-battery signal.
- Power cutOn battery
- From Power cutPi checks50% / 10 min / LB
- From Pi checksHibernatePreserve session
- From HibernateManual WakeStable mains
Now, if the power cuts out while I’m asleep and the conditions are met, the workstation can Hibernate without asking me. When I wake up, I can check the status, wait for mains to be stable, and resume the same Windows session from my phone.
It doesn’t mean every cloud-based AI task will reconnect and continue automatically. Preserving the session gives the local work a much better chance of surviving than letting the UPS run flat.
09 What I'd improve next
I’d like to collect more real outage data so I can judge battery health and tune the protection thresholds. That history belongs outside the controller’s safety path. If a logging service goes down, the Pi should still protect the computer.
I’d also like to explore automatic Wake after power has been stable for a while. It could help overnight work resume without me, but it needs more testing around repeated outages, recovery state and what happens to AI jobs when the machine comes back. Automatic Wake is not enabled now.
The remote-display issue can still be fixed separately, and there’s a small battery-status label in the Flutter app I’d like to clean up.
Was a Raspberry Pi controller, a Windows service and an Android app a little much for a power cut? Maybe. But now I don’t have to race the battery every time the lights go out, and waking up to a hibernating PC is considerably better than finding a dead one.