Aqara can run local smart-home functions without an internet connection. That does not answer every privacy question: a hub’s local control path, an Aqara account, the phone app and optional online services need to be considered separately.
Aqara’s published app policies are dated 20 March 2026. This article compares their local-control wording and explains how to check your own setup. The policies are statements about data handling; the network tests below establish what particular devices and workflows do under the conditions you test.
The short answer
The EU Aqara Home policy says internet access is unnecessary for in-home smart functions and includes the phrase “no personal data is transferred to us” for enabling those functions. It separately describes update/support and remote-control transfers. This is narrower than a promise that every network-connected Aqara product sends no data.
Choose the setup you want to assess: Aqara Home with a bound account, Apple Home/HomeKit, or sensors paired directly to a local Zigbee coordinator. Then test the hub and phone independently. Keeping lights working through an outage is useful evidence of local execution, but does not prove that an online app collects nothing.
The March 2026 policy documents
Both the EU document and non-EU app policy give 20 March 2026 as their update/effective date. The EU version includes an overview of local and remote operation; the non-EU version lacks that equivalent overview. These are the app/product policies, not the separate policy for browsing Aqara’s website.
The date tells us which published text we are reading. It does not establish that a particular clause was newly added that day; that would require comparing an earlier saved version. I would judge the current scope and wording rather than treating the update date itself as evidence of a new technical capability.
Read the policy supplied in your app and the device’s own privacy notice as well. Imported products, selected regions and device-specific services can complicate a simple EU-versus-global label.
What local control means on the network
A motion-to-light routine can stay inside the house: a Zigbee sensor sends to its hub, and a locally stored rule tells the switch to turn on. With a separate Zigbee coordinator and Home Assistant, the equivalent path is sensor → coordinator → local software → actuator. Neither example inherently needs a vendor server to perform that command.
That is different from a phone away from home reaching a cloud service that relays the request. It is also different from the same locally controlled hub making a separate online connection. A local command and an outbound update check can coexist; observing one does not settle whether the other exists.
Do not assume every automation is local because one of them is. A routine involving an online weather service, a third-party cloud device or a phone notification may have a dependency the motion-to-light example lacks. Test schedules, scenes, sensor-triggered rules and app control individually.
“Local mode” is also not one universal switch across every Aqara hub and app version. Aqara HomeKit Mode is a specific configuration: Aqara’s developer documentation describes device control/settings, updates and child additions for Apple Home devices, but excludes Aqara automation and scene settings in that mode. An account-bound Aqara setup with local rules is a different arrangement.
Account, app and online-service data
The EU policy lists account details, handset identifiers/version information, location information, logs and hub/sub-device settings for its described account-linked use. The non-EU policy also lists account, device/network, automation and service data, with device-specific notices. These disclosures identify categories and purposes; they do not prove that every item is uploaded continuously in every mode.
Account binding: An existing cloud account record is separate from today’s sensor traffic. Logging out of an app does not establish that an account has been deleted or that a previously bound hub has stopped all cloud functions. Check binding, sharing, subscriptions and account-management settings separately.
Phone app: The phone has its own network connection. Blocking the hub’s WAN access does not block the app, especially if the phone can use cellular data. Review permissions, optional analytics/marketing settings and any diagnostic uploads. A policy disclosure is not a packet capture of what your installed app did.
Remote access: Aqara account-based remote control uses its online infrastructure. Apple Home remote access and a Home Assistant remote-access service have their own architecture and privacy terms. Removing Aqara from a control path does not remove every other provider from it.
Updates and support: Fetching firmware or sending diagnostics is an online activity. Allow access deliberately when needed, then repeat your local-function tests afterwards. Disabling updates forever has a different maintenance cost from limiting ordinary day-to-day WAN access.
Retention and deletion: Read the relevant retention entries and account/log deletion controls. Deleting a phone app alone is not a request to delete a server-side account. If a specific data category or device notice is unclear, ask Aqara’s privacy contact about that exact use.
The EU and non-EU wording gap
The EU policy limits its stated scope to Aqara Home use in the EU and contains the explicit local-function wording. The non-EU document does not state an equivalent blanket local-function clause. That is a difference in the text, not proof that the hardware behaves differently across regions or that non-EU users have no privacy rights.
Your applicable rights depend on the law and circumstances, rather than just a server-region dropdown. The non-EU document itself also discusses EEA users in its transfer provisions, so its filename is not a complete map of legal coverage. Check the policy presented for your service and device. If you need a definitive answer about an imported product’s data handling or a deletion request, get that answer for the specific account and region.
For a reader in Singapore or elsewhere outside the EU, the practical choice is still clear: select the features you need, limit unnecessary online services and verify local operation. The same testing discipline is useful for an EU reader; stronger wording does not replace checking a misconfigured system.
Checking local operation and outbound traffic
Record the hub model, firmware, app version, binding mode and test time. Separate three questions: does a function need the WAN, does the device attempt outbound traffic, and what data does that traffic contain? Different tests answer different questions.
1. A reversible WAN-block test
- Reserve the hub’s address in DHCP and record your existing firewall settings.
- Confirm the automation works with normal internet access.
- Block that hub’s WAN access at the router, while keeping required LAN access. Cover IPv6 if it is enabled.
- Trigger the routine several times. Check direct control, schedules and a hub restart separately.
- Restore access when the test is complete, or keep the rule if its tradeoffs fit your setup.
A working routine shows that this routine worked without the hub’s WAN connection during the test. A failed routine suggests a dependency or an overbroad firewall rule; it does not by itself show a privacy violation. A full WAN outage can test the wider system, but it affects every household service, so plan it accordingly.
2. Router connection and firewall logs
Filter logs by the hub’s addresses and compare idle periods, routine execution, app use, restarts and deliberate update checks. Record destinations, allowed/blocked connections and timing. A repeated destination may be worth investigating, but neither a domain name nor an encrypted connection tells you the complete payload or purpose.
If your router only sees WAN traffic, it will miss same-LAN exchanges. Use the appropriate interface or a local capture when investigating discovery or direct control. Keep captures private: they can contain device identifiers and other household information.
3. Pi-hole or AdGuard Home
Use per-client logs to see what the hub resolves, and test filtering on a hub-specific group. In Pi-hole, add domains with its wildcard/regex controls; do not enter a shell-style wildcard into a field expecting an exact domain. Examples of regex deny rules are:
(^|\.)aqara\.com$ (^|\.)lumiunited\.com$
These match the named domains and subdomains. They are examples, not a complete vendor endpoint inventory. Use the Pi-hole regex documentation to check syntax. DNS logs do not show cached lookups, direct-IP traffic or connections that bypass that resolver, so a quiet log cannot certify zero outbound traffic. A WAN firewall rule addresses those gaps more directly.
4. Test the phone separately
Put the phone on the same LAN, disable cellular data during the controlled test and check whether the app can operate the devices with WAN access unavailable. Keep the hub’s LAN rules intact. If the app offers a local-control option for that model/version, test it; do not assume an identically named setting exists on every hub.
For stronger evidence about app telemetry, compare phone-originated network connections with and without the app in use. That remains a destination/timing observation unless you can lawfully inspect the relevant payloads. This article does not report a packet capture or measured traffic from your hardware.
Comparing the available setups
| Setup | Local control path | What still needs checking |
|---|---|---|
| Aqara hub with account-bound Aqara Home | Supported hub rules and LAN control may run locally | Account-linked services, app connections, device notices and which rules use cloud features |
| Aqara hub/accessory through Apple Home | HomeKit can control supported accessories locally | Any simultaneous Aqara binding; Apple’s remote access, iCloud and home-hub requirements |
| Home Assistant through a supported HomeKit/Matter bridge | HA communicates with the bridge locally | Bridge feature coverage, setup/update requirements and any separately enabled vendor services |
| Zigbee2MQTT with a local coordinator | Supported Zigbee devices communicate directly with your own Zigbee network | Broker/host security, downloaded updates, HA remote services and notification delivery |
For an Apple Home-only use, the EU policy distinguishes third-party-app control from Aqara Home account-linked use and directs readers to that other provider’s privacy terms. It should not be extended to a dual-bound hub still using Aqara online services. HomeKit Mode can help with device maintenance, but changing the screen you use every day is not the same as removing an existing binding.
There is also no universal “Aqara local API” option for every HA-compatible hub. Use a supported HomeKit or Matter integration where appropriate; unofficial local-API projects have their own device and firmware lists. Our gateway local-API guide explains that separate decision.
Direct Zigbee2MQTT pairing removes the Aqara hub and account from that device-control path. It is useful for compatible sensors and switches, but is not a universal replacement for camera functions, proprietary hub features or every device model. The Zigbee2MQTT setup guide covers that route.
Choosing the arrangement that suits your home
If you want Aqara’s app features, use them with a clear inventory of which services are online. If your priority is local everyday control, supported HomeKit/Matter bridging or direct Zigbee pairing can reduce the account-based control path. Test the feature set before removing a binding you still need.
I would keep a short record of the configuration and repeat the WAN-block checks after significant firmware or integration changes. That provides evidence about your own routines. The policy wording helps identify what Aqara says it does; neither that wording nor a successful light switch test justifies a claim that an entire system has zero telemetry.
FAQ
Does a local automation mean Aqara collects no data?
No. It establishes a local execution path for that automation. Account records, app activity and separately enabled online services need their own assessment.
Can Aqara devices work without internet?
Supported local functions can. Verify the exact hub, integration and routine, including behavior after a restart. Remote access, cloud storage and online update retrieval are different functions.
Is using Apple Home or Home Assistant enough?
It can keep control local, but check the protocol and any remaining vendor account binding. Apple/HA online services may also have their own external dependencies.
Does the EU/non-EU distinction matter?
It matters when reading the stated scope and promises. Use the policy applicable to your service/device; do not infer the hardware’s traffic or all your legal rights from the presence or absence of one clause.
Can a DNS block prove no data leaves the house?
No. It only affects matching DNS queries through that resolver. Check WAN rules, IPv6 and connection logs as well, and state what the test actually observed.