76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Ja, ok. Wie man es auch immer sieht. Letztlich soll der Ziel-SoC (bei mir 100%) zu einer bestimmten Zeit, nämlich 2 Stunden vor Sonnenuntergang erreicht werden. Das hatte ich im Sommer (Sonnenuntergang 21:00 Uhr) in loadTarget mit 100:-2 (laut Doku) angegeben, aber trotzdem war die Batterie um 16:00 Uhr voll und nicht um 19:00 Uhr.

Mit optPower hatte ich hier (fast) nie Problem. Nutzt Du smartPower?

PS: In Deiner Signatur findet man keiner Info über Dein HW/SW-Setup, was die Beantwortung der ein oder anderen Frage vielleicht aber vereinfachen könne

@Heiko: Apropos Sonnenauf- und untergang: Auch wenn er per Perl-Code erledigt werden kann, so wäre eine bei der Consumer-Konfiguration praktisch, wenn notbefore und notafter auch relativ zum Sonnenauf- und -untergang angeben werden könnte.

[DS_Starter]

Um derart intelligent steuern zu können, benötige ich aber Erzeugungs- und Verbrauchshorizont, der größer also nur ein Tag ist. Ist die hierfür erforderliche Datenbasis prinzipiell von SF zu beziehen?

Ja, gibt es. Für die nächste 3 Tage in die Zukunft, PV komplett:

Code Auswählen Erweitern

get ... radiationApiData

bzw. CON bis 72h auf den vollen Tag:

Code Auswählen Erweitern

get ... nextHours
Die Daten kann man sich herausziehen mit eigenem Code wie im Wiki beschrieben.

[Parallix]

Um derart intelligent steuern zu können, benötige ich aber Erzeugungs- und Verbrauchshorizont, der größer also nur ein Tag ist. Ist die hierfür erforderliche Datenbasis prinzipiell von SF zu beziehen?

Ja, gibt es.
...

Danke für die schnelle Rückmeldung. Das mit den 72h hatte ich im Wiki wohl übersehen. Habe es aber auch beim nochmaligen Suchen nicht gesichtet. Habe wohl Knöpfe auf bzw. vor den Augen.

[Wolle02]

Mit optPower hatte ich hier (fast) nie Problem. Nutzt Du smartPower?

Ja, ich benutze smartPower. Ich meine ich hätte auch mal optPower ausprobiert, aber das weiß ich nicht mehr. Grundsätzlich ist mir smartPower etwas sympathischer, weil ja laut Wiki "bei der Ladestrategie smartPower die generelle Erreichbarkeit des Ladeziels bei der Festlegung der Ladeleistung berücksichtigt" wird.

[enno]

die Warnung habe ich beseitigt und die Funktion _createReadingsFromArrayFast entsprechend gefixt.
Fix liegt in V 2.10.5 in meinem contrib vorab.

Moin Heiko, der Fix aus dem contrib funktioniert. Danke! Habe dein Modul erst mal vom Update ausgeschlossen bis es diese Änderung in die "normale" Version geschafft hat.

Gruss
  Enno

[DS_Starter]

Ich nutze ebenfalls smartpower und habe nichts auszusetzen.
Morgen wird ein sonniger Tag und ich werde mal eine Zielzeit setzen. Mal schauen ob ich deine Beobachtung nachvollziehen kann.

[300P]

Das mit den 72h hatte ich im Wiki wohl übersehen. Habe es aber auch beim nochmaligen Suchen nicht gesichtet. Habe wohl Knöpfe auf bzw. vor den Augen.

Inzwischen dies hier "gesehen" bzw. gefunden ?

Die Daten kann man sich herausziehen mit eigenem Code wie im Wiki beschrieben.

Code Auswählen Erweitern

[FHEM::SolarForecast::]NexthoursVal ('<Name>', <nhr>, '<Key>', <default>)
entspricht der Abfrage mit "get ... nextHours".


[DS_Starter]

Moin,

@Wolle02, ich habe jetzt in ctrlBatSocManagement01 eingestellt:

Code Auswählen Erweitern

careCycle=20
loadAbort=99:400:95
loadStrategy=smartPower
loadTarget=98:-5
lowSoc=10
maxSoC=90
safetyMargin=2:0
stepSoC=5
upSoC=50

Für den Test relevant ist loadTarget=98:-5. Der Sonnenuntergang ist 19:11. Wir rechnen mit vollen Stunden, d.h. die Bat soll 19-5= 14 Uhr 98% SoC erreicht haben.
Die Prognose im Screen stimmt zunächst, der Balken 13 deckt den Bereich 13-14 Uhr ab. Am Ende, d.h. 14 Uhr sind 98% SoC prognostiziert.
Bleibt nun abzuwarten was der Tag so bringt, ob PV- und CON Prognosen die Realität gut abbilden werden damit das Ladeergebnis am Ende so hinkommt wie geplant.

