93_DbLog - Umstellung Log-Funktion auf non-blocking

[DS_Starter]

Hallo miteinander,

das Beschneiden der Feldlängen vor dem Schreiben in die DB (für nicht SQLite-DB's) gab es bereits in dieser Form in der bisherigen DbLog-Version und wurde aus Kompatibilitätsgründen auch so übernommen.
Möglicherweise ist es nicht (mehr) notwendig und könnte entfernt werden. Aber das würde ich nur nach entsprechenden Tests gemeinsam mit euch tun.

An dieser Stelle mal einen herzlichen Dank an die Unterstützer dieses Umstellungsprozesses !!

@ friesenjung ... wenn du für dich in deiner DB-Umgebung die Spaltenbreite angepasst hast, dann kannst du diese Werte gleich am Anfang des Moduls
ab Zeile 56 (etwa) zentral ändern :

Code Auswählen Erweitern


my %columns = ("DEVICE"  => 64,
               "TYPE"    => 64,
                "EVENT"   => 512,
                "READING" => 64,
                "VALUE"   => 128,
                "UNIT"    => 32
          );


Bei dir wäre dann " "EVENT"   => 1024, " gültig. So wäre es besser als direkt im Code zu ändern wenn man solche Veränderungen an der DB vorgenommen hat.

@Tobias ... danke für die Info. Ich denke die jetzige V2.8.5 aus #167 sollten wir heute Abend einchecken da sie die wichtigen Korrekturen für NOTIFYDEV-Verwendung und und die zuschaltbaren Events enthält.

Grüße
Heiko

[betateilchen]

In DbLog ist vieles seltsam und es wird nicht besser.

93_DbLog.pm ist die "fhem-Nutte" - da haben schon ganz viele dran rumgefummelt...

[Tobias]

93_DbLog.pm ist die "fhem-Nutte" - da haben schon ganz viele dran rumgefummelt...

ich würds ja auch alleine machen, aber soviel Zeit habe ich nicht. Da ist jede Zuarbeit willkommen. Allerdings sehe ich mich trotzdem als Maintainer um drauf zu achten Was dort Wie reinkommt.

Fhem-Nutte *schmunzel*

[Loredo]

93_DbLog.pm ist die "fhem-Nutte" - da haben schon ganz viele dran rumgefummelt...

Na, na! Mind your words.


Heiko ist jedenfalls IMHO keiner, der da auch nur eben schnell drüber huscht. Das wird seinem Engagement nicht gerecht.

[betateilchen]

Na, na! Mind your words.

ich weiß, wovon ich rede, ich habe in der Vergangenheit auch schon einiges in das Modul implantiert... 

[Newbie]

Hallo,

ich hab heute Mittag ein ReduceLog ausgeführt, seitdem funktioniert der async-Modus mit der Version 2.8.5 nicht mehr. Es werden keine Daten in die Datenbank geschrieben. Mit der alten Version 2.8.1 funtioniert es.

Version 2.8.5

Code Auswählen Erweitern

2017.01.09 21:14:03.171 4: DbLog logdb -> ################################################################
2017.01.09 21:14:03.171 4: DbLog logdb -> ###              start of new Logcycle                       ###
2017.01.09 21:14:03.171 4: DbLog logdb -> ################################################################
2017.01.09 21:14:03.172 4: DbLog logdb -> amount of events received: 2 for device: logdb
2017.01.09 21:14:03.172 4: DbLog logdb -> check Device: logdb , Event: background_processing_time: 0.0122
2017.01.09 21:14:03.172 4: DbLog logdb -> check Device: logdb , Event: sql_processing_time: 0.0041
2017.01.09 21:14:03.174 5: DbLog logdb -> DbLog_PushAsyncDone finished
2017.01.09 21:14:11.177 4: DbLog logdb -> ################################################################
2017.01.09 21:14:11.178 4: DbLog logdb -> ###              start of new Logcycle                       ###
2017.01.09 21:14:11.178 4: DbLog logdb -> ################################################################
2017.01.09 21:14:11.178 4: DbLog logdb -> amount of events received: 1 for device: SZ_Clima
2017.01.09 21:14:11.178 4: DbLog logdb -> check Device: SZ_Clima , Event: 28
2017.01.09 21:14:11.183 4: DbLog logdb -> ################################################################
2017.01.09 21:14:11.183 4: DbLog logdb -> ###              start of new Logcycle                       ###
2017.01.09 21:14:11.183 4: DbLog logdb -> ################################################################
2017.01.09 21:14:11.184 4: DbLog logdb -> amount of events received: 2 for device: SZ_Ventil2
2017.01.09 21:14:11.184 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: ValveDesired: 28
2017.01.09 21:14:11.184 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: set_28
2017.01.09 21:14:11.306 4: DbLog logdb -> ################################################################
2017.01.09 21:14:11.306 4: DbLog logdb -> ###              start of new Logcycle                       ###
2017.01.09 21:14:11.307 4: DbLog logdb -> ################################################################
2017.01.09 21:14:11.307 4: DbLog logdb -> amount of events received: 6 for device: SZ_Ventil2
2017.01.09 21:14:11.307 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: ValvePosition: 28
2017.01.09 21:14:11.307 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: battery: ok
2017.01.09 21:14:11.307 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: motor: stop
2017.01.09 21:14:11.308 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: motorErr: ok
2017.01.09 21:14:11.308 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: operState: onTarget
2017.01.09 21:14:11.308 4: DbLog logdb -> check Device: SZ_Ventil2 , Event: 28
2017.01.09 21:14:13.060 4: DbLog logdb -> ################################################################
2017.01.09 21:14:13.061 4: DbLog logdb -> ###              start of new Logcycle                       ###
2017.01.09 21:14:13.061 4: DbLog logdb -> ################################################################
2017.01.09 21:14:13.061 4: DbLog logdb -> amount of events received: 1 for device: hmusb
2017.01.09 21:14:13.061 4: DbLog logdb -> check Device: hmusb , Event: loadLvl: low
2017.01.09 21:14:21.827 4: DbLog logdb -> ################################################################
2017.01.09 21:14:21.828 4: DbLog logdb -> ###              start of new Logcycle                       ###
2017.01.09 21:14:21.828 4: DbLog logdb -> ################################################################
2017.01.09 21:14:21.828 4: DbLog logdb -> amount of events received: 1 for device: HMLAN1
2017.01.09 21:14:21.828 4: DbLog logdb -> check Device: HMLAN1 , Event: loadLvl: batchLevel



vg Jens

Edit: Version 2.8.4 funktioniert auch noch
2. Edit mit aktiviertem Attr. "cacheEvents" geht auch die Version 2.8.5, hab die Funtion dieses Attr. aber anders verstanden

[Xcoder]

Hallo DbLog Freunde

Hat jemand eine Idee woran es bei meinen DbLogExclude-Problem liegt?

Gruss, Xcoder

[Xcoder]

Hallo,

ich hab heute Mittag ein ReduceLog ausgeführt, seitdem funktioniert der async-Modus mit der Version 2.8.5 nicht mehr. Es werden keine Daten in die Datenbank geschrieben. Mit der alten Version 2.8.1 funtioniert es.

Wie sieht Dein Filter aus?

Ich musste bei mir nach dem Update von (KNX_....:.*|SWC_170:.*) auf (KNX_....|SWC_170):.* wechseln, weil sonst nur noch KNX_.... Events gelogt wurden.

Gruss, Xcoder

[Rewe2000]

Hallo,

hatte ursprünglich meine Frage im Bereich "Anfänger" eingestellt, da ich euch nicht mit diesen "Kinderkram" nerven wollte. Aber ich denke es könnte mit dieser Thematik etwas zu tun haben, da ein weiterer User vom gleichen/ähnlichen Fehler berichtet.
Bitte steinigt mich nicht wenn ich total daneben liege.

Der Fehler (gemäß Logauszug):

Code Auswählen Erweitern

2017.01.08 15:00:56 5: exec at command DBLogging_Reopen
2017.01.08 15:00:56 2: DbLog DBLogging -> Error: DBD::mysql::db begin_work failed: Turning off AutoCommit failed at ./FHEM/93_DbLog.pm line 923.

2017.01.08 15:00:56 1: PERL WARNING: rollback ineffective with AutoCommit enabled at ./FHEM/93_DbLog.pm line 994.
2017.01.08 15:00:56 3: DBLogging_Reopen: Reopen executed.

kommt meistens, nachdem das DBLogging_Reopen mit at aufgerufen wird, aber es gibt auch Zeiten wo kein Fehler zu beobachten ist.
Wenn ich mein Log ansehe, kommt der Fehler erst seit dem Fhem Update vom 07.01.2016, hier ist auch eine Änderung in der "93_DbLog: can now working in  async mode" enthalten. Kann auch nur eine falsche Vermutung sein, denn wenn es so wäre, gäb es sicher bei mehreren Usern Probleme. Da ich mein System derzeit in Fhem komplett neu aufbaue, kann ich natürlich nicht ausschließen, dass ich irgend etwas noch anderes geändert habe, was den Fehler auslöst.

Verwendetes System und versuchte Lösungen in Stichpunkten:
Raspberry PI 3 mit 16 GB Speicherkarte
MYSQL Datenbank ist über Console (mysql) und HeidiSQL jederzeit erreichbar und sichtbar
Verwendeter Datenbankclient unter WIN7 HeidiSQL -> in die Datenbank wird korrekt geschrieben
Tabelle history ist mit Daten gefüllt
Tabelle current ist leer ? ? -> denke aber mittlerweile das ist OK so!
MySQL Datenbank komplett gelöscht und neu angelegt und eingerichtet, jedoch gleicher Fehler wieder
Fhem ist aktuell, eben update ausgeführt
Raspi mehrmals neu gestartet, Fehler bleibt jedoch

Es wäre nett wenn ihr mir einen Tipp geben könntet woran es liegt oder wie ich den Fehler eingrenzen könnte. Gerne liefere ich noch weitere Informationen, sollten diese Hilfreich sein.

Den usprünglichen Beitrag "https://forum.fhem.de/index.php/topic,64405.0.html" habe ich geschlossen.

Gruß Reinhard

[Newbie]

Hallo Xcoder,

die Einstellungen sind schon ok bei mir. Problem mit der 2.8.5 ist im async-Modus, das nur 1x die Daten in die Datenbank geschrieben werden und danach nicht mehr. Bis zur Version 2.8.4 geht es.
Bis zum "set reduceLog" funktionierte ja die Version 2.8.5 auch.

vg Jens

[DS_Starter]

@Newbie, die Unterschiede zw. 2.8.4 und 2.8.5 sind geringfügig. Der async-Modus funktioniert auf Timer-Basis. Möglicherweise liegt da das Problem.
Wie sieht es aus wenn du fhem mit der Version 2.8.5 restart hast, klappt dann alles wieder ?

@Rewe2000, nach deinem Fehler suche ich mal im Netz. Die Daten werden geloggt, das ist das Wichtigste. Die Current-Tabelle kannst du mit füllen wenn du das Attr "DbLogType" auf "Current" bzw. "Current/History" setzt.

EDIT: habe gerade das gesehn:

Edit mit aktiviertem Attr. "cacheEvents" geht auch die Version 2.8.5, hab die Funtion dieses Attr. aber anders verstanden

Ist auch anders, eben nur eine Eventgenerierung.  Das erschließt sich mir gerade nicht.

[Newbie]

Hallo Heiko,

shutdown und System neu gestartet schon probiert. Gleiches Ergebnis.
Ich sehe im Reading "CacheUsage" das einmal Daten hochzählen, nach Ablauf von "syncInterval"(bei mir 60sek) in die Datenbank geschoben werden und danach CacheUsage bei 0 stehenbleibt.

vg Jens

[DS_Starter]

@XCoder, das Filterproblem für die Regex ist mit 2.8.3 behoben, am besten gleich die 2.8.5 benutzen.

@Rewe2000, habe hier https://rt.cpan.org/Public/Bug/Display.html?id=105382 einen Hinweis auf ein solches Problem gefunden. Bezieht sich auf Perl 5.14.2 with DBD::mysql 4.031 Version. Möglicherweise gibt es noch mehr Hinweise. Mal schauen ...

[DS_Starter]

Hallo Jens,

du hattest doch geschrieben

mit aktiviertem Attr. "cacheEvents" geht auch die Version 2.8.5

Bin jetzt etwas verwirrt.

[Newbie]

Hallo Heiko,

mit cacheEvents=1 geht es ja auch.

Ich sehe im Reading "CacheUsage" das einmal Daten hochzählen, nach Ablauf von "syncInterval"(bei mir 60sek) in die Datenbank geschoben werden und danach CacheUsage bei 0 stehenbleibt.

bezog sich bei cacheEvents=0