Inconsistent network naming?

We have 62 LIFX lamps, are trying to troubleshoot why some keep disappearing from the network and one thing we’ve encountered is inconsistencies in the network names. Some will use ‘LIFX-GU10-Macaddr’ while others will use the name that we give the lamp (which is preferred for finding them). All are on FW: 3.6.0.

The settings for these all appear the same. Nothing there that I can see that would cause this. Some lamps were setup differently (per instructions from LIFX Employees) due to some problems we were encountering. I can’t find my notes on which these were and if there is any correlation but even so there s/b a difference in settings.


Yeah, if you ever work out why this happens, let me know. I had a range of theories based on how the light is onboarded to how it got named via HomeKit vs the LIFX app, and all my theories seemed promising until one bulb would go and do the wrong thing.

Eventually I just gave up trying.

1 Like

So, the names you see here are the “friendly hostname” of the device as part of mDNS. It’s formatted by using the RFC1034 version of the bulb’s label.

By default it’s the RFC1034 version of the bulb’s SSID (the network name that shows up when it’s been factory reset)

There is a difference between older and newer LIFX firmware that means with older firmware, changing the accessory label in Homekit itself wouldn’t change the hostname on the network.

When you change the label of the device in the app or programmatically, we are using the LIFX protocol and that should be updating the hostname. It also is possible that changing the device’s label via the LIFX protocol might not be updating the hostname, and that would require some investigation to work out why.

How have you been changing the labels of these devices?

All of these lamps were purchased this spring and all are on FW 3.6.0. The names were either set during initial adoption or in the LIFX IOS App under Light Settings / Device Name.

Edit: To add a bit more detail… Some of these were onboarded w/ the HomeKit procedure but when LIFX failed to work with that we’d let them timeout to the LIFX procedure to onboard them. All have consistent Device Names consisting of two-letter code for floor level + room + specific descriptor within the room.

I’m not quite the same as LD1: as you know, I have a broad range of bulbs from the Original Kickstarter all the way up to the Candle Colour. They’re all on the latest available firmware for their generation.

I have some (like the Candle Colour) that will not change their hostname no matter how often or how I change their labels. Others as I mention before will change their hostname.

Can you please recheck your information as this doesn’t seem to track with my (or others) experience. I likewise have over 45 bulbs and MANY do not contain the bulb LiFx name in their mDNS response/host name.

Config: all bulbs current (2021-05-06) FW: v2.8 or 3.6

iOS app current: 4.8.1 (per in app help/info)

Specifically bulbs with issue are 2.8 (ie last gen current firmware)

