Unbetitelt

[draegerit]

Node-RED Fehler loggen: Mit Bordmitteln und eigener Logger-Node

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.

Deshalb erweitern wir den Flow so, dass für jeden Tag automatisch eine eigene Logdatei verwendet wird.

[draegerit]

Node-RED Fehler finden: Catch-, Status- und Debug-Node einfach erklärt

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:

- Fehler lassen sich eindeutig einer bestimmten Node zuordnen. - Unterschiedliche Bereiche eines Flows können eigene Fehlerbehandlungen erhalten.

[draegerit]

ThinkNode M5 von Elecrow im Test: LoRa und Meshtastic in der Praxis

LoRa ist eine spannende Funktechnik, wenn Daten über größere Entfernungen übertragen werden sollen, ohne dauerhaft auf WLAN, Mobilfunk oder eine bestehende Internetverbindung angewiesen zu sein. Besonders für IoT-Projekte, Sensorstationen, Outdoor-Anwendungen oder einfache Nachrichtenübertragung ist diese Technik interessant.

Nachdem ich im vorherigen Abschnitt erklärt habe, was LoRa ist und wie sich diese Funktechnik von WLAN oder Bluetooth unterscheidet, wird es nun praktischer. Denn erst mit einem passenden Gerät sieht man, was mit LoRa im Alltag wirklich möglich ist.

https://youtu.be/TzemcPG01I0

Ein spannendes Beispiel dafür ist der ThinkNode M5 von Elecrow. In diesem Beitrag schaue ich mir das Gerät genauer an und zeige, warum es sich besonders gut für den Einstieg in LoRa und Meshtastic eignet.

Transparenzhinweis: Für diesen Beitrag habe ich von der Firma Elecrow zwei ThinkNode M5 kostenfrei für ein Review erhalten. Eine inhaltliche Vorgabe für diesen Beitrag gab es nicht. Meine Einschätzung, Erfahrungen und gezeigten Ergebnisse basieren auf meinem eigenen Test der Geräte.

Was ist der ThinkNode M5?

Der ThinkNode M5 ist ein kompaktes LoRa-Gerät von Elecrow, das für den praktischen Einsatz mit Meshtastic ausgelegt ist. Anders als bei klassischen Entwicklungsboards sind Gehäuse, Display, Stromversorgung und Bedienelemente bereits integriert.

Dadurch kann man direkt mit ersten Tests starten, ohne vorher eine eigene Schaltung aufbauen zu müssen. Der ThinkNode M5 eignet sich daher besonders gut, um LoRa und Meshtastic praktisch auszuprobieren – zum Beispiel für Nachrichten, Reichweitentests oder einfache Mesh-Netzwerke.

Technische Daten des ThinkNode M5

Der ThinkNode M5 bringt bereits viele Komponenten mit, die man für erste LoRa- und Meshtastic-Projekte benötigt. Neben dem ESP32-S3 sind unter anderem ein LoRa-Modul, ein E-Paper-Display, GPS, ein Akku sowie mehrere Bedienelemente integriert.

BereichTechnische DatenHauptprozessorESP32-S3CPUXtensa 32-Bit LX7 Dual-Core, bis zu 240 MHzArbeitsspeicher512 KB SRAM, 8 MB PSRAMSpeicher4 MB Flash, 384 KB ROMFirmwarekompatibel mit Meshtastic, Signalübertragung per LoRaAnzeige1,54 Zoll (ca. 4 cm) E-Paper-Display, monochromAuflösung200 × 200 PixelDisplay-TreiberSSD1681Display-Aktualisierungca. 2 SekundenBluetoothBluetooth Low Energy, Bluetooth 5.0LoRa-ModulSX1262 LoRa-ModulFrequenzEU 868 MHz / US 915 MHzAntenneexterne Antenne über RP-SMA-AnschlussSchnittstellenUSB-C, RP-SMAStandortbestimmungGPS, GLONASS, BeiDou, QZSSWeitere FunktionenRTC, USB 2.0, PMU-Power-Management, BuzzerAkkuintegrierter 1200-mAh-Lithium-AkkuTasten/SchalterDrehschalter, Funktionstaste, Seitentaste, GPS-Schalter, Reset-TasteLED-AnzeigenStromversorgung, GPS-/LoRa-StatusStromversorgung5 V/1 A über USB oder AkkuStromverbrauchmax. ca. 340 mA, Low-Power ca. 34 µABetriebstemperatur–10 °C bis 50 °CLagertemperatur–20 °C bis 60 °CLuftfeuchtigkeit10 % bis 95 % bei 40 °C, nicht kondensierendAbmessungen82 × 51,6 × 26,3 mmGehäusematerialABS-KunststoffGewichtca. 81 g Abmessungen und erster Eindruck

Mit seinen Abmessungen von 82 × 51,6 × 26,3 mm ist der ThinkNode M5 angenehm kompakt und lässt sich problemlos in der Hand halten oder in einer Tasche transportieren. Auf meinen Fotos sieht man gut, dass das Gerät deutlich kleiner ausfällt, als man es anhand der integrierten Funktionen vielleicht erwarten würde.

Trotz der kompakten Bauform wirkt der ThinkNode M5 nicht wie ein einfaches Bastelboard, sondern eher wie ein fertiges kleines Kommunikationsgerät. Das Gehäuse schützt die Elektronik, die Antenne ist sauber herausgeführt und die Anzeige ist direkt auf der Vorderseite ablesbar.

Gerade für mobile LoRa- und Meshtastic-Tests ist das ein großer Vorteil. Man muss keine offene Schaltung mit Breadboard, Kabeln und separatem Akku mitnehmen, sondern kann das Gerät direkt verwenden.

Bedienelemente und Anschlüsse

Der ThinkNode M5 verfügt über mehrere Bedienelemente und Anschlüsse, die direkt am Gehäuse erreichbar sind. Dadurch lässt sich das Gerät nicht nur über die Meshtastic-App konfigurieren, sondern auch direkt am Gerät bedienen.

Die wichtigsten Bedienelemente und Anschlüsse des ThinkNode M5 sind direkt am Gehäuse erreichbar.

An der Oberseite befindet sich der Anschluss für die externe LoRa-Antenne. Diese sollte vor dem Einschalten montiert werden, da LoRa-Module grundsätzlich nicht ohne angeschlossene Antenne betrieben werden sollten. Ebenfalls vorhanden ist ein USB-C-Anschluss, über den der ThinkNode M5 geladen und mit dem Computer verbunden werden kann.

ThinkNode M5 - LoRa Antenne mit Dichtungsringe

ThinkNode M5 - LoRa Antenne mit Dichtungsringe - montiert

Zur Bedienung stehen mehrere Tasten und Schalter zur Verfügung. Dazu gehören unter anderem eine Funktionstaste, eine Taste zum Wechseln der Anzeige sowie ein separater Schalter für GPS. Über die Status-LEDs kann man außerdem erkennen, ob das Gerät mit Strom versorgt wird oder ob GPS bzw. LoRa aktiv sind.

In der Praxis gefällt mir dieser Aufbau ausgezeichnet, da alle wichtigen Elemente direkt zugänglich sind. Man muss das Gerät nicht öffnen oder zusätzliche Adapter verwenden, um es für erste Tests mit LoRa und Meshtastic einzusetzen.

Lieferumfang des ThinkNode M5

Der Lieferumfang des ThinkNode M5 ist übersichtlich, enthält aber alles, was für den ersten Start benötigt wird.

Im Lieferumfang enthalten sind:

- 1 × ThinkNode M5 - 1 × LoRa-Antenne - 2 × Dichtungsringe für den Antennenanschluss - 1 × Befestigungsring mit Lasche - 1 × zweiseitige Beschreibung - 1 × USB-C-Kabel zum Laden des Gerätes

Die LoRa-Antenne sollte vor der Inbetriebnahme aufgeschraubt werden. Über den Befestigungsring mit Lasche kann der ThinkNode M5 zum Beispiel an einem Schlüsselband, Karabiner oder einer Tasche befestigt werden.

Der Lieferumfang des ThinkNode M5 umfasst das Gerät, die LoRa-Antenne, ein USB-C-Kabel, Dichtungsringe, einen Befestigungsring und eine kurze Beschreibung.

Preis und Bezug

Der ThinkNode M5 ist direkt im Shop von Elecrow erhältlich. Zum Zeitpunkt meiner Recherche lag der Preis dort bei 53,90 US-Dollar. Wichtig ist dabei, auf die passende Frequenzvariante zu achten. Für Deutschland beziehungsweise Europa wird die 868-MHz-Version benötigt.

Der ThinkNode M5 ist im Elecrow-Shop erhältlich. Wichtig ist die Auswahl der passenden Frequenzversion.

Menü und Anzeige des ThinkNode M5

Der ThinkNode M5 zeigt viele wichtige Informationen direkt auf dem integrierten E-Paper-Display an. Dadurch kann man auch ohne dauerhaft geöffnete Meshtastic-App schnell prüfen, welchen Status das Gerät hat und welche Daten gerade verfügbar sind.

Durch das Menü wird direkt am Gerät navigiert. Mit der Funktionstaste auf der rechten Seite blättert man vorwärts durch die einzelnen Ansichten. Mit der Page-Taste kann man wieder zurück zur vorherigen Anzeige wechseln. Die Bedienung ist dadurch recht einfach gehalten und nach kurzer Zeit schnell verständlich.

Je nach Menüseite werden unterschiedliche Informationen angezeigt. Dazu gehören unter anderem der Startbildschirm mit Geräten in der Nähe, gefundene Satelliten und die eigene Meshtastic-ID, die aktuelle Uhrzeit, Systeminformationen, LoRa-Daten, GPS-Position sowie weitere Meshtastic-Informationen wie Bearings, Distance, Hops/Sig und Last Heard.

Für den ersten Praxistest habe ich außerdem eine Nachricht zwischen den Geräten gesendet. Diese erscheint im Kanal #LongFast direkt auf dem Display und zeigt damit schön, dass der ThinkNode M5 nicht nur Statusinformationen anzeigt, sondern auch empfangene Nachrichten sichtbar macht.

Auf dem Startbildschirm des ThinkNode M5 werden die wichtigsten Statusinformationen übersichtlich zusammengefasst. Dazu gehören der aktuelle Akkustand, die Uhrzeit, die Uptime des Gerätes sowie die Anzahl der Geräte, die in der Nähe online sind.

Zusätzlich zeigt das Display an, wie viele Satelliten für die GPS-Positionsbestimmung gefunden wurden. Ebenfalls wichtig ist die angezeigte Meshtastic-ID, über die das Gerät im Netzwerk eindeutig identifiziert werden kann.

Die zweite Anzeige zeigt die aktuelle Uhrzeit. Dabei sollte man beachten, dass das E-Paper-Display seinen letzten Bildinhalt auch dann beibehält, wenn das Gerät ausgeschaltet wird.

Das kann im ersten Moment etwas verwirrend sein, da weiterhin eine Uhrzeit auf dem Display zu sehen ist, obwohl der ThinkNode M5 bereits ausgeschaltet wurde. Erst beim nächsten Aktualisieren der Anzeige wird der Inhalt wieder geändert.

Auf der Anzeige System werden technische Informationen zum laufenden ESP32-S3 angezeigt. Dazu gehören unter anderem der freie Heap-Speicher, der Flash-Speicher, die Firmwareversion und die aktuelle Uptime des Gerätes. Zusätzlich wird der Status des verbundenen Clients dargestellt.

Für den normalen Einsatz sind diese Werte meist nicht dauerhaft wichtig. Besonders interessant ist jedoch die Firmwareversion, da man darüber prüfen kann, ob auf dem ThinkNode M5 noch eine aktuelle Meshtastic-Version läuft oder ob ein Update sinnvoll ist.

Deutlich wichtiger als die reinen Systeminformationen sind die LoRa-Informationen. Auf dieser Anzeige sieht man, mit welchem Frequenzbereich der ThinkNode M5 aktuell arbeitet.

In meinem Fall wird die europäische Frequenzvariante angezeigt. Das Gerät arbeitet also im Bereich um 868 MHz. Konkret wurde bei mir eine Frequenz von 869,525 MHz angezeigt.

Die Frequenz wird bei der ersten Einrichtung des Gerätes festgelegt. Wie das Setup durchgeführt wird, zeige ich im oben verlinkten YouTube-Video. Die Anzeige am ThinkNode M5 ist anschließend besonders praktisch, um die gewählte Frequenz direkt am Gerät zu kontrollieren.

Wenn der GPS-Schalter auf der rechten Seite auf ON gestellt ist, kann der ThinkNode M5 die aktuelle GPS-Position ermitteln. In meinem Test lag die Abweichung der angezeigten Position bei knapp 7 Metern, verglichen mit meiner Position in Google Maps.

Der separate GPS-Schalter ist dabei durchaus sinnvoll, denn das GPS-Modul belastet den integrierten 1200-mAh-Akku zusätzlich. Wer GPS nicht dauerhaft benötigt, kann es über den Schalter deaktivieren und so Energie sparen.

Gut gedacht ist auch die Kompassanzeige zur Nordausrichtung. In der Praxis ist diese Funktion mit einem E-Paper-Display jedoch etwas träge. Da das Display bei jeder Änderung neu aufgebaut werden muss, sieht man die neue Ausrichtung nicht sofort. Für eine dynamische Kompassanzeige wäre ein TFT- oder LCD-Display besser geeignet, da diese deutlich schneller aktualisieren können.

Für gelegentliche Positionsinformationen ist die GPS-Anzeige dennoch sehr nützlich. Als dauerhaft schneller Live-Kompass ist sie durch das E-Paper-Display aber nur eingeschränkt praktisch.

Unter Bearings werden Geräte in der Nähe nach ihrer Richtung beziehungsweise Ausrichtung aufgelistet. So kann man erkennen, in welcher Richtung sich andere Meshtastic-Teilnehmer ungefähr befinden.

Diese Ansicht ist besonders dann interessant, wenn mehrere Geräte im Netzwerk aktiv sind und man sich im Gelände orientieren möchte. Voraussetzung ist natürlich, dass die Geräte gültige Positionsdaten übertragen.

Noch interessanter als die Bearings-Ansicht ist für mich die Anzeige Distance. Hier wird die Entfernung zu Geräten in der Nähe angezeigt. Dadurch kann man direkt verfolgen, ob man sich einem anderen Meshtastic-Teilnehmer nähert oder sich weiter von ihm entfernt.

Gerade bei einem Test im Freien ist diese Ansicht sehr hilfreich, weil man sofort ein Gefühl dafür bekommt, wie sich die Entfernung zwischen den Geräten verändert.

Praktisch wäre an dieser Stelle eine kombinierte Ansicht aus Bearing und Distance. Dann hätte man sowohl die grobe Richtung als auch die Entfernung zum anderen Gerät direkt auf einer Seite im Blick.

In einem Mesh-Netzwerk kennt nicht jedes Gerät zwangsläufig jedes andere Gerät direkt. Stattdessen können Nachrichten über benachbarte Geräte weitergeleitet werden. Genau das macht Meshtastic so interessant: Geräte können als Zwischenstationen dienen und dadurch die Reichweite des Netzwerks erhöhen.

In der Anzeige Hops/Sig sieht man, über wie viele Sprünge beziehungsweise Zwischenstationen ein Gerät erreichbar ist und wie gut das empfangene Signal ist. Je weniger Hops benötigt werden, desto direkter ist die Verbindung. Die Signalwerte helfen zusätzlich dabei einzuschätzen, wie stabil die Verbindung zu einem anderen Gerät ist.

Diese Ansicht ist besonders hilfreich, wenn mehrere Geräte im Netzwerk aktiv sind und man nachvollziehen möchte, ob ein Teilnehmer direkt erreichbar ist oder ob die Verbindung über andere Knoten im Mesh-Netzwerk läuft.

Die Anzeige Last Heard listet die Geräte auf, mit denen der ThinkNode M5 zuletzt Daten ausgetauscht hat. Zusätzlich wird angezeigt, wie lange diese Kommunikation bereits zurückliegt, zum Beispiel in Minuten oder Stunden.

Das ist besonders praktisch, um schnell zu erkennen, welche Meshtastic-Geräte zuletzt im Netzwerk aktiv waren.

[draegerit]

Was ist LoRa? Vorteile, Einsatzgebiete und Geräte für den Einstieg

Nicht jedes Mikrocontroller- oder IoT-Projekt befindet sich direkt neben dem heimischen WLAN-Router. Gerade bei Sensoren im Garten, auf dem Feld, im Wald oder bei mobilen Anwendungen stößt WLAN schnell an seine Grenzen. Genau an dieser Stelle wird LoRa interessant: eine Funktechnik, mit der kleine Datenmengen über große Entfernungen und mit vergleichsweise geringem Energieverbrauch übertragen werden können.

Ich habe von der Firma Elecrow zweimal das ThinkNode M5 für ein Review erhalten. Bevor ich diese Geräte im Detail vorstelle und teste, möchte ich in diesem Beitrag zunächst die Grundlagen klären: Was ist LoRa eigentlich, wo liegen die Vorteile und für welche Projekte eignet sich diese Technik?

Außerdem werfe ich einen ersten Blick auf drei spannende LoRa-Geräte: den Arduino Nesso N1, das Heltec LoRa V3 und natürlich das ThinkNode M5 von Elecrow.

https://youtu.be/ZhlQJd7MZhE

Was ist LoRa?

LoRa steht für Long Range und beschreibt eine Funktechnik, mit der kleine Datenmengen über vergleichsweise große Entfernungen übertragen werden können. Technisch basiert LoRa auf einer Modulation, die von Chirp Spread Spectrum abgeleitet ist. Der große Vorteil: LoRa ist sehr robust gegenüber Störungen und eignet sich besonders für Anwendungen, bei denen nur wenige Daten übertragen werden müssen, dafür aber über größere Distanzen und mit wenig Energieverbrauch.

Das Schaubild zeigt vereinfacht, wie LoRa funktioniert: Sensoren senden kleine Datenmengen per Funk über große Entfernungen an ein Gateway oder einen Empfänger.

Wichtig ist dabei: LoRa ist nicht dasselbe wie WLAN oder Bluetooth. Während WLAN für hohe Datenraten im Heimnetz gedacht ist, geht es bei LoRa eher um kurze Nachrichten, Sensordaten, Statusmeldungen oder Positionsinformationen. Bilder, Videos oder große Datenmengen sind dafür nicht geeignet.

LoRa, LoRaWAN und Meshtastic – wo ist der Unterschied?

LoRaWAN ist vor allem spannend, wenn Sensoren ihre Daten über Gateways an einen Server oder eine Cloud senden sollen. Die LoRa Alliance beschreibt LoRaWAN als Low-Power-Wide-Area-Netzwerkprotokoll für batteriebetriebene Geräte, inklusive bidirektionaler Kommunikation, Sicherheit, Mobilität und Ortungsfunktionen.

Meshtastic geht in eine etwas andere Richtung. Hier bilden einzelne Geräte ein dezentrales Mesh-Netzwerk. Nachrichten können von Gerät zu Gerät weitergereicht werden, ohne dass Mobilfunk, WLAN oder Internet benötigt werden. Genau deshalb ist Meshtastic besonders interessant für Outdoor, Wandern, Camping, Notfallkommunikation oder Experimente mit eigener Funkinfrastruktur.

Das Schaubild zeigt die Unterschiede zwischen LoRa, LoRaWAN und Meshtastic auf einen Blick. Während LoRa die eigentliche Funktechnik ist, beschreibt LoRaWAN ein Netzwerkprotokoll für IoT-Anwendungen und Meshtastic ein Mesh-Netzwerk für direkte Kommunikation über LoRa. BegriffBedeutungLoRaDie eigentliche Funktechnik für die drahtlose Übertragung kleiner Datenpakete.LoRaWANEin Netzwerkprotokoll auf Basis von LoRa, häufig für Sensoren, Gateways und IoT-Plattformen genutzt.MeshtasticEine Open-Source-Firmware, mit der LoRa-Geräte ein unabhängiges Mesh-Netzwerk bilden können.

Wo liegt der Vorteil von LoRa?

Der größte Vorteil von LoRa liegt in der Kombination aus Reichweite, geringem Energieverbrauch und einfacher Datenübertragung. Für viele Mikrocontroller- und IoT-Projekte reicht es völlig aus, alle paar Minuten einen Messwert zu übertragen. Genau hier spielt LoRa seine Stärke aus.

Typische Vorteile sind:

VorteilErklärungHohe ReichweiteJe nach Umgebung sind deutlich größere Distanzen als bei WLAN oder Bluetooth möglich.Geringer EnergieverbrauchIdeal für Sensoren, die mit Akku oder Batterie betrieben werden.Kein WLAN nötigGeräte können auch dort kommunizieren, wo kein Heimnetz vorhanden ist.Gute Outdoor-EignungBesonders interessant für Garten, Feld, Wald, Camping oder Tracking.Mesh möglichMit Meshtastic können Geräte Nachrichten über andere Geräte weiterreichen.Perfekt für kleine DatenmengenSensorwerte, Textnachrichten, GPS-Positionen oder Statusmeldungen passen sehr gut.

LoRa ist also keine Alternative zu WLAN, sondern eine Ergänzung für Projekte, bei denen Reichweite und Energieverbrauch wichtiger sind als Geschwindigkeit.

Typische Einsatzgebiete

LoRa eignet sich besonders für Projekte wie:

- Wetterstationen im Garten oder auf dem Feld - Bodenfeuchte- und Umweltsensoren - Pegelstand- oder Zisternenüberwachung - GPS-Tracking - einfache Textkommunikation über Meshtastic - Notfallkommunikation ohne Mobilfunk - Smart-Farming-Projekte - Sensoren an Orten ohne WLAN-Abdeckung

Gerade für Maker, Bastler und Mikrocontroller-Projekte ist LoRa spannend, weil man damit Geräte vernetzen kann, ohne direkt auf WLAN, Router oder Cloud-Dienste angewiesen zu sein.

Drei spannende LoRa-Geräte im Überblick

Für den Einstieg möchte ich drei Geräte kurz vorstellen: den Arduino Nesso N1, das Heltec WiFi LoRa 32 V3 und das Elecrow ThinkNode M5.

GerätKurzbeschreibungBesonderheitArduino Nesso N1Kompaktes All-in-One-Board mit ESP32-C6, LoRa, Wi-Fi 6, Bluetooth LE 5.3, Thread/Zigbee, Touchdisplay, IMU und Akku.Sehr vielseitig für IoT-Projekte und Prototypen.Heltec WiFi LoRa 32 V3Entwicklerboard mit ESP32-S3, SX1262-LoRa-Chip, WLAN, Bluetooth, OLED-Display, USB-C und Batteriemanagement.Sehr beliebt für eigene LoRa-, LoRaWAN- und Meshtastic-Projekte.Elecrow ThinkNode M5Fertiges Meshtastic-Gerät mit ESP32-S3, SX1262, GPS, 1,54-Zoll-E-Paper-Display, 1200-mAh-Akku und Gehäuse.Direkt einsatznah für Meshtastic, Outdoor und mobile Kommunikation.

Arduino Nesso N1 – kompakter Allrounder

Der Arduino Nesso N1 ist weniger ein reines LoRa-Modul, sondern eher ein kompaktes IoT-Entwicklungsgerät. Neben LoRa bringt es auch Wi-Fi 6, Bluetooth LE 5.3 sowie Thread/Zigbee mit. Dazu kommen ein 1,14-Zoll-Farb-Touchdisplay, ein 6-Achsen-IMU-Sensor, programmierbare Tasten, Akku und Erweiterungsmöglichkeiten über Grove, Qwiic und HAT-Anschlüsse.

Arduino Nesso N1

Arduino Nesso N1 - zwei frei programmierbare Taster

Arduino Nesso N1 - Qwiic Schnittstelle & ON/OFF/RESET Taster

Arduino Nesso N1 - Rückseite

Arduino Nesso N1 - freie GPIOs via Buchsenleiste

Damit eignet sich das Board besonders für Projekte, bei denen mehrere Funktechniken ausprobiert oder kombiniert werden sollen.

Heltec WiFi LoRa 32 V3 – der bekannte Maker-Klassiker

Das Heltec WiFi LoRa 32 V3 ist ein sehr beliebtes Entwicklerboard für LoRa-Projekte. Es kombiniert einen ESP32-S3 mit einem SX1262-LoRa-Chip, WLAN, Bluetooth, einem kleinen OLED-Display und USB-C. Zusätzlich ist ein Batteriemanagement integriert, wodurch sich das Board auch für mobile Experimente eignet.

Mikrocontroller Heltec LoRa 32 V3

Mikrocontroller Heltec LoRa 32 V3 von oben

Mikrocontroller Heltec LoRa 32 V3 von hinten - IPEX Anschluss

Mikrocontroller Heltec LoRa 32 V3 von unten

Mikrocontroller Heltec LoRa 32 V3 von vorne

Für Bastler ist das Heltec-Board interessant, weil man damit sehr flexibel eigene Programme schreiben kann. Es eignet sich also gut, wenn man LoRa nicht nur benutzen, sondern auch technisch verstehen und selbst programmieren möchte.

Elecrow ThinkNode M5 – fertig für Meshtastic

Das ThinkNode M5 von Elecrow ist dagegen deutlich näher an einem fertigen Gerät. Es kommt mit Meshtastic-Firmware, besitzt ein 1,54-Zoll-E-Paper-Display, GPS, Akku, Gehäuse und eine externe LoRa-Antenne. Laut Elecrow ist es mit der Meshtastic-App kompatibel und kann darüber konfiguriert, überwacht und für Nachrichten sowie Standortfunktionen genutzt werden.

ThinkNode M5 - GPS Position

ThinkNode M5 - Funktionstasten

ThinkNode M5 - Uhrzeit

ThinkNode M5 - USB-C Schnittstelle

Damit ist das ThinkNode M5 besonders spannend, wenn man nicht erst ein Entwicklerboard verkabeln und flashen möchte, sondern direkt mit Meshtastic starten will.

Transparenzhinweis: Das hier gezeigte ThinkNode M5 wurde mir von der Firma Elecrow kostenlos für ein Review zur Verfügung gestellt. Vorgaben zum Inhalt dieses Beitrags gab es nicht.

Laut Elecrow ist das ThinkNode M5 mit der Meshtastic-App kompatibel und kann darüber konfiguriert, überwacht und für Nachrichten sowie Standortfunktionen genutzt werden.

Häufige Fragen zu LoRa

Was ist LoRa, einfach erklärt?

LoRa ist eine Funktechnik, mit der kleine Datenmengen über große Entfernungen übertragen werden können. Sie eignet sich besonders für Sensoren, Mikrocontroller-Projekte und IoT-Anwendungen mit geringem Energieverbrauch.

Was ist der Unterschied zwischen LoRa und LoRaWAN?

LoRa beschreibt die eigentliche Funktechnik. LoRaWAN ist ein Netzwerkprotokoll, das LoRa nutzt, um Geräte über Gateways und Netzwerkserver mit IoT-Plattformen zu verbinden.

Was ist Meshtastic?

Meshtastic ist eine Open-Source-Firmware für LoRa‑Geräte. Damit können mehrere Geräte ein Mesh-Netzwerk bilden und Nachrichten auch ohne WLAN, Mobilfunk oder Internet weiterleiten.

Kann LoRa WLAN ersetzen?

Nein, LoRa ersetzt WLAN nicht. WLAN ist für hohe Datenraten gedacht, LoRa dagegen für kleine Datenmengen über größere Entfernungen.

Welche LoRa-Frequenz benötige ich in Deutschland?

Für Deutschland und Europa sollte man beim Kauf auf Geräte mit EU868-Unterstützung achten.

Kann ich mit LoRa Bilder oder Videos übertragen?

Nein, dafür ist LoRa nicht geeignet. Die Technik ist für kleine Datenpakete wie Sensorwerte, Statusmeldungen, Textnachrichten oder GPS-Positionen gedacht.

Fazit

LoRa ist besonders dann interessant, wenn kleine Datenmengen über größere Distanzen übertragen werden sollen. Für klassische WLAN-Projekte im Haus ist LoRa meist nicht notwendig. Sobald es aber um Outdoor-Sensoren, mobile Geräte, lange Akkulaufzeit oder Kommunikation ohne vorhandenes Netzwerk geht, wird LoRa richtig spannend.

Für Entwickler und Bastler ist das Heltec WiFi LoRa 32 V3 ein guter Einstieg in eigene Experimente. Der Arduino Nesso N1 ist ein vielseitiger Allrounder für moderne IoT-Projekte. Das Elecrow ThinkNode M5 ist dagegen besonders spannend, wenn man direkt mit Meshtastic und mobiler LoRa-Kommunikation starten möchte.

Im nächsten Beitrag schaue ich mir das ThinkNode M5 dann genauer an und teste, wie gut sich die beiden Geräte in der Praxis einsetzen lassen.

[draegerit]

Node-RED SD-Karte schonen: Persistent Context richtig nutzen

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.

