A mini UPS keeps the smart home intelligent

A Raspberry Pi running Home Assistant, a small access point, and a small switch sit in a cupboard, plugged into a strip that has to survive far less than people assume: not a multi-hour blackout, just long enough for the grid to recover or the board to shut down cleanly. That's the whole design brief for a mini UPS in a smart home. Most people size the battery like they're protecting a desktop PC, not a coordinator other devices in the house depend on.

I've seen both failure modes: a UPS sized like a small generator under a Pi drawing a few watts, or no UPS at all, with an SD card corrupting a bit more each time a fuse trips somewhere on the block. Bridge power, not backup power. The job is keeping one small, boring control path alive long enough to finish a graceful shutdown or ride the interruption out unnoticed.

Write the shutdown script before you shop for a battery

Write the event, the input, the output, and the deadline in four lines before buying anything. "Add a UPS" tells you nothing about what has to survive or for how long. "When mains drops, the Pi finishes any pending write, unmounts cleanly, and resumes automations within a few seconds of power returning" is testable, and it shows you which parts need no battery at all: a sensor already reporting its own state locally doesn't care what the coordinator is doing.

The first useful move isn't shopping, it's sizing the protected core: decide which devices count, expose battery state to Home Assistant so automations know they're running on borrowed time, script the clean shutdown, then test recovery instead of trusting it works. The board matters less than you'd think; whatever you land on for hardware for local LLMs matters far less than storage, supply, cooling, and the service that consumes the output.

Test against the outage pattern your area produces, not a lab simulation. A short blink behaves differently than a long brownout, and a UPS handling one badly usually handles the other worse. Edge deployments amplify ordinary variation: a warm cabinet, a marginal cable, a database write mid-flight. Any of it moves the outcome more than the battery brand you picked.

Keep a short field record:

UPS runtime under real load, switch and router included
shutdown trigger threshold and script exit time
cold boot time after a full discharge
automation state after an abrupt cut vs. a graceful one
duplicate trigger or notification after reconnect

None of this has anything to do with whether the local model is accurate. What matters for a feature other people rely on:

• whether it produces duplicate notifications after a reconnect
• whether the board comes back up on its own after a hard reboot
• whether automations resume once the network returns, not just once the Pi boots
• whether the house degrades safely when the inference service is the one thing still down

If turning a light on requires knowing which container died, the feature isn't finished yet.

A battery under one board is not resilience

The most common mistake I see: protecting the single-board computer while the router and access point beside it still go dark the moment the strip loses power. If the Pi survives but the network doesn't, you've built an expensive brick that logs its own uselessness. Put the switch and access point on the same UPS, or accept that your setup only survives outages where the internet also stays up, which is rarely the one you're planning for.

That same logic runs past the power hardware into the software on top of it. Generative output can interpret a request, summarize a history, or rank a few options, but it should not be the only thing standing between a person and a lock, a heater, an alarm, a valve, or the UPS's own load-shedding logic. Ranges, permissions, timeouts, confirmations, and interlocks belong in plain deterministic code, not a prompt. Camera captions, calendar entries, MQTT payloads, and voice transcripts are data the system reads, not instructions it obeys.

Privacy needs the same full-path thinking as power. Local inference stops one upload, but recordings, logs, thumbnails, backups, and a remote dashboard can still leave copies you never see. Decide up front what gets kept, for how long, and who can pull it during a debug session. The most private frame is the one the camera never captures. The next best is thrown away right after the decision it was needed for.

Run the gateway like an appliance, not a demo left running: a service manager or a small pinned container, config kept apart from the model files, and a health check that proves the actual function works, not just that a process owns a port. Back up the controller state, track which model file is running, and keep a known-good storage image for any node installed somewhere you don't want to visit twice.

Power and heat belong in that same acceptance test, not a separate one you skip once the first passes. Run the enclosure until it reaches real thermal equilibrium and measure draw at the wall with everything plugged in and working: that combined number is what the UPS has to carry, not the figure on the board's spec sheet. If the setup throttles, swaps, corrupts storage, or hogs the machine also running Home Assistant, it isn't finished, even if the model performs fine alone.

The rule that's held up for me: keep the control path alive long enough to shut down cleanly or ride the gap out, and treat the model as a narrow layer above sensors that already work and below a household policy a person could read. That's the shape of any resilient AI architecture: when a piece goes missing, the system gets less clever, not silent.

What I'd check next: pull power for real, not a graceful shutdown command but the actual mains cut, mid-write, and time how long the switch and access point stay reachable on battery, how long the Pi takes to unmount and resume or power down cleanly, and whether Home Assistant fires any automation twice once the network returns. If those numbers surprise you, the UPS is the wrong size or the shutdown script isn't running. Better to find out on a quiet afternoon than during the outage that matters.