Test scenario 1:

  • Edit/rename bulb name in Lifx (iOS app). Bulb name shows changed in app. Result: No effect on hostname (Confirmed at WiFi AP AND via by network scan
  • Restart bulb Using light switch. While turned off confirm bulb “went dark in app” and via network scan. When bulb was energized . Result: No effect, on hostname (Confirmed at WiFi AP AND via by network scan

Test scenario 2: (reset bulb and try clean add). Reset 3 bulbs via, THEN did factory reset (cycle power 5 times). Factory reset confirmed as bulbs present in WiFi ssid scan AND color change cycling)

  • option 1: Set up a Factory reset‘ed bulb via HomeKit network device setup. This “allows” me to name the bulb and on-board it to my WiFi network. Result new hostname NOT presented though network scan (still Lifx mac suffix. Then setup bulb in Lifx app AGAIN naming bulb. Again change not visible on net. Restart bulb by powering off, then waiting a couple seconds and power on. STILL bulb name unchanged.

  • Option 2: Add bulb DIRECTLY via app. Complete Lifx cloud setup, and check on network. **Again bulb name not present in network scan ** Add bulb to HomeKit via Lifx. Again Bulb name not presented in network scan.

  • option 3 Add bulb DIRECTLY via app. Connect to bulb as an ADHOC Access Point. Then in Lifx app add bulb after telling app bulb not present. When done again look for bulb on network before and after power cycling. **Bulb name not presented **. Add bulb to HomeKit DIRECTLY by adding new device with code. Again name entered in HomeKit (to replace Lifx MAC) *IS NOT PRESENTED ON THE NETWORK *

In short what I THINK happened. As a long time owner of NUMEROUS bulbs purchased over 4 yrs+ (with MOST BEING previous generation)… What you wrote MAY have been true at one time (with regard to previous gen bulbs) As mentioned I have just shy of 50 bulbs on my network. 7 of them have names I CAN NOT NOW SET (as documented above). My guess as an engineer myself you BROKE the Lifx API in your recent firmware update. If not then I have 7 bulbs I want replaced as defective because they CLEARLY are as there is NO WAY TO CHANGE the bulb host name.

Thank you for your assistance.

I see label as hostname for my LIFX Beams, Tiles and Downlights and one LIFX Mini D (fw 3.6.0) and I have no idea why or how I got that bulb to change its hostname. None of the rest of my LIFX Mini or Mini D bulbs do.

And the hostname is definitely the LIFX label because it had a typo in it that wasn’t in HomeKit. Though, I may have typo’d when adding the bulb to the network.

I have changed the label of the bulb and power cycled it and it’s still advertising its old name, not the new label, so it got set during provisioning/onoboarding somehow.

Hello, some versions of the firmware did change the hostname based on the label. However we learnt that this introduces a number of complexities around character encoding and newer versions of the firmware no longer do that

Once again. How do I modify the host name (using your API, application or ANY method)??? AT THE the very least if you are shipping a HomeKit certified product support the HomeKit onboarding process. As I showed in my test you are NOT respecting the values entered as part of Device configuration done ENTIRELY outside of you app…

Quite frustrated not only at not being able to update the hostname, but at the hours spent attempting to do it using the information that Lifx POSTED here, and we all expected was correct till I SPECIFICALLY called your firmware out as being defective.

  1. When are you going to fix the firmware to RESTORE functionality of the product at purchase?
  2. Second how do I install the OLD firmware that actually DID set the hostname correctly?
  3. I am a network engineer and KNOW how to name hosts appropriately (I actually worked on DNS, and while at Apple with those responsible for ZeroConf/Rendezvous/Bonjour so PLEASE believe me when I say I can set mDNS names, just tell me how.


I asked one of our firmware engineers and unfortunately there is currently no method for changing the hostnames sorry.

  1. Will you bring this functionality back?

I’ve passed on this feedback to the product team

  1. Can I install an old version of the firmware?

We don’t offer the ability to rollback firmware.

I actually worked on DNS, and while at Apple with those responsible for ZeroConf/Rendezvous/Bonjour

Oh cool, that sounds awesome.

Out of interest, what do you currently use the hostnames for @BikeDude ?

Actually I didn’t see a clear response to the bulbs/firmware being out of compliance with HomeKit, which when on-boarding the bulb (independent of your app), allows me (normally) to assign an mDNS hostname. You firmware (defectively) seems to disregard that value when it’s passed to your device as part of network-onboarding and pairing for new devices.

While I understand users may request names that fall outside of the zeroconf spec, there are APIs in Mac/iOS to obtain a sanitized/safe name space device name. Regardless of that it’s simple enough to filter character values to (at least in this country to alpha numeric a-Z and 0-9 + dash and underscore. Have you developers look at Bonjour - Apple Developer and HomeKit - Apple Developer

Timing to fix

  1. So it is confirmed that this is NOT desired functionality, and a fix will be forthcoming?

  2. ETA? Hopefully A LOT shorter than nearly 2 year wait for the promised adaptive lighting support since this is a clear regression in functionality and relatively simple as the functionality was intentionally removed. It SEEMS like you just need to filter on character strings to ensure valid input. While it might be nice to offer a simple way to just rename the bulbs already deployed, I (and perhaps others), could even live with reseting the bulb to factory and re-onboarding as the quickest & simplest path to market for the update though bonus points for eventually adding a developer API to do this (at some FUTURE date). Once again I will add my willingness to test release(s) that support either app or API based bulb naming or even the mythical adaptive lighting support you previously mentioned in other threads.

Bulb naming.
I name bulbs with the -<fixture, if appropriate>-. For example Kitchen-Overhead-1, Kitchen-Flood-3, Downstairs-Hall-6. Given the ~ 50 bulbs this is the only way to keep track of this number of bulbs, MACs, and HomeKit codes, and dynamic link local addresses. Also simplifys using bulbs with LOCAL/on-net third-party applications and integration.

Well that how I number those OTHER than the 7 Lifx default named (aka unnamed) bulbs that remain, and inspired my original post in this thread. I also have a smattering of older bulbs with spaces in the bulb name in place of a the ‘-’. While not consistent with my standard, they do allow me to understand what the bulb is, and don’t cause any problems on my network as I don’t actually send commands to them by DNS name. Of course they would’t be considered valid as pure DNS naming but then again I can’t exactly change them so…

I can’t make promises about this feature. The product team is now aware of it and have added it to the list of features/improvements that need consideration moving forward.

In the meantime, I’m curious what programs you use that rely on the mdns hostnames of your homekit devices?

I can’t answer for @BikeDude, but I used to use it to more easily verify the fixed DHCP lease has been assigned to the right bulb, as the UniFi Controller displays the mDNS hostname (if available). Now I have to manually alias all my bulbs.


For us, per my OP, it’s mostly a matter of knowing what’s what when trying to do general management tasks or debug problems. That I have to have a sheet of paper printed out with a list of the LIFX names such as ‘LIFX-GU10-55D144’ along w/ what they are ‘LL-Gym-NE’ is antiquated. This is stuff we’d have to do back in the 1980’s.

However, this raises a bigger concern of the general quality of management and direction for the company and of code development. This is a pretty basic thing that LIFX isn’t getting right. And that it’s not consistent on top of that - it acts one way with some lamps and another way with other lamps that are all the same GU-10’s purchased at the same time running the same FW versions.

1 Like

I think the previous 2 posters covered my thoughts perfectly. To summarize (in my case, as I think they also stated), to allow network professionals, to use the professional networking tools they typically use to administer and troubleshoot network issues (adding or managing services/application/devices) on their likely larger, and more complex networks (multiple segments, domains, etc).

For example: I have significant integrations set up between many of my bulbs and physical light switches that send network events (on net) via shelly relays to turn on and off the bulbs (rather then switch line voltage). Amongst other things it allows me to produce 3-way switches through software and many other truly cool things in software like Home Assistant. My next effort when I get time is to use a circadian rhythm docker container to provide adaptive lighting for my Lifx bulbs via on (tcp) net events given the unfortunate delays in corporate support for the function.

Think of our use as acting in the role and perspective of a Network Manager rather than a consumer with 5 bulbs, and a smart switch that they simply want integrate into HomeKit/Google Home/Alexa.

Hopefully that helps? Honestly as I said we are a “small” minority of your total customer base, however I suspect we may own a disproportionate number of your products (per customer)… Just a guess.

1 Like

@delfick-employee, were there any updates on this feature?

Edit: Okay, they left the company. @BikeDude did you find any way to set the hostname in the end?

Unfortunately not.

Without any clear notice or introduction I found I was VERY kindly added to the Lifx’s TestFlight group.

Given worked at Apple for 13 years and managed engineering/product teams for years I take confidentiality serious even if it isn’t explicitly asked for. So with that said let me be clear that I have seen nothing from Lifx on name ing that has me assuming the feature request ever moved beyond the stated Discovery stage mentioned in the original post.

Unfortunately I have seen precious little in terns of ANY development from Lifx on the software side and even less on the hardware side related to ANY of the Edison screw in products (A19, BR-30, mini’s, etc). The only exceptions being the “clean” bulb which for most has no value given required Dev trade offs that make it useless for most home fixtures as an upgrade for the A19, and of course the package redesign that seems designed to “refresh” the shelf appearance of the products while reducing cost of production.

Wether by intent or neglect Lifx seems to have given up on anything other than their dedicated/embedded RGB panels and strips, choosing to abandon the market for “legacy” fixture lighting to other companies in China and of course Philips. Consumers tend to but these on cost and they likely decided to focus efforts on a market segment where the believe they can innovate/differentiate and thereby maintain the margins they one had in the profits WE still care about.

The unfortunate telling story if you read my posts is that when buying a 20 year bulb (like ANY product with a projected 20 year lifespan (at the price points we paid then) you NEED to seriously consider the company track record and how long they have been around AT LEAST as prominently as you consider the feature set otherwise as has happens countless time in the past you end up with orphan proxies the become functionally obsolete LONG before their expected and often ADVERTISED lifespan.

I wish I could be of more help perhaps someone at Lifx will step up but learning the person here from Lifx that appears to TRY to help left the company seemed simply like more of the same thing we have been seeing which stated OVER A YEAR before COVID-19. The company was sold and the rest is history. Despite promises and hopes by many inside and out I think the best we all can do is cut OUR losses, learn from the mistakes and help others not to make the same mistakes in the future (aka my comment about purchase decisions above).

Best of luck…

yeah, I moved on in July

Best of luck and though I stated it above (and in other posts), thank you for all you did and tried to do. It was a bright light in the almost complete darkness that has been LIFX support and Product Management.

(Yes, pun intended) :+1: