Protocol comparison tables list range, bandwidth, power draw, and whether a hub is required. Those numbers are easy to compare and almost never decide whether an installation is satisfactory. What decides it is what still works on the worst day: the router has rebooted, the internet is down, the gateway lost power, the phone is not at home, or the vendor's cloud is having a bad afternoon. Every protocol fails differently, and the right choice is the one whose failure you can live with.
Start from the outage you cannot accept
Write down the single function that must keep working. For a wall switch it is usually "the light turns on when someone presses the plate". For a camera it may be "the recording exists afterwards". For a leak alarm it is "the valve closes". Then walk each failure through and see which protocol still delivers that one function.
A physical wall switch keeps working in every case, regardless of protocol, because the plate is a local input to the relay. Almost every other smart function depends on a chain: device, radio, hub or router, cloud, app. The shorter that chain in the failure case, the better the installation ages.
When the internet is down
Tuya WiFi devices speak to a local router and then to a cloud service. Remote control and voice assistants stop when the uplink stops. Whether local control survives depends on whether the platform exposes a LAN path and whether the app uses it; some do, some fall back to cloud-only. Timers are the subtler case: a schedule stored in the cloud does not run, while a schedule stored on the device does. Ask where the timer lives before assuming the lights will come on at dusk during an outage.
ZigBee devices need a gateway to reach anything beyond their own mesh, but the mesh itself is independent of the internet. Local bindings, meaning switch to lamp or sensor to siren, keep working with the WAN cable pulled, provided the gateway is powered and the rule was stored locally. Bluetooth devices need neither hub nor internet, but they need a phone or a nearby bridge in range, so "offline" for them means "as long as you are standing there".
The comparison of Tuya Bluetooth, Tuya ZigBee and Tuya WiFi lays out the three architectures; the failure analysis below is the part that a spec sheet leaves out.
When the gateway or router loses power
A ZigBee mesh has a single point of failure: the gateway. Pull its power and the switches still toggle locally, but every scene, every remote command, and every sensor-to-cloud alert stops. A UPS on the gateway restores most of that with a small battery, which is why whole-home ZigBee installations usually put the gateway on the same protected circuit as the router.
WiFi devices have the mirror image: no dedicated gateway, but all of them depend on the router. A router reboot takes down every WiFi device at once, and some devices do not reconnect cleanly without a power cycle of their own. Bluetooth has no such shared dependency; each link is local and isolated, which is its real strength in a single-room installation and its real weakness across a house.
When the phone is not at home
This is the constraint that surprises buyers of Bluetooth-only devices. Pairing, configuration, and often control happen from a phone within a few metres. Away from home the device is unreachable unless a bridge is left on site permanently, at which point the bridge has become a gateway and the "no hub needed" advantage has gone. For a device in a holiday rental, a basement, or an elderly relative's flat, ask who is physically present when something needs changing.
When the cloud or the vendor changes
The longest-lived failure is commercial rather than technical. A device that needs a vendor cloud for pairing, firmware, and device identity stops being improvable when that cloud is retired or the account is closed. Local-control capability, documented LAN APIs, and standard clusters all reduce exposure, but the honest mitigation is to keep the critical function local: the plate must switch the light, the valve must close on a local alarm, and the recording must exist on local storage even if the notification never arrives.
For a buyer choosing a smart switch for a whole floor, that criterion usually matters more than the radio band. On OEM projects it is worth asking which parts of the stack are under your control; the OEM/ODM programme is where questions about firmware identity, cloud product entries, and long-term support belong, and they should be raised before tooling rather than after.
A short commissioning test
Before signing off an installation, run four drills and record what happens:
- Unplug the WAN uplink for an hour. Note which local controls, schedules, and automations still run.
- Power-cycle the router, then the gateway, separately. Count devices that need a manual reset to reconnect.
- Take the phone out of range. Try a local action and a remote one.
- Trigger a sensor alarm with the app logged out. Confirm the local action happens even if no notification is delivered.
The results are specific to the devices actually installed, not to the protocol in general. Two products both labelled "ZigBee" can behave differently here, which is why what ZigBee 3.0 changed is best read as a compatibility baseline rather than a behaviour guarantee. XingLiao Tech documents the manufacturing side of the same families if the next step is sourcing rather than selecting.
Top comments (0)