BETA — Open to testers. Tell us what to fix on @vomehome or via a tester code.

Move Tuya devices to local control

Get local keys for your Tuya devices and convert them to tuya-local, without a developer account and without breaking your automations.

Updated 16 August 2026 tuyahome-assistantlocal-control


Tuya devices normally route every command through Tuya's cloud. Local control removes that round trip: switches respond instantly, and they keep working when your internet does not. To talk to a Tuya device directly you need its local key, and getting one used to mean a Tuya developer account.

It no longer does.

Before you start

  • The tuya-local integration installed in Home Assistant (via HACS).
  • The Smart Life or Tuya Smart app, with your devices in it.
  • Devices on the same network as Home Assistant — see the warning below if your Home Assistant is hosted rather than sitting on your home network.

Zigbee and Bluetooth devices behind a hub cannot be converted — they speak their own protocol to the hub and have no individual local key. Only Wi-Fi devices and the hubs themselves qualify.

Installing the Tuya Local Bridge

The bridge is a Home Assistant add-on, not part of the VomeHome control panel. Add its repository and install it from inside Home Assistant:

  1. Settings → Add-ons → Add-on Store
  2. Top-right menu (⋮) → Repositories
  3. Add https://github.com/Vortitron/tuya-local-bridge
  4. Install Tuya Local Bridge from the list, then start it and open its Web UI.

Discovery needs to be on the same network as your devices

Tuya devices announce themselves by broadcasting on the local network, and broadcasts are designed never to leave the network they were sent on. A hosted Home Assistant therefore sees no devices at all in tuya-local's discovery, even though the bridge can still fetch your keys from the cloud.

You can still add devices by IP address once you have their keys, and HomeLink L2 mode removes the limitation entirely by putting the hosted server on your own network segment.

1. Connect your Tuya account

In the Smart Life app, go to Me → the gear icon → Account and Security and note your User Code. Enter it in the Tuya Local Bridge, then scan the QR code it shows with the same app.

That is the whole login. No developer account, no cloud project, no subscription — it is the same mechanism Home Assistant's own Tuya integration uses, and it returns a local key for every eligible device.

2. Review what it found

Devices are sorted into four groups, and the grouping matters more than it looks:

Group What it means
Ready In your account and visible on the network. Convert these.
Already local tuya-local already has it.
Not discovered Offline, on another subnet, or not local-capable.
Unexplained On your network, but your account has never heard of it.

That last group is worth reading rather than skipping — see below.

Your Tuya account device id → local key Network discovery device id → 192.168.x.y Ready to convert joined on device id
Neither source is enough alone. The cloud knows the key but reports only your public address; discovery knows the address but not the key.

3. Convert

Select the devices you want and convert them. tuya-local will ask which device type to use for some of them — it cannot always tell from the device alone. The best guess is listed first, but check it: a plug configured as a bulb will half-work in confusing ways.

4. Keep your automations working

This step is the one people skip, and regret.

Converting a device creates new entities. Your automations, scripts, scenes and dashboards all still point at the old cloud entities, which are now dead weight. Nothing warns you; things just stop happening.

The fix is to move the entity IDs across, so light.front_porch keeps meaning what it always meant:

tuya-local-bridge swap --dry-run bfa0ad92…

Check the plan, then run it without --dry-run. Every swap is recorded and can be rolled back.

Do not swap devices you converted by hand

If you previously converted a device and renamed its entities to something sensible, a swap will replace those names with the auto-generated cloud ones. That is why nothing is swapped unless you name it or pass --all.

When it goes wrong

A device stops responding weeks later. A tuya-local entry pins an address, a key and a protocol version, and none of those are permanent. DHCP moves addresses, and re-pairing a device rotates its key. Both look identical: silence, with nothing in the log. Run tuya-local-bridge heal --dry-run to see what has moved, then heal to re-sync it. Worth doing on a schedule rather than waiting.

A device is "on your network but not in your account". Most often it is Tuya hardware sold under another brand — LEDVANCE, SYLVANIA and many others — and paired in that brand's own app, which is a separate Tuya account. It is not broken and you did not do anything wrong. See Local keys for other brands.

The other explanation is a device you factory-reset. It keeps broadcasting but belongs to no account, so no key exists for it anywhere.

The main switch did not swap. Tuya's cloud names a plug's primary switch "Socket 1" while tuya-local leaves it unnamed, so they do not pair automatically. Anything left unpaired is reported and keeps using the cloud — move it by hand in Home Assistant's entity settings.

Nothing is discovered at all. Discovery only works from inside your network's broadcast domain. If you are running the tool outside your network, it can read Home Assistant's own discovery instead, which works from anywhere.

Rather not do this alone?
The Vome assistant will walk you through this guide a step at a time, and can do some of it for you.
Sign in for AI help

Something wrong or missing here? Tell us — these pages are written from real work, so corrections are welcome.