Dynamischen Strompreis nutzen 2.

[wiggal]

Fortsetzung von (#106)

Aktuelle Methode:

Getrennt nach Akkuladen und Entladung sperren werden folgende Schritte durchlaufen:

• Es werden alle Stunden der bekannten Strompreise durchlaufen.
• Für jede Stunde wird vom Akkustand der Verbrauch abgezogen bzw. die Produktion addiert.
• Sollte dadurch der Mindestakkustand unterschritten werden, wird der Akku geladen oder gesperrt.
• Anschließend wird gesucht, ob es zu einem früheren Zeitpunkt einen billigeren Strompreis gibt, an dem Akku geladen oder gesperrt werden könnte.
• Dann werden die Kosten für die jeweilige Methode ermittelt, und die billigere angewendet.

Da die Berechnung jede Stunde durchgeführt wird, kann sich vor allem bei geringen Preisunterschieden die Methode jede Stunde ändern.

Folgende Verfeinerungen sind noch möglich bzw. schon angebracht (bei Methode Laden):

• Was passiert, wenn der Akku voll ist? Weiterladen oder entladen (aktuell wird weiter geladen).
• Was passiert, wenn in zwei Stunden die Produktion einsetzt. (Es wird nur so viel geladen, dass die zwei Stunden überbrückt werden).
• Wenn der Preis nächste Stunde fällt, wird der Akku bis 5% entladen (ist drin).

[wiggal]

In der neuesten Version (#116) habe ich den Block fürs Laden überarbeitet.

• Erst werden alle Zeitpunkte ermittelt, die den spätesten Ladezeitpunkt ergeben.
  Hierbei wird minimum_batterylevel_Prozent auf 5% heruntergesetzt, der Akku bis 5% entladen, wenn der Preis in der nächsten Stunde fällt. Die ermittelten Werte werden als Tabelle Späteste Ladezeitpunkte ausgegeben.
• Anschließend wird versucht, die Ladezeitpunkte auf günstigere Zeitpunkte, die früher sind, zu verschieben, und der Ladepreis errechnet. Ausgabe als Tabelle Günstigste Ladezeitpunkt.

Gruß Wiggal

[Manniene]

Hallo Wiggal,

testen wird gerade wieder interessant! Laden wurde 5h zu früh gestartet...
Hier die Infos dazu:

Dynlog1.log

[Manniene]

Akku war halt leer, mit der neuesten Version hätte er zumindest noch eine Stunde gewartet. Edit: Du hast ja Minimum schon auf 5%, dann hätte auch die neue Version nicht mehr warten können

ja, habe minimum_batterylevel_Prozent auf 5%, aber im WR habe ich auf 10% gestellt. Der Akkustand war seit gestern konstant - geht halt nur langsam runter auf bis zu 8% und wird dann vom WR wieder auf 10% geladen.
=> ich wollte verhindern, dass dein Programm eine Ladung der Batterie wegen "minimum_batterylevel_Prozent" auslöst. Ich verstehe nicht in welchem Fall diese Funktionalität benötigt wird.

Nochmal zu der Ladung um 17:00. Ich verstehe das Log so, dass die Ladung angestossen wurde weil die Kosten für den Charging Block geringer waren als ohne.
Vergleichskosten Akkuladung: 6.94 €
Vergleichskosten Ladungstop: 6.99 €

Das hat mich sehr überrascht, aber ich denke hier hat der Zufall zugeschlagen -> durch die Laderate des Wechselrichters von 4000w wird ja aufgrund meines Verbrauchsforecast (4000 / ca. 1500W) alle 3-4h im Charging Block eine Batterieladung kalkuliert. Wenn ich eine ChargingRate für den WR von z.B. 7000w oder 2000w eingestellt hätte würde ich nicht darauf wetten, dass die Vergleichskosten Akkuladung wieder unter den 6.99Euro gewesen wären.

[wiggal]

Das bedeutet, wenn ich z.B. mit 4000W lade und 1000W Verbrauch laut Forecast habe, wird in der Ladungsberechnung nach 4h die nächste Batterieladung in die Vergleichskosten reinkalkuliert. => wenn ich die Ladeleistung des WR z.B. auf 2000W oder 8000W stelle, dann wird mit anderen Stundenpreisen gerechnet und somit kommen bei der Berechnung ganz andere Kosten heraus.

Richtig, wenn du 2000W Ladeleistung festlegst, muss er öfters laden, und die sehr günstigen Preise reichen nicht mehr, also wird das Laden teurer. Aber das ist ja logisch.

[wiggal]

Man rechnet ausgehend von der aktuellen Stunde und für alle direkt folgenden eine Batterieladung ein bis der Speicher voll ist und dann weiter wie gewohnt...

Aber was ist dann, wenn der Preis steigt, Akku trotzdem voll laden? Und wenn der Akku voll ist und dann kommen noch günstigere Stunden?

[wiggal]

Nochmal zu der Ladung um 17:00. Ich verstehe das Log so, dass die Ladung angestossen wurde weil die Kosten für den Charging Block geringer waren als ohne.
Vergleichskosten Akkuladung: 6.94 €
Vergleichskosten Ladungstop: 6.99 €

ja genau

Das hat mich sehr überrascht, aber ich denke hier hat der Zufall zugeschlagen -> durch die Laderate des Wechselrichters von 4000w wird ja aufgrund meines Verbrauchsforecast (4000 / ca. 1500W) alle 3-4h im Charging Block eine Batterieladung kalkuliert. Wenn ich eine ChargingRate für den WR von z.B. 7000w oder 2000w eingestellt hätte würde ich nicht darauf wetten, dass die Vergleichskosten Akkuladung wieder unter den 6.99Euro gewesen wären.

Nicht ganz.
Je niedriger die ChargingRate je höher die Kosten (siehe oben). Wenn du 7000w einstellst, ob das für Akku gut bzw. überhaupt möglich ist mal dahingestellt, gehen die Ladekosten im Normalfall nach unten, weil du weniger Ladezeitpunkte brauchst, und damit die günstigsten nutzt.

[Manniene]

Nochmal zu der Ladung um 17:00. Ich verstehe das Log so, dass die Ladung angestossen wurde weil die Kosten für den Charging Block geringer waren als ohne.
Vergleichskosten Akkuladung: 6.94 €
Vergleichskosten Ladungstop: 6.99 €

ja genau

Das hat mich sehr überrascht, aber ich denke hier hat der Zufall zugeschlagen -> durch die Laderate des Wechselrichters von 4000w wird ja aufgrund meines Verbrauchsforecast (4000 / ca. 1500W) alle 3-4h im Charging Block eine Batterieladung kalkuliert. Wenn ich eine ChargingRate für den WR von z.B. 7000w oder 2000w eingestellt hätte würde ich nicht darauf wetten, dass die Vergleichskosten Akkuladung wieder unter den 6.99Euro gewesen wären.

Nicht ganz. Je niedriger die ChargingRate je höher die Kosten (siehe oben). Wenn du 7000w einstellst, ob das für Akku gut bzw. überhaupt möglich ist mal dahingestellt, gehen die Ladekosten im Normalfall nach unten, weil du weniger Ladezeitpunkte brauchst, und damit die günstigsten nutzt.

Ja, das ist möglich. Der limitierende Faktor ist mein GEN24 8KW - der kann ja 8000w laden und entladen - um den mache ich mir eher sorgen wenn der immer am Limit läuft - auch im Sommer. Ich kann mir nicht vorstellen, dass der Speicher damit ein Problem hat. Und bei mir ist der Wert ja auch nochmal halbiert auf 4000w pro Speicher - habe 2 HVS 10,24. Man kann das sicherlich nicht vergleichen, aber so eine Autobatterie muss locker zu Spitzenzeiten das 10-12 fache an Leistung zur Verfügung stellen, wenn man mal so richtig schnell beschleunigt. Da bekommt man schnell mal für kurze Zeit auf 100kw.

[Manniene]

Noch eine andere Überlegung. Durch die Parameter "Akkuverlust" und "Gewinnerwartung" weiß man ja wie hoch der Strompreis maximal sein darf, so dass eine Ladung überhaupt Sinn macht => ist der Wert in der nächsten Stunde höher, dann muss ich überhaupt nichts berechnen. Damit wäre so ein Fall wie heute 17:00 nicht eingetroffen....

[wiggal]

Noch eine andere Überlegung. Durch die Parameter "Akkuverlust" und "Gewinnerwartung" weiß man ja wie hoch der Strompreis maximal sein darf, so dass eine Ladung überhaupt Sinn macht

Wie hoch der Strompreis maximal sein darf, sodass eine Ladung überhaupt Sinn macht, hängt ja von allen Strompreisen im Betrachtungszeitraum ab, und nur indirekt von den Parametern.

=> ist der Wert in der nächsten Stunde höher,

höher als was? Höher als die Parameter?

dann muss ich überhaupt nichts berechnen. Damit wäre so ein Fall wie heute 17:00 nicht eingetroffen....

Der Preis um 18:00 war ja niedriger, also hätte er trotzdem geladen.

Grundsätzlich könnte man schon irgendwie bestimmen, dass man nicht lädt, wenn die Preise fallen. Ich habe aber noch keine geeignete Methode gefunden, wann man dann trotzdem wieder lädt?

Einige Fragen, die ich noch aus meinen Überlegungen weiß, sind sicher nicht vollständig:

• Wie hoch soll der Unterschied sein, damit man nicht lädt?
  Nur, wenn der Preis niedriger ist?
  Was ist, wenn die Ladequote zu niedrig ist, dass der Verbrauch in den verbleibenden Stunden mit niedrigen Preisen nicht reicht, um günstig zu laden?
• Erst, wenn die Preise wieder steigen?
  Ist wohl zu spät

Das Problem bei der ganzen überlegung ist halt, dass eine Entscheidung zu einer gewissen Stunde immer abhängig von allen anderen ist.

[Manniene]

bin auf dynamicPrice2...

[Manniene]

Wenn ich mir die Preise von heute und morgen anschaue (Diagramme oben) und als Basis einen Ladeverlust von 10% veranschlage, dann komme ich auf folgende Ladestrategie.

Ladestrategie:
zu Preise heute: Preise fallen kontinuierlich => es gibt keine Stunde in der das Laden Sinn macht
zu Preise morgen: laden des Speichers macht in dem Zeitraum von 00:00 - 06:59 Sinn und für alles was von 07:00-08:00 geladen wird (falls notwendig) macht eine Entladung aus der Batterie zwischen 12:00 und 12:59 Sinn.

Preis 07:00: 0,2497 liegt + 10% Ladeverlust = 0,274 => von 12:00 bis 12:59 liegt der Preis bei 0,2805

Überlegung: Jeden Tag wenn die Preise für den Folgetag kommen berechnet man eine Ladestrategie und speichert diese ab / oder man berechnet diese immer wieder neu. Das Ergebnis dieser "Strategie" ist eine Berechnung der aufeinanderfolgenden Stunden pro Tag zu denen die Batterie geladen werden darf. Ausserhalb dieser Phasen wird der Strom aus der Batterie bezogen oder aus dem Netz. Während der Zeiten in denen ein laden der Batterie erlaubt ist, wird der Strom für den direkten Hausverbrauch immer aus dem Netz bezogen. In der Stunde bevor die erste Ladephase beginnt (1 bis n Stunden). Also heute um 22:58 läuft dann der Algorithmus um die Stunden 22:58 bis morgen 07:59 zu optimieren. Der Algorithmus sollte jedoch nur die Preise bis 07:59 einbeziehen. Spätere Preise sind nicht relevant. In den Stunden 08:00 - 11:59 sollte der Algorithmus dafür sorgen, dass der in der Batterie gespeicherte Strom kostenoptimal verbraucht wird.
Da es Morgen nur eine lohnende Ladephase gibt, in der es sich lohnt Strom zu speichern geht es Morgen ab 12:59 bis Abends ebenfalls nur darum den gespeicherten Strom kostenoptimal zu verbrauchen (in welchen Stunden gibt man die Batterie zum entladen frei)

[wiggal]

Ladestrategie:
zu Preise heute: Preise fallen kontinuierlich => es gibt keine Stunde in der das Laden Sinn macht
zu Preise morgen: laden des Speichers macht in dem Zeitraum von 00:00 - 06:59 Sinn und für alles was von 07:00-08:00 geladen wird (falls notwendig) macht eine Entladung aus der Batterie zwischen 12:00 und 12:59 Sinn.

Ich hab deine Strategie mal an 14:00, als die neuen Preise kamen, durchgerechnet, und mit der Berechnung aus dem LOG verglichen.
Der Preis deiner Strategie liegt bei 8.60€ der Preis aus dem LOG 8,63€.
Ich finde das ist gar nicht so schlecht.

[wiggal]

Überlegung: Jeden Tag wenn die Preise für den Folgetag kommen berechnet man eine Ladestrategie und speichert diese ab / oder man berechnet diese immer wieder neu. Das Ergebnis dieser "Strategie" ist eine Berechnung der aufeinanderfolgenden Stunden pro Tag zu denen die Batterie geladen werden darf. Ausserhalb dieser Phasen wird der Strom aus der Batterie bezogen oder aus dem Netz. Während der Zeiten in denen ein laden der Batterie erlaubt ist, wird der Strom für den direkten Hausverbrauch immer aus dem Netz bezogen. In der Stunde bevor die erste Ladephase beginnt (1 bis n Stunden). Also heute um 22:58 läuft dann der Algorithmus um die Stunden 22:58 bis morgen 07:59 zu optimieren. Der Algorithmus sollte jedoch nur die Preise bis 07:59 einbeziehen. Spätere Preise sind nicht relevant. In den Stunden 08:00 - 11:59 sollte der Algorithmus dafür sorgen, dass der in der Batterie gespeicherte Strom kostenoptimal verbraucht wird.

Ich kann deine Überlegung schon nachvollziehen, wenn ich die Strompreise sehe.
Aber genau um die Berechnung der Ladestrategie geht es. Du schreibst dies immer allgemein, aber an welchen Kriterien wir die Entscheidungen im Programm hängen sollen, weiß ich immer noch nicht.

[wiggal]

OK, ich glaube so kommen wir nicht weiter, lass uns das ganze nochmal Schritt für Schritt von Anfang an durchsprechen:

1. Holen der Strompreise.
   Aktuell hole ich die Preise vom aktuellen Zeitpunkt 24 Stunden in die Zukunft.

   • Brauen wir auch eine Stunde zurück, um evtl. zu sehen, ob der aktuelle Preis fällt oder steigt?
   • Reichen 24 Stunden in die Zukunft, wenn z.B. um 14:00 Uhr die Preise für morgen kommen?

2. Differenz zwischen Min und Max des Strompreises, um zu entscheiden, ob überhaupt etwas veranlasst ist?

   • Ab welchen Unterschied ist überhaupt etwas veranlasst?

...................

[Manniene]

Bin dabei!😀
Muss schauen wieviel Zeit ich heute tagsüber habe, aber heute Abend kann ich! Hier schon mal meine ersten Gedanken.

zu 1.) Lass uns gedanklich heute um 14:00 beginnen, wenn die Preise für Morgen verfügbar sind und lass uns erstmal "nur" diskutieren was wir mit den Preisen für Morgen machen - den Rest des heutigen Tages blenden wir zur Vereinfachung jetzt erstmal aus.

Bestimmung der Ladestrategie für Morgen:
a.) Preise holen
b.) Bestimmung der Stunden in denen geladen werden darf (wird nur einmal für den ganzen Tag berechnet/bestimmt)
c.) Bestimmung der Stunden die man möglichst über Strom aus der Batterie abdecken möchte (wird nur einmal für den ganzen Tag berechnet/bestimmt)

a.) ist klar
b.) => ich mache später weiter......

VG,
Manfred

[wiggal]

b.) Bestimmung der Stunden in denen geladen werden darf (wird nur einmal für den ganzen Tag berechnet/bestimmt)
c.) Bestimmung der Stunden die man möglichst über Strom aus der Batterie abdecken möchte (wird nur einmal für den ganzen Tag berechnet/bestimmt)

Mit dem nur einmal am Tag, lassen wir die Entwicklung des Akkustandes, der ja vom Lastprofil abweichen kann, aber total außer acht. Damit kann passieren, dass wir für die teuren Stunden evtl. nix mehr im Akku haben, wollen wird das?

[Manniene]

b.) Bestimmung der Stunden in denen geladen werden darf (wird nur einmal für den ganzen Tag berechnet/bestimmt)
c.) Bestimmung der Stunden die man möglichst über Strom aus der Batterie abdecken möchte (wird nur einmal für den ganzen Tag berechnet/bestimmt)

Mit dem nur einmal am Tag, lassen wir die Entwicklung des Akkustandes, der ja vom Lastprofil abweichen kann, aber total außer acht. Damit kann passieren, dass wir für die teuren Stunden evtl. nix mehr im Akku haben, wollen wird das?

Mit dem einmal am Tag meine ich nicht, dass es keine stündlichen Berechnungen mehr geben soll. Einmal am Tag soll die "Strategie" bestimmt werden und die stündlichen Berechnungen können dann auf diesen Informationen aufbauen.
Aber Ja, dass ist das eigentliche Problem das wir optimieren wollen. Mit deiner PV Prognose und dem Vebrauchsprofil ist schon alles da, was man machen kann. Wie gut das dann wird sehen wir. Lass uns den Elefanten in kleine Stücke schneiden😀

Vorschlag: Wollen wir vielleicht für die oben angefangene Schritt für Schritt Vorgehensweise eine zentrale Stelle erstellen? Dort würden wir dann nur die abgestimmten Schritte dokumentieren und die Diskussionen halten wir hier in den Comments. Wäre viel übersichtlicher und wir könnten unsere Diskussionspunkte immer in den gerade relevanten Kontext/zu dem zu diskutierenden Schritt stellen. Wäre das WIKI hierfür das richtige? Habe das noch nie benutzt, aber ich kann einfach mal versuchen loszulegen, wenn das Ok für dich ist.

[wiggal]

Ich glaube die abgestimmten Schritte sind am besten im "pull request" aufgehoben, sind ja für die Entwicklung dort.

[wiggal]

OK, zurück zu den kleinen Stücken:

1. Strompreis holen soweit klar, wie viele Stunden können wir immer noch schnell ändern.
2. Die "Strategie" bestimmen, was meinst du damit, bzw. wie willst du die bestimmen?
   Nun mal konkret, wir haben für jede Stunde folgende Daten: Stompreis, Verbrauch, PV-Produktion
   Wie sollen wir festlegen, wann was erfolgen soll? Laden, Laden gesperrt oder Verbrauch aus dem Akku

[Manniene]

Hier Beispiel 1:
Anhand der Skizze können wir das diskutieren (Beipiel2 folgt noch...)
Vorgehensweise -> ab 14:00 am Tag zuvor:

• Berechnung der Ladephase -> von 00:00 - 05:59:59
• Berechnung für welche Stunden ein Bezug aus dem Speicher Sinn macht -> von 07:00 - 20:59:59
• Bestimmung der Stunden, in denen die Entladung aus dem Speicher gestoppt ist -> auf jeden Fall 06:00 - 06:59:59 und 21:00 - 23:59:59
  -> Ergebnis abspeichern oder immer wieder berechnen

Wenn dann der neue Tag beginnt, läuft der Algorithmus und optimiert das Verhalten, der jeweiligen zeitlichen Phase in der "er" sich befindet => von 00:00 - 05:59:59 nur die Ladephase

[Manniene]

Hier Beispiel 2: (sorry für meine Sauklaue - habe das Schreiben mit der Hand verlernt😀)

Vorgehensweise -> ab 14:00 am Tag zuvor:

Berechnung wieviele Minimum/Maximum am Tag => 2

• Berechnung der Ladephase 1 -> von 02:00 - 04:59:59
• Berechnung der Ladephase 2 -> von 14:00 - 16:59:59
• Berechnung für welche Stunden ein Bezug aus dem Speicher Sinn macht -> von 07:00 - 09:59:59 Ladephase 1 und 14:00 - 16:59:59
• Bestimmung der Stunden, in denen die Entladung aus dem Speicher gestoppt ist -> 00:00 - 01:59:59 und 05:00 - 06:59:00 und 10:00 - 13:59:59 und 17:00 - 17:59:59 und 20:00 - 23:59:59
-> Ergebnis abspeichern oder immer wieder berechnen
  Wenn dann der neue Tag beginnt, läuft der Algorithmus und optimiert das Verhalten, der jeweiligen zeitlichen Phase in der "er" sich befindet

[Manniene]

Was machen wir, wenn der Akku schon leer wird, bevor der günstigste Preis zum Laden auftritt?

ich bin mir nicht sicher wo du dich im Ablauf gedanklich befindest

Lass uns doch einige Begrifflichkeiten einführen. Ich habe dein Spreadsheet etwas angepasst und wieder angehängt.

• Ganz links habe ich eine Spalte hinzugefügt -> soll die Programmläufe darstellen
  Programmläufe = gehen bei - 1 los => Lauf -1 (23:58), Lauf 0 (00:58), Lauf 1 (01:58) usw.
  (Ich gehe davon aus, dass du das neue Programm auch jede Stunde laufen lassen lässt )

• Die Strompreise in der Tabelle habe ich farblich markiert.
  grüne Phase = potenzielle Stunden in denen die Batterie geladen wird + parallel wird Hausbedarf über Netzbezug abgedeckt
  graue Phase = immer Netzbezug
  gelbe Phase = Verbrauch wenn möglich aus Batterie

• Idealer Tagesverlauf = PV Forecast + Forecast Verbrauch treffen mit einer Genauigkeit von 100% ein

Passt das so für dich?
Entwicklungneu_Schritt3-3.ods
—————————————————————————————————
Wir sind im Programmlauf -1 (23:58 des Vortages):

• Wir gehen von einem idealen Tagesverlauf aus
• Berechnung “Bedarf Entladung”(das sind die 4689,95wh aus deiner Tabelle)
• Bestimmung in welchen grünen Stunden der Bedarf in die Batterie geladen werden soll
• graue Stunden: Netzbezug
• Überprüfung ob der “Bedarf Entladung” in den Speicher passt
  • Fall 1: ja => alles gut - Batteriesteuerung auf “0” für alle gelben Stunden
  • Fall 2: Nein => die teuersten gelben Stunden bekommen die Batteriesteuerung 0, die verbleibenden bekommen eine -1 (Netzbezug)

————————————————————————————————
Jetzt zu deinen Fragen. Bist du da gedanklich im Lauf -1 oder später?

1. Was machen wir, wenn der Akku schon leer wird, bevor der günstigste Preis zum Laden auftritt?
2. Aus dem Netz verbrauchen?
3. Mit dem bis dahin günstigsten Preis laden?

Hab die Tabelle nochmal überarbeitet, hier wird nun der Zeitpunkt angezeigt, bei dem die Ladung erforderlich wäre, da der Akku am Minimum ist.
4. Hab die Reduzierung der Ladeleistung jetzt bei der letzten Ladung angebracht, da die mit dem höheren Preis passiert, richtig?
5. Wenn ja, sollten wir die Variable dann auch noch umbenennen?

[wiggal]

(Ich gehe davon aus, dass du das neue Programm auch jede Stunde laufen lassen lässt )

Ja hab ich eigentlich vor

Jetzt zu deinen Fragen. Bist du da gedanklich im Lauf -1 oder später?

Müsste eigentlich egal sein:
Nehmen wir mal an, dass wir im Lauf 15 sind, der Verbrauch war höher als nach Lastprofil berechnet, und der Akku ist leer.
Jetzt kommen aber die teuersten Stunden, Laden ist evtl. erst wieder um 02:00 am nächsten Tag berechnet, was machen wird dann?

• Ich könnten den Stand, den wir bis jetzt gebrainstormt haben, programmieren, und dann testen wir, oder uns fällt jetzt schon was Kluges für solche Situationen ein.

[Manniene]

(Ich gehe davon aus, dass du das neue Programm auch jede Stunde laufen lassen lässt )

Ja hab ich eigentlich vor

Jetzt zu deinen Fragen. Bist du da gedanklich im Lauf -1 oder später?

Müsste eigentlich egal sein:

sehe ich nicht ganz so - ich würde erstmal die notwendige Programmlogik für die 3 Phasen (grau, grün und gelb) separat "halten" / "denken"

wir sind im Lauf 15 , der Verbrauch war höher als nach Lastprofil berechnet, und der Akku ist leer. Jetzt kommen aber die teuersten Stunden, Laden ist evtl. erst wieder um 02:00 am nächsten Tag berechnet, was machen wird dann?

Im Lauf 15 => gelbe Phase => Akku leer => "Pech gehabt" => Bezug aus dem Netz. Programm ist in der gelben Phase => keine Berechnung von neuen Ladezeiten -> das ist nur in grau und grün notwendig
ABER: in den Läufen 7 bis 20 könnte man jede Stunde prüfen, wie weit weg man sich vom zuvor berechneten Ideallauf befindet. => man überprüft ob die geladene Strommenge für die restlichen Stunden ausreicht -> wenn nicht -> Fall 2 (siehe oben) => Die teuersten gelben Stunden bekommen die Batteriesteuerung 0, die verbleibenden bekommen eine -1 (Netzbezug) => der verbleibende Akkustand wir neu über die gelben Stunden verteilt.

• Ich könnten den Stand, den wir bis jetzt gebrainstormt haben, programmieren, und dann testen wir, oder uns fällt jetzt schon was Kluges für solche Situationen ein.

wie du möchtest - wir können aber auch gerne weitere Ausnahmen diskutieren

EDIT WIGGAL:
Ich hab die Reihenfolge der Diskussion mal etwas bereinigt, ich tue mich sonst so schwer zu sehen, wer in welche Ebene was gesagt hat.

deine Aussagen

meine Antworten

deine neuen Antworten

>>  deine Aussagen

>  meine Antworten

deine neuen Antworten

[Manniene]

ja, geht mir genauso. Danke! versuche mich daran zu halten - falls nicht => ich habe kein Problem damit, wenn du meine Beiträge veränderst...

[wiggal]

Im Lauf 15 => gelbe Phase => Akku leer => "Pech gehabt" => Bezug aus dem Netz. Programm ist in der gelben Phase => keine Berechnung von neuen Ladezeiten -> das ist nur in grau und grün notwendig

OK, dann halt ich das mal fest #116

[wiggal]

Übrigens gibt es im photovoltaikforum eine Diskussion zu einem ähnlichen Projekt, könnte man sich da auch was abschauen?
https://www.photovoltaikforum.com/thread/216690-batcontrol-gen24-batterie-tibber-geld-sparen/?postID=4083096#post4083096

[Manniene]

Also das was ich gelesen habe, inklusive dem PPT passt aus meiner Sicht nicht / ist noch nicht so weit. Ich war auch schon öfter im PV Forum unterwegs, habe aber nie etwas gefunden was auch nur ansatzweise so weit vorangeschritten, detailliert und umfangreich ist wie dein Programmpaket. Ich habe nur von einem meiner Arbeitskollegen erzählt bekommen, dass er eine Drittanbieter iPhone App für E3/DC Systeme verwendet die gut sein soll und das dort auch an einer Dynprice Funktionalität gearbeitet wird. Der Drittanbieter hat jedoch lokal nichts am laufen und nutzt das E3/DC Portal um an die Daten zu kommen. Wer anscheinend auch an einer Lösung arbeitet ist die Firma Growatt.
Ich schaue mich weiter um…

[wiggal]

Bisher haben wird nur den Preis betrachtet, aber den Akkustand nicht mit einbezogen, dies kommt nun noch dazu.

Wann ist der Speicher voll bzw. wann ist er leer.

Folgendes Beispiel:

Beim Programmlauf 7 wird festgestellt, dass am Punkt 10 der Speicher leer wird.
Nach der Tagesberechnung wird also hier nicht geladen, obwohl die Preise noch stark steigen würde.
Wenn wir aber nur das Zeitfenster ab Punkt 7 vom höchsten Preis her denken, würde es sich doch lohnen an Punkt 7 zu laden.

Dies bestärkt mich eigentlich darin, jede Stunde immer nur die aktuelle Situation und die folgenden bekannten Stunden zu betrachten. Wenn ich einen Tag um 0:00 Uhr betrachte, habe ich ja auch nicht mehr die Preise vom Vortag z.B. 22:00 bis 24:00 im Blick, und mögen sie noch so günstig oder teuer gewesen sein. Ist dann sozusagen Schnee von gestern.

[Manniene]

Bisher haben wird nur den Preis betrachtet, aber den Akkustand nicht mit einbezogen, dies kommt nun noch dazu.

Wann ist der Speicher voll bzw. wann ist er leer.

Folgendes Beispiel:

Beim Programmlauf 7 wird festgestellt, dass am Punkt 10 der Speicher leer wird. Nach der Tagesberechnung wird also hier nicht geladen, obwohl die Preise noch stark steigen würde. Wenn wir aber nur das Zeitfenster ab Punkt 7 vom höchsten Preis her denken, würde es sich doch lohnen an Punkt 7 zu laden.

Ich sehe deinen Punkt, nur wird man im Lauf 7 nicht in diese Situation kommen. - graue Phase wurde gerade mit einem Akkufüllstand von 100% abgeschlossen. => ich kann noch gar nicht wissen, dass der Akkustrom nicht ausreicht (ausser Akku nicht groß genug).
Nochmal von der Denke von vorne: Lauf 6 geht los - Akku ist voll -> jetzt geht es darum die gelben Stunden zu optimieren -> schau mal mein Beispiel 2 weiter oben (MAXIMUM Bestimmung) => Ziel Nr. 1 in einer gelben Phase ist es, die Stunden mit den höchsten Preisen mit Akkustrom zu versorgen.
=> lass uns die Logik für die Phase GELB noch weiter diskutieren und an konkreten Strompreistageskurven diskutieren. Die von dir genutzte Strompreiskurve folgt einem nicht oft vorkommenden Muster

Dies bestärkt mich eigentlich darin, jede Stunde immer nur die aktuelle Situation und die folgenden bekannten Stunden zu betrachten. Wenn ich einen Tag um 0:00 Uhr betrachte, habe ich ja auch nicht mehr die Preise vom Vortag z.B. 22:00 bis 24:00 im Blick, und mögen sie noch so günstig oder teuer gewesen sein. Ist dann sozusagen Schnee von gestern.

sehe ich nachwievor nicht ganz so => lass uns Beispiele durchgehen

[wiggal]

Bist du auf www.photovoltaikforum.com angemeldet, dort gibt es Konversation, die sehnen nur die zwei Beteiligten?

[wiggal]

OK, hab die Adresse

[wiggal]

Noch ein Beispiel, in dem ich glaube, dass es nicht reicht, nur beim günstigsten Preis zu laden, ohne auf den Akkustand zu achten:

Wenn in deinem Beispiel der zweite Block einige Hundertstel billiger ist als der erste, und am Tag zuvor ein Eingriff in die Ladestrategie nicht nötig war, wird der Akku ziemlich leer sein, und die erste Ladung erfolgt wahrscheinlich um 14:00 erfolgen, und davor der Strom aus dem Netz gezogen.
Wenns blöd läuft, ist dann auch noch viel PV Überschuss vorhanden.

[Manniene]

Noch ein Beispiel, in dem ich glaube, dass es nicht reicht, nur beim günstigsten Preis zu laden, ohne auf den Akkustand zu achten:

das sehe ich genauso

Wenn in deinem Beispiel der zweite Block einige Hundertstel billiger ist als der erste, und am Tag zuvor ein Eingriff in die Ladestrategie nicht nötig war, wird der Akku ziemlich leer sein, und die erste Ladung erfolgt wahrscheinlich um 14:00 erfolgen, und davor der Strom aus dem Netz gezogen. Wenns blöd läuft, ist dann auch noch viel PV Überschuss vorhanden.

habe die Preise aus dem Beispiel in dein Spreadsheet im TAB Beispiel 2 eingetragen und die Phasen farbig Markiert (sonst nichts) -> können wir zur Diskussion verwenden - bin jetzt erstmal 2-3h offline
Entwicklungneu_Schritt3-3.ods

[Manniene]

Hallo Wiggal,
schau dir mal bitte das angehängte Spreadsheet an. Die Idee ist, dass man pro Tab die Preise konstant lässt und nebeneinander verschiedene Fälle mit unterschiedlichen Verbräuchen darstellt. Habe im Tab 1 jetzt 2 Fälle. Ich werde als nächstes Tab 2 und Tab 3 jeweils mit einem Preisverlauf aus der Vergangenheit versehen und dann pro Tab zwei Verbrauchsfälle darstellen. Ich denke dann haben wir erstmal genügend Fälle um die ganzen Ausnahmen durchzugehen.
Use_Cases_01.ods

[wiggal]

hab die Adresse, ansonsten bin ich heute weg

[Manniene]

Spreadsheet hat nun 3 Use Cases. Graue, Grüne und Gelbe Phasen sind eingearbeitet.
Use_Cases_01.ods

[wiggal]

Hi, hab jetzt mal einen Prototyp gebaut, der Akkuladen und Ladestopps je nach Bedarf mischt und so die günstigste Methode anwenden soll.
Vielleicht können wir auf diese Grundlage mal testen.

[wiggal]

Der Entladestop beim Laden des E-Autos wurde nicht geschrieben, da nichts aus der Batterie entladen wurde.
Der Entladestop wird nur geschrieben, wenn auch aus der Batterie größere Mengen entnommen werden, also auch nicht, wenn der Akku leer ist, oder wie deinem Fall durch die Zwangsladung nichts aus dem Akku entnommen wird.

[Manniene]

Kannst du bitte deine CONFIG/charge_priv.ini posten

charge_priv.txt

hatte eben einen manuellen Entladestopp gesetzt der vom nächsten Symolauf wieder gelöscht wurde (E-AUTO WIRD NICHT MEHR GELADEN)

***** BEGINN: 2025-01-03 20:01:02 *****
## HTTP-LADESTEUERUNG ##
>>Parameteränderung durch WebUI-Settings: Ladesteuerung:['logging', 'entladen']
aktuellePrognose: 0
TagesPrognose - BattVollUm: 0 - 12
Grundlast_Summe für Tag: 0
aktuellePVProduktion/Watt: 0
aktuelleEinspeisung/Watt: -146
aktuelleBatteriePower/Watt: 23
GesamtverbrauchHaus/Watt: 1490
aktuelleBattKapazität/Watt: 3276
Batteriestatus in Prozent: 84.0 %
LadewertGrund: Auf MaxLadung stellen, da PVProduktion < 10 Watt!
Bisheriger Ladewert/Watt: 0
Neuer Ladewert/Watt: 7840

## ENTLADESTEUERUNG ##

Feste Entladegrenze in % : 100 %
VerbrauchsgrenzeEntladung: 0 W
Feste Entladegrenze Table: 0 W Entladeeintrag Löschen!

Ladesteuerung NICHT geschrieben, da Option "laden" NICHT gesetzt!
Entladeeintrag wurde gelöscht.

In SQLite-Datei gespeichert!
***** ENDE: 2025-01-03 20:01:02 *****

[wiggal]

Ist klar, da du die Option entladen gesetzt hast

[Manniene]

Ist klar, da du die Option entladen gesetzt hast

Mit Option 'entladen' gesetzt meinst du die Aktivierung über den GUI von "Ent- und Endladesteuerung"?

[wiggal]

ja, die Option gibt das Schreiben der Entladesteuerung auf dem WR frei

[Manniene]

Anmerkung nach dem Update & prinzipiell zur Überlegung:
Mein Akku ist im Moment ja relativ voll und die neue Version sieht vor, dass ich ab 23:00 wieder aus dem Netz lade. In den Stunden 20:00, 21:00 und 22:00 müsste die Batterieentladung eigentlich gestoppt werden, da die Batterie mit Preisen geladen wurde, die bei 15% Akkuverlsut + 0,01, erst ein Entladen bei > 0,34xx erlauben sollte.

*** BEGINN DynamicPriceCheck:  2025-01-03 19:32:15 ***
Es sind Ladezeiten UND Entladepausen n  tig!!

>>>>>>>> Batteriestand und Ladezeitpunkte
Ladezeitpunkt       | PV_Prognose (W) | Verbrauch (W) | Strompreis ( ^b /kWh) | Batteriestand (W) | Ladewert
---------------------------------------------------------------------------------------------------------
2025-01-03 20:00:00 | 0               | 2013          | 0.3296             | 16010             | 0
2025-01-03 21:00:00 | 0               | 2399          | 0.3231             | 13611             | 0
2025-01-03 22:00:00 | 0               | 2382          | 0.3117             | 11229             | 0
2025-01-03 23:00:00 | 0               | 2099          | 0.3002             | 12729             | -1500
2025-01-04 00:00:00 | 0               | 2181          | 0.3024             | 14229             | -1500
2025-01-04 01:00:00 | 0               | 2297          | 0.3022             | 15729             | -1500
2025-01-04 02:00:00 | 0               | 2315          | 0.3021             | 17229             | -1500
2025-01-04 03:00:00 | 0               | 2299          | 0.3037             | 18729             | -1500
2025-01-04 04:00:00 | 0               | 2282          | 0.309              | 16447             | 0

[wiggal]

OK, der Bug in der verwendetet Version ermöglicht hier keine Beurteilung.

[Manniene]

Ok, hier die bisherige Auswertung für die gestern aktualisierte Version. Habe auf 1500w Ladeleistung reduziert.

Crontab-2.log
LOG_DynamicPriceCheck-2.log

ist mir bei schneller Durchsicht aufgefallen. Heute um 08:00 und 11:00 soll aus dem Netz geladen werden ....
(kannst gerne alles was du aus meinem Post nicht benötigst löschen)

min_price:     0.3021
profit_price:  0.3574
max_price:     0.3748

Es sind Ladezeiten UND Entladepausen nötig!!

Batteriestand und Ladezeitpunkte
Ladezeitpunkt       | PV_Prognose (W) | Verbrauch (W) | Strompreis (€/kWh) | Batteriestand (W) | Ladewert
---------------------------------------------------------------------------------------------------------
2025-01-04 08:00:00 | 0               | 2215          | 0.3476             | 20480             | -1500   
2025-01-04 09:00:00 | 245             | 2199          | 0.3504             | 18526             | 0       
2025-01-04 10:00:00 | 459             | 2182          | 0.3499             | 16803             | 0       
2025-01-04 11:00:00 | 575             | 2165          | 0.3475             | 18303             | -1500   

[wiggal]

Die Ladepunkte waren nötig, damit der Akku um 18:00 nicht leer läuft (vermutlich).
Dein Ladewert von 1500 Watt ist halt sehr niedrig, wenn man bedenkt, dass du immer mehr als 2000 Watt verbrauchst.

[wiggal]

Erklärung zur aktuellen Version:

• Ermittlung der benötigten Ladevorgänge ohne Eingriffe
  -->> Wenn keine Ladevorgänge ermittelt werden, erfolgen keine Eingriffe
• Ermittlung des kleinsten Preises für den gesamten aktuellen Tag,
  Berechnung des profitablen Preises fürs Laden
  Ermittlung des maximalen Preises für den Berechnungszeitraum (aktuell: nächste Stunde + 18 Stunden)
  -->> Wenn maximaler Preis kleiner profitabler Preis, dann nur Entladestopps, keine Zwangsladungen
• Ansonsten Zwangsladungen und Entladestopps:
  Durchläufe über alle Stunden des Berechnungszeitraums
  • Suchen des größten noch nicht behandelten Preises
    -->> Wenn Akkustand für Verbrauch reicht, Entladung (0) setzen.
    -->> Wenn Akkustand für Verbrauch NICHT reicht, für einen Zeitpunkt zuvor einen Preis kleiner profitabler Preis suchen, Zwangsladung eintragen und Entladung (0) setzen.
    -->> Wenn kein profitabler Preis für eine Zwangsladung gefunden wird, Entladestopp (-1) eintragen.

Habe gerade den DEBUG-LEVEL2 erweitert.
Bei Eintrag dyn_print_level = 3 wird für jeden Durchlauf die aktuelle Tabelle ausgegeben (ACHTUNG viele Ausgaben, ab besten nur vereinzelt zu Analyse einsetzen)

[Manniene]

Hier die Logs von gestern bis heute Morgen. Sieht schon ganz gut aus. Aus meiner Sicht hätte jedoch ab 2025-01-04 05:00 die Batterie nicht mehr geladen werden dürfen -> Steuercodes wurden geschrieben - Batterie war jedoch schon bei 100%.
Um 10:00 und 11:00 wäre es "beinahe" zu einer Ladung der Batterie gekommen (hätte aus meiner Sicht aufgrund des Preises nie passieren dürfen)

Und dann schau dir mal das Dynlog für 2025-01-05 02:58:01 an -> von diesem Zeitpunkt an gab es ja nur noch fallende Preise -> es wurden Entladestops und Ladungen bestimmt -> Eis kam dann aber final nie zu einer Ladung der Batterie (was ja in Ordnung ist)

LOG_DynamicPriceCheck.log
Crontab.log

[wiggal]

OK, interessante Vorgehensweise! Hätte jetzt schon Feedback zu dem Durchlauf den du erklärt hast - aber ich muss das erstmal sacken lassen - bin mir nicht sicher, ob ich das schon komplett Durchblicke, da ja die komplette Programmlogik jede Stunde von vorne durchlaufen wird...

Wollte dir gerade vorschlagen, dass du nochmal einen Check einführen könntest bevor du die Steuercodes schreibst. Und zwar: wenn für die nächste kommende Stunde eine "0" bestimmt wurde , dass du nochmal prüfst ob nicht eine -1 besser wäre (so dass es nicht dazu kommt das aus der Batterie Strom bezogen wird, falls sich das gar nicht rechnet) ==>> geht aber nicht, weil das Programm zu diesem Zeitpunkt nichts mehr darüber weiß wie viel der Strom gekostet hat mit dem die Batterie eventuell schon zu einer früheren Stunde geladen wurde.

Was bringt uns das Wissen, was der Strom im Akku gekostet hat, also die Vergangenheit?
Wir haben den aktuellen Akkustand, und zukünftige Daten wie Strompreis, Verbrauch und Produktion und müssen den Strom zukünftig möglichst kostengünstig verteilen.
Dies sollte jede Stunde neu erfolgen. Eine hundertprozentige Lösung wird es aus meiner Sicht aufgrund der vielen Unwägbarkeiten, wie Verbrauch und Produktion eh nicht geben.

Ich liege doch richtig in der Annahme, dass du das Programm so gestalten willst, dass in jeder Stunde die gleiche Logik durchlaufen wird ohne etwas über die "Vergangenheit" zu "wissen" bzw. zusätzliche Infos mitzugeben?

Auf alle Fälle ist eh schon kompliziert genug.

Hier mal ein Gedanke. Vielleicht könnte man sich ja überlegen, ob es vielleicht hilfreich wäre neben der "Füllmenge" des Speichers auch den Wert fortzuschreiben.

Wie oben....

Ich glaube, dass die Berechnung schon recht gut ist, einzig den Ladeverlust (evtl. 10%) könnte man noch berücksichtigen.

[Manniene]

OK, interessante Vorgehensweise! Hätte jetzt schon Feedback zu dem Durchlauf den du erklärt hast - aber ich muss das erstmal sacken lassen - bin mir nicht sicher, ob ich das schon komplett Durchblicke, da ja die komplette Programmlogik jede Stunde von vorne durchlaufen wird...
Wollte dir gerade vorschlagen, dass du nochmal einen Check einführen könntest bevor du die Steuercodes schreibst. Und zwar: wenn für die nächste kommende Stunde eine "0" bestimmt wurde , dass du nochmal prüfst ob nicht eine -1 besser wäre (so dass es nicht dazu kommt das aus der Batterie Strom bezogen wird, falls sich das gar nicht rechnet) ==>> geht aber nicht, weil das Programm zu diesem Zeitpunkt nichts mehr darüber weiß wie viel der Strom gekostet hat mit dem die Batterie eventuell schon zu einer früheren Stunde geladen wurde.

Was bringt uns das Wissen, was der Strom im Akku gekostet hat, also die Vergangenheit? Wir haben den aktuellen Akkustand, und zukünftige Daten wie Strompreis, Verbrauch und Produktion und müssen den Strom zukünftig möglichst kostengünstig verteilen. Dies sollte jede Stunde neu erfolgen. Eine hundertprozentige Lösung wird es aus meiner Sicht aufgrund der vielen Unwägbarkeiten, wie Verbrauch und Produktion eh nicht geben.

du könntest z.B. nach jedem Programmlauf, für die direkt darauffolgende Stunde bestimmen, ob ein Bezug aus dem Speicher sinnvoll ist.. Aber lass mal, wie gesagt jetzt wo ich die neue Programmlogik verstanden habe, beobachte ich mit diesem Wissen weiter. Vielleicht fällt mir noch etwas ein wie man das jetzige Verhalten noch verbessern könnte.
Was mir in der jetzigen Ablauflogik auch noch aufgefallen ist. Du arbeitest ja immer 2 Wertepaare ab (einen von "oben" (High Price) und den anderen von "unten" (Low Price) und hakst pro Loop 2 Werte ab. Was hierbei unberücksichtigt bleibt, ist die Tatsache, dass 1 Low Price, je nach Strombedarf pro Stunde und verfügbarer Batteriekapazität, eventuell mehrere High Price Stunden abgedecken kann. Aber wie gesagt ich muss die neue Logik noch sacken lassen.

Ich liege doch richtig in der Annahme, dass du das Programm so gestalten willst, dass in jeder Stunde die gleiche Logik durchlaufen wird ohne etwas über die "Vergangenheit" zu "wissen" bzw. zusätzliche Infos mitzugeben?

Auf alle Fälle ist eh schon kompliziert genug.

Hier mal ein Gedanke. Vielleicht könnte man sich ja überlegen, ob es vielleicht hilfreich wäre neben der "Füllmenge" des Speichers auch den Wert fortzuschreiben.

Wie oben....

Ich glaube, dass die Berechnung schon recht gut ist, einzig den Ladeverlust (evtl. 10%) könnte man noch berücksichtigen.

ja, sehe ich auch so! Nur was meinst du mit dem Ladeverlust, der ist doch schon berücksichtigt bzw. kann sogar jeder selbst einstellen? Jetzt mit dem Verständnis der neuen Programmlogik schau ich mir die Logs weiter im Detail an. Vielleicht fällt mir noch etwas ein....

[wiggal]

Was bringt uns das Wissen, was der Strom im Akku gekostet hat, also die Vergangenheit? Wir haben den aktuellen Akkustand, und zukünftige Daten wie Strompreis, Verbrauch und Produktion und müssen den Strom zukünftig möglichst kostengünstig verteilen. Dies sollte jede Stunde neu erfolgen. Eine hundertprozentige Lösung wird es aus meiner Sicht aufgrund der vielen Unwägbarkeiten, wie Verbrauch und Produktion eh nicht geben.

du könntest z.B. nach jedem Programmlauf, für die direkt darauffolgende Stunde bestimmen, ob ein Bezug aus dem Speicher sinnvoll ist.. Aber lass mal, wie gesagt jetzt wo ich die neue Programmlogik verstanden habe, beobachte ich mit diesem Wissen weiter. Vielleicht fällt mir noch etwas ein wie man das jetzige Verhalten noch verbessern könnte.

Ja, ich glaube auch wir sollten, mit dem momentanen Stand, mal länger Erfahrung sammeln.

Was mir in der jetzigen Ablauflogik auch noch aufgefallen ist. Du arbeitest ja immer 2 Wertepaare ab (einen von "oben" (High Price) und den anderen von "unten" (Low Price) und hakst pro Loop 2 Werte ab. Was hierbei unberücksichtigt bleibt, ist die Tatsache, dass 1 Low Price, je nach Strombedarf pro Stunde und verfügbarer Batteriekapazität, eventuell mehrere High Price Stunden abgedecken kann. Aber wie gesagt ich muss die neue Logik noch sacken lassen.

Ja ist klar, ich glaube, das wird dann damit abgedeckt, dass beim nächsten HighPrice der Akkustand für den Verbrauch reicht, und damit kein Ladepunkt gesucht wird.

Ich glaube, dass die Berechnung schon recht gut ist, einzig den Ladeverlust (evtl. 10%) könnte man noch berücksichtigen.

ja, sehe ich auch so! Nur was meinst du mit dem Ladeverlust, der ist doch schon berücksichtigt bzw. kann sogar jeder selbst einstellen? Jetzt mit dem Verständnis der neuen Programmlogik schau ich mir die Logs weiter im Detail an. Vielleicht fällt mir noch etwas ein....

Der Ladeverlust ist nur bei der Berechnung des rentablen Preises drin, aber nicht bei der Berechnung des Akkufüllstandes.
Wenn wir mit 5000 Watt laden, dürften wir dann nur 4500 Watt beim Akkufüllstand addieren, und nicht 5000.
Ober halt weniger.

Hierzu wären noch LOG_DynamicPriceCheck.log gut, bei denen einiges in den Akku geladen wurde, bisher hätte ich aus deine Logfiles durchschnittlich etwas über 5% berechnet, ist ja nur der Verlust, der beim Laden nicht ankommt. Da ich ja einen festen Strompreis habe, läuft bei mir DynamicPriceCheck.py nur trocken, ohne wirkliche Ladung.

[Manniene]

Was bringt uns das Wissen, was der Strom im Akku gekostet hat, also die Vergangenheit? Wir haben den aktuellen Akkustand, und zukünftige Daten wie Strompreis, Verbrauch und Produktion und müssen den Strom zukünftig möglichst kostengünstig verteilen. Dies sollte jede Stunde neu erfolgen. Eine hundertprozentige Lösung wird es aus meiner Sicht aufgrund der vielen Unwägbarkeiten, wie Verbrauch und Produktion eh nicht geben.

du könntest z.B. nach jedem Programmlauf, für die direkt darauffolgende Stunde bestimmen, ob ein Bezug aus dem Speicher sinnvoll ist.. Aber lass mal, wie gesagt jetzt wo ich die neue Programmlogik verstanden habe, beobachte ich mit diesem Wissen weiter. Vielleicht fällt mir noch etwas ein wie man das jetzige Verhalten noch verbessern könnte.

Ja, ich glaube auch wir sollten, mit dem momentanen Stand, mal länger Erfahrung sammeln.

Was mir in der jetzigen Ablauflogik auch noch aufgefallen ist. Du arbeitest ja immer 2 Wertepaare ab (einen von "oben" (High Price) und den anderen von "unten" (Low Price) und hakst pro Loop 2 Werte ab. Was hierbei unberücksichtigt bleibt, ist die Tatsache, dass 1 Low Price, je nach Strombedarf pro Stunde und verfügbarer Batteriekapazität, eventuell mehrere High Price Stunden abgedecken kann. Aber wie gesagt ich muss die neue Logik noch sacken lassen.

Ja ist klar, ich glaube, das wird dann damit abgedeckt, dass beim nächsten HighPrice der Akkustand für den Verbrauch reicht, und damit kein Ladepunkt gesucht wird.

Ich glaube, dass die Berechnung schon recht gut ist, einzig den Ladeverlust (evtl. 10%) könnte man noch berücksichtigen.

ja, sehe ich auch so! Nur was meinst du mit dem Ladeverlust, der ist doch schon berücksichtigt bzw. kann sogar jeder selbst einstellen? Jetzt mit dem Verständnis der neuen Programmlogik schau ich mir die Logs weiter im Detail an. Vielleicht fällt mir noch etwas ein....

Der Ladeverlust ist nur bei der Berechnung des rentablen Preises drin, aber nicht bei der Berechnung des Akkufüllstandes. Wenn wir mit 5000 Watt laden, dürften wir dann nur 4500 Watt beim Akkufüllstand addieren, und nicht 5000. Ober halt weniger.

Hierzu wären noch LOG_DynamicPriceCheck.log gut, bei denen einiges in den Akku geladen wurde, bisher hätte ich aus deine Logfiles durchschnittlich etwas über 5% berechnet, ist ja nur der Verlust, der beim Laden nicht ankommt. Da ich ja einen festen Strompreis habe, läuft bei mir DynamicPriceCheck.py nur trocken, ohne wirkliche Ladung.

habe dir etwas zugeschickt

[wiggal]

Ok, hab mir die Logfiles angesehen, hier zeigt sich wieder, dass der Akku-SOC ziemlich ungenau ist.
Je nachdem wann das letzte Balancing durchgeführt wurde usw., bin auch nicht so ein Akkuspezialist.
Ich würde mal versuchen, mit einem Ladeverlust von Akku_Verlust_Prozent / 2 zu arbeiten, da der Verlust beim Laden des Akkus evtl. die Hälfte des Gesamtverlustes ist.

[wiggal]

Hallo Manfred,
habe das Skript nochmal überarbeitet.

minimum_batterylevel_Prozent aus CONFIG/dynprice.ini entfernt. Der Minimalwert wird nun vom GEN24 gelesen, da er sich je nach Einstellung verändern kann (Minimales Ladelimit oder Notstrom Reservekapazität).

Es wird jetzt für jeden gefundenen Minimalpreis, der eine Ladung ermöglicht, geprüft, ob er sich nach Berechnung des rentablen Preises als Ladung bzw. als Entladestopp eignet.

Ich hoffe, dass damit das Problem, dass der rentable Preis ja immer nur für den niedrigsten Preis gegolten hätte, erledigt hat.

Ich lasse, das Skript jetzt mal eine Woche laufen, und schaue, ob noch Probleme auftreten.

Gruß
Wiggal

[Manniene]

Hallo Manfred, habe das Skript nochmal überarbeitet.

minimum_batterylevel_Prozent aus CONFIG/dynprice.ini entfernt. Der Minimalwert wird nun vom GEN24 gelesen, da er sich je nach Einstellung verändern kann (Minimales Ladelimit oder Notstrom Reservekapazität).

habe da nochmal eine Frage: ich habe ja für Notstrom nichts konfiguriert und habe das bis jetzt auch nicht vor. Bei mir ist im WR eine Reservekapazität von 10% eingestellt und ein Minimales Ladelimit von 5%. => Batterie wird bis 10% entladen und die nachfolgenden Ladeverluste managed der WR mit Zwangsladungen. Soweit so gut! Frage: Wann führt dein Programm Zwangsladungen der Batterie durch und kann ich das durch Konfiguration verhindern?

Es wird jetzt für jeden gefundenen Minimalpreis, der eine Ladung ermöglicht, geprüft, ob er sich nach Berechnung des rentablen Preises als Ladung bzw. als Entladestopp eignet.

Ich hoffe, dass damit das Problem, dass der rentable Preis ja immer nur für den niedrigsten Preis gegolten hätte, erledigt hat.

Ich lasse, das Skript jetzt mal eine Woche laufen, und schaue, ob noch Probleme auftreten.

Gruß Wiggal

[wiggal]

habe da nochmal eine Frage: ich habe ja für Notstrom nichts konfiguriert und habe das bis jetzt auch nicht vor. Bei mir ist im WR eine Reservekapazität von 10% eingestellt und ein Minimales Ladelimit von 5%. => Batterie wird bis 10% entladen und die nachfolgenden Ladeverluste managed der WR mit Zwangsladungen. Soweit so gut! Frage: Wann führt dein Programm Zwangsladungen der Batterie durch und kann ich das durch Konfiguration verhindern?

Wo stellst du den die Reservekapazität von 10% ein, ist das nicht beim Notstrom? Hast du mal ne Bildschirmkopie?

Mein Programm führt diesbezüglich keine Zwangsladungen durch, nur im Zusammenhang mit den Strompreisen.

[Manniene]

habe da nochmal eine Frage: ich habe ja für Notstrom nichts konfiguriert und habe das bis jetzt auch nicht vor. Bei mir ist im WR eine Reservekapazität von 10% eingestellt und ein Minimales Ladelimit von 5%. => Batterie wird bis 10% entladen und die nachfolgenden Ladeverluste managed der WR mit Zwangsladungen. Soweit so gut! Frage: Wann führt dein Programm Zwangsladungen der Batterie durch und kann ich das durch Konfiguration verhindern?

Wo stellst du den die Reservekapazität von 10% ein, ist das nicht beim Notstrom? Hast du mal ne Bildschirmkopie?

Habe da nichts "bewusst" eingestellt - ist Standard

Mein Programm führt diesbezüglich keine Zwangsladungen durch, nur im Zusammenhang mit den Strompreisen.

alles klar! -> dann hatte ich etwas falsch verstanden

[wiggal]

Ist die neue Firmware oder?
wäre Interessant was das Script als minimaler Ladestand (Wh) ermittelt. Sollte 10% sein.

[Manniene]

Ist die neue Firmware oder? wäre Interessant was das Script als minimaler Ladestand (Wh) ermittelt. Sollte 10% sein.

ja, wurde installiert als ich im November den 2. Speicher bekommen habe
Batteriekapazität (Wh) | Aktueller Ladestand (Wh) | minimaler Ladestand (Wh)
20480 | 1987 | 2048

[wiggal]

Servus Manfred,

zu deiner Info, ich werde morgen den pull request #116 in den main Zweig mergen, und eine neue Version ziehen.
Weiteren kleine Veränderungen kann ich dann im main weiterpflegen.

[Manniene]

Alles klar!

[Manniene]

Hallo Wiggal,

Habe die Auswertung für die ganze Woche eingestellt. Musste den Dynlog zippen, da ich den log level auf 3 stehen habe und “Lastprofile Neue Tage = 0". Zusätzlich habe ich für die letzte Woche für jeden Tag Screenshots in das angehängte Dokument hinzugefügt.

Das neue Programm läuft konsistent und ist ein guter Fortschritt. Das parallele Laden eines Elektroautos hat ebenfalls gut funktioniert. Für mich stellen die folgenden zwei Themen die wichtigsten Topics dar:

1.) Anpassung des Programmes, so dass aus der Batterie nur Strom bezogen wird, wenn es wirtschaftlich Sinn macht. Aus den Screenshots ist ersichtlich, dass es an der Mehrheit der Tage passiert, dass Strom aus der Batterie bezogen wird, obwohl dies aufgrund der Einstellungen (Akkuverlust + Gewinnerwartung) nicht passieren sollte.

2.) Kontext Elektroauto laden - Gibt es die Möglichkeit, dass Programm “SymoGen24Controller2.py” öfter zu starten z.B. alle 60 sec , ohne das z.B. die WR Daten jedes mal weggeschrieben werden?

Viele Grüße,
Manfred
Auswertung KW03.odt
Crontab-2.log.zip
LOG_DynamicPriceCheck-4.log.zip

[wiggal]

Mein Problem ist, dass vielleicht viele Beispiele aus deiner Sicht in den Auswertungen sind. Aus meiner Sicht gibts die halt nicht.

[wiggal]

OK, dass mit dem Steuerungslauf ohne Logging, geht aktuell nicht, habe nicht gedacht, dass man das braucht. Wäre aber kein großes Ding.

[Manniene]

OK, dass mit dem Steuerungslauf ohne Logging, geht aktuell nicht, habe nicht gedacht, dass man das braucht. Wäre aber kein großes Ding.

wäre super!

[wiggal]

OK, dass mit dem Steuerungslauf ohne Logging, geht aktuell nicht, habe nicht gedacht, dass man das braucht. Wäre aber kein großes Ding.

wäre super!

OK, is drin, du brauchst natürlich die neuesten Codes.

• WebUI-Settings auf WebUI-Settings ausschalten stellen
• einen Cronjob für Logging alle 10 Minuten erstellen
  1-56/10 * * * * /home/GEN24/start_PythonScript.sh http_SymoGen24Controller2.py logging
• einen Cronjob für Entladesteuerung jede Minute erstellen. Sonstige Steuerung brauchst du ja nicht, oder?
  * * * * * /home/GEN24/start_PythonScript.sh http_SymoGen24Controller2.py entladen

Ich hoffe so klappt es.
Wiggal

[Manniene]

OK, dass mit dem Steuerungslauf ohne Logging, geht aktuell nicht, habe nicht gedacht, dass man das braucht. Wäre aber kein großes Ding.

wäre super!

OK, is drin, du brauchst natürlich die neuesten Codes.

• WebUI-Settings auf WebUI-Settings ausschalten stellen
• einen Cronjob für Logging alle 10 Minuten erstellen
  1-56/10 * * * * /home/GEN24/start_PythonScript.sh http_SymoGen24Controller2.py logging
• einen Cronjob für Entladesteuerung jede Minute erstellen. Sonstige Steuerung brauchst du ja nicht, oder?
  * * * * * /home/GEN24/start_PythonScript.sh http_SymoGen24Controller2.py entladen

Ich hoffe so klappt es. Wiggal

Ah, verstehe! Ich benötige natürlich noch:
58 * * * * /home/GEN24/start_PythonScript.sh -o LOG_DynamicPriceCheck.log DynamicPriceCheck.py schreiben
+
Solarprognose
=> pull ich gleich heute Abend
VG + Dankeschön!!

[killwack]

Guten Morgen!

Darf ich eine kurze Frage in die Runde stellen? Mir ist ein interessantes Verhalten aufgefallen.
Ich stufe mich mal als DOU User ein, so kann dies durchaus eine gewollte Funktion sein.

Da ich nun "endlich" die 7 Tage zur Verbrauchsanalyse überschritten habe, werden seit 2 Tagen statt den 600 W nun "reellere" Verbrauchswerte zur Zwangsbeladung der Batterie herangezogen. Die Berechnung schaut soweit sehr gut aus, da es dem entspricht wie ich es auch die Beladung manuell einstellen würde.

Da heute ein besonders "teurer" Tag mit Tarifen in Österreich ist, viel mir gestern aber im LOG folgendes auf:

Die Konfiguration zur Kosten-Abfrage in GEN24 was meine Kosten betrifft stimmt auch mit jenen Werten in GEN24 überein.
Aber die errechnete Ladung verwirrt mich ein wenig:

Frage 1: Haus-Verbrauchswerte Prognose sehr hoch? Möglicher Fehler: Batterie Netzbeladung wird eingerechnet?

1. Ich habe als Max Ladegrenze 7000 eingestellt. Mehr geht beim Fronius Gen24 mit BYD HVS 7.7 (2x Blöcke) technisch nicht zu beladen.
2. Der errechnete Verbrauch in der Nacht ist sehr hoch. Wie werden hier die Verbrauchswerte aus den Historie Daten errechnet?
   Würden hier die Werte vom vergangenen Montag (13.01) herangezogen?

Wird die Netzbeladung der Batterie als "Verbrauch" bewertet und dazu gerechnet?

Hier mein Energieverbrauch am Montag dem 13.01. Hier wurde auch um 3 bis 5 Uhr vom Netz die Batterie manuell über GEN24 "zwangsbeladen".

Frage 2: Errechnete Zwangsbeladung zu hoch, da Batterie bereits voll?

Aus dem Log ersichtlich ist, das obwohl der Batterie Ladestand bereits fast bei max ist (ich kann maximal 15360 laden) dennoch sehr hohe Werte errechnet werden. Auch wenn der sehr hohe Verbrauch abgezogen wird, erscheint mir die Berechnung der Zwangsbeladung zu hoch, oder? Das schafft die Batterie technisch ja gar nicht. (wird entsprechend dann nicht in Fronius umgesetzt, abgeregelt).

Hier dann jene in GEN24 dann geschriebene "Entladesteuerung"

Übersehe ich hier etwas im Verständnis jener von euch konzipierten Dyn.Price Regelung?

[wiggal]

@killwack
Habe gerade einen FIX hochgeladen, in dem dürfte die Batterie Netzbeladung nicht mehr eingerechnet werden.
Bitte mal testen, danke.

[killwack]

Pull gezogen. Werde es nun weiter beobachten.

Eine Frage bitte noch:

Stehen in der PV_Daten.sqlite DB nun bereits "falsch errechnete Verbrauchswerte meiner "7 Tages Historie" drinnen, bzw. muss ich sonst noch etwas ändern? Wenn dem so wäre, ist die 7 Tages Historie bereits verfälscht und ich müsste die Einträge in der DB; oder die DB selbst löschen und von Vorne beginnen (was kein Thema ist, muss nur 7 Tage wieder warten).

Oder werden in der SQL-DB nur die "Rohdaten" jener zur Berechnung nötigen "Messwerte" geschrieben. D.h. dein Fix greift immer, da du den "Tages-Verbrauchsforcast" über deine Berechnungs-Formel aus jenen in der SQL DB hinterlegten "Historischen Messwerte" generierst.

[wiggal]

Nein, die Daten in der PV_Daten.sqlite sind nicht falsch, hier werden nur die Zählerstände zu den jeweiligen Daten gespeichert (AC_Produktion,DC_Produktion,Netzverbrauch,Einspeisung,Batterie_IN Batterie_OUT ). Alles andere wie z.B. das Lastprofil oder die Diagramme werden daraus berechnet.

[wiggal]

Du musst halt die LastprofilNeuTage in CONFIG/dynprice_priv.ini mal für einen Durchlauf von DynamicPriceCheck.py auf 0 setzen, damit das Lastprofil neu berechnet wird.

[killwack]

Guten Morgen. Gestern Abend habe ich die Lastprofilneuberechnung wie oben beschrieben erzwungen. Die danach errechneten Verbrauchswerte sind nun wesentlich geringer.. Die Berechnung der Batteriebeladung stimmt ebenfalls.

Ich beobachte nochmals die Berechnung für den heutigen Tag / Nacht aber es schaut so aus als das dein Fix mit 0.26.2 greift.

[killwack]

Zur Info: Zum obigen Spotprice-Beispiel von heute: Die Berechnung zum Nachladen funktioniert offensichtlich sehr gut. Hier wurde im zweiten Tiefpreisfall des Tages ebenso eine Nachladung initiiert. (um 13:00 Uhr)

[Manniene]

Hallo Wiggal,
hier 2 Screenshots für gestern und heute. Programm lief gestern sehr gut und heute perfekt! Bin auf dem neusten Stand und lasse den "SymoGen24Controller2" mit "entladen" laufen (wegen E-Auto Ladung). => Scheint ebenfalls gut zu funktionieren! Beobachte aber weiter und gebe Feedback.

LOG_DynamicPriceCheck.log
Crontab.log

[wiggal]

Nochmal kurz zur Erläuterung. Nach deiner Entladeberechnung würde nur um 8:00 und 9:00 entladen (>0,3611€). Das heißt, es wären um 24:00 noch ca. 13000Wh im Akku. Man weiß aber die Preise für den nächsten Tag nicht, es könnte passieren, dass sie nicht über 0,3611€ steigen, dann würde der Akku auch morgen nicht entladen, da sich der Preis für den geladenen Strom nicht mehr ändert.

Nicht ganz. Wenn man sich die Preise vom 23.01.25 anschaut, dann ist es ja so, dass es eben nur von 08:00 - 10:00 wirtschaftlich überhaupt Sinn macht Strom aus dem Akku zu beziehen der zuvor für ca. 0,314 Euro geladen wurde (wenn man mit Akkuverlust 15% + 0,01 arbeitet).

Doch genau das habe ich ja geschrieben. Mit dem Entladepreis von 0,3611€ (den hast du ja geschrieben) wird nur zwei Stunden entladen, von 8-10, und dann sind noch genau 13015Wh im Akku, die du evtl. so schnell nicht mehr los wirst.

[Manniene]

Nochmal kurz zur Erläuterung. Nach deiner Entladeberechnung würde nur um 8:00 und 9:00 entladen (>0,3611€). Das heißt, es wären um 24:00 noch ca. 13000Wh im Akku. Man weiß aber die Preise für den nächsten Tag nicht, es könnte passieren, dass sie nicht über 0,3611€ steigen, dann würde der Akku auch morgen nicht entladen, da sich der Preis für den geladenen Strom nicht mehr ändert.

Nicht ganz. Wenn man sich die Preise vom 23.01.25 anschaut, dann ist es ja so, dass es eben nur von 08:00 - 10:00 wirtschaftlich überhaupt Sinn macht Strom aus dem Akku zu beziehen der zuvor für ca. 0,314 Euro geladen wurde (wenn man mit Akkuverlust 15% + 0,01 arbeitet).

Doch genau das habe ich ja geschrieben. Mit dem Entladepreis von 0,3611€ (den hast du ja geschrieben) wird nur zwei Stunden entladen, von 8-10, und dann sind noch genau 13015Wh im Akku, die du evtl. so schnell nicht mehr los wirst.

so betrachtet hast du recht, nur beinhaltet für mich Entladestrategie auch, dass die anderen von mir angesprochenen Aspekte - also die Aspekte die für die Ladeberechnung betrachtet werden - auch berücksichtigt werden. Je nachdem wie man die Begriffe versteht / definiert / benutzt 😀

[wiggal]

Wäre es möglich die bestehende Logik folgendermassen zu erweitern: Die derzeitig implementierte Logik läuft um 23:58 durch und bestimmt ja bereits die Steuercodes für den WR die zwischen der ersten Tiefphase und dem ersten Hochpunkt (bzw. auch darüber hinaus) liegt. Im Anschluss könnte man doch für diese Stunden / oder alle des Tages überprüfen, ob deren Preis >= der Anforderung ist. Wenn nicht dann bekommen diese Stunden eine “-1" was in den Folgestunden auch nicht mehr angefasst wird d.h. diese Stunden des Tages werden in zukünftigen Steuerungsdurchlaufen nicht mehr angefasst.
Mit dieser “neuen" Liste die nur noch die Stunden enthält die für eine Batterieentnahme in Frage kommen wird dann nochmal der komplette Tag durchgerechnet und die zu ladende Strommenge neu bestimmt. => dadurch wird kein Strom für Stunden geladen in denen es nicht wirtschaftlich ist. Aber ja, jetzt würde sozusagen die Prog_Steuerung.sqlite genutzt werden, um Informationen zu persistieren die von den zukünftigen Programmdurchläufen als Basis verwendet werden können. Alle zukünftigen Programmabläufe würden dann jeweils den Entladestrg Eintrag der vorangegangenen Stunde löschen (so würde die Steuertabelle wieder abgebaut). Die zukünftigen Programmdurchläufe würden dann hauptsächlich dafür genutzt den geladenen Strom bis mindestens zum folgenden Strompreishoch (oder darüber hinaus) zeitlich optimal zu verbrauchen. Was meine ich damit zeitlich optimal verbrauchen? Extrembeispiel: ich bin jetzt noch 2 Stunden vom nächsten Hochpreis entfernt und es wird festgestellt, dass der tatsächliche Verbrauch der vorangegangenen Stunden höher war als ursprünglich die Prognose hergab und im Speicher habe ich “nur" noch 1 kWh und in der Folgestunde kostet der Strom 40 Cent und in der Stunde danach 70Cent (diese Beispiele hatten wir in den letzten Wochen), dann möchte ich ja natürlich das ich bei 40Cent aus dem Netz beziehe und bei 70Cent aus dem Speicher (dann würde man den Steuercode der 40 Cent Stunde ebenfalls auf -1 setzen. Und so gibt es noch weitere Szenarien die wir noch angehen können (:-)). Aber jetzt sollten wir vielleicht erstmal annehmen, dass die Prognosewerte zu 100% korrekt sind. Was meinst du?

Ich muss hier ehrlich gestehen, das ist mir zu hoch und viel zu kompliziert, um es funktionell zu coden.
Aber gerne kannst du es auf eine Fork versuchen, du musst in der Datei FUNCTIONS/DynamicPrice.py nur die Funktion get_charge_stop neu stricken, hier steckt die ganze Ladelogik drin.

---

An dem jetzigen Stand der Ladelogik werde ich noch folgendes verbessern:

Bis jetzt wird ja nach einem Maximalpreis gesucht, bei dem die Akkuversorgung nicht mehr reicht.
Dann wird nach einem Minimalpreis vor dem Maximalpreis gesucht.
Wenn die Differenz den rentablen Preis überschreitet, wird charge_rate_kW als Ladewert geschrieben.

Nachteile sind hier vor allem, wenn die charge_rate_kW viel größer ist als der Verbrauch aus dem Lastprofil.
Dann wird auch für die nächsten X Maximalpreise mitgeladen, für die evtl. der rentable Preis nicht mehr überschritten wird,
Oder die benötigte Energie im Speicher wäre nur noch einige Watt, bevor PV-Leistung kommt, es wird aber trotzdem mit charge_rate_kW geladen.

Deshalb möchte ich immer nur den benötigten Verbrauch bzw. die benötigte Energie im Speicher vom gefunden Maximalpreis als Ladewert schreiben, und diesen dann evtl. für mehrere Maximalpreise aufaddieren, bis beim Minimalpreis charge_rate_kW erreicht ist, usw.

Ich hoffe, dann wird es noch ein bisschen genauer, aber natürlich nur im Rahmen der jeweiligen Vorhersagen, die immer ein Problem bleiben.

[Manniene]

Ich muss hier ehrlich gestehen, das ist mir zu hoch und viel zu kompliziert, um es funktionell zu coden.
Aber gerne kannst du es auf eine Fork versuchen, du musst in der Datei FUNCTIONS/DynamicPrice.py nur die Funktion get_charge_stop neu stricken, hier steckt die ganze Ladelogik drin.

kann ich nachvollziehen! Danke für das Angebot - im Moment bin ich noch nicht so weit - bin noch bei Kapitel 3 meines Python Einsteigerbuchs. Ich will mich erstmal an kleinere Aufgaben heranmachen.

[Manniene]

An dem jetzigen Stand der Ladelogik werde ich noch folgendes verbessern:

Bis jetzt wird ja nach einem Maximalpreis gesucht, bei dem die Akkuversorgung nicht mehr reicht.
Dann wird nach einem Minimalpreis vor dem Maximalpreis gesucht.
Wenn die Differenz den rentablen Preis überschreitet, wird charge_rate_kW als Ladewert geschrieben.

Nachteile sind hier vor allem, wenn die charge_rate_kW viel größer ist als der Verbrauch aus dem Lastprofil.
Dann wird auch für die nächsten X Maximalpreise mitgeladen, für die evtl. der rentable Preis nicht mehr überschritten wird,
Oder die benötigte Energie im Speicher wäre nur noch einige Watt, bevor PV-Leistung kommt, es wird aber trotzdem mit charge_rate_kW geladen.

Deshalb möchte ich immer nur den benötigten Verbrauch bzw. die benötigte Energie im Speicher vom gefunden Maximalpreis als Ladewert schreiben, und diesen dann evtl. für mehrere Maximalpreise aufaddieren, bis beim Minimalpreis charge_rate_kW erreicht ist, usw.

Ich hoffe, dann wird es noch ein bisschen genauer, aber natürlich nur im Rahmen der jeweiligen Vorhersagen, die immer ein Problem bleiben.

Alles klar - bin weiter mit dabei. Das mit den Vorhersagen ist noch so ein Ding bei mir. Sowohl die PV Vorhersage als auch die Verbrauchsprognose. Speziell die Verbrauchsprognose ist eine Challenge. Das Laden der Autos bekommt man ja, gut rausgerechnet mit dem Parameter, den du dafür zur Verfügung stellst. Aber mit einer Wärmepumpe ist das schwierig. Hier nur mal als Beispiel: Gestern und heute kam/komme ich pro Tag auf ca. 18kwh und vor einer Woche als es viel kälter war ging der Verbrauch auf 45kwh hoch. => zwischen 0,75kwh bis fast auf 2kwh Verbrauch pro Stunde. Das ist ein Thema das ich für mich angehen möchte. Aber nicht mit der Speed die du vorlegst😀. Nur mal so: Ich habe noch nie so viel Zeit in mein Hobby gesteckt - du hast mich mit deinem Projekt so sehr motiviert - muss etwas bremsen -> meine bessere Hälfte steigt mir sonst noch aufs Dach.