If you’ve put Aqara or Xiaomi gear on an isolated IoT VLAN, you already know the drill: mDNS reflection, outbound NAT tricks to preserve source IPs, a checklist that makes “just segment your network” sound like a part-time job. Move Tuya Wi-Fi devices onto the same kind of VLAN and LocalTuya’s “Discovered Devices” list comes back empty, which looks like the same problem. It isn’t. The failure is narrower, better documented, and the fix doesn’t require anything close to the Aqara/Xiaomi playbook.
This piece is the direct follow-through on our guide to blocking Tuya devices from the internet, which named a dedicated IoT VLAN as the strongest long-term way to block Tuya’s cloud and pointed at our Aqara/Xiaomi VLAN guide as “this site’s existing IoT segmentation approach.” That pointer implied Tuya would need the same level of complexity. It doesn’t. Everything below is sourced from integration issue trackers, project documentation, and Home Assistant Community threads describing the discovery and control protocol. No hands-on testing was performed for this piece.
Short answer: discovery breaks, control mostly doesn’t
Moving a Tuya Wi-Fi device to a separate VLAN from Home Assistant breaks discovery, the step where LocalTuya finds devices on the network and lists them for you to add. It does not, based on the sources checked for this piece, break ongoing control of a device once it’s already known to the integration. Those are two different mechanisms, and conflating them is what makes the Aqara/Xiaomi comparison misleading.
This covers Tuya Wi-Fi devices through LocalTuya (and, per the same device-side broadcast mechanism, tuya-local). It does not cover Tuya-branded Zigbee devices running through Zigbee2MQTT or ZHA, which don’t do UDP discovery at all.
“LocalTuya” is no longer one repository. The original rospogrigio/localtuya has stalled, the fork the community points at is xZetsubou/hass-localtuya, and for common devices make-all/tuya-local is the easier starting point. Our comparison of the three covers that choice. The issues cited below live in the original repository, but what they document is Tuya’s own device-side broadcast behavior, so the mechanism applies whichever one you install.
Why discovery fails: UDP broadcast doesn’t cross VLANs
Tuya devices announce themselves on the local network with a UDP broadcast, and which port they use depends on the device’s protocol version: 6666 for the older 3.1 and 3.2 firmware, 6667 for 3.3 and later, and 7000 for solicited discovery on protocol 3.5 devices. LocalTuya listens for these broadcasts to build its “Discovered Devices” list. UDP broadcast traffic doesn’t cross VLAN or subnet boundaries on any standard router or switch configuration. That’s ordinary network behavior, not a Tuya quirk. Once a device sits on a different VLAN than Home Assistant, the broadcast never arrives and discovery comes back empty. The version spread matters if you ever scope a rule to those discovery ports, because a list written for 6666 and 6667 alone misses a newer 3.5-era device.
This is documented directly in a LocalTuya GitHub issue (#2253, opened 2026-06-26), which states plainly that a working Tuya Cloud API connection doesn’t populate the Discovered Devices list either. The cloud API only retrieves account information and local_keys, not live device broadcasts. A separate, older feature request (#1603, opened 2023-12-29, still open) proposes fixing this by having LocalTuya fall back to the cloud API for discovery, precisely because the UDP-broadcast-only approach doesn’t reach across subnets. Treat that one as corroboration for the mechanism rather than for any fork’s current state, though: it sits in a tracker that has since stalled, where “still open” carries less information than it would in an active repository.
The broadcast comes from the device’s own firmware rather than from the integration listening for it, so tuya-local almost certainly depends on the same announcements. That follows from the protocol behavior, not from a code-level check, so treat it as the same underlying Tuya mechanism rather than a verified claim that both integrations behave identically here.
Why control still works: it’s just a TCP connection
Once a device is known to LocalTuya, whether it was auto-discovered before the VLAN move or added manually afterward, ongoing local control is a plain outbound TCP connection from Home Assistant to the device’s IP address on port 6668, authenticated with the device’s local_key. Home Assistant initiates this connection outbound to the device. Per the same GitHub issue, that’s also why the control port needs no special port mapping even in a Docker context, unlike the discovery broadcast.
This is the real contrast with Xiaomi Miio devices, covered in our Aqara and Xiaomi IoT VLAN guide: Miio devices filter incoming UDP commands by source IP, which is what forces the outbound NAT rewrite trick to make cross-subnet control work at all. Nothing in the LocalTuya sources checked for this piece documents any equivalent source-IP filtering on the Tuya control channel. A firewall rule permitting the Home Assistant host to reach the device’s IP on TCP 6668 is what the mechanism calls for, with no NAT rewrite and no mDNS reflector.
| Requirement | Aqara hub / Xiaomi Miio (per our VLAN guide) | Tuya Wi-Fi (LocalTuya, tuya-local) |
|---|---|---|
| Discovery across VLANs | Aqara hub needs an mDNS reflector (multicast UDP 5353) | UDP broadcast doesn’t cross VLANs; add the device by IP instead |
| Ongoing control across VLANs | Miio needs outbound NAT (source-IP filtering on UDP 54321) | Plain firewall allow rule on TCP 6668, no NAT rewrite |
| Prerequisite | Device already paired and tokened | Device already paired, local_key extracted |
The fix: static IP, then add the device manually
The practical fix for the empty-discovery-list problem is skipping discovery entirely: add the device to LocalTuya manually by IP address. That requires two things already in place. A static IP for the device, via a DHCP reservation, because a manual entry breaks if the address later changes. And the device’s local_key already extracted, which our Tuya local key guide covers. tuya-local offers the same escape hatch under “Manually Provide Device Connection Information,” which takes the device ID, IP address, and local_key directly.
An earlier HA Community thread (“LocalTuya on Vlans?”, thread 579304) documents a different approach: one user got discovery working by temporarily lifting the VLAN’s firewall isolation, letting LocalTuya complete its scan, then re-applying isolation afterward, later confirmed still working with static IP reservations on their gear. That’s a real, reported workaround, but it’s a workaround for discovery, not a description of how the underlying mechanism works.
Given the discovery-versus-control split above, manually adding the device by IP should avoid the need to lift firewall rules at all, provided the device finished its cloud pairing and has a local_key before being moved to the isolated VLAN. That matches the “pair first, block second” sequence from the block-internet piece. This is our own reading of the discovery mechanism rather than advice the thread gives, so treat it as the more direct fix the mechanism implies, not a community-endorsed recommendation.
A separate gotcha: Docker bridge networking
If Home Assistant itself runs in a Docker container using bridge networking rather than network_mode: host, discovery can fail for a second, unrelated reason. The UDP broadcast ports need to be explicitly published to the host, or LocalTuya never receives them, regardless of VLAN configuration. This is a distinct failure mode from the VLAN case above and shouldn’t be conflated with it.
If you’re running HA in Docker with bridge networking, check the port mappings before assuming a VLAN misconfiguration. Fixing the VLAN firewall rules won’t help if the broadcast ports never reach the container in the first place.
What the firewall rule actually needs to allow
Once a device is added manually and has a stable IP, the VLAN firewall configuration this calls for is narrow: one rule permitting the Home Assistant host to initiate outbound TCP connections to the device’s IP on port 6668. No mDNS reflector service, no outbound NAT or source-IP rewrite, and no inbound rule from the device back to Home Assistant, since the connection is initiated by Home Assistant rather than the device.
allow tcp from 192.168.1.50 to 192.168.20.0/24 port 6668
Honest caveat: this is still real configuration work
None of the above should read as “Tuya-on-a-VLAN is trivial.” The 2026-05-08 HA Community thread asking almost this exact question (“Tuya Loal — How to safely integrate the device”) got a candid response from an experienced poster. Asked directly whether they’d recommend VLAN isolation for a Wi-Fi device, their answer was no, not for anyone with novice-level networking knowledge, with the fallback suggestion being to replace Tuya Wi-Fi devices with Zigbee entirely. That’s a reasonable position for readers who find DHCP reservations and firewall allow-rules intimidating in the first place.
FAQ
Why does LocalTuya show no devices found after moving to a VLAN?
Because Tuya’s device-side UDP broadcast discovery doesn’t cross VLAN or subnet boundaries, a property of standard network behavior rather than something LocalTuya does wrong. Add the device manually by IP instead of relying on the Discovered Devices list.
Does LocalTuya need the same subnet as Home Assistant?
Only for discovery. Once a device is added (auto-discovered beforehand, or manually by IP), ongoing control is a normal outbound TCP connection on port 6668 that a firewall allow rule handles across subnets without issue.
Do I need an mDNS reflector for Tuya devices on a VLAN, like Aqara/Xiaomi?
No, and for a more basic reason than you might expect: Tuya discovery doesn’t use mDNS at all, so an mDNS reflector has nothing to reflect here.
What ports does LocalTuya need open across VLANs?
Just TCP 6668, outbound from Home Assistant to the device, once the device has been added. The UDP discovery ports (6666, 6667, and 7000, depending on protocol version) matter only for discovery, which the manual-IP-add approach sidesteps.
Can I add a Tuya device to LocalTuya manually without discovery?
Yes, provided you already have a static IP (DHCP reservation) for the device and its local_key extracted. See our Tuya local key guide if you haven’t extracted a key yet.
What’s confirmed here, and what to verify yourself
Confirmed directly from the LocalTuya GitHub tracker: UDP broadcast discovery doesn’t cross VLAN boundaries (Issue #2253, corroborated by the older Issue #1603), ongoing control is a local_key-authenticated outbound TCP connection on port 6668 that needs no special port mapping (Issue #2253), and Docker bridge networking introduces a separate port-publishing requirement unrelated to VLANs (Issue #2253). The protocol-version split across the discovery ports is documented by the tinytuya project rather than by either Home Assistant integration, and the note about the original repository having stalled reflects our own earlier comparison of the LocalTuya forks. The community-workaround account (temporarily lifting firewall rules, then re-applying) comes from a single HA Community thread and is reported, not independently verified.
Two things stay explicitly hedged rather than asserted as fact: whether tuya-local’s discovery behaves identically to LocalTuya’s, and whether manually adding a device by IP genuinely avoids the need to lift firewall rules at all. If you’re setting this up, the thing worth checking against your own network first is whether your VLAN firewall already permits outbound-initiated TCP from Home Assistant to the IoT VLAN by default. Many default-deny configurations block that direction too, and the single allow rule above only gets you there if outbound-from-trusted-VLAN traffic isn’t already blanket-blocked.