openWB Forum

Auf Anfrage eines anderen Nutzers habe ich hier ein neues Thema erstellt, welches sich aus einem anderen ergeben hat.

Ursprungsthema:
Zielladen mit Tibber: viewtopic.php?t=8592

Worum geht es:
Der Hausspeicher soll nur dann entladen werden, wenn es kostenseitig Sinn macht (Tibber). Um die sinnvollen Stunden zu ermitteln, wird der zu erwartende PV Ertrag mit einbezogen.

Bisheriger Post von mir: viewtopic.php?p=106356#p106356

"Ich habe dafür bei mir auf einem Raspberry die Tibber-Daten abgefragt.
Dann wird die Preisliste/Std. nach Preisen sortiert.
Danach wird der SOC des Speichers ausgelesen und anhand dessen geschätzt, wie viele Stunden dieser noch durchhält.
Weiterhin habe ich über forecast.solar die zu erwartenden Sonnenstunden und kWh geholt/berechnet.

Die sortierte Tibber-Preisliste (teuerste Stunden stehen oben) wird nun "beschnitten":
Es fallen alle vergangenen Stunden raus und in der Zukunft die, die nach einer erneuten Ladung sind (das kommt von forecast.solar). Falls keine Ladung durch PV zu erwarten ist, bleiben in der Liste auch die Stunden bis zum Abend des nächsten Tages.

Dann wird aus der sortierten und gefilterten/beschnittenen Liste nur der teuerste Teil (Anzahl der Stunden = verbleibende Rest-kWh des Akkus anhand SOC) genommen. Zu den übriggebliebenen Zeiten wird der Akku zum Entladen freigegeben (ist am Victron per MQTT gelöst) und ansonsten wird per Tibber der Strom aus dem Netz geholt. Somit wird der Akku nur für die teuersten Stunden verwendet. Der Speicher behält dann immer die notwendige Energie, um die höchstmöglich-bekannten Preise abzudecken.

Das ist ein kleines Python Script. Wäre natürlich schön, wenn das mit einfließen könnte. Aber mittels kleiner Logik wie beschrieben geht das auch so separat.

Läuft bis jetzt schön stabil. Probleme mit dem Tibber-Auslesen gab es auch noch keine."

Nachfrage von "truth": viewtopic.php?p=106382#p106382

"Klingt interessant.
Wie hast du denn das Script in die OpenWB Software integriert? ... als eigenständiges Modul?
Der Wirkungsgrad des Speichers kann bei langsamen Lade- und Entladevorgängen schnell mal unter 50% fallen kann.
Wenn du den Wirkungsgrad des Speichers nicht miteinbeziehst, sparst du evtl. weniger ein als du denkst.
Wie hast du den Speicher via MQTT an der Entladung gehindert? Gibt's dazu einen Link?
Mach doch mal einen neues Ticket auf ... das Thema interessiert bestimmt noch mehr."

Daher dieses Thema und ich beschreibe das hier etwas weiter.

Zu den Fragen:

- Integration: Das ist nicht in OpenWB integriert, sondern läuft separat auf einem Raspberry. Da ist das Tool als Python Service installiert. Die Kommunikation zur OpenWB und zum Speichersystem (Victron Multiplus + CerboGX + Akkus) läuft über MQTT. Die Daten von Tibber werden über die Tibber API und die von "forecast.solar" über deren API (REST) abgeholt.
- Wirkungsgrad: Das habe ich nicht mit einberechnet. Finde die Angabe auch etwas dramatisch, bei minimalen Strömen kann es natürlich sein, dass der Eigenverbrauch des Systems vom Anteil her höher ist. Aber erstens hat mein Haus einen Grundverbrauch von ca. 700 W - so gering ist also das Entladen selbst nachts nicht. Und zweitens kommt dann bei steigendem Strom (I=U/R) auch der Leitungsverlust hinzu. Aber wie gesagt, das habe ich nur pauschal mit einbezogen, da ich eine Schätzung zum Stromverbrauch in kWh pro Zeiteinheit (1 Std) gemacht habe. Ich gehe also aktuell von 1 kWh / Stunde aus bei unserem Haus. Das kommt recht gut hin - gerade in den Abendstunden. Kochen ist da natürlich nicht mit drin. Aber das würde den Rahmen auch sprengen - Keep it simple...
- Speicherentladung verhindern: Wie oben beschrieben, habe ich einen Victron Multiplus mit CerboGX. Es gibt wohl für jedes System einen Weg. In meinem Fall gibt es einen Wert, der die maximale Entladung in Prozent regelt. Auf der Console schaut das so aus:
"sudo mosquitto_pub -h [IP-ADDRESSE] -t 'W/[XXXXXXXXX]/settings/0/Settings/CGwacs/MaxDischargePercentage' -m '{"value": 100}'"
Das [XXXXXXX] ist die ID des Victron Systems und [IP-ADDRESSE] die Adresse. Durch den Value wird das Entladen also gesteuert. Analog dazu gibt es auch ein MaxChangePercentage - aber das wird hier nicht gebraucht.

Das Ziel ist also einfach, dass:

- der Akku sich nicht entlädt, wenn z.B. tagsüber der Tibber Preis niedrig ist und das E-Auto angesteckt wird und auf den Mindest-SOC geladen wird.
- der Akku sich nicht entlädt, wenn generell der Tibber Preis niedrig ist - z.B. Kochen am Nachmittag
- der Akku sich nicht Nachts entlädt, sondern die Kapazität auf die Stunden von z.B. 6-8 Uhr aufspart.
- die verbleibende Restkapazität des Akkus soll sich auf die Stunden mit dem höchsten Tibber Preis verteilen

Die Logik dazu hatte ich eingangs beschrieben. Das funktioniert wirklich gut und der Akku wird nur bei den teureren Tibber-Stunden genutzt.

Dies in OpenWB zu integrieren, ist wohl etwas zu speziell - erstmal bräuchte es dafür überhaupt eine Möglichkeit, das Speichersystem direkt anzusteuern - z.B. über MQTT

Wenn jemand Fragen zu dieser Lösung hat oder auch so etwas bauen möchte, kann ich gerne behilflich sein.

Schau mal bei EVCC, dort können Speicher bereits teilweise aktiv gesteuert werden. Eine entsprechende Anregung hatte ich hier schon mal gemacht:
viewtopic.php?p=106145#p106145

Weitere Infos bei EVCC (ein kleines Stück nach unten scrollen): https://docs.evcc.io/docs/devices/meters

Vielleicht hilft das ja schon mal weiter.

Ich kann ja den Speicher ansteuern, kein Problem. Und mittels EVCC heißt auch, dass das System von außen erreichbar ist - weil es eine Cloud Lösung ist. Das finde ich immer etwas bedenklich. Das Thema selber ist ja auch keine Frage, sondern ein Bericht, wie es umgesetzt ist und bereits funktioniert.

Ob OpenWB irgendwann eine Speicheransteuerung implementiert, ist ja eine andere Sache. Dann würde ja auch noch der Rest der Logik fehlen. Aber wenn OpenWB das machen würde, fände ich eine reine EVCC Lösung nicht schön. Denn im Intranet liegende IT Systeme von außen zugänglich zu machen, ist auch immer ein Sicherheitsrisiko. Ich finde die MQTT Lösung, die auch im Inselbetrieb funktioniert, für meine Belange besser.

Die bidirektionale Regelung kommt nativ mit openWB für die bidirektionalen Fahrzeuge.
Das wird ein stetiger Prozess wie was gehen wird nach gemachten Erfahrungen.

openWB hat geschrieben: ↑Do Apr 04, 2024 9:32 am Die bidirektionale Regelung kommt nativ mit openWB für die bidirektionalen Fahrzeuge.
Das wird ein stetiger Prozess wie was gehen wird nach gemachten Erfahrungen.

Dieses Thema hat überhaupt nichts mit bidirektionalem Laden/Entladen zu tun. Es handelt sich ja noch nicht mal um einen Fahrzeugspeicher.
Es geht hier ausschließlich um einen Hausspeicher und das Thema ist nur als Erfahrungsaustausch auf eine Bitte hin angelegt worden.
Es existiert also kein Problem - alles läuft wie es soll

Softwareleute suchen immer Gemeinsamkeiten von Problemstellungen um dann möglichst nur eine Lösung zu finden. Ob das nun eine Hausbatterie oder eine Fahzeugbatterie ist, die da gesteuert werden soll ist aus dieser Sichtweise her unerheblich.

Das mit dem Tibberstrom nur dann nehmen, wenn er billig ist, ist ja nur eine Anwendung von gesteuerter Batterie. Man kônnte sie ja auch mit billigen Tibberstrom im Winter aufladen, wenn eh keine PV vorhanden ist.

Was hier besprochen wird ist ein Teilproblem vom bidirektionalen Laden.
Ein Hausspeicher ist final wie eine Auto zu sehen das immer verfügbar ist. Von der Problematik und Logik also einfacher als ein Fahrzeug das zu Zeit x noch SoC Y haben muss.

Ich finde meinen Hinweis das die reine Logik nativ vorhanden sein wird daher durchaus sinnvoll.

Das ist ja passend - Software entwickle ich seit über 25 Jahren.
Das mit den Gemeinsamkeiten kann ja sein. Aber das Auto wird (hoffentlich) eine standardisierte Schnittstelle haben, analog zur PWM Ladesteuerung?

Der Hausspeicher hingegen ist ein komplett heterogenes Feld. Natürlich kann man es vom Softwaredesign so anlegen, dass Speicher=Speicher ist. Und natürlich wäre es schön, wenn man dann nicht nur die native Autosteuerung da einbaut, sondern gleich mehrere Optionen zur Steuerung des Hausspeichers mit vorsieht (REST/MQTT/Relaissteuerung/etc).

Sobald also die Speicheransteuerung im OpenWB bereit steht, kann man ja schauen, ob mein Anwendungsfall so gelöst werden kann - also innerhalb OpenWB.
Bis dahin wird es der Python Service bei mir weiterhin machen - und falls das jemand auch bauen möchte oder Anregungen daraus ziehen kann, für den war dieses Thema angelegt.

Es ist ja aktuell auch nicht so, dass man den Hausspeicher steuern könnte, nur weil das auch ein Speicher ist und man das Ladeverhalten des PKW kontrollieren kann. Das ist also logischerweise kein Selbstläufer. Denn selbst wenn man das in der Softwarestruktur als gleiche "Basisklasse" behandelt, sind es dennoch unterschiedliche Hardwareinterfaces - die eben auch implementiert werden wollen.
Aber schön, wenn ihr das in der Entwicklung mit berücksichtigen wollt.

Bis dahin lebe ich mit meiner Lösung.