93_DbLog - Umstellung Log-Funktion auf non-blocking

[DS_Starter]

Die einzige Stelle die ich mir momentan vorstellen kann ist dass dein lifetracking-Device nicht im Internal NOTIFYDEV enthalten ist.
Alle zu loggenden Devices sollten dort enthalten sein. (Screenshot). Hast du FHEM restartet mit dem neuen DbLog-Modul ?
Ansonsten stelle mal bitte verbose 4 ein. Dann sieht man im Logfile was bewertet und geloggt wird.
Bei mir wird alles geloggt was auch im NOTIFYDEV enthalten ist und was in die DB soll.

[stromer-12]

Ich hatte jedesmal einen Restart gemacht.

Ich habe es gerade noch mal eingebunden.
Es wird vom Dblog erkannt, den die splitFn Funktion wird aufgerufen.

Code Auswählen Erweitern

2016.12.23 16:01:45.708 4: track_Companion OwnTracks: 2016-12-23 16:01:25  {"_type":"location","t":"u","tid":"1","acc":21,"lat":xx.087540,"lon":yy.390250,"tst":1482505285,"batt":55,"dis":16}
2016.12.23 16:01:45.720 4: DbLog myDbLog -> max events: 1 for device track_Companion
2016.12.23 16:01:45.720 4: DbLog myDbLog -> check Device: track_Companion , Event: battery: 55 %
2016.12.23 16:01:45.721 5: DbLog_ParseEvent calling external DbLog_splitFn for type: livetracking , device: track_Companion
2016.12.23 16:01:45.721 5: event battery: 55 %
2016.12.23 16:01:45.722 5: output battery / 55 / %
2016.12.23 16:01:45.723 4: DbLog myDbLog -> processing event Timestamp: ARRAY(0x5c4e280), Device: track_Companion, Type: LIVETRACKING, Event: battery: 55 %, Reading: battery, Value: 55, Unit: %


Mein notifydev lautet .*

[DS_Starter]

Ich denke das wird das Problem sein:

event Timestamp: ARRAY(0x5c4e280), Device:.....

Dort steht normalerweise der Timestamp so wie bei mir:

processing event Timestamp: 2016-12-23 15:57:37, Device: MySTP_5000

Teste mal bitte die angehängte Version ob es dann bei dir ok ist.

[CoolTux]

Ich wollte nach den Feiertagen mein dbLog eh etwas umbauen, dann werde ich Deine Version mal testen. Grüße

[DS_Starter]

Ich wollte nach den Feiertagen mein dbLog eh etwas umbauen, dann werde ich Deine Version mal testen

Würde mich freuen, gemeinsam geht halt alles besser 
Schöne Feiertage ! Ich mache auch erst im neuen Jahr etwas weiter.

Grüße
Heiko

[stromer-12]

Jetzt klappt der Eintrag   

Code Auswählen Erweitern

2016.12.23 16:49:08.417 4: DbLog myDbLog -> processing event Timestamp: 2016-12-23 16:49:08, Device: track_Companion, Type: LIVETRACKING, Event: battery: 53 %, Reading: battery, Value: 53, Unit: %

[DS_Starter]

Prima 

Wenn du dir einen Überblick über Performance gemacht hast wäre es interessant zu wissen und welche DB du einsetzt.
Danke für die Geduld beim Test und einen schönen Abend !

Grüße
Heiko

[Loredo]

Wenn ihr möchtet: Im Rahmen von Unit.pm gibt es bereits auch eine generalisierte Funktion, die für alle Module einmal als Standard Split Funktion für die Einheiten, welche einmal dafür gedacht wäre, dass sie für alle Module einsetzbar ist und somit gar in das DbLog Modul wandern könnte.


https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/Unit.pm#L3715-L3771


Wird momentan von den Modulen Wunderground und HP1000 genutzt.
Die Performance Diskussion zu DbLog mit Wunderground gab es hier schon (wenig fortgeschritten): https://forum.fhem.de/index.php?topic=61085

[JoeALLb]

Wenn ihr möchtet: Im Rahmen von Unit.pm gibt es bereits auch eine generalisierte Funktion, die für alle Module einmal als Standard Split Funktion für die Einheiten, welche einmal dafür gedacht wäre, dass sie für alle Module einsetzbar ist und somit gar in das DbLog Modul wandern könnte.

Mit diesem Modul wäre eine der Baustellen, die ich weiter oben in meiner Liste genannt habe, mit korrigiert....!
Das Unithandling von DbLog ist recht "brachial" und in  die Jahre gekommen.

Ich teste aktuell mit einem kleinen x86-Server auf Atomm und einer DB mit 59GB und  600 Mio. Datensätzen.
Es flutscht: => Ist angenehm schnell und reagiert deutlich spritziger im Vergleich zu zuvor.

Danke, unf fröhliche Feiertage euch allen.

[Loredo]

Das Unithandling von DbLog ist recht "brachial" und in  die Jahre gekommen.

Aktuell taugt Unit.pm auch fast nur zum loggen, weil wir Rudi bisher nicht davon überzeugen konnten einige wenige Patches in fhem.pl, FHEMWEB und TELNET zu akzeptieren. Überzeuger welcome

[DS_Starter]

Hallo zusammen,

guter Vorschlag Loredo und Joe. Mir ist das ungenügende Split vor allem bei Sysmon aufgefallen.
Jetzt habe ich den gegenwärtigen Entwicklungsstand noch etwas geschönt, das verbose 4 Logging verbessert und hier als V2.4 angehängt.

Es kann uns als Grundlage für die weitere Entwicklung dienen bzw. m.M. nach so wie es ist das bisherige DbLog im SVN ersetzen.  Schön wäre es wenn sich noch ein paar mehr Tester finden würden.

Wenn ich wieder Zeit finde schaue ich mir mal die Integration der Split-Funktion von Unit.pm ins DbLog an. Falls du Lust hast kannst du es ja schonmal probieren Loredo .....

Aber jetzt erstmal allen schöne Weihnachten und paar Tage der Erholung ... bis zum neuen Jahr !

Grüße
Heiko

[abc2006]

Schön wäre es wenn sich noch ein paar mehr Tester finden würden.

Ich wills schon länger mal einbauen, bin aber noch nicht dazu gekommen.

Kann ich das Modul gefahrlos auf einem Prod-System einbauen oder laufe ich Gefahr, irgendwas (in der DB) zu zerschießen?
Backups für den Notfall hab ich natürlich ...

Grüße
Stephan

[Loredo]

Ich würde erwarten, dass es das vorhandene Modul ersetzt und es abwärtskompatibel ist.


Gruß

Julian

[stromer-12]

Ich würde es gut finden, wenn man die verbose Ausgaben von dblog mehr auf bestimmte Device begrenzen könnte.
Sonst es wird sonst ganz schon viel Ausgaben erzeugt bei einer größeren Fhem Installation.

[stromer-12]

So, Version 2.4 ist jetzt einen Tag gelaufen, letzte Nacht gerade mal 6 Freezes von 1-2.5 Sekunden vorher waren es viel mehr und längere Freezes.

Meine Datenbank ist ca 15GB groß und hat ca 60M Datensätze.