76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Das Wetter ist heute nicht so gut weswegen der Tag mit einer Tasse Kaffee und Forum lesen startet. 

@Parallix,

U.a. vor dem o.g. Hintergrund schlage ich vor, in SF ein Attribut zu definieren, mit denen angegeben werden kann zu welchem prozentualen Anteil SF Verbräuche bei der Bestimmung der "optimalen Ladeleistung" berücksichtigen sollen.
....

Meines Erachtens ist es ungünstig, dass SF für den Fall, dass nicht genügend "Überschuss" vorhanden ist, Battery_ChargeOptTargetPower_XX auf pinreduced setzt, insb. dann, wenn Battery_ChargeOptTargetPower_XX dem WR als maximale Leistung genannt wird, mit dem er einen Speicher laden soll.
.... schlage ich vor, Battery_ChargeOptTargetPower_XX auf pinreduced nur für denn Fall, dass eine Speicher unter lowSoc fällt, zu setzen (also wenn Battery_ChargeRequest_XX == 1).

Kann ich machen, gebe aber zu bedenken, dass OTP dann auf pinmax bzw. 'unendlich' zurück fällt.
Würde ich einen Schlüssel für den prozentualen Anteil der SF Verbräuche bei der Bestimmung der "optimalen Ladeleistung" einbauen, würde auch dies Auswirkung auf den prognostizierten PV-Überschuß und somit den Rückfall haben. So würde z.B. bei 0% Anteil Verbrauch immer ein PV-Überschuß prognostiziert sofern überhaupt PV-Leistung erwartet wird.

Andererseits wird pinreduced auch dann (erhöhend) genutzt wenn die berechnete Ladeleistung auf Grundlage der Prognose unterhalb dieses Wertes ist. Wenn ich also pinreduced durch pinmax ersetze, fehlt dieser Vergleichswert bei der Bestimmung der Ladeleistung (ich kann nicht sinnvoll gegen pinmax vergleichen) und es würden sich u.U. sehr kleine Ladeleistungen ergeben. Nur dann wenn überhaupt kein PV-Überschuß prognostiziert wird, käme pinmax zum Tragen.

Wegen dieser Zusmmenhänge ist die Auswahl einer von den zwei möglichen Stategien zur Bat Ladung m.M. nach von der Jahreszeit abhängig. Im Wiki habe ich dazu meine Haltung geschrieben so wie ich die Auswahl der Strategie vornehmen würde.

LG und einen schönen Sonntag ...

[Parallix]

Das Wetter ist heute nicht so gut weswegen der Tag mit einer Tasse Kaffee und Forum lesen startet. 
...

Schade, dass Du im Urlaub derzeit schlechtes Wetter hast! Da wird es Dich auch nicht trösten, wenn wir hier bei uns ist derzeit bestes solares Wetter haben.

Was den Rückfallwert angeht, so wäre es wahrscheinlich sinnvoll, einen weiteren zu haben, der aber nur dann angenommen wird, wenn der SOC so niedrig ist, dass bald eine Zwangsladung aus dem Netz droht.

Was Du da hinsichtlich der gegenseitigen Abhängigkeiten geschrieben hast, das muss ich mir erst mal in Ruhe ansehen.

[DS_Starter]

Hallo @all,

während meines Urlaubs (es gab immer mal wieder etwas Zeit  ) habe ich die Funktion zur optimalen Ladeleistung komplett überarbeitet.
Die Leistungen werden nun über eine binäre Iteration bis zur Zielgenauigkeit von 1 Watt ermittelt und mit dem gewählten safety-Prozent aufgewertet. Der Rückfallwert ist bei fehlendem Surplus auf pinmax (oder undendlich) realisiert was ein Laden der Batterie ermöglicht falls doch unerwartet Surplus entsteht. Es wird mindestens mit pinreduced geladen. Wird <=lowSoC erkannt, wird pinreduced im Reading Battery_ChargeOptTargetPower_XX eingetragen. Damit wird die Bat schonend aus den Grid geladen falls nötig.

Weiterhin gibt es einen neuen Key ctrlBatSocManagementXX->loadStrategy um die Auswirkungen der gewählten Strategie in der Batterie Balkengrafik zu sehen:

loadStrategy Bei der Anzeige der Batterie in der Balkengrafik wird die gewählte Ladestrategie berücksichtigt.
    Die Generierung der Steuerreadings wird nicht beeinflusst. Die Angabe ist optional.
    Weitere Informationen siehe Wiki.
    Wert: loadRelease oder optPower, default: loadRelease

Ein Link zum Wikibeitrag für weitere Erläuterungen ist eingefügt.

Der Debuglog sieht auch ganz anders aus:

Code Auswählen Erweitern

2025.10.01 13:28:42.484 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.01 13:28:42.484 1: SolCast DEBUG> Bat 01 ChargeOTP - used safety margin: 20 %
2025.10.01 13:28:42.484 1: SolCast DEBUG> Bat 01 ChargeOTP - is the charging goal likely to be achieved? - goal: 5967 Wh -> no
2025.10.01 13:28:42.485 1: SolCast DEBUG> Bat 01 ChargeOTP 01/13 - hod: 14 / 00, lc: 1, SoC S/E: 22449 / 23423 Wh, Surplus: 677 Wh, OTP: 974 W
2025.10.01 13:28:42.485 1: SolCast DEBUG> Bat 01 ChargeOTP 01/14 - hod: 15 / 01, lc: 1, SoC S/E: 23423 / 24199 Wh, Surplus: 647 Wh, OTP: 776 W
2025.10.01 13:28:42.485 1: SolCast DEBUG> Bat 01 ChargeOTP 01/15 - hod: 16 / 02, lc: 1, SoC S/E: 24199 / 24799 Wh, Surplus: 371 Wh, OTP: 600 W
2025.10.01 13:28:42.486 1: SolCast DEBUG> Bat 01 ChargeOTP 01/16 - hod: 17 / 03, lc: 1, SoC S/E: 24799 / 26245 Wh, Surplus: 1205 Wh, OTP: 1446 W
2025.10.01 13:28:42.486 1: SolCast DEBUG> Bat 01 ChargeOTP 01/17 - hod: 18 / 04, lc: 1, SoC S/E: 26245 / 26845 Wh, Surplus: 368 Wh, OTP: 600 W
2025.10.01 13:28:42.486 1: SolCast DEBUG> Bat 01 ChargeOTP 01/18 - hod: 19 / 05, lc: 1, SoC S/E: 26845 / 26845 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.487 1: SolCast DEBUG> Bat 01 ChargeOTP 01/19 - hod: 20 / 06, lc: 1, SoC S/E: 24801 / 24801 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.487 1: SolCast DEBUG> Bat 01 ChargeOTP 01/20 - hod: 21 / 07, lc: 1, SoC S/E: 24114 / 24114 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.487 1: SolCast DEBUG> Bat 01 ChargeOTP 01/21 - hod: 22 / 08, lc: 1, SoC S/E: 23376 / 23376 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.488 1: SolCast DEBUG> Bat 01 ChargeOTP 01/22 - hod: 23 / 09, lc: 1, SoC S/E: 22613 / 22613 Wh, Surplus: 0 Wh, OTP: 5040 W
2025.10.01 13:28:42.488 1: SolCast DEBUG> Bat 01 ChargeOTP 01/23 - hod: 24 / 10, lc: 1, SoC S/E: 21844 / 21844 Wh, Surplus: 0 Wh, OTP: 5040 W


Man sieht auch ob das Ladeziel, die benötigte Ladeenergie, (is the charging goal likely to be achieved?) am laufenden Tag überhaupt erreicht werden kann.
Jetzt ist die Lösung auch so flexibel, dass ich auf individuelle Ladeziele bzw. Ziel-SoCs erweitern kann. Oder auch die prozentuale Berücksichtigung des Verbrauchs was noch zu machen ist.

Das update liegt im contrib.

LG,
Heiko