Der Node-RED Delay-Node hält Nachrichten für eine festgelegte Zeit zurück oder gibt sie mit einer festen Rate frei. Damit ist er der einfachste Weg, schnelle MQTT-Datenströme zu bändigen. In diesem Tutorial nutzen Sie ihn, um hochfrequente Sensordaten vor dem Publizieren zu drosseln, jedes Topic einzeln zu begrenzen, zwischen Puffern und Verwerfen zu wählen, die Warteschlange zur Laufzeit zu steuern und bequem innerhalb der Broker-Limits zu bleiben.
Warum Rate Limiting für MQTT-Flows wichtig ist
Ein Sensor, der alle 100 Millisekunden abtastet, erzeugt zehn Nachrichten pro Sekunde. Multiplizieren Sie das mit ein paar Dutzend Sensoren, und Node-RED schiebt Hunderte Nachrichten pro Sekunde zu dem, was nachgelagert ist. Oft braucht nichts davon diese Rate:
- Broker setzen Limits durch. Geteilte und öffentliche Broker begrenzen die Nachrichtenrate pro Client. Der kostenlose Öffentliche MQTT-Broker unter
broker.connectmq.comerlaubt zum Beispiel 10 Nachrichten pro Sekunde und Client. Wird das überschritten, werden Nachrichten abgelehnt oder der Client gedrosselt. - Dashboards kommen nicht hinterher. Ein Browser-Diagramm, das 50-mal pro Sekunde neu zeichnet, ist unlesbar und verschwendet CPU.
- Datenbanken und APIs rechnen pro Schreibvorgang ab. Jeden Rohwert in eine Cloud-Datenbank zu schreiben oder pro Nachricht eine HTTP-API aufzurufen, wird teuer und kann API-Ratenlimits auslösen.
- Benachrichtigungen nerven. Eine Temperatur, die um einen Schwellwert pendelt, kann Dutzende Alarme pro Minute erzeugen.
Der Node-RED Delay-Node löst all das ohne Code.
Die Modi des Delay-Nodes im Überblick
Öffnen Sie einen Delay-Node, und das Dropdown Action bietet zwei Verhaltensfamilien:
| Modus | Option | Was er tut | Typische Verwendung |
|---|---|---|---|
| Delay each message | Feste Verzögerung | Hält jede Nachricht gleich lange zurück | Entprellen, Aktionen in Reihenfolge bringen |
| Delay each message | Zufällige Verzögerung | Hält jede Nachricht für eine zufällige Zeit in einem Bereich zurück | Last verteilen, Geräte simulieren |
| Delay each message | Verzögerung mit msg.delay überschreiben |
Nutzt die Verzögerung in Millisekunden aus der Nachricht | Timing pro Nachricht |
| Rate limit | Alle Nachrichten | Gibt höchstens N Nachrichten pro Intervall frei | Schutz eines Brokers oder einer API |
| Rate limit | Für jedes msg.topic |
Begrenzt jedes Topic unabhängig und behält den neuesten Wert | Drosselung vieler Sensoren |
Der Delay-Modus verwirft nie etwas; er verschiebt Nachrichten nur zeitlich. Der Rate-limit-Modus puffert überzählige Nachrichten oder verwirft sie, je nach gewählter Option.
Puffern oder verwerfen: die entscheidende Frage
Im Rate-limit-Modus mit All messages wird standardmäßig gepuffert: Nachrichten über der Rate warten im Arbeitsspeicher und werden einzeln freigegeben. Aktivieren Sie drop intermediate messages, werden überzählige Nachrichten stattdessen verworfen. Aktuelle Node-RED-Versionen bieten außerdem an, Zwischennachrichten an einen zweiten Ausgang zu senden, sodass Sie den Überlauf woandershin leiten können, etwa an einen Zähler.
Entscheiden Sie anhand der Frage, ob jede Nachricht zählt:
- Jede Nachricht zählt (Befehle, Ereignisse, Stückzahlen): puffern. Achten Sie darauf, dass die mittlere Eingangsrate unter der Freigaberate liegt, sonst wächst die Warteschlange endlos.
- Nur der neueste Wert zählt (Temperaturen, Füllstände, Positionen): verwerfen oder den Modus pro Topic nutzen. Sie behalten frische Daten, und der Speicherbedarf bleibt konstant.
- Sie brauchen beides: Leiten Sie den Überlauf an den zweiten Ausgang und aggregieren Sie ihn, zum Beispiel zu einem Mittelwert.
Eine unbegrenzt wachsende Warteschlange ist der klassische Fehler beim Delay-Node. Übertreffen die Erzeuger die Freigaberate stundenlang, steigt der Speicherverbrauch, bis Node-RED langsamer wird oder abstürzt. Sie können Warteschlangen global mit der Einstellung nodeMessageBufferMaxLength in settings.js begrenzen, doch die bessere Lösung ist, für Telemetrie das Verwerfen zu wählen.
Beispiel: Einen schnellen Sensor vor dem Publizieren drosseln
Simulieren Sie einen verrauschten Sensor und drosseln Sie ihn auf eine Nachricht alle zwei Sekunden, bevor Sie auf einem Zusammenfassungs-Topic republizieren. Ersetzen Sie 3e5b durch eine eigene Zufallszeichenfolge, damit die Topics auf dem öffentlichen MQTT-Broker eindeutig bleiben.
[
{"id":"tabdl","type":"tab","label":"Delay demo"},
{"id":"brkdl","type":"mqtt-broker","name":"ConnectMQ public","broker":"broker.connectmq.com","port":"1883","clientid":"nr-delay-3e5b","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true},
{"id":"tick","type":"inject","z":"tabdl","name":"every 200 ms","props":[{"p":"payload","v":"","vt":"date"}],"repeat":"0.2","once":true,"onceDelay":"1","x":130,"y":80,"wires":[["sim"]]},
{"id":"sim","type":"function","z":"tabdl","name":"simulate vibration","func":"msg.topic = 'connectmq/demo/3e5b/press1/vibration';\nmsg.payload = { mm_s: Number((2 + Math.random() * 3).toFixed(2)), ts: msg.payload };\nreturn msg;","outputs":1,"x":330,"y":80,"wires":[["rate"]]},
{"id":"rate","type":"delay","z":"tabdl","name":"1 msg / 2 s, drop","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"2","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"allowrate":false,"outputs":1,"x":540,"y":80,"wires":[["pub","dbgdl"]]},
{"id":"pub","type":"mqtt out","z":"tabdl","name":"publish","topic":"","qos":"0","retain":"false","broker":"brkdl","x":730,"y":60,"wires":[]},
{"id":"dbgdl","type":"debug","z":"tabdl","name":"released","active":true,"complete":"payload","x":740,"y":110,"wires":[]}
]
Fünf Nachrichten pro Sekunde gehen hinein; eine Nachricht alle zwei Sekunden kommt heraus, immer ein frischer Messwert. Beobachten Sie das Ergebnis in einem Terminal:
mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-3e5b \
-t "connectmq/demo/3e5b/#" -v
Ohne den Delay-Node würde dieser Flow fünf Nachrichten pro Sekunde von einem Client publizieren, bereits die Hälfte des Limits pro Client auf dem öffentlichen MQTT-Broker. Mit einem zweiten Sensor wären Sie am Limit.
Rate Limiting pro Topic für viele Sensoren
Abonniert ein einzelner mqtt in-Node mit einer Wildcard wie connectmq/demo/3e5b/+/telemetry, behandelt ein einfaches Rate Limit alle Topics als einen Datenstrom. Ein gesprächiger Sensor würde dann einen leisen verdrängen. Stellen Sie den Delay-Node auf Rate limit → For each msg.topic um.
In diesem Modus behält der Node nur die jüngste Nachricht pro Topic und gibt sie mit der konfigurierten Rate frei, wobei er die Topics reihum durchläuft. Jeder Sensor kommt an die Reihe, und nur sein neuester Wert wird gesendet. Genau das will ein Dashboard oder ein Datenbank-Schreiber. Achten Sie darauf, dass msg.topic korrekt gesetzt ist; haben alle Nachrichten dasselbe Topic, verhält sich der Modus pro Topic wie eine einzige Warteschlange der Länge eins. In industriellen Flows, die einen Unified Namespace (UNS) nach ISA-95 abonnieren, etwa werk-muenchen/presswerk/+/+/vibration, sorgt der Modus pro Topic dafür, dass jede Anlage der Hierarchie gleichberechtigt berücksichtigt wird.
Die Warteschlange zur Laufzeit steuern
Ein Delay-Node im Puffermodus reagiert auf spezielle Eigenschaften eingehender Nachrichten:
| Eigenschaft | Wirkung |
|---|---|
msg.reset |
Leert die Warteschlange, ohne etwas zu senden |
msg.flush |
Sendet gepufferte Nachrichten sofort; eine Zahl sendet entsprechend viele |
msg.rate |
Ändert im Rate-limit-Modus mit der Option "allow msg.rate to override" die Rate in Millisekunden zwischen Nachrichten |
msg.delay |
Setzt im Überschreibmodus die Verzögerung dieser Nachricht in Millisekunden |
msg.reset ist nützlich, wenn eine Maschine stoppt: Gepufferte Messwerte von vor dem Stopp sind nicht mehr aussagekräftig. msg.flush hilft, wenn eine Verbindung zurückkehrt und Sie gepufferte Befehle auf einmal freigeben möchten. Verbinden Sie einen Inject-Node, dessen Eigenschaft auf true gesetzt ist, um sie auszuprobieren.
Alarme mit einer Verzögerung entprellen
Rate Limits heilen auch Alarmstürme. Setzen Sie vor einen E-Mail- oder Chat-Benachrichtigungs-Node einen Delay-Node mit einer Nachricht pro 10 Minuten und drop intermediate messages. Der erste Alarm geht sofort hinaus; Wiederholungen innerhalb des Fensters werden verworfen. Für Alarme pro Gerät setzen Sie msg.topic auf die Geräte-ID und nutzen den Modus pro Topic, damit ein Gerät nicht den Alarm eines anderen unterdrückt. Wenn Sie diese Logik lieber im Code halten, erledigt das Cooldown-Beispiel in unserem Leitfaden zu Node-RED-Subflows dasselbe pro Topic.
Checkliste häufiger Fehler
- Telemetrie puffern. Nutzen Sie Verwerfen oder den Modus pro Topic, wenn nur der neueste Wert zählt.
- Nach dem teuren Schritt drosseln. Setzen Sie den Delay-Node vor Datenbank-Schreibvorgänge, HTTP-Aufrufe oder aufwendige Function-Nodes, nicht dahinter.
- Fehlendes
msg.topic. Der Modus pro Topic braucht in jeder Nachricht ein aussagekräftiges Topic. - Delay und Rate Limit verwechseln. Der Delay-Modus verschiebt jede Nachricht; er reduziert die Nachrichtenanzahl nicht.
- Auf der falschen Ebene drosseln. Publizieren Geräte weit schneller als nötig, korrigieren Sie die Abtastrate in der Firmware, statt Daten in Node-RED zu verwerfen.
- Broker-Limits ignorieren. Kennen Sie die Limits Ihres Brokers für Nachrichtenrate und -größe und planen Sie darunter.
Für Transformationen vor oder nach dem Drosseln siehe den Leitfaden zum Node-RED Function-Node, und für die Grundlagen der MQTT-Verdrahtung in Node-RED das Node-RED-MQTT-Tutorial. Die Optionen des Delay-Nodes sind auch in der integrierten Hilfe und in der Dokumentation der Node-RED-Core-Nodes beschrieben.
Gedrosselte Daten an ConnectMQ publizieren
Sobald Ihr Flow mit einer vernünftigen Rate publiziert, ziehen Sie ihn auf einen privaten Broker um. ConnectMQ ist ein verwalteter MQTT-Broker mit TLS auf Port 8883, MQTT-5-Message-Expiry und Kontingenten pro Plan, die jeden Mandanten vor Überflutung schützen. Der kostenlose Serverless-Plan unterstützt bis zu 25 Verbindungen und Nachrichten bis 256 KB, und kostenpflichtige Serverless-Pläne ergänzen QoS 2 und Shared Subscriptions, wenn Sie skalieren. Erstellen Sie Ihren Broker unter app.connectmq.com ohne Kreditkarte und stellen Sie den Broker-Node dann mit Ihren generierten Zugangsdaten auf TLS um. Zum Vergleich der Betriebsmodelle lesen Sie unseren Leitfaden zum Cloud-MQTT-Broker.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Delay und Rate Limit im Node-RED Delay-Node?
Der Delay-Modus hält jede Nachricht eine Zeit lang zurück, lässt aber jede Nachricht passieren. Der Rate-limit-Modus steuert, wie viele Nachrichten pro Intervall hinausgehen, und kann überzählige puffern oder verwerfen.
Wie begrenze ich jedes MQTT-Topic in Node-RED einzeln?
Stellen Sie die Action des Delay-Nodes auf Rate limit und wählen Sie "For each msg.topic". Der Node behält die neueste Nachricht pro Topic und gibt die Topics reihum mit der konfigurierten Rate frei.
Wie leere ich die Warteschlange eines Delay-Nodes?
Senden Sie eine Nachricht, in der msg.reset auf einen beliebigen Wert gesetzt ist. Die Warteschlange wird geleert, ohne die gepufferten Nachrichten zu senden.
Kann der Delay-Node Speicherprobleme verursachen?
Ja, wenn er über längere Zeit schneller Nachrichten puffert, als er freigibt. Nutzen Sie für Telemetrie Verwerfen oder den Modus pro Topic, oder begrenzen Sie die Warteschlangengröße mit nodeMessageBufferMaxLength in settings.js.
