MQTT Flooding Messages from Shelly

hey guys, today my mqtt broker (eclipse-mosquitto) seems to flood my node-red at all.

I have a couple of Shelly Plug S in my smarthome. They send multiple messages of their actual state like temperature/energy/relay state/power and so on.

If I connect my mqtt broker node with any node that follows this flow I get a overflooded node-red that consumes 100% CPU on my Raspberry Pi. Then I just tryed it on my home PC with MQTT.FX to see what is going on there.

In about 3 minutes I got around 1.600 messages from 7 Shelly Plug S devices o_O

How can this be properly managed by node-red.
I know there is the rate/limit but if I will use this it could be possible that the main messages I'm waiting for will be dropped (in case of drop immediate msg) or they take too long to be used in the following flow (because all nonsense msg will be send first at random)...

How should I do this properly?

You have an MQTT loop, so something is subscribing to the topic and message goes through nodes and ends up publishing it again, which initiates a new message at the subscriber, etc. Often this is through a dashboard node where you have told it to pass input messages to the output. Stop the mqtt server and then look at what is subscribing to the topic and follow the flow through. A hack to get it going in the meantime is to insert an RBE node to stop the flow of identical values, but ideally find what is actually causing it.
Sometimes loops can be more complex, involving multiple devices and more that one topic. Use the command line client to subscribe to "#" and you will be able to see which topic(s) are involved, or perhaps you know that already.

3 Likes

Thank you for your answer.

That could not be the issue. I never changed anything in past 2-3 weeks that belongs to my MQTT nodes!
It started today at 9:48 am.... I even wasn't at home to change anything :frowning:

Will take a 5th look at all my flows. Starting to think about that my Shellies or just one is broken.

EDIT: What I found out so far is that there are incoming messages from switched off shellies every 25-35 seconds. That seems to be the keep alive messages. The shellies are configured this way that they should send them all 2 minutes. mhhh...

Actually 1600 over 3 minutes is only 10/second, a pi should be able to handle 1000/second. Something else is going on.

1 Like

Ah ok, I thought this will be too much right now :slight_smile:

EDIT: Forget it... you were right! The test switch wasn't configured right.... that was connected the one not connected shelly that is laying around... I didn't take a look at this on my debug trys (because it wasn't in use)....

Now it seems to be fixed :slight_smile:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.