A smart plug that stops responding after a cloud shutdown still contains a working relay, a working radio, and a working power supply. Nothing inside the enclosure failed. The failure is a request that no longer gets an answer — and that distinction changes how you diagnose the device, how you price it, and what you should buy next.
This is not a hypothetical pattern. Belkin announced that cloud services and app support for selected Wemo products would end, after which affected devices could no longer be controlled through the Wemo app, Alexa, or Google Home (Smarter Home Gadgets). Google ended support for the entire Nest Secure alarm system in 2024, hubs, sensors, and key fobs together (Smarter Home Gadgets). Revolv, a hub acquired by Google’s Nest in 2014, was shut down in 2016, bricking every hub sold, including units purchased with an explicit lifetime subscription promise (TechNygrow). Iris by Lowe’s shut down its service in 2019, leaving customers with hardware that no longer functioned as a connected system (TechNygrow). Wink Labs switched from free service to a $4.99 monthly subscription in 2020 rather than closing entirely (Okoniq).
The pattern is structural, not accidental. Running cloud infrastructure has an ongoing cost that does not stop after the initial device sale, and smart home hardware margins are often thin. When a company is acquired, pivots strategy, or cannot sustain the infrastructure cost against a shrinking customer base, shutting down the cloud service is the fastest way to stop the bleeding. Device owners generally have no contractual recourse beyond whatever warranty terms applied to the original hardware purchase — which rarely covers this scenario.
The failure is in the request path, not the components
When a cloud-dependent device stops working, the physical hardware is entirely undamaged. The device sends a request to the manufacturer’s remote server and expects a real answer. When the server goes offline, those requests time out with no response, so the specific features that depended on that round trip stop working, while any genuinely local features continue functioning normally (KnowThisWell).
A concrete example: a cloud-dependent smart plug’s scheduling feature can stop after a shutdown because each scheduled check-in times out, while the manual on/off button continues to function because it involves no server request (KnowThisWell). A smart thermostat whose core temperature logic runs on the device can keep heating and cooling after a shutdown while losing remote access and voice control, which depended on the now-offline server (KnowThisWell).
This is why the teardown framing matters. If you open the enclosure expecting to find a failed component, you will not find one. The relay still clicks. The radio still transmits. The power stage still delivers. The device is not broken; it is waiting for an answer that will never come.
Walk the chain a button press travels
Every smart home command travels a chain: button or app, local network, internet link, vendor cloud, back to the device. The question that determines survival is where that chain stops.
Zigbee, Z-Wave, Thread, and Matter devices survive a vendor exit because a third-party hub can adopt them. Wi-Fi devices that require a vendor account do not (Smarter Home Gadgets). Zigbee and Z-Wave devices paired to an open, self-hosted coordinator continue working even if the device manufacturer disappears entirely, because the coordinator talks directly to the device over the local mesh rather than routing through the manufacturer’s servers (TechNygrow).
Matter devices use local control by default. When you pair a Matter device to a controller, communication happens over the local network via Thread or Wi-Fi, and the cloud is not required for routine operation (Smart Home Mend). Part of the motivation behind the Matter standard was explicitly to reduce the cloud-shutdown problem by defining a common local-control layer that is not tied to any single manufacturer’s cloud infrastructure (TechNygrow).
But Matter is not a guarantee. The sources state the opposite limitation: Matter guarantees the control protocol, not the vendor’s commitment. A Matter device commissioned into a local controller keeps its basic functions after a vendor exit, but Matter-over-Wi-Fi devices that still rely on a vendor cloud for firmware and notifications lose those parts.
Not all Zigbee devices work with any Zigbee hub. Some manufacturers use proprietary Zigbee profiles that only work with their own hubs (Smart Home Mend). Check the device’s certification and community documentation before assuming compatibility.
Three observable states after a shutdown announcement
When a shutdown is announced, the outcome is not binary. The sources describe three states.
Total loss of control. The device gives you little or no usable control, often because app sign-in, remote access, or automations that route through the vendor’s service stop responding. If every command routes through the company’s servers, the device becomes a brick when those servers go dark (Smart Home Mend).
Practical uselessness. The hardware may still switch locally in some scenarios, but cloud-dependent features vanish — no remote control, no seamless device management, and often no voice-assistant routines that depend on the vendor’s account layer. The device works, but not in the way you bought it to work.
Limited fallback. Some affected Wemo devices may keep working with Apple HomeKit after the shutdown if they were already added to the Apple Home app before the cutoff, because HomeKit control can continue locally through Apple’s home hub architecture without relying on the Wemo app for everyday on/off and status (TechYorker). The limitation is strict: it only applies to existing HomeKit users with pairings that happened before the end-of-support changes. If you reset the device after the cutoff, re-pairing could be impossible or at least uncertain.
Even when the app dies and voice assistants stop responding, local automations on a hub may keep running because the hub executes those rules on your network without needing the internet (Smart Home Mend). You just cannot change them from your phone anymore.
The pre-purchase test that requires no teardown
Pull the WAN cable and press the button. That is the whole buying test. If the device does not work with the internet unplugged, the vendor owns the device more than you do.
Pair it with the account test. A mandatory cloud account at commissioning means the setup path itself will break when the servers go (Smarter Home Gadgets). If you cannot complete setup without signing into the manufacturer’s service, you cannot re-provision the device after a factory reset once that service is gone.
For devices you already own, run a diagnostic: unplug your internet router but keep your Wi-Fi network up. Try to control the device using its app, a physical switch, or a hub. If the app fails but the physical switch works, the device is partially local. If nothing works, the device is cloud-dependent (Smart Home Mend). This test is imperfect — some devices cache credentials and may work briefly offline — but it gives you a rough idea.
A more precise check: look at the device’s pairing method. If it pairs directly to your Wi-Fi network and requires the manufacturer’s app for setup, it is almost certainly cloud-dependent. If it pairs to a hub via Zigbee, Z-Wave, or Thread, it has local control potential.
Rescue options, ranked by effort
A device announced for shutdown is not always lost. In rough order of effort:
Check for a local mode you never enabled. Several brands ship a LAN control toggle buried in developer settings, off by default. Shelly, Tasmota-based devices, and many cameras have one.
Adopt it with a generic hub. Zigbee and Z-Wave devices can be factory reset and joined to any coordinator. You lose the vendor app and keep the hardware. This is not always possible — some devices use proprietary Zigbee profiles — but it is worth trying.
Reflash the firmware. ESP-based Wi-Fi plugs and bulbs often take Tasmota or ESPHome. This voids the warranty and is the most durable outcome available. The catch: not all devices are flashable, and newer chips have locked down the flashing process. Check the device’s chipset and search for community documentation before buying if this is your plan.
Use RTSP directly for cameras. Many cameras stream RTSP on the LAN regardless of cloud state. Point a local recorder at it and the cloud subscription becomes irrelevant.
Accept the loss and harvest the parts. A bricked cloud plug is still a relay, an enclosure, and a socket.
What local-first costs you
The local-first argument is often made as if there were no trade-off. There is.
Remote access becomes your problem: a VPN or a reverse proxy you maintain, rather than a vendor tunnel that just works. You own the backups. A hub with your entire automation state on an SD card is a single point of failure until you back it up. Setup takes longer. Commissioning to a generic hub is measured in minutes rather than the thirty seconds a vendor app takes. Some features genuinely need the cloud, mainly AI processing that a local box cannot run. Face recognition on a $40 camera is cloud work.
For some users the trade is clearly worth it, because the failure mode changes shape. A local setup breaks when you break it, and it breaks in a way you can fix. A cloud setup breaks on a date chosen by someone else.
Price a cloud-only device as a subscription
If a device requires the manufacturer’s cloud for every command, you are not buying hardware. You are buying a hardware lease with an unspecified end date.
Price it accordingly. A hypothetical example: a $40 cloud-only camera assumed to last five years is $8 per year of hardware. That may be perfectly reasonable if you decide it consciously. The number is illustrative, not measured. The point is that the purchase price is not the cost of ownership; the cost of ownership is the purchase price divided by the number of years the manufacturer chooses to keep the servers running.
For a device that uses Zigbee, Z-Wave, Thread, or Matter, the hardware is yours. The manufacturer’s business decisions do not determine whether the relay clicks. That is a different asset class, and it should be priced differently.
What to check before buying
Search the model name with the words “local API” and check whether it appears in third-party integration lists. If a community has already reverse-engineered local control, the device has a future beyond its vendor.
Check whether the device supports Matter, Zigbee, or Z-Wave. These protocols are more likely to have local control options. Avoid devices that require the manufacturer’s app for setup and have no documented local API.
Read the privacy policy and terms of service. If the company can change the terms unilaterally, assume they will.
For devices you already own, download all settings and configuration files while you still can. Some apps let you export device lists and automations. Check if the device has a local API that the community has reverse-engineered. Some devices that appear cloud-dependent actually have hidden local endpoints.
Frequently asked questions
Can I use my smart devices if the company’s app is removed from the app store?
Yes, if the devices use local protocols and you have a local hub. The app is just a remote control — the actual logic runs on the hub. If your devices are cloud-dependent, the app removal effectively kills them because there is no other way to control them.
Will my devices work if I just do not update the app?
Possibly, but only until the company’s servers go down. If the cloud dependency is built into the device’s firmware, avoiding app updates does not help. The device still phones home to servers that will eventually stop responding.
Do all Zigbee devices work with any Zigbee hub?
No. Some manufacturers use proprietary Zigbee profiles that only work with their own hubs. Check the device’s certification and community documentation before assuming compatibility. Standard Zigbee devices generally work with generic coordinators, but this is not guaranteed.
Is Matter actually local?
Yes, Matter uses local communication by default. When you pair a Matter device to a controller, the communication happens over your local network via Thread or Wi-Fi. The cloud is not required for routine operation. However, some features like remote access may still route through the controller’s cloud. And Matter guarantees the control protocol, not the vendor’s commitment. A Matter device commissioned into a local controller keeps its basic functions after a vendor exit, but Matter-over-Wi-Fi devices that still rely on a vendor cloud for firmware and notifications lose those parts.
Should I avoid cloud devices completely?
Not necessarily, but price them as a subscription. A cloud-only camera at $40 with a five-year life is $8 a year of hardware, which can be perfectly reasonable if you decide that consciously. The problem is not cloud dependency itself; the problem is buying a cloud-dependent device at a price that assumes it will work indefinitely.
How can I tell before buying?
Search the model name with the words “local API” and check whether it appears in third-party integration lists. If a community has already reverse-engineered local control, the device has a future beyond its vendor. Also check whether the device requires a mandatory cloud account at commissioning. If it does, the setup path itself will break when the servers go.
The conditional verdict
If you are a renter with a handful of smart plugs and a camera, and you replace them every few years anyway, cloud dependency may be a reasonable trade. The hardware is cheap, the setup is fast, and the failure mode — a device that stops responding on a date chosen by someone else — is annoying but not catastrophic. Price it as a subscription and move on.
If you are a homeowner with hardwired smart switches, a hub that controls your lighting, or any device that controls something safety-related — a lock, a smoke detector, a water leak sensor — the transport is the deciding factor. Buy Zigbee, Z-Wave, Thread, or Matter. Buy a hub you self-host. Test every device with the WAN cable pulled before you commit to it. The extra setup time is measured in minutes; the cost of replacing a hardwired switch after a cloud shutdown is measured in hours and dollars.
The hardware in a post-shutdown device is not dead. It is waiting for an answer that will never come. The only way to avoid that outcome is to buy devices that do not need to ask the question.