How to stop your smart home from phoning home

Your smart home probably phones home more than you think. Every time you ask Alexa to turn on a light, or your thermostat checks in with the cloud, you’re relying on someone else’s servers. When those servers go down - and they will - your “smart” home becomes very dumb, very fast. Even devices marketed as “local” often keep hidden cloud connections for firmware updates, voice processing, or remote access.

This guide covers how to find those connections, and how to build a local-first system that keeps running when the internet doesn’t. Accept up front that eliminating every cloud dependency may cost you some conveniences (like cloud voice assistants), but for an autonomous smart home the trade-off is usually worth it.

Short version: Put your IoT devices on their own VLAN, watch their DNS with Pi-hole or AdGuard Home, then pull the WAN cable and see what still works. Start with a Home Assistant Green, add a Zigbee coordinator, prefer Zigbee and Z-Wave over Wi-Fi, and replace cloud-dependent devices as they fail or age out. You don’t need to replace everything overnight - just stop adding new cloud dependencies.

Step 1: audit what still phones home

You likely have some devices already. Audit them with these questions:

1. Does it work without internet? Test by disconnecting your router temporarily.
2. Does the app require a cloud account? If yes, expect cloud dependencies.
3. Can you control it via local API? Check whether it exposes HTTP or MQTT endpoints.
4. What’s the data being sent? Use network monitoring tools to see traffic destinations.

For the last question, start with network visibility. Put your IoT devices on a separate VLAN or guest network so you can watch their traffic in isolation, then inspect what they talk to. Useful tools:

• Your router or firewall logs (especially on firmware like OpenWrt, pfSense, or OPNsense) to see outbound connections per device.
• Pi-hole or AdGuard Home as your DNS server, which logs every domain each device looks up - an easy way to spot a “local” gadget quietly resolving a vendor cloud.
• Wireshark or tcpdump for a deeper packet-level look when you want to know exactly where traffic goes.

In the DNS logs, look for queries to cloud providers like amazonaws.com and googleapis.com, Apple’s push service at push.apple.com (devices open their APNs connection to a host like 1-courier.push.apple.com, so that is the pattern you will actually see in DNS logs), and manufacturer-specific domains. Pay special attention to anything with a microphone or camera - those frequently stream audio or video to the cloud for processing even when you think recording is local. And remember that “local” doesn’t automatically mean “private”: some devices talk locally but still send telemetry home.

The simplest test of all: pull the internet and see what still works. Unplug your WAN (or block a device’s internet access at the firewall) and try the core function. If the light still toggles and the sensor still triggers its automation, the device is operating locally. If it goes dark, it was relying on the cloud.

Auditing is an ongoing practice rather than a one-time chore: every new device gets the same DNS watch and the same pull-the-internet test. Once you know which gadgets are chatty, the rest of this guide covers blocking or replacing them.

Step 2: choose your local hub wisely

The foundation of a local smart home is the hub. Cloud-dependent hubs like those from Abode or Ring force everything through their servers. Local options keep traffic on your network.

Home Assistant is the strongest choice here. The Home Assistant Green is the purpose-built option (the Home Assistant Yellow was discontinued in October 2025 but remains fine if you already own one), or you can run Home Assistant on general-purpose hardware like a Beelink EQ14, which replaced the discontinued EQ13, or a used Intel NUC 12 Pro, which is discontinued as well. The big advantage is that Home Assistant runs entirely locally by default. Unless you explicitly enable cloud features, your automations never leave your network.

Hubitat Elevation is another solid option, particularly if you want Z-Wave and Zigbee without relying on a separate computer. Buy the standard C-8 Pro; Hubitat stopped making the plain C-8 in March 2026, and the Thread Special Edition of the Pro swaps the Zigbee radio out for Thread. It runs local rules engine and doesn’t require cloud connectivity for core functionality.

Aqara Hub M3 occupies a middle ground - it supports Matter but also works locally for Aqara devices. However, some cloud features are mandatory for initial setup.

Avoid hubs that require cloud accounts for basic operation. If your automation logic lives on someone else’s servers, you’re one account suspension away from losing your setup.

Step 3: prioritize Zigbee and Z-Wave over WiFi

WiFi devices are convenient but tend to be more cloud-dependent. Zigbee and Z-Wave devices communicate directly with your hub, keeping traffic local.

For Zigbee, you’ll need a coordinator. The Sonoff Zigbee 3.0 USB Dongle Plus is a budget-friendly option, or the ConBee III if you want broader device compatibility. The Tube Zigbee Coordinator is another solid choice. Any of them with Home Assistant’s ZHA integration gives you a fully local Zigbee network.

