Wifi lighting: LIFX vs Hue?

G

geoffathome

New Member
I'd like to use wifi-enabled lighting throughout our new house we're currently building.
 
I plan to use my ip based system to integrate with security, occupancy sensing, etc.
 
So far I've narrowed it down to the following choices:
 
lifx.co
meethue.com/en-US
 
LIFX PROs:
* brighter (1000 lumens vs 600 for the hue)
* supposedly better colors
* built on an open/ip software stack (vs zigbee)
* no hub required
* much nicer control app
 
HUE PROs:
* made by an established company (Philips)
* slightly cheaper
 
Does anyone have experience with both systems or had a chance to do a proper comparison?
 
Thanks,
Geoff
 
Geoff, I've not used either of systems but the Lifi bulbs don't look like they'd work very well in a lamp (little light pointing down, most of the light up and some to the sides). Are there other bulbs? This is also a problem with Hue but it looks like to a lesser extent. I've been playing with the Connected by TCP and I like them so far. but they don't handle color and I think they work okay in lamps (I don't have this in my main lamp). They also have similar bulbs to the Lifi for ceiling lights).
 
I'd love to play with the Philip's LED strips but at $122 I won't be buying those any time soon.
 
There are also 2 other LED parameters, light color temperature and a percentage (sorry I can't recall the value).
 
I'm trying to figure out which way to go - none of them sound quite right just yet but I expect the market to evolve in the next year.
 
The LifX bulb seems OK but the distribution pattern is all wrong - maybe others can speak but I'll wait this out...
 
I have LIFX lights and they work fine. They are slightly big but they are bright. I've been told they are not Zigbee, but I think they use 802.16.4 mesh networking, which is the same physical layer of Zigbee.  They also contain Wi-Fi, but only one bulb connects to your Wi-Fi network, and it meshes to the other bulbs over the 802.16.4  (I believe). This means this one bulb should remain powered at all times.
 
I haven't done any lighting distribution tests on the bulb, but it seems to distribute light just fine. (Interestingly enough, the company I work for can do quite elaborate tests on LED bulbs, but I haven't seen the need to test this bulb.)
 
The negatives of the bulb is at this point, only some phone apps can control the bulb manually, and not much else. Also the bulb gets quite hot when at 100% brightness, but it is very bright.
 
i have 3 of the br30 hue bulbs, and three of the standard bulbs on the way from this deal (http://slickdeals.net/f/6664644-philips-hue-starter-kit-model-426353-for-149-99-or-philips-hue-single-bulbs-3-for-131-97-free-shipping?)
 
the phillips app isnt great but it gets the job done and I have not integrated it with the vera yet so i cant say how that works.  I was a little worried when when i got them that they would not be bright enough especially when using the colors but i have not been disappointed.  The construction of the bulbs is very solid, i feel like it would not do any damage if you dropped one and they look good installed.
 
I have not seen or used a lifx but i went with the hue because being a startup (and a kickstarter no less) I have no reason to believe lifx is going to be around in 5 years and further I have enough experience in manufacturing that I will be surprised if they do not have some quality issues now or once they have been in use a while.  
 
I didn't know you could integrate the Hue bulbs with a Vera.  That would be great if you could as the Hue only has an Apple interface.
 
I'm starting on a driver today. It's not quite optimal, in that (being basic HTTP) there's no way for it to send asynchronous notifications of changes (AFAIK), so they have to be polled. If you have 30 or 40 of them, it could be up to a minute before the automation would see a change made locally at the light, because they have to just be round robin polled, and from the bit of pre-driver experimentation I've done, it's not a blazing fast response, and occasionally longer than usual. Even half a second is very long time when you have to round robin through individual lights to get the status, if you are talking about using them throughout a home and having some tens of them. If one occasionally takes a couple seconds, that adds up as well.
 
And of course the more time the driver spends polling, the more likely it's out doing that when a command comes in to set a light, which has to wait for the current poll query to end. It won't be a long time, but even a second can make for a laggy feeling.
 
As long as you only make changes through the automation system it's fine, but with lights that's seldom the case. To be fair I'm doing this remotely, so some of that won't be there locally. But typically the packet speed even remotely is quite fast and the response time seen is reasonably indicative of actual performance, but we'll see.
 
I got a basic driver done today. It just provides two-way on/off control for each switch and outgoing ability to set the color, which is the core functionality that most folks would want. Some other things can be added over time if they are useful enough. The polling works well enough I guess, though it seems to sometimes respond very quickly and sometimes much less so. But, I didn't see it time out while I was testing, with a 2 second timeout. I just have it round robin polling through the list with a 500ms interval between each one.
 
To make it cooler I created a nice color palette widget which lets you interactively select colors on the touch screen, by just dragging your finger to the correct place in the palette. So you can just select a color, then have a 'set' button that just asks the palette widget for its currently set color, and writes that to the color setting field of the desired light. The palette can also send its current color on the fly as you make changes, not to the light, which couldn't accept them that fast, but to some other widget (probably a color fill one), to let you show a preview of the color you've selected.
 
I spiffed up the driver some more. Though it doesn't support 'dimming' per se, it uses the HSV color model, and the V of HSV is effectively a brightness level, so I provided access to just that component for dimming, and made the current HSV color readable as well as settable. There's only one use of it so far but he seems happy with it and says it's working well.
 
I have the HUE integrated with CQC.  So far in my small environment, the Hue bulbs seem to be working great.  They're plenty bright enough (compared to regular CFL) and we have a lot of fun with the colors.  Particularly being able to lower the color temp in the evening.  The hub makes it easy in the off chance we screw up and power off the light itself, the entire integration won't go down.
 
Right now I have 5 bulbs actually plugged in and working, w 2 light strips and 2 more bulbs hanging out waiting.  I figure (at most) I would add an additional 4 bulbs, and that would be after 'getting cute' with the bathroom lighting.  re: LIFX, I can't fathom a bulb that offers almost twice the brightness of the Hue; these seem brighter than any bulb I have used in the past including incandescent.  If you want me to test anything in particular or take any photos, just let me know.
 
Oh, the Hue app is awful, but there are (literally) dozens of apps that can control Hue, not to mention the CQC app for iOS and a custom template.
 
But you can take any of the apps, and listen in for ip commands over wifi, and write them into your automation, and not swap apps
 
You must log in or register to reply here.
Back
Top