Universal Tuya v9.0.832 — local-first Tuya WiFi (no cloud required in operation)
50 WiFi drivers ship with the app: 28 speak the Tuya LAN protocol (local-first, AES-encrypted TCP on port 6668) and 22 use other local protocols (eWeLink, Sonoff DIY, camera). Every Tuya LAN driver below works entirely on your local network once paired.
wifi_* driver and choose a pairing method: QR code (Smart Life), Tuya IoT API, or manual entry.local_key once from the Tuya cloud (opt-in) and stores it locally on Homey.No. The cloud is only used once during pairing to fetch the local_key. Daily operation
(on/off, dimming, telemetry, automations) is 100% LAN via TuyaLocalClient (TCP 6668, AES).
Tuya devices encrypt local traffic with a per-device local_key that is only issued by the Tuya
cloud at provisioning time. Fetching it is a one-time, explicit opt-in step — you can also enter it manually
if you extracted it yourself.
TuyaUDPDiscovery listens on UDP 6666/6667/6668 for device broadcasts and re-resolves the IP
automatically (IP self-healing). No re-pairing needed.
Commands are buffered in a bounded offline queue (50 commands, 5-minute expiry) and the client reconnects with exponential backoff (5 s → 60 s) plus a 15 s heartbeat. The device shows as unavailable in Homey instead of failing silently.
Yes — wifi_connection_policy.cloudFallback (default false, local-first). Even then,
the cloud is only queried for a diagnostic status snapshot (rate-limited, never applied to capabilities):
control always stays local. Every transport decision is logged with its reason.
The WiFi stack follows the tuya-local pattern: pure decision logic first, I/O second, and every transport decision explainable from the logs.
cloudFallback=true AND credentials present) → nonereason for every decision, logged as
[LOCAL-FIRST] Transport decision: …find() scan on connectlocal_firstcloudFallback defaults to false (opt-in)localDiscovery enables dynamic IP self-healingconnection-timeout handler)resolveTransport(id) with decision logging
UDP 6666 / 6667 / 6668 (broadcasts)
┌──────────────────────────────────────────┐
│ ▼
┌───────────────┐ TCP 6668, AES ┌────────────────────────────┐
│ Tuya WiFi │ ◄────────────────────► │ TuyaLocalClient │
│ device │ proto 3.1/3.3/3.4/3.5│ heartbeat 15s · backoff │
│ │ │ 5s→60s · queues │
└───────────────┘ └─────────────┬──────────────┘
▲ │
│ LAN (default) ┌─────────────▼──────────────┐
│ │ LocalFirstResolver │
┌──────┴───────────────────────┐ │ pure decision + reason │
│ Homey app │ │ lan → cloud? → none │
│ wifi_* drivers (Tuya LAN) │ └─────────────┬──────────────┘
│ TuyaLocalDevice │ │ only if cloudFallback=true
└──────────────────────────────┘ ┌─────────────▼──────────────┐
▲ TuyaUDPDiscovery │ Tuya Cloud (opt-in) │
└── IP self-healing ─────────────►│ diagnostic snapshot only, │
│ never applied, rate- │
│ limited 1/10min │
└────────────────────────────┘
| Component | File | Role |
|---|---|---|
| TuyaLocalClient | lib/tuya-local/TuyaLocalClient.js | Encrypted LAN session: protocol auto-negotiation, heartbeat, backoff, command & offline queues |
| TuyaLocalDevice | lib/tuya-local/TuyaLocalDevice.js | Base class for the 28 Tuya LAN drivers; wires resolver decisions, connection-timeout fallback, LAN retry |
| LocalFirstResolver | lib/wifi/LocalFirstResolver.js | Pure transport decision (lan/cloud/none) with a logged, user-diagnosable reason |
| WiFiConnectionPolicy | lib/wifi/WiFiConnectionPolicy.js | Per-device policy store — local_first strategy, cloudFallback opt-in (default off) |
| TuyaUDPDiscovery | lib/tuya-local/TuyaUDPDiscovery.js | UDP 6666/6667/6668 listener, dynamic IP self-healing |
| LocalWiFiTuyaBridge | lib/tuya/LocalWiFiTuyaBridge.js | Local-first facade (discovery + sessions) for unified WiFi handling |
| TuyaCloudAPI | lib/tuya-local/TuyaCloudAPI.js | Pairing-time local_key retrieval and opt-in diagnostic snapshots |
The data-point mappings are cross-checked against the tuya-local project catalog:
0 devices catalogued across
0 manufacturers with
0 DP mappings
(snapshot 0 devices exported in data/scanners/tuya-local-results.json).
Conservative additions land in driver dpMappings only when attested across multiple devices —
ambiguous generic DP names ("switch", "sensor", "value") are annotated, never guessed.