Node-RED Switch-Node und Change-Node für MQTT-Routing

Der Node-RED Switch-Node ist der einfachste Weg, jede MQTT-Nachricht auf den richtigen Pfad zu schicken: Temperaturen in einen Zweig, Luftfeuchte in einen anderen, Werte außerhalb des Bereichs in einen Alarm. In diesem Tutorial kombinieren Sie den Switch-Node mit dem Change-Node, um Nachrichten nach Topic und nach Wert zu routen, Payloads ohne JavaScript umzubauen und saubere Alarme an einen Broker zu publizieren. Am Ende haben Sie einen importierbaren Flow, den Sie in zwei Minuten testen können.

Warum MQTT-Nachrichten in Node-RED routen

Ein einzelner mqtt in-Node, der eine Wildcard wie sensors/# abonniert, empfängt alles unterhalb dieser Ebene. Das ist bequem, weil ein Abonnement Dutzende ersetzt, bedeutet aber auch, dass jeder nachgelagerte Node jede Nachricht sieht. Ohne Routing landen Sie bei einem großen Function-Node voller if-Anweisungen, den niemand pflegen möchte.

Der Switch-Node löst das deklarativ. Er prüft eine Eigenschaft der Nachricht gegen eine Liste von Regeln und gibt die Nachricht über den passenden Port aus. Der Change-Node bearbeitet die Nachricht dann in jedem Zweig: Er setzt ein neues Topic, verschiebt ein Feld, entfernt Störendes oder berechnet einen Wert mit einem JSONata-Ausdruck. Zusammen decken die beiden die meisten Routing-Aufgaben ab, und die Logik bleibt im Editor sichtbar, wo eine Kollegin sie auf einen Blick lesen kann.

Wenn Sie neu im Editor sind, beginnen Sie mit dem Node-RED-MQTT-Tutorial und kehren Sie hierher zurück, sobald Ihre Broker-Verbindung funktioniert.

So funktioniert der Node-RED Switch-Node

Öffnen Sie einen Switch-Node, sehen Sie drei relevante Einstellungen.

1. Property. Der zu prüfende Wert. Standard ist msg.payload, möglich sind aber auch msg.topic, ein verschachteltes Feld wie msg.payload.value, eine Flow- oder Global-Context-Variable oder ein JSONata-Ausdruck.
2. Rules. Jede Regel erzeugt einen Ausgangsport. Die Regeln werden der Reihe nach ausgewertet.
3. Prüfmodus. „Checking all rules“ gibt die Nachricht über jeden passenden Port aus. „Stopping after first match“ nur über den ersten Treffer. Für Routing wollen Sie fast immer die zweite Option, damit ein Wert nie versehentlich in zwei Zweigen landet.

Die am häufigsten genutzten Regeltypen sind unten aufgeführt.

Fügen Sie am Ende immer eine otherwise-Regel hinzu. Sie kostet nichts und ist die erste Stelle, an der Sie suchen, wenn eine Nachricht scheinbar verschwindet.

So funktioniert der Change-Node

Der Change-Node wendet eine Liste von Operationen der Reihe nach auf die Nachricht an:

• Set setzt eine Eigenschaft auf einen String, eine Zahl, einen booleschen Wert, JSON, eine andere Nachrichteneigenschaft, einen Context-Wert, einen Zeitstempel oder einen JSONata-Ausdruck.
• Change ersetzt einen Teil eines Strings, per Klartext oder regulärem Ausdruck, praktisch zum Umschreiben von Topics.
• Delete entfernt eine Eigenschaft, etwa ein Debug-Feld, das ein Gerät in jede Nachricht packt.
• Move verschiebt eine Eigenschaft an eine neue Stelle, zum Beispiel msg.payload.value hoch nach msg.payload.

JSONata macht den Change-Node mächtig. Innerhalb eines Ausdrucks verweisen payload und topic auf msg.payload und msg.topic, sodass $round(payload.value * 9 / 5 + 32, 1) Celsius in Fahrenheit umrechnet und $split(topic, "/")[4] die fünfte Topic-Ebene extrahiert. Sie erhalten berechnete Werte ohne Function-Node und ohne den visuellen Editor zu verlassen.

