ApiError: Problems resolving hue bridges, HTTP error status: 429

[lexicalunit]

ApiError: Problems resolving hue bridges, HTTP error status: 429

[peter-murray]

With the deprecation of the UPnP and the addition of mDNS, it looks like I will need to add that to the library as an alternative approach for discovery now.

[peter-murray]

I have released a new version with mDNS support, see here for details #221 (comment)

[pixlpirate]

Same for me, identical error status and message. My script has been working fine for months until today.

[peter-murray]

It is not the library; https://developers.meethue.com/rate-limiting-status-code/

[peter-murray]

I have a complete lack of visibility to the use case here and the full manifestation of the error, can you provide some more context and a reproducible way for this error to be created?

[lexicalunit]

This is the code: https://github.com/lexicalunit/busylight/blob/main/cli.js

Essentially I'm just doing:

    const results = await discovery.nupnpSearch()
    const host = results[0].ipaddress
    const secure = await api.createLocal(host).connect(settings.username)
    const light = (await secure.lights.getLightByName(options.light))[0]
    const state = stateFromOptions(options)
    await secure.lights.setLightState(light.id, state)

[pindab0ter]

I'm experiencing the same issue when trying to develop an extension using this package. When I started today, everything was alright. But after several uses of discovery.nupnpSearch() I'm now getting the exact same issue.

For the record, all I've used for this error to appear up until this point is discovery.nupnpSearch().

[peter-murray]

From the Hue documentation it looks to be active as of now:

NOTE 1 – UPnP (or more specifically the UPnP subset Simple Service Discovery Protocol (SSDP)) used to be available as another discovery method but has been deprecated in favor of mDNS and will be disabled in Q2 2022.

[peter-murray]

That deprecation warning should no impact this particular endpoint, as the nupnp search is reaching out to the Hue cloud to get the data back for the known register bridges, https://discovery.meethue.com

They will have some level of rate limiting on this endpoint to stop abuse, but I cannot see any details on a rate limit documented anywhere. Do you know how many calls you are making before this starts to trigger?

[peter-murray]

I managed to reproduce the rate limiting by hitting just the end point around 10 times in less than a minute. Hue are clearly protecting this endpoint now more than they used to, and it is technically an unauthenticated endpoint, so is a reasonable safety measure I guess to stop abuse...

That said, nothing that I am going to be able to remedy here, it is enforced by Hue themselves, I will take a look into the headers to see if there is any extra data about the rate limits, but nothing that I can change from the library side, Hue own the endpoint and can do whatever they like here.

[pindab0ter]

I just did a quick test and the limit seems to be 12. The thirteenth request fails. I don't know what the timeframe is.

[peter-murray]

Nothing useful in the returned headers indicating a window, number of api calls remaining or reset time:

[peter-murray]

I found this snippet buried in the Hue docs

The rate limit of using the discovery endpoint is maximum one request per 15 minutes per client. Typically it should be much less than that because the discovered IP can be stored and only rechecked when a request times out (as the ip might have changed). More regular ip scanning can always be done with mDNS.

[pindab0ter]

Works great on my end! Discovery takes about 4s for me, every time. So maybe the default timeout could be a little more than 5s.

[lexicalunit]

Works great for me too!