Unable to reconnect after power loss #445
Comments
|
Debug logs: |
|
I'm having the same problem with two SULION bulbs (white only). I think I found out what the problem is:
Even if we give internet access after that first try, the bulb won't come up. This is the error from the log. maybe localtuya module could handle this exception, avoid the error log and warns user about the need to resync. 2021-04-22 20:33:22 ERROR (MainThread) [custom_components.localtuya.common] [bf4...rcv] Connect to 192.168.150.105 failed |
|
I was able to "fix" the issue somehow. When the bulb first powers up, it is in a state where localtuya cannot connect (the timeout in my original post). But I wrote a script using https://github.com/codetheweb/tuyapi that simply connects to the bulb, issues a command, and then disconnects. This script works fine and after the disconnect, localtuya is able to connect to the bulb successfully afterwards. |
|
Well, I wouldn't call it a 'fix', but it puts the bulb back into a state that localtuya can then work with again. Hopefully it'll be some help as to figure out how to fix the issue inside localtuya? |
|
can you share with me, so I can see if that exact same script solves the problem with SULION bulbs? |
|
@jrochate It's just a modified version of an example script tuyapi has on their repo. I've created a repo here for ease of sharing: https://github.com/alex-phillips/tuyapi-test Just change the IP, ID, and KEY props at the top. Also, depending on the device, you may have to change the It's also possible that the Let me know if it works for you. |
|
Awesome!!! It really works and you saved me a lot of time in resync and get new Local Key. On both lamps I get output like this: $ node test.js And then they appear again on HA. @rospogrigio you could take a look at this script from @alex-phillips. Thank you all. |
|
I've been setting up localtuya in an effort to "cloud proof" my home, because who knows when these random chinese servers will go down or start updating devices with malware? I just started, so all my devices were ordered within the last few weeks; and unfortunately no one company made everything I need so its a spread of manufacturers. This "can't reconnect after power loss" issue was the last thing holding me back on some devices. A note was added recently to the localtuya readme.md "you must block DNS requests too", but blocking DNS only solved my issue with a single device manufacturer (gosung). The rest could not be controlled until internet and DNS was restored to them, even though they successfully connect to wifi. Here are my experiences for what happens on power loss and return (with no internet available): Treatlife: Instantly controllable Although running the script above did not solve my issue, adding "issueRefreshOnConnect: true" did. I did not need to set any values; just connect with that string in place and then the devices become controllable the next time localtuya polls them. This is just a guess, but this "refresh" command is likely newer and needs sent to devices on newer firmware before they start responding. Also, how each manufacturer has implemented it (or the lack of getting it) seems to differ. This is also why (as found in another issue report) opening the Smart Life app causes these devices to start responding again. |
|
Hacked together a fix that sends the REFRESH command in localtuya. I'm sure there are edge cases I didn't handle here, as every single manufacturer I have handled this situation differently/oddly. But if anyone wants to try, my branch is here: |
|
I'm in the same boat, after some time the device is without power, when it comes back to life LocalTuya won't detect it. Any solution to that? |
|
You can try my branch if you want (see the post directly above yours); the reason my devices could not be commanded after a power loss was due to needing the 0x12 REFRESH command sent to them. Given that yours come back if you open the tuya app then I'd say there is a good chance you are in the same state. |
|
The problem is that I won't get the future updates from the official repo that way. |
|
So far I'm the only one that has tried it, and given that every single device from different manufacturers I have caused different edge cases I'm almost sure there are more issues yet to be found. If you or someone else tries it and it works then I'll PR it to start further review. It needs cleaned up and I'm not sure I'm going to have time to work on that, so if it gets merged will probably depend on if someone more "official" or involved wants to pick it up. |
|
I have tried it in the past 4 days and so far it has been working flawlessly with my Tuya Bulb and Downlight. |
|
Thanks for trying it. If it worked for you, then I will go ahead and PR it and get the discussion on it started. |
Workaround for rospogrigio/localtuya#445.
Workaround for rospogrigio/localtuya#445, at least until rospogrigio/localtuya#491 is merged.
|
Some updates on my end on this: everything was working fine with some franken-branch of mine which was a mix of @Elendilon's branch #491, and my encoding fix for #424 #424 (comment). But I wanted the latest and shiniest, so I upgraded Local Tuya to latest. #424 immediately reared its ugly head, so I re-applied my patch, but the devices weren't Zombifying, so I assumed that this issue here was fixed on master. Zombie fix still neededFast forward to this morning, after a power cut, and both globe are 🧟 , so it seems the current master definitely doesn't fix all the issues. I wanted to reach for #491 and reapply it to test, but as pointed here, it now conflicts with So, as suggested above, it does seem like a rebase of #491 on master, and a merge, is still needed. Workaround with tuya-cliIn the meantime I ended up with a workaround using $ IP=192.0.2.1
$ ID=eb...
$ KEY=...
$ tuya-cli set --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3 --dps 20 --set true
Set succeeded.
$ tuya-cli set --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3 --dps 21 --set 'white'
Set succeeded.
$ tuya-cli set --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3 --dps 22 --set 500
Set succeeded.
$ tuya-cli set --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3 --dps 23 --set 1000
Set succeeded.
$ tuya-cli set --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3 --dps 25 --set '030e0d00000000000000001f403e8'
Set succeeded.
$ tuya-cli set --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3 --dps 26 --set 0
Set succeeded.
$ tuya-cli get --id ${ID} --key ${KEY} --ip ${IP} --protocol-version 3.3
{
'20': true,
'21': 'white',
'22': 1000,
'25': '030e0d00000000000000001f403e8',
'26': 0
} |
|
Following up on my previous message. Workaround with HA scripts (not sure this one works)LocalTuya has a
it takes the
The script runs without error, but I haven't been able to 100% confirm that it actually does what it needed. I suspect localtuya may not want to I'm leaving this here nonetheless in case someone else want to give it a go, as it at lease provides a fully HA-based solution to dezombify without having to patch localtuya. Please report here with info on success/failure if you do. |
I can now confirm that it works. |
|
@shtrom - I've incorporated the set_dp behavior into PR #956 . The changes in this PR allow you to specify DPIDs that are not detected and it will initialise them on connection. So far this has worked with all my offline Tuya devices, except for a Fanco fan - but even the Tuya App isn't able to make this work without the internet. |
The problem
I have a Gosund RGBW bulb. I retrieved the ID and local key just fine, configured HA to talk to the bulb without issue and it worked great. But it seems as though if the power to the bulb is lost and restored (such as the light switch cutting power or the bulb being unscrewed and moved to another light), the integration can no longer talk to the device. I have to start the process over by retrieving a new local key to regain control. The HA logs show the following when it fails to connect:
Environment
Steps to reproduce
Configuration
configuration.yamlorconfig_flowDP dump
Provide Home Assistant taceback/logs
See logs above
Additional information
The text was updated successfully, but these errors were encountered: