search

peter-murray / node-hue-api

Node.js Library for interacting with the Philips Hue Bridge and Lights
Apache License 2.0
1.19k stars 145 forks source link

Rate limiting #91

Closed genox closed 4 years ago

genox commented 8 years ago

Hi,

How does this module handle when multiple states change in a short period of time? Is there a queue of sorts that prohibits state changes from getting lost or a retry if a state change was rejected due to the bridge's rate limit?

I have multiple toggles, each for a bulb. When I hit them fast enough, only the last bulb's state is actually being changed. This causes the apps states to be inconsistent.

genox commented 8 years ago

Found this:

"How many commands you can send per second?

You can send commands to the lights too fast. If you stay roughly around 10 commands per second to the /lights resource as maximum you should be fine. For /groups commands you should keep to a maximum of 1 per second."

What I can't find is info on how fast commands can be sent, e.g. if commands sent faster than ~100ms apart are problematic. But it seems that way. It would probably make sense to implement a module like bottleneck to limit consecutive calls to 100-150ms.

https://www.npmjs.com/package/bottleneck

peter-murray commented 8 years ago

I have always left it to the consumer/developer to not storm the bridge with excessive commands. There has never been an error code from the bridge to determine that you are storming it with commands, which may have changed now, I will need to reread the current API documentation.

Whilst it may be possible to rate limit in the library, I am uncertain that is something I would want to do, as the library is only meant to be a thin wrapper around the REST API of the bridge itself. The problem is that in some cases rate limiting calls would result in noticible delays visible to users when you start chaining commands, some of which may be necessary, others not.

I will take a look and propose something as a follow up in a few weeks, as I don't have time in the next three weeks to do any work on this.

genox commented 8 years ago

I understand your concerns and thanks for considering. Since the rate limiting is technically part of the API for better or worse, I think it would make sense to allow for optional rate limiting. Handling this in the client is semi optimal at best as there might be multiple clients. I will probably create a fork. Let's see.

peter-murray commented 4 years ago

Completed using bottleneck in 4.0.0-alpha-3