Entladen des Speichers steuern (Tibber + PV Ertrag)

[Gero]

Denn selbst wenn man das in der Softwarestruktur als gleiche "Basisklasse" behandelt, sind es dennoch unterschiedliche Hardwareinterfaces - die eben auch implementiert werden wollen.

Genau das ist ja das Design der openWB. Es gibt die Komponente „Wechselrichter“ und die hat diverse verschiedene Hardwareausprägungen. Oder halt Speicher, bei denen aktuell nur passive Anbindung im Design verankert ist. Aber ob der nun per modbus/tcp oder per MQTT oder sonstwie ausgelesen wird, ist im jeweiligen Modul geregelt. Allen Speicher-Modulen gemein ist dass sie ein paar Werte liefern und diese zentral identisch abgehandelt werden.

[Andreas.M]

Genau Dein Satz "bei denen aktuell nur passive Anbindung im Design verankert ist" beschreibt ja aber den IST Zustand.
Dieses Thema hier geht darum, wie man den aktuellen IST Zustand mit einer kleinen Extra-Lösung verbessert.

Wahrscheinlich hätte ich das Thema hier gar nicht eröffnen sollen, sondern lieber in einem Forum zur Hausautomation. Ich wollte gar keine Diskussion über bidirektionales Laden in der OpenWB etc. - wenn es denn irgendwann da ist, gut. Bis dahin muss man sich halt anders behelfen.

Wann ist denn der Speicher in OpenWB (Release Zweig) nutzbar mit Hardwareansteuerung (also aktiv - MQTT, REST, etc.)?
Ab dann würde evtl. meine Lösung (wenn denn auch Tibber + Sonnenertragsschätzung integriert sind) durch OpenWB ersetzt werden können.

[openWB]

Wahrscheinlich hätte ich das Thema hier gar nicht eröffnen sollen, sondern lieber in einem Forum zur Hausautomation. Ich wollte gar keine Diskussion über bidirektionales Laden in der OpenWB etc. - wenn es denn irgendwann da ist, gut. Bis dahin muss man sich halt anders behelfen.

Nein. Vollkommen ok. Ich wollte nur erwähnen was noch kommt.

Wann ist denn der Speicher in OpenWB (Release Zweig) nutzbar mit Hardwareansteuerung (also aktiv - MQTT, REST, etc.)?
Ab dann würde evtl. meine Lösung (wenn denn auch Tibber + Sonnenertragsschätzung integriert sind) durch OpenWB ersetzt werden können.

Das wird dann auch hier im Forum angekündigt werden.

[hhoefling]

Interesannter Thread....

