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

[abc2006]

Hi,
ich hab ein Geschwindigkeits-Issue bemerkt:

mit phpmyadmin:
select * from history limit 1;
Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0522 Sekunden.)

mit DbRep:
state running 2017-12-15 17:17:21
( jetzt ist es mittlerweile 17:22:46)

Es laufen drei weitere tw. große Abfragen auf die Datenbank. Aber dass phpmyadmin *soo* viel schneller ist...

Grüße.
Stephan

[DS_Starter]

Mein DbRep ist sogar noch schneller als dein phpMyAdmin. Guckst du:

Readings
SqlResultRow_1                                   2017-12-01 22:46:09|sysmon|SYSMON|stat_cpu2_percent: 0.30 0.00 0.17 99.53 0.00 0.00 0.00|stat_cpu2_percent|0.30 0.00 0.17 99.53 0.00 0.00 0.00|                                                                          2017-12-15 19:08:40
background_processing_time               0.0336                                    2017-12-15 19:08:40
sqlCmd                                                  select * from history limit 1;   2017-12-15 19:08:40
sqlResultNumRows                                1                                            2017-12-15 19:08:40
sql_processing_time                             0.0319                                    2017-12-15 19:08:40
state                                                     done                                       2017-12-15 19:08:40

Grüße
Heiko

[choenig]

Hi Heiko,

vielen Dank erstmal für das 'delSeqDoublets', sowas suche ich schon lange .

Ich habe aber Probleme mit Strings, die ' oder " enthalten, solche werden nicht gelöscht und erzeuge Fehler.

Lösung für ' ist um Zeile ~3995 herum das $val zu escapen:

Code Auswählen Erweitern

$val =~ s/'/''/g; # escape ' with '' for MySQL

Edit: Das selbe sollte auch für die $read gemacht werden (mindestens).

Das Problem mit " rührt daher, dass Du in Zeile 3995 alle " und \n löscht:

Code Auswählen Erweitern

$val =~ tr/"\n"//d;

Ich kann leider nicht nachvollziehen, wieso Du das machst, entferne ich aber die " dann funktioniert es erstmal für meine betroffenen Strings aus dem SONOS Umfeld. Falls es aber Einträge mit \n gibt, würden die vermutlich weiterhin nicht gelöscht werden.

LG
Christian

[choenig]

Hi,

ich habe leider noch ein Problem gefunden, ausgelöst durch krude Werte von Pushover:

Folgender Eintrag in der history-Tabelle führt zu einem Fehler:

Code Auswählen Erweitern


+---------------------+----------+----------+---------------------------------------------------------------------------------------------------------+------------------------------------------------------------+--------------------------------------+------+
| TIMESTAMP           | DEVICE   | TYPE     | EVENT                                                                                                   | READING                                                    | VALUE                                | UNIT |
+---------------------+----------+----------+---------------------------------------------------------------------------------------------------------+------------------------------------------------------------+--------------------------------------+------+
| 2017-10-14 11:53:23 | Pushover | PUSHOVER | msg title='' device='my_iPhone6:' priority=0 url_title="" message='status_EG.Eingang.Briefkasten: dead' | msg title='' device='my_iPhone6:' priority=0 url_title=""  | dead'                                |      |


Hier der ausgeführte SQL-Query:

Code Auswählen Erweitern

2017.12.17 11:39:05.739 4: DbRep dbRep__full - SQL execute: delete FROM history where TIMESTAMP = 'title='' device='my_iPhone6:' priority=0 url_title=""  2017-10-14 11:53:23' AND DEVICE = 'Pushover' AND READING = 'msg' AND VALUE ='dead''';


Code Auswählen Erweitern

DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'my_iPhone6:' priority=0 url_title="" 2017-10-14 11:53:23' AND DEVICE = 'P' at line 1 at ./FHEM/93_DbRep.pm line 4006

(Die Zeilennummer kann durch hinzugefügte Log-Einträge von mir von der svn-Version abweichen!)

Hier enden leider mein Perl-Skills, so dass ich nur den Fehler reporten kann .

LG
Christian

[DS_Starter]

Hi Christian,

danke für die Mitteilungen. Ich schaue mir das in Ruhe an.
Dazu muss ich mir mal solche verqueren Datensätze in der DB erzeugen.
Melde mich wieder ...

Grüße
Heiko

[choenig]

Hi Heiko,

vielen Dank

Als workaround habe ich jetzt erstmal das Leerzeichen im Timestamp direkt escaped, dann funktioniert der Rest:

Code Auswählen Erweitern

@row_array = map { $_->[0]."_ESC_".$_->[1]."_ESC_".($_->[2] =~ s/ /_ESC_/r)."_ESC_".$_->[3]."\n" } @{$sth->fetchall_arrayref()};


Und dazu natürlich noch die Zeile auskommentiert:

Code Auswählen Erweitern

#     s/ /_ESC_/ for @row_array;             # Leerzeichen in TIMESTAMP escapen

LG
Christian

[DS_Starter]

Hallo Christian, @all,

da ich gerade dabei war die DbRep-Version 7.0.0 zu erstellen, habe ich mich entschieden den Fix gleich in dieser Version mit einzubauen.

@row_array = map { $_->

• ."_ESC_".$_->[1]."_ESC_".($_->[2] =~ s/ /_ESC_/r)."_ESC_".$_->[3]."\n" } @{$sth->fetchall_arrayref()};

Das erleichtert den Ablauf Christian, habe ich gleich so übernommen.

Ansonsten habe ich das Escapen von ' in device/reading gleich in den anderen Funktionen auch verallgemeinert. Es wird zwar (hoffentlich) nicht allzu oft vorkommen dass solche kruden Datensätze geloggt werden ... aber man weiß ja nie.

Außer deinem Fix (danke für den Änderungsvorschlag !) habe ich in der V7.0.0 noch folgendes getan:

* neues Kommando get blockinginfo
  Damit kann man sich systemweit die laufenden BlockingCalls anschauen. Die Ausgabe erfolgt als Tabelle mit gekürzten Informationen falls zuviel Daten
  angezeigt werden sollten (Schutz vor Browserlock)

* Wenn keine Zeitgrenzen UND keine Aggregation angegeben ist, wird auf die Verwendung von Timestamp-Vergleichen im Select verzichtet.
  Das bringt in diesen Fällen Geschwindigkeitsvorteile.

* DbRep-Device erkennt nun wenn das verbundene DbLog-Device die Verbindung zur DB temporär geschlossen hat (reopen xxx läuft) und führt keine
  Aktivitäten aus (Mitteilung in Log und state)

* weitere Codereviews

Ist im ersten Beitrag enthalten und bitte wie immer rege Rückmeldung 

Grüße,
Heiko

[choenig]

Hallo Heiko,

ich werde die neue Version ausprobieren, heute aber nicht mehr, hoffentlich morgen. Ich gebe Dir dann Feedback.

Danke für's schnelle fixen .

LG
Christian

[JoeALLb]

Hallo Zusammen!

Ich hätte noch einen Wunsch an delSeqDoublets.
Ich habe viele Temperatursensoren, die manchmal leider um 0.01° nach oben und unten schwanken.
Diese Genauigkeit benötige ich nur am aktuellen Tag, an älteren Tagen jedoch nicht.

Schön wäre es also, wenn ich bei delSeqDoublets angeben könnte, welche Value-Abweichung ignoriert wird und als "Doublets" angesehen wird.

Danke für das neuen Feature!!!

sG und frohe Weihnachten euch allen!
Joe

Edit: Also so etwas wie "diffAccept" für delSeqDoublets, welches jedoch auch Float-Zahlen erlaubt.

[DS_Starter]

Hi Joe,

Schön wäre es also, wenn ich bei delSeqDoublets angeben könnte, welche Value-Abweichung ignoriert wird und als "Doublets" angesehen wird.

Ja, schaue ich mir mal an. Wird aber sicherlich erst nach den Feiertagen.

viele Grüße und ebenfalls schöne Festtage allen !

Grüße
Heiko

[choenig]

Hallo Heiko,

hab Deine neue Version jetzt (endlich) ausprobiert, und sie läuft einwandfrei .

Vielen Dank!

LG und frohe Weihnachten
Christian

[abc2006]

Hi,
hab grade festgestellt, dass das dbRep-Modul trotz "disable 1" weiterhin versucht, die Datenbank zu erreichen:

Code Auswählen Erweitern

