#node-red

On the initial K-9 version we used NodeRed, Python, and Blynk to enable control by an I-phone. This was a fast to implement solution since we had no experience programming in JavaScript / HTML. 

However it had several issues:            

Time needed at boot to load both the Blynk and NodeRed servers. 

Challenges to keep the servers in sync through various software releases.      

User interface limited by Blynk’s options.

On K-9 V3 we are simplifying the architecture using just Python and a Flask server. This allows for a quick load on boot and by using sockets we maintain fast communications between the I-Phone and control.

Im vorherigen Beitrag habe ich dir gezeigt, wie du Fehler und Statusänderungen in Node-RED mit einer Catch- beziehungsweise Status-Node erkennst und anschließend über eine Debug-Node ausgibst.

Doch was passiert, wenn ein Flow unbeaufsichtigt läuft und du einen Fehler erst Stunden oder Tage später bemerkst? In diesem Fall reicht die Ausgabe im Debug-Bereich nicht aus. Damit sich die Ursache im Nachhinein nachvollziehen lässt, sollten wichtige Meldungen dauerhaft in einer Logdatei gespeichert werden.

https://youtu.be/U-w314Y3hc0

In diesem Beitrag zeige ich dir deshalb, wie du Fehler mit den Bordmitteln von Node-RED in eine Logdatei schreibst. Anschließend stelle ich dir eine eigene Logger-Node vor, die dir viele wiederkehrende Arbeitsschritte abnimmt. Sie lässt sich flexibel konfigurieren und sorgt dafür, dass deine Logeinträge einheitlich und übersichtlich gespeichert werden.

Praxisbeispiel: Ausfälle des MQTT-Brokers protokollieren

Als Beispiel verwenden wir erneut die Überwachung eines MQTT-Brokers. Dieser Anwendungsfall ist besonders praxisnah, da ein Broker in vielen IoT- und Smart-Home-Projekten eine zentrale Rolle übernimmt.

Der Node-RED Flow erkennt Statusänderungen der MQTT-Out-Node und unterscheidet zwischen einer unterbrochenen und einer wiederhergestellten Verbindung. Node-RED Flow zum Importieren }, { "id": "7d1c53815cc56777", "type": "inject", "z": "8c105c2e4a45c10e", "name": "", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 120, "y": 120, "wires": ] }, { "id": "2e69599beb37b62d", "type": "mqtt out", "z": "8c105c2e4a45c10e", "name": "", "topic": "/beispiel/text", "qos": "", "retain": "", "respTopic": "", "contentType": "", "userProps": "", "correl": "", "expiry": "", "broker": "2dc0a4b70d96ebb5", "x": 270, "y": 120, "wires": }, { "id": "7113958f4b37c1cb", "type": "status", "z": "8c105c2e4a45c10e", "name": "", "scope": , "x": 100, "y": 260, "wires": ] }, { "id": "5edda4976ee422cb", "type": "debug", "z": "8c105c2e4a45c10e", "name": "Ausgabe der Statusänderung", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 880, "y": 260, "wires": }, { "id": "99ee96e58880f9fd", "type": "function", "z": "8c105c2e4a45c10e", "name": "Statusmeldung für "nicht verbunden" erstellen", "func": "msg.payload = "Die Verbindung zum MQTT Broker ist unterbrochen!";nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 540, "y": 220, "wires": ] }, { "id": "895156e15c61ffb6", "type": "switch", "z": "8c105c2e4a45c10e", "name": "", "property": "status.text", "propertyType": "msg", "rules": , "checkall": "false", "repair": false, "outputs": 2, "x": 250, "y": 260, "wires": , ] }, { "id": "03e0329660e4c26b", "type": "function", "z": "8c105c2e4a45c10e", "name": "Statusmeldung für "verbunden" erstellen", "func": "msg.payload = "Die Verbindung zum MQTT Broker wurde hergestellt!";nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 540, "y": 300, "wires": ] }, { "id": "0ffb9997f320e647", "type": "debug", "z": "8c105c2e4a45c10e", "name": "debug 1", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 240, "y": 360, "wires": }, { "id": "2dc0a4b70d96ebb5", "type": "mqtt-broker", "name": "", "broker": "mosquitto", "port": 1883, "clientid": "", "autoConnect": true, "usetls": false, "protocolVersion": 4, "keepalive": 60, "cleansession": true, "autoUnsubscribe": true, "birthTopic": "", "birthQos": "0", "birthRetain": "false", "birthPayload": "", "birthMsg": {}, "closeTopic": "", "closeQos": "0", "closeRetain": "false", "closePayload": "", "closeMsg": {}, "willTopic": "", "willQos": "0", "willRetain": "false", "willPayload": "", "willMsg": {}, "userProps": "", "sessionExpiry": "" } ]

Fällt der MQTT-Broker aus, können angeschlossene Geräte und Anwendungen keine Nachrichten mehr austauschen. Läuft der Node-RED-Flow unbeaufsichtigt, bemerken wir die Unterbrechung möglicherweise erst deutlich später. Eine dauerhaft gespeicherte Logdatei hilft uns dabei, nachzuvollziehen, wann die Verbindung unterbrochen und zu welchem Zeitpunkt sie wiederhergestellt wurde.

Der Ausgangspunkt ist der Flow aus dem vorherigen Beitrag. Eine Status-Node überwacht den Verbindungszustand der MQTT-Out-Node. Die nachfolgende Switch-Node unterscheidet zwischen den beiden Statuswerten „verbunden“ und „nicht verbunden“.

Abhängig vom erkannten Zustand erzeugen zwei Function-Nodes eine verständliche Meldung:

Die Verbindung zum MQTT-Broker ist unterbrochen!

beziehungsweise:

Die Verbindung zum MQTT-Broker wurde hergestellt!

Bisher werden diese Meldungen lediglich über eine Debug-Node ausgegeben. Im nächsten Schritt erweitern wir den Flow so, dass jede Statusänderung zusätzlich mit einem Zeitstempel in einer Logdatei gespeichert wird.

Damit können wir später beispielsweise folgende Fragen beantworten:

- Wann ist der MQTT-Broker ausgefallen? - Wie lange war die Verbindung unterbrochen? - Wann konnte Node-RED die Verbindung wiederherstellen? - Tritt der Fehler regelmäßig zu einer bestimmten Uhrzeit auf?

Gerade bei einem dauerhaft laufenden Node-RED-System ist diese Protokollierung deutlich hilfreicher als eine reine Ausgabe im Debug-Bereich.

MQTT-Status mit Node-RED-Bordmitteln protokollieren

Für die erste Lösung verwenden wir ausschließlich Nodes, die bereits in Node-RED enthalten sind. Zusätzliche Erweiterungen müssen dafür nicht installiert werden.

Node-RED Flow zum Importieren }, { "id": "7d1c53815cc56777", "type": "inject", "z": "8c105c2e4a45c10e", "name": "", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 120, "y": 40, "wires": ] }, { "id": "2e69599beb37b62d", "type": "mqtt out", "z": "8c105c2e4a45c10e", "name": "", "topic": "/beispiel/text", "qos": "", "retain": "", "respTopic": "", "contentType": "", "userProps": "", "correl": "", "expiry": "", "broker": "2dc0a4b70d96ebb5", "x": 270, "y": 40, "wires": }, { "id": "7113958f4b37c1cb", "type": "status", "z": "8c105c2e4a45c10e", "name": "", "scope": , "x": 100, "y": 140, "wires": ] }, { "id": "5edda4976ee422cb", "type": "debug", "z": "8c105c2e4a45c10e", "name": "Ausgabe der Statusänderung", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 1260, "y": 120, "wires": }, { "id": "99ee96e58880f9fd", "type": "function", "z": "8c105c2e4a45c10e", "name": "Statusmeldung für "nicht verbunden" erstellen", "func": "msg.payload = "Die Verbindung zum MQTT Broker ist unterbrochen!";nmsg.logLevel = "ERROR";nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 540, "y": 100, "wires": ] }, { "id": "895156e15c61ffb6", "type": "switch", "z": "8c105c2e4a45c10e", "name": "", "property": "status.text", "propertyType": "msg", "rules": , "checkall": "false", "repair": false, "outputs": 3, "x": 250, "y": 140, "wires": , , ] }, { "id": "03e0329660e4c26b", "type": "function", "z": "8c105c2e4a45c10e", "name": "Statusmeldung für "verbunden" erstellen", "func": "msg.payload = "Die Verbindung zum MQTT Broker wurde hergestellt!";nmsg.logLevel = "INFO";nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 540, "y": 220, "wires": ] }, { "id": "ae0e3cd59331728d", "type": "function", "z": "8c105c2e4a45c10e", "name": "LogMessage erstellen", "func": "function createGermanTimestamp() {n const now = new Date();nn const day = String(now.getDate()).padStart(2, "0");n const month = String(now.getMonth() + 1).padStart(2, "0");n const year = now.getFullYear();nn const hours = String(now.getHours()).padStart(2, "0");n const minutes = String(now.getMinutes()).padStart(2, "0");n const seconds = String(now.getSeconds()).padStart(2, "0");n const milliseconds = String(now.getMilliseconds()).padStart(3, "0");nn return `${day}.${month}.${year} ${hours}:${minutes}:${seconds}.${milliseconds}`;n}nnlet timestamp = createGermanTimestamp();nmsg.payload = timestamp + " " + msg.payload;nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 980, "y": 160, "wires": ] }, { "id": "e42770381c324907", "type": "file", "z": "8c105c2e4a45c10e", "name": "", "filename": "/data/sample.log", "filenameType": "str", "appendNewline": true, "createDir": false, "overwriteFile": "false", "encoding": "none", "x": 1220, "y": 180, "wires": ] }, { "id": "da8de8fd48fad8c1", "type": "function", "z": "8c105c2e4a45c10e", "name": "Statusmeldung für "Verbindung wird hergestellt" erstellen", "func": "msg.payload = "Die Verbindung zum MQTT Broker wird hergestellt!";nmsg.logLevel = "INFO";nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 590, "y": 160, "wires": ] }, { "id": "2dc0a4b70d96ebb5", "type": "mqtt-broker", "name": "", "broker": "mosquitto", "port": 1883, "clientid": "", "autoConnect": true, "usetls": false, "protocolVersion": 4, "keepalive": 60, "cleansession": true, "autoUnsubscribe": true, "birthTopic": "", "birthQos": "0", "birthRetain": "false", "birthPayload": "", "birthMsg": {}, "closeTopic": "", "closeQos": "0", "closeRetain": "false", "closePayload": "", "closeMsg": {}, "willTopic": "", "willQos": "0", "willRetain": "false", "willPayload": "", "willMsg": {}, "userProps": "", "sessionExpiry": "" } ]

Die Status-Node überwacht den Verbindungszustand der MQTT-Out-Node. Sobald sich der Status ändert, wird eine Nachricht an die Switch-Node übergeben. Diese unterscheidet in unserem Beispiel zwischen drei möglichen Zuständen:

- Verbindung unterbrochen - Verbindung wird hergestellt - Verbindung hergestellt

Für jeden Zustand wird eine eigene Function-Node verwendet. Dort erzeugen wir eine verständliche Meldung und ergänzen zusätzlich ein Log-Level.

Bei einer unterbrochenen Verbindung verwenden wir das Log-Level ERROR:

msg.payload = "Die Verbindung zum MQTT-Broker ist unterbrochen!"; msg.logLevel = "ERROR"; return msg;

Während Node-RED versucht, die Verbindung erneut herzustellen, verwenden wir das Log-Level INFO:

msg.payload = "Die Verbindung zum MQTT-Broker wird hergestellt!"; msg.logLevel = "INFO"; return msg;

Auch die erfolgreich wiederhergestellte Verbindung wird als Information protokolliert:

msg.payload = "Die Verbindung zum MQTT-Broker wurde hergestellt!"; msg.logLevel = "INFO"; return msg;

Alle drei Nachrichten werden anschließend an dieselbe Function-Node weitergeleitet. Diese ergänzt einen Zeitstempel mit Millisekunden und erzeugt daraus einen einheitlichen Logeintrag.

function createGermanTimestamp() { const now = new Date(); const day = String(now.getDate()).padStart(2, "0"); const month = String(now.getMonth() + 1).padStart(2, "0"); const year = now.getFullYear(); const hours = String(now.getHours()).padStart(2, "0"); const minutes = String(now.getMinutes()).padStart(2, "0"); const seconds = String(now.getSeconds()).padStart(2, "0"); const milliseconds = String(now.getMilliseconds()).padStart(3, "0"); return `${day}.${month}.${year} ${hours}:${minutes}:${seconds}.${milliseconds}`; } const timestamp = createGermanTimestamp(); msg.payload = `${timestamp} ${msg.payload}`; return msg;

Die fertige Meldung wird anschließend gleichzeitig an eine Debug-Node und eine File-Node übergeben. Die Debug-Node hilft uns während der Entwicklung, während die File-Node den Eintrag dauerhaft in der Datei /data/sample.log speichert.

In der Write-File-Node geben wir den vollständigen Pfad an, unter dem die Logdatei gespeichert werden soll. Dieser setzt sich aus dem Zielverzeichnis und dem Dateinamen zusammen.

Da ich Node-RED in einem Docker-Container betreibe, verwende ich das Verzeichnis /data/. Als Dateinamen wähle ich für dieses Beispiel zunächst sample.log.

Der vollständige Pfad lautet damit: /data/sample.log

Das Verzeichnis /data/ wird bei einer typischen Node-RED-Docker-Installation für persistente Daten verwendet. Voraussetzung ist, dass es als Volume eingebunden wurde. Dadurch bleibt die Logdatei auch erhalten, wenn der Container neu gestartet oder neu erstellt wird.

Die Option zum Anhängen an eine bestehende Datei muss aktiviert sein. Andernfalls würde die Logdatei bei jeder neuen Meldung überschrieben werden. Außerdem sollte nach jedem Eintrag automatisch ein Zeilenumbruch ergänzt werden.

Logdateien automatisch nach Datum aufteilen

Bisher werden alle Meldungen in dieselbe Datei geschrieben: /data/sample.log

Bei einem dauerhaft laufenden Node-RED-System kann diese Datei mit der Zeit jedoch sehr groß und unübersichtlich werden. Außerdem ist es schwieriger, gezielt nach Ereignissen eines bestimmten Tages zu suchen.

In der Softwareentwicklung reicht es nicht aus, nur die sogenannten Happy Cases abzudecken – also die Fälle, in denen eine Anwendung genau so funktioniert wie vorgesehen. Genauso wichtig sind die Fehlerfälle.

Ein Endpunkt auf einem Server kann vorübergehend nicht erreichbar sein, ein Gerät kann ausfallen oder eine Netzwerkverbindung kann unterbrochen werden. Solche Ausfälle können geplant oder ungeplant auftreten. Deshalb muss eine Anwendung damit umgehen können, ohne sofort komplett abzubrechen.

https://youtu.be/5fzqeXvJz1o

Node-RED ist grundsätzlich sehr robust. Es muss schon einiges passieren, damit die gesamte Anwendung beendet wird. Trotzdem kann ein einzelner Flow an einer Stelle stoppen, an der wir es nicht erwarten oder nicht möchten. Noch problematischer wird es, wenn wir gar nicht erkennen, warum der Flow nicht weiterläuft, weil keine verständliche Fehlermeldung ausgegeben wird.

In diesem Beitrag zeige ich dir deshalb, wie du Fehler in Node-RED gezielt findest und behandelst. Dabei schauen wir uns die Debug-, Catch- und Status-Node an und klären, welche Aufgabe jede dieser Nodes übernimmt.

Ein echter Fehlerfall aus der Praxis

Diesen Beitrag schreibe ich gerade während einer Zugfahrt. Dabei zeigt sich sehr deutlich, warum eine saubere Fehlerbehandlung in Node-RED wichtig ist: Die mobile Internetverbindung ist unterwegs nicht immer stabil und bricht zwischendurch vollständig ab.

Beim ersten Aufruf meines Blogs über die HTTP-Request-Node wurde die Seite noch erfolgreich geladen und der Server antwortete mit dem HTTP-Statuscode 200. Beim nächsten Versuch war die Verbindung jedoch unterbrochen und die Anfrage schlug fehl.

Das Schaubild zeigt, wie sich eine instabile Internetverbindung unterwegs auf Anfragen auswirken kann und warum eine saubere Fehlerbehandlung in Node-RED wichtig ist.

Damit ist dieses Beispiel kein künstlich erzeugter Testfall, sondern ein echter Anwendungsfall aus der Praxis. Netzwerkverbindungen, Server und Geräte können jederzeit vorübergehend nicht erreichbar sein. Ein guter Node-RED Flow sollte solche Situationen erkennen, den Fehler verständlich ausgeben und kontrolliert darauf reagieren.

Ausgangssituation: Ein einfacher Flow mit Fehler

Wir starten bewusst mit einem kleinen Flow:

Inject → URL setzen → HTTP Request → Debug

Beim ersten Test verwenden wir die korrekte Adresse meines Blogs. Anschließend erzeugen wir bewusst einen Fehler, indem wir den Hostnamen verändern oder die Netzwerkverbindung unterbrechen.

Der erste HTTP-Aufruf liefert den Statuscode 200. Beim zweiten Versuch schlägt die Anfrage wegen der instabilen Internetverbindung im Zug fehl. Node-RED Flow als JSON zum Importieren }, { "id": "1fed1fa1c2946366", "type": "inject", "z": "34e4fe199e96c12e", "name": "Anfrage an Server stellen", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 190, "y": 80, "wires": ] }, { "id": "02edada60c105002", "type": "http request", "z": "34e4fe199e96c12e", "name": "HTTP Request", "method": "GET", "ret": "txt", "paytoqs": "ignore", "url": "https://draeger-it.blo", "tls": "", "persist": false, "proxy": "", "insecureHTTPParser": false, "authType": "", "senderr": false, "headers": , "x": 400, "y": 140, "wires": ] }, { "id": "1c0dd8bbac0c8573", "type": "debug", "z": "34e4fe199e96c12e", "name": "Ausgabe der Antwort", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 600, "y": 200, "wires": } ]

Beim Auslösen versucht die HTTP-Request-Node, die Webseite aufzurufen. Beim Test mit der absichtlich veränderten Domain kann der Hostname nicht aufgelöst werden. Die HTTP-Request-Node meldet deshalb einen Fehler.

Der entscheidende Pain Point: Der Flow liefert keine normale Antwort mehr – aber wie erkennen und behandeln wir diesen Fehler gezielt?

Ein erster wichtiger Hinweis kann bereits über die Debug-Node am Ende des Flows sichtbar werden. Dafür sollte sie jedoch nicht nur msg.payload, sondern das vollständige Nachrichtenobjekt ausgeben.

Fehlerinformationen befinden sich häufig in zusätzlichen Eigenschaften der Nachricht und wären bei einer reinen Ausgabe von msg.payload nicht zu sehen. Durch die Einstellung „vollständiges Nachrichtenobjekt“ lassen sich deshalb neben dem Payload auch weitere Informationen untersuchen, die bei der Eingrenzung eines Fehlers helfen können.

Allerdings erhält eine direkt angeschlossene Debug-Node im Fehlerfall nicht immer eine Nachricht. Meldet die betreffende Node den Fehler ausschließlich an die Node-RED-Laufzeit, muss dieser über eine Catch-Node abgefangen werden.

Das ist ein guter erster Schritt bei der Fehlersuche. Betrachtet man allerdings nur den sogenannten Happy Case und geht fest davon aus, dass die Adresse immer erreichbar ist, würde der Flow an dieser Stelle im Fehlerfall schlicht nicht wie erwartet weiterlaufen.

Genau hier beginnt das eigentliche Problem: Der Flow kann an einer Stelle stoppen, an der wir eigentlich mit einer Antwort gerechnet haben. Deshalb reicht eine Debug-Node allein oft nicht aus. Für eine saubere Fehlerbehandlung in Node-RED schauen wir uns im nächsten Schritt an, wie sich Fehler gezielt mit einer Catch-Node abfangen lassen.

Fehler mit der Catch-Node gezielt abfangen

Die Debug-Node hilft uns dabei, Nachrichten und mögliche Fehler genauer zu untersuchen. Sie reagiert jedoch nur auf Nachrichten, die sie über eine direkte Verbindung erhält. Für eine gezielte Fehlerbehandlung stellt Node-RED deshalb die Catch-Node bereit.

Wichtig: Die Catch-Node kann nur Fehler verarbeiten, die von einer Node als abfangbarer Fehler an die Node-RED-Laufzeit gemeldet werden. Manche Nodes schreiben Fehler lediglich in das Protokoll oder ändern ihren sichtbaren Status. In solchen Fällen wird die Catch-Node nicht ausgelöst. Eine Statusänderung lässt sich gegebenenfalls stattdessen mit der Status-Node überwachen.

Die Catch-Node wird nicht direkt in den normalen Nachrichtenfluss eingebaut. Stattdessen überwacht sie andere Nodes innerhalb desselben Flows und wird ausgelöst, sobald eine überwachte Node einen abfangbaren Fehler meldet.

Für unser Beispiel erweitern wir den Flow zunächst um eine Catch-Node und eine weitere Debug-Node:

Die Catch-Node erfasst alle abfangbaren Fehler innerhalb des aktuellen Flows und leitet sie an die Debug-Node weiter. Node-RED Flow als JSON zum Importieren }, { "id": "1fed1fa1c2946366", "type": "inject", "z": "34e4fe199e96c12e", "name": "Anfrage an Server stellen", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 190, "y": 80, "wires": ] }, { "id": "02edada60c105002", "type": "http request", "z": "34e4fe199e96c12e", "name": "HTTP Request", "method": "GET", "ret": "txt", "paytoqs": "ignore", "url": "", "tls": "", "persist": false, "proxy": "", "insecureHTTPParser": false, "authType": "", "senderr": false, "headers": , "x": 400, "y": 80, "wires": ] }, { "id": "1c0dd8bbac0c8573", "type": "debug", "z": "34e4fe199e96c12e", "name": "Ausgabe der Antwort", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 600, "y": 80, "wires": }, { "id": "06272495c7e74077", "type": "catch", "z": "34e4fe199e96c12e", "name": "", "scope": null, "uncaught": false, "x": 120, "y": 140, "wires": ] }, { "id": "7e40a2e0d5e75996", "type": "debug", "z": "34e4fe199e96c12e", "name": "Ausgabe der Fehlermeldung", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 340, "y": 140, "wires": } ] Inject → URL setzen → HTTP Request → Debug Catch → Debug

Die Catch-Node ist in diesem ersten Beispiel so eingestellt, dass sie alle abfangbaren Fehler innerhalb des aktuellen Flows überwacht. Schlägt der Aufruf der Webseite beispielsweise wegen einer unterbrochenen Internetverbindung oder einer ungültigen Adresse fehl, erzeugt die Catch-Node eine neue Nachricht für unseren Fehlerpfad.

Diese Nachricht enthält unter anderem die Eigenschaft msg.error. Darin finden wir Informationen zur Fehlermeldung und zu der Node, die den Fehler ausgelöst hat.

Typischerweise kann die Nachricht beispielsweise folgende Struktur enthalten:

{ "_msgid": "173ab202bb77ddd9", "error": { "message": "RequestError: getaddrinfo ENOTFOUND draeger-it.blo", "source": { "id": "02edada60c105002", "type": "http request", "name": "HTTP Request", "count": 1 }, "code": "ENOTFOUND", "stack": "RequestError: getaddrinfo ENOTFOUND draeger-it.blon at ClientRequest. (file:///usr/src/node-red/node_modules/got/dist/source/core/index.js:790:107)n at Object.onceWrapper (node:events:639:26)n at ClientRequest.emit (node:events:536:35)n at emitErrorEvent (node:_http_client:101:11)n at TLSSocket.socketErrorListener (node:_http_client:504:5)n at TLSSocket.emit (node:events:524:28)n at emitErrorNT (node:internal/streams/destroy:169:8)n at emitErrorCloseNT (node:internal/streams/destroy:128:3)n at process.processTicksAndRejections (node:internal/process/task_queues:82:21)n at GetAddrInfoReqWrap.onlookupall (node:dns:122:26)" } }

Die genaue Fehlermeldung kann je nach Ursache unterschiedlich aussehen. Bei einer instabilen Netzwerkverbindung können beispielsweise Zeitüberschreitungen, DNS-Fehler oder Verbindungsabbrüche auftreten.

Da sich eine instabile Internetverbindung nicht zuverlässig reproduzieren lässt, erzeuge ich den Fehler für das folgende Beispiel bewusst. Dazu entferne ich das „g“ am Ende der Domain. Die URL verweist dadurch auf den nicht vorhandenen Hostnamen draeger-it.blo.

Der große Vorteil: Über den Ausgang der Catch-Node können wir den Fehler nun kontrolliert weiterverarbeiten. Wir könnten ihn beispielsweise:

- im Debug-Fenster ausgeben, - in einer Datei protokollieren, - per MQTT versenden, - als Benachrichtigung weiterleiten, - oder nach einer kurzen Wartezeit einen erneuten Versuch starten.

Damit endet der Fehler nicht mehr unbemerkt innerhalb des ursprünglichen Flows. Stattdessen entsteht ein eigener Fehlerpfad, über den wir gezielt auf die jeweilige Situation reagieren können.

Fehler mit einer Switch-Node unterscheiden

Nachdem die Catch-Node den Fehler abgefangen hat, können wir die Nachricht mit einer Switch-Node genauer untersuchen. Dadurch lässt sich abhängig von der Fehlerursache unterschiedlich reagieren.

Die Fehlermeldung befindet sich in unserem Beispiel unter: msg.error.message

Bei einer nicht auflösbaren Adresse lautet die Meldung beispielsweise: RequestError: getaddrinfo ENOTFOUND draeger-it.blo

Der Bestandteil ENOTFOUND bedeutet, dass der angegebene Hostname nicht über das Domain Name System aufgelöst werden konnte. In diesem Beispiel wurde die Adresse absichtlich falsch geschrieben.

In der Switch-Node wählen wir deshalb folgende Eigenschaft aus: msg.error.message

Als Regel verwenden wir: enthält ENOTFOUND

Alternativ können wir in diesem Beispiel direkt die Eigenschaft msg.error.code auswerten. Diese enthält den Wert ENOTFOUND und ist damit eindeutiger als die vollständige Fehlermeldung unter msg.error.message.

Sofern msg.error.code vorhanden ist, sollte bevorzugt diese Eigenschaft ausgewertet werden. Falls eine Node keinen separaten Fehlercode liefert, kann alternativ nach einem eindeutigen Bestandteil wie ENOTFOUND innerhalb von msg.error.message gesucht werden.

Die Switch-Node leitet die Nachricht anschließend über einen eigenen Ausgang weiter. An diesem Ausgang könnten wir beispielsweise eine verständliche Meldung erzeugen, den Fehler protokollieren oder einen erneuten Aufruf vorbereiten.

