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

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

DS_Starter

Zitat
Mich wunderte eben nur das geschriebene im Wiki etwas und verwirrte.
Das die current für SVG Auswahl grundsätzlich nur die Readings/Device benötigt, wusste ich nicht.
Hatte ich allerdings geschrieben dass die current mit Device/Readings-Kombinationen aufgefüllt wird. Kommt vielleicht nicht so deutlich raus, ich besser nach ...

ZitatStellt mir eben aber gerade die Frage, für was dann die Funktion der current Bereinigung ...  :-[
Naja, dafür gibt es zwei Überlegungen.
Zum einen ist/war es oft so, dass sich in der current Kombinationen von Device/Readings wiederfinden die es vllt. nicht mehr gibt und weg können, auch Mehrfachvorkommen bzw. Redundanzen wurden genannt.
Andererseits will man vielleicht Plots von Werten erstellen die es als reales Gerät nicht mehr gibt, aber noch in der DB enthalten sind.
Man sich natürlich in allen Fällen manuell im Editor behelfen, aber diese Funktion gibt die Chance die current als Editorhilfe aktuell zu halten. Außerdem kann durch die Einstellung in DbLog das ständige (synchrone) Schreiben in die current vermieden werden falls man den asynchronen Modus nicht verwendet.

Naja, ich würde mir nur Arbeit für Erweiterungen machen wenn es dafür eine sinnvolle Verwendung gibt.  ;)

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

topa_LE

Ah ok, danke Dir. Hab's verstanden.

Nun gut, für mich persönlich wäre die "normale" Current Table nur von neuen Defines zu bereinigen, die ich nicht grundsätzlich loggen möchte. Dafür kann ich aber auch schnell die current manuell löschen.

Daher ist alles gut so. ;-)

abc2006

Hi, ich habe ein Problem mit DbRep: nach dem Anlegen und dem Absetzen des Befehls countEntries (also die ersten Zeilen aus dem Wiki) erhalte ich den State "disconnected",
Log (verbose 5):
2018.12.27 18:10:01.849 3: DbRep test - WARNING - old process 8806 will be killed now to start a new BlockingCall
2018.12.27 18:10:01.866 1: DbRep test -> BlockingCall DbRep_getInitData pid:8806 Timeout: process terminated
2018.12.27 18:10:01.928 3: DbRep test - get initial structure information of database "fhem", remaining attempts: 3
2018.12.27 18:10:01.930 3: DbRep test - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2018.12.27 18:10:02.047 3: DbRep test - WARNING - old process 8855 will be killed now to start a new BlockingCall
2018.12.27 18:10:02.048 1: DbRep test -> BlockingCall DbRep_getInitData pid:8855 Timeout: process terminated
2018.12.27 18:10:02.121 3: DbRep test - get initial structure information of database "fhem", remaining attempts: 2
2018.12.27 18:10:02.123 3: DbRep test - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser

list:
Internals:
   CFGFN     
   DATABASE   fhem
   DEF        logdb
   LASTCMD    countEntries current
   MODEL      Client
   NAME       test
   NOTIFYDEV  global,test
   NR         83087
   NTFY_ORDER 50-test
   ROLE       Client
   STATE      disconnected
   TYPE       DbRep
   UTF8       1
   VERSION    8.9.6
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  1
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     RUNNING_PID:
       abortFn    DbRep_getInitDataAborted
       arg        test|countEntries|current|DbRep_Main
       bc_pid     3588
       finishFn   DbRep_getInitDataDone
       fn         DbRep_getInitData
       loglevel   5
       pid        8856
       telnet     telnetPort_127.0.0.1_58680
       timeout    120
       abortArg:
   READINGS:
     2018-12-27 18:10:02   errortext       Timeout: process terminated
     2018-12-27 18:10:02   state           disconnected
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db_fhem.conf
     DEF        ./db_fhem.conf .*:.*
     MODE       asynchronous
     MODEL      MYSQL
     NAME       logdb
     NR         307
     NTFY_ORDER 50-logdb
     PID        654
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     UTF8       1
     VERSION    3.13.0
     dbconn     mysql:database=fhem;host=localhost;port=3306
     dbuser     fhemuser
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   0
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2018-12-27 18:11:48   CacheUsage      12
       2018-12-27 18:11:42   NextSync        2018-12-27 18:12:12 or if CacheUsage 100 reached
       2018-01-30 17:16:35   lastCachefile   ./log/cache_logdb_2018-01-25_03-37-17 import successful
       2018-12-27 18:11:43   state           connected
     cache:
       index      159920
Attributes:
   verbose    5


Das LogDB-Device funktioniert einwandfrei, in selbst geschriebenen Routinen kann ich Werte aus der Datenbank abrufen.
Achso, die version ist noch interessant:
93_DbRep.pm            17773 2018-11-18 07:48:35Z DS_Starter

EDIT: ich hab grad das Update auf die aktuellste Version gemacht, was aber keine anderen Ergebnisse liefert.

Andere Abfragen funktionieren auch nicht. Weitere Datenbankzugriffe hab ich erstmal nicht getestet.
"Früher" gings mal, dann hab ichs jetzt länger nicht benutzt.
Achso, kann das an der Datenbank liegen? Diese hab ich nämlich .. neulich .. durch MariaDB ersetzt...
Das DbLog-Device funktioniert (soweit ich beurteilen kann) noch einwandfrei.
Wo kann ich noch suchen?
Soll ich besser nen eigenen Thread aufmachen?

Danke und Grüße,
Stephan
FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX

DS_Starter

Hallo Stephan,

setze dir das Attribut "fastStart = 1" und Restart.

Vor einiger Zeit habe ich die Startroutine wegen noch kommender Weiterentwicklungen angepasst. Wenn der initiale Datenabruf zu lange dauert, kommt es zu dem Timeout.
An MariaDB an sich liegt es nicht. Kann aber sein, dass sich deine DB-Zeiten (ziemlich) erhöht haben ?
Das würdest du sehen wenn du dir im DbLog-Device das Attribut "showproctime = 1" setzt.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

abc2006

Hi,
danke für die schnelle Antwort.


restart = shutdown restart von fhem?

showproctime im DbLog:
background_processing_time 0.1267

Ist das zuviel?

Die Abfrage scheint trotz disconnect gelaufen zu sein, denn ich habe ein Ergebnis:
__/__ALLREADINGS__COUNT_history__no_aggregation 57910707

Danke und Grüße,

Stephan
FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX

DS_Starter

Zitatrestart = shutdown restart von fhem?
Ja, genau. Dann zieht das fastStart.

Zitatshowproctime im DbLog:
background_processing_time 0.1267

Ist das zuviel?
No, das ist ok.

Vllt. nur ab und zu einen "Hänger" ? Schwer zu sagen jetzt.

Mit dem gesetzten Attribut geht dein DbRep nach dem Start erstmal auf "initialized". Erst wenn die erste Aktion gestartet wird, werden die Initialinfos abgerufen. Das Verfahren ist besonders hilfreich wenn man viele DbRep definiert hat, die sonst alle bei FHEM Start zur DB connecten wollen um ihre Infos abzurufen.
Deswegen hatte ich mit derV8.8.0 vom 06.11.2018 das fastStart implementiert.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

vuffiraa

Hallo,

ich habe auch ein Problem mit DbRep und der Funktion diffValues. Da ich meine Datenbank neu befüllen durfte, kommen bei einem Select die Einträge nicht mehr in der erwarteten Reihenfolge. Dadurch kommt dann auch die Funktion diffValues durcheinander.

Spricht etwas dagegen, im Modul in den Zeilen 3321 und 3323 den letzten (leeren) Parameter in 'ORDER BY TIMESTAMP' zu ändern?

Gruß VuffiRaa
FHEM 5.8 auf Cubietruck, Raspi B+

Weinzierl KNX IP BAOS 770, Homematic, EnOcean

DS_Starter

Hallo VuffiRaa,

auf den ersten Blick spricht da nichts dagegen. Ich schaue es mir am Vormittag genauer an und melde mich wieder.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Guten Morgen,

ich habe die gewünschte Änderung in diffValue noch etwas getestet und sieht für mich gut aus.
Werde im Laufe des Tages noch ein paar Vergleichsläufe beobachten, aber habe die geänderte Version 8.9.9 für nach contrib geladen:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter  (Downloadbutton benutzen)

und checke sie ein wenn mir nichts mehr auffallen sollte.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

vuffiraa

Hallo Heiko,

danke für die prompte Bedienung  :)

Hab das geänderte Modul übernommen und jetzt entsprechen die Statistiken wieder meinen Erwartungen.

Gruß VuffiRaa
FHEM 5.8 auf Cubietruck, Raspi B+

Weinzierl KNX IP BAOS 770, Homematic, EnOcean

DS_Starter

Danke für die Info. Ist eingecheckt und morgen Früh im Regelupdate.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo zusammen,

habe einen Vorschlag aus https://forum.fhem.de/index.php/topic,96056.msg892890.html#msg892890 umgesetzt.
DbRep ist so erweitert, dass man beim Export die Filegröße begenzen kann:

* exportToFile [</Pfad/File>] [MAXLINES=<lines>] - exportiert DB-Einträge im CSV-Format in den gegebenen Zeitgrenzen.

Der Dateiname wird durch das Attribut "expimpfile" bestimmt. Alternativ kann "/Pfad/File" als Kommando-Option angegeben werden und übersteuert ein eventuell gesetztes Attribut "expimpfile". Optional kann über den Parameter "MAXLINES" die maximale Anzahl von Datensätzen angegeben werden, die in ein File exportiert werden. In diesem Fall werden mehrere Files mit den Extensions "_part1", "_part2", "_part3" usw. erstellt (beim Import berücksichtigen !).
.........

Man kann die MAXLINES-Option sowohl im Kommando als auch im Attribut expimpfile verwenden.

Die Version 8.11.0 ist eingecheckt und morgen im Update.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Thowe

Hallo,
ich nutze mysql und dbrep.
Jedoch führt das Report-Define die executeAfterProc nicht aus, wenn das set seinerseits eine Report-Aktion startet.
im Beispiel unten wird nach Beendigung des sqlcmd das executeAfterProc "set Rep_HH_Tagesenergie_max maxValue writeToDB" nicht ausgeführt
Ist das so gewollt? MUSS das mit der Chain-Funktion oder über eine benutzerdefinierte Perl-Routine gelöst werden?

Viele Grüße,
Thowe

define Rep_HH_Tagesenergie_Corr DbRep DBLogging
attr Rep_HH_Tagesenergie_Corr timestamp_begin previous_day_begin
attr Rep_HH_Tagesenergie_Corr timestamp_end previous_day_end
attr Rep_HH_Tagesenergie_Corr executeAfterProc set Rep_HH_Tagesenergie_max maxValue writeToDB

define Rep_HH_Tagesenergie_max DbRep DBLogging
attr Rep_HH_Tagesenergie_max aggregation day
attr Rep_HH_Tagesenergie_max device HH_Tagesenergie
attr Rep_HH_Tagesenergie_max reading state
attr Rep_HH_Tagesenergie_max timestamp_begin previous_day_begin
attr Rep_HH_Tagesenergie_max timestamp_end previous_day_end

define Correct_Rep_HH_Tagesenergie_timestamp at *00:05:00 set Rep_HH_Tagesenergie_Corr sqlCmd UPDATE history SET timestamp = DATE_SUB(timestamp, INTERVAL (minute(timestamp)*60 + second(timestamp)+1) second) where TIMESTAMP >= §timestamp_end§ and device = 'HH_Tagesenergie' and value > '1.0'

DS_Starter

Hallo Thowe,

die executeAfterProc (executeBeforeProc) ist für sqlCmd noch nicht umgesetzt.
Ich kann das aber gern tun und stelle dir kurzfristig eine Version bereit die ich nach erfogreichem Test auch einschecke.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Thowe

Hallo Heiko,

sogar sonntags am Gerät?! :)
Ja, gerne. Ich habe allerdings auch die gleichen Probleme mit anderen dbrep-Funktionen, das executeAfterProc zu starten:
sumValue und maxValue

Viele Grüße,
Thowe