Internals:
   DATABASE   fhem
   DEF        logdb
   LASTCMD     
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         46
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      disconnected
   TYPE       DbRep
   UTF8       1
   VERSION    7.0.0
   HELPER:
     DBLOGDEVICE logdb
   READINGS:
     2017-12-25 15:26:17   state           disconnected
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION db.conf
     DEF        db.conf neversaveanything
     MODE       synchronous
     MODEL      MYSQL
     NAME       logdb
     NR         20
     NTFY_ORDER 50-logdb
     PID        30284
     REGEXP     neversaveanything
     STATE      disconnected
     TYPE       DbLog
     UTF8       1
     VERSION    3.5.0
     dbconn     mysql:database=fhem;host=localhost;port=3306
     dbuser     fhemuser
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   initialized
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2017-12-25 15:26:18   state           disconnected
     cache:
       index      0
Attributes:
   disable    1

Code Auswählen Erweitern

2017.12.25 15:27:26 3: DbRep repdb - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2017.12.25 15:27:26 3: DbRep repdb - Waiting for database connection

ich hätte das nicht erwartet... ich dachte, disable = mach gar nix mehr, sei nur noch definiert...

Grüße,
Stephan

[DS_Starter]

Hi Stephan,

folgt nur aus einem Testvorgang. Aber du hast recht .... ich fixe das nach den Feiertagen.

Grüsse,
Heiko

[DS_Starter]

Hallo zusammen,

ich habe die V7.2.0 im ersten Beitrag bereitgestellt.
Darin sind enthalten:

* bugfix für disable=1 (von Stephan gemeldet)

* neues Zeit-Attribut "timeYearPeriod"
   Mit Hilfe dieses Attributes wird eine jährliche Zeitperiode für die Datenbankselektion bestimmt. Die Zeitgrenzen werden zur Ausführungszeit dynamisch 
   berechnet. Es wird immer eine Jahresperiode bestimmt. Eine unterjährige Angabe ist nicht möglich.
   Dieses Attribut ist vor allem dazu gedacht Auswertungen synchron zu einer Abrechnungsperiode, z.B. der eines Energie- oder Gaslieferanten,
   anzufertigen.

    Beispiel:

    attr <DbRep-device> timeYearPeriod 06-25 06-24

    # wertet die Datenbank in den Zeitgrenzen 25. Juni AAAA bis 24. Juni BBBB aus.
    # Das Jahr AAAA bzw. BBBB wird in Abhängigkeit des aktuellen Datums errechnet.
    # Ist das aktuelle Datum >= 25. Juni und =< 31. Dezember, dann ist AAAA = aktuelles Jahr und BBBB = aktuelles Jahr+1
    # Ist das aktuelle Datum >= 01. Januar und =< 24. Juni, dann ist AAAA = aktuelles Jahr-1 und BBBB = aktuelles Jahr

* neues Attribut "seqDoubletsVariance" (Joe)
   akzeptierte Abweichung (+/-) für das Kommando "set <Name> delSeqDoublets".
   Der Wert des Attributs beschreibt die Abweichung bis zu der aufeinanderfolgende numerische Werte (VALUE) von Datensätze als gleich angesehen und
   gelöscht werden sollen. "seqDoubletsVariance" ist ein absoluter Zahlenwert, der sowohl als positive als auch negative Abweichung verwendet wird.

    Beispiele:
    attr <Name> seqDoubletsVariance 0.0014
    attr <Name> seqDoubletsVariance 1.45

Viel Spaß beim Test und gerne Feedback.

viele Grüße
Heiko

[blaxbox]

Hallo zusammen,

also entweder habe ich einen grundlegenden Denkfehler, oder es stimmt wirklich was nicht dem timestamp "previous_month_begin" bzw. "previous_month_end".
Mir ist es nur aufgefallen, da JETZT ja Jänner ist und ich in timestamp_begin "previous_month_begin" verwende. Hier ist neuerdings FHEM komplett gecrashed u. ich habe nach einigem suchen nur die banale Meldung im log gefunden:

Month '12' out of range 0..11 at ./FHEM/93_DbRep.pm line 1314.

Das hat mich dann stutzig gemacht u. hätte da in 93_DbRep.pm tatsächlich gefunden, dass bei "previous_month_begin" bzw. "previous_month_end" das monat nach "12" gesetzt wird, und nicht auf "11". Codesnip: $rmon  = ($mon-1<0)?12:$mon-1;
timelocal kann meines Wissens aber nur Werte von 0-11.
Ich habe das bei mir einmal auf "11" geändert - und es funktioniert so wie es soll (analog natürlich auch bei "previous_month_end").

Vielleicht kann mir hier jemand sagen ob dies tatsächlich ein Fehler ist, oder ich nur wieder einmal ums Eck denke....

Grüsse