openWB Forum

Danke für deine ausführliche Erklärung – das macht die Unterschiede zwischen den Herstellern deutlich.

Genau da sehe ich aber das Problem: Wenn OpenWB sich komplett auf die jeweiligen Schnittstellen verlässt, muss das für zig Hersteller dauerhaft gepflegt sein. Das ist zwar bei anderen Modulen auch so, aber das Auslesen von PV Daten ist halt auch nicht kritisch. Sobald ein Hersteller etwas ändert, kann es passieren, dass der Mindest-SoC nicht mehr beachtet wird – wie ich es gerade mit Victron erlebt habe. (Problem müsste noch gesucht werden - noch ist nicht klar warum das so passieren konnte)

Darum mein Vorschlag: Zusätzlich zu den herstellerspezifischen Lösungen wäre ein einfacher, generischer Fallback in OpenWB sinnvoll. OpenWB kennt ja den SoC sowieso. Wenn man in der UI z.B. 15 % als Mindest-SoC eintragen kann, könnte OpenWB beim Erreichen dieses Werts die aktive Speichersteuerung einfach sperren.

Das wäre kein Ersatz für die Herstellermodule, aber ein zusätzlicher „doppelter Boden“, der verhindert, dass ein Speicher im Ernstfall komplett leergezogen wird.

Grundsätzlich würde ich es natürlich begrüßen das die Speichersteuerung nicht nur die Entladung, sondern auch die Beladung steuern würde. Das habe ich aber auch schon öfter an verschieden Stellen angemerkt.

Selbst ein kurzes Feedback würde schon zeigen: „Wir haben es gesehen, wir nehmen es ernst“

Wir haben es gesehen und das wird ernst genommen und diskutiert.
Etwas mehr als eine Woche ist aber dennoch nötig.


Zu Victron:
Die konfigurierte Grenze als Reserve ist absolut keine harte.
Die openWB kann in keinem Fall die Grenzen des BMS überschreiten.

Ich dachte es gäbe nur SolarEdge, die auf die Idee kommen, dass Leer <> 0% ist. Wenn das auch andere Hersteller machen (sowohl konfigurierbar als auch auslesbar oder halt nicht) sollte es vielleicht doch lieber global in der openWB gelöst werden. Dann kann man das für alle Module einheitlich nutzen.

Wenn man also einen Mindest-SoC (Ich will nicht mehr entladen) und einen Reserve-SoC (Ich darf nicht mehr entladen und die Steuerung muss beendet werden) einführen möchte, wäre dabei m.E. folgendes zu beachten:
Der Mindest-SoC ist ein globaler Wert, der über verschiedene Speicher hinweg gilt.
Der Reserve-SoC müsste in jedem Speicher-Modul existieren, da er bei mehreren vorhandenen Speichern sogar in einem System unterschiedlich sein könnte.
Im Normalfall würde dieser Reserve-SoC einen Default-Wert von 0% erhalten für alle Speicher die ihn nicht brauchen. Bei SolarEdge z.B. müsste der Default-Wert aber auf 15% stehen.
Für Speicher, die ein Auslesen eines (zusätzlichen) Reserve-SoC unterstützen (Bei SolarEdge z.B. die Backup-Reserve, bei Victron dann z.B. der konfigurierte Wert) müsste dieser (höhere) Wert in der normalen Update-Funktion mit ausgelesen werden und den Reserve-SoC dynamisch aktualisieren.
Dann könnte die Funktion set_power_limit dies bereits berücksichtigen und es muss dort nichts geändert werden.
Wenn der Mindest-SoC erreicht wird, wird power_limit=0 übergeben, wenn der Reserve-SoC erreicht wird, power_limit=null. Damit wären o.g. Anforderungen erfüllt ohne dass in den vorhandenen Modulen etwas angepasst werden müsste.

Schwieriger finde ich aber, den Unterschied zwischen Mindest-SoC und Reserve-SoC dem geneigten Anwender einfach darzustellen, da sie ja unterschiedliche Funktionen haben und daher nicht verwechselt werden dürfen.

Gerade bei Victron (vermutlich auch bei anderen) kommt hinzu das SoC eine nicht so relevante Zahl ist.

Das BMS begrenzt aufgrund von Spannung / Drift / usw...

Ob da berechnet noch 2% oder 7% steht ist vollkommen egal.

Wenn eine Zelle z.b. unter 3V fällt ist entladeende, egal was dann die openWB sagt.

Dann macht also (bisher bekannt) nur SolarEdge diese Sonderlocke?
Dafür brauchen wir dann natürlich keine Klimmzüge machen, da ist es ja schon umgesetzt.

Es ist anzunehmen das aber selbst im Solaredge das BMS den Akku vor Tiefentladung schützt und irgendwann (bevor der Akku wirklich einen Defekt erleidet) trennt. Will natürlich niemand testen, ist auch klar. Mit 100%iger Sicherheit weiß man es auch nicht,

Bei Kai bzw bei Victron ist das Thema (haben vor vorher getestet): In unserem damaligen Test zur Integration haben wir extern per Modbus die Befehle zum Entladen gegeben und mit einer fixen Vorgabe entladen bis zu einem angepassten SoC Wert (minSOC), dann hat Victron die Entladung des Speichers abgebrochen.
Nun ist es aber so das openWB bei power_limit > 0 alle 10sek einen neuen Wert schreibt und genau das führt dazu, der Speicher hört bei minSOC auf zu entladen, mit einem erneuten Übergaben einer Leistung fängt er aber wieder an zu entladen bis er kurz danach wieder stoppt das Spiel geht so weiter. Ob das nun eine Besonderheit von Victron ist oder vllt sogar ein Bug, kA. Auch hier wird vermutlich das BMS des Akkus (Pylontech etc) den Akku vor Tiefentladung schützen wie Kevin richtig schreibt, nur 100% sicher ist das ja auch nicht
Bei Sungrow hab ich das auch getestet, da kann ich weiter ein power_limit > 0 schreiben, der Speicher reagiert danach nach unterschreiten des SoC Werts aber nicht weiter darauf. SMA vermutlich das gleiche, weil gleiche Hardware wie Sungrow

In meiner vorherigen Ausführung/Idee war der Mindest(Nutz) SoC genau dafür angedacht: Ich habe einen min(Nutz)SoC und einen max(Nutz)SoC, belege diese mit einem Standartwert (z.B. 40 und 100%) und nur in diesem Bereich des SoC arbeitet das power_limit. Bin ich ausserhalb des Bereichs dann wird umgeschaltet auf power_limit=none, also Selbstregelung des Speichers.
Hat den Charme der User kann selbst entscheiden in welchem Bereich des SoCs der Speicher mit einer Steuerung durch openWB genutzt wird und ausserhalb des Bereichs ist er in einem sicheren Eigenregelmodus. Der SoC ist sowieso vorhanden in den Batterien bzw aus den entsprechenden Modulen. So muss man aber nicht noch selbst dort eine Logik dort einbauen, wenn die übergeordnet vorhanden ist. Das war auch die Intension hinter "klare Struktur ohne Wildwuchs".

Auch klar SoC ist nicht SoC, der ist auch nicht einheitlich geregelt, so gibt es nen realen und nen angezeigten SoC, nen minSoC, ReserveSoC etc. und letztendlich ist das ja auch nur ein errechneter Wert, aber das beste was man hat um damit zu Arbeiten.

seaspotter hat geschrieben: So Aug 31, 2025 6:03 pm Es ist anzunehmen das aber selbst im Solaredge das BMS den Akku vor Tiefentladung schützt und irgendwann (bevor der Akku wirklich einen Defekt erleidet) trennt. Will natürlich niemand testen, ist auch klar. Mit 100%iger Sicherheit weiß man es auch nicht,

