LIFX Developer Zone

Discovering LIFX Bulbs

Continuing the discussion from Building a LIFX packet:

The protocol documentation includes a section on workflows including how to do discovery. Essentially it works like this:

  1. Send a Device::GetService packet to the broadcast address (255.255.255.255) on port 56700
  2. Each bulb will respond with a list of service they support as a Device::StateService message. The only service currently documented is UDP which has its type field set to 1.
  3. When your application receives one of these messages it should store the sender address and the service port internally. This will constitute the list of LIFX devices that you have found.
1 Like

I can send packets to change color example
blue = 31 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 66 00 00 00 00 FF 7F FF FF FF FF AC 0D 00 04 00 00
green = 31 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 66 00 00 00 00 55 55 FF FF FF FF AC 0D 00 04 00 00

when i try to send this packet = 31 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 65 00 00 00

It is supposed to acquire responses from all devices on the local network , i get nothing returned . Im using wireshark and packetsender to see all UDP packets incoming/out-going to see if anything gets returned.

in the DatagramPacket p object the getBroadcastAddress, is the IP address of router so it can broadcast to everyone on the lan .

Only thing that could possbily be wrong is my packet

this is my method

One thing to remember: the first two bytes of the packet need to indicate the length of the packet in bytes.

A Light::Get packet won’t be the same length as the Light::SetColor packet in @daniel_hall’s example, because Light::Get doesn’t carry a payload - it’s just a header. If I paste the packets below, you can see that they are different lengths:

Your packet (Light::Get):
31 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 65 00 00 00

daniel_hall’s packet (Light::SetColor):
31 00 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 66 00 00 00 00 55 55 FF FF FF FF AC 0D 00 04 00 00

So you will need to adjust the first two bytes of your packet to reflect the actual length of the message. I think a Light::Get packet should actually contain 36 bytes of data. So if you convert 36 to hex and byteswap it, the first two bytes of your packet should be 24 00, instead of 31 00.

There might be other problems with the packet too, but as a first step you could check and see if this helps.

@SaidAbs when you say ‘address of the router’, what do you mean? Do you have some other process on the router that will perform the broadcast when it receives the packet? Otherwise, you’re just sending a unicast packet to the router device, whatever that is, and it will just drop it or return ICMP port unreachable. You need to actually broadcast the packet.

I meant the broadcast IP

Yeap changed it, on wireshark & lifx just sends STUN to be broadcasted on the LAN , still not working

You are actually getting the right response from the bulb here - it’s sending a Light::State message as expected. See my red highlights at the bottom of the image below:

I’ve underlined a couple of clues - the “6b” is the message type (107 in decimal, which is the code for a Light::State message), and the “ff 7f ff ff ff ff” are the hue, saturation and brightness that you set with your previous message.

I don’t know why there’s a bunch of stuff before the start of the message, though… Is that a Wireshark thing? I’ve never used Wireshark so I don’t know how it works/what it does.

Those STUN packets are exactly what you should expect to see. Wireshark doesn’t understand the LIFX protocol and miscategorises them as STUN. You may want to set the source header field to a non zero value so that the packets come directly back to you instead of being broadcast, but you should be able to parse these for now.

The data before the start of the packet in Wireshark is the Ethernet and the IP headers for the packet. Wireshark captures traffic that passes directly from the network interface. This means it captures every single byte. Thats why Wireshark is one of the best tools for debugging network applications.

thanks , i changed the source header to non zero value and im getting a response directly back, thanks for the help :smiley:

@rasputin303 whats the data between “00 54” and “6b”

That would be the LIFX frame, the frame address and the protocol header. You can read about all of them in the protocol documentation. Also the first post in this thread covers how the whole packet fits together.

1 Like