MQTT Problem and Rate Limiting in General


I have a vibration sensor that generates MQTT events, and those are handled by n8n and eventually generate matrix notifications.

The problem I am facing is that the sensor does not generate 1 clean event, but usually a bunch of consecutive events. 4 or 5 within the same couple of seconds.

This results in the generation of batches of notifications instead of 1 clean notification.

How can I prevent this from happening?

My first thought was to look for a rate limiting node. One that would take the rate and limit the number of executions per time unit, that I would place right before the notification. But I don’t think there is such a thing yet.

Then I thought, perhaps there is a Workflow variable that executions share, where I can annotate the last notification and implement the same thing from a function node. But I am not sure it is possible.

Any Ideas? How do you deal with this issue?

Hey @rvalle!

Welcome to the community :sparkling_heart:

For such a use case, I would store the data in a database (or Google Sheets or Airtable) and then fetch the information from there every minute. I would then combine the incoming data and send it to Matrix.

The other way is to use a service like Redis to store the data.

Every time your workflow executes, you will lose the data from the previous execution i.e you can’t directly access the data from the previous executions. Hence, I would store it in a database temporarily and fetch it from there.


That is a geat idea. I did not notice there was redis connector.

I think I can deploy one alongside n8n to be able to do more things.

I kind of remember it is possible to give redis entries expiry date and that also support counters. perhaps incrementing a counter with expiry date solves the whole problem in one workflow.

Thanks, I will investigate :slight_smile:

1 Like

No worries! I am happy that I could help :slight_smile:

With the Redis node, you can set values, set expiration time, as well as increment values.

I would love to see the solution that you build. Please do share it here so that others can benefit from it as well :sparkling_heart:

1 Like

Sure! will do.

1 Like

This is the idea:

A message is received, and then parsed (json as string)

Not all messages are vibration, devices also report things like battery status, and those as discarded first.

If the message is about vibration then we use an increment counter with 5 minutes expiry. An we will use 1 as the limit. So, only the first message after 5 minutes without activity is reported.

I have the option to differentiate amount multiple types or reported values (drop, vibration, tilt, etc) which I am not using yet,

Last a notification is sent.

Here is the workflow:

It is now working, in principle. Instead of bursts of 5-6 alerts I am getting just one.

However, I am noticing something strange. When I subscribe with mosquitto command line tools I get order of magnitude less notifications, something with MQTT listener is acting up.

after restarting the n8n container the strange condition stopped happening. I suspect there is something going on while editing the workflow, like a leaked listener or something…

Thank you for sharing this. Can you share some more information that might help us replicate it on our end?