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

DS_Starter · 14 März 2019, 10:22:32

Naja, es sind eigentlich Zeichen, die ausgewertet werden. Aber wenn man ein Zeichen mit einem Byte gleichsetzt stimmen Byte im Großen und Ganzen.

supergrobi · 14 März 2019, 11:04:07

Wow !

... bin jetzt bei ~19 min, 17 min ohne compress
RAM Max war hier bei 1618 MB, Load bei ~0.9
damit kann man leben

danke !

Code Auswählen

Attributes:
   aggregation day
   allowDeletion 1
   device     LaCrosse_3E
   dumpCompress 1
   dumpMemlimit 500000000
   dumpSpeed  4000000
   group      DBLog
   reading    temperature
   room       Energy,System
   timestamp_begin current_day_begin
   timestamp_end current_day_end
   verbose    1

Code Auswählen

   READINGS:
     2019-03-14 10:54:35   DumpFileCreated ./log/fhem_2019_03_14_10_35.sql.gzip
     2019-03-14 10:54:35   DumpFileCreatedSize 113.66 MB
     2019-03-14 10:54:35   DumpFilesDeleted fhem_2019_03_13_10_04.sql.gzip
     2019-03-14 10:54:35   DumpRowsCurrent 6651
     2019-03-14 10:54:35   DumpRowsHistory 11360885
     2019-03-14 10:54:35   background_processing_time 1124.5978
     2019-03-14 10:54:35   state           Database backup finished

... läuft auf nem TinkerBoard mit 2GB Ram

Thowe · 28 März 2019, 12:15:58

Hallo Heiko,
nach einem set Rep_HH_Eingangsleistung_delete_older delEntries mit:

Code Auswählen

define Rep_HH_Eingangsleistung_delete_older DbRep DBLogging
setuuid Rep_HH_Eingangsleistung_delete_older 5c9c935b-f33f-7c4f-2e23-094ad81859f7bee8
attr Rep_HH_Eingangsleistung_delete_older allowDeletion 1
attr Rep_HH_Eingangsleistung_delete_older device HH_Eingangsleistung
attr Rep_HH_Eingangsleistung_delete_older reading state
attr Rep_HH_Eingangsleistung_delete_older showproctime 1
attr Rep_HH_Eingangsleistung_delete_older timeOlderThan d:14

verbleiben in der DB:

Code Auswählen

mysql> select distinct date(timestamp), device, reading from history where device = 'HH_Eingangsleistung' and reading = 'state'; 
+-----------------+---------------------+---------+
| date(timestamp) | device              | reading |
+-----------------+---------------------+---------+
| 2019-03-02      | HH_Eingangsleistung | state   |
| 2019-03-03      | HH_Eingangsleistung | state   |
| 2019-03-04      | HH_Eingangsleistung | state   |
| 2019-03-05      | HH_Eingangsleistung | state   |
| 2019-03-06      | HH_Eingangsleistung | state   |
| 2019-03-07      | HH_Eingangsleistung | state   |
| 2019-03-08      | HH_Eingangsleistung | state   |
| 2019-03-09      | HH_Eingangsleistung | state   |
| 2019-03-10      | HH_Eingangsleistung | state   |
| 2019-03-11      | HH_Eingangsleistung | state   |
| 2019-03-12      | HH_Eingangsleistung | state   |
| 2019-03-13      | HH_Eingangsleistung | state   |
| 2019-03-14      | HH_Eingangsleistung | state   |
| 2019-03-15      | HH_Eingangsleistung | state   |
| 2019-03-16      | HH_Eingangsleistung | state   |
| 2019-03-17      | HH_Eingangsleistung | state   |
| 2019-03-18      | HH_Eingangsleistung | state   |
| 2019-03-19      | HH_Eingangsleistung | state   |
| 2019-03-20      | HH_Eingangsleistung | state   |
| 2019-03-21      | HH_Eingangsleistung | state   |
| 2019-03-22      | HH_Eingangsleistung | state   |
| 2019-03-23      | HH_Eingangsleistung | state   |
| 2019-03-24      | HH_Eingangsleistung | state   |
| 2019-03-25      | HH_Eingangsleistung | state   |
| 2019-03-26      | HH_Eingangsleistung | state   |
| 2019-03-27      | HH_Eingangsleistung | state   |
| 2019-03-28      | HH_Eingangsleistung | state   |
+-----------------+---------------------+---------+
24 rows in set (45.43 sec)

