Hello, So I have been using localtuya since 1 year or so, But I was struggling a little bit due to instability and loading, issues. I tried to make PRs adding features and fixes but it seems the upstream dev is busy IRL due to personal issues, I didn’t have an experiences in python but localtuya is an important integration in my setup. While I was updating the integration I actually started to understand how HA and python works so I decided to keep updating the fork at least for my use in no time I saw some people started using my fork so I decided to share it with you guys.
Before someone ask: The reason I stick with this integration is due to the approach of both integrations localtuya is way lighter on HA and faster.
What’s the main features does this fork have?
Stability! no crashes or loading fails
Auto configure Devices if Cloud API account is set up.
Supports protocol 3.5 discoverable.
Support sub-devices devices that works through gateways e.g. ZigBee and BLE.
^ Sub Devices automatically discoverable if Cloud API account is set up.
Configure devices with templates ready-config yaml file shareable.
^ Configured devices are exportable through config-flow.
Platforms humidifers, button and siren are supported.
Supports Multi-Hubs aka multi accounts.
Other features may not be important to mention like entity category, icons, devices classes and HA Events etc…
IR Remote:
CREDITS:
All thanks goes to the upstream dev rospogrigio, This fork wouldn’t be existed without him
Installation:
HACS
Or add the repository manually to HACS
Open HACS and navigate to Integrations Section.
Open the Overflow Menu (⋮) in the top right corner and click on Custom repositories.
Paste https://github.com/xZetsubou/localtuya into the input field and select Integration from the category dropdown then click ADD.
Now the integration should be added search in for it and install it!.
Manual installation:
Download the latest version from GitHub releases extract the file.
Copy custom_components directory into your HA config directory.
NOTES:
It’s possible to install this fork integration above upstream integration. But reverting back may not works as it should, because devices config values type aren’t the same.
Reverting back to upstream and keeping the devices data isn’t possible after the 3.2.4 update.
Yes, the fork posted on the first message is using the same data model from the previous one so after installing the new one, all is continue to work perfectly.
My feature request goes here;
All looks great but can i just give my cloud account credentials and let the integration setup all existing devices automatically for me without any intervention? It can generate a report at the end such as: 5 devices found in cloud. 4 of them supported and their sensors are automatically created. 1 of them is not supported, try manual configuration
This kind of step would ease initial onboarding for beginner users.
The auto configure feature just added on last update I don’t know how effective it is since I haven’t tested it on other then my devices. Don’t know if it will work fine for others it needs to be tested more. Mass auto configure was a plan but since it require more steps to validate devices are usable locally, I thought it can be done later after making sure that it works as it should and integration is stable.
This branch is 110 commits ahead, 14 commits behind rospogrigio:master
The upstream repo isn’t literally dead, it gets updates from time to time…
It looks like a lot of work to maybe get some “smart” bulbs I purchased (for a good price) to work offline in HA
Have any of you recently added any new Tuya devices using localtuya (via any repo)?
I don’t understand what do you mean by new Tuya devices since even new tuya devices can come with old firmware, I think many bulbs are running on protocol 3.5 I’m currently using one.
Then I mean devices that might have newer firmware and that have not have been used with home-assistant before, and that need some sort of setup prior to use in HA.
I was also wondering if the method needed to get a Tuya account has changed.
But I’ve given up on these devices since I’d only use 2 or 3 and there’s no manufacturer supported method I can find to get them working in non-local mode.
Localtuya uses your Tuya account only to pull device data like localkey ← is required to make connection with your devices locally. that why it’s not needed. you still able to use localtuya even if you used Tuya Cloudcutter.
So setting up Tuya account will make device set up step easier. You can still able to pull localkeys from you smart/tuya apps in case don’t want to set up Cloud API.
Help! I had some device that suddenly became “unavailable” for reasons I cannot find out… So I thought I’d give this fork a go. I removed the upstream version and installed this one. Now I can not add the device anymore. It gives an empty error. When trying to add.
I guess the old entities were not removed with the removal of upstream version, and it cannot add a duplicate? How can I remove the old data? Where is data for this integration stored
I don’t know what happen to you, whether it’s merging issue or not. but showing an error when choosing Add Device might be different issue. installing the fork above upstream doesn’t remove or add any entitles your old devices should works normally after merging complete and should already added if you didn’t delete them. maybe checking the logs will give you an idea of what is happening.
All Data stored in: config/.storage/core.config_entries search inside for localtuya
You can delete the data from the file or delete the entry from HA integration page.
Note You need to refresh the page after installing the fork this might be the reason why error is empty.
thank you for your project. I installed it today and I can finally see my bluetooth curtain. the only thing is that the commands are very slow and are not always taken.
