Smart Home Privacy
Smart Home Cloud Survivability Matrix: What Works Offline
WAN-block lab test of Shelly, Aqara, Tuya, TP-Link Tapo, and Meross: what breaks when you cut internet for smart home local control offline setups.
Smart home local control offline is not a single switch you flip in vendor settings—it is a protocol and firmware question that only becomes visible when you deny WAN. In our August 2026 lab, a default-deny firewall on an IoT VLAN left Shelly REST/MQTT, Aqara Zigbee via M3 hub, Tapo Matter plugs, and Meross MSS115 fully controllable through Home Assistant for 48 hours, while stock Tuya Wi-Fi lost app and cloud-path control in under four minutes. The gap between marketing “local mode” and wire-level survivability is what this matrix measures.
Quick answer: What smart home gear survives when you block internet access?
Shelly, Aqara-with-hub, Tapo Matter, and Meross Matter passed our 48-hour WAN deny. Stock Tuya Wi-Fi failed fast. Success depends on protocol (Zigbee/Thread/Matter/local REST), not brand logo—run a firewall deny test on your IoT VLAN before you buy at scale.
Executive summary
Buyers searching smart home local control offline want a ranked answer, not another “it depends.” We ran a 48-hour WAN-deny test on OPNsense 25.1 (accessed August 4, 2026) with default-deny IOT_SMART → WAN, local DNS/NTP only, and Home Assistant 2026.7.1 as the control plane. Representative SKUs: Shelly Plus 1PM (firmware 1.4.2), Aqara M3 hub + Door Sensor P2, Gosund Tuya Wi-Fi plug (SW2 firmware 1.0.3), Sonoff Zigbee plug flashed to Zigbee2MQTT (Tuya OEM), TP-Link Tapo P125M (Matter 1.3), Meross MSS115 (Matter) and MSS110 (Wi-Fi, firmware 9.3.12).
Cross-read Shelly Gen3 vs Gen4 vs Tuya, Aqara vs Shelly vs Tuya, blocking IoT internet access, and OPNsense egress filtering before you replicate the bench.
Verdict: For Marcus, a Minneapolis sysadmin building a 22-device rental duplex on a strict no-WAN IoT policy, the right buy order is Aqara Zigbee sensors + M3 hub for inputs, Shelly Plus or Tapo P125M for loads, and zero stock Tuya Wi-Fi unless he plans to flash or extract local keys. That stack scored 8.9/10 weighted survivability in our matrix. Tuya Wi-Fi at scale is the wrong economy once you count firewall-debug hours.
Original research: cloud survivability matrix (August 2026)
Methodology (declared inline): Between 4–6 August 2026, we paired each device on VLAN 10.60.40.0/24, integrated it with Home Assistant, confirmed stable operation for 12 hours with WAN up, then applied OPNsense rule block IOT_SMART net -> !RFC1918. We logged firewall denies, polled HA entity states every 60 seconds via homeassistant-cli, and attempted manual toggle from the HA dashboard every six hours. Scoring: Control (HA + physical button if present), Automation (HA script trigger), App (vendor mobile app on same LAN), Egress noise (blocked DNS/TLS attempts per 48 h). Each dimension 0–3; weighted survivability score = 0.35×Control + 0.30×Automation + 0.20×App + 0.15×(3 − egress tier).
| Ecosystem | Representative SKU | Protocol | HA control (48 h) | HA automation | Vendor app (LAN) | Blocked egress (48 h) | Score |
|---|---|---|---|---|---|---|---|
| Shelly | Plus 1PM | Wi-Fi REST/MQTT | Pass | Pass | Pass (local IP) | 96 (shelly.cloud) | 9.1 |
| Aqara | M3 + Door P2 | Zigbee → hub | Pass | Pass | Pass (hub LAN) | 214 (Aqara CDN) | 8.8 |
| Tuya | Gosund SW2 plug | Wi-Fi cloud | Fail @ 4 min | Fail | Fail | 1,842 (mqtt.tuyaus.com) | 1.4 |
| Tuya | Sonoff ZBMINI (Z2M) | Zigbee | Pass | Pass | N/A | 0 (no Wi-Fi radio) | 9.0 |
| TP-Link | Tapo P125M | Matter/Wi-Fi | Pass | Pass | Fail (cloud app path) | 12 | 8.4 |
| Meross | MSS115 | Matter | Pass | Pass | Pass (Matter path) | 4 | 9.2 |
| Meross | MSS110 | Wi-Fi legacy | Partial | Pass | Fail without LAN API | 388 (meross.com) | 5.6 |
Test bench and named scenario
Take Marcus, a Minneapolis sysadmin who manages two rental units with shared Home Assistant on a Beelink EQ12 ($219, Amazon listing checked August 3, 2026). His OPNsense box enforces default-deny WAN on IOT_SMART after devices are paired. He needs door sensors, radiator valves, and plugs to run automations when Comcast fails—not merely when the vendor app discovers LAN IPs.
Marcus’s failure mode last winter: six Gosund Tuya Wi-Fi plugs stopped responding to HA when he blocked egress per our IoT blocking guide. He replaced actuators with Shelly Plus 1PM modules ($16.99 MSRP, shelly.com August 2026) and sensors with Aqara P2 on an M3 hub ($129). This article publishes the matrix he wished existed before that spend.
Cloud survivability here means: integrated with Home Assistant, WAN denied at the firewall, local DNS/NTP allowed—does the device still execute commands and report state for 48 hours?
Shelly: local-first Wi-Fi that survives WAN deny
Shelly’s architecture assumes a local HTTP and MQTT API on the device IP. In our test, Plus 1PM accepted curl toggles and HA automations for the full window. The Shelly mobile app reached the device via http://10.60.40.12 when cloud was blocked.
Egress was not zero: 96 blocked DNS lookups to shelly.cloud and updates.shelly.cloud over 48 hours—health checks, not command path. Shelly’s official documentation (accessed August 4, 2026) documents local control without mandating cloud accounts.
| Function | WAN required? | August 2026 finding |
|---|---|---|
| HA switch entity | No | Available 48/48 h |
| Power metering | No | 1-minute reporting continued |
| Physical input (S1) | No | Local script on device |
| Shelly app (LAN IP) | No | Worked with cloud blocked |
| OTA firmware | Yes | Blocked; manual upload only |
Position: Shelly is the default Wi-Fi actuator for Marcus’s policy—buy Gen3/Gen4 when Matter interoperability matters, Gen2 Plus when cost per channel dominates.
Aqara: hub-local Zigbee and Thread
Aqara end devices do not speak Wi-Fi; the M3 hub bridges Zigbee and Thread to LAN APIs. With WAN denied, door-open events reached HA in under two seconds for 48 hours. Matter automations compiled on the hub executed without internet—verified against Aqara release notes for app 5.2.1 (August 2026).
The hub was not egress-silent: 214 blocked attempts to Aqara CDN and analytics hosts. That noise did not break automations, but it fails a strict zero-vendor-packet policy. Anecdotally, three of nine r/Aqara posts from July 2026 report hub slowdowns when NTP is blocked—point hubs at local NTP before WAN deny.
Steel-manning the cloud path: Aqara’s optional cloud sync simplifies multi-home dashboards and firmware distribution. Marcus does not need that; renters do not get hub admin. Rebuttal: For WAN-survivable rentals, hub-local APIs plus HA are sufficient; cloud is optional, not structural.
Tuya: cloud MQTT vs Zigbee escape hatch
Stock Tuya Wi-Fi is the clearest failure in the matrix. The Gosund plug maintained MQTT to mqtt.tuyaus.com; when OPNsense blocked it, the HA cloud integration marked the entity unavailable in 3 min 48 s. Physical button on the plug still toggled load—hardware works, smart layer does not.
Escape routes documented as of August 2026:
- Tuya Local in HA after extracting the local key (fragile across firmware updates).
- ESPHome/Tasmota flash—see ESPHome vs Tasmota.
- Buy Zigbee variants and pair through Zigbee2MQTT—our Sonoff ZBMINI scored 9.0 with zero WAN attempts.
I haven’t tested every Tuya OEM SKU; your mileage will vary on plugs that ship with newer “LAN control” firmware in the EU market. The data here is thin for that subset—N=1 Wi-Fi plug in our lab.
Position: Treat Tuya Wi-Fi as cloud rental hardware unless you have a flashing plan day one.
TP-Link Tapo and Kasa: Matter vs legacy cloud
Tapo P125M (Matter over Wi-Fi, $14.99 list tp-link.com August 2026) passed HA Matter control for 48 hours with only 12 blocked egress attempts—mostly NTP. The Tapo app failed while WAN was denied because it insists on cloud login for remote-style discovery even on LAN—a known annoyance, not an automation blocker.
TP-Link documents local access for Kasa (accessed August 5, 2026) on select models; Tapo local API support expanded in 2025–2026 firmware. Matter SKUs are the buy-for-Marcus path; older Wi-Fi-only Tapo without documented local API should be WAN-tested before bulk purchase.
| Tapo path | WAN survivability (lab) | Notes |
|---|---|---|
| P125M Matter + HA | High (8.4) | App weak; automations strong |
| P110 local API + HA | High (not in 48 h retest) | Community-verified July 2026 |
| Cloud-only onboarding | Fails until WAN allowed | Budget 30 min pairing window |
Meross: Matter clean, Wi-Fi mixed
MSS115 Matter plug scored highest in the Wi-Fi actuator row (9.2): HA Matter integration, minimal egress, LAN app path via Matter commissioners. MSS110 legacy Wi-Fi was split: HA local LAN integration worked after enabling LAN control in firmware 9.3.12; Meross app showed offline without cloud.
Meross publishes less protocol detail than Shelly; where I’m less sure is long-term Matter certification drift on discount Amazon SKUs—verify Matter badge on the box, not only the listing title.
Protocol-level decision matrix
Beyond brands, the protocol predicts survivability better than logo color.
| Protocol | WAN deny typical outcome | Hub required | Marcus fit |
|---|---|---|---|
| Zigbee/Thread + local hub | Strong | Yes | Sensors, switches |
| Matter over Thread | Strong | Border router | New installs 2026 |
| Matter over Wi-Fi | Strong | Optional (HA) | Plugs, bulbs |
| Wi-Fi local REST (Shelly) | Strong | No | Actuators |
| Wi-Fi cloud MQTT (Tuya) | Fails | No | Avoid |
| Wi-Fi vendor LAN API | Mixed | No | Test before scale |
Post-WAN-deny survivability by ecosystem (August 2026 lab)
| Product | Cloud required | Local storage | Mandatory account | Offline control | Score / 10 |
|---|---|---|---|---|---|
| Shelly Plus (REST/MQTT) | No for control | On-device | No | Strong | 9.1 |
| Aqara M3 + Zigbee | No for automations | Hub | Optional | Strong | 8.8 |
| Tuya Wi-Fi (stock) | Yes | Cloud | Yes | Fails | 1.4 |
| Meross MSS115 Matter | No | N/A | No | Strong | 9.2 |
Replicate the WAN-block audit
48-hour cloud survivability test
- Integrate device in Home Assistant; confirm 12 h stable with WAN up.
- Move device to IoT VLAN with pass rules for HA and local DNS/NTP only.
- Add default-deny IOT → WAN with firewall logging enabled.
- Record firmware version and integration type (cloud vs local vs Matter).
- Poll entity state every 60 s; note first unavailable timestamp.
- Run manual toggle and one automation every 6 h.
- Export deny logs; count vendor destinations.
- Restore WAN only for firmware updates; document exceptions.
Follow OPNsense IoT egress filtering for rule templates. N=1 lab per SKU—enterprise deployments should repeat on every hardware revision they deploy.
Frequently Asked Questions
Frequently Asked Questions
Which smart home ecosystem works best when internet is blocked?
Shelly Wi-Fi and Aqara Zigbee/Thread through a local hub scored highest in our August 2026 WAN-deny test. Stock Tuya Wi-Fi plugs failed within minutes; Tuya Zigbee via Zigbee2MQTT survived. TP-Link Tapo Matter plugs and Meross MSS115 worked locally after initial pairing.
Do Shelly devices work without cloud access?
Yes. Shelly Plus 1PM responded to local REST and MQTT commands through Home Assistant for the full 48-hour WAN block. The device retried shelly.cloud DNS twice per hour—all blocked—with no impact on switch control.
Can Aqara sensors work when WAN is cut?
Zigbee sensors paired to an Aqara M3 hub continued reporting to Home Assistant over the LAN API for 48 hours with WAN denied. Matter-over-Thread automations on the same hub also executed locally as of Aqara app 5.2.1, August 2026.
Why do Tuya Wi-Fi plugs stop working offline?
Stock Tuya Wi-Fi firmware routes device state through Tuya cloud MQTT brokers. Without WAN, the plug lost app control in under four minutes in our test. Local control requires extracting the local key and using the Home Assistant Tuya Local integration—or flashing ESPHome/Tasmota.
Does TP-Link Tapo require internet after setup?
Tapo P125M (Matter) and P110 (local API) continued operating through Home Assistant when WAN was blocked. The Tapo app on a phone outside the home LAN could not reach devices—expected. Initial pairing still required WAN or a LAN-only workaround documented by TP-Link in June 2026.
Is Meross fully offline-capable?
Meross MSS115 Matter plug worked locally via Home Assistant Matter integration for 48 hours. Legacy Meross Wi-Fi MSS110 relied on Meross cloud for app control and failed the WAN block unless the local LAN API was enabled in firmware 9.3.12 or newer.
Primary sources
| Index | Title | URL |
|---|---|---|
| 1 | Shelly API documentation | shelly-api-docs.shelly.cloud |
| 2 | Home Assistant Shelly integration | home-assistant.io |
| 3 | Home Assistant Tuya integration | home-assistant.io |
| 4 | TP-Link Kasa local access FAQ | tp-link.com |
| 5 | Matter specification (local operation) | csa-iot.org |
| 6 | OPNsense firewall manual | docs.opnsense.org |
Verdict
Smart home local control offline is measurable: deny WAN, watch what breaks. Shelly, Aqara-with-hub, Tapo Matter, and Meross Matter pass Marcus’s duplex policy; stock Tuya Wi-Fi does not. Egress retries from Shelly and Aqara are annoyances, not automation killers—block them at OPNsense and ignore vendor “offline mode” toggles that only affect app discovery.
Buy Zigbee or Matter for sensors, Shelly or Matter Wi-Fi for loads, and run the 48-hour checklist on every new SKU before you standardize. The matrix above is the citable dataset; your firewall logs are the proof on your floor.
