LAN API responses

I have a LifX Mini Day and Dusk bulb. I would like to control it using the LAN API.

My ultimate goal is to flash the bulb on and off at about a 1 Hz rate for about 10 seconds to use as an alerter – I am deaf.

I’ve written a Java program that runs on a Windows 10 PC to test controlling the bulb.

I can turn the bulb on and off, SetPower (117), and generate the binary string for SetColor (102) to confirm it matches the example.

But when I issue one of the get commands, GetPower (116) or Get (101), the response I receive does not seem to match the documentation.

This is the binary string (shown in HEX) I receive for Get Power when the light is 100% on:

This is the binary string I receive for Get Power when the light is off:

This is the binary string I receive for Get when the light is on:

This is the binary string I receive for Get when the light is off:

(Note: My UDP is set up to return a buffer of 200 bytes. I have artificially truncated the above strings at the point where the data seems to become all zeros. I may have truncated the strings too short by mistake)

For example, in the responses for GetPower I would expect to see FFFF/0000 in the 0 position, according to the LifX Light Messages documentation. I do see it at the very end of the string, but what’s all that other stuff? The Same for Get. If I try to match one for one with the documentation, the values just don’t make sense.

In the responses for the Get command I see the Hex string “4C494658” (LIFX), which would correspond to part of Label, but not at the position I expect.

Can someone help explain what I am seeing?

Second question: Is it better to use a waveform to flash the bulbs on an off (or bright and dark) than to actually issue on and off commands and a 1 Hz rate? How would I approach this with my Day and Dusk bulb?


Oh Boy! To answer my own question, at least partially.
I read in some other posts about “all messages contain headers” and 36 byte headers.
When I manually decode the data I received and include that information, it makes perfect sense.

GetPower (header 36 bytes) on 2600001418DD0000D073D53D032900004C49465856320100D0D8E89E4700000076000000
level word FFFF

GetPower (header 36 bytes) off 2600001418DD0000D073D53D032900004C4946585632010040F0FBB89200000076000000
level word 0000

Get (header 36 bytes) on 5800001418DD0000D073D53D032900004C4946585632010020B4C88D5C0000006B000000
color HSBK word[4] 0000 0000 FFFF AC0D (0, 0, 65535, 3500)
reserved word 0000
power uint-16 FFFF (65535)
label byte[32] 414C4552544552 (ALERTER)

Get (header 36 bytes) off 5800001418DD0000D073D53D032900004C4946585632010060C1CBCBA50000006B000000
color HSBK word[4] 0000 0000 FFFF AC0D (0, 0, 65535, 3500)
reserved word 0000
power uint-16 0000 (0)
label byte[32] 414C4552544552 (ALERTER)

Is the header in the same format as the header for sent messages?

Is it better to use waveforms to flash the lights? How should I approach using waveforms with my Day and Dusk lights?




You are correct, the header in the response is the same as the header in the request.

As for flashing your bulbs, that’s exactly what the waveform messages are for!

I suggest something similar to what I mentioned in this post: LAN API still available

Thanks. I will have to eventually look at that stuff.

I am not familiar with Python. I am more familiar with C type languages. Eventually I want to incorporate this bulb flashing into my own program. Actually sending UDP packets will be easy to incorporate.

My test application uses UDP and successfully flashes my bulb on and off for 10 cycles at a 1 Hz rate. Once I found the documentation and forum posts about the header and header length, I was able to decipher the return strings from a couple Get… commands.

The second part of my application will be determining when a Windows 10 event notification appears on the screen. The only way I have found is with UWP, C#, and a Notification Listener - that seems complicated. Maybe Python offers a way to detect Windows notifications?


Fair enough.

I don’t have much experience with Windows, so I don’t have much advice to offer there.

One recommendation I can make is to use Wireshark with Wireshark LAN Protocol Plugin to analyse the protocol responses, makes life much easier.

Thanks. I did not know about Wireshark. That and your dissector will be useful.

Not my dissector, but it is very useful :slight_smile: