Hi, nachdem DbLog bei mir recht regelmäßig und verständlicherweise beim nächtlichen Neustart aller VMs cache-Files anlegt, würde ich gerne den Import von Cachefiles automatisieren.
Ein "importAllCachfiles" oder so gibt es nicht, also muss ich mir selbst was basteln. Und da die vorhandenen Cache-Files im WebUI angegeben werden, nicht aber in Readings stehen und ich beim Googeln aber nichts finden konnte, wollte ich mal fragen: Kann ich in Perl die vorhandenen Logfiles irgendwie aus dem DbLog-Modul auslesen? Oder sollte ich mir die Liste besser selbst im Filesystem zusammensuchen?
Danke, Christian
Hallo Christian,
momentan gibt es keine Möglichkeit die Files aus DbLog auszulesen.
Ich könnte aber einen "get ... cacheFileNames" einbauen der eine Liste der vorhandenen und noch nicht importierten Cachefiles zurückliefert.
Damit könnte man sich leicht einen Importer bauen.
Würde dir das helfen?
LG,
Heiko
Kein Problem. Ich lese dann das Filesystem aus.
Falls jemals jemand dasselbe Problem haben sollte und diesen Thread hier findet:
sub readCacheFilesIntoDB () {
my @CacheFiles = glob('/opt/fhem/log/cache_DBLog_*');
if (@CacheFiles) {
fhem('set DBLog importCachefile '.basename($CacheFiles[0]));
fhem("define at_readDbLogCachefile_$NbrCacheFiles at +00:00:05 { readCacheFilesIntoDB() }") if (@CacheFiles > 1);
}
}
Habe gemerkt, dass ich, obwohl die SQL-DB auf schnellen SSDs liegt, zwischen den einzelnen Versuchen etwas Zeit lassen muss. Daher über at anstatt einfach über eine foreach-Schleife.
Gruß, Christian
Das kommt durch die asynchrone Arbeitsweise.
Alternativ zum "at" kannst du dir auch ein Notify anlegen und auf den Event:
state importCachefile finished .* datasets were imported
des DbLog reagieren um den nächsten Import zu starten.
Das wäre IMHO sauberer weil dadurch das Ende des vorherigen Laufs sichergestellt ist.
warum ist es überhaupt nötig Cachefiles zu verbuchen? DBLog schreibt doch beim sauberen Runterfahren alles auf die DB. Ich würde eher die Reihenfolge des Shutdowns anpassen anstatt irgend welche Scripte zu basteln. Oder Fhem ein bisschen mehr Zeit zum Runterfahren gönnen. Und erst wenn Fhem weg ist MySQL oder welche DB du hast stoppen.
in global kannst du shutdown verzögern falls nötig
maxShutdownDelay
Einige Module benötigen Zeit zum Aufräumen beim shutdown, aber FHEM begrenzt diese Zeit auf 10 Sekunden. Mit diesem Attribut kann man sie anpassen.
Keine Ahnung, irgendeine Race-Condition vielleicht. An den meisten Tagen klappt es, aber manchmal leider nicht, wenn ich aus den Cache-Files auf ein Problem beim Runterfahren schließen kann. (Im FHEM-Log steht nichts...)
Zitat von: Motivierte linke Hände am 18 Februar 2024, 20:18:50Keine Ahnung, irgendeine Race-Condition vielleicht. An den meisten Tagen klappt es, aber manchmal leider nicht, wenn ich aus den Cache-Files auf ein Problem beim Runterfahren schließen kann. (Im FHEM-Log steht nichts...)
ich kenn dein Setup nicht. Ich könnte mir vorstellen, wie geschrieben, dass deine Datenbank vor fhem beendet wird. Oder dass dein Hypervisor (Tool für die VM) die VM nicht richtig runterfahren lässt, sondern vorzeitig hart abschaltet. Welches Setup nutzt du? VM auf ESXi, Proxmox, ... Datenbank und Fhem in selber VM? Nativ auf in einer VM oder noch per Docker oder anders geteilt?