How to audit which smart devices still phone Home
Learn how to audit your smart home devices for hidden cloud dependencies and shift to local control with Home Assistant.
On this page
Why Auditing for Cloud Dependencies Matters
Every smart device that phones home is a privacy exposure, a potential point of failure, and a dependency on someone else’s servers staying online. Even devices marketed as “local” often keep hidden cloud connections for firmware updates, voice processing, or remote access. Auditing isn’t just about privacy — it’s about resilience. When your internet goes down or a company shuts down its servers, locally controlled devices keep working. Accept up front that eliminating every cloud dependency may cost you some conveniences (like cloud voice assistants), but for a truly autonomous smart home the trade-off is usually worth it.
Tools and Methods to Detect Phoning Home
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
tcpdumpfor 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 / api.push.apple.com, 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.
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. Once you know which gadgets are chatty, how to stop your smart home from phoning home covers blocking or replacing them.
Common Culprits and Alternatives
Voice assistants are the most obvious offenders. Devices like the Amazon Echo and Google Nest speakers send audio to the cloud for processing. 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).
Security cameras often phone home for AI features and storage. Look for cameras that record to local storage and process detection on-device. 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 wired PoE cameras, 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 wired PoE camera. Either way, pairing local-storage cameras with an NVR or Frigate keeps footage and detection off the cloud entirely.
Thermostats are a mixed bag — many require cloud access for their full app experience. The most reliable local path is a thermostat that integrates directly with Home Assistant over Z-Wave, Zigbee, or Matter, so the schedule and automations run on your hardware rather than the vendor’s. As always, verify by cutting internet and confirming basic control still works.
Building a Truly Local-First Smart Home
Prioritize devices that expose local control: Zigbee and Z-Wave (via a local coordinator), Matter over Thread or your LAN, or a documented local API/MQTT. A Sonoff Zigbee 3.0 USB Dongle Plus with Home Assistant’s ZHA integration gives you a fully local Zigbee network; for Z-Wave, Home Assistant’s Z-Wave JS handles devices from brands like Zooz and Aeotec locally.
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. And remember that “local” doesn’t automatically mean “private”: some devices talk locally but still send telemetry home. Finally, accept that 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.
Quick verdict
Auditing for cloud dependencies is an ongoing practice, not a one-time chore. Isolate your IoT devices on their own network, watch their DNS and traffic, and use the “pull the internet” test on each one. Start with the most invasive devices — cameras, microphones, voice assistants — and replace cloud-bound hardware with locally controllable alternatives over time. The result is a smart home that’s more private, more resilient, and under your control.