Main

Recovering Local Control When a Vendor Cloud Goes Away: A Tuya Device Case Study

October 20, 2026

This is a recovery procedure for Tuya devices that are already installed. It is not a report of a specific vendor shutdown. The sources I can point to document how local control works, what it requires, and where it breaks. They do not document a particular cloud being switched off. That distinction matters, because the procedure is worth doing before any shutdown happens.

The premise is simple: treat the vendor cloud as a credential-issuance step, not a runtime dependency. If you can capture the device ID and local key while the cloud path still works, routine control can survive without it. If you cannot, you are dependent on whatever the vendor keeps running.

Why this is a maintenance task, not a crisis response

A vendor shutdown is one trigger. There are others that are easier to verify. The official Home Assistant Tuya integration relies on Tuya’s Python SDK, and that SDK does not expose all functionality available in the SmartLife app. The integration also requires re-authentication after every reload when Tuya updates the terms and conditions of its developer portal. A community report describes the Tuya IoT API explorer returning “No permissions. Your subscription to cloud development plan has expired.” when trying to retrieve a local key.

Those are ordinary operational failures. They interrupt the cloud path without any shutdown at all. If your devices depend on that path, they fail the same way.

Inventory the failure surface first

Before touching anything, separate your devices by radio type and by integration path.

Wi-Fi Tuya devices are the ones this procedure addresses. They speak a local protocol on your LAN, but they need a device ID and a local key to accept local connections. The official Home Assistant integration is cloud-dependent: it integrates devices added to the Tuya Smart and Smart Life apps and relies on Tuya’s SDK. A community post states plainly that the standard Tuya integration depends on cloud services and will fail without internet, while LocalTuya uses the local network.

Zigbee Tuya devices are a different stack. Zigbee2MQTT allows you to use Zigbee devices without the vendor’s bridge or gateway and bridges events to MQTT. That is the local path for Zigbee, not LocalTuya. Route yourself by radio type before you start, because the two procedures do not overlap.

One caveat on Zigbee: a community thread notes that Tuya Zigbee devices usually work but often require custom work to integrate with Zigbee2MQTT. Do not assume every Tuya Zigbee device is a drop-in.

Step 1 — Capture credentials while the cloud path still works

You need two values per Wi-Fi device: the device ID and the local key.

The documented path is the Tuya IoT developer portal. Log in, and under Cloud you should see a list of your devices containing the Device ID. Then go to the API Explorer, select “Query Device Details in Bulk” under Devices Management, and enter the device IDs separated by commas. The results include the local key.

If you prefer a command-line route, the tinytuya wizard can scan your local network for Tuya devices and report their IP address. Its devices.json output contains the device id, the local key, and the node_id for hub-dependent devices. The wizard needs your API credentials from the developer portal: Access ID, Access Secret, one registered device ID, and your data center region.

Record three things for every device: device ID, local key, and a fixed IP address. Fix the IP in your router’s DHCP reservation. The tuya-local documentation is explicit that the “Auto” IP setting fails if LocalTuya is installed, if the Tuya/Smartlife app is connected locally to some devices, or if your network is anything other than a simple single subnet. Reconnection performance is also worse with Auto because the integration has to search the network first.

Store the keys somewhere you will find them after a re-pairing. A local key can change when a device is re-paired, and the LocalTuya documentation notes that its optional cloud API configuration exists partly to auto-update local keys after re-pairing. If you are running without cloud access, you are the auto-update mechanism.

Step 2 — Choose the local integration

There are two realistic options for Wi-Fi Tuya devices, and they are not equivalent.

The official Tuya integration is the cloud path. It is supported, it is in core, and it depends on Tuya’s SDK and servers. It is not the recovery target. Keep it configured but disabled as a rollback, and do not expect it to work when the cloud path is unavailable.

LocalTuya is a Home Assistant custom integration for local handling of Tuya-based devices. It updates device status by pushing updates instead of polling, so status changes arrive quickly even when a device is operated manually. Its cloud API account configuration is not mandatory, but it is strongly suggested for retrieving and auto-updating local keys. Cloud API calls happen only at startup and when a local key update is needed.

That last point is the design principle in one sentence: the cloud is a credential source, not a runtime dependency. If you configure the cloud API, the integration touches it at startup and then leaves it alone. If you do not configure it, you supply the keys yourself and the integration never calls the cloud at all.

LocalTuya supports Tuya protocols 3.1 through 3.4 and lists switches, lights, covers, fans, climates, and vacuums as supported device types. Energy monitoring is supported on compatible devices. If your device is outside that list, this path may not recover it.

Step 3 — Configure and verify

Add the integration, then add each device. If you configured the cloud API, the device list is populated automatically and you only need a friendly name and the local key. If you did not, enter the device ID, local key, and fixed IP manually.

Map the data points. The integration shows the available DPs with their current status, which makes identification straightforward for switches and lights. For climates, the documentation includes a DP mapping table for specific models and notes that Tuya-based climates vary widely, so treat any mapping as device-specific until you verify it.

Set the scan interval only if energy or power values update too slowly. The documentation recommends 30 seconds and warns that values below 10 seconds may cause stability issues. Do not lower it by default.

Verification is the part people skip. Confirm three things:

  • State changes initiated at the device appear in Home Assistant without a cloud round trip.
  • Commands from Home Assistant reach the device with the cloud path unavailable.
  • The device survives a power cycle and reconnects.

Test the third one deliberately. Power-cycle the device at the breaker, not just at the switch, and watch whether it comes back.

