76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

Moin Heiko,

hab gerade gesehen, dass meine Datei "AItra_SolarForecast_solErtrag" 15 MB groß ist, kann das "Bremsen"?

Dieter

[DS_Starter]

Bremsen im Sinne von CPU Auslastung im Prinzip nur wenn dein RAM aufgebraucht ist und dein System anfängt zu swappen.
Das frist Performance und CPU Leistung. Das kannst du aber auch Linux Ebene prüfen.

Die Datei AItra_SolarForecast_solErtrag enthält übrigens die Modelldaten der PV KI die unabhängig von der CON KI aktiviert wird.
Diese KI Unterstützung wird mit dem PV Autokorrekturprofil aktiviert oder deaktiviert.

[TheTrumpeter]

Ich überlege eventuell demnächst einen Plug&Play-AC-gekoppelten Speicher anzuschaffen wie weiter oben von "justcallmeal" auch genannt, z.B. Zendure 4000 AC+ oder einen Marstek Venus E, wenn es dann die Gen 4 gibt. (Vielleicht in weiterer Folge dann 2 weitere, aber für den Moment gehen wir mal von einem aus.)

Leider habe ich die Diskussionen hier zur Speichereinbindung bzw. -funktionalität nie wirklich verfolgt. Aus dem Wiki würde ich verstehen, dass SF den bzw. die Speicher zwar in der Flussgrafik visualisiert & auf Basis der 3 Säulen "Konfiguration", "PV-" und "Verbrauchsprognose" Empfehlungen für die Ladesteuerung anhand von Readings zur Verfügung stellt, die dann extern "der Batterie mitgeteilt" werden müss(t)en.

Was ich im Wiki nicht gefunden habe, ist etwas analoges für die Entladestrategie. Abhängig von der Speichergröße, dem vorhergesagten Verbrauch sowie dem vorhergesagten Ertrag könnte man die Entladeleistung "vorschlagen", um entweder eine Spitzenlastkappung zu machen oder eben Netzbezug gänzlich zu vermeiden. Bei der Spitzenlastkappung kommt auch noch eine weitere Dimension hinzu: Laden trotz fehlendem PV-Überschuss, um später erwartete Bezugs-Spitzen ausbügeln zu können.

Habe ich das übersehen oder existiert das derzeit nicht?
Ist geplant so etwas umzusetzen?

[DS_Starter]

Hallo @all,

ich habe den Feature Request aus #6982 umgesetzt und das Modul im contrib aktualisiert.
Neu ist drin:

Schlüssel plantControl->plantCoordinates hinzugefügt, um mehrere SF-Geräte
    an verschiedenen Standorten innerhalb eines FHEM-Systems zu unterstützen.
    Format: latitude-><Wert>, longitude-><Wert>
    Wenn dieses Attribut gesetzt ist, haben die gerätespezifischen Koordinaten Vorrang vor den Werten,
    die im globalen Device definiert sind. Die Höhe ist hier nicht konfigurierbar
    und muss im globalen Device festgelegt bleiben (erforderlich für das Astro-Modul).
    Die Eingabe wird beim Setzen validiert; unbekannte Schlüssel werden abgelehnt.

 
altitude muß wegen Abhängigkeiten zu anderen Modulen weiterhin im global Device gesetzt werden.

LG,
Heiko

[DS_Starter]

@TheTrumpeter,

Was ich im Wiki nicht gefunden habe, ist etwas analoges für die Entladestrategie. Abhängig von der Speichergröße, dem vorhergesagten Verbrauch sowie dem vorhergesagten Ertrag könnte man die Entladeleistung "vorschlagen", um entweder eine Spitzenlastkappung zu machen oder eben Netzbezug gänzlich zu vermeiden. Bei der Spitzenlastkappung kommt auch noch eine weitere Dimension hinzu: Laden trotz fehlendem PV-Überschuss, um später erwartete Bezugs-Spitzen ausbügeln zu können.

Habe ich das übersehen oder existiert das derzeit nicht?
Ist geplant so etwas umzusetzen?

Eine Entladeleistungskontrolle/Steuerung gibt es zur Zeit nicht. Nur eine SoC-Steuerung, die eine Entladung unter einen SoC-Wert verhindert wenn im BMS umgesetzt.
Nach einer Enladesteuerung im Sinne einer Leistungsbegrenzung wurde bisher nicht gefragt. Mir ist auch nicht bewußt, dass in Batteriesystemen eine solche Leistungsbegrenzung dynamisch umsetzbar ist. Aber kann es natürlich geben ... kenne ich nur nicht.
Insofern ist diesbezüglich bislang auch nichts geplant.

Stößt dieses Thema noch auf weitere Resonanz? Ich selbst habe eine Begrenzung der Entladeleistung bisher nicht vermißt, meine Batterie soll ja leisten was benötigt wird.

LG,
Heiko

[grappa24]

die gesammelten Daten können den verbrauchten RAM erhöhen. Allerdings sind sie auch vorhanden ohne aiConActivate=1, bzw. wenn die CON KI-Unterstützung nicht verwendet wird.
Du kannst sie trotzdem ansehen mit:

 get ... valDecTree aiRawData ...


Wenn du aiConActivate=1 gesetzt hast, wird dein System auch mal ein Training ausführen. Das halte ich für die wahrscheinliche Ursache.
Das Training ist normalerweise in relativ kurzer Zeit fertig. Wenn das bei dir aus irgendwelchen Gründen nicht so ist, kann es deine CPU über lange Zeit auslasten.
Das verhalten des Trainings siehst du am deutlichsten mit ctrlDebug=aiProcess(_long).

Ich hab mal das Debug mitlaufen lassen,

Code Auswählen Erweitern

2026.09.18 16:28:08 1: solErtrag DEBUG> Epoche 427: Train MSE=0.007037, Val MSE=0.011775, Val MAE=0.056351, Val MedAE=0.020985, Bit_Fail=50 -> Snap weighted rmse improved
2026.09.18 16:28:08 1: solErtrag DEBUG> Epoche 428: Train MSE=0.007032, Val MSE=0.011775, Val MAE=0.056326, Val MedAE=0.020985, Bit_Fail=50 -> Snap weighted rmse improved
2026.09.18 16:28:09 1: solErtrag DEBUG> Epoche 429: Train MSE=0.007026, Val MSE=0.011775, Val MAE=0.056300, Val MedAE=0.020985, Bit_Fail=49 -> Snap bit tradeoff
2026.09.18 16:28:09 1: solErtrag DEBUG> Epoche 430: Train MSE=0.007021, Val MSE=0.011775, Val MAE=0.056275, Val MedAE=0.020985, Bit_Fail=49 -> Snap weighted rmse improved
2026.09.18 16:28:09 1: solErtrag DEBUG> Epoche 431: Train MSE=0.007016, Val MSE=0.011775, Val MAE=0.056250, Val MedAE=0.020985, Bit_Fail=49 -> Snap weighted rmse improved
2026.09.18 16:28:09 1: solErtrag DEBUG> Epoche 432: Train MSE=0.007011, Val MSE=0.011775, Val MAE=0.056225, Val MedAE=0.020985, Bit_Fail=49 -> Snap weighted rmse improved
2026.09.18 16:28:10 1: solErtrag DEBUG> Epoche 433: Train MSE=0.007006, Val MSE=0.011775, Val MAE=0.056199, Val MedAE=0.020985, Bit_Fail=49 -> Snap weighted rmse improved
2026.09.18 16:28:10 1: solErtrag DEBUG> Epoche 434: Train MSE=0.007001, Val MSE=0.010882, Val MAE=0.056174, Val MedAE=0.020913, Bit_Fail=49 -> Snap metric improved
2026.09.18 16:28:11 1: solErtrag DEBUG> Epoche 437: Train MSE=0.006986, Val MSE=0.010850, Val MAE=0.056099, Val MedAE=0.020902, Bit_Fail=49 -> Snap metric improved
2026.09.18 16:28:11 1: solErtrag DEBUG> Epoche 438: Train MSE=0.006981, Val MSE=0.010839, Val MAE=0.056074, Val MedAE=0.020881, Bit_Fail=49 -> Snap metric improved
2026.09.18 16:28:11 1: solErtrag DEBUG> Epoche 439: Train MSE=0.006976, Val MSE=0.010828, Val MAE=0.056049, Val MedAE=0.020861, Bit_Fail=49 -> Snap metric improved
2026.09.18 16:28:26 1: solErtrag DEBUG> Epoche 492: Train MSE=0.006725, Val MSE=0.010828, Val MAE=0.055483, Val MedAE=0.020861, Bit_Fail=47 -> Snap bit tradeoff
2026.09.18 16:28:27 1: solErtrag DEBUG> Epoche 493: Train MSE=0.006721, Val MSE=0.010828, Val MAE=0.055458, Val MedAE=0.020861, Bit_Fail=47 -> Snap weighted rmse improved
2026.09.18 16:28:27 1: solErtrag DEBUG> Epoche 494: Train MSE=0.006717, Val MSE=0.010828, Val MAE=0.055433, Val MedAE=0.020861, Bit_Fail=47 -> Snap weighted rmse improved
2026.09.18 16:28:29 1: solErtrag DEBUG> Epoche 500: Train MSE=0.006700, Val MSE=0.010197, Val MAE=0.055769, Val MedAE=0.022566, Bit_Fail=48
2026.09.18 16:28:38 1: solErtrag DEBUG> Epoche 533: Train MSE=0.006574, Val MSE=0.010828, Val MAE=0.054723, Val MedAE=0.020861, Bit_Fail=46 -> Snap weighted rmse improved
2026.09.18 16:28:40 1: solErtrag DEBUG> Epoche 540: Train MSE=0.006551, Val MSE=0.010828, Val MAE=0.053662, Val MedAE=0.020383, Bit_Fail=48 -> Snap weighted rmse improved
2026.09.18 16:28:42 1: solErtrag DEBUG> Epoche 544: Train MSE=0.006537, Val MSE=0.010828, Val MAE=0.053570, Val MedAE=0.020383, Bit_Fail=47 -> Snap bit tradeoff
2026.09.18 16:28:57 1: solErtrag DEBUG> Epoche 600: Train MSE=0.006379, Val MSE=0.009617, Val MAE=0.052202, Val MedAE=0.019134, Bit_Fail=43
2026.09.18 16:28:57 1: solErtrag DEBUG> Epoche 600: Train MSE=0.006379, Val MSE=0.009617, Val MAE=0.052202, Val MedAE=0.019134, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:00 1: solErtrag DEBUG> Epoche 606: Train MSE=0.006364, Val MSE=0.009601, Val MAE=0.052087, Val MedAE=0.019125, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:07 1: solErtrag DEBUG> Epoche 608: Train MSE=0.006359, Val MSE=0.009594, Val MAE=0.052052, Val MedAE=0.019044, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:15 1: solErtrag DEBUG> Epoche 609: Train MSE=0.006357, Val MSE=0.009591, Val MAE=0.052034, Val MedAE=0.018989, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:24 1: solErtrag DEBUG> Epoche 610: Train MSE=0.006355, Val MSE=0.009587, Val MAE=0.052017, Val MedAE=0.018963, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:28 1: solErtrag DEBUG> Epoche 611: Train MSE=0.006353, Val MSE=0.009583, Val MAE=0.052000, Val MedAE=0.018940, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:34 1: solErtrag DEBUG> Epoche 612: Train MSE=0.006350, Val MSE=0.009580, Val MAE=0.051983, Val MedAE=0.018909, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:35 1: solErtrag DEBUG> Epoche 613: Train MSE=0.006348, Val MSE=0.009576, Val MAE=0.051967, Val MedAE=0.018897, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:36 1: solErtrag DEBUG> Epoche 616: Train MSE=0.006342, Val MSE=0.009566, Val MAE=0.051917, Val MedAE=0.018890, Bit_Fail=43 -> Snap metric improved
2026.09.18 16:29:37 1: solErtrag DEBUG> Epoche 617: Train MSE=0.006340, Val MSE=0.009562, Val MAE=0.051901, Val MedAE=0.018847, Bit_Fail=42 -> Snap metric improved
2026.09.18 16:29:37 1: solErtrag DEBUG> Epoche 618: Train MSE=0.006338, Val MSE=0.009559, Val MAE=0.051884, Val MedAE=0.018821, Bit_Fail=42 -> Snap metric improved
2026.09.18 16:29:38 1: solErtrag DEBUG> Epoche 619: Train MSE=0.006336, Val MSE=0.009559, Val MAE=0.051868, Val MedAE=0.018821, Bit_Fail=42 -> Snap weighted rmse improved
2026.09.18 16:30:57 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 14857
2026.09.18 16:30:57 3: PRESENCE (LG_TV_Status) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2026.09.18 16:30:57 1: solErtrag -> BlockingCall FHEM::SolarForecast::aiFannConDataLoad pid:DEAD:14653 aborted: Process died prematurely
2026.09.18 16:30:57 2: netatmo_M03_00_00_07_d0_f2: getmeasure request failed:  SSL connect attempt failed
2026.09.18 16:30:58 2: netatmo_D70_ee_50_04_82_be: getmeasure request failed:  SSL connect attempt failed
2026.09.18 16:31:14 2: solErtrag - WARNING - The calculated Energy consumption of the house is negative. This appears to be an error and is not saved. - hour=17, PVreal=0, GridFeedIn=233, GridConsumption=10, BatIn=29 , BatOut=49
2026.09.18 16:31:16 3: PRESENCE (LG_TV_Status) - check returned a valid result after 1 unsuccesful retryist leider zu groß um alles zu posten, aber am Ende stimmt irgendwas nicht und der KI-Status in der GUI zeigt "Process died prematurely". Und ja, ein Training lässt meine CPU Auslastung schnell gegen 100% gehen. Memory und Swap "scheinen" unauffällig:

[TheTrumpeter]

Enladesteuerung im Sinne einer Leistungsbegrenzung

So war es nicht gemeint.

Wenn ich Gemini richtig verstanden habe, kann man den oben genannten Geräten die momentane Lade- und Entladeleistung per REST-API bzw. Modbus vorgeben.
Im einfachsten Fall entspricht das dem Überschuss bzw. Momentanbezug.
Wenn die Kapazität zu klein ist, möchte man vielleicht nur die Spitzen kappen, um die Netzgebühr zu reduzieren.

[DS_Starter]

ist leider zu groß um alles zu posten, aber am Ende stimmt irgendwas nicht und der KI-Status in der GUI zeigt "Process died prematurely". Und ja, ein Training lässt meine CPU Auslastung schnell gegen 100% gehen.

Volltreffer würde ich sagen. Wenn du das gesamte Training in ein File packst und anhängst sollte es klappen.

2026.09.18 16:30:57 1: solErtrag -> BlockingCall FHEM::SolarForecast::aiFannConDataLoad pid:DEAD:14653 aborted: Process died prematurely

Hier laufen mehre Hintergrundprozesse gleichzeitig und verbrauchen vermutlich zuviel RAM, wobei du nichts feststellen konntest.

Im Training geht auf jeden Fall die CPU hoch, das ist aber kein Grund für einen Abbruch. 

[grappa24]

Volltreffer würde ich sagen. Wenn du das gesamte Training in ein File packst und anhängst sollte es klappen.
Hier laufen mehre Hintergrundprozesse gleichzeitig und verbrauchen vermutlich zuviel RAM, wobei du nichts feststellen konntest.
Im Training geht auf jeden Fall die CPU hoch, das ist aber kein Grund für einen Abbruch. 

Das mit den Hintergrundprozesses hab ich auch schon in der Linux Prozessübersicht gesehen, mehrere fhem-Prozesse waren am Laufen

[justcallmeal]

@al (& all),

in meinem contrib liegt ein Update bzgl. der Korrektur Flowcontrol:
 
 * Korrektur der Darstellung bei Netzladung der Batterie über den Hausknoten.
   Ein negativer Energiefluss zwischen Inverterknoten und Hausknoten wird nun korrekt als direkter Fluss Hausknoten → Batterie dargestellt.
   Der angezeigte Hausverbrauch bleibt davon unberührt.
Man braucht keine zusätzlichen Einstellungen/Schlüssel etc.
Einfach Einspielen, restarten und testen ob bei Netzladung die Flußrichtung stimmt (und natürlich alles andere wie bisher).
LG,
Heiko

Hallo Heiko,
Dein Update im Contrib funktioniert perfekt, vielen Dank!
Wirst du es in die künftigen Updates aufnehmen?

Grüße,
al

[DS_Starter]

Dein Update im Contrib funktioniert perfekt, vielen Dank!
Wirst du es in die künftigen Updates aufnehmen?

Ja, kommt mit rein im kommenden Update. Ankündigung wie üblich.
Vermutlich am WE.

Das mit den Hintergrundprozesses hab ich auch schon in der Linux Prozessübersicht gesehen, mehrere fhem-Prozesse waren am Laufen

Das ist per se erstmal nichts verwerfliches. Es sind entweder SubProcesses (z.B. DbLog) oder BlockingCalls (z.B. KI-Trainings)/Forks.
Alle vermeiden Blockierungen in FHEM.
BlockingCalls können aber temporäre Speicherfresser sein. Im global Device gibt es das Attribut blockingCallMax um gleichzeitige Prozesse zu begrenzen. Mal ausprobieren ...

Wenn ich Gemini richtig verstanden habe, kann man den oben genannten Geräten die momentane Lade- und Entladeleistung per REST-API bzw. Modbus vorgeben.
Im einfachsten Fall entspricht das dem Überschuss bzw. Momentanbezug.

Ja, so meinte ich die Entladeleistungsbegrenzung. Persönlich kenne ich das nicht und meine Victron Anlage kann das auch nicht, aber sicher bin ich mir nicht.