Will your smart home still work when the internet goes down?

Ask about each function, not the whole house

“Works offline” can be too vague to be helpful. A light switch, a phone app, a remote camera view and a voice command may rely on different parts of the system. Instead, list the actions you need and ask which parts must be available for each one.

There are also different failures to consider. Losing the internet connection is not the same as losing power, losing Wi-Fi or having the automation controller stop. A good design discussion separates those cases so the fallback matches the actual problem.

Check the integration rather than the brand

Home Assistant’s integration directory can be filtered by IoT class, distinguishing local and cloud interaction types. The relevant documentation is a useful starting point for understanding a dependency; the exact equipment and desired features still need checking.

Our approach is to produce a short dependency list for the agreed functions. We record which need the local network, the controller or an outside service, and identify the expected behaviour when one is unavailable. This is more useful than treating local control as a blanket guarantee.

Supporting guidance: Home Assistant integration directory

Keep a practical way to take over

For each important routine, agree a manual alternative. Can someone turn the light on without opening a dashboard? Can they see and use the normal heating controls? Which information would temporarily disappear? The answer should be understandable to the person actually in the house.

An automation should also avoid presenting an old reading as a confident current state. Where information becomes unavailable, the intended interface should make that clear. The design should not encourage a household to rely on a reassuring display that no longer reflects the equipment.

Test the agreed scenarios carefully

An implementation handover should include the failure scenarios agreed in the scope, with a controlled test plan and a way to restore normal operation. Avoid casually switching off shared equipment when other household services depend on it. Explain what is being tested and why.

Record the result in practical terms: which controls continued, which features stopped and what action restored the system. If a dependency cannot be removed, that is not automatically a reason to reject the design. It is a trade-off to understand before committing.

Design for the household you have

Some homes value remote access highly; others mainly want reliable controls while at home. Those priorities influence the architecture. We start with the required experience and then explain the dependencies of the proposed equipment.

A Home Assistant project can include a documented fallback and recovery plan alongside the dashboards and automations. Ask for that scope explicitly. The most reassuring answer is a clear, tested explanation of your installation, rather than a broad promise about a platform.