Bulbs will loose connection after losing power for a longer period of time. about tuya-cloudcutter

[tony-fav]

There's some root issue there to be dug into, but for the device id and key issue, you can already set those to something specific:

run_detach.sh -d 20characterdeviceid -l 16characterlocalkey ...

LocalTuya seems to required a unique device id (I've been doing a friendly name then padding to 20 characters friendlybulb1zzzzzzz) but you can set the local key for everything to the same thing.

[troy-f]

Don't forget you need to apply the zombie fix pr to localtuya as well. by default it is not telling the bulb to refresh dpid's as it assumes there is a working tuya cloud doing that.

[troy-f]

in regards to the tuya app no longer recognizing the bulbs, yes that is by design it is cut off from the app/cloud semi-permanently, technically an exploit payload could be built that reverses this, though I defer to @KhaledNassar in regards to how that would be accomplished

[notkmhn]

Short answer is no, by design it's not possible to regain stock app/cloud connectivity.

The long answer is if you're very lucky, you may be able to but it requires a custom app that supports OTA updates and remote flash dumps. Even then, the necessary configuration in flash might have been already overwritten.

[GravitySandwichh]

run_detach.sh -d 20characterdeviceid -l 16characterlocalkey ...

Thank you, this worked for now and they atleast have their own preferred names and keys now for easy re-deploying.

Don't forget you need to apply the zombie fix pr to localtuya as well. by default it is not telling the bulb to refresh dpid's as it assumes there is a working tuya cloud doing that.

What exactly do you mean with the zombie fix pr? I tried googling on it a bit, but nothing matches the dpid stuff you are talking about. They only talk about DNS blocking when cutting of a non-exploited bulb.

Short answer is no, by design it's not possible to regain stock app/cloud connectivity.

It might be a good idea to make this a very visible warning in the Instructions so people can have a think about this before they continue.

[tony-fav]

You might try running

import tinytuya

d = tinytuya.BulbDevice('<deviceID>', '<deviceIP>', '<deviceLocalKey>')
d.version = 3.3 # hack to set the version without communicating with the device
d.updatedps()
d.set_version(3.3)
print(d.status())

in Python next time instead of recutting. It may work/be something localtuya doesn't do automatically but needs to be done. I just changed the IP of a bulb in my reservations and localtuya new it was at the new IP but couldn't change anything. Ran this and it popped right in.

[troy-f]

edit these two files on your localtuya folder in homeassistant https://github.com/rospogrigio/localtuya/pull/491/files (essentially makes localtuya do the same thing as what that tinytuya script above does)

[notkmhn]

Short answer is no, by design it's not possible to regain stock app/cloud connectivity.

It might be a good idea to make this a very visible warning in the Instructions so people can have a think about this before they continue.

It is mentioned in the instructions, though not as prominently indeed. I'll update it, thanks for pointing that out!

[GravitySandwichh]

edit these two files on your localtuya folder in homeassistant https://github.com/rospogrigio/localtuya/pull/491/files (essentially makes localtuya do the same thing as what that tinytuya script above does)

Thank you very much for this! I just changed LocalTuya so let's see if this fixes it.

[troy-f]

did that resolve your issue @GravitySandwichh ?

[Cossid]

Closing issue as stale.