Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

ioT4db · 08 Januar 2018, 22:46:25

habs nochmal hier angesprochen: https://forum.fhem.de/index.php/topic,65027.msg745149.html, da das andere Thema wohl geschlossen ist...

DS_Starter · 10 Januar 2018, 23:22:56

Hallo zusammen,

im ersten Beitrag gibt es die weiterentwickelte V7.4.0.

Weil ich in letzter Zeit immer häufiger darüber gestolpert bin dass SQLite-User kein oder nur altes/unbrauchbares Backup haben, ist nun hier eine Backup/Restore-Funktion eingebaut die über die SQLite Online API es ermöglicht im laufenden Betrieb konsistente Backups zu fahren.
Jetzt sollte jeder ein aktuelles Backup anfertigen können

Was ist neu ?

* Kommandos dumpSQLite/restoreSQLite zum Online-Backup / Restore von SQLite-Datenbanken

* backup/restore (MySQL/SQLite), optimizeTables, vacuum,restoreMySQL, restoreSQLite ist jetzt verfügbar auch wenn im DbLog-Device ein "reopen xxxx" läuft

* vor und nach den Backup/Restore-Kommandos sowie optimizeTables, vacuum kann jetzt ein FHEM-Kommando bzw. Perl-Code {} ausgeführt werden. Bisher war dies nur bei dumpMySQL implementiert.

ACHTUNG: Um die Attribute executeBeforeDump & executeAfterDump allgemein gültig zu machen, wurden die Attribute umbenannt nach executeBeforeProc & executeAfterProc.

Dadurch ist es nun möglich z.B. vor einem restoreMySQL/restoreSQLite das zugehörige DbLog von der DB zu trennen bzw. nichts zu loggen und nach dem Restore wieder zu verbinden. Das ist auch nach einem Timeout o.ä. in der AbortFn implementiert.

Dazu ganz einfach die Attribute setzen z.B.:

Code Auswählen

attr <Rep> executeBeforeProc set LogDB1 reopen 3600
attr <Rep> executeAfterProc set LogDB1 reopen

Die auflaufenden Evnts werden im DbLog asynchronen Mode in dieser Zeit im Cache gehalten und nach Abschluss der Operation nachgefahren.
Das ist auch für ein Vacuum oder optimizeTables günstig.

Wenn ich Zeit habe erstelle ich mal einen Wikibeitrag mit Beispielen zu Backup/Restore.

LG,
Heiko

supergrobi · 11 Januar 2018, 09:59:23

Hallo Heiko.

Ich hätte da noch einen Wunsch:

Ich habe in versch. Zimmern PIR Sensoren. Die melden bei Bewegung on/off. Wenn sich jetzt jemand oft bewegt kommt halt auch oft die Meldung. Aber manchmal reicht auch schon ein Luftzug oder die Heizung um viele aufeinanderfolgende Meldungen zu erzeugen. Könntest du hier vielleicht auch in dem selSeqDoublets eine Funktion anbauen, mit der man oft wiederkehrende Folgen einfach löschen kann? Also wenn z.B. ab 19:30:10 das erste mal die Meldung "on" auftaucht, 19:30:11 "off" und dann jede Sekunde (die Zeit der Abstände bis zum Neuen Ereignis vielleicht einstellbar) erneut on/off usw. bis z.B. 20:00:00 ein "off" mit längerer Pause auftaucht...
Das erste "on" und das letzte "off" sollten stehen bleiben und dazwischen die oft wiederkehrenden ereignisse sollten gelöscht werden. So weis ich das in der Zeit Bewegung stattgefunden hat.

lg
Thomas

DS_Starter · 11 Januar 2018, 18:56:47

Hallo Thomas,

ich habe jetzt eine Weile auf dein Anliegen geschaut und gegrübelt ob und wie ich so etwas umsetzen könnte ohne dass die Komplexität ins uferlose steigt, die bisherige Funktionalität erhalten bleibt und das Ganze noch durch mich oder den User beherrschbar ist

Also ich muß da passen. Vielleicht gibt es jemanden der mir dafür einen Patch für die selSeqDoublets -funktion liefern kann ?

Was aber vorstellbar wäre, ist die userExitFn zu nutzen und ein Script für die 99_MyUtils zu erstellen, welches für genau deinen Anwendungsfall gebaut ist. Ohne genau darüber nachgedacht wie man das machen könnte, wäre so etwas nur sinnvoll, wenn du danach in der Lage wärst mit eigenem Perl Know-How Änderungen in dem Script vorzunehmen, um es an deine Belange anpassen und abändern zu können.

Wie ist deine Meinung dazu ?

LG,
Heiko

supergrobi · 12 Januar 2018, 08:04:53

Hallo Heiko,

es war nur ein wunsch

scheinbar bin ich auch der einzige mit diesem Wunsch. Das dafür der Aufwand zu groß ist, kann ich verstehen und bin dir deswegen auch nicht böse. Du hast mir ja schon sehr mit dem löschen der aufeinanderfolgenden Werte geholfen. Hier bin ich auch sehr dankbar.

Leider sind meine Kenntnisse in Perl und SQL noch nicht so weit fortgeschritten das ich es selbst machen könnte. Aber es wird täglich mehr. Die 99_MyUtils kenne ich, aber die userExitFn noch nicht. Ich werde mich hierzu im Wiki mal einlesen.

gruß
Thomas

DS_Starter · 12 Januar 2018, 08:25:43

Hallo Thomas,

also ich bleibe da dran und vielleicht ist es auch eine schöne Aufgabe für dich zur übung im Umgang mit Perl und der myUtils. Wenn am Ende noch etwas dabei rauskommt, können wir ja auch einen Wikibeitrag erstellen zur Nachnutzung.

Vielleicht ist dann ja sogar mehr Leuten geholfen wenn sie wissen wie eigene Anpassungen umgesetzt werden können.
Mal schauen wie ich Zeit finde und dazu komme.

LG,
Heiko

pechnase · 17 Januar 2018, 17:13:28

Hallo DS_Starter,

zunächst herzlichen Dank für die Entwicklung und die Pflege des DbRep-Moduls. Ich bin dabei meine FHEM Installation auf DbLog umzustellen und verwende dazu eine SQLite DB. FHEM und Db laufen auf einem Raspberry PI eigentlich schon seit Jahren zuverlässig.
Ich verwende den Include Mode und logge ca. 40 Einträge pro Minute in der Db.

Ein Backup der Db mache ich jetzt mit den neuen Möglichkeiten des Moduls mit SQLiteDump und den entsprechend konfigurierten Attributen. Über die Attribute executeBeforeProc und executeAfterProc verschicke ich jeweils zu Beginn und am Ende des Backups eine E-Mail, wie ich es auch an anderen Stellen in FHEM mache. Das funktioniert im Prinzip auch, nur bekomme ich den Inhalt des Readings background_processing_time nicht in der E-Mail angezeigt. Ich verwende folgenden Perl Einzeiler:

Code Auswählen

{ my $duration = ReadingsVal("BackupDb","background_processing_time"," ");; exmail('test1@meinedomain.de','Backup DB Ende','Backup DB wurde nach ' .$duration. ' sec. beendet') }

Wenn ich genau diesen Einzeiler mit c&p z.B. in ein notify oder at einsetze, funktioniert alles wie erwartet.

Woran könnte das liegen?

Getriggert wird das Backup über ein at-Device in der Nacht.

FHEH auf aktuellem Stand/Update, Raspberry Pi, Raspbian Stretch

Viele Grüße
Wolfgang

DS_Starter · 17 Januar 2018, 21:20:25

Hallo Wolfgang,

freut mich dass du dein Backup mit der (relativ neuen) SQLiteDump-Funktion erfolgreich erstellen kannst.
Dei Problem liegt daran, dass ich ungünstigerweise die Readingerstellung für "background_processing_time" nach der Ausführung von "executeAfterProc " programmiert hatte.
Mit der Version 7.5.1 im ersten Beitrag habe ich das geändert.
Probiere mal ob es damit nun so klappt wie du es möchtest.

Nicht wundern, die Version enthält neue Funktionalitäten für Summen-, Differenz- , Maximum- , Minimum- und Durchschnittswertberechnungen die du mit "help dbrep" erläutert bekommst. Ich schreibe aber noch etwas extra dazu.

LG,
Heiko

pechnase · 18 Januar 2018, 22:29:23

Hallo Heiko,
herzlichen Dank für die schnelle Reaktion und die Bereitstellung der Version 7.5.1. Ich habe die neue Version installiert und FHEM neu gestartet.
Was ich bis jetzt beobachten konnte, scheint die Verarbeitung von background_processing_time jetzt richtig zu funktionieren.

Nochmals vielen Dank.

Viele Grüße
Wolfgang

DS_Starter · 18 Januar 2018, 22:55:23

Guten Abend miteinander,

wie versprochen hier noch ein paar Erläuterungen zur neuen Version 7.5.1 (im Eingangsbeitrag nochmal geändert!).

Die Version enthält die Möglichkeit bei den Summen-, Differenz- , Maximum- , Minimum- und Durchschnittswertberechnungen diese Ergebnisse wieder in der Datenbank zu speichern. Dazu werden keine Events erstellt oder benötigt.
Dazu gibt es neu zwei Aufrufoptionen display und writeToDB. "display" ist gleichbedeutend ohne Aufrufoption, was weiterhin aus Kompatibilitätsgründen funktioniert.

Hier stellvertretend ein Auszug aus Commandref für die maxValue Funktion:

* maxValue [display | writeToDB]

berechnet den Maximalwert eines Readingwertes (DB-Spalte "VALUE") in den Zeitgrenzen (Attribute) "timestamp_begin", "timestamp_end" bzw. "timeDiffToNow / timeOlderThan". Es muss das auszuwertende Reading über das Attribut "reading" angegeben sein. Die Auswertung enthält den Zeitstempel des ermittelten Maximumwertes innerhalb der Aggregation bzw. Zeitgrenzen. Im Reading wird der Zeitstempel des letzten Auftretens vom Maximalwert ausgegeben falls dieser Wert im Intervall mehrfach erreicht wird.
Ist keine oder die Option "display" angegeben werden die Ergebnisse nur angezeigt. Mit der Option "writeToDB" werden die Berechnungsergebnisse mit einem neuen Readingnamen in der Datenbank gespeichert.
Der neue Readingnamen wird aus einem Präfix und dem originalen Readingnamen gebildet. Der Präfix setzt sich aus der Bildungsfunktion und der Aggregation zusammen.
Der Timestamp der neuen Readings in der Datenbank wird von der eingestellten Aggregationsperiode abgeleitet, sofern kein eindeutiger Zeitpunkt des Ergebnisses bestimmt werden kann. Das Feld "EVENT" wird mit "calculated" gefüllt.

Beispiel neuer Readingname gebildet aus dem Originalreading "totalpac":
max_day_totalpac
# <Bildungsfunktion>_<Aggregation>_<Originalreading>

Im Wiki gibt es noch ein Anwendungsbeispiel: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Speichern_von_Berechnungswerten_in_der_Datenbank_und_Erstellen_eines_Plots_.28ab_Version_7.5.1.29

LG,
Heiko

knxler · 23 Januar 2018, 08:49:05

Hallo Heiko,

erst einmal vielen Dank für den tolles Reporting Tool. Ich nutze es und bin begeistert davon.
Ich glaube deine Mittelwert Berechnung ist nicht ganz richtig. Ich logge die Tagesaußentemperaturen und möchte einen Tagesmittelwert bilden. Wenn ich nun deine Funktion aufrufe erhalte ich natürlich einen Mittelwert. Wenn ich nun die doppelten Einträge aus der Datenbank lösche, erwarte ich natürlich das der Mittelwert identisch ist dem vorherigen. Dies ist leider nicht der Fall. Mir ist jetzt nicht klar ob das Rundungsfehler sind, oder ob dein Berechnungsverfahren daran schuld ist. Berücksichtigst du die unterschiedlichen Zeitabstände die entstehen, wenn die Doppelten Datensätze gelöscht werden?

Gruß Martin

DS_Starter · 23 Januar 2018, 09:17:25

Gute Morgen Martin,

ZitatIch glaube deine Mittelwert Berechnung ist nicht ganz richtig.

Naja, die averageValue Funktion basiert in diesem Fall auf der Datenbank eigenen AVG-Funktion. Das heißt der Ergebniswert wird nicht durch mich (das Modul) berechnet, sondern durch die Datenbank ermittelt und geliefert. Ich glaube nicht, dass diese Funktion fehlerhaft arbeitet.

Allerdings ist das noch keine Erklärung für deine Beobachtung. Muss mir das mal durchdenken oder ein Beispiel durchspielen.

Man muss aber bedenken, dass es bei delSqDoublets zwar gleiche aufeinander folgende Sätze gelöscht werden, aber immer der erste und letzte Wert einer Aggregationsperiode erhalten bleibt (das ist/war so gewollt). Daraus können sich leichte Änderungen im AVG ergeben. Vielleicht muss ich mir die Logik an den Grenzen der Aggregationsperiode nochmal vornehmen.
Ich weiß jetzt nicht von welchen Größenordnungen du sprichst. Kannst du mal ein Beispiel geben ?

LG,
Heiko

JoeALLb · 23 Januar 2018, 09:33:05

Grüß euch,

ist es nicht so, dass AVG die Anzahl der Vorkommen mittelt, den zeitlichen Abstand jedoch ignoriert?
Von daher wäre es logisch, dass die Kurve im Plott anders aussieht als die per AVG gemittelte.

Siehe dazu den Screenshot im Excel:

DS_Starter · 23 Januar 2018, 09:57:13

Hi Joe,

du hast recht. Abgesehen davon erscheint es auch logisch wenn das mehrfache Auftreten eines gleichen Wertes (die 10 in deinem Besipiel) den Durchschnitt einer Periode anders beeinflusst als wenn dieser Wert nur 2 mal in dieser Periode auftritt.
Insofern wäre der Durchschnittswert von Temperaturen eines Tages nur aussagefähig, wenn diese Temperaturen in gleichen und kurzen Zeitabständen gemessen werden. Im Extremfall (nur theoretisch) fängt der Tag mit 15 Grad an und fällt dann sofort auf 5 Grad, bleibt den ganzen Tag so und steigt am Ende wieder auf 15 Grad. Löscht man alles raus außer die Wechsel am Anfang/Ende kommt ein Durchschnitt von 10 heraus (15+5+5+15/4). Wenn man nur 2 x 5 Grad-Werte mehr stehen lästt, werden daraus 7,5 Grad usw.

In dem Zusammenhang erscheint mir das Löschen von Datensätzen kontraproduktiv und man sollte es dann wohl besser nicht tun.

Thyraz · 23 Januar 2018, 10:23:47

Das ist ja aber allgemein ein Problem beim Berechnen von Durchschnittstemperaturen.
Dazu braucht man noch gar nicht mit DBRep auszudünnen um das zu bemerken.

Auch wenn man z.B. einen Sensor hat der nicht in festem Zeitraster sendet (sondern z.B. bei einem bestimmten Temperaturdelta) oder Event-On-Change-Reading aktiviert,
ist das Zeitraster zwischen den Messwerten ja nicht immer gleich.

Die Gewichtung der DB-Einträge bei einer Mittelwertberechnung entspricht also nicht dem was wir uns wünschen.

Ich mache das für meine Tagesdurchschnittsauswertung so, dass ich einen aktuellen Wert für jede volle Stunde von 0 bis 23 Uhr bestimme (https://de.wikipedia.org/wiki/Tagesmitteltemperatur).
Dazu gibt es natürlich keine genauen Treffer in der DB, sondern man muss immer nach dem letzten geloggten Wert VOR der vollen Stunde suchen.
Dieser ist ja der Wert, der zu dem Zeitpunkt der nächsten vollen Stunde noch gültig ist (sonst hätte es einen weiteren DB-Eintrag danach gegeben).
Wenn die Temperatur sich über mehrere Stunden nicht verändert haben sollte, dann kann der selbe Logeintrag für mehrere Stunden gelten.

Über diese 24 Werte bilde ich dann den Mittelwert.

Und ja, die Kurven weichen zu meiner früher verwendeten Mittelwertberechnung (habe da auch einfach alle Werte in der DB addiert und daraus den Mittelwert gebildet) durchaus ab.