1.2 Was Node-RED ist – und was nicht. Messwert, Sollwert, Zustand, Aktion

Lernziel

Nach dieser Lektion kannst du

• in eigenen Worten erklären, was Node-RED ist und wofür es sich in einer Victron-Anlage eignet,
• begründen, warum Node-RED keine Schutz- oder Sicherheitssteuerung ist und weder ein BMS noch die ESS-Regelung ersetzt,
• die vier Begriffe Messwert, Sollwert, Zustand und Aktion sicher unterscheiden und mit Beispielen aus deiner Anlage belegen,
• erklären, was Ereignisse, Nachrichten und Flows sind,
• eine einfache Steuerungsidee so beschreiben, dass man sie später in Node-RED umsetzen kann.

Voraussetzungen und Komponenten

• Lektion 1.1 gelesen, vor allem die Sicherheitsregeln.
• Keine Software und keine Hardware. Diese Lektion ist reine Grundlagenarbeit. Sie ist trotzdem wichtig: Die meisten Fehler in Automatisierungen entstehen nicht beim Programmieren, sondern weil Begriffe vermischt werden.

Erklärung

Was Node-RED ist

Node-RED ist ein Werkzeug zum Verbinden von Geräten, Diensten und Daten. Es ist Open Source und steht unter der Apache-Lizenz 2.0. Du programmierst damit nicht Zeile für Zeile, sondern setzt Bausteine auf einer Arbeitsfläche zusammen und verbindest sie mit Linien. Ein solcher Baustein heißt Node, die Verbindungslinie heißt Draht (englisch wire), und eine Gruppe verbundener Nodes heißt Flow.

Node-RED besteht aus zwei Teilen:

• Der Editor läuft in deinem Browser. Dort baust du die Flows.
• Die Laufzeit (englisch runtime) läuft auf dem Rechner, auf dem Node-RED installiert ist. Sie führt die Flows aus, auch wenn kein Browser geöffnet ist.

Technisch ist Node-RED ein Programm für Node.js, eine Umgebung zum Ausführen von JavaScript außerhalb des Browsers. Die aktuelle Version ist 5.0.9. Sie verlangt Node.js ab Version 22.9. Auf einem GX-Gerät mit Venus OS Large v3.80 steckt laut Victron-Changelog Node-RED 4.1.11 mit Node.js 24.18.1. Die Kurs-Flows nutzen keine Funktionen, die erst Node-RED 5 bietet. Getestet wurden sie allerdings nur mit Node-RED 5.0.9.

Die Nodes kommen aus der Palette, der Bausteinleiste am linken Rand des Editors. Einige Nodes sind immer dabei, zum Beispiel für Zeitsteuerung, Verzweigungen oder Netzwerkanfragen. Weitere Nodes installierst du als Pakete nach. Für diesen Kurs sind das zwei Pakete:

• @victronenergy/node-red-contrib-victron: Nodes, die Werte aus dem Victron-System lesen und, in Teil 4, auch schreiben.
• @flowfuse/node-red-dashboard: das Dashboard 2.0, mit dem du Anzeigen und Bedienelemente im Browser baust.

Wofür Node-RED in einer Victron-Anlage gut ist

Node-RED ist stark bei Aufgaben, die Daten aus mehreren Quellen zusammenführen und daraus Komfortfunktionen machen:

• Werte anzeigen, die das Victron-Portal so nicht zeigt, etwa den Überschuss ohne den eigenen Verbraucher,
• einen Verbraucher einschalten, wenn Solarstrom übrig ist und der Akku voll genug ist,
• Benachrichtigungen verschicken, wenn ein Wert ungewöhnlich ist,
• Daten protokollieren und auswerten.

Gemeinsam ist diesen Aufgaben: Wenn Node-RED einmal nicht läuft, ist das ärgerlich, aber nicht gefährlich. Die Spülmaschine läuft dann eben mit Netzstrom oder gar nicht.

Was Node-RED nicht ist

Node-RED ist keine Schutz- oder Sicherheitssteuerung. Dafür gibt es drei Gründe.

1. Node-RED läuft auf einem gewöhnlichen Rechner. Der Rechner kann abstürzen, neu starten oder sich aufhängen. Auf einem GX-Gerät teilt sich Node-RED Speicher und Rechenzeit mit Venus OS. Victron warnt ausdrücklich: Zu viel Last führt irgendwann zum Neustart des Geräts.
2. Node-RED hängt oft am Netzwerk. Ein WLAN-Aussetzer reicht, und ein Schaltbefehl kommt nicht an. Node-RED ist nicht dafür gebaut, Reaktionszeiten zu garantieren.
3. Flows sind von dir geschrieben. Sie sind so gut getestet, wie du sie testest. Ein Tippfehler in einer Grenze oder ein vertauschtes Vorzeichen kann eine Logik ins Gegenteil verkehren.

