76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

Das Update liegt im contrib. Gerne testen.

Ich hab's auch eingespielt, mal sehen...

In den ersten 24 h kann ich mit dem "Augenintegral" keine Änderung ggü. vorher feststellen, die Speicherzunahme in diesen ersten 24 h ist vergleichbar mit dem Verhalten davor, siehe Screenshot der beiden letzten Neustarts, der erste nach dem Update auf die .4, der letzte mit der .5 aus dem Contrib von gestern.

[DS_Starter]

Danke für die Info. Gern das Update im contrib von heute früh einspielen und ebenfalls testen.

[grappa24]

moin,
hab jetzt lang nicht mehr mitgelesen; hab ich was verpasst oder hab ich ein Problem?

Code Auswählen Erweitern

2026.09.26 05:20:38 1: solErtrag - ERROR - Open-Meteo API server response: Model 'best_match' is not supported by the Ensemble API. Please select a specific ensemble model.

[DS_Starter]

Moin,

nein, da kannst du oder das Modul nichts dafür. OpenMeteo hat offensichtlich etwas an der Ensemble API geändert. Stelle einfach temporär auf z.B. OpenMeteoDWD_D2-API um.
Die Ensemble API muß ich im Modul anpassen. Muß aber erst nachschauen was OpenMeteo geändert hat.

[grappa24]

Stelle einfach temporär auf z.B. OpenMeteoDWD_D2-API um.

damit gehts, danke!

[DS_Starter]

Die Ensemble API habe ich angepasst und funktioniert wieder.
Update der V2.10.5 liegt im contrib.

[DS_Starter]

Zwischenstand zum Problem des Speicherwachstums.
Ich habe inzwischen zahlreiche Funktionen rund um den RAM‑Verbrauch refaktoriert und optimiert.
Im Langzeittest gibt es noch zwei Funktionen die potentiell verantwortlich sein können einen RAM-Sprung von ca. 3MB genau zum Stundenwechsel zu verursachen.
Die Funktionen untersuche ich gerade versuche auch das noch in den Griff zu bekommen. Ein geringes Wachstum an dieser Stelle ist gerechtfertigt, da hier die Daten zur Langzeitspeicherung akkumuliert werden. Nur 3MB scheint mir zu viel zu sein.

Hier ein Überblick, was in die v2.10.5 bisher alles schon eingeflossen ist:

- **Fix:**
  * _createReadingsFromArrayFast: exists Prüfung zur Verhinderung Auto-Vivification (Forum: https://forum.fhem.de/index.php?msg=1369271)
  * removeMinMaxArray: fix limit
  * aiAddInstance (AI::DecisionTree): push gebinntes sunalt in @pvhdata
 
  * Neural Network Wrapper neue Wrapper‑Methode
    AIF_isModelValid() 
    Neue Validierungsmethode, die das FANN-Modell leak-frei prüft.
    Verwendet get_num_input() statt MSE(), da diese XS-Methode keine Exceptions wirft und keine temporären Referenzen erzeugt.
   
  * Absturzgefahr (Segfault) bei Verwendung von gebrochenen `AI::FANN`-C-Pointern aus wiederhergestellten Storable-Cache-Dateien behoben.
  * Falsch-positive I/O-Fehlermeldungen beim Auslesen gültiger Cache-Dateien mit Null-Werten behoben.
  * _calcDataEveryFullHour: durch Array-Kopie bedingtes Speicherleck beseitigt
   
- **Change:**
  * Anpassung bezüglich OpenMeteo API Änderung für OpenMeteoDWDEnsembleAPI
  * Der Befehl "get ... rooftopData" kehrt bei Erfolg anstatt bisher undefiniert mit der Meldung
    "A data retrieval request for the selected radiation and/or weather API has been triggered" (zweisprachig EN/DE)
   zurück.
  * __aiAddRawData: writeCacheFile in den BlockingCall Wrapper writeCacheFileBlocking eingebettet -> Vermeidung Speicherleck
  * Der Befehl "get ... data" meldet in EN oder DE zurück
 
  * **AiFannModelWrapper**: Speichersicherheit bei der Serialisierung über `Storable` deutlich erhöht.
    - Implementierung von `STORABLE_freeze` und `STORABLE_thaw` Hooks, um ungültige C-Pointer/Memory-Leaks nach Demaskierung (Deserialisierung) zu verhindern und FHEM vor Segmentation Faults zu schützen.
    - Überarbeitung der Methode `AIF_isModelValid` zur besseren Unterscheidung zwischen Objekt- und Klassenaufrufen.
 
  * **fileStore / fileRetrieve**: Fehlerbehandlung und Evaluierung geglättet.
    - Umstellung auf das `eval { ... 1; } or do { ... }` Pattern, damit skalare Falsy-Werte (`0`, `""`) nicht fälschlicherweise als I/O-Fehler interpretiert werden.
    - Expliziter Guard-Check bei Nichtexistenz von Dateien in `fileRetrieve`.
 
  * **readCacheFile**: Ressourcenverwaltung für `AI::FANN`-Modelle verbessert.
    - Vor dem Laden neuer Cache-Daten werden alte XS-Objekte nun explizit via `AIF_modelDestroy()` freigegeben.
 
  * **Serialize / Deserialize**:
    - `Deserialize` um Guard-Clauses gegen leere/unverarbeitbare Eingaben ergänzt sowie Fehler-Logging robuster gestaltet.
 
  * removeMinMaxArray, limitArray, _addCon2CircArray, __aiAddRawData, aiFannDetectDrift, medianArray, _calcCaQcomplex, _calcDataEveryFullHour, _aiFannSlopeBias, getPvHistTargetArray, LRU_reset, LRU_evict_tail, __calcNewFactor_migrated, __readConFromCircular refaktoriert
 
 

[Pete]

Hallo zusammen,
ich setze 2.10.2, Stand 29.08.2026 ein. Mir ist im PV-Entscheidungsbaum aufgefallen, dass subalt im Training als Rohwert und bei der Vorhersage als Klasse benutzt wird.
In 76_SolarForecast.pm wird die Sonnenhöhe für den PV-Entscheidungsbaum (AI::DecisionTree) beim Training und bei der Vorhersage unterschiedlich behandelt.

Training (aiAddInstance, Zeilen 32889–32931):
my $sabin = sunalt2bin ($sunalt);                                   # 32889, wird berechnet, aber nicht verwendet
push @pvhdata, { ..., sunalt => $sunalt, ... };                     # 32891, Rohwert
$dtree->add_instance (attributes => { ..., sunalt => $instance->{sunalt}, ... }, ...);   # 32931

Die Variable $sabin wird berechnet, in den Datensatz kommt aber $sunalt. Bei temp und wcc wird dagegen $tbin bzw. $cbin verwendet.

Vorhersage (aiGetResult, Zeilen 33167–33175):
my $sabin = sunalt2bin ($sunalt);                                   # 33167
my $new_data = { ..., sunalt => $sabin, ... };                      # 33175, Klasse

sunalt hat im Training pro Stunde einen fast eindeutigen Wert mit einer Nachkommastelle (z. B. 45.. Das ID3-Verfahren bevorzugt ein Merkmal mit so vielen Ausprägungen beim Informationsgewinn, deshalb steht es an der Wurzel jedes Baums. Die Bäume merken sich einzelne Stunden.
if sunalt='45.80' -> '7760'
if sunalt='32.90' -> '777'
if sunalt='35.00' and wid='3' -> '3675'

Ist die unterschiedliche Behandlung von sunalt Absicht? Falls nicht, wäre sunalt => $sabin in aiAddInstance naheliegend. Ich habe das nicht getestet

[DS_Starter]

Hallo Pete,

guter Fund, danke.
Ich habe es in der v2.10.5 geändert und in mein contrib geladen.

Nur zur Info, die KI Unterstützung für PV-Prognose werde ich ebenfalls auf das neuronale Netz umstellen und AI::DecisionTree ablösen. Das ist mein nächster großer Entwicklungsschritt.

[DS_Starter]

Die Funktionen untersuche ich gerade versuche auch das noch in den Griff zu bekommen. Ein geringes Wachstum an dieser Stelle ist gerechtfertigt, da hier die Daten zur Langzeitspeicherung akkumuliert werden. Nur 3MB scheint mir zu viel zu sein.

Das Problem konnte ich nun mit einem BlockingCall-Workaround beseitigen.
Update liegt im Contrib.

[Wolle02]

Rauf ... dein System braucht weniger Ladeleistung für das gleiche Ergebnis. Weiterhin evtl. Noch safetyMargin auf 0 setzen. Per default sind 20% Sicherheitsaufschlag im Sytem eingestellt. Auch das kann bei dir überzogen sein.

Ich habe mal zum Testen die efficiency auf 100 gesetzt. Das hat die Prognose wann die Batterie voll sein soll noch weiter nach vorne geschoben. Also habe ich mal 55 eingestellt und damit bin ich mit der Prognose auf 100% SoC um 17.00 Uhr gekommen. Das war dann aber auch alles, denn die Anlage hat das mal rein gar nicht interessiert, weil angeblich rechnerisch keine 100% erreicht werden konnten und deshalb das Reading Battery_TargetAchievable_01 auf 0 steht. Damit greift auch keine Regelung, die die Ladeleistung begrenzt.
Will sagen, bei den Tests war das Verstellen des Schlüssels efficiency rein kosmetischer Natur.

Ich finde das aber trotzdem merkwürdig....

Naja, was soll ich dazu sagen. Mein obiger Praxischeck war eindeutig positiv. Wenn du in deinem Code bisher ohne Effizenz gearbeitet hast, hat deine Anlage wohl einen sehr guten Wirkungsgrad -> efficiency=95..98 , Gratulation 

Naja, bei deinem obigen Praxischeck hast du ja auch den Zeitpunkt wann die Batterie voll sein soll nach vorne geschoben. Das gewünschte Verhalten ist ja aber den Zeitpunkt nach hinten zum Ende des Sonnentages zu schieben. Das hast du nicht gemacht.
Aber mittlerweile ist wahrscheinlich die Jahreszeit auch zu weit fort geschritten, um das noch vernünftig testen zu können.

[DS_Starter]

Morgen wird bei mir wieder ein sonniger Tag.
Nun habe ich das Target nach hinten setzt:

Code Auswählen Erweitern

careCycle=20
loadStrategy=smartPower
lowSoc=10
maxSoC=90
safetyMargin=2:0
stepSoC=5
upSoC=50
loadTarget=98:18

Die Prognose ist im Anhang. Dann schauen wir mal wie sich das morgen ausspielt.

Edit:

denn die Anlage hat das mal rein gar nicht interessiert, weil angeblich rechnerisch keine 100% erreicht werden konnten und deshalb das Reading Battery_TargetAchievable_01 auf 0 steht. Damit greift auch keine Regelung, die die Ladeleistung begrenzt.

Gibt es evtl. bei dir eine entsprechend hohe Verbrauchsprognose? Das könnte ein Grund sein.
Auch eine gesetzte Einspeisebegrenzung kann die Ladeleistung hochziehen um eine Abregelung zu vermeiden. Das würde aber mit Battery_TargetAchievable_01=0 nicht zusammenpassen.

[Wolle02]

Morgen wird bei mir wieder ein sonniger Tag.
Nun habe ich das Target nach hinten setzt:

Code Auswählen Erweitern

careCycle=20
loadStrategy=smartPower
lowSoc=10
maxSoC=90
safetyMargin=2:0
stepSoC=5
upSoC=50
loadTarget=98:18


Du setzt zum Testen gerne absolute Werte. 18 Uhr ist ein interessanter Zeitpunkt. Gibt es um die Uhrzeit zu der Jahreszeit bei Dir noch soviel Solarertrag, dass ein Erreichen von 100% möglich wäre? Bei mir ist 18 Uhr mittlerweile zu spät. Deshalb verwende ich gerne relative Werte, weil sie mehr der Realität im täglichen Betrieb entsprechen. 2 Stunden vor Sonnenuntergang  ist bei mir der Zeitpunkt an dem ich grade noch so viel Solarertrag habe, dass ein Erreichen der 100% möglich wäre. Deshalb habe ich loadTarget=100:-2 gesetzt. Der Test mit der absoluten Uhrzeit morgen ist interessant, aber versuch doch im Anschluss auch mal einen relativen Wert. Vielleicht ergibt sich ja eine Veränderung.

denn die Anlage hat das mal rein gar nicht interessiert, weil angeblich rechnerisch keine 100% erreicht werden konnten und deshalb das Reading Battery_TargetAchievable_01 auf 0 steht. Damit greift auch keine Regelung, die die Ladeleistung begrenzt.

Gibt es evtl. bei dir eine entsprechend hohe Verbrauchsprognose? Das könnte ein Grund sein.
Auch eine gesetzte Einspeisebegrenzung kann die Ladeleistung hochziehen um eine Abregelung zu vermeiden. Das würde aber mit Battery_TargetAchievable_01=0 nicht zusammenpassen.

Ja, bei mir gibt es hohe Verbräuche. Das hat das KI Modell mittlerweile gelernt und zeigt deshalb auch eine hohe Prognose an, die am Ende des Tages auch immer wieder erstaunlich gut eintritt. Heute waren es -1,9 %. Aber das führt natürlich dazu, dass die Differenz zwischen Ertrag und Verbrauch zu dieser Jahreszeit nicht so hoch ist, dass prognostiziert werden könnte, dass die Batterie trotzdem voll wird. Das Abregeln der Ladeleistung stelle ich bei mir eigentlich immer nur im Sommer fest.
Eine Einspeisebegrenzung habe ich nicht.

[DS_Starter]

Ok, dann habe ich das Szenario mal so eingestellt:

Code Auswählen Erweitern

careCycle=20
loadStrategy=smartPower
lowSoc=10
maxSoC=90
safetyMargin=2:0
stepSoC=5
upSoC=50
loadTarget=88:-1

Morgen ist 18:57 Sonnenuntergang. Da nur mit vollen Stunden gerechnet wird (18:00), ergibt sich mit -1 ein Ziel von 88% bei 17:00. Prognosegrafik anbei. 88% habe ich gewählt, dass man die gewünschte Ladeleistungsminderung besser sieht.