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.
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.

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.

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.

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.
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ösung | Vorteile | Nachteile | Geeignet für |
|---|---|---|---|
| microSD-Karte | günstig, einfach, direkt nutzbar, keine Zusatzhardware nötig | begrenzte Schreibzyklen, Qualität stark unterschiedlich, bei vielen Schreibzugriffen nicht ideal | kleine Node-RED-Projekte, einfache Automationen, wenige Schreibvorgänge |
| USB-Stick | günstig, schnell angeschlossen, entlastet die microSD-Karte | ebenfalls Flash-Speicher, Qualität stark unterschiedlich, nicht ideal für dauerhafte hohe Schreiblast | einfache Auslagerung von Logs, Backups oder kleineren Daten |
| externe USB-SSD | robuster als USB-Stick, besser für viele Schreibzugriffe, gute Geschwindigkeit | etwas teurer, benötigt mehr Platz, ggf. mehr Strom | Datenbanken, Logs, Home Assistant, Docker, dauerhafte Smarthome-Projekte |
| NVMe HAT mit SSD | sehr schnell, kompakt, saubere Lösung für den Raspberry Pi, gut für Dauerbetrieb | teurer, Zusatzhardware nötig, Kompatibilität zum Raspberry-Pi-Modell beachten | Mini-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.

