Dynamic ESS verstehen und steuern

Wie Victrons DESS wirklich entscheidet — und wie der Hausakku für das Autoladen stillgelegt wird · Stand 23.10.2026

Warum es diese Seite gibt. Beim Laden des Autos soll der Strom aus dem Netz kommen, nicht aus dem Hausakku. Weil bei uns alle Lasten am AC-Ausgang hinter dem Akku hängen — die Wallbox eingeschlossen — versorgt er das Auto sonst automatisch mit. Victron bietet dafür keine offizielle Einstellung an. Der Weg unten ist am Firmware-Quelltext belegt und an der eigenen Anlage gemessen.

DESS schreibt keine Watt, sondern einen Fahrplan

Dynamic ESS legt 48 Zeitpläne im Ekrano ab, je eine Viertelstunde, zusammen also zwölf Stunden. Jeder Plan steht unter com.victronenergy.settings im Pfad /Settings/DynamicEss/Schedule/<0…47>/ und hat acht Felder.

FeldTypBedeutung
TargetSocGleitkomma 0,0–100,0Der gültige Zielwert.
Socganzzahlig 0–100Abgekündigt. Nur Rückfallebene, wenn TargetSoc = 0 ist.
Strategy0–30 = Ziel-SoC folgen · 1 = Eigenverbrauch · 2 = pro Akku · 3 = pro Netz
RestrictionsBitmuster 0–31 = kein Export Akku→Netz · 2 = kein Import Netz→Akku · 3 = beides
FlagsBitmuster 0–31 = volle Ladeleistung · 2 = Solar im Fenster abschalten
StartUnix-Zeitwird in Lokalzeit umgerechnet
DurationSekundenbei uns immer 900
AllowGridFeedIn0 / 1Einspeisung im Fenster erlaubt
Falle: die beiden SoC-Felder. Steht TargetSoc auf 0 und Soc auf 100, zielt die Anlage auf 100 Prozent. VRM schreibt tatsächlich Soc = 100 neben einem feinen TargetSoc. Wer selbst schreibt, muss beide Felder setzen. Die Regel im Quelltext: 
self.soc = targetsoc if (targetsoc is not None and targetsoc > 0) else soc
   #legacy support: fall back to /Soc, when /Targetsoc is 0

Der Hebel für das Autoladen

Mit Strategy = 0 und TargetSoc = aktueller SoC hat der Regler nichts zu tun: Er soll auf einen Stand fahren, auf dem er schon steht. Der Entscheidungsbaum landet dann auf IDLE_MAINTAIN_TARGETSOC, und für unsere Geräteklasse tut idle() genau das Gewünschte:

def idle(self, allow_feedin):
    # idling means: Grid needs to deliver consumption - ACPV - DCPV * 0.95
    ... '/Ess/AcPowerSetpoint', acps
    # when idling during 0 external mppt power, we can additionally disable discharge
    if (math.ceil(self.external_pvpower or 0)) == 0:
        ... '/Ess/DisableDischarge', 1
        ... '/Ess/DisableCharge', 1

Netz-Sollwert gleich dem ganzen Verbrauch, die Wallbox eingeschlossen — und ohne externe PV zusätzlich ein hartes Lade- und Entladeverbot. Nachgezogen wird das bei jedem neuen Messwert, nicht nur alle fünf Sekunden; bei 11 kW schaltender Last ist das wichtig.

Strategy = 1 wäre genau falsch. Dieser Zweig verlässt den Entscheidungsbaum sofort („we can ommit to walk through the decission tree“), und auf dem Multi RS werden die Beschränkungen dann gar nicht ausgewertet — die Klasse nimmt den Parameter entgegen und benutzt ihn nirgends.

Gemessen am 10.10.2026

Dreiminütiger Versuch um die Mittagszeit, während der Akku aus der PV lud:

ZeitModusReaktive StrategieAkkuPV
12:0611+1.206 W1.826 W
12:0749+137 W945 W
12:0845−5 W542 W
12:0945−5 W572 W
12:10 zurückgestellt1–+924 W1.630 W
Der Akku stand. Von +1.206 W auf −5 W, SoC unverändert bei 33,0 %. Die übrigen −5 W sind der Eigenbedarf der Wechselrichter, den sie aus dem DC-Kreis ziehen — „Stillstand“ heißt nie exakt null.
Einfrieren ohne Last wirft Sonnenstrom weg. Die PV fiel während des Versuchs von 1.826 auf 542 W und erholte sich unmittelbar nach der Rückstellung auf 1.630 W. Der Überschuss konnte nirgends hin — Akku gesperrt, Einspeisung aus — also regelten die Regler ab. Beim Autoladen fällt das weg, weil die Ladeleistung den Überschuss ohnehin aufbraucht.

Modus 4 heißt „Node-RED“ — wir benutzen es aber nicht

Victron nennt /Settings/DynamicEss/Mode = 4 den Node-RED-Modus. Das ist nur ein Name. Er bedeutet: irgendwer anders als VRM füllt die Zeitpläne. Wer das ist, interessiert den Ekrano nicht — in neueren Venus-Versionen heißt der Modus deshalb schlicht Local.

Wir schreiben direkt per MQTT vom apps-server an den dbus des Ekrano, dieselbe Technik wie beim Mindest-SoC. Kein Flow, kein Knoten, keine Oberfläche.

Node-RED würde genauso gehen. Der Flow bleibt über ein Venus-Update hinweg erhalten; nur während des Neustarts ist die Steuerung über Node-RED nicht verfügbar. Wir schreiben trotzdem vom apps-server aus, weil die Logik dort bei den übrigen Werkzeugen liegt, mitgesichert wird und als lesbare Datei mit Belegstellen vorliegt statt als Knotengeflecht. Das ist eine Vorliebe, keine Notwendigkeit.

Das Werkzeug

~/energie/dess_akku_einfrieren.py, ausgeführt mit ~/.venvs/mqtt/bin/python:

dess_akku_einfrieren.py pruefen        nur lesen, nichts schreiben
dess_akku_einfrieren.py ein <Minuten>  einfrieren, danach selbsttätig zurück
dess_akku_einfrieren.py aus            sofort zurückstellen

Es setzt den Modus auf 4, beschreibt Slot 0 und zieht das Fenster jede Minute nach. Am Ende — auch bei Abbruch oder Fehler — räumt es Slot 0 und stellt den Modus auf 1 zurück. Die Höchstdauer ist auf sechs Stunden begrenzt.

Drei Regeln, die darin stecken

Wachhund statt Einmaleintrag. Läuft ein Fenster ohne Nachfolger ab, fällt DESS sofort auf Eigenverbrauch zurück — und der Akku versorgt das Auto. Das Fenster muss laufend nachgezogen werden.

Slot 0 belegen. Plätze mit Start = 0 existieren für DESS nicht, und bei mehreren passenden Fenstern gewinnt der niedrigste Index. Ein einziger gültiger Plan genügt.

Zahlen, keine Zeichenketten. {"value": 0} — ein String wird abgewiesen.

Niemals -1 in die vier Lade- und Entladegrenzen schreiben. Victron-Issue venus#1699, eröffnet am 08.10.2026, betrifft genau unsere Gerätekombination (Multi RS, Cerbo, Venus 3.80): Ein Node-RED-Flow schrieb -1, DESS stieg aus, reaktive Strategie 93, nur noch PV-Ladung. Ursache ist eine fehlende Prüfung im Code, behoben ist nichts. Nur echte Werte schreiben.

Wege, die nicht tragen

Ansatzwarum nicht
Netz-Sollwert /Settings/CGwacs/AcPowerSetPoint DESS schreibt alle fünf Sekunden direkt /Ess/AcPowerSetpoint am Gerät und überstimmt die Einstellung. Erst nach DESS-Abschaltung ein Hebel.
MinSoC auf den aktuellen Stand heben Funktioniert, ist aber grob — sperrt den Akku ganz. Und DESS hält die Entladung dann auch für die Zukunft für unmöglich und wirft seinen Plan um. Diesen Weg geht EVCC bereits, mit demselben Nachteil.
ESS-Zeitplan-Ladung DESS hat Steuerpriorität 0, die Zeitplan-Ladung 20. DESS verdrängt sie, nicht umgekehrt.
ESS-Modus „Keep charged“ DESS schaltet sich dann mit Fehler 2 ab, und der Akku lädt mit voller Leistung aus dem Netz — mehr als gewollt.

Der ganze Fahrplan ist lesbar — zwölf Stunden voraus

Gemessen am 23.10.2026, 10:15 Uhr, direkt am Ekrano

Die 48 Zeitpläne liegen im Ekrano selbst, nicht nur in der VRM-Cloud: com.victronenergy.settings, Pfad /Settings/DynamicEss/Schedule/0…47. VRM schreibt sie hinein, der Ekrano speichert und führt aus. Lesen lässt sich die ganze Reihe per MQTT — kein Cloud-Zugriff nötig, nur ein R/<portal>/keepalive vorweg, weil der Broker Einstellungen sonst nicht sendet.

Alle 48 Plätze waren gefüllt, von 10:15 bis 22:15 — zwölf Stunden voraus, jede Viertelstunde mit allen acht Feldern.

Slot 0 ist NICHT immer die laufende Viertelstunde. Das stand hier am Morgen des 23.10. falsch. VRM schreibt die ganze Reihe als Block, und nur etwa alle 30 Minuten — nachgezählt an 80 Zustandswechseln von sensor.dess_slot0_start über zwei Tage: 09:17→Fenster 09:15, 09:49→09:45, 10:20→10:15, 10:52→10:45. Dazwischen steht die Reihe still. Um 10:47 war Slot 0 das Fenster von 10:15, also 32 Minuten alt und längst abgelaufen; die laufende Viertelstunde lag auf Slot 2. Wer also „das aktuelle Fenster“ sucht, muss die Reihe nach der Zeit durchsehen und darf nicht Slot 0 nehmen.
ZeitraumZiel-SoCStrategieBeschränkung
10:15 → 15:4525,7 → 42,3 % steigend 1 = Eigenverbrauch3 = kein Import, kein Export
16:00 → 22:1542,1 → 29,8 % fallend 1 = Eigenverbrauch1 = kein Export

An diesem Tag stand jeder der 48 Plätze auf Eigenverbrauch: DESS plante kein Netzbezugsfenster, sondern lud den Akku aus der Sonne auf 42 % und entlud ihn abends ins Haus. Zum Anhängen gab es an diesem Tag also nichts.

Daraus folgt: Slot 0 zu sichern ist sinnlos (Jürgen, 23.10.2026). Gesichert wurde er, um „VRMs laufendes Fenster“ zurückzugeben — aber VRM schreibt die Reihe ohnehin neu, etwa halbstündlich. Bei einer Ladung von einer Stunde ist die Sicherung also zweimal veraltet. Zu schliessen war nie das Fenster, sondern nur die Lücke bis zur nächsten Viertelstundengrenze — und das tut der Moduskniff unten sofort und richtig.

Die Freigabe: Modus kurz auf off und zurück

Jürgens Vorschlag vom 12.10.2026: „das einfachste ist es auf off zu setzen und dann wieder on.“ Der Moduswechsel erzwingt bei VRM eine Neuplanung. Gemessen:

22:33:50  Netz 439 W | Akku  74 W | Soll-SoC 76   <- Halt war zurueck
22:34:26  Netz 427 W | Akku  74 W | Soll-SoC  0   <- VRM plant neu
22:34:44  Netz  -3 W | Akku 505 W | Soll-SoC  0   <- geloest

Der dynamische Soll-SoC fiel binnen 70 Sekunden von 76 auf 0. Der Modus wird vorher gelesen und genau so wiederhergestellt — ein manuelles buy/sell/ node_red wird nicht überschrieben, und bei bereits off passiert nichts. Mit DESS auf off läuft der Multi RS im normalen ESS-Eigenverbrauch — daher die Redeweise „kurz auf ESS und zurück“.

Woran man den Halt NICHT erkennt. Am 12.10. hielt VRM den Akku noch fest, nachdem unser Slot 0 schon genullt war: Soll-SoC 76 bei Stand 75, Akku konstant 74 W Leerlauf, das Haus lief mit 425–500 W am Netz. Der Halt kam also aus VRMs eigenem Plan, der um 22:15:00 geschoben wurde — nicht aus unserem Slot. Wer nur den eigenen Slot prüft, sieht das nicht.

Zwei Mindest-SoC — und nur einer wirkt

