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

MarcusR · 24 Januar 2020, 00:38:56

Hallo DS_Starter,

nach Deinem Tip in https://forum.fhem.de/index.php/topic,92458.msg849985.html#msg849985 habe ich mir eine Backup-Lösung mit syncStandby aufgesetzt. Ich hatte die Funktion der Methode so verstanden, dass sie im konfigurierten Umfang und Fragmenten eine Datenbank zu einer anderen abgleicht und bereits kopierte Zeilen nicht ein zweites Mal kopiert. Vulgo 1-Wege-Sync. Ich meine auch, das hinreichend ausprobiert zu haben. Jetzt habe ich aber festgestellt, dass er jedes Mal, wenn ich die Methode aufrufe, die gleichen Zeilen wieder und wieder in die Zieldatenbank schreibt.

Hier meine beiden dbRep-Devices zum syncen:

Code Auswählen


define logdb.sync_daily DbRep logdb
setuuid logdb.sync_daily 5cfe4b71-f33f-c353-3373-1ae195c977a4b689
attr logdb.sync_daily aggregation day
attr logdb.sync_daily group Log
attr logdb.sync_daily room Technik
attr logdb.sync_daily timeDiffToNow d:2

define logdb.sync_weekly DbRep logdb
setuuid logdb.sync_weekly 5cfe4b71-f33f-c353-6026-7e7569a0d087caff
attr logdb.sync_weekly aggregation day
attr logdb.sync_weekly group Log
attr logdb.sync_weekly room Technik
attr logdb.sync_weekly timeDiffToNow d:10

define logdb.sync.timer at *00:15:00 {\
    if(  # Immer Montags\
		($wday == 1)\
	  ) \
	{\
        Log (1,"logdb.sync.timer: wday: ".$wday.", Wochen-Sync wird durchgeführt.");;\
		fhem("set logdb.sync_weekly syncStandby archivedb");;\
	} else {\
		Log (1,"logdb.sync.timer: Tages-Sync wird durchgeführt.");;\
		fhem("set logdb.sync_daily syncStandby archivedb");;\
	};;\
\
	}
setuuid logdb.sync.timer 5cfe4b71-f33f-c353-7d83-4d282dae45c78845

Ein at-Device entscheidet dann einmal am Tag, ob der Tages- oder der Wochen-Sync aufgerufen wird.

Habe ich nun die Methode falsch verstanden (und auch mal falsch getestet) oder hat sich mit einem Update was an der Funktionalität geändert?

Viele Grüße
Marcus

DS_Starter · 24 Januar 2020, 08:59:17

Guten Morgen Marcus,

das hast du nicht ganz richtig interpretiert.

ZitatIch hatte die Funktion der Methode so verstanden, dass sie im konfigurierten Umfang und Fragmenten eine Datenbank zu einer anderen abgleicht und bereits kopierte Zeilen nicht ein zweites Mal kopiert.

Nein, es werden die Datensätze , die durch die Zeit- ,Reading- ,Device- und auch valueFilter aus der Quelldatenbank in die Standby-Datenbank übertragen. Das passiert bei jedem Lauf.

Der Nutzer muss also selbst darauf achten nichts doppelt zu schreiben. Aber das ist reativ einfach.
Eine nicht ganz so elegante Methode ist, das at immer auf den Beginn eines Tages also 00:00:00 zu setzen und im DbRep Device timeDiffToNow d:1 zu setzen. Das würde ein doppeltes Schreiben verhindern.

Aber diese Methode hat Nachteile, weil diese Nahtlosigkeit nicht garantiert werden kann wenn mal ein System nicht da ist oder andere Umstände.

Deswegen ist es am effektivsten, in der Standby-Datenbank die history-Tabelle mit einem primary Key aufzubauen. Dann verhindert die DB von sich aus doppelte Einträge und du kannst dein Verfahren so lassen wie du es engstellt hast.

Du hast doch eine MySQL als Archiv wenn ich mich nicht irre. Dann dropst du am Besten deine history Tabelle in der Standby nochmal und erstellst sie neu mit einem primary Key so:

Code Auswählen


drop table history;

CREATE TABLE `fhemtest`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
ALTER TABLE `fhemtest`.`history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

Dann kannst du neu Syncen und den Lauf so oft wiederholen wie du willst, die Zeiträume können sich dabei überlappen. Alles kein Problem. Die DB verhindert dass doppelte Einträge entstehen.

Wenn ich Zeit finde, erstelle ich auch mal einen Wiki-Beitrag dazu.
Probiers mal aus ...

LG,
Heiko

DS_Starter · 24 Januar 2020, 15:55:01

Hallo zusammen,

ich habe das ganze Verfahren zur Synchronisation einer Standby-Datenbank im Wiki genau beschrieben.
Falls Fragen/Ergänzungen bestehen ... gerne melden.

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Grüße,
Heiko

DS_Starter · 24 Januar 2020, 21:19:52

Ich habe die Logausgaben für den Befehl syncStandby noch etwas verbessert.

Code Auswählen


2020.01.24 20:47:09.383 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 14930
2020.01.24 20:47:48.007 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 168164
2020.01.24 20:48:17.547 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 132427
2020.01.24 20:48:39.390 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 100402
2020.01.24 20:49:02.580 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 99906
2020.01.24 20:49:27.012 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 99685
2020.01.24 20:49:46.452 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 86970
2020.01.24 20:49:46.453 3: DbRep Rep.LogDB1.syncStandby - number of lines inserted into "LogStby": 20705

Es werden sowohl die an die Standby-Datenbank übertragenen Datensätze (total lines transfered) als auch die davon tatsächlich eingefügten Datensätze (number of lines inserted) getrennt voneinander ausgewiesen. Die "number of lines inserted" werden im Reading "number_lines_inserted_Standby" ausgegeben.
Damit sieht man deutlich wie der primary Key wirkt und das doppelte Datensätze vermieden werden.

Die Version 8.30.7 liegt noch in meinem contrib, Download mit:

Zitat
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

LG

ironalf · 25 Januar 2020, 11:31:14

Zitat von: DS_Starter am 23 Januar 2020, 22:59:19
Hallo Alfons, @all,

ich habe die überarbeitete Version bereitgestellt. delDoublets klappt nun auch für PostgreSQL.

Liegt in meinem contrib.

Download, komplett mit "" so im FHEMWEB ausführen:

Code Auswählen Erweitern
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Danach FHEM restarten.

Probiers mal bitte bei dir/euch aus. Bei mir waren die Tests alle positiv.

Grüße,
Heiko

Hallo Heiko,

ich habe es getestet und es hat funktioniert.

Danke und viele Grüße
Alfons

DS_Starter · 25 Januar 2020, 12:55:53

Danke für die Rückmeldung Alfons. Dann checke ich die Version heute ein. Sie ist dann morgen früh im Regelupdate enthalten.
Da hat sich dann einiges getan. Ihr seht es dann in den Updatehinweisen.

Grüße,
Heiko

DS_Starter · 27 Januar 2020, 14:39:45

Ich weiß nicht mehr wo/wann genau es war, aber es gab mal einen Featurerequest eines Users um bei der Ausführung von maxValue alle anderen Datensätze außer dem Datensatz mit dem maximum Wert zu löschen.
Das habe ich nun umsetzt. Es gibt eine Option "deleteOther" beim maxValue.

* maxValue [display | writeToDB | deleteOther]
.....

Wird die Option deleteOther verwendet, werden alle Datensätze außer dem Datensatz mit dem ermittelten Maximalwert aus der Datenbank innerhalb der definierten Grenzen gelöscht.
....

Die Version 8.31.0 liegt in meinem contrib zum Test bereit wer mag.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

Code Auswählen


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Danach FHEM restart.

Grüße,
Heiko

DS_Starter · 29 Januar 2020, 11:28:30

Habe die Option deleteOther auch noch für die minValue-Funktion verfügbar gemacht.
Die neue DbRep Version 8.32.0 ist eingecheckt und morgen früh im Regelupdate enthalten.

booster · 07 Februar 2020, 21:52:12

Hallo, das mit der neuen Funktion bei maxValue und deleteOther werden die maximalen Werte aller devices pro aggregation zusammengelegt und nur der höchste (egal von welchem device) behalten und der Rest gelöscht. Somit werden die maxWerte der anderen auch mit gelöscht.
Ich dachte das die Funktion jedes Device/Reading Eigenständig betrachtet und den maxValue ermittelt.

Auch habe ich festgestellt, das bei einem delEntries Aufruf mit timeolderthan 30 Tagen nicht alle Werte bis in die Vergangenheit bearbeitet bzw. gelöscht werden. Es wird nur eine bestimmte Anzahl gelöscht. Gibt es da eine Begrenzung im Modul?

DS_Starter · 07 Februar 2020, 22:05:27

ZitatIch dachte das die Funktion jedes Device/Reading Eigenständig betrachtet und den maxValue ermittelt.

Der User gibt ja in den Attributen device/reading an welche Devices/Readings betrachtet werden sollen. Der User muss dafür Sorge tragen, dass die "richtigen" bearbeitet werden. Works as designed.

Zitat
Auch habe ich festgestellt, das bei einem delEntries Aufruf mit timeolderthan 30 Tagen nicht alle Werte bis in die Vergangenheit bearbeitet bzw. gelöscht werden. Es wird nur eine bestimmte Anzahl gelöscht. Gibt es da eine Begrenzung im Modul?

Eine Begrenzung gibt es nicht und ich kann es momentan auch nicht nachvollziehen. Du müsstest mal verbose 4 einschalten und ein Log eines Laufs von delEntries posten. Möglichst ein List vom Device noch dazu.

LG,
Heiko

booster · 07 Februar 2020, 22:47:56

Ich habe von 2017 bis heute Datensätze in der Datenbak und wollte die jetzt ausdünnen. Mit deinem Tool kann man das sehr gut machen., jedoch bearbeitet es nicht alle Werte.

DBrep ist wie folgt definiert

Code Auswählen

efmod DBLogging_DbRep_Cleaner3 DbRep DBLogging
attr DBLogging_DbRep_Cleaner3 aggregation day
attr DBLogging_DbRep_Cleaner3 alias Datenbank-Log Cleaner SeqDoublets (DbRep)
attr DBLogging_DbRep_Cleaner3 allowDeletion 1
attr DBLogging_DbRep_Cleaner3 comment Löschen von aufeinander folgenden identische Datensätzen.
attr DBLogging_DbRep_Cleaner3 devStateIcon .*connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr DBLogging_DbRep_Cleaner3 device cnKW271Brenner
attr DBLogging_DbRep_Cleaner3 group Logging
attr DBLogging_DbRep_Cleaner3 icon recycling
attr DBLogging_DbRep_Cleaner3 reading countsPerDay
attr DBLogging_DbRep_Cleaner3 room Logs
attr DBLogging_DbRep_Cleaner3 showproctime 1

Wenn ich die Werte in der DB zähle dann dürften max. 1500...2000 Werte nach der ausführung von maxValue deleteOther enthalten sein. Jedoch habe ich noch ca. 200000 Werte in der Datenbank. Im Plot kann ich erkennen, das die Datensätze nur von etwa 1 Jahr gelöscht wurden.

DS_Starter · 07 Februar 2020, 23:02:37

Naja wie gesagt, poste mal bitte ein verbose 4 Log von einem Delete Lauf. Man muß sich die SQL-Statements anschauen können die ausgeführt werden, sonst kann man nichts sagen.

booster · 08 Februar 2020, 07:41:18

Bitte entschuldige, hier der Log Eintrag.

Code Auswählen

2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - -------- New selection --------- 
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Command: delEntries 
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - timeOlderThan - year: , day: 90, hour: , min: , sec: 
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Year 2020 is leap year
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - startMonth: 9 endMonth: 10 lastleapyear: 2020 baseYear: 2019 diffdaylight:0 isdaylight:0
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - FullDay option: 0
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Timestamp begin human readable: 2017-10-29 22:35:56
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Time difference to current time for calculating Timestamp end: 7862401 sec
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Timestamp end human readable: 2019-11-09 07:24:01
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Aggregation: no
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - SQL execute: delete FROM history where ( DEVICE IN ('MAX_0f8852','MAX_0f8880','MAX_0f8983','MAX_0ffd00','MAX_10176e','MAX_1056a0','MAX_11b8a6','MAX_11b8a9','MAX_1483f9','MAX_16434e','MAX_1663b9','MAX_185056','Garage','Heizungsraum','WW_Ausgang','WW_Zirkulation','HK1_RL','HK1_VL','HK2_RL','HK2_VL','ESPEasy1','ESPEasy_esp1_SONOFF_TH10_clima','ESPEasy_esp1_SONOFF_TH10_output','xiaomiButton1','xiaomiButton2','xiaomiButton3','xiaomiTempSensor1','xiaomiTempSensor2','HM_4D1493_IEC_01','Shelly_DRHZ_N','Shelly_DRHZ_SW','Shelly_TeichPumpe') ) AND TIMESTAMP >= '2017-10-29 22:35:56' AND TIMESTAMP <= '2019-11-09 07:24:01' ;
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - execute command after delEntries: 'setstate IFTimeDBcleanFHEM -' 
2020.02.08 07:24:02 3: DbRep DBLogging_DbRep_Cleaner1 - Entries of fhem.history deleted: MAX.//Garage/Heizungsraum/WW.//HK.//ESPEasy.//xiaomi.//HM_4D1493_IEC_01/Shelly./--/--0

und die configuration

Code Auswählen

defmod DBLogging_DbRep_Cleaner1 DbRep DBLogging
attr DBLogging_DbRep_Cleaner1 alias Datenbank-Log Cleaner (DbRep) (90d)
attr DBLogging_DbRep_Cleaner1 allowDeletion 1
attr DBLogging_DbRep_Cleaner1 comment Löschen von Einträgen welche älter als 90 Tage sind.
attr DBLogging_DbRep_Cleaner1 devStateIcon .*connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr DBLogging_DbRep_Cleaner1 device MAX.*,Garage,Heizungsraum,WW.*,HK.*,ESPEasy.*,xiaomi.*,HM_4D1493_IEC_01,Shelly.*
attr DBLogging_DbRep_Cleaner1 event-on-change-reading state
attr DBLogging_DbRep_Cleaner1 event-on-update-reading state
attr DBLogging_DbRep_Cleaner1 executeAfterProc setstate IFTimeDBcleanFHEM -
attr DBLogging_DbRep_Cleaner1 group Logging
attr DBLogging_DbRep_Cleaner1 icon recycling
attr DBLogging_DbRep_Cleaner1 room Logs
attr DBLogging_DbRep_Cleaner1 showproctime 1
attr DBLogging_DbRep_Cleaner1 timeOlderThan d:90
attr DBLogging_DbRep_Cleaner1 verbose 4

Bei mir wurden jetzt seltsamerweise doch die Einträge gelöscht. Nach der Ausführung hat es noch ca. 1/2 Tag gedauert bis diese aus der DB verschwunden sind. Bin grad etwas verwirrt.

DS_Starter · 08 Februar 2020, 08:09:15

Guten Morgen,

danke fürs Log. Also das SQL-Statement ist absolut in Ordnung und tut das was du möchtest.
Als Tipp ... du verwendest im Attribut device DevSpec (HK.*,ESPEasy.*,xiaomi.*...) also Regex. Das ist auch absolut in Ordnung und ist so vorgesehen. Aber man muss dazu wissen, dass in diesem Fall die realen Devices für den Select anhand der aktuell im System vorhandenen Geräte aufgelöst werden.
Sind alte Devices in der DB, werden die nicht aufgelöst und auch nicht gelöscht. Das würde man aber in der IN-Klausel des SQLs sehen bzw. die Devices dort vermissen.
In solchen Fällen benutzt man dann SQL-Wildcard (%) was aber deutlich langsamer arbeitet.

ZitatNach der Ausführung hat es noch ca. 1/2 Tag gedauert bis diese aus der DB verschwunden sind. Bin grad etwas verwirrt.

Das wäre ich auch.

Nach dem Löschen muss die DB noch einen Commit durchführen um die Einträge tatsächlich zu entfernen. Allerdings ist der Löschlauf in dieser Zeit noch im state "running" und noch nicht fertig. 1/2 Tag wäre aber auch extrem lang.
Wie schnell ist denn deine DB so ? (Reading sql_processing_time).

LG,
Heiko

booster · 08 Februar 2020, 08:10:20

Ich hab da nochmal eine Frage zu dem maxValue Thema in bezug mit dem deleteOther. Wie kann ich mit einem dbRep-Device eine Vielzahl an Einträgen bearbeiten, so das die Readings pro device immer betrachtet werden? Es soll jedes Reading aus der reading-list einzel bearbeitet werden.

Device: A, B, C
Reading Atest1, Atest2, Btest1, Btest2, Ctest1

Ich möchte gerne vom jedem Reading den maxValue einzeln erhalten, und nicht den maxValue von den zusammengefassten Readings.

Mit dieser Config habe ich es versucht, aber das ist falsch,. Wie mache ich das besser, bzw. geschickter?

Das ist ein Setting nur für ein Device und Reading was funktioniert wie ich es mir vorstelle.

Code Auswählen

defmod DBLogging_DbRep_Calc2 DbRep DBLogging
attr DBLogging_DbRep_Calc2 aggregation day
attr DBLogging_DbRep_Calc2 alias Datenbank-Log Calc2 (DbRep) (Shrink) (90d)
attr DBLogging_DbRep_Calc2 allowDeletion 1
attr DBLogging_DbRep_Calc2 comment Ermittelt die täglichen Maximalwerte von Einträgen und entfernt die restlichen welche älter als 90 Tage sind.
attr DBLogging_DbRep_Calc2 devStateIcon .*connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr DBLogging_DbRep_Calc2 device cnKW271Brenner
attr DBLogging_DbRep_Calc2 event-on-change-reading state
attr DBLogging_DbRep_Calc2 event-on-update-reading state
attr DBLogging_DbRep_Calc2 group Logging
attr DBLogging_DbRep_Calc2 icon edit_settings
attr DBLogging_DbRep_Calc2 reading countsPerDay
attr DBLogging_DbRep_Calc2 room Logs
attr DBLogging_DbRep_Calc2 showproctime 1
attr DBLogging_DbRep_Calc2 timeOlderThan d:90

Und das ist mein Problemkind.

Code Auswählen

  - device: myElectricityCalc
  - reading: HM_4D1493_IEC_01_energyCounterValue_EnergyDay,HM_4D1493_IEC_01_energyCounterValue_EnergyMonth,HM_4D1493_IEC_01_energyCounterValue_EnergyYear,HM_4D1493_IEC_01_energyCounterValue_EnergyDayLast,HM_4D1493_IEC_01_energyCounterValue_EnergyMonthLast,HM_4D1493_IEC_01_energyCounterValue_EnergyYearLast,HM_4D1493_IEC_01_energyCounterValue_EnergyMeter
  - aggregation: day