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
(3) sending ICMP Address Mask Request(s) and receiving ICMP
Address Mask Reply(s).
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):
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:
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.
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.
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.