Local Tuya host configuration works with bad IP - why do we need a host configuration?

Hi,
I’m trying to understand how Local Tuya still works for me, even after my devices changed their IP, and why do we need to configure a host attribute at all.
I have configured my devices (lights and plug) manually with Local Tuya and provided each device’s IP in the host attribute.
After a power failure in my apartment, my devices reconnected to the router and got a different IP than they had. Still, HA showed the devices and I was able to control them.
Looking at the logs, I saw that LocalTuya uses UDP broadcast to identify devices, and I assumed it was able to match the reported device ID with the the device ID I provided in the configuration. I was also able to get the devices to respond after changing the host attribute of each device to a non-valid IP (for example - “…”).

  1. Is LocalTuya indeed able to reconnect to devices even after they change their IP?
  2. Is (1) is true, then why do we need to provide a host attribute?
  3. Given that I provide device_id and device_key for all my devices, is it ok to set an invalid IP in the host attribute and let LocalTuya discover their IP?
2 Likes

You are correct. Localtuya listens to broadcasts from devices (based on device id) and updates incorrect IP addresses automatically. I added it since devices often change IP address due to DHCP, this way the integration recovers automatically. You can basically enter anything and it will eventually recover, once a broadcast message has been received.

The host field exists both due to legacy reasons (before this feature even existed) but also to handle the case where devices are on a different VLAN, so broadcasts aren’t received at all. By keeping the host field up-to-date, you don’t get any failure to connect in the logs which you will get otherwise if the IP is not correct. If you set up via config flow, the stored address is updated to that it persists between restarts of Home Assistant. That does not happen with YAML (you need to update manually), it only works during runtime.

3 Likes

Thanks. That is a very useful feature, especially since I can’t set a static IP for any of my Tuya devices, and my locked-down router doesn’t provide me a way to reserve IP addresses.
I noticed that sometimes after a power failure, HA loads with one of my Tuya devices disabled. Is this because the device did not respond in time to the broadcast? Is it only checked when HA loads?

Can’t you shut down the dhcp server on the router??
HassOS hass an dhcp server addon :thinking:

Good to know. I’m actually waiting for my ISP to upgrade my connection, which also comes with a new router. Already made sure the new model supports reserving IPs :slight_smile:

Disabled as in the same way as when you pick “Disable” in the …-menu next to the integration (and it no longer shows in the integrations list)? That shouldn’t happen and I would suspect a bug in core.

It’s shown as unavailable - the device in lovelace is shown visually as disabled, i.e. I cannot turn the light on/off.

Disabled and unavailable are not the same😉

Bad choice of wording on my end as a former frontend developer. GUI-wise the entity is disabled :wink:

That was what I was fishing for :wink:

@IdoF You will have to refer to the logs as to why the entities are unavailable.

Next time it happens, I’ll check the logs. Thanks.
I’ve set the default log level to warning and LocalTuya logs to debug. Is this enough to troubleshoot such a use case?
Anything specific I should look for, any keyword to search for?

I think you should see it with just warning or so, but debug is fine. There’s likely an error message about failure to connect or so, hard to tell as it depends on the problem.

I have 2 Question. This answered a lot of questions for me, but I have a situation where I’m using a bulb that has some limitations it’s a felt Eletric product. For some reason in their great wisdom they have made their bulbs only work with their app. Yet I can bring it into smart life but I lose some functionality such as scenery and grouping. I followed all the instructions and got them to be brought into local Tuya. I was worried about the IP change but this answered that question. But in my discovery of this when I got the Device found and I went into HA Local Tuya to configure it. Sometimes I would not get all the pins that I needed well ID’s or whatever you wanna call it to reference. I was missing pin 24 and 25 which would make them unusable. So I couldn’t attach it to a reference point. I found a work around by doing this. Going into the smart life app and changing the color, the color temp and Dimming once then on the site the pins showed up. I have put a recommendation in the forum for adding a private Template library or even better a community one . Once you got the Devices configured you can put it in a template to pull from later. That would be a great time saver. But it this got me thinking if this fix the pin number so I could see it to map it. This got me thinking the show up in this process and after your married to Smart life and developer is there a way to get to see the other pins that have the built with sent command in developers Site So I Can posable get the effects Aka imbedded Scenes to work. So I then can link those into my configuration also getting more potential out of the Device. I’m sorry this turned into such a long question. Also on the configuration you can set intervals if they don’t update do you recommend doing that and will that make the broadcast happen faster. And or do you have a number in mind to set it. One last crazy thought I saw you were talking about V Lan is there a way to set up a V LAN or separate network with a route with Any Tuya device So if a hacker can hacks the Device they don’t get access to my full network. I originally had two networks at my house one for any device like these plus my ring cameras to prevent that. But when I realized I need local Tuya I just bought them in on my network. I look forward to your answer and thank you in advance.