Same Switch, Different Architecture: What Survives the Week a Service Is Shut Down

Two devices with identical features can behave completely differently on the morning a company stops running its servers, and the difference is structural.

Written by
Ellen Marsh
Published
Filed under
Tech
Length
932 words, about 4 minutes
A smart light switch, a small local hub device, an ethernet cable and a wall plate arranged in a row on a plain neutral surface
A smart light switch, a small local hub device, an ethernet cable and a wall plate arranged in a row on a plain neutral surface

The usual way of thinking about smart home devices is that they differ by features, so two light switches offering the same app, the same schedules and the same voice control are treated as the same purchase at two prices. They are frequently not the same purchase at all. One sends every command through a server on the internet while the other executes locally and uses the internet only for remote access and firmware updates. On an ordinary Tuesday that distinction is completely invisible. On the Tuesday the service is retired, one of them keeps working and the other becomes a wall plate.

What Actually Happens When You Press the Button

There are two paths and the product documentation rarely states which one it uses. On the cloud path the app sends the command to the manufacturer's server, the server authenticates it and relays it down to the device, which has been holding an outbound connection open for exactly that purpose, and the device acts and reports back. On the local path the app or a hub sends the command directly across the home network to the device and the internet plays no part in it whatsoever.

The cloud path is easier to build and far easier to support, which is why so much of the market uses it. It behaves identically whether the phone is in the kitchen or three states away, and the manufacturer can change how a device works without ever touching the device. The cost of all that convenience is that every single press now depends on three separate systems being up at once: your internet connection, their server, and whatever authentication service sits between the two.

What Survives a Shutdown, in Tiers

Physical control is the top tier and the most valuable feature on the list, meaning a switch that is still a switch, a thermostat with a dial, a lock with a keyed cylinder, and nothing any company does can take it away. Below that sits local automation, where schedules and rules stored on the device or on a hub inside the house simply keep running. Below that is local app control, which works while you are home on the same network. Then remote access, which needs somebody's server and is the first thing to go. And at the bottom sit the cloud services proper: stored video, voice assistant integration, notifications and anything with recognition in its name, all of which disappear completely. A device's real resilience is just the highest tier it can operate at with the manufacturer entirely out of the picture.

The Five-Minute Test That Tells You Which You Own

Unplug the internet connection at the router while leaving the home network itself running, then try each device from the app and try any physical control it has. Three outcomes are possible and each one is informative. Everything works, which means local control with cloud as a convenience layer and is the outcome worth paying for. Local commands work while remote does not, which is normal and expected. Or nothing works at all, which means the app has been a remote control for a server rather than for the device sitting in front of you. Run the test before buying more of the same brand rather than afterward, and run it again once a year, because a firmware update can move a product in either direction without anybody announcing it.

The Week a Service Actually Closes

Shutdowns follow a recognizable pattern and knowing the pattern buys real time. Notice usually arrives by email with a date several months out, and the window between the announcement and that date is the only one available. Export anything stored, meaning video, history and schedules, because this is the last chance. Write down what each device actually does, since automations built up over years exist only inside an app that is about to stop working. Check whether a local mode can be enabled before the servers go dark, as some devices can be moved onto a local hub or an open protocol and the migration frequently requires the original app to authorize it. Then identify whatever has no path forward at all and plan those replacements deliberately rather than waiting for the morning they stop.

Buying With This in Mind

Four features predict survivability and every one of them can be checked before a purchase. A physical control that works with no network at all. Support for an open or widely implemented protocol rather than only the manufacturer's own. Local scheduling stored on the device or on a hub in the house. And a published statement about local operation, which manufacturers who have built for it tend to make prominently, because it is a selling point to precisely the people who think to ask. None of that is an argument against cloud features, since remote access is genuinely useful and a notification when a door opens is worth having. The argument is only about which layer the essential function lives in.

The Arrangement That Works

Put the things that genuinely matter on local control: heat, locks, the garage, lighting on circuits somebody needs at two in the morning. Let the conveniences live in the cloud and treat them honestly as conveniences that may end. Arranged that way, a shutdown announcement becomes an inconvenience with a shopping list attached rather than a week of a house that has stopped answering, and the same arrangement tends to be more reliable on ordinary days too, since fewer systems sit between a finger on a button and a light coming on.


About the writer

Ellen MarshEllen writes about the gap between what is advertised and what is delivered.