Daraus folgt: Node-RED ersetzt kein BMS. Das Batteriemanagementsystem überwacht Zellspannungen, Temperaturen und Ströme und schützt den Akku. Node-RED ersetzt auch nicht die ESS-Regelung. ESS regelt, wie viel Energie zwischen Solar, Akku, Haus und Netz fließt, und hält dabei Grenzen ein, die du im GX-Gerät eingestellt hast. Und Node-RED ersetzt keine Sicherung und keinen Geräteschutz.

Die Abbildung zeigt die Zuständigkeiten. Node-RED sitzt ganz oben. Es darf Wünsche äußern, etwa einen Verbraucher einschalten. Die Ebenen darunter müssen aber immer so arbeiten, als gäbe es Node-RED nicht. Wenn deine Automatisierung ausfällt, darf daraus keine Gefahr entstehen.

Hinweis: Eine wörtliche Victron-Aussage „nicht für sicherheitskritische Aufgaben“ wurde in der geprüften Victron-Dokumentation zu Venus OS Large nicht gefunden. Die Regel dieses Kurses ergibt sich aus den drei Gründen oben und aus Victrons Hinweisen: kein Support für Systeme mit diesen Zusatzfunktionen und Neustart bei Überlast.

Vier Begriffe, die du trennen musst

In jeder Steuerung tauchen vier Arten von Größen auf. Wer sie vermischt, baut Logik, die in der Simulation funktioniert und an der echten Anlage versagt.

Messwert: eine Größe, die ein Gerät gemessen und gemeldet hat. Ein Messwert beschreibt die Vergangenheit, auch wenn sie nur eine Sekunde zurückliegt. Beispiele: Der SoC beträgt 83,5 %. Die Batterie lädt mit 800 W. Am Netzanschluss fließen 1200 W. Der Shelly meldet: Relais ist eingeschaltet, Leistung 9 W.

Sollwert: ein Wert, den jemand vorgibt. Er sagt, wie etwas sein soll oder ab wann etwas passieren soll. Beispiele: „Verbraucher freigeben ab SoC 80 %“. „Freigabe beenden unter SoC 60 %“. „Einschalten ab 700 W Überschuss“. Auch der Netzsollwert der ESS-Regelung ist ein Sollwert. Victron beschreibt ihn so: positiv heißt Bezug aus dem Netz, negativ heißt Einspeisung. In Teil 1 veränderst du keine ESS-Sollwerte.

Zustand: etwas, das sich die Steuerung merkt, oder eine Eigenschaft, die über die Zeit gilt. Beispiele: Die Betriebsart ist „Automatik“. Der Verbraucher soll laut Steuerung seit 4 Minuten laufen. Der letzte SoC-Wert ist 12 Sekunden alt. Ein Schaltbefehl wartet noch auf Bestätigung. Der Shelly gilt als nicht erreichbar.

Aktion: etwas, das die Steuerung tut und das außerhalb des Flows eine Wirkung hat. Beispiele: einen Schaltbefehl an den Shelly senden, eine Meldung verschicken, einen Eintrag ins Protokoll schreiben, in Teil 4 einen Wert ins Victron-System schreiben.

Begriff	Frage dazu	Beispiel aus dem Praxisprojekt
Messwert	Was wurde gemessen?	SoC 87,1 %, Batterieleistung 1100 W, Shelly meldet AUS, 0 W
Sollwert	Was soll gelten?	Ein ab 80 %, Aus unter 60 %, Einschaltschwelle 700 W
Zustand	Was merkt sich die Steuerung?	Betriebsart Automatik, Einschaltverzögerung läuft seit 40 s
Aktion	Was wird ausgelöst?	Befehl „einschalten“ an den Shelly

Zwei Verwechslungen kommen besonders oft vor:

