智能插座離線仍可運作，重設後還能重新設定嗎？

On 31 January 2026, Belkin ended cloud services and app support for selected Wemo products. The Wemo app and affected cloud-dependent integrations with Alexa and Google Assistant stopped working. Its support notice distinguishes between devices: compatible products already configured with Apple HomeKit could continue locally, while Belkin lists Thread-based Wemo products as unaffected by the cloud shutdown. For affected devices, new setup or reconfiguration through the Wemo app or HomeKit is no longer available. The exact model and its setup history matter.

The unsettling part comes later. A switch that still works through an existing HomeKit setup may have no supported route back after a factory reset. That follows from Belkin’s published setup restrictions; it is not a test I’ve run on Wemo hardware. The risk is losing the ability to recover a working device, not necessarily losing every function on the day the cloud shuts down.

Belkin also says affected Wemo owners whose products are still under warranty on or after the cutoff may be eligible for a refund, with proof of purchase required. Claims can be submitted through Belkin’s refund form. That is worth checking before treating a device as e-waste; it is not a blanket buyback promise.

“Use local control” is sensible advice. It is also an incomplete answer.

Take tuya-local, the Home Assistant integration. Its maintainers are unusually plain about the trade-off: sending commands over your LAN does not stop the device itself from reporting status to Tuya’s cloud. They also document reports of some devices becoming unresponsive after an extended period without their vendor’s servers. That is not a verdict on every Tuya product. It is a reason to test the model and firmware you actually own.

The same README warns that many devices permit only one local connection at a time. If a second integration or a phone app is already connected, a failed command does not, by itself, demonstrate cloud dependence; first rule out competing local clients. It also reports that rapid successive commands can make some devices briefly disconnect or reboot; record command spacing before attributing a failed test to the cloud.

Here is a test worth designing, not casually trying on the switch that runs your heating. Start with a spare plug powering an ordinary lamp. Keep the LAN running while blocking its route to the internet. Does it still obey local commands? Does it come back after a normal power cycle? What happens during a longer outage? Record the model, firmware and the method of network isolation. The tuya-local maintainer notes reports that some devices behave differently when DNS is blocked as well as other connections. A five-minute success is not evidence of indefinite operation.

An internet outage is not a failure of the home network. A Wi-Fi plug may still need its access point; controlling Zigbee devices through Home Assistant uses a coordinator, while reaching Thread devices from the home IP network uses a border router. A report should name which local components stayed online. Passing the ‘WAN blocked’ scenario does not establish what happens when the router or hub fails.

A separate question is what the device sends out when internet access is available. A successful LAN command says nothing about outbound telemetry. A future check could use router or firewall logs to record observed external connections and the observation window. ‘No traffic observed during this test’ is not the same as ‘this device never sends data’.

Factory reset belongs in a separate, potentially irreversible recovery test. Only consider it for a spare device after confirming a viable way to set it up again. tuya-local says each pairing changes the local key. The integration can retrieve credentials with cloud assistance or accept an already obtained key manually; a text field cannot produce a new key without the vendor. An offline switch can still be one you cannot recover offline.

I’d record each result on its own line: local commands, cold start, sustained offline use, recovery after reset. If a stage has not been tested, write not tested instead of giving it a green “local” badge. And keep synthetic-device results separate from physical-device results. Before sharing a test report, redact local_key values, access tokens, device IDs, home-network IP addresses and timestamps that reveal household routines. tuya-local uses the local key to connect to a device; publish placeholders or synthetic examples, not live credentials.

A synthetic plug might survive a simulated three-day outage. That tells us the test harness followed the scenario; it certifies nothing about the plug in anyone’s kitchen. Reports must name what was actually exercised.

What leaves the house

My interest in this goes beyond keeping a light switch alive. A front-door lock event, movement in the hall, a heating schedule: over time, those records can reveal when people leave, return and sleep. Now imagine asking a future home assistant why the hall light came on at 2 a.m. I’d want it to inspect the relevant events, with permission. I wouldn’t want that one question to justify keeping a permanent diary of everybody’s movements.

I’m not claiming every device collects these events or uploads them to a manufacturer. Some people will choose cloud services and find them worthwhile. Fine. I want that to remain a choice they understand and can reverse, without losing the basic use of a device they’ve bought. Cloud services can be useful. Being compelled to send a private household log just to keep the lights working is a different bargain.

There is a familiar reply to privacy concerns: “I’ve got nothing to hide.” Neither have I, in the dramatic sense. That doesn’t mean a company needs a timestamped account of my household’s movements. The question isn’t whether my routine is scandalous. It’s who gets to keep a copy.

My home. My devices. My data. By “my data” I mean meaningful control over personal information, not a claim that every legal system treats every sensor reading as property.

The campaign Stop Killing Games has pushed a related question about games that can become unplayable when publishers turn off servers. The European citizens’ initiative Stop Destroying Videogames received a Commission response on 16 June 2026. The Commission said it could not, at that stage, propose a legal duty to keep games playable after commercial supply ends. It pointed to existing EU consumer protections and proposed talks on an industry end-of-life code. No new general obligation followed from that response. Appliances have a different legal context, but the uncomfortable question travels well: what can you still use after the seller walks away?

For a home device, the answer can involve more than entertainment. It can involve heat, doors and the routines people rely on.

There are ways back — for some devices

Open firmware already gives owners options. Tasmota and ESPHome support compatible hardware and make local operation possible in configurations that would otherwise be less open. Developers can contribute to those projects, extend support, or write new firmware where the hardware and licensing permit. The point is not flashing firmware for the thrill of it. The point is making unnecessary outbound telemetry optional, or removing it entirely when that is safe and feasible.

None of that is a universal rescue kit. Bootloaders can be locked; firmware can be signed; a chipset may have no workable support. A successful flash does not establish electrical or physical safety. I would not want a casual experiment with a door lock or a heater to be sold as liberation.

And even a house full of locally controlled devices isn’t quite the destination I have in mind.

That is the sort of job I have in mind for Jeeves, a possible local AI butler in NoemaForge’s longer-term plans. Ask why the hall light came on; Jeeves could inspect only the events residents have authorised, identify the rule that fired, and suggest a change. Residents would decide whether to apply the change, which events to retain and when to delete them — without turning family life into round-the-clock surveillance. This is a design intention, not a feature running in people’s homes.

Crucially, a wall switch must work when the model is unavailable. So must a safety interlock. A language model should never be the only route between a human hand and a relay.

NoemaForge is an open-source project for local AI orchestration. Its SmartHome Local Control work is currently at the policy-and-contract stage: shadow / offline_contract. There is no hardware-ready universal controller. We’re not replacing Home Assistant, and we cannot promise to bring cloud-only hardware back to life. I hope safe, device-specific rescue paths will become possible in some cases; that is an ambition, not a tested capability.

There’s useful work to do before buying hardware. One candidate contribution: specify a synthetic plug that obeys LAN commands until a factory reset, then cannot obtain a new local key. What should a test report say — FAIL for recovery, UNKNOWN for physical compatibility, and why? If you maintain Home Assistant integrations, write firmware, or work with Python and MQTT tests, challenge that scenario in the repository. A concrete counterexample would help more than another reassuring dashboard.

A house that cannot recover a window sensor without its vendor’s login service is a shaky foundation for any clever butler.

────────

Explore NoemaForge or contribute to the project:

https://github.com/Sinev-Maksim/NoemaForge