Just got a batch of Shelly devices (replacing Insteon - surprise!), and they are all working great.
Dimmer2’s, H&T’s, Motion’s.
Didn’t replace the firmware with ESPHome (though it’s nice to know I could) because the factory firmware does a great job.
But its app and the HA integration for Shelly recommend static IP addresses.
So I setup a DHCP reservation for them all.
But I’m curious why that’s important.
The DNS resolution for them would follow them to whatever LAN IP they were assigned, so why do they so strongly urge static addrs?
TIA
[update: the short of it is that hard-configuring IP on a battery-powered device is helpful in that it saves it time and battery power when it wakes up, by not having to renegotiate its DHCP lease.]
That isn’t a static IP, but it has the same effect.
I have over 65 devices on my local network and not one of them has a static IP (assigned by the device) or a DHCP reservation in the router.
The only devices on my network with reserved DHCP (AKA Permanent Lease) are servers. Imagine the pain if you have reserved DHCP addresses for 30 Shellys and have to replace the router.
I always assumed it was speed after waking up. If device just knew it’s it then didn’t need to think about asking for a new lease etc, it could just get on with it’s job of doing whatever its’ doing, ie a battery power sensor.
That said I run dhcp on mine and set static addresses via router (unifi) for name resolution etc.
I don’t know why or how, but when we switched router most or all kept their IPs to the next router.
I had not done static IP on the devices I only reserved them but some how they got preserved, obviously not in the router so I had to add them there.
Most likely because devices were powered on during router switch, so devices themseves remembered assigned IPs. Only if devices would be power cycled (or restarted) they would ask for new IP and most likely completely different one would be asigned from new router.
For me question of assigning static IPs is question of convinience (as Tom mentioned it is easy to connect to specific device for debug/troublesoot, if you do not need to first to figure out what is its actual IP), but also sort of maintaining of consistent configuration for other purposes. I have a lot of scripts that I regularly run on my network (outside of HA) and most of them are using static IPs for connecting to queried devices. Changing IPs in somehow random manner would require editing these scripts after each change. Also I’m not sure if all integration in HA itself are fully able to recognize devices by other than IP/MAC properties. So if integration is poorly written it can recognize device as new, after IP change and tread association with old IP as missing device. Said that, it is for sure not the case for Shelly integration :-).
Static IP addresses or static DHCP leases have advantages when it comes to defining firewall rules and it also will help getting a better structure within your network and a better overview of your networks, VLANs and devices.
Static DHCP leases still require the device to do the DHCP handshake (Request - Offer - ACK)
A statically assigned IP-address in the device itself has a small speed advantage instead, especially for battery powered devices with sleep mode: When waking up, no DHCP handshake is required so the device can react faster and they are independend from the DHCP-server.
What I usually do is to assign static DHCP leases for all devices on the DHCP-server but additionally configure the reserved address in the according device statically.
The only drawback of statically assigned addresses (not leases) is the manual effort required when you want to change subnets, netmasks or gateway information.
I’m marking this as solution since it provides what is probably the reasoning behind Shelly recommending static IP: Saves time (and thus battery life) by avoiding the requisite handshaking for DHCP negotiation each time the battery-powered device wakes up.
Hadn’t thought of that one - it makes sense.
i.e. hard-configure the IP on the battery-powered devices, and let the mains-powered ones do DHCP (reserved or otherwise)
Thanks.
There are a few advantages to static IPs.
First it is faster to get a device online, because a few steps in network initialization can be skipped, which is especially good for battery powered devices.
Secondly, if a DHCP service is restarted, then the lease list is usually lost and the router then tries to guess if an IP is available by ping or ARC lookup, but IoT devices are not always the much communicative kind, so IP conflicts might occur and then IoT devices are again not the best to handle those due to limited CPU power and code space.
Thirdly, a setup with HA and devices on static IPs would still function even if the router fails.
The recommendation is also often made, because many ISP provided routers do not link DHCP and DNS together, so there is no way to keep track on dynamic assigned IPs on these networks. This is actually the majority of network setups.
@WallyR
Don’t quite agree on your 2nd and 3rd reasons:
2nd: That depends on the DHCP server. A good one should store the assigned leases together with the remaining lease time accross a service restart.
3rd: That’s true but only in case of a flat network configuration. As soon as you segregate your devices into several VLANs (which is a good idea for security reasons, like one for IoT-devices, one for guests, one for management-/network-devices and one for your trusted devices) you will depend on your router.
No router stores their lease list, because the router does not know for how long it has been down and what has happened in that time.
If it stored it, then it would restart with a lot of reserved IPs that might not be in use and a pool shortage could then easily occur.
I have yet to see a router that actually store the lease list over a reboot and it can not do it when there is a crash or power outage.
True, but your IoT devices and HA would probably be on the same VLAN, the IoT VLAN, and therefore continue to operate.
It’s getting off-topic but the lease table should be uneffected by a DHCP-server reboot (the router knows the current time and hence the remaining lease-timeouts).
Like Sonicwalls or UniFi gateways have persistent lease-tables.
But it is still down and therefore unable to receive and handle release notifications.
I have a EdgeRouter and that does certainly not have a persistent lease list.
I would love to see it in writing for those gateways.
UniFi aims there product range for large networks too and those are especially prone to pool shortage, so it would not make much sense.
If you observe that behavior then it is probably the rebuilding from the ARP table that you see, which occurs really fast for most devices, but there are some devices that do not send that often, like ESP devices in deep sleep.
You are absolutely right! I had to replace my router and could not buy the same model so my backup was useless… I still have problems getting some of my devices back in the old config as I used DHCP at first. Now I am assigning statics and that is way more reliable and would solve the router replacement issue, assuming you configure your router correct off course.
