Give the hub a static IP?

📢 Feedback
1

Can this be done? When I restart my hub the IP address changes.

2

My recommendation for managing static IPs within a home environment would be to set them within the router DHCP management interfaces.
That way, maintaining all your home IPs would be possible through one single interface and you can even manage IPs for devices (like Hubitat) which do not expose their network setup for configuration.

In the current scenario, once you set the static IP on your router, probably a power cycle of the Hubitat Hub followed by an updation of its registration with the cloud (via the settings page) should ensure that you get a static IP working with your hub.
A related discussion was happening on the thread linked below…
https://community.hubitat.com/t/best-practices-for-migration/84/139?source_topic_id=644

2 Likes
3

For some routers, after creating a static DHCP reservation, you may need to reboot the router as well to have it “forget” the original DHCP lease that it assigned to the Hubitat hub.

So, the process would be something like:

  1. Shutdown the Hubitat Hub in an orderly manner
  2. Create the Static DHCP Reservation for the Hubitat Hub (you’ll need to know the MAC address of the hub)
  3. Reboot the Router
  4. Restart the Hubitat Hub
2 Likes
4

True, although any router worth its salt will refresh when you save changes to the reservation list. Usually only the client that needs rebooting.

1 Like
5

Good point! I had missed that.
This is especially true if you swap existing IP addresses and want all the devices to adhere to the new reservations,

6

A word of warning: Not all routers are equal, and not all router owners are experts. One user attempted to change the hub’s IP address to static, and managed to cut off the hub from the cloud due to routing problems. Change your router settings with caution, and only if you really know what you are doing. The hub relies on DHCP and a properly configured router to get to the Hubitat cloud.

When in doubt, leave it be. You can always find your hub IP address through portal.hubitat.com. Also, in most circumstances you will find the web interface at http://hubitat/ in your browser.

6 Likes
7

I am running a newish version of AsusWRT-Merlin on a new Asus RT-AC86U. I know the firmware I am currently running does not flush the DHCP lease when a conflicting static reservation is created. So, I figured it might help others ensure a clean DHCP lease table and avoid any unnecessary frustration.

I am pretty sure my old Asus RT-AC68U, running even older AsusWRT-Merlin did work as one would hope. The 86U runs a much newer flavor of AsusWRT, with a lot more closed source binaries. Perhaps Merlin cannot ‘fix’ the behavior any longer?

2 Likes
8

That’s terrible. No warning, just allows a conflict to be saved?

9

True that.
Should have mentioned this as a word of caution for users not familiar with managing router settings :+1:t3:
BTW, the http://hubitat/ or http://hubitat.lan address never worked for me, unless I registered the hostname on my router.
Other devices like my NAS seem to work fine without requiring any such registration on the router side, Never quite understood why,

10

This is my point exactly: Routers come in all flavors and exhibit unexplainable behavior to anyone but an expert for that router. My router finds http://hubitat/ as the host name after some time with no intervention.

1 Like
11

Yes, but the conflict doesn’t cause any real harm. Once the lease expires, the static reservation takes precedence. I may upgrade my firmware to see if Merlin has corrected this.

1 Like
12

This is exactly what caused the cloud to be unreachable on another router. As I said, not all routers are equal. Tread carefully.

3 Likes
13

I think I'm the:

One user attempted to change the hub’s IP address to static, and managed to cut off the hub from the cloud due to routing problems.

Or could be, I did submit a ticket on exactly this topic... :slight_smile:

Because this is getting some attention I will go ahead and outline what MY problem was... Highly Technical

I have a Linux server doing just about one of everything, including DNS and DHCP. DHCP has been running, untouched for at least 3 years (except for adding Reservations.) Yet I found that the Hubitat AND one other device I attached this month, were NOT finding a default gateway in the DHCP response.

