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 
.
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.
Yes, this was noted by you when you first described the endpoint. But the netmask settings definitely stick.
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.
Try this endpoint:
http://192.168.11.253/hub/allowSubnets?192.168.10.0
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 ...
Yeah sounds like the app itself not recognizing the extended subnet
I have good news to report. The combination of fixing the subnet mask and allowing both the 192.168.10.0 and 192.168.11.0 subnets got me working. For reference, I used https://192.168.11.253/hub/allowSubnets?192.168.10.0,192.168.11.0 to ensure that both were included.
and I used...
https://192.168.11.253/hub/advanced/switchToStaticIp?address=192.168.11.253&netmask=255.255.254.0&gateway=192.168.10.250&nameserver=192.168.10.10&override=yes
to set the static IP, mask, gateway and DNS.
I sincerely thank everyone for the attention and support they provided, it was great!
On a related note, is there a list of all the "endpoints" that can be configured through URL parameters?
Thanks!
Got it. If you're successful you can be wrong and get away with it. Enjoy your world, it's not one I'd want to live in.
That’s not what I said, and we live in the same world.
I’m going to guess that for around 99% of its intended customer base of home consumers, this is a non-issue. Whether or not the hub adheres to a technical standard for basic IP networking.
What? Is Hubitat hardcoded to a /24 network? Even with a DHCP assigned configuration?
I mean ... that can't be right. This is a product for DIY tinkerers and geeks. Surely it actually has a correct implementation of the IP stack, and respects DHCP?
I use a /16 network for various reasons (work and non-IOT home-lab stuff means I easily consume an address space larger than 254). If Hubitat is perpetually locked to a /24 network I need multiple networks and custom routing. Is that really necessary?
Can someone confirm this? I just spent two days trying to identify why certain IoT WiFi devices fail to work correctly with Hubitat. I need to to know if Hubitat is actually non-compliant with basic ethernet standards.
No it isn't. While you cannot configure the subnet mask via the platform gui, you can configure it to be whatever you want via an endpoint.
For details, read this post:
Also, while the mask will change to whatever you want, it will continue to display as being /24 in the gui, but that display bug is irrelevant to its function.
No, DHCP works as it normally does.
Static IP assignment has a UI page where /24 is locked in, but there's also an endpoint to set subnet and other parameters without built-in nanny, as @aaiyar mentioned.
Download the Hubitat app
