Zum Hauptinhalt springen

Häufig genutzte Basisnodes im IIoT

Neben der Kategorie 엣지 sind dies die Nodes, die vanilla Node-RED standardmäßig mitbringt und die in IIoT-Flows eine zentrale Rolle spielen. Sortiert nach Häufigkeit der Verwendung.

1. inject — Trigger / Scheduler​

Der Startpunkt eines Flows. Entweder per Schaltfläche einmalig ausgelöst oder automatisch in festen Intervallen bzw. zu festen Uhrzeiten.

OptionBeschreibung
Repeat: intervalAuslösung alle N Sekunden/Minuten/Stunden (z. B. Polling im Sekundentakt)
Repeat: interval between timesAuslösung nur in einem bestimmten Zeitfenster (z. B. 09–18 Uhr)
Repeat: at a specific timeTäglich zu einer festen Uhrzeit (z. B. täglich 07:00)
Repeat: cron-likecrontab-Format (z. B. 0 7 * * * — täglich 07:00)
Inject once afterEinmalige Auslösung direkt nach dem Deploy + Verzögerungszeit

Da sich auch msg.payload und msg.topic injizieren lassen, übernimmt ein einzelner Node gleichzeitig die Rolle von „Zeitplan + Eingangsdaten“.

2. debug — Log in der Seitenleiste​

Gibt msg oder msg.payload im Reiter debug der rechten Seitenleiste aus. Stellt man das Ausgabeziel auf „gesamtes msg-Objekt“ um, werden auch bisher verborgene Felder sichtbar — unverzichtbar beim Debuggen.

3. function — Freies JavaScript​

Eingabe eines beliebigen JavaScript-Codeblocks. Wird msg verändert und anschließend return msg;, geht die Nachricht an den nächsten Node.

// 예: payload 가 숫자라면 100배 해서 출력
msg.payload = parseFloat(msg.payload) * 100;
return msg;

Für eine Verzweigung auf mehrere Ausgänge in den Node-Einstellungen z. B. Outputs: 2 setzen und ein Array zurückgeben return [a, b];.

4. change — Felder setzen/kopieren/löschen (ohne Code)​

Einfache Umwandlungen wie msg.topic = "abc" oder msg.payload = msg.payload.value erledigt man ohne Function-Node mit einem einzigen change. Vier Aktionen: set / change / move / delete.

5. switch — Bedingte Verzweigung​

Wertet msg.payload oder ein beliebiges Feld aus und leitet die Nachricht an unterschiedliche Ausgangsports. Optionen: checking all rules oder stop after first match.

            ┌─ ≥ 80 ─▶ Slack 알림
read ──▶ switch ─┤
            └─ < 80 ─▶ 정상 라인

6. join — Mehrere Nachrichten zusammenführen​

Fasst die Ergebnisse mehrerer parallel laufender Nodes (z. B. 태그값 읽기 ×3) zu einem Array/Objekt zusammen. mode manual, count N, key msg.topic.

7. delay — Verzögerung / Rate Limit​

  • Pause: Hält Nachrichten N Sekunden/Minuten zurück (z. B. nach einem Alarm 5 Minuten lang keine erneute Zustellung)
  • Rate Limit: Begrenzt die Verarbeitungsrate, etwa „1 Nachricht pro Sekunde“ — schützt Polling externer APIs bzw. den MQTT-Versand

8. trigger — Kombination aus Zustand und Timer​

Muster wie „bei eingehender Nachricht eine Startmeldung, und wenn nach N Sekunden keine Aktualisierung erfolgt, eine Endmeldung“ — häufig zur Erkennung von Datenabrissen eingesetzt.

9. http request / http in / http response​

NodeVerwendung
http requestAufruf externer REST API (z. B. externe Wetter-API, internes ERP)
http in + http responseNeuen HTTP-Endpunkt in Node-RED selbst anlegen (z. B. /myreport POST entgegennehmen)

10. file / file in​

  • file (write/append): Speichern als Datei auf der Festplatte (z. B. CSV-Logging)
  • file in (read): Dateiinhalt lesen

11. csv / json / xml​

Umwandlung String ↔ Objekt. csv bietet umfangreiche Optionen für Header und Trennzeichen.

12. template​

Template-Ausgabe in mustache-Syntax. Am praktischsten beim Erstellen von E-Mails, Slack-Nachrichten oder Berichtstexten.

🔥 [경보] {{tag_id}} = {{value}}{{unit}} (한도 {{threshold}})

13. link in / link out​

„Virtueller Sprung“ innerhalb desselben Workspace. Dient dazu, ein Gewirr aus Verbindungen übersichtlich aufzuräumen.

14. catch / status / complete​

Tritt irgendwo im Flow ein Fehler auf, fängt ihn catch ab; über den Zustand eines Nodes (z. B. mqtt verbunden/getrennt) informiert status. Unverzichtbar für einen stabilen Betrieb.

Nächste Schritte​