It's not you, it's the App

It’s not the LIFX bulbs that are the problem, but the Android LIFX App. I found the app is responsible for unresponsive lights.

I own about 15 LIFX bulbs. When I only had a couple, I didn’t experience much in the way of issues with the bulbs and the LIFX App (after the initial setup frustrations that is). It was after I expanded the system that I really began to have issues. I thought maybe the router was the issue. I bought another router and flashed one with DD-WRT and the other router with Merlin. I still had issues with lights randomly not responding. So much so, I thought I had some bad lights. I had contacted support and was processing a return. If that didn’t work, then I was going to return the entire light setup.

I bought the LIFX bulbs with the Google Home device in mind. When my Google Home device arrived, I set up IFTTT to control the lights. I now control the lights mainly through the cloud via IFTTT and not the App. I now have zero issues with the lights themselves. The lights that would, on a daily basis, refuse to respond, or respond then go offline to the app have worked flawlessly with IFTTT. This tells me the issue is with the Android LIFX App and not the bulbs. The only issue with IFTTT is it can be sluggish and if the internet is down, the control of the lights through the Home device will not work.

So, in short, I have spent almost $300 in additional equipment to get the bulbs to work when the App has been the issue the entire time. The LIFX developers need to re-look the app. If the App had functioned correctly, I could have saved myself the purchase of a new router. The Google Home device was why I purchased the LIFX bulbs but they don’t work correctly without it.

It’s not the app. I have the same issue. LAN control is 50/50 and Cloud is 100%. Support acknowledged it is a known issue. Take a look at this thread.

Maybe I do need to return the bulbs not reporting on the network then.

Same problem and I can repeat the issue 100% of the time. All 5 of my bulbs work perfectly from the cloud. When I use wifi on my phone to control the bulbs its extremely sketchy, some bulbs will respond some of the time, some wont at all, some will respond only once or twice out of 20 attempts. I turn wifi off and everything works as it should.

I didnt have any of these issues until sometime this summer. I stopped using the bulbs for the most part but finally got around to calling support and going through the process - knowing that it was going to be a long drawn out process of troubleshooting - and it has been. About a month of router testing and changes to settings, bulb resets, etc, and the issue is still not resolved. So very frustrating having had them work perfectly and now they are completely unreliable.

Would be nice if I could just go back to cloud API in the lifx app. I will try IFTTT although my experience in the past has been it has been a little sluggish and you also loose granular control, maybe it will just get me by until LIFX can resolve this massive issue they have.

1 Like

It’s not the app, because I’ve tried:

  • Official LIFX android app
  • Lampshade app in Android
  • LIFX Tasker plugin in android
  • AutoLifx in android
  • IFTTT integration
  • directly calling the LIFX cloud API from Eventghost
  • Windows 10 app

NONE of these work for me more than like 20% of the time.

REX: I don’t think you loose any granularity in IFTTT, you can specify commands in each applet (AKA recipe) at least that I remember. I personally had a script that sent Maker requests to IFTTT in such a fashion as to emulate a color cycle - so I do think you can do a lot with IFTTT.


I have definitely found that restarting my android app is sometimes helpful. I run that on a tablet mounted in the wall. Same with iOS. However, my real problem was that the netgear r6400 consumer router I have only support 32 simultaneous wifi clients per band. So 32 on 2.4g and 32 on 5g. It doesn’t just get slower, but rather it does not accept any connection from a 33rd device. So instead of trashing my router altogether, I purchased a ubiquity uap pro access point for $127 and connected it to my router, which supports 250 clients simultaneously. Since then the lights have been stable almost all the time, I have had only a few occasions where a light is not responding and fixed by turning the light switch off and then on again.

1 Like

I’m definitely having issues with the App. I can control the lights fine with Amazon Echo or with IFTTT. But every time I start the app both of my lights go offline, then come back. While they are offline nothing can talk to them - neither the app nor the Echo work.

I did some experimenting and found that the light sends out an ARP request, then stops functioning for 70 seconds. After 70 seconds it sends a second ARP, then everything works.

Because of the way my network is setup I was only seeing half of the conversation, so I don’t know if the first ARP was answered or not. I’ll have to do some more experiments.

At this point I suspect that the real bug is in firmware, but the phone triggers it. I suspect the ARP isn’t being answered, and the light goes out to lunch waiting for a reply. I’ll post more details if I get them.


Long term with your router… If you add a lot more devices, thought the AP can handle a ton of clients, you will run into issues with your router being able to handle a lot of them. Before switching to the Ubiquiti EdgeRouter, my regular router had issues going above 65 wireless clients, once I offloaded the wifi to Ubiquiti APs, it was fine, then I crossed 85ish devices (wired / wireless) and the router couldn’t handle that many. Just an FYI for the future.

1 Like

Thanks. After a month, I decided to go full on with the UBNT gear, and am now using the Ubiquiti Switch and the USG as my router. Everything with LIFX works great when using Alexa or Echo to control them, but the android and IOS apps from LIFX are still useless. It bogles my mind how Amazon got it so right, and LIFX gets it so wrong.

1 Like

Yes, LAN control is crap for these bulbs. Works 100% through the Echo or Smarthings for me. App, not even close.

Agreed. Everything comes back to the LAN protocol. However, I was surprised when you said smartthings is 100%. That has not been my experience - the only thing I have that works 100% of the time is the Echo / Echo Dots. I was under the assumption that Smartthings uses the LAN protocol because of my spotty experience.

At any rate, LIFX needs to resolve this issue ASAP. They are losing customers in droves because of this failure to fix the problem after all this time. If Hue had decent colors, I would have made the switch long ago.

One idea I had - VLANNING the android controller so that it cannot access the bulbs over the LAN, and must go out over the internet instead. I’d like to try this while having cellular completely turned off on my Android. Does any one out there know if this would work?

i.e. Will an android without any cellular access automatically switch to the cloud protocol and go over the internet to use cloud if it cannot reach the bulbs on the LAN? Or will it just not work at all? My fear is that the LIFX app just does a check to see whether internet is coming via WIFI or cellular and make the decision of which protocol to use based only on that.

1 Like


I should have said that SmartThings is likely 100% because I use device handlers that I wrote myself.

1 Like

Another update. I created as separate VLAN just for IOT things in my house. I added all the LIFX bulbs to the VLAN, and then tested. Voila - the android and IOS apps using LAN protocol worked fine. In fact they worked flawlessly.

UNTIL… I put my iphone or android on the same vlan as the bulbs. As soon as I do that, it does not work. I have tested over and over again.

Conclusion: 100% certain that the LAN protocol is the problem. I have not put a sniffer on the network to verify that in fact the apps automatically switch to the cloud when they cannot get to the bulbs over the LAN. But there is no other explanation, and I see no need to waste time with a sniffer.

In summary, if you want your bulbs to work 100% reliably, then make sure your app cannot reach them on the LAN. One solution is to turn wifi off on your phone every time you walk in the door, or my solution of making the bulbs only accessible via the cloud by segmenting them with a vlan.

I recommended to LIFX support that they beef up their cloud infrastructure, and put a button on the app that says “Always use cloud protocol.” Even if people lose internet access and can;t control the bulb for a while, it is still better than what they have now. LIFX us going to go out of business is they do not come up with a very fast fix for this very simple problem. Word is getting out that the bulbs don’t work, and I am afraid that this GREAT product will go belly up because they don’t have the resources to fix the LAN protocol.

1 Like

I think you’re onto something here…
In my setup, the bulbs are all scheduled (with Stringify / IFTTT) to come on and off daily so I rarely have to control them with the App manually, however I have noticed this recently as I’ve added more and more bulbs:

Bulbs behave and work with the schedules daily - scheduling commands are driven from the Cloud so this suggests the internet and cloud connection is not a problem.

When using the App, I open the app and see a few bulbs appear as offline - Quit the App, restart and they reappear. Or if you do nothing, the schedule will still turn them on/off which suggests they are not really offline, but the App just thinks they are.

Or another scenario I’ve seen. The App shows the bulb as ON but in reality its off. Pressing the on/off or changing a color in the App, does nothing to the bulb, but the App thinks its controlling it. When checking the bulb properties, it shows as Wifi signal good and Cloud connected. Go figure. The daily schedule will again, have no issue in controlling the bulb.

Finally, I turned on a single bulb in a bathroom a month ago and haven’t since then. Every time I open the App, it starts off by showing that same bulb as On and full brightness. Wait 5-10 seconds and then it changes to its proper status of OFF. Its like the App has cached the previous bulb status and keeps showing it.

These inconsistencies with what the App is telling you and what the bulb is actually doing need to be resolved as a priority.

In contrast, manually controlling the bulbs with Logitech POP switches that also use the LAN protocol has not been an issue other than to say that “sometimes” one out of a group of 4 bulbs may not get the message to turn on. So you have to try a second time.

1 Like

I appreciate all the work you did but I already spent a ton of time and came to the same conclusion…

Like I said, using SmartThings with my custom device handler is pretty much 100%. I can’t remember the time one of my 46 bulbs didn’t turn on.

Moses, can’t you teach the LIFX developers what the problem is with their LAN protocol, or does your device handler use the cloud protocol?

@Rooster - I can’t. My ST handler uses the http api. I might make a LAN version this winter.

However, since the latest firmware updates my lifx bulb have been fine on the LAN. I understand that not everyone sees the same results.

Bummer! Glad it’s working for you now! I’m gathering data for my support ticket now, as I unfortunately have not had the same experience with the latest. May I ask the mix of bulbs you have? I have the gen2’s, and am wondering if there may be a difference based on the bulb series.

I have 49 bulbs.

4 - LIFX Z
2 - LIFX Color BR30 Gen3
5 - LIFX Color A19 Gen2
38 - LIFX Color BR30 Gen2

I have 5 APs in the house.

As an example on this, I use lifxLAN to control my bulbs, if I do a search for bulbs it finds all of my gen 1 bulbs no problem. the Z either does not appear or causes the code to crash.
It appears that the Z bulb (gen 2 may be same across the board I am not sure) has issues with the wifi chip-set. I know Google told me that the bulbs and here I assume it is the Z is continually asking for a new DHCP address even though it was already given one.The Z will first respond correctly to lifxLAN then it will cause it to crash as data packets were not received or just dropped and finally the Z appears to reboot the wifi and it connects again.

The continual re-request for a DHCP address is causing my Google WIFI units to fail and this is something Google is looking at but yes whilst 1.22 firmware is an improvement it would appear it is a patch to a fundamentals flawed product chip-set. If LIFX does upgrade the Z hardware I am going to be requesting a replacement unit.