Node-RED Flow als JSON zum Importieren }, { "id": "1fed1fa1c2946366", "type": "inject", "z": "34e4fe199e96c12e", "name": "Anfrage an Server stellen", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 190, "y": 80, "wires": ] }, { "id": "02edada60c105002", "type": "http request", "z": "34e4fe199e96c12e", "name": "HTTP Request", "method": "GET", "ret": "txt", "paytoqs": "ignore", "url": "", "tls": "", "persist": false, "proxy": "", "insecureHTTPParser": false, "authType": "", "senderr": false, "headers": , "x": 400, "y": 80, "wires": ] }, { "id": "1c0dd8bbac0c8573", "type": "debug", "z": "34e4fe199e96c12e", "name": "Ausgabe der Antwort", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 600, "y": 80, "wires": }, { "id": "06272495c7e74077", "type": "catch", "z": "34e4fe199e96c12e", "name": "", "scope": null, "uncaught": false, "x": 120, "y": 140, "wires": ] }, { "id": "7e40a2e0d5e75996", "type": "debug", "z": "34e4fe199e96c12e", "name": "Ausgabe der Fehlermeldung", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 340, "y": 140, "wires": }, { "id": "b1bc78c235752bfd", "type": "switch", "z": "34e4fe199e96c12e", "name": "", "property": "error.message", "propertyType": "msg", "rules": , "checkall": "true", "repair": false, "outputs": 1, "x": 270, "y": 200, "wires": ] }, { "id": "8ecf3eecd3dc4b50", "type": "debug", "z": "34e4fe199e96c12e", "name": "Fehlermeldung ausgeben", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 670, "y": 280, "wires": }, { "id": "b8dcbfd71f5a3a7f", "type": "function", "z": "34e4fe199e96c12e", "name": "bauen der spezifizierten Fehlermeldung", "func": "msg.payload = "Die Adresse " + msg.url + " konnte nicht gefunden werden!";nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 520, "y": 200, "wires": ] } ]

Es ist sinnvoller, nur auf den Bestandteil ENOTFOUND zu prüfen und nicht die vollständige Fehlermeldung zu vergleichen. Der Domainname oder zusätzliche Bestandteile der Meldung können sich ändern, während der eigentliche Fehlercode gleich bleibt.

Catch-Node auf die HTTP-Request-Node begrenzen

In der bisherigen Konfiguration reagiert die Catch-Node auf Fehler aller Nodes innerhalb des aktuellen Flows. Für kleine Beispiele ist das zunächst praktisch. Sobald ein Flow jedoch größer wird und mehrere Nodes Fehler erzeugen können, lässt sich die Ursache schwieriger zuordnen.

Deshalb können wir festlegen, welche Node von der Catch-Node überwacht werden soll.

Dazu öffnen wir die Catch-Node und wählen unter den überwachten Nodes ausschließlich die HTTP-Request-Node aus. Anschließend reagiert die Catch-Node nur noch auf Fehler, die von dieser Node gemeldet werden.

Das hat mehrere Vorteile:

Im Beitrag „Node-RED Context nach Neustart behalten – so geht’s“ habe ich gezeigt, wie man Context-Daten in Node-RED dauerhaft speichern kann.

Dafür wird der sogenannte Persistent Context aktiviert. Node-RED speichert Werte dann nicht nur im Arbeitsspeicher, sondern zusätzlich im Dateisystem.

Gerade auf einem Raspberry Pi kommt dabei schnell eine wichtige Frage auf:

Kann das häufige Schreiben auf die SD-Karte zu Problemen führen?

Die kurze Antwort lautet: Ja, grundsätzlich sollte man Schreibzugriffe auf SD-Karten im Blick behalten. Für einfache Zähler, Zustände und Konfigurationswerte ist der Persistent Context aber in der Regel unkritisch.

https://youtu.be/uruYVypy1D4

Warum sind Schreibzyklen bei der Node-RED SD-Karte ein Thema?

SD-Karten nutzen Flash-Speicher. Dieser Speicher kann nicht unbegrenzt oft beschrieben werden.

Je nach Qualität der Karte, Speichertechnik und Controller gibt es deutliche Unterschiede. Sehr einfache Karten können eine deutlich geringere Lebensdauer haben als hochwertige Industrie- oder High-Endurance-Karten.

Deshalb sollte man bei Projekten mit Raspberry Pi immer überlegen, wie häufig Daten geschrieben werden.

Typische Beispiele für viele Schreibzugriffe sind:

- Logdateien - Messwerte in kurzen Intervallen - Datenbanken - temporäre Dateien - häufig aktualisierte Statusdateien

Wenn jede Sekunde neue Daten auf die SD-Karte geschrieben werden, kann das langfristig zu Problemen führen.

Wie schreibt Node-RED Context-Daten?

Beim localfilesystem Context Store schreibt Node-RED die Daten nicht zwangsläufig bei jeder einzelnen Änderung sofort auf die SD-Karte.

Stattdessen werden die Daten gepuffert und in Intervallen in das Dateisystem geschrieben.

Dafür gibt es unter anderem die Option flushInterval.

Ein Beispiel:

contextStorage: { default: { module: "localfilesystem", config: { cache: true, flushInterval: 30 } } }

Mit flushInterval: 30 legt Node-RED fest, in welchem Mindestabstand Daten in das Dateisystem geschrieben werden.

Das bedeutet: Wenn sich ein Context-Wert mehrfach innerhalb kurzer Zeit ändert, muss nicht jede Änderung sofort einen direkten Schreibvorgang auf die SD-Karte auslösen.

Ist das ein Problem für die SD-Karte?

Für einzelne Werte ist das normalerweise kein großes Problem.

Beispiele:

- ein Zählerstand - ein letzter Schaltzustand - eine Konfiguration - ein Grenzwert - ein Betriebsmodus - ein Merker innerhalb eines Flows

Solche Werte ändern sich meist nicht regelmäßig oder sind gering.

Problematisch wird es eher, wenn man versucht, viele Sensordaten in kurzen Intervallen im Persistent Context zu speichern.

Beispiele:

- Temperaturwert jede Sekunde - Stromverbrauch alle paar Sekunden - große JSON-Objekte - Messwert-Historien - viele verschiedene Sensoren gleichzeitig

Dafür ist der Persistent Context nicht die beste Lösung.

Bessere Lösung: Zwei Context Stores verwenden

Eine sehr saubere Lösung ist es, zwei Context Stores zu verwenden:

- einen flüchtigen Speicher im RAM - einen persistenten Speicher im Dateisystem

Die Idee dahinter ist einfach:

Standardmäßig bleiben Werte im Arbeitsspeicher. Nur Werte, die wirklich dauerhaft benötigt werden, werden gezielt im Dateisystem gespeichert.

Beispiel:

contextStorage: { default: "memoryOnly", memoryOnly: { module: "memory" }, file: { module: "localfilesystem" } }

Damit nutzt Node-RED standardmäßig den RAM. Der Dateispeicher wird nur verwendet, wenn man ihn bewusst auswählt.

Das ist besonders sinnvoll auf einem Raspberry Pi mit SD-Karte.

Speichern im File-Store

Wenn mehrere Context Stores definiert sind, kann man gezielt festlegen, wo ein Wert gespeichert wird.

Ein Wert im normalen RAM-Context:

flow.set("letzteTemperatur", 22.6);

Ein Wert im persistenten File-Context:

flow.set("letzteTemperatur", 22.6, "file");

Das Auslesen erfolgt entsprechend so:

let temperatur = flow.get("letzteTemperatur", "file");

Damit lässt sich perfekt steuern, welche Daten dauerhaft erhalten bleiben sollen.

Wann sollte ich welchen Store verwenden?

Den RAM-Context würde ich verwenden für:

- aktuelle Sensorwerte - temporäre Statuswerte - Zwischenberechnungen - Werte, die nach einem Neustart egal sind - häufig aktualisierte Daten

Den File-Context würde ich verwenden für:

- Zählerstände - Konfigurationswerte - letzte bekannte Zustände - Grenzwerte - Betriebsmodi - wichtige Merker

So hält man die Schreibzugriffe auf die SD-Karte gering und nutzt den Persistent Context trotzdem sinnvoll.

Das Schaubild vergleicht Arbeitsspeicher, persistenten Context und Datenbank in Node-RED und zeigt, welche Datentypen jeweils sinnvoll gespeichert werden sollten.

Wann sollte ich lieber eine Datenbank nutzen?

Wenn du viele Messwerte speichern und später auswerten möchtest, ist eine Datenbank meist die bessere Wahl.

Zum Beispiel für:

- Temperaturverläufe - Stromverbrauch über mehrere Tage - Diagramme - CSV-Export - historische Daten - viele Sensorwerte

Hier sind SQLite, InfluxDB oder andere Datenbanken besser geeignet als der Persistent Context.

Der Persistent Context ist ideal für wenige wichtige Zustände.

Eine Datenbank ist ideal für viele historische Werte.

Warum ist eine Datenbank dann nicht automatisch besser?

Eine berechtigte Frage ist: Wenn SQLite, PostgreSQL oder eine andere Datenbank ebenfalls auf der SD-Karte liegt, entstehen doch auch dort Schreibzugriffe.

Genau so ist es.

Eine Datenbank verhindert keine Schreibzugriffe und schont die SD-Karte nicht automatisch. Der Vorteil liegt eher darin, dass sie für viele strukturierte Daten, Abfragen, Historien und Auswertungen gemacht ist.

Der Unterschied ist also nicht: Datenbank schreibt nicht – Persistent Context schreibt.

Sondern:

Persistent Context eignet sich für wenige wichtige Zustände, etwa Zähler, Grenzwerte oder letzte Schaltzustände.

Eine Datenbank eignet sich für viele historische Messwerte, Diagramme, Auswertungen oder Exporte.

Das Schaubild zeigt, dass der Persistent Context für wenige wichtige Zustände geeignet ist, während eine Datenbank besser zu vielen historischen Messwerten, Diagrammen und Auswertungen passt.

Wenn sehr viele Daten geschrieben werden, sollte man zusätzlich über eine High-Endurance-SD-Karte, eine SSD, größere Speicherintervalle oder das Speichern nur bei Änderungen nachdenken.

Merksatz:

Entscheidend ist nicht nur, ob Context oder Datenbank genutzt wird, sondern auch, wie oft geschrieben wird und wo die Daten gespeichert werden.

Alternative: Raspberry Pi mit SSD oder NVMe betreiben

Eine weitere Möglichkeit, die SD-Karte zu entlasten, ist der Betrieb des Raspberry Pi mit einer SSD oder NVMe-Festplatte.

Dafür gibt es spezielle Erweiterungsplatinen, sogenannte NVMe HATs. Diese werden auf den Raspberry Pi aufgesteckt und ermöglichen den Anschluss einer NVMe-SSD.

Ein NVMe HAT ermöglicht den Anschluss einer SSD am Raspberry Pi und kann helfen, die microSD-Karte bei vielen Schreibzugriffen zu entlasten.

Der Vorteil: Die Daten werden dann nicht mehr auf die microSD-Karte geschrieben, sondern auf ein Speichermedium, das deutlich besser für häufige Schreibzugriffe geeignet ist.

Das ist besonders interessant, wenn auf dem Raspberry Pi mehrere Dienste laufen, zum Beispiel:

- Node-RED - MQTT-Broker - Home Assistant - SQLite oder PostgreSQL - InfluxDB - Grafana - Docker-Container

Gerade bei Datenbanken oder vielen Log- und Messwerten kann eine SSD die bessere Wahl sein.

Für kleine Projekte reicht eine gute microSD-Karte oft aus. Wenn aber dauerhaft viele Daten geschrieben werden, ist ein Raspberry Pi mit SSD oder NVMe-Speicher deutlich robuster.

Damit verschiebt man die Grenze weg von der SD-Karte und schafft eine stabilere Grundlage für Smarthome- und IoT-Projekte.

Wo bekommt man ein NVMe HAT und was kostet es?

NVMe HATs für den Raspberry Pi bekommt man bei verschiedenen Händlern. Dazu gehören zum Beispiel offizielle Raspberry-Pi-Händler, Elektronikshops, Amazon, eBay oder AliExpress.

Die Preise hängen stark vom Modell und vom Funktionsumfang ab. Ein einfaches NVMe HAT ist deutlich günstiger als ein Gehäuse mit integrierter NVMe-Erweiterung, Kühlung oder zusätzlichen Funktionen.

ShopPreishttps://amazon.deab 12 €*https://ebay.deab 18 €*https://www.pollin.de15,49 €

Hinweis von mir: Die mit einem Sternchen (*) markierten Links sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision, die dazu beiträgt, diesen Blog zu unterstützen. Der Preis für dich bleibt dabei unverändert. Vielen Dank für deine Unterstützung!

Node-RED SD-Karte entlasten: Speicheroptionen im Vergleich

Wenn viele Schreibzugriffe entstehen, lohnt sich ein Blick auf das verwendete Speichermedium. Denn egal ob Persistent Context, Datenbank oder Logdatei: Am Ende werden die Daten irgendwo gespeichert.

Beim Raspberry Pi gibt es dafür mehrere Möglichkeiten.

SpeicherlösungVorteileNachteileGeeignet fürmicroSD-Kartegünstig, einfach, direkt nutzbar, keine Zusatzhardware nötigbegrenzte Schreibzyklen, Qualität stark unterschiedlich, bei vielen Schreibzugriffen nicht idealkleine Node-RED-Projekte, einfache Automationen, wenige SchreibvorgängeUSB-Stickgünstig, schnell angeschlossen, entlastet die microSD-Karteebenfalls Flash-Speicher, Qualität stark unterschiedlich, nicht ideal für dauerhafte hohe Schreiblasteinfache Auslagerung von Logs, Backups oder kleineren Datenexterne USB-SSDrobuster als USB-Stick, besser für viele Schreibzugriffe, gute Geschwindigkeitetwas teurer, benötigt mehr Platz, ggf. mehr StromDatenbanken, Logs, Home Assistant, Docker, dauerhafte Smarthome-ProjekteNVMe HAT mit SSDsehr schnell, kompakt, saubere Lösung für den Raspberry Pi, gut für Dauerbetriebteurer, Zusatzhardware nötig, Kompatibilität zum Raspberry-Pi-Modell beachtenMini-Server, viele Dienste, viele Schreibzugriffe, Datenbanken und Smarthome-Setups

Für kleine Projekte reicht eine gute oder sogenannte High-Endurance-microSD-Karte oft völlig aus.

Wenn du nur einzelne Werte wie Zählerstände, Konfigurationen oder letzte Zustände speicherst, ist das normalerweise unkritisch.

Wenn aber regelmäßig viele Daten geschrieben werden, zum Beispiel durch Datenbanken, Logs, Home Assistant, InfluxDB oder mehrere Docker-Container, ist eine externe SSD oder ein NVMe HAT mit SSD die robustere Lösung.

Ein USB-Stick kann eine günstige Zwischenlösung sein, sollte aber nicht mit einer SSD verwechselt werden. Auch USB-Sticks nutzen Flash-Speicher und sind qualitativ sehr unterschiedlich.

Als einfache Orientierung:

Wenig Schreiblast: microSD-Karte Günstige Auslagerung: USB-Stick Viele Schreibzugriffe: externe USB-SSD Kompakter Dauerbetrieb: NVMe HAT mit SSD

Node-RED Context Stores praktisch nutzen: RAM, SD-Karte und USB-Stick

Nachdem wir uns die verschiedenen Speicheroptionen angeschaut haben, wird es nun etwas praktischer.

Im vorherigen Beitrag haben wir uns angeschaut, wie der Node-RED Context funktioniert und wie du Werte ohne Datenbank zwischenspeichern kannst.

Dabei gab es aber einen wichtigen Hinweis:

In der Standardkonfiguration werden Context-Werte im Arbeitsspeicher gespeichert. Wird Node-RED neu gestartet, der Docker-Container beendet oder der Raspberry Pi neu gebootet, können diese Werte verloren gehen.

In diesem Beitrag zeige ich dir, wie du den Node-RED Context persistent speicherst. Dadurch bleiben Werte auch nach einem Neustart erhalten.

https://youtu.be/Ux8aLVRMakY

Was bedeutet Persistent Context?

Persistent bedeutet dauerhaft gespeichert.

Beim normalen Context werden Werte im Arbeitsspeicher gehalten. Das ist schnell und für viele kleine Automationen völlig ausreichend.

Beim Persistent Context werden die Werte zusätzlich im Dateisystem gespeichert.

Das bedeutet:

- Node-RED läuft → Wert ist verfügbar - Node-RED wird beendet → Wert bleibt gespeichert - Node-RED startet neu → Wert kann wieder ausgelesen werden

Das ist besonders praktisch für:

- Zählerstände - letzte Schaltzustände - gespeicherte Grenzwerte - einfache Konfigurationen - Betriebsmodi - Merker innerhalb eines Flows

Wichtig ist aber: Auch Persistent Context ist keine vollwertige Datenbank. Für große Messwertverläufe, Diagramme oder historische Auswertungen ist SQLite, InfluxDB oder MySQL weiterhin die bessere Wahl.

Standardverhalten: Context liegt nur im Arbeitsspeicher

Standardmäßig speichert Node-RED Context-Werte im Arbeitsspeicher.

Ein einfacher Zähler funktioniert also nur, solange Node-RED läuft:

let zaehler = context.get("zaehler") || 0; zaehler++; context.set("zaehler", zaehler); msg.payload = { zaehler: zaehler }; return msg;

Nach einem Neustart beginnt dieser Zähler wieder bei 0, wenn kein persistenter Context eingerichtet ist.

Das ist kein Fehler im Flow, sondern das normale Standardverhalten.

Persistent Context in settings.js aktivieren

Um Context-Werte dauerhaft zu speichern, muss die Datei settings.js angepasst werden.

Dort wird der Bereich contextStorage ergänzt oder aktiviert.

Die einfache Variante sieht so aus:

contextStorage: { default: { module: "localfilesystem" } }

Damit verwendet Node-RED den eingebauten localfilesystem Context Store.

Die Werte werden dann nicht nur im Arbeitsspeicher gehalten, sondern zusätzlich lokal im Dateisystem gespeichert.

Wo liegt die settings.js?

Die Datei settings.js liegt normalerweise im Benutzerverzeichnis von Node-RED.

Typische Speicherorte sind:

/home/pi/.node-red/settings.js /home//.node-red/settings.js

Die Datei settings.js befindet sich im Node-RED-Benutzerverzeichnis und enthält wichtige Einstellungen, unter anderem für den Persistent Context.

Wichtig: Node-RED verwendet immer die settings.js aus dem Benutzerverzeichnis des Benutzers, unter dem Node-RED gestartet wurde.

Läuft Node-RED als normaler Benutzer, liegt die Datei meistens unter: /home//.node-red/settings.js

Läuft Node-RED dagegen als root, wird diese Datei verwendet: /root/.node-red/settings.js

Wenn Änderungen an der settings.js scheinbar keine Wirkung haben, wurde häufig die falsche Datei bearbeitet.

Bei einer Docker-Installation liegt die Datei meistens im eingebundenen /data-Verzeichnis des Containers.

Zum Beispiel:

/home/stefandraeger/.node-red/settings.js

Wichtig ist: Nach der Änderung muss Node-RED neu gestartet werden.

sudo systemctl restart nodered.service

Nach Änderungen an der settings.js muss Node-RED neu gestartet werden, damit die neue Persistent-Context-Konfiguration aktiv wird.

Beispiel für Docker

Wenn Node-RED in Docker läuft, ist es besonders wichtig, dass das Datenverzeichnis dauerhaft eingebunden ist.

Ein typischer Ausschnitt aus einer docker-compose.yml sieht so aus:

services: node-red: image: nodered/node-red:latest container_name: node-red ports: - "1880:1880" volumes: - ./node-red-data:/data

Der Ordner ./node-red-data liegt auf dem Host-System und wird in den Container unter /data eingebunden.

Dadurch bleiben die Node-RED-Daten auch erhalten, wenn der Container neu erstellt wird.

Wenn du Persistent Context verwendest, sollten auch die gespeicherten Context-Daten in diesem Bereich liegen.

Erweiterte Konfiguration

Der localfilesystem Store kann zusätzlich konfiguriert werden.

Ein Beispiel:

contextStorage: { default: { module: "localfilesystem", config: { cache: true, flushInterval: 30 } } }

Mit cache: true werden Werte zusätzlich im Arbeitsspeicher gehalten.

Mit flushInterval: 30 legt Node-RED fest, in welchem Mindestabstand die Werte in das Dateisystem geschrieben werden.

Das bedeutet: Die Werte werden nicht zwangsläufig bei jeder einzelnen Änderung sofort auf die Festplatte geschrieben.

Für normale Automationen ist der Standardwert in der Regel vollkommen ausreichend.

Mehrere Context Stores verwenden

Du kannst auch mehrere Context Stores definieren.

Zum Beispiel:

contextStorage: { default: "memoryOnly", memoryOnly: { module: "memory" }, file: { module: "localfilesystem" } }

Damit gibt es zwei Speicherbereiche:

- memoryOnly für flüchtige Werte - file für dauerhaft gespeicherte Werte

Einen Wert im normalen Speicher setzt du so:

flow.set("letzteTemperatur", 22.6);

Einen Wert gezielt im Dateispeicher setzt du so:

flow.set("letzteTemperatur", 22.6, "file");

Auslesen kannst du ihn entsprechend so:

let temperatur = flow.get("letzteTemperatur", "file");

Das ist praktisch, wenn du bewusst unterscheiden möchtest, welche Werte dauerhaft gespeichert werden und welche nur während der Laufzeit benötigt werden.

Test: Bleibt der Wert nach einem Neustart erhalten?

Nach der Einrichtung kannst du den persistenten Context einfach testen.

Dafür eignet sich ein kleiner Zähler.

Function Node:

let zaehler = flow.get("zaehler") || 0; zaehler++; flow.set("zaehler", zaehler); msg.payload = { zaehler: zaehler }; return msg;

Starte den Flow mehrmals über eine Inject Node.

Danach sollte der Zähler hochzählen.

Jetzt startest du Node-RED neu.

Nach dem Neustart löst du den Flow erneut aus.

Wenn der Zähler nicht wieder bei 1 beginnt, sondern mit dem letzten Wert weitermacht, funktioniert der Persistent Context.

Wo werden die Context-Daten gespeichert?

Wenn der localfilesystem Store aktiviert ist, speichert Node-RED die Context-Daten als Dateien im Dateisystem.

Die Datei flow.json liegt im Context-Ordner von Node-RED und enthält gespeicherte Flow-Context-Werte des localfilesystem Stores.

Standardmäßig findest du diese Dateien im Node-RED-Benutzerverzeichnis unter:

~/.node-red/context/

Bei einer normalen Installation kann der Pfad zum Beispiel so aussehen:

/home/pi/.node-red/context/

oder:

/home//.node-red/context/

In diesem Ordner legt Node-RED weitere Unterordner an. Für Flow-Context-Daten wird häufig ein Ordner mit einer internen ID verwendet. Darin befindet sich dann unter anderem eine Datei:

/home//.node-red/context//flow.json

In dieser Datei werden die gespeicherten Werte des Flow Context als JSON abgelegt.

Ein gespeicherter Zähler kann dort zum Beispiel so aussehen:

{ "zaehler": 5, "letzterZeitstempel": "06.06.2026, 10:15:30" }

Wichtig: Die ⁣ entspricht nicht unbedingt dem Namen deines Flow-Tabs, sondern einer internen ID, die Node-RED für den Flow verwendet.

Auch Global-Context-Daten werden in diesem Context-Verzeichnis gespeichert. Je nach Context-Art und Konfiguration legt Node-RED dafür eigene Dateien und Ordner an.

Wichtig bei Raspberry Pi und SD-Karte

Beim Raspberry Pi sollte man beachten, dass häufiges Schreiben auf die SD-Karte die Lebensdauer beeinflussen kann.

Deshalb sollte man nicht jede Sekunde große Datenmengen in den Persistent Context schreiben.

Für einzelne Zustände, Zähler oder Konfigurationen ist das unproblematisch.

Für viele Messwerte in kurzen Intervallen ist eine Datenbank oder eine speziellere Speicherlösung besser geeignet.

Wann sollte ich Persistent Context verwenden?

Persistent Context ist sinnvoll für:

- einfache Zähler - letzte Zustände - letzte bekannte Werte - Konfigurationen - Grenzwerte - Betriebsmodi - kleine Merker

Nicht ideal ist er für:

- große Messwert-Historien - hochfrequente Sensorwerte - Langzeitdiagramme - viele tausend Datensätze - komplexe Auswertungen

Als Faustregel gilt:

Persistent Context ist für wenige wichtige Zustände. Eine Datenbank ist für viele historische Werte.

Fazit

Mit dem Persistent Context kannst du Werte in Node-RED dauerhaft speichern, ohne direkt eine Datenbank zu verwenden.

Dafür wird in der Datei settings.js der localfilesystem Store aktiviert.

Das ist besonders praktisch, wenn einfache Zustände, Zähler oder Konfigurationen auch nach einem Neustart erhalten bleiben sollen.

In Node-RED werden Daten normalerweise von Node zu Node weitergereicht. Ein Sensorwert kommt rein, wird verarbeitet und anschließend zum Beispiel im Debug-Fenster ausgegeben, per MQTT verschickt oder in einer Datenbank gespeichert.

Aber was ist, wenn du dir einen Wert nur kurz merken möchtest?

Zum Beispiel:

- den letzten Sensorwert - den letzten Schaltzustand - einen einfachen Zähler - den Zeitpunkt der letzten Aktion - einen Grenzwert - den Status eines Gerätes

Genau dafür gibt es in Node-RED den sogenannten Context.

Mit dem Context kannst du Werte speichern, ohne direkt eine Datenbank wie SQLite, InfluxDB oder MySQL zu verwenden. Das ist besonders praktisch für kleine Automationen, einfache Zustände und schnelle Logik innerhalb eines Flows.

https://youtu.be/EJaSk1J1iD4

Was ist der Node-RED Context?

Der Context ist vereinfacht gesagt ein kleiner Speicherbereich innerhalb von Node-RED.

Du kannst dort Werte ablegen und später wieder abrufen. Das funktioniert ähnlich wie eine Variable in einem Programm, nur dass der Wert nicht nur während einer einzelnen Nachricht existieren muss.

Ein einfaches Beispiel:

Ein Temperaturwert kommt regelmäßig in Node-RED an. Du möchtest prüfen, ob sich der Wert seit der letzten Messung geändert hat. Dafür musst du den vorherigen Wert irgendwo speichern.

Natürlich könntest du dafür eine Datenbank verwenden. Für so eine kleine Aufgabe wäre das aber übertrieben.

Hier reicht der Node-RED Context völlig aus.

Wann ist der Context sinnvoll?

Der Context ist ideal für kleine Zustände und einfache Zwischenspeicher.

Typische Beispiele sind:

- letzter Messwert eines Sensors - vorheriger Schaltzustand eines Shelly - Anzahl der Tastendrücke - letzte MQTT-Nachricht - letzter Zeitstempel - aktueller Modus einer Automation - Merker, ob eine Benachrichtigung bereits gesendet wurde

Ein praktisches Beispiel aus dem Smarthome:

Ein Shelly Plug S liefert regelmäßig seine aktuelle Leistung. Du möchtest aber nicht bei jedem identischen Wert eine neue Aktion auslösen. Also speicherst du den letzten Wert im Context und vergleichst ihn mit dem neuen Wert.

Nur wenn sich der Wert geändert hat, läuft der Flow weiter.

Wann sollte ich lieber eine Datenbank verwenden?

Der Context ist praktisch, aber kein Ersatz für eine richtige Datenbank.

Eine Datenbank ist besser geeignet, wenn du Daten langfristig speichern oder später auswerten möchtest.

Wenn du Messwerte dauerhaft speichern möchtest, ist SQLite eine gute und leichtgewichtige Lösung. Wie du SQLite mit Node-RED verwendest, zeige ich dir in meinem Beitrag „Node-RED mit Docker – SQLite Datenbank anbinden und erste Abfragen“.

Nutze eine Datenbank für:

- Messwerte über Tage, Wochen oder Monate - Energieverbrauch - Temperaturverläufe - Diagramme - CSV-Export - historische Auswertungen - viele Datensätze

Nutze den Context für:

- einzelne Zustände - letzte Werte - einfache Merker - kleine Zähler - temporäre Logik

Merke dir als einfache Faustregel:

Context ist für Zustände. Datenbanken sind für Historien.

Die drei Context-Arten in Node-RED

Node-RED unterscheidet zwischen drei Bereichen:

- Node Context - Flow Context - Global Context

Diese drei Varianten unterscheiden sich darin, wo der gespeicherte Wert sichtbar ist.

Node Context

Der Node Context ist nur innerhalb einer bestimmten Node sichtbar.

Der Node Context speichert Werte nur innerhalb einer bestimmten Node. Ideal für einfache Zähler oder lokale Merker in einer Function Node.

Das bedeutet: Nur diese eine Function Node kann den Wert speichern und später wieder abrufen.

Das ist sinnvoll, wenn der Wert wirklich nur in dieser einen Node benötigt wird.

Beispiel:

let zaehler = context.get("zaehler") || 0; zaehler++; context.set("zaehler", zaehler); msg.payload = zaehler; return msg;

Dieser Code erzeugt einen einfachen Zähler.

Beispiel für das speichern von Werten im Node Context Flow als JSON zum Import in Node-RED }, { "id": "f4eb283e75ccec08", "type": "group", "z": "f5ee6b8ce3d7f0ea", "name": "Flow 1", "style": { "label": true }, "nodes": , "x": 34, "y": 79, "w": 572, "h": 82 }, { "id": "e0d1008fa6962d21", "type": "group", "z": "f5ee6b8ce3d7f0ea", "name": "Flow 2", "style": { "label": true }, "nodes": , "x": 34, "y": 239, "w": 572, "h": 82 }, { "id": "9b5afd956de9abc1", "type": "inject", "z": "f5ee6b8ce3d7f0ea", "g": "f4eb283e75ccec08", "name": "Start", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 130, "y": 120, "wires": ] }, { "id": "ac6cdb52ac14f29f", "type": "function", "z": "f5ee6b8ce3d7f0ea", "g": "f4eb283e75ccec08", "name": "increment value", "func": "let zaehler = context.get("zaehler") || 0;nnzaehler++;nncontext.set("zaehler", zaehler);nnmsg.payload = {n zaehler: zaehler,n flow: 1n};nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 300, "y": 120, "wires": ] }, { "id": "a7ee079e7b0ec0ec", "type": "debug", "z": "f5ee6b8ce3d7f0ea", "g": "f4eb283e75ccec08", "name": "print value", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 490, "y": 120, "wires": }, { "id": "f1bd4fcfe79191df", "type": "inject", "z": "f5ee6b8ce3d7f0ea", "g": "e0d1008fa6962d21", "name": "Start", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 130, "y": 280, "wires": ] }, { "id": "7f14fb5dea0406ed", "type": "function", "z": "f5ee6b8ce3d7f0ea", "g": "e0d1008fa6962d21", "name": "increment value", "func": "let zaehler = context.get("zaehler") || 0;nnzaehler++;nncontext.set("zaehler", zaehler);nnmsg.payload = {n zaehler: zaehler,n flow: 2n};nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 300, "y": 280, "wires": ] }, { "id": "0ed25a54054903c9", "type": "debug", "z": "f5ee6b8ce3d7f0ea", "g": "e0d1008fa6962d21", "name": "print value", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 490, "y": 280, "wires": } ]

