Lifx Bulbs Unavailable After 2022.8.0

2022.8.0 has breaking changes for Lifx. Apparently it deprecated the manual configuration used for lights on segregated, firewalled subnets in favor of a different configuration structure or a totally automatic discovery process. Does anyone know the details on either option, whichever is the correct one? I’m not sure from the release notes or the current integration docs, which are not updated yet. The effect for me after updating is the all my 4 bulbs are unavailable, despite showing fine on the Lifx app. They are all on a separate subnet behind a firewall and were working through the lifx yaml entry (deprecated on this release).

If only automatic discovery will now be used, what are the firewall requirements? Or if still a manual config will be possible, how is it?

It’s both. The automated discovery is greatly expanded but you can also manually configure your bulbs via the integration page (instead of via yaml). To connect to your bulbs, it uses port 56700/UDP. Discovery is done via UDP broadcast as well as Zeroconf and DHCP.

4 of my bulbs were unavailable after the 2022.8 upgrade, I removed the config for them in configuration.yaml, removed them from integrations and then rebooted. Once back up I re-added them through Integrations > Add Integration > Lifx, it asks you for the IP of the individual bulbs.

All 4 are now back and working as expected.

1 Like

is there any advantage in adding the bulbs manually rather than relying on discovery/broadcast?
Would it possibly make start up quicker and reduce broadcasting across the network?

The only time you should need to use manual configuration is if Home Assistant can’t automatically detect your bulbs. If it can, let it do that because it can automatically reconfigure a bulb if it gets a new address via DHCP, etc. Given how many discovery methods are used, it’s usually best to let it do that.

However, top tip: if you’re not using HomeKit, you may have a better experience integrating your bulbs using Home Assistant’s HomeKit Controller integration instead. That uses local push updates, which can dramatically reduce the amount of network traffic and almost completely eliminates sync issues, because the bulbs push their state to Home Assistant.

If you are using HomeKit, my advice is to remove the bulb from the real HomeKit, connect it to Home Assistant and then export it from Home Assistant to HomeKit using a bridge. :wink:


Spot on! I’d add that for every bulb you just repeat Add Integration > Lifx.

This so very interesting!
I am not using HomeKit, hence all this should come for free!

Could you please explain why this should reduce network traffic? Is it due to moving from polling bulbs to have them pushing the status?

My bulbs should all be HomeKit compatible, I just have some old Z strips which I am not sure they are…

There’s some discussion regarding the relative network efficiency of each integration in this topic:

So far it looks like that advantage is not that significant.

The advantage is local push is always going to be faster for updating state inside Home Assistant than the LIFX integration’s local polling interval. WIth HomeKit Controller, the bulb notifies HASS when it changes. With the LIFX integration, we check the bulb every 10 seconds. This means it’s possible for a bulb to be out of sync for ~9 seconds with the LIFX integration.

I have never seen this happen. So I did a bit of experimenting and worked out why. Basically it comes down to the fact that I only ever control the lights from Home assistant. If I change the light with something outside home assistant (e.g. the Lifx app) then yes I do see the up to 10 sec delay.

Heh, yes. If you only ever change the state of your bulbs using Home Assistant, than this is of little to no benefit. :slight_smile:

However, I do know a lot of folks who use native HomeKit support for example who do experience this. Switching things around so that Home Assistant uses HomeKit and then shares the lights with HomeKit itself means both ecosystems get the same local push functionality.

1 Like