tuya-local
tuya-local copied to clipboard
make-all
Contribution - Auto Discover Device ID, Local Key, and Other Product Details
Hey Team,
I created a python script to go retrieve the device_id, local_key, and device name info for each device owned by a user. The inputs they need are:
UID: (The UserID associated to their linked Tuya app or SmartLife app) AccessID/ClientID: The AccessID you get for creating a cloud development project at TUYA's IoT website. AccessSecret/ClientSecret: The API key for the above.
The rest of it is pretty much static. It makes an HTTP Request Call for an access_token, then makes a second get request call for the devices with that access token. I can also get the brand and a bunch of details about the product.
{"code":"switch_led","value":true},{"code":"work_mode","value":"white"},{"code":"bright_value_v2","value":1000},{"code":"temp_value_v2","value":1000},{"code":"colour_data_v2","value":"{"h":0,"s":1000,"v":1000}"},{"code":"scene_data_v2","value":"{"scene_num":1,"scene_units":[{"bright":200,"h":0,"s":0,"temperature":0,"unit_change_mode":"static","unit_gradient_duration":13,"unit_switch_duration":14,"v":0}]}"},{"code":"countdown_1","value":0},{"code":"music_data","value":""},{"code":"control_data","value":""},{"code":"rhythm_mode","value":"AAAAAAA="},{"code":"sleep_mode","value":"AAA="},{"code":"wakeup_mode","value":"AAA="},{"code":"power_memory","value":"AAEAAAPoA+gD6APo"},{"code":"do_not_disturb","value":true},{"code":"cycle_timing","value":"AAAA"},{"code":"random_timing","value":"AAAA"}
Long story short, I think this could supercharge the ease of use for this integration. It gives us the ability to automatically find the device IDs for each user, their local keys, and the types of devices they are.
Let me know how I can contribute. I'm not familiar with committing to Git/GitHub in relation to open source projects (didn't do pylint, don't have standard code practices, etc.). So I'd like to know what you'd like me to do to get this code into your hands so you can apply it appropriately (if you so desire).
This is already supported by tinytuya, so we don't need a separate script for it. The difficult part is integrating it with the config flow, and preferably in a way that does not require it to be used, as some people do not want to use the cloud at all.
I was unaware of tinytuya. Okay, so would you say there could be a feature request for an "option" to allow people to use it to discover devices, and that is the entirety of the cloud operation? Everything else is local. Basically, it'd be a dialogue pop up that asks them if they want to "discover devices" (or could be in the setup form... discover devices and then they load into a list with a dropdown). This might also increase speed of "setting up" devices again - if the first setup (for whatever reason) fails (or maybe an IP address changed - this could help repair those "broken" devices).
I don't believe it is possible to "discover" IP addresses via the cloud. The IP address listed in the cloud data is the external IP address, which is almost always not the local IP address of the device. Local discovery is a separate issue (which tinytuya can also help with), which can discover everything relevant except the local key, so really there is only a need to use the cloud to fetch the local keys for devices.
That's precisely what I'm referring to. Discover of local keys via the cloud so it doesn't take years off of someone's life to add a device (let alone many). I have 70 lights. I had to go through your process 70 times. They are all the same light. It would have been extremely nice not to have to do that 70 times - just select all of them, set them all up in the same way, and let them join/pair.
And guess what, cause Home Assistant scenes apparently absolutely blows, I'm likely going to have to do it again. Nothing I do with any of the lights sticks... and now my damn home assistant is dead and I'm going to have to revert to a backup (which, guess what, doesn't have the lights added).
So yeah, some way of adding lights in bulk would be really, really nice.
I personally prefer not to use the tuya cloud integration and have installed Tuyalocal which works great until the local key is changed for whatever reason. Then I have to create and account, as certainly my most recent account will have expired. Then I need to fetch new local keys all over again. This is a huge PITA.
I would definitely be on board for a process that avoids me having to reset a new developer account to get the local keys. Does this solve that problem? B
No, this would use the same developer account that is used currently, it would just do so automatically.
But probably your experience defines a requirement that the account credentials be completely reconfigurable without losing any of the existing devices, so you can create a new account when your has expired if it is easier than extending the expired account (which I have heard takes a few days to get approved).
bump on this one. I'm staring at 40 devices (minus 4 I've migrated) in Tuya and it's a bit of an epic to migrate devices. After forgetting about renewing the trial account I've pretty much had jack of the 6 monthly surprise. I'd really prefer not to have to go through the exercise I migrating everything by hand.
The first step to migrate that I've come to realise is the removal of the Tuya cloud integration to stop clashing with device names. With the number of devices I've I cannot remove the Tuya cloud installation during the migration stage as I will lose control of devices... ie - I've migrated 4, the other 36 will only have Tuya or Google control - through the Tuya Cloud integrations.
The pull from the Tuya cloud is very nice to have as opposed to having to manually integrate each device.
