[Server] Feature Request: Add a way to sync or put keys for devices

[geNAZt]

Hello,

i try to use the API server ( i want to use it as an add-on in HA and an integration to get the devices into HA without the cloud). Currently it finds my devices just fine and i could get its status but the key is missing and i get an error. I also don't see a way to set the key of a device or the API server taking a Tuya IoT Token for querying itself against the cloud to get the local key.

It would be nice to have either a endpoint which can set the local key or having the API Server ask Tuya itself. For me it would be nice if maybe it can support both and only activate the Tuya API scraping only if credentials are given.

If you want i can implement, test and PR it. Just give shoot me a info if its ok.

Thanks

[uzlonewolf]

Edit: ignore this, it seems I misunderstood the question
Is it even possible to set the local key without going through Tuya's server?

[jasonacox]

Hi @geNAZt - thanks for the feedback!

The TinyTuya API server is pulling the device local keys from the devices.json file that the TinyTuya wizard creates during the setup process (python -m tinytuya wizard) which I suspect you already know. When you start the API server, it looks for devices.json in current dir (pwd) or if you are using docker, in the location specified in command line.

I believe you are suggesting that we add the ability (API call?) to add a new device local key or better yet, add an API call that triggers the API server to log in to the Tuya IoT platform and pull an update of these keys... basically running wizard behinds the scenes to update devices.json.

I can see how that feature would be handy. If this API server is used for a tool like HA, you can present the user with the ability to "refresh devices" which causes it to poll a new list of devices/keys and builds devices.json. Some thoughts:

• Would need to make sure the API server updates devices.json so those devices persist after restart
• The Tuya IoT credentials are stored in tinytuya.json so the server could use that similar to devices.json
• I would absolutely welcome help and a PR request. 😁

@uzlonewolf - You are correct, the way to get local keys is through the Tuya IoT platform which is what the wizard helps do, but still requires the painful process of registering as a platform user and linking the account to SmartLife. I think we would all love it if there was a better way, but I haven't found one.

[geNAZt]

There is no need to refresh devices i guess since the API server itself generates new devices if they start broadcasting their UDP packets. They will start to get listed in /devices but are not fully configured (yet) to get their status or set any key.

For that i would propose either a new endpoint /key/device_id/local_key and any external service will handle the retrieving of that (via tuya iot api) or that logic is put inside the api and queried on discovery with the device_id from it and stored inside a internal database (in that case devices.json). This would enable full device functionality without a) needing to restart the API server, b) running the wizard over and over again when adding new devices.

[jasonacox]

Thanks @geNAZt , I understand what you are saying. You suggest we add /key/device_id/local_key so we can programmatically add the local key for any new device. I can do that.

Another idea:

Since the API server will detect any new device on the network (or any that it doesn't have a local key), it could automatically poll the Tuya IoT platform API and pull the local key itself. My only thought is that the new device will show up on the network even before it is registered (e.g. brand new device not put into the SmartLife app). It could be set to retry at some frequency. We could also have a /sync endpoint that just forces a refresh of devices.json with the Tuya IoT API.

[uzlonewolf]

I don't think the devices start broadcasting on the local network until after they have registered and gotten a local key, but the above PR includes a retry timer anyway just in case the API is lagging or something. It will try up to 5 times waiting 30 seconds between tries.