Hello,
since HA is forcing me to disable Outbound websocket on Shelly devices i’m noticing that when router fails (sometime it happen) some device get a new IP address. This make shellys unavailablet to HA and HA is unaware of changed ip addresses of shellys… at the end my all automations about lock/unlock home doors and security become unreliable.
This is not how domotic should be as i would like to trust the system and not triple-check it is working as expected…
Now, i want to avoid use static IP on shelly because management become too much heavy for any replacement, and absolutely i cannot trust “DHCP reservation” as it is just an illusion adding to the fact management of MAC addresses become a nightmare, and even worse replacement of the router…
So, is there a way to make shelly devices alert HA of their actual IP?
I suppose outbound websocket could fix this problem but HA now push me to disable in a very annoyng way.
Not sure why you say that.
On my router, it’s a matter of clicking “Set static” on an existing DHCP assignement, and the reservation will be fulfilled as long as the MAC address stays the same…
Not without a valid IP, since that is needed to communicate.
You need to look into the firmware of the Shelly and its settings.
The Shelly might go into safe mode and start up a webserver with the WiFi card running as an access point, so you can connect to that and reconfigure your Shelly.
If the device is just reconnected with a new IP because the router have been restarted, then Shelly needs to be using a discovery protocol that is supported by HA for it to work.
Most routers have a way to set a static address for a device. Every device with a network card also has a MAC address—this is an address permanently stored in the card’s memory by the manufacturer. When assigning IP addresses to your Shelly devices, the router simply “pairs” the MAC address <> IP address. For example: c8:c9:a3:b8:fe:a2 [MAC] <> 192.168.102.55 [IP]—this is the IP address lease. The problem you describe is normal router behavior, as in most cases, the default lease expiration time is 86000 seconds = 24 hours. What you can do:
1/ A temporary solution if you need to “save yourself now.” In the DHCP server settings, change the default lease time to the longest possible value. This will not solve your problem.
2/ In the router’s DHCP settings, specify that it should permanently remember the above-mentioned binding.
I apologize if the above description is obvious to you – I don’t mean to offend you in any way.
If you don’t know how to do this, please provide the name and model of your router – we’ll try to solve the problem together.
Because if router resets, or you need to migrate to another route, all ip reservations settings are gone, also because under certain circumstances home routers are not reliable (i have now the AX72Pro) and i’ve seen they could reassign a released address to another device if the bound one is not online for a certain time.
Sure, but i mean, it it happens a shelly change its ip for any reason, i could imagine that if the shelly send a packet to HA (that have a static IP), then HA could recognize the new IP of shelly and sync accordingly…
Not mine… you have to add one by one. The UI helps with a MAC autocompleting list from ARP list… but the list is very long and previously bound devices are not removed from that list… a nightmare.
Could you tell me what router do you have?
If really there is no way to reach this auto-sync of IP… could this be a feature request?
All you need is to set DHCP range outside of static IPs range and it won’t happen again. I mean set start of DHCP to 192.168.1.128 and make sure that all static IPs are in range of 192.168.1.2~127. If there is an overlap then there is also a risk of such situation.
That is how a DHCP service should be set up.
Static IPs configured inside the DHCP pool range is a no go.
Even setting a static IP inside the DHCP pool and then make a reservation in the DHCP for the same MAC address to IP address is actually against the “rules”.
Some DHCP services check their ARP list or do a ping to check if an IP is actually free, but most just assume their list of IP leases are the truth and that list is lost when the DHCP service is restarted, so after that then all devices should actually be requesting a reassignment of their IP.