I was able to get this working on OpenHab, but most things in OpenHab are a pretty big lift and anything interesting often involves text editing and manual config. Thanks for giving this a go!
Just ordered a Hubitat hub for a studio with lots of LIFX bulbs. Looking fwd to trying Rob's code. Fascinating to see things developing in the community like this.
1 Like
It's getting close to being right, still one or two things that need to be worked on a bit more.
Latest version works pretty well with all bulb type devices, no support yet for Tile, Beam or Z Strip, but they will come with time (Tile may take a while as it's quite complex).
3 Likes
Great experience. I really like the discovery approach. The app found all but one of our bulbs on the first scan sequence and the remaining bulb turned up with a tap on "Discover only new devices".
We are about to add ~30 LIFX bulbs to our network, so the timing is perfect. (We also have the LIFX LED strip and a Tile; looking forward to support of those too.)
Thank you.
Rob has a repo. Code last updated yesterday. It is beta though (but doing really well)
Also check out the other thread Lifx support out of the box
2 Likes
I'm still not sure why it sometimes takes two attempts to find some devices, there's very little consistency in what works and what doesn't, which is strange since actually controlling the devices seems to work more than 99.99% of the time.
Tile may take some time, definitely a complex device, but the latest version does let you turn it on and off 
I'm hoping the strip will work the same as the beam (which currently can only be turned on and off), so they should only need the LIFX Multizone DTH. I only got my Beam this week so that's the next on the list.
This is great! thanks @rob!!
Quick question: I can see that the app is able to see the groups.. obviously we can always make a new group device in Hubitat.. but is there a possibility of a Group Device type for LIFX?
Yes, there is, I just need to work out how to build it. It's been on my list for a while now, and possibly also one for locations.
Although there was a hint from one of the LIFX engineers that it may be possible at some point to allow a device to be in more than one group, which would be very handy. I guess it depends on how much memory is free in the devices themselves. I don't think there was any timeframe given for it though.
Great - thanks for all your hard work on this.. Having LIFX local control has been on my wish list for years!!
another thing to add to your roadmap: it would be great to be able to set a transition period for all changes.. not just colour map.
Thanks again
I'm also considering a proxy device, which would delegate to the real device. The idea being that you'd reference the proxy in your rules etc. and discovery wouldn't wipe out the proxies - this would also allow for IP address changes and substituting in a replacement bulb in case one broke.
This could be done with virtual devices I guess, but I'm not sure how that would work with e.g. Tile
All my LIFX bulbs have a static address on my network and I'd recommend that people do that if they can because I've found it helps a lot with their stability
2 Likes
It's been a bit of a slog, but it's working fairly well.
The default colour map transition time preference actually now applies to all transitions where a duration isn't specified. I should probably change the wording
Great!
How are you finding the speed of this? - for e.g. it seems a little sporadic currently. If I hit on/off the light will respond anywhere from instantaneously to 5 seconds, when using as part of a group they all turn on at different times.
I find that for a single device it's virtually instantaneous 100% of the time so far, but you're right about multiple devices. Not sure if I can do much about that, there's a lot going on in the background.
It would be nice to have a high resolution timer available to work out how long it takes to build a packet. Then I could perhaps see if it's worth caching the packets for a given command and payload rather than rebuilding them every time.
I'm sure there must be something undocumented that happens with the HTTP API to allow a group to be treated as one device.
It's possible that UDP packets are occasionally being lost I suppose. I request an acknowledgement for each packet that modifies state, if another packet is sent (such as polling for the state of the device) before the ack is received then it will attempt to resend the previous packet just once. But I would expect that to take potentially up to a minute, rather than just 5 seconds.
seems like a good idea for the roadmap!
1 Like
I'd recommend holding off until tomorrow at least - I've made some changes to the discovery process, it now discovers all my devices in the first pass, over 95% of the time. I need to make a few more tweaks, but it seems pretty solid - going to try it on my new spare hub tomorrow though (and make sure that it works when you have two hubs as well).
1 Like
Okay, the github repo is updated with better discovery, and a new LIFX White driver in addition to the LIFX White Mono driver.
2 Likes