Gemessen am 22.10.2026, während der Hausakku 11,4 kW ins Auto abgab

RegisterWertWirkung
acsystem/0/Ess/ActiveSocLimit20 Das wirksame Limit des Multi RS. Bis hierher gibt der Akku ab.
acsystem/0/Settings/Ess/MinimumSocLimit20 Die Einstellung dahinter — hierher schreibt die Schutz-Automation.
settings/0/Settings/CGwacs/BatteryLife/MinimumSocLimit73 Beisst nicht. DESS schreibt hier seinen eigenen Wert hinein.
Die Falle: number.multi_rs_6000_3p_ess_mindest_soc in Home Assistant zeigt das BatteryLife-Register. Am 22.10. stand dort 73, während der Akku von 78 % auf 48 % ins Auto durchlief — weil das Gerät sich an die 20 aus ActiveSocLimit hielt. Der angezeigte Wert war kein Schutz, sondern DESS' Notiz an sich selbst. Ein Anzeigename ist kein Beleg; hier ist nicht einmal der Pfad einer.

Gemessen 23.10.2026: VRM schreibt auch in Modus 4 weiter

Der offene Punkt dieser Seite seit dem 10.10.2026 — beantwortet

Modus um 10:47:39 auf 4 gesetzt und keinen Slot angefasst, damit DESS weiter VRMs eigenen Plan abarbeitet; alle zwei Minuten gelesen. Um 10:52:03 sprang Slot 0 vom Fenster 10:15 auf 10:45 und Slot 47 von 22:00 auf 22:30 — die ganze Reihe zwei Viertelstunden weiter, mitten in Modus 4.

Die reaktive Strategie blieb dabei unverändert auf scheduled_selfconsume, die Zahl der Zeitpläne auf 48. Modus 4 stört die Regelung also nicht, er ändert nur, wer die Pläne füllen darf — und VRM füllt sie weiter. Um 11:20:41 zurück auf 1, alles unversehrt.

Folge für die Freigabe: Slot 0 nur zu nullen genügt NICHT. Weil VRM weiterschreibt, liegen alle anderen Plätze immer in der Zukunft. Ein genullter Slot 0 hinterlässt darum eine Lücke bis zum nächsten Block — bis zu einer halben Stunde, in der DESS auf Eigenverbrauch fällt. Genau das war das gemessene no_window vom 10.10. zwischen 16:00 und 16:15.
Der nächste Schritt, noch nicht gebaut (Jürgens Idee vom 23.10.2026: „den aktuell gültigen Plan zurückschreiben wenn wir mit dem Laden fertig sind. dann braucht es kein kurzes DESS off.“) — Slot 0 beim Beenden aus Slot 1 fortschreiben: Start = jetzt, Dauer bis zum Beginn von Slot 1, Strategie, Beschränkungen, Einspeisung und Ziel-SoC kopiert. Das wäre örtlich und ohne Cloud, während der Moduskniff VRM und Internet braucht und bis zu 70 Sekunden dauert. Was dazu fehlt: acht sensor.dess_slot1_*. Die acht für Slot 0 stehen in keiner YAML — sie kamen per MQTT-Discovery und leben nur im Entitätsregister. Bis dahin bleibt der Moduskniff der Rückweg.

Die Kette, die den Hausakku beim Autoladen schützt

Stand 23.10.2026, 11:20 · der Einfrier-Weg läuft wieder, der Mindest-SoC-Weg bleibt aus

