DHCP failures without retyring

When my DHCP server is failing or when there are Wi-Fi problems LIFX seems to get a 169.254 address instead of retrying as per the spec. I have to manually power cycle. This is a serious problem with many bulbs.

I’m surprised given how common this problem should be. What is happening and is there a fix?

1 Like


Are you able to open a support ticket if you haven’t already (mention this thread and the email of your LIFX account) and then DM me the ticket number and I’ll get the firmware team to have a look.

1 Like

Not sure of the DM mechanism but I have sent email and just submitted a trouble question(?). This does seem to be a straightforward failure WRT to the standards. What’s surprising is that, after all these years, it’s still an issue.

I ran into this with another product after I had a DHCP glitch recently so went to look at the spec and found the retry requirement. Even better, though, would be V6 support with link-local addresses.

If you click a person’s avatar there is a "message’ button where you can send private messages.

I think I found your ticket, but I’m not sure, I’ll start a private discussion with you.

I’ve experienced this before as well many times. In my case the problem is if/when the bulb is disconnected from Wi-fi it doesn’t always renew the DHCP lease again when it reconnects. My understanding is that it should do so. It is much worse with older generations of hardware.
IPv6 support would be very welcome - I can use it and test IPv6 now too.


The problem is getting worse and my wife is complaining about lights not working. Is there any progress in figuring out why this is happening and fixing it? I can understand DHCP hiccups, I cannot understand why the retry isn’t implemented.

Perhaps I need to speak directly to a developer if LIFX is to avoid a #737MAX problem.

As per


If DHCP is not successful, it waits five minutes before starting over
again. Once DHCP is successful, the autoconfigured Link-Local
address is given up. The Link-Local subnet, however, remains

Hi Bob,

We are really sorry about the ongoing issue with DHCP, we understand this is really frustrating and affecting your day to day. We have logged the issue with our team and done an initial investigation. It has been added to our roadmap of fixes, however due to our capacity we may not have a fix for you in the near future.

That’s incredibly sad to hear. Been having issues with mine as well and as a result been slowly replacing my bulbs with hue’s instead.

This is a show stopper issue. If you can’t support the bulbs do you have a plan B?

And it’s getting significantly worse for some reason.

It seems as if the app is depending on the IP address not the MAC for identity so when a device gets a new address it appears to be a new device.

Also I noticed

Changed Br2mWall from to

(Reported by my monitoring software). How did it get a 153.47 address for a while before reverting.

I realize there may not be developer resources which makes it imperative that LIFX tell us more about the OS and software in each bulb if we are to trust them. Otherwise there is a large risk in depending on LIFX.

While on the topic, the last is a quick 169 and return which pleases me but I’d like to understand why

Any update on this? I have this issue as well.

I notice that the bulbs now retry fairly quickly so, while not perfect, it has vastly improved.

1 Like

I would also add that for a multi-AP (Unifi and the like) solution, turning down the power on the 2Ghz (mine were on high) to med (or around 18-19dBm) makes a huge difference where APs can no longer reach bulbs without enough power to properly connect back. e.g. several of the old DHCP like issues were actually that the WiFi communication was one way vs bi-directional due to over powered APs.

Agreed. I actually turned my APs down to low (~9dB) and get better coverage.

Here we go again… For no apparent reason, 3 of my bulbs are not retrying DHCP requests and are very low db and all bulbs around them are fine.

This problem sounds very familiar …

Lifx bulbs now renewing their lease

The only fix I currently know if, physically turning the bulb off and then back on.

What router are you using?

I got the same issue:



Unifi USG-3P
Unifi AP AC Lite
Unifi Controler (Dockerized)

It was working flawless until last week. No changes made so far.
The problem only occurs with the Color 1000 Bulbs, all my MiniColor are working fine.

@LIFX please give us a fix!

What firmware are you running on your UAPs? Ubiquiti have been pretty active with updates recently (including quite a few beta releases).

I’m running on my UAP-QCA devices and on my UAP-MTKs using UniFi Network Controller 6.0.41 with 55 LIFX devices and DHCP is pretty flawless. I haven’t seen a DHCP issue for a while and I’ve been doing fairly regular power cycles (for other reasons). The bulbs also happily survive controller outages.

Likewise, I highly recommend a dedicated SSID for your LIFX bulbs that has all the UniFi provided options disabled except for Unscheduled Automatic Power Save Delivery. I’ve found that to be the most reliable configuration for my fleet.