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

DS_Starter · 23 Januar 2018, 22:19:06

Zitat
Mir ist gerade aufgefallen, dass nach dem update auf Revision
Latest Revision: 15962
der "blockinginfo" -Befehl nicht mehr vorhanden ist.

Sicher ? Ich habe auch 15962 im Einsatz, aber blockinginfo gibts noch.

ZitatIn der DbRep.pm scheinst du ohne diesen auszukommen... ist die Funktionalität gleich?

Sie ist ähnlich. Nachgebaut und abgeändert damit es dem gewünschten Umfang entspricht.

knxler · 24 Januar 2018, 09:21:16

Hallo,

ich bin völlig überrascht über die zahlreichen Reaktionen durch meinen Beitrag.
Es wäre natürlich schön dies direkt mit in das Tool zu implementieren. Wenn nicht, sollte dies aber im Wiki erwähnt werden, auf welche Weise der Mittelwert gebildet wird.
Ich kann mir natürlich eine Perlfunktion bauen die die Mittelwertberechnung übernimmt. Diese kann ich wenn ihr wollt dann natürlich auch hier zur Verfügung stellen.

Gruß Martin

DS_Starter · 24 Januar 2018, 09:35:49

Hallo Martin,

war ich selber auch überrascht.

Darauf, dass es sich bei der averageValue Funktion um das arithmetische Mittel handelt, habe ich jetzt in der commandref explizit hingewiesen. Damit sollte die Bildung eindeutig beschrieben sein.
Gern kannst du uns deine Perlfunktion zur Mittelwertberechnung zur Verfügung stellen.

Ich stelle es mir momentan so vor, dass die bisherige averageValue Funktion als arithmetischer Mittelwertbildung so erhalten bleibt wie sie ist.
Zusätzlich könnte man eine Funktion "averageValueSpecial" mit verschiedenen Aufrufoptionen, "meteoTemperature" etc. anzubieten.
Dort könnten dann die "besonderen" Mittelwertbildungen abgebildet sein.

LG,
Heiko

DS_Starter · 24 Januar 2018, 21:08:12

Hallo Stephan, @all,

in der V7.5.4 ist die "delSeqDoublets"-Funktion hinsichtlich Laufzeit und Ressorcenverbrauch optimiert.

Auf meinem Testsystem auf SQLite wird für die Analyse mit "delSeqDoublets adviceRemain" von 2,5 GB und 12 Mio Datensätzen ohne Eingrenzung eine Laufzeit von nur noch 155 Sekunden erreicht.

Die Attribute "executeBeforeProc", "executeAfterProc" sind nun auch für "delSeqDoublets" verfügbar.

Grüße
Heiko

abc2006 · 26 Januar 2018, 10:24:02

alles klar, wird geladen und getestet. Puh, grad hab ich einige Baustellen, das muss in die queue.

Habe gerade versucht, etwas aus einer Datenbank zu löschen. Dieser Befehl schlägt fehl.

Aufbau:
octocore mit 16GB RAM
SQLite mit 400 MB
countCurrent 220 2018-01-26 10:08:06
countHistory 2840982 2018-01-26 10:08:06

logdb:

Code Auswählen

Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32 
   CONFIGURATION ./dabafhem_db.conf
   DEF        ./dabafhem_db.conf .*:.*
   MODE       synchronous
   MODEL      SQLITE
   NAME       logdb
   NR         17
   NTFY_ORDER 50-logdb
   PID        5193
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   VERSION    3.7.1
   dbconn     SQLite:dbname=/opt/fhem/dabafhem.db
   dbuser     
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
   READINGS:
     2018-01-26 10:08:06   countCurrent    220
     2018-01-26 10:08:06   countHistory    2840982
     2018-01-26 09:53:25   state           connected
   cache:
     index      0
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Include
   DbLogType  SampleFill/History
   room       LOG

repdb:

Code Auswählen

Internals:
   DATABASE   /opt/fhem/dabafhem.db
   DEF        logdb
   LASTCMD    sqlCmd delete
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         19
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       0
   VERSION    7.5.5
   HELPER:
     DBLOGDEVICE logdb
     CV:
       aggregation no
       aggsec     1
       destr      2018-01-20
       dsstr      2018-01-10
       epoch_seconds_end 1516402800
       mestr      01
       msstr      01
       testr      00:00:00
       tsstr      00:00:00
       wdadd      432000
       yestr      2018
       ysstr      2018
   READINGS:
     2018-01-26 10:08:01   errortext       DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

     2018-01-26 10:08:01   state           error
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32 
     CONFIGURATION ./dabafhem_db.conf
     DEF        ./dabafhem_db.conf .*:.*
     MODE       synchronous
     MODEL      SQLITE
     NAME       logdb
     NR         17
     NTFY_ORDER 50-logdb
     PID        5193
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     VERSION    3.7.1
     dbconn     SQLite:dbname=/opt/fhem/dabafhem.db
     dbuser     
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2018-01-26 10:08:06   countCurrent    220
       2018-01-26 10:08:06   countHistory    2840982
       2018-01-26 09:53:25   state           connected
     cache:
       index      0
Attributes:
   DbLogExclude .*
   allowDeletion 1
   room       LOG
   timestamp_begin 2018-01-10 00:00:00
   timestamp_end 2018-01-20 00:00:00

Befehl:

Code Auswählen

set repdb sqlCmd delete from history where DEVICE='global'

Fehler:

Code Auswählen

DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

LOG:

Zitat2018.01.26 10:21:21.811 4: DbLog logdb -> ################################################################
2018.01.26 10:21:21.812 4: DbLog logdb -> ### start of new Logcycle ###
2018.01.26 10:21:21.812 4: DbLog logdb -> ################################################################
2018.01.26 10:21:21.812 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:21:21.812 4: DbLog logdb -> check Device: repdb , Event: state: error
2018.01.26 10:21:21.812 5: DbLog logdb -> parsed Event: repdb , Event: state: error
2018.01.26 10:21:21.812 4: DbRep repdb -> BlockingCall sqlCmd_ParseDone finished
2018.01.26 10:21:49.705 4: DbLog logdb -> ################################################################
2018.01.26 10:21:49.705 4: DbLog logdb -> ### start of new Logcycle ###
2018.01.26 10:21:49.705 4: DbLog logdb -> ################################################################
2018.01.26 10:21:49.705 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:21:49.706 4: DbLog logdb -> check Device: repdb , Event: state: running
2018.01.26 10:21:49.706 5: DbLog logdb -> parsed Event: repdb , Event: state: running
2018.01.26 10:21:49.706 4: DbRep repdb - -------- New selection ---------
2018.01.26 10:21:49.706 4: DbRep repdb - Command: sqlCmd delete from history where DEVICE='global'
2018.01.26 10:21:49.707 5: DbRep repdb - Timestamp begin epocheseconds: 1515538800
2018.01.26 10:21:49.707 4: DbRep repdb - Timestamp begin human readable: 2018-01-10 00:00:00
2018.01.26 10:21:49.707 5: DbRep repdb - Timestamp end epocheseconds: 1516402800
2018.01.26 10:21:49.708 4: DbRep repdb - Timestamp end human readable: 2018-01-20 00:00:00
2018.01.26 10:21:49.708 5: DbRep repdb - weekday of start for selection: Mi -> wdadd: 432000
2018.01.26 10:21:49.708 4: DbRep repdb - Aggregation: no
2018.01.26 10:21:49.728 4: DbRep repdb -> Start BlockingCall sqlCmd_DoParse
2018.01.26 10:21:49.729 4: DbRep repdb - SQL execute: delete from history where DEVICE='global';
2018.01.26 10:22:19.791 2: DbRep repdb - ERROR - DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

2018.01.26 10:22:19.792 4: DbRep repdb -> BlockingCall sqlCmd_DoParse finished
2018.01.26 10:22:19.794 4: DbRep repdb -> Start BlockingCall sqlCmd_ParseDone
2018.01.26 10:22:19.795 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.795 4: DbLog logdb -> ### start of new Logcycle ###
2018.01.26 10:22:19.795 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.795 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:22:19.796 4: DbLog logdb -> check Device: repdb , Event: errortext: DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

2018.01.26 10:22:19.796 5: DbLog logdb -> parsed Event: repdb , Event: errortext: DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

2018.01.26 10:22:19.798 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.798 4: DbLog logdb -> ### start of new Logcycle ###
2018.01.26 10:22:19.798 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.798 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:22:19.798 4: DbLog logdb -> check Device: repdb , Event: state: error
2018.01.26 10:22:19.799 5: DbLog logdb -> parsed Event: repdb , Event: state: error
2018.01.26 10:22:19.799 4: DbRep repdb -> BlockingCall sqlCmd_ParseDone finished

Wie kann das kommen?
Ich hoff ich hab keine Infos vergessen..

ah, dazu hätt ich noch nen feature-wunsch.
Ich weiss nicht, ob das einfach geht, aber in den letzten Tagen wünschte ich mir immer sehnlicher eine Funktion, die mir .. die letzten, ka, 5 Befehle als Button zur Verfügung stellt, damit ich nicht den ganzen Text nochmal tippen muss ...

Grüße,
Stephan

abc2006 · 26 Januar 2018, 10:31:37

Zitat von: DS_Starter am 24 Januar 2018, 21:08:12
in der V7.5.4

ich hab ausm *update* bereits die 7.5.5?

Grüße,
Stephan

DS_Starter · 26 Januar 2018, 10:48:01

Moin Stephan,

Zitat2018.01.26 10:22:19.791 2: DbRep repdb - ERROR - DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

Ja sowas kann kommen wenn du zum Beispiel einen SQL-Editor aufhast und die DB geladen ist. SQLite ist da nicht so gentle wie MySQL.

Zitatich hab ausm *update* bereits die 7.5.5?

Ja, bin grad fleißig

ZitatIch weiss nicht, ob das einfach geht, aber in den letzten Tagen wünschte ich mir immer sehnlicher eine Funktion, die mir .. die letzten, ka, 5 Befehle als Button zur Verfügung stellt, damit ich nicht den ganzen Text nochmal tippen muss ...

Ich denk mal drüber nach. Habe ja das gleiche Problem. Behelfe mir momentan damit dass ich meine am häufigsten benötigten Statements in das Attribut comment im Device eintrage und dann per Coppy&Paste ...

LG,
Heiko

abc2006 · 26 Januar 2018, 10:51:05

Moin Heiko,

Zitat von: DS_Starter am 26 Januar 2018, 10:48:01
Ja sowas kann kommen wenn du zum Beispiel einen SQL-Editor aufhast und die DB geladen ist. SQLite ist da nicht so gentle wie MySQL.

Hab ich aber nicht. Nur logdb und repdb.
und auch nur ein device.
und weils grade brandneu installiert ist, auch *keine* sonstigen Events.
und weil die mit DbLogExclude ausgeschlossen sind, schon gar keine Events.

ZitatJa, bin grad fleißig

Klasse, weiter so

ZitatAttribut comment im Device eintrage und dann per Coppy&Paste ...

dito. ist aber auch nicht userfreundlich, wenn sich die Statements öfter verändern

Grüße,
Stephan

DS_Starter · 26 Januar 2018, 10:56:00

Zitat
Hab ich aber nicht. Nur logdb und repdb.
und auch nur ein device.
und weils grade brandneu installiert ist, auch *keine* sonstigen Events.
und weil die mit DbLogExclude ausgeschlossen sind, schon gar keine Events.

Das war nur ein Beispiel was sein könnte. Musst du mal googeln. SQLite ist auch nicht gerade mein Liebling unter den DB's ...

DS_Starter · 26 Januar 2018, 19:05:16

Hallo Stephan, @all,

die V7.6.0 steht nun zum Download und Test bereit.

Was ist neu ?

* Die Ergebnisreadings von fetchrows beinhalten nun nach dem Datum/Zeit-Feld einen Index. Dieser ist bei jedem unikaten Datensatz "1". Gibt es multiple Vorkommen, d.h. exakt gleiche Datensätze im Selektionsbereich, wird der Index mit jedem Duplikat hochgezählt. Dadurch erkennt man doppelte Sätze leicht, da die Readings sich sonst überdecken. Sieht etwa so aus:

Zitat
2018-01-26 18:35:14 2017-10-22_02-56-36_1__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_1__sysmon1__loadavg 0.09 0.04 0.01
2018-01-26 18:35:14 2017-10-22_02-56-36_1__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_1__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00
2018-01-26 18:35:14 2017-10-22_02-56-36_1__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB, 0.27 %, Free: 1289.52 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_2__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_2__sysmon1__loadavg 0.09 0.04 0.01
2018-01-26 18:35:14 2017-10-22_02-56-36_2__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_2__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00
2018-01-26 18:35:14 2017-10-22_02-56-36_2__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB, 0.27 %, Free: 1289.52 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_3__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_3__sysmon1__loadavg 0.09 0.04 0.01
2018-01-26 18:35:14 2017-10-22_02-56-36_3__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_3__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00
2018-01-26 18:35:14 2017-10-22_02-56-36_3__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB, 0.27 %, Free: 1289.52 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_4__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_4__sysmon1__loadavg 0.09 0.04 0.01
2018-01-26 18:35:14 2017-10-22_02-56-36_4__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB
2018-01-26 18:35:14 2017-10-22_02-56-36_4__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00
2018-01-26 18:35:14 2017-10-22_02-56-36_4__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB, 0.27 %, Free: 1289.52 MB

* fetchrows kann nun auch Ergebniswerte darstellen, die ein Pipe "|" enthalten. Die Änderung wurde notwendig, da DbLog in der aktuellen (noch nicht eingecheckten Version) diese Daten nun auch loggen kann.

* es gibt ein neues Set-Komando "sqlCmdHistory" (Stephan wird sich hoffentlich freuen

)
Dieses Command enthält eine Drop-Downliste der bisher verwendeten SQL-Statements mit "sqlCmd". Dieses Set-Kommando taucht erst auf, wenn man mindestens einmal ein "set .. sqlCmd xxxx" ausgeführt hat. Die Liste habe ich momentan auf 10 beschränkt, kann aber leicht abgeändert werden. In der Liste gibt es immer am Schluß den Eintrag "___purge_historylist___". Mit dieser Selektion kann man die Liste löschen. Die Historie ist auch nach einem Restart noch vorhanden, weil sie in einem CacheFile gesichert wird. Jedes DbRep-Device führt seine eigene History-Liste. Ein einmal verwendetes Kommando wird nicht noch einmal eingetragen.
(siehe Screeshot).

Ich hoffe diese Erweiterungen stellen einen weiteren Mehrwertgewinn im Modul dar. Viel Spaß beim Testen.

LG,
Heiko

DS_Starter · 27 Januar 2018, 09:41:14

Guten Morgen,

da vielleicht nicht jeder eine History-Liste haben möchte und darüber hinaus es wünschenswert wäre, die Länge dieser Liste einstellbar zu haben wenn man sie nutzen möchte, habe ich mit der V7.6.1 das Verhalten etwas geändert.

Mit dem neuen Attribut "sqlCmdHistoryLength" schaltet man die Verwendung ein und kann dabei die Länge in 5er Stufen bis z.Zt. 50 festlegen.

EDIT: Habe noch ein Highlighting für mehrfach vorkommende Datensätze eingebaut. Wer möchte setzt sich das Attribut "fetchMarkDuplicates". Es sind ein paar Farben vordefiniert. Aber mit widgetoverride kann man sich an dieser Stelle den colorpicker einbauen:

Code Auswählen


attr <dbrep> widgetOverride fetchMarkDuplicates:colorpicker

Das Ergebnis ist im Screenshot zu sehen.

LG,
Heiko

abc2006 · 27 Januar 2018, 16:15:58

Moin Heiko,

klasse Idee!

Eine Bitte: könntest du mal hier reinschauen:
https://forum.fhem.de/index.php?topic=73490.msg756527#msg756527

Da geht's unter anderem um meine Memory-Thematik...

Grüße,
Stephan

DS_Starter · 27 Januar 2018, 16:33:44

Hallo Stephan,

habe da mal reingeschaut und auch gleich mal "fhemdebug memusage" ausgeführt.
Stürzt aber nichts ab und gibt einwandfrei Rückmeldung.

Grüße
Heiko

DS_Starter · 28 Januar 2018, 11:34:14

Hallo zusammen,

nachdem ich die V7.6.1 recht ausgiebig getestet habe, werde ich sie wahrscheinlich heute noch einchecken. Vielleicht findet sich noch der eine oder andere der bis dahin Feedback gibt.

Danach würde ich mich mal der Average-Thematik zuwenden.

Allerdings ist mir während der Arbeit an 7.6.1 aufgefallen, dass es wohl zur Zeit keine Löschmöglichkeit für echte Dubletten gibt, also für Datensätze die tatsächlich doppelt/mehrfach in der DB vorhanden sind (nicht zu verwechseln mit den sequentiellen Datensätzen mit unterschiedlichen Timestamps und deren Wertegleichheit).
Mit herkömmlichen SQL-Mitteln kann man die ja auch nicht löschen, da in diesem Fall wegen eines fehlenden eindeutigen Schlüssels sowohl die Dubletten als auch der Ausgangsdatensatz gelöscht werden.

Da das Modul jetzt in der Lage ist Dubletten zu behandeln, steht natürlich die Frage ob eine Erweiterung für die Löschung von echten Dubletten benötigt/gewünscht ist ?
Oder übersehe ich Möglichkeiten mit einfachen SQL-Statements und so etwas wäre überflüssig ?

Grüße,
Heiko

kadettilac89 · 28 Januar 2018, 12:27:41

Zitat von: DS_Starter am 28 Januar 2018, 11:34:14
Oder übersehe ich Möglichkeiten mit einfachen SQL-Statements und so etwas wäre überflüssig ?

In Oracle gibt es dazu die virtuelle spalte ROWID. Damit kann man zumindest den einen identischen Wert behalten, restliche löschen. In MySQL gibt es sowas nicht direkt, aber scheinbar einen Workaround ...
https://stackoverflow.com/questions/2728413/equivalent-of-oracle-s-rowid-in-mysql

Link habe ich aber nicht getestet. Aber alles mit Aufwand verbunden. Andere DB's weiß ich nicht.

Ansonten umständlicher Weg den Satz lokal zwischenspeichern, doppelte Sätze löschen und im Anschluss wieder einfügen.

Normal sollten aber überhaupt keine doppelten Sätze (alle Felder identisch) vorhanden sein ... also Aufwand wahrscheinlich höher als Nutzen. Unique-Index wäre aus DB-Design die sauberste Lösung, ohne irgendwelchen Nachteil. Im Falle einer Duplette --> Insert-Fehler ins Log.