1. Sollwert und Messwert. Der Schieberegler „Verbraucher freigeben ab SoC“ im Dashboard ist ein Sollwert für deinen Flow. Er ändert nicht den SoC des Akkus und keinen Wert im GX-Gerät. Der SoC kommt vom Batteriemonitor oder vom BMS.
2. Aktion und Zustand. „Ich habe den Einschaltbefehl gesendet“ heißt nicht „der Verbraucher ist eingeschaltet“. Der Befehl kann verloren gehen, oder das Gerät lehnt ihn ab. Erst wenn der Shelly seinen Schaltzustand zurückmeldet, weißt du, was wirklich gilt. Diese Rückmeldung ist wieder ein Messwert. Deshalb fragt das Praxisprojekt den Shelly regelmäßig nach seinem Zustand und vergleicht ihn mit dem gewünschten Zustand.

Ereignisse

Node-RED ist ereignisgesteuert. Ein Flow tut nichts, solange nichts passiert. Ein Ereignis ist alles, was eine Verarbeitung anstößt:

• Ein Zeitgeber läuft ab, zum Beispiel „jede Sekunde“ oder „alle 5 Sekunden“.
• Ein Gerät meldet einen neuen Wert, etwa die Victron-Node einen neuen SoC.
• Du klickst im Dashboard auf eine Schaltfläche oder verschiebst einen Schieberegler.
• Eine Netzwerkanfrage bekommt eine Antwort oder läuft in eine Zeitüberschreitung.

Diese Denkweise unterscheidet sich von einem klassischen Programm, das in einer Schleife immer wieder alle Werte abfragt. In Node-RED reagierst du auf das, was gerade passiert. Dabei entsteht eine wichtige Frage: Was passiert, wenn ein erwartetes Ereignis ausbleibt? Wenn zum Beispiel keine neuen SoC-Werte mehr kommen, weil die Verbindung weg ist, löst das von selbst kein Ereignis aus. Deshalb brauchen gute Flows einen Taktgeber oder einen Watchdog, der regelmäßig prüft, wie alt die letzten Werte sind. Das lernst du in Lektion 1.6 und 1.8.

Nachrichten

Wenn ein Ereignis eintritt, erzeugt die auslösende Node eine Nachricht und schickt sie über ihren Ausgang weiter. In Node-RED heißt eine Nachricht msg. Sie ist ein Paket mit Eigenschaften. Die zwei wichtigsten sind:

• msg.payload, die Nutzlast. Hier steht der eigentliche Inhalt, zum Beispiel die Zahl 83.5.
• msg.topic, das Thema. Hier steht, worum es geht, zum Beispiel "meas/soc".

Jede Node bekommt die Nachricht über ihren Eingang, verarbeitet sie und gibt eine Nachricht an ihrem Ausgang weiter, oder sie hält die Nachricht an. Die Einzelheiten lernst du in Lektion 1.5.

Flows

Ein Flow ist eine Arbeitsfläche, auf der Nodes über Drähte verbunden sind. Im Editor erscheint jeder Flow als eigener Reiter oben. Die Kurs-Flows heißen zum Beispiel „01 Erste Nachricht“ oder „04 Dashboard SoC“. Mehrere Flows laufen gleichzeitig in derselben Laufzeit.

Wichtig ist der Schritt Deploy: Änderungen im Editor sind zunächst nur ein Entwurf. Erst wenn du auf „Übernahme (deploy)“ klickst, übernimmt die Laufzeit die neue Fassung. Das lernst du in Lektion 1.4.

Einfache Steuerungslogik

Eine Steuerung verbindet die vier Begriffe. Sie nimmt Messwerte, vergleicht sie mit Sollwerten, berücksichtigt ihren Zustand und löst bei Bedarf eine Aktion aus. Drei Grundsätze ziehen sich durch den ganzen Kurs:

1. Zwei Grenzen statt einer. Wer bei 80 % ein- und bei 80 % ausschaltet, schaltet ständig hin und her, sobald der SoC um 80 % schwankt. Besser: Ein ab 80 %, Aus unter 60 %. Dazwischen bleibt der bisherige Zustand. Diesen Abstand zwischen Ein- und Ausschaltgrenze nennt man Hysterese (Lektion 1.13).
2. Nur handeln, wenn sich etwas ändern soll. Die Steuerung sendet nicht bei jedem Messwert einen Befehl, sondern nur, wenn sich der gewünschte Zustand ändert, wenn eine Bestätigung ausbleibt oder wenn eine Absicherung aufgefrischt werden muss.
3. Im Zweifel aus. Fehlt ein Messwert, ist er zu alt oder ungültig, ist der Shelly nicht erreichbar oder steht die Betriebsart auf „Aus“, dann will die Steuerung den Verbraucher ausschalten. Sie rät nicht.

Als Satz formuliert lautet die Automatik des Praxisprojekts vereinfacht:

WENN Betriebsart = Automatik
 UND SoC-Messwert ist frisch und gültig
 UND SoC >= Einschaltgrenze (Sollwert)
 UND Überschuss >= Einschaltschwelle (Sollwert), ununterbrochen für die Einschaltverzögerung
DANN Aktion: Verbraucher einschalten und Rückmeldung abwarten

WENN Verbraucher läuft (Zustand)
 UND (SoC < Ausschaltgrenze ODER Überschuss ohne Last < Ausschaltschwelle), lange genug
 UND Mindestlaufzeit ist vorbei
DANN Aktion: Verbraucher ausschalten und Rückmeldung abwarten

Das ist kein Code, sondern eine Beschreibung. Genau so solltest du jede Automatisierung beginnen: erst in Worten, dann im Flow.

Schritt für Schritt

Übe die Begriffe an einer eigenen Idee. Nimm dir dafür Papier oder eine Textdatei.

1. Formuliere das Ziel in einem Satz. Beispiel: „Die Tischlampe im Büro soll leuchten, wenn der Akku voll genug ist und Solarstrom übrig ist.“ Warum: Ein klares Ziel verhindert, dass du später Funktionen einbaust, die niemand braucht.
2. Liste die Messwerte. Welche Größen braucht die Entscheidung? Hier: SoC, Netzleistung, Batterieleistung, Schaltzustand des Shelly. Warum: Jeder Messwert muss eine Quelle haben, und jede Quelle kann ausfallen.
3. Liste die Sollwerte. Welche Grenzen und Schwellen legst du fest? Hier: Einschaltgrenze, Ausschaltgrenze, Einschaltschwelle für den Überschuss. Warum: Sollwerte willst du später ändern, ohne die Logik anzufassen.
4. Liste die Zustände. Was muss sich die Steuerung merken? Hier: Betriebsart, ob der Verbraucher laufen soll, seit wann er läuft, ob ein Befehl auf Bestätigung wartet. Warum: Ohne Zustand kann die Steuerung keine Hysterese und keine Mindestlaufzeit umsetzen.
5. Liste die Aktionen. Was soll passieren? Hier: Schaltbefehl ein oder aus. Warum: Jede Aktion braucht eine Rückmeldung, sonst weißt du nicht, ob sie gewirkt hat.
6. Liste die Ereignisse. Wann wird entschieden? Hier: bei jedem neuen Messwert merken, einmal pro Sekunde entscheiden. Warum: Ein fester Takt bemerkt auch, wenn Messwerte ausbleiben.
7. Beantworte die Ausfallfrage. Was soll passieren, wenn ein Messwert fehlt, Node-RED neu startet oder der Shelly nicht antwortet? Warum: Diese Fälle treten im Betrieb garantiert auf. Die Antwort lautet im Kurs fast immer: ausschalten und den Grund anzeigen.

Code und Nachrichtenstruktur

So sehen die Nachrichten aus, die in den Kurs-Flows unterwegs sind.

Eine Victron-Input-Node sendet den Wert in payload und als topic den Namen der Node, wenn du ihr einen Namen gibst. In Flow 03 heißt die SoC-Node „SoC (System)“:

{ "payload": 83.5, "topic": "SoC (System)" }

Das ist ein Messwert. Die Flows setzen das Topic danach auf ein einheitliches Schema, hier meas/soc (von englisch measurement, Messung).

Der Schaltbefehl der Steuerung ist eine Aktion. Die Zeile stammt wörtlich aus flows/src/steuerung_v4.js:

    cmd = { topic: 'shelly/cmd', payload: { on: on, toggleAfter: on && cfg.watchdogS > 0 ? cfg.watchdogS : 0 } };

on ist true für Einschalten und false für Ausschalten. toggleAfter überträgt den Geräte-Timer aus Regel 4 der Lektion 1.1.

Wie „im Zweifel aus“ im echten Code aussieht, zeigt der Anfang der Entscheidung in derselben Datei. Die Bedingungen werden der Reihe nach geprüft. Die erste, die zutrifft, gewinnt:

