93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

[Omega]

 
Danke!!! Funktioniert wie gewünscht

LG
Holger

[SusisStrolch]

Habe grade gesehen, dass bei meinem CUL-Devices einiges zu viel geloggt wird (Version 2.22.0):

Code Auswählen Erweitern

defmod logdb DbLog ./contrib/dblog/MariaDB10.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb cacheEvents 2
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 128
attr logdb disable 0
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 86400
attr logdb verbose 3


Der CUL:

Code Auswählen Erweitern

defmod miniCUL433 CUL 192.168.254.88:85 0000
attr miniCUL433 DbLogInclude state,uptime
attr miniCUL433 addvaltrigger 1
attr miniCUL433 comment freq: 433.940MHz, bWidth: 325kHz\
(bei 433.92: T1: -35,7kHz, T2: +42,3kHz, T3: +60,8kHz)\


Der Thermometer:

Code Auswählen Erweitern

defmod NC_WS_81 CUL_TCM97001 CUL_TCM97001_81
attr NC_WS_81 event-min-interval .*:300
attr NC_WS_81 event-on-change-reading .*
attr NC_WS_81 model NC_WS
attr NC_WS_81 room CUL_TCM97001

setstate NC_WS_81 T: 23.3 H: 24
setstate NC_WS_81 2017-08-03 15:36:15 battery low
setstate NC_WS_81 2017-08-03 15:36:15 channel 1
setstate NC_WS_81 2017-08-08 14:26:29 humidity 24
setstate NC_WS_81 2017-08-03 15:36:15 mode normal
setstate NC_WS_81 2017-08-08 14:26:29 state T: 23.3 H: 24
setstate NC_WS_81 2017-08-08 14:26:29 temperature 23.3


Und das dblog für dieses Device:

Code Auswählen Erweitern


TIMESTAMP    DEVICE TYPE EVENT READING VALUE UNIT
2017-08-08 14:17:44 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801B RAWMSG s51C90E91801B
2017-08-08 14:17:09 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:16:34 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:15:59 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:15:24 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:14:49 NC_WS_81 CUL_TCM97001 humidity: 24 humidity 24 %
2017-08-08 14:14:49 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:14:14 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:13:39 NC_WS_81 CUL_TCM97001 temperature: 23.3 temperature 23.3 °C
2017-08-08 14:13:39 NC_WS_81 CUL_TCM97001 state: T: 23.3 H: 24 state T: 23.3 H: 24
2017-08-08 14:13:39 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801E RAWMSG s51C90E91801E
2017-08-08 14:13:06 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:12:29 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801D RAWMSG s51C90E91801D
2017-08-08 14:11:54 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:11:19 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801D RAWMSG s51C90E91801D
2017-08-08 14:10:44 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918022 RAWMSG s51C90E918022
2017-08-08 14:10:09 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801E RAWMSG s51C90E91801E
2017-08-08 14:09:34 NC_WS_81 CUL_TCM97001 humidity: 24 humidity 24 %
2017-08-08 14:09:34 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:08:59 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:08:24 NC_WS_81 CUL_TCM97001 temperature: 23.3 temperature 23.3 °C
2017-08-08 14:08:24 NC_WS_81 CUL_TCM97001 state: T: 23.3 H: 24 state T: 23.3 H: 24
2017-08-08 14:08:24 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:07:51 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:07:14 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020


[DS_Starter]

Habe grade gesehen, dass bei meinem CUL-Devices einiges zu viel geloggt wird (Version 2.22.0)

Gehe ich richtig in der Annahme dass mit "einiges zu viel geloggt" die Einträge

Code Auswählen Erweitern


NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F


bzw. deren Häufigkeit, gemeint sind ?

Das diese Readings des Thermometers überhaupt in der DB sind ist soweit i.O. weil nicht über den Regex ausgeschlossen.
Anders verhält es sich mit der Häufigkeit. Anders als "state" und "humidity" die sich an die Frequenz vo 300 Sekunden halten, 
scheinen sich die Readings "RAWMSG" nicht darum zu scheren.

Ob geloggt wird oder nicht (bzgl. Intervall), wird durch einen Vergleich des letzten Logzeitpunkt des Readings und dessen Wert ermittelt.
Dazu gibt es in dem betreffenden Device einen Helpereintrag (list NC_WS_81) für das DbLog-Device:

Code Auswählen Erweitern


   Helper:
     DBLOG:
       Bezug_WirkP_Kosten_Diff:
         LogDB1:
           TIME       1502210951.26597
           VALUE      0.0000

 
Bei dir müßte es also etwas Vergleichbares für das Reading "RAWMSG" geben, wobei ich etwas unschlüssig bin ob es dieses Reading überhaupt gibt weil ich keinen setstate-Eintrag im Thermometer dafür erkennen kann.
Schau mal bitte mit list in dein Thermometer und suche nach "RAWMSG" und was dort drin steht (sollte ja z.B. "s51C90E91801F" sein).

Grüße
Heiko

[DS_Starter]

Die 93_DbLog: V2.22.1, new attribute "suppressAddLogV3" ist eingecheckt und morgen früh im Update.

Grüße
Heiko

[SusisStrolch]

RAWMSG ist ein internal.
Und DbLogExclude steht auf .*
Für die Thermometer gibt's kein explizites Include.

[DS_Starter]

RAWMSG ist ein internal.

Dann verstehe ich momentan nicht wieso dafür Events erzeugt werden denn nur die können ja geloggt werden. Üblicherweise erzeugt der Autor Events für Readings mit den dafür vorgesehenen fhem-Befehlen. Da könntest du mal in dem entsprechenden Unterforum nachfragen wie sich das verhält.

Und DbLogExclude steht auf .*

Das hast du aber im DbLog-Device selbst gesetzt. Das bedeutet, es würden alle Events missachtet die das DbLog-Device SELBST erzeugt (wenn es das tun würde). "DbLogExclude" bzw. "DbLogInclude" setzt du immer in der Quellen, d.h. den zu loggenden Devices.

Für die Thermometer gibt's kein explizites Include.

Das ist auch nicht nötig. Wie die einzelnen Attribute "DbLogExclude" bzw. "DbLogInclude" ausgewertet werden, sofern sie in den Quellen gesetzt sind, hängt von dem im DbLog-Device gesetzten Attribut "DbLogSelectionMode" ab. Ist es nicht gesetzt, wie in deinem Fall, gilt immer "Exclude" als Default .
Das heißt, solltest du irgendwo ein "DbLogInclude" gesetzt haben, würde es durch DbLog ignoriert.

Zitat aus der Commandref ->

DbLogSelectionMode
Dieses, fuer DbLog-Devices spezifische Attribut beeinflußt, wie die Device-spezifischen Attributes DbLogExclude und DbLogInclude (s.u.) ausgewertet werden.  Fehlt dieses Attribut, wird dafuer "Exclude" als Default angenommen.
       
Exclude: DbLog verhaelt sich wie bisher auch, alles was ueber die RegExp im DEF angegeben ist, wird geloggt, bis auf das, was ueber die RegExp in    DbLogExclude ausgeschlossen wird
Das Attribut DbLogInclude wird in diesem Fall nicht beruecksichtigt

Ich muß zugeben dass ich auch jedesmal dreimal über diesen Zusammenhang nachdenken muss und löse bisher alles über die Regex im DEF bzw. "event-on-change-reading" in den Quellen.

Also soweit ist mir alles klar was passiert, aber bzgl. des RAWMSG ist mir das momentan nicht transparent denn ein INTERNAL wirft allgemein keinen Event.

[DS_Starter]

@Virsacer, @all,

hier nochmal der Versuch die "Uninitialized" Meldungen in Zeile 737 zu beseitigen.
Bitte die V2.22.2 testen ob es diesmal ohne Nebeneffekte funktioniert. D.h. bitte die SVG Erstellung explizit testen.
Bei mir sieht es bis jetzt gut aus.

Grüße
Heiko

[Omega]

Hallo Heiko,

ich schon wieder

Ich bin gerade etwas am Optimieren. In der Definition meiner DB steht u.a., dass das Reading ,,state" geloggt werden soll. Dabei ist mir jetzt aufgefallen, dass ich auch viele state-Readings von diversen DOIFs und ATs habe, die ich aber nicht benötige. Ich habe daher in der DB (DbLogSelectionMode Exclude) ein

Code Auswählen Erweitern


attr <db> excludeDevs      speedtest,my_unifi_controller,TYPE=DOIF,TYPE=AT
gesetzt.

Für DOIF funktioniert es, für AT nicht. Getestet habe ich auch die Schreibweise: TYPE=(DOIF|AT). Hat auch nur für DOIF funktioniert. Auch ausschließlich TYPE=AT funktioniert nicht.
Habe ich etwas übersehen?

LG
Holger

[DS_Starter]

AT klein schreiben ?

LG
Heiko

[JoeALLb]

at mus sklein geschrieben werden.

Code Auswählen Erweitern


fhem> list TYPE=AT
fhem> list TYPE=at
DbLog.DeleteOldData
PCA301_01.calcD
...


[SusisStrolch]

Dann verstehe ich momentan nicht wieso dafür Events erzeugt werden denn nur die können ja geloggt werden. Üblicherweise erzeugt der Autor Events für Readings mit den dafür vorgesehenen fhem-Befehlen.

Fehler bei mir...
Hatte versehentlich "addValTrigger" auf dem CUL-Device aktiviert - der ist dafür verantwortlich.

[Omega]

Ihr habt recht: at muss klein geschrieben werden. Danke.
Was ich nicht so ganz verstehe, warum es dann in der DB groß abgespeichert wird. Ist das so gewollt?

LG
Holger

[DS_Starter]

Was ich nicht so ganz verstehe, warum es dann in der DB groß abgespeichert wird. Ist das so gewollt?

Ja, der Type wird auf Uppercase gesetzt. Allerdings kann ich dir die Entwicklungsgeschichte nicht verraten. Das war bereits in dem "alten" DbLog-Modul (2016) der Fall und wurde bei der Weiterentwicklung nicht verändert.
Wahrscheinlich wollte man eine gewisse Vereinheitlichung erreichen.

[Virsacer]

hier nochmal der Versuch die "Uninitialized" Meldungen in Zeile 737 zu beseitigen.
Bitte die V2.22.2 testen ob es diesmal ohne Nebeneffekte funktioniert. D.h. bitte die SVG Erstellung explizit testen.
Bei mir sieht es bis jetzt gut aus.

Danke, aber eine Meldung hab ich bisher:

2017.08.09 23:05:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 4322.

[DS_Starter]

2017.08.09 23:05:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 4322.

Ich wollte schrittweise vorgehen und habe mit der angehängten V2.22.3 auch noch diese Zeile behandelt.
Schau mal bitte ob auch diese Änderung keine negativen Auswirkungen auf die SVG-Erstellung bzw. SVG-Änderung hat.

LG
Heiko