PowerCut

When backup power is limited, every choice matters. PowerCut helps households protect what matters most, explore verified alternatives, and plan together on Fire TV.

Comment

PowerCut: Plan What Stays Powered

Inspiration

When the power goes out, not everything can stay on.

A household might have a backup battery, but what happens when its capacity isn't enough for everything? The refrigerator needs to keep food cold. Someone needs their laptop for work. Another person wants the fan running through the night.

The problem isn't simply calculating how much electricity these appliances consume. It's deciding what matters most when not everything can run at once.

That question inspired PowerCut.

I wanted to build something more useful than another energy calculator. Instead of simply warning that a household has exceeded its battery capacity, I wanted an application that could explain the problem, calculate realistic alternatives within a defined energy model, and help people make informed compromises.

I chose Fire TV deliberately. Household decisions are often shared decisions, yet most planning tools are designed around one person looking at a phone. A television offers a shared screen where everyone can see the same constraints, discuss their priorities, and compare possible solutions.

PowerCut turns a technical optimization problem into a household decision.

What it does

PowerCut is a standalone backup-power planning application built for Amazon's Vega platform.

Using only a TV remote, households can configure the required runtime of six appliances, adjust their battery's usable energy capacity and maximum output, and decide which appliances they consider essential.

PowerCut then calculates whether the requested plan is feasible.

If the battery cannot support everything, the application does more than display an error. It identifies the conflicting requirements, explains why the plan fails, and calculates up to two independently verified alternatives.

Each alternative shows what stays powered, what needs to be reduced, how much battery capacity remains, and whether an essential appliance would be affected.

The defining feature is household-controlled priorities.

A refrigerator and router are marked essential by default, but the household can change those selections directly with the TV remote.

For example, PowerCut might initially recommend reducing the fan from four hours to one. But what if keeping the fan running is particularly important tonight?

Marking the fan as essential changes the optimization itself. The original fan-reduction recommendation is replaced by another option, while the application continues to distinguish alternatives that preserve essentials from those requiring an explicit compromise.

This isn't a cosmetic badge or a hardcoded recommendation. The household's choices become part of the mathematical problem being solved.

When an alternative affects a refrigerator or router, PowerCut also displays an explicit caution. A plan can satisfy the energy model without guaranteeing food safety, connectivity, or the performance of real electrical equipment.

How I built it

PowerCut combines React Native, TypeScript, Amazon Vega, the Kepler TV APIs, and constraint optimization.

The frontend was designed specifically for television interaction, with remote-controlled appliance cards, visible D-pad focus states, runtime steppers, a live battery overview, and side-by-side alternative comparisons.

Behind that interface is a deterministic optimization engine.

I began by developing a Python reference implementation consisting of a constraint solver, an independent schedule verifier, and a repair-search algorithm.

The solver uses dynamic programming to evaluate appliance scheduling requirements against available energy, maximum simultaneous power, and operating windows.

When the requested plan is infeasible, a separate repair-search process explores appliance-runtime reductions. It prioritizes preserving household-selected essentials and uses binary search and feasibility-frontier exploration to identify low-sacrifice alternatives within its one-or-two-appliance search scope.

Every proposed schedule is checked again by an independent verifier before being displayed.

One of the most important architectural decisions was removing the need for a separate backend.

I ported the complete optimization engine to TypeScript so that it executes directly inside the Vega application.

PowerCut now runs its calculations on-device, without a cloud service, external API, or companion server. The original Python engine remains in the repository as a reference implementation for testing.

To validate the TypeScript port, I built a differential-testing suite comparing its outputs against the Python engine across 230 scenarios, including randomized inputs, edge cases, and different household-priority selections.

Challenges I faced

Making the recommendations genuinely correct

Producing an alternative that appears feasible is relatively easy. Establishing that the result actually satisfies the constraints, respects household priorities, and ranks consistently is much harder.

During adversarial testing, I discovered that equally ranked repairs could appear in different orders depending on Python's hash-seed-driven iteration order. I fixed this with deterministic tie-breaking and verified the behavior across multiple hash seeds.

I also used exhaustive brute-force checks to validate repair minimality within the algorithm's defined search scope.

Running optimization directly on Vega

The earliest version used a Python backend. Moving everything into the application made PowerCut much more self-contained, but introduced new performance considerations.

Profiling revealed that the fallback repair search repeated calculations that had already been completed. Eliminating that redundant work reduced solver calls from 770 to 629 in the tested difficult scenario, an 18.3% reduction.

Some challenging configurations can still take approximately two seconds to evaluate on the Virtual Device. I documented this limitation rather than claiming that every calculation is instantaneous.

Building for a real television, not a desktop

Television interfaces have very different constraints from conventional web applications.

During Virtual Device testing, I discovered that some controls were rendering outside the visible screen because I had underestimated the device's display scaling. The controls were technically focusable but invisible.

I reworked the layout for the actual 1920 × 1080 output, verified D-pad navigation, and improved focus visibility and text contrast.

Distinguishing mathematical feasibility from real-world safety

One important design challenge was making sure the interface did not imply that every mathematically feasible recommendation was physically safe.

PowerCut uses illustrative appliance consumption estimates. It does not measure actual devices or model every electrical and battery behavior.

I added explicit cautions wherever a suggested compromise affects refrigerator runtime or connectivity, so the interface communicates the limits of its calculations rather than overstating their reliability.

Accomplishments I'm proud of

PowerCut progressed from an initial feasibility experiment to a functioning, independently runnable Vega application.

The completed engineering milestone passed 294 automated checks, covering the interactive frontend, Python reference implementation, optimization logic, and TypeScript differential testing.

The project also includes an independently implemented schedule verifier, adversarial correctness tests, deterministic repair ranking, configurable household priorities, and real Virtual Device testing.

I'm particularly proud that the most meaningful feature isn't just a visual interaction. When a household changes its priorities, the underlying algorithm changes the solutions it offers.

And all of this runs directly inside the application, without relying on a separate backend.

What I learned

Building PowerCut reinforced an important distinction: a mathematically correct solution isn't necessarily the right solution for the person using it.

An algorithm might find a way to fit within an energy budget by reducing a particular appliance. But if that appliance matters most to the household, the technically feasible solution may be the least desirable one.

The challenge was to make household preferences part of the optimization process itself, while still being transparent about which constraints could and could not be satisfied.

I also learned how valuable independent verification, differential testing, adversarial edge cases, and real-device validation are when building software that makes recommendations people might rely on.

What's next

PowerCut is a working hackathon prototype, with several directions for future development.

I'd like to support customizable appliance profiles, measured rather than illustrative power consumption, flexible outage durations, persistent household plans, and more advanced optimization across larger numbers of appliances.

I'd also like to test the experience with real households to understand how people interpret the recommendations and whether a shared television genuinely helps them make decisions together.

The long-term vision is a practical planning tool that makes limited backup power easier to understand and manage.

Because when power is limited, the best plan isn't simply the one that fits. It's the one that protects what matters most.

Built With

Share this project:

Updates

Submission history