76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Schön 

Mein Backup ist offenbar inkonsistent. Vermutlich, weil ich es jede Nacht bei laufendem fhem mache.

Vermutlich liegt die Ursache tiefer. Auch wenn FHEM läuft, sind diese Daten relativ statisch.
Datenbank Files sind eine Ausnahme.
Aber normale Dateien in deinem Filesystem sollten in der Sicherung nicht 0kB groß sein. Da stimmt etwas nicht.

LG,
Heiko

[peterboeckmann]

Aber normale Dateien in deinem Filesystem sollten in der Sicherung nicht 0kB groß sein. Da stimmt etwas nicht.

Im Backup von heute Nacht waren die Dateien auch wieder befüllt.
Hatte wohl etwas mit dem Problem zu tun, das dazu geführt hat, dass die SD-Karte vollgelaufen ist.

Viele Grüße,
Peter

[peterboeckmann]

Hallo Heiko,

zu früh gefreut, leider habe ich gerade doch noch ein Problem festgestellt:

Code Auswählen Erweitern

2026.10.16 11:40:21 3: SolarForecast - WARNING - The Total Energy of Inverter 'Enphase' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this inverter is set to '0'.
2026.10.16 11:40:21 3: SolarForecast - WARNING - The Total Energy of Inverter 'ha_tjsLMch1' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this inverter is set to '0'.
2026.10.16 11:40:21 3: SolarForecast - WARNING - The BatIn Energy of Battery 'Enphase' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this Battery is set to '0'.
2026.10.16 11:40:21 3: SolarForecast - WARNING - The BatOut Energy of Battery 'Enphase' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this Battery is set to '0'.
2026.10.16 11:40:21 3: SolarForecast - WARNING - The BatIn Energy of Battery 'ha_tjsLMch1' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this Battery is set to '0'.
2026.10.16 11:40:21 3: SolarForecast - WARNING - The BatOut Energy of Battery 'ha_tjsLMch1' is lower than the value saved before. This situation is unexpected and the Energy generated of current hour of this Battery is set to '0'.

Diese Meldungen erscheinen im Log seit dem Start von FHEM nach dem Umbenennen der beiden Dateien mit gleichem Zeitstempel.
Das führte in den Balkengrafiken dazu, dass kein stundenweiser Verbrauch und keine stundenweise pvReal mehr angezeigt wurden.

Nachdem ich nun das recover über den set-Befehl ausgeführt habe, kommen die Meldungen bzgl. "The Total Energy of Inverter" nicht mehr, nur noch die mit BatIn und BatOut.
Balkengrafiken bauen sich nun für Consumption und pvReal wieder auf, über die Batterien habe ich keine Grafiken.

Sagt Dir das was?

Viele Grüße,
Peter

[DS_Starter]

Ja, das sind Sicherungsmechanismen im Modul gegenüber unerwarteten Werten.
Das rappelt sich wieder ein.
Du hast den Recover Befehl genutzt ... das ist gut. Der macht im Modul ein bisschen mehr als nur Restore.

Spätestens morgen sollte das erledigt sein.
Ansonsten mal ctrlDebug=collectData einschalten um bisschen mehr zu sehen.
Diese Meldungen sagen nur aus, dass die gemessenen Daten nicht zu den davor gesicherten Daten passen, also z.B. etotal kleiner ist als vorher was nicht sein kann wenn es ein aufsteigender Zähler ist wie gefordert.

Die nächste Zeit schaue ich nur sporadisch ins Forum ... mache mal ein bisschen frei.
Geht dann bald weiter, aber brauche mal Erholung.

LG,
Heiko

[peterboeckmann]

Die nächste Zeit schaue ich nur sporadisch ins Forum ... mache mal ein bisschen frei.
Geht dann bald weiter, aber brauche mal Erholung.

Alles klar, gute Erholung!

[mrhaefele@gmx.de]

Hallo Heiko,

beim Einarbeiten in die PV-KI (aiDecTree) bin ich auf eine Kleinigkeit mit großer Wirkung gestoßen. Geprüft gegen die aktuelle Version 2.10.8 im SVN.

1. Rundungsklammer bei der Umrechnung Wh/m² → kJ/m²

In __openMeteo_ApiResponse (Zweig GHIREFILL, also set ... aiDecTree rawDataGHIreplace) steht:

Code Auswählen Erweitern

my $ghikj = 10 * (round0 ($srwh * WH2KJ) / 10);
Durch die Klammerung ergibt das einfach round0($srwh * WH2KJ). Die Multiplikation mit 10 hebt die Division wieder auf, es wird also nicht auf Zehner gerundet. Beispiel: 10 * (523 / 10) = 523 statt 520.

Die DWD-Werte (Rad1h), mit denen aiGetResult später abfragt, kommen aber immer in Zehnerschritten. Weil AI::DecisionTree Merkmalswerte exakt vergleicht, passt ein ersetzter Datensatz praktisch nie zu einer späteren Abfrage. Bei mir waren nach rawDataGHIreplace nur 19 von 143 ersetzten Werten Vielfache von 10, und das nur zufällig.

Vorschlag:

Code Auswählen Erweitern

my $ghikj = 10 * round0 ($srwh * WH2KJ / 10);
Danach waren es 110 von 110 Werten.

Dieselbe Klammerung steht ein paar Zeilen höher im MODEL-Zweig (Open-Meteo als Strahlungsquelle):

Code Auswählen Erweitern

my $radkJ = 10 * (round0 ($radwh * WH2KJ) / 10);
Dort sind Training und Abfrage zwar in sich konsistent. Wenn aber auch hier Zehnerschritte gemeint sind, bekommt der Baum unnötig viele verschiedene rad1h-Werte und findet entsprechend seltener einen Treffer.

2. sunalt in aiAddInstance – erledigt

Den zweiten Fehler, den ich lokal gepatcht hatte (aiAddInstance trainierte mit sunalt => $sunalt statt mit dem Bin $sabin, sodass die Abfrage schon am Wurzelknoten scheiterte), hast du in der aktuellen Version bereits behoben. Danke!

Zur Einordnung: Mit beiden Korrekturen stieg die Trefferquote der PV-KI bei mir von 0 auf 17 von 28 Vorschaustunden (Stand Anfang September).

Viele Grüße
Udo

[DS_Starter]

Hallo Udo,

danke für den Hinweis/Fund.
Ich habe die Stellen im Modul so wie von dir vorgeschlagen übernommen.
Die V liegt in meinem contrib. Checkin mache ich erst nach meinem Urlaub.

LG,
Heiko