93_DbLog - Umstellung Log-Funktion auf non-blocking

[DS_Starter]

Hallo Chris,

jetzt habe ich in der Zwischenzeit meine SQLte Test-DB wieder belebt und mit der eingecheckten Version 2.9.1 durchgespielt.
Auch damit ist bei mir alles ok, d.h. die Device:Reading Vorschaufelder sind gefüllt. der Graph wird gezeichnet und "show preprocessed input" ist ebenfalls
gefüllt. Alles mit SQLite.
Stehe momentan vor einem Rätsel ...

[Sunny]

Moin Heiko,

leider kann ich das von Chris auch bestätigen.
Nutze auch SQLite auf BPi und RPi2.

Code Auswählen Erweitern

DbLogType Current/History
asyncMode 0
Vorher nur "DbLogType History"

Werde mal die "Chris Versionen" testen.

LG
sunny

[Sunny]

Moin Heiko,

leider keine Besserung mit "93_DbLog_V2.9.2_Chris.pm"aus Antwort #329 am: Heute um 20:15:34

LG
sunny

[DS_Starter]

Hallo sunny,

hmm .... das Ergebnis ist einerseits gut weil die Änderungen bzgl. des MySQL-Fehlers nicht "schuld" sind.
Ich mache gleich noch eine V ...

[DS_Starter]

Hallo Sunny,

auch diese Version läuft problemlos bei mir. MySQL und SQLite.
Schalte bitte auch mal um in asynch ob sich dadurch Änderungen ergeben . Glaube ich aber nicht.

[Sunny]

Moin Heiko,

habe

Code Auswählen Erweitern

asyncMode 0
gelöscht und Deine "93_DbLog_V2.9.2_Test.pm" getestet.
Auf Win10/Firefox und Android/Firefox.
Sieht GUT aus. (Nach kurzem testen) 

DANKE für Deine Zeit/Know How!

Mit gefüllten SVG Grüßen
sunny

[DS_Starter]

Hallo sunny,

danke, das ist wirklich schön nur kann ich es fast nicht glauben  Kannst du bitte noch einen Negativtest
machen ? Wäre hilfreich für mich.

Grüße
Heiko

[Sunny]

Moin Heiko,

mit "93_DbLog_V2.9.2_Test2.pm" tritt der Fehler wieder auf.
Was möchtest Du jetzt an Daten haben?

Sorry, aber Heute wird es nix mehr.
Muss in die Falle.
Aber morgen kann ich dann versuchen die Daten  zu erstellen.

Mit müden Grüßen
sunny

[DS_Starter]

Hallo sunny,

auch für mich ist es heute schon zu spät. Ich muß die Ergebnisse in Ruhe sichten.
Heute wird das auch nichts mehr.
Morgen wieder .... danke für die Unterstützung !

Grüße
Heiko

[Ellert]

Ich sehe gerade das Attribut verbose4Devs und lese, dass in DbLog automatisch das globale Logfile für Geräte mit verbose 4 geloggt wird.

Das ich hinsichtlich des globalen Logfiles konservativ bin benötige ich keine Einträge in die Datenbank, da sie bei einem FHEM Absturz oder DB-Fehler nicht leicht verfügbar sind.

Das globale Logfile kann ich per Texteditor einsehen, häufig auch wenn die Datenbank nicht zugänglich ist.

Könnte ich zum Abschalten  verbose4Devs none setzen, wenn das Gerät "none" nicht existiert? Oder prüft DbLog, ob ein globales Logfile als FileLog-Gerät definiert ist?

[DS_Starter]

Hallo Ellert,

vielleicht ist die Beschreibung des Attributs etwas mißverständlich ausgedrückt.
Wenn man in DbLog verbose4 einstellt werden ja unter Umständen sehr viele EInträge im Logfile mit "Logcycle..." auftreten, je nachdem wieviele Geräte man mit DbLog so logged. Um die Lesbarkeit der Ausgaben in diesem Fall zu verbessern, kann man mit diesem Attribut nicht interessierende Geräte von der verbose 4 Ausgabe (in DbLog) ausnehmen.
Das ist alles was dieses Attribut macht, ist nur eine kleine Hilfe um verbose 4 in DbLOg etwas übersichtlicher zu machen wenn Bedarf besteht.

Grüße
Heiko

[Ellert]

Danke für die Aufklärung.

[Benni]

Hallo zusammen,

ohne jetzt den ganzen Thread durchgelesen zu haben  , hier mal die Frage, ob das Performance-Problem, das bei DbLog im Zusammenspiel mit dem Wunderground-Modul auftritt, hier bereits bekannt ist?
(siehe https://forum.fhem.de/index.php/topic,59646.msg529392.html#msg529392)

Ich habe gestern mal wieder ein update gemacht und in der Hoffnung, dass dieses Problem hier evtl.  schon gelöst wurde. Allerdings scheint das Problem nach wie vor zu bestehen, egal, ob DbLog im asynchronen Modus läuft oder nicht. Die Freezes beim update vom Wunderground-Modul bestehen nach wie vor:

Code Auswählen Erweitern


2017.01.16 09:00:24 3: Wunderground set wuMain update
2017.01.16 09:00:31 1: Perfmon: possible freeze starting at 09:00:26, delay is 5.691
2017.01.16 09:02:39 3: Wunderground set wuMain update
2017.01.16 09:02:47 1: Perfmon: possible freeze starting at 09:02:42, delay is 5.444


Schalte ich DbLog ab, dann habe ich keine Freezes beim Wunderground-update.

Eventuell könnt ihr ja mal Loredos Theorie aus dem o.a. Thread überprüfen. Nachdem hier v.a. an der Performance-Schraube gedreht wird, könnte sich, wenn sich das bestätigt und abstellen lässt, evtl. ein nicht unerheblicher Performance-Gewinn für das DbLog-Modul generell erzielen lassen.

Wenn ich was dazu beitragen kann (Tests, Logs, Lists, ...), natürlich gerne!

Danke und Gruß
Benni.

[h3llsp4wn]

Sorry - auf die Gefahr, dass ich hier total falsch bin - ich habe mal auf die aktuelle Version des DbLog aktualisiert, habe dann aber das Problem, dass ich von Devices, die z.B. alle 15 Minuten
gepollt/abgerufen werden alle Änderungen in dem Zeitraum dann zum Abrufzeitpunkt eingetragen bekomme, d.h. z.b. den Temperaturverlauf mit allen Temperaturen zur Abrufzeit, anstelle
zu den tatsächlichen Zeiten der Ereignisse und nicht zur der einen Event-Zeit des Abrufs. Über Nacht führt dies Beispielsweise bei einem meiner Sensoren dazu, dass dann der kpl. Temperaturverlauf der Nacht auf den Abruf um 7:00 gelegt wird. Damit sind natürlich die Daten und auch die Plots im Eimer.

Gibt es eine Möglichkeit das "alte" Verhalten wiederherzustellen? Ich bin aktuell erst mal auf eine DbLog-Version aus dem Oktober zurück - so bin ich dann über die Suche auch hierhin gelangt.

[JoeALLb]

Sorry - auf die Gefahr, dass ich hier total falsch bin - [...]

Mehrere Fragen dazu:
# Mit welchem Modul Pollst Du die Werte?
# Pollst Du in der Nacht nicht, da dann erst um 07:00 wieder Werte eingetragen werden?
# Wie sehen die Poll-Readings aus? Dort müsste dann ja ein Zeitstempel enthalten sein?
# Wie sehen die DB-Einträge jetzt aus? Ist dort in der Spalte "Events" der korrekte Zeitstempel eingetragen?