76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Wolle02]

Im Punkt 1 machst du ein einfaches Define ohne irgendwelche Konfigurationen.

Ok, das hab ich tatsächlich nicht kapiert. Es hat jetzt im neuen Anlauf besser geklappt, aber leider hat er beim restore einige Einstellungen trotzdem nicht mit übernommen. Einige Attribute, insbesondere das Wetter Device und die setupInverter... musste ich händisch nachziehen.

Jetzt siehts ganz gut aus und ich beobachte mal.

Danke und Gruß

[DS_Starter]

Einige Attribute, insbesondere das Wetter Device und die setupInverter... musste ich händisch nachziehen.

Gab es die Devices, die in den Attr eingetragen werden, zu diesem Zeitpunkt vllt. noch nicht in dem neuen System?

[Wolle02]

Gab es die Devices, die in den Attr eingetragen werden, zu diesem Zeitpunkt vllt. noch nicht in dem neuen System?

Das Wetterdevice gab es tatsächlich noch nicht, aber die Inverterdevices eigentlich schon. Ebenfalls musste ctrlLanguage und ctrlSpecialReadings nachgezogen werden.

[DS_Starter]

Ok danke. Dann schaue ich mir die Routine bzgl. Inverterdevice / ctrlLanguage , ctrlSpecialReadings nochmal an. Vllt. fehlt da etwas. Bei nicht existierenden Devices, oder Devices mit anderem Namen als hinterlegt, ist die Sache klar.

[DS_Starter]

@Wolle02, habe das Problem gefunden und beseitigt. Es war ein Reihenfolgeproblem beim Import der Attribute wegen diverser Abhängigkeiten. Wird in der kommenden Version gefixt sein.

[klaus.schauer]

In meiner Konfiguration werden die LOG-Daten nicht als SVG-Plots ausgegeben. Nun bringt mich u. U. der Beitrag https://forum.fhem.de/index.php?topic=140509.0 weiter. Rudolf führt dies darauf zurück, dass LOG-Einträge nicht in der chronologische Reihenfolge in der LOG-Datei gespeichert sind. Dies ist in meinen LOG-Dateien tatsächlich so

wie schon geschrieben betrifft es die LastHour.* Readings die wegen ihrer rückwirkenden Erstellung (das habe andere Module sicherlich nicht) immer einen älteren Timestamp in einem sequentiellen File haben werden. Für eine Datenbank ist es so genau richtig.
Deswegen würde ich dir auch empfehlen den Vorschlag von Rudi mit einem separaten Logfile für diese Werte zu gehen.

Ich habe jetzt ein LOG-Device eingerichtet, das nur die Events der benötigten Readings speichert. Jetzt klappt es. Vielleicht wäre es sinnvoll, zu dieser Besonderheit des Moduls einen Hinweis im Wiki aufzunehmen. Da man ja immer erst einmal den Fehler bei sich selbst sucht, hat mich das Stunden gekostet. Danke fürs mithelfen.

[DS_Starter]

Kann ich machen. In den letzten 5 Jahren hatte bis jetzt jedenfalls niemand ein Thema damit. Aber vllt. nutzen ja alle DbLog  ... keine Ahnung.

[Wolle02]

.... Aber vllt. nutzen ja alle DbLog  ... keine Ahnung.

In der Tat. Auch dafür vielen Dank.

[Hadl]

Das wird bereits gemacht. Man sieht es in dem aktuellen Debuglog besser. Heute ist ein Tag ohne jeglichen Überschuß, deswegen hier der Ausschnitt von morgen:

Hallo Heiko,
nachdem die SmartPower Strategie heute mit reichlich Überschuss gut und relativ gleichmäßig zu Laden angefangen hat, ist sie Mittag wieder auf hohe Ladeleistungen gesprungen.
Und das obwohl nur noch 1413Wh gebraucht wurden und deutlich mehr Überschuss erwartet wurde. Der "orginale" OTP ist mit 432W da auch richtig.

Code Auswählen Erweitern

2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 3955 Wh -> target likely achievable? yes
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/10 - hod:11/00, lr/lc:1/1, SocS/E:3725/7680 Wh, SurpH/D:4997/23276 Wh, OTP:768/640 W
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/11 - hod:12/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:5568/17708 Wh, OTP:3000/0 W
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/12 - hod:13/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:6278/11430 Wh, OTP:3000/0 W
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/13 - hod:14/03, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:5095/6335 Wh, OTP:3000/0 W
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/04, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:3527/2808 Wh, OTP:3000/0 W
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/05, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:2000/653 Wh, OTP:3000/0 W
2025.10.29 10:00:02 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/06, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:114/0 Wh, OTP:3000/0 W


2025.10.29 13:55:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 1413 Wh -> target likely achievable? yes
2025.10.29 13:55:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/13 - hod:14/00, lr/lc:1/1, SocS/E:6267/6636 Wh, SurpH/D:5091/1506 Wh, OTP:2178/432 W
2025.10.29 13:55:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/01, lr/lc:1/1, SocS/E:6636/7680 Wh, SurpH/D:3944/0 Wh, OTP:3000/464 W
2025.10.29 13:55:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:2067/0 Wh, OTP:3000/0 W
2025.10.29 13:55:47 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/03, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:115/0 Wh, OTP:3000/0 W

2025.10.29 13:59:17 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 1275 Wh -> target likely achievable? yes
2025.10.29 13:59:17 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/13 - hod:14/00, lr/lc:1/1, SocS/E:6405/6479 Wh, SurpH/D:5091/1167 Wh, OTP:3000/386 W
2025.10.29 13:59:17 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/01, lr/lc:1/1, SocS/E:6479/7680 Wh, SurpH/D:3944/0 Wh, OTP:3000/543 W
2025.10.29 13:59:17 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:2067/0 Wh, OTP:3000/0 W
2025.10.29 13:59:17 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/03, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:115/0 Wh, OTP:3000/0 W

2025.10.29 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 1229 Wh -> target likely achievable? yes
2025.10.29 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/00, lr/lc:1/1, SocS/E:6451/7680 Wh, SurpH/D:3477/2696 Wh, OTP:652/543 W
2025.10.29 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:1930/681 Wh, OTP:3000/0 W
2025.10.29 14:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:142/0 Wh, OTP:3000/0 W


2025.10.29 14:14:27 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, remaining: 1267 Wh -> target likely achievable? yes
2025.10.29 14:14:27 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/14 - hod:15/00, lr/lc:1/1, SocS/E:6413/7680 Wh, SurpH/D:3944/1309 Wh, OTP:2600/575 W
2025.10.29 14:14:27 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/15 - hod:16/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:2067/0 Wh, OTP:3000/0 W
2025.10.29 14:14:27 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 29/16 - hod:17/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:115/0 Wh, OTP:3000/0 W

Hier sieht man recht schön, das der OTP teilweise extrem nach oben korrigiert wird. Woran kann das liegen? Überschuss ist ja reichlich vorhanden!
Auffällig ist der SurpD Wert der irgendwann auf 0 geht.
Ich würde ungern die letzten 20% Ladung des Akkus Mittags mit hoher Leistung reinladen ohne das ich eine Not dazu habe, wenn ich Überschuss bis 17:00 Uhr habe.

Viele Grüße

Hadl

[DS_Starter]

nachdem die SmartPower Strategie heute mit reichlich Überschuss gut und relativ gleichmäßig zu Laden angefangen hat, ist sie Mittag wieder auf hohe Ladeleistungen gesprungen.
Und das obwohl nur noch 1413Wh gebraucht wurden und deutlich mehr Überschuss erwartet wurde. Der "orginale" OTP ist mit 432W da auch richtig.
...
Hier sieht man recht schön, das der OTP teilweise extrem nach oben korrigiert wird. Woran kann das liegen? Überschuss ist ja reichlich vorhanden!
Auffällig ist der SurpD Wert der irgendwann auf 0 geht.

Das konnte ich bei mir auch beobachten und ich bin mir relativ sicher, dass die zusätzliche Anhebung über das Ratio (___batAdjustPowerByMargin) dafür verantwortlich ist. Die Ratio aus Tagesüberschuß zu benötigter Ladeenergie wird am Nachmittag schnell kleiner. Unterhalb 100% gehen wir bei smartPower auf pinmax.
Das sieht man auch am SurpD Wert = 0, ca. 14-15:00 ist der Break-Even wo der noch kommende Verbrauch des Tages den verbleibenden Überschuß übersteigt.
Ich werde die Ratio im Debug mit andrucken um die These überprüfen zu können.

[Hadl]

Das sieht man auch am SurpD Wert = 0, ca. 14-15:00 ist der Break-Even wo der noch kommende Verbrauch des Tages den verbleibenden Überschuß übersteigt.
Ich werde die Ratio im Debug mit andrucken um die These überprüfen zu können.

Ich vermute mal das liegt daran das wir das SmartPower Adjustment mit "spday" machen. Damit haben wir warscheinlich den Verbrauch der ganzen Stunden nach Sonnenuntergang mit drin, und wir erwarten das wir deswegen den Akku nicht voll kriegen. Das ist aber garnicht sinnvoll, wir wollen ihn nach nicht bis Mitternacht voll kriegen, sondern bis kein Überschuss mehr zu erwarten ist.
Könnte man "$total" stattdessen nehmen?

[DS_Starter]

Gut möglich. Ich baue das mal ein und dann sehen wir morgen wir es läuft.

[DS_Starter]

Habe es anpepasst und ins contrib geladen.