LIFX Developer Zone

Add HTTP API product identifiers to products.json

See the following GitHub issue:

It would be great if you could add the product identifier (like lifx_color_a19 ) that is returned using the HTTP API to the products.json file. We would like to use this for matching all of the LIFX lights to icons in our app. I was not able to find a list anywhere which contains all of the product identifiers of the HTTP API. Could you add these identifiers to the products.json file, please? Or provide a list of all current identifiers?

An alternative solution would be to add the vendor and product id to the HTTP API so we can use products.json.

Thanks for your help,

I think that’s a great suggestion, but I’m also wondering why your app is using the HTTP API when the LAN protocol is so much more efficient?

Note that the products.json content is stored on the bulbs themselves which can provide their vendor ID and product ID values in response to a GetVersion request.

You are right that the LAN protocol is much more efficient. We use the LAN protocol whenever possible, but when a light cannot be reached, our app uses the HTTP API. This could happen for example when the user is not at home.

Our app saves the vendor and product IDs locally so they are always available. We use them with products.json for showing the correct light icons in the app.

In case the user has not (yet) connected the app to the same network as the lights, the vendor and product IDs are unknown. So we cannot show a correct icon for the light. If we could use the HTTP product identifiers as well, we can show a correct icon in every situation.

That makes sense, thanks for the explanation!

Sorry, I was going to discuss that github issue with the team on Tuesday when we were all at work, but then I forgot and then I took yesterday off. I’ll have that conversation today.

As for the problem you’re trying to solve, are you able to explain a bit more about how you want to match up the device to the icons?

One of the problems with the identifiers is we change the names of our devices sometimes so, unlike the product id, they can change over time. Everything in products.json is in the /v1/lights output (except pid and identifier) so you should be able to combine capabilities and look for keywords in the name like original, br30, a19, downlight, etc.

1 Like

Great to hear you are considering this, thanks!

When using the LAN protocol, we use the vendor and product IDs (the “numbers”) to match every ID to a correct light icon. The products.json has a nice list with all the currently available IDs so that was very easy to do.
When the LAN protocol isn’t available, we use cached values of the vendor and product IDs. But if the light was not (yet) connected locally we can only retrieve the details using the HTTP API. In that case we don’t know the vendor or product IDs yet so are unable to use the same code to match every ID to a correct icon. That is why we are trying to find an alternative way when using the HTTP API.

Are you talking a about the HTTP API list lights product.identifier or If the product.identifier stays the same, we could use that to match every available identifier to a light icon. But if that changes often it could be more challenging to use that for matching it to a correct icon. In that case it would be really great if the HTTP API would also return the LAN vendor and product API so we can use the same code for matching the IDs to icons as the LAN API.

That could work, but in that case it would be nice if you could provide a list of all the http names/identifiers. We don’t have every LIFX lamp ever made (yet), so we don’t know all of the names/identifiers.

The identifiers change very rarely, but they can change. For example “warm to white” instead of “day dusk” was a recent change.

A list of all our products could be useful, we’ll consider that for a future enhancement to the public product registry.

For now, I’ve added the product_id to the /v1/lights output.


You might want to update the example output on to match. :slight_smile:

1 Like

Thank you so much! It is working great for me.


You might want to update the example output on to match. :slight_smile:

I already did <shifty eyes/> :slight_smile:

1 Like

So now I’m curious which app this is. :slight_smile: I went to and it doesn’t list LIFX under the supported devices.

Hue Essentials for iOS and Android (TV) supports Philips Hue Bluetooth and Bridge, Phoscon (deCONZ), diyHue, and (only Android:) Trådfri.

Development for LIFX as a new addition just started recently and we expect to release a beta in the coming weeks. What we want to bring is for instance support for the LIFX lightstrip with zones on your Android TV.

Furthermore, current features supported (like Dance Sensation or effects) under the current brands should come to LIFX, too.

We only communicated our intention to bring support for LIFX on our Instagram channel. When we release the beta, we will start to update the website.

That’s awesome. If you’re planning an iOS Test Flight, I’d been keen to be a tester.

Hi Avi, a TestFlight version is now available. Here is the link:
Please let me know your experience. Remember that purchases are free of charge in TestFlight, the App Store should mention this when trying to purchase something. More functionality will be added in the coming updates.

I actually signed up to the Test Flight about 10-15 minutes ago. Someone provided the link on Reddit. :slight_smile: Thanks!

BTW, I just submitted beta feedback. You’re hitting the same Test Flight IAP issue that I got with the Test Flight build of iLightShow. Seems to be a problem:

Thanks for letting me know. In-app purchases work for most people in TestFlight, but fail for some. I am not sure what is causing this wrong dialog to show, it looks like an issue that Apple needs to fix.

Please try the latest TestFlight build which contains a workaround. There is a new option on the upgrade screen so Hue Essentials just unlocks the purchases instead of communicating with the App Store. Then you should be able to try out all the paid features. Hope that it works for you now!

1 Like

I saw TestFlight auto-upgraded my install earlier this morning. Will give it a try after work tonight.

1 Like

This worked. I did notice (in my quick check) that it only found one of my 55+ LIFX bulbs though, but I don’t really have time to play right now. I’ll play properly later and send feedback if I can reproduce it.

Thank you very much for the feedback, I really appreciate it.

Previously Hue Essentials only used UDP broadcasts to discover the lights (broadcast GetService message). I changed this so now it also checks every available IP (by sending a unicast GetService message). I think that should fix the discovery on your network. Could you uninstall Hue Essentials, reinstall it, and see if it finds your lights (without signing in)? If all works fine, then of course you can sign in again. This is just to check whether the new discovery in the app works now.

When you sign in to your LIFX account, it reads the lights using the HTTP API. That is why all your lights appear when signed it. When trying to control a light, the app first tries the LAN API, and if that fails the HTTP API. In your case the lights were not found locally, so it would always use the HTTP API.