I found out by accident that I needed to have a reserved IP for my HUE bridge because of an issue I saw with my log flooding with polling and connection messages.
I have also had intermittent problems with communications between Hubitat and my Lutron Bridge PRO, so I changed it to a RESERVED IP.
At this point, I still don't have a RESERVED IP for the Hubitat itself. Is it recommended?
I'm still having periodic TELNET errors which is how Hubitat talks to Lutron.
BTW, I have an Eero mesh network which uses 3 routers.
Personally I've given all my hubs and WiFi devices static IP addresses. This has stopped me having any issues after power cuts or devices being powered off for any length of time and their original IP address being allocated to other devices.
I just think it's good practice.
I do DHCP reservations for everything (IP) on my network (yes, I am a control freak). The only thing with a truly static IP address is the DHCP server (a PC running Ubuntu). It's a little more management overhead but I hate chasing down IP address problems . . .
For infrastructure devices, IMO it's highly desirable. Arguably if DNS is good you don't need reservations or statics ... but then there's the old sysadmin troubleshooting cliche "it's always DNS", so ... [shrug]
No downsides other than maybe some administrative overhead (eg, remember to kill reservations of retired devices so your scope doesn't get eaten up with invalid leases over time).
The only issue is typically a limitation on the number of reservations the router allows. I've seen some home-use routers allow as little as 20 devices...
A few cams, phones + tablets + TV & you're way over such a low number... Like others I am an IP control freak, and part of my security model is to only allow devices by MAC address , and IP reservation kinda ties into this.
My router only allows 16 IP address reservations! So, i've figured out what really needs an IP reserved and what works fine without reserving, out of sheer necessity.
If that's constraining, turn it off and allow your Mac or rPi to handle DHCP for you. I have a Linux box doing my primary DHCP with a Mac Mini as redundant.
I do, but I also have a 9 year old and I really like the Parental controls and the fact I can adjust them from my phone with ease. I can't have it both ways, so I'm choosing the limits for now. I'm getting by and for now I'll just keep complaining to TP-Link about this strange limit.
I firmly believe in known IPs through DHCP assignments or failing that static IPs. It makes HA work better. My only reservation (bad pun) is that if your router fails you maybe lose the reservation table. Here static wins. In my case I can restore it to another replacement router but thatβs not a standard feature.
Static IP addresses require thorough documentation and coordination. It is far easier to maintain reservations then remembering which device is assigned which IP. More over with reservations you can assign host names as well. Most routers have backups or you can typically copy and paste the table into a spreadsheet.
All it takes is one static IP address on the wrong IP to cause havok. Takes hours to days tracking it down without the right tools.
Not to mention some devices can't be reset to DHCP without a factory reset.
Bottom line is, in my opinion, consumer level devices should not have static IP addresses. Consumers should set up reservations for devices that shouldn't change.
I agree and I do use reservations, however, old habits die hard. So I still assign them in ranges. 1 to 19 are for networking devices, 20 - 39 for Hubs and HA like the EcoBee and so on.