Open RkcCorian opened 7 months ago
seb2010
commented
7 months ago 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
commented
7 months ago 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
commented
7 months ago 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.
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!