Node-RED verstehen: Nodes, Flows & Messages als Denkmodell

Die Grundbausteine – Nodes, Flows, Messages

Warum Node-RED kein Baukasten ist, sondern ein Denkmodell

Ziel: Node-RED wirklich verstehen Ergebnis: Du denkst in Flows, nicht in Kästchen.

1. Das Herz von allem: Was ist eine msg wirklich?

In Node-RED ist fast alles eine Message – kurz: msg.

Viele Einsteiger denken:

„Die msg ist halt irgendein Datenobjekt.“

Das ist zu kurz gedacht.

Die richtige Sichtweise

Eine msg ist:

• ein Transportmittel
• ein Zustandsträger
• ein Kontextobjekt

Sie fließt durch den gesamten Flow und nimmt unterwegs Eigenschaften an, verliert andere oder verändert sie.

Typisch:

• msg.payload → der eigentliche Inhalt
• msg.topic → Einordnung / Routing
• msg.headers → Metadaten
• eigene Felder → dein Modell

👉 Wichtig: Node-RED arbeitet nicht mit Variablen, sondern mit fließenden Zuständen.

Wer das verstanden hat, hört auf, gegen das System zu kämpfen.

2. Debug-Node: Dein wichtigstes Denkwerkzeug

Der Debug-Node ist kein Kontrolllicht, sondern dein Röntgengerät.

Typischer Anfängerfehler

• Debug überall
• Debug nie entfernen
• Debug nur auf payload

Besser:

• Debug gezielt einsetzen
• ganze msg anzeigen lassen
• nur an logischen Übergängen prüfen

Mentales Modell

Der Debug-Node beantwortet nur eine Frage:

„Was kommt hier wirklich an?“

Nicht:

• was du erwartest
• was du gedacht hast
• was im Kopf „logisch“ war

👉 Debug zeigt die Wahrheit – und die ist manchmal unbequem.

3. Function-Node vs. Switch / Change

Macht, Kontrolle – und Disziplin

Der Function-Node ist verführerisch:

„Hier kann ich alles mit JavaScript lösen!“

Ja. Aber solltest du es immer tun? Nein.

Switch- & Change-Nodes: deklarative Logik

Diese Nodes sind:

• sichtbar
• lesbar
• wartbar

Sie eignen sich perfekt für:

• Routing
• einfache Transformationen
• Bedingungen
• Feldänderungen

👉 Faustregel: Was ohne Code geht, sollte ohne Code gelöst werden.

Function-Node: gezielt & bewusst

Nutze den Function-Node für:

• komplexe Logik
• Berechnungen
• Sonderfälle
• externe Libraries

Aber:

• halte ihn kurz
• dokumentiere ihn
• kapsle Logik sauber

👉 Ein langer Function-Node ist oft ein Zeichen für:

• schlechtes Flow-Design
• fehlende Struktur
• Denkfehler

4. Best Practices für Lesbarkeit (oder: Warum Ordnung kein Luxus ist)

Flows werden nicht für den Moment gebaut, sondern für:

• spätere Änderungen
• andere Personen
• dich selbst in 3 Monaten

Bewährte Regeln

• Ein Flow = ein Zweck
• sprechende Namen für Nodes
• Kommentare nutzen
• logische Reihenfolge von links nach rechts
• keine Kreuzungen ohne Not

Denk in Ebenen

• Trigger links
• Verarbeitung in der Mitte
• Aktionen rechts

👉 Dein Flow ist ein Lesetext, kein Schaltplan.

5. Typische Anfängerfehler (und wie du sie vermeidest)

Fehler 1: Alles in einen Flow

„Ist doch alles logisch zusammen.“

Nein. Es wird unlesbar, unwartbar, unrettbar.

Fehler 2: msg.payload als Müllhalde

„Ich packe da einfach alles rein.“

Besser:

• klare Struktur
• eigene Felder
• konsistente Namensgebung

Fehler 3: Function-Node als Allzweckwaffe

„Geht schneller.“

Kurzfristig: ja Langfristig: nein

Fehler 4: Keine Struktur, kein Projektmodus

„Mach ich später.“

Später = nie.

Fazit: Wer Node-RED versteht, denkt nicht mehr in Kästchen

Node-RED zwingt dich, umzudenken:

• von Funktionen zu Flüssen
• von Variablen zu Zuständen
• von Code zu Prozessen

Wenn du aufhörst, Nodes als „Bausteine“ zu sehen, und anfängst, Messages als Träger von Bedeutung zu begreifen, öffnet sich Node-RED vollständig.

👉 Dann ist es kein Tool mehr. 👉 Dann ist es ein mentales Modell für Automatisierung.