Stufe 3 · Kapitel 6 von 14

Advanced Node-RED Flows: Subflows, Join & Performance

Du kennst die Grundlagen von Node-RED? Dann lass uns tiefer gehen: Subflows für wiederverwendbare Bausteine, Join-Nodes für komplexe Datenflüsse, robuste Fehlerbehandlung und Performance-Tuning für große Installationen.

5 Min. LesezeitAktualisiert 3. Juni 2026

In 30 Sekunden

Die drei mächtigsten Node-RED-Konstrukte für Fortgeschrittene sind Subflows (wiederverwendbare Flow-Fragmente), Join-Nodes (Nachrichten zusammenführen) und Context-Variablen (Zustand zwischen Flows teilen). Wer diese beherrscht, kann Automatisierungen bauen, die wartbar, fehlertolerant und performant bleiben — selbst bei hunderten Nodes.

Partnerlinks: Die mit 🛒 markierten Links sind Affiliate-Links. Bei einem Kauf erhalten wir eine kleine Provision – ohne Mehrkosten für dich.

Subflows: Wiederverwendbare Bausteine statt Copy & Paste

Wenn du denselben Flow-Abschnitt in mehreren Tabs brauchst, ist Copy & Paste der falsche Weg. Änderungen müsstest du dann an jeder Kopie einzeln vornehmen. Subflows lösen dieses Problem: Du definierst einen Flow einmal und instanziierst ihn beliebig oft. Jede Instanz teilt dieselbe Logik, aber kann eigene Eigenschaftswerte mitbekommen.

Subflow erstellen und Eigenschaften definieren

Unter dem Menüpunkt „Subflows“ legst du einen neuen Subflow an. Darin baust du wie gewohnt Nodes zusammen. Das Besondere: Du kannst im Subflow-Editor benutzerdefinierte Eigenschaften definieren — zum Beispiel einen MQTT-Topic-Prefix oder einen Schwellwert. Diese Eigenschaften erscheinen dann in jeder Instanz als konfigurierbares Feld. So wird ein Subflow zu einem parametrisierbaren Baustein.

Status-Node im Subflow: Transparenz nach außen

Ein häufiges Problem: Subflows laufen im Hintergrund, und du siehst nicht, was passiert. Ab Node-RED 3.0 kannst du die Status-Node verwenden, um den Zustand einer Subflow-Instanz im Parent-Flow anzuzeigen — zum Beispiel ein grünes Häkchen bei Erfolg oder eine Fehlermeldung bei Misserfolg.

Pro-Tipp
Benenne deine Subflows mit einem klaren Präfix wie sf_mqtt_publish oder sf_alert_handler. So findest du sie im Node-Palette-Filter sofort wieder — besonders wichtig, wenn dein Projekt auf 20+ Subflows anwächst.

Join-Nodes: Nachrichten aus mehreren Quellen zusammenführen

In der echten Welt kommen Daten selten aus einer einzigen Quelle. Vielleicht willst du die Außentemperatur, den Fensterstatus und die Heizungsstellung gleichzeitig auswerten, bevor du eine Entscheidung triffst. Genau dafür gibt es die Join-Node: Sie sammelt Nachrichten aus verschiedenen Zweigen und feuert erst, wenn alle erwarteten Eingänge vorliegen.

Manuelles vs. automatisches Join

Im Modus „manual" gibst du an, wie viele Nachrichten die Node sammeln soll, bevor sie weitergibt. Im Modus „automatic" erzeugt die Node ein Array aller eingehenden Nachrichten. Beide Modi lassen sich mit einem Timeout kombinieren — wichtig, falls eine Quelle nicht antwortet und der Flow sonst blockiert.

Typische Fallstricke

Der häufigste Fehler: Die Join-Node wartet ewig, weil ein Zweig keine Nachricht sendet. Lösung: Setze immer einen Timeout (z.B. 10 Sekunden) und leite die Nachricht über einen Catch-Node an eine Fehlerbehandlung weiter. Ein weiteres Problem entsteht, wenn du vergessen hast, die msg.parts-Eigenschaft korrekt zu setzen — ohne sie weiß die Join-Node nicht, welche Nachricht zu welchem Stream gehört.

3 ModiJoin-Node: Automatic, Manual, Reduce — drei Strategien für jedes Szenario

10 sEmpfohlener Timeout-Wert für Join-Nodes in typischen Smart-Home-Flows

64 KBMaximale Context-Größe pro Flow in Node-RED Default-Konfiguration

Fehlerbehandlung: Catch-Node, Log-Strategie und Circuit Breaker

Ein Flow ohne Fehlerbehandlung funktioniert — bis etwas schiefgeht. Dann stürzt der Flow stillschweigend ab oder, schlimmer, führt unerwartete Aktionen aus. Robuste Fehlerbehandlung ist kein Nice-to-have, sondern Pflicht.

