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

[DS_Starter]

Hallo zusammen,

zur Info.
Ich habe hier https://forum.fhem.de/index.php/topic,62998.0.html den Diskussionsthread zum non-blocking DbLog aufgemacht.

Wer mag kann mit testen und verbessern.

wünsche noch einen schönen Abend
Heiko

[DS_Starter]

Hallo zusammen,

weil ich heute darüber gestolpert bin habe ich DbRep noch mit der Funktion "set ... readingRename <alter Reading Name>,<neuer Reading Name>" ergänzt.
Es funktioniert genau wie "deviceRename" nur dass die alten Readings in der Datenbank in den neuen Namen umbenannt werden.
Vielleicht hilft es manchmal. Version 4.9 im Eingangsbeitrag.

Grüße
Heiko

[DerFrickler]

Hallo,

ich habe mal gemäß wiki ein kontinuierliches Löschen einzelner Datensätze in der DB aufgesetzt

Als Argument der Attribute "device" bzw. "reading" können SQL-Wildcards "%" bzw. "_" verwendet werden.
und habe mich immer gewundert warum nichts gelöscht wird.

Folgenden Hinweis habe ich gerade nach einem Restart im Log gefunden:

2016.12.27 22:57:44 3: WARNING: unsupported character in reading window.sensor.% (not A-Za-z/\d_\.-), notify the DbRep module maintainer.

Mit der Aufforderung den DbRep module maintainer zu benachrichtigen. Das mache ich jetzt mal mit der Frage was ich da möglicherweise falsch gemacht habe.

Gruß!

[DS_Starter]

Guten Morgen,

hier sind zwei Dinge die wir auseinanderhalten müssen.
Im Wiki, Asche auf mein Haupt, habe ich fälschlicherweise bei der Löschfunktion die Verwendungsmöglichkeit von Wildcards in Readings/devices angegeben. Momentan habe ich die Abgrenzung noch Namensscharf, d.h. ohne Wildcards implementiert.
Ich wollte es tun, war aber aus Sicherheitsgründen davon abgekommen damit man nicht ungewollt mehr löscht als beabsichtigt. Stellt sich die Frage ob ich den Wikieintrag anpasse oder tatsächlich Wildcards in der Löschfunktion erlaube.

Was wäre denn deine Meinung dazu ?

Die andere Sache ist die Warnung bzgl. verwendeter Zeichen in Readings. Hier geht es um die generierten Readings die in einem DbRep-Device als Selektion aus der DB generiert werden.
Es muß also bei dir ein DbRep-Device geben welches solche Readings mit unerlaubten Sonderzeichen enthält. Das hat aber nichts mit Wildcards in den Attributen device/reading zu tun. Du kannst auch in ../log/fhem.save danach suchen.
Gib mal ein paar mehr Infos wenn du den "schuldigen" gefunden hast.

Grüße
Heiko

[DerFrickler]

Es muß also bei dir ein DbRep-Device geben welches solche Readings mit unerlaubten Sonderzeichen enthält. Das hat aber nichts mit Wildcards in den Attributen device/reading zu tun. Du kannst auch in ../log/fhem.save danach suchen.

nicht nur eins... Meine "Naming Convention" legt fest dass jedes Gerät mit dem Typ beginnt... z.B. die Heizkörperthermostate mit radiator.thermostat. und die Wandthermostate mit wall.thermostat.. Klever wäre jetzt sicherlich gewesen das thermostat an den Anfang zu setzten, aber...
Und auf diese Art und Weise habe ich auch die Löschfunktionen generiert: radiator.thermostat.% und wall.thermostat.%... Das ganze zieht sich dann abgesehen von den meter.reading.s durch das ganze System.

Hier als Beispiel mal den Fenstersensor Eintrag wie oben genannt:

Internals:
   CFGFN
   DATABASE   fhem
   DEF        DbLog
   LASTCMD    delEntries
   NAME       DbRep.Del.window.sensor
   NOTIFYDEV  global,DbRep.Del.window.sensor
   NR         438
   NTFY_ORDER 50-DbRep.Del.window.sensor
   ROLE       Client
   STATE      done
   TYPE       DbRep
   VERSION    4.8.6
   Helper:
     DBLOGDEVICE DbLog
     Cv:
       aggregation no
       aggsec     1
       destr      2016-12-28
       dsstr      1970-01-01
       epoch_seconds_end 1482883793
       mestr      12
       msstr      01
       testr      01:09:53
       tsstr      01:00:00
       wdadd      345600
       yestr      2016
       ysstr      1970
   Readings:
     2016-12-28 01:10:00   state           done
     2016-12-28 01:10:00   window.sensor.% --  -- DELETED ROWS --  0
   Dbloghash:
     CFGFN
     CONFIGURATION /opt/fhem/DbLog.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/DbLog.conf .*:.*
     NAME       DbLog
     NR         17
     NTFY_ORDER 50-DbLog
     PID        9037
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=127.0.0.1;port=3306
     dbuser     fhem
     Helper:
       Dblog:
         Counthistory:
           Dblog:
             TIME       1482919059.06664
             VALUE      91795
     Readings:
       2016-12-28 10:57:39   countCurrent    113
       2016-12-28 10:57:39   countHistory    91795
       2016-12-12 23:39:10   lastReduceLogResult Rows processed: 0, deleted: 0, time: 0.00sec
       2016-12-15 00:00:00   lastRowsDeleted 0E0
       2016-12-27 22:57:36   state           connected
       2016-12-12 01:00:00   userCommand     "VACUUM history"