[Parallix]

...
Inzwischen dies hier "gesehen" bzw. gefunden ?
...

Die Beschreibung der API habe ich natürlich gesehen, nicht aber den gültigen Wertebereich und insb. nirgends die Zahl 72 (für die Stunden) bzw. die 3 (für die Tage).  Wo soll das stehen?

[DS_Starter]

...und insb. nirgends die Zahl 72 (für die Stunden). Wo soll das stehen?

Ich behaupte das steht nirgends so fest geschrieben.
Es sind bis zu 72h erkennbar über "get ... nextHours". Der letzte Eintrag zeigt die Kalkulationsgrenze, bei mir aktuell:

Code Auswählen Erweitern

NextHour62 => starttime: 2026-09-25 23:00:00, day: 25, weekday: Fr, holiday: 0, hourofday: 24, today: 0
              pvapifcraw: 0, pvapifc: 0, pvaifc: -, pvfc: 0, pvfcfeedlim: 0, aihit: 0
              conlegfc: 688, conaifc: 692, confc: 692, conbiascorr: 2, confcEx: 688, weatherid: 103, wcc: 100, rr1c: 0.00
              temp: 13.00, windspeed: 2.02, windspeed_fast: 2.02, rad1h: -, sunaz: 330.70, sunalt: -36.00, DoN: 0
              rrange: 0.00, crange: 100, DaysInRange: 17, correff: 1.00/-
              soc01: 82.2, soc02: -, soc03: -, socprogwhsum: 26287
              rcdchargebat01: 1, rcdchargebat02: -, rcdchargebat03: -
              lcintimebat01: 1, lcintimebat02: -, lcintimebat03: -
              strategybat01: smartPower, strategybat02: -, strategybat03: -
                                                                           

Endedatum 25.09 23:00. Der aktuelle Tag ist bereits in Stunde 10, sonst wären es 72h.

[Parallix]

...und insb. nirgends die Zahl 72 (für die Stunden). Wo soll das stehen?

Ich behaupte das steht nirgends so fest geschrieben.
...

Danke, wollte schon zum Augenarzt

[lawern]

Aja... beobachte schon länger stetig steigenden Speicherverbrauch.

Kann aber auch noch andere Ursachen als SF AI::FANN haben. Gestern hatte ich z.B. noch ein potentielles Speicherleck im FHEM Kern selbst kommuniziert.
Also warten wir mal ab ob es schon der Weisheit letzter Schluß ist. Auch andere Module können noch problematische Speicher-Situationen hervorrufen.

Hallo Heiko,

zu dem Speicherthema, das hier ein paar Beiträge weiter oben aufkam (2.10.4 mit dem Fix am potenziellen AI::FANN-Leck, und TheTrumpeters Beobachtung von stetig wachsendem Speicher) hätte ich Messwerte beizusteuern. Du hattest ja selbst geschrieben, dass da mehrere Ursachen zusammenkommen können. Ich glaube, ich kann wenigstens eine davon dingfest machen.

Mein Pi 2 hat nur 1 GB RAM, da fällt jedes Megabyte auf. Ich protokolliere deshalb seit zwei Wochen alle 5 Minuten den Speicherbedarf von FHEM (RSS plus ausgelagerte Seiten).

Was mir zuerst auffiel: Die Zuwächse sammeln sich fast alle in der ersten 5-Minuten-Messung nach der vollen Stunde. Also genau dort, wo die DRIFT-Berechnung für con läuft und die FANN-Driftdaten geschrieben werden.
Verteilung der Sprünge über 0,3 MB nach Minute der Stunde, über zwei Tage:

Code Auswählen Erweitern

Minute :05   33 Sprünge, zusammen 28,2 MB
Minute :50    9 Sprünge, zusammen  5,5 MB
Minute :00    8 Sprünge, zusammen  2,9 MB
alle übrigen  1-7 Sprünge, je 0,3-3,6 MB

Also habe ich es zweimal sauber gegengetestet und die Verbrauchs-KI jeweils über Nacht abgeschaltet (aiControl aiConActivate=0), einmal unter 2.10.2 und einmal unter 2.10.4.
Summe der sieben Stundenwechsel zwischen 23:00 und 05:00:

Code Auswählen Erweitern

                              mit FANN           ohne FANN
Test 1 (13./14.09., 2.10.2)   +6,25 / +4,88 MB     -1,62 MB
Test 2 (22./23.09., 2.10.4)   +8,85 / +8,23 MB     -0,40 MB

Einzeln sieht die Testnacht unter 2.10.4 so aus:

Code Auswählen Erweitern

21:00 (FANN an)    +1,66 MB
22:00 (FANN aus)   -0,19 MB
23:00              +0,13 MB
00:00              -0,40 MB
01:00 bis 05:00     0,00 MB   (fünfmal exakt null)
06:00 (wieder an)  +0,70 MB

In dem Fenster fehlten im Log erwartungsgemäß sämtliche "AI FANN drift data"-Zeilen.

Der Vergleich der Stundensprünge vor und nach dem Update:

Code Auswählen Erweitern

15.09. (2.10.3)   24 Sprünge, Mittel +0,85 MB, Tagesrate +1,98 MB/h
22.09. (2.10.4)   20 Sprünge, Mittel +0,82 MB, Tagesrate +2,27 MB/h

Für mich heißt das: Das Wachstum hängt eindeutig an der Verbrauchs-KI, und der Fix in 2.10.4 hat an diesem Pfad nichts geändert, aber du hattest den Fix ja ausdrücklich als "potenziell" angekündigt, und das globale DESTROY-Patching betraf ja die Serialisierung. Unser Pfad scheint ein anderer zu sein.

Noch zwei Beobachtungen, die vielleicht bei der Eingrenzung helfen:

Erstens wächst dabei nichts, was von Perl aus sichtbar wäre.
Ich habe zweimal im Abstand von 39 Minuten sämtliche Devices und alle Teilbäume unter $data gezählt: Keine einzige Veränderung außer ein paar neuen Forecast-Readings im Tagesverlauf.
pvhist bleibt bei 31, circular bei 25, der Logsperr-Hash bei 820. Das passt zu einem Leck unterhalb der Perl-Ebene, also in der C-Bibliothek oder der XS-Anbindung.

Zweitens: das Intervall der zentralen Aufgabe spielt keine Rolle. Ich habe cycleInterval testweise von 70 auf 600 s gestellt, also 8,5-mal seltener. Die Wachstumsrate blieb unverändert (2,7 statt 2,0 MB/h, im Rahmen der Streuung). Es hängt also an etwas Stündlichem, nicht am Zyklus.

Falls Du irgendetwas gegentesten willst: Debug-Ausgaben, eine Testversion, andere Parameter.
Sag gern Bescheid, ich habe die Messkette stehen und kann über Nacht beliebige A/B-Vergleiche fahren.

Viele Grüße
Lars

[DS_Starter]

Danke Lars für deine ausführlichen Ergebnisse. Dem gehe ich mal nach.

[TheTrumpeter]

Danke Lars für deine ausführlichen Ergebnisse. Dem gehe ich mal nach.

Ich habe mal ein bisschen in meinen Logs gegraben. Bei mir sieht es so aus als ob sich der Speicherverbrauch ab Juli grundlegend anders darstellt das davor.
Vorher: linearer Anstieg mit geringer Steigung nach FHEM-Neustart
Seither: linearer Anstieg mit großer Steigung in den ersten Stunden nach FHEM-Neustart, nach ca. 24 h für ein paar Stunden fast exponentiell, danach linear mit geringer Steigung

Das Update auf die 2.10.4 habe ich am 21.09.2026 gemacht. Auf den ersten Blick scheint damit der leichte Anstieg ab ca. 40-48 h nach Neustart etwas weiter abgeflacht zu sein, aber am extremen Zuwachs innerhalb der ersten Stunden hat es nichts geändert.

Woran die gravierende Änderung ab Juli liegt, kann ich so erst mal nicht sagen. Falls gewünscht, kann ich meine - täglich gesicherte - fhem.cfg in dem Zeitraum mal durchschauen, ob ich da ev. grad CON:FANN aktiviert habe, oder siehst Du anhand der Moduländerungen eine mögliche Ursache in dem Zeitraum?

[DS_Starter]

Ich gehe erstmal dem Ergebnis von Lars nach.
Bezüglich Speicherleck bin ich bei der Programmierung von SF sehr achtsam wegen dem schieren Umfang und habe die Perl Strukturen auch bereits mit Hilfe von KI Analyse durchsehen lassen.
Deswegen teile ich Lars Meinung:

Das passt zu einem Leck unterhalb der Perl-Ebene, also in der C-Bibliothek oder der XS-Anbindung.

Es liegt wahrscheinlich tiefer im Code und der Hinweis bezüglich AI::Drift kann sehr hilfreich sein. Diese Werte werden stündlich berechnet und auch im FANN Objekt zur Wiederherstellbarkeit gespeichert. Normalerweise erfolgt eine solche Speicherung im BlockingCall im Training. Der Nebenprozess wird nach dem Training weggeworfen was den Speicher freigibt, bei der Driftberechnung ist es nicht so. Möglicherweise ist das ein wichtiger Aufhänger, die Berechnung selbst oder der Speicherungsprozess des Objektes. Bleibt abzuwarten.