On May 15, 2016, a few thousand home automation hubs stopped working at the same moment. The hardware was fine. Nothing had broken, nothing had worn out. The servers they depended on had been switched off.
The hubs had cost around $300 each, and had been sold with what the manufacturer described as a lifetime subscription. The company behind them was acquired, and roughly two years later the new owner concluded that the service was no longer worth running. The lifetime in question turned out to be the product’s, not the buyer’s. After public criticism the owners were offered refunds, and a regulator opened and then closed an inquiry into whether ending the service that way had been an unfair practice.
The refunds made it a smaller story than it should have been. Money was never the interesting part. The interesting part is that the owners still had the hubs. Nothing was repossessed. They kept the object and lost the thing the object did.
What was actually taken
Lawyers describe property as a bundle rather than a single thing: the right to possess, to use, to exclude others, to sell or pass on. We say own as if it were one indivisible relation, but it has always been several, and they can come apart.
Cloud-dependent hardware pulls them apart cleanly. You keep possession — the hub is on your shelf. You keep the right to exclude — nobody else may take it. What you lose is use, which was the only strand you actually wanted, and usually transfer along with it, since a bricked device is worth nothing to a buyer.
So the sentence you own it remains technically true while becoming practically empty. This is not a metaphor or a complaint about language. It is a precise description of which rights survive and which do not, and it explains why the refunds felt beside the point. The owners were not compensated for a loss of property. They were compensated for the discovery that their property had been hollow for some time.
It keeps happening
That was not an isolated event, and the decade since has made it clear.
Server shutdowns have gone on to end app control for hubs, robot vacuums, plugs, switches, bulbs, and sensors across a range of product lines. In some cases the manufacturer wound down and the systems people had assembled over years simply stopped responding, with little or no notice. In others the product line survived its own support: the hardware kept working as hardware and stopped working as anything else.
The shape is consistent enough to be predictable. A company is acquired, runs out of money, or decides a product line is no longer worth the hosting bill. The servers go dark. Hardware in tens of thousands of homes becomes decorative. What varies is mainly the notice period, and sometimes there isn’t one.
The point of noticing the pattern is not to assign blame. Each of these decisions was probably defensible from inside the company that made it — a service running at a loss for a shrinking number of users is a real problem, and no one is obliged to run a server forever. The pattern matters because of what it reveals about the arrangement buyers thought they were entering.
The number nobody publishes
The obvious defense is to buy from companies that will still exist in ten years. This is difficult to act on, because almost nobody tells you how long they intend to support what they are selling.
In November 2024, staff at the US Federal Trade Commission surveyed 184 connected products — hearing aids, security cameras, door locks, and similar — looking for a stated software support duration or end date on the manufacturer’s own product pages. They found it missing for 161 of them. Searching more broadly, beyond the product page, staff still could not establish a support period for two-thirds of the devices.
That is the part worth sitting with. This is not a case of information buried in a specification sheet that consumers fail to read. For most of these products the information does not exist in public at all. You cannot compare support commitments across brands, because there is usually nothing to compare.
The tool that becomes an object
There is an old observation about equipment that this situation illustrates almost too neatly.
When a tool is working, you do not perceive it. A hammer in use is not an object of attention; attention is on the nail. The tool withdraws, becomes transparent, and effectively disappears into the task. It surfaces as a thing only at the moment it fails — and then it appears with unusual force, suddenly obtrusive, demanding to be looked at rather than used.
A light switch you have used for two years has withdrawn completely. You do not think about it any more than you think about a doorknob. Then a server is switched off, and the switch reappears — as a small plastic rectangle on a wall, which is what it always was and never seemed to be.
This is why the experience of a bricked device is disproportionate to the function lost. The failure does not only remove a convenience. It converts a part of your home back into an object, and reveals that it had been an endpoint of somebody else’s service the entire time it was pretending to be furniture.
Why a lock needs a server
The mechanism behind this is prosaic.
Much smart home hardware is built as a thin client. The physical device handles very little on its own; it maintains a connection to the manufacturer’s cloud, and the actual logic — schedules, automations, permissions, even the decision to turn on — happens there and returns as an instruction.
There are real reasons for building this way. It makes remote access work without asking anyone to configure a router. It allows updates. It keeps the phone app simple, because the app talks to one predictable service rather than to a hundred devices on a hundred home networks. From the manufacturer’s side it is also cheaper to build and easier to support.
The cost is that the object is less a product you own than an endpoint attached to a service you rent. When the service ends, the endpoint has nothing to talk to. This is the same dependency question that appears in software pricing, and it behaves identically — worth reading alongside Subscription is a design decision.
What actually survives
The devices that keep working after a company disappears are the ones that were never fully dependent.
That property has a name worth learning to look for: local control. A device with local control performs its core function on your own network, without reaching the manufacturer’s servers. The cloud adds remote access and notifications; its absence does not break the basic thing.
A few markers, none requiring technical knowledge:
- Does it work with the internet disconnected? Testable in about thirty seconds, before the return window closes. Turn off the router and see whether the switch still switches. - Does it support an open standard? Matter, Zigbee, Z-Wave, or Thread generally mean a different hub can adopt the device later. A device that speaks only its manufacturer’s protocol has exactly one possible future. - Is there a stated support period? Given the FTC finding, its presence is itself informative — it usually means someone had to think about it and commit. - Would a shutdown be inconvenient or unlivable? A lamp that stops responding is annoying. A lock, a thermostat in a cold climate, or a security camera is a different category of problem.
The last question matters most and is the one people skip. It costs nothing before installation and a great deal afterward.
The uncomfortable trade
None of this resolves into buy local-only devices and be done with it.
Cloud-dependent products are frequently better. They tend to be cheaper, easier to set up, and more capable, because the manufacturer can put the complexity somewhere maintainable. Local-first systems ask more of the owner — more configuration, more decisions, sometimes a hub in a cupboard. A reasonable person can look at that trade and take the convenient option.
The mistake is not choosing convenience. It is choosing it without knowing that you did, then learning the terms years later when a support page quietly changes tense. Depth of dependency is a legitimate decision when it is made deliberately, which is also the argument in The real cost of switching.
Back to the hub
The owners in that first case got their money back, which is more than most people in this position get. What they could not get back was the assumption they had made when they installed it — that something fixed to the wall of their home would keep working because it was theirs.
That assumption stopped being safe a decade ago. The useful response is not suspicion of connected devices but a single question asked before installation rather than after: if this company disappears tomorrow, what in my home stops working?
If the honest answer is nothing important, buy the convenient one. Ownership was never one thing, and it is worth knowing which parts of it you are actually getting.