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

[Thowe]

Hallo Heiko,

sogar sonntags Support
Und mit Erfolg, vielen Dank
Thowe

[DS_Starter]

Prima... dann wie gehabt morgen früh im Update.

Schönen Wochenstart !
Heiko

[andies]

Guten Abend, ich nutze das tolle Modul, habe es aber heute nicht geschafft, alte Einträge zu löschen. Da ich DbLog erst seit vier Monaten verwende, sollte doch folgendes leicht gehen:

Code Auswählen Erweitern


Internals:
   DATABASE   fhem
   DEF        DbLog
   LASTCMD    delEntries
   MODEL      Client
   NAME       DbLogRep
   NOTIFYDEV  global,DbLogRep
   NR         108
   NTFY_ORDER 50-DbLogRep
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       0
   VERSION    7.15.2
   HELPER:
     DBLOGDEVICE DbLog
     CV:
       aggregation no
       aggsec     1
       destr      2018-01-13
       dsstr      1970-01-01
       epoch_seconds_end 1515870764
       mestr      01
       msstr      01
       testr      20:12:44
       tsstr      01:00:00
       wdadd      345600
       yestr      2018
       ysstr      1970
   READINGS:
     2018-04-23 21:13:37   errortext       DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 3669.

     2018-04-23 21:13:37   state           error
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db.conf
     DEF        ./db.conf (sysmon:.*|Stromzaehler:.*|Viessmann:.*NurGestern.*|Viessmann:.*temperatur.*|Garagensensor:Temperatur:.*|Heizungskeller:Gasverbrauch:.*|Heizungskeller:Wasser:.*|DECT1:temperature.*|Sonoff_pow1:.*|Sonoff_TH10a:myTemperature.*|Sonoff_TH10a:mypower.*|BresserTemeo_1:temperature.*|SensorHydrAbgleich.*:.*Temperatur.*|DECT1:power.*)
     MODE       synchronous
     MODEL      MYSQL
     NAME       DbLog
     NR         20
     NTFY_ORDER 50-DbLog
     PID        32119
     REGEXP     (sysmon:.*|Stromzaehler:.*|Viessmann:.*NurGestern.*|Viessmann:.*temperatur.*|Garagensensor:Temperatur:.*|Heizungskeller:Gasverbrauch:.*|Heizungskeller:Wasser:.*|DECT1:temperature.*|Sonoff_pow1:.*|Sonoff_TH10a:myTemperature.*|Sonoff_TH10a:mypower.*|BresserTemeo_1:temperature.*|SensorHydrAbgleich.*:.*Temperatur.*|DECT1:power.*)
     STATE      connected
     TYPE       DbLog
     UTF8       0
     VERSION    3.10.6
     dbconn     mysql:database=fhem;host=127.0.0.1;port=3306
     dbuser     root
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2018-04-15 13:59:53   lastRowsDeleted 800717
       2018-04-23 21:16:15   state           connected
     cache:
       index      0
Attributes:
   allowDeletion 1
   timeOlderThan 8640000

Statt dessen kommt (auch mit größeren Zahlenwerten bei OlderThan)

Code Auswählen Erweitern

2018.04.23 21:13:37 2: DbRep DbLogRep - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 3669.

[DS_Starter]

Hallo andies,

DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction

Das ist kein Problem des Moduls, sondern eine Reaktion darauf dass die Tabelle für die anstehende Aktion nicht gesperrt werden konnte
(Lock wait timeout ) = Datenbankproblematik

Was bringt denn  "get ... procinfo" ?

[andies]

danke - das hier:

[DS_Starter]

Sieht jetzt aber sauber aus, es gibt nur den query prozess den du gerade abgesetzt hast.

Du kannst jetzt folgendes tun:

1. die Aktion einfach wiederholen
2. DbLog in des asynchronen Mode setzen und die Aktion wiederholen
3. in der my.cnf von mysql den Wert für innodb_lock_wait_timeout hochsetzen und die DB restarten (würde ich aber erstmal nicht machen)

Probiere erstmal 1 und 2 ...

[andies]

danke, sieht gut aus. Scheint zu laufen (Nr. 2).

[DS_Starter]

Hatte ich vermutet. Ein Prozess von dblog (Nr. 49) in deinem Screenshot hatte die history wahrscheinlich noch gelockt obwohl im sleep.
Bei grafana bin ich mir nicht sicher wie sich das verhält. Musst du mal darauf achten falls dir das nochmal auffällt.

Edit: vergiß grafana, ist eine ganz andere Tabelle 

[Thowe]

Hallo Heiko,

ich hänge wieder an einem systematischen Problem fest.
Mit:

Code Auswählen Erweitern

define Rep.NT_365d_Energieaufnahme DbRep DBLogging
attr Rep.NT_365d_Energieaufnahme aggregation no
attr Rep.NT_365d_Energieaufnahme device Tagesgesamtenergieaufnahme_NT
attr Rep.NT_365d_Energieaufnahme reading state
attr Rep.NT_365d_Energieaufnahme showproctime 1
attr Rep.NT_365d_Energieaufnahme timeDiffToNow d:365
attr Rep.NT_365d_Energieaufnahme verbose 5

define Calc.Rep.NT_365d_Energieaufnahme at *00:02:56 set Rep.NT_365d_Energieaufnahme sumValue writeToDB

... erhalte ich folgenden Log:

Code Auswählen Erweitern

2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - -------- New selection ---------
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Command: sumValue writeToDB
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - timeDiffToNow - day: 365, hour: , min: , sec: 
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Time difference to current time for calculating Timestamp begin: 31536001 sec
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Timestamp begin epocheseconds: 1493021749
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Timestamp begin human readable: 2017-04-24 10:15:49
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Timestamp end epocheseconds: 1524557750
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Timestamp end human readable: 2018-04-24 10:15:50
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - weekday of start for selection: Mo  ->  wdadd: 604800
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Aggregation: no
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - IsTimeSet: 1, IsAggrSet: 0
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Timestamp-Array:
no_aggregation#2017-04-24 10:15:49#2018-04-24 10:15:50
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Device specifications use for select: Tagesgesamtenergieaufnahme_NT
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Reading specification use for select: state
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - SQL execute: SELECT SUM(VALUE) FROM history where DEVICE = 'Tagesgesamtenergieaufnahme_NT' AND READING = 'state' AND TIMESTAMP >= '2017-04-24 10:15:49' AND TIMESTAMP <= '2018-04-24 10:15:50' ;
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - SQL result: 0.2
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme -> Primary Key used in fhem.history: none
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme -> Primary Key used in fhem.current: DEVICE,READING
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme - data prepared to db write:
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme - 2017-04-24 23:59:58|Tagesgesamtenergieaufnahme_NT|dummy|calculated|sum_no_state|0.2000|
2018.04.24 10:15:51 3: DbRep Rep.NT_365d_Energieaufnahme - number of lines updated in "DBLogging": 1
2018.04.24 10:15:51 3: DbRep Rep.NT_365d_Energieaufnahme - number of lines inserted into "DBLogging": 0


In die DB wird jedoch nichts eingetragen und das Notify wird nicht ausgelöst:

Code Auswählen Erweitern

define N.Rep.NT_365d_Energieaufnahme_sum notify Rep.NT_365d_Energieaufnahme:(\d).*Tagesgesamtenergieaufnahme_NT__state__SUM__no_aggregation {fhem("set NT_365d_Energieaufnahme $EVTPART1")}

Viele Grüße,
Thowe

[DS_Starter]

Hallo Thowe,

habe gerade bei mir nachgestellt. Der Event erscheint im Eventmonitor. Sieh mal bei dir dort rein in einem zweiten browserfenster wenn du die Aktion durchführst.
Ich denke das ist ein Problem der notify definition. Möglicherweise hilft es so:

... Rep.NT_365d_Energieaufnahme:.*(\d).*Tagesgesamt....

Allerdings habe ich den Sinn des notify nicht verstanden. was willst damit tun ?

Der Wert wird bestimmt in die db geschrieben. Schau mal nach diesem timestamp in der db "2017-04-24 23:59:58".
Bin da schon selber darüber gestolpert weil ich dachte es kommt nichts an.

[Thowe]

Hallo Heiko,
wieder ein Danke für die schnelle Antwort. Sorry, meine Fehler.
Mit

Code Auswählen Erweitern

select * from history where device = 'Tagesgesamtenergieaufnahme_NT';
wird der in der Zukunft liegende Eintrag nicht angezeigt - zumindest mit mysql. Alles OK, der DB-Eintrag wurde geschrieben.

Mit dem Notify übertrage ich den Summenwert in einen Dummy, weil ich mehrere DB-Summationen mit Tagesgesamtenergieaufnahme_NT ausführe. Ich ging davon aus, dass das Event erst gesetzt wird, wenn auch der DB-Eintrag abgesetzt wurde. Ich hätte auch readingRename benutzen können, aber das ändert die gesamte DB. Deshalb benenne ich den von dbrep in die DB eingetragenen Wert mit sqlCmd update ... um (hatte ich im Post weggelassen).
Das Notify funktioniert jetzt. Ich hatte im Suchmuster das abschließende .* unterlassen, da kommt ja noch der Readingvalue...

Viele Grüße,
Thowe

[DS_Starter]

sehr schön 

Aber geht die Übertragung zum dummy nicht einfacher ?

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Reading_von_DbRep_nach_Dummy_.C3.BCbertragen

LG
Heiko

[Thowe]

Hallo Heiko,

danke für den Tipp. Abgesehen von den längeren Device-/Reading-Bezeichnern entsprechen sich die Dummy-Übertragungen?
Eine Alternative wäre, den Dummy mit DbReadingsVal zu befüllen. Aber da kann wegen asynchronem Schreibzugriff der aktuelle Wert noch fehlen, d.h. ich müsste erst ein commit erzwingen. Da erscheint mir Deine Methode aus dem Wiki besser.
Und um den Wert in der DB nicht doppelt zu haben, entweder Dummy loggen und Timestamp anpassen oder vom dbrep-Eintrag Device und Reading umbenennen.

Viele Grüße,
Thowe

[DS_Starter]

DercWiki Beitrag ist schon etwas älter. Inzwischen gibt es das Attr userExitFn mit dem man ein paar feine Sachen machen kann, etwas perl Kenntnisse vorausgesetzt. Wenn das etwas für dich wäre können wir heute Abend nochmal schreiben.

LG

[Thowe]

Hallo Heiko,

das Bessere ist der Feind des Guten...
Perl beherrsche ich nicht, aber das ist kein Hinderungsgrund. Die userExitFn habe ich in Anwendungsbeispielen gesehen. D.h. als dritte Alternative führe ich die DB-Aktion (z.B. Monatssumme) ohne writeToDB aus und schreibe in der Exitfunktion den Wert in den Dummy und unter dessen Device-Bezeichner mit INSERT in die DB? Generiert der Dummy ein Event während der Abarbeitung der Exitfunktion oder erst nach deren Abschluss?

Das Problem ist letztendlich hausgemacht: Ich muss über ein identisches Device/reading mit gleicher Aggregation aber unterschiedlichen Zeitbereichen in der DB unterscheidbare Einträge erzeugen, Beispiel: Monatsertrag und Vergleichsmonatsertrag.

Noch eine Frage: Ist die writeToDB-Opperation bei Eintritt in die Exitfunktion abgeschlossen, bzw. würde in der Exitfunktion eine Operation auf einer asynchronen DB-Instanz erst nach dem writeToDB-Zugriff ausgeführt werden?

Und wo ich gerade am Fragen bin: Ich bekomme im Ablauf von mehreren aufeinander abfolgenden DB-Operation mit dbrep mitunter:

Code Auswählen Erweitern

WARNING - old process nnnn will be killed now to start a new BlockingCall
Kann das zu Datenverlust führen?

Viele Grüße,
Thowe