93_DbLog - Umstellung Log-Funktion auf non-blocking

[betateilchen]

nach Update habe ich ein kleines Problem.

FHEM2FHEM daten werden nicht in DB geschrieben

Das ist vermutlich genau das gleiche Problem.

[marvin78]

Da werden noch einige mehr aufschlagen...

[betateilchen]

93_DbLog.pm sollte NOTIFYDEV erstmal pauschal auf .* setzen, bis man sich überlegt hat, ob man das Problem sinnvoll anders lösen kann.

Oder per Attribut vom User wählbar abschaltbar gestalten.

[DS_Starter]

Oder per Attribut vom User wählbar abschaltbar gestalten.

So werde ich das morgen früh einbauen ....

Grüße
Heiko

[My-FHEM]

Auch mit .* werden keine FHEM2FHEM daten geloggt.

Wie kriege ich das wieder hin?

Code Auswählen Erweitern


Internals:
   CONFIGURATION ./db.conf
   DBMODEL    MYSQL
   DEF        ./db.conf .*
   MODE       asynchronous
   NAME       myDbLog
   NOTIFYDEV  .*
   NR         4
   NTFY_ORDER 50-myDbLog
   PID        2994
   REGEXP     .*
   STATE      connected
   TYPE       DbLog
   VERSION    2.8.2
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemuser
   Helper:
   Helper:
     Dblog:
       Cacheusage:
         Mydblog:
           TIME       1483806780.105
           VALUE      21
       Dbd::mysql::st execute_array failed:
         Mydblog:
           TIME       1483803885.42194
           VALUE      executing 1278 generated 1 errors at ./FHEM/93_DbLog.pm line 1183.

       Nextsync:
         Mydblog:
           TIME       1483806779.21278
           VALUE      2017-01-07 17:33:29
       State:
         Mydblog:
           TIME       1483806779.64402
           VALUE      connected
   Readings:
     2017-01-07 17:33:00   CacheUsage      22
     2017-01-07 17:32:59   NextSync        2017-01-07 17:33:29
     2015-02-21 14:57:11   countCurrent    3053
     2015-02-21 14:57:11   countHistory    148316222
     2017-01-07 17:32:59   state           connected
     2017-01-07 00:05:00   userCommand     select
                                max(to_number(value,'999.999')) - min(to_number(value,'999.999')) as kw
                                from history
                                where device = 'PCA301_FeOben'
                                and reading = 'consumption'
                                and timestamp >= TO_TIMESTAMP('2017-01-06 00:00:00','YYYY-MM-DD HH24:MI:SS')
                                and timestamp <= TO_TIMESTAMP('2017-01-06 23:59:59','YYYY-MM-DD HH24:MI:SS')
   Cache:
     index      3256
     Memcache:
       3235       2017-01-07 17:32:59|myDbLog|DBLOG|CacheUsage: 0|CacheUsage|0|
       3236       2017-01-07 17:32:59|myDbLog|DBLOG|NextSync: 2017-01-07 17:33:29|NextSync|2017-01-07 17:33:29|
       3237       2017-01-07 17:32:59|myDbLog|DBLOG|connected|state|connected|
       3238       2017-01-07 17:32:59|EC3000_476A|EC3000|consumption: 1685.343|consumption|1685.343|
       3239       2017-01-07 17:32:59|EC3000_476A|EC3000|power: 16.1|power|16.1|
       3240       2017-01-07 17:32:59|EC3000_476A|EC3000|powerMax: 18.5|powerMax|18.5|
       3241       2017-01-07 17:32:59|EC3000_476A|EC3000|on|state|on|
       3242       2017-01-07 17:32:59|EC3000_476A|EC3000|consumptionTotal: 1685.343|consumptionTotal|1685.343|
       3243       2017-01-07 17:32:59|myDbLog|DBLOG|CacheUsage: 8|CacheUsage|8|
       3244       2017-01-07 17:32:59|EC3000_3E58|EC3000|consumption: 31.296|consumption|31.296|
       3245       2017-01-07 17:32:59|EC3000_3E58|EC3000|power: 1.8|power|1.8|
       3246       2017-01-07 17:32:59|EC3000_3E58|EC3000|powerMax: 1266.4|powerMax|1266.4|
       3247       2017-01-07 17:32:59|EC3000_3E58|EC3000|on|state|on|
       3248       2017-01-07 17:32:59|EC3000_3E58|EC3000|Total: 31.296|Total|31.296|
       3249       2017-01-07 17:32:59|myDbLog|DBLOG|CacheUsage: 14|CacheUsage|14|
       3250       2017-01-07 17:32:59|myDbLog|DBLOG|connected|state|connected|
       3251       2017-01-07 17:33:00|EC3000_3DDC|EC3000|consumption: 93.986|consumption|93.986|
       3252       2017-01-07 17:33:00|EC3000_3DDC|EC3000|power: 3.4|power|3.4|
       3253       2017-01-07 17:33:00|EC3000_3DDC|EC3000|powerMax: 99.6|powerMax|99.6|
       3254       2017-01-07 17:33:00|EC3000_3DDC|EC3000|on|state|on|
       3255       2017-01-07 17:33:00|EC3000_3DDC|EC3000|consumptionTotal: 93.986|consumptionTotal|93.986|
       3256       2017-01-07 17:33:00|myDbLog|DBLOG|CacheUsage: 21|CacheUsage|21|
