Closed clach04 closed 6 years ago
Dumped payload and sometimes switch is returning an encrypted payload. Using similar technique as when sending payload to switch. I'm not sure what triggers this. THe returned payloa donce decrypted looks like a status but with extra elements for "t" and "s", they are both numeric. s
is so far 3 digits. t
is 10 digits.
Sometimes see a 2nd switch entry in dps, which is zero - wonder if this is timer related?
E.g. (numbers changed.....):
{
"devId":"0020046560019434492c",
"dps":{
"1":true,
"2":0
},
"t":1234567890,
"s":123
}
and
{
"devId":"0020046560019434492c",
"dps":{"1":true},
"t":1234567890,
"s":123
}
t
looks like its epoch time (i.e. time.time())
t
is epoch time (i.e. time.time()).
I believed this is resolved by commit 8d70404fb38cf2144c60329678b8f6bb84a8720d.
Leaving open for testing.
Tuya documentation alluded to the devices having time series of data although I can't remember where I saw that and if the device itself maintains that or it's solely the Tuya "cloud"
Does 's' increase or seem to change randomly?
s
- maybe, I don't have a good record of them. Its not increment by one but I'm trying to remember if it jumps around. I'll have to start dumping that info to a file.
I checked t
with python time.time() so I'm convinced is epoc time.
@nijave I spent a while trying to get it to dump a crypted status and it took a really long time before it happened. I only managed to catch a few:
{"devId":"XXXXXXXXXXXXXXX","dps":{"1":true,"2":0},"t":1515131564,"s":569}
{"devId":"XXXXXXXXXXXXXXX","dps":{"1":true,"2":0},"t":1515131566,"s":573}
{"devId":"XXXXXXXXXXXXXXX","dps":{"1":true},"t":1515131582,"s":576}
{"devId":"XXXXXXXXXXXXXXX","dps":{"1":true},"t":1515131584,"s":580}
{"devId":"XXXXXXXXXXXXXXX","dps":{"1":true},"t":1515131594,"s":592}
So yes increasing. These are all the same device. I've no idea why s
is missing on the last few.
@clach04 @nijave Could this be the same issue I'm having where I get an error response. I'm using tuyapi, and just assumed that the issues was with my glue script since I have pretty much no nodejs knowledge I was messing things up by leaving connections open, etc. IT works most the time but now and then it gets into a tizzy. https://github.com/unparagoned/njsTuya/issues/1
@unparagoned unlikely - your reported problem looks like a comms disconnect, this is an encrypted payload (that was unexpected until decryption support was added). One way to tell for sure would be to check the error you are seeing. I would say try the new version of python-tuya but its Python not javascript so likely not something you want to do.
One of the things python-tuya does differently is that its deliberately naive in its comms approach. It opens and closes the socket each time (its not that slow to do) which reduces the window for disconnects to occur.
@unparagoned @clach04 that doesn't sound like the issue clach04 was having with the extra/encrypted payload but that sounds like the issue I was hitting running inside HomeAssistant. The TCP RST which sounds like @unparagoned's problem I've only hit running inside HA. I was able to recreate the extra data issue with a constant loop that toggled the device's state and polled in between (after a few loops it returned an encrypted payload).
@unparagoned issue #2
Resolved by commit 8d70404fb38cf2144c60329678b8f6bb84a8720d
related to Issue #2
repeated status calls sometimes fail with:
extract of test (after creating switch object):