What battery backup can't fix in a smart home power outage

Power returns, the hub light comes back, and the house still does not behave the way it did before the outage. That is the part most smart-home battery backup advice for power outages skips. The blackout is often simple: no power means no powered devices. The recovery is where the surprises show up — a plug restores off, a bulb turns on, a sensor is alive but missing from the app, or a hub has power but no useful path to the cloud.

This is worth planning for, but not because there is one national “normal outage” to design around. U.S. electricity customers averaged 11 hours of interruptions in 2024, nearly double the prior decade’s annual average, while state-level experience varied sharply: South Carolina was around 53 hours and Arizona was under 2 hours in that same year. [1]

The hub is the first fork in the recovery path

The first question after an outage is not “Which battery did I buy?” It is “Was there still a controller in the house when everything else disappeared?” A battery-powered contact sensor can keep sensing. A thermostat may have its own battery. A leak sensor may never have lost power at all. But if the hub, router, or cloud path vanished first, those devices may be functionally invisible until the control path comes back.

The SmartThings example is the cleanest warning against ecosystem-level assumptions. EVVR states that SmartThings Hub gen 2 includes a backup battery, while SmartThings Hub gen 3 does not. [2] That does not prove every SmartThings installation survives an outage in a useful way, and it does not say every automation will keep running. It only establishes a narrower but important point: two hubs in the same broad ecosystem can have different power-failure behavior before you even get to the devices.

A hub plugged into a UPS is in the same category. It may stay electrically alive. That is useful if the radios, local automation engine, and network path it needs are also alive. It is less useful when the setup depends on a cloud decision loop and the WAN link is gone, or when the app and voice assistant need servers outside the home. Backup power can preserve a box; it cannot convert a cloud-first control path into a local one at 3 a.m.

This is why two homes with the same UPS runtime can recover differently. In one, local automations keep a few Zigbee or Z-Wave rules working because the hub, coordinator, and router stayed up. In the other, the hub LED is on, but voice commands, cloud routines, and remote app control are waiting on the internet path. The owner sees “powered,” but the system is still missing the part that makes decisions.

If the immediate problem is that devices are already offline, the repair path belongs in a fix sequence, not here. NestGrid’s smart home reconnect after power outage guide handles the order-of-operations work. The compatibility question is more basic: before the next outage, label the controller path as battery-backed, UPS-backed, or unbacked — then label whether it can still make decisions locally.

Power-on state is where the house comes back “wrong”

Once a plug, bulb, relay, or switch actually loses power, the hub usually is not the first authority anymore. The device’s firmware decides what happens when voltage returns. That choice may be fixed by the manufacturer, exposed as a parameter, or surfaced differently depending on the platform.

That table is more useful than a generic “use a UPS” rule because it predicts the visible mess. A freezer plug that restores off is a different risk than a lamp that restores on. A porch light that restores previous state behaves differently depending on whether it was on or off when the outage started. A Zooz or Tuya-style configurable behavior is only helpful if someone checked the parameter before the event.

The status labels matter. The GE, Linear, GoControl, Schlage, Leviton, IKEA, and Zooz entries above come from a long-running SmartThings Community FAQ, not from a current independent lab retest across every model and firmware revision. [3] The Tuya 0/1/2 mapping comes from Home Assistant community documentation and discussion, which is useful for platform users but still depends on whether a specific integration and device expose the value cleanly. [4]

The practical test is simple: for every powered device that matters, record its post-outage state as one of four labels — OFF, ON, previous, or configurable. If it is configurable, record the actual setting, not just the brand. The hub may later report the device correctly, but the device may already have made the decision that matters.

Why some Zigbee devices take their time

Zigbee recovery can look broken when it is really just slow. Community reports often describe devices taking up to 1–2 hours to rejoin after an outage, with recovery tied to periodic heartbeat or check-in behavior. That timing should be treated as community-reported, not a guaranteed protocol limit or a confirmed benchmark. Mesh layout, sleeping device behavior, coordinator state, firmware, and whether repeaters came back cleanly can all change the result.

The important consequence is that a UPS cannot make every Zigbee device hurry. It can keep the coordinator or hub from losing power. It may prevent one disruption if the mesh around it also stays stable. But if a battery sensor is sleeping, or if a mains-powered router device comes back after the coordinator has already rebuilt part of the mesh, the recovery sequence can still lag.

This is where owners often make recovery worse. They see devices offline five minutes after power returns and start deleting, re-pairing, or factory-resetting gear that might have reappeared if the mesh had been given time. If food safety, heat, water, or access control is involved, waiting is not a plan by itself. For ordinary sensors and lights, though, a slow rejoin window is part of the prediction model.

What a UPS is actually good for

Backup power is still useful. It is just useful for specific links in the chain. Put the right hub, router, modem, ONT, or controller on battery and you may preserve local automations, logging, alerts, or remote access for as long as the rest of the path also survives. Put only the hub on battery while the router dies, and a cloud-heavy system may still lose practical control. Put the router on battery while the ISP path is out, and local Wi-Fi may remain while the internet does not.

Runtime sizing, UPS versus power station tradeoffs, and load math are separate decisions. If the question is how long a router, hub, or modem can realistically stay up, use the UPS or power station guide. If the question is what devices remain useful during an outage, compare the survival tiers in smart home devices during a power outage and smart home devices and power outages. If the goal is automation after failover or battery events, that belongs in power outage smart home automation and power outage alerts and backup.

The one mistake to avoid is buying battery capacity as if it changes firmware behavior. A UPS does not tell a plug to restore previous state. It does not make a Tuya device choose value 2 instead of value 1. It does not make a cloud routine local. It only keeps selected equipment powered long enough for whatever architecture you already have to keep operating.

Thread and Matter may improve the shape of the problem, but specs are not recovery proof

Battery-backed network infrastructure is starting to show up in newer smart home hardware. The UniFi SuperLink Gateway, for example, has been reported with an 11.8Wh battery, about 2.2 hours of backup, LTE failover, and a built-in Thread Border Router. [6] That is an interesting architectural direction: keep the border router and network path alive, and some Thread/Matter recovery problems may be less dramatic.

It should still be labeled correctly. Those figures are manufacturer-spec information reported by a third-party smart home news site, not proof that a real home with mixed devices, weak mesh links, ISP failure, and drained batteries will recover cleanly. The same prediction standard applies: identify the controller, identify the network path, identify the protocol recovery behavior, and identify the device’s own power-on state.

Label the setup before judging the battery

A smart home outage plan is much easier to trust when every important part has a recovery label. The hub is internally backed, UPS-backed, or unbacked. The control path is local-capable, cloud-dependent, or mixed. The protocol is expected to recover immediately, slowly, or only after manual attention. Each powered device restores ON, OFF, previous, or configurable.

Buy backup power when it keeps the right controller, router, modem, or gateway alive for the outcome you need. Do not expect it to rewrite a plug’s firmware default, preserve a cloud path that has disappeared, or accelerate every sleepy mesh device. The useful question is not whether the house has a battery. It is which part of the recovery chain the battery actually protects.

References

1. U.S. electricity customers averaged 11 hours of power interruptions in 2024 — EIA Today in Energy
2. What Happens To Your Smart Devices During A Power Outage — EVVR
3. FAQ: How Outlets/SmartPlugs Behave After A Power Outage: Brand Differences — SmartThings Community
4. Power on behavior 0 1 2 what do these do? — Home Assistant Community
5. Various smart plugs power state after power failure — Hubitat Community
6. UniFi gets its own Thread Border Router — matter-smarthome.de