TCP packet not decoded #505
Comments
|
Hi @leweafan , Thanks for opening this. Wow, that is a big payload!
That's correct, but only for discovery. Tuya devices announce themselves on the network via UDP broadcasts. TinyTuya listens to those to discover devices. But that isn't related to the issue you are seeing. The debug you have shows TCP traffic which is how TinyTuya and localtuya both communicate with Tuya devices. I notice that in your example, TinyTuya gets a response packet with just one DPS (114) however, localtuya gets a response with everything BUT 114. That means that the device seems to be sending back two different payloads. You will likely need to keep monitoring to get all the DPS payloads (or query it multiple times). You can try this script which will keep monitoring the device and print everything that comes back from it: Lines 10 to 66 in a75324b |
|
Hello @jasonacox! Actually I have tried it cause seen in other issues. All I can catch using this script is DPS of counters (137-144). I've also used tinytuya wizard and got only DP 114. Can I get data from TCP packet using tinytuya? |
I'm not following what you mean. These are all TCP packets. Do you mean running a packet capture? What is this device and can you send a link to it? I may have to try to buy one to help you debug. I suspect it has something to do with the seqno (sequence number). It looks like Tinytuya is only picking up seqno = 0 and localtuya is only picking up seqno = 1 and avoiding seqno = 0. Do you know the function/meaning of DPS 114? |
Yes I would like to get device DPs (reads state) and seems its all in TCP packet only.
I suppose it's not available worldwide. It's tuya code "sfkzq" - "Water valve controller". It supports 50+ wireless sensors that's is why TCP packet so big IMHO.
Do you know where I can read more about Tuya API sequence number?
I have created device config using localtuya and want to share it with community but seems that localtuya do not use yaml configs anymore and switched to config flow (UI) as I understood. That's why I decided to create config for tuya-local project but seems that it's using tinytuya and can't discover and manage my device. |
|
Try this modified version of the above script (don't forget to replace DEVICEKEY with your key): key = 'DEVICEKEY'
######### Don't change anything below here ##########
import tinytuya
import time
d = tinytuya.Device('bfc6d450d7e2a0b4322mkq', '192.168.1.129', key, version=3.3, persist=True)
STATUS_TIMER = 3
status_time = time.time() + STATUS_TIMER - 2
print(" > Begin Monitor Loop <")
while(True):
if status_time and time.time() >= status_time:
# poll for status
print(" > Send Request for Status < ")
data = d.status()
status_time = time.time() + STATUS_TIMER
else:
# no need to send anything, just listen for an asynchronous update
data = d.receive()
print('Received Payload: %r' % data)
if data and 'Err' in data:
print("Received error!")
# rate limit retries so we don't hammer the device
time.sleep(5) |
|
Nothing changed only counters broadcasted all other DP should be polled. I think you are right and localtuya does the trick using seqno=1 to get all DPS from device. P.S. Added KEEPALIVE_TIMER = 12 Thanks for your time @jasonacox |
|
I need to do more investigation on this. Thanks for raising it @leweafan |
|
Hi @leweafan I have something for you to test. I have released a dev version that simply ignores seqno=0. pip install tinytuya==1.14.1.dev0You can use the import tinytuya
key = 'DEVICEKEY'
d = tinytuya.Device('bfc6d450d7e2a0b4322mkq', '192.168.1.129', key, version=3.3)
print(d.status()) |
|
You can give it a shot, but I find it highly unlikely to help; a non-zero sequence number would have been picked up in the modified monitor script I posted above. |
|
Hello @jasonacox! Sorry for delay. I have tested a new version and got nothing. Scan is working fine but the new script and old ones don't work. Made rollback to the previous version. |
|
Thanks @leweafan - As @uzlonewolf predicted, no difference. Thanks for trying. Without the device, I'm not sure what more we can try. Sorry about that. |
Hi all,
I'm trying to figure out why tinytuay can't get my device status and localtuya can.
I see that tinytuya decodes only UDP packets and ignores TCP packet and in case of localtuya TCP packet decoded.
DP_QUERY makes the same request as localtuya does but also ignores TCP packet.
Can you help me to understand why I can't get my device status from TCP packet. May be I'm missing some config parameter.
Using tinytuya I get the following output.
As you can see from debug only UDP ports listned:
DEBUG:Listening for Tuya devices on UDP ports 6666, 6667 and 7000Using localtuya I get the following output where all DPS are presented:
TCPDUMP flow:
The TCP packet I've mentioned:
22:46:51.541550 IP 192.168.1.129.6668 > 192.168.1.83.54312: Flags [P.], seq 1:1133, ack 153, win 2768, length 1132The text was updated successfully, but these errors were encountered: