-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ApiError: Problems resolving hue bridges, HTTP error status: 429 #222
Comments
Same for me, identical error status and message. My script has been working fine for months until today. |
It is not the library; https://developers.meethue.com/rate-limiting-status-code/ |
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? |
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) |
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 For the record, all I've used for this error to appear up until this point is |
From the Hue documentation it looks to be active as of now:
|
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? |
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. |
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. |
I found this snippet buried in the Hue docs
|
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. |
I have released a new version with mDNS support, see here for details #221 (comment) |
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. |
Works great for me too! |
I have a CLI built using
node-hue-api
that has been working fine for months. Suddenly I'm getting rate limits now. I got a rate limit today and I haven't even run the CLI once today before that. The rate limits make no sense.The text was updated successfully, but these errors were encountered: