Rate Limit

[barcar]

Would it be possible to add a configuration to set a rate limit for tag readings?

Maybe something like "only send readings if they are x seconds older than the last reading" (for any sensor/metric).

[Scrin]

Something like that would likely be possible, although the exact way to do that would require behavioral changes. Currently ruuvi-go-gateway "mimics" the physical gateway behavior, which is:

• For MQTT, the measurements are published as they are received in real time over the open connection to a MQTT server
• For HTTP, the ruuvi-go-gateway "ticks" at 10s interval (by default, but this is configurable) and sends the newest received measurement for each tag

To add a rate limit, I suppose the MQTT implementation could either throttle by discarding or buffering measurements, and the HTTP version could perhaps be changed to skip a "tick" if no new measurements were received since the previous HTTP POST.

Could you elaborate a little why you need a rate limit, so that I can come up with the best solution?

[barcar]

Really it’s just about the frequency of readings being pumped into Influx DB. The default Ruuvitag frequency is much higher than I need.

I could rate limit it downstream but I was wondering if it could be done at (almost) source in the gateway.

I’m using MQTT, so discarding intermediate readings would work for me.

[Scrin]

Right, I guess adding an optional rate limit to MQTT specifically could be done with reasonable effort, and it would also be useful in situations where the MQTT server is either rate limited itself or a service that's billed by the amount of messages or something, so I think it would be an useful feature to have

I need to think about the optimal way to do this along with a few other architectural changes I have planned, since right now the benefit of MQTT is that it's a "fire-and-forget" system that supports virtually unlimited amount of sensors without any memory or CPU overhead, but adding a rate limiter would increase the CPU and memory usage since it would need to keep track of each sensor separately to "remember" when they were last transmitted

That combined with the fact that my free time is pretty limited at the moment means that it will take some time before I get to implement this