Open Ilia-SB opened 12 months ago
+1 same problem
Same problem, i have a switch atteched to zigbee sub and it stuck at device.get
@duongvanba Can you please also post a log?
same, refresh() return false, get() never return
$ node index.js
2023-07-15T02:08:42.369Z TuyAPI Finding missing IP undefined or ID 6cf11fd3dbc9ebe325rwin
2023-07-15T02:08:45.079Z TuyAPI Received UDP message.
2023-07-15T02:08:45.093Z TuyAPI UDP data:
2023-07-15T02:08:45.112Z TuyAPI {
payload: {
ip: '192.168.1.51',
gwId: '6cf11fd3dbc9ebe325rwin',
active: 2,
ablilty: 0,
encrypt: true,
productKey: 'keym557nqw3p8p7m',
version: '3.4',
lan_cap: 500,
lan_seq: 8,
lan_ablilty: 1,
token: true,
wf_cfg: true,
clientLink: 3
},
leftover: false,
commandByte: 35,
sequenceN: 0
}
Found: true
2023-07-15T02:08:45.131Z TuyAPI Connecting to 192.168.1.51...
2023-07-15T02:08:45.449Z TuyAPI Socket connected.
2023-07-15T02:08:45.463Z TuyAPI Protocol 3.4: Negotiate Session Key - Send Msg 0x03
2023-07-15T02:08:48.428Z TuyAPI Received data: 000055aa00009f70000000040000006800000000003e496591f756b2114028a0ac76e93c7c86277823a4289953d7ac656240903909605e3a6865c39b78a15136188098759b10f5dffacf626f35d33dee25da2c7ca588bf046a6a03ae85eba5c7a6a45cdbf5a7454fef70648ba8b155abd5607c6d0000aa55
2023-07-15T02:08:48.432Z TuyAPI Parsed:
2023-07-15T02:08:48.437Z TuyAPI {
payload: <Buffer 33 31 34 39 34 35 39 38 64 30 63 63 34 36 32 65 08 2d 08 f8 83 fb 4f 4a 37 cc 7c da 11 df d3 de 76 74 cd 05 be 80 43 25 77 fd d5 b7 59 6e 0e 85>,
leftover: false,
commandByte: 4,
sequenceN: 40816
}
2023-07-15T02:08:48.442Z TuyAPI Protocol 3.4: Local Random Key: 2d745c78b1bf75edb168bb98cfe2afde
2023-07-15T02:08:48.442Z TuyAPI Protocol 3.4: Remote Random Key: 33313439343539386430636334363265
2023-07-15T02:08:48.448Z TuyAPI Protocol 3.4: Session Key: e4bee89f2c4359afc3d2f934eb44566e
2023-07-15T02:08:48.448Z TuyAPI Protocol 3.4: Initialization done
Connected to device!
2023-07-15T02:08:48.454Z TuyAPI GET Payload (refresh):
2023-07-15T02:08:48.457Z TuyAPI {
gwId: '6cf11fd3dbc9ebe325rwin',
devId: '6cf11fd3dbc9ebe325rwin',
t: '1689386928',
dpId: [ 18, 19, 20 ],
uid: '6cf11fd3dbc9ebe325rwin',
cid: '8c5ac80eeeb003cf'
}
2023-07-15T02:08:48.468Z TuyAPI GET Payload:
2023-07-15T02:08:48.472Z TuyAPI {
gwId: '6cf11fd3dbc9ebe325rwin',
devId: '6cf11fd3dbc9ebe325rwin',
t: '1689386928',
dps: {},
uid: '6cf11fd3dbc9ebe325rwin'
}
2023-07-15T02:08:50.162Z TuyAPI Received data: 000055aa00009f710000001200000028000000005377a2f1b0f0f0ad133c606dde78ec439013b4cdf4396e89698d94940423e4e70000aa55
2023-07-15T02:08:50.164Z TuyAPI Parsed:
2023-07-15T02:08:50.165Z TuyAPI { payload: false, leftover: false, commandByte: 18, sequenceN: 40817 }
2023-07-15T02:08:50.165Z TuyAPI Received DP_REFRESH response packet without data - resolve
Refresh ret: false
2023-07-15T02:08:50.170Z TuyAPI GET Payload:
2023-07-15T02:08:50.172Z TuyAPI {
gwId: '6cf11fd3dbc9ebe325rwin',
devId: '6cf11fd3dbc9ebe325rwin',
t: '1689386930',
dps: {},
uid: '6cf11fd3dbc9ebe325rwin',
cid: '8c5ac80eeeb003cf'
}
2023-07-15T02:08:50.175Z TuyAPI Received data: 000055aa00009f7200000010000000580000000006918727b9fbf6fe5ddd84832cdf11bf311ebf418aa341ac8658afa24ce47879179decf79b09442f8d79d32f07ab80848cc30ac6a38e315e3aab263af8c4d0367bfb74effa58636105607635138ce5cc0000aa55
2023-07-15T02:08:50.177Z TuyAPI Parsed:
2023-07-15T02:08:50.180Z TuyAPI {
payload: { dps: { '4': false, '32': 'normal' } },
leftover: false,
commandByte: 16,
sequenceN: 40818
}
2023-07-15T02:08:50.180Z TuyAPI Received DATA packet
2023-07-15T02:08:50.181Z TuyAPI data: 16 : {"dps":{"4":false,"32":"normal"}}
Data from device: { dps: { '4': false, '32': 'normal' } }
2023-07-15T02:08:50.192Z TuyAPI Received data: 000055aa00009f7300000010000000480000000163150f1113dc642e2a39f51333d47aac6c243156259b946411444b1ea7d78fcee32ea4d144b2618fa81b7a79cfbbb5851903aa4e89ff58673106515208d2a74e0000aa55
2023-07-15T02:08:50.194Z TuyAPI Parsed:
2023-07-15T02:08:50.196Z TuyAPI {
payload: <Buffer 6a 73 6f 6e 20 6f 62 6a 20 64 61 74 61 20 75 6e 76 61 6c 69 64>,
leftover: false,
commandByte: 16,
sequenceN: 40819
}
2023-07-15T02:08:50.197Z TuyAPI Received DATA packet
2023-07-15T02:08:50.197Z TuyAPI data: 16 : 6a736f6e206f626a206461746120756e76616c6964
Data from device: <Buffer 6a 73 6f 6e 20 6f 62 6a 20 64 61 74 61 20 75 6e 76 61 6c 69 64>
2023-07-15T02:08:58.475Z TuyAPI Pinging 192.168.1.51
2023-07-15T02:08:58.564Z TuyAPI Received data: 000055aa00009f740000000900000048000000010c8e6b194d5b707497aa534e6e7540b13db39d571fb5ff2c186ecb841f75617bb163f2c47063140c74f0408e59407638c540afb41b95eed207de44c7155e5bd50000aa55
2023-07-15T02:08:58.567Z TuyAPI Parsed:
2023-07-15T02:08:58.569Z TuyAPI {
payload: <Buffer 70 61 72 73 65 20 64 61 74 61 20 65 72 72 6f 72>,
leftover: false,
commandByte: 9,
sequenceN: 40820
}
2023-07-15T02:08:58.569Z TuyAPI Pong from 192.168.1.51
2023-07-15T02:09:02.379Z TuyAPI Disconnect
Disconnected from device.
2023-07-15T02:09:02.386Z TuyAPI Socket closed: 192.168.1.51
Done in 21.56s.
It seems the sequenceN sent out is not matching the one received, something is wrong with the protocol or the sequenceN encoding. so any api call rely on _send() and sequenceN not works. the raw bytes send and received like this:
TuyAPI Sending: 000055aa0000000300000010000000a4c23770e4223ba2a546897a0e0dd287ee4cd3774e9237534ddc97cae4089d62a4da00c5e6924413b25695f4a43055c7ce47833244608ecd1c93b59db6ecaec84325d460382e85d9f59c30970ab1a1b66052bada4a58c7794fd2675f9c7277a579e888676aa02845ee37ebd2ba34d97b69a9785be4e921140d4abe2581e4ab48c5a2061656be8bd912a8884d1f980c61b197e144333a83c3dfc04da768ff82ca960000aa55 +2ms
TuyAPI Received data: 000055aa0000e4f10000001000000058000000008943977cf459d98ad608401892fd26279d5a63165a90662471e21d5cdcbf59f923ad4adb2dcdd22fec837e56a54117710aa7e89853916310ef5202dd7667b07b1a9da99c92123102ad68a1ce5b9509c90000aa55 +198ms
so, for now, my temp workaround is to calculate the sequence difference when the 3.4 handshake done, then use it in _send() for correct response slot key. still no idea why this happens.
I'm working on new version of this hope it work
in simple, the sequenceN sent is not directly related to the one responded. sometimes the device broadcast some message with command type 8, or 64, which also increase the sequence sent from device, but on the other side, the sender side (the tuyapi), still in it's own sequence step, so the sequence diff will change. Then it's hard to predict what the expected response sequence when send a request. we only know what's the newest sequenceN NEWEST_RESP_SEQ we received for now, and how many pending requests PENDING_REQ_NUM which not got response, could we tell the expected sequence is NEWEST_RESP_SEQ+PENDING_REQ_NUM? we can not. it can not cover race cases. then the predict sequence algorithm is no longer reliable. on the other hand, if every time we received a broadcast message (not a response of a request we sent), then we can adjust the predicted response sequence, this may work.
In my experience, the hubs (Zigbee, BLE, IR) do not have their own DPs, and therefore SET/GET to the Hub are not allowed and cause various malfunctions, with rare exceptions. Naturally SET/GET for connected virtual devices are allowed, although often very limited. I believe that in many cases Tuya uses other communication channels (e.g. images from WiFi camera), not implemented in tuyAPI. For more details see notes on gateways.
Hello. I've just started using tuyapi, so please forgive me if this is a known issue. I couldn't find anything related on the web.
Describe the bug Using tuyapi@7.5.2. When trying synchronous usage example on a protocol 3.4 device, device.get() never returns a value, although the data from device is received and parsed successfully. The device is a zigbee hub, but I'm not trying to communicate with subdevices, just with the hub itself. Unfortunately I don't have other devices to test.
To Reproduce Here's the actual script:
Expected behavior The await device.get() call returns, data is printed to console and device disconnects.
Debug Output
The received data is never printed to console, the script just keeps pinging the device forever.
Desktop (please complete the following information):
Additional context Asynchronous usage example works just fine.