Integration broken w/VLAN in 5.5+ (including recent beta)

Question

Integration broken w/VLAN in 5.5+ (including recent beta)

Ixian opened this issue 2 years ago · 11 comments

Any version of HA from 5.5 onwards (including the new 6.1) breaks the LIFX integration for me. Existing bulbs show offline and do not come back even if the integration is reloaded. If I delete and re-add the integration, it doesn't discover any bulbs at all. I've tried with the built in integration and this beta via HACs, same behavior.

I'm wondering if this has to do with my VLAN. My bulbs site on a different VLAN on my network (192.168.40.x my "regular" subnet is 192.168.1.x). HA is configured for both networks, can ping items on both from the console, including the bulbs themselves (which I have configured statically on that VLAN). Prior to 5.5 it discovered them just fine. In fact my current "solution" is rolling back to the last backup I have of 4.7, at which point they start working again.

Did something change and perhaps HA no longer looks beyond it's default interface for bulb discovery? If so that will break more setups than mine, it's fairly common to put "IOT" stuff on a separate VLAN.

Appreciate the work on the beta and any insight you can offer!

Answer 1 · 2022-06-01T22:04:25.000Z

Networking in HASS got a bit of an overhaul recently. Can you please check Settings -> System -> Network and make sure the interface for each VLAN is active/enabled? The LIFX integration won't send discovery packets to inactive/disabled interfaces.

Answer 2 · 2022-06-01T22:08:07.000Z

Networking in HASS got a bit of an overhaul recently. Can you please check Settings -> System -> Network and make sure the interface for each VLAN is active/enabled? The LIFX integration won't send discovery packets to inactive/disabled interfaces.

Thanks! Yes, they are active and enabled, and I can ping both subnets from the HA box, I can even ping the bulbs themselves.

Answer 3 · 2022-06-01T22:17:42.000Z

Can you please enable debug logging:

logger:
  default: info
  logs:
    homeassistant.components.lifx: debug
    custom_components.lifx: debug

Then let HASS run for at least 3-5 minutes after fnishing startup and then either pastebin the lines that include either homeassistant.components.lifx or custom_components.lifx or if you prefer, email them to <github@dje.li> so I can take a look?

Answer 4 · 2022-06-01T22:45:21.000Z

All I'm getting in the logs is

[homeassistant.setup] Setup of domain lifx took 0.0 seconds
and
[homeassistant.components.light] Setting up light.lifx

All lights still show unavailable. Also, I'm using the latest LIFX beta via HACS now, but I don't see an option for allowing duplicate discovery - was that removed? The devices page shows it's using the custom component.

Answer 5 · 2022-06-01T22:49:23.000Z

Yeah, all the new discovery logic was taken out of the latest beta. I've basically gone back to the original discovery method, but using the new HASS networking. If you've added those lines to your configuration.yaml and you're not getting any DEBUG output in home-assistant.log then something is weird.

Do you have any hard-coded LIFX-related stuff in your configuration.yaml?

Answer 6 · 2022-06-01T22:55:05.000Z

I don't, but double-checked it anyway. My config and setup is pretty run of the mill.

It's almost like it finds nothing on the default network and stops, though it is strange no logs output beyond the initial load. I am checking the Home Assistant Core logs via Settings>System>Logs to be clear.

Answer 7 · 2022-06-01T23:06:12.000Z

Aha. There is something off with auto-discovery on VLANs now.

I added the following config to force HA to look to the correct subnet:

lifx:
  light:
    - server: 192.168.40.56
      port: 56700
      broadcast: 192.168.40.255

Rebooted and it works. All devices show up and the logs are full of standard messages re: bulb connections such as:
[custom_components.lifx.light] Connecting to 192.168.40.10

So, good in that there's a workaround, but I suspect this will hit more folks if auto-discovery still doesn't work.

Answer 8 · 2022-06-01T23:08:08.000Z

What does your "Network Adapter" section of Settings -> System -> Network look like? That's what controls which adapters HASS uses for discovery.

Answer 9 · 2022-06-01T23:11:10.000Z

If you don't have 192.168.40.56 enabled as a Network Adapter, then auto-discovery won't happen on that VLAN.

Answer 10 · 2022-06-01T23:15:10.000Z

What does your "Network Adapter" section of Settings -> System -> Network look like? That's what controls which adapters HASS uses for discovery.

Aha again! I didn't even notice that section - appears to be new? It was set to auto-configure and picked the first interface, of course, but if I de-select that option I can tell it to monitor my VLAN as well.

I went ahead and backed out the config changes I made to force Lifx discovery on that VLAN subnet, rebooted, and it still works as it should. So that was it - I'm guessing that was a new setting introduced last month.

Given that it defaults to the "main" interface I suspect some others will see this problem but good to know there's a simple fix. Thanks!

Answer 11 · 2022-06-01T23:18:15.000Z

Yep, that controls mDNS/Zeroconf discovery in general, so ensuring all your VLANs are enabled is a good thing. I guess I need to tell more folks about it!

Meanwhile, I'm busy creating a test VLAN to make sure I can reproduce the issue and for future regression testing purposes.

I'm going to go ahead and close this issue for now. Please do open a new one if you notice anything weird, though.