93_DbLog - Umstellung Log-Funktion auf non-blocking

[Xcoder]

Ich habe hier die Error: DBD::mysql::db begin_work failed Meldungne mit Perl 5.24.1 und DBD::mysql 4.041. DbLog 2.8.2 ist im synchronen Modus.


@DS_Starter: Wo finde ich den 2.8.5? Ist das nicht im SVN?

[DS_Starter]

Also wenn cacheEvents nicht gesetzt ist, wird auch die Anzeige nicht mehr aktualisiert. Hast du mal den Brower refresht und geschaut ob sich cacheEvents ändert ? Ansonsten mit verbose 5 schauen ob du den Start des DB-processing im Log findest:

Code Auswählen Erweitern

2017.01.09 22:40:51.055 5: DbLog LogDB -> ################################################################
2017.01.09 22:40:51.056 5: DbLog LogDB -> ###              New database processing cycle               ###
2017.01.09 22:40:51.056 5: DbLog LogDB -> ################################################################
2017.01.09 22:40:51.056 5: DbLog LogDB -> MemCache contains 17 entries to process
2017.01.09 22:40:51.056 5: DbLog LogDB -> MemCache contains: 2017-01-09 22:40:09|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0117|Bezug_WirkP_Zaehler_Diff|0.0117|
2017.01.09 22:40:51.056 5: DbLog LogDB -> MemCache contains: 2017-01-09 22:40:09|SMA_Energymeter|SMAEM|Bezug_WirkP_Kosten_Diff: 0.0025|Bezug_WirkP_Kosten_Diff|0.0025|
2017.01.09 22:40:51.056 5: DbLog LogDB -> MemCache contains: 2017-01-09 22:40:09|SMA_Energymeter|SMAEM|Einspeisung_WirkP_Zaehler_Diff: 0|Einspeisung_WirkP_Zaehler_Diff|0|


[DS_Starter]

@XCoder. die V2.8.5 findest du hier im Beitrag #167.  Tobias wird sie heute sicherlich noch einchecken.

[Newbie]

So hab jetzt etwas intensiver rumprobiert.

Ergebnis 1 - warum heute Nachmittag nicht gelogt wurde ist nicht mehr festzustellen

Ergebnis 2 - es wird zwar korrekt in die Datenbak geschrieben, aber die Anzeige von "CacheUsage" wird nach dem ersten Interval nicht mehr aktualisiert (mit Linux,Windows sowie verschiednene Browser probiert). Lade ich die Seite neu steht wieder einmal der aktuelle Wert drin. Und wie schon geschrieben mit cacheEvent=1 geht´s.

vg Jens

[DS_Starter]

Hallo Jens,

Lade ich die Seite neu steht wieder einmal der aktuelle Wert drin. Und wie schon geschrieben mit cacheEvent=1 geht´s.

Ja das ist normal wenn die Eventgenerierung ausgeschaltet ist wird das Reading nicht mehr automatisch aktualisiert. Die nicht erzeugten Events sollen die Systemressourcen schonen, sind aber zuschaltbar wenn der User es will/braucht. Nebeneffekt ist dass dann die Anzeige wieder refresht wird und automatisch aktualisieren.

Grüße
Heiko

[Newbie]

Danke für die Info,

bleibt also nur das ungeklärte Problem vom Nachmittag. Wobei ich den Eindruck habe, das es sinnvoll ist bei Einstellungsänderungen am DbLog-Modul nicht nur FHEM neu zu starten sondern das komplette System.

Sorry für die Aufregung und DANKE für deine Arbeit hier.


vg Jens

[DS_Starter]

Hallo,

anbei die V2.8.6.
Es sollte das Prob "mysql::db begin_work failed: Turning off AutoCommit failed" was bei XCoder immer mal auftritt, nicht mehr in Erscheinung treten.
Bitte Rückmeldung ob ok.

EDIT: das geschilderte Problem dass nach reducelog der asynchrone Logmodus nicht fortgeführt wird sollte auch behoben sein.

VG

[Tobias]

2.8.6 ist jetzt eingecheckt.
@DS_Starter, dachte du machst das gestern

[DS_Starter]

Morgen Tobias,

danke    War gestern noch zeimlich mit den User-Issues beschäftigt und darüber ganz untergegangen ... thx !

Wünsche dir einen schönen Tag ... Arbeit ruft...
Grüße
Heiko

[JoeALLb]

Hallo Heiko,

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.

Das wurde aber in der (nahen) Vergangenheit nicht ausgeführt. Bisher reichte es völlig aus, die Datenbank-Spalte zu verbreitern.
Erst seit den jüngsten Updates muss dazu noch die Breite im Modul mit geändert werden.
Warum, konnte ich leider anhand der Diffs des Moduls nicht finden.

[Wuppi68]

als Ad Hoc Vorschlag:

Sollte man die Feldlängen nicht als Optionales Attribut einführen?

[ioT4db]

als Ad Hoc Vorschlag:

Sollte man die Feldlängen nicht als Optionales Attribut einführen?

den Vorschlag finde ich gut!

Habe gestern die Feldlängen im Modul angepasst und nach FHEM-restart gings noch nicht. Hab dann Raspi komplett neugestartet und seit dem geht es wunderbar, so wie "früher".

Um nun nicht nach jedem FHEM-Update die Datei neu editieren zu müssen, wäre ein Attribut echt klasse.

Btw. gibt es eine Möglichkeit ein Modul explizit vom Update auszuschließen?

Grüße...

[betateilchen]

Btw. gibt es eine Möglichkeit ein Modul explizit vom Update auszuschließen?

Ja. Indem man die Doku zu "update" liest, da steht sowas drin.

Code Auswählen Erweitern

help update

Und dann Augenmerk auf den Abschnitt mit den Attributen.

[betateilchen]

als Ad Hoc Vorschlag:

Sollte man die Feldlängen nicht als Optionales Attribut einführen?

Ich wäre eher dafür, das in der Konfigurationsdatei, die man ohnehin für DbLog braucht, zu hinterlegen.

[JoeALLb]

Ich wäre eher dafür, das in der Konfigurationsdatei, die man ohnehin für DbLog braucht, zu hinterlegen.

Ich wäre eher dafür, (sobald es denn überhaupt notwendig ist),
diese Information bei der Initialisierung direkt aus der DB abzufragen. Nur so ist sichergestellt, dass die beiden Werte übereinstimmen.
Bei SQLite und bei MySQL sehe ich jedoch keinerlei Notwendigkeit dafür, diese Strings schon im Modul zu kürzen.

Bei MySQL ist standardmäßig

Code Auswählen Erweitern

STRICT_TRANS_TABLES und STRICT_ALL_TABLES disabled, was das automatische Kürzen beim Insert erlaubt.
Der Benutzer muss es also bewußt deaktivieren.

Vielleicht sollten wir bei der Initialisierung auf ein paar wenige Standardeinstellungen prüfen und eine Meldung anzeigen, sofern diese nicht den Anforderungen von DbLog entspricht....