Bulb with latest firmware not responding to discovery (actually turned out to be old firmware)

I have an LIFX bulb with 2.0 firmware and I’ve been developing with it and it works great. However, I just bought a second bulb, which presumably has the latest firmware. (I can’t find a way to get the app to tell me the exact firmware version, but it says the old bulb is out of date and the new bulb is not.) Both bulbs are “Original 1000”.

The new bulb works fine in the app, so I know the bulb itself is working. But unlike the old bulb with the 2.0 firmware, the new bulb is not responding to my GetService messages. The message I’m sending is
24000034b7ca3b3600000000000000000000000000000000000000000000000002000000.

Has anyone else had this experience with the latest firmware? Any ideas what I’m doing wrong?

Or, broken down, the message I’m sending is Header {hdrSize = 36, hdrOrigin = 0, hdrTagged = True, hdrAddressable = True, hdrProtocol = 1024, hdrSource = 909888183, hdrTarget = 0, hdrAckRequired = False, hdrResRequired = False, hdrSequence = 0, hdrType = 2}.

(The source is set to a different number each time I run the program, and of course the sequence number increments with each message during one run of the program. Reserved fields are not shown here, but they’re all set to 0.)

I’ve also tried setting the source to zero in the GetService message, because that’s what Kate said worked for her. If I set source to zero, my GetService message is 240000340000000000000000000000000000000000000000000000000000000002000000, which is byte-for-byte identical to the one @kate said worked for her.

Sorry for all the sequential posts!

We haven’t documented how to talk to the old version bulbs, but because they use mesh it is much more complicated. Since those bulbs are being phased out it is unlikely to get documented any time soon, and I would suggest you tell all your users to update your bulbs.

So first off, to get the version number of all your bulbs you can hijack the diagnostics information that we send with feedback requests. Go in to the app, open the bulb list, choose the little cog icon (on the left on iOS and the right on Android), choose the feedback option, change the email address from support to your own email address and email the results to yourself. Attached to the email will be a bunch of diagnostic information which should include the firmware version.

The latest firmware is currently 2.1 for the Original and Color 650 bulbs and 1.5 for the White 800 models. Versions 2.0 and upwards of the Original and Color 650 protocol and all White 800 bulbs should be able to talk the documented protocol.

If you bought the Original bulb you almost certainly got an older firmware as they make up most of our stock, Color 650 and White 800s come with a firmware that talks the current protocol out of the box.

Aha! Now I see what you mean. I just bought a new Gunmetal bulb through the developer special, and I’d been assuming it already had the 2.1 firmware because it was new. So that’s why I erroneously thought I could talk to 2.0 and not 2.1. But the Gunmetal bulb was really 1.x.

So, I’ve been working on applying the firmware update to the Gunmetal bulb. I started it about four hours ago and it still hasn’t finished… the progress bar is stuck at “almost done but not quite” and doesn’t seem to be moving anymore. I remember having a similarly long/frustrating process when I updated my other bulb from 1.x to 2.0 a few months ago.

Ugh. I don’t have email configured on my phone, so that would be a hassle. (Yeah, I’m a semi-Luddite in some strange ways.) It would be much preferable if the app could just show the firmware versions of all my bulbs in a straightforward way. The frustratingness of the app is exactly the reason I’m writing my own.

Anyway, sorry about my confusion over what was going on, and thanks for setting me straight! It sounds like I’ll be fine, if/when my bulb finishes its firmware update.

If the bulb doesn’t finish the firmware update after a few attempts email our support team at support@lifx.com and they’ll help you out.

As you noticed though the 1.X update to 2.X can be a bit of a pain. Once that’s done though all further firmware updates should be faster/easier.

Okay, that was pretty grueling, but I seem to have my firmware updated now! I’m now able to communicate with it successfully with the library I’m writing.

I noticed that the “version” field of the StateHostFirmware and StateWifiFirmware is now 0x20001. Since that’s supposed to correspond to version 2.1, does that mean I should interpret the “version” as two 16-bit numbers, and display them with a decimal point in between? In other words, there isn’t ever going to be a 2.1.1, since there doesn’t seem to be a place for a third number?

Anyway, thanks for the help and encouragement. And I can’t wait until the rest of the protocol is documented, so I don’t have to use the app for onboarding or firmware updates, either!

Good catch! It looks like the documentation calls it a single 32 bit integer, but really it should be two 16 bit integers. I’ll go update it.

The ‘name’ of the firmware is the two integers separated by a decimal. For updating purposes we use the ‘build’ field to see if the firmware is newer. I recommend if you are displaying the version to the user use the two integers, but if you are deciding if the firmware needs to be updated use the ‘build’ field.

You are very welcome. I’ve prepared docs for dealing with bulb groups and locations that I’ll be adding soon.

Actually it turns out the firmware version is more complex than splitting it out into two bits … Its getting a bit late on a Friday but I’ll sort it all out Monday and post here again.

Okay, so I have the official answer from the firmware team now.

The version field is a 32 bit integer, where higher numbers are newer versions of the firmware. Use this to compare firmware versions not the build timestamp as I mentioned earlier.

If you wish to display the firmware to the user in an easily readable way, take the first two bytes, that is the major version. Take the last two bytes, that is the minor version. Then combine the two with a ‘.’ in between. Here is some example python code to do it:

def get_firmware_version_string(version):
    major_version = version >> 0x10
    minor_version = version & 0xFFFF
    return '%d.%d' % (major_version, minor_version)