Closed accelle17 closed 3 years ago
Is there any chance that you also block UDP on this device?
When I do below udp test from a machine on the iot vlan, it goes through:
hass = 192.168.1.167 pi on iot = 192.168.20.239
nc -z -v -u 192.168.1.167 6666 > /dev/null && echo on || echo off Connection to 192.168.1.167 6666 port [udp/*] succeeded! on
EDIT: is the UDP the difference between version 3.1 and master?
Yes, tuya devices send udp advertisement packet on the network and we now use these packets (containing the real ip address of the device) to trigger the connection.
I tested on another tuya device by using the non-IOT vlan and it was working fine. ok, it looks like this is udp multicast issue which I think can just be resolved by moving to the non-IOT vlan. I already have igmp-proxy and masquerading between the two VLAN which I used to fix the xiaomi miio protocol. I am already out of option unless anyone can chime in, staying on 3.1 for now.
Edit: will try this during off peak hours: https://community.ui.com/questions/Multicast-Sonos-Phorus-and-Play-Fi-Broadcast-255-255-255-255-lessportgreater-Discovery-Solution/1ce890c2-5e7e-4ef2-a42a-e9c59444fd3f#answer/fae150b3-ad70-4e9a-9b8b-9f20777e46e7
There are plans on writing a small script that can relay these broadcasts to Home Assistant directly. You would run it on a machine that is on the network where your tuya devices are and point it to the address of your Home Assistant instance. Would that work?
I've tested https://github.com/britannic/ubnt-bcast-relay for the UDP 6666 and 6667 relay on my USG and it works. The localtuya can discover the devices now and I'm able to control couple of devices. I needed to do remove, reboot and re-add before the light component cooperates.
There are plans on writing a small script that can relay these broadcasts to Home Assistant directly. You would run it on a machine that is on the network where your tuya devices are and point it to the address of your Home Assistant instance. Would that work?
If you need help on testing that kind of relay, it might be another option to look into.
I was trying to update due to test out #236. All is working properly when on localtuya 3.1. However, if I try to use the master branch, the device shows unavailable right away unlike what is describe on #223. I even tried just using the base DP (20) for the light to isolate the issue but it doesn't work. Note: the tuya device is on a vlan blocked from internet and I already blocked the DNS queries from this device.
System Health
Home Assistant Community Store
GitHub API | ok -- | -- Github API Calls Remaining | 4246 Installed Version | 1.9.0 Stage | startup Available Repositories | 692 Installed Repositories | 15Hass.io
host_os | Raspbian GNU/Linux 10 (buster) -- | -- update_channel | stable supervisor_version | 2020.12.6 docker_version | 19.03.13 disk_total | 234.6 GB disk_used | 83.0 GB healthy | true supported | failed to load: Unsupported supervisor_api | ok version_api | ok installed_addons | Terminal & SSH (8.6.0), Samba share (9.2.0), Duck DNS (1.10), ADB - Android Debug Bridge (0.6.2), Git pull (7.3), Mosquitto broker (5.1), Log Viewer (0.6.3), Zigbee2mqtt (1.14.4.2), DHCP server (1.2), FTP (3.2.0), Tor (2.0.0), AdGuard Home (2.6.0), Portainer (1.2.2), MariaDB (2.2.0), deCONZ (6.3.0), UniFi Controller (0.17.0), RPC Shutdown (2.2), Let's Encrypt (3.0), Nginx Proxy Manager (0.6.0), Node-RED (6.0.3), Traccar (0.5.4), motionEye (0.5.5), ink to MQTT (0.2), Check Home Assistant configuration (3.3.0), Assistant Relay (0.7.4), Z-Wave to MQTT (0.5.0), Grafana (4.2.0), Grocy (0.7.1), Almond (1.0.1), Plex Media Server (2.3.3), ZeroTier One (0.7.2), room-assistant (2.8.2), JupyterLab Lite (0.3.1), ledfx (d56084f)Lovelace
dashboards | 5 -- | -- mode | storage views | 1 resources | 12DEBUG LOGS: