Why Lifx support? Reasoning?

I see with the new 2.3 release Lifx products are supported. Forgive my confusion, but why? Aren't these things WiFi-based? I've been brainwashed for years now from Hubitat and members that WiFi is not for home automation. What's so special about these things that would redirect developers to focus on this?

1 Like

@eric10 In this case (and a few other rare cases) these products can be controlled 100% locally. No cloud involvement what so ever (except to update their firmware and you can even turn that off). They are lightning fast and very color accurate. Shelley is also directly supported by hubitat and they are wifi devices but as said, they're controlled locally. The issue with most wifi crap is that it's cloud based.

7 Likes

Ah! The Local benefit definitely makes good sense. Thank you!

3 Likes

And farking fast....

2 Likes

To add to the above, I wouldn't say Wi-Fi is inherently bad for home automation, but besides the fact that many such products happen to require the cloud (not all), saturation on a regular consumer Wi-Fi router/AP could be an issue, as some cheaper ones are reported not to work well for large numbers of clients. Filling your house with LIFX might still run into this issue.

But for me, a lot of the reason has been power consumption. Wi-Fi battery life pales in comparison to things like Zigbee and Z-Wave battery life. I don't think it's possible to get the 2+ years I got on my Iris v2 motion sensor battery using Wi-Fi! (And have I ever mentioned how much I regretted backing the Lockitron v2 on Kickstarter back in the day?) And to get a good mesh, you need powered devices, too. Add to that the fact that Z-Wave and Zigbee are mostly standardized and interoperable, and it's another win (I've used some of my devices on at least three different platforms; sometimes Wi-Fi devices don't have an API and lock you into the vendor's app/ecosystem, a problem LIFX obviously doesn't have).

On the topic of bulbs, most of mine are Hue, and I don't see this changing that. But I have tried a LIFX bulb and impressed with its color temperature (and color, but unlike CT, that's mostly just for fun) and brightness. Many are also a bit cheaper. Unfortunately, the lack of startLevelChange() and stopLevelChange(), which are important to me for dimming from button devices like a "regular" switch, means these are probably a no-go in most rooms for me--but perhaps others don't care about that as much as I do. :slight_smile:

11 Likes

Can you control the LIFX bulbs in the event of a power outage and power resuming so they won't come on in the middle of the night if a brownout occurs? Thanks.

My bulbs return to last state when power is restored.. If they were off the are off when the power is restored, etc.. But.. I think I remember this being configurable in the LIFX mobile app

1 Like

If that’s the only hold up for you, I can add that functionality..

6 Likes

Or you can.. Community drivers are fully supported in the integration :grin:

1 Like

I thought it might be a limitation of the bulbs! :scream: But good to know it might be possible (hopefully with something other than repeated level sets...).

I've got my hands full with Hue and only have one of these, so definitely not a big deal to me, but maybe it matters more for others.

3 Likes

Well the bulbs don’t have native firmware support for this like z-wave.. But it wouldn’t be hard to implement in software.

2 Likes

I've managed to approximate that using Node-RED; I use a Lutron Connected Bulb Remote to control a LIFX group in my nightstand (for level changes - up & down). Here's what the flow looks like. It should be possible to approximate this using Rule Machine - I'll take a stab at it over the weekend. Off course, using a Pico instead of a Lutron CBR.

Also happy to share the flow if anyone wants it.

4 Likes

I think this is just a wrong perception and in fact my (large) system is predominantly WiFi or preferably wired LAN, and is my first choice. I have around 220 IP devices and maybe a dozen Z devices. Matter / Thread is very interesting of course.

As Robert said above it has advantages and disadvantages, and anything cloud based is obviously a consideration you need to make. It's not good particularly good battery wise and so you'll find few WiFi battery devices but the radio / WiFi aspect of it I find way more solid than either Z mesh solution and when wired it's highly dependable.

If speaking about wifi, devices don't form a mesh?

Also on 2.4Ghz if you run separate radios for Vlans on your AP (as they're all on the same channel). 5Ghz support can't come soon enough IMO.

I did back LIFX at the beginning as it was invented by an Australian (yay) but the bulbs were bulky and ran hot in the early versions BUT they were also the brightest on the market for a very long while. Unfortunately in the current environment they're just too expensive. I only have one LIFX mini in service because no other bulb would fit in that use case.

1 Like

Not typically as they form essentially a star network from the main router via access points. However the newer mesh WiFi routers use a backhaul connection to be essentially similar to a mesh. The devices themselves don't provide any path (repeating) for other devices.

Large number of WiFi devices require more capable access points for more supported devices.

I think at one early stage it was touted that Lifx bulbs might 'mesh' together but I don't think they do that now... or do they ?

2 Likes

:+1: I was trying very hard to find a way to phrase my original comment! :laughing:

My understanding that they originally had some form of mesh protocol but that went away quite some years ago.

1 Like

I wasn't sure if you posted it as a question or a comment as it had a ? on the end...

1 Like

Trying to have it both ways .... sorry! :wink: I was trying for what my kids call "ironic" but probably failed miserably.

I think @bertabcd1234 meant that since zigbee or z-wave battery powered devices need mains powered repeaters to form a healthy mesh, for many people it makes the most sense to use those protocols for their wired devices as well.

1 Like

That's indeed what I meant--thanks! (I edited that sentence a few times and realize it's not clear, but the context is the "Z" protocols. Also note that I didn't say if I thought this was a good or bad thing, but it does have theoretical advantages. :smiley: )

4 Likes