Vom 18.10. bis zum 23.10.2026 lief diese Kette NICHT. Am 18.10. um 20:45 sind drei der vier Stücke abgeschaltet und um 21:41 mit initial_state: false festgeschrieben worden — auf Jürgens Wort: „wir nutzen nur noch die Lösung über evcc und DESS.“ Der sachliche Grund war die PV-Drosselung: ein angehobener Mindest-SoC lässt den Akku keine Sonne mehr annehmen, am 18.10. nachmittags rund 1 kWh. Die Annahme dahinter — „DESS sperrt den Akku beim Schnellladen ohnehin“ — ist am 22.10. widerlegt worden: DESS stand auf Eigenverbrauch, und der Hausakku lief von 78 auf 48 % ins Auto.
Am 23.10.2026 wieder scharf gestellt — aber nur der Einfrier-Weg. Jürgen: „Jetzt muss es erst einmal wieder zuverlässug laufen.“ Der Wachhund läuft wieder, umgebaut (siehe die Spalte rechts), und die Freigabe greift nur noch, wenn wirklich eingefroren war. Der Mindest-SoC-Weg und die Notbremse bleiben aus — der Mindest-SoC hat am 18.10. die PV um rund 1 kWh gedrosselt, und die 73 im falschen Register hat am 22.10. gezeigt, wie leise er versagt.
WannWasWoStand 23.10.
beim Preissignal Victron-Mindest-SoC auf min(99, Stand+1) — der Akku gibt nichts mehr ab. Hört auf smart_cost_active, Modus now und den eigenen Schnell-Merker; ein Wachhund holt den Ruhewert 20 zurück, sobald nicht mehr geladen wird. HA, Hausakku: Schutz auch bei EVCC-Schnellladen bleibt aus. Drosselte die PV; schreibt zwar auf das Register, das wirkt — aber grob, es sperrt den Akku ganz.
jede Minute, solange geladen wird DESS Slot 0 einfrieren: Strategy 0 mit TargetSoc = Ist-SoC führt auf idle_maintain_targetsoc, Restrictions 3 verbietet Import und Export. Der Netz-Sollwert deckt dann den ganzen Verbrauch inklusive Wallbox. HA, DESS: Hausakku einfrieren (Wachhund) läuft seit 23.10., dauerhaft (initial_state entfernt). Umgebaut: greift nicht ein, wenn DESS den Akku schon selbst still hält; setzt den Merker input_boolean.dess_eingefroren; sichert Slot 0 nicht mehr.
vor der Freigabe Neu 18.10. Die Fenstersuche sperrt den Akku, bevor sie Tor und Preisgrenze öffnet — der Wachhund verlangt charging = on und käme sonst erst, wenn der Strom schon fliesst. Bei 11 kW sind das 0,2 kWh je Minute aus dem Akku. ~/energie/nachbar_fenster.py, akku_sichern() ausgebaut 18.10. — drosselte die PV. Die Funktion steht ungenutzt da; ihre Prüfung akku_gesichert() ist der Baustein, den die Soll-Kette unten braucht.
wenn der Schutz nicht wirkt Neu 18.10. Die Notbremse prüft nicht den Plan, sondern die Wirkung: entlädt der Akku stärker als 500 W, während das Auto lädt, werden nach 3 Minuten beide Schutzstücke nachgezogen und nach 8 Minuten der Ladepunkt abgeschaltet. HA, Hausakku-Notbremse bleibt aus, nie im Feld ausgelöst. Ihre Stufe 1 ruft den Mindest-SoC-Weg — darum fällt sie mit ihm.

Das fünfte Stück, und das einzige, das noch läuft: DESS: Hausakku freigeben — es hebt eine bestehende Sperre wieder auf und macht den Moduskniff oben. Seit 23.10. mit der Bedingung input_boolean.dess_eingefroren = on: sie läuft nur noch, wenn wirklich eingefroren war, und löscht den Merker als letzte Handlung. Eine Freigabe abzuschalten wäre das Gegenteil des Auftrags gewesen, darum blieb sie an. Sie läuft bei Moduswechsel weg von now, Ladeende, zurückgenommener Schnellwahl, abgelaufenem Preisfenster — und als Notbremse nach sechs Stunden.

Gemessen in der Nacht zum 18.10.2026. Dietrichs Ladung 03:00–04:15, 12,06 kWh, Einkaufsschnitt 0,331 €/kWh. Von 158 Messwerten der DC-Batterieleistung lagen 155 im Ruhebereich bei −73 W; zwei Ausschäge von +8,1 und +8,3 kW über fünf Sekunden beim Start, −367 W beim Ladeende. Der Hausakku hat nichts ins Auto abgegeben. Der Mindest-SoC stand von 03:00 bis 04:04 auf 35 statt 20. Die Notbremse hat nie ausgelöst — sie ist damit weiterhin nicht im Feld erprobt.

Zwei Fallen, beide am 18.10. ins Netz gegangen