Attributes:
   DbLogType  Current/History
   asyncMode  1
   room       db-logs
   shutdownWait 5
   verbose    0


Code Auswählen Erweitern


      Dbd::mysql::st execute_array failed:
         Mydblog:
           TIME       1483803885.42194
           VALUE      executing 1278 generated 1 errors at ./FHEM/93_DbLog.pm line 1183.


bedeutet diese Meldung bezüglich FHEM2FHEM etwas?


VG

PS. nach einiger Zeit zeigt list myDbLog:

Code Auswählen Erweitern


   CONFIGURATION ./db.conf
   DBMODEL    MYSQL
   DEF        ./db.conf .*.
   MODE       synchronous
   NAME       myDbLog
   NOTIFYDEV  .*.
   NR         4
   NTFY_ORDER 50-myDbLog
   PID        2994
   REGEXP     .*.
   STATE      connected
   TYPE       DbLog
   VERSION    2.8.2
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemuser
   Helper:
   Helper:
     Dblog:
       Cacheusage:
         Mydblog:
           TIME       1483811468.89884
           VALUE      168
       Dbd::mysql::st execute_array failed:
         Mydblog:
           TIME       1483809090.57913
           VALUE      executing 309 generated 1 errors at ./FHEM/93_DbLog.pm line 1183.

       Nextsync:
         Mydblog:
           TIME       1483811447.36378
           VALUE      2017-01-07 18:51:17
       State:
         Mydblog:
           TIME       1483811447.51395
           VALUE      connected
   Readings:
     2017-01-07 18:51:08   CacheUsage      169
     2017-01-07 18:50:47   NextSync        2017-01-07 18:51:17
     2015-02-21 14:57:11   countCurrent    3053
     2015-02-21 14:57:11   countHistory    148316222
     2017-01-07 18:50:47   state           connected
     2017-01-07 00:05:00   userCommand     select
                                max(to_number(value,'999.999')) - min(to_number(value,'999.999')) as kw
                                from history
                                where device = 'PCA301_FeOben'
                                and reading = 'consumption'
                                and timestamp >= TO_TIMESTAMP('2017-01-06 00:00:00','YYYY-MM-DD HH24:MI:SS')
                                and timestamp <= TO_TIMESTAMP('2017-01-06 23:59:59','YYYY-MM-DD HH24:MI:SS')

Attributes:
   DbLogType  Current/History
   asyncMode  1
   room       db-logs
   shutdownWait 5
   verbose    0




es wird in den internals: synchronous angezeit obwohl ATTR asyncMode 1

Eine Idee?

Wo gibt es die letzte funktionierende Version vor den Update?

[CoolTux]

./db.conf .*.

Eventuell so. Aber dann wird alles geloggt

[My-FHEM]

