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

Connection problem -> Scan finds but does not connect #319

Closed Saimond closed 1 year ago

Saimond commented 1 year ago

Hello;

I have a device, and I'm having a problem connecting to it...

There are moments that everything works out, but other moments that don't connect..

OBS:

Follow image with test.. Tuya_3_4

System:

Router:

New Tests, based on othres post....

File Python:

import tinytuya

tinytuya.set_debug(True)

d = tinytuya.OutletDevice(
    dev_id='ebc.....ajs',
    address='192...4',
    local_key='06....29', 
    version=3.4)

print(d)

print(" > Fetch Status < ")
data = d.status()
print(data)

Result:

DEBUG:TinyTuya [1.12.2]

OutletDevice( 'ebc.....ajs', address='192...4', local_key='06....29', dev_type='default', connection_timeout=5, version=3.4, persist=False, cid=None, parent=None, children={} )
 > Fetch Status <
DEBUG:status() entry (dev_type is default)
DEBUG:final payload_dict for 'ebc.....ajs' ('v3.4'/'default'): {1: {'command': {'gwId': '', 'devId': '', 'uid': '', 't': ''}}, 7: {'command': {'protocol': 5, 't': 'int', 'data': 
{}}, 'command_override': 13}, 8: {'command': {'gwId': '', 'devId': ''}}, 9: {'command': {'gwId': '', 'devId': ''}}, 10: {'command': {}, 'command_override': 16}, 13: {'command': {'protocol': 5, 't': 'int', 'data': {}}}, 16: {'command': {}}, 18: {'command': {'dpId': [18, 19, 20]}}, 64: {'command': {'reqType': '', 'data': {}}}}
DEBUG:building command 10 payload=b'{}'
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'000055aa0000000100000003000000449d284eaa335439142a8244c892fedb89f1999684df290bc9e17d34805794286137b2705b6a2ec91b7ef2646d5be7eb0199d213352b593c1122762b72dd4d5cbb0000aa55'
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None), fetch new one - 1 retries remaining
DEBUG:received null payload (None) but out of recv retries, giving up
DEBUG:session key negotiation failed on step 1
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'000055aa0000000200000003000000449d284eaa335439142a8244c892fedb89f1999684df290bc9e17d348057942861150de1a49448d2cd93023ae620d41c1717a697f7a3997e9b948e617e11adcf350000aa55'
DEBUG:_recv_all(): no data? b''
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None), fetch new one - 1 retries remaining
DEBUG:_recv_all(): no data? b''
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None) but out of recv retries, giving up
DEBUG:session key negotiation failed on step 1
DEBUG:sending payload quick
DEBUG:final payload: b'0123456789abcdef'
DEBUG:payload encrypted=b'000055aa0000000300000003000000449d284eaa335439142a8244c892fedb89f1999684df290bc9e17d348057942861d389336b2f540c28e44c05dd109af7e3e807ad0e32d8f53ec641c43f5c0dc1a00000aa55'
DEBUG:_recv_all(): no data? b''
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None), fetch new one - 1 retries remaining
DEBUG:_recv_all(): no data? b''
DEBUG:_recv_all(): no data? b''
DEBUG:received null payload (None) but out of recv retries, giving up
DEBUG:session key negotiation failed on step 1

So as not to have any doubts, I went to the Tuya website again to confirm the Key...

{
  "result": {
    "active_time": 1678295795,
    "category": "tdq",
    "category_name": "Breaker",
    "create_time": 1676221694,
    "gateway_id": "",
    "icon": "smart/icon/ay1562830083757AoBrF/aeb390315391a67810556b3a5343310b.jpg",
    "id": "ebc.....ajs",
    "ip": "138.186.144.108",
    "lat": "-27.3907",
    "local_key": "06....29",
    "lon": "-49.8261",
    "model": "MYK",
    "name": "Bomba",
    "online": true,
    "owner_id": "101315101",
    "product_id": "gdknjvdpiwoq6smx",
    "product_name": "Smart Switch Module",
    "sub": false,
    "time_zone": "-03:00",
    "update_time": 1679844144,
    "uuid": "b5571f510ed2709f"
  },
  "success": true,
  "t": 1680729175854,
  "tid": "a248dd36d3f611edad308aa96389a5bf"
}

Error in Debug => DEBUG:session key negotiation failed on step 1

Probably, if I reconfigure the device, register the account again, it should fix the problem...

But if there's another way...

jasonacox commented 1 year ago

This is odd:

image

Do you see the device in the devcies.json file that the wizard downloaded? It isn't matching the device ID to the record that it pulled (notice "Unknown device" and missing local key).

Saimond commented 1 year ago

This is odd:

image

Do you see the device in the devcies.json file that the wizard downloaded? It isn't matching the device ID to the record that it pulled (notice "Unknown device" and missing local key).

Hello @jasonacox; First of all thanks for the module, very good.

I usually go to Tuya's website, get the device data, ID and Key.. I set the MAC to Static IP... And I put this information in Python... In the photo, I did the python scan without having done the wizard before.. But, in the other applications, I never used the scan or wizard...

But, I believe it must be a failure with Tuya... because in the Scan it finds the device, but in the program (d.status()), it indicates a Key failure..

Thus, I believe that the failure would not have a solution here..

I will proceed with the following solution:

After that, I'll let it run for 1 day, and if you don't have problems, I'll bring the information here.

uzlonewolf commented 1 year ago

DEBUG:session key negotiation failed on step 1

This usually means either a) the local key is wrong or b) the device needs to be rebooted.

I will proceed with the following solution:

Yes, that looks like a good plan.

Saimond commented 1 year ago

Hello... I did the reset, registered the device again, and used the following code to monitor:

import tinytuya

# Debug removed from Runtime
#tinytuya.set_debug(True)

d = tinytuya.OutletDevice('*** ID ***','*** Static IP ***','*** Key ***')
d.set_version(3.4)
d.set_socketPersistent(True)

payload = d.generate_payload(tinytuya.DP_QUERY)
d.send(payload)

while(True):
    data = d.receive()
    if type(data) is dict:
        print(data)
    payload = d.generate_payload(tinytuya.HEART_BEAT)
    d.send(payload)

I put the program to run the: 2023-04-06T05:17:15.189Z (UTC)

But, around 11:54:30 (UTC) switched to True and 12:26:30 (UTC) switched to False

Here's a print of Grafana comparing the Python registry with power monitoring: Tuya_Grafana

@uzlonewolf

This usually means either a) the local key is wrong or b) the device needs to be rebooted.

a) It's ok, for initially it worked... b) why after a period, need to restart the device?

Saimond commented 1 year ago

Hello;

After another reset, adding again to the account, the same situation happened, it worked for a period and then there was a problem...

I restarted the device, it worked for a while, stopped again...

so I left it off for about 10 minutes, turned it on and after that, for now it's working normally, it's been working for about 3 days

jasonacox commented 1 year ago

We occasionally see devices like this. I had one (requires a restart every few days) which I replaced and the rest (I have 27 devices) work fine. I don't know what causes them to be defective. They are rare but they are out there.

I wonder if some of them have ARP issues where they no longer respond with their MAC address for ARP requests. You could see if your host has a map for the device by doing arp -a.

Saimond commented 1 year ago

I also have 17 who never had any problems, but this one after these procedures, it's working... I don't know for how many days, but, so far, it's going well.

Well, the point is that after re-registering the device a few times and turning it back on a few times, it is now working fine (more than 7 days without any problems).

Thanks.