Actually, your initial questions were:
It’s clear now that you want to turn off your router and want DHCP to continue working, but it wasn’t in your original post.
Regarding your first two questions, it’s logical to me that the Conbee binding updates to the Pi’s latest IP address when a new one is assigned by the DHCP server. Otherwise, the connection would fail every time the IP changes, and the majority of users would not like that at all. So, I would see it not as a bug, but as a feature that just doesn’t happen to work well in your unusual scenario.
Regarding your third question, the simplest solution is to keep your router turned on. We’ve established that you don’t want to do that.
The second simplest solution (if it works) is to set the static IP on your Raspberry Pi, per my other post and @ubeaut’s instructions. Hopefully this works when you test it.
The third solution I can think of is to move your DHCP server onto your Raspberry Pi. For example, you could install Pi-Hole and use its DHCP server for your network. It’s not recommended to run other software alongside openHAB, but it’s a solution that would probably work. Of course, that could introduce other problems in your network that are even more of a headache.
You can find discussions about connecting Pi-Hole to openHAB here, but if you want help with installing and configuring it, you’ll have to look elsewhere on the Internet (there are lots of articles).
The fourth solution would be to submit a feature request to the binding developer in GitHub asking for one of the following:
- add a checkbox to prevent the binding from reacting to IP changes (so that you can set it to localhost permanently)
- have the IP default to localhost when there’s no DHCP server available
You would need to communicate that the change is beneficial to more users than just you, but again, most people don’t turn off their routers regularly. In a power outage, everything is off. If you’re rebooting your router, it’s only a few minutes of downtime. So, I can’t see a developer agreeing unless it’s a super easy change to implement (and I have no idea how easy/hard it would be) or something they think has broader utility. Also, there’s still a chance that this isn’t the actual problem, and you’ll be right back where you started.
So there you go. #1 is the guaranteed-to-work scenario that you want to avoid. #2 is the best-case scenario if it works. #3 will probably work, but requires more effort on your part. #4 may or may not be accepted by a developer, may or may not solve your problem, and may or may not take days/weeks/months to be available to you.