Lifx legacy bulb

[tekstein]

The problem

I have a legacy LIFX bulb that will not pair with the LIFX integration

What version of Home Assistant Core has the issue?

2022.3.8

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

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

I believe this integration used to work. Now no longer works with legacy bulbs. When I try to pair my Legacy bulb it says no devices found. Please advise if does work with the original lifx bulb

[probot-home-assistant[bot]]

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

[Djelibeybi]

What model bulb? What firmware version? You can find both of these in the LIFX app under Tech Specs for the bulb.

[bjeanes]

Not author, but I have an old bulb that does not show up.

Firmware = 2.80 Model = LIFX (A19) (it's the original bulb from the Kickstarter)

[Djelibeybi]

Discovery is done by the underlying aiolifx library, which hasn't changed for ages. I wonder if something has changed with HA's networking perhaps? Could you please describe how and on what hardware you're running HA? And when last it worked?

[Djelibeybi]

I don't have any original Kickstarter bulbs left, but I have a bunch of Downlights running the same firmware version and they are still working. If you could enable debug logging for the lifx integration, that will give us a better understanding of what's happening.

[bjeanes]

Honestly, I don't know. It's been a few months, but since I moved house to one with very few sockets that my LIFX bulbs fit in, it hadn't been a priority to get working again. At some point in the last 2-3 months, I noticed my LIFX integration had 0 entities and 0 devices. If I delete and re-add the integration, it tells me there are no detected devices on the network.

[bjeanes]

I have a newer bulb which I want to add to test but I can't even add it to the LIFX app because of https://community.lifx.com/t/setup-without-homekit/7148/35 (absolute shambles...)

[bjeanes]

If you could enable debug logging for the lifx integration, that will give us a better understanding of what's happening.

Is the logger key homeassistant.components.lifx or something else? I am not quite sure of the scheme here...

[Djelibeybi]

Is the logger key homeassistant.components.lifx or something else? I am not quite sure of the scheme here...

Yep, it is. If you're running HACS, you could optionally install my LIFX Beta integration which won't fix the issue, but will output a lot more debugging information: https://github.com/djelibeybi/ha-lifx-beta

[bjeanes]

Oh yeah that's the other thing I totally forgot about this...

If I delete the integration and re-start HA, I get a "device detected" notification from LIFX integration:

I tried with the beta custom component and after restarting, I see the same behaviour.

Logs:

8:2022-03-31 22:09:21 WARNING (SyncWorker_5) [homeassistant.loader] We found a custom integration lifx which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
1062:2022-03-31 22:10:33 INFO (MainThread) [homeassistant.setup] Setting up lifx
1063:2022-03-31 22:10:33 INFO (MainThread) [homeassistant.setup] Setup of domain lifx took 0.0 seconds
1064:2022-03-31 22:10:33 INFO (MainThread) [homeassistant.components.light] Setting up light.lifx
1065:2022-03-31 22:10:33 DEBUG (MainThread) [custom_components.lifx] (Network) action=enable_interface, interface=enp0s3, ip_addr=10.10.10.243, network_prefix=24, broadcast_address=10.10.10.255.
1066:2022-03-31 22:10:33 DEBUG (MainThread) [custom_components.lifx] (Discovery) action=start_discovery, listen_ip=10.10.10.243, discovery_interval=60, message_timeout=0.5, retry count=3, grace period=180
1067:2022-03-31 22:10:33 DEBUG (MainThread) [custom_components.lifx] (Discovery) action=broadcast, count=1, GetService, pkt=2, seq=0, ack=0, resp=1
1080:2022-03-31 22:10:38 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=55, step=5
1087:2022-03-31 22:10:43 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=50, step=5
1094:2022-03-31 22:10:48 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=45, step=5
1104:2022-03-31 22:10:53 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=40, step=5
1122:2022-03-31 22:10:58 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=35, step=5
1136:2022-03-31 22:11:03 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=30, step=5
1149:2022-03-31 22:11:08 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=25, step=5
1162:2022-03-31 22:11:13 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=20, step=5
1172:2022-03-31 22:11:18 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=15, step=5
1182:2022-03-31 22:11:23 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=10, step=5
1201:2022-03-31 22:11:28 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=5, step=5
1214:2022-03-31 22:11:33 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=0, step=5
1227:2022-03-31 22:11:38 DEBUG (MainThread) [custom_components.lifx] (Discovery) action=restarting, elapsed_time=65.02603161206935
1228:2022-03-31 22:11:38 DEBUG (MainThread) [custom_components.lifx] (Discovery) action=broadcast, count=2, GetService, pkt=2, seq=0, ack=0, resp=1
1247:2022-03-31 22:11:43 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=55, step=5
1260:2022-03-31 22:11:48 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=50, step=5
1271:2022-03-31 22:11:53 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=45, step=5
1289:2022-03-31 22:11:58 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=40, step=5
1302:2022-03-31 22:12:03 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=35, step=5
1312:2022-03-31 22:12:08 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=30, step=5
1328:2022-03-31 22:12:13 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=25, step=5
1335:2022-03-31 22:12:18 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=20, step=5
1346:2022-03-31 22:12:23 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=15, step=5
1361:2022-03-31 22:12:28 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=10, step=5
1368:2022-03-31 22:12:33 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=5, step=5
1378:2022-03-31 22:12:38 DEBUG (MainThread) [custom_components.lifx] (Discovery) countdown=0, step=5
1391:2022-03-31 22:12:43 DEBUG (MainThread) [custom_components.lifx] (Discovery) action=restarting, elapsed_time=65.01489536499139
1392:2022-03-31 22:12:43 DEBUG (MainThread) [custom_components.lifx] (Discovery) action=broadcast, count=3, GetService, pkt=2, seq=0, ack=0, resp=1

[bjeanes]

I think the only other thing to mention is that the LIFX bulbs are on another VLAN (HA is on 10.10.10.x and IoT stuff are reside on a VLAN with subnet 10.10.20.x). They always were (when they used to work) but if anything has changed substantially in how bulbs are discovered that limits it to the current network.

[Djelibeybi]

Can you ensure you've got mDNS repeating between your VLANs? Use something like https://apps.apple.com/us/app/discovery-dns-sd-browser/id305441017 to see if you can see the mDNS announcements from your HA VLAN.

[bjeanes]

HA is on my main VLAN, it's just LIFX and similar things on a different VLAN. But yes, I can see mDNS announcements across VLANs

These are all on a separate VLAN, for instance:

And the _hap._tcp namespace(?) is showing things from 10.10.10.x (untagged/default VLAN that this computer and HA are on), 10.10.20.x (IoT, and it shows the LIFX bulb there), and 10.10.30.x (another IoT VLAN but with stricter controls on external connectivity):

[tekstein]

Bulb model is called lifx original. Firmware is 2.1 On Mar 31, 2022, 3:42 AM -0500, Avi Miller @.***>, wrote:

What model bulb? What firmware version? You can find both of these in the LIFX app under Tech Specs for the bulb. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[Djelibeybi]

Could you please move a bulb to the HA VLAN to see if that works? That will narrow down the issue considerably.

[Djelibeybi]

HA is on my main VLAN, it's just LIFX and similar things on a different VLAN. But yes, I can see mDNS announcements across VLANs

Ok, so mDNS is what HA uses to determine if you have any bulbs, but broadcast UDP is what the aiolifx library uses to actually find them. Can you ensure you're allowing UDP on port 56700 from HA to the LIFX VLAN? And UDP replies from the bulbs?

[Djelibeybi]

If you're comfortable on the command-line, installing Photons on a device on the HA VLAN and then running lifx lan:device_finder_info would tell us if discovery is working cross-VLANs.

[bjeanes]

Could you please move a bulb to the HA VLAN to see if that works? That will narrow down the issue considerably.

I actually can't, because LIFX app won't let me re-setup this bulb because it forces HomeKit but those old bulbs have no HK pairing code (also: I don't want to use HK). I have no Android phone. This bulb simultaneously works in the LIFX app already and shows up as an option in "New Light" flow. It's bizarre.

Annoyingly, even for the one newer LIFX bulb I have which does have an HK code, I can't add it unless I add it to HomeKit (and the HK code is on the bulb, so you have to remember to write it down before plugging it in 🙄). I'm so annoyed by this flow. Just let me add the bulb and then later, separately and optionally, link it to HomeKit.

Ok, so mDNS is what HA uses to determine if you have any bulbs, but broadcast UDP is what the aiolifx library uses to actually find them. Can you ensure you're allowing UDP on port 56700 from HA to the LIFX VLAN? And UDP replies from the bulbs?

I allow everything on all VLANs to talk to HA on any port and vice versa.

... HOWEVER, I think the issue is that UDP broadcasts don't cross subnets. I found https://community.ui.com/questions/Getting-UDP-Broadcasts-across-subnets/07aa70c4-0bf4-4e4c-80e5-300c27134dcf with some workarounds I could explore, but it gets into fuzzy territory.

The question is -- why did this work before? Did it previously get bulbs from LIFX account instead of LAN discovery, perhaps?

In any case, I'll explore setting it up so UDP broadcasts can traverse subnets or see if I can put my HA instance on all subnets directly. Probably the latter.

Thanks for your patient help debugging this with me.

[Djelibeybi]

If you want to onboard a LIFX builb without using the app: https://github.com/tserong/lifx-hacks

[Djelibeybi]

If you hardcode the IP addresses, it doesn't broadcast. So that's unicast UDP and that traverses VLANs just fine. So if you add that to the configuration.yaml, it should work.

[bjeanes]

Ack. Thanks for those tips.

I think I can bind my HA OS appliance VM to some extra veths and have it broadcast on all subnets anyway, but if that doesn't work, I'll statically define the bulbs. The former seems preferable though as this kind of issue may rear its head with other integrations anyway.

[Djelibeybi]

The HA folks have been making a bunch of changes to networking in HA OS. I found I had to bind to a specific interface instead of the "auto" default to get other stuff to work, so perhaps try that too? The networking stack from inside Docker containers is complex and I'm glad someone else has to deal with it, not me. :)

[tekstein]

This fixed my issue. Thanks for the help! On Mar 31, 2022, 7:46 AM -0500, Avi Miller @.***>, wrote:

Could you please move a bulb to the HA VLAN to see if that works? That will narrow down the issue considerably. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[bjeanes]

@tekstein you also had a separate VLAN?

[tekstein]

Yes I did. On Mar 31, 2022, 9:49 PM -0500, Bo Jeanes @.***>, wrote:

@tekstein you also had a separate VLAN? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[bjeanes]

Cool. What do you think about renaming the issue and closing it, since this isn't an issue with HA but merely network configuration? At best, something about this caveat could be added to some docs somewhere.

[Djelibeybi]

It would be super helpful if one of you could install some older HA versions with your current VLAN setup to see when discovery stopped working. It doesn't even need to be an HA OS install. Doing inside multiple virtualenv instances on a single machine is fine. I don't use VLANs, so I can't reproduce it here.

[bjeanes]

Hmm... my familiarity with python and virtualenv is pretty subpar but I might be able to try this next weekend (if I remember). I'm in Melbourne for a few days from tomorrow morning so won't be on my network.

[Djelibeybi]

I'm in Melbourne for a few days from tomorrow morning so won't be on my network.

Welcome to Melbourne. I'm waving from the north eastern suburbs. :)

[bjeanes]

(I'm usually in Bendigo :D)

[borez]

Could you please move a bulb to the HA VLAN to see if that works? That will narrow down the issue considerably.

I've got the same issue on HA 2022.4.5, where my bulbs are on another VLAN and my Pi HA installation on the main subnet via LAN.

Tried connecting the Pi to my IOT subnet via WiFi, set HA's network to use only the WiFi interface and the LIFX bulbs are back on.

[bjeanes]

I think I can bind my HA OS appliance VM to some extra veths and have it broadcast on all subnets anyway, but if that doesn't work, I'll statically define the bulbs. The former seems preferable though as this kind of issue may rear its head with other integrations anyway.

Unfortunately, this does not seem to fix it. Even though the HA appliance has an IP on each network, it doesn't seem to broadcast/search on all networks. Perhaps not all are exposed to the hass_core container or something.

[Djelibeybi]

Unfortunately, this does not seem to fix it. Even though the HA appliance has an IP on each network, it doesn't seem to broadcast/search on all networks. Perhaps not all are exposed to the hass_core container or something.

The LIFX integration is supposed to send the broadcast out to all networks, but recent changes to networking may have broken this. We really need to find out what the most recet working version is, so we can evaluate the changes made since then to determine which may have caused this regression.

[bjeanes]

Yeah... I know I said I'd help with that but I forgot about it until now and I'm back in Melbourne from tomorrow morning for rest of week.

What worked for me to fix this locally, for now, is:

lifx:
  light:
    - broadcast: 10.10.10.255 # Home VLAN
    - broadcast: 10.10.20.255 # IoT VLAN
    - broadcast: 10.10.30.255 # NoT VLAN

(+ adding the appliance to all networks but not 100% sure if that was necessary or not, but am going to leave it like that)

[Djelibeybi]

Assuming all your LIFX bulbs are on the IoT VLAN, that's the only one that should be required. I suggest removing the other two to see if it still works. If so, keep it that way to reduce unnecessary broadcasts hitting those networks.

[bjeanes]

I have one bulb that is on the Home VLAN and I can't seem to reset it, but I can definitely remove the 3rd one.

[Djelibeybi]

Does the Reset button in the LIFX app not work?

[bjeanes]

No it's more that the other bulb of this model won't let me set it up without HomeKit and the lifx-hacks thing you linked earlier doesn't seem to work for me either, so I don't want to reset it.

[Djelibeybi]

The lifx-hacs thing relies on the HomeKit stuff timing out, so both require you to wait at least 15 minutes for the bulb's wifi to appear.

While you wait for that to happen:

1. make sure that only the IoT VLAN is set to auto-join on your phone
2. disable mobile data
3. force-close the LIFX app using the swipe up gesture

Once the bulb's wifi network appears:

3. join the bulb's network
4. open the LIFX app. Your existing bulbs will appear offline. This is expected.
5. hit the "+" add device button
6. follow the onboarding process, which should now be relatively quick. At the end, it'll join the IoT VLAN and all your bulbs should now be visible
7. ...
8. PROFIT

I've had at least one model of every bulb released from Kickstarter onwards and I've never had an issue onboarding them using this process. And I'm a lunatic who will move all 60 of my bulbs on a whim.

[bjeanes]

Thanks. That took two tries, but did eventually work.

[Djelibeybi]

I've now gotten into the habit of hiding my network complexity completely when onboarding IoT devices. Vendors of consumer-oriented devices assume a very simple home wifi setup, or (at best) a high-end consumer mesh solution. Very few test with complex multi-VLAN deployments.

[Djelibeybi]

btw, if you do find yourself with some hours to kill, it really would be great if we could narrow down when it broke. I'd be happy to work with you over a shared session (like Zoom or TeamViewer) to do the actual bisection of release versions, if you want.

[bjeanes]

The LIFX integration is supposed to send the broadcast out to all networks, but recent changes to networking may have broken this.

I just updated to 2022.5 and poking around noticed this:

It seems to imply this specifically is about multicast. If set to "automatic", the text implied only the 10.10.10.255 would have broadcasts sent. This would possibly explain

[Djelibeybi]

Yes, I changed this for the 2022.05 release. See the breaking changes section of the release notes. The old behaviour actually caused more problems than it solved.

[bjeanes]

Oh cool. I see it now. Does that mean this issue is closed?

[Djelibeybi]

I guess that's up to @tekstein as they opened the issue in the first place.

[bjeanes]

They also confirmed the above discussion fixed their issue

[Djelibeybi]

I don't have the ability to close this issue, so either @tekstein or one of the maintainers need to do so.

@bdraco can you close this issue for us?