76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Im Wiki steht auch, dass die Werte mit jedem Zyklus "Attribut plantControl->cycleInterval" gesammelt und der Verbrauch ermittelt wird. So wie ich das sehe, ändern sich die Werte aber bei jedem Event, das zu einer Neuberechnung in SolarForecast führt.

Ja, das ist natürlich richtig und habe ich gleich ergänzt.

Werden dann auch alle für die Berechnung nötigen Werte "frisch abgeholt" oder ggf. teilweise Werte des letzten regulären Zyklusses verwendet?

Alle Werte werden neu gelesen. Die Zyklen gemäß Zeitplan unterscheiden sich inhaltlich nicht von den Eventzyklen.

Um nähere Informationen zu bekommen, sollte dir ctrlDebug=collectData helfen. Nach den ganze Wetterdaten kommen die gelieferten Werte der Geräte, z.B.:

Code Auswählen Erweitern

2025.04.24 17:07:12.176 1: SolCast DEBUG> collect Meter data - device: SMA_Energymeter =>
2025.04.24 17:07:12.176 1: SolCast DEBUG> gcon: 11.4 W, gfeedin: 0 W, contotal: 1001574.9 Wh, feedtotal: 3476679.9 Wh
2025.04.24 17:07:12.177 1: SolCast DEBUG> write to pvHistory - day: 24, hod: 18, GridConsumption (gcons): 3 Wh
2025.04.24 17:07:12.177 1: SolCast DEBUG> collect Battery Readings data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2025.04.24 17:07:12.178 1: SolCast DEBUG> pin: 0 W, pout: 334 W, totalin: 4840059.83604193 Wh, totalout: 4722562.66920408 Wh, soc: 87
2025.04.24 17:07:12.192 1: SolCast DEBUG> EnergyConsumption input -> PV: 20, PP: 0, GridIn: 0, GridCon: 3, BatIn: 0, BatOut: 43
2025.04.24 17:07:12.192 1: SolCast DEBUG> EnergyConsumption result -> 66 Wh

Möglicherweise verletzen manche Geräte die Forderung nach einem sich ortlaufend erhöhenden Zähler. Das Debug sollte dann auch entsprechende Mitteilungen zeigen.

LG,
Heiko

[bismosa]

Hallo!

Ich bin derzeit dabei meinen RAM-Bedarf in FHEM zu untersuchen. Von 180MB (maximal) vor einem Jahr bin ich mittlerweile bei 360MB direkt nach einem Neustart. Dies auch kontinuierlich ansteigend.
Bei mir benötigte SolarForecast ca. 110MB. Zumindest war der RAM-Bedarf ca. 110MB weniger nach einem neustart, als ich SF entfernt hatte.

Jetzt habe ich SF wieder neu eingerichtet. Jetzt liege ich bei ca. 280MB RAM. SF Benötigt nur noch 10-20MB. Ist aber auch noch wieder im Lernprozess. Habe nur das Device selbst danach wiederhergestellt. So wichtig sind die bisher gesammelten Daten da für mich nicht. Ich benötige es eigentlich nur um ein paar Verbraucher zu schalten, wenn genug Strom da ist.

Ist es richtig, das mit der Zeit der Bedarf immer weiter wächst?
Ich beobachte in regelmäßigen Abständen, das der Bedarf Sprunghaft um 5-8MB einmal am Tag steigt. (Nur bei aktiviertem SF) So habe ich derzeit immer nur ein paar Tage Laufzeit von FHEM bis ich zu viel RAM verbrauche.

Ist der RAM-Verbrauch "normal" und ich sollte mein System lieber weiter aufrüsten? Oder liegt es nur an meiner Installation?

Gruß
Bismosa

[DS_Starter]

Tendenziell wird durch Datensammlung und vor allem durch KI Prozesse der Speicherbedarf wachsen. Allerdings hat alles seine Grenzen bzw. kann man darauf Einfluß nehmen.

Insbesondere kannst du zwei Dinge einstellen:

