Cloud control against local control, and what happens the week a service shuts down

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

Written by
Ellen Marsh
Published
Filed under
Tech
Length
775 words, about 3 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

Two smart light switches look the same on the wall and do the same job. One sends every command through a server on the internet. The other executes locally and uses the internet only for remote access and updates.

On an ordinary Tuesday the difference is invisible. On the Tuesday the service goes away, one switch keeps working and the other becomes a wall plate.

What actually happens when you press a button

Two paths, and the product's documentation rarely states which one it uses.

The cloud path: the app sends the command to the manufacturer's server. The server authenticates it and relays it to the device, which is holding an outbound connection open for exactly this purpose. The device acts and reports back.

The local path: the app or hub sends the command directly over the home network to the device. The internet is not involved.

The cloud path is easier to build and easier to support. It works identically whether the phone is in the kitchen or in another state, and the manufacturer can change behavior without touching the device. It also means every press depends on three things being up: your internet, their server, and the authentication service in between.

What survives a shutdown, in tiers

  1. Physical control. A switch that is still a switch, a thermostat with a dial, a lock with a keyed cylinder. Nothing can take this away, and it is the single most valuable feature on the list.
  2. Local automation. Schedules and rules stored on the device or on a hub in the house. These keep running.
  3. Local app control. The app talking to the device over the home network. Works while you are home.
  4. Remote access. Needs a server, or needs you to run your own. First to go.
  5. Cloud services. Stored video, voice assistant integration, notifications, and anything with recognition in the name. Gone entirely.

A device's real resilience is the highest tier it can operate at without the manufacturer.

How to find out which kind you have

One test, and it takes five minutes.

Unplug the internet connection at the router, leaving the home network running. Then try each device from the app, and try any physical control.

  • Everything works: local control, with cloud as a convenience layer. The good outcome.
  • Local commands work, remote does not: normal and expected.
  • Nothing works at all: fully cloud-dependent. The app is a remote control for a server, not for the device.

Do this before buying more of the same brand rather than after. It is also worth running once a year, because a firmware update can change the answer in either direction.

The week a service actually closes

Shutdowns follow a recognizable pattern, and knowing it buys time.

Notice usually arrives by email with a date some months out. Between the announcement and the date, the practical steps are:

  • Export anything stored. Video, history, schedules. This is the only window.
  • Write down what each device does. Automations you built over years live only in an app you are about to lose.
  • Check whether a local mode can be enabled before the servers go. Some devices can be moved to a local hub or an open protocol, and the migration frequently requires the original app to authorize it.
  • Identify what has no path forward and plan the replacement rather than waiting for the day it stops.

The devices that hurt most are the ones wired in place: thermostats, switches, doorbells, and anything on a lock. Replacing those is electrical work, not shopping.

Buying with this in mind

Four features predict survivability, and all four are checkable before purchase.

  1. A physical control that works with no power to the network.
  2. Support for an open or widely implemented protocol rather than only the manufacturer's own.
  3. Local scheduling stored on the device or a local hub.
  4. A published statement about local operation. Manufacturers who build for it say so, because it is a selling point to the people who ask.

None of this argues against cloud features. Remote access is genuinely useful, and so is a notification when a door opens. The argument is about which layer the essential function sits in.

The sensible arrangement

Put the things that matter on local control: heat, locks, garage, lighting on circuits you need. Let the conveniences live in the cloud, and treat them as conveniences.

Arranged that way, a shutdown announcement is an inconvenience with a shopping list attached rather than a week of a house that stops responding. It is also the arrangement that tends to be more reliable day to day, since fewer things sit between a button and a light.


About the writer

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