And the ColorPlus driver has the same line
Ah, well spotted
I don't think I have, I'll add it to my list 
I gave it a go again trying HE groups but the speed of response calling a group compared to calling lights directly is just too big; responsiveness is the same as the old lifx GOG for me and popcorn effect on a group compared to direct call is really bad. I get why you say use groups but compared to Hue bulbs which were instant which I had before lifx, it kind of takes the shine away from lifx even though, in my opinion, they are better bulbs than hue
1 Like
I haven't looked at the Groovy implementation since I mainly use my own. In mine I overlap all the UDP calls rather than waiting for each one and the lights turn on more or less simultaneously. Why less? Perhaps lost packets -- I haven't fully investigated but do automatic retries.
I presume the Groovy driver is similar but perhaps not. Note the groups are not part of LAN API -- they are part of the cloud implementation. Given that broadcast is not reliable and multimegabit networks are not the bottle neck it makes sense to send message to each and handle response.
1 Like
My own -- actually it was based on another code base and I converted it to TypeScript with async. It's still very much a work-in-progress at bobfrankston/lzlan. If I were to rewrite it from scratch I'd do it differently but it works well enough for my own use and by not committing to it as a stable interface I"m able to experiment.
There was some discussion about using the bulbs MAC address instead of IP to avoid having to assign static IPs but I just wanted to share that I had to change over a faulty bulb with little config change in the LIFX Master App. I changed a Color 1000 to a Color Plus bulb and assigned it the same static IP as the faulty bulb. All I had to do was change the driver that was assigned to the old bulb record to the Color Plus driver. Thats it.
If we were using MAC addresses, I assume we'd have to rerun device discovery for "new devices only" again and as device discovery has proven very hit and miss with my 75 bulbs, I avoided having to rerun it. I have 2 bulbs remaining that simply won't show up and I've run discovery more than 30 times over the last week or so.
Speaking of discovery -- I continue to have problems with bulbs not getting IP addresses. Have others been having this problem?
I've got a mix of the original GU10s, Color 1000s, and newer Plus models, never had issues getting an IP from my DHCP Server using reservations.
I've abandoned the idea of using the MAC address, for much the same reason.
I'm intrigued by the 2 bulbs that aren't showing up, what kind of bulbs are they?
You mean when you add the bulb using the LIFX phone/tablet app? The only reason I know of for that is using a modem/router that has an artificially low limit on the number of devices
There are 3 ColorPlus (A19 +) bulbs of which 1 was discovered finally after many attempts but the other 2 just won't show up. I had all 3 part of a Lifx Group called Backyard with another 5 bulbs in the group (all discovered). I then moved the 3 into their own group to see if it would make a difference but no. The new group was listed in the discovery process but thats it. 73 out of 75 discovered.
Just a side note, with the number of bulbs I have, I have nightly scenes that include most bulbs and the popcorn effect is terrible, to the point where I've decided to keep using IFTTT and activating the scene from Lifx directly. I will likely only use the LAN drivers for direct control from wall switches on a per room basis. How does LIFX themselves eliminate popcorn effect when they send commands to so many bulbs at once? Really wish Hubitat supported LIFX natively... but job well done Rob to get us this far, amazing effort.
I'm guessing that LIFX may use multiple threads - I have a number of ideas for improving performance, but I need to find the time to implement them.
When you refer to "LIFX" are you referring to the Groovy implementation? The wire protocol itself treats each bulb independently so the concept of threats doesn't apply.
As far as I know the only Groovy implementation is mine. I'm wondering whether the LIFX app talks to the bulbs using multiple threads.
Threads aren't quite the right paradigm. In my JavaScript implementation, there is a single thread but it's asynchronous in that the code doesn't wait on the messages and it responds to events. Is that how your code works?
I'm limited by the way that sendHubCommand() works. I think it's asynchronous, but there may be some overhead.
Although the most recent version of the Hubitat code has an ignoreResponse flag that I've not played with yet, no idea whether it will help until I try it.
This is one reason I'm using node as an environment. It complements Hubitat for me.
