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.
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.
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.
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 product.name? 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.
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.
Hi Avi, a TestFlight version is now available. Here is the link: https://testflight.apple.com/join/u1953sBd
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.
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!
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.