Der Flow empfängt einen Sensorwert per MQTT und speichert ihn gezielt im RAM, auf der SD-Karte oder auf einem USB-Stick. Flow JSON für MQTT-Sensorwert und Context Stores anzeigen , "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "sensor/wohnzimmer/temperatur", "payload": "", "payloadType": "date", "x": 180, "y": 80, "wires": ] }, { "id": "a8d74225924844ad", "type": "function", "z": "b9a1e07bb447b3d1", "name": "Zufallswert 10 bis 30 °C", "func": "let zufallswert = Math.random() * (30 - 10) + 10;nzufallswert = Number(zufallswert.toFixed(2));nnmsg.payload = zufallswert;nmsg.topic = "sensor/wohnzimmer/temperatur";nnreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 450, "y": 80, "wires": ] }, { "id": "c6b41cbdf945d245", "type": "mqtt out", "z": "b9a1e07bb447b3d1", "name": "MQTT Sensorwert senden", "topic": "", "qos": "", "retain": "", "respTopic": "", "contentType": "", "userProps": "", "correl": "", "expiry": "", "broker": "ec3f5f670a624e22", "x": 730, "y": 80, "wires": }, { "id": "f75bfa1a756fa168", "type": "mqtt in", "z": "b9a1e07bb447b3d1", "name": "MQTT Sensorwert empfangen", "topic": "sensor/wohnzimmer/temperatur", "qos": "0", "datatype": "auto-detect", "broker": "ec3f5f670a624e22", "nl": false, "rap": true, "rh": 0, "inputs": 0, "x": 190, "y": 180, "wires": ] }, { "id": "d49a39e499a62e39", "type": "function", "z": "b9a1e07bb447b3d1", "name": "Sensorwert aufbereiten", "func": "let sensorwert = Number(msg.payload);nnlet zeitstempel = new Date().toLocaleString("de-DE", {n timeZone: "Europe/Berlin",n day: "2-digit",n month: "2-digit",n year: "numeric",n hour: "2-digit",n minute: "2-digit",n second: "2-digit"n});nnmsg.payload = {n sensor: "Wohnzimmer",n typ: "Temperatur",n wert: sensorwert,n einheit: "°C",n zeitstempel: zeitstempeln};nnreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 470, "y": 180, "wires": ] }, { "id": "d127437b75dc028f", "type": "function", "z": "b9a1e07bb447b3d1", "name": "Speichern im RAM", "func": "flow.set("temperaturAktuell", msg.payload, "memoryOnly");nnmsg.payload = {n speicher: "memoryOnly / RAM",n hinweis: "Wert wird nur im Arbeitsspeicher gespeichert und ist nach Neustart weg.",n daten: msg.payloadn};nnreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 760, "y": 140, "wires": ] }, { "id": "aa4f11d9d23c2966", "type": "function", "z": "b9a1e07bb447b3d1", "name": "Speichern auf SD-Karte", "func": "let letzterWert = flow.get("temperaturLetzteSD", "sdcard");nlet geaendert = !letzterWert || letzterWert.wert !== msg.payload.wert;nnif (geaendert) {n flow.set("temperaturLetzteSD", msg.payload, "sdcard");n}nnmsg.payload = {n speicher: "sdcard / localfilesystem",n hinweis: "Wird persistent auf der SD-Karte gespeichert. Durch flushInterval 180 aber nicht sofort bei jeder Änderung auf die Karte geschrieben.",n gespeichert: geaendert,n vorherigerWert: letzterWert ? letzterWert.wert : null,n daten: msg.payloadn};nnreturn msg;", "outputs": 1, "timeout": 0, "noerr": 0, "initialize": "", "finalize": "", "libs": , "x": 780, "y": 200, "wires": ] }, { "id": "cefc0e1283c6127a", "type": "function", "z": "b9a1e07bb447b3d1", "name": "Speichern auf USB-Stick", "func": "flow.set("temperaturLetzteUSB", msg.payload, "usbstick");nnmsg.payload = {n speicher: "usbstick / localfilesystem",n hinweis: "Wird persistent auf dem USB-Stick gespeichert.

[draegerit]

Node-RED Context nach Neustart behalten – so geht’s

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.

Für große Datenmengen oder Messwertverläufe bleibt eine Datenbank aber weiterhin die bessere Lösung.

[draegerit]

Node-RED Context erklärt: Werte speichern ohne Datenbank

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.

Im Reiter Contextdaten zeigt Node-RED gespeicherte Werte aus dem Flow Context und Global Context an. So lässt sich prüfen, ob Werte korrekt gespeichert wurden.

[draegerit]

Home Assistant einrichten: Die ersten Schritte nach der Installation

Im letzten Beitrag „Home Assistant unter Fedora Linux installieren – Schritt für Schritt mit Docker Compose“ habe ich gezeigt, wie du Home Assistant auf einem Mini-PC wie dem Dell OptiPlex 3050 installierst. Dabei läuft Home Assistant nicht direkt auf dem System, sondern sauber gekapselt in einem Docker-Container, der über Docker Compose verwaltet wird.

Nach der erfolgreichen Installation ist Home Assistant zwar bereits über den Browser erreichbar, wirklich eingerichtet ist das Smart-Home-System damit aber noch nicht. Genau hier knüpfen wir in diesem Beitrag an.

Ich zeige dir Schritt für Schritt, was nach der ersten Installation passiert: vom ersten Aufruf der Home-Assistant-Oberfläche über das Anlegen des Benutzerkontos bis hin zu den grundlegenden Einstellungen wie Standort, Sprache, Zeitzone und ersten erkannten Geräten im Netzwerk.

Ziel dieses Beitrags ist es, aus der frisch installierten Home-Assistant-Instanz eine sauber vorbereitete Smart-Home-Zentrale zu machen, auf der wir in den nächsten Beiträgen weiter aufbauen können.

https://youtu.be/RDAbk7bvdq4

Testinstanz für diesen Beitrag

Für diesen Beitrag habe ich mir bewusst eine separate Home-Assistant-Instanz in einem eigenen Docker-Container erstellt. Das ist einer der großen Vorteile, wenn man Home Assistant mit Docker Compose betreibt.

Anstatt mein eigentliches Smart-Home-System zurückzusetzen oder daran herumzutesten, kann ich einfach eine zusätzliche Testumgebung starten. Diese Testinstanz läuft unabhängig von meiner produktiven Home-Assistant-Installation und eignet sich perfekt, um die ersten Einrichtungsschritte sauber zu dokumentieren.

Der Vorteil liegt auf der Hand: Ich kann Home Assistant frisch starten, die komplette Ersteinrichtung durchgehen, Screenshots erstellen und bei Bedarf alles wieder löschen oder neu aufsetzen. Mein eigentliches Smart Home bleibt dabei unangetastet.

Gerade für Tutorials, Tests oder neue Integrationen ist das sehr praktisch. Wenn etwas nicht funktioniert oder man eine Einstellung ausprobieren möchte, setzt man einfach die Testinstanz zurück, anstatt am laufenden System Änderungen vorzunehmen.

Ein weiterer Vorteil ist, dass sich solche Testumgebungen mit Docker Compose sehr schnell erstellen lassen. Man benötigt lediglich einen eigenen Container-Namen, einen eigenen Port und ein separates Konfigurationsverzeichnis. Dadurch können produktive Instanz und Testinstanz sauber nebeneinander laufen.

Docker Compose: Testinstanz für Home Assistant erstellen

Für meine Testinstanz verwende ich eine eigene compose.yml-Datei. Wichtig ist dabei vor allem, dass ein anderer Container-Name, ein separates Konfigurationsverzeichnis und ein anderer externer Port verwendet werden.

services: homeassistant-test: container_name: homeassistant-test image: ghcr.io/home-assistant/home-assistant:stable volumes: - /opt/homeassistant-test/config:/config - /etc/localtime:/etc/localtime:ro environment: TZ: Europe/Berlin restart: unless-stopped ports: - "8124:8123"

erstellen einer Testinstanz für Home Assistant

Meine Testinstanz läuft nicht auf dem Standard-Port 8123, sondern auf 8124. Damit erreiche ich sie in meinem Netzwerk unter:

http://192.168.178.186:8124

Meine produktive Home-Assistant-Instanz bleibt davon getrennt. So kann ich in Ruhe herumspielen, Einstellungen testen und bei Bedarf die Testinstanz einfach wieder zurücksetzen, ohne mein echtes Smart Home zu gefährden.

Home Assistant im Browser öffnen

Nachdem die Testinstanz gestartet wurde, kann Home Assistant im Browser geöffnet werden. Dazu rufe ich die IP-Adresse meines Mini-PCs zusammen mit dem zuvor festgelegten Port auf.

Home Assistant erster start nach der Einrichtung im Docker Container

In meinem Fall lautet die Adresse:

http://192.168.178.186:8124

Beim ersten Aufruf begrüßt uns Home Assistant direkt mit der Ersteinrichtung. An dieser Stelle gibt es grundsätzlich mehrere Möglichkeiten, wie es weitergehen kann.

Home Assistant - Möglichkeiten der Wiederherstellung von Instanzen beim ersten Start

Zum einen kann ein vorhandenes Backup wiederhergestellt werden. Das ist besonders praktisch, wenn man bereits eine bestehende Home-Assistant-Installation hatte und diese auf ein neues System übertragen möchte.

Zusätzlich besteht die Möglichkeit, ein Backup aus der Home-Assistant-Cloud zu verwenden, sofern diese Funktion zuvor eingerichtet wurde.

Die dritte Option ist der komplette Neuaufbau eines frischen Systems. Genau diesen Weg gehen wir in diesem Beitrag, denn ich möchte die Einrichtung Schritt für Schritt an einer neuen und leeren Home-Assistant-Instanz zeigen.

Neues Home-Assistant-System erstellen

Da ich für diesen Beitrag bewusst mit einer frischen Testinstanz arbeite, wähle ich an dieser Stelle die Option zum Erstellen eines neuen Home-Assistant-Systems. Damit starten wir komplett leer und können die Einrichtung Schritt für Schritt durchgehen.

Das ist besonders praktisch, weil Home Assistant nun genau so eingerichtet wird, wie es auch bei einer neuen Installation der Fall wäre. Es gibt noch keine vorhandenen Geräte, Benutzer, Automatisierungen oder Dashboards. Dadurch lässt sich sehr gut zeigen, welche Schritte nach der Installation notwendig sind.

Benutzerkonto anlegen

Im ersten Schritt wird ein Benutzerkonto erstellt. Dieses Konto wird später für die Anmeldung an Home Assistant verwendet und besitzt die notwendigen Rechte, um das System einzurichten und zu verwalten.

Hier werden folgende Angaben benötigt:

- Name - Benutzername - Passwort

Beim Passwort sollte man nicht zu einfach denken. Über diesen Zugang wird später das komplette Smart Home verwaltet. Ich empfehle daher ein sicheres Passwort und idealerweise die Speicherung in einem Passwortmanager.

Nach dem Ausfüllen der Felder wird das Benutzerkonto erstellt und die Einrichtung fortgesetzt.

Home Assistant - erster Start - einrichten des Benutzers

Home Assistant - erster Start - Standort einrichten Standort des Zuhauses festlegen

Im nächsten Schritt fragt Home Assistant nach dem Standort des Zuhauses. Diese Einstellung ist wichtiger, als sie auf den ersten Blick wirkt.

Home Assistant nutzt den Standort unter anderem für die Zeitzone, Sonnenaufgang und Sonnenuntergang sowie spätere Automatisierungen. Ein typisches Beispiel wäre eine Automation wie:

Wenn die Sonne untergeht, schalte die Außenbeleuchtung ein.

Damit solche Funktionen korrekt arbeiten, sollte der Standort möglichst passend gesetzt werden.

Analyse- und Diagnoseinformationen

Während der Einrichtung fragt Home Assistant außerdem, ob Analyse- und Diagnoseinformationen geteilt werden dürfen. Diese Daten können dabei helfen, Home Assistant weiterzuentwickeln und Fehler besser zu erkennen.

Ob man diese Optionen aktiviert, ist eine persönliche Entscheidung. Für meine Testinstanz ist das weniger kritisch, bei einem produktiven System sollte man sich die einzelnen Punkte aber bewusst anschauen und dann entscheiden.

Home Assistant - erster Start - Informationen senden

Home Assistant - erster Start - Fertig

Damit ist die Konfiguration abgeschlossen und wir können über die Schaltfläche "Fertig" zum Dashboard gelangen. In den meisten Fällen wird das SmartHome gescannt und bereits erkannte Geräte aufgelistet.

Entdeckte Geräte im Home Assistant nach der Einrichtung

Erstes Gerät hinzufügen

Als erstes Beispiel eignet sich ein Shelly-Gerät sehr gut. Viele Shelly-Geräte werden von Home Assistant automatisch im Netzwerk erkannt, sobald sie sich im gleichen Netzwerk befinden.

Zusammenfassung mit Menüeintrag "Entdeckte Geräte"

Wird ein Shelly-Gerät gefunden, kann es direkt über die Home-Assistant-Oberfläche eingerichtet werden. Dabei wird die passende Integration hinzugefügt und das Gerät anschließend in Home Assistant verfügbar gemacht.

erkannte Shelly Geräte im Netzwerk Schritt 1: Dialog „Entdeckte Geräte“ öffnen

Nach der Einrichtung zeigt Home Assistant auf der rechten Seite den Bereich „Entdeckte Geräte“ an. Darunter wird direkt angezeigt, wie viele Geräte oder Integrationen im Netzwerk automatisch gefunden wurden.

Über diesen Eintrag gelangst du zu einer Übersicht der Geräte, die Home Assistant bereits erkannt hat und die nun eingerichtet werden können.

Wird dieser Menüpunkt bei dir nicht angezeigt, wurde vermutlich kein Gerät automatisch erkannt. Das ist aber kein Problem. In diesem Fall kann das Gerät später manuell über die Konfiguration hinzugefügt werden. Je nach Gerät oder Integration wird dafür zum Beispiel der passende Integrationstyp und die IP-Adresse benötigt. Darauf gehe ich weiter unten noch genauer ein.

Schritt 2 - Gerät aus der Liste auswählen

Für dieses Beispiel richte ich einen Shelly H&T Gen3 ein, der bei mir in der Wohnstube steht. Der Sensor misst Temperatur und Luftfeuchtigkeit und eignet sich daher sehr gut als erstes Beispiel für einen Sensor in Home Assistant.

Beim Einrichten fällt direkt auf, dass Home Assistant hier nicht den Namen übernimmt, den ich zuvor in der Shelly Cloud vergeben habe. Stattdessen wird zunächst nur eine technische Typenbezeichnung bzw. Gerätekennung angezeigt.

Eintrag - Shelly H&T im Home Assistant unter "Entdeckte Geräte"

Name des Gerätes in der Shelly Cloud

Das ist nicht weiter schlimm, sollte aber erwähnt werden. Gerade wenn mehrere Shelly-Geräte im Netzwerk vorhanden sind, kann es sonst schnell unübersichtlich werden. Die eigentliche Bezeichnung und die Zuordnung zum passenden Raum können später in Home Assistant angepasst werden.

Der Shelly H&T verfügt über ein ePaper Display welches in einem Intervall aktualisiert wird und dieses Gerät dann in den Deep Sleep verfällt, daher kann es passieren das dieses Gerät mal nicht gefunden wird, hier hilft ein neustart über die Shelly Cloud oder direkt am Gerät.

Schritt 3 - Gerätedetails prüfen

Im ersten Dialog zeigt Home Assistant die wichtigsten Informationen zum gefundenen Gerät an. Dazu gehören der erkannte Gerätetyp sowie die IP-Adresse, unter der das Gerät im Netzwerk erreichbar ist.

In meinem Fall handelt es sich um den Shelly H&T Gen3. Zusätzlich wird die IP-Adresse des Sensors angezeigt. Das ist besonders hilfreich, wenn mehrere Geräte im Netzwerk vorhanden sind oder man später prüfen möchte, welches Gerät tatsächlich eingebunden wurde.

Einrichten des Shelly H&T im Home Assistant Name und IP-Adresse prüfen - Hinweis auf Batteriebetriebene Geräte

Außerdem weist Home Assistant darauf hin, dass es sich bei batteriebetriebenen Geräten etwas anders verhalten kann als bei dauerhaft mit Strom versorgten Geräten. Solche Geräte sind nicht permanent aktiv, sondern wechseln häufig in einen stromsparenden Modus. Dadurch kann es sein, dass die Einrichtung oder Aktualisierung der Werte nicht sofort erfolgt.

Bei einem batteriebetriebenen Sensor sollte man daher etwas Geduld mitbringen oder das Gerät bei Bedarf kurz aufwecken, sofern dies vom jeweiligen Gerät unterstützt wird. Danach kann die Einrichtung fortgesetzt werden.

Schritt 4 - Name und Bereich zuordnen

Im nächsten Schritt wird das Gerät einem Bereich zugeordnet und ein passender Name vergeben. Ein Bereich entspricht in Home Assistant in der Regel einem Raum, also zum Beispiel Wohnzimmer, Küche, Büro, Flur oder Badezimmer.

Da mein Shelly H&T Gen3 in der Wohnstube steht, ordne ich das Gerät entsprechend diesem Bereich zu.

Dialog - Benennen und zuordnen #1

Dialog - Benennen und zuordnen - gesetzer Name und zu einem Raum zugeordnet

Besonders wichtig ist hier die Namensvergabe. Wenn später mehrere gleichartige Geräte eingebunden werden, kann es sonst schnell unübersichtlich werden. Statt nur den automatisch vorgeschlagenen Namen zu übernehmen, empfiehlt es sich, direkt einen sprechenden Namen zu verwenden.

Ein sinnvoller Name wäre zum Beispiel:

Wohnstube Temperatur & Luftfeuchtigkeit

oder etwas kürzer:

Shelly H&T Wohnstube

So lässt sich das Gerät später im Dashboard, in Automatisierungen und in der Geräteübersicht deutlich einfacher wiederfinden.

Gerade bei mehreren Sensoren vom gleichen Typ ist eine klare Benennung sehr hilfreich. Ein Name wie Shelly H&T Wohnstube ist deutlich aussagekräftiger als eine technische Gerätekennung oder eine automatisch erzeugte Bezeichnung.

Schritt 5 - aktuelle Messwerte des Shelly H&T anzeigen

Das Geräte wurde in meinem Fall in den Bereich "Wohnzimmer" eingerichtet und zeigt dort die aktuellen Messwerte für Temperatur & Luftfeuchtigkeit an.

Shelly H& mit messwerten im Home Assistant

Fazit

Damit ist Home Assistant nicht nur installiert, sondern auch grundlegend eingerichtet. Wir haben eine frische Testinstanz gestartet, den ersten Benutzer angelegt, den Standort festgelegt und anschließend ein erstes Gerät eingebunden.

Am Beispiel des Shelly H&T Gen3 sieht man sehr gut, wie Home Assistant automatisch Geräte im Netzwerk erkennt und daraus nutzbare Sensorwerte macht. Nach der Einrichtung stehen Temperatur und Luftfeuchtigkeit direkt in Home Assistant zur Verfügung und können später im Dashboard angezeigt oder für Automatisierungen verwendet werden.

Wichtig ist dabei vor allem eine saubere Struktur von Anfang an. Geräte sollten passend benannt und direkt einem Bereich zugeordnet werden. Das sorgt später für deutlich mehr Übersicht, besonders wenn immer mehr Sensoren, Aktoren und Integrationen hinzukommen.

Im nächsten Beitrag schauen wir uns dann die Automatisierungen in Home Assistant an. Dabei geht es darum, wie Sensorwerte und Gerätezustände genutzt werden können, um automatisch Aktionen auszulösen – zum Beispiel eine Lampe einzuschalten, wenn Bewegung erkannt wird, oder Geräte abhängig von bestimmten Bedingungen zu steuern.

[draegerit]

Lauflicht ohne Mikrocontroller: CD4017BE einfach erklärt

Ein LED-Lauflicht muss nicht immer mit einem Arduino, ESP32 oder einem anderen Mikrocontroller aufgebaut werden. Gerade für einfache Lötprojekte, Workshops oder den Einstieg in klassische Elektronik kann es sogar spannender sein, wenn der Effekt komplett ohne Programmierung entsteht.

In diesem Beitrag zeige ich dir eine kleine Lauflicht-Schaltung mit dem CD4017BE Dekadenzähler. Der besondere Punkt: Der Takt kommt hier nicht von einem NE555-Timer oder einem Mikrocontroller, sondern von einer blinkenden LED. Diese gibt den Takt zwar fest vor und ist dadurch nicht so flexibel wie eine Lösung mit Drehpoti, macht aber genau das, was für ein einfaches Lauflicht benötigt wird.

https://youtu.be/QjI1vaLdGUI

Die Grundidee zu dieser Schaltung stammt vom Elektor Magazin aus dem Beitrag „Kleine Schaltungen: Mini-Weihnachtsbaum – Folge 50“. Dort wurde die Schaltung als kleiner LED-Weihnachtsbaum umgesetzt. Die Idee mit der Blink-LED als Taktgeber für den 4017 fand ich so einfach wie genial, dass ich sie hier aufgreife und Schritt für Schritt für ein eigenes Lauflicht-Projekt erkläre. Props gehen an dieser Stelle also ganz klar an Elektor raus!

Warum ohne Mikrocontroller?

Auf diesem Blog dreht sich eigentlich sehr viel um Mikrocontroller wie Arduino, ESP32, Raspberry Pi Pico & Co. Für viele Projekte sind diese kleinen Boards perfekt, weil sie flexibel programmierbar sind und unzählige Möglichkeiten bieten. Es gibt aber auch Aufgaben, bei denen ein Mikrocontroller schlichtweg übertrieben wäre.

Ein einfaches LED-Lauflicht ist dafür ein verständliches Beispiel. Hier muss nicht unbedingt ein ESP32 gestartet, programmiert und mit Code versorgt werden. Ein passender IC reicht vollkommen aus, um den gewünschten Effekt zu erzeugen. Genau das macht dieses Projekt so interessant: Die Schaltung bleibt übersichtlich, funktioniert ohne Software und zeigt wunderbar, wie klassische Elektronik arbeitet.

Mit diesem kleinen Projekt möchte ich zugleich eine neue Reihe starten, in der ich zeige, dass nicht immer ein Mikrocontroller die Steuerung übernehmen muss. Manchmal reichen wenige Bauteile und ein clever eingesetzter IC völlig aus.

Das eigentliche Projekt wird später noch weitergeführt und zu einem kleinen Lötevent im örtlichen JFZ umgesetzt. Dazu gibt es dann aber einen separaten Beitrag.

Der Weg zur passenden Schaltung

Die Idee für dieses Projekt ist nicht einfach aus dem Nichts entstanden. Ich war tatsächlich längere Zeit auf der Suche nach einer möglichst einfachen Möglichkeit, ein LED-Lauflicht ohne Mikrocontroller aufzubauen. Dabei bin ich über viele klassische Schaltungen gestolpert, häufig mit einem NE555-Timer, einem Drehpoti zur Geschwindigkeitseinstellung und dem CD4017 als Zählerbaustein.

Diese Schaltungen funktionieren natürlich und sind technisch auch absolut sinnvoll. Für meinen Einstieg und vor allem für ein späteres Lötprojekt im JFZ war mir der Aufbau zunächst aber etwas zu umfangreich. Ein NE555, zusätzliche Widerstände, Kondensatoren, ein Poti zur Einstellung der Blinkfrequenz – das alles erhöht die Komplexität, obwohl ich eigentlich nur ein einfaches Lauflicht erzeugen wollte.

Mein Gedanke war daher ziemlich schnell: Das muss doch auch einfacher gehen.

Selbst die KI konnte mir an dieser Stelle nicht wirklich die einfache Lösung liefern, nach der ich gesucht habe. Fündig geworden bin ich dann ganz klassisch beim Stöbern auf dem Sofa mit dem Handy. Dabei bin ich auf den Elektor-Beitrag „Kleine Schaltungen: Mini-Weihnachtsbaum – Folge 50“ gestoßen. Genau dort wurde eine Idee verwendet, die ich sofort spannend fand: Eine 5-mm-Blink-LED dient als Taktgeber für den CD4017.

Damit entfällt der komplette Aufbau rund um den NE555-Timer. Die Blink-LED gibt einfach ihren festen Takt vor und der CD4017 schaltet seine Ausgänge entsprechend weiter. Der Aufbau ist dadurch deutlich übersichtlicher, schneller verständlich und ideal für den Einstieg – auch für mich.

Der CD4017BE Dekadenzähler

Das Herzstück der Schaltung ist der CD4017BE. Dabei handelt es sich um einen sogenannten Dekadenzähler, also einen Zählerbaustein, der seine Ausgänge nacheinander durchschaltet. Der IC zählt intern von 0 bis 9 und aktiviert dabei jeweils einen seiner zehn Ausgänge. Genau dieses Verhalten macht ihn ideal für ein LED-Lauflicht.

Der CD4017BE ist als klassischer DIP16-IC erhältlich und lässt sich dadurch sehr gut auf dem Breadboard oder später auf einer Lochrasterplatine bzw. eigenen Platine verwenden. Für Einsteiger ist das besonders praktisch, da der Baustein groß genug ist, um ihn gut einsetzen und verdrahten zu können.

Pinbelegung des Dekadenzählers CD4017BE

Laut Datenblatt arbeitet der CD4017 in einem recht breiten Spannungsbereich von 3 V bis 15 V. Damit eignet er sich sowohl für kleine Batterieschaltungen als auch für typische 5-V-Projekte. Für mein Lauflicht ist das ideal, da die Schaltung ohne Mikrocontroller auskommt und trotzdem mit wenigen Bauteilen zuverlässig funktioniert.

Ein paar wichtige technische Daten aus dem Datenblatt:

EigenschaftWertVersorgungsspannung3 V bis 15 VBauformDIP16Typische Geschwindigkeitbis ca. 5 MHz bei 10 VLeistungsaufnahmeca. 10 µW typischBetriebsartvoll statischStörfestigkeithohe Störfestigkeit, typisch 0,45 × VDD

Für dieses Projekt ist die maximale Geschwindigkeit natürlich nicht entscheidend. Das Lauflicht wird sehr langsam betrieben, da der Takt von einer blinkenden LED kommt. Viel wichtiger ist hier, dass der CD4017 sehr einfach zu beschalten ist und seine Ausgänge automatisch nacheinander aktiviert.

Vereinfacht gesagt passiert Folgendes: Immer wenn am Takteingang ein Impuls ankommt, springt der aktive Ausgang einen Schritt weiter. Ist also zuerst Ausgang 0 aktiv, folgt beim nächsten Takt Ausgang 1, danach Ausgang 2 und so weiter. Nach dem letzten verwendeten Ausgang kann der Zähler wieder zurückgesetzt werden, sodass das Lauflicht von vorn beginnt.

Quelle: Datenblatt CD4017, MakerHero https://www.makerhero.com/img/files/download/CD4017-Datasheet.pdf

Die Lauflicht-Schaltung im Überblick

Nachdem wir uns den CD4017BE als Dekadenzähler angeschaut haben, geht es nun an die eigentliche Schaltung. Der Aufbau basiert auf der Idee aus dem Elektor-Beitrag, wurde hier aber auf das Prinzip eines einfachen Lauflichts reduziert.

Im Mittelpunkt steht der CD4017BE. Dieser erhält an seinem Clock-Eingang einen Taktimpuls und schaltet bei jedem Impuls einen Ausgang weiter. An diesen Ausgängen hängen später die LEDs des Lauflichts.

Der besondere Punkt dieser Schaltung ist der Taktgeber: Statt eines NE555-Timers wird eine blinkende LED verwendet. Diese LED blinkt selbstständig in einem festen Rhythmus. Genau dieses Blinksignal wird genutzt, um den CD4017BE weiterzuschalten.

https://youtu.be/9ap5-KPXEu4

Vereinfacht gesagt läuft die Schaltung so ab:

- Die Blink-LED erzeugt den Takt. - Der CD4017BE erkennt diesen Takt am Clock-Eingang. - Bei jedem Takt springt der aktive Ausgang einen Schritt weiter. - Die angeschlossenen LEDs leuchten nacheinander auf. - Nach dem letzten verwendeten Ausgang beginnt das Lauflicht wieder von vorne.

Damit entsteht ein einfaches Lauflicht, ohne dass dafür ein Mikrocontroller, Programmcode oder ein einstellbarer Timer notwendig ist.

Benötigte Bauteile

Für den Aufbau der Schaltung werden nur wenige Bauteile benötigt:

BauteilAnzahlPreis & LinkHinweisCD4017BE Dekadenzähler1xab 2,95€*DIP16-ICBlink-LED 5 mm1xab 3,50€*dient als TaktgeberLEDs für das Lauflicht9xab 2,89€*z. B. 5mm LEDsWiderstände für die LEDs9xab 1,99€*1 kΩ VorwiderstandWiderstand für die Blink-LED1xab 1,99€*10 kΩ VorwiderstandKondensator1xab 1,12€*100nF Breadboard1xab 3€*für den ersten Testaufbau reicht ein 830 Pin BreadboardJumperkabelmehrereab 2,80€*zur VerdrahtungSpannungsversorgung1xz. B. Batterie oder 5V Versorgung

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!

Die benötigten Bauteile bekommst du zum Beispiel bei eBay, Amazon oder AliExpress. Ich selbst greife bei solchen Kleinteilen häufig zu AliExpress, da die Preise dort oft unschlagbar günstig sind. Der Nachteil sind allerdings die längeren Lieferzeiten. Wer die Teile kurzfristig benötigt, ist mit eBay oder Amazon meist besser bedient.

Die Schaltung

Nachdem wir uns den CD4017BE als Dekadenzähler angeschaut haben, folgt nun die eigentliche Lauflicht-Schaltung. Der Aufbau ist bewusst einfach gehalten und kommt ohne Mikrocontroller, ohne Programmcode und auch ohne klassischen NE555-Timer aus.

Schaltung für ein einfaches LED-Lauflicht mit CD4017BE und Blink-LED als Taktgeber

Der CD4017BE wird in dieser Schaltung mit einer Versorgungsspannung betrieben und bekommt sein Taktsignal über eine blinkende LED. Diese LED besitzt bereits eine kleine interne Elektronik und blinkt selbstständig, sobald sie mit Spannung versorgt wird. Dieses Blinksignal wird genutzt, um den Clock-Eingang des CD4017BE anzusteuern.

Bei jedem Taktimpuls schaltet der Dekadenzähler einen Ausgang weiter. Dadurch werden die angeschlossenen LEDs nacheinander aktiviert und es entsteht der typische Lauflicht-Effekt.

Wichtig sind in der Schaltung vor allem diese Verbindungen:

AnschlussBedeutungPin 16Versorgungsspannung VDDPin 8Masse/GNDPin 14Clock-Eingang für den TaktPin 13Clock Enable, wird auf GND gelegtPin 15Reset-EingangQ0 bis Q8Ausgänge für die LEDsQ9Rücksetzen des Zählers über Reset

Der Ausgang Q9 wird in diesem Aufbau nicht für eine LED verwendet. Stattdessen wird er mit dem Reset-Eingang verbunden. Dadurch zählt der CD4017BE nur von Q0 bis Q8 und beginnt anschließend automatisch wieder bei Q0.

So entsteht ein einfaches Lauflicht mit neun LEDs. Die zehnte Zählstufe des CD4017BE sorgt lediglich dafür, dass der Ablauf wieder von vorne startet.

Fazit: Lauflicht ohne Mikrocontroller

Mit diesem Beitrag habe ich dir gezeigt, wie einfach ein LED-Lauflicht auch ohne Mikrocontroller aufgebaut werden kann. Statt Arduino, ESP32 oder Programmcode kommt hier ein klassischer CD4017BE Dekadenzähler zum Einsatz. Der Takt wird von einer einfachen Blink-LED erzeugt, wodurch die Schaltung sehr übersichtlich bleibt.

Gerade für Einsteiger ist dieser Aufbau interessant, weil man direkt sieht, wie der Zähler auf einen Takt reagiert und die einzelnen Ausgänge nacheinander durchschaltet. Die Liste der benötigten Bauteile bleibt erfreulich kurz und der Aufbau eignet sich sehr gut für erste Tests auf dem Breadboard.

Natürlich ist diese einfache Variante nicht besonders flexibel, denn die Geschwindigkeit des Lauflichts wird durch die Blink-LED fest vorgegeben. Für viele kleine Projekte oder Lötübungen reicht das aber vollkommen aus.

Im nächsten Beitrag möchte ich die Schaltung erweitern und dir zeigen, wie du einen NE555 als Taktgeber einbaust. Damit lässt sich die Geschwindigkeit des Lauflichts über ein Drehpotentiometer einstellen. So wird aus der einfachen Grundschaltung eine deutlich flexiblere Variante, ohne direkt auf einen Mikrocontroller zurückgreifen zu müssen.

[draegerit]

Blogideen direkt in WordPress planen: Mein Plugin Blog Idea Board vorgestellt

Schon der ehemalige US-Präsident Lyndon B. Johnson soll auf seinem Nachttisch einen Notizblock liegen gehabt haben, um spontane Geistesblitze und Ideen sofort festzuhalten. Denn gute Ideen kommen selten genau dann, wenn man gerade Zeit hat, sie sauber auszuarbeiten.

Genau an diesem Punkt setzt Blog Idea Board an.

Blogideen direkt in WordPress planen: Mein Plugin Blog Idea Board vorgestellt

Das WordPress-Plugin soll mehr sein als nur ein digitaler Notizblock. Es hilft dir dabei, Ideen für Blogbeiträge, YouTube-Videos, Shorts, Newsletter oder andere Inhalte direkt im WordPress-Backend zu sammeln, zu strukturieren und weiterzuplanen.

Dabei beginnt alles ganz einfach mit einer Idee. Ein Titel und eine kurze Beschreibung reichen bereits aus, um einen Gedanken festzuhalten. Weitere Informationen wie Priorität, geplantes Datum, Plattformen, Labels, Cluster oder ein verknüpfter WordPress-Beitrag können später ergänzt werden.

Bewusst verzichtet das Plugin auf starre Pflichtfelder. Du sollst nicht in einen festen Workflow gezwungen werden, sondern das Tool so nutzen können, wie es zu deinem eigenen Arbeitsstil passt. Ob als einfache Ideensammlung, als Redaktionsplaner oder als kleines Content-Planungstool: Blog Idea Board wächst mit deinem Workflow mit.

WordPress Plugin: blog-idea-board-v0.11.1Herunterladen

Was ist Blog Idea Board?

Blog Idea Board ist ein WordPress-Plugin, mit dem du Ideen für neue Inhalte direkt im WordPress-Backend sammeln, organisieren und planen kannst. Statt spontane Einfälle in Notizen, Textdateien oder Chatverläufen zu verlieren, landen sie an einem zentralen Ort: direkt dort, wo später auch der eigentliche Beitrag entsteht.

Jede Idee wird als eigener Eintrag gespeichert und kann nach und nach erweitert werden. Am Anfang reicht ein einfacher Titel mit kurzer Beschreibung. Später kannst du zusätzliche Informationen ergänzen, zum Beispiel eine Priorität, ein geplantes Veröffentlichungsdatum, passende Plattformen, Labels, Cluster oder sogar eine Verknüpfung zu einem echten WordPress-Beitrag.

Damit eignet sich das Plugin nicht nur als einfache Ideensammlung, sondern auch als kleines Planungstool für Blogger, Content Creator und alle, die regelmäßig neue Inhalte veröffentlichen.

Für wen ist das Plugin gedacht?

Blog Idea Board richtet sich an alle, die regelmäßig Inhalte planen und veröffentlichen. Besonders interessant ist es für Blogger, YouTuber, kleine Redaktionen, Technikseiten oder Webseitenbetreiber, die nicht nur einzelne Beiträge schreiben, sondern langfristig Themen sammeln und strukturieren möchten.

Gerade wenn aus einer Idee später mehrere Inhalte entstehen, wird eine einfache Notiz schnell unübersichtlich. Aus einem Blogbeitrag kann zusätzlich ein YouTube-Video, ein Short, ein Newsletter oder ein Social-Media-Beitrag werden. Genau dafür bietet das Plugin die passenden Felder und Ansichten.

Ich nutze das Plugin zum Beispiel, um Themen wie Home Assistant, ESP32, Arduino, Node-RED, Shelly, Docker oder WordPress zu sammeln und visuell zu gruppieren. So sehe ich schnell, welche Ideen noch offen sind, welche bereits geplant wurden und welche Inhalte sich aktuell in Arbeit befinden.

Ideen schnell im Dashboard erfassen

Ein wichtiger Punkt bei einer Ideensammlung ist die Geschwindigkeit. Wenn eine Idee entsteht, soll sie möglichst schnell gespeichert werden können, ohne erst viele Felder ausfüllen zu müssen.

Deshalb bringt Blog Idea Board ein eigenes Widget für das WordPress-Dashboard mit. Dort kannst du eine neue Idee direkt über zwei Felder erfassen:

Mehr ist für den ersten Schritt nicht notwendig. Die Idee wird automatisch gespeichert und landet zunächst im Status Idee. Alle weiteren Informationen kannst du später ergänzen, wenn aus dem ersten Gedanken ein konkreter Beitrag oder ein größeres Content-Projekt wird.

Unterhalb der Schnelleingabe zeigt das Dashboard außerdem eine Übersicht der offenen Ideen. Je nach Einstellung kann dort entweder eine kompakte Liste angezeigt werden oder eine Wochenübersicht mit überfälligen, geplanten und undatierten Ideen.

auflisten der offenen Ideen im Dashboard

auflisten der Ideen welche den Status - in Arbeit - haben

Besonders praktisch ist der Tooltip in der Dashboard-Übersicht: Wenn du mit der Maus über einen Eintrag fährst, werden zusätzliche Informationen wie Beschreibung, geplantes Datum, Kosten, Plattformen, Labels, Cluster oder verknüpfte Inhalte eingeblendet. So bleibt die Tabelle kompakt, ohne dass wichtige Details verloren gehen.

Blog Idea Board im Dashboard - Tooltip mit Informationen #2

Blog Idea Board im Dashboard - Tooltip mit Informationen

Das Ideen-Board: Kacheln statt klassischer Tabellen

Nachdem eine Idee erfasst wurde, landet sie nicht einfach nur in einer klassischen WordPress-Liste. Blog Idea Board stellt dafür eine eigene Board-Ansicht bereit, in der die Ideen als Kacheln dargestellt werden.

Ideen Board mit Kacheln für gesammelte Ideen

Das macht die Planung deutlich übersichtlicher, denn wichtige Informationen sind direkt sichtbar. Dazu gehören zum Beispiel der Titel, die Priorität, das geplante Datum, die vorgesehenen Plattformen, Labels, Cluster und der aktuelle Status der Idee.

Gerade wenn viele Ideen parallel entstehen, ist eine reine Tabellenansicht schnell unübersichtlich. Die Kachelansicht fühlt sich hier deutlich natürlicher an, da jede Idee wie ein kleiner Planungsbaustein dargestellt wird.

Eine Idee kann dabei verschiedene Status durchlaufen:

- Idee - Geplant - In Arbeit - Beitrag geschrieben - Video offen - Umgesetzt - Verworfen

Diese Status sollen den Arbeitsprozess unterstützen, aber nicht erzwingen. Es gibt keine harten Pflichtschritte und keine blockierenden Regeln. Du kannst eine Idee also genauso nutzen, wie es zu deinem eigenen Workflow passt.

Besonders praktisch ist die Möglichkeit, den Status direkt im Board weiterzuschalten. So kann aus einer einfachen Idee mit wenigen Klicks ein geplanter Beitrag oder ein Inhalt in Arbeit werden.

Priorität mit 1 bis 5 Sternen

Nicht jede Idee ist gleich wichtig. Manche Themen sind spannend, aber eher etwas für später. Andere Ideen sollten möglichst schnell umgesetzt werden, weil sie aktuell gut passen, ein Problem lösen oder besonders viel Potenzial haben.

Deshalb kann jede Idee in Blog Idea Board mit einer Priorität von 1 bis 5 Sternen bewertet werden.

- ⭐ = niedrige Priorität - ⭐⭐⭐ = normale Priorität - ⭐⭐⭐⭐⭐ = sehr hohe Priorität

Die Priorität hilft vor allem dann, wenn viele Ideen gesammelt wurden. Auf diese Weise sieht man schneller, welche Themen wirklich wichtig sind und welche Ideen erstmal nur als Gedanke gespeichert bleiben.

Auch im Dashboard werden die Ideen nach Priorität sortiert angezeigt. Dadurch stehen wichtige Ideen automatisch weiter oben und geraten nicht so leicht in Vergessenheit.

Plattformen für die Veröffentlichung planen

Viele Inhalte bestehen heute nicht mehr nur aus einem einzelnen Blogbeitrag. Aus einer Idee kann zusätzlich ein YouTube-Video, ein Short, ein Newsletter oder ein Social-Media-Beitrag entstehen.

Deshalb lassen sich in Blog Idea Board geplante Plattformen direkt an einer Idee hinterlegen. Zur Auswahl stehen unter anderem:

- Blog - YouTube Video - YouTube Short - TikTok - Instagram - Newsletter - Facebook - LinkedIn

Damit lässt sich bereits früh festhalten, was aus einer Idee entstehen soll. Eine Idee kann zum Beispiel nur als Blogbeitrag geplant werden oder gleichzeitig als Blogbeitrag, YouTube-Video und Short.

Gerade für Content Creator ist das hilfreich, weil man nicht nur den eigentlichen Beitrag plant, sondern direkt die weitere Verwertung der Idee im Blick behält.

Labels mit Autocomplete wiederverwenden

Neben Plattformen und Prioritäten bietet Blog Idea Board auch Labels. Diese Labels helfen dabei, Ideen flexibel zu markieren, ohne sie direkt in eine feste Kategorie pressen zu müssen.

Labels an einer Idee

So lassen sich zum Beispiel Hinweise wie „Recherche“, „Kooperation“, „Short-Idee“, „Evergreen“, „Wartet auf Hardware“ oder „Video geplant“ an einer Idee hinterlegen.

Besonders praktisch ist dabei die Autocomplete-Funktion. Sobald du mindestens drei Zeichen eingibst, schlägt dir das Plugin bereits vorhandene Labels vor. Dabei können nicht nur Labels aus anderen Ideen genutzt werden, sondern auch bestehende WordPress-Schlagwörter.

Das sorgt dafür, dass Begriffe wiederverwendet werden und nicht immer neue Schreibweisen entstehen. Aus „Review“, „Reviews“ und „Produktreview“ wird so nicht unnötig ein chaotischer Mix, sondern eine sauberere Struktur.

Cluster: Ideen visuell nach Themen gruppieren

Während Labels eher für flexible Hinweise gedacht sind, dienen Cluster zur thematischen Gruppierung. Damit lassen sich Ideen bestimmten Themenbereichen zuordnen.

Ich nutze Cluster zum Beispiel für Themen wie Home Assistant, ESP32, Arduino, Node-RED, Shelly, Docker oder WordPress. Jeder Cluster kann eine eigene Farbe bekommen und ist dadurch im Ideen-Board, im Dashboard und im Kalender schnell erkennbar.

Cluster für Ideen erstellen

Das ist besonders hilfreich, wenn viele Ideen gesammelt wurden. Statt nur eine lange Liste einzelner Einträge zu sehen, erkennst du sofort, zu welchem Themenbereich eine Idee gehört.

So kann man zum Beispiel schnell sehen, ob aktuell viele Ideen zu einem bestimmten Thema vorhanden sind oder ob ein Bereich längere Zeit nicht mehr bedient wurde.

gesammelte Ideen mit Cluster Label

Planungskalender für Ideen, Beiträge und Seiten

Aus einer einfachen Ideensammlung wird spätestens mit dem Planungskalender ein echtes Content-Planungstool.

Blog Idea Board - Planungskalender

Im Kalender zeigt Blog Idea Board nicht nur geplante Ideen an, sondern auch echte WordPress-Beiträge und Seiten. Dadurch siehst du auf einen Blick, welche Ideen für einen bestimmten Tag geplant sind und welche Inhalte bereits im WordPress-System existieren.

Angezeigt werden unter anderem:

- geplante Blogideen - geplante Beiträge - veröffentlichte Beiträge - geplante Seiten - veröffentlichte Seiten

Ein Klick auf einen Eintrag führt direkt zum jeweiligen Inhalt. So kannst du schnell von der Kalenderansicht zur Idee, zum Beitrag oder zur Seite wechseln.

Besonders praktisch ist dabei die farbliche Darstellung über Cluster. Dadurch wird nicht nur sichtbar, wann etwas geplant ist, sondern auch zu welchem Themenbereich der Inhalt gehört.

Wenn aus einer Idee ein echter WordPress-Beitrag wird

Eine Idee bleibt in Blog Idea Board nicht zwangsläufig nur eine Notiz. Sie kann auch mit einem echten WordPress-Beitrag oder einer Seite verknüpft werden.

Das ist besonders praktisch, wenn aus einer ersten Idee später ein konkreter Beitrag entsteht. Die Verbindung sorgt dafür, dass nachvollziehbar bleibt, welcher Inhalt aus welcher Idee hervorgegangen ist.

Zusätzlich aktualisiert das Plugin den Status der Idee automatisch:

- Wird der verknüpfte Beitrag auf „Privat“ gesetzt, wechselt die Idee auf „In Arbeit“. - Wird der Beitrag veröffentlicht, wird die Idee auf „Umgesetzt“ gesetzt. - Wird der Beitrag in den Papierkorb verschoben, springt die Idee wieder zurück auf „Idee“.

Damit bleibt die Planung aktuell, ohne dass jeder Schritt manuell nachgetragen werden muss.

Installation des Plugins

Aktuell stelle ich Blog Idea Board als ZIP-Datei bereit. Die Installation erfolgt wie bei einem normalen WordPress-Plugin:

- ZIP-Datei herunterladen - In WordPress unter „Plugins“ den Punkt „Plugin hochladen“ öffnen - ZIP-Datei auswählen und installieren - Plugin aktivieren - Den neuen Menüpunkt „Blogideen“ im WordPress-Backend öffnen

Ob das Plugin später auch im offiziellen WordPress.org Plugin Directory erscheint, ist aktuell noch offen. Zunächst stelle ich es direkt über meinen Blog bereit und entwickle es anhand meines eigenen Workflows weiter.

Fazit: Vom Gedankenblitz zum geplanten Inhalt

Blog Idea Board ist aus einem einfachen Problem entstanden: Ideen kommen oft spontan, aber sie sauber zu organisieren ist deutlich schwieriger.

Mit dem Plugin lassen sich Blogideen direkt in WordPress sammeln, priorisieren, gruppieren und weiterplanen. Durch Dashboard-Schnelleingabe, Kachelansicht, Labels, Cluster, Kalender und die Verknüpfung mit echten Beiträgen wird daraus mehr als nur eine einfache ToDo-Liste.

Für mich ist Blog Idea Board inzwischen ein kleines Content-Planungstool, das direkt dort arbeitet, wo der spätere Inhalt entsteht: im WordPress-Backend.

In zukünftigen Versionen sind weitere Funktionen denkbar, zum Beispiel Content-Typen, Checklisten pro Idee, bessere Filteransichten oder ein Export als CSV oder JSON.

[draegerit]

ZigBee USB-Stick unter Home Assistant mit Docker einrichten

Damit Home Assistant direkt mit ZigBee-Geräten kommunizieren kann, wird ein sogenannter ZigBee-Koordinator benötigt. In meinem Fall verwende ich einen ZigBee 3.0 USB Dongle OpenHAB mit dem EFR32MG21 SoC. Der Stick wird einfach per USB an den Home-Assistant-Server angeschlossen und stellt anschließend das ZigBee-Netzwerk bereit.

Da ich Home Assistant jedoch nicht als Home Assistant OS, sondern als Docker-Container betreibe, gibt es einen kleinen zusätzlichen Schritt: Der USB-Stick muss vom Host-System in den Docker-Container durchgereicht werden. Andernfalls erkennt Home Assistant den Stick zwar auf dem Linux-System, kann aber innerhalb des Containers nicht darauf zugreifen.

https://youtu.be/Uok9g3alikc

USB-Stick unter Linux erkennen

Nachdem der ZigBee-Stick eingesteckt wurde, kann man zunächst prüfen, ob er vom System erkannt wurde:

lsusb

auflisten der erkannten USB Geräte

In meinem Fall wird der Stick als serieller USB-Adapter erkannt. Zusätzlich sollte geprüft werden, unter welchem stabilen Gerätepfad der Stick erreichbar ist:

ls -l /dev/serial/by-id/

Die Ausgabe sieht beispielsweise so aus:

Wichtig ist hier der Pfad unter /dev/serial/by-id/. Dieser ist stabiler als /dev/ttyUSB0, da sich /dev/ttyUSB0 ändern kann, wenn später weitere USB-Geräte angeschlossen werden.

Der vollständige Pfad lautet in diesem Beispiel:

/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

Docker Compose anpassen

Damit Home Assistant den ZigBee-Stick verwenden kann, muss die docker-compose.yml ⁣erweitert werden. Entscheidend ist der Abschnitt devices.

Ein Beispiel für meine Home-Assistant-Konfiguration sieht so aus:

Docker Compose - Container konfiguration mit ZigBee Device Gerätepfad Datei compose.yml mit dem Pfad zum ZigBee-Gerät services: homeassistant: container_name: homeassistant image: ghcr.io/home-assistant/home-assistant:stable volumes: - /opt/homeassistant/config:/config - /etc/localtime:/etc/localtime:ro - /run/dbus:/run/dbus:ro devices: - /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0:/dev/ttyUSB0 environment: TZ: Europe/Berlin restart: unless-stopped privileged: true network_mode: host

Auf der linken Seite steht der Gerätepfad auf dem Host-System. Auf der rechten Seite wird festgelegt, unter welchem Pfad der Stick im Container verfügbar ist. In diesem Beispiel ist der Stick innerhalb des Home-Assistant-Containers unter /dev/ttyUSB0 erreichbar.

Nach der Änderung muss der Container neu erstellt und neu gestartet werden:

docker compose up -d --force-recreate

Anschließend kann geprüft werden, ob Home Assistant sauber gestartet ist:

docker compose logs -f homeassistant

Docker Container nach der Änderung neuerstellen und starten

ZHA-Integration in Home Assistant einrichten

Jetzt kann die eigentliche Einrichtung in Home Assistant erfolgen.

Dazu öffnest du in Home Assistant:

Einstellungen → Geräte & Dienste → Integration hinzufügen

Dort suchst du nach „Zigbee Home Automation“

Falls Home Assistant den Stick automatisch erkennt, wird die Einrichtung direkt vorgeschlagen. Andernfalls kann die Integration manuell hinzugefügt werden.

Home Assistant - Zigbee Gerät hinzufügen - Step 1

Die Einrichtung erfolgt über einen Wizard, welcher durch die Schritte führt. In meinem Fall wähle ich die automatische Einrichtung, welche am Ende dazu führt, dass mein Gerät als ZigBee-Koordinator eingerichtet ist.

Erstes Zigbee-Gerät hinzufügen: Shelly Plus 1 Gen4 einrichten

Nachdem der Zigbee USB-Stick erfolgreich in Home Assistant eingerichtet wurde, kann das erste Zigbee-Gerät hinzugefügt werden. In meinem Fall verwende ich dafür einen Shelly Plus 1 Gen4.

Der Shelly Plus 1 Gen4 ist besonders interessant, da er nicht mehr nur per WLAN und Bluetooth genutzt werden kann, sondern zusätzlich auch Matter und Zigbee unterstützt. Dadurch lässt sich der smarte Schalter sehr flexibel in unterschiedliche Smart-Home-Systeme integrieren.

Bevor ich den Shelly in Home Assistant eingebunden habe, habe ich ihn zunächst ganz normal über die Shelly Cloud eingerichtet. Anschließend wurde das Gerät auf die Firmware-Version 1.7.5 aktualisiert. Erst danach konnte ich im lokalen Webfrontend des Shelly unter:

Settings → Switch to ZigBee Firmware

die Firmware auf den Zigbee-Betrieb umstellen.

Shelly Gen4 wechsel der Firmware für ZigBee - Hinweis

Der Wechsel dauert einige Sekunden. Währenddessen wird die passende Zigbee-Firmware auf das Gerät übertragen und der Shelly startet anschließend im Zigbee-Modus neu. Danach steht das Gerät nicht mehr wie gewohnt über die WLAN-Firmware zur Verfügung, sondern kann als Zigbee-Gerät an einem Zigbee-Koordinator angelernt werden.

Shelly Gen4 wechsel der Firmware für ZigBee

In Home Assistant wird dazu die bereits eingerichtete ZHA-Integration geöffnet. Dort kann über Gerät hinzufügen beziehungsweise Add Device die Suche nach neuen Zigbee-Geräten gestartet werden. Sobald der Shelly im Pairing-Modus ist, wird er von Home Assistant erkannt und kann anschließend benannt sowie einem Bereich zugeordnet werden.

Damit das Gerät gefunden / gekoppelt werden kann, muss dieses in den Kopplungsmodus versetzt werden. Wie man diesen Modus einstellt, ist vom Gerät abhängig, bei Shelly Geräten klappt dies ab der Firmware Version 1.7.0 über die Weboberfläche.

Wird das Gerät erkannt, so wird eine Verbindung aufgebaut und zunächst lediglich die Adresse angezeigt. Im Anschluss wird der korrekte Name angezeigt, welchen man nach Belieben ändern kann, und das Gerät lässt sich einem Bereich/ Raum zuordnen.

Shelly Plus 1 Gen4 - eingerichtet in Home Assistant

Nach der erfolgreichen Einrichtung steht der Shelly Plus 1 Gen4 als smarter Schalter in Home Assistant zur Verfügung und kann dort für Automationen, Szenen oder Dashboards verwendet werden.

Ausgang am Shelly Plus 1 Gen4 deaktiviert

Ausgang am Shelly Plus 1 Gen4 aktiviert

Wichtig: Ein Zigbee-Gerät kann immer nur mit einem Zigbee-Netzwerk verbunden sein. Wird der Shelly über Home Assistant eingebunden, ist er Teil dieses Zigbee-Netzwerks. Soll er später wieder über eine andere Plattform oder einen anderen Funkstandard genutzt werden, muss die Firmware bzw. der Betriebsmodus entsprechend erneut gewechselt werden.

Fazit

Die Einrichtung eines Zigbee USB-Sticks unter Home Assistant ist grundsätzlich recht einfach. Die eigentliche Besonderheit entsteht erst dann, wenn Home Assistant – wie in meinem Fall – als Docker-Container betrieben wird. Der USB-Stick wird zwar vom Linux-System erkannt, muss aber zusätzlich sauber an den Container durchgereicht werden.

Mit dem stabilen Gerätepfad unter /dev/serial/by-id/ und der passenden Erweiterung in der docker-compose.yml lässt sich der Zigbee-Koordinator zuverlässig in Home Assistant einbinden. Anschließend übernimmt die ZHA-Integration die Einrichtung des Zigbee-Netzwerks.

Besonders spannend wird es mit Geräten wie dem Shelly Plus 1 Gen4. Durch die Unterstützung von WLAN, Bluetooth, Matter und Zigbee lässt sich der smarte Schalter sehr flexibel einsetzen. Nach dem Wechsel auf die Zigbee-Firmware kann er direkt in Home Assistant angelernt und für Automationen, Szenen oder Dashboards verwendet werden.

Damit ist der Grundstein für ein eigenes Zigbee-Netzwerk in Home Assistant gelegt. Weitere Sensoren, Schalter, Lampen oder Aktoren können nun Schritt für Schritt hinzugefügt und zentral über Home Assistant gesteuert werden.

[draegerit]

Home Assistant unter Fedora Linux installieren – Schritt für Schritt mit Docker Compose

Home Assistant ist eine der beliebtesten Lösungen, wenn es darum geht, Geräte im Smart Home zentral zu steuern, Automationen zu erstellen und verschiedene Hersteller in einer Oberfläche zusammenzuführen. Ob Shelly, MQTT, Zigbee, ESP32-Projekte oder klassische WLAN-Geräte: Home Assistant bietet eine sehr flexible Plattform für viele Smart-Home-Szenarien.

In diesem Beitrag zeige ich dir, wie du Home Assistant unter Fedora Linux installierst. Dabei nutzen wir nicht Home Assistant OS, sondern die Container-Variante mit Docker Compose.

Das ist besonders praktisch, wenn Fedora bereits als Linux-System läuft und du Home Assistant zusätzlich betreiben möchtest, ohne das komplette Betriebssystem durch Home Assistant OS zu ersetzen.

Der Beitrag richtet sich an alle, die Fedora als Server, Mini-PC oder Testsystem nutzen und Home Assistant sauber über die Kommandozeile installieren möchten.

Warum Home Assistant als Container unter Fedora?

Es gibt verschiedene Möglichkeiten, Home Assistant zu installieren. Für Einsteiger wird häufig Home Assistant OS empfohlen, weil dort viele Dinge bereits fertig integriert sind. Dazu gehören zum Beispiel der Supervisor, Backups und Add-ons.

Wenn du aber bereits ein vorhandenes Linux-System wie Fedora nutzt, kann die Container-Installation deutlich flexibler sein. Du kannst Home Assistant neben anderen Diensten betreiben, zum Beispiel neben Node-RED, Mosquitto, SQLite, Grafana oder eigenen Docker-Containern.

Der große Vorteil:

Du behältst die volle Kontrolle über dein Fedora-System und kannst Home Assistant trotzdem sauber isoliert in einem Container ausführen.

Wichtig ist aber auch der Nachteil:

Bei der Container-Installation gibt es keinen Home Assistant Supervisor und damit auch keinen Add-on-Store direkt in Home Assistant. Dienste wie Mosquitto, Node-RED oder Zigbee2MQTT müssen dann separat als eigene Container installiert werden.

Für meinen Anwendungsfall ist genau das sogar ein Vorteil, da ich viele Dienste ohnehin getrennt und nachvollziehbar über Docker Compose betreibe.

Mein Testsystem: Dell Optiplex 3050 Micro mit Fedora

Für diesen Beitrag verwende ich meinen Dell Optiplex 3050 Micro, den ich bereits in einem separaten Beitrag genauer vorgestellt habe:

Dell Optiplex Micro als Heimserver – ein günstiger Einstieg in die Serverwelt

DELL Optiplex 3050 Micro

Ursprünglich lief auf diesem kleinen Heimserver Ubuntu. Für meine aktuelle Nutzung bin ich jedoch aus Performancegründen auf Fedora Linux gewechselt. Gerade bei einem kompakten Mini-PC, der dauerhaft als kleiner Server laufen soll, zählt für mich ein schlankes und reaktionsschnelles System.

Fedora eignet sich hier sehr gut als Grundlage, weil es aktuelle Pakete bereitstellt und sich trotzdem sauber als Linux-Host für Docker, Home Assistant, Node-RED oder weitere Smart-Home-Dienste nutzen lässt.

Wichtig: Die Anleitung ist nicht auf den Dell Optiplex 3050 beschränkt. Du kannst die Schritte grundsätzlich auch auf anderer kompatibler Hardware mit Fedora Linux nachvollziehen.

Voraussetzungen

Für diese Anleitung benötigst du:

- ein installiertes Fedora Linux - Zugriff auf ein Terminal oder SSH - einen Benutzer mit sudo-Rechten - eine Netzwerkverbindung - grundlegende Kenntnisse im Umgang mit der Linux-Konsole

In meinem Beispiel verwende ich Fedora als Host-System und installiere Home Assistant mit Docker Compose.

Schritt 1: System aktualisieren

Zuerst aktualisieren wir Fedora:

sudo dnf update -y

Das ist kein zwingender Schritt, aber gerade bei einem frisch installierten System sinnvoll.

Fedora Linux - System aktualisieren

Schritt 2: Altes Docker entfernen

Falls auf deinem System bereits ältere oder nicht offizielle Docker-Pakete installiert sind, solltest du diese vorher entfernen.

sudo dnf remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-selinux docker-engine-selinux docker-engine

Wenn Fedora meldet, dass einige dieser Pakete nicht installiert sind, ist das kein Problem.

Schritt 3: Docker-Repository unter Fedora hinzufügen

Damit wir Docker Engine aus dem offiziellen Docker-Repository installieren können, fügen wir zuerst das Repository hinzu:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Danach kann Docker direkt über dnf installiert werden.

Schritt 4: Docker Engine und Docker Compose installieren

Nun installieren wir Docker Engine, die Docker CLI, containerd sowie das Docker-Compose-Plugin:

sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Während der Installation kann Fedora fragen, ob ein GPG-Schlüssel akzeptiert werden soll. Diesen musst du bestätigen, damit die Pakete installiert werden können.

Schritt 5: Docker starten und automatisch aktivieren

Nach der Installation ist Docker zwar installiert, aber noch nicht zwingend gestartet. Mit dem folgenden Befehl starten wir Docker und aktivieren den automatischen Start beim Booten:

sudo systemctl enable --now docker

Ob Docker läuft, kannst du so prüfen:

sudo systemctl status docker

Optional kannst du zusätzlich den klassischen Testcontainer ausführen:

sudo docker run hello-world

Wenn Docker korrekt funktioniert, lädt Docker ein kleines Testimage herunter und gibt eine Erfolgsmeldung aus.

Docker - Hello World Container zum testen

Schritt 6: Docker ohne sudo verwenden

Standardmäßig muss Docker oft mit sudo ausgeführt werden. Wenn du deinen Benutzer zur Docker-Gruppe hinzufügen möchtest, kannst du folgenden Befehl nutzen:

sudo usermod -aG docker $USER

Danach musst du dich einmal abmelden und wieder anmelden. Bei einer SSH-Verbindung bedeutet das: Verbindung trennen und neu verbinden.

Anschließend sollte folgender Befehl ohne sudo funktionieren:

docker ps

Docker ohne sudo starten

Schritt 7: Verzeichnis für Home Assistant anlegen

Ich lege die Konfiguration bewusst unter /opt/homeassistant ab. Dadurch liegt Home Assistant nicht irgendwo im Home-Verzeichnis, sondern an einem sauberen Ort für dauerhaft laufende Dienste.

sudo mkdir -p /opt/homeassistant/config sudo chown -R $USER:$USER /opt/homeassistant

In diesem Ordner speichert Home Assistant später seine Konfiguration, Datenbank, Logs und Einstellungen.

Schritt 8: Docker-Compose-Datei erstellen

Jetzt wechseln wir in das neue Verzeichnis:

cd /opt/homeassistant

Dort erstellen wir die Datei compose.yaml:

nano compose.yaml

Der Inhalt sieht so aus:

services: homeassistant: container_name: homeassistant image: ghcr.io/home-assistant/home-assistant:stable volumes: - /opt/homeassistant/config:/config - /etc/localtime:/etc/localtime:ro - /run/dbus:/run/dbus:ro environment: TZ: Europe/Berlin restart: unless-stopped privileged: true network_mode: host

Speichere die Datei anschließend mit STRG + O, bestätige mit Enter und verlasse den Editor mit STRG + X.

Was bedeuten die wichtigsten Einträge?

image image: ghcr.io/home-assistant/home-assistant:stable

Damit verwenden wir das stabile Home-Assistant-Container-Image.

volumes - /opt/homeassistant/config:/config

Dieser Eintrag sorgt dafür, dass die Home-Assistant-Konfiguration dauerhaft auf dem Fedora-System gespeichert wird. Wenn der Container später gelöscht oder aktualisiert wird, bleiben deine Einstellungen erhalten.

- /etc/localtime:/etc/localtime:ro

Damit übernimmt der Container die lokale Zeit des Host-Systems.

- /run/dbus:/run/dbus:ro

Dieser Eintrag ist vor allem dann interessant, wenn später Bluetooth-Funktionen genutzt werden sollen.

restart restart: unless-stopped

Home Assistant startet dadurch automatisch neu, wenn der Container beendet wurde oder das System neu gestartet wird.

network_mode network_mode: host

Home Assistant verwendet damit direkt das Netzwerk des Fedora-Hosts. Das ist bei Home Assistant besonders wichtig, weil viele automatische Erkennungen im Netzwerk über mDNS, SSDP oder ähnliche Mechanismen laufen.

privileged privileged: true

Damit erhält der Container erweiterte Rechte. Das ist bei Home Assistant üblich, da je nach Integration Zugriff auf System- oder Gerätedienste notwendig sein kann.

Schritt 9: Home Assistant starten

Jetzt starten wir Home Assistant:

docker compose up -d

Docker lädt nun das Image herunter und startet den Container im Hintergrund.

Home Assistant als Docker Container gestartet

Den Status prüfst du mit:

docker ps

Du solltest nun einen Container mit dem Namen homeassistant sehen.

Home Assistant als Docker Container gestartet

Die Logs kannst du dir mit folgendem Befehl anzeigen lassen:

docker logs -f homeassistant

Beim ersten Start kann es etwas dauern, bis Home Assistant vollständig initialisiert wurde.

Ausgabe der Logs des Containers

Schritt 10: Home Assistant im Browser öffnen

Sobald Home Assistant gestartet ist, erreichst du die Oberfläche im Browser über Port 8123.

Direkt auf dem Fedora-System:

http://localhost:8123

Von einem anderen Gerät im Netzwerk:

http://IP-DEINES-FEDORA-SYSTEMS:8123

Ein Beispiel:

http://192.168.178.186:8123

Home Assistant - Einrichten nach dem ersten starten

Wenn du die IP-Adresse deines Fedora-Systems nicht kennst, kannst du sie mit folgendem Befehl anzeigen lassen:

ip -br addr

Achte dabei auf die IP-Adresse deiner aktiven Netzwerkschnittstelle, zum Beispiel wlan0 oder enp....

Schritt 11: Firewall unter Fedora freigeben

Wenn Home Assistant lokal funktioniert, aber von einem anderen Gerät im Netzwerk nicht erreichbar ist, liegt es häufig an der Firewall.

Unter Fedora kannst du Port 8123 so freigeben:

sudo firewall-cmd --permanent --add-port=8123/tcp sudo firewall-cmd --reload

Danach solltest du Home Assistant von einem anderen Rechner, Smartphone oder Tablet im Netzwerk öffnen können.

Home Assistant verwalten

Container stoppen docker compose down Container starten docker compose up -d Home Assistant neu starten docker compose restart Logs anzeigen docker logs -f homeassistant Aktive Container anzeigen docker ps

Home Assistant aktualisieren

Ein Update ist bei der Container-Installation sehr einfach. Wechsle zuerst in das Verzeichnis mit deiner compose.yaml:

cd /opt/homeassistant

Dann lädst du das aktuelle Image:

docker compose pull

Anschließend startest du den Container neu:

docker compose up -d

Die Konfiguration bleibt erhalten, weil sie im Ordner /opt/homeassistant/config gespeichert wird.

Trotzdem solltest du vor größeren Updates ein Backup des Config-Ordners erstellen.

Einfaches Backup der Konfiguration

Für ein schnelles Backup kannst du den kompletten Config-Ordner packen:

sudo tar -czvf homeassistant-config-backup.tar.gz /opt/homeassistant/config

Wenn du möchtest, kannst du die Datei anschließend auf einen USB-Stick, ein NAS oder einen anderen Rechner kopieren.

USB-Geräte wie Zigbee-Stick einbinden

Wenn du später einen Zigbee- oder Z-Wave-Stick verwenden möchtest, solltest du diesen möglichst über /dev/serial/by-id/ einbinden.

Die Geräte findest du mit:

ls -l /dev/serial/by-id/

Ein Beispiel für einen Eintrag in der compose.yaml:

services: homeassistant: container_name: homeassistant image: ghcr.io/home-assistant/home-assistant:stable volumes: - /opt/homeassistant/config:/config - /etc/localtime:/etc/localtime:ro - /run/dbus:/run/dbus:ro environment: TZ: Europe/Berlin restart: unless-stopped privileged: true network_mode: host devices: - /dev/serial/by-id/DEIN_USB_STICK:/dev/ttyUSB0

Der Vorteil von /dev/serial/by-id/ ist, dass der Pfad meistens stabiler ist als /dev/ttyUSB0. Gerade nach einem Neustart kann sich die Reihenfolge von USB-Geräten ändern.

Typische Fehler und Lösungen

Home Assistant ist nicht erreichbar

Prüfe zuerst, ob der Container läuft:

docker ps

Danach prüfst du die Logs:

docker logs -f homeassistant

Wenn Home Assistant im Container läuft, aber der Browser keine Verbindung bekommt, prüfe die Firewall:

sudo firewall-cmd --permanent --add-port=8123/tcp sudo firewall-cmd --reload docker compose wird nicht gefunden

Prüfe, ob das Compose-Plugin installiert ist:

docker compose version

Falls nicht, installiere das Plugin nach:

sudo dnf install docker-compose-plugin -y Docker kann nicht ohne sudo verwendet werden

Wenn folgender Fehler erscheint:

permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

oder:

permission denied while trying to connect to the Docker daemon socket

dann wurde dein Benutzer zwar möglicherweise bereits zur Docker-Gruppe hinzugefügt, aber die aktuelle Terminal-Sitzung kennt diese neue Gruppenmitgliedschaft noch nicht.

Prüfe zuerst, ob dein Benutzer bereits in der Docker-Gruppe steht:

groups

Wenn docker dort noch nicht auftaucht, prüfe zusätzlich:

getent group docker

Den Benutzer fügst du mit folgendem Befehl zur Docker-Gruppe hinzu:

sudo usermod -aG docker $USER

Damit die Änderung aktiv wird, musst du dich normalerweise einmal komplett abmelden und wieder anmelden. Bei einer SSH-Verbindung bedeutet das: SSH-Verbindung trennen und neu verbinden.

Alternativ kannst du die neue Gruppenmitgliedschaft direkt in der aktuellen Sitzung aktivieren:

newgrp docker

Danach sollte dieser Befehl ohne sudo funktionieren:

docker ps Docker startet nicht

Prüfe den Status:

sudo systemctl status docker

Details findest du mit:

journalctl -u docker -xe

Home Assistant Container oder Home Assistant OS?

Die Container-Installation ist ideal, wenn du bereits ein Linux-System betreibst und Dienste sauber über Docker verwalten möchtest.

Sie eignet sich besonders für:

- Fedora-Server - Mini-PCs - Testsysteme - bestehende Docker-Umgebungen - Nutzer, die Node-RED, Mosquitto oder Datenbanken separat betreiben möchten

Home Assistant OS ist dagegen besser geeignet, wenn du möglichst wenig administrieren möchtest und Add-ons direkt aus Home Assistant heraus nutzen willst.

Kurz gesagt:

Wenn du maximale Bequemlichkeit möchtest, nimm Home Assistant OS. Wenn du maximale Kontrolle auf einem bestehenden Linux-System möchtest, ist Home Assistant Container eine sehr gute Wahl.

Fazit

Home Assistant lässt sich unter Fedora Linux sehr sauber mit Docker Compose installieren. Die Einrichtung ist schnell erledigt, die Konfiguration bleibt dauerhaft im Host-Dateisystem gespeichert und Updates können mit wenigen Befehlen durchgeführt werden.

Für mich ist diese Variante besonders interessant, weil sie sich gut in bestehende Docker-Setups integrieren lässt. Wer ohnehin Dienste wie Node-RED, Mosquitto oder eigene Microcontroller-Projekte betreibt, bekommt mit Home Assistant eine starke zentrale Oberfläche für das Smart Home.

Der wichtigste Punkt ist jedoch:

Bei Home Assistant Container musst du zusätzliche Dienste selbst verwalten. Dafür bekommst du aber ein sehr flexibles Setup, das sich perfekt für eigene Smart-Home- und IoT-Projekte eignet.

Die eigentliche Ersteinrichtung nach dem ersten Start lagere ich bewusst in einen separaten Beitrag aus. Dort zeige ich dann Schritt für Schritt, wie Home Assistant nach der Installation eingerichtet wird, welche ersten Einstellungen sinnvoll sind und wie sich später Geräte oder Dienste wie Shelly, MQTT, Node-RED oder Zigbee2MQTT anbinden lassen. Dazu ist zusätzlich ein passendes YouTube-Video geplant.

FAQ

Kann ich Home Assistant direkt unter Fedora installieren?

Ja, aber die sauberste und flexibelste Variante ist die Installation als Container mit Docker Compose. So bleibt Home Assistant vom Host-System getrennt und lässt sich einfach aktualisieren.

Hat Home Assistant Container Add-ons?

Nein. Die Container-Variante besitzt keinen Supervisor und damit auch keinen Add-on-Store. Dienste wie Mosquitto oder Node-RED müssen separat installiert werden.

Welchen Port nutzt Home Assistant?

Home Assistant ist standardmäßig über Port 8123 erreichbar.

Warum wird network_mode: host verwendet?

Home Assistant erkennt viele Geräte automatisch im lokalen Netzwerk. Dafür sind Netzwerkfunktionen wie mDNS und SSDP wichtig. Mit network_mode: host kann Home Assistant direkt das Netzwerk des Fedora-Hosts nutzen.

Bleiben meine Daten bei einem Update erhalten?

Ja, solange du den Ordner /opt/homeassistant/config nicht löschst. Dort liegen die Konfiguration und die Daten von Home Assistant.

Kann ich später Zigbee oder Z-Wave nutzen?

Ja. USB-Sticks können über die devices-Sektion in der compose.yaml in den Container eingebunden werden. Empfehlenswert ist dabei der Pfad über /dev/serial/by-id/.

[draegerit]

Shelly Pro 3EM im Test: 3-Phasen-Strommessung mit 120A CT-Klemmen

Wer den eigenen Stromverbrauch genauer analysieren möchte, kommt mit einfachen Zwischensteckern oder smarten Steckdosen schnell an Grenzen. Diese eignen sich gut für einzelne Verbraucher, liefern aber keinen vollständigen Überblick über den Stromverbrauch eines Hauses, einer Unterverteilung oder größerer Stromkreise.

Genau hier setzt der Shelly Pro 3EM an. Das Gerät ist ein Energiezähler für die Hutschiene und kann zur Messung von ein- oder dreiphasigen Stromkreisen eingesetzt werden. Damit eignet er sich besonders für Anwendungen, bei denen nicht nur ein einzelner Verbraucher, sondern der gesamte Energiefluss betrachtet werden soll.

https://youtu.be/SQlQNZfxXGw

Für meine Beitragsreihe verwende ich den Shelly Pro 3EM in der 120A-Version mit drei CT-Klemmen. Diese Variante ist besonders interessant, weil die Strommessung über aufklappbare Stromwandler erfolgt. Die vorhandenen Leitungen müssen dafür nicht gelöst werden, sondern werden von den CT-Klemmen umschlossen.

Shelly Pro 3EM - 120A

Shelly Pro 3EM - Schaltung aufgedruckt auf dem Gehäuse

Shelly Pro 3EM - Technische Daten aufgedruckt auf dem Gehäuse

Warum ein Shelly Pro 3EM?

Der Shelly Pro 3EM ist deutlich mehr als ein einfacher Stromzähler mit WLAN. Er ist für die Montage auf der Hutschiene vorgesehen und bringt neben WLAN auch LAN und Bluetooth mit. Zusätzlich unterstützt das Gerät verschiedene Integrationsmöglichkeiten wie MQTT, HTTP und WebSocket. Dadurch lässt es sich nicht nur über die Shelly-App nutzen, sondern auch lokal in eigene Systeme wie Node-RED, Home Assistant oder andere Smarthome- und Monitoring-Lösungen einbinden. Laut Shelly bietet der Pro 3EM eine Messgenauigkeit von 1 % für aktive Energie und kann historische Daten für 60 Tage mit einer Auflösung von einer Minute speichern.

Besonders spannend ist für mich aber nicht nur die reine Anzeige der Messwerte. In dieser Beitragsreihe soll daraus ein komplettes kleines Projekt entstehen:

- Messwerte erfassen - Daten lokal speichern - CSV-Export bereitstellen - Werte in einem Dashboard visualisieren

Damit wird der Shelly Pro 3EM nicht nur zu einem Messgerät, sondern zur Grundlage für ein eigenes Energiedashboard.

Meine Variante: Shelly Pro 3EM 120A mit CT-Klemmen

In meinem Fall kommt der Shelly Pro 3EM 120A zum Einsatz. Diese Variante wird mit drei Stromwandlern geliefert, die jeweils bis 120A ausgelegt sind. Shelly beschreibt diese Version als Hutschienen-Energiezähler für ein- oder dreiphasige Messungen mit drei 120A-Stromwandlern.

Shelly Pro 3EM - Lieferumfang

Der große Vorteil dieser CT-Klemmen liegt in der Montageart. Es handelt sich um aufklappbare Stromwandler. Die Leitung muss also nicht aufgetrennt oder aus einer Klemme gelöst werden. Stattdessen wird die CT-Klemme geöffnet, um den Leiter gelegt und anschließend wieder geschlossen.

Das ist gerade für Nachrüstungen sehr praktisch, weil sich der Messaufbau dadurch deutlich einfacher realisieren lässt. Trotzdem bleibt natürlich wichtig: Arbeiten in einer Unterverteilung oder an 230V/400V-Anlagen dürfen nur von einer Elektrofachkraft durchgeführt werden.

Auf die Richtung der CT-Klemmen achten

Ein wichtiger Punkt bei der Montage ist die korrekte Ausrichtung der Stromwandler. Auf der Unterseite der CT-Klemmen ist die Richtung mit K > L gekennzeichnet.

Dabei gilt für den Aufbau:

- K zeigt in Richtung der Zuleitung - L zeigt in Richtung des Sicherungsautomaten

Shelly Pro 3EM - Leitungsklemme - Einbaurichtung

CT Klemme geöffnet

CT Klemme geöffnet

CT Klemme geschlossen

Die Richtung ist wichtig, damit die gemessene Leistung korrekt interpretiert wird. Wird eine CT-Klemme falsch herum montiert, können Messwerte mit falschem Vorzeichen dargestellt werden. Das ist besonders dann relevant, wenn später Bezug und Einspeisung unterschieden oder Messwerte automatisch ausgewertet werden sollen.

Für die reine Verbrauchsanzeige fällt ein verdrehter Stromwandler eventuell nicht sofort auf. Sobald die Daten aber gespeichert, exportiert oder in Node-RED weiterverarbeitet werden, sollte die Richtung sauber stimmen.

Einsatzbereiche des Shelly Pro 3EM

Der Shelly Pro 3EM eignet sich für verschiedene Szenarien. Typische Anwendungsfälle sind zum Beispiel:

- Messung des Hausverbrauchs - Überwachung einer Unterverteilung - Analyse einzelner größerer Stromkreise - Kontrolle von Werkstatt, Küche oder Technikraum - Einbindung in PV- oder Balkonkraftwerk-Projekte - Datenerfassung für spätere Auswertung

Shelly nennt selbst unter anderem Energiesparen, Leistungsüberwachung, PV-Systeme und Wallboxen als typische Einsatzbereiche für den Shelly Pro 3EM.

Für mein Projekt steht vor allem die lokale Datenerfassung im Vordergrund. Ich möchte die Messwerte nicht nur in der Shelly-App betrachten, sondern regelmäßig abrufen, speichern und später auswerten können.

Wichtig: Der Shelly Pro 3EM ist kein Schaltaktor

Ein Punkt, der schnell übersehen wird: Der Shelly Pro 3EM misst Energie, schaltet aber selbst keine Lasten. Shelly weist darauf hin, dass das Gerät kein integriertes Relais besitzt. Eine Schütz- oder Schaltsteuerung kann nur über zusätzliche Komponenten wie ein Shelly Pro Add-on umgesetzt werden.

Das ist für mein Projekt aber kein Nachteil. In dieser Reihe geht es zunächst nicht darum, Verbraucher direkt zu schalten, sondern darum, Messwerte sauber zu erfassen und nutzbar zu machen.

Technische Daten des Shelly Pro 3EM

Der Shelly Pro 3EM ist für die Montage auf der Hutschiene ausgelegt und wird direkt in der Unterverteilung installiert. Das Gerät ist vergleichsweise kompakt und benötigt nur wenig Platz im Schaltschrank.

EigenschaftWertAbmessungen94 × 19 × 69 mmGewichtca. 62 gMontageHutschieneGehäusematerialKunststoffFarbeWeißVersorgungsspannung100 bis 260 V AC, 50/60 HzLeistungsaufnahme< 3 WUmgebungstemperatur-20 °C bis 40 °CLuftfeuchtigkeit30 % bis 70 % RHMaximale Höhe2000 mWLAN802.11 b/g/nBluetooth4.2ProzessorESP32-D0WDQ6Flash-Speicher16 MBMQTTJaScriptingJaWebhooks20 Webhooks mit je 5 URLsCoAPNein Messfunktionen

Besonders interessant sind natürlich die Messfunktionen. Der Shelly Pro 3EM misst Spannung, Strom, Leistung und Energie auf den einzelnen Phasen.

MesswertAngabeSpannungsmessung100 bis 260 V je PhaseGenauigkeit Spannung±1 %Strommessung0 bis 120 A je Phase über CT-KlemmenKompatible StromwandlerCT 120AGenauigkeit Strommessung±1 % bei 2 bis 120 AGenauigkeit bei kleinen Strömen±2 % bei 1 bis 2 A, ±5 % bei 0 bis 1 ALeistungsmessungWirkleistung und ScheinleistungEnergiemessungWirkenergie und ScheinenergieLeistungsfaktorJaBlindenergieFundamental reactive energyDatenspeichermindestens 60 Tage bei 1-Minuten-AuflösungDatenexportCSV für PQ-Werte, JSON über RPC

Wichtiger Hinweis: Der Shelly Pro 3EM wird in der Unterverteilung bzw. im Schaltschrank installiert. Arbeiten an 230V/400V-Anlagen dürfen ausschließlich von einer Elektrofachkraft durchgeführt werden. Dieser Beitrag dient der technischen Vorstellung und Dokumentation meines Projekts.

Wichtige Punkte für die Praxis

Für den praktischen Einsatz sind ein paar Daten besonders relevant. Der Shelly Pro 3EM benötigt eine eigene Spannungsversorgung im Bereich von 100 bis 260 V AC und verbraucht dabei weniger als 3 W. Die Messung des Stroms erfolgt nicht direkt durch das Gerät, sondern über die angeschlossenen 120A CT-Klemmen.

Die Strommessung ist im Bereich von 2 bis 120 A mit ±1 % angegeben. Bei sehr kleinen Strömen nimmt die Genauigkeit ab. Das ist wichtig, wenn sehr geringe Lasten oder Standby-Verbräuche bewertet werden sollen.

Ebenfalls spannend ist der interne Speicher. Der Shelly Pro 3EM kann Messdaten für mindestens 60 Tage mit einer Auflösung von einer Minute speichern. Für mein Projekt möchte ich mich darauf jedoch nicht allein verlassen, sondern die Daten zusätzlich lokal mit Node-RED abrufen und in einer eigenen Datenbank speichern.

Anschlussprinzip des Shelly Pro 3EM

Auf der oberen Seite des Shelly Pro 3EM befinden sich die Schraubklemmen für die Spannungsmessung bzw. Zuleitungen. Diese sind mit A, B und C gekennzeichnet. Wichtig ist dabei, dass die angeschlossenen Phasen zu den jeweiligen Stromwandlern auf der Unterseite passen.

Shelly Pro 3EM - Schraubklemmen für Zuleitungen #1

Shelly Pro 3EM - Schraubklemmen für Zuleitungen #2

Shelly Pro 3EM - Anschlüsse für die CT Klemmen #1

Shelly Pro 3EM - Anschlüsse für die CT Klemmen #2

Das bedeutet: Die Phase, die oben an A angeschlossen wird, muss auch durch die CT-Klemme geführt werden, die dem Kanal A zugeordnet ist. Gleiches gilt für B und C. Werden Spannungseingang und Stromwandler vertauscht, können die später angezeigten Messwerte verfälscht oder schwer nachvollziehbar werden.

Einphasiger Betrieb

Der Shelly Pro 3EM kann nicht nur für dreiphasige Messungen verwendet werden, sondern auch in einem einphasigen Aufbau. In diesem Fall wird die einzelne Phase gemäß dem Schaltbild auf dem Gehäuse an Klemme C angeschlossen.

Der Grund dafür ist, dass der Shelly Pro 3EM seine eigene Versorgung über die Klemme C bezieht. Das Gerät wird also nicht separat über ein eigenes Netzteil versorgt, sondern nutzt diese angeschlossene Phase für den Betrieb.

Kleine Messabweichung durch Eigenverbrauch

Da der Shelly Pro 3EM selbst ebenfalls eine geringe Leistungsaufnahme besitzt, kann es bei der Messung auf dieser Phase zu einer kleinen Abweichung kommen. Laut technischen Daten liegt die Leistungsaufnahme des Geräts bei unter 3 W.

In der Praxis ist diese Abweichung für viele Anwendungen vermutlich vernachlässigbar. Wenn man jedoch sehr kleine Verbraucher oder Standby-Werte möglichst exakt erfassen möchte, sollte man diesen Punkt im Hinterkopf behalten.

Preis und Einordnung

Je nach Händler und Lieferumfang liegt der Shelly Pro 3EM 120A mit CT-Klemmen meist im Bereich ab etwa 75 bis 90 € zuzüglich Versandkosten. Im offiziellen Shelly-Shop kann der Preis je nach Variante oder Bundle deutlich höher ausfallen.

Im Vergleich zu einem Shelly PM Mini oder anderen einfachen Messmodulen bietet er jedoch deutlich mehr Möglichkeiten. Statt nur einen einzelnen Verbraucher oder Stromkreis zu erfassen, können mit dem Shelly Pro 3EM bis zu drei Phasen gemessen und umfangreiche Messwerte wie Spannung, Strom, Leistung, Energie und Leistungsfaktor ausgewertet werden.

Man sollte ihn daher nicht direkt mit einem einfachen Shelly PM oder Shelly PM Mini vergleichen. Diese sind deutlich günstiger und für einzelne Messpunkte sehr praktisch. Ein Shelly Plus 1PM kann zusätzlich sogar messen und schalten. Der Shelly Pro 3EM spielt jedoch in einer anderen Klasse: Er ist eher für die zentrale Energieerfassung, Unterverteilungen oder größere Auswertungen gedacht. Für einfache Schaltaufgaben ist er überdimensioniert, für ein eigenes Energiedashboard oder eine detaillierte Verbrauchsanalyse ist der Preis jedoch gut nachvollziehbar.

shellyparts.deoffizieller Shelly Shopebay.deShelly Pro 3EM - 120 A - CT85,44 €157,14 €ab 80€*

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!

Ausblick auf die Beitragsreihe

Dieser erste Beitrag dient als Einstieg und stellt den Shelly Pro 3EM sowie die verwendete 120A-Variante mit CT-Klemmen vor.

In den nächsten Teilen geht es dann praktisch weiter:

- Shelly Pro 3EM einrichten Netzwerk, Weboberfläche, erste Messwerte und Grundeinstellungen. - Daten exportieren Abruf der Messwerte mit Node-RED, Speicherung in SQLite und Export als CSV-Datei. - Daten visualisieren Aufbau eines Dashboards zur Anzeige von Leistung, Verlauf und Verbrauchswerten.

Damit entsteht Schritt für Schritt ein lokales Energiemonitoring-System auf Basis des Shelly Pro 3EM.

Fazit zum Shelly Pro 3EM

Der Shelly Pro 3EM ist für mich ein spannender Einstieg in eine professionelle Energieerfassung im eigenen Smarthome. Besonders die 120A-Version mit aufklappbaren CT-Klemmen eignet sich gut für Projekte, bei denen bestehende Leitungen gemessen werden sollen, ohne diese für die Strommessung lösen zu müssen.

Positiv fallen vor allem die vielen Schnittstellen wie LAN, WLAN, MQTT, Webhooks und Scripting auf. Dadurch ist man nicht auf die Shelly-App beschränkt, sondern kann die Messwerte auch lokal auslesen und weiterverarbeiten.

Für einfache Verbraucher ist der Shelly Pro 3EM sicherlich überdimensioniert. Wer jedoch den Energieverbrauch eines Hauses, einer Unterverteilung oder größerer Stromkreise analysieren möchte, bekommt hier eine sehr flexible Grundlage. In den nächsten Teilen zeige ich daher, wie sich der Shelly Pro 3EM einrichten, mit Node-RED auslesen und für ein eigenes Energiedashboard nutzen lässt.

Häufige Fragen zum Shelly Pro 3EM

Was ist der Shelly Pro 3EM?

Der Shelly Pro 3EM ist ein Energiezähler für die Hutschiene. Er kann Strom, Spannung, Leistung und Energie auf bis zu drei Phasen messen und eignet sich damit für die Überwachung von Hausanschlüssen, Unterverteilungen oder größeren Stromkreisen.

Wofür eignet sich der Shelly Pro 3EM?

Der Shelly Pro 3EM eignet sich für die Energieanalyse im Smarthome, zur Überwachung des Hausverbrauchs, für Unterverteilungen, Werkstätten, Technikräume oder PV-Anwendungen. Besonders interessant ist das Gerät, wenn Messwerte später gespeichert, exportiert oder in einem Dashboard visualisiert werden sollen.

Was ist der Vorteil der 120A CT-Klemmen?

Die CT-Klemmen der 120A-Variante lassen sich öffnen und um eine vorhandene Leitung legen. Dadurch muss die Leitung für die Strommessung nicht gelöst werden. Gerade bei Nachrüstungen in bestehenden Verteilungen ist das ein großer Vorteil.

Muss man bei den CT-Klemmen auf die Richtung achten?

Ja. Auf der Unterseite der CT-Klemmen ist die Richtung mit K > L gekennzeichnet. In meinem Aufbau zeigt K in Richtung der Zuleitung und L in Richtung des Sicherungsautomaten. Wird die Klemme falsch herum montiert, können Messwerte mit falschem Vorzeichen angezeigt werden.

Kann der Shelly Pro 3EM auch einphasig betrieben werden?

Ja, der Shelly Pro 3EM kann auch einphasig betrieben werden. In diesem Fall wird die Phase gemäß dem Schaltbild auf dem Gehäuse an Klemme C angeschlossen, da der Shelly Pro 3EM seine eigene Versorgung über diese Klemme bezieht.

Warum kann es bei Klemme C zu einer kleinen Messabweichung kommen?

Der Shelly Pro 3EM verbraucht selbst eine geringe Menge Strom. Da sich das Gerät über Klemme C versorgt, kann dieser Eigenverbrauch auf dieser Phase eine kleine Abweichung verursachen. Laut technischen Daten liegt die Leistungsaufnahme bei unter 3 W.

Kann der Shelly Pro 3EM Verbraucher schalten?

Nein, der Shelly Pro 3EM ist kein Schaltaktor. Er misst Strom, Spannung, Leistung und Energie, besitzt aber kein integriertes Relais zum Schalten von Verbrauchern.

Welche Schnittstellen unterstützt der Shelly Pro 3EM?

Der Shelly Pro 3EM unterstützt unter anderem WLAN, LAN, Bluetooth, MQTT, Webhooks, Scripting sowie den Datenabruf über lokale Schnittstellen. Dadurch lässt er sich gut in Systeme wie Node-RED, Home Assistant oder eigene Monitoring-Lösungen integrieren.

Kann man die Messwerte des Shelly Pro 3EM exportieren?

Ja, Messwerte können exportiert oder über Schnittstellen lokal abgefragt werden. Für meine Beitragsreihe ist geplant, die Daten mit Node-RED abzurufen, in SQLite zu speichern und später als CSV-Datei bereitzustellen.

Wie lange speichert der Shelly Pro 3EM Messdaten intern?

Der Shelly Pro 3EM kann Messdaten intern für mindestens 60 Tage mit einer Auflösung von einer Minute speichern. Für langfristige Auswertungen ist es dennoch sinnvoll, die Daten zusätzlich lokal zu speichern.

Muss der Shelly Pro 3EM von einer Elektrofachkraft installiert werden?

Ja. Der Shelly Pro 3EM wird in der Unterverteilung bzw. im Schaltschrank installiert. Arbeiten an 230V/400V-Anlagen dürfen ausschließlich von einer Elektrofachkraft durchgeführt werden.

[draegerit]

Badlüfter mit Shelly nachlaufen lassen – smarte Lüftersteuerung fürs Badezimmer

Ein Badezimmer ohne Fenster oder mit nur unzureichender Entlüftung kennt wohl jeder: Nach dem Duschen bleibt die feuchte Luft lange im Raum stehen, der Spiegel beschlägt und auch unangenehme Gerüche verschwinden nicht sofort. Häufig ist in solchen Räumen ein einfacher Rohrlüfter verbaut, der zusammen mit dem Licht eingeschaltet wird. Wird das Licht ausgeschaltet, stoppt jedoch oft auch direkt der Lüfter.

Genau hier ist eine Lüfternachlaufsteuerung sinnvoll.

https://youtu.be/TkAQDPhdiuo

Der Badlüfter läuft nach dem Ausschalten des Lichts noch für eine bestimmte Zeit weiter und sorgt so dafür, dass Feuchtigkeit und Gerüche besser abgeführt werden. Klassisch wird dafür häufig ein Nachlaufrelais verwendet. In diesem Beitrag zeige ich dir jedoch, wie du eine solche Steuerung mit Shelly-Geräten deutlich flexibler umsetzen kannst.

Dabei schauen wir uns verschiedene Möglichkeiten an: von einer einfachen Lösung mit zwei Shelly 1 Mini über eine kompakte Variante mit einem Shelly 2PM bis zu einer erweiterten Steuerung mit Shelly Plus 1 oder Shelly Plus 1PM, Add-on und DHT22-Sensor. Damit kann der Lüfter nicht nur zeitgesteuert nachlaufen, sondern bei Bedarf auch automatisch starten, wenn die Luftfeuchtigkeit im Badezimmer einen bestimmten Wert überschreitet.

In diesem Beitrag erfährst du, welche Shelly-Variante sich für welchen Anwendungsfall eignet, wie die grundsätzliche Schaltung aufgebaut ist und welche Automationen für eine smarte Badlüftersteuerung sinnvoll sind.

Warum nicht einfach ein klassisches Lüfternachlaufrelais?

Für genau diesen Anwendungsfall gibt es klassische Lüfternachlaufrelais. Diese werden häufig direkt in Verbindung mit Badlüftern eingesetzt und haben einen großen Vorteil: Die Nachlaufzeit lässt sich meist recht einfach über ein kleines Potentiometer oder eine feste Einstellung vorgeben.

Zeitschalter für eine Lüfternachlaufsteuerung

Die Schaltung bleibt dadurch übersichtlich und der Lüfter läuft nach dem Ausschalten des Lichts noch für die eingestellte Zeit weiter.

Für eine einfache Badezimmerlüftung ist das bereits eine solide Lösung.

Die Shelly-Variante bietet jedoch deutlich mehr Möglichkeiten. Neben einer frei anpassbaren Nachlaufzeit kann die Steuerung später erweitert, per App angepasst oder in ein Smarthome-System eingebunden werden. Besonders interessant wird es, wenn ein Shelly Plus 1 oder Shelly Plus 1PM mit einem Add-on und einem DHT22-Sensor kombiniert wird. Dadurch lässt sich nicht nur eine feste Nachlaufzeit realisieren, sondern auch die Luftfeuchtigkeit im Badezimmer auswerten.

Steigt die Luftfeuchtigkeit nach dem Duschen beispielsweise über einen bestimmten Wert, kann der Lüfter automatisch eingeschaltet werden. Sinkt die Luftfeuchtigkeit wieder, wird der Lüfter wieder ausgeschaltet oder nach einer zusätzlichen Sicherheitszeit deaktiviert. Damit arbeitet die Lüftersteuerung nicht nur nach Zeit, sondern tatsächlich nach Bedarf.

einfache Lüfternachlaufsteuerung mit Zeitschalter

Sicherheitshinweis zum Anschluss

Die hier verwendeten Shelly-Module werden direkt mit 230 V Wechselspannung betrieben und in der Regel in einer Unterputzdose oder Anschlussdose installiert. Arbeiten an elektrischen Anlagen sind gefährlich. Bei 230 V AC besteht akute Lebensgefahr durch Stromschlag.

Daher gilt: Der Anschluss darf nur von einer Elektrofachkraft durchgeführt werden. Besonders im Badezimmer müssen zusätzlich die geltenden Schutzbereiche, geeignete Installationsorte und passendes Installationsmaterial beachtet werden.

Vor Arbeiten an elektrischen Anlagen gelten die fünf Sicherheitsregeln:

- Freischalten - gegen Wiedereinschalten sichern - Spannungsfreiheit feststellen - Erden und Kurzschließen - benachbarte, unter Spannung stehende Teile abdecken oder abschranken

Wichtig: Die Spannungsfreiheit muss fachgerecht und allpolig festgestellt werden. Dafür wird ein geeigneter zweipoliger Spannungsprüfer verwendet. Einpolige Phasenprüfer-Schraubendreher oder berührungslose Spannungsprüfer sind hierfür nicht geeignet.

Schaltung: Badlüfter mit Shelly Plus 2PM nachlaufen lassen

Die einfachste Variante für eine smarte Lüfternachlaufsteuerung ist der Aufbau mit einem Shelly Plus 2PM. Dieses Shelly-Modul verfügt über zwei getrennt schaltbare Ausgänge. Dadurch lassen sich Lampe und Badlüfter separat ansteuern, obwohl beide über ein gemeinsames Shelly-Gerät gesteuert werden.

Shelly 2PM Gen2 - Vorderseite

Shelly 2PM Gen2 - Schraubklemmen

Shelly 2PM Gen2 - Rückseite

Shelly 2PM Gen2 mit AddOn

In dieser Schaltung wird die Badezimmerlampe an O1 angeschlossen. Der Rohrlüfter wird an O2 angeschlossen. Der vorhandene Lichtschalter wird mit dem Eingang S1 des Shelly verbunden. Wird der Schalter betätigt, erkennt der Shelly den Schaltvorgang und kann daraufhin die Lampe einschalten. Gleichzeitig kann über eine Automation der Lüfter gestartet und später mit einer Nachlaufzeit wieder ausgeschaltet werden.

Schaltung einer Lüfternachlaufsteuerung mit Shelly Plus 2PM

Der große Vorteil dieser Lösung ist der sehr übersichtliche Aufbau. Es wird nur ein Shelly-Gerät benötigt, und beide Verbraucher können trotzdem unabhängig voneinander geschaltet werden. So kann die Lampe sofort mit dem Schalter ein- und ausgeschaltet werden, während der Lüfter nach dem Ausschalten des Lichts noch einige Minuten weiterläuft.

Benötigtes Material

Für diese Schaltung werden folgende Komponenten benötigt:

- Shelly Plus 2PM* - Rohrlüfter* für 230 V - Lampe - Schalter - geeignete Zuleitung - passende Anschlussklemmen bzw. Installationsmaterial

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!

Beim Einsatz im Badezimmer ist besonders darauf zu achten, dass der verwendete Schalter für Feuchträume geeignet ist. Außerdem müssen die geltenden Schutzbereiche im Badezimmer berücksichtigt werden. Arbeiten an 230 V dürfen nur von einer Elektrofachkraft durchgeführt werden.

Grundprinzip der Schaltung

Der Shelly Plus 2PM übernimmt in dieser Variante die Steuerung von zwei getrennten Verbrauchern:

- O1: Lampe - O2: Badlüfter - S1: Eingang für den Lichtschalter

Wird der Lichtschalter betätigt, schaltet der Shelly die Lampe ein. Zusätzlich kann der Lüfter entweder sofort mit eingeschaltet oder erst über eine Automation gestartet werden. Sobald das Licht ausgeschaltet wird, bleibt der Lüfter noch für eine definierte Zeit aktiv. Nach Ablauf dieser Nachlaufzeit wird der Lüfter automatisch ausgeschaltet.

Lüfternachlaufsteuerung mit Shelly 2PM - deaktiviert

Lüfternachlaufsteuerung mit Shelly 2PM - Lampe und Lüfter aktiviert

Lüfternachlaufsteuerung mit Shelly 2PM - Lampe deaktiviert und Lüfter läuft nach

Damit entsteht eine klassische Lüfternachlaufsteuerung, allerdings ohne zusätzliches Nachlaufrelais. Die Nachlaufzeit wird nicht mechanisch am Relais eingestellt, sondern komfortabel über die Shelly-App, die Weboberfläche oder später über ein Smarthome-System wie Home Assistant.

Shelly Skript für die Lüfternachlaufsteuerung mit einem Shelly 2PM

Nachfolgend findest du das Skript für die Lüfternachlaufsteuerung mit einem Shelly 2PM. Die Zeit welche der Lüfter nach dem deaktivieren der Lampe weiterlaufen soll wir im Feld "FAN_DELAY" eingestellt.

// Nachlaufzeit für den Lüfter in Sekunden. // In diesem Beispiel läuft der Lüfter nach dem Ausschalten des Lichts // noch 10 Sekunden weiter. // Für den echten Einsatz im Badezimmer wären z. B. 120 bis 300 Sekunden sinnvoll. const FAN_DELAY = 10; // Variable zum Speichern des laufenden Timers. // Wird benötigt, damit ein bereits gestarteter Nachlauf wieder abgebrochen // werden kann, wenn das Licht erneut eingeschaltet wird. let timerId = null; // Event-Handler registrieren. // Diese Funktion wird immer dann aufgerufen, wenn am Shelly ein Ereignis auftritt, // zum Beispiel wenn sich der Zustand eines Eingangs ändert. Shelly.addEventHandler(function (event) { // Prüfen, ob das Ereignis vom Eingang 0 kommt. // Beim Shelly Plus 2PM entspricht "input:0" dem ersten Eingang, // also dem Eingang S1. // // Andere Ereignisse, z. B. von Ausgängen oder anderen Eingängen, // werden ignoriert. if (event.component !== "input:0") return; // Den aktuellen Zustand des Eingangs auslesen. // true = Schalter/Taster ist eingeschaltet // false = Schalter/Taster ist ausgeschaltet let isOn = event.info.state; // Wenn der Schalter eingeschaltet wurde: if (isOn) { // Falls bereits ein Nachlauf-Timer aktiv ist, // wird dieser zuerst gestoppt. // // Beispiel: // Das Licht wurde ausgeschaltet und der Lüfter läuft nach. // Wird das Licht während dieser Nachlaufzeit wieder eingeschaltet, // darf der alte Timer den Lüfter nicht mehr ausschalten. if (timerId !== null) { Timer.clear(timerId); timerId = null; } // Ausgang 0 einschalten. // Beim Shelly Plus 2PM ist das der erste Schaltausgang. // In dieser Schaltung ist daran die Lampe angeschlossen. Shelly.call("Switch.Set", { id: 0, on: true }); // Ausgang 1 einschalten. // In dieser Schaltung ist daran der Lüfter angeschlossen. // // Dadurch läuft der Lüfter direkt mit, // sobald das Licht eingeschaltet wird. Shelly.call("Switch.Set", { id: 1, on: true }); } else { // Wenn der Schalter ausgeschaltet wurde: // Ausgang 0 sofort ausschalten. // Die Lampe geht also direkt aus, // sobald der Lichtschalter ausgeschaltet wird. Shelly.call("Switch.Set", { id: 0, on: false }); // Einen neuen Timer für den Lüfter-Nachlauf starten. // // Timer.set erwartet die Zeit in Millisekunden. // Deshalb wird FAN_DELAY mit 1000 multipliziert. // // Der zweite Parameter "false" bedeutet: // Der Timer wird nur einmal ausgeführt und wiederholt sich nicht. timerId = Timer.set(FAN_DELAY * 1000, false, function () { // Nach Ablauf der Nachlaufzeit wird Ausgang 1 ausgeschaltet. // Damit wird der Lüfter deaktiviert. Shelly.call("Switch.Set", { id: 1, on: false }); // Die Timer-ID wird zurückgesetzt. // Dadurch weiß das Script, dass aktuell kein Nachlauf-Timer mehr aktiv ist. timerId = null; }); } });

Alternative: Zwei Shelly Plus 1 Mini verwenden

Alternativ kann die Schaltung auch mit zwei einzelnen Shelly Plus 1 Mini aufgebaut werden. Dabei übernimmt ein Shelly die Steuerung der Lampe und der zweite Shelly die Steuerung des Badlüfters.

Schaltung - zwei mal Shelly Plus 1 Mini für Lüfternachlaufsteuerung mit Rohlüfter und Lampe

Diese Variante kann interessant sein, wenn Lampe und Lüfter räumlich oder elektrisch nicht sinnvoll gemeinsam über ein Shelly 2PM angeschlossen werden können. Der grundsätzliche Ablauf bleibt jedoch gleich: Die Lampe wird über den Schalter bedient, während der Lüfter nach dem Ausschalten des Lichts noch für eine definierte Zeit weiterlaufen kann.

Lüfternachlaufsteuerung mit zwei Shellys - Lampe und Lüfter deaktiviert

Lüfternachlaufsteuerung mit zwei Shellys - Lampe und Lüfter aktiviert

Lüfternachlaufsteuerung mit zwei Shellys - Lampe deaktiviert und Lüfter läuft einige Sekunden nach

Im direkten Vergleich ist der Shelly Plus 2PM für diese Anwendung meist die übersichtlichere Lösung, da beide Ausgänge in einem Gerät vorhanden sind. Außerdem lässt sich die Schaltung mit dem Shelly Add-on und einem DHT22-Sensor erweitern, um den Lüfter zusätzlich abhängig von der Luftfeuchtigkeit zu steuern.

Benötigtes Material

Für diese Schaltung werden folgende Komponenten benötigt:

- 2x Shelly Plus 1 Mini* - Rohrlüfter* für 230 V - Lampe - Schalter - geeignete Zuleitung - passende Anschlussklemmen bzw. Installationsmaterial

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!

Shelly Skript für die Lüfternachlaufsteuerung mit zwei Shelly

Nachfolgend das Skript für die Lösung mit zwei smarten Shellys in meinem Fall einmal ein Shelly Mini PM Gen3 für den Schalter + Lampe und einmal ein Shelly Plus 1 Gen4 für den Rohlüfter.

Wenn du das Skript kopierst musst du hier die IP Adresse des Gerätes für den Rohlüfter anpassen!

// Nachlaufzeit für den Lüfter in Sekunden. // In diesem Beispiel läuft der Lüfter nach dem Ausschalten des Lichts // noch 10 Sekunden weiter. // // Für den echten Einsatz im Badezimmer sind eher Werte wie // 120, 180 oder 300 Sekunden sinnvoll. const FAN_DELAY = 10; // IP-Adresse des zweiten Shelly. // An diesem Shelly ist der Lüfter angeschlossen. // // Wichtig: // Die IP-Adresse sollte im Router fest vergeben werden, // damit sich diese nicht irgendwann ändert. const FAN_SHELLY_IP = "192.168.178.198"; // Variable zum Speichern des aktiven Timers. // Wird benötigt, damit ein laufender Nachlauf-Timer // wieder abgebrochen werden kann. let timerId = null; // Funktion zum Schalten des Lüfters. // // Der Lüfter hängt nicht direkt an diesem Shelly, // sondern an einem zweiten Shelly im Netzwerk. // // Über einen HTTP-Request wird der zweite Shelly angesprochen. // Der Parameter "state" legt fest, ob der Lüfter ein- oder ausgeschaltet wird. // // true = Lüfter einschalten // false = Lüfter ausschalten function setFanState(state) { Shelly.call("HTTP.GET", { url: "http://" + FAN_SHELLY_IP + "/rpc/Switch.Set?id=0&on=" + state }); } // Event-Handler registrieren. // Diese Funktion wird immer dann ausgeführt, // wenn am Shelly ein Ereignis auftritt. Shelly.addEventHandler(function (event) { // Nur Ereignisse vom Eingang 0 verarbeiten. // Beim Shelly entspricht "input:0" dem ersten Eingang, // also dem angeschlossenen Lichtschalter oder Taster. // // Alle anderen Ereignisse werden ignoriert. if (event.component !== "input:0") return; // Aktuellen Zustand des Eingangs auslesen. // // true = Schalter ist eingeschaltet // false = Schalter ist ausgeschaltet let isOn = event.info.state; // Wenn der Schalter eingeschaltet wurde: if (isOn) { // Prüfen, ob noch ein Nachlauf-Timer aktiv ist. // // Beispiel: // Das Licht wurde ausgeschaltet und der Lüfter läuft noch nach. // Wird das Licht in dieser Zeit wieder eingeschaltet, // muss der alte Timer gestoppt werden. // // Sonst würde der Timer später trotzdem auslösen // und den Lüfter ausschalten, obwohl das Licht wieder an ist. if (timerId !== null) { Timer.clear(timerId); timerId = null; } // Ausgang 0 dieses Shelly einschalten. // Daran ist in dieser Variante die Lampe angeschlossen.

[draegerit]

MQTT kann mehr: So baust du deinen eigenen Chat mit Node-RED

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.

Vielleicht ist dieser kleine Chat ja der Einstieg in dein nächstes größeres IoT-Projekt.

[draegerit]

Docker-Container erreichen sich nicht? So löst du das Netzwerkproblem

Mit Docker lassen sich mehrere Dienste wie Mosquitto, Node-RED, Nginx oder Datenbanken schnell als eigene Container starten. Spannend wird es jedoch, sobald diese Container miteinander kommunizieren sollen.

Ein häufiger Fehler ist dabei, nur auf die IP-Adresse des Containers zu schauen. Unterschiedliche IP-Bereiche können zwar ein Hinweis auf unterschiedliche Docker-Netzwerke sein, entscheidend ist aber: In welchem Netzwerk hängt der Container wirklich?

Docker bringt standardmäßig das Netzwerk bridge mit. Wird ein Container ohne eigene Netzwerkangabe erstellt, landet er meist dort. Wird er später mit docker start erneut gestartet, bekommt er keine neue Netzwerkkonfiguration, sondern verwendet weiterhin die ursprüngliche.

Für einfache Tests kann das funktionieren. Für saubere Setups ist jedoch ein eigenes Docker-Netzwerk oder Docker Compose meist die bessere Lösung.

https://youtu.be/N7QYUKZE-HM

In diesem Beitrag zeige ich dir anhand von Node-RED und Mosquitto, wie du das Netzwerk deiner Container prüfst und sie sauber miteinander verbindest.

Ausgangslage: Zwei Container, aber unterschiedliche Netzwerke

In meinem Beispiel laufen zwei Dienste als Docker-Container. Zum einen Node-RED für die Automatisierung und Verarbeitung der Daten, zum anderen Mosquitto als MQTT-Broker.

Beide Container wurden erfolgreich gestartet und sind vom Host-System aus erreichbar. Node-RED lässt sich zum Beispiel über den Browser öffnen, und auch der Mosquitto-Broker läuft grundsätzlich. Auf den ersten Blick sieht also alles korrekt aus.

Beim Blick auf die internen Docker-IP-Adressen zeigt sich jedoch ein wichtiger Unterschied:

Docker - zugewiesene IP-Adressen der gestarteten Container

Mosquitto läuft in diesem Beispiel unter der IP-Adresse 172.19.0.2, während Node-RED die IP-Adresse 172.18.0.2 erhalten hat. Die unterschiedlichen IP-Bereiche sind ein deutlicher Hinweis darauf, dass beide Container nicht im selben Docker-Netzwerk hängen. Sicher prüfen lässt sich das jedoch erst über die tatsächliche Netzwerkzuordnung des Containers.

$ docker inspect -f '{{range $name, $network := .NetworkSettings.Networks}}{{println $name $network.IPAddress}}{{end}}' nodered bridge 172.17.0.3 $ docker inspect -f '{{range $name, $network := .NetworkSettings.Networks}}{{println $name $network.IPAddress}}{{end}}' mosquitto bridge 172.17.0.2

Genau hier liegt das Problem: Nur weil beide Container vom PC aus erreichbar sind, bedeutet das nicht automatisch, dass sie auch untereinander kommunizieren können.

Der Host-Rechner kann die Container über veröffentlichte Ports erreichen, zum Beispiel Node-RED über den Browser oder Mosquitto über den MQTT-Port. Die direkte Kommunikation zwischen zwei Containern läuft jedoch über das Docker-Netzwerk. Befinden sich die Container nicht im selben Netzwerk, kann Node-RED den Mosquitto-Broker nicht ohne Weiteres erreichen.

In meinem Fall war genau das die Ursache: Beide Dienste liefen korrekt, aber Node-RED konnte keine Verbindung zum Mosquitto-Broker aufbauen, weil beide Container in unterschiedlichen Docker-Netzwerken gestartet wurden.

Container-ID und Namen der Container ermitteln

Bevor die interne IP-Adresse eines Docker-Containers ausgelesen werden kann, muss zunächst bekannt sein, wie der Container heißt. Alternativ kann auch die Container-ID verwendet werden.

Damit die Ausgabe von Docker übersichtlich bleibt, kann man sich mit folgendem Befehl nur die Container-ID und den Namen anzeigen lassen:

docker ps --format "table {{.ID}}t{{.Names}}"

Die Ausgabe sieht dann zum Beispiel so aus:

Ausgabe der Container ID und Names der Docker Container

In diesem Beispiel heißt der Node-RED-Container nodered und der Mosquitto-Container mosquitto. Diese Namen können anschließend direkt für den docker inspect-Befehl verwendet werden.

Die IP-Adresse des Node-RED-Containers lässt sich zum Beispiel so auslesen:

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' nodered

Für den Mosquitto-Container entsprechend:

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mosquitto

Alternativ kann statt des Containernamens auch die Container-ID verwendet werden. In der Praxis ist der Name jedoch meist deutlich lesbarer und einfacher zu merken.

Docker-Netzwerk erstellen

Damit sich die Container gegenseitig erreichen können, erstellen wir zuerst ein eigenes Docker-Netzwerk. In meinem Beispiel verwende ich den Namen iot-net.

Der Befehl dazu lautet:

docker network create iot-net

Docker Netzwerk erstellt

Damit legt Docker ein neues benutzerdefiniertes Netzwerk an. Der Name iot-net ist frei gewählt und kann natürlich angepasst werden.

Nach dem Erstellen müssen die gewünschten Container noch mit diesem Netzwerk verbunden werden.

Container mit dem Docker-Netzwerk verbinden

Nun verbinden wir beide Services mit dem zuvor erstellten Netzwerk iot-net. In meinem Beispiel heißen die Container nodered und mosquitto.

Docker Container zu einem Netzwerk verbunden

Dazu werden folgende Befehle ausgeführt:

docker network connect iot-net nodered docker network connect iot-net mosquitto

Damit werden beide bereits laufenden Container zusätzlich mit dem Docker-Netzwerk iot-net verbunden.

Anschließend kann geprüft werden, ob beide Container wirklich im Netzwerk vorhanden sind:

docker network inspect iot-net --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

Die Ausgabe sieht in meinem Fall so aus:

mosquitto 172.21.0.3/16 nodered 172.21.0.2/16

Jetzt befinden sich beide Container im selben Docker-Netzwerk und können sich darüber gegenseitig erreichen. Wichtig ist dabei nicht mehr die direkte IP-Adresse, sondern der Containername. Node-RED kann Mosquitto nun also über den Namen mosquitto und den Port 1883 ansprechen.

Container wieder aus dem Docker-Netzwerk entfernen

Falls ein Container später nicht mehr Teil des Netzwerks sein soll, kann die Verbindung wieder getrennt werden. Der Container selbst wird dabei nicht gelöscht, sondern nur vom Netzwerk iot-net entfernt.

Für Node-RED:

docker network disconnect iot-net nodered

Für Mosquitto:

docker network disconnect iot-net mosquitto

Anschließend kann wieder geprüft werden, ob noch Container mit dem Netzwerk verbunden sind:

docker network inspect iot-net --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

Wenn keine Ausgabe mehr erscheint, sind keine Container mehr mit diesem Netzwerk verbunden.

Nun kann das Docker-Netzwerk vollständig gelöscht werden:

docker network rm iot-net

Wichtig: Ein Docker-Netzwerk kann nur gelöscht werden, wenn keine Container mehr damit verbunden sind. Falls Docker hier eine Fehlermeldung ausgibt, sollte zuerst geprüft werden, welche Container noch im Netzwerk hängen.

Container aus dem Docker-Netzwerk entfernen

Docker Compose Variante

Wenn Node-RED und Mosquitto dauerhaft gemeinsam betrieben werden sollen, ist Docker Compose meist die bessere Lösung. Der große Vorteil: Das Netzwerk kann direkt in der docker-compose.yml definiert werden. Dadurch muss man die Container nicht nachträglich per docker network connect miteinander verbinden.

Ein einfaches Beispiel könnte so aussehen:

services: mosquitto: image: eclipse-mosquitto container_name: mosquitto ports: - "1883:1883" networks: - iot-net nodered: image: nodered/node-red container_name: nodered ports: - "1880:1880" volumes: - node_red_data:/data networks: - iot-net volumes: node_red_data: networks: iot-net: name: iot-net driver: bridge

Gestartet wird das Setup anschließend mit:

docker compose up -d

oder wenn du den Dateinamen angepasst hast:

docker compose -f docker-compose-nodered_mosquitto.yml up -d

Docker Compose - Container via YAML im selben Netzwerk starten

Docker Compose erstellt nun automatisch das Netzwerk iot-net und verbindet beide Container damit. Dadurch befinden sich Node-RED und Mosquitto direkt im selben Docker-Netzwerk.

Innerhalb von Node-RED wird als MQTT-Broker dann nicht die IP-Adresse des Mosquitto-Containers eingetragen, sondern einfach der Servicename bzw. Containername: mosquitto

Der Port bleibt: 1883

Also lautet die Verbindung in Node-RED: mosquitto:1883

Node-RED verbindung zu Mosquitto

Der Vorteil dieser Lösung ist, dass Docker Compose das Netzwerk bei jedem Start automatisch korrekt einrichtet. Dadurch entfällt das manuelle Erstellen und Verbinden per docker network create und docker network connect.

Fazit

Wenn sich Docker-Container nicht gegenseitig erreichen, liegt die Ursache häufig nicht an der Anwendung selbst, sondern am verwendeten Docker-Netzwerk. Interne IP-Adressen wie 172.18.0.2 oder 172.19.0.2 wirken zwar auf den ersten Blick eindeutig, sind für die Kommunikation zwischen Containern aber oft nicht die beste Lösung.

Wichtiger ist, dass sich die betreffenden Container im selben Docker-Netzwerk befinden. Erst dann können sie sich zuverlässig untereinander erreichen – idealerweise über ihren Container- oder Servicenamen statt über eine feste IP-Adresse.

Für schnelle Tests lässt sich ein gemeinsames Netzwerk bequem per docker network create und docker network connect aufbauen. Wer mehrere Dienste dauerhaft betreibt, fährt mit Docker Compose meist noch besser, da sich Netzwerk, Container und Ports direkt in einer zentralen Datei definieren lassen.

Am Ende gilt also: Nicht die IP-Adresse ist entscheidend, sondern das richtige Docker-Netzwerk. Ist dieses sauber eingerichtet, funktioniert auch die Kommunikation zwischen den Containern zuverlässig.

[draegerit]

Node-RED Status: So zeigst du Zustände in eigenen Nodes

Statusinformationen in Node-RED direkt an der jeweiligen Node darzustellen, ist besonders dann hilfreich, wenn ein Flow mit mehreren Verbindungen, Abfragen oder externen Geräten arbeitet. Natürlich kann man solche Informationen auch über eine zusätzliche Debug-Ausgabe sichtbar machen. Bei größeren Flows wird das jedoch schnell unübersichtlich: Der Flow wächst unnötig an, und im Debug-Fenster gehen wichtige Meldungen zwischen vielen anderen Ausgaben leicht unter.

https://youtu.be/4QrFBEs_Xn8

Genau hier kommt das Feature Node Status ins Spiel. Damit lassen sich kurze Statusmeldungen direkt unterhalb einer Node anzeigen — also genau dort, wo die Information entsteht. Ob eine Verbindung aktiv ist, ein Fehler aufgetreten ist oder gerade Daten verarbeitet werden: Der Status bleibt sauber an der auslösenden Node hängen und macht den Flow deutlich übersichtlicher und besser nachvollziehbar.

Ein erstes Beispiel mit node.status()

Am einfachsten lässt sich die Statusanzeige mit einer Function Node testen. Dafür muss keine eigene Custom Node erstellt werden. Es reicht aus, eine Function Node in den Flow zu ziehen und dort folgenden Code einzufügen:

node.status({ fill: "blue", shape: "ring", text: "Hello World!" });

Nach dem Deploy wird direkt unterhalb der Function Node der Text Hello World! angezeigt. Zusätzlich erscheint ein blauer Ring als Statussymbol. Damit sieht man sofort, wie einfach sich Informationen direkt an einer Node darstellen lassen.

Node-RED - Node Status - Beispiel "Hello World!"

Der große Vorteil: Die Information bleibt genau dort sichtbar, wo sie entsteht. Es wird keine zusätzliche Debug Node benötigt und der Flow bleibt sauber und übersichtlich.

Die Parameter von node.status()

Die Statusanzeige wird über ein kleines JavaScript-Objekt gesteuert. Dieses Objekt besteht aus drei möglichen Eigenschaften: fill, shape und text.

node.status({ fill: "blue", shape: "ring", text: "Hello World!" }); fill – die Farbe des Symbols

Mit fill legst du die Farbe des Statussymbols fest. Mögliche Werte sind:

- red - yellow - green - blue - grey

Wichtig: In der offiziellen Node-RED-Dokumentation wird grey verwendet, nicht gray.

shape – die Form des Symbols

Mit shape bestimmst du, wie das Statussymbol dargestellt wird.

- dot zeigt einen ausgefüllten Kreis an. - ring zeigt einen Kreis mit weißer Mitte an. text – die Statusmeldung

Mit text wird die Nachricht festgelegt, die direkt neben dem farbigen Symbol angezeigt wird.

Beispiel:

node.status({ fill: "green", shape: "dot", text: "verbunden" });

Damit erscheint unterhalb der Node ein grüner ausgefüllter Punkt mit dem Text verbunden.

Status ohne Symbol: Emoji im Text verwenden

Die Parameter fill und shape sind optional. Lässt man beide weg, wird kein farbiges Statussymbol angezeigt. Das kann praktisch sein, wenn man stattdessen direkt im Statustext mit einem Emoji arbeiten möchte.

Ein gutes Beispiel ist eine Fehlermeldung mit einem Warnsymbol:

node.status({text: "🚨 Fehler - E001 - Keine Verbindung!"}); return msg;

In diesem Fall zeigt Node-RED keinen zusätzlichen Punkt oder Ring an. Stattdessen erscheint nur der Text unterhalb der Node. Durch das Emoji am Anfang der Meldung fällt der Status trotzdem sofort ins Auge.

Das eignet sich besonders gut für kurze und auffällige Hinweise, zum Beispiel:

node.status({ text: "✅ Verbindung hergestellt" }); node.status({ text: "⚠️ Warte auf Antwort" }); node.status({ text: "🚨 Fehler - E001 - Keine Verbindung!" }); node.status({ text: "🔄 Verarbeitung läuft" });

Damit lassen sich Statusmeldungen sehr flexibel gestalten, ohne zwingend auf die vordefinierten Farben und Formen angewiesen zu sein. Gerade bei Fehlern oder besonderen Zuständen kann ein Emoji die Lesbarkeit im Flow deutlich verbessern.

Eigene Status-Node für Node-RED

Für einfache Tests reicht node.status() in einer Function Node vollkommen aus. Wenn der Status aber bewusst an einer bestimmten Stelle im Flow angezeigt werden soll, wird es mit normalen Function Nodes schnell unpraktisch. Genau dafür habe ich die Custom Node node-red-contrib-status-display erstellt.

Node-RED - Custom Status Node mit aktiven Status

Du findest das Projekt auf GitHub: https://github.com/StefanDraeger/node-red-contrib-status-display

Die Idee dahinter ist einfach: In einer Function Node wird ein Statusobjekt erzeugt und über msg.status weitergegeben.

msg.status = { index: 0, fill: "green", shape: "dot", text: "Verbindung hergestellt"}; return msg;

Mit einem leeren JSON kann der zuvor gesetzte Status gelöscht werden:

msg.status = {}; return msg;

Die Custom Node liest diese Information aus und zeigt den Status direkt im Flow an. Dadurch lassen sich Statusmeldungen sauber darstellen, ohne zusätzliche Debug Nodes einzubauen oder den Flow unnötig aufzublähen.

Das eignet sich besonders gut für:

- Verbindungsstatus - Fehlermeldungen - Wartezustände - laufende Prozesse - externe Geräte - APIs - TCP/UDP-Kommunikation - eigene Node-RED Flows

So kannst du sehr einfach eine Statusmeldung an eine dafür vorgesehene Node hängen und deinen Flow deutlich übersichtlicher gestalten.

Fazit

Mit node.status() bietet Node-RED eine einfache, aber sehr nützliche Möglichkeit, Zustände direkt im Flow sichtbar zu machen. Gerade bei größeren Projekten ist das deutlich übersichtlicher als zusätzliche Debug-Nodes oder lange Ausgaben im Debug-Fenster.

Ob Verbindung hergestellt, Fehler aufgetreten oder Prozess läuft — die Information erscheint direkt an der passenden Node und ist damit sofort nachvollziehbar. Besonders praktisch ist dabei, dass sich Statusmeldungen nicht nur mit Farben und Formen, sondern auch mit Emojis sehr flexibel gestalten lassen.

Für einfache Fälle reicht die direkte Nutzung in einer Function-Node vollkommen aus. Wenn Statusmeldungen jedoch gezielt an einer eigenen Stelle im Flow angezeigt werden sollen, bietet sich eine kleine Custom-Node wie node-red-contrib-status-display an. Damit lassen sich Statusinformationen sauber über msg.status übergeben und direkt sichtbar machen.

So bleiben Node-RED-Flows aufgeräumt, verständlich und deutlich leichter zu analysieren.

FAQ – Häufige Fragen zu Node-RED Statusmeldungen

Was macht node.status() in Node-RED?

Mit node.status() kannst du direkt unterhalb einer Node eine kurze Statusmeldung anzeigen. Diese besteht optional aus einem farbigen Symbol, einer Form und einem Text.

node.status({ fill: "green", shape: "dot", text: "verbunden" });

Kann ich mit node.status() den Status einer anderen Node ändern?

Nein. node.status() setzt immer nur den Status der Node, in der der Code ausgeführt wird. In einer Function-Node wird also nur der Status dieser Function-Node geändert.

Welche Farben kann ich für fill verwenden?

Für fill können folgende Farben genutzt werden:

- red - yellow - green - blue - grey

Wichtig ist die Schreibweise grey, nicht gray.

Welche Formen gibt es für shape?

Für shape gibt es zwei mögliche Werte:

- dot zeigt einen ausgefüllten Kreis an. - ring zeigt einen Kreis mit weißer Mitte an. Sind fill und shape Pflicht?

Nein, beide Parameter sind optional. Wenn du nur einen Text anzeigen möchtest, reicht auch:

node.status({ text: "🚨 Fehler - E001 - Keine Verbindung!" });

Dann wird kein zusätzliches Symbol angezeigt.

Kann ich Emojis im Node-Status verwenden?

Ja, Emojis können direkt im text verwendet werden. Das eignet sich besonders gut für auffällige Statusmeldungen wie Fehler, Warnungen oder erfolgreiche Verbindungen.

node.status({ text: "✅ Verbindung hergestellt" });

Wie kann ich den Status wieder löschen?

Der Status kann mit einem leeren Objekt entfernt werden:

node.status({});

Wofür ist eine eigene Status-Node sinnvoll?

Eine eigene Status-Node ist sinnvoll, wenn Statusmeldungen nicht an der Function-Node selbst, sondern an einer bestimmten Stelle im Flow angezeigt werden sollen. So bleibt der Flow übersichtlich und Statusinformationen können gezielt dargestellt werden.

Wie übergebe ich einen Status an die Custom-Node?

In einer Function-Node wird der Status über msg.status gesetzt:

msg.status = { fill: "blue", shape: "ring", text: "Hello World!" }; return msg;

Die Custom-Node liest dieses Objekt aus und zeigt den Status direkt an der eigenen Node an.