How do I add devices when LAN Discovery doesn't work on my /21 network? In particular, Lifx bulbs? I don't see a way to add the bulbs and set the IP address.
Do your discovery with the following fields empty:
Device name prefix
Worked for me…
I don't see any fields when I click
It could be that the Lifx driver doesn't work for /21
But it doesn't find the Shellys either.
How are you doing discovery?
I don’t have any wifi devices, but you’ll have to double check what devices are discovered via that option. I don’t believe Lifx or Shelly would pop up via that method.
You’ll want to take a look at this doc to see if your devices are listed. Should find instructions on how to join if they are - if not you’ll have to search the community to see if there are any drivers. (I want to say there is official support for some Shelly devices, but not sure about Lifx)
There's a driver for Lifx but it has a wired-in/24 assumption.
Is there any documentation on how the LAN is searched. If it's by enumeration then it cannot scale.
You could segment your iot stuff into a /24 while still maintaining a /21 and adjust your routes for access. That would solve your problem (unless you are going to have more than 254 wifi ip's
Why would I want to do all that complex segmenting just because Hubitat has a bug?
That said, I do have less 254 WiFi devices for now.
Developer documentation is here:
The hub docs underwent an update recently, but they’re not necessarily comprehensive.
Rather Hubitat does not have a feature you want... That doesn't make it a bug.
An unfortunate design choice on their part maybe, but this product is geared towards typical home users. And in 99%+ of those installs, the networks are /24.
Anyway, good luck.
Assuming /24 is bug ... it goes against my original design.
Assuming without verifying is a bug on YOUR part, yes. Lol
Anyway, us arguing semantics changes nothing. The product does what it does. Good luck.
I don't think it's complicated at all. Though you can certainly put in a feature request. Personally I would segment it and put it in a controlled vlan then let my firewall handle things (but then again for me that's easy) Admittedly i'm network engineer and ip routing tends to be second nature for me so in my case I don't look at things like that as complicated.
I think that has kind of been Hubitat's point in the past... If you are savvy enough to know subnetting and have atypical layouts, you are savvy enough to either make a new subnet or vlan or static routes to work around this.
Hubitat chose to keep things very simple for their 99%+ install based and not cater to the exceptions. It is ok to disagree with that decision (I don't really like it, for example), but it is what it is.
Never hurts to lodge a feature request though.
Fair enough....It's also not often you see someone running a whack 21 at home...
Presumptions about CIDR blocks generally cause problems. Perhaps not a bug, in the sense that it’s working as designed. But it is arguably a poor design choice.
That said, /21 is a massive block.
I don't want to get into a round about network architecture and the problems with subnets. I do regret I didn't insist on sticking with my original net 10 /8 design.
Understood. I think how the hub works has been well covered now, so hopefully you can work around that.
Even outside of what the hub does, there is still the issue of how the driver works. Lots of drivers just assume /24 too, so that may need to be verified as well - I don't know/use that particular driver.
Good luck getting done what you need to!
Ahh - finally found it in the LifxCode documentation
"Open the LIFX Master app and press the Discover devices button. You may notice the LIFX Discovery device in your list of devices, but this should disappear at the end of the scan."
The problem is that "Lifx Master" is not showing up in the app list hence my attempt to use generic discovery. It should all be updated using package manager so I'll have to ask @rob for suggestions
Sorry, no. If it assumes /24, then it's broken. That's not a "missing feature".
(I've been working on Internet protocols since the 80s)