What works when the
internet—or hub—goes down?
A wireless smart home does not have one “offline” state. Losing the cloud, the local network, a Matter controller, a Thread border router or a Zigbee coordinator removes a different layer of the system.
No internet should mean fewer conveniences, not no control.
If the router, radios and local controllers remain powered, Matter and Zigbee can both operate without an internet connection. Physical controls and locally processed automations are the most likely functions to survive.
A failed hub is more consequential. It may remove the controller, automation engine, remote gateway, Zigbee coordinator and Thread border router at once. The result depends on which of those roles the product was performing—and whether another device can perform them.
Internet, network and hub outages
affect different functions.
The internet is down
Your broadband connection has failed, but the Wi-Fi router and local network are still running. Matter devices can continue communicating locally, and Zigbee never needed the internet for its radio mesh. Local switches, apps and automations can keep working if the platform actually executes them inside the home.
What disappears first is anything that must leave the house: remote app control, cloud-based voice recognition, web-service integrations, firmware downloads and notifications delivered through a vendor service. A product carrying a Matter logo can still use the manufacturer’s cloud for optional features, so “Matter” does not make every feature local.
The local network is down
A failed Wi-Fi router or access point is a different event. Matter-over-Wi-Fi devices lose their network path, phones may no longer reach controllers, and Thread border routers may be cut off from controllers on Ethernet or Wi-Fi. The broadband service can be perfectly healthy while the smart home is locally unreachable.
Zigbee’s radio network is independent of Wi-Fi, so its mesh can remain active. App control may still vanish because the Zigbee hub normally connects to the phone and other systems through the LAN.
The hub is down
“Hub” is a product description, not a single protocol role. One box may be a Matter controller, Thread border router, Zigbee coordinator, automation engine and internet gateway. Powering it off can therefore cause several failures at the same time. Before predicting behaviour, list the roles inside it and identify which ones have an alternative.
Smart-home functions
by failed component.
These are design-level expectations, not a promise for every brand. Vendor apps and automation engines differ, and a combined hub may occupy more than one row.
| Unavailable layer | Likely to remain | Likely to stop |
|---|---|---|
| Internet connection | Physical controls, the Zigbee mesh, local Matter control and locally executed automations can continue while the LAN stays up. | Remote access, cloud voice, web integrations, cloud automations and off-site notifications. |
| One Matter controller or hub | Another authorised Matter ecosystem may still control reachable devices. Device-level manual controls remain available. | Automations, history and remote access owned only by the failed hub. |
| Only Thread border router | The Thread mesh may remain formed and powered. | Matter controllers on Wi-Fi or Ethernet lose their route to Thread devices until a compatible border router returns. |
| Zigbee coordinator or hub | Some established device-to-device bindings and group commands may continue; routers may keep carrying existing mesh traffic. | App control, hub automations, event history, bridging and usually device commissioning. |
| Wi-Fi router or local network | Zigbee radio traffic and direct bindings can continue independently; physical controls still work. | Matter-over-Wi-Fi access, phone-to-controller paths and network access to the Zigbee hub. |
Matter depends on controllers
and Thread border routers.
Matter does not equal the cloud
Matter is an IP-based application protocol that operates locally over Wi-Fi, Ethernet or Thread. A phone or controller on the functioning home network can issue commands without sending each one through a manufacturer’s server. Remote control still needs an internet-connected controller or another vendor-provided route into the home.
A controller is not a border router
A Matter controller commissions devices and administers their access. A Thread border router joins the low-power Thread network to the home’s Wi-Fi or Ethernet network. An automation engine decides when actions should happen. These are separate functions even when a smart speaker or hub contains all three.
If the only Thread border router fails, Thread devices do not necessarily lose their own mesh, but Matter controllers elsewhere on the LAN lose the route to them. A second compatible border router on the same Thread network removes that physical single point of failure.
Multiple Matter controllers provide a fallback
Matter’s multi-admin capability allows a device to be shared with more than one ecosystem. If one platform’s controller fails, another commissioned platform may still operate the device, provided the local network path it needs is available. This helps resilience, although routines and history stored only in the failed platform do not move automatically to the other one.
Zigbee devices may communicate
when the hub fails.
The radio network is local
Zigbee routers—commonly powered plugs, lamps and dedicated repeaters—relay messages across the mesh. Battery end devices wake briefly to report through a parent. None of that requires an internet connection.
Coordinator failure is not a cloud outage
The coordinator forms the network, and in a typical centralized-security installation the hub also carries trust-centre and management responsibilities. Existing routers may keep forwarding traffic for a time when that device is absent, but the installation loses its main management point. Joining devices, repairing some failures and changing security state generally depend on the coordinator or trust centre returning.
Direct relationships can outlast the hub
A switch bound directly to a lamp or Zigbee group may continue sending commands without asking the hub to interpret every press. A hub-created automation—“when motion is detected after sunset, set three lights to 30%”—normally stops because the automation engine is gone. Direct binding is valuable for essential, simple actions; it is not a backup for every scene.
Bridged devices follow the bridge
When Zigbee products appear in Matter through a bridge, the bridge is the translator between the two systems. If that bridge or hub fails, the Zigbee devices may still exist on their own mesh, but Matter controllers can no longer see or operate them through that path.
Keep lights, locks and shades
controllable locally.
- 01
Keep a physical control for lights, locks, shades, heating and other functions that must remain usable during a network fault.
- 02
Confirm which automations run locally. Test them with the broadband cable disconnected rather than relying on a product-page claim.
- 03
Use direct Zigbee binding for simple critical relationships where the devices and platform support it.
- 04
Avoid making one box the only Matter controller, Thread border router, Zigbee bridge and automation engine for every essential function.
- 05
Place the router, network switch, hubs and border routers on a small UPS so a brief power cut does not masquerade as several network failures.
- 06
Document recovery: replacement hardware, configuration backups, Zigbee network data, Matter setup codes and the location of manual overrides.
Local controls should survive
internet and hub failures.
A well-designed Matter or Zigbee home should keep its ordinary physical controls and core local behaviour when the internet disappears. Cloud voice, remote access and web integrations may stop; the lights should not.
A hub outage reveals architecture. If one enclosure holds every important role, its failure can isolate an otherwise healthy radio network. Separate the roles, add alternate paths where they matter, and test one failed layer at a time. Resilience is not the absence of failure—it is a home that remains understandable and usable while something is unavailable.
This guide describes protocol capabilities and common platform behaviour as verified in September 2026. Exact offline operation depends on the product, controller, firmware, network topology and where each automation is executed. Test the specified installation before treating any function as available during an outage.
- Connectivity Standards Alliance · Matter FAQ ↗
- Connectivity Standards Alliance · Matter on the local network ↗
- Connectivity Standards Alliance · Matter roles explained ↗
- Google Home Developers · Matter local connectivity ↗
- Connectivity Standards Alliance · Zigbee specification ↗
- Connectivity Standards Alliance · Zigbee Direct FAQ ↗
Add local fallback to the
smart-home wiring plan.
See how actuator location, control infrastructure and manual fallback change the cost and behaviour of a smart home.