Building a LIFX packet

Thanks. I really appreciate your feedback. I don’t often get told that my code looks nice. :smiley:

I can’t see a license for your repository, but if you are happy with an MIT or a GPL license then feel free to pull my code directly into your repo if it helps. You can never have too many implementations of something. Also my job here is to empower developers like yourself, so feel free to reach out if you have any questions.

I’ll give your code a quick test tomorrow with the lights in the LIFX office and let you know how it goes.

The license is MIT, but that was buried in setup.py. I’ve added an explicit license file to make it clear!

Thanks for the encouragement! This is a super-friendly community. Looking forward to hearing how the test goes. :smile:

Hi mclarkk. Can you spend time and help me. My situation is strange and i can control lifx only from linux pc. Tried to use lifxlan - all works fine. But i need simple script to send on/off/color directly to my 1 bulb. I’am not programmer - here is the problem. If you can help me, please email me at brutevinch@icloud.com

If you have a question about a specific library it might be a good idea to start a new thread about it…

If you need to notify someone in particular you can place an @ in front of their forum name and the system will email them to let them know.

@brutevinch I’d be happy to add some scripts to the examples. If there are simple scripts that would be helpful to you, I’m sure you’re not the only one they would help. I’ll email you to get a better idea of what you have in mind.

im new to networking for lan and stuff, could you show me a an example lifx packet that broadcast to the LAN and recieves a list off lifx ip’s

@rasputin303 @daniel_hall

Hi Guys, I’m new to python and trying to learn it specifically to experiment with the LAN protocol.

Ed and Daniel i really like the work that you have put into the script on this page and have it working with plans to hopefully turn it into something of my own.

I don’t know if anyone else has experienced this but when i run the program and input the values, one of my 2 bulbs changes colour instanly, however it takes about a second or two for the second bulb to change. Do you have any idea why this would be the case.

Cheers,
Darren

I don’t know if there’s a code-related reason why this should happen - I’m a Python noob too, and that script was only the second thing I ever wrote. But in theory, the bulbs should change at the same time. The code is broadcasting to the whole network at once, it’s not sending messages sequentially to one bulb at a time - so there’s no reason that one bulb should change before the other. My guess is that because UDP is a pretty flaky protocol, sometimes messages bounce around the network for a bit before the bulbs pick them up. But I will defer to people like @daniel_hall who actually know what they’re talking about!

In trying to implement the packet format in C# in notice that the frame description says that the origin and flag bits go before the protocol number but that’s only true if you view it as a 16 bit field that gets byte flipped for little endian but as a bit layout it’s backwards.

To assure that I understand things right it would be helpful to have an example of a “getservices” packet with the fields marked, I presume that

28 00 00 34 7B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 64 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00

is wrong but need an example to compare it against.

decodes as

lifx_packet(
  frame_header=frame_header(
    size=40,
    origin=0,
    tagged=1,
    addressable=1,
    protocol=1024,
    source=123),
  frame_address=frame_address(
    target=0,
    reserved1=0,
    reserved2=0,
    ack_required=0,
    res_required=1,
    sequence=100),
  protocol_header=protocol_header(
    reserved1=0,
    pkt_type=2,
    reserved2=0),
  payload=payload_getservice()
)

Which looks alright to me.

I agree the ordering does seem a little weird because you build is as a bit field, and then perform the endian swap. When you read the C structure at the bottom of the Header Description page it is a little bit clearer (if you know C).

Apparently C# is allocating an extra 4 bytes at the end so I programmed around that for now so I can find the payload. But otherwise is working fine now. Yes, I know C but you should fix the diagram http://lan.developer.lifx.com/docs/header-description to avoid the confusion.

SOLVED – added pack=1 to StructLayout

Looking at the Payload for StateService I see two response – one for service 1 (UDP) and the other 5 for ???

I’ll make a note to update the diagram and text to better match the layout of the packet in bits.

All values other than 1 are undocumented and thus can be ignored. Some have uses for LIFX only, and others are reserved for future use.

I get SetColor and SetPower to work but in testing if I do a GetService all bulbs respond but if I do a Get only a subset respond. Is there a reason for that?

Can I see the packet that you are sending for the ‘Get’ where only a subset respond?

OK, tracked down a problem. I was doing the queries in parallel threads but apparently that confuses the bulbs. This could a serious scaling problem when there are multiple clients controlling the devices. I can interlock on a single system but not across systems. I also turned on that tagged flag to be safe.

One strange result - I just got
D0:73:D5:12:6B:4E kwall3 StateInfo Since 2015-12-16 22:12:40 Down()
but that bulb is reporting itself offline via the http interface
12-17 00:28:31.116 17 [LifxUpdater] 12/16 23:49:07 kwall3 offline kwall3 126b4e

BTW, the received bytes count is very high – are the bulbs eavesdropping on all the traffic on my network?

Even then some devices don’t respond though most do. Since your system can only handle images I"m uploading the results. Notice the number of responses is 20 or 21 but getservice has only 38 but should have 42.
The columns show the count (#) and the number of seconds since the query was sent out. I wait 1 second since the response all come with less the .5 or don’t come at all.

Tried again and this time got up to 23 devices (Apparently your uploads overwrite) and 42 responses to getservice

Markdown can also handle preformatted text. You just need to indent the text by four spaces. You can either do that manually, or just highlight the text and hit the </> button in the toolbar. For example:

Label            Pwr Color             Temp        Uptime DevID  FW  HW    Group
---------------- --- ----------------- ------ ----------- ------ --- ----- -----
Traditional floo On  120   0 100 9000K 71.3°C 40d4h19m32s 029e03 2.1 O1000 Bedro

Will try </>. I notice I’m getting lots of lost packets. But I"m also confused – is the response to LightSetPower the resulting value or the previous level. It should be the current so I can do clsoed loop signaling. In this case the 41 in the last message is the sequence number (or before that, 40 etc)

1  34 0.02 D0:73:D5:03:26:73 officetest           LightStatePower  Level=65535
To[192.55.226.195]  35  Msg(LightSetColor   )
To[192.55.226.195]  36  Msg(LightSetColor   )
To[192.55.226.195]  37  Msg(LightSetColor   )
 1  37 0.33 D0:73:D5:03:26:73 officetest           LightState       test 032673
To[192.55.226.195]  38  Msg(LightSetPower   ) Level=65535
To[192.55.226.195]  39  Msg(LightSetPower   ) Level=65535
To[192.55.226.195]  40  Msg(LightSetPower   ) Level=65535
 1  40 0.02 D0:73:D5:03:26:73 officetest           LightStatePower  Level=65535
To[192.55.226.195]  41  Msg(LightSetPower   ) Level=0
 1  41 0.02 D0:73:D5:03:26:73 officetest           LightStatePower  Level=65535

As one last test I set all my kitchen bulbs to green creating separate threads for speed and it worked nicely. Even seemed to reach bulbs deemed “offline”. But now they keep turning green even after I’ve used the app (Windows) to set them to white! What is making them go green again even after I’ve exited the program and visual studio? And how do I stop it! , OK, I think it finally stopped and the one bulb remaining claiming to be Green is a white one so that’s moot.

I presume the bulbs themselves have a buffering problem in keeping a queue long after I’ve assumed the message has been lost and without signaling the change i can’t know what is really happening short of polling often. Or maybe the app is … might as well stop guessing.