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:

## [v2.10.5]
xx.xx.xxxx Rev. xxxxx

- **Fix:**
  * _createReadingsFromArrayFast: exists Prüfung zur Verhinderung Auto-Vivification (Forum: https://forum.fhem.de/index.php?msg=1369271)
  * removeMinMaxArray: fix limit
 
  * 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"
   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.