LIFX bulb colors don't match HomeKit vs LIFX LAN protocols

[tggman]

The problem

I've been using the LIFX LAN protocol based integration since its inception. I recently setup and started using the HomeKit Accessory Protocol and noticed that my existing yaml code (e.g. color_temp or color_temp_kelvin) yielded different visual bulb colors LAN protocol vs HomeKit protocol.

Note: I use the light.turn_on service with the HomeKit entities by default but use the LAN protocol based entities as required (e.g. when I need to use the lifx.set_state service without the power: attribute and lifx.effect_colorloop service)

What version of Home Assistant Core has the issue?

2023.1.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

LIFX

Link to integration documentation on our website

https://www.home-assistant.io/integrations/lifx/

Diagnostics information

N/A

Example YAML snippet

service: light.turn_on
data:
  entity_id: light.lifx_color_1100din01  # lifx LAN protocol entity_id
  color_temp: 250                        # ... or color_temp_kelvin

# the above produces a different visual color then this:
service: light.turn_on
data:
  entity_id: light.lifx_hk_abcd_din01    # HomeKit entity_id
  color_temp: 250                        # ... or color_temp_kelvin

Anything in the logs that might be useful for us?

Nope

Additional information

Issue can be duplicated using the Developer Tools/Services dialog.

Workaround: Based on limited testing, using color_name: instead of color_temp or color_temp_kelvin works as expected (i.e. it produces the same visual color LAN protocol vs HomeKit protocol).

All my bulbs were paired using Home Assistant's HomeKit Controller integration ONLY (I'm not an Apple guy).

[home-assistant[bot]]

Hey there @bdraco, @djelibeybi, mind taking a look at this issue as it has been labeled with an integration (lifx) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `lifx` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign lifx` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

lifx documentation lifx source _{^{(message by IssueLinks)}}

[Djelibeybi]

There is a misunderstanding somewhere: there is no cloud-based LIFX integration. The difference you're seeing is probably caused by LIFX not supporting color_temp properly via HomeKit on color bulbs, only on Warm to White bulbs.

You can validate this by checking what the LIFX app says the bulb is actually set to after changing it via Home Assistant.

[Djelibeybi]

Also, to be absolutely clear: the LIFX integration does not use the cloud at all. It controls LIFX bulbs completely locally using the LIFX LAN protocol.

[tggman]

I didn't know that (how would I?). Thanks for the clarification.

Are there ANY advantages to using HomeKit? If not, I'm going to reverse course (and hours of work). Updating the docs would seem to be prudent so others don't go down the same path I did - especially since HomeKit doesn't support lifx.setstate and lifx.effect*

Because I should have used the term "LAN protocol" instead of "cloud", l'll go ahead update this issue accordingly. But still is a bug. How do you want me to proceed relative to this issue?

[Djelibeybi]

Yes, the HomeKit Controller integration has a significant advantage in that the bulbs push updates instantly to HomeKit whenever they are changed. If you use the LIFX integration, it polls every 10 seconds for changes, which adds network load and latency.

[Djelibeybi]

This isn't a bug, btw. It's "working as intended", as least according to LIFX.

[Djelibeybi]

Finally, if you have configured the LIFX integration in order to use lifx.set_state, you lose the lowered network usage advantage as the LIFX integration will be polling every 10 seconds. However, the HomeKit version of your bulbs will update themselves instantly.

Finally, if you only ever change your bulbs using Home Assistant, the benefit of the HomeKit Controller option is fairly negligible.

[tggman]

This isn't a bug, btw. It's "working as intended", as least according to LIFX.

That doesn't make sense to me. A color is a color. But what do I know. Want me to close this issue?

And are you saying that I need to disable all of the LAN protocol entity_ids or LIFX will poll every 10sec?

[Djelibeybi]

Using HomeKit, color LIFX bulbs don't expose their white LED, i.e. the color_temp is emulated using HSB values. So, what you're getting is a color that resembles the kelvin value. Not the white LED set to the Kelvin value. If you want accurate color temp on a color bulb, use the LIFX integration. If you have Warm to White bulbs, use the HomeKit integration.

And yes, if you have LIFX integration enabled, it will poll each of those bulbs at least every 10 seconds.

[Djelibeybi]

This limitation makes no sense to me either, btw. It is what the HomeKit Accessory Protocol states, but every other manufacturer seems to ignore it somehow. It's only LIFX that seem to abide by the "rules" here.

[tggman]

Again, thanks for the clarification.

Using HomeKit, color LIFX bulbs don't expose their white LED, i.e. the color_temp is emulated using HSB values. So, what you're getting is a color that resembles the kelvin value. Not the white LED set to the Kelvin value. If you want accurate color temp on a color bulb, use the LIFX integration. If you have Warm to White bulbs, use the HomeKit integration.

And yes, if you have LIFX integration enabled, it will poll each of those bulbs at least every 10 seconds.

Keep in mind color_name returns visually identical colors - and those names have color codes associated with them.

Anyhow and regardless, it sounds like I should close this issue - agree? Regardless, it seems like adding these clarification to the docs makes sense - but you know best.

[Djelibeybi]

Keep in mind color_name returns visually identical colors - and those names have color codes associated with them.

Yes, this is to be expected: it uses the color (HSB) LEDs regardless.

Anyhow and regardless, it sounds like I should close this issue - agree? Regardless, it seems like adding these clarification to the docs makes sense - but you know best.

To be honest, I thought I had added something along these lines to the docs, but perhaps that got lost in one of the many edits I've been doing over the past few months. I'll review the docs and see if I can provide more clarity.

[tggman]

Thanks for taking the time to explain and esp. for all the work you've put into this integration Take care

[tggman]

@Djelibeybi I didn't want to open up another "unwarranted" issue so I figured I'd ask here first.

I just noticed that the transition: attribute for service light.turn_on does not seem to be working when using the HomeKit protocol. Is this expected? If not, and you can't duplicate, I'm beginning to wonder if I'm having issues on this often used service because I'm using both the LIFX LAN protocol and HomeKit.

for example:

service: light.turn_on
data:
  entity_id: light.lifx_hk_dcba_din01
  brightness_pct: 50
  color_name: white
  transition: 15

[Djelibeybi]

To be honest, I don't use the HomeKit protocol with my LIFX bulbs, so this is not something I can answer. It would be a question for the HomeKit Controller devs. Anecdotally, I've noticed the same issue using HomeKit Controller with my Nanoleaf bulbs, so this may be a known issue for them.

[tggman]

Yeah, I decided a few hours ago it was time for me to cut my losses. I restored my LAN only protocol yamls from backup and disabled the LIFX HomeKit entities in the HA HomeKit integration. The LAN protocol has served me well over the years while the HomeKit protocol's behavioral differences have forced too many code changes and added complexity. It's been an interesting exercise if nothing else, but it's definitely not something I would recommend (especially to Android users).

It's been fun -- sort of LOL