Design Intermediate 4 min read Updated 19 October 2026

Designing for Local Control: What Should Still Work When the Internet Fails

A method for deciding which functions must survive a broadband outage, tracing each one through its dependencies, choosing designs that keep working, and proving it with an outage test before handover.

By Abhi Bavishi, Founder, Smartify

Technical review pending

At a glance

You will learn

  • Sort functions into what must work with only local power, with the internet down, or with the internet
  • Trace each function from the action to the load
  • Prove it with an outage test

You need

  • A client conversation about what cannot fail
  • Access to the router and hub for the test

Key takeaway

Write a must-keep-working list, trace every link, replace anything that needs the cloud, then test by pulling the internet, the router and the power.

Short answer: agree what must keep working, trace every dependency from the person’s action to the load, and replace cloud-dependent links where needed. Prove the design by testing internet, router, hub and power failures separately.

Broadband loss and power loss are different events. A function can survive one and fail the other, so “local control” needs a tested definition for this household.

Test three different failuresInternet loss, hub loss and power loss are different tests. Local paths may work without internet; hub-based rules need the hub; power backup must cover the whole path. Manual fallback must be tested on the actual installation, not assumed from a protocol logo.Which dependency is unavailable?Internet downLocal paths may still work.Cloud-dependent actions stop.Hub downHub-based rules stop.Test independent manual controls.Power downOnly backed-up paths can work.Check every link, not just the router.Promise only the functions you have tested.
Test three different failures

Start with the client’s list

TierExample functionsRequired behaviour
Local power onlyWall switches, mechanical lock key, manual geyser/pump switch-offNo hub, network or internet required
Internet downScenes, schedules, sensor lighting, local appLocal controller and network still operate
Internet-dependentVoice assistants, remote access, notifications, cloud integrationsClient accepts the documented dependency

These are example expectations to agree with the client, not promises about every product. Put the agreed list in the quote.

Trace each function’s dependencies

For each first- or second-tier function, write down:

  1. Action and device: what is pressed or triggered, and whether the device accepts local commands.
  2. Radio or wire: Zigbee, Thread, Wi-Fi or wired bus, including power for intermediate equipment.
  3. Controller and logic: which box executes the rule, where it sits and whether a cloud service is involved.
  4. Network and login: the router/access point crossed and how the phone reaches the controller.
  5. Power: mains, UPS or inverter for every link and the required runtime.

Any required cloud link puts that function in the internet-dependent tier. A device with a local radio can still belong to a cloud-dependent automation.

What the sources say about local paths

Home Assistant documents offline operation for its locally connected devices, including Zigbee, Z-Wave, Matter, Thread and ESPHome. Its vendor-cloud-only devices, remote access and voice-assistant integrations need internet. This describes that system, not every commercial hub.

Matter is designed for local core control. Google’s documentation describes commands travelling directly over the home network. However, some vendors require an account before enabling Matter or for additional features. Some Wi-Fi products also offer local control separately from an optional cloud service; that is a product capability, not a guarantee from Wi-Fi itself.

Read the exact device and controller documentation, then test the installation. Neither a protocol logo nor an app screen proves that the full function survives an outage.

Design choices that keep working

  • Keep wall switches that operate with the hub off, or a mechanical fallback beside smart control. Confirm that the family can use it.
  • Run essential automations on the local controller and avoid cloud-to-cloud chains for the first two tiers. Check whether startup or pairing also needs cloud access.
  • Back up the whole path. A UPS on the router does not power an unbacked hub, Thread border router or relay circuit. Record load, runtime and recharge requirements before sizing backup.
  • Decide each load’s restore state: off, on or previous state. Test what actually happens.
  • Check where schedules get their time after an offline reboot. This is practitioner guidance, as is checking that the phone can log in locally without a cloud account.

Safety first

Keep life-safety and equipment-safety functions independent of the smart system. Geyser thermostats, pump protection and smoke alarms must continue to work. Coordinate mains power-cut tests with the qualified electrician; record the affected circuits and agreed restore states.

The outage test

With the client present, record pass or fail for each promised function:

  1. Disconnect broadband while keeping router and hub powered. Test both local tiers and document which internet features stop.
  2. Turn off the router or access point. Identify surviving direct paths and functions that lose the network.
  3. Restart the hub. Record recovery, device rejoining and unexpected load changes.
  4. Have the electrician cut and restore the relevant mains supply. Check backup coverage, load states and network recovery.
  5. Restore power while leaving internet disconnected. Check that the system settles and schedules have correct time.

Use the commissioning and handover checklist for the on-site record. Acceptance should cover the tested failure cases, not just normal online operation.

What to tell the client

Demonstrate the wall switch, key or local app used during failure. List local and internet-dependent functions, tested backup coverage/runtime, and what changes if a vendor withdraws service or an account lapses. Promise the tested list, not “always works”.

Common mistakes

Do not equate an app with local control, back up only the router, omit wall-switch fallback or skip offline tests. Record every internet dependency the client accepts.

Where to go next

Check yourself.

Questions from real jobs. Think first, open the answer, then say how you did. The score is for you and stays on this device.

A UPS keeps the broadband router on during a power cut. Is that enough?

Not by itself. An unbacked hub, border router or light circuit still goes down, so plan backup around the whole path of each function.

A light only works through a vendor's cloud. Which tier is it in?

The internet-dependent tier. If any link in the path is the cloud, that function belongs there.

Sources

← All Design lessons
Chat with us