fhem.cfg verschwindet

[passibe]

Mach mal eine google-Suche mit site:fhem.de Memory Leak, da dürftest du ein paar Threads mit verschiedenen Strategien finden. Ich glaube aber, dass es keine zuverlässigere Methode gibt, als Module eins nach dem anderen zu deaktivieren.

Natürlich vorher auch mal einen Blick in den Event Monitor werfen, usw. Vielleicht ist da ja schon etwas erkennbar.

[Beta-User]

Wenn du DbLog im Verdacht hast: Konfiguration ist OK?
(Man kann das automatisiert checken lassen).

[Hardy74]

Man kann das automatisiert checken lassen

Wie? (Um mir googeln zu ersparen  )

An der Defaultkonfig von dblog habe ich nur geändert, dass nur die Readings geloggt werden sollen, die in den jeweiligen Devices explizit dazu eingebunden sind.

[Beta-User]

Man kann das automatisiert checken lassen

Wie? (Um mir googeln zu ersparen  )

An der Defaultkonfig von dblog habe ich nur geändert, dass nur die Readings geloggt werden sollen, die in den jeweiligen Devices explizit dazu eingebunden sind.

RTFM zu DbLog. Nix Suchmaschine. Doku!

[betateilchen]

Man kann das automatisiert checken lassen

Wie? (Um mir googeln zu ersparen

Auch wenn Du offenbar den Unterschied zwischen "jemanden um Hilfe bitten, weil man etwas nicht weiß/versteht" und "jemanden ausnutzen, indem man aus Bequemlichkeit alles vorgekaut haben möchte" nicht kennst, hier zwei Stichworte, die Dir weiterhelfen könnten:

• commandref zu DbLog: https://commandref.fhem.de/#DbLog
• dort insbesondere die Beschreibung zum Befehl: get <name> configCheck

Viel Spaß beim Lesen & viel Erfolg.

[Hardy74]

indem man aus Bequemlichkeit alles vorgekaut haben möchte

In dem Fall tatsächlich erwischt.

Wenn ich so darüber nachdenke, habe ich allerdings auch keinen Mehrwert davon, den Übeltäter zu identifizieren. Warum? Das eine sind Zeitgründe, primär aber schlicht Unkenntnis von Perl. Ich bin bei C++ zu Hause, was hier nicht hilft. Im besten Fall könnte ich hier posten, dass es wohl Modul xyz ist, müßte dann aber hoffen, dass irgendjemand, des Perl mächtiger, das dann irgendwann fixt.

Der Workaround des täglichen Restarts hilft in diesem Fall, WENN es denn nicht neuerdings das Problem gäbe, dass die fhem.cfg bei 2 von 3 Neustarts verschwindet und fhem damit alleine natürlich nicht mehr auf die Beine kommt. Da schließt sich dann auch der Kreis zum initialen Grund dieses Threads. Das Memoryleak fiel in diesem Kontext nur mit auf.

[Beta-User]

Es wird aber schon in die DB geschrieben, oder?
Den configCheck zu machen schadet jedenfalls nicht ..

[Icinger]

DBLog und MQTT2 kann ich ausschließen. Mein FHEM läuft seit Jahren stabil (erst auch nem Pi, seit 1.5 Jahren auf nem Docker in Proxmox)

HUE hab ich nix.

Am einfachsten ist es, erstmal alle verdächtigen Module zu disablen und dann Stück für Stück wieder ins Leben zu rufen.

[Beta-User]

DBLog und MQTT2 kann ich ausschließen. Mein FHEM läuft seit Jahren stabil (erst auch nem Pi, seit 1.5 Jahren auf nem Docker in Proxmox)

HUE hab ich nix.

Am einfachsten ist es, erstmal alle verdächtigen Module zu disablen und dann Stück für Stück wieder ins Leben zu rufen.

Habe ich beides auch im Einsatz... HUE.* auch lange, war unproblematisch.

DbLog kann für Probleme sorgen, wenn es die gepufferten Daten nicht wegschreiben kann...

[Hardy74]

Es wird aber schon in die DB geschrieben, oder?
Den configCheck zu machen schadet jedenfalls nicht ..

Die gewünschten Daten werden anstandslos geloggt. Der Check lieferte u.A plotfork solle in den FHEMWEB auf 1 gesetzt werden. Da es mit fork offenbar Probleme geben kann, wie in anderen Posts zitiert, habe ich das gemacht, ebenso ein fhem update ausgeführt. Weiter werden Zeichensätze angemerkt, wobei hier meine Erwartungshaltung wäre, da automatisch generiert, dass dies auch passt. Das habe ich nicht geändert.

Code Auswählen Erweitern

Character Set used by Client (connection): UTF8MB3
Collation used by Client (connection): UTF8MB3_BIN
Character Set used by DB fhem: UTF8MB3
Collation used by DB fhem: UTF8MB3_BIN
Da ich tatsächlich auch, in Zusammenhang mit dem dblog, erstmalig mit SVG Plots rumgespielt habe, könnte das ggf. schon geholfen habe. Ich werde das beobachten. Was es aber nicht erklärt, den initialen Grund dieses Posts: das Verschwinden der fhem.cfg

Good news: diverse Neustarts heute, auch hart durch Reboot des Raspis, hat die fhem.cfg überstanden.