Auch das führt nicht zum loggen von FHEM2FHEM Daten

VG

[rudolfkoenig]

FHEM2FHEM im LOG-Mode legt temporaer Geraete an, es sei denn, ein Geraet mit dem passenden Namen existiert schon.

Das in DoTrigger verwendete %ntfyHash wird in createNtfyHash aus NOTIFYDEV mit devspec2array berechnet.
createNtfyHash wird nur beim Aendern von Geraeten aufgerufen, nicht aber, wenn FHEM2FHEM ein temporaeres Geraet anlegt.
-> Von FHEM2FHEM temporaer angelegte Geraete koennen nur ohne NOTIFYDEV benachrichtigt werden.

Die Funktion notifyRegexpChanged prueft sowas, und berechnet aus einem Regexp NOTIFYDEV bzw. loescht sie, falls NOTIFYDEV kontraproduktiv ist. Modulautoren sollten NOTIFYDEV nur ueber diese Funktion setzen, und nie direkt. Damit ist auch eine Aenderung/Optimierung eher moeglich.

[betateilchen]

So werde ich das morgen früh einbauen ....

wobei ich den von Rudi empfohlenen Weg sogar noch besser finde...

Die Funktion notifyRegexpChanged prueft sowas, und berechnet aus einem Regexp NOTIFYDEV bzw. loescht sie, falls NOTIFYDEV kontraproduktiv ist. Modulautoren sollten NOTIFYDEV nur ueber diese Funktion setzen, und nie direkt. Damit ist auch eine Aenderung/Optimierung eher moeglich.

[sfancy]

Bei mir werden seit dem Update heute auch keine Daten mehr vom Type GPIO4 geloggt. Vorher wurde alles geloggt. Die Events sind im Event-Monitor sichtbar:

2017-01-07 22:44:22 GPIO4 Heizungsvorlauf temperature: 40.875
2017-01-07 22:44:33 GPIO4 Heizungsvorlauf temperature: 40.25
2017-01-07 22:44:55 GPIO4 Heizungsvorlauf temperature: 39.312

DbLog ist wie folgt definiert:

Code Auswählen Erweitern

defmod LogDB DbLog ./db.conf (Heizung|HK_).*:.*
attr LogDB group Log
attr LogDB room System
attr LogDB sortby 12

Was kann ich einstellen, das es wieder loggt?
Signale vom Type MAX werden weiterhin geloggt.

[DS_Starter]

Sorry war bis jetzt unterwegs ...

So sollte es gehen:

Code Auswählen Erweitern

defmod LogDB DbLog ./db.conf (Heizung.*|HK_.*):.*

Morgen früh werde ich das Problem fixen..

[sfancy]

Danke,

so klappt es bei mir. Nach der Änderung ist unter Internals auch ein NOTIFYDEV und REGEXP sichtbar. Das es vorher nicht gab.

[DS_Starter]

Prima ... das NOTIFYDEV ist eine feine Sache weil es FHEM bei einer umfangreichen Installation entlastet. Hat aber leider jetzt Späne verursacht.
Muß mich morgen um eine Verbesserung bemühen.

[DS_Starter]

Guten Morgen,

anbei die korrigierte Version V8.2.3 bzgl. der NOTIFYDEV-Verwendung.

Habe die von Rudi angemerkte Funktion zum Setzen des  NOTIFYDEV eingebaut.
Außerdem gibt es noch das Attribut "noNotifyDev" womit der User die Verwendung von NOTIFYDEV explizit unterbinden kann wenn es nötig/gewünscht ist.

Die Commandref ist auch ergänzt und gecheckt.

EDIT: In der auch angehängten V2.8.4 habe ich gleich noch $readingFnAttributes ergänzt, sodass nun die Attribute stateFormat, event-on-change-reading ... ebenfalls verfügbar sind.

Grüße
Heiko

[Wuppi68]

noch einen  Tip ...

man sollte DbLogExclude mit CacheUsage,NextSync,sql_processing_time auf das Device setzen, sonst logged sich die Queue selber von alleine nach oben

bei event-on-change-reading mit .* filtert sich der state ja von alleine