The problem turned out to be options I'd added 3 years ago:
#option rfc3442-classless-static-routes code 121 = array of integer 8;
#option ms-classless-static-routes code 249 = array of integer 8;
#option rfc3442-classless-static-routes 23, 10, 6, 0, 10, 5, 5, 10;
#option ms-classless-static-routes 23, 10, 6, 0, 10, 5, 5, 10;
(they are commented out now, but weren't "yesterday".)

I also have redundant DNS and DHCP and when THAT server responded first, the default route was seen with no error. Thus when DHCP was supplying un-reserved addresses it happened to come from the lesser used server (thus faster) and didn't have the "option ... route... " lines. When I added in the reservation, that dhcp response came from the primary and included the option(s) that broke it.

This of course was already fully summarized by: "When in doubt, leave it be. " :smiley: In my case however, I had to make that 3 years retroactive!!

1 Like
14

At Lutron technical support, where the vast majority of people calling in are well trained and experienced technical installers, 85% of their problems are networking related, or so I was told.

We’ve discussed this internally, and you can see why from a support perspective it’s a nasty problem. One of our own people was complaining one day that Alexa couldn’t find his devices. It turned out he was running two ISPs, and hub and Echo were on different networks. It happens to everyone who ventures from the straight and narrow!

Lutron has a simple solution for their installers: bring a simple router along with you, and put your laptop and the main repeater on their own subnetwork behind that router. Then you won’t have any problem with it. Ha! Like that’s going to work for a customer base.

I guess in some ways we are vulnerable to this issue since everything is local. That’s a heck of a crazy reason to run off to the cloud – that you can get there but you can’t get to devices on your own LAN.

1 Like
16

May I suggest some additional output on the Settings page? Had it taken me less than a day to figure out the hub couldn’t “escape” my network, I would have avoided creating a support query, because clearly, it was all my fault/problem to cure.

Or perhaps even an entire “Diagnostics” page where pings and other network “clues” can be displayed… so that when a support query is made, those details can be copy pasted to the email and several “try this…” cycles can be shortcut. Will save the support staff many hours, I bet. :slight_smile:

17

As a network engineer for many years, I believe that home networks should rarely not use static IP Addresses. Even servers in the home should use DHCP. Instead of using a static IP address, use the router or DHCP server to reserve an IP for the device that need a static address. the reason is that your device will always get an IP address, even if you replace your router, and it will not conflict with other DHCP assigned devices. Effectively achieving the same result, but in a very dynamic and manageable way.

Just my two cents.

3 Likes
18

I wasn’t aware we had a choice. DHCP is the only means that Hubitat Hub has to get an address, unless I missed something. Therefore “DHCP reserving” is the only means to give it a long term predictable (static) address.

1 Like
19

I get the, “will not conflict” part. but if your replace your router, your devices won’t be automatically assigned the same IP addresses, because the reservation tables were in the router you just replaced! :wink:

I can see a reasoning for wanting to use a static IP, since your device would always have the same IP and if you replace your router (in theory), then your devices would still be reachable at the same IP. The reality, neither is perfect, because if you buy a different brand of router, and they use a different address range, you would have to also make changes to either the router’s DHCP IP range or the device’s static IP.

I do agree with DHCP reservation vs static IP. It does limit the chance of accidental IP conflicts, and if you always assign the same IP in your router’s DHCP address reservation list for your devices MAC address, you’ll always be able to find it at that same IP as long as you have that same router in place.

1 Like
20

I don’t have a “small home network” as you describe. I have a much more complicated need, exacerbated by a heavy fascination. My DHCP is on a pair of computers, not router. It’s redundant and part of a much bigger environment that includes an ASA firewall and 3 switches scattered around, even an oscilloscope here at my elbow. :slight_smile:

I have no risk with changing routers since my DHCP isn’t located there… but your point(s) is correct for everyone else with an ordinary small home network.

21

I wouldn’t trust a router to provide dhcp either.
(Apart from the fact that my networks are behind different firewalls and on different subnets)
Yep, stand alone redundant dhcp servers are best (hell, you can even use a couple of cheap rPi if you don’t have other servers)
Having said all that most of my permenant kit have static IPs
I have a mind that says if it doesn’t move why should the IP.

Andy

1 Like