if (mode === 'off') {
    want = false; reason = 'Betriebsart Aus'; prio = true;
} else if (!fresh(meas.soc)) {
    want = false; prio = true;
    reason = meas.soc && meas.soc.invalid !== undefined ? 'SoC ungültig (' + meas.soc.invalid + ')' : 'SoC fehlt oder ist veraltet';
} else if (soc < cfg.socHardMin) {
    want = false; prio = true; reason = 'SoC unter Schutzgrenze ' + cfg.socHardMin + ' %';
} else if (!shellyFresh) {
    want = false; prio = true; reason = 'Shelly nicht erreichbar – Schaltzustand unbekannt';

Du musst diesen Code jetzt noch nicht verstehen. Achte nur auf das Muster: want ist der gewünschte Zustand des Verbrauchers. fresh(meas.soc) prüft, ob der Messwert jung genug ist. cfg.socHardMin ist ein Sollwert. Und reason ist der Klartext, den das Dashboard anzeigt. Jede Entscheidung hat einen Grund, den du nachlesen kannst.

Erwartetes Ergebnis

Du kannst

• einem Bekannten in zwei Sätzen erklären, was Node-RED ist und warum es keine Sicherheitseinrichtung ist,
• zu jeder Größe in deiner Anlage sagen, ob sie Messwert, Sollwert, Zustand oder Aktion ist,
• deine eigene Steuerungsidee in den sieben Schritten oben aufschreiben, einschließlich der Antwort auf die Ausfallfrage.

Typische Fehler und Behebung

Ein Schieberegler wird für den SoC gehalten. Wer den Regler „Ein ab 80 %“ auf 50 % zieht, ändert nur die Grenze im Flow. Der Akku hat danach genau denselben Ladezustand. Behebung: Benenne Sollwerte im Dashboard eindeutig, zum Beispiel „Verbraucher freigeben ab SoC (%)“ statt „SoC“.

Ein gesendeter Befehl wird als Schaltzustand angezeigt. Das Dashboard zeigt „EIN“, weil der Befehl rausging, aber die Lampe ist aus. Behebung: Zeige getrennt an, was die Steuerung will und was das Gerät meldet. Das Praxisprojekt hat dafür die Zeile „Shelly: meldet EIN, 500 W“.

Die Logik verlässt sich darauf, dass Werte immer kommen. Fällt die Verbindung weg, bleibt der letzte Wert einfach stehen, und die Steuerung arbeitet mit einem SoC von gestern. Behebung: Jeder Messwert bekommt einen Zeitstempel, und ein Takt prüft regelmäßig sein Alter (Lektion 1.8).

Zwei Regelungen ändern dasselbe. Ein Flow schaltet eine Wärmepumpe, gleichzeitig schaltet ihre eigene Zeitsteuerung. Am Ende weiß niemand, wer zuletzt entschieden hat. Behebung: Lege für jedes Gerät genau einen Zuständigen fest. Wenn Node-RED zuständig ist, schalte andere Automatiken für dieses Gerät ab oder binde sie bewusst ein (Teil 3).

Node-RED soll den Akku schützen. Behebung: Den Schutz übernehmen BMS und Victron-Regelung. Node-RED darf zusätzlich vorsichtig sein, etwa mit der Schutzgrenze socHardMin. Darauf verlassen darfst du dich nicht.

Übung

Ordne jede der folgenden Größen einem Begriff zu: Messwert, Sollwert, Zustand, Aktion oder Ereignis.

1. Der Batteriemonitor meldet 52,4 V.
2. Im Dashboard steht „Freigabe beenden unter SoC 60 %“.
3. Die Steuerung merkt sich: Verbraucher läuft seit 7 Minuten.
4. Die Inject-Node „jede Sekunde“ löst aus.
5. Ein Befehl Switch.Set mit on: true geht an den Shelly.
6. Der Shelly antwortet auf eine Statusabfrage: output: true, apower: 9.6.
7. Die Betriebsart steht auf „Manuell Ein“.
8. Die Einschaltverzögerung beträgt 60 Sekunden.
9. Du verschiebst im Dashboard den Schieberegler.
10. Der letzte SoC-Wert ist 45 Sekunden alt.

Musterlösung

Nr.	Begriff	Begründung
1	Messwert	Ein Gerät hat die Spannung gemessen und gemeldet.
2	Sollwert	Du gibst eine Grenze vor. Sie ändert nichts am Akku.
3	Zustand	Die Steuerung merkt sich etwas über die Zeit.
4	Ereignis	Der Zeitgeber stößt eine Verarbeitung an.
5	Aktion	Die Steuerung löst etwas außerhalb des Flows aus.
6	Messwert	Das Gerät meldet seinen tatsächlichen Zustand und seine Leistung. Für die Steuerung ist das die Rückmeldung.
7	Zustand	Die Betriebsart gilt so lange, bis jemand sie ändert.
8	Sollwert	Eine vorgegebene Zeitgrenze aus der Konfiguration.
9	Ereignis	Die Bedienung erzeugt eine Nachricht. Der neue Reglerwert ist danach ein Sollwert.
10	Zustand	Das Alter ist eine Eigenschaft des letzten Messwerts, die sich mit der Zeit ändert. Mit 45 Sekunden ist er im Kurs „veraltet“ (Grenze 30 Sekunden).

Bei Nr. 9 und Nr. 10 sind auch andere Begründungen vertretbar. Entscheidend ist, dass du zwischen dem Ereignis „Regler bewegt“ und dem Sollwert „neue Grenze“ unterscheidest.

Verständnisfragen

Frage 1: Warum ist Node-RED auf einem GX-Gerät trotzdem keine Sicherheitseinrichtung, obwohl es direkt im Victron-System läuft?

Antwort anzeigen

Antwort: Weil es sich auch dort Speicher und Rechenzeit mit Venus OS teilt, abstürzen oder neu starten kann und von dir geschriebene Flows ausführt. Victron warnt, dass Überlast zum Neustart des Geräts führen kann. Der Schutz des Akkus und der Anlage liegt bei BMS, Sicherungen und der Victron-Regelung, die unabhängig von Node-RED arbeiten müssen.

Frage 2: Was ist der Unterschied zwischen „Befehl gesendet“ und „Verbraucher eingeschaltet“?

Antwort anzeigen

Antwort: „Befehl gesendet“ ist eine Aktion. Ob sie gewirkt hat, ist offen: Der Befehl kann verloren gehen oder abgelehnt werden. „Verbraucher eingeschaltet“ ist erst belegt, wenn das Gerät seinen Schaltzustand zurückmeldet. Diese Rückmeldung ist ein Messwert.

Frage 3: Warum braucht ein ereignisgesteuerter Flow trotzdem einen regelmäßigen Takt oder einen Watchdog?

Antwort anzeigen

Antwort: Weil ein ausbleibendes Ereignis selbst kein Ereignis auslöst. Wenn keine Messwerte mehr kommen, merkt der Flow das nur, wenn etwas anderes regelmäßig prüft, wie alt der letzte Wert ist. Sonst würde die Steuerung mit einem eingefrorenen Wert weiterarbeiten.

Frage 4: Warum arbeitet das Praxisprojekt mit zwei SoC-Grenzen statt mit einer?

Antwort anzeigen

Antwort: Mit nur einer Grenze würde der Verbraucher ständig ein- und ausschalten, sobald der SoC um diese Grenze schwankt. Mit zwei Grenzen (Ein ab 80 %, Aus unter 60 %) bleibt der Zustand dazwischen erhalten. Diese Hysterese schont Geräte und verhindert Flattern.

Frage 5: Ist der ESS-Netzsollwert ein Messwert oder ein Sollwert, und darfst du ihn in Teil 1 ändern?

Antwort anzeigen

Antwort: Er ist ein Sollwert, denn er gibt vor, wie viel Leistung am Netzanschluss fließen soll (laut Victron positiv für Bezug, negativ für Einspeisung). In Teil 1 änderst du ihn nicht. Schreibzugriffe auf das Victron-System kommen erst in Teil 4.

Quellen und Versionen

• Node-RED 5.0.9 und Mindestversion Node.js 22.9: https://github.com/node-red/node-red/releases und https://raw.githubusercontent.com/node-red/node-red/master/package.json (geprüft am 27.10.2026). Lizenz: Apache-Lizenz 2.0 laut Kopf der Quelltextdateien von Node-RED 5.0.9.
• Node-RED-Version im Large-Image v3.80 (4.1.11, Node.js 24.18.1): Changelog v3.80 von Victron in der Community, https://community.victronenergy.com/t/54392 (Beitrag von Victron-Mitarbeiter, geprüft am 27.10.2026).
• Überlastwarnung und Support-Hinweis zu Venus OS Large: https://www.victronenergy.com/live/venus-os:large (zuletzt geändert 15.04.2026, geprüft am 27.10.2026).
• Vorzeichen des ESS-Netzsollwerts: https://www.victronenergy.com/live/ess:ess_mode_2_and_3 (geprüft am 27.10.2026).
• Nachrichtenformat der Victron-Input-Nodes: Quelltext @victronenergy/node-red-contrib-victron 1.7.30, src/nodes/victron-nodes.js.
• Codeausschnitte: flows/src/steuerung_v4.js aus dem Kurs-Download.