The Lights Still Work. Or They Don't.

Your internet drops. You walk to the switch, tap the app, and the bulb just sits there: powered, connected to your Wi-Fi, technically alive, and completely useless. Your neighbor has the same brand. Hers still responds. Same outage, same street, different result.

Not luck. Architecture.

Specifically, it's whether a device processes commands locally, on hardware sitting in your home, or whether every tap of your finger has to make a round trip to a server farm before anything happens. Understanding that split is the whole ballgame.

The Round Trip Nobody Tells You About

Here's how most smart devices actually work when everything is fine. You press a button in an app. That command travels over your home Wi-Fi to your router, out through your internet connection, up to a cloud server (often in another state or country), which processes the request and sends an instruction back down to your device. The whole trip takes under a second. It feels instant. You never think about it.

Cut the internet, and that round trip snaps in the middle. The app can still reach your router. Your router can still reach the bulb or thermostat or lock. But the cloud server is unreachable, so the command never gets authorized, never gets processed, never arrives. The device waits for instructions that won't come.

This is cloud-dependent architecture. It's the dominant model because it's cheap for manufacturers: all the computing muscle lives on their servers, and the physical device is just a radio and a relay.

Local processing flips that. The brains live in your home, usually in a hub or controller on your network. You tap a button, the command goes app-to-hub, hub-to-device, entirely within your local network. No internet required. The hub is the server now, and the hub is plugged into your wall.

Which Devices Actually Survive a Dropout

The honest answer: it depends almost entirely on the ecosystem and the specific product, not the category.

Smart speakers are a near-total loss. Without cloud access, an Amazon Echo or Google Nest Audio loses almost everything. Basic routines might fire if pre-scheduled and cached locally, but conversational commands are gone. Voice recognition processing happens in the cloud, full stop.

Smart thermostats split cleanly. A Nest will hold its current schedule and run heating and cooling normally during an outage because the schedule is stored on-device. You lose remote control and any learning features requiring server-side processing. An Ecobee behaves similarly. The physical controls still work. Your home won't freeze.

Smart locks are the category that matters most, and the variance is significant. Many Z-Wave and Zigbee locks controlled through a local hub (a Hubitat hub, say, or a SmartThings hub running local execution) will lock and unlock on schedule and respond to keypads without touching the internet. Locks that rely purely on a cloud API for every command are a liability, and frankly, a security risk you shouldn't accept. You don't want to discover which type you have when you're locked out at midnight.

Smart lighting is where local processing shines most visibly. Philips Hue's bridge processes commands locally; the internet is only needed for remote access when you're away. On a local network with the bridge running, Hue bulbs respond to the app and to automations during an outage. LIFX bulbs, which have no hub and connect directly to Wi-Fi, route commands through the cloud. They go functionally dark when the internet does. That's a real difference, and it should matter when you're choosing.

Hub-based platforms built for local execution, Hubitat being the clearest example, exist specifically to solve this problem. Automations run on hardware in your home. The company's servers going down is irrelevant to your daily routines.

What People Get Wrong (The Part Most Guides Skip)

The common assumption is that "smart home" implies cloud, full stop. People buy devices, everything works fine for months, they build elaborate automations, and then discover during a two-hour outage that their entire setup is inert.

There's an equally wrong assumption in the other direction: that local processing means the device works with no network at all. It usually doesn't. Local processing means your home network is sufficient, not that Wi-Fi itself is optional. If your router crashes (not just your internet connection, the router itself) even local-execution hubs lose contact with devices. Internet outage versus total network failure are two different failure modes. Most local-processing setups survive the first but not the second.

The other thing people miss: Matter, the newer cross-platform smart home standard, has local communication baked in as a core requirement. Devices certified under Matter are supposed to respond to local commands without cloud dependency. Think of it like a building code that finally got written after decades of contractors doing whatever they wanted. The standard is still maturing and real-world behavior varies by implementation, but the direction is clear. Local-first is where the industry is slowly, reluctantly heading.

A Tale of Two Setups

Take two people who both set up smart homes around the same time. Call them Priya and Marcus.

Priya built hers around convenience. Wi-Fi bulbs, a cloud-connected plug, a video doorbell whose processing happens on the manufacturer's servers, a voice assistant as the control point. Setup was fast, the app is polished, and the ecosystem works beautifully when everything is running.

Marcus spent an extra afternoon reading forums. He bought a Hubitat hub, Z-Wave switches (which communicate directly with the hub over a separate radio protocol), and a thermostat with on-device scheduling. His app is less slick. Setup took longer.

During a four-hour internet outage, Priya's lights respond only to physical switches. Her doorbell records nothing. Her voice assistant is a decorative cylinder.

Marcus notices the outage because a web search fails. His lights still switch on schedule. His thermostat runs its program. His Z-Wave locks respond to codes. His home is, functionally, identical to a normal day.

The difference in hardware cost between those two setups was modest. The difference in resilience was total.

Building for the Outage You'll Eventually Have

If you're starting fresh, local-execution hubs with Z-Wave or Zigbee devices are the practical path to resilience. Not flashy. The apps aren't always as polished. But the physics are on your side.

If you're already invested in a cloud-dependent ecosystem, check whether your hub or bridge supports local processing modes. SmartThings has expanded its local execution capabilities significantly, though not all device handlers run locally. Philips Hue's bridge has always been local-first for basic control. The answer is usually buried in support documentation under a heading nobody reads.

So here's the question worth sitting with: if your internet provider's infrastructure went down for six hours tonight, would your home still work, or would you be wandering around manually flipping switches in a house full of expensive hardware that forgot how to be a house?

If your core automations run locally, you're in good shape. If every automation requires cloud access, you've built a smart home that's only smart when someone else's servers cooperate. That's not a smart home. That's a rental.