Support protocol version 3.4

[pschucker]

Describe the bug
I tried the example script from the read me. Tuyapi is able to find the device and to connect, but directly disconnects afterwards. It's not possible to keep the connection and listen to data.

Also tried it in Node-Red with package node-red-contrib-tuya-smart-device which uses latest tuyapi. Same error, it constantly reconnects. But at least it receives some data events which results in error logs with messages like Error: CRC mismatch: expected -674619356, was -22843090

Maybe the problem is the protocol version 3.4? Didn't find any information if tuyapi supports 3.4.

debug output:

node test.js
  TuyAPI Finding missing IP undefined or ID bf97ae127518bd821b1mdo +0ms
  TuyAPI Received UDP message. +4s
  TuyAPI UDP data: +1ms
  TuyAPI {
  TuyAPI   payload: {
  TuyAPI     ip: '192.168.0.42',
  TuyAPI     gwId: 'bf97ae127518bd821b1mdo',
  TuyAPI     active: 2,
  TuyAPI     ablilty: 0,
  TuyAPI     encrypt: true,
  TuyAPI     productKey: 'keyyj3fy8x98arty',
  TuyAPI     version: '3.4',
  TuyAPI     token: true
  TuyAPI   },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 35,
  TuyAPI   sequenceN: 0
  TuyAPI } +1ms
  TuyAPI Connecting to 192.168.0.42... +5ms
  TuyAPI Socket connected. +7ms
Connected to device!
  TuyAPI GET Payload: +2ms
  TuyAPI {
  TuyAPI   gwId: 'bf97ae127518bd821b1mdo',
  TuyAPI   devId: 'bf97ae127518bd821b1mdo',
  TuyAPI   t: '1623446698',
  TuyAPI   dpId: [ 18, 19, 20 ],
  TuyAPI   uid: 'bf97ae127518bd821b1mdo'
  TuyAPI } +0ms
  TuyAPI GET Payload: +3ms
  TuyAPI {
  TuyAPI   gwId: 'bf97ae127518bd821b1mdo',
  TuyAPI   devId: 'bf97ae127518bd821b1mdo',
  TuyAPI   t: '1623446698',
  TuyAPI   dps: {},
  TuyAPI   uid: 'bf97ae127518bd821b1mdo'
  TuyAPI } +0ms
  TuyAPI Socket closed: 192.168.0.42 +13ms
  TuyAPI Disconnect +1ms
Disconnected from device.

[codetheweb]

Hmm, that's the first instance of 3.4 that I've seen in the wild... so yes, that's probably the issue.

If you send me a packet dump of when the app is controlling it I can investigate further.

[codetheweb]

After taking a quick look at the provided packet dump, it does indeed appear to be significantly different than 3.3 / 3.1.

I don't currently have plans to add support for 3.4, sorry.

[pschucker]

Thanks for having a look. Can you tell me how you decrypted the messages. Maybe I will try it myself.

[kueblc]

Decrypting messages requires a bit of background in cryptography and lots of trial and error.

No guarantees but I'd be willing to take a look.

[RealIndica]

Do you have a link to the device you bought running the 3.4 protocol? Would like to look into this myself for my C# implementation :)

[pschucker]

It is a SILVERCREST Gateway Zigbee Smart Home from LIDL

[harryzz]

If someone interested I will send linux binary (tyZ3Gw: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0). Seems the protocol for crypt/decrypt messages are the same AES/ECB/NoPadding. May be localKey is modified to be used for crypt/decrypt. There are also token send in registration process encrypted with md5(constant) - like broadcast message.

regards,
Zahari

[harryzz]

Finally I reverse key generation for 3.4.

in 3.4 there are session_key generated runtime:
local_key is well known from devices.json.

SESSION_KEY negotiation

client send frame_id: 0x03
16 bytes random

gw responds with frame_id: 0x04
16 bytes random
32 bytes hmacSHA256(client_random, local_key)

client send frame_id: 0x05
32 bytes hmacSHA256(gw_random, local_key)

