93_DbLog - einige kleine Bugs?

[chris1284]

hallo,

mir sind ein paar Sachen bei dem Inhalt des DbLogs aufgefallen:

bei HM-CC-RT-DN 's

hz.Schlafzimmer_Clima    CUL_HM    T: 16.6 desired: off valve: 0    T    16.6 desired: off valve: 0    

richtig wäre als reading die bezeichnung state und nicht T
hz.Schlafzimmer_Clima    CUL_HM    T: 16.6 desired: off valve: 0    state    T: 16.6 desired: off valve: 0    

bei einem beliebigen Log-Eintag

2014-03-16 21:06:19    RemoteCT    RFHEM    cmd setreading TempSensor state T: 10.0 H: 78.7    cmd setreading TempSensor state    10.0 H: 78.7

hier wird beim VALUE "T:" weggelassen, das Value ist somit unvollständig (passiert scheinbar immer wenn T: auftaucht)
richtig wäre:
2014-03-16 21:06:19    RemoteCT    RFHEM    cmd setreading TempSensor state T: 10.0 H: 78.7    cmd setreading TempSensor state    T: 10.0 H: 78.7

ein weiterer x-beliebiger logeintrag   

2014-03-16 21:08:13    RemoteCT    RFHEM    cmd setreading Wettermast state T: 10.1 H: 76 W: 5...    cmd setreading Wettermast state    10.1 H: 76 W: 5.8 R: 8.9 IR: no Wi: 1    

hier wird mit ... der event-text einfach beschnitten (im Modul denke ich,  in der DB ist EVENT mit varchar(512) konfiguriert)

gruß
christian

[chris1284]

push da die Eigentliche Fragestellung verändert wurde

[chris1284]

in der shell sind auch diverse

DBD::mysql::db begin_work failed: Turning off AutoCommit failed at ./FHEM/93_DbLog.pm line 403.

zu sehen.

[betateilchen]

Grundsätzlich sollte DbLog Values immer ohne irgendwelche Zusätze loggen, aber durch die Vielzahl neu hinzugekommener Geräte, die Werte liefern, funktioniert das momentan einfach nicht mehr für alle Komponenten in allen Fällen hundertprozentig.

Da aktuell im Entwicklungsbereich eine Grundsatzdiskussion über die künftige Darstellung von Readings läuft, wird sich am aktuellen Zustand vermutlich ad-hoc nichts ändern. Das Loggen muss - vereinfacht gesagt - derzeit für jedes mögliche Gerät in DbLog fest eingebaut werden.

Die Hinweismeldung wegen des AutoCommit kannst Du einfach ignorieren.

[chris1284]

Ah ok, dann werde ich mir das wohl für meine devices einfach mit hinzufügen.

Da aktuell im Entwicklungsbereich eine Grundsatzdiskussion über die künftige Darstellung von Readings läuft

mal schauen was dabei raus kommt

[peterk_de]

Ich weiß nicht, ob es hier gut rein passt und ob es überhaupt ein Bug von DBlog ist, aber möglicherweise hilft es dem ein oder anderen weiter:

Nach dem Komplett-Umzug von Filelog nach DBLog (Mysql, alles Loggen mit .*:.* und Default-Einstellung, d.h. keine Attribute gesetzt) war FHEM auf meinem Raspberry kaum noch zu gebrauchen. Ich habe dann ersteinmal das Logging entschlackt und alles auf event-on-change reading umgestellt etc, um die Masse an Logzeilen zu reduzieren.

Trotzdem war es deutlich langsamer, apptime nannte mir Ausführungszeiten von DBLog von 30 sekunden (max); 6 sekunden im Durchschnitt - HOLLA!

Ich war kurz davor eine potentere Hardware zu ordern - las dann aber irgendwo im Forum hier vergraben den (in der Commandref nicht enthaltenen) Tipp, das Logging auf die History-Relation zu begrenzen. Fürs Protokoll, das geht mit:

attr mydblog DbLogType History

Und jetzt ... Whoah! Faktor 300 (!) schneller, FHEM rennt so schnell wie noch nie, viel schneller als bei meinen vielen, unsauberen FileLogs! Maxtime 123 ms, avg 44 ms bei aktuell gut 500 Calls.

Nun las ich, für irgendwas sei das Current-Logging durchaus noch zu gebrauchen - aber muss das SO viel Performance fressen? Das loggen in eine zweite, viel kleinere Relation sollte doch eigentlich die Performance maximal halbieren, aber eigentlich nichtmal das?