Bei jedem Durchlauf wird der gespeicherte Wert gelesen, um 1 erhöht und wieder gespeichert.

Flow Context

Der Flow Context ist innerhalb eines kompletten Flow-Tabs sichtbar.

Der Flow Context speichert Werte für alle Nodes innerhalb desselben Flows. So kann ein Wert gespeichert und in einem anderen Verarbeitungspfad weiterverwendet werden.

Das bedeutet: Mehrere Nodes auf derselben Arbeitsfläche können auf denselben Wert zugreifen.

Das ist in der Praxis oft die nützlichste Variante.

Beispiel zum Speichern eines Wertes:

flow.set("letzteTemperatur", msg.payload); return msg;

Beispiel zum Abrufen eines Wertes:

let letzteTemperatur = flow.get("letzteTemperatur"); msg.payload = letzteTemperatur; return msg;

Damit kannst du einen Wert in einer Function Node speichern und in einer anderen Function Node wieder verwenden.

Node-RED - Flow Context Beispiel Flow als JSON zum Import in Node-RED }, { "id": "4a2e2396ea5e2544", "type": "mqtt in", "z": "989e20d562ad874b", "name": "", "topic": "/sensor/temp", "qos": "0", "datatype": "auto-detect", "broker": "2dc0a4b70d96ebb5", "nl": false, "rap": true, "rh": 0, "inputs": 0, "x": 110, "y": 180, "wires": ] }, { "id": "68282a22fe7258cd", "type": "debug", "z": "989e20d562ad874b", "name": "print value from MQTT flow", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 940, "y": 180, "wires": }, { "id": "bfb362dbabd6e504", "type": "function", "z": "989e20d562ad874b", "name": "save sensor value", "func": "flow.set("letzteTemperatur", msg.payload || undefined);nnreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 450, "y": 180, "wires": ] }, { "id": "acdb440a4401a7af", "type": "function", "z": "989e20d562ad874b", "name": "build debug message", "func": "msg.payload = "neuer Sensorwert: " + flow.get("letzteTemperatur");nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 680, "y": 180, "wires": ] }, { "id": "bf7938c56e845be4", "type": "switch", "z": "989e20d562ad874b", "name": "", "property": "letzteTemperatur", "propertyType": "flow", "rules": , "checkall": "false", "repair": false, "outputs": 2, "x": 270, "y": 180, "wires": , ] }, { "id": "4a28d1dcca1585e9", "type": "inject", "z": "989e20d562ad874b", "name": "Start", "props": , "repeat": "", "crontab": "", "once": true, "onceDelay": 0.1, "topic": "", "x": 110, "y": 60, "wires": ] }, { "id": "3351321a370f12ee", "type": "function", "z": "989e20d562ad874b", "name": "create default value", "func": "flow.set("letzteTemperatur", 0);nnreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 290, "y": 60, "wires": ] }, { "id": "cc074b457a60b73f", "type": "debug", "z": "989e20d562ad874b", "name": "print message", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 640, "y": 120, "wires": }, { "id": "7795de29b7e93269", "type": "function", "z": "989e20d562ad874b", "name": "create message", "func": "msg.payload = "selben Sensorwert empfangen."nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 440, "y": 120, "wires": ] }, { "id": "2dc0a4b70d96ebb5", "type": "mqtt-broker", "name": "", "broker": "mosquitto", "port": 1883, "clientid": "", "autoConnect": true, "usetls": false, "protocolVersion": 4, "keepalive": 60, "cleansession": true, "autoUnsubscribe": true, "birthTopic": "", "birthQos": "0", "birthRetain": "false", "birthPayload": "", "birthMsg": {}, "closeTopic": "", "closeQos": "0", "closeRetain": "false", "closePayload": "", "closeMsg": {}, "willTopic": "", "willQos": "0", "willRetain": "false", "willPayload": "", "willMsg": {}, "userProps": "", "sessionExpiry": "" } ]