Step 4 — Harden against the zombie state

This is the step where naive “block the internet” advice goes wrong.

If you block a Tuya device’s outbound internet access but leave DNS reachable, the device can sit in a zombie state: it refuses or does not respond to connections with the local key. The LocalTuya documentation is explicit that you must also block DNS requests to the local DNS server. Blocking only outbound internet is not sufficient.

The correct order is: connect the device with active internet, capture the local key, then implement the block. Doing it in the other order leaves you without the credential you need.

If a device is already in the zombie state after a power cycle, LocalTuya has a recovery option: “DPIDs to send in RESET command.” It is used when a device does not respond to Tuya commands after a power cycle but can still be connected to. The documentation notes that this scenario mostly occurs when the device is blocked from accessing the internet, and that the DPIDs vary by device — typically “18,19,20” is used, but wrong entries can prevent the device from coming out of the zombie state. Treat those numbers as a starting point to verify, not a universal constant.

Present the DNS block and the RESET DPIDs option as one procedure. They address the same failure mode from two directions.

Step 5 — Define graceful degradation

Local control preserves switching, dimming, and status for supported device types. It does not restore everything.

Cloud-only scenes will not come back through this path. The official integration notes that scenes created in the Tuya app appear in Home Assistant, and that if the SDK exposes no status, status_range, or function data points for a device, only scenes declared inside Tuya are available. Those scenes are cloud artifacts. If your automations depend on them, they are not recovered by LocalTuya.

Data points the SDK does not expose will not appear. The official integration’s troubleshooting section says to download the device diagnostics JSON and check the status, status_range, and function keys. If all three are empty, the device exposes nothing useful through that path. That is a useful pre-check even if you are migrating away from the official integration: it tells you what the device is willing to report.

Write down what still works when the cloud is unreachable. For a typical Wi-Fi switch or dimmer on LocalTuya, that is on/off, brightness, and state feedback. For a climate device, it depends on the DP mapping you verified. For anything cloud-scene-dependent, assume it stops.

Rollback and re-pairing

Keep the official Tuya integration configured but disabled. If the local path fails on a device you cannot afford to lose, you can re-enable the cloud path and get control back, assuming the cloud path is still available.

Record the local keys and fixed IPs in a file that survives a Home Assistant rebuild. If a device is re-paired, its local key may change, and without the cloud API configured you will need to re-derive it from the developer portal. That is the tradeoff: no runtime cloud dependency, but manual credential maintenance after re-pairing.

If the developer portal itself becomes unavailable — expired subscription, changed terms, account issue — you cannot re-derive keys. That is the scenario this procedure is designed to survive, and it is why capturing credentials early is the whole point.

When a plain switch is the smarter choice

Not every device is worth recovering. A Wi-Fi Tuya bulb that needs a local key, a fixed IP, a DNS block, and a DP mapping to do what a wall switch does is a poor trade. If the device controls a light in a hallway and the household expectation is that the light works, a mechanical timer or a plain switch is more reliable than any of this. The recovery procedure is for devices where local control adds something you actually use — dimming, scheduling, status feedback — and where you are willing to maintain the credentials.

Repeatable checklist

  1. Separate Wi-Fi Tuya devices from Zigbee Tuya devices. Zigbee goes to Zigbee2MQTT, not LocalTuya.
  2. For each Wi-Fi device, capture device ID and local key from the Tuya IoT developer portal, or via the tinytuya wizard.
  3. Fix each device’s IP address in the router.
  4. Install LocalTuya. Configure the cloud API only if you want automatic key retrieval; otherwise enter keys manually.
  5. Map DPs and verify state changes, commands, and power-cycle recovery.
  6. Block outbound internet and DNS for the device. Do not block only outbound internet.
  7. If a device enters the zombie state after a power cycle, try the RESET DPIDs option with device-specific values.
  8. Document what still works without the cloud, and what does not.
  9. Store keys and IPs outside the Home Assistant instance.
  10. Keep the official cloud integration configured but disabled as a rollback.

FAQ

Does LocalTuya need the Tuya cloud at all?

No. The cloud API account configuration is not mandatory. It is strongly suggested for retrieving and auto-updating local keys, and cloud calls happen only at startup and when a key update is needed. Without it, you supply keys manually.

Why did my device stop responding after I blocked its internet access?

Most likely the zombie state. Blocking outbound internet without also blocking DNS leaves the device refusing local-key connections. The LocalTuya documentation states this directly. Block DNS as well, and use the RESET DPIDs option if the device is already stuck.

Will this restore everything the vendor app did?

No. Local control preserves switching, dimming, and status for supported device types. Cloud-only scenes and data points the SDK does not expose will not come back through this path. Check the diagnostics JSON for empty status, status_range, and function keys before assuming a device is recoverable.

What about my Tuya Zigbee devices?

They are a different stack. Zigbee2MQTT lets you use Zigbee devices without the vendor’s bridge or gateway and bridges events to MQTT. A community thread notes that Tuya Zigbee devices often require custom work to integrate, so verify device support before committing.

What happens if a device is re-paired?

Its local key may change. If you configured the cloud API in LocalTuya, the integration can auto-update the key. If you did not, you need to re-derive it from the developer portal — which is exactly the dependency this procedure is meant to reduce. Capture keys early and keep them.

For a broader look at which small systems in a home quietly carry this kind of dependency, see How to Audit the Small Systems That Quietly Run Your Week.