Flow JSON für MQTT-Sensorwert und Context Stores anzeigen
[
{
"id": "b9a1e07bb447b3d1",
"type": "tab",
"label": "MQTT Sensorwert Context Stores",
"disabled": false,
"info": ""
},
{
"id": "a76cb3e22604cfa1",
"type": "inject",
"z": "b9a1e07bb447b3d1",
"name": "Zufälligen Sensorwert erzeugen",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "sensor/wohnzimmer/temperatur",
"payload": "",
"payloadType": "date",
"x": 180,
"y": 80,
"wires": [
[
"a8d74225924844ad"
]
]
},
{
"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));\n\nmsg.payload = zufallswert;\nmsg.topic = \"sensor/wohnzimmer/temperatur\";\n\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 450,
"y": 80,
"wires": [
[
"c6b41cbdf945d245"
]
]
},
{
"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": [
[
"d49a39e499a62e39"
]
]
},
{
"id": "d49a39e499a62e39",
"type": "function",
"z": "b9a1e07bb447b3d1",
"name": "Sensorwert aufbereiten",
"func": "let sensorwert = Number(msg.payload);\n\nlet 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});\n\nmsg.payload = {\n sensor: \"Wohnzimmer\",\n typ: \"Temperatur\",\n wert: sensorwert,\n einheit: \"°C\",\n zeitstempel: zeitstempel\n};\n\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 470,
"y": 180,
"wires": [
[
"d127437b75dc028f",
"aa4f11d9d23c2966",
"cefc0e1283c6127a"
]
]
},
{
"id": "d127437b75dc028f",
"type": "function",
"z": "b9a1e07bb447b3d1",
"name": "Speichern im RAM",
"func": "flow.set(\"temperaturAktuell\", msg.payload, \"memoryOnly\");\n\nmsg.payload = {\n speicher: \"memoryOnly / RAM\",\n hinweis: \"Wert wird nur im Arbeitsspeicher gespeichert und ist nach Neustart weg.\",\n daten: msg.payload\n};\n\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 760,
"y": 140,
"wires": [
[
"f1d7614754987db7"
]
]
},
{
"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;\n\nif (geaendert) {\n flow.set(\"temperaturLetzteSD\", msg.payload, \"sdcard\");\n}\n\nmsg.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.payload\n};\n\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 780,
"y": 200,
"wires": [
[
"c59297df356bc865"
]
]
},
{
"id": "cefc0e1283c6127a",
"type": "function",
"z": "b9a1e07bb447b3d1",
"name": "Speichern auf USB-Stick",
"func": "flow.set(\"temperaturLetzteUSB\", msg.payload, \"usbstick\");\n\nmsg.payload = {\n speicher: \"usbstick / localfilesystem\",\n hinweis: \"Wird persistent auf dem USB-Stick gespeichert. flushInterval 30 schreibt häufiger als der SD-Karten-Store.\",\n daten: msg.payload\n};\n\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 790,
"y": 260,
"wires": [
[
"cfc2bbf04767f75a"
]
]
},
{
"id": "f1d7614754987db7",
"type": "debug",
"z": "b9a1e07bb447b3d1",
"name": "RAM / memoryOnly",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"x": 1070,
"y": 140,
"wires": []
},
{
"id": "c59297df356bc865",
"type": "debug",
"z": "b9a1e07bb447b3d1",
"name": "SD-Karte / sdcard",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"x": 1070,
"y": 200,
"wires": []
},
{
"id": "cfc2bbf04767f75a",
"type": "debug",
"z": "b9a1e07bb447b3d1",
"name": "USB-Stick / usbstick",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"x": 1080,
"y": 260,
"wires": []
},
{
"id": "ec3f5f670a624e22",
"type": "mqtt-broker",
"name": "Lokaler MQTT Broker",
"broker": "localhost",
"port": "1883",
"clientid": "",
"autoConnect": true,
"usetls": false,
"protocolVersion": "4",
"keepalive": "60",
"cleansession": true,
"birthTopic": "",
"birthQos": "0",
"birthPayload": "",
"birthMsg": {},
"closeTopic": "",
"closeQos": "0",
"closePayload": "",
"closeMsg": {},
"willTopic": "",
"willQos": "0",
"willPayload": "",
"willMsg": {},
"userProps": "",
"sessionExpiry": ""
}
]
In diesem Beispiel empfängt Node-RED einen Sensorwert per MQTT. Anschließend wird dieser Wert auf drei unterschiedliche Arten gespeichert:
- im Arbeitsspeicher
- persistent auf der SD-Karte
- persistent auf einem USB-Stick
Damit lässt sich gut zeigen, dass nicht jeder Sensorwert automatisch auf der SD-Karte landen muss. Du kannst in Node-RED gezielt entscheiden, welche Daten nur flüchtig im RAM gespeichert werden und welche Werte dauerhaft erhalten bleiben sollen.
Vorbereitung in der settings.js
Damit das funktioniert, werden mehrere Context Stores in der settings.js definiert.
contextStorage: {
default: "memoryOnly",
memoryOnly: {
module: "memory"
},
sdcard: {
module: "localfilesystem",
config: {
dir: "/home/stefandraeger/.node-red/context-sdcard",
cache: true,
flushInterval: 180
}
},
usbstick: {
module: "localfilesystem",
config: {
dir: "/mnt/usb/node-red-context",
cache: true,
flushInterval: 30
}
}
},
In dieser Konfiguration gibt es drei Speicherbereiche:
| Store | Speicherort | Zweck |
|---|---|---|
memoryOnly | Arbeitsspeicher | aktuelle Werte, die nach einem Neustart nicht erhalten bleiben müssen |
sdcard | Dateisystem auf der SD-Karte | wichtige Werte, die persistent gespeichert werden sollen |
usbstick | externer USB-Stick | ausgelagerte persistente Werte, um die SD-Karte zu entlasten |
Der Standard-Store ist hier memoryOnly. Das bedeutet: Wenn kein Store explizit angegeben wird, landen Werte zunächst nur im Arbeitsspeicher.
Die SD-Karte wird mit einem längeren flushInterval von 180 Sekunden verwendet. Dadurch werden die Context-Daten nicht ständig geschrieben, sondern gepuffert und erst in größeren Abständen ins Dateisystem geschrieben.
Der USB-Stick verwendet in diesem Beispiel ein kürzeres flushInterval von 30 Sekunden und speichert die Daten unter:
/mnt/usb/node-red-context
Wichtig: Dieser Pfad muss existieren und für den Benutzer, unter dem Node-RED läuft, beschreibbar sein.
Aufbau des Flows
Der Beispiel-Flow besteht aus zwei Teilen.
Im ersten Teil wird ein zufälliger Sensorwert erzeugt und per MQTT veröffentlicht. Dadurch lässt sich das Beispiel auch ohne echten Sensor testen.
Im zweiten Teil empfängt Node-RED diesen MQTT-Wert wieder und speichert ihn in den unterschiedlichen Context Stores.
Der Flow zeigt damit drei typische Fälle:
| Speicherart | Verhalten |
|---|---|
RAM / memoryOnly | schnell, keine Schreibzugriffe auf SD-Karte, nach Neustart weg |
SD-Karte / sdcard | persistent, aber mit längerem Schreibintervall |
USB-Stick / usbstick | persistent, aber auf externes Medium ausgelagert |
Sensorwert im RAM speichern
Aktuelle Sensorwerte, die sich häufig ändern, eignen sich gut für den Arbeitsspeicher.
flow.set("temperaturAktuell", msg.payload, "memoryOnly");
Dieser Wert ist schnell verfügbar und erzeugt keine Schreibzugriffe auf die SD-Karte. Nach einem Neustart von Node-RED ist er allerdings nicht mehr vorhanden.
Das ist für aktuelle Sensorwerte meistens völlig ausreichend.
Sensorwert auf der SD-Karte speichern
Werte, die nach einem Neustart erhalten bleiben sollen, können gezielt in den Store sdcard geschrieben werden.
flow.set("temperaturLetzteSD", msg.payload, "sdcard");
In diesem Beispiel wird die SD-Karte aber nicht für jeden beliebigen Wert verwendet. Sinnvoll ist es, dort nur Werte zu speichern, die wirklich wichtig sind, zum Beispiel den letzten bekannten Sensorwert oder einen Zustand.
Zusätzlich sorgt das flushInterval dafür, dass Node-RED die Daten nicht bei jeder Änderung sofort auf die SD-Karte schreibt.
Sensorwert auf dem USB-Stick speichern
Alternativ können persistente Werte auch auf einen USB-Stick ausgelagert werden.
flow.set("temperaturLetzteUSB", msg.payload, "usbstick");
Damit landen diese Daten nicht im normalen Node-RED-Verzeichnis auf der SD-Karte, sondern auf dem externen Speichermedium.
Das kann sinnvoll sein, wenn du die SD-Karte entlasten möchtest oder bestimmte Daten getrennt speichern willst.
Wichtig ist aber: Auch ein USB-Stick nutzt Flash-Speicher. Er ist also keine perfekte Lösung für sehr viele Schreibzugriffe, kann aber eine einfache und günstige Zwischenlösung sein.
Warum ist das Beispiel sinnvoll?
Das Beispiel zeigt hervorragend, dass man nicht pauschal sagen muss:
Alles wird persistent gespeichert.
Oder:
Alles bleibt nur im RAM.
Stattdessen kann man gezielt entscheiden:
- häufig wechselnde Werte bleiben im RAM
- wichtige Zustände landen persistent auf der SD-Karte
- ausgelagerte Daten können auf einen USB-Stick geschrieben werden
Damit lässt sich die Schreiblast auf die SD-Karte reduzieren, ohne komplett auf persistente Daten zu verzichten.
Der wichtigste Punkt ist:
Nicht jeder Sensorwert muss auf der SD-Karte gespeichert werden.
Durch mehrere Context Stores kannst du in Node-RED sehr genau steuern, welche Daten wohin geschrieben werden.
Fazit
Der Persistent Context in Node-RED ist eine praktische Möglichkeit, wichtige Werte auch nach einem Neustart zu behalten.
Auf einem Raspberry Pi sollte man dabei aber die Schreibzugriffe auf die SD-Karte im Blick behalten.
Für einfache Zähler, Zustände und Konfigurationswerte ist das in der Regel unkritisch. Für viele Sensordaten in kurzen Intervallen sollte man dagegen lieber den RAM-Context oder eine passende Datenbank verwenden.
Besonders sauber ist die Kombination aus zwei Context Stores:
memoryOnlyfür flüchtige Wertefilefür dauerhaft gespeicherte Werte
Damit bleibt Node-RED flexibel, und die SD-Karte wird nicht unnötig belastet.
Letzte Aktualisierung am: 07. Juni 2026



