"Tuya" on the box is not one thing. It is a cloud platform, a Wi-Fi firmware stack, and — in the ZigBee range — a ZigBee profile. Which of the three your device actually uses decides what you can do with it in Home Assistant, and where the pain is.
Path 1: the official cloud integration
The Tuya integration talks to the Tuya cloud, not to your device. Your switch reports to Tuya's servers, Home Assistant polls those servers, and a command goes back the same way.
The good part: it works with essentially every Tuya device, including ones you will never get local access to. It survives firmware updates, and it works when you are away from home.
The bad part: it is polling. State changes can take several seconds to a couple of minutes to appear, and if the internet is down your automations stop even though the switch is two metres away. Physical presses are usually reported quickly; state changes you trigger from Home Assistant are the slow ones. Some regions and some accounts also have a limited device count on the free developer tier.
Path 2: Local Tuya
Local Tuya (the custom component, not the official one) talks to the device directly over LAN, on TCP port 6668, using the same protocol the app uses locally. Latency drops to tens of milliseconds and it keeps working without internet.
To set it up you need three things per device: the device ID, the local IP, and the local key. The local key is the awkward one. You get it from the Tuya IoT developer console by linking your own app account to a cloud project, or by pulling it out of an Android app backup. The key is per-device, and it is rotated if you re-pair the device.
Where it breaks: newer firmware on the 3.5 protocol refuses many local connections outright, and some devices simply never answer on 6668. Devices that do work can still stop working after a firmware update. Practically, you should assume Local Tuya is a per-device experiment rather than a platform guarantee.
If you want local control to be reliable, block the device from the internet at the router after pairing. Otherwise a firmware update can land overnight and quietly end it.
Path 3: reflashing the firmware
Plugs and a few low-cost devices are built on ESP8266 or ESP32 and can be flashed with ESPHome or Tasmota. That gives you MQTT, full local control, and no cloud at all.
Do not do this to a mains wall switch. You are opening a device that carries line voltage, the enclosure is not designed to be opened repeatedly, you lose the certification that made it legal to install, and the RF calibration is not something you can redo on a bench. If you want local-only mains switching, buy a device that is designed for it instead.
Tuya ZigBee devices cannot be reflashed in place at all — they are not ESP-based.
Tuya ZigBee on your own coordinator
A Tuya ZigBee switch will usually pair to a generic coordinator running Zigbee2MQTT or ZHA. The relay exposes the standard On/Off cluster, so the light turns on and off, and multi-gang switches show up as separate endpoints, one per gang.
What you should not expect: the Tuya manufacturer-specific cluster carries scene events, button presses, backlight settings and sometimes energy monitoring. Those will not map cleanly to ZHA or Z2M out of the box. You typically get reliable switching and partial everything else, and you write automations against raw cluster commands if you want the rest.
This is a genuinely good option if your priority is "my lights must work when the internet does not". It is a bad option if you expect a polished, complete entity list on day one.
DPs: why your three-gang switch shows up as several things
Tuya models a device as a set of data points. A switch is not "a switch" — it is switch 1, switch 2, switch 3, plus a backlight setting, plus countdown timers, plus sometimes power monitoring.
That is why one physical device can appear as four or five entities, and why the number of entities changes after a firmware update. If you are building automations, target the switch entities, not the device, so a later firmware change does not silently break them.
What I would actually do
Keep mains switching devices on ZigBee with a local coordinator if you can, because a light that needs a round trip to a cloud server to turn on is a light that will eventually annoy you. Use the cloud integration as the fallback for remote access and for any device that will not pair locally. Re-pair rather than fight a device that has been flaky since an update — most "unreachable" ZigBee problems are pairing problems, not firmware problems.
One honest caveat: I work on the manufacturing side of this category, so I am biased toward "buy the device that fits your topology" rather than "make this device fit". But the topology advice holds regardless of whose logo is on the front.
Xingliao Smart Home builds smart switches, video doorbells and security cameras on Tuya WiFi and Tuya ZigBee, and runs OEM/ODM programmes from Shenzhen. Factory and ODM capability.
Top comments (0)