93_DbLog - Umstellung Log-Funktion auf non-blocking

[stromer-12]

Ich hatte gestern einen Rechnerausfall.
DbLog eines entfernten FHEM hatte knapp 28Stunden die Daten gepuffert und nach Datenbankserver Neustart sauber weggeschrieben.

[DS_Starter]

Ich hatte gestern einen Rechnerausfall.
DbLog eines entfernten FHEM hatte knapp 28Stunden die Daten gepuffert und nach Datenbankserver Neustart sauber weggeschrieben.

Wow, das war ja dann ein echter Härtetest.
Hast du noch mitbekommen wieviele Datensätze gepuffert wurden und wie lange dann das wegschreiben gedauert hat ?
Wäre einfach mal interessant.

@Tedious ... anbei habe ich eine V2.10.7 angehängt. Teste mal bitte ob im synchronen Modus dein Problem nun erledigt ist.

Grüße
Heiko

[DS_Starter]

Hallo Christian,

Geräte bei denen ein reduceLog bzw. eine deleteOldDays nicht greift
readings bei denen ein reduceLog bzw. eine deleteOldDays nicht greift

Zumindest für reducelog kannst du Device/Reading-Kombinationen schon jetzt von der Behandlung ausschließen. Dafür gibt es den Zusatz "EXCLUDE= "

Auszug aus der Commandref:

......
Optional kann als letzer Parameter "EXCLUDE=deviceRegExp1:ReadingRegExp1,deviceRegExp2:ReadingRegExp2,...." angegeben werden um device/reading Kombinationen von reduceLog auszuschließen.
...

Vielleicht kann man einen ähnlichen Zusatz für "deleteOldDays " einbauen.
Attribute würde ich auch nicht dafür vorsehen, da gebe ich Benny bzw. Joe recht.
Mal schauen.

Grüße
Heiko

[stromer-12]

Hast du noch mitbekommen wieviele Datensätze gepuffert wurden und wie lange dann das wegschreiben gedauert hat ?
Wäre einfach mal interessant.

Es war ein kleines FHEM auf einen Pi1 was nur 5 Temperatur/Luftfeuchtesensoren protokolliert und über das Internet zum Server schickt.
Es waren 5855 Events.

[Benni]

Es waren 5855 Events.

Hallo zusammen,

das bringt einen doch gleich auf die Idee, dass man hier ggf. eine Obergrenze festlegen können sollte zu der dann ein gewisses Kontingent an alten Daten im Puffer verworfen wird. Eventuell wäre auch noch ein entsprechender event zu dem Zeitpunkt nützlich.

Gruß Benni

[DS_Starter]

Morgen Benni,

das bringt einen doch gleich auf die Idee, dass man hier ggf. eine Obergrenze festlegen können sollte zu der dann ein gewisses Kontingent an alten Daten im Puffer verworfen wird. Eventuell wäre auch noch ein entsprechender event zu dem Zeitpunkt nützlich.

Diesbezüglich hatte ich mir vorgestellt, dass man optional eine filebasierende DB angeben kann, in die während der Datenbank-Abwesenheit die Daten geschrieben werden. Aus dieser werden die Daten in die richtige DB übernommen wenn sie wieder verfügbar ist und in der File-DB gelöscht.
Das hätte auch den Vorteil dass sie nicht verloren gehen falls FHEM mal abstürzt (oder nur wenige). Evtl. kann man es auch mit deinem Vorschlag kombinieren, dass nur Daten ab einer bestimmten Obergrenze (Anzahl) in diese File-DB geschrieben werde.
Bei stromer-12 hat das Ganze ja super geklappt, wenn aber sein remotes FHEM abgestürzt wäre, wären natürlich auch die gepufferten Daten weg gewesen.
Mal sehen wann ich dazu komme das mal auszuarbeiten ...

Grüße
Heiko

[JoeALLb]

Vielleicht kann man einen ähnlichen Zusatz für "deleteOldDays " einbauen.
Attribute würde ich auch nicht dafür vorsehen, da gebe ich Benny bzw. Joe recht.

Rückfrage dazu: gehen bei einem defmod nicht sämtliche Caches verloren?
Vielleicht wäre es in solch einem Fall doch besser, das über attribute zu handeln und nicht über die Definitionszeile.
Damit könnte man das ergänzen ohne Nebeneffekte bezüglich verlust eines Caches, etc.

[DS_Starter]

Morgen Joe,

Rückfrage dazu: gehen bei einem defmod nicht sämtliche Caches verloren?

defmod ?  ... ich steh jetzt etwas auf dem Schlauch. Hilf mir mal zu verstehen wie du das in dem Zusammenhang meinst.

[JoeALLb]

... Wenn man ein definiertes Device "umdefiniert".

Klick als Beispiel mal bei einem Device unten auf den Link "Raw definition" in der Webansicht.

[DS_Starter]

Achso ... nein, es handelt sich ja hier um den set-Befehl "set .... deleteOldDays <n>" der sich dann zu einem  "set .... deleteOldDays <n> EXCLUDE=..." erweitern würde. Also keine Umdefinition o.ä.
Ich bräuchte nur ein geschicktes SQL-Statement welches bestimmte Werte der Felder Device/Reading von vornherein beim delete excludiert. Dann wäre es einfach zu realisieren.

[JoeALLb]

Also soetwas wie

Code Auswählen Erweitern

delete from history where concat(device,":",reading) not in ("wz.Temp:measured-temp","wz.Temp:humidity")
geht schon! Nicht sonderlich performant aber es geht! Vielleicht habe ich dazu nochmal eine bessere Idee/Lösung?

Nachtrag: gerade getestet in DB mit 24Mio Datensätzen: 16,2 Sekunden Laufzeit, also nicht "extrem" langsam.

[pc1246]

Hallo Christoph,
Wenn Du etwas "experimentierfreudig" bist und auch mal kurz ohne Plots in FHEM leben kannst, habe ich schon Ideen, wie das ganze bei Dir besser laufen kann! Wenn Du also lust hast, schreibe ich Dir ein paar Schritte zusammen die du testen kannst! Keine Sorge, Daten gehen dabei nicht verloren, du brauchst dazu auch keinen zweiten Rechner.
Auf welcher Hardware läuft das ganze denn bei Dir? Selbst auf einem schwachen RPI funktioniert das in der Regel tadellos!

schöne Grüße
Joe

Hallo Joe
Ich komme gerne auf Dein Angebot zurueck! Heute abend habe ich sturmfreie Bude, da koennte ich das mit deiner Hilfe angehen!
Gruss Christoph

[JoeALLb]

Hallo Christoph,

gerne! Die Anleitung im älteren Thread sollte soweit ok sein damit du loslegen kannst. Das Umkopieren der Daten wird schon eine weile dauern!
Ich bin zwar im Ausland unterwegs, schau aber immer mal wieder ins Forum und kann auf Fragen antworten.

Ich komme gerne auf Dein Angebot zurueck! Heute abend habe ich sturmfreie Bude, da koennte ich das mit deiner Hilfe angehen!

Grüße Joe

[pc1246]

Hallo Christoph,

gerne! Die Anleitung im älteren Thread sollte soweit ok sein damit du loslegen kannst.

? ? ? 

[JoeALLb]

? ? ? 

Ok, #448 https://forum.fhem.de/index.php/topic,62998.msg568302.html#msg568302
war nicht nur an Daniel gerichtet, sondern auch als Idee für Dich!
Es ist ein Versuch, aber ich denke dass dies besser funktionieren wird.
Schau es Dir doch einfach mal an.