search

jasonacox / tinytuya

Python API for Tuya WiFi smart devices using a direct local area network (LAN) connection or the cloud (TuyaCloud API).
MIT License
923 stars 165 forks source link

Timeout Waiting for Device from RPi but not from another Ubuntu device #301

Closed OToussaint closed 1 year ago

OToussaint commented 1 year ago

Hello,

I'm facing a weird beaviour and I'm pretty sure that I missed something. Running the command python -m tinytuya scan on my Ubuntu machine is fine (but the machine is not up 24/7)

olivier@olivier-ubuntu:~$ python3 -m tinytuya scan

TinyTuya (Tuya device scanner) [1.12.0]

[Loaded devices.json - 1 devices]

Scanning on UDP ports 6666 and 6667 and 7000 for devices for 18 seconds...

Frigo CR 328 AZD   Product ID = keyjup78v54myhan  [Valid Broadcast]:
    Address = 192.168.0.44   Device ID = ab3961c448d2979e55sean (len:22)  Local Key = b7bd599d6dbbfa2f  Version = 3.3  Type = default, MAC = fc:67:1f:cb:12:58
    Status: {'1': True, '9': 0, '17': 4, '18': 289, '19': 653, '20': 2362, '21': 1, '22': 551, '23': 25500, '24': 14219, '25': 2930, '26': 0, '38': 'on', '39': False, '40': 'relay', '41': False, '42': '', '43': '', '44': ''}
Scan completed in 18.0572 seconds                  

Scan Complete!  Found 1 devices.
Broadcasted: 1
Versions: 3.3: 1

>> Saving device snapshot data to snapshot.json

Running the same from my RPi (which is up 24/7), it fails (tinytuya) pi@hassbian:/etc/tinytuya $ python -m tinytuya scan

TinyTuya (Tuya device scanner) [1.12.0]

[Loaded devices.json - 1 devices]

Scanning on UDP ports 6666 and 6667 and 7000 for devices for 18 seconds...

Frigo CR 328 AZD   Product ID = keyjup78v54myhan  [Valid Broadcast]:
    Address = 192.168.0.44   Device ID = ab3961c448d2979e55sean (len:22)  Local Key = b7bd599d6dbbfa2f  Version = 3.3  Type = default, MAC = fc:67:1f:cb:12:58
    Polling 192.168.0.44 Failed: No response
Scan completed in 18.0742 seconds

Scan Complete!  Found 1 devices.
Broadcasted: 1
Versions: 3.3: 1

>> Saving device snapshot data to snapshot.json

What I already did:

  1. Look if ports are not in use on the RPi.
  2. Tuya device is reachable 
    (tinytuya) pi@hassbian:/etc/tinytuya $ ping 192.168.0.44
PING 192.168.0.44 (192.168.0.44) 56(84) bytes of data.
64 bytes from 192.168.0.44: icmp_seq=1 ttl=255 time=80.2 ms
From 192.168.0.100 icmp_seq=2 Redirect Host(New nexthop: 192.168.0.44)
64 bytes from 192.168.0.44: icmp_seq=2 ttl=255 time=122 ms
64 bytes from 192.168.0.44: icmp_seq=3 ttl=255 time=144 ms
64 bytes from 192.168.0.44: icmp_seq=4 ttl=255 time=37.9 ms
64 bytes from 192.168.0.44: icmp_seq=6 ttl=255 time=61.1 ms
64 bytes from 192.168.0.44: icmp_seq=7 ttl=255 time=98.8 ms
64 bytes from 192.168.0.44: icmp_seq=8 ttl=255 time=119 ms
64 bytes from 192.168.0.44: icmp_seq=9 ttl=255 time=128 ms
^C
--- 192.168.0.44 ping statistics ---
9 packets transmitted, 8 received, +1 errors, 11.1111% packet loss, time 8040ms
rtt min/avg/max/mdev = 37.892/98.930/144.054/34.180 ms
  3. Tuya device is answering on port 6668 
    