Attributes:
   alias      DbRep - 03 - Delete Device window.sensor.%
   allowDeletion 1
   comment    löschen aller Einträge:
countHistory
in DbLog älter als 7 Tage
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     window.sensor.%
   event-on-change-reading state
   group      DbLog
   room       06 Logging
   timeOlderThan 7

[DS_Starter]

Was die Löschfunktion betrifft:

Und auf diese Art und Weise habe ich auch die Löschfunktionen generiert: radiator.thermostat.% und wall.thermostat.%

Im Moment geht die Löschfunktion schief, weil das "%" im Device-Name "radiator.thermostat.%" nicht als Wildcard sondern als normales Zeichen gewertet und an die DB gesendet wird. Im Ergebnis wird ein Reading generiert:

Readings:
     2016-12-28 01:10:00   state           done
     2016-12-28 01:10:00   window.sensor.% --  -- DELETED ROWS --  0

welches den Devicenamen enthält -> "window.sensor.%". Das führt dann zu der Warnung bzgl. Sonderzeichen im Log.

Gibt es momentan zwei Varianten:

1. ich statte die Löschfunktion mit Wildcards aus
2. ich lasse das Modul so wie es es ist und passe den Wikieintrag an. In diesem Fall müsstest du die zu löschenden Devices konkret ageben was andererseits die Sicherheit erhöht (siehe meine Überlegungen zuvor)

Was denkst du ?

Achtung ! timeOlderThan  sind Sekunden !  d.h. timeOlderThan 7  würde alles älter 7 Sekunden löschen und nicht älter 7 Tage. -> Wohl gut dass es mit den Wildcards nicht funktioniert hat.

[DerFrickler]

1. ich statte die Löschfunktion mit Wildcards aus
2. ich lasse das Modul so wie es es ist und passe den Wikieintrag an. In diesem Fall müsstest du die zu löschenden Devices konkret ageben was andererseits die Sicherheit erhöht (siehe meine Überlegungen zuvor)

Ich würde die 1 wählen.

Gruß!

[DS_Starter]

Ok.
Ich stelle die neue Version kurzfristig wieder hier ein.
Melde mich ....

[DS_Starter]

Hallo,

habe die neue Version 4.10 wie gehabt angehängt.

Die Löschfunktion kann nun auch Wildcards % bzw. _ an die DB übergeben.
In dem Ergebnisreading der gelöschten Datensätze wird ein evtl. vorhandenes "%" durch "/" ersetzt um die Richtlinien für Readings entsprechend einzuhalten.

Probiers mal aus, bei mir habe ich es erfolgreich durchgeetestet.

Grüße
Heiko

[DerFrickler]

funktioniert gut!

Danke,
Karsten

[DS_Starter]

Thx Karsten für die Rückinfo.
Ich checke es ein.

Grüße
Heiko

[DerFrickler]

wenn ich jetzt von einer bestimmten Gerätegruppe switchable.socket.% alle Einträge älter 7 Tage, bis auf ein spezifisches energy_kWh löschen möchte, gibt es da eine einfache Kombi zwischen device und reading die das in einem Rutsch löst?

Gruß!

[DS_Starter]

Moin Karsten,

gibt es da eine einfache Kombi zwischen device und reading die das in einem Rutsch löst?

Ich wüßte keine auf Anhieb. SQL-Wildcards sind nicht so mächtig wie ein Perl-Regex, sondern nur einfache Platzhalter für ein oder mehrere Zeichen.
Das wird sich wahrscheinlich nicht ganz so simpel lösen lassen.

schönen Tag...
Heiko

[DS_Starter]

Hallo zusammen,

habe eine kleine Korrektur an der Funktion importFromFile vorgenommen. Unter bestimmten Umständen kam ein quote (") mit in die DB.
-> Version 4.10.1

Grüße
Heiko

[DerFrickler]

jetzt noch mal eine Frage zur Optimierung der DB... bei sqlite habe ich das über das userCommand "VACUUM history" gemacht, geht das bei sql auch so einfach? oder ist da noch was zu beachten?

Gruß!