Skip to content
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

Please make Rate Limiting configurable #234

Open
RkcCorian opened this issue Dec 25, 2023 · 3 comments
Open

Please make Rate Limiting configurable #234

RkcCorian opened this issue Dec 25, 2023 · 3 comments

Comments

@RkcCorian
Copy link

Dear developer,

I have several groups and I know even with a smaller waiting time btw. group commands it is working for me and is much more performant (faster) when switching states of multiple lights.

To get this feature officially.. can you please make the Rate Limiting configurable?

Many many thanks for your support!

@seb2010
Copy link

seb2010 commented Dec 25, 2023

The issue (also) seems to be, that although a client-library build on top of node-hue-api may be issuing custom RateLimits as a parameter of the createLocal function, but the RateLimits for Lights and Groups are additionally hard-coded in the Groups.js and Lights.js folder in the lib/api folder.

Or maybe you could hint us towards the proper procedure on how to pass down custom RateLimit to the api-interface...

@peter-murray
Copy link
Owner

The rate limits that are hard coded are those that Signify state in the documentation as to being the requirements to ensure access complies to their best practices.

Whilst it might be possible to push the bridge harder and faster, it can and will eventually break the responsiveness for the end user or other integrations.

It is would not particularly too difficult to bubble these up to being controllable via an instantiation of the API, I don't believe going against the recommendations of the manufacturer in this regard as it does not take much to overload these bridges.

@seb2010
Copy link

seb2010 commented Jan 15, 2024

Hi @peter-murray, thank you for your response.
To me, it looks like the ability to override the RateLimits via instantiation-parameters is already prepared. And if someone overrides these parameters on purpose, he should know what he is doing. As for me I can say, that I am riding with 50ms group-command delay (opposed to 1000ms recommended) for my living room without issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants