Several questions related to REST API infrared&color commands

Hello, I am integrating an A19+ infrared bulb and am using the LIFX REST API for that purposes. However, I have several questions related to infrared and color commands being sent via REST to the bulb.

  1. I know that the possible % levels for the infrared brightness are 0 (disabled), 25%, 50% and 100% - that’s what the LIFX app. allows. However, no matter if I change the level via LIFX app. or via the API call PUT{bulbId}/state with body {"infrared": 0.25} for example, I don’t see a change. In other words, after a change of the IR brightness via the LIFX app. or via a successful API call, doing GET{bulbId} doesn’t show any difference in the IR brightness. Also, I sometimes see the brightness changed after some considerable time, but only if the selected percentages are 50% or 100% - I never saw 25% (i.e. infrared: 0.25 ) in the API response. So, any advice why such behavior is present?

  2. Since the possible IR values are 0%, 25%, 50% and 100%, why aren’t the middle values (e.g. 50%) returned as exact corresponding [0.00 … 1] values by the API? What I mean is - if the IR brightness is set to 50%, GET{bulbId} returns 0.49999237048905165 and not 0.5. Is there a way to get precisely 0.5 or 0.25 for example and why such behavior is present?

  3. I see that GET{bulbId} always returns all settings: [hue, saturation, kelvin] as part of the color object, together with brightness. However, I need to know if the color settings I receive by the API were applied via the color temperature palette or via the color (hue-saturation-brightness) palette. Is there a way to distinguish this - I would personally expect that the kelvin value goes to 0 when color is applied via the color palette, but it always carries the latest applied color temperature value. What I spotted is that if the color was set via the color palette, the saturation never goes to 0, but has a mininum of 0.009994659342336155 and when the color is set via the color temperature palette, the saturation is always an exact zero (0). Is this reliable enough to be used as a marker about the current color mode of the bulb - HSB or CT?

Will be happy to hear opinions on the topic, wish everybody a nice day.



Great questions, I can answer them all :slight_smile:

The device represents the infrared level (and hsbk values) as uint16 values. So a number between 0 and 65535. When you use the HTTP API, you’re providing percentage values. When you send 0.5 for infrared, we give the device int(65535 * 0.5) as a value. In this case that’s 32767. You may note that 65535 * 0.5 equals 32767.5 which is why the value you get back won’t be exactly 0.5 because we lose information when we give the value to the device. We currently don’t limit the precision of that result when we give it back in an API request.

The Mobile Apps restricts the level of infrared you can set on the device, but the API does not, so you can set any percentage you like. The reason you don’t get the new value back in a GET response straight away is a bug, so thanks for finding that :slight_smile: . It appears we aren’t setting the new value in our device cache straight away and so it doesn’t show the new value until our internal polling gets around to asking for infrared. I’ve made a card to fix this.

The API however, is still setting the infrared value, which I have just confirmed with my own light and asking for it’s infrared value via the LAN API. How are you checking whether the infrared is on? Some cameras will block out infrared while others will see it. For example I have a raspberry pi camera (reasons) and it can see the infrared while my phone can’t, so you get this effect.

For changing values, We only change values that you specify to change. This means if you don’t change the kelvin value, the kelvin value will remain the same. When you set saturation 1, you can set kelvin to 0 at the same time if you want that to be 0 the next time you ask for state.

Also, some idiosyncrasies of the firmware/cloud that affects the response we give back

  1. The brightness can be set to 0, but when you turn on the light we set a minimum brightness. Otherwise if the brightness is already 0, telling the device to turn on won’t do anything visual.

  2. Our white lights will still report back a nonzero saturation level despite not doing anything with it. So to determine if a device is not using the hue value you need to both check saturation is near 0 and check the product capabilities.

  3. When you set saturation to 0 and a different hue value at the same time, the device won’t change the hue value. So if you want to change the hue value as well, you have to set a saturation to near 0. For example {"color": "hue:40 saturation:0"} won’t change the hue on the device to 40, but {"color": "hue:40 saturation:0.001} will. Also saturation isn’t limited to 0.009. What is the command are you sending?

  4. LCM2 devices with the current latest firmware may have a hue value off by up to two due to a bug in the firmware.

  5. The affect of the kelvin value on the appearance of the device becomes less the higher saturation is. So when saturation is 1, it still has an effect but very little. We recommend just setting a consistent value (like 3500) when you have a non zero saturation.

Don’t hesitate to ask more questions!