Lt. Logdaten wird der Befehl wie folgt umgesetzt:

Code Auswählen

2019.03.28 12:01:16 4: DbRep Rep_HH_Eingangsleistung_delete_older - SQL execute: delete FROM history where DEVICE = 'HH_Eingangsleistung' AND READING = 'state' AND TIMESTAMP >= '1970-01-01 01:00:00' AND TIMESTAMP <= '2019-03-02 12:01:15' ;

Der jüngere Timestamp müsste auf '2019-03-14 12:01:15' gesetzt sein, oder?

DS_Starter · 28 März 2019, 12:46:52

Bin auch deiner Meinung. Mach mir mal bitte einen verbose 4 Auszug mit dem gleichen Befehl.
Also komplett ab dem Start des Befehls. Da kommen noch ein paar Zeilen vorher.

DS_Starter · 28 März 2019, 15:16:59

Hallo Thowe,

jetzt habe ich ein Rep-Device bei mir identisch zu deinem konfiguriert und laufen lassen.
Bei mir wird der Select korrekt aufgebaut (wird natürlich nichts gelöscht weil ich diese Datensätze nicht habe):

Code Auswählen


2019.03.28 15:08:48.470 4: DbRep Test - -------- New selection --------- 
2019.03.28 15:08:48.471 4: DbRep Test - Command: delEntries 
2019.03.28 15:08:48.472 4: DbRep Test - timeOlderThan - year: , day: 14, hour: , min: , sec:  
2019.03.28 15:08:48.473 4: DbRep Test - Year 2016 is leap year
2019.03.28 15:08:48.473 4: DbRep Test - Timestamp begin human readable: 2016-04-10 07:00:00
2019.03.28 15:08:48.474 4: DbRep Test - Time difference to current time for calculating Timestamp end: 1213201 sec
2019.03.28 15:08:48.475 4: DbRep Test - Timestamp end human readable: 2019-03-14 14:08:47
2019.03.28 15:08:48.475 4: DbRep Test - Aggregation: no
2019.03.28 15:08:48.509 4: DbRep Test - SQL execute: delete FROM history where DEVICE = 'HH_Eingangsleistung' AND READING = 'state' AND TIMESTAMP >= '2016-04-10 07:00:00' AND TIMESTAMP <= '2019-03-14 14:08:47' ;
2019.03.28 15:08:48.605 3: DbRep Test - Entries of fhemtest.history deleted: HH_Eingangsleistung--state--0

Verwendung findet die aktuell eingecheckte Version 8.17.0. Welchen Wert ? siehst du denn bei dir von:

Code Auswählen

Time difference to current time for calculating Timestamp end: 1213201 sec

DS_Starter · 28 März 2019, 18:43:52

Ich habe weitergeforscht und einen Kalkulationsfehler bei der Berücksichtigung von Schaltjahren identifiziert.
Melde mich wieder mit einer Korrekturversion.

DS_Starter · 28 März 2019, 22:17:09

Hallo Thowe,

ich habe die Berücksichtigung der Schaltjahre korrigiert und etliche Kombinationen durchgetestet.

Die Version kannst du hier aus dem contrib zum Testen herunterladen:

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

Danach auf jeden Fall restarten !

Grüße
Heiko

Thowe · 29 März 2019, 13:47:27

Hallo Heiko,
Danke für die schnelle Reaktion. Mit 18.7.2 wurde der richtige jüngere Timestamp berechnet.

Ich habe mir die Logdaten nochmal angesehen vom Zeitraum, bevor der Fehler auftrat. Es gab während der Initialisierungsphase tatsächlich einen DB-Neustart, so dass eine Erklärung für den Fehler auch sein könnte, dass DbRep_getInitData von Rep_HH_Eingangsleistung_delete_older nicht korrekt beendet wurde.

