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 255.255.255.0) regardless of what DHCP assigned.
It is impossible to assign a /23 (255.255.254.0) 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 192.168.11.253. 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).
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 255.255.255.0 is hard coded somewhere in the networking.
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 (255.255.255.0) 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.
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.
I thought that there was a way to allow additional non-public IP ranges access the hub? Maybe I'm going crazy? 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.....
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):
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.
Just came across my mind... custom subnet mask will not show in the app. App has 255.255.255.0 hardcoded, it's not getting the value from any setting. This enpoint should show the right values, though:
/hub/advanced/ipSettings
Maybe the app needs a bit of retouching here. It definitely is geared towards basic home setup.
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 255.255.255.0 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.
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 ...
.
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.