Global Context

Der Global Context ist in der gesamten Node-RED-Instanz sichtbar.

Der Global Context speichert Werte für alle Flows und Tabs innerhalb derselben Node-RED-Instanz. Dadurch können zentrale Werte in mehreren Flows verwendet werden.

Das bedeutet: Alle Flows können auf diesen Wert zugreifen.

Das ist sinnvoll für Werte, die wirklich überall benötigt werden.

Beispiele:

- zentrale Konfiguration - IP-Adresse eines Gerätes - API-Basisadresse - globaler Betriebsmodus - gemeinsam genutzte Grenzwerte

Beispiel:

global.set("shelly_ip", "192.168.178.50"); return msg;

Abrufen kannst du den Wert dann so:

let ip = global.get("shelly_ip"); msg.url = "http://" + ip + "/rpc/Shelly.GetStatus"; return msg;

Hier wird die IP-Adresse eines Shelly-Gerätes zentral gespeichert und später für einen HTTP-Request verwendet.

Beispiel - Global Context Beispiel Global Context - Flow #1 }, { "id": "ca2f5066067c72ee", "type": "inject", "z": "fee017b8a550cd64", "name": "Start", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 530, "y": 60, "wires": ] }, { "id": "605814d58e345769", "type": "function", "z": "fee017b8a550cd64", "name": "set value to global context", "func": "global.set("name", "Stefan")nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 730, "y": 60, "wires": ] } ] Beispiel Global Context - Flow #2 }, { "id": "be95863731cef366", "type": "inject", "z": "7037c6aa34965146", "name": "Start", "props": , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "x": 370, "y": 60, "wires": ] }, { "id": "cf8196e6d58f8d00", "type": "function", "z": "7037c6aa34965146", "name": "build greeting", "func": "msg.payload = "Hallo " + (global.get("name") || "Hans");nreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 540, "y": 60, "wires": ] }, { "id": "b6017c014fbeb390", "type": "debug", "z": "7037c6aa34965146", "name": "print message", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 740, "y": 60, "wires": } ]

Context im Debug-Bereich anzeigen

Node-RED bietet in der Seitenleiste auch eine Context-Ansicht.

Dort kannst du gespeicherte Werte prüfen. Das ist beim Entwickeln sehr hilfreich, weil du sehen kannst, ob dein Wert wirklich gespeichert wurde.

Meist wird MQTT verwendet, um Sensordaten oder Schaltzustände zu übertragen: Temperaturwerte, Luftfeuchtigkeit oder das Ein- und Ausschalten eines Relais. Klassisches IoT eben.

Doch was viele dabei übersehen: MQTT ist völlig unabhängig davon, was du überträgst.

Ob Zahlen, Texte oder sogar strukturierte Daten – für MQTT ist alles einfach nur eine Nachricht.

Und genau hier wird es spannend.

Denn im Grunde passiert beim Chatten nichts anderes: Eine Nachricht wird gesendet, verteilt und von anderen empfangen.

👉 Genau das macht MQTT bereits – nur normalerweise ohne Menschen.

https://youtu.be/zNiSUmRnl9c

Das bedeutet:

👉 Geräte „chatten“ längst miteinander – wir müssen nur den Menschen mit ins Spiel bringen.

In diesem Beitrag zeige ich dir, wie du mit MQTT, Node-RED und einer kleinen SQLite-Datenbank einen eigenen Chat baust. Kein riesiges Framework, keine komplizierte Architektur – sondern ein leicht verständliches Praxisprojekt, das dir gleichzeitig zeigt, wie flexibel MQTT wirklich ist.

Und das Beste daran: Der Chat funktioniert nicht nur im Browser, sondern lässt sich später problemlos auf ESP32, andere Clients oder sogar dein eigenes Smart Home erweitern.

Ziel des Projekts

In diesem Beitrag bauen wir gemeinsam einen einfachen Chat auf Basis von MQTT und Node-RED. Der Fokus liegt dabei nicht auf einer vollwertigen Chat-Anwendung, sondern auf dem Verständnis der zugrunde liegenden Kommunikation.

einfacher Chat umgesetzt mit MQTT und Node-RED

Das Ziel ist es, aufzuzeigen, wie Nachrichten über MQTT gesendet, verteilt und von mehreren Teilnehmern empfangen werden können – genau so, wie es auch in klassischen IoT-Szenarien passiert.

Dabei setzen wir auf folgende Komponenten:

- MQTT als Transportprotokoll für die Nachrichten - Node-RED zur Verarbeitung und Visualisierung - SQLite zur Speicherung der Chat-Historie

Die Datenbank dient dabei ausschließlich dazu, bereits gesendete Nachrichten persistent zu speichern und beim Beitritt zum Chat erneut anzeigen zu können.

Bewusst verzichten wir in diesem Projekt auf zusätzliche Funktionen wie:

- Upload von Bildern oder Dateien - Versand von Videos - komplexe Benutzerverwaltung

Stattdessen konzentrieren wir uns auf das Wesentliche:

👉 Das Senden und Empfangen von Textnachrichten über MQTT

Genau dieser reduzierte Ansatz macht das Projekt so interessant, denn er zeigt sehr deutlich, wie einfach sich mit MQTT ein verteiltes Kommunikationssystem umsetzen lässt.

Architektur & Funktionsweise des Chats

Bevor wir mit der eigentlichen Umsetzung starten, werfen wir einen Blick auf die Architektur unseres Chats und das Zusammenspiel der einzelnen Komponenten.

In diesem Projekt übernimmt Node-RED eine zentrale Rolle:

- Es stellt das Dashboard für die Benutzeroberfläche bereit - Es fungiert als Publisher und Subscriber im MQTT-System - Es dient als Schnittstelle zur SQLite-Datenbank, in der die Nachrichten gespeichert werden

Dadurch entsteht eine flexible Architektur, bei der Node-RED zwar das Frontend liefert, aber nicht zwingend der einzige Teilnehmer im System ist.

Ablauf der Kommunikation im Chat Client mit MQTT und Node-RED Offenes System durch MQTT

Ein großer Vorteil von MQTT ist die Offenheit des Systems.

👉 Das bedeutet konkret: Dein Chat ist nicht auf das Dashboard beschränkt – er ist ein offenes System.

Neben dem Node-RED Dashboard können also auch andere Clients Nachrichten senden und empfangen, zum Beispiel:

- der MQTT Explorer zur direkten Analyse und zum Testen - ein Mikrocontroller wie ESP8266 oder ESP32 - eigene Anwendungen oder Skripte

Chatnachrichten vom MQTT Explorer als JSON

Diese Clients können problemlos Nachrichten in den Chat senden oder empfangen. Einziger Unterschied:

👉 Der Zugriff auf die Chat-Historie erfolgt in unserem Projekt ausschließlich über Node-RED und die angebundene SQLite-Datenbank.

Ablauf einer Chatnachricht

Der Ablauf einer Nachricht ist bewusst einfach gehalten und orientiert sich vollständig am MQTT-Prinzip:

- Der Benutzer meldet sich im Dashboard mit einem Benutzernamen an - Anschließend kann er – wie in jedem klassischen Chat – eine Nachricht eingeben und absenden - Node-RED veröffentlicht diese Nachricht auf einem MQTT-Topic - Der MQTT-Broker verteilt die Nachricht an alle verbundenen Clients - Node-RED empfängt die Nachricht erneut als Subscriber - Die Nachricht wird in der SQLite-Datenbank gespeichert - Der Chatverlauf wird aktualisiert und im Dashboard angezeigt