Viele Grüße,
Thowe

DS_Starter · 29 März 2019, 14:02:59

Hi Thowe,

danke für deine Rückmeldung. Ungeachtet dessen hast du mich dadurch auf einen Fehler in der Schaltjahrberücksichtigung aufmerksam gemacht

Werde die Version einchecken, sodass sie morgen früh im Update verfügbar ist.
Falls dir noch etwas auffallen sollte melde dich gerne wieder.

Grüße,
Heiko

DS_Starter · 01 April 2019, 23:33:03

Hallo zusammen,

ich habe im DbRep die Aggregation "year" eingebaut. Damit ist es nun möglich, Auswertungen und Vergleiche auf Kalenderjahr-Ebene einzustellen.

Wie gewöhnlich wieder zunächst aus dem contrib laden zum Test wer möchte:

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

Grüße
Heiko

DS_Starter · 27 April 2019, 23:52:07

Ich habe soeben die Version 8.20.0 eingecheckt. Mit dieser Version gibt es ein "set ... index" Command mit dem man leicht die benötigten Indexe für DbLog und DbRep managen kann.

* index <Option> - Listet die in der Datenbank vorhandenen Indexe auf bzw. legt die benötigten Indexe an. Ist ein Index bereits angelegt, wird er erneuert (gelöscht und erneut angelegt)

Die möglichen Optionen sind:

list_all    : listet die vorhandenen Indexe auf
recreate_Search_Idx : erstellt oder erneuert (falls vorhanden) den Index Search_Idx in Tabelle history (Index für DbLog)
drop_Search_Idx    : löscht den Index Search_Idx in Tabelle history
recreate_Report_Idx : erstellt oder erneuert (falls vorhanden) den Index Report_Idx in Tabelle history (Index für DbRep)
drop_Report_Idx    : löscht den Index Report_Idx in Tabelle history

Die Version ist morgen früh im Regelupdate verfügbar.

Grüße,
Heiko

kadettilac89 · 29 Mai 2019, 21:12:34

Zitat von: DS_Starter am 26 Februar 2018, 23:51:54
Es werden alle Datensätze übertragen, die durch Timestamp-Attribute bzw. die Attribute "device", "reading" bestimmt sind.
Die Datensätze werden dabei in Zeitscheiben entsprechend der eingestellten Aggregation übertragen. Hat das Attribut "aggregation" den Wert "no" oder "month", werden die Datensätze automatisch in Tageszeitscheiben zur Standby-Datenbank übertragen. Quell- und Standby-Datenbank können unterschiedlichen Typs sein.

Die zur Steuerung der syncStandby Funktion relevanten Attribute sind:

aggregation    : Einstellung der Zeitscheiben zur Übertragung (hour,day,week)
device      : Übertragung nur von Datensätzen die <device> enthalten
reading      : Übertragung nur von Datensätzen die <reading> enthalten
time.*      : Attribute zur Zeitabgrenzung der zu übertragenden Datensätze.

LG,
Heiko

Hallo Heiko,

ich bin durch einen deiner Posts in eine anderen Forum auf die Funition gestoßen. Wenn ich meine DB in eine andere syncen will - Initialload mit device .* - erhalte ich fortlaufend Fehler.

Code Auswählen


DBD::mysql::st execute failed: Incorrect datetime value: '2015-03-29 02:08:40' for column 'TIMESTAMP' at row 1 at ./FHEM/93_DbRep.pm line 10407.

Wenn ich den Lauf wiederhole kommt der selbe Fehler. Wenn ich den entsprechenden Eintrag lösche findert er immer wieder weitere. Meine DB hat etwa 750.000 Sätze. In der RemoteDB wurden ungefähr 150.000 übertragen, es ist also kein genereller Fehler. Der Fehler sagt, dass Timestamp falsches Format hat, es entspricht aber dem ISO-Format der DB.

Irgend eine Idee? Habe dir 2 SQL-Files angehängt falls du die genauen Daten sehen willst. Ein Datensatz der erfolgreich geladen wurde ist auch angehängt. Ich sehe hier keinen Unterschied im Timestamp.

