Node-RED vs. n8n für IoT-Workflows: MQTT-Support, Betrieb und Einsatzbereiche

Node-RED vs. n8n ist immer dann ein Thema, wenn ein Team Low-Code-Automatisierung möchte und sowohl Geräte als auch Geschäftssysteme anbinden muss. Beide Werkzeuge verbinden Nodes auf einer Arbeitsfläche, beide können über MQTT abonnieren und publizieren, und beide lassen sich selbst betreiben – trotzdem wurden sie für unterschiedliche Aufgaben gebaut. Dieser Vergleich erklärt die Unterschiede bei Ausführungsmodell, MQTT-Support, Lizenz und Betrieb und endet mit einem hybriden Muster, das jedem Werkzeug die Arbeit gibt, die es am besten erledigt.

Der Kernunterschied: Nachrichtenströme vs. Workflow-Ausführungen

Node-RED ist ein dauerhaft laufender Prozess, der Nachrichten im Arbeitsspeicher zwischen Nodes weiterreicht. Eine Nachricht kommt an einem mqtt-in-Node an, läuft durch eine Funktion, einen Switch und einen mqtt-out-Node und ist dann weg. Es gibt keine Buchführung pro Nachricht. Deshalb fühlt sich Node-RED bei kontinuierlichen Strömen sehr wohl: ein Sensor, der jede Sekunde meldet, ein SPS-Gateway, das Hunderte Tags publiziert, ein Dashboard mit Live-Aktualisierung. Es wurde bei IBM für die IoT-Verdrahtung entwickelt und ist heute ein Projekt der OpenJS Foundation unter der Apache-2.0-Lizenz.

n8n ist eine Plattform für Workflow-Automatisierung. Jeder Trigger startet eine Ausführung: einen abgeschlossenen Lauf des Workflows, dessen Eingabe, Ausgabe und Status gespeichert und später geprüft werden können. Dieses Modell eignet sich hervorragend für Geschäftsprozesse wie „neues Formular eingegangen, Kontakt anreichern, CRM-Datensatz anlegen, in Slack posten“, weil jeder Lauf nachvollziehbar und wiederholbar ist. Für hochfrequente Telemetrie ist es weniger natürlich: Wird jede MQTT-Nachricht zu einer eigenen protokollierten Ausführung, entsteht Overhead, und das Ausführungsprotokoll läuft voll. n8n wird unter seiner Sustainable Use License vertrieben, einer Fair-Code-Lizenz, die kostenloses Selbsthosting für den internen Gebrauch erlaubt, aber einige kommerzielle Nutzungen einschränkt; außerdem gibt es einen gehosteten Cloud-Dienst.

Keines der Modelle ist grundsätzlich besser. Sie sind auf unterschiedliche Arten von Arbeit optimiert.

Node-RED vs. n8n: Funktionsvergleich

MQTT-Support im Detail

Für IoT-Arbeit entscheidet der MQTT-Support die meisten Vergleiche.

Node-RED behandelt MQTT als Bürger erster Klasse. Der Broker-Konfigurations-Node unterstützt MQTT 3.1.1 und 5, TLS mit eigenen CAs, Client-Zertifikate, Last Will, Clean oder Persistent Sessions sowie MQTT-5-Properties wie Message Expiry, Response Topic und User Properties. Der mqtt-in-Node beherrscht die Wildcards + und #, dynamische Abonnements über Steuernachrichten und parst JSON-Payloads automatisch. Das Node-RED-MQTT-Tutorial geht all das durch.

n8n enthält einen MQTT-Node zum Publizieren und einen MQTT-Trigger-Node, der einen Workflow startet, wenn eine Nachricht auf einem abonnierten Topic eintrifft. Das deckt die wesentlichen Anwendungsfälle ab: auf ein Geräteereignis reagieren oder am Ende eines Geschäftsprozesses einen Befehl senden. Ein Stream-Prozessor will n8n nicht sein; meist brauchen Sie also etwas davor, das rohe Telemetrie in aussagekräftige, niederfrequente Ereignisse verwandelt.

