Smart home in practice · intermediate

How do you run a smart home without the cloud?

Which protocols and integrations keep working without the internet, what breaks when it drops, how to keep voice local, and how to back up a local setup.

Grey couch beside a window in a quiet living room

Photo: Roberto Nickson / Unsplash

After reading this article you will be able to:

  • Identify which devices and integrations keep working when the internet goes down
  • Predict what stops working in an outage and design automations around it
  • Set up local voice control and a backup routine that survives a failed controller
On this page
  1. What makes a device local?
  2. What breaks when the internet goes down?
  3. Can voice control stay local?
  4. How do you protect a local setup?
  5. How do you move an existing home toward local control?
  6. Where to go next

A smart home runs locally when the device, the controller and the automation logic all sit on your own network, so the lights still respond when the internet connection or a vendor’s server is down. That needs three things together: a local controller such as Home Assistant, devices that speak a local protocol (Zigbee, Z-Wave, Thread with Matter, or a documented local API), and integrations that talk to them directly rather than through a cloud account. Missing any one of the three puts the cloud back in the path.

Going fully local is not all-or-nothing. Most homes end up with a local core (lights, sensors, heating, locks) and a few cloud services kept for things that need them, such as remote access or a car integration. The point is to know which is which, so that an outage is an inconvenience rather than a failure. This guide covers how to tell, what breaks, how to keep voice local, and how to protect the controller that now holds everything.

What makes a device local?

The radio is the first clue. Zigbee and Z-Wave devices talk only to a hub or coordinator in the house; they have no internet connection of their own (Zigbee vs Z-Wave compares the two). Matter devices, over Wi-Fi or Thread, are controlled over the local network using IPv6, and the Home Assistant Matter documentation describes the protocol as relying on local IPv6 and mDNS. A device built on ESPHome, or a product with a documented local API such as Shelly relays or the Philips Hue bridge, also works without the internet.

Wi-Fi devices without Matter are where the cloud usually creeps in. Many cheap plugs and bulbs are controlled only through the maker’s app and cloud, and a Home Assistant integration for them may simply call that same cloud. Home Assistant labels every integration with an IoT class: local push and local polling mean direct communication with the device, while cloud push and cloud polling require an active internet connection. The integrations directory lets you filter by local or cloud connection; check it before buying, not after.

What breaks when the internet goes down?

With a local controller and local devices, automations, dashboards on the home network, schedules and sensor history keep working. What stops depends on what you connected:

  • Cloud integrations. Anything with a cloud IoT class goes unavailable: many robot vacuums, cars, some thermostats and Wi-Fi plugs, and weather forecasts.
  • Remote access. The app on a phone outside the house cannot reach the controller, whether you use Home Assistant Cloud or your own VPN, because both need the internet.
  • Commercial voice assistants. Alexa and Google speakers depend on their vendors’ servers. Even with Google’s local fulfillment, the Google Assistant integration documentation notes that devices still use the internet for some tasks.
  • Notifications to a phone away from home, since they have to travel over the internet.
  • Cloud speech and text-to-speech, if your voice pipeline uses them.

Two quieter dependencies are easy to miss. Your router has to stay up, since Matter and Wi-Fi devices need the local network even when the internet is gone; a small UPS on the router, switch and controller covers short power cuts. And automations that trigger on time or sunset depend on the controller’s clock, which is normally synchronized over the internet; if the controller restarts during a long outage, check that its clock is right.

Can voice control stay local?

Yes, with Home Assistant’s own voice pipeline, Assist. The local voice documentation describes two speech-to-text engines. Speech-to-Phrase recognizes a fixed set of home-control commands and responds in under a second on a Home Assistant Green or a Raspberry Pi 4. Whisper transcribes free speech, at the cost of around 8 seconds per command on a Raspberry Pi 4 and under a second on an Intel NUC. Piper speaks the replies, also locally.

For the microphone, the Voice Preview Edition detects its wake word on the device and states that it does not need Home Assistant Cloud. The practical limit is language and phrasing: Speech-to-Phrase covers a subset of Assist’s commands, not free-form requests such as adding items to a shopping list. If you want an assistant that answers anything, that part will be cloud based or will need hardware strong enough to run a local language model.

How do you protect a local setup?

When everything runs on one machine, that machine is a single point of failure, and the backup is your insurance. Home Assistant’s backup system creates automatic backups on a schedule; the recommended preset runs daily and keeps the last three. Backups are encrypted by default, and restoring one requires the encryption key from the emergency kit, so store that key in a password manager or on paper, not only on the controller.

The documentation recommends keeping a copy on another system and ideally one off-site. Network storage is a supported backup location, and Home Assistant Cloud stores the most recent backup, up to 5 GB, if you subscribe. A restore can be started from the onboarding screen of a fresh installation, which makes recovering on new hardware realistic: test it once on a spare machine or a virtual machine before you need it.

Two more habits help. Give the controller and network coordinators fixed IP addresses through DHCP reservations, so integrations do not lose them after a router restart. And keep a note of the Zigbee adapter model and channel: replacing a dead adapter is far easier when your Zigbee stack can restore the network from a coordinator backup, which Zigbee2MQTT currently supports only for Z-Stack and EmberZNet adapters. ZHA vs Zigbee2MQTT covers coordinator choice in more detail.

How do you move an existing home toward local control?

Start with an inventory: list every device, its protocol and the IoT class of its integration. Then work through the cloud-only items in order of how much an outage would hurt. Heating, locks and lights usually come first. Some devices can be moved to a local integration; some can be added through Matter; some Wi-Fi devices can be replaced by Zigbee or Thread equivalents; a few, like a car, will stay in the cloud because the product only offers that.

Finally, test it. Disconnect the router’s internet connection for an evening and note what fails. Each failure is either acceptable, fixable with a local alternative, or a reason to add a fallback, such as a physical switch that works whatever the controller is doing.

Where to go next

Topics: smart home, local control, Home Assistant, Zigbee, Z-Wave, Matter, privacy

Diagram