Tuya integration: config entry dies permanently — sensors stuck for days

Configuration
1

Summary

The official Tuya integration fails in two distinct, compounding ways:

  1. MQTT channel freezes every ~2-3h: the tuya_sharing MQTT thread dies with API_QPS_LIMIT_OR_DEGRADE and never reconnects. All Tuya sensors go unavailable / stay frozen at their last value until the integration is manually reloaded. This has been happening for weeks and requires an automation to auto-reload every 3h as a workaround.

  2. A config entry can die permanently: one of my two Tuya entries (same Tuya account, same HA instance) now returns sign invalid / token is expired on EVERY API call, including GET /v1.0/m/token/{refresh_token} (the refresh token itself is dead). The entry cannot be recovered by reloading, by homeassistant.reload_config_entry, or by any API call. The other entry (same account) still works fine and sees 25 devices.

Environment

  • Home Assistant Core (container), latest 2026.x
  • Integration: tuya (official), 2 config entries, same account
  • Devices affected: 3 Tuya covers (blinds) + 3 background lights + 1 scene in the dead entry; ~25 devices in the working entry
  • All devices work fine in the Tuya/SmartLife app — the problem is purely the HA ↔ Tuya Cloud integration

What I did

  • homeassistant.reload_config_entry on the dead entry → no change
  • Tried refreshing the token via the SDK’s own refresh flow (Manager + SharingTokenListener + refresh_access_token_if_need) → refresh never fires (bug: CustomerTokenInfo has no .get(), refresh silently fails)
  • Tried direct GET /v1.0/m/token/{refresh_token} → token is expired (1010) even when signing with the refresh_token
  • Tried re-querying the devices with the OTHER (working) entry’s token → permission deny (1106) — the devices belong to a home/project that this entry can no longer see
  • Devices are reachable on the LAN (Tuya protocol 3.3, found via broadcast) but the local_key HA has is stale (rotated by Tuya), so local control is also impossible

Expected behavior

A config entry whose token expires should be recoverable via its refresh_token, or at least fail in a way that surfaces clearly (not silently freezing all entities for days). Losing a whole entry permanently, with no recovery path other than scanning a QR with the phone, is a serious reliability problem.

Actual behavior

  • The entry is permanently dead from HA’s side; only re-authenticating with a QR scan (or moving devices to another home in the app) recovers it
  • The community workaround (auto-reload every 3h) fixes the freeze but not the dead entry
  • Community threads with identical symptoms: #915171 (Tuya Online Acting Strange), #701217, #748635, GitHub #116299

Logs

ERROR (Thread-X) [root] Uncaught thread exception
.../tuya_sharing/mq.py ... API_QPS_LIMIT_OR_DEGRADE
Exception: network error:(-9999999) API_QPS_LIMIT_OR_DEGRADE

network error:(1010) token is expired   (on refresh endpoint)
network error:(-9999999) sign invalid   (on all entry API calls)
network error:(1106) permission deny    (querying dead entry's devices with working entry token)

Questions

  1. Is there any supported way to force a token refresh of a Tuya config entry without a QR scan?
  2. Is the refresh_access_token_if_need bug (CustomerTokenInfo.get missing) known? It makes automatic token renewal impossible.
  3. Should the integration detect a permanently-dead entry and alert the user instead of silently freezing entities for days?
2

Not unknown for Tuya devices. They are on average the least stable and the most non-standard devices in HA. They are designed and sold by many small engineering firms with different ideas on how to do things (This is why so many company names).
Also if it’s a WIFI thing they often rely on the control to go thru a server in China for all commands.
This is why there are several Community members that have created Custom Integrations for Tuya. Perhaps these troublesome devices would work better with a different integration? No guarantee but possible.

3

Thanks @Sir_Goodenough - agreed, and I have a fresh reproducible example of the frozen datapoint side of this today.

Concrete case (23 Aug 2026):

  • Tuya smart plug with energy monitoring, in the WORKING entry (the one that sees 25 devices fine).
  • The SmartLife app shows 13.40 kWh consumed today - device is perfectly fine.
  • Home Assistant shows 0.0 for the total energy sensor and its last_updated is stale.
  • The HA history DOES contain the real values from overnight (0.368 to 6.6 kWh per hourly cycle, about 13 kWh total), but every ~60 min the entity goes unavailable for a few seconds and when it comes back the datapoint is reset to 0 (the device total_increasing_kWh is re-reported from 0).

So the device reports real consumption, the app shows it, but HA receives a reset-to-0 datapoint each cycle. Same MQTT-dies/frozen-datapoint symptom, but on the healthy entry, not the dead one. A manual reload of the config entry wakes the sensor (updates again) but the value stays 0.

This suggests the integration is losing device state on reconnect instead of re-syncing the full datapoint set. Happy to add full logs and entity history export if useful for a GitHub issue.

4

¯\_(ツ)_/¯ Sounds like you are looking for…