Open chemelli74 opened 1 month ago
rstrouse
commented
1 month ago Are you sure it didn't pick up the newly assigned IP address because it was broadcast from the server id? The IP address shouldn't matter except for the initial setup. That message above also just comes from the HA code as it loops through the entities on the device. Even though it is not actually updating anything.
There is no polling going on.
chemelli74
commented
4 weeks ago Hi,
yes unfortunately I'm sure the IP changed and was not picked up by the integration :-(
chemelli74
commented
4 weeks ago I think we should add to the coordinator above the following parameter:
update_interval=timedelta(seconds=5),I'll have a look at that setting. It is odd that there would be any sort of polling going on with a local_push event model. All state data should be originating from the socket and only written on a filtered event.
For the debug message above I believe this is generated from each call to async_write_ha_state() which I will investigate to see if I have an entity that is calling it out of turn. However, when I first looked at that there was a process that queues up the calls and commits only once on the event loop despite multiple debug messages. Perhaps I can reduce the debug messages by simply checking for changes. Either way I am sure it only does one commit despite how often you are seeing that in the log.
I'll also have a look at the zeroconf. I'll bet I mistakenly assumed that the config_flow would be called if it changed ip addresses. However, the plugin does not identify the device by hostname or by ip. It looks at the underlying embedded chip id for the ESP32 to come up with a unique identifier for the hardware. That is the reason why the host is not the primary key for the device.
In the end the IP address should not matter and the device should not need to be torn down and stood back up during an IP change. In fact I assumed that the config_flow would be called by either the UPnP process or zeroconf on the existence of the new IP but I could be mistaken. I'll do a deep dive into that process as well to ensure I am dealing with the proper instance of the config_entry. Bear in mind that ip reservations in DHCP exist for this very purpose. It not only ensures good address assignments but ensures deterministic routing. Otherwise the network has to do local mDNS lookups for routing.
rstrouse
commented
4 weeks ago That setting simply adds polling to the device which I do not need or want. When the socket is dropped, the pings begin to fail and it sets the entities to inactive. Not quite sure how yours are still active since the socket connection should have dropped if the IP changed regardless of any half open socket processing. When a new IP is issued to the ESP32 this also generates both an SSDP discovery as well as mDNS and zeroconf packets. Perhaps during this process I am not seeing the instance of the hub that I expect so the changes to the IP address are going into the ether.
Perhaps the entire integration needs to be unloaded when the socket drops. I'll look into that but I don't want it to fall off the configuration. I simply want the new ssdp or zeroconf configuration to be used. If I have to I suppose I could listen for udp packets on my own. I have noticed some integrations doing that.
Hi,
I have one more time the device not available (not responding to old ip because of DHCP change), but config entry is still loaded while instead should be in
ConfigNotReadyand retry:I also notice from the log there there is a very close loop refresh: