Home Assistant wont change it's DHCP IP Address when a reservation is created

Recently had an issue with my HA config and my IP Address changed on my HA instancefrom 192.168.1.169 to 192.168.1.165

So i reserved the old address in the router and restarted HA. HA still decides it has a preference for new address 192.168.1.165 even though theres a reservation for 192.168.1.169

Do i need to edit something in the cli to force HA to forget about it’s old 192.168.1.165 address, kind of goes against DHCP in some regards to have to do that! Didn’t really want to have to force a static IP for it tbh. Anyone experienced this weirdness?

Typically, a new DHCP reservation won’t be picked up without a full restart of the network stack or a release of the existing lease. AFAIK, restarting HA just restarts the process and doesn’t restart the network stack. Performing a full reboot should do that. If you are running a Linux os, you could just renew the DHCP lease by using the command sudo dhclient -r, I’m not sure if Hass OS supports that or not.

Also, check how long your DHCP reservation timeout is set to. A lot of routers set it to 24 hours by default. If after a reboot your HA instance still isn’t picking up the new reservation, try adjusting the timeout in your router to something like 1 hour.

Personally, any server in my network always gets a static IP address. Since HA is a core service in my home, it ALWAYS gets a static IP address.

Well, Home Assistant is an application - it doesn’t have an IP or have anything to do with DHCP :wink: Restarting HA does nothing.

A reboot will do it, but eventually the current lease will expire and the DHCP client in the OS will be told that it cannot use that IP. At that point it’ll accept a new lease.

@Tinkerer I get that it’s an application, but its very involved and relies on a docker stack by the look of it. I didnt want to just get into the OS and start forcing changes if it was expecting it to be done in a different way causing issues potentially for docker to properly assign addressing. Knowing there are different way of assigning IP Addressing in linux i didnt know if HA had standardized on a process or created the potential to do this via the web ui for changes to take effect after a reboot.

I’ve already taken the IP Address that HASS.IO is using to force it to update the lease. But yet it ignores the fact that the IP is taken which seems like strange behaviour for DHCP on a linux based OS.

@code-in-progress - Yup i have restarted the network stack and the reservation is being picked up. Dont think dhclient -r is valid for HA.My router is hardcoded for a 24hr lease and cant change it. So i’ve taken HA’s IP on a laptop to force a change and it hasnt attempted to renew it knowing theres a conflict.

Home Assistant is the application, it doesn’t rely on the Docker stack.

There is the Supervisor, which does. There is also Home Assistant OS, previously called Hass.io) (which uses HassOS) which is one way of installing with the Supervisor.

Your problem/question relates to the OS you’re using (HassOS or other), not Home Assistant :wink:

@Tinkerer- Thanks for taking the time, it’s appreciated. If my problem relates to the OS (Which i agree it does) And HassOS is the OS. Then havn’t we kind of come full circle a bit?

It’s all done. Router issue it seem, thanks for the tips of where to look. Appreciated.

hallo, (sorry for my bad english) I have had the same problem. Each 12 hours (the interval to renew ip with dchp of my router) the raspberry lost network connection.
After I read this thread, I have configured a static ip and the problem dissapeared.
I think that something is bad in Homeassistant OS config because my raspberry pi 4 has run perfectly with raspbian and Homeassistant with docker without problems for 1 year.
The problem started when I passed my raspberry pi 4 to use homeassitant os.
I have to say that is wonderful how you can have a new configured homeasistant server without expertise :), but I have been fighting with this problem for a week (first i thought that was the network cable , etc…).

thanks