search

rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.91k stars 557 forks source link

Device unavailable after update from 3.1 or light_hsv branch to master #241

Closed accelle17 closed 3 years ago

accelle17 commented 3 years ago

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

version 2020.12.0
installation_type Home Assistant Supervised
dev false
hassio true
docker true
virtualenv false
python_version 3.8.6
os_name Linux
os_version 5.4.75-v7l+
arch armv7l
timezone Asia/Manila
Home Assistant Community Store GitHub API | ok -- | -- Github API Calls Remaining | 4246 Installed Version | 1.9.0 Stage | startup Available Repositories | 692 Installed Repositories | 15
Hass.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 | 12

DEBUG LOGS:

2020-12-16 11:32:47 DEBUG (MainThread) [custom_components.localtuya.discovery] Listening to broadcasts on UDP port 6666 and 6667 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Started heartbeat loop 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Sending command heartbeat (device type: type_0a) 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Send payload: b'{}' 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Waiting for sequence number -100 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Sending command status (device type: type_0a) 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Send payload: b'{"gwId":"ebfcbbc2606b0d7b39xadr","devId":"ebfcbbc2606b0d7b39xadr"}' 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Waiting for sequence number 1 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211) 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Got heartbeat response 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Decrypted payload: {} 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Dispatching message TuyaMessage(seqno=1, cmd=10, retcode=0, payload=b'\xafia@\x0c\x11\xe0\xac\xbe\xd8\x07\x8e\xbf\x94\xea\x184\xd8.\x7f\xd0\xd0[\xecj\x04?\xdc\x87.\xc0\xa9\xa9\x05dx\x08\x80X\x97\xca\x8dT\xb8\x8a\xfeU\x128\x9c\x19p\x91G\xf1R\xd8v_D\xc1\xcf\xcd\xa1\xb8\xb9\x92\x8e\xeea\xb4\xdd\xdeYC\x87\xad\xe2\xbe\x96u\xc6\x89\xe6\xc3\x13\x9a\xbd/s\xb9\xe5\xbb\x1eQt\xa3O\xce\x97,\xabd\xdc\xce\xb5q\x1e\x1c7\x07m', crc=1291000084) 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Dispatching sequence number 1 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Decrypted payload: {"dps":{"20":false,"21":"colour","24":"010e03e803e8","25":"10096","26":0,"101":"15500FA1016803E800FA"}} 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Closing connection 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Stopped heartbeat loop 2020-12-16 11:33:19 DEBUG (MainThread) [custom_components.localtuya.pytuya] [ebf...adr] Connection lost: None 2020-12-16 11:33:49 DEBUG (MainThread) [custom_components.localtuya.discovery] Listening to broadcasts on UDP port 6666 and 6667 2020-12-16 11:33:49 DEBUG (MainThread) [custom_components.localtuya.light] [ebf...adr] Adding light.fairy_light with configuration: {'brightness_lower': 247, 'brightness_upper': 1000, 'color_temp_min_kelvin': 2700, 'color_temp_max_kelvin': 6500, 'music_mode': False, 'friendly_name': 'fairy light', 'id': 20, 'platform': 'light'}

ultratoto14 commented 3 years ago

Is there any chance that you also block UDP on this device?

accelle17 commented 3 years ago

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?

ultratoto14 commented 3 years ago

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.

accelle17 commented 3 years ago

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

postlund commented 3 years ago

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?

accelle17 commented 3 years ago

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.