Beide Werkzeuge verbinden sich mit jedem standardkonformen Broker. Auf einen kostenlosen öffentlichen MQTT-Broker wie broker.connectmq.com auf Port 1883 mit eindeutiger Client ID gerichtet, läuft jedes von beiden in einer Minute.

Betrieb und Wartung

In der Praxis läuft Node-RED oft an der Edge, nahe an den Maschinen, während n8n zentral neben den Geschäftssystemen läuft, mit denen es kommuniziert.

Wann Sie Node-RED wählen sollten

• Sie verarbeiten kontinuierliche Sensor- oder Maschinendaten und brauchen Filterung, Aggregation oder Einheitenumrechnung.
• Sie benötigen neben MQTT Industrieprotokolle wie Modbus oder OPC UA.
• Der Workflow muss auf einem Edge-Gerät oder einem offlinefähigen Gateway laufen.
• Sie wollen ein lokales Dashboard für Bedienpersonal.
• Ihnen ist eine permissive Open-Source-Lizenz wichtig.

Wann Sie n8n wählen sollten

• Der Workflow dreht sich hauptsächlich um SaaS-Werkzeuge: CRM, Ticketing, Tabellen, Chat, E-Mail-Marketing.
• Sie brauchen einen prüfbaren Verlauf jedes Laufs, mit Wiederholungen.
• Nicht-Entwickler auf der Fachseite sollen den Workflow pflegen.
• Ereignisse sind relativ selten: Alarme, abgeschlossene Chargen, Instandhaltungsanforderungen.

Das hybride Muster: Node-RED an der Edge, n8n für Geschäftsereignisse

Die robustesten Installationen nutzen beide. Node-RED verarbeitet rohe Telemetrie und publiziert kompakte Ereignisse; n8n abonniert nur diese Ereignisse und führt Geschäftsprozesse aus. Der MQTT-Broker ist der Vertrag zwischen beiden. In Industrie-4.0-Umgebungen ist das genau die Idee eines Unified Namespace (UNS): Rohdaten und abgeleitete Ereignisse liegen in einer ISA-95-orientierten Topic-Hierarchie auf dem Broker, und jedes System abonniert nur die Ebene, die es braucht.

Devices --raw telemetry--> MQTT broker --> Node-RED (filter, aggregate, detect)
Node-RED --events--> MQTT broker --> n8n MQTT Trigger --> CRM / tickets / Slack / sheets
n8n --commands--> MQTT broker --> devices

Hier ist ein Node-RED-Function-Node, der sekündliche Maschinenzählerstände in ein schichtrelevantes Ereignis alle fünf Minuten verwandelt, plus ein sofortiges Ereignis, wenn eine Maschine stoppt:

// Input: connectmq/demo/n8x4w1/line1/press3/count, payload = total parts produced
const PREFIX = "connectmq/demo/n8x4w1/events";
const WINDOW_MS = 5 * 60 * 1000;

const count = Number(msg.payload);
if (isNaN(count)) return null;

const now = Date.now();
const s = context.get("s") || { start: now, first: count, last: count, lastChange: now, stopReported: false };
if (count !== s.last) {
    s.lastChange = now;
    s.stopReported = false;   // machine is producing again
}
s.last = count;

const out = [];

// Stop detection: no new parts for 3 minutes, report once
// (relies on the gateway publishing the counter every few seconds)
if (now - s.lastChange > 3 * 60 * 1000 && !s.stopReported) {
    s.stopReported = true;
    out.push({ topic: `${PREFIX}/press3/stopped`, payload: { since: new Date(s.lastChange).toISOString() } });
}

// Five-minute production summary
if (now - s.start >= WINDOW_MS) {
    // note: msg objects in "out" go to the single output one after another
    out.push({
        topic: `${PREFIX}/press3/summary`,
        payload: { parts: s.last - s.first, from: new Date(s.start).toISOString(), to: new Date(now).toISOString() }
    });
    s.start = now;
    s.first = s.last;
}

