LIFX Bulb MAC Address

[josh-blake]

Thanks heaps for adding LIFX Bulb support.

Just wanted to flag that many of the older bulbs have a physical wifi MAC address different than the one expected in the UDP protocol.

To reliably get bulbs to work, they expect the Serial Number found in the LIFX app expressed as a MAC address. On newer generation light strips, the serial number and the physical MAC address are the same so it does not matter.

I should also say that the protocol is super speedy. I am running it at 25FPS currently and have not once had it lag out or stutter.

The only thing that would be more user friendly is some way to assign a particular bulb to an ‘LED’ so that the layout file does not need to be manually configured to correlate with the order that you’ve added your bulbs in.

[awawa-dev]

Hi
This is not in the master branch and under development yet so can we continue when it was started?
#1297 (comment)
There is a wizard in the latest build that can assign a lamp to particular screen area just like we do with Philips Hue lamps/Home Assistant/Zigbee and others? Did you try it?

Just wanted to flag that many of the older bulbs have a physical wifi MAC address different than the one expected in the UDP protocol.

currently the mac address is extracted as it is from their own response from the GetService:

	struct LifxHeader {
		uint16_t size;

		uint16_t frameFlags;
		uint32_t source;

		std::array<uint8_t, 8> target;
		std::array<uint8_t, 6> reserved1{};

		uint8_t flags;

		uint8_t sequence;

		std::array<uint8_t, 8> reserved2{};
		uint16_t pkt_type;
		std::array<uint8_t, 2> reserved3{};
	};
       const LifxHeader* hdr = reinterpret_cast<const LifxHeader*>(datagram.constData());
       QByteArray macBytes(reinterpret_cast<const char*>(hdr->target.data()), 6);

If old lamps report their own MAC address as not working later, where are we supposed to get the correct 'target'? Besides, it's more of an "identifier," not a MAC address. We send commands to the IP:PORT address, and the lamp also verifies whether is it a target by checking the "target" in the header against its own "MAC." So, it's more of an identifier (redundant, since we're sending the packet to the lamp's specific IP:PORT address).

[josh-blake]

The wizard only works if it detects the devices. In my case, the wizard did not, and I'm not sure why. Although I have my LIFX devices assigned on a static IP, so easy enough to resolve.

The MAC address is integral to the LIFX UDP Message protocol; specifically the Target within the Frame Address section of the UDP Header. Please see here: https://lan.developer.lifx.com/docs/packet-contents

Note that UDP Message Header is dependent on the serial number and not the MAC address. All that I propose is a change in wording on the setup that specifies the Serial Number rather than the MAC address.

I should also add that addressing a LIFX bulb (even with the correct IP) does not work unless the serial is supplied as the MAC address in the current build.

[awawa-dev]

Yes, I use it that way in the target already. But if the devices don't response to the Getservice then nothing can be done here and no wizard setup will be available as it doesn't work that way. Please provide logs from HyperHDR when you click the wizard button and it doesn't find them. Maybe it is something different.

[awawa-dev]

Could you also test these new installers? I used different flags for lamps discovery: https://github.com/awawa-dev/HyperHDR/actions/runs/18494052951

[josh-blake]

Pardon the delayed response here. I have tried out the build from 21bea84. Works great. The Wizard seems to detect the bulbs on the network. For some reason the 'Cancel' button does not work so no way to get out of the Wizard without committing changes to your current configuration.

For background: I am running Debian Trixie on a RPI5 8Gb; POE powered with an NVME; Elgato 4k Capture Card, Custom realtime kernel 6.17.5 with the P010 UVC patch applied (fully preemptable kernel with a 1000 HZ tick rate, lazy preemption although have tried scheduler controlled as well). I am running 2 instances of HyperHDR; 1 to a WLED box (245 LED RGBW strip) at 100Hz over wifi, and 1 to (currently) 2 LIFX bulbs at 30Hz. Not a single missed frame / dropped packet. Everything is butter smooth here without any jitter.

[awawa-dev]

For some reason the 'Cancel' button does not work so no way to get out of the Wizard without committing changes to your current configuration.

The Cancel button works when you run the wizard and you've already configured LEDs in the same controller. This prevents you from overwriting them if you don't want to. Since this is a shared element across multiple dialogs, I won't be changing this behavior, and it's probably not a bug, but rather a feature ;-)