tuya-local
tuya-local copied to clipboard
make-all
Add Tuya cloud assisted setup flow
Pick up the streamlined Tuya cloud login from the official HA cloud Tuya integration. This allows you to get a code from the Smart Life app and then use the app to login to Tuya with a QR code. All available devices for that account can then be select to add locally. Only the IP address still needs to be discovered so a local scan is performed to get that. Just like the final device connection the scan for the IP can fail if other things (including the Smart Life app just used for login!) are connecting to the device when the scan runs so those should be closed before that and the final connection step.
New flow:
Starting page in the config flow allows users to choose to go down the cloud assisted configuration path or the original manual entry path:
Now you need to provide the 'User Code' available from the Smart Life app:
Then you will get presented with a QR code you scan in the Smart Life app:
Once you scan and approve the login in the app, a list of available devices that the cloud account knows about is shown. Now you must select the device you want to add and, if necessary, the gateway it connects through:
Next the local IP address of the device is found by discovery:
Finally the retrieved data is prepopulated into the existing register local device page:
@make-all this is not yet ready but wanted to get your early thoughts on this new streamlined setup option that directly utilizes the Tuya cloud to get all the device data without having to set up an IOT account.
This presents the local / cloud selection for each device that is added. It might be better to detect that the user has already selected one of these, and skip that selection, using the cloud login details if available, otherwise jumping straight to local selection.
Ideally the way this should work is: local discovery to detect devices -> if cloud available, get local key from cloud, otherwise prompt. If local discovery is not available (due to complex network config, or conflict with localtuya), then the full manual setup needs to also be available, though device ids may also be available to be pre-populated from the cloud.
Yes, I wanted to keep this first version simple and less disruptive vs the status quo. The cloud credentials can be saved into the domain data and then re-used on subsequent device additions (vs the current repetitive login required). In my experience doing that correctly and safely handling the possible states is a little hard to test all the edge cases so I didn't really want to include it in the initial changes.
If the flow was as-is (i.e. always giving the user the choice up front) but the QR login steps were skipped if credentials had already been saved from a previous configure, would that work for you?
@make-all I haven't found a good way to save the authentication data persistently into home assistant. I can save data to self.hass.data[DOMAIN][DATA_STORE] but that doesn't survive a reload of the integation / home assistant restart. It would improve over what I have as adding multiple devices in one go would only require a single login via the smart life app so the very first setup if you had multiple devices to add would be better. But the scenario of getting more Tuya devices over time wouldn't really change. Any ideas?
Having played with the in-memory cache of the login token it looks like it expires relatively quickly anyway (tens of minutes to a small number of hours) so there may not be much difference in practice between permanently storing it and the temporary store I currently have.
@make-all I'm not familiar with the automated python testing. It's complaining about the new tuya_sharing dependency:
custom_components/tuya_local/config_flow.py:22: in
Do you have any pointers on how I can fix this / run those tests locally?
The tuya-sharing library is not a standard part of Python, so needs to be declared as a dependency in requirements.txt and requirements-dev.txt
No, only finding the time to manually rebase it is blocking the merge now, as it cannot automatically be rebased.
No, only finding the time to manually rebase it is blocking the merge now, as it cannot automatically be rebased.
I think you'll want to squash merge this anyway. I like to create lots of small commits - no point polluting the history permanently with them.