(tinytuya) pi@hassbian:/etc/tinytuya $ telnet 192.168.0.44 6668
Trying 192.168.0.44...
Connected to 192.168.0.44.
Escape character is '^]'.

Connection closed by foreign host.


I'm running out of idea :'(

Please help

P.S.: Trying in python directly

(tinytuya) pi@hassbian:/etc/tinytuya $ python Python 3.11.2 (main, Mar 4 2023, 12:59:45) [GCC 10.2.1 20210110] on linux Type "help", "copyright", "credits" or "license" for more information.

import tinytuya d = tinytuya.OutletDevice('ab3961c448d2979e55sean','192.168.0.44','b7bd599d6dbbfa2f') d.set_version(3.3) print( d.status() ) {'Error': 'Timeout Waiting for Device', 'Err': '902', 'Payload': 'Check device key or version'}

uzlonewolf commented 1 year ago

This feels to me like a network issue, especially with the From 192.168.0.100 icmp_seq=2 Redirect Host(New nexthop: 192.168.0.44) and 9 packets transmitted, 8 received, +1 errors, 11.1111% packet loss. Is the RPi on the same network as the device? Is there a firewall in there somewhere?

OToussaint commented 1 year ago

Yes, the 2 devices are in the same network, there is no firewall in between. The reason why From 192.168.0.100 icmp_seq=2 Redirect Host(New nexthop: 192.168.0.44) is because the RPi is hosting Pi-Hole and it was looping to itself, so I added a route especially for the tuya device, maybe it is wrong, and it is the cause of the issue (192.168.0.100 is my gateway, my internet box)

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.100   0.0.0.0         UG    600    0        0 wlan0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0
192.168.0.44    192.168.0.100   255.255.255.255 UGH   0      0        0 wlan0

As a consequence, there is always 1 packet drop, it is the one redirecting to 192.168.0.100. Without the route, I was not even able to ping the device. All packets were dropped.

uzlonewolf commented 1 year ago

If it really is on the same network then it should not be going to/through a gateway. ip route add 192.168.0.44/32 dev wlan0 would be the way to tell it it's directly attached, however that feels like a band-aid; the better question is: why is it looping? AFAIK Pi-hole is not a transparent firewall/proxy, so how/why are packets getting looped back to it?

OToussaint commented 1 year ago

Ok, I removed the route. It was still working and tinytuya was working too, until it failed again. But I think I found the reason, the tuya plug is advertising itself with the name of my wlan interface, and not the name in the Smart Life App weirdly enough. My Ubuntu is not using wifi, only a lan interface.

arp | grep fc:67:1f:cb:12:58
wlan0.lan                ether   fc:67:1f:cb:12:58   C                     wlan0

I edited the /etc/hosts file and added

192.168.0.44 ab3961c448d2979e55sean

And it is working now.

OToussaint commented 1 year ago

And it failed again. The plug is back in my arp table as wlan0.lan and ping is not working. Again.

nslookup 192.168.0.44
44.0.168.192.in-addr.arpa       name = wlan0.lan.

I can ping any other devices

pi@hassbian:/usr/bin $ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=51.6 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=54.6 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=8.64 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=32.5 ms
^C
--- 192.168.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 8.642/36.814/54.578/18.343 ms

But not the tuya plug

pi@hassbian:/usr/bin $ ping 192.168.0.44
PING 192.168.0.44 (192.168.0.44) 56(84) bytes of data.
^C
--- 192.168.0.44 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8339ms
OToussaint commented 1 year ago

Running a tshark while ping is like that

pi@hassbian:/home/pi $ sudo tshark -i wlan0 -f "host 192.168.0.44" -f "icmp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
    1 0.000000000 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=6/1536, ttl=64
    2 1.040043499 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=7/1792, ttl=64
    3 2.080053454 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=8/2048, ttl=64
    4 3.120040125 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=9/2304, ttl=64
    5 4.160030649 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=10/2560, ttl=64
    6 5.200063827 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=11/2816, ttl=64
    7 6.240062420 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=12/3072, ttl=64
    8 7.280055125 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=13/3328, ttl=64
    9 8.320066109 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=14/3584, ttl=64
   10 9.360099540 192.168.0.26 → 192.168.0.44 ICMP 98 Echo (ping) request  id=0x1a61, seq=15/3840, ttl=64

Request, no reply. There is absolutely no firewall, from my ubuntu, the ping is no issue

olivier@olivier-ubuntu:~$ ping 192.168.0.44
PING 192.168.0.44 (192.168.0.44) 56(84) bytes of data.
64 octets de 192.168.0.44 : icmp_seq=1 ttl=255 temps=42.5 ms
64 octets de 192.168.0.44 : icmp_seq=2 ttl=255 temps=261 ms
64 octets de 192.168.0.44 : icmp_seq=3 ttl=255 temps=98.1 ms
64 octets de 192.168.0.44 : icmp_seq=4 ttl=255 temps=99.5 ms
64 octets de 192.168.0.44 : icmp_seq=5 ttl=255 temps=25.6 ms
64 octets de 192.168.0.44 : icmp_seq=6 ttl=255 temps=33.4 ms
64 octets de 192.168.0.44 : icmp_seq=7 ttl=255 temps=75.9 ms
^C
--- statistiques ping 192.168.0.44 ---
7 paquets transmis, 7 reçus, 0 % paquets perdus, temps 6011 ms
rtt min/moy/max/mdev = 25,610/90,896/261,282/74,920 ms
jasonacox commented 1 year ago

Thanks for sharing all these details @OToussaint . I have several RPi's of different hardware versions and OS, and have never seen this issue. You could try to disable PiHole and see if that is what is poisoning your arp:

# Disable Pi-hole for 30 seconds
pihole disable 10m

# Or more drastic
sudo systemctl stop pihole-FTL
sudo systemctl disable pihole-FTL

I would also try to hardwire to the network (if not already) to see if that makes a difference. If not, I would just re-image the Pi (new SD) and see if it is a hardware issue vs config issue.

OToussaint commented 1 year ago

No, no change, not even with a brand new SD Card. My work-around, working for 14 hours now, is awful:

I'd like a real solution but I'm hopeless.

P.S.: I realise that it is not a tinytuya issue anymore. Sorry about that.

jasonacox commented 1 year ago

Hi @OToussaint , I can understand the frustration. It still seems like this is an issue with the RPi configuration if your ubuntu host works. What OS are you using on your RPi? For my working units, I'm using Debian version: 11 (bullseye) here: https://www.raspberrypi.com/software/operating-systems/

OToussaint commented 1 year ago

The same, Debian 11 (bullseye)

uname -a

Linux hassbian 5.15.84-v7+ #1613 SMP Thu Jan 5 11:59:48 GMT 2023 armv7l GNU/Linux

pi@hassbian:~ $ hostnamectl


   Static hostname: hassbian
         Icon name: computer
        Machine ID: 880c5857b62e440f9bf62c65361b7f13
           Boot ID: 8c0e3d95002d4298adb951eea80cad2d
  Operating System: Raspbian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.15.84-v7+
      Architecture: arm

For now, my terrible workaround is working ... image

jasonacox commented 1 year ago

Well, at least, congrats on getting the workaround to work! Unfortunately, I have no ideas or other suggestions for you.

OToussaint commented 1 year ago

Issue with the workaround is that if ping is skipped, I might go back to step 1: recreate the route, and everything after. In theory, I could do a script with 

ip route add 192.168.0.44 via 192.168.0.100 dev wlan0
ping -c 10 192.168.0.44
ip route del 192.168.0.44 via 192.168.0.100 dev wlan0
ping -c 10 192.168.0.44

cron with root every minute but seems like overkill.

OToussaint commented 1 year ago

Let me close that issue here, I'll try to find help in the appropriate forum. Thank you for your help.

jasonacox commented 1 year ago

Good luck, @OToussaint ! It will probably be a simple thing on your network or setup that will be easy to fix once you finally sort it. If you find it, please report back in case someone is following your steps. 🙏

OToussaint commented 1 year ago

Posted on SuperUser for a few days but everyone is struggling as much as I do ...