Lifx support out of the box

Well restoring back to an old backup seemed to work. Not sure why but I will take it.
Thanks for the help :slight_smile:

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. :+1: I'm able to start and stop all four reliably. I'm able to see their on/off status on the dashboard reliably. :+1:

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. :disappointed: 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. :frowning:

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!

There is some lifx support in webcore if you want to try that.

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.

hmmm ... the package says 120-240V 50/60Hz ... would a bulb sold in the USA work in the UK?

As far as I know they're universal.

I did some work on Tile/Candle Color - see this branch on my fork: GitHub - dkilgore90/lifxcode at candle

I haven't touched it in a while, and I don't own either device - so it's all theoretical code, likely with some bugs...

Feel free to take it for a spin, though - and let me know what does/doesn't work!

1 Like

Thank you! I've got some time off this coming week, so I plan to play with this. (fingers crossed)

Hi Rob... just wanted to see if there was any progress on the custom groups?

FYI...The built in Lifx integration is now available in the latest version. Check out the release notes here:

3 Likes

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.

2 Likes

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.

2 Likes

same here... with over 100 lifx devices I also have them on a separate VLAN...

1 Like

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.

3 Likes

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.

1 Like

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.

1 Like

Similar setup here.

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.

1 Like

Now that LIFX is officially supported can I report the problems with detecting devices on my 172.20.0.1/22 as a bug?

This would be nice to add in some official documentation somewhere.

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.

Download the Hubitat app