Ich habe mir bisher einen "Endladeschutz" implementiert der bei Preisgesteuertem Sofort-Laden aus dem Netz (1.9'er)
den Hausspeicher auf 1A Endladestrom runtersetzt. Er liefert dann nur noch ca. 230Watt und deckt die Grundlast ab.

Auch ein manuelles runtersetzen für 1 oder 2 Stunden habe ich ins Colour-Thema eingebaut.
Sinn ist das Entladen beim Duschen (Durchlauferhitzer) oder Backen zu verhindern.
Schalte sich automaisch nach 1 oder 2 Stunden wieder aus (Watchdog)

Preisgesteuertes Laden des Hausakkus ist paralell zum PKW-Preis-Laden auch implementiert. (abschaltbar)
In desem SInne ist der Hausakku tatsächlich ein immer anwesender kleiner PKW-Akku

Ich verwende gerne noch die 1.9er als Basis, da kann ich einfacher Erweiterungen einbauen.
HA/NR/IOB sind bei mir noch überflüssig. OpenWB deckt alles ab was ich brauche.

[Andreas.M]

Interesannter Thread....

Ich habe mir bisher einen "Endladeschutz" implementiert der bei Preisgesteuertem Sofort-Laden aus dem Netz (1.9'er)
den Hausspeicher auf 1A Endladestrom runtersetzt. Er liefert dann nur noch ca. 230Watt und deckt die Grundlast ab.

Auch ein manuelles runtersetzen für 1 oder 2 Stunden habe ich ins Colour-Thema eingebaut.
Sinn ist das Entladen beim Duschen (Durchlauferhitzer) oder Backen zu verhindern.
Schalte sich automaisch nach 1 oder 2 Stunden wieder aus (Watchdog)

Preisgesteuertes Laden des Hausakkus ist paralell zum PKW-Preis-Laden auch implementiert. (abschaltbar)
In desem SInne ist der Hausakku tatsächlich ein immer anwesender kleiner PKW-Akku

Ich verwende gerne noch die 1.9er als Basis, da kann ich einfacher Erweiterungen einbauen.
HA/NR/IOB sind bei mir noch überflüssig. OpenWB deckt alles ab was ich brauche.

Auch in interessanter Ansatz.
Aber ich wollte gleich die neue Version und hab die Steuerung lieber auf einem Extra-Raspberry. Dann bin ich nicht von OpenWB Versionen abhängig. Außerdem laufen da noch ein paar andere Python Scripts. Zum Hausakku BMS Auslesen und per MQTT an die Hausautomation verteilen. Solar-Ertrag an OpenWB und Hausautomation senden, etc.

Zum Thema Hausakku-Laden aus dem Netz:
Da habe ich Abstand von genommen, da ich folgendes zu Grunde lege:
Verlust Laden 10% + Verlust Entladen 10%
Eine kWh Strom aus dem Akkus kostet mich auf 10 Jahre gerechnet ca. 10 ct / kWh.
Bei einem Tibberpreis von 18ct zzgl. der 20% Verlust = 21,6ct und den 10 ct Akkukosten (=31,6ct) komme ich auf eine Tibber-Preisdifferenz von 13,6 ct. Ab dann fängt es erst an, sich überhaupt zu amortisieren. Und das ist so selten, dass ich diese Prozedur wieder gelassen habe. Aber machmal "juckt" es mich doch in den Fingern und aktiviere das manuell

M.E. lohnt es sich also nicht. Es sei denn, man nimmt den Akku als gegeben an und will ihn nach x Jahren eh austauschen - egal wie viele Zyklen er gelaufen ist.

So gesehen ist die Abschaltung zu günstigen Zeiten die wohl beste Möglichkeit, hier Kosten zu sparen. Das hat sich bei mir sofort bemerkbar gemacht. Denn vorher hat das e-Auto einfach den Hausakku leergesaugt und dann kamen die teuren Abendstunden...

Für alle, die so ein Script nicht haben, wäre eine in OpenWB integrierte Lösung wirklich ein wichtiges Feature.
Denjenigen, die einen Python-Rechner haben (Linux/Debian/Raspberry) und einen Victron Akku haben, kann ich mein Script geben für die Steuerung. Aber den Victron Part zum An- und Abschalten des Entladens kann man auch meist durch irgendetwas anderes ersetzen.

[Andreas.M]

Bei mir läuft jetzt nur noch das "Zielladen" - durchgehend.
Neben dem Zielladen ist noch das "Zeitladen" aktiviert - von 00:00-23:59 Uhr und SOC 25%.
Das ist also das Mindest-SOC, was immer geladen wird, wenn das Auto angesteckt wird.

Der Rest wird durch das Zielladen eben durch Überschuss bzw. Tibber-Preisladen geladen.

[truth]

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.

Ich bin mir noch nicht sicher, ob ich das verstanden habe:

Du nutzt die OpenWB Software und zusätzlich einen Raspberry, auf dem dein Script läuft - die Beiden kommunizieren über MQTT, um Informationen auszutauschen.

Ich kenne mich mit MQTT leider (noch) nicht aus.
Wie funktioniert das? Kann man über MQTT den Ladevorgang der OpenWB anstoßen?

[Gero]

Man kann die openWB komplett per MQTT fernsteuern. Konfigurieren gibg früher auch mal, das ist aber eingeschränkt worden, weil sich da zu viele die Konfiguration mit kaputt gemacht haben.

Ich nehme dafür gerne node red auf einem separaten Raspi.

Hier viewtopic.php?t=4285 habe ich mal eine kleine Anleitung geschrieben.

[truth]

Danke für die Infos und den Link - das hilft mir weiter.

[aiole]

Für alle, die so ein Script nicht haben, wäre eine in OpenWB integrierte Lösung wirklich ein wichtiges Feature.
Denjenigen, die einen Python-Rechner haben (Linux/Debian/Raspberry) und einen Victron Akku haben, kann ich mein Script geben für die Steuerung. Aber den Victron Part zum An- und Abschalten des Entladens kann man auch meist durch irgendetwas anderes ersetzen.

Danke für deinen Input.
Wenn Dein Script als reiner NodeRed-Flow verfügbar wäre, würde ich den mal mit meinem Victron-MP2-System und Venus Large-OS ausprobieren. Extra Python-tools will ich vermeiden.
VG