LIFX Developer Zone

Add HTTP API product identifiers to products.json

This should work, though I have noticed when working with Photons that if a bulb has gone into power save mode then it may not wake up fast enough for the default timeout for discovery. This usually results in the app only discovering 35-50 of my 55 bulbs.

I would strongly discourage checking every IP though, and wouldn’t run any app that did this. In fact, my network security would probably blacklist my phone as soon as it tried for security reasons. It would also take a fair amount of time because I use quite a large network range so the app would sit scanning tens of thousands of possible IP addresses.

So, while I don’t doubt this solution would work, I’m going to politely decline to test it. I’d be happy to test a solution that periodically runs the UDP broadcast to find bulbs that have been added since the last scan. It should be doing this anyway, just for normal operations.

1 Like

Ok, understood. I will revert the change for checking every IP.

What I am going to do instead is send a broadcast message periodically, like you suggested. Furthermore, remember previously connected light IP addresses so the app can connect faster on startup. Does that sound right to you? Do you think that would find every light?

I think a periodic broadcast to find new lights is a good idea. You should only remember the IP address for a light for the current session. You don’t want to try and do unicast connections on old IP addresses because that could also trigger a security scanner that your app is scanning the network.

Rather, rely on the documented LIFX LAN protocol option for discovery. :slight_smile:

1 Like

The way discovery works in Photons is something like

  • broadcast GetService
  • If I get no responses then retry the broadcast after a period of time (starts at 0.2 seconds and slowly increases till their 1 seconds apart)
  • If I get any responses, then keep waiting until it’s been 0.4 seconds since the last response and assume all the collected results are everything

And also if I have any responses and I’m still waiting for that 0.4 second gap when overall timeout passes, then wait past the overall timeout till that gap has happened.

The code that does the most of the work is my favourite function in photons to be honest and is used specifically for discovery here.

1 Like

Out of curiosity, what is the overall timeout? And how did you calculate the 0.4 second gap?

I ask because the beacon interval is 100ms and the DTIM period most often recommended for most APs is 3, so devices that are sleeping only wake up every 300ms so they only have 100ms left to respond to your broadcast before the timeout occurs. Vaguely.

I’d love to tweak these settings to see if it results in a more stable discovery of the bulbs locally.

The numbers aren’t scientific :slight_smile:

They’re set over here https://github.com/delfick/photons/blob/main/modules/photons_transport/retry_options.py#L45

and overall timeout is set when you do discovery, but defaults to 20 seconds

(It’s probably worth spinning off this discussion away from the original HTTP API request)

@HueEssentials it would be super peachy keen if you didn’t cut and paste the same text for each build and rather specified exactly what the changes for that build are. Right now, I don’t know if the latest build I’m seeing (13) includes the network scanning code or not.

@delfick I think there is scope for some tweaking here and also a bit of confusion. I don’t think I’ve ever seen Photons wait 20 seconds to finish discovery, so how would that particular timeout value get hit? I certainly think these values are the cause of that issue where Interactor used to complain about getting messages without a future, or something, because I suspect the response from the (sleeping) bulb came after the timeout expires.

are you able to make an issue on photons github? and we’ll continue there

I also meant the Hue Essentials bits after the HTTP API stuff was sorted. :slight_smile:

Thanks for the information @delfick, I will look into it.

Alright, will add the changes for the next build. The currently latest build 1.9.0 (13) includes the network scanning, so skip that one. I will remove it from TestFlight. The next version will be 1.9.0 (14) with only UDP broadcasts for discovery, I will put that in the changelog for that build.

1 Like

Early testing of build 14 is very promising. I see the bulbs populate over time.

1 Like