Batterie Management

[weindler]

Ich habe mir die neue Entwicklung zum Batteriemanagement angesehen, ich komm hier einfach nicht mit wie das beschrieben ist.

Also ich habe nun unter dem Wirkungsgrad mal 0.1 eingegeben dann habe ich 2 Datenpunkte unter User angelegt einer für das Batterie laden und der 2 für das nicht entladen.

Nun habe ich gemeint dass z.b für 15 Uhr der Preis "normal" angegeben wird und das laden und entladen auf falsch gesetzt wird, dem ist aber nicht so das entladen ist true.

@hombach könntest du das mal für Dummies erklären wie und was man da genau einstellen soll. Und wie du das rechnest?

Aber zu erst. Danke für das Entwickeln des tollen Adapters.

[hombach]

Im Test-System mit den Demo Daten von Tibber sieht das z.B. so aus:

ergibt dieses Verhalten:

Mal auf den 16.12. gezoomt:

• hier sieht man schön die 7h zum Laden, die sich in 2 Blöcke aufteilen (13-14h und 18-24h) - Ausgang SBB-Charge wird auf den definierten "YES" Wert gesetzt - hier "True"
• Teuerster Preis war um 13:00 mit 0,2957 - der durchschnittliche Preis der 7 Stunden war 0,2057
• Auf den teuersten Preis die 20% Verlust ergibt einen Preis von min. 0,3368 als Trigger für das Einspeisen mit der Batterie.
• Im lila Block der Batterie Einspeissung ist der beste Preis um 10:00 mit 0,3405 - dort wird der 2te Datenpunkt auf den "YES" Wert gesetzt hier "True"

Jetzt muss man sehen wie das in die eigene Umgebung passt - in meinem Live System sieht es z.B. etwas anders aus:

Wert 1 steuert hier das Laden der Batterie - YES = true = Laden
Wert 2 steuert das Victron ESS System direkt an, hier gibt es einen Datenpunkt "Dissable Feed-In" dieser erwartet Zahlenwerte, sprich YES = 0 = Einspeisen - bzw. NO = 1 = Dissable Feed-In

Ist echt blöd zu erklären - du bist doch Ausbilder.... mach mir mal eine schöne Beschreibung;)

Ich denke 0,1 als Verlust ist physikalisch nicht erreichbar UND was dabei verwirrend wird: Aufgrund des Mittelwerts der "billigen" Ladestunden kann es sehr oft sein, dass es gar keine "normale" Stunden gibt. Probier doch mal mit größeren Werten, dann läßt sich das Verhalten beim Testen auch besser beobachten.

[weindler]

OK, nun stell ich dir Mal meines zusammen so wie ich das bisher über blockly gelöst habe.

1. Die billigsten 2 oder 3 Stunden als Ladestunden deklarieren um die Batterie zu laden, egal jetzt wie voll das kann man über blockly machen und nach seinen Gegebenheiten einrichten.
2. Unter dem Durchschnittspreis des Tages oder einem Festpreis der vom User bestimmt werden
   kann, sollte die Batterie nichts entladen und einfach auf standbye stehen. Nur Beladung über PV möglich, Entladung verboten.
3. Über dem Durchschnittspreis des Tages, oder einem Festpreis der vom User festgelegt werden kann + Wirkungsgrad sollte die Batterie zum normalen Arbeiten gezwungen werden. Also Abgabe von Strom ins Haus.

Ich habe ja die Sonnenbatterie, hier läuft das folgendermaßen ab. Es gibt 2 datenpunkte Charge und discharge.

Mit diesen 2 Punkten kann man der Batterie sagen was sie tun soll.

Alle 10 Sekunden muss der Wert Charge beschrieben werden mit z.b 4500 ( bedeutet die Batterie läd mit 4500 Watt aus dem Netz oder bei PV füllt sie den netzbezug mit der Leistung auf um auf 4500 zu kommen

Alle 10 Sekunden discharge mit z. B dem Wert 0 verbietet der Batterie Strom ins Netz abzugeben.

Wichtig zwischen den beiden schaltzuständen müssen mindestens 30 Sekunden sein damit die Batterie nicht auf Error geht

So das war nun Mal meine Erklärung wie ich mir das vorstelle. Würde mich freuen wenn du zu meinem Vorschlag was anmerken würdest.

Natürlich könnte man nun noch so art KI einbauen z.b automatische beladezeit der Batterie bei verschiedenen ladeständen und beladeleistung( Script bereits vorhanden)

Grundlast der verschiedenen Wochentage so könnte man voraussagen was man an batteriekapazität für mo, die, Mittwoch usw. Braucht und nur den Hausspeicher auf das nötige Level laden. (Script bereits vorhanden)

Ist Schnee auf den Modulen, jeden Tag auf 100% Laden

[hombach]

Da sind wir sehr dicht beieinander.... die 10 Sekunden Wiederholung für die Steuerung braucht ein Victron System auch. Das mache ich auch mit einem nachgelagerten Blockly Script.

Die Dauer der Ladung anhand des Ladezustands müsste man dem TibberLink Adapter auch geben (AmountHours). Hier kann man natürlich auch etwas an den Werten drehen um Winterbetrieb / Sommerbetrieb / Schnee auf den Modulen etc. zu berücksichtigen.

Die Festlegung von Festpreis habe ich nicht im Adapter, alles Dynamisch mit Bezug auf den geladenen Strom.
Kommt aber in vielen Situationen auf ähnliche Ergebnisse - spannend ist die "Aggresivität" die man ja noch über eine variable "Efficiency Loss" ändern könnte.

Mir gefällt eben beim Nachdenken die Idee der Beeinflussung über das Verhältnis der Durchschnittswerte der Preisblöcke - siehe #240

[hombach]

Man sieht hier allerdings auch schön die Grenzen des Logik .... wenn der Preis wie hier über 3 Tage recht einheitlich am Sinken ist, dann lädt man teurer wie die Einspeisung am Tag drauf. Es existiert ein issue um noch die in der Berechnung ermittelten Mittelwerte auszugeben #240 .... hier könnte man noch optimieren indem man dies speichert und am nächsten Tag als Trigger verwendet.... sozusagen den Preis des Stroms in der Batterie speichern... ???

Was ich auch noch probieren möchte, ist, was passiert, wenn ich immer Preise für heute UND morgen zusammen heranziehe - sofern schon vorhanden.

[weindler]

Kann man bei "Amount Hours" auch 0 eingeben, daß die Batterie nicht geladen wird und nur das nicht entladen durchführt?

[hombach]

nein - die definition des efficiencyLoss greift dann ins Leere....

[weindler]

Hier wird es nie eine 100% zufriedenstellende Lösung geben das ist klar. Was man aktuell auch als Vorhersagen nehmen könnte wäre der Wind und das Wochenende. Da die Preise grundsätzlich am WE günstiger sind, aber wer kann schon 3 oder 4 Tage von seiner Batterie zerren.

Am Donnerstag, Freitag dieser Woche müssten die Preise regelrecht abstürzen außer es ist schon zu stürmisch, wird sich rausstellen.