Sigh. Again - IN YOUR OPINION. That does not make it fact. Shouldn't have to explain fact vs opinion to people.
It was a design decision. One you may disagree with, but it was a conscious decision. Aka, not a bug and not broken versus their design.
2 Likes
Sigh. Sorry, that's not an opinion. That's a developer making a shoddy implementation (e.g., "bug ridden").
1 Like
Which is YOUR OPINION. Get the difference?
It is an opinion BY DEFINITION.
Look - I'm not going to argue basic word definitions with people. Put your emotional response/preconceived notion of right/wrong to the side, and go look up the definition of the words fact and opinion. It may be enlightening.
Again, I'm not arguing it was a good or bad design decision. That is a different topic/OPINION altogether. I'm arguing people throwing around the word "fact" for things that are not indeed facts.
5 Likes
This is why I didn't want to get into this but I do have to point out wiring in /24 is a bug (doing this since the 60s and specced home networking.
That said, I do appreciate anything the developers do to facilitate supporting devices. This is a common error that comes from learning by example. I had to fix it in a Lifx library in JavaScript. I can understand the reason if Hubitat doesn't make it easy to listen to broadcast messages thus leaving few options but polling and scanning all addresses.
This is why I want a plan B (as with Wiz) to just add the bulbs explicitly and update the IP address using the MakerAPI.
1 Like
holy crap, this seemed to devolve into semantics
afaik, HE isn't going to expand past /24, so it may just be a limitation of the equipment for you
being coded for /24 and working on /24 means it's not a bug, it just doesn't fit your environment. if it was coded for /24 but was only picking up /25, then that would be a bug
at the end of the day, you want this to work, so just try different things.
do the bulbs have fixed IPs? can the hub even reach the device? i'm able to ping across multiple different /24 networks using my HE and that works with no problems. confirm connectivity before trying to degrade the platform
1 Like
Do you understand how IP addressing works and how discovery works?
As an FYI, I took the code to support setting IP address from the Wiz driver and passed it on to Rob. I would've debugged it but not sure about the build environment.
1 Like
Is that still in the docs? The LIFX Discovery device hasn't been used in ages.
If it's not showing up in the app list then there are two causes.
- You didn't install the app
- You didn't click
Doneto install the app
The second of these is a documentation fault - my latest local version of the code checks to see if it's installed and won't let you attempt discovery until it has been.
" bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." (Notice, nothing about design or scope errors.)
How can a feature not even included in code have an error, flaw, or fault?
Not including a feature might be (in your opinion) a bad decision, but hardly a bug. No different than a car manufacturer deciding to only support Apple Play connectivity and nothing else, that does not constitute a bug.
3 Likes
It's not in the docs, I didn't realize I had to go into the App. As an FYI, I left sample code as an issue comment on Github. I would've tested it myself, but I wasn't sure how to taste it, but it seems very easy to implement. Tell me if you have any questions.
I presume you can't implement the LIFX broadcast on Hubitat, but one option would be to use the HTTPS interface to get the list from their services. All you'd need is the access token. While it doesn't provide the IP address, I can use a JavaScript app the look up and set the addresses. I depend on Ubiquiti to do the lookup, but I'm going to look at programs like arpscan - npm (npmjs.com) so see I can do an implementation that can run independently of Ubiquiti.
Oops - when I said "not in the docs", I meant not listed in the doc which means it's not supposed to work. I just want to clarify the ambiguity. I don't have an easy answer other than, perhaps, Hubitat listing all the supported devices when doing the scan. I had just assumed ...
Since there seems to be some confusion, I want to clarify for the readers that /24 isn't a thing, it's just an arbitrary setting. We're used to the 256 limit because that has been the default for consumer use but, even then, 192.168 is actually a /16 space ( Private network - Wikipedia. One side-effect of /24 being the common configuration is that it's small enough to scan so implementations get complacent.
I'm forced to be aware because I'm a tad ahead of the curve but once your light bulbs are Wi-Fi and other devices that limit will seem quaint.
1 Like
I'll take a look at github tomorrow. Although I'm not going to reconfigure my network for it, so I wouldn't be able to test it either.
Yeah, the LIFX broadcast is currently a no-go because I can't set up a socket to listen for UDP packets - that would have been my preference.
I'm not keen on using the MAC address when sending a command since that means constructing the packets to be sent every time, although it would be possible to just update the MAC address field I suppose, however that wouldn't play well with my current test implementation of LIFX groups.
That's a good point about /24, the Limitations section of the doc should be updated to reflect that.
Out of interest, what are your IP address ranges?
First, I'm using 172.20.0.0/21 for the moment. Changing from my personal class C was painful because of static addresses and, unlike 192.168.. I couldn't expand it because it was indeed limited to being a class C.
I'm not suggesting you use the MAC address -- just that by having it available I can do my own MAC=>IP translation and use setAddress via the MakerAPI.
Turns out MAC=>IP is more difficult than I expected. I just did a dive into RARP and what I found is disappointing and, alas, deprecated.
Even if I do a broadcast ping it only gets a subset of the addresses. The only reliable way seems to be to rely on the DHCP server managing the table. For Ubiquiti I can get out it via an undocumented API used by the Unifi app.. If this is kludgy that's only because it is.
As an FYI, the reason I want to use your driver is that, while mine works (* -- well, LIFX broadcast isn't that reliable) I want to use the Hubitat settings screen when I go beyond simple settings.
I've just had an idea that may help, but I'll have to have a play with it first. It depends on how getMACFromIP() functions when there is no MAC address associated with an IP address, if it fails quickly I can do a pre-scan of all IP addresses in a range and filter out the ones that don't return a MAC address. This could be used to optimise the initial scan and also to remap the deviceNetworkId for known MAC addresses. If, however, it takes a while for the function to return then it would probably end up being a non-starter.
I'll play with it tomorrow.
Is it feasible to simply use the http API. I don't like to depend on external sources for day to day operation but it's fine for initial setup and discovery.
The real challenge is MAC=>IP but I can do that on my end. It's OK if you don't do it for networks above /24. It would be a documented limitation rather than a bug 
since there is a work-around.
Potentially, yes.
BTW it seems that getMACFromIP() returns fairly quickly, taking 1.3 seconds to scan the 254 addresses that I normally use - that includes filtering out any non LIFX MAC addresses.
The interesting thing is that this actually reduced the number of devices found on an initial scan, possibly because there was more successful traffic between Hubitat and the LIFX devices, which makes me want to revisit the way that the scanning is done.
If anyone has code (in any language) that can determine the range of addresses for an e.g. 172.20.0.0/21 network that would save me a lot of time.
Potentially this could also be used to rescan for a LIFX device that has been allocated a new IP address, and repair it automatically.
I'm not surprised that MAC from IP is fast since that's just ARP.
As to getting the range, or the address mask. I see a way to get the local IP address but no way to get the mask.
You're now getting into the issue of IP support on Hubitat including not being able to use DNS names rather than IP addresses. including not providing a name for DHCP and/or support mDNS. But that gets emotional pushback so I've dropped pushing for it.
All I really need is to be able to work out the IP addresses from a xxx.xxx.xxx.xxx/nn.
I'm just being lazy but given that I'm not willing to reassign all my IPs just yet some working code would be useful since it'll be tricky to test.