all frames are aes_ecb_128 encrypted with local_key and have checksum hmacSHA256(data,local_key)

SESSION_KEY generation

aes_ecb_128( XOR_by_byte(client_random,gw_random) , local_key))

@codetheweb if you decide to implement this and have questions just contact me.

regards,
Zahari

[codetheweb]

@harryzz that's great, thank you for taking the time to figure out the protocol!

I don't have plans to implement it myself as I don't have any 3.4 devices to test with (nor much free time for TuyAPI) but happy to accept PRs that add support. 😄

[harryzz]

Hello
I made some changes for support 3.4 version and pushed code in my repository @github. If someone interested and have time can review and clean code and make PR here. Tested about 2 month with tuya-mqtt(patched to support zigbee gateways). Tested devices: sensors, switches, dimmers, valves.

regards,
Zahari

[Apollon77]

@harryzz Why you do not do a PR ?

Are there more such devices out in the wild in the meantime? Any example purchase link?

[a-lost-shadow]

I just came across another 3.4 device. It's the Minoston Wi-Fi Countdown Timer Switch (MT10W). Amazon Link: https://www.amazon.com/dp/B0B3WN622J?th=1

  TuyAPI Received UDP message. +2s
  TuyAPI UDP data: +1ms`
  TuyAPI {
  TuyAPI   payload: {
  TuyAPI     ip: '192.168.xxx.yyy',
  TuyAPI     gwId: 'eb261b9786xxxxxxxxxxxx',
  TuyAPI     active: 2,
  TuyAPI     ablilty: 0,
  TuyAPI     encrypt: true,
  TuyAPI     productKey: 'ae0y7quogjcnzery',
  TuyAPI     version: '3.4',
  TuyAPI     token: true,
  TuyAPI     wf_cfg: true
  TuyAPI   },
  TuyAPI   leftover: false,
  TuyAPI   commandByte: 35,
  TuyAPI   sequenceN: 0
  TuyAPI } +0ms

I'm not having luck with the code in harryzz`s repo, but that could be user error. I haven't done much with node.js before.

[Monacoslo]

Hello I made some changes for support 3.4 version and pushed code in my repository @github. If someone interested and have time can review and clean code and make PR here. Tested about 2 month with tuya-mqtt(patched to support zigbee gateways). Tested devices: sensors, switches, dimmers, valves.

regards, Zahari

Do you have fork of localtuya that supports 3.4?

[pmneo]

One more device with Protocol 3.4:

https://nous.technology/product/nous-smart-wi-fi-socket-a1/de.html

{
    "payload": {
        "ip": "192.168.0.189",
        "gwId": "bf54bb9c187c1552b4hd2a",
        "active": 2,
        "ablilty": 0,
        "encrypt": true,
        "productKey": "keyjup78v54myhan",
        "version": "3.4",
        "token": true,
        "wf_cfg": true
    },
    "leftover": false,
    "commandByte": 35,
    "sequenceN": 0
}

[Apollon77]

@codetheweb I will try to take the changes from @harryzz and somehow test them to bring in a PR ... But feels that it is not all.

They also send new UDP package with commandByte 35 ... will also add that. But might take some time

[Apollon77]

PS: If someone is willing to sende me such a device please contact me at [email protected]. That could simplify things a lot

[Apollon77]

I should get a device by monday thanks to @Domi920

[Apollon77]

So all friends of the 3.4 protocol ... I want to give it a shot to implement it.

Please see #606 and test it and provide Feedback please in the PR.
I hope that I can also verify stuff in some days

[Apollon77]

@harryzz is it stable on your side? I have one using using the fork where the device starts acting strange after some time ... Could it be tha the session needs to be refreshed after a certain time?

[harryzz]

I can't test now because my 3.4 device broke months ago.

[Apollon77]

But was it running with your code base for some time or had it also issues? If it was running also "long connected"?

[Apollon77]

(PS: In fact also in the pythong libs where 3.4 is supported there is no "timed reconnect or session refresh" that I noticed ... )