Skip to content

Technik Blog

Programmieren | Arduino | ESP32 | MicroPython | Python | Raspberry Pi | Raspberry Pi Pico

Menu
  • Smarthome
  • Gartenautomation
  • Mikrocontroller
    • Arduino
    • ESP32 & Co.
    • Calliope Mini
    • Raspberry Pi & Pico
  • Solo Mining
  • Über mich
Menu

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

Veröffentlicht am 7. Juni 20267. Juni 2026 von Stefan Draeger

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.

Dieses Video auf YouTube ansehen.

Inhaltsverzeichnis

  • Warum sind Schreibzyklen bei der Node-RED SD-Karte ein Thema?
  • Wie schreibt Node-RED Context-Daten?
  • Ist das ein Problem für die SD-Karte?
  • Bessere Lösung: Zwei Context Stores verwenden
  • Speichern im File-Store
  • Wann sollte ich welchen Store verwenden?
  • Wann sollte ich lieber eine Datenbank nutzen?
  • Warum ist eine Datenbank dann nicht automatisch besser?
  • Alternative: Raspberry Pi mit SSD oder NVMe betreiben
    • Wo bekommt man ein NVMe HAT und was kostet es?
  • Node-RED SD-Karte entlasten: Speicheroptionen im Vergleich
  • Node-RED Context Stores praktisch nutzen: RAM, SD-Karte und USB-Stick
    • Vorbereitung in der settings.js
    • Aufbau des Flows
    • Sensorwert im RAM speichern
    • Sensorwert auf der SD-Karte speichern
    • Sensorwert auf dem USB-Stick speichern
    • Warum ist das Beispiel sinnvoll?
  • Fazit

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.

Schaubild zum Vergleich von Arbeitsspeicher, persistentem Context und Datenbank in Node-RED mit Beispielen, welche Daten jeweils sinnvoll gespeichert werden sollten.
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.

Schaubild zum Vergleich von Persistent Context und Datenbank in Node-RED mit Beispielen für wenige wichtige Zustände sowie viele historische Messwerte, Diagramme und Auswertungen.
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.

Screenshot eines NVMe HAT für den Raspberry Pi, mit dem eine SSD als Alternative zur microSD-Karte genutzt werden kann.
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.

ShopPreis
https://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ür
microSD-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änge
USB-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 Daten
externe 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-Projekte
NVMe 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.

Screenshot eines Node-RED Flows, der einen MQTT-Sensorwert empfängt und diesen in verschiedenen Context Stores wie RAM, SD-Karte und USB-Stick speichert.
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
[
    {
        "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:

StoreSpeicherortZweck
memoryOnlyArbeitsspeicheraktuelle Werte, die nach einem Neustart nicht erhalten bleiben müssen
sdcardDateisystem auf der SD-Kartewichtige Werte, die persistent gespeichert werden sollen
usbstickexterner USB-Stickausgelagerte 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:

SpeicherartVerhalten
RAM / memoryOnlyschnell, keine Schreibzugriffe auf SD-Karte, nach Neustart weg
SD-Karte / sdcardpersistent, aber mit längerem Schreibintervall
USB-Stick / usbstickpersistent, 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:

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

Damit bleibt Node-RED flexibel, und die SD-Karte wird nicht unnötig belastet.

Letzte Aktualisierung am: 07. Juni 2026

Foto von Stefan Draeger
Über den Autor

Stefan Draeger — Entwickler & Tech-Blogger

Ich zeige praxisnah, wie du Projekte mit Arduino, ESP32 und Smarthome-Komponenten umsetzt – Schritt für Schritt, mit Code und Schaltplänen.

Mehr Artikel von Stefan →

Schreibe einen Kommentar Antwort abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Fragen oder Feedback?

Du hast eine Idee, brauchst Hilfe oder möchtest Feedback loswerden?
Support-Ticket erstellen

Newsletter abonnieren

Bleib auf dem Laufenden: Erhalte regelmäßig Updates zu neuen Projekten, Tutorials und Tipps rund um Arduino, ESP32 und mehr – direkt in dein Postfach.

Jetzt Newsletter abonnieren

Unterstütze meinen Blog

Wenn dir meine Inhalte gefallen, freue ich mich über deine Unterstützung auf Tipeee.
So hilfst du mit, den Blog am Leben zu halten und neue Beiträge zu ermöglichen.

draeger-it.blog auf Tipeee unterstützen

Vielen Dank für deinen Support!
– Stefan Draeger

Kategorien

Tools

  • QR-Code Generator
  • Passwort Generator: Sichere Passwörter & Passphrasen erstellen
  • Unix-Zeitstempel-Rechner
  • ASCII Tabelle
  • Spannung, Strom, Widerstand und Leistung berechnen
  • Widerstandsrechner
  • 8×8 LED Matrix Tool
  • 8×16 LED Matrix Modul von Keyestudio
  • 16×16 LED Matrix – Generator

Links

Blogverzeichnis Bloggerei.de TopBlogs.de das Original - Blogverzeichnis | Blog Top Liste Blogverzeichnis trusted-blogs.com

Stefan Draeger
Königsberger Str. 13
38364 Schöningen
Tel.: 015565432686
E-Mail: info@draeger-it.blog

Folge mir auf

link zu Fabook
link zu LinkedIn
link zu YouTube
link zu TikTok
link zu Pinterest
link zu Instagram
  • Impressum
  • Datenschutzerklärung
  • Disclaimer
  • Cookie-Richtlinie (EU)
©2026 Technik Blog | Built using WordPress and Responsive Blogily theme by Superb
Cookie-Zustimmung verwalten
Wir verwenden Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wir tun dies, um das Surferlebnis zu verbessern und um personalisierte Werbung anzuzeigen. Wenn Sie diesen Technologien zustimmen, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn Sie Ihre Zustimmung nicht erteilen oder zurückziehen, können bestimmte Funktionen beeinträchtigt werden.
Funktional Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt. Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
  • Optionen verwalten
  • Dienste verwalten
  • Verwalten von {vendor_count}-Lieferanten
  • Lese mehr über diese Zwecke
Einstellungen anzeigen
  • {title}
  • {title}
  • {title}