- das Attr aiControl->aiStorageDuration auf einen ganz niedrigen Wert setzen. Dadurch werden nur ganz wenige KI-Rawdaten gehalten. Einmal in der Nacht erfolgt die Löschung, Kontrolle mit get ... valDecTree aiRawData.

- das Attr aiControl->aiTreesPV auf 1 setzen. Das reduziert stark den Umfang der Random Trees, Kontrolle mit get ... valDecTree aiRuleStrings.

Damit dürftest du die stärksten Ressourcenfresser reduziert haben wenn du diese Funktionen nicht benutzt.
Die restlichen Speicher wie pvHistory und pvCircular werden regelmäßig überschrieben und sollten nicht so stark beitragen.

ch beobachte in regelmäßigen Abständen, das der Bedarf Sprunghaft um 5-8MB einmal am Tag steigt.

Das kommt durch die KI RandomTree Berechnung.

So habe ich derzeit immer nur ein paar Tage Laufzeit von FHEM bis ich zu viel RAM verbrauche.

Bei nur einem SF-Device kommt mir ein wenig merkwürdig vor. Auf meinem P-system laufen 6! SF-Devices parallel. Jedes davon sammelt in vollem Umfang Daten.
Man sieht im Screenshot wie der RAM eine Zeit lang steigt, sich aber dann einpendelt.
Allerdings läuft auf dem Server so ziemlich alles was es bei mir gibt (1213 Entitäten).

Vielleicht liegt es auch an deiner Perl-Version. Hatten wir ja schon öfter. Bei mir Perl 5.36

Grüße,
Heiko

[bismosa]

Hallo!

Danke für die schnelle und sehr ausführliche Antwort!

800MB RAM? Ok...da brauche ich noch ein bisschen. Dann liege ich mit meinen 360MB (und mein System ist nicht gerade klein...über 1000 devices) ja noch gut im Rennen.

Ich habe das Attribut aiControl nun gesetzt und werde das mal weiter beobachten. Perl habe ich ebenfalls 5.36
Und über eine Hardwareerweiterung sollte ich dann auch dringend mal nachdenken 

Gruß
Bismosa

[DS_Starter]

Man gönnt sich ja sonst nichts 
Die SF-Instanzen haben jeweils ca. 5000 bis 8000 KI-Rawdatensätze und jeweils 10 RandowmTrees mit jeweils ca. 7000 Knoten und 10 x 5200 Regeln. Das wird alles im Ram gehalten. Dadurch leifert die KI ein Abfragergebnis innerhalb von 0.06 ms. Das ist wichtig für die Gesamtperformance, denn diese Zeit würde FHEM direkt ausbremsen. Deswegen achte ich darauf. Trotz der Komplexität brauchen meine SF-Devices pro Zyklus nur etwa 40 ms. Das variiert natürlich etwas je nachdem ob physische Devices geschaltet werden müssen usw.

LG,
Heiko

[DS_Starter]

@all,

ich habe noch einige Attribute identifiziert, die m.M. nach selten bis sehr selten genutzt bzw. nach ihrer Festlegung geändert werden.
Diese Attribute würde ich unter einem Attr "graphicControl" zusammenfassen:

Code Auswählen Erweitern

graphicBeamWidth     
graphicHourCount     
graphicEnergyUnit     
graphicHeaderDetail       
graphicHourStyle     
graphicLayoutType     
graphicSpaceSize
Natürlich kann man diese Schlüssel dann wieder über den Setter attrKeyVal selektiv ändern.

Gibt es andere Meinungen/Ergänzungen dazu?


     

[TheTrumpeter]

bei 360MB direkt nach einem Neustart. Dies auch kontinuierlich ansteigend.

Was verwendest Du denn sonst noch?

Ich habe vor einiger Zeit festgestellt, dass fhempy (verwende ich für tuyalocal) bei mir zu permanent steigendem RAM-Verbrauch führt. Warum das so ist, konnte ich noch nicht ergründen. Ich helfe mir nun damit, dass ich fhempy mittels watchdog neu starte, wenn die RAM-Auslastung über eine bestimmte Schwelle geht.

Ich plane schon lange mein System von einem RasPi 3B (1 GB RAM) auf einen 4B mit 4 GB RAM umzuziehen und bei der Gelegenheit auch gleich die ganzen aufgesteckten HATs umzubauen sowie die weitere Verkabelung auf abnehmbare Schraubterminals zu ändern, aber irgendwie fehlt mir die Motivation dafür... never change a running system.

[300P]

Ich plane schon lange mein System von einem RasPi 3B (1 GB RAM) auf einen 4B mit 4 GB RAM umzuziehen und bei der Gelegenheit auch gleich die ganzen aufgesteckten HATs umzubauen sowie die weitere Verkabelung auf abnehmbare Schraubterminals zu ändern, aber irgendwie fehlt mir die Motivation dafür... never change a running system.

Bau dir eine WP ein und lass den HZB dann doch mal alles im Raum "fluten"    - dann MUSST du es tun......hab Erfahrung damit 
 
Gruß
300P

[300P]

@all,

ich habe noch einige Attribute identifiziert, die m.M. nach selten bis sehr selten genutzt bzw. nach ihrer Festlegung geändert werden.
Diese Attribute würde ich unter einem Attr "graphicControl" zusammenfassen:
.......
Natürlich kann man diese Schlüssel dann wieder über den Setter attrKeyVal selektiv ändern.
Gibt es andere Meinungen/Ergänzungen dazu?

Keine Einwände meinerseits

[TheTrumpeter]

Bau dir eine WP ein und lass den HZB dann doch mal alles im Raum "fluten"    - dann MUSST du es tun......hab Erfahrung damit 

WP heißt Wärmepumpe und HZB Heizungsbauer?

Wärmepumpe habe ich schon, der FHEM-RasPi bzw. generell die ganzen Zusatzgeräte hängen ca. 2,3 Meter über dem Fussboden im Keller. Bis das ganze Geschoss auf 2,3 m geflutet ist, sind erstmal gut 200 m³ Wasser erforderlich. Da ist der RasPi dann meine letzte Sorge.

[300P]

Meiner war wegen einer vorhandenen Brennstoffzellenheizung mit einem USB-Viessmannadapter aus Platzgründen an der Wand unterhalb der Verteilung in einer geschlossenen Kunstoffkiste - genau da ging aber der Wasserstrahl rein (RPI incl. SSD und Backup SSD haben schwimmen gelernt) weil einer der Handwerker wohl da reingeschaut hatte und den Deckel daneben gelegt hatte......
Meine Datenbank ist glücklicherweise in einem anderen Keller untergebracht - der RPI jetzt aber ebenfalls.

[Shadow3561]

Moin,
seit dem Update vom contrib auf V 1.51.3 habe ich folgende Meldung im log

Code Auswählen Erweitern

V_forecast - ERROR deleting file ./FHEM/FhemUtils/PVCsm_SolarForecast_PV_forecast: No such file or directoryReicht es hier einfach eine leere Datei zu erstellen oder aus das Device dies tun?
Mit freundlichen Grüßen

[softwear]

Moin zusammen,

ein Bombenprojekt, das ich seit längerem verfolge und nutze  . Herzlichen Dank, DS_Starter!
In Version 1.51.3 treten nach update und shutdown restart folgende Warnings auf (nur zur Info, sind ja unproblematisch):

Code Auswählen Erweitern

2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
2025.04.26 07:40:20 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
Macht alle weiter so! Ich bleibe dabei 

Beste Grüße
softwear

[DS_Starter]

Moin zusammen,

die Meldung Error deleting file kommt daher dass du vermutlich keine Consumer registriert hast. Das werde ich in eine Warning umwandeln mit anderem verbose Level. Muss ich mal schauen.

Die andere Warnung mit dem FW Variablen ist im nächsten Release auch gelöst, wahrscheinlich. 

Schönen sonnigen Tag!
Heiko