Die Catch-Node: Fehler abfangen und behandeln

Die Catch-Node fängt Fehler von beliebigen Nodes auf und leitet sie an einen Fehlerbehandlungs-Zweig weiter. Du kannst sie auf bestimmte Node-Typen oder sogar einzelne Nodes einschränken. Im Fehlerhandling-Zweig protokollierst du den Fehler (z.B. per msg.error) und entscheidest, ob der Flow fortgesetzt, abgebrochen oder ein Fallback ausgeführt wird.

Circuit Breaker mit Delay und Count

Wenn ein Service wiederholt fehlschlägt, solltest du nicht endlos probieren. Ein Circuit Breaker merkt sich die Anzahl aufeinanderfolgender Fehler und öffnet den Stromkreis nach z.B. drei Fehlern. Für eine konfigurierbare Zeit werden dann keine weiteren Requests gesendet. In Node-RED baust du das mit einer Kombination aus Counter, Switch und Delay.

Wusstest du schon?
Node-RED speichert fehlerhafte Nachrichten standardmäßig nicht. Wenn du nachvollziehen willst, was schiefgelaufen ist, brauchst du eine eigene Log-Strategie — z.B. eine Function-Node, die Fehler in eine Datei oder einen MQTT-Topic schreibt.

Context-Variablen: Zustand intelligent verwalten

Manche Informationen müssen über mehrere Nachrichtenaufrufe hinweg erhalten bleiben — zum Beispiel der letzte bekannte Temperaturwert oder ein Zähler. Dafür bietet Node-RED drei Context-Ebenen: Node-Context (nur für diese eine Node), Flow-Context (geteilt im gesamten Tab) und Global-Context (über alle Tabs hinweg).

Flow-Context vs. Global-Context

Flow-Context ist die richtige Wahl, wenn Daten nur innerhalb eines Tabs geteilt werden sollen. Global-Context nutzt du, wenn mehrere Tabs auf dieselben Daten zugreifen müssen — zum Beispiel eine System-Konfiguration oder eine Liste aktiver Alarme. Achtung: Global-Context verringert die Isolation zwischen Tabs und kann ungewollte Seiteneffekte verursachen, wenn Variablen an vielen Stellen gelesen und geschrieben werden.

Persistenter Context: Daten über Neustarts erhalten

Standardmäßig geht der Context beim Neustart von Node-RED verloren. In der settings.js kannst du jedoch persistenten Context aktivieren. Node-RED speichert die Werte dann in einer Datei (default) oder in Redis. Das ist besonders wichtig für Zähler, Schwellwerte oder den letzten bekannten Zustand eines Geräts.

Pro-Tipp
Vermeide es, große Objekte im Global-Context zu speichern. Bei jedem Zugriff wird das gesamte Objekt serialisiert und deserialisiert. Besser: Schlüssel granular anlegen (z.B. global.heizung.wohnzimmer.soll) statt ein riesiges heizung-Objekt.

Performance: Wenn hunderte Nodes langsam werden

Node-RED ist erstaunlich schnell — bis es das nicht mehr ist. Wenn dein Flow hundert Function-Nodes enthält, die bei jeder Nachricht komplexe Berechnungen ausführen, spürst du die Verzögerung. Hier sind die wichtigsten Hebel:

Function-Nodes minimieren: Jede Function-Node startet einen neuen JavaScript-Kontext. Kombiniere mehrere kleine Function-Nodes zu einer einzigen, die die Logik gebündelt ausführt.
Debounce und Throttle nutzen: Sensoren senden oft mehr Nachrichten als nötig. Die Delay-Node mit „rate limit" oder die RBE-Node (Report by Exception) filtern redundante Nachrichten heraus.
Flows aufteilen: Ein einziger riesiger Tab ist schwer zu debuggen und belastet den Scheduler. Verteile Logik auf mehrere Tabs, die über Link-Nodes kommunizieren.
Node-RED als Add-on in HA: Wenn Node-RED als Home Assistant Add-on läuft, teilt es sich Ressourcen mit der HA-Instanz. Bei großen Flows empfiehlt sich ein eigener Container mit dediziertem Arbeitsspeicher (z. B. auf einem Beelink Mini-PC oder einem dedizierten Raspberry Pi).

500+Nodes in einem Tab: Ab hier wird sichtbares Performance-Tuning empfohlen

256 MBMindest-Arbeitsspeicher für Node-RED als eigenständigen Container

Alle Produkte aus diesem Guide

Beelink Mini S12 Pro (Intel N100)

Intel N100 Prozessor, 16GB RAM, 500GB SSD, stromsparend (~6W).

Auf Amazon ansehen

Raspberry Pi 4 mit 4 GB

Der Preis-Leistungs-Favorit für Home Assistant und ioBroker im Einstieg.