👉 Wichtig: Jede Nachricht durchläuft immer denselben Weg – unabhängig davon, ob sie vom Browser, einem Mikrocontroller oder einem anderen MQTT-Client stammt.

Verwendetes MQTT-Topic

Für die Kommunikation verwenden wir ein zentrales Topic:

chat/message

Alle Teilnehmer abonnieren dieses Topic und erhalten dadurch jede neue Nachricht in Echtzeit.

Speicherung der Nachrichten

Da MQTT selbst keine dauerhafte Speicherung vorsieht, wird jede Nachricht zusätzlich in einer SQLite-Datenbank abgelegt.

SQLite Datenbank mit Chat Historie

Das ermöglicht:

- das Nachladen der Chat-Historie beim Einstieg - die Anzeige vergangener Nachrichten - einen konsistenten Zustand im Dashboard Simple MQTT Chat mit Node-REDHerunterladen

Voraussetzungen

Für dieses Projekt benötigst du eine laufende Umgebung mit Node-RED, einem MQTT-Broker sowie einer SQLite-Datenbank.

Die gute Nachricht: Alle notwendigen Grundlagen habe ich bereits in separaten Beiträgen ausführlich erklärt.

👉 Wenn du diese Komponenten noch nicht eingerichtet hast, findest du hier die passenden Anleitungen:

- Node-RED mit Docker installieren – Schritt für Schritt - Node-RED unter Windows 11 mit WSL installieren – Schritt für Schritt - Node-RED mit Docker – SQLite Datenbank anbinden und erste Abfragen Benötigte Komponenten im Überblick

Für den Chat selbst setzen wir auf folgende Bausteine:

- Node-RED zur Verarbeitung der Daten und Bereitstellung des Dashboards - MQTT-Broker (z. B. Mosquitto) für die Verteilung der Nachrichten zwischen den Teilnehmern - SQLite-Datenbank zur Speicherung der Chat-Historie Hinweis

In diesem Beitrag konzentrieren wir uns vollständig auf die Umsetzung des Chats. Die Installation und Grundkonfiguration der einzelnen Komponenten wird daher nicht erneut behandelt.

👉 So kannst du dich direkt auf das Wesentliche konzentrieren: Das Senden und Empfangen von Nachrichten über MQTT.

Einrichten der SQLite-Datenbank für die Chat-Historie

Die Historie des Chats wird in einer SQLite-Datenbank gespeichert. Diese liegt als einfache Datei im Dateisystem vor – genau das ist einer der großen Vorteile von SQLite: Es wird kein separater Datenbankserver benötigt.

SQLite Datenbank im Docker Container von Node-RED

Für unser Projekt reicht eine einzige Tabelle aus, da wir zunächst nur einen Chatraum verwenden.

Tabellenstruktur

Die Tabelle chat_messages enthält folgende Spalten:

- id – fortlaufende, eindeutige Nummer (Primärschlüssel) - name – Name des Benutzers, der die Nachricht gesendet hat - message – eigentlicher Text der Nachricht - zeit – UNIX-Timestamp der Nachricht SQL zum Anlegen der Tabelle CREATE TABLE chat_messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, message TEXT NOT NULL, zeit INTEGER NOT NULL );

Node-RED Flow erstellen

Nachdem die Datenbank vorbereitet ist, kümmern wir uns im nächsten Schritt um den eigentlichen Node-RED Flow. Dieser verbindet das Dashboard, den MQTT-Broker und die SQLite-Datenbank zu einem einfachen, aber erstaunlich flexiblen Chat-System.

👉 Ziel ist es, drei zentrale Komponenten miteinander zu verbinden:

- Benutzeroberfläche (Dashboard) - Nachrichtenübertragung (MQTT) - Speicherung der Historie (SQLite) Aufbau des Flows im Überblick

Der Flow besteht im Kern aus drei Bereichen:

1. Dashboard (ui-template) Hier wird die Chat-Oberfläche dargestellt und Benutzereingaben werden erfasst.

Code Chat beitreten Absenden Angemeldet als {{ username }} {{ entry.name }} {{ entry.message }} {{ entry.zeit_format }} Senden

Anmeldung an einen einfachen Chat

aktiver Chat mit drei Teilnehmern

2. MQTT-Kommunikation Nachrichten werden über das Topic chat/message versendet und empfangen.

3. Datenbank-Anbindung (SQLite) Alle Nachrichten werden gespeichert und bei Bedarf wieder geladen.

Der komplette Flow

kompletter Node-RED Flow für ein einfaches Chat System

👉 Importiere den folgenden Flow in Node-RED:

Simple MQTT Chat mit Node-REDHerunterladen Verarbeitung eingehender Nachrichten

Sobald eine Nachricht im Dashboard abgesendet wird, passiert Folgendes:

- Das Dashboard sendet eine Nachricht mit: - name (Benutzername) - message (Text) - In der Function-Node „baue Nachricht“ wird die Nachricht erweitert: let name = msg.payload.name; let message = msg.payload.message; let time = Date.now(); msg.payload = { name: name, message: message, timestamp: time }; return msg;

👉 Hier wird der UNIX-Zeitstempel ergänzt, damit die Nachricht später korrekt sortiert und angezeigt werden kann.

Nachricht via MQTT versenden

Die aufbereitete Nachricht wird anschließend über eine mqtt out-Node veröffentlicht:

Topic:

chat/message

👉 Wichtig: Alle Teilnehmer im System abonnieren genau dieses Topic.

Nachricht empfangen (Subscriber)

Node-RED ist gleichzeitig auch Subscriber und empfängt jede gesendete Nachricht erneut über die mqtt in-Node.

Das bedeutet:

👉 Egal ob die Nachricht vom Browser, einem ESP32 oder dem MQTT Explorer kommt – sie wird immer gleich verarbeitet.

Speicherung in der SQLite-Datenbank

Die empfangene Nachricht wird anschließend in der Datenbank gespeichert.

Dazu wird in einer Function-Node ein SQL-Statement erzeugt:

function esc(str) { return String(str).replace(/'/g, "''"); } const name = esc(msg.payload.name); const message = esc(msg.payload.message); const zeit = esc(msg.payload.timestamp); msg.topic = `INSERT INTO chat_messages (name, message, zeit) VALUES ('${name}', '${message}', ${zeit});`; return msg;

👉 Die SQLite-Node führt dieses Statement aus und speichert die Nachricht persistent.

Chat-Historie laden

Damit der Benutzer alle bisherigen Nachrichten sieht, wird nach jedem Event die Historie neu geladen.

Das erfolgt über folgende SQL-Abfrage:

SELECT id, name, message, strftime('%d.%m.%Y %H:%M:%S', zeit / 1000, 'unixepoch', 'localtime') AS zeit_format FROM chat_messages ORDER BY zeit ASC;

👉 Hier passiert etwas Wichtiges:

- Der gespeicherte UNIX-Timestamp wird direkt in ein lesbares Datum umgewandelt - Format: Tag.Monat.Jahr Stunde:Minute:Sekunde Steuerung über Topics

Im Flow wird zwischen zwei Aktionen unterschieden:

- load_chat → lädt die Historie - send_message → sendet eine neue Nachricht

Das erfolgt über eine switch-Node:

👉 Dadurch bleibt der Flow übersichtlich und klar strukturiert.

Warum funktioniert das Ganze so gut mit MQTT?

Ganz einfach: MQTT ist von Grund auf für verteilte Systeme gebaut.

Jeder Teilnehmer kann:

- Nachrichten senden (Publisher) - Nachrichten empfangen (Subscriber)

👉 Und genau das macht einen Chat aus.

Der große Vorteil: Neue Teilnehmer können jederzeit hinzugefügt werden, ohne dass die bestehende Architektur angepasst werden muss.

Ob Browser, ESP32 oder ein eigenes Script: Solange das richtige Topic verwendet wird, ist jeder sofort Teil des Systems.

Nachrichten mit anderen MQTT-Clients senden

Ein großer Vorteil dieses Aufbaus ist, dass der Chat nicht fest an das Node-RED Dashboard gebunden ist.

Da alle Nachrichten über das MQTT-Topic chat/message laufen, kann grundsätzlich jeder MQTT-fähige Client an der Kommunikation teilnehmen. Das kann ein weiteres Node-RED Dashboard sein, ein ESP32, ein ESP8266 oder auch ein externes MQTT-Tool wie CorreoMQTT.

CorreoMQTT Tool

Wichtig ist nur, dass die Nachricht im erwarteten JSON-Format gesendet wird:

{ "name": "CorreoMQTT", "message": "Hallo aus einem externen MQTT-Client!", "timestamp": 1715779200000 }

Die Nachricht wird anschließend vom Node-RED Subscriber empfangen, in der SQLite-Datenbank gespeichert und beim erneuten Laden der Historie im Dashboard angezeigt.

Damit wird sehr schön sichtbar, worum es bei MQTT eigentlich geht:

👉 Der Absender muss das Dashboard nicht kennen. 👉 Der Empfänger muss den Absender nicht kennen. 👉 Beide müssen nur dasselbe MQTT-Topic verwenden.

Für unser Beispiel lautet dieses Topic:

chat/message

Dadurch lässt sich der Chat sehr einfach erweitern. So könnte später zum Beispiel ein ESP32 automatisch Statusmeldungen senden oder ein anderes System Benachrichtigungen in den Chat schreiben.

Fazit

Mit diesem Projekt hast du gesehen, dass MQTT deutlich mehr kann als nur Sensordaten oder Schaltbefehle zwischen Geräten auszutauschen.

Mit überraschend wenig Aufwand haben wir einen einfachen Chat aufgebaut, der Nachrichten in Echtzeit verteilt, dauerhaft speichert und unabhängig vom eigentlichen Client funktioniert.

Dabei übernehmen die einzelnen Komponenten klar getrennte Aufgaben:

- MQTT verteilt die Nachrichten - Node-RED übernimmt Oberfläche und Logik - SQLite speichert die Historie dauerhaft

Genau diese Trennung macht den Aufbau so flexibel.

Das Spannende daran: Der Chat selbst ist am Ende nur ein Beispiel.

Denn technisch betrachtet unterscheiden sich Chatnachrichten kaum von Sensordaten, Statusmeldungen oder Befehlen aus einem Smart-Home-System.

Heute schreibt ein Benutzer eine Nachricht. Morgen sendet ein ESP32 eine Warnung. Übermorgen meldet ein Shelly automatisch einen Zustand.

Und genau hier zeigt sich die eigentliche Stärke von MQTT: Nicht die Nachricht ist entscheidend – sondern dass jeder Teilnehmer dieselbe Sprache spricht.

Ich hoffe, ich konnte dir mit diesem Projekt zeigen, dass MQTT weit mehr ist als nur ein Protokoll für Temperaturwerte.

Den Shelly Plus 1PM habe ich auf meinem Blog bereits in mehreren Beiträgen vorgestellt. In meinem Fall ist das Gerät an meinem Balkonkraftwerk (BKW) angeschlossen, sodass ich darüber jederzeit die aktuelle Leistung sowie den Energieverbrauch ablesen kann.

Über die App Shelly Smart Control oder die Cloudlösung von Shelly funktioniert das grundsätzlich sehr einfach. Sobald man jedoch mehrere Werte gleichzeitig auswerten oder übersichtlich darstellen möchte, stößt die App schnell an ihre Grenzen.

Shelly selbst bietet mit dem Shelly Wall Display zwar eine Lösung an, allerdings ist dieses mit aktuell über 130 € nicht gerade günstig.

In dieser Beitragsreihe zeige ich dir daher eine deutlich flexiblere und kostengünstigere Alternative. Mit Node-RED und der gut dokumentierten Shelly API bauen wir uns Schritt für Schritt ein eigenes Energie-Dashboard, über das sich Leistungsdaten speichern, auswerten und später auch grafisch darstellen lassen.

https://youtu.be/fD2mbJ2gjpI

Im ersten Teil legen wir dafür die Grundlage: Wir erstellen eine SQLite-Datenbank, importieren vorhandene Daten und lernen, wie sich diese anschließend wieder abrufen lassen.

Node-RED Flows zum erstellen eines Shelly Dashboards

Aufbau der Lösung

Damit wir ein eigenes Energie-Dashboard erstellen können, benötigen wir zunächst eine Möglichkeit, die Leistungsdaten des Shelly dauerhaft zu speichern. Über die API lassen sich bei vielen Shelly-Geräten aktuelle Werte direkt abrufen. Eine Schnittstelle für historische Energiedaten ist jedoch nicht bei allen Modellen verfügbar.

Geräte wie der Shelly EM (Mini) oder Shelly Pro 3EM sind für Energie-Monitoring ausgelegt und bieten dafür deutlich mehr Möglichkeiten. Diese Modelle sind allerdings – je nach Ausführung – auch spürbar teurer. Beim Shelly Plus 1PM, den ich an meinem Balkonkraftwerk einsetze, lassen sich die bereits gesammelten historischen Daten nicht einfach per API abrufen.

Aus diesem Grund verfolgen wir in dieser Reihe folgenden Ansatz:

- Bereits vorhandene Daten werden zunächst einmalig als CSV-Datei exportiert. - Diese Daten importieren wir anschließend in eine lokale SQLite-Datenbank. - Über Node-RED können wir die gespeicherten Daten später wieder abrufen und für Auswertungen oder Diagramme verwenden.

Die Architektur unseres Projekts sieht daher wie folgt aus:

Schemata der Architektur - Shelly & Node-RED

Der große Vorteil dieses Ansatzes ist, dass alle Daten lokal im eigenen Netzwerk gespeichert werden. Es ist keine Cloud-Anbindung notwendig und du behältst jederzeit die volle Kontrolle über deine Messwerte.

Im nächsten Schritt installieren wir die benötigten SQLite-Nodes für Node-RED und erstellen anschließend unsere erste Datenbank.

SQLite auf dem Raspberry Pi installieren

Damit Node-RED die Energiedaten speichern kann, benötigen wir zunächst eine lokale Datenbank. Für dieses Projekt verwende ich SQLite, da diese Datenbank besonders leichtgewichtig ist und ohne zusätzlichen Server direkt auf dem Raspberry Pi betrieben werden kann.

SQLite eignet sich hervorragend für kleinere Projekte oder Zeitreihen wie Energie- und Leistungsdaten, da die komplette Datenbank einfach in einer Datei gespeichert wird.

Zuerst aktualisieren wir das System:

sudo apt update sudo apt upgrade

Anschließend installieren wir SQLite:

sudo apt install sqlite3

Nach der Installation können wir prüfen, ob SQLite korrekt installiert wurde:

sqlite3 --version

Die Ausgabe sollte ungefähr so aussehen:

Ausgabe SQLite Versionsnummer

Damit ist SQLite erfolgreich auf dem Raspberry Pi installiert und einsatzbereit.

SQLite Datenbank erstellen

Nun erstellen wir eine erste Datenbank für unsere Energiedaten. Dazu wechseln wir zunächst in das Node-RED Verzeichnis:

cd ~/.node-red

Jetzt können wir eine neue Datenbank erstellen:

sqlite3 shelly-energy.db

SQLite erstellt die Datei automatisch, falls sie noch nicht existiert. Wir befinden uns nun in der SQLite Konsole, in der wir SQL-Befehle ausführen können.

Die Eingabeaufforderung sieht dann so aus:

SQLite Datenbank anlegen

m nächsten Schritt legen wir eine Tabelle an, in der später die Leistungsdaten des Shelly gespeichert werden.

Tabelle für den CSV-Import anlegen

Da der CSV-Export des Shelly in meinem Fall einen Zeitstempel sowie den Energieverbrauch in Wh enthält, lege ich dafür zunächst eine eigene Tabelle in der SQLite-Datenbank an.

Innerhalb der SQLite-Konsole führe ich dazu folgenden SQL-Befehl aus:

CREATE TABLE shelly_energy_monthly ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, energy_wh REAL NOT NULL );

Exportieren der historischen Daten aus der Shelly Cloud

Zunächst exportieren wir die historischen Energiedaten aus der Shelly Cloud. Diese Daten dienen als Grundlage für unsere Datenbank, damit wir nicht bei Null beginnen müssen. In meinem Beispiel exportiere ich die Daten der letzten 12 Monate im CSV-Format.

Mit etwas zusätzlichem Aufwand lassen sich auch Daten über einen längeren Zeitraum exportieren. Der grundlegende Ablauf bleibt jedoch identisch.

Schritt 1: Anmeldung in der Shelly Cloud

Melde dich zunächst in der Shelly Cloud unter folgendem Link an: https://control.shelly.cloud/

Nach der Anmeldung erscheint die Übersicht deiner Geräte. Wähle dort das entsprechende Gerät aus. In meinem Fall ist der Shelly Plus 1PM, der an meinem Balkonkraftwerk angeschlossen ist und daher auch entsprechend als „Balkonkraftwerk“ bezeichnet wurde.

Schritt 2: Energieverbrauch öffnen

Auf der rechten Seite der Geräteübersicht findest du ein kleines Liniendiagramm, das den Energieverbrauch visualisiert. Klicke auf dieses Diagramm, um die detaillierte Verbrauchsansicht zu öffnen.

Anschließend aus der Auswahlliste den Eintrag "Letzte 12 Monate" auswählen.

Schritt 3: CSV-Export starten

Oben im Diagramm befindet sich neben der Beschriftung „Verbrauch“ ein Menü mit drei Punkten.

Öffnest du dieses Menü, findest du dort die Option:

„CSV exportieren“

Mit einem Klick darauf wird der Download der CSV-Datei gestartet.

Damit liegen dir nun die historischen Verbrauchsdaten vor, die wir im nächsten Schritt in unsere SQLite-Datenbank importieren werden.

CSV-Daten importieren

Nachdem wir die historischen Daten aus der Shelly Cloud exportiert haben, können wir diese nun in unsere SQLite-Datenbank importieren. Bevor wir den Import in Node-RED umsetzen, lohnt sich jedoch ein kurzer Blick in die CSV-Datei.

Öffnet man die Datei beispielsweise mit einem Editor wie Notepad++, fällt auf, dass diese zwei Datenblöcke enthält:

- Verbrauchsdaten - Einspeisedaten

Diese beiden Abschnitte stehen untereinander in der CSV-Datei.

In meinem Fall ist der Shelly Plus 1PM an einem Balkonkraftwerk angeschlossen. Da der Shelly jedoch nicht erkennt, dass Energie in das Netz eingespeist wird, werden die relevanten Werte im Abschnitt „Verbrauch“ gespeichert. Der darunter liegende Block zur Einspeisung ist für unser Projekt daher nicht relevant.

Möglichkeit 1: CSV-Datei vorher bereinigen (empfohlen)

Der einfachste Weg besteht darin, die CSV-Datei mit einem Editor wie Notepad++ zu öffnen und den unteren Block mit den Einspeisedaten zu entfernen. Sowie entfernen wir noch die Leerzeichen um die Spaltenüberschriften Zeit und Wh sowie vor den Datenzeilen. Die Datei enthält danach nur noch die benötigten Verbrauchsdaten.

Der Vorteil dieser Variante ist, dass der Node-RED Flow deutlich einfacher bleibt, da wir nur noch einen einheitlichen Datensatz importieren müssen.

Möglichkeit 2: Aufbereitung direkt in Node-RED

Alternativ könnte man die CSV-Datei auch komplett importieren und anschließend im Node-RED Flow nur die relevanten Datensätze herausfiltern. Diese Variante funktioniert ebenfalls, erhöht jedoch die Komplexität des Flows, da zusätzliche Filter- oder Function-Nodes benötigt werden.

Da es sich in diesem Beitrag um einen einmaligen Import historischer Daten handelt, entscheide ich mich für die erste Variante und bereinige die CSV-Datei vor dem Import.

Node-RED Palette erweitern

Damit Node-RED Daten in unsere SQLite-Datenbank schreiben kann, benötigen wir zunächst eine passende Node. Standardmäßig bringt Node-RED keine direkte Unterstützung für SQLite mit, diese kann jedoch sehr einfach über den Palette Manager nachinstalliert werden.

Öffne dazu zunächst das Menü in der Node-RED Oberfläche. Dieses findest du oben rechts hinter dem Symbol mit den drei horizontalen Strichen.

In dem sich öffnenden Menü wählst du anschließend den Eintrag „Palette erweitern“ aus.

Über diesen Dialog lassen sich zusätzliche Nodes installieren, die den Funktionsumfang von Node-RED erweitern. In unserem Fall benötigen wir eine Node, mit der sich SQL-Abfragen an eine SQLite-Datenbank senden lassen.

Im neu geöffneten Dialog wählst du nun den Reiter „Installation“ aus. In diesem Bereich lassen sich zusätzliche Erweiterungen für Node-RED suchen und direkt installieren.

Im Reiter „Installation“ suchen wir nun nach dem Paket node-red-node-sqlite. Sobald das Paket in der Liste erscheint, klicken wir auf „Installieren“, um die Erweiterung zu Node-RED hinzuzufügen.

Im nun erscheinenden Bestätigungsdialog klicken wir erneut auf „Installieren“, um die Installation des Pakets zu starten.

Sobald die Installation abgeschlossen ist, steht im Node-RED Editor eine neue Node mit der Bezeichnung „sqlite“ zur Verfügung. Diese findest du in der linken Node-Auswahl im Bereich „Speicher“.

Node-RED - SQLite Node

Kommunikation mit der SQLite-Datenbank testen

Bevor wir die CSV-Daten importieren, prüfen wir zunächst, ob die Kommunikation zwischen Node-RED und der SQLite-Datenbank korrekt funktioniert.

Dazu erstellen wir einen kleinen Test-Flow. Wir verwenden eine Inject Node, um ein einfaches SQL-Statement an die SQLite-Node zu übergeben. Dieses Statement liefert den aktuellen Zeitstempel der Datenbank zurück.

In der Inject Node tragen wir dazu folgenden Wert für msg.topic ein:

SELECT datetime('now');

Die Inject Node wird anschließend mit der sqlite Node verbunden. Zusätzlich verbinden wir die sqlite Node mit einer Debug Node, um das Ergebnis anzeigen zu lassen.

SQLite-Node konfigurieren

Bevor wir das SQL-Statement ausführen können, muss die sqlite Node noch konfiguriert werden. Da SQLite-Datenbanken direkt in Dateien gespeichert werden, müssen wir der Node zunächst mitteilen, wo sich unsere Datenbank befindet.

Öffne dazu die sqlite Node per Doppelklick und trage im Feld Datenbank den Pfad zur Datenbankdatei ein.

In meinem Fall lautet der Pfad:

/root/.node-red/shelly-energy.db

Dieser Pfad zeigt auf die SQLite-Datenbank, die wir zuvor auf dem Raspberry Pi erstellt haben. Sobald der Pfad eingetragen ist, kann die sqlite Node SQL-Abfragen an diese Datenbank senden und die Ergebnisse wieder an den Flow zurückgeben.

Nach dem Speichern der Einstellungen ist die sqlite Node bereit, um das zuvor erstellte Test-Statement auszuführen.

Der Test-Flow sieht damit so aus:

Flow zum abrufen eines Zeitstempels aus der SQLite Datenbank via SQL Statement