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).
Paul
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
https://community.ui.com/questions/Howto-HDHomerun-broadcast-relay-with-multiple-vLans/5307f894-76c8-48ec-938f-18d7d83a31d9
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
1 Like
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()
asyncio.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 (192.168.20.118) 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 ('192.168.20.118', 6668)
If you revert back to the version that previously worked, does it function properly again?