LIFX Developer Zone

LAN documentation conflicts with latest firmware

The “What’s in a LIFX message” documentation states:

The target field represents the MAC address of the device. This is also known as the device’s serial and appears as a hex number of the form d073d5xxxxxx . When you address a device you should left-justify the first 6 bytes of the target field with the MAC address and then zero-fill the last two bytes. You should set this value to all zero’s if you want to broadcast a message to the network.
The replies you get back from devices will always contain the MAC address of the device sending the reply. So for example if you are discovering devices, the StateService (3) message will tell you the serial for each LIFX device on your network.

With firmware 3.70 and higher, the serial of the device is no longer the same as the MAC address of the device, so this needs to change.

Does this imply having to handle newer firmwares differently with 3rd party libraries? I’m asking as an occasional maintainer of GitHub - node-lifx/lifx-lan-client: Canonical fork of the number one Node.js 💡 LIFX LAN protocol implementation. and one of it’s dependants GitHub - ristomatti/node-red-contrib-node-lifx: Node RED nodes for controlling Lifx lights.

Both are actively used by many and I have not been particularly happy with my maintenance abilities due to lack of time. So far this has not created too much issues as even new products have worked with little to no changes (for the basic set of features supported). This got me worried of a potential flood of issue reports…

Which products use this firmware? None of mine* seem to have newer than 3.60.

*) Models LIFX Original, LIFX+, LIFX Mini Color/White, LIFX Z Light Strip (1st version), LIFX GU-10, LIFX Tile

All of my LIFX Minis have upgraded, but I’m in the beta firmware testing group. My LIFX Clean and LIFX BR30+ also updated.

For most libraries, this has zero impact because the bulbs are discovered via broadcast and then targeted via IP address, not MAC address. However, it’s noticeable with Home Assistant, because it uses the serial as the unique identifier, not the MAC address. When they were the same, this enabled mapping of devices to network entities. This no longer works.

1 Like

I am afraid this could break some features in my app and would like to test that. Is there a way to install this 3.70 beta firmware so I can make sure everything is working correctly before it is rolled out to everyone?

In my app I am using the “target” field as a unique identifier for the light. Do I understand correctly that this value will change? Or does it stay the same? Or in other words, is the target still the mac address? If this value changes with the 3.70 update it will break my app and I would need to fix it.

The target field stays the same, but the actual MAC address used by the device changes. I’m in the HueEssentials Test Flight (though, I admit, I haven’t tried it recently). If there is a particular function or feature you want me to test with the new firmware, send me a message.

1 Like

Thanks Avi. The app only reads the target field so if that stays the same then all is fine. It does not read the mac address or compare it or so. And for the HTTP API it reads the light “id” field (which in the current firmware is equal to the target).

There isn’t a specific feature that is affected. I was more worried that if the target field changes, the app would see all lights as new devices. But looks like that is not the case which is great to hear.

Thanks a lot for the quick response, I appreciate it.

You’re welcome. I’ve made a note to grab the latest HueEssentials Test Flight build while I’m on leave next week to take it for a spin.

1 Like

@Djelibeybi Would it be too much to ask you to also test if Node.js library lifx-lan-client is affected? It’s used at least by the Node-RED plugin node-red-contrib-node-lifx but likely some other Node based automation platforms. It’d be a lot of help!

If you have Node.js installed, the easiest way to test would be with my interactive LIFX CLI lifxsh that also uses the library. It also lists the light IP’s and id’s used by the lib which I suspect might be an issue.

You can install it with:

npm install lifxsh

Then run the interactive CLI with lifxsh. Unless you’ve got UDP port 56700 blocked by your firewall it should detect the lights via discovery. Type list to see the light infos, help to see what else you can do.

I have not written the internals of lifx-lan-client (a fork of node-lifx). I’ve only dug into the packet level stuff to do some improvements years ago, and I honestly don’t remember how the id was generated but it does look like a MAC address.

It works just fine. Discovered all my bulbs and turned them on/off as expected. LIFX did the right thing and ensured that directly identifying a light remained using the serial as printed on each device. What changed is the MAC address used on the network, so any static IP address assignments would’ve broken, for example (as mine did).

1 Like

I’ve played with the Test Flight version and it seems to work OK. One thing I noticed is that when I turned a bulb off, after a few seconds the app would revert its representiation to powered on, but the bulb remained off.

1 Like

That is a relief. And yes, I’ve also got static IP address mappings set for all lights. I would’ve been very puzzled what’s up if I were to receive the update to any of my lights. This would’ve taken a looong time to debug.

Thank you for the warning and help! :bowing_man:

You’re welcome.

FYI for any other Home Assistant users, my fix was merged a few days ago to ensure Home Assistant remains able to automagically merge the LIFX bulb entity to an entity discovered by a network integration like UniFi.

Cool! I just happened to finally dive into HA a week ago. Does it by any chance have something to do with an error I’m getting an every HA startup. It’s about LIFX integration reporting non unique ID’s?

No, that’s just the integration showing its age. It was one of the first, and it’s been mostly abandoned for a while.

This was my assumption. It’s kind of odd still, given how widely used HA is and LIFX is still in business. But then again I noticed it’s part of the core repository which seems to have grown in size very fast based on GitHub repo commit stats page. There’d need to be a lot more people involve to keep all those integrations up-to-date. :smile:

can I clarify here: does StateService now return the MAC address, or the serial, or is that unknowable?

Also your HA fix appears to increment the final serial octet - is that the pattern (ie: mac address is still derived from serial) or is it now somewhat random?

TL;DR I want the mac address. What do I need to do?

It returns the serial, which is the MAC address on devices with firmware < (3,70) and is off-by-one to the MAC address of devices that have firmware >=(3,70).

As for the pattern: that’s what I derived from the statement on Reddit and my own investigation. Only the last octet is incremented and if it’s FF then it becomes 00 without any change to any other octet.

If you want the MAC address, check the FW version. If FW>(3,70) then increment the serial by 1 or rollover from FF to 00.

You should never need to know the actual MAC address of a LIFX bulb. You discover them via broadcast and once its discovered, you use its IP address for unicasting.

The only reason it was an issue for Home Assistant is because it uses the MAC address to associate the same device across multiple integrations, which had broken.

Thanks. I’ll be more specific.

My code is a discrete switch that once set will link to a particular light and offer physical control. Once I’ve assigned the right light I’m currently sending a broadcast GetState with the mac address as the target, which returns the current state and the current IP for the light (so I can unicast to it).

If I use StateService will I get a value I can use for the target, or will I need to manipulate it?

NB: at the moment I’m pulling the mac address from either the LIFX Android App or from arpscan and setting it by hand, but it’d be nice to have a list of the lights available during setup