rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.84k stars 546 forks source link

Improve recall the reload light #221

Open DavidFFerreira opened 3 years ago

DavidFFerreira commented 3 years ago

Hi, I want to do a update button to reload all bulbs that I have, can u tell me what service I should use for each bulb?

ultratoto14 commented 3 years ago

Hi @DavidFFerreira what do you mean exactly by reload ? Is it the reload integration ?

postlund commented 3 years ago

The YAML config can be reloaded via the localtuya.reload service. Not sure if there's any way to reload individual integrations programmatically yet (I.e. what corresponds to the "Reload" option when pressing the three dots for an integration). I think you will have to search at the community forums for that as it's not part of our integration.

DavidFFerreira commented 3 years ago

Hi, i'm talking about this. For all my non working bulbs, I use that to restore the status and connectivity ![Uploading image.png…]()

DavidFFerreira commented 3 years ago

image

DavidFFerreira commented 3 years ago

thats work individually, because even with my lights turn on all the time, at some part of the day, I found that i have no access to a especific light. Checking logs I got this image image

and I can assure you that I have the most stable network in house. Even the ips are locket to mac

DavidFFerreira commented 3 years ago

Soo a button or service to call reload for bulb are welcome, for I can check if bulb is avaliable, and if not, reload again by my request

ultratoto14 commented 3 years ago

This a native HA functionality, it doesn't seem to have a service call associated.

You can check this post. It uses a rest_command to do the same as the reload button call in the integration.

DavidFFerreira commented 3 years ago

this is very anoying :S.....another drop and i can only revice my bulb by doing the process that i menction before

postlund commented 3 years ago

There are numerous bugs in the re-connect logic and #177 was supposed to fix that (and it does). But we've taken the direction of not implementing that and switching over to the "passive device" concept instead, as implemented in #171. So the best way forward is to test that PR as much as possible and smoke out all the bugs, so we both get faster and more reliable re-connects.

DavidFFerreira commented 3 years ago

Can I help with something?

ultratoto14 commented 3 years ago

@DavidFFerreira you proposed your help, the #171 has been merged. You can check if it helps on your availability problem.