Z-Wave offers longer range and more reliable mesh networking, though at a higher price point. If you already have Z-Wave devices, stick with a Hubitat Elevation hub - buy the C-8 Pro if you are buying new, since Hubitat discontinued the plain C-8 in March 2026 - or add a Z-Wave stick to Home Assistant, where Z-Wave JS handles devices from brands like Zooz and Aeotec locally.

Practical devices to consider:

• Shelly Plus 1 and Shelly Plus 2PM for relay switches - these work locally without cloud, though both are discontinued now and the Shelly 1 Gen4 and Shelly 2PM Gen4 are what to buy
• Aqara Door Window Sensor P2 for occupancy detection
• Philips Hue Bridge with Philips Hue Lightstrip Plus - Hue bulbs work locally through the bridge
• Lutron Caseta Diva Smart Dimmer for lighting, though it requires a hub that mostly stays local

Avoid WiFi-only smart plugs unless you can flash them with local firmware like ESPHome. Most off-the-shelf WiFi plugs report usage data to cloud services.

Step 4: avoid cloud dependencies where possible

Even devices that claim to work locally often have cloud dependencies. Here’s how to identify and avoid them:

Matter isn’t automatically local. Matter is a communication protocol, not a guarantee of local operation. Many Matter devices still phone home for firmware updates, account linking, or “enhanced features.” Check whether the device requires cloud onboarding.

Smart speakers are cloud-first. Amazon Echo 4th Gen and Google Nest Mini are useful for voice commands, but voice processing happens in the cloud. Use them as triggers only, not as the automation engine. Two caveats if you are buying rather than using what you already own: Google ended production of the Nest Mini in June 2026 and points new buyers at the Google Home Speaker, and it is replacing Google Assistant on its speakers with Gemini for Home, a switch Google’s own support pages describe as irreversible. The local-first alternative is Home Assistant’s Assist voice pipeline; the Home Assistant Voice Preview Edition runs wake-word detection on the device (via the microWakeWord engine) and can do speech-to-text locally - either with the lightweight Speech-to-Phrase for command-style control, or with a local Whisper model for full transcription if you have enough CPU (an Intel N100-class processor or better is recommended for Whisper).

Cameras vary more than any other category. Cloud-first brands like Ring route video through vendor servers, and battery-powered Wi-Fi cameras usually do too. Wired PoE cameras are the exception: the Reolink PoE line exposes RTSP and ONVIF and records to your own NVR with no cloud account. If local storage matters, look at UniFi Protect or a Reolink NVR setup that keeps footage on your network. Some battery cameras do keep storage and detection local: the Reolink Argus 4 Pro, for example, does people/vehicle/animal detection on the camera and records to a microSD card with no subscription required. One caveat specific to battery models: Reolink reserves RTSP and ONVIF for its mains-powered cameras - its PoE line and its wired Wi-Fi models such as the Reolink Video Doorbell WiFi alike - so a battery camera cannot stream straight into Frigate. Reaching it from Home Assistant means adding a Reolink Home Hub or NVR to re-expose it locally. If you want the plain Frigate path with no extra box, buy a mains-powered camera.

Thermostats vary. Ecobee Premium is cloud-based with no official local API (its Home Assistant integration is cloud-polling), and Nest Thermostat also leans heavily on cloud. A Honeywell T6 Pro Z-Wave (or another Z-Wave, Zigbee, or Matter thermostat) works better in local setups, since the schedule and automations run on your hardware rather than the vendor’s. The Mysa Smart Thermostat has no local API, so its own Home Assistant integration relies on Mysa’s servers. Mysa’s Wi-Fi models are HomeKit accessories, though, so pairing one through HomeKit Controller does give local LAN control, and the Matter-certified Mysa Smart Thermostat for Central HVAC skips the workaround entirely by joining Home Assistant over Matter.

When evaluating a purchase, search “[device name] Home Assistant local” before you buy, and check whether the device supports local control without the manufacturer’s cloud. Be skeptical of anything that requires an account and a vendor app just to complete basic setup - that’s usually a sign of cloud dependence. When in doubt, check whether a device works without an internet connection. Unplug your router and test. If it stops working, it’s not local.

Step 5: replace the worst offenders

For devices that fail these tests, consider replacing them with local alternatives. A Shelly smart plug (the Plug US Gen4 in North America, the EU Type-F Plug S in Europe) can replace a cloud smart plug while offering local HTTP control. Eve Energy stores data locally if you avoid Eve’s cloud service. Start with cameras, microphones and voice assistants, and replace the cloud-bound ones over time.

Some cloud devices are acceptable if you’re okay with the tradeoff - security cameras often need cloud for remote access, for instance. Just don’t build critical automations around devices that require connectivity to function. A few conveniences (like one-tap remote firmware updates) may take manual effort in a local-first setup - the payoff is control and reliability that outlive any company’s servers.