Wo muss ich ein "or die" setzen damit im Fehlerfall weiter geladen wird und ein Fehler im Log erscheint.

Danke schon mal!

DS_Starter · 30 Mai 2019, 07:17:31

Guten Morgen,

ad hoc habe ich noch keine Idee, schaue es mir aber gerne (morgen

) an.
Gib mir mal bitte noch die Releases der Quell- und Zieldatenbank. Ich muss wahrscheinlich in dieser Richtung forschen.

ZitatWo muss ich ein "or die" setzen damit im Fehlerfall weiter geladen wird und ein Fehler im Log erscheint.

Meinst du damit, dass die fehlerhaften Sätze einfach übersprungen werden (mit Log-Info) aber der Prozess weiterlaufen soll ?
Also "or die" ist eine schlechte Idee. Ich würde mir aber gleich mit Gedanken machen ob/wie man dem Befehl eine solche Option mitgeben kann.

Edit: Noch eine Frage. Siehst du bei den besagten Datensätzen beim Timestamp irgendwelche zusätzlichen Zeichen wenn du ein Admintool (phpmyAdmin etc.) benutzt ? Ich vermute als ersten Ansatz dass in diesen Feldern irgenwelchen Steuerzeichen mit drin sind, wie auch immer die dort reingekommen sein könnten.

Danke und einen schönen Feiertag !

Grüße,
Heiko

kadettilac89 · 30 Mai 2019, 08:24:30

Hallo Heiko,

dir auch einen schönen Feiertag und danke für das Angebot, ich erwarte gar keine Anpassung im Modul, hätte einfach die Fehler übersprungen und weiter gearbeitet. Das Ganze eilt nicht.

Den Fehler habe ich gefunden. "Daylight saving time" sprich Sommerzeit. Meine Systeme laufen alle auf CET/CEST [edit Mischung UTC/CET s. u.] und da gibt / gab es das Problem, dass durch Verzögerung ein paar Sätze zu nicht existierenden Zeiten geschrieben wurden, es geht nur um ein paar Sekunden (02:00:08). Ich lösche die Sätze einfach und gut.

Beide Datenbanken sind MariaDB 10 (MySql).

Noch 2 Fragen zu der Bedienung ...
- Gibt das Modul im Erfolgsfall ein Event aus, in dem auch syncStandby vorkommt? Oder sehe ich irgend wo den Zeitpunkt der letzten erfolgreichen Syncronisierung?
- wie müsste ich time.* setzen damit z. B. timestamp >= 2019-05-28 10:00:00 übertrage?

Edit: eine Datenbank läuft in Docker (Original) und da ist Systemzeit UTC, die andere auf der Synology (STandby), da ist Systemzeit CET ... muss mal schaun, irgend was mit "--skip-tz-utc"

DS_Starter · 30 Mai 2019, 08:56:08

ZitatDen Fehler habe ich gefunden. "Daylight saving time" sprich Sommerzeit.

Ah, interessant. Heißt für mich Problem an sich gelöst ?

ZitatGibt das Modul im Erfolgsfall ein Event aus, in dem auch syncStandby vorkommt? Oder sehe ich irgend wo den Zeitpunkt der letzten erfolgreichen Syncronisierung?

Ja, es gibt das Reading "number_lines_inserted_Standby", welches nach jedem erfolgreichen Sync aktualisiert wird. Daraus kannst du ja auch den jeweiligen Zeitpunkt ableiten (FHEM ReadingsTimestamp).
Alternativ könntest du im Attribut "executeAfterProc" einen FHEM Trigger Befehl (https://fhem.de/commandref_DE.html#trigger) absetzen der einen Event erzeugt den du möchtest. Im Attribut "executeAfterProc" kannst du beliebige FHEM-Befehle oder eine eigene Perl-Routine abarbeiten lassen.

Zitatie müsste ich time.* setzen damit z. B. timestamp >= 2019-05-28 10:00:00 übertrage?

Das wäre:

Code Auswählen


attr <Name> timestamp_begin 2019-05-28 10:00:00

Wenn du Verbesserungen siehst, lass es mich gerne wissen.

EDIT: Attr changed

LG,
Heiko