76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[roadghost]

Danke @grappa24 > Hab´s bei mir angepasst

[DS_Starter]

@Gerd, @all,

der Setter "reset" ist nun deutlich aufgewertet. Die KI-Daten lassen sich selektiver löschen:

aiData    
    Mit den nachfolgenden Argumenten können die KI-Daten selektiv oder komplett entfernt werden:
   delDataAll - löscht die KI Instanz inklusive aller Trainings- und Rohdaten sowie Daten auf Fileebene und initialisiert sie neu
   delIndex=<Index>,<Index>,... - löscht einen oder mehrere Datensätze mit dem Index. Der Index kann als Regex angegeben sein.
   Beispiele: 1.) delIndex=2025013023 2.) delIndex=2025013023,2025013024 3.) delIndex=202501.* 4.) delIndex=20250130[0-9]

Weitere Eingrenzungsmöglichkeiten werden bei Bedarf folgen.
Außerdem können die weiteren reset-Optionen mit ihren Argumenten direkt in dem verfügbaren Eingabefeld aufgerufen werden. Dadurch entfällt bei bestimmten Aufrufen mit mehreren Argumenten die Notwendigkeit über die Kommandozeile zu gehen.

Liegt im Contrib.
Es sind nun bereits so viele Weiterentwicklungen eingeflossen, dass ich diese Version demnächst als Minor Release 1.60.0 veröffentlichen werde.

LG,
Heiko

[DS_Starter]

Thema smartPower Batteriesteuerung...

Meine Vermutung von gestern hat sich erhärtet. Das Ratio ist unter 100% und somit wird auf pinmax gegangen.
Alternativ könnte implementiere:

   Ratio < 100% -> OTP Iterationswert übernehmen (+ safety)
         < 50%  -> OTP pinmax

Allerdings wäre dadurch heute einiges mehr eingespeist worden. So wurden nur geringe Spitzen abgeschnitten.

Code Auswählen Erweitern

...
2025.10.30 12:44:01.882 1: SolCast DEBUG> ChargeOTP Bat 01 - current Ratio of surplus / energy requirement to achieve the load target: 40.52 %
2025.10.30 12:44:01.882 1: SolCast DEBUG> ChargeOTP Bat 01 30/12 - hod:13/00, lr/lc:1/1, SocS/E:11082/11811 Wh, SurpH/D:2878/4292 Wh, OTP:5040/2878 W
2025.10.30 12:44:01.883 1: SolCast DEBUG> ChargeOTP Bat 01 30/13 - hod:14/01, lr/lc:1/1, SocS/E:11811/14398 Wh, SurpH/D:2723/1569 Wh, OTP:5040/2723 W
2025.10.30 12:44:01.883 1: SolCast DEBUG> ChargeOTP Bat 01 30/14 - hod:15/02, lr/lc:1/1, SocS/E:14398/16454 Wh, SurpH/D:2164/0 Wh, OTP:5040/2164 W
2025.10.30 12:44:01.884 1: SolCast DEBUG> ChargeOTP Bat 01 30/15 - hod:16/03, lr/lc:1/1, SocS/E:16454/17724 Wh, SurpH/D:1337/0 Wh, OTP:5040/1337 W
..


[Hadl]

Meine Vermutung von gestern hat sich erhärtet. Das Ratio ist unter 100% und somit wird auf pinmax gegangen.

Hallo Heiko,
ich hab mich mal selbst an den Code gewagt und folgendes geändert:

- Aktuelle Stunden erhält wieder den Überschuss Anteilig der Rest-Minuten
- Der Überschuss des Rest Tages bis zum letzen Überschuss wird in RemainingSurp gespeichert
- RemainingSurp wird zur SmartPower Margin Berechnung verwendet statt spday
- Wenn der SOC unterhalb lowSoc ist wird die Ladeleistung nichtmehr auf bpinreduced nach oben hin begrenzt, sondern minimal bpinreduced gesetzt.

Damit hab ich schon nen relativ gleichmäßigen Verlauf über den Tag hinbekommen.

Die kleinen Wellen innerhalb einer Stunde möchte ich auch noch wegbekommen, dazu fehlt mir aber gerade der Ansatz. Ich glaube aber ich hab den Grund verstanden.

Wenn ich in einer Stunde 5kWh Überschuss habe, und im Schnitt 1kW brauche, dann passt das zu Beginn der Stunde.
Nach einer halben Stunde rechne ich noch mit 2,5kWh Überschuss in der Stunde. Die Stundenbasierte Suche nach minimaler Ladeleistung sieht also damit immer noch diese Stunde so als könnte man daraus 1kW ziehen. Der Akku ist aber schon voller, dadurch sinkt ungerechtfertigt die Ladeleistung.

Das ganze geht dann bis 10 Minuten vor der vollen Stunde. Dort sind von den 5kW nur noch 1kW übrig, aber auch das wird voll eingerechnet. Wir laden aber diese 1kWh nicht in 10 Minuten rein, sonst müssten wir mit 6kW laden. Hier ist der Fehler am größten.

Anschließend ist weniger als 1kW verfügbar, der Fehler wird kleiner und die Ladeleistung steigt wieder zur notwendigen Leistung hoch.

Hast du eine Idee, wie man die restliche Energiemenge der aktuellen Stunde so einrechnen könnte, das diese nur der minimal notwendigen Ladeleistung mal Rest-Zeit der Stunde entspricht?

Den Verlauf sieht man gut zwischen 13:00 und 15:00
Du darfst diesen Dateianhang nicht ansehen.
schlechtester Punkt wenn OTP ~= SurpH

2025.10.30 12:51:53 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 30/12 - hod:13/00, lr/lc:1/1, SocS/E:4524/4638 Wh, SurpH/D/R:880/6407/12207 Wh, OTP:877/731 W

Aber der Fehler ist klein genug so das er von den default Margin leicht aufgefangen wird.

VG

Hadl