skip_condition überspringt die eigene Prüfung. Die Sperre vor der Freigabe stösst den Wachhund mit automation.trigger und skip_condition: true an — genau das übergeht dessen Bedingung charging = on. Weil die Maske wegen eines rechnerischen Rests von 0,6 kWh jede Viertelstunde eine Preisgrenze setzte und das Kabel steckte, wurde der Akku um 07:00 und 07:15 für eine Ladung gesperrt, die es nicht gab: charging war von 06:00 bis 08:00 durchgehend aus. Der Wachhund überschrieb dabei zweimal Slot 0, während VRM den Akku günstig auf 50,63 % laden wollte — er blieb bei 45 % stehen. Behoben: gesperrt wird nur noch, wenn schon Strom fliesst oder das Tor in diesem Lauf neu geöffnet wird und die Wallbox nicht „Ladung beendet“ meldet.
Ein ladender Hausakku ist nicht automatisch ein Fehler. Um 07:00 meldete die Statusüberwachung „Teurer Netzbezug IN DEN HAUSAKKU, 9870 W bei 0,336“. Falsch: DESS hat den Akku 06:04–06:59 planmässig von 35 auf 45 % geladen und in der teuren Phase wieder entladen, bei Preisen bis 0,413. Der Beleg ist der Ziel-SoC: liegt er über dem Ist-Stand und steht der Modus nicht auf node_red, ist das Laden Teil des Fahrplans. Alarm bleibt es nur, wenn DESS es nicht vorsieht — oder wenn wir selbst eingefroren haben, denn dann darf der Akku überhaupt nichts aus dem Netz nehmen.

Wie es werden soll

Beschlossen am 23.10.2026 — drei Veränderungen gegen die Kette oben

1. Erst nachsehen, ob DESS den Akku schon selbst hält. Der Wachhund schreibt heute jede Minute sein eigenes Fenster und stellt den Modus auf 4 — auch dann, wenn DESS den Netzbezug ohnehin gestellt hätte. Damit nimmt er VRM den Plan ohne Not weg. Die Prüfung dafür ist gebaut und liegt ungenutzt in nachbar_fenster.py: akku_gesichert() erkennt drei Lagen — Strategie idle_maintain_targetsoc (der belastbare Beleg) · Soll-SoC = Ist-SoC ± 1 · Stand am Mindest-SoC. Der Mindest-SoC allein zählt ausdrücklich nicht, sein Ruhewert ist 20 und bis dahin darf der Akku abgeben.

2. Keine Sicherung von Slot 0 mehr — Begründung im Abschnitt oben. input_text.dess_slot0_sicherung und der Zurückschreib-Zweig der Freigabe können entfallen; der Moduskniff bleibt.

3. Der Wachhund bleibt ein Wachhund. Steigt DESS mitten in der Ladung aus dem Netzbezug aus, muss das System es im Minutentakt bemerken und wieder einfrieren. Das ist der Grund für den Minutentakt und bleibt es: läuft ein Fenster ohne Nachfolger ab, fällt DESS sofort auf Eigenverbrauch zurück.

Und die offene Idee dahinter: weil der Fahrplan zwölf Stunden voraus lesbar ist, liesse sich die Autoladung an ein DESS-Fenster anhängen, das den Akku ohnehin still hält — dann braucht es gar keinen Eingriff. Ob sich das lohnt, ist offen: DESS hält den Akku typischerweise still, um ihn für eine teure Stunde zurückzuhalten (belegt am 22.10. um 00:00: Soll-SoC 36 bei Stand 36, Netzbezug 2.646 W von DESS selbst gestellt) — während die Lademaske umgekehrt die billigsten Stunden sucht. Wie oft sich beide Fenster treffen, ist nicht durch Nachdenken zu klären, das muss mitgeschrieben und gezählt werden.

Was noch offen ist

Erledigt am 23.10.2026: ob VRM im Modus 4 aufhört zu schreiben — nein, es schreibt weiter. Messung im Abschnitt oben.

Warum VRM in Soc nur 0 und 100 schreibt, ist ungeklärt — die VRM-Seite ist nicht quelloffen.

Wie oft ein DESS-Fenster in die billigen Stunden fällt, ist ungezählt — siehe den Kasten oben. Dazu muss der Fahrplan über einige Tage mitgeschrieben werden.