Good morning. Wink refugee here. I've tried to read thru this and the "Lifx Local Control" threads, but the way the threads load, you can't easily search them, so I sincerely apologize if I'm asking something that's been asked many times already ...
I have three Color Candles (on window sills) and one Z strip (for bias lighting behind the TV). This Lifx app & drivers found all four lights. I'm able to start and stop all four reliably. I'm able to see their on/off status on the dashboard reliably.
But ... my biggest complain with the native Lifx app is that while I can schedule turning the lights on and off, I can not have them start in a certain effect mode, nor scheduled to switch to an effect. I thought it seemed obvious that a smart light named "Candle" with the ability to do special effects should be able to look like it's on fire like a real candle ... alas Lifx didn't agree.
So ... I think I saw in one of these threads that someone was looking into figuring out and hopefully getting effects working on the Tiles. Is there a chance that that code might work on the Candle Colors? I'd be willing to help test if you'd like. Thanks for reading all of this!
The protocol for the Candle Colour isn't well documented at the moment, they do seem to function like the Tile, but development for the tile hasn't really progressed much - partly due to LIFX stopping production.
It also doesn't help that I've not been able to get hold of a candle colour here in the UK, they've been sold out every time I've looked.
The new Lifx integration sounds awesome but it doesn't work in my setup. My hub is on a different subnet from my Lifx and so the hub can't find them. The community driver has a custom subnet option and I wonder if the same could be done with the official integration.
By keeping them on the same subnet and using broadcast discovery it facilitates ip changes gracefully.. The devices are identified by mac address and so if the ip changes it makes no difference. Also if a device is powered on between discovery cycles it can fallback to broadcast commands until it has a direct ip stored from discovery.
Why not just have a larger subnet?.. Or have a hub on the LIFX subnet? You lose so much flexibility and resilience by not having the hub in the same broadcast domain.
it was setup like that many many years ago, before I had Hubitat. But you will find many of us have VLANS for various reasons. Some have dedicated VLAN for IOT devices etc... I like the separation a VLAN provides from the main network. Like the previous user mentioned, I too had the community driver for a while and it had no problem finding the bulbs when you specified the custom subnet.
I have all my IOT devices on a separate VLAN, but kept my hub on my main VLAN because everything is working good this way. I have tons of devices and apps that point to hub's static IP and moving it over to the IOT VLAN would be a lot of unnecessary trouble.
I have 2 IoT VLANs - "1" for devices I kind of trust/regularly monitor and update (this is where my hubitat is), and "2" for ones I don't trust at all/don't actively monitor and update (this is where my Lifx are). "1" routes to "2", but "2" can't get to "1".
I have no desire for a single larger subnet, as the point in making the 2 VLANs was to segregate devices, as to me not all IoT devices are equal. So right now I just control my lifx devices on another system/hub.
No complaining at all, just providing another data point on why some may choose multiple VLANs over a large single subnet.
The protocol is fully documented by LIFX so i"m not sure what documentation you are asking for. The limitation seems to be with Hubitat support for broadcast discovery.
I'm able to start and stop all four reliably. I'm able to see their on/off status on the dashboard reliably. 
I thought it seemed obvious that a smart light named "Candle" with the ability to do special effects should be able to look like it's on fire like a real candle ... alas Lifx didn't agree. 
