Tuya local

Got the keys no problem, the problem is understanding how to use the entities once you have them. I don’t have a clue what I need to send to curtains and blind to open and close them

Sorry no, I gave up and went back to the Tuya Integration until someone can figure it out

ok too bad but thanks for your comment

Hi Paul (@paulearley),

Did you manage to get Tuya Local working on a separate VLAN from HA? I have also just started moving devices to a separate VLAN and am seeing the same as what you mention. I am guessing it may have something to do with broadcast traffic even though I have mDNS enabled on my UniFi UDM.

In for the same issue.
Just starting with Tuya Local yesterday and have a separate IoT VLAN. Internet is not blocked on this VLAN but I do restrict it’s access to other VLAN’s. I’ve got a hole opened in the firewall to allow it to reach HA and that works, but any Tuya Local devices I put on there don’t get picked up by the integration GUI for configuration, and a manual config just shows the device as “unresponsive”.

EDIT: @brentk I was able to get all of my devices connected by rolling the integration back from 3.2.0 to 3.1.0. I’ve only got 7 but they all instantly started working by doing this. If you head to the github issues section and search “unavailable” there’s 2 or 3 different issues posted with the same thing. I guess in my case it was completely unrelated to the VLAN

1 Like

Thanks @MRobi - I’ll try rolling back. I’m pretty sure mine is related to the separate VLAN as I have only moved one of my devices over to the new VLAN and it is the only one showing unavailable. Other devices still on the same main VLAN as HA work fine. I have temporarily disabled the firewall rules blocking traffic between VLANs - so I think it must be related to broadcast traffic. If rollback doesn’t work I might have to look at installing multicast-relay on my UDM as hinted to in this github issue post..

I tried using a Podman container to transport UDP across VLANs - it worked for Sonos but not for the Tuya devices.

The solution that DID work was to have the Tuya’s on the same network as HA and implementing a Drop rule all outbound traffic (WAN OUT) for the Tuya devices on the UDM Pro AND blocked DNS for the Tuya devices (on LAN LOCAL)

I am now running Tuya Local, the Tuya app on my phone says all my devices are offline. It SEEMS I am running true Tuya local at this time. If you need more specific instructions I would be happy to share. It was a long road to get here (but I am relatively new to UniFi hardware).


That shouldn’t be necessary.
I have my Tuya devices on a dedicated IoT VLAN with blocks to everything on my network except HA, which is on it’s own VLAN. I’m also using the UDM-P. On version 3.2, I couldn’t connect to any devices. Downgrading to 3.1 and they all connect right away. There’s something in 3.2 that’s causing this behavior with VLANs and I don’t think reconfiguring how your network is setup because of a bug is really the solution

In 3.2, all connection attempts to devices are made based on broadcast messages from the devices. So when a device sends a broadcast to port 6666/6667 (UDP), that’s when we connect. This is a problem when using VLANs and I intend to add a re-connect loop back at some point. There’s a PR open for it that you can try. With that PR, an attempt to connect is made every minute.

Would poking a hole in the firewall to those 2 ports fix it?

By chance are you clicking the add integration button on the integrations page? You have to add the tuya local integration each time you want to add a new device

Thanks @paulearley - I have managed to temporarily get it working by rolling back to version 3.1.0. I tried installing multicast-relay in a podman container to relay the port 6666/6667 packets but could not get that working (probably due to lack of understanding). I guess I’ll just wait for the next version which includes the re-connect loop @postlund has mentioned (I have no idea how to get the PR running inside the HACS installed integration).

@MRobi - Not as far as I’ve been able to tell. Even with no firewall rules blocking traffic between the 2 VLANS - this does not work. From my understanding - the devices send BROADCAST traffic to those 2 ports which don’t get transmitted across subnets / VLANs without some form of relay to explicitly do that (which is why I tried to install multicast-relay on my UDM).

You need to forward broadcast traffic to those ports, so you will need something that does that for you. Just “opening” those ports won’t do.

I had the same issue. I tested @MRobi solution and it worked fine, but I like to updated to the latest version everything. Based on tuyalocal change log

Added support for passive devices, I.e. connection attempts are now made when discovery messages are received. This is a breaking change as these messages are now mandatory for the integration to function. Ensure UDP broadcasts for port 6666 and 6667 are forwarded to Home Assistant.

this change will be permanent, so I tried this
and it works for me.

My setup is main LAN with no VLAN id and IOT VLAN 100, hass is on LAN the smart plugs are on IOT.
I added 2 bcast-relay service id 1,2 like this and after restarting hass it started working again on localtuya 3.2.1.

set service bcast-relay id 1 description 'Tuya broadcast listener 6666'
set service bcast-relay id 1 interface eth1
set service bcast-relay id 1 interface eth1.100
set service bcast-relay id 1 port 6666         
set service bcast-relay id 2 description 'Tuya broadcast listener 6667'
set service bcast-relay id 2 interface eth1
set service bcast-relay id 2 interface eth1.100
set service bcast-relay id 2 port 6667

This is interesting. Are you on a USG? It doesn’t seem to want to install on the UDM-Pro

Yes, I’m using USG, but the bcast-relay was originally for EdgeOS so it works on diffrent devices. I’m not sure how the UDM is different, I never used one.

After upgrading to the latest TuyaLocal, several of my (simple) Tuya wifi sockets fell offline. I removed one of the sockets from the TuyaLocal integration then attempted to re-attach. The id and key were checked using the tuya-cli wizard and confirmed correct.
The error message seems to be a timeout on the query. I have never seen this before. Oh, and I attempted this WITH and WITHOUT the firewall rules in place that block remote access. Any thoughts?

Unexpected exception
Traceback (most recent call last):
  File "/config/custom_components/localtuya/config_flow.py", line 279, in async_step_basic_info
    self.dps_strings = await validate_input(self.hass, user_input)
  File "/config/custom_components/localtuya/config_flow.py", line 192, in validate_input
    detected_dps = await interface.detect_available_dps()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 510, in detect_available_dps
    data = await self.status()
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 472, in status
    status = await self.exchange(STATUS)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 467, in exchange
    return await self.exchange(command, dps)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 451, in exchange
    msg = await self.dispatcher.wait_for(seqno)
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 240, in wait_for
    await asyncio.wait_for(self.listeners[seqno].acquire(), timeout=timeout)
  File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
    raise exceptions.TimeoutError()

Further data:
Tried to add a previously unused Tuya WiFi socket to TuyaLocal. Again, all firewall rules to prevent access to Tuya Servers are disabled. I was able to ping the socket ( before attempting integration. The following error occurred:

Traceback (most recent call last):
  File "/config/custom_components/localtuya/config_flow.py", line 279, in async_step_basic_info
    self.dps_strings = await validate_input(self.hass, user_input)
  File "/config/custom_components/localtuya/config_flow.py", line 185, in validate_input
    interface = await pytuya.connect(
  File "/config/custom_components/localtuya/pytuya/__init__.py", line 637, in connect
    _, protocol = await loop.create_connection(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1025, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1010, in create_connection
    sock = await self._connect_sock(
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 924, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 496, in sock_connect
    return await fut
  File "/usr/local/lib/python3.8/asyncio/selector_events.py", line 528, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('', 6668)

If you revert back to the version that previously worked, does it function properly again?