Static IP Address and DHCP Support for non /24 Subnets

I am surprised that there are not more people having issues with the fact that the Hubitat hub insists that it's in a /24 subnet (from setting screen: Subnet mask is fixed at regardless of what DHCP assigned.

It is impossible to assign a /23 ( static IP address and even though it accepts is IP and gateway address properly, it ignores the subnet mask.

This is a problem when I have tablets used to control hubitat with static IP addresses in the range of 192.168.10.x and my hub is at Hubitat thinks that they are remote (not local) and the Hubitat app is treated as untrusted (and wants a VPN).

This was already mentioned in a 2019 Feature Request, but it didn't get any attention because the author wasn't clear on what issues were caused by this bug/limitation. Road Map and Vlan Support


You can assign a fixed address in your router. That is what I did for my devices from back before I had even heard of Hubitat. Assign the IP address to the device MAC address.

Thank you for your reply. My issue is that Hubitat doesn't recognize that 192.168.10.x is in the same subnet as 192.168.11.x when using a /23 mask. It is a matter of what the hub's software is treating as local. The networking surprisingly works, I'm just unable to use the Hubitat app on my iPads because it thinks they are on a remote (non local) network. Decent security feature, but only if the hub uses IP networking properly (per the RFC).

1 Like

Try this endpoint:

Then power-down the hub, and re-power it after a minute or two.


No change other than it now says static IP. It still doesn't allow the /23. I have tested this before and found that DHCP is the only way to give it the /23, but it still changes it back or never accepts it. It's like the is hard coded somewhere in the networking.

Here is a screenshot of my static IP setting.

I also found this thread where another community member points out the bug/limitation.

The interesting thing is that the network stack still works with the larger subnet; at least when using DHCP to assign the mask. In this setup, the hub has no issues communicating with local, remote, or internet systems. The only issue is that it will treat some devices in its local subnet as remote because they are not in the same /24 ( subnet. The reason for my feature request is to add support for a user selected subnet mask so the hub knows what is in its local security zone.

I can only guess at the reasons why this has been reported but hasn’t made it high enough on a priority list to change.

But I think for a very large percentage of home users, there is no need to expand beyond a /24 subnet.

I don’t mean to suggest it’s not a legit request, but mainly that I’m not surprised there are not more people having issues with this.


They prioritize features based on the widest need in use cases versus the development effort to implement.

The overwhelming majority of home users use a single full class c subnet, or multiple full class c subnets.

I don't know what the current status is of supporting larger, or smaller, subnets. It may be on the list, it may not be on the list, depending on the amount of development effort versus the number of customers that need it.


It's just an extremely poor implementation. In fact, they can't even legitimately claim to support IP networking. RFC1122:

A host MUST support the subnet extensions to IP... 

A host MUST support the first, and MAY implement all three,
        of the following methods for determining the address mask(s)
        corresponding to its IP address(es):

        (1)  static configuration information;

        (2)  obtaining the address mask(s) dynamically as a side-
             effect of the system initialization process (see
             [INTRO:1]); and

        (3)  sending ICMP Address Mask Request(s) and receiving ICMP
             Address Mask Reply(s).

If you know what you’re talking about, I’m sure that’s true (and I don’t doubt you, since I’m just one of those home users that doesn’t really understand subnetting very well anyway).

And yet, it apparently hasn’t prevented them from becoming a surprisingly notable force in the DIY home automation markets of several countries in only three years.

And they’re not even a part of a multi-national mega-corporation.

So they’re still doing something right :man_shrugging:.


I thought that there was a way to allow additional non-public IP ranges access the hub? Maybe I'm going crazy? :thinking: Although kludgy, a workaround may be to send the /23 via DHCP and add a bogus subnet entry for the neighboring /24 into the hub.

Having native IPv6 support would be nice too, but I'm not holding my breath.....

1 Like

@gopher.ny Wanna chime in?

1 Like

There's a direct endpoint without /24 limitation for those who know what they are doing.
The endpoint is /hub/advanced/switchToStaticIp, and it accepts the following query string parameters (names are self-descriptive):

  • address
  • netmask <- use for /23 subnet.
  • gateway
  • nameserver


Are you sure the suggestion in my previous response, which is reiterated by @gopher.ny's response, didn't work? I have used something similar for someone else's C-7, and it worked.

1 Like

Just came across my mind... custom subnet mask will not show in the app. App has hardcoded, it's not getting the value from any setting. This enpoint should show the right values, though:


Maybe the app needs a bit of retouching here. It definitely is geared towards basic home setup.


Yes, this was noted by you when you first described the endpoint. But the netmask settings definitely stick.

1 Like

I have both optimistic and less than optimistic feedback. Per the great suggestions of @aaiyar and @gopher.ny, I was able to confirm that the ipSettings are correct using the URL parameter method to set it up. I have also confirmed that the message on the Networking settings page is always going to read regardless of what the actual setting is.

Unfortunately though, my iPad Hubitat app still thinks it is connecting from a remote network. I was optimistic that the subnet mask was the issue, but perhaps not.

1 Like

Try this endpoint:

I think that should fix the issue.

Also tagging @gopher.ny ...


Both app and hub are within a private IP range, so that shouldn't matter.
The issue may be in the app's logic that decides whether hub is local or not. Tagging @moncho1138 ...

1 Like

Ahh ... so if @brian9 were to use Safari on his iPad then it would work fine ....