Please make Rate Limiting configurable

[RkcCorian]

Please make Rate Limiting configurable

[seb2010]

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]

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]

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.