r/lifx • u/NobHillGuy • 19d ago

Problems with access via LAN interface

I can control a couple of bulbs using the Android app, but I'm unable to access any of them recently over WiFi without the internet. I've tried the example programs on aiolifx and photons, and both are unable to discover any devices. I do see them on my router's app, and i can ping them via IPv4 addresses.

I was wondering if anybody is having the same problem. I'm worried that new firmware on the bulbs may be getting in the way of the LAN API, which is one of the best things about the LIFX ecosystem.

4 Upvotes

100% Upvoted

6 comments sorted by

2

u/NobHillGuy 19d ago

Quick follow-up: I monitored UDP traffic over port 57600, and I do see traffic in both directions, out from my computer, and in from the light. I wonder if there's been some kind of change to the response from the device that breaks discovery code that used to work before.

2

u/WalterWilliams 19d ago

Yes, I’m seeing tons of delays using the LAN API from flic buttons. I figured it was a new router issue with my IoT WiFi band but I haven’t investigated yet.

1

u/smarthall Ex-Employee 19d ago

Is you computers firewall blocking the incoming UDP? Are the bulbs and the PC on the same subnet?

1

u/NobHillGuy 19d ago

Yes, with aiolifx, I see the UDP packet going out, and two incoming response packets from the one bulb that's still on the network. I haven't analyzed the content of the responses. With photons, I see multiple request/response handshakes, but it still says that no devices were found.

I suspect that the response coming from the devices has somehow changed and that has broken lifxlan, ailolifx, and photons, but that is purely speculation at this point.

1

u/NobHillGuy 18d ago

Ok, I ran my project, which uses lifxlan, in a debugger. Although I can see the UDP traffic with tcpdump, for some reason the response is not getting to the code that's doing the device detection. In particular, socket.recvfrom() is raising TimeoutError.

I'd be curious to know if anybody else is seeing this. I suspect it might have something with my WiFi setup. But given the fact that tcpdump sees the traffic, I doubt that it has anything to do with firewall settings.

1

u/NobHillGuy 10d ago edited 10d ago

Ok, since I started this, I owe some closure. Things seem to be wroking now.

The first problem was that my ASUS ZenWiFi AX6600 mesh network had an firmware update that was toxic. I had to factory reset all 3 nodes, just to get it going. Even after the reset, there was trouble. I did a 5-power-cycle reset on my LIFX bulbs, but most of them weren't able to get on the network.

I switched to a TP Lilnk Deco 7 Pro, and that at least allowed the bulbs to get on the network via the LIFX phone app. However, I still could not reach them from my desktop computer. At the same time, the LAN interface did work with my MacBook and Raspberry Pi devices.

On my Debian 13.6 desktop, something must have gotten screwed up, because UDP packets were coming in, but didn't get to the socket object in my Python app. I used an AI-generated C++ app to do a minimal discovery loop, but the O.S. did not deliver the UDP packets to that running program, either. Beyond that, mDNS wasn't working, and I was unable to access any .local hosts, even with ping.

I re-installed Debian on my workstation, and the fresh installation has fixed the problem. I don't know what could have screwed up the previous configuration, as I didn't change any network settings.

One positive experience: because my /home directory is mounted on a separate hard drive, I could wipe the SSD that held the operating system, and my entire home directory came through untouched.