Hi,
Thanks for the pr. I’ll take a look as soon as I have some time. I can’t remember what keys were returned with my devices, so I need to check that my test devices don’t also return the keys you have used. It may take a few days, but I will get to it asap.
Thanks for the contribution, if you have any other ideas for improvement i’d be happy to include them.
Cool!
Let me know if there is anything that you see that you think should be changed.
It would be nice if there was a better way of knowing those indices from the data returned; however, I wasn’t able to think of one that would be accurate yet.
I’ll play around with it a bit more in the following days and may open up another pr if I can think of any meaningful changes!
VirtualID is DeviceID, DeviceKey must be exported as a “localKey” from the app itself (rooted device, older version of the app) or via communication (sniffing SSL packets of the app).
If you follow my guide at the top it points you to a page that shows all the ways you can grab the IDs / keys. It’s fairly painless.
Haven’t seen these errors. What API version you’ve set?
It looks like you are connecting to the device but it’s returning a payload that is encoded. That’s to be expected but the python package should be decoding it. So, that means one of 3 things:
What happens if you switch the api version?
This script only works with the two api version listed in the first post here. If you aren’t using the correct version it wont work properly.
Thank you, this is amazing! Feel like I’m so close…but keep getting socket errors. I’ve confirmed
Crontab file includes three lines in format:
pythonlocation tuya2mqttlocation “deviceID” “IPAddress” “” “3.1”
Using CloudMQTT, see the requests coming in but continue to get the following:
2020-01-10 06:37:03: Received PUBLISH from vm (d0, q0, r0, m0, ‘devices/tuya/plug/’, … (146 bytes))
2020-01-10 06:37:03: Socket error on client vm, disconnecting.
Any ideas? Any help is appreciated 
what firmware version are these 3 devices on?
In your 2nd image it has the power values already. See the section of ‘dps’ values? Those are the tuya device stats.
However, I’m a little confused as to what your issue is and where / how you are getting those dps values if you say things aren’t working for you.
As I said, the second image shows the same ‘dps’ data that you would expect to get from this python package. So, Im at a loss as to what the issue is.
Show us your code for trying to get the info in HA and the results that you get.
The key and id are unique to every device. Are you using the same details in bluestacks to get those dps values shown in the image I referred to in the previous posts?
That is the encrypted data, which means that you have successfully connected to the device. The device is also returning it’s encrypted data.
So, as mentioned previously, you are either selecting the wrong api version or your device uses a completely different api version.
This leads us to the question of how you were able to get the dps values posted in your image earlier.
Looks like 1.0.3
So you got the spa values using the Tuya2MQTT python package? If so, then I’m totally confused as to what the issue is.
In one post you say you can’t connect to the device. In another you say you are getting encoded data, then DPS values in another.
Show us how you are calling the device via Tuya2MQTT and then how you are consuming it.
If you hit the device too often it will typically start to refuse your connections for a period of time. Likewise if you have the device open in the app, the device will refuse to connect.
Will this work for devices that have already been freed with tuya-convert and are now running tasmota?
As long as a device can be interacted with via tuya / smart life / jinvoo this should work.
I dont think that’s the case for devices that have been flashed with tasmota. The conversion process replaces the firmware