context.set("s", s);
return [out];

Verbinden Sie ihn mit einem mqtt-out-Node. In n8n kann dann ein MQTT-Trigger-Node, der connectmq/demo/n8x4w1/events/+/stopped abonniert, ein Instandhaltungsticket eröffnen und den Schichtleiter benachrichtigen, und ein zweiter Workflow schreibt die Zusammenfassungen in eine Tabelle. n8n sieht wenige Nachrichten pro Stunde statt Tausender, wodurch sein Ausführungsverlauf aussagekräftig bleibt.

Testen Sie die Ereignisseite aus einem Terminal, während Sie den n8n-Workflow bauen:

mosquitto_pub -h broker.connectmq.com -p 1883 -i n8n-test-n8x4w1 \
  -t "connectmq/demo/n8x4w1/events/press3/stopped" -m '{"since":"2026-10-16T08:12:00Z"}'

Dieselbe Idee der Edge-Verarbeitung findet sich in unseren Leitfäden zu Node-RED-E-Mail-Alarmen und Node-RED mit Home Assistant, und der Leitfaden zum Node-RED Function-Node behandelt Context und mehrere Ausgänge ausführlicher.

Der Broker in der Mitte

Welche Kombination Sie auch wählen: Beide Werkzeuge sind Clients, und keines sollte das führende System für Nachrichten sein. Ein zuverlässiger Broker entkoppelt sie: Node-RED kann neu deployt werden, ohne dass n8n es bemerkt, und n8n kann aktualisiert werden, ohne dass Geräte ihre Verbindung verlieren. ConnectMQ stellt diese Schicht als verwalteter MQTT-Broker bereit, mit MQTT 3.1.1 und 5, TLS auf 8883 und Secure WebSocket auf 8084. Es führt selbst keine Workflows aus und verbindet sich nicht mit SaaS-Werkzeugen; genau diese Aufgabe übergeben Sie Node-RED und n8n, die als gewöhnliche MQTT-Clients mit eigenen Zugangsdaten angebunden sind.

Für die Produktion geben Sie jedem Werkzeug eigene Zugangsdaten aus dem Portal (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), nutzen Port 8883 mit TLS und QoS 1 für Ereignis-Topics, damit ein kurzer Reconnect kein Stopp-Ereignis verschluckt.

Node-RED und n8n mit ConnectMQ verbinden

Registrieren Sie sich unter app.connectmq.com für den kostenlosen Serverless-Plan, ohne Kreditkarte, legen Sie einen Broker an und verbinden Sie Node-RED und n8n mit getrennten Zugangsdaten. Der Live-Topic-Explorer im Portal zeigt Roh- und Ereignis-Topics nebeneinander, sodass Sie leicht prüfen können, ob nur die richtigen Nachrichten Ihre Geschäftsworkflows erreichen.

Häufig gestellte Fragen

Kann n8n Node-RED für IoT ersetzen?

Für niederfrequente Geräteereignisse funktioniert der MQTT-Trigger von n8n gut. Für kontinuierliche Telemetrie, Edge-Betrieb, Dashboards und Industrieprotokolle ist Node-RED die natürlichere Wahl.

Unterstützt n8n MQTT?

Ja. n8n hat einen MQTT-Node zum Publizieren und einen MQTT-Trigger-Node zum Abonnieren und kann sich mit jedem Standard-Broker verbinden, einschließlich ConnectMQ, mit oder ohne TLS.

Ist n8n Open Source wie Node-RED?

Node-RED ist Open Source unter Apache 2.0. n8n ist unter seiner Sustainable Use License quellverfügbar; sie erlaubt kostenloses Selbsthosting für den internen Gebrauch, schränkt aber bestimmte kommerzielle Nutzungen ein.

Sollten Node-RED und n8n direkt miteinander kommunizieren?

Sauberer ist es, sie über einen MQTT-Broker zu verbinden. Node-RED publiziert Ereignisse, n8n abonniert sie, und beide lassen sich ändern oder neu starten, ohne das andere zu beeinträchtigen.