76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo zusammen,

in meinem contrib liegt ein Update der v2.10.6.

Manche/viele? kennen das Problem: Perl gibt intern nicht mehr benötigten Speicher (Hashes, Arrays, temporäre Strings) oft nicht direkt an das Betriebssystem zurück. Der Arbeitsspeicher des FHEM-Prozesses wächst dadurch im Laufe der Zeit kontinuierlich an (bei manchen sehr deutlich), obwohl die Daten längst verarbeitet sind. Von echten Speicherleaks mal abgesehen.

Ich habe eine regelmäßige Speicherbereinigung direkt in den Datenfluß integriert. Sobald ein Verarbeitungsdurchlauf abgeschlossen ist, fordert eine Funktion den Linux-Kernel explizit dazu auf, den ungenutzten Heap-Speicher wieder an das System freizugeben.

In meinen Tests zeigt sich eine deutliche und nachhaltige Reduktion des RAM-Footprints:

- deutlicher RAM-Rückgang: Die RAM-Belegung des Prozesses sinkt wieder auf das reale Minimum ab (siehe angehängter Plot).
  Der RAM fand ein Plateau und fiel nach Einsatz des Code sukszessive.
- stabilisierter RAM: Der Speicheranteil des FHEM Hauptprozesses reduziert sich bei mir um ca. 200 MB.
- minimaler Overhead: Die Ausführungszeit der Bereinigung liegt im Bereich von Bruchteilen einer Millisekunde und hat somit keinen spürbaren Einfluss auf die Performance.

Der Code läuft im Modul, hat aber Auswirkung auf das gesamte FHEM System.
Es ist eigentlich eine zentrale Funktionalität, die ich vielleicht in einem separaten kleinen Helper-Modul bereitstelle. Es kann allen geplagten Usern helfen ihre System zu stabilisieren. Klappt aber nur unter Linux.


Vorraussetzung:
Ihr müsst das Perl Modul FFI::Platypus in eurem System installieren. Das geht einfach mit dem FHEM Installer oder auf OS mit "apt install libffi-platypus-perl".
Danach rebooten. Wenn ihr das Modul nicht installiert passiert nichts, jedoch wird keine Speicherrückgabe durchgeführt.

Probiert es gerne mal aus.


LG,
Heiko

[DS_Starter]

[Offtopic]
Hallo zusammen,

ich habe ein kleines Modul 98_MemSaver erstellt, welches die Speicherrückgabe an das OS (Linux) organisiert und darüber hinaus ein schlankes Set an RAM/CPU-Readings bereitstellt. Die wichtigsten Kennzahlen sollten so ohne weitere Module verfügbar sein.

Das Modul liegt in meinem contrib und wird ganz einfach definiert. Hier mein Beispiel:

Code Auswählen Erweitern

defmod Saver MemSaver 300
attr Saver alias Speicherfreigabe
attr Saver devStateIcon disabled:10px-kreis-gelb active:10px-kreis-gruen
attr Saver disable 0
attr Saver icon it_memory
attr Saver room Dienste->Allgemein
attr Saver verbose 3

Online Hilfe ist auch verfügbar und sagt eigentlich alles aus.
Vorher muß das Modul FFI::Platypus installiert werden.

Bei mir hat der RAM inzwischen ein unteres Plateau erreicht und steht absolut stabil.
Mit diesem kleinen Modul sollten auch User, die das SF-Modul nicht nutzen, ihr System bezüglich des RAM-Verbrauchs optimieren können. Schwere Speicherleaks durch Programmfehler kann das Helferlein nicht beseitigen, aber in vielen Fällen sollte es nützlich sein und ich würde mich freuen wenn es den Usern hilft.

Über Rückmeldungen freue ich mich natürlich. 

LG,
Heiko
[/Offtopic]

[300P]

Kurzanleitung Linux
(Offtopic. )

Code Auswählen Erweitern

sudo apt update
sudo apt install libffi-platypus-perl

cd /opt/fhem/FHEM/
sudo wget https://svn.fhem.de/trac/export/31726/trunk/fhem/contrib/DS_Starter/98_MemSaver.pm
sudo chown fhem:dialout 98_MemSaver.pm

reload 98_MemSaver

defmod Saver MemSaver 300
attr Saver alias Speicherfreigabe
attr Saver devStateIcon disabled:10px-kreis-gelb active:10px-kreis-gruen
attr Saver disable 0
attr Saver icon it_memory
attr Saver room Dienste->Allgemein
attr Saver verbose 3
Fertig   

[300P]

Will den Faden hier zwar nicht kapern...:
Ich bekomme genau ab heute Morgen nach Update/shutdown&&restart und dem Installierungszeitpunkt alle 5 Minuten einen "....PERL WARNING: Argument "" isn't numeric in sprintf at..." als Eintrag:
(passend zu dem 300 Sekunden Intervall)

Code Auswählen Erweitern

2026.10.04 08:59:18 1: Including ./log/fhem.save
2026.10.04 08:59:20 1: PERL WARNING: Use of uninitialized value $r_unit in split at ./FHEM/98_DOIF.pm line 6027.
2026.10.04 08:59:20 1: PERL WARNING: Use of uninitialized value $r_unit in split at ./FHEM/98_DOIF.pm line 6028.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcEnd in addition (+) at ./FHEM/98_DOIF.pm line 6585.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcBegin in addition (+) at ./FHEM/98_DOIF.pm line 6585.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcEnd in numeric gt (>) at ./FHEM/98_DOIF.pm line 6586.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcBegin in numeric gt (>) at ./FHEM/98_DOIF.pm line 6586.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcBegin in sprintf at ./FHEM/98_DOIF.pm line 7032.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcEnd in sprintf at ./FHEM/98_DOIF.pm line 7032.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcBegin in sprintf at ./FHEM/98_DOIF.pm line 7050.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $arcEnd in sprintf at ./FHEM/98_DOIF.pm line 7050.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $endAngle in numeric gt (>) at ./FHEM/98_DOIF.pm line 6621.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $startAngle in numeric gt (>) at ./FHEM/98_DOIF.pm line 6621.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $angleInDegrees in subtraction (-) at ./FHEM/98_DOIF.pm line 6577.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $startAngle in subtraction (-) at ./FHEM/98_DOIF.pm line 6628.
2026.10.04 08:59:21 1: PERL WARNING: Use of uninitialized value $endAngle in subtraction (-) at ./FHEM/98_DOIF.pm line 6628.
2026.10.04 08:59:21 1: PERL WARNING: Argument "initialized" isn't numeric in numeric gt (>) at (eval 2452) line 1.
2026.10.04 08:59:21 0: Featurelevel: 6.4
2026.10.04 08:59:21 0: Server started with 462 defined entities (fhem.pl:31669/2026-09-20 perl:5.036000 os:linux user:fhem pid:14736)
2026.10.04 09:02:01 2: AttrTemplates: got 272 entries
2026.10.04 09:02:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 15231) line 1.
2026.10.04 09:02:05 2: After sleep: data requested, watch readings
2026.10.04 09:03:16 1: RMDIR: ./restoreDir/save/2026-08-31
2026.10.04 09:07:02 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 33792) line 1.
2026.10.04 09:12:00 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 50995) line 1.
2026.10.04 09:17:00 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 67631) line 1.
2026.10.04 09:22:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 86841) line 1.
2026.10.04 09:25:55 1: SMAInverter SBS25_2 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2026.10.04 09:27:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 127827) line 1.
2026.10.04 09:32:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 172261) line 1.
2026.10.04 09:37:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 217257) line 1.
2026.10.04 09:42:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 259478) line 1.
2026.10.04 09:42:56 1: SMAInverter SB25 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2026.10.04 09:47:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 274977) line 1.
2026.10.04 09:52:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 297083) line 1.
2026.10.04 09:57:01 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 316787) line 1.

Bin aber leider auf dem Sprung zu einer Familienfeier......  

[DS_Starter]

Mach mal stacktrace an damit man sieht welcher Wert bei dir Argument "" und nicht numerisch ist.
Wahrscheinlich ein Wert für eine Logausgabe.

[Parallix]

Da es ja immer mal wieder Änderungen von APIs gibt (war ja erst kürzlich der Fall), wäre es aus meiner Sicht gut, wenn im Fehlerfall automatisch ein alternativer Dienst/Server genutzt werden würde.

Das klingt zwar nach einer verführerischen Idee, hat aber entscheidende Nachteile bzw. bedenkenswerte Fakten:
...

Unter Berücksichtigung dieser Punkte und der Belastung meiner Freizeit bzw. meines Zeitfonds kommt es nicht auf die Agenda. Da steht bereits einiges drauf. 

Kann ich total verstehen!

Wäre denn eine Parallelbetrieb zweier APIs denkbar:

• API 1 liefert eine örtlich und zeitlich gut aufgelöste Prognose für die die nächsten 48h
• API 2 liefert eine eine Prognose für den Zeitraum nach dem Prognosehorizont von API 1.
  Dadurch könnte man verschiedene Maßnahmen, wie z.B. um mehr als 48h verschiebbare Aufladevorgänge eines BEV planen und (perspektivisch) auch die Bestimmung des neuen Battery_OptimumBaseSoC_XX in SF nochmals verbessern.

[DS_Starter]

Wäre denn eine Parallelbetrieb zweier APIs denkbar:

    API 1 liefert eine örtlich und zeitlich gut aufgelöste Prognose für die die nächsten 48h
    API 2 liefert eine eine Prognose für den Zeitraum nach dem Prognosehorizont von API 1. Dadurch könnte man Szenarien wie z.B. mehr als 48h verschiebbare Aufladevorgänge eines BEV, aber auch die Bestimmung des neuen Battery_OptimumBaseSoC_XX in SF besser vornehmen.

Das müsste man etwas präzisieren. Denn im Prinzip gibt es das schon mit der API OpenMeteoDWD-API (ohne D2) wie in #7092 geschrieben.
Bei Benutzung des DWD_OpenData Device rechnen wir die Prognose selbst aus. D.h. die Prognoseauflösung wird automatisch herabgesetzt in Abhängigkeit der von DWD gelieferten Daten.
Was ich damit sagen will ... solche Zusammenhänge gibt es schon und der Modulnutzer bekommt bei der Wahl der entsprechenden API diese Abstufung "frei Haus" geliefert.

Ansonsten ist ein Mischbetrieb verschiedener API's im selben Device sehr komplex und schwierig umzusetzen. Ich weiß es weil ich dieses Konstrukt bereits mit der Wetter-API durch habe.
Wenn man sowas machen möchte, würde man zwei SF-Devices definieren. Jeweils mit den relevanten API's.
Dann würde man noch die Architektur eines SF-Mergerdevices benötigen, also einen Betriebsmodus einer speziellen SF-Device Definition (ein drittes Device im Verbund), welches als Datenkonzentrator funktioniert und die Daten der anderen "Clients" sammelt und zu einem Gesamtbild zusammenfügt.
Eine solche Architektur wäre sauber und auch supportbar weil Fehler immer nachvollziebar sind wo sie auftreten.
Es muß "nur" gemacht werden.