I don’t want to force anyone nor do I say that it’s the only valid option. However here are a few arguments:
DHCP option is easier and platform independently configured, minimal room for error (see above…)
DHCP stays in control of address assignment for dynamic and static devices, one point of administration
A device will always be assigned with an IP address, irrespective of the subnet it is in (prepared for change, with the one condition that the network provides a DHCP server)
Advantages of device-side static IP assignment: Safe against router failure (in which case IP address assignment is the least of your problems )
So yes, my very personal and not-one-true-answer opinion is that DHCP address assignment is better.
Those are valid points but mostly when related to small all-in-one type home networks which admittedly is what most people here have.
I think you meant safe against DHCP server failures, not router. My router (and everybody’s for that matter) has absolutely zero to do with dhcp. If my dhcp server fails… then that is my only worry as that is all it does. My router will keep routing away happily. For the all-in-one units, technically your dhcpd implementation could crash without routing, gateway and other services failing as its just a small linux box anyways.
I also don’t find home “router” dhcp implementations to be overly robust or easy to work with (for anything better than VERY simple flat networks). I suspect the vast majority of them would force you to (or do it without asking) clean out the reservation table if you changed a subnet. You would also have to re-key all of these pairs if you changed different hardware as you aren’t going to be able to export/import them.
Change a nic or docker container or restore a vm; you could be looking at new mac addresses. I actually have automated backup validation software that would fail if you didn’t have static IP’s for servers at work.
All in all, I think they have their place but the industry best practice for servers definitely still is static. I read and implement a fair amount of solutions as an SE and documentation still expects static IP for most situations. That’s all I was saying. My intent wasn’t to say you were wrong, just that neither is BETTER… even static.
Besides… he’s now learning about linux!!! Nothing is better than linux!!! oops, next opinion topic
Yep you are right, all I said was aimed at the normal home network with one subnet, a bunch of devices and one active component acting as physical switch, router, NAT and DHCP. That’s also why I used “router” as the equivalent to “DHCP server”.
We both agree that a bigger network will define other requirements and static configurations have their place there. I’m helping manage a small ISP backbone network and there almost all devices are statically configured.
In the end we both have different preferences and that’s great, the world would be boring otherwise
@ThomDietrich Do you think you could make an option to set a static IP in openhabian-config? You could put a disclaimer that it is not the preferred way to set up.
@ThomDietrich, that’s right, DHCP address assignment is better - but with one of the latest Debian updates, I had the strange behavior that the MAC address of my RPi ethernet interface changed on every reboot! That makes it impossible to use DHCP address reservation to make the IP address of my openhabian “static”. The only way which worked for me was to edit the interface file on OS level.
I’m use to set static addresses in my router for all my “regular” devices. Openhab server running on RPI3 installed initially whit Openhabian is in that list. Everything works fine but I have a question about what I’m trying to do currently:
I want to prepare a setup similar to mine for my parents. So, I just disconnect my RPI, burn an image of my SD card and run that card on another RPI. From there, no problem everything is identical. I removed complex stuff from Paper UI and keep only basic functionalities I want for the second setup.
The problem is that my parents router is running under a different address as mine (192.168.0.1 instead of 192.168.2.1). Because of that (I think… because I’m not a pro in network configuration), DHCP server of the router of the final location is not attributing any IP address. I just don’t see the RPI in that router. I don’t want to change basic address of that router and have to change everything already connected just to add the Openhab setup.
Do you think this could fit my need following my previous post (replacing xx by the wanted address) ?
######################################################
# TEMPLATE: A different IP address on each network
#
# The arping address should be the router
# or some other machine guaranteed to be
# available. You need to know the addresses
# of the servers. If none of the arpings find
# an active machine then you will get a DHCP
# allocation.
######################################################
interface eth0
arping 192.168.2.1
arping 192.168.0.1
profile 192.168.2.1
static ip_address=192.168.2.xx/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1
profile 192.168.0.254
static ip_address=192.168.0.xx/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1
But If I use this, I understand the IP address will be static if arping find out a router on the network. What will happen if I remove static ip_address in both profile? Should I get an address from DHCP server if a router is found at 192.168.2.1 or 192.168.0.1 or it will not work at all?
Finally, I’m not sure if I should keep ‘‘persistent’’ lower in the script. It was there on the original script but I’m not sure to understand if it will interact with the arping and profile setup when I will change the RPI to it’s final location?
Be careful if you are using Stretch and have predictable network names enabled, this will change your interface name (eth0).
There are a lot of posts around the net dealing with this …
I faced almost same problem & problem resolved after fresh installation of Openhab 2.
I am not sure about why this problem arises in my previous setup, but it was started after enabling WIFI connection. So during fresh openhab setup I first applied statistic ip in dhcpd.conf file before doing anything else. & It works.
In essence, I had to replace /etc/network/interfaces/interfaces with /etc/network/interfaces/interfaces.dpkg-old, edit /boot/cmdline.txtand add net.ifnames=0 as boot parameter (to make sure your network interfaces are named eth0 and wlan0), and then add the following lines at the bottom of etc/dhcpcd.conf:
Where xx represents the last byte of the static IPv4 address I want to assign to the wired Ethernet link (eth0 interface), and <dns.ip.addr.1> <dns.ip.addr.2> represents a space-separated list of IPv4 / IPv6 addresses of domain servers you should use (e.g., as provided by your ISP).
In my case I know I can pick any value for xx in the range 2 to 99 as those addresses are not assigned by the DHCP server of my cable modem/router. And I have to use static IP addresses as my modem/router doesn’t expose static address assignment.
Should you not know the names of your network interfaces, then please run ifconfig -a.
Hmmm, I am confused when reading all the articles about setting a static IP for Openhab. I also need to set a static IP and search for a simple and stable solution.
Is 2.4 now using stretch out not and
when I would use your recommendation will this be overwritten when updating OH?
To my knowledge there are 2 openhabian distributions available, one based on stretch (does not support RPi4), one based on buster (supports RPi4). The openhabian-config script will help you select the openHAB release you’d like to use, irrespective of the openhabian distribution. Right now, you can chose between:
openHAB 2.4 stable
openHAB 2.5 milestone (currently M4) — I’d recommend this for new deployments
openHAB daily snapshots — only use if you want/need to test new features or new binding updates
If your home automation setup is critical, I’d say to leave it at the current openHAB release and use a second computer (RPi) to prepare the migration to a newer openHAB version (based on 2.5 snapshot).
I haven’t tried upgrading a stretch-based image to buster; instead I reinstalled a blank buster-based openhabian distribution.
)
