search

clach04 / python-tuya

Python interface to ESP8266MOD WiFi smart devices from Shenzhen Xenon. NOTE I'm not using any devices with this library so I can't test :-(
MIT License
239 stars 54 forks source link

partial dps decode removed #42

Open tixi opened 6 years ago

tixi commented 6 years ago

In status function when the payload is encrypted, only a partial dps is present in the decrypted payload. This is a source of bug in case of multiplug or bulb. I just put comments for that part.

clach04 commented 6 years ago

Can you describe this a little more? I thought I remember seeing crypted packets that had status information and it was complete json. complete.

What bug does this change address? For some of the devices I have it would regress (albeit not on each call, not all status results are returned encrypted).

tixi commented 6 years ago

What I observe with my different devices is that when the payload is encrypted the json is valid but the state is not fully present. I got something similar to what you have in comment: {"devId":"ID","dps":{"1":true,"2":0},"t":EPOCH_SECS,"s":3_DIGIT_NUM} Except that the dps only contains the first entry (i.e. "1":true). Returning that state is valid only for devices where we care only about the first entry mostly single socket outlet. For bulb, or multi socket outlet this is a source of bug since we may want for instance the mode of a bulb or the state of the second socket. BTW, i also observe that this encrypted payload is what the device reply to a set command.

BillSobel commented 6 years ago

This occurs upon local control and is just the modified dps.

Sent from my iPhone please excuse any typos.

On Nov 14, 2018, at 7:53 PM, tixi notifications@github.com wrote:

What I observe with my different devices is that when the payload is encrypted the json is valid but the state is not fully present. I got something similar to what you have in comment: {"devId":"ID","dps":{"1":true,"2":0},"t":EPOCH_SECS,"s":3_DIGIT_NUM} Except that the dps only contains the first entry (i.e. "1":true). Returning that state is valid only for devices where we care only about the first entry mostly single socket outlet. For bulb, or multi socket outlet this is a source of bug since we may want for instance the mode of a bulb or the state of the second socket. BTW, i also observe that this encrypted payload is what the device reply to a set command.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.