Der Beispiel-Flow: erst nach Topic, dann nach Wert routen

Der Flow, den Sie gleich importieren, macht Folgendes:

1. Er abonniert connectmq/demo/a7f3k2/sensors/# auf dem Öffentlichen MQTT-Broker, mit dem Payload-Typ „parsed JSON“.
2. Ein erster Node-RED Switch-Node routet nach msg.topic: Temperatur, Luftfeuchte oder alles andere.
3. Ein zweiter Switch-Node teilt Temperaturen anhand von msg.payload.value in drei Bänder.
4. Das untere und obere Band laufen durch einen Change-Node, der Alarm-Topic und Payload aufbaut; danach publiziert ein mqtt out-Node den Alarm.
5. Normale Messwerte, Luftfeuchte und unbekannte Topics gehen an Debug-Nodes.

Ersetzen Sie a7f3k2 vor dem Deploy überall durch Ihren eigenen Zufallsstring. Der öffentliche MQTT-Broker ist für jeden lesbar; ein eindeutiges Präfix hält Ihren Testverkehr getrennt, und sensible Daten sollten Sie dort niemals senden. Auch die Client ID muss eindeutig und nicht leer sein.

[
  {"id":"cmq_broker","type":"mqtt-broker","name":"ConnectMQ public","broker":"broker.connectmq.com","port":"1883","clientid":"nr-switch-a7f3k2","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true},
  {"id":"in_all","type":"mqtt in","name":"all sensors","topic":"connectmq/demo/a7f3k2/sensors/#","qos":"1","datatype":"json","broker":"cmq_broker","nl":false,"rap":true,"rh":0,"inputs":0,"x":140,"y":160,"wires":[["sw_topic"]]},
  {"id":"sw_topic","type":"switch","name":"by measurement","property":"topic","propertyType":"msg","rules":[{"t":"regex","v":"/temperature$","vt":"str","case":false},{"t":"regex","v":"/humidity$","vt":"str","case":false},{"t":"else"}],"checkall":"false","repair":false,"outputs":3,"x":350,"y":160,"wires":[["sw_temp"],["dbg_hum"],["dbg_other"]]},
  {"id":"sw_temp","type":"switch","name":"temperature band","property":"payload.value","propertyType":"msg","rules":[{"t":"lt","v":"5","vt":"num"},{"t":"btwn","v":"5","vt":"num","v2":"30","v2t":"num"},{"t":"gt","v":"30","vt":"num"},{"t":"else"}],"checkall":"false","repair":false,"outputs":4,"x":560,"y":100,"wires":[["chg_alert"],["dbg_ok"],["chg_alert"],["dbg_other"]]},
  {"id":"chg_alert","type":"change","name":"build alert","rules":[{"t":"delete","p":"payload.debug","pt":"msg"},{"t":"set","p":"payload","pt":"msg","to":"{\"room\": $split(topic, \"/\")[4], \"value\": payload.value, \"level\": payload.value > 30 ? \"high\" : \"low\", \"fahrenheit\": $round(payload.value * 9 / 5 + 32, 1)}","tot":"jsonata"},{"t":"set","p":"topic","pt":"msg","to":"\"connectmq/demo/a7f3k2/alerts/\" & payload.room","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":790,"y":60,"wires":[["out_alert","dbg_alert"]]},
  {"id":"out_alert","type":"mqtt out","name":"publish alert","topic":"","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"cmq_broker","x":1000,"y":40,"wires":[]},
  {"id":"dbg_alert","type":"debug","name":"alert","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":990,"y":90,"wires":[]},
  {"id":"dbg_ok","type":"debug","name":"normal temperature","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":800,"y":120,"wires":[]},
  {"id":"dbg_hum","type":"debug","name":"humidity","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":560,"y":200,"wires":[]},
  {"id":"dbg_other","type":"debug","name":"unrouted","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":800,"y":240,"wires":[]}
]

Importieren Sie ihn über Menü → Import, fügen Sie das JSON ein und klicken Sie auf Deploy. Unter dem mqtt in-Node sollte innerhalb weniger Sekunden der grüne Status „connected“ erscheinen.

Achten Sie auf zwei Details im Change-Node. Zuerst wird die Payload neu aufgebaut, danach liest die Topic-Regel payload.room aus der neuen Payload. Die Reihenfolge der Regeln zählt: Jede Regel sieht die Nachricht so, wie die vorherige sie hinterlassen hat. Außerdem ist das Topic-Feld des mqtt out-Nodes leer, sodass er auf das msg.topic publiziert, das der Change-Node gesetzt hat. Tragen Sie dort ein Topic ein, überschreibt es msg.topic, und Ihr dynamisches Routing hört stillschweigend auf zu funktionieren.

Das Routing auf der Kommandozeile testen

Publizieren Sie ein paar Testnachrichten mit den Mosquitto-Clients. Jeder Befehl verwendet eine eigene Client ID.

# Normal temperature -> "normal temperature" debug output
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-1 \
  -t connectmq/demo/a7f3k2/sensors/room1/temperature -m '{"value": 22.5}'

# High temperature -> alert published to connectmq/demo/a7f3k2/alerts/room1
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-2 \
  -t connectmq/demo/a7f3k2/sensors/room1/temperature -m '{"value": 34.2, "debug": "fw-1.2"}'

# Humidity -> "humidity" debug output
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-3 \
  -t connectmq/demo/a7f3k2/sensors/room1/humidity -m '{"value": 48}'

# Unknown measurement -> "unrouted" debug output
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-a7f3k2-4 \
  -t connectmq/demo/a7f3k2/sensors/room1/co2 -m '{"value": 640}'

Beobachten Sie in einem zweiten Terminal das Alarm-Topic, um zu prüfen, ob der Change-Node die erwartete Nachricht gebaut hat:

mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-a7f3k2 -v \
  -t 'connectmq/demo/a7f3k2/alerts/#'

Sie sollten {"room":"room1","value":34.2,"level":"high","fahrenheit":93.6} sehen, ohne das debug-Feld. Wenn Sie unsicher sind, was die einzelnen QoS-Stufen in diesem Test für die Zustellung bedeuten, erklärt der Leitfaden zu MQTT-QoS-Stufen, warum der Flow für Alarme QoS 1 verwendet.

Routing-Muster, die sich wiederverwenden lassen

Sobald der Basis-Flow läuft, decken diese Muster die meisten realen Projekte ab:

• Nach Gerätetyp über eine Topic-Ebene routen. Statt eines Regex setzen Sie die Switch-Property auf den JSONata-Ausdruck $split(topic, "/")[3] und vergleichen mit ==-Regeln. Das liest sich schneller als ein Regex, wenn Topics einer strikten Hierarchie folgen – etwa der ISA-95-Struktur eines Unified Namespace (UNS).
• Vor dem Routing validieren. Setzen Sie direkt hinter mqtt in einen Switch-Node mit der Regel „is of type: object“. Fehlerhafte Payloads gehen an den otherwise-Port, wo Sie sie protokollieren können, statt dass sie später einen Function-Node zum Absturz bringen.
• Zustandsänderungen deduplizieren. Kombinieren Sie den Switch-Node mit einem Filter-Node (Modus „report by exception“), damit ein Türsensor, der jede Sekunde open publiziert, Ihren Zweig nur bei einer Wertänderung auslöst.
• Einheiten früh normalisieren. Nutzen Sie direkt nach dem Routing einen Change-Node, um Einheiten umzurechnen und Felder umzubenennen, damit alles Nachgelagerte ein einheitliches Schema sieht.
• Mit Context anreichern. Ein Change-Node kann msg.payload.limit aus flow.limits[room] setzen, und der nächste Switch-Node vergleicht gegen msg.payload.limit statt gegen eine fest codierte Zahl. Grenzwerte liegen dann an einer einzigen Stelle.

Wenn Bedingungen über eine Handvoll Regeln hinauswachsen oder Schleifen und Zustand benötigen, ist ein Function-Node das bessere Werkzeug. Der Leitfaden zum Node-RED Function-Node behandelt diesen Schritt, und das Tutorial zum JSON-Node erklärt, wie String- und Objekt-Payloads mit diesen Routing-Regeln zusammenspielen.

Fehlerbehebung bei Switch- und Change-Nodes

Eine nützliche Angewohnheit: Geben Sie jedem Switch- und Change-Node einen sprechenden Namen. Die Debug-Sidebar zeigt den Node-Namen an, und „temperature band“ ist viel leichter nachzuverfolgen als „switch“.

Den Flow auf einen privaten Broker umziehen

Der öffentliche MQTT-Broker ist ideal zum Lernen, produktive Routing-Flows sollten aber gegen Ihren eigenen Broker laufen, mit Zugangsdaten und TLS. Legen Sie im ConnectMQ-Portal einen Broker an und bearbeiten Sie dann den mqtt-broker-Konfigurations-Node:

• Server: der im Portal angezeigte Host, Port 8883, Use TLS aktiviert.
• Reiter Security: YOUR_USERNAME und YOUR_PASSWORD.
• Client ID: YOUR_CLIENT_ID, weil ConnectMQ Client IDs an die ausgegebenen Zugangsdaten bindet.

Alle mqtt in- und mqtt out-Nodes teilen sich diesen Konfigurations-Node, die Routing-Logik selbst ändert sich also nicht. Danach können Sie das Präfix connectmq/demo/a7f3k2 streichen und eine saubere Hierarchie wie site/area/line/device/measurement verwenden – die ISA-95-Ebenen bilden so die Topic-Struktur Ihres Unified Namespace. Mit einem verwalteten MQTT-Broker müssen Sie außerdem keinen Broker-Prozess neben Node-RED patchen und überwachen.

Ihre Node-RED-Flows auf ConnectMQ betreiben

Ihre Switch- und Change-Nodes verdienen einen Broker, der stabil läuft, während Sie iterieren. Registrieren Sie sich unter app.connectmq.com, wählen Sie den kostenlosen Serverless-Plan (ohne Kreditkarte), legen Sie einen Broker an und tragen Sie den generierten Benutzernamen, das Passwort und die Client ID in Ihren Node-RED-Konfigurations-Node ein. Der Live-Topic-Explorer im Portal zeigt Ihre Alarm-Topics in Echtzeit, was die Prüfung der Routing-Logik deutlich beschleunigt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Switch-Node und Change-Node in Node-RED?

Der Switch-Node entscheidet, wohin eine Nachricht geht, indem er eine Eigenschaft gegen Regeln prüft und einen Ausgangsport wählt. Der Change-Node verändert die Nachricht selbst, indem er Eigenschaften setzt, ändert, löscht oder verschiebt.

Kann der Node-RED Switch-Node nach msg.topic routen?

Ja. Setzen Sie die Property auf msg.topic und verwenden Sie Regeln wie „matches regex“, „contains“ oder ==. Das ist der Standardweg, um Verkehr aus einem einzelnen Wildcard-Abonnement aufzuteilen.

Warum greift meine numerische Switch-Regel bei MQTT-Werten nicht?

MQTT-Payloads kommen als Text an, sofern der mqtt in-Node sie nicht parst. Stellen Sie sicher, dass der Node ein geparstes JSON-Objekt ausgibt, und wandeln Sie String-Felder vor dem Vergleich mit $number() in einem Change-Node um.

Sollte ich statt Switch- und Change-Nodes einen Function-Node verwenden?

Verwenden Sie Switch- und Change-Nodes für Routing und einfache Transformationen, weil sie leichter zu lesen und zu prüfen sind. Wechseln Sie zu einem Function-Node, wenn Sie Schleifen, komplexen Zustand oder Logik brauchen, die mehr als ein paar Regeln erfordern würde.