Bei Kai bzw bei Victron ist das Thema (haben vor vorher getestet): In unserem damaligen Test zur Integration haben wir extern per Modbus die Befehle zum Entladen gegeben und mit einer fixen Vorgabe entladen bis zu einem angepassten SoC Wert (minSOC), dann hat Victron die Entladung des Speichers abgebrochen.
Nun ist es aber so das openWB bei power_limit > 0 alle 10sek einen neuen Wert schreibt und genau das führt dazu, der Speicher hört bei minSOC auf zu entladen, mit einem erneuten Übergaben einer Leistung fängt er aber wieder an zu entladen bis er kurz danach wieder stoppt das Spiel geht so weiter. Ob das nun eine Besonderheit von Victron ist oder vllt sogar ein Bug, kA. Auch hier wird vermutlich das BMS des Akkus (Pylontech etc) den Akku vor Tiefentladung schützen wie Kevin richtig schreibt, nur 100% sicher ist das ja auch nicht
Bei Sungrow hab ich das auch getestet, da kann ich weiter ein power_limit > 0 schreiben, der Speicher reagiert danach nach unterschreiten des SoC Werts aber nicht weiter darauf. SMA vermutlich das gleiche, weil gleiche Hardware wie Sungrow

In meiner vorherigen Ausführung/Idee war der Mindest(Nutz) SoC genau dafür angedacht: Ich habe einen min(Nutz)SoC und einen max(Nutz)SoC, belege diese mit einem Standartwert (z.B. 40 und 100%) und nur in diesem Bereich des SoC arbeitet das power_limit. Bin ich ausserhalb des Bereichs dann wird umgeschaltet auf power_limit=none, also Selbstregelung des Speichers.
Hat den Charme der User kann selbst entscheiden in welchem Bereich des SoCs der Speicher mit einer Steuerung durch openWB genutzt wird und ausserhalb des Bereichs ist er in einem sicheren Eigenregelmodus. Der SoC ist sowieso vorhanden in den Batterien bzw aus den entsprechenden Modulen. So muss man aber nicht noch selbst dort eine Logik dort einbauen, wenn die übergeordnet vorhanden ist. Das war auch die Intension hinter "klare Struktur ohne Wildwuchs".

Auch klar SoC ist nicht SoC, der ist auch nicht einheitlich geregelt, so gibt es nen realen und nen angezeigten SoC, nen minSoC, ReserveSoC etc. und letztendlich ist das ja auch nur ein errechneter Wert, aber das beste was man hat um damit zu Arbeiten.

Schade, dann meintest Du nur das ,was ich vorher also Reserve-SoC beschrieben habe.
Die Idee des (zusätzlichen) Mindest-SoC fand ich aber ganz nett, da man dann als Anwender z.B. eine Restladung im Speicher für das Haus "aufheben" könnte, die nicht für´s Autoladen verwendet wird.
Dafür darf die Steuerung aber nicht beendet werden, da ja sonst sofort wieder vollständig entladen wird.

Deine Intension "klare Strukturen ohne Wildwuchs" in allen Ehren, verstehe ich auch, aber wenn man bei Victron einen "Wunsch SoC" konfigurieren kann (lese ich so aus Deiner Beschreibung), dann müsste dieser, da er ja gerätespezifisch ist, in jedem Fall im Batterie-Modul ausgelesen werden.
Solange es dafür noch keine zentrale Konfiguration durch openWB gibt, müsste es in der Funktion set_power_limit umgesetzt werden, wenn es später zentral umgesetzt ist, muss es nur in die normale Updatefunktion "auswandern".
Aber jegliche Änderung wird ja sowieso erst in die 2.1.9 einfließen, da wir bereits im Beta-Stadium sind.
Mal sehen, ob dann bereits so eine zentrale Konfiguration vorgesehen wird.

Das BMS kann bei SolarEdge auch nicht übersteuert werden, wenn ein Reserve- oder Backup-SoC definiert ist, gewinnt der immer, auch bei externer Steuerung.
Wie Kevin geschrieben hat, ist das bei Victron ja auch sichergestellt. Allerdings enlädt er dann ggf. unter Deinen Wunsch-SoC, wenn einer definiert war, solange das noch nicht berücksichtigt wird.

ChristophR hat geschrieben: So Aug 31, 2025 7:46 pm Schade, dann meintest Du nur das ,was ich vorher also Reserve-SoC beschrieben habe.
Die Idee des (zusätzlichen) Mindest-SoC fand ich aber ganz nett, da man dann als Anwender z.B. eine Restladung im Speicher für das Haus "aufheben" könnte, die nicht für´s Autoladen verwendet wird.
Dafür darf die Steuerung aber nicht beendet werden, da ja sonst sofort wieder vollständig entladen wird.

Bevor wir uns in widersprüchlichen Begrifflichkeiten verirren:
Es gibt in jedem Speicher verschiedener Hersteller einen minSoC und einen maxSoc. Manchmal kann der durch den User verändert werden, manchmal nur durch den Installateur/Hersteller. MaxSoC ist in 99% aller Fälle immer 100%, minSoC ganz oft 5%. In diesem Bereich arbeitet der Speicher, technisch gesehen interessiert den Speicher der SoC nicht, weil das BMS auf die Zellenspannung schaut wann er voll und leer ist, aber das nur nebenbei. Für den User ist das was er sieht der SoC. Diese Begrifflichtkeiten sind meines Wissens nach bei allen Speichern genormt. Einige besitzen noch einen Reserve SoC (bei dir vielleicht Backup SoC), dieser Wert wird hergenommen um im Normalbetrieb noch etwas mehr wie minSoC im Speicher zu behalten um im Blackoutfall das Haus mit Strom zu versorgen. Also ist ReserveSoC > minSoC. Im Normalbetrieb wird der Speicher auch nur bis ReserveSoC verwendet und dann stoppt die Entladung. Ist also bei allen Hybridanlagen meist so, die eine Notstromversorgung haben. Ich kenne diesen Wert so von verschiedenen Herstellern. Die Begrifflichkeiten können sicher bei jedem Hersteller anders heißen, aber meine Auflistung soll mal dazu dienen, dass wir über das gleiche sprechen.

All diese SoCs will ich weder auslesen, noch verändern noch anzeigen noch irgendwas. Die Einstellung ist rein Kunden bzw. Installateurspezifisch.
Mein Vorschlag ist ein nutzbarer SoC einstellbar im UI der sich rein auf die aktive Steuerung innerhalb der openWB bezieht. Dieser muss natürlich im min und max Bereich des SoCs liegen, bei einem Reserve SoC auch darüber.
Einfaches Beispiel eines Speichers (minSoC 10%, maxSoC 100%, ReserveSoC 20%). Ich stelle in openWB für den nutzbaren SoC Bereich ein: 40-100%. Dann nutzt openWB zum Entladen (bei Einstellung für Hausverbrauch) den Speicher bis 40% SoC und entlädt ihn und stoppt diese aktive Steuerung bei 40%. Dann ist genau das was du beschrieben hast gegeben: Zwischen 20 und 40% kann ich den Speicher dann für die Selbstregelung und den Hausverbrauch verwenden (ohne aktive Steuerung aus openWB). Lade ich dann weiter das Auto, wird natürlich im "immer"-Modus (power_limit=none) trotzdem entladen, aber in Selbstregelung, sprich es hört bei Unterschreiten der Speicher-eigenen minmalen SoC / Zellspannung auf zu entladen und der Eigenschutz ist gegeben, ich muss keinerlei SoC Überwachung einbauen.
Gleiches gilt wenn zukünftig mit einem positiven power_limit geladen werden kann, vielleicht will ich meinen Speicher nicht bis 100% preisbasiert laden, sondern nur bis 90% dann stelle ich eben als nutzbarer Bereich 40-90% ein.

Deine Intension "klare Strukturen ohne Wildwuchs" in allen Ehren, verstehe ich auch, aber wenn man bei Victron einen "Wunsch SoC" konfigurieren kann (lese ich so aus Deiner Beschreibung), dann müsste dieser, da er ja gerätespezifisch ist, in jedem Fall im Batterie-Modul ausgelesen werden.
Solange es dafür noch keine zentrale Konfiguration durch openWB gibt, müsste es in der Funktion set_power_limit umgesetzt werden, wenn es später zentral umgesetzt ist, muss es nur in die normale Updatefunktion "auswandern".

Bei Victron gibt es keinen Wunsch-SoC und ich versteh auch nicht was du da gelesen hast, habe ich so nicht beschrieben. Zu Testzwecken wurde der minSoC Wert nach oben gesetzt. Siehe oben., wird im Normalbetrieb weder benötigt, noch ausgelesen, noch verändert noch sonst irgendwo gebraucht. Nicht mehr und nicht weniger.

Das BMS kann bei SolarEdge auch nicht übersteuert werden, wenn ein Reserve- oder Backup-SoC definiert ist, gewinnt der immer, auch bei externer Steuerung.
Wie Kevin geschrieben hat, ist das bei Victron ja auch sichergestellt. Allerdings enlädt er dann ggf. unter Deinen Wunsch-SoC, wenn einer definiert war, solange das noch nicht berücksichtigt wird.

Siehe oben

seaspotter hat geschrieben: So Aug 31, 2025 8:34 pm All diese SoCs will ich weder auslesen, noch verändern noch anzeigen noch irgendwas. Die Einstellung ist rein Kunden bzw. Installateurspezifisch.
Mein Vorschlag ist ein nutzbarer SoC einstellbar im UI der sich rein auf die aktive Steuerung innerhalb der openWB bezieht. Dieser muss natürlich im min und max Bereich des SoCs liegen, bei einem Reserve SoC auch darüber.
Einfaches Beispiel eines Speichers (minSoC 10%, maxSoC 100%, ReserveSoC 20%). Ich stelle in openWB für den nutzbaren SoC Bereich ein: 40-100%. Dann nutzt openWB zum Entladen (bei Einstellung für Hausverbrauch) den Speicher bis 40% SoC und entlädt ihn und stoppt diese aktive Steuerung bei 40%. Dann ist genau das was du beschrieben hast gegeben: Zwischen 20 und 40% kann ich den Speicher dann für die Selbstregelung und den Hausverbrauch verwenden (ohne aktive Steuerung aus openWB). Lade ich dann weiter das Auto, wird natürlich im "immer"-Modus (power_limit=none) trotzdem entladen, aber in Selbstregelung, sprich es hört bei Unterschreiten der Speicher-eigenen minmalen SoC / Zellspannung auf zu entladen und der Eigenschutz ist gegeben, ich muss keinerlei SoC Überwachung einbauen.
Gleiches gilt wenn zukünftig mit einem positiven power_limit geladen werden kann, vielleicht will ich meinen Speicher nicht bis 100% preisbasiert laden, sondern nur bis 90% dann stelle ich eben als nutzbarer Bereich 40-90% ein.
...
Bei Victron gibt es keinen Wunsch-SoC und ich versteh auch nicht was du da gelesen hast, habe ich so nicht beschrieben. Zu Testzwecken wurde der minSoC Wert nach oben gesetzt. Siehe oben., wird im Normalbetrieb weder benötigt, noch ausgelesen, noch verändert noch sonst irgendwo gebraucht. Nicht mehr und nicht weniger.

Dann bleiben wir gerne bei Deiner Begriffsdefinition.

Ich bin bisher davon ausgegangen, dass der minSoC bei anderen Herstellern quasi als 0% angezeigt wird und es bei SolarEdge eine Besonderheit ist, dass bei z.B. 10% Entladung immer Schluss ist.
Bei der Verwendung der HomeBattery in SolarEdge wird dies nämlich auch so gehandhabt, daher meine Annahme, die dann wohl falsch ist.
Dass 0% natürlich nur eine Fake-Anzeige ist, die eine interne Reserve enthält, damit die Speicher nicht kaputt gehen, war mir dabei schon bewusst.

Den minSoC oder den höher konfigurierten ReserveSoC will ich schon auslesen, weil ich dann die externe Steuerung beenden will.
Wenn ich das nicht mache und die externe Steuerung bleibt aktiv (auch wenn sie nichts mehr zu steuern hat), dann erfolgt keine Zwangsladung, wenn der SoC (Durch Selbstentladung oder Neuberechnung im BMS) weiter fällt.
Für openWB spielt es dabei keine Rolle, ob es der minSoC des Herstellers oder ein höher konfigurierter ReserveSoC wegen vorhandenem Backup Modul o.ä. ist. Ich muss einfach nur wissen, bis zu welchem SoC ich effektiv entladen kann.

Ich bleibe bei Deinem Beispiel, nutze aber den Modus "Hausverbrauch", da im Modus "Immer" eh keine Steuerung erfolgt.
Während das Fahrzeug lädt, wird also immer nur der Hausverbrauch entladen, bis die eingestellten 40% erreicht sind.
Wenn nun die Steuerung beendet wird, wird sofort bis 20% entladen und das wollte ich ja nicht, es sollte nur bis 40% entladen werden.
Daher dachte ich an eine Einstellung, dass die Steuerung den Hausverbrauch bis 40% beim Fahrzeugladen entladen lässt, dann aber den Speicher sperrt, damit er nicht weiter entladen wird.
Wenn dann die Ladung des Fahrzeugs beendet wird, habe ich weiterhin 40% im Speicher, um Herd, Waschmaschine, Wärmepumpe o.ä. noch aus dem Speicher bedienen zu können, bevor er wieder aufgeladen wird, da die verfügbare PV-Energie bei Laden ja im Auto gelandet ist.
Das war der Use-Case an den ich bei "Deiner Idee" dachte.
Wen das keiner braucht, auch gut. Ist ja auch wieder nur ein "rechte Tasche, linke Tasche"-Ding, aber manche Anwender haben ja besondere Wünsche.

P.S: Mit Wunsch-SoC meinte ich den veränderten minSoC, den Du beschrieben hattest.

Ich möchte meinen Input zum Abschluss noch einmal kurz zusammenfassen:

1. Min- und Max-SoC in der UI:
Die Idee, einen Slider für Mindest- und Max-SoC zu implementieren, unterstütze ich ausdrücklich. Besonders der Max-SoC macht perspektivisch Sinn, falls OpenWB den Speicher auch aktiv laden soll. So könnte OpenWB irgendwann alle Steuerungen zentral regeln, ohne dass man in mehrere Systeme (PV, Speicher, Auto etc.) eingreifen muss.

2. Use Case Speicherladung bei Auto-Ladevorgang:
Aktuell wird der Speicher bei aktiver Speichersteuerung nicht geladen. OpenWB unterscheidet momentan nur zwischen „Speicher sperren“ oder „Entladen in Höhe des Hausverbrauchs“. Der PV-Überschuss wird immer komplett ins Auto geleitet – was problematisch ist, wenn es nicht das eigene Auto ist (z. B. Gäste oder Nachbarn) oder wenn man den Speicher gezielt für die Nacht füllen möchte.

3.Vorschlag zur Logik:
Wenn ein Auto lädt (z. B. 11 kW), sollte diese Ladeleistung für die Speicherregelung ausgeklammert werden. Der PV-Überschuss (PV-Ertrag minus Hausverbrauch) sollte zuerst in den Speicher fließen. Sollte der Speicher bereits gesättigt sein (z. B. bei mir nur 1,7 kW Ladeleistung), geht der verbleibende Überschuss ins Auto. Nur wenn der PV-Überschuss den Hausverbrauch nicht deckt, darf der Speichernatürlich in Höhe Hausverbauch entladen werden. So wird der Speicher effizient geladen, teurer Netzstrom vermieden und die eigene Energie optimal genutzt.