TinyTuya based devices stop responding after years of working.

[yuuzhan]

I believe this might be the same issue as #556 but I dont want to hijack their thread

History: I have about 20 devices, mostly Feit style light switches. When I set them up years ago, tinytuya was working with them, and then I migrated to using Home assistant Local Tuya to control them. No major issues for years.

Current: Some time last week a few of my devices stopped responding and I didnt think much about it - as that happens from time to time and usually resolves itself. Instead of resolving this got worse and worse, eventually getting to the point where no devices were responding. I tried a bunch of things but nothing seemed to get the devices back up and running. Unfortunatly the logs for LocalTuya are quite minimal, so I disabled that and fired up TinyTuya to see if I can debug the problem better.

I can run the wizard without any issues, it seems to download the details for all the devices, however when doing a local polling nothing seems to be working (It also cant seem to get an IP address for most of the devices). Even when I manually edit the devices.json file to put in the device IP Address I get a No Response issue. The two devices that automatically return IPs are a tuya switch (like a white box, not a light switch) and a zigbee hub.

I have not made any changes to the network that I know of... I have tried rebooting the network, and the PC that is doing the polling with no luck.

Here is the debug log: https://pastebin.com/JdYzWSzb

Any thoughts?

[Poil]

Hi,

Strange, I had the same problem you describe but since the major update of Tuya Smart last week, my devices are now always working locally, and more strange is that I didn't need to unplug them to reset them and have them working.

I didn't see any firmware update on my device but perhaps I miss some because I'm in automatic update.

Regards

[yuuzhan]

Hmm, I have auto update turned off on my devices - but going in to manually check on them I can see that it says there are no updates available.

Main Module Version: v3.1.4
MCU Module: v1.1.12

[Poil]

My problematic devices were

• 炬为电能宝-温控仪(S1TW) / Version = 3.4
  • Main Module Version: v2.1.6
  • MCU Module: v1.1.0
• ANTELA Smart Plug FR / Socket / Version = 3.3
  • Main Module Version: v1.1.8
  • MCU Module: v1.1.8

All other Socket were working without any issue

It doesn't look like I had firmware update, so I think they change something on "Tuya Smart App" that were locking my devices on LAN (via cloud API it was always working)

I just saw my IOT Core license on Tuya Cloud expired in september, just to be sure I have renewed it, w&s

[yuuzhan]

Hmm, My IOT Core License is good until January. I havent seen any notice about a Tuya Smart change last week, do you have a news blast about that?

Is there any settings in the tuya smart app other then the basic setup?

[Poil]

Tuya Smart App has been updated the 8 November (v6) on Android App Store

no other settings :/

[uzlonewolf]

Have you tried rebooting the devices? Do they respond at all to the Smart Life app?

[yuuzhan]

I have not tried rebooting the devices yet, as they are light switches in the wall without a power button to see. I would have to kill power to the whole house to reboot them lol.

They do respond to smart life app as well as the google home integration.

[uzlonewolf]

Well, at least that makes it easy to reboot them all at the same time 🤣 If they're v3.4 devices, well, I'd say a few years without needing a reboot is really good, I have a couple that need to be rebooted every few days/weeks.

[Poil]

This morning I have some v3.3 devices that were working for years without any issue that stop to work again on LAN.
In Smart App, they are responding (monitor & control) but the network check give an error

Edit, this morning more and more devices become unreachable ... I kill Smart App to see if it's better or not

[yuuzhan]

I suspect mine were 3.3 devices as well, but I am not fully sure.

[yuuzhan]

I have been playing around with the python scripts, seeing if i can gleam any more information. So far this is what I found:

set_status() result {'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

Edit:

Here is some debug info:

DEBUG:TinyTuya [1.15.1]

DEBUG:Python 3.12.3 (main, Nov  6 2024, 18:32:19) [GCC 13.2.0] on linux
DEBUG:Using pyca/cryptography 43.0.3 for crypto, GCM is supported
DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for 'XXXXIDXXXXX' ('v3.3'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'devId': '', 'uid': '', 't': ''}}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 13: {'command': {'devId': '', 'uid': '', 't': ''}}, 16: {'command': {'devId': '', 'uid': '', 't': ''}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{"gwId":"XXXXIDXXXXX","devId":"XXXXIDXXXXX","uid":"XXXXIDXXXXX","t":"1732158544"}'
DEBUG:sending payload
DEBUG:payload encrypted=b'XXXXpayloadXXXXX'
DEBUG:Network connection error in _send_receive() - retry 1/5
[...]
ConnectionResetError: [Errno 104] Connection reset by peer
DEBUG:sending payload
DEBUG:payload encrypted=b'XXXXpayloadXXXXX'
DEBUG:Network connection error in _send_receive() - retry 6/5
Traceback (most recent call last):
  File "/home/jason/tinytuya/venv/lib/python3.12/site-packages/tinytuya/core.py", line 1149, in _send_receive
    rmsg = self._receive()
           ^^^^^^^^^^^^^^^
  File "/home/jason/tinytuya/venv/lib/python3.12/site-packages/tinytuya/core.py", line 1037, in _receive
    data = self._recv_all( min_len )
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jason/tinytuya/venv/lib/python3.12/site-packages/tinytuya/core.py", line 1011, in _recv_all
    newdata = self.socket.recv(length)
              ^^^^^^^^^^^^^^^^^^^^^^^^
ConnectionResetError: [Errno 104] Connection reset by peer
DEBUG:Exceeded tinytuya retry limit (5)
DEBUG:Unable to connect to device
DEBUG:ERROR Network Error: Unable to Connect - 901 - payload: null
DEBUG:set_status received data={'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

[yuuzhan]

I had to reset some breakers the other day to install a new light switch, so figured while I was there I would turn the whole house "off and on" again :P. No luck unfortunately!

Any other suggestions?

[jasonacox]

Are you getting the same debug trace?

[yuuzhan]

The debug trace seems to be the same yes.

DEBUG:TinyTuya [1.15.1]

DEBUG:Python 3.12.3 (main, Nov  6 2024, 18:32:19) [GCC 13.2.0] on linux
DEBUG:Using pyca/cryptography 43.0.3 for crypto, GCM is supported
DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for 'XXXXIDXXXXX' ('v3.3'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'devId': '', 'uid': '', 't': ''}}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 13: {'command': {'devId': '', 'uid': '', 't': ''}}, 16: {'command': {'devId': '', 'uid': '', 't': ''}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{"gwId":"XXXXIDXXXXX","devId":"XXXXIDXXXXX","uid":"XXXXIDXXXXX","t":"1733406491"}'
DEBUG:sending payload
DEBUG:payload encrypted=b'000055aa000000010000000a00000078ac8df1ab2de7bde380f65304ea03acaa42b45f456324cc7def670777ea21e2748be1b6ebafd0f77ebd09a543deda6f9bea5878c615a5d7534528f6e00e4569a26319f27a34cbfe1b873e349c4a5fbfc5cb26f35db0b4cf5d477931169661129047d6bebe373638ffd8971d7eb57d5b8593db94c40000aa55'
DEBUG:Network connection error in _send_receive() - retry 1/5
Traceback (most recent call last):
  File "/home/jason/tinytuya/venv/lib/python3.12/site-packages/tinytuya/core.py", line 1149, in _send_receive
    rmsg = self._receive()
           ^^^^^^^^^^^^^^^
  File "/home/jason/tinytuya/venv/lib/python3.12/site-packages/tinytuya/core.py", line 1037, in _receive
    data = self._recv_all( min_len )
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jason/tinytuya/venv/lib/python3.12/site-packages/tinytuya/core.py", line 1011, in _recv_all
    newdata = self.socket.recv(length)
              ^^^^^^^^^^^^^^^^^^^^^^^^
ConnectionResetError: [Errno 104] Connection reset by peer
...
DEBUG:Exceeded tinytuya retry limit (5)
DEBUG:Unable to connect to device
DEBUG:ERROR Network Error: Unable to Connect - 901 - payload: null
DEBUG:status() received data={'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}
d.status() result {'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

The Wizard gave the same results as before as well (I can upload a new debug log if you want).

I had been peeking around in the code, but I dont know enough python to change the code and run the changed code to attempt to extract more information when the code fails out with a generic error catch:
core.py line 1202

            except Exception as err:
                # likely network or connection error
                do_send = True
                retries += 1
                # toss old socket and get new one
                self._check_socket_close(True)
                log.debug(
                    "Network connection error in _send_receive() - retry %s/%s",
                    retries, self.socketRetryLimit, exc_info=True
                )
                # if we exceed the limit of retries then lets get out of here
                if retries > self.socketRetryLimit:
                    log.debug(
                        "Exceeded tinytuya retry limit (%s)",
                        self.socketRetryLimit
                    )
                    log.debug("Unable to connect to device ")
                    # timeout reached - return error
                    return error_json(ERR_CONNECT)
                # wait a bit before retrying
                time.sleep(0.1)

I have more experience with C# where you might be able to write out err.Message to get a bit more information about the type of error that is being thrown?

EDIT: This is the PY script I am using:

import sys
sys.path.append('/tinytuya/venv/bin')
import tinytuya
import json

tinytuya.set_debug(True)

# Connect to Device
d = tinytuya.OutletDevice(
    dev_id='xxxxxxx', 
    address='192.168.x.x',  # Or set to 'Auto' to auto-discover IP address
    local_key='Key Includes upper, lower, dash (-), pound (#) and dot (.) characters.  It is 16 characters long',  
    version=3.3)
# Get Status
data = d.status() 
print('d.status() result %r' % data)

[jasonacox]

A ConnectionResetError typically occurs when the remote server or peer unexpectedly closes the connection. This can be due to various reasons such as:

1. Server overload
2. Network issues or packet loss
3. Firewall or antivirus software blocking the connection

For the Tuya device, have you tried running from a different host to eliminate a host issue?

[yuuzhan]

I tried to run the scan from a docker image on my windows machine - it didnt work but it also was on a different subnet due to how the docker was setup and I am not fully sure how to change that in windows docker!

That said, I did some network sniffing on the router with tcpdump while I ran a wizard and got this the first time I did it, but never again when I tried to repeat it (So I think it was just a coincidence / luck I saw this)

21:53:06.520659 EDSA 0xdada, Forward port 0.2, VLAN 4095u, IP ZigbeeSwitch.lan.39840 > LightSwitchAlcove.lan.6668: Flags [P.], seq 3539412463:3539412487, ack 293351800, win 14600, length 24

The zibgee switch I have shouldnt be talking to the LightSwitches (which are wifi)

I didnt see any other traffic to the tuya devices, except one device gave this:

22:12:28.950665 EDSA 0xdada, Forward port 1.0, VLAN 4095u, ARP, Reply LightSwitchBsmtPlayLeft.lan is-at 58:6d:8f:fd:f0:f4 (oui Unknown), length 28

I also found this one:
21:53:06.649301 EDSA 0xdada, Forward port 0.2, VLAN 4095u, IP ZigbeeSwitch.lan.52297 > 255.255.255.255.7000: rx type 232 (87)

Is the zibee switch firing off its own "whos there" call?

[Poil]

Yesterday I changed my router and also changed my LAN CIDR, what is my surprise the devices that was offline on LAN become available again without unplugging them. So the networking is not totally stuck. For me the problem is the Android App that stuck them randomly. I'm looking for an alternative android app to switch on/off some devices and nothing more. Perhaps I will write a Django app.

[yuuzhan]

What router software are you running, openwrt? if so what settings in there did you change?

[uzlonewolf]

My suspicion is the devices stop responding to ARP requests that do not come from the gateway, but I've been unable to verify this as none of my 50+ device stop responding like this. I do use Unifi APs with the Proxy ARP ("Remaps ARP table for station") option turned on.

[uzlonewolf]

Is the zibee switch firing off its own "whos there" call?

Yes, if it's a hub device (has both WiFi and Zigbee) it'll try and connect to all your other devices so it can manage scenes.
"Connection reset" sure sounds like multiple apps/hubs are fighting for control over the device.

[uzlonewolf]

An option for scanning within docker (or from any other routed network for that matter) is the force scan option. python3 -m tinytuya scan -force 192.168.0.0/24

[yuuzhan]

oo, Making progress @uzlonewolf ! I am not sure what that tells me - but with the force and defining the subnet I can see more information

Running from inside a docker on my laptop I am able to ping the devices it seems:

# python3 -m tinytuya scan -force 192.168.0.0/24

[Loaded devices.json - 43 devices]

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

    Option: Network force scanning requested.


    Running Scan...
New Broadcast from App at 172.17.0.2 - {'from': 'app', 'ip': '172.17.0.2'}
  Starting Scan for network 192.168.0.0/24              
Scan completed in 26.9862 seconds                                
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.100   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.116   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.117   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.134   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.126   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.164   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.166   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.167   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.169   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.170   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.195   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.178   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.190   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.206   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.207   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.208   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.215   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.201   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.193   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.241   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC = 
                    
Scan Complete!  Found 20 devices.
Broadcasted: 0
Force-Scanned: 20  - Matched GWID: 0 Matched Key: 0 Unmatched: 20
Versions: 3.4: 20
Unknown Devices: 20

So I went back to my host machine to run the normal scan:

$ ./venv/bin/python3.12 -m tinytuya scan

TinyTuya (Tuya device scanner) [1.15.1]

[Loaded devices.json - 30 devices]

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

New Broadcast from App at 192.168.0.205 - {'from': 'app', 'ip': '192.168.0.205'}
under cabinet lights   Product ID = xxxxx [Valid Broadcast]:
    Address = 192.168.0.170   Device ID = xxxxx (len:22)  Local Key = xxxxxx  Version = 3.4  Type = default, MAC = fc:67:1f:e1:fc:b0
    Status: {'20': False, '21': 'white', '22': 1000, '26': 0, '34': False}
ZigBee gateway wired   Product ID = xxxxx  [Valid Broadcast]:
    Address = 192.168.0.134   Device ID = xxxxx (len:22)  Local Key = xxxxx Version = 3.4  Type = default, MAC = fc:67:1f:ef:b3:96
    Polling 192.168.0.134 Failed: No response
Scan completed in 18.0851 seconds

Scan Complete!  Found 2 devices.
Broadcasted: 2
Versions: 3.4: 2

>> Saving device snapshot data to snapshot.json

Then with the Force:

$ ./venv/bin/python3.12 -m tinytuya scan -force 192.168.0.0/24)

[Loaded devices.json - 30 devices]

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

    Option: Network force scanning requested.


    Running Scan...
New Broadcast from App at 192.168.0.205 - {'from': 'app', 'ip': '192.168.0.205'}
under cabinet lights   Product ID = xxxxx [Valid Broadcast]:
    Address = 192.168.0.170   Device ID = xxxx (len:22)  Local Key = xxx  Version = 3.4  Type = default, MAC = fc:67:1f:e1:fc:b0
    Status: {'20': False, '21': 'white', '22': 1000, '26': 0, '34': False}
  Starting Scan for network 192.168.0.0/24
ZigBee gateway wired   Product ID = xxxxxx [Valid Broadcast]:
    Address = 192.168.0.134   Device ID = xxxx (len:22)  Local Key = xxxx Version = 3.4  Type = default, MAC = fc:67:1f:ef:b3:96
    Polling 192.168.0.134 Failed: No response
New Broadcast from App at 192.168.0.134 - {'ip': '192.168.0.134', 'from': 'app'}
Unknown v?? Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.100   Device ID =  (len:0)  Local Key =   Version = ??  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.116   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.117   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.164   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v?? Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.167   Device ID =  (len:0)  Local Key =   Version = ??  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.171   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.190   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.193   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.195   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.201   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.206   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.207   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v3.4 Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.208   Device ID =  (len:0)  Local Key =   Version = 3.4  Type = default, MAC =
Unknown v?? Device   Product ID = ?  [Failed to Force-Scan, FORCED STOP]:
    Address = 192.168.0.241   Device ID =  (len:0)  Local Key =   Version = ??  Type = default, MAC =
Scan completed in 40.1799 seconds

Scan Complete!  Found 16 devices.
Broadcasted: 2
Force-Scanned: 14  - Matched GWID: 0 Matched Key: 0 Unmatched: 14
Force-Scan Errors: Connection Errors: 0 Version Detect Failed: 3
Versions: 0.0: 3, 3.4: 13
Unknown Devices: 14

>> Saving device snapshot data to snapshot.json

If I run it not in the venv, but on the local system where I have it installed - I also get these errors:

Fatal error message

``` DEBUG:Force-Scan Found Device 192.168.0.201 DEBUG:final payload: b'0123456789abcdef' DEBUG:payload encrypted=b'000055aa00000001000000030000004468547ac859cffe5561d50866068d05d1139b4a20221c2027296b8b981065f9515dd9d87f27ce8d9e538abfd9256cc1714a31f11a0d3ee6afa1253ef83c8fccdf0000aa55' Traceback (most recent call last): File "/home/user/.local/bin/tinytuya", line 5, in from tinytuya.__main__ import dummy File "/home/user/.local/share/pipx/venvs/tinytuya/lib/python3.12/site-packages/tinytuya/__main__.py", line 124, in scanner.scan( scantime=args.max_time, color=(not args.nocolor), forcescan=args.force, discover=(not args.no_broadcasts), assume_yes=args.yes ) File "/home/user/.local/share/pipx/venvs/tinytuya/lib/python3.12/site-packages/tinytuya/scanner.py", line 1034, in scan devices(verbose=True, scantime=scantime, color=color, poll=True, forcescan=forcescan, discover=discover, assume_yes=assume_yes) File "/home/user/.local/share/pipx/venvs/tinytuya/lib/python3.12/site-packages/tinytuya/scanner.py", line 1482, in devices all_socks[sock].write_data() File "/home/user/.local/share/pipx/venvs/tinytuya/lib/python3.12/site-packages/tinytuya/scanner.py", line 604, in write_data self.v34_negotiate_sess_key_start() File "/home/user/.local/share/pipx/venvs/tinytuya/lib/python3.12/site-packages/tinytuya/scanner.py", line 388, in v34_negotiate_sess_key_start self.sock.sendall( self.device._encode_message( step1 ) ) ConnectionResetError: [Errno 104] Connection reset by peer ```

Weirdly the devices report as 3.4 version? I thought they were 3.3 or 3.2. When I run a test python on that docker that is working going from version 3.1 to 3.4 (then leaving the version blank) I get this:

d.status() result {'Error': 'Unexpected Payload from Device', 'Err': '904', 'Payload': None}
d.status() result {'Error': 'Unexpected Payload from Device', 'Err': '904', 'Payload': None}
d.status() result {'Error': 'Unexpected Payload from Device', 'Err': '904', 'Payload': None}
d.status() result {'Error': 'Check device key or version', 'Err': '914', 'Payload': None}
d.status() result {'Error': 'Unexpected Payload from Device', 'Err': '904', 'Payload': None}