← Writing

Local control vs the cloud, for when the vendor dies

One morning the lights don't respond. Nothing on your side is broken — the switch is on the wall, the bulb is good, the breaker is on, your internet works. What changed is that a company you have never spoken to shut down a server in a building you couldn't name, and the switch on your wall is now a switch that does nothing.

That isn't a thought experiment. In April 2016 Nest gave Revolv owners about a month's notice that their $299 hub — sold with a lifetime subscription — would stop working on May 15. In April 2022 Insteon switched its cloud off with no warning at all, and houses full of Insteon switches stopped responding. In May 2020 Wink gave about a week's notice that hubs people already owned would need a monthly fee to keep working. None of those customers did anything wrong.

What you actually bought

A cloud-dependent device is not a product you own. It is a subscription to someone else's business continuing to exist, priced at zero for now. It ends three ways: the company folds or gets acquired and the servers go dark; the free tier becomes a paid tier; or the feature you bought it for disappears in a firmware update you didn't ask for and can't decline. None of that requires bad intent — a cloud service costs money every month to run for a device that was sold once, years ago, and eventually somebody follows the economics.

"Works locally" is a specific claim

Local control means the decision and the action both happen inside your building. The sensor tells the hub a door opened, the hub decides to turn on a light, the hub tells the switch. No packet leaves the property. Remote access — checking on the house from a hotel — is a separate feature, and it's fine for that to need the internet. The question is whether the automation needs it.

By that definition a lot of what gets sold as a smart home isn't. If a motion sensor's report travels to a vendor's cloud, gets evaluated against a rule stored in your account there, and comes back as a command, your hallway light depends on a round trip through three networks and one company's uptime to do what a hardware occupancy sensor did in 1995.

The protocols that pass cleanly tend to be the ones that were never IP to begin with. Z-Wave and Zigbee devices talk to a radio in your hub and have no route to the internet even if they wanted one. Wired PoE cameras speaking RTSP or ONVIF to a recorder in your utility closet are the same. Wi-Fi is the mixed bag: a few expose a real local API, most treat the cloud as the only way in.

The test

Unplug the WAN — not the router, the cable between the router and the modem, so the internal network keeps running and only the internet is gone. Then walk the house.

  • Do the switches still switch, and the dimmers dim?
  • Do schedules still fire on time?
  • Does the thermostat hold its program?
  • Does motion still trigger the lights it triggered before?
  • Is the camera still recording to the box on your property?

Anything that fails that walk is a thing you are renting.

Here's the part the reviews skip

Passing the unplug test once does not mean passing it for good. You have to test again after a reboot.

A great many devices execute locally but establish remotely. They hold the schedule they already have in memory, so pulling the WAN looks encouraging. Then the power blinks, or a firmware update restarts them, and on the way back up they need the vendor to re-authenticate a token or re-download a configuration. Now the storm that took out your internet has taken the house with it, at precisely the moment you wanted the lights and the heat to behave.

So the honest test has two steps: pull the WAN, then power-cycle the device and the hub with the WAN still unplugged. What comes back is local. What sits there blinking a status LED is not. Ten minutes, and it beats any review.

What to do

  1. Decide the floor — what must work with the internet down. Usually lights, locks, heat, water shutoff, recording. Convenience can be cloudy. Safety can't.
  2. Buy the floor in local protocols: Z-Wave, Zigbee, or wired. The optional extras can be Wi-Fi.
  3. Run the two-step test before the return window closes, not after. For proof rather than an impression, block the device outbound at the firewall for a day and note what breaks.
  4. Put the decision-making on a hub in the building, so the rules survive the vendor that sold you the parts.
  5. Assume every cloud you depend on gets switched off eventually, and ask what goes with it.

Built that way, a vendor going under is an inconvenience: you lose an app and replace a device when you feel like it. Built the other way, it's an electrician's visit and a house full of hardware that no longer does the one thing you bought it for.

I rate every device I spec on a single question — does it still work when the vendor doesn't. That's the whole basis of the build.


Need this kind of thinking applied to your own setup? Get in touch →