LIFX Developer Zone

When a bulb goes "offline" why doesn't it try again?


I have 3rd generation bulbs and the same problem. Why my 6 wifi cameras are being viewed in a dashboard, the LIFX lights act like what you describe.


Same here. This is intermittent with bulbs. I have 12 bulbs (most color, so I’m not sure if it happens more or less for color vs whites, hard to say) and a led strip in my home. It’s a bit frustrating when all the lights in a group turn off but one.

These bulbs are not far away from the router at all. Flipping the switch off at the wall and back on typically does the trick…But that’s not a wonderful solution the more I grow used to not using wall switches (which I find strange, but that’s a neat behavioral observation).

PS: Super excited to find your API… I really want to dig into it and Google Home’s stuff if I ever get enough free time :frowning:


I got my first bulb a few days ago. Plan to build a house in the coming months and was considering buying a large amount of these but am also having this issue where the bulb disconnects from the wi-fi.

I have a support ticket opened but just wanted to also share my experience here. The bulb goes offline after a few hours and never reconnects without a power cycle. No other devices in the house have the issue. I tried everything from static leases. Forcing to channel 6. Shortening dhcp lease length from 1 day to 1 hour (just tried this today and they are online 3 hours.). Hopefully we can all find a common pattern in those that have the issue and a firmware update might then fix that.

I do think when the bulb disconnects, it should reconnect without a power cycle though. That’s definitely a firmware update that should be made followed by another update after we hopefully find the cause of the disconnects in the first place.



Check out solutions in this other thread – isolating the bulbs to their own WiFi Access Point: Raspberry Pi 2.4ghz Wifi Knocks Bulbs Offline?!?


The technology is not quite ready for prime time. It’s fine to deploy them in your house but you need a plan B that works even if you hub is down or you lose your Internet connection. Perhaps putting a conventional light switch so you can still turn lights on and off when things go wrong. It would also insulate you from problems in connectivity.

I’d recommend against an additional WiFi zone but if you do WiFi extenders (or meshing) you do want to make sure you can extend a secondary SSID throughout the house.


Yeah I think when you get to tens of bulbs all of these ideas of separate access points and mesh networks make sense. But there’s still fundamental issues with even a single bulb in my case where I only have 5/6 devices at any time connected to my router.

In this case no workaround should be necessary for the bulb to stay connected. I think the focus should be on figuring out why even a single bulb disconnects for some people. Working around it isn’t going to help the masses of people that will pick a new bulb today or tomorrow and have the same issues of it disconnecting where none of their other wi-fi devices disconnect.


I’m almost at my wits end with these bulbs randomly dropping off the network. They are unstable. I’ve tried them on several routers in two different houses with similar results. LIFX support just keep asking me the same questions. I’d just love my money back.


Yea, it’s pretty bad and I think it’s something that could be addressed through software/firmware. So I’m just hoping for an update here in the future that will fix it. It’s not like these bulbs transfer a lot of data and use a ton of bandwidth, I imagine more could be done with regard to health checks and reconnection attempts. It’s not a range/signal thing either as I have working bulbs sitting maybe 2ft away from one that went offline and all of them are close to the router (within 30-50ft). So I imagine it’s all software related.


I believe the dropoffs are due to interference from other devices on the same WLAN. My raspberry pi’s would knock off the LIFX when the pi’s would do a lot of network activity. Once I put the bulbs on their own access point, their own SSID, they haven’t dropped once.

But I agree – the problem is on LIFX’s side. They need to fix their hardware or software.


Can any of the LIFX Devs let us know if a reconnect feature can be added to the next firmware version. At least then the investigation as to why they disconnect in the first place isn’t necessarily as high priority as the disconnects might go unnoticed if they can power cycle themselves.


I would prefer that the figure out why the bulbs are still dropping for so many people. Please note, as in my previous posts, I have found that both my Echo and Echo dot control the lights perfectly almost all of the time. I look at the lights in the LIFX app (both Android and IOS), and they sometimes show offline and cannot be controlled even after an App restart or android/ios reboot, but more frequently, they show online but cannot be managed via the app. Both the IOS app and the Android app are essentially useless, and they often cause me to think the bulb needs a reboot, but then I ask Alexa, and she gets them to do whatever I ask.

Again, as in other posts, if you have a consumer router and more than 32 WiFi clients on a single bad, then this will be a problem. Netgear, for example, has a hard stop at 32 devices and then start refusing to dole our new IP addresses. That being said, the bulb should not have to ask for an IP every time and should use it;s last IP without a DHCP request if it is within the lease window. Probably not enough smart code on these bulbs to know what the lease and last IP are, though. Going to a UAP-Pro with USG as a router and only using Alexa and Logitech Pop has solved the vast majority of problems I have had with the bulbs becoming unresponsive…


I’ve had problems with the bulbs off and on since I started using the Gen 2s. Here are a couple of observations:

  1. The other day, we lost Internet and all the bulbs started rebooting the whole time we had no Internet. If the bulb is checking for connectivity to the cloud and if can’t reach the cloud it reboots in an attempt to re-connect, then this needs to stop. If I have no Internet, it shouldn’t matter since my home automation can control the bulbs locally via the LAN. What should happen is the bulb should periodically to see if it can reach the default gateway, and if it can’t, then reboot to try and get back on the network. If the bulb can talk to the default gateway, but not the cloud, don’t do anything.

  2. The Android app doesn’t work for me. When I launch the app, all the bulbs start randomly rebooting. I’m using a Cisco wireless solution (AIR-CAP3702e with a wireless lan controller) with multiple APs. I have created a dedicated SSID just for my smart devices removing all business features and limiting to 2.4 GHz only. I have noticed a couple of things: a) Trying to control the bulbs from the Android app doesn’t work. As soon as I launch the app, the bulbs start to randomly reboot and go offline/online. I might be able to turn a bulb off or on if I catch it before it reboots again, but it’s too unreliable. b) Impossible to do a firmware update with the Android app. The update starts, but the bulbs reboot causing a failure. Eventually, I have to power cycle the bulbs and sometimes they will go into Rescue mode and I can connect with a laptop to apply the firmware update. If the bulb doesn’t go into rescue mode, I have to factory reset it and then connect to the LIFX_xxxx SSID in order to apply the new firmware.

I’ve had a ticket open with support for months, but haven’t been able to figure out why the bulbs randomly reboot when trying to control them via the Android app.

Luckily, I mainly control the bulbs with my home automation system, Homeseer. It has no problems controlling the bulbs as long as I’m not in the Android app.


Try either turning of WIFI on the android app to force it to go via the cloud, or putting the bulbs and android on a separate VLAN so they are forced to use the cloud, and let me know if that works.

You are correct that if the cloud goes away, then they should communicate over the LAN, but the LAN protocol does not work and is a known issue.


Hi Matt, I remember seeing your post previously and thinking it would be highly unlikely that interference was the cause. Since then, I have made some discoveries and put my bulbs on a separate VLAN as the controller apps, and now they work 100% of the time. I figured, as you did, that they just can’t handle interference - but in a switched environment, that should not be an issue. Then it hit me - when I put the bulbs on a separate VLAN, my app could not longer reach them via the LAN so it must be going via the cloud. I suspect yours is the same. The cloud protocol works really well, as is evidenced by Alexa working all the time, but the LAN protocol does not work.


“Interference”? What does that even mean? In IP you can lose packets and need to recover gracefully. Here is also the issue of DHCP timeouts.

If a VLAN fixes the problems then there is a serious sub in the LIFX software.


I’ve written my own custom code that uses the LAN protocol. When the lights are on the same Wifi Access Points as the rest of my devices, they are unstable. When the lights are on their own Wifi Ap (but same LAN and subnet), they are stable.


Interference is the word Matt used, which indicated to me that Matt is a software developer, and not a network guy, and I saw no need to correct him because I knew what he was driving at. You could substitute it for “packet loss” I suppose.

My theory is that the only reason a VLAN solved the problem is because my lifx app is forced to use the cloud, instead of LAN protocol - which has proven to me to be extremely reliable and stable.


OK, now that’s really bizarre. I don’t even have a theory for that, Matt!


Matt, one question - is in instability there even when you use your own code with the LAN protocol?


Yup. If everything on the house is on 1 physical wifi access point, then the LIFX lights eventually get “sick” and stop responding to anything (whether it’s LAN protocol or Cloud/HTTP protocol) and eventually have to be power cycled. But they’re rock solid when on a separate physical access point (but again, same LAN and subnet). So for now I just have two access points on opposite ends of the spectrum (different SSIDs) and we make it work.