93_DbLog - Umstellung Log-Funktion auf non-blocking

[DeeSPe]

Hi Dan und Joe,

Denke das wäre von Vorteil. Wir haben bis jetzt nur die Log-Funktion non-blocking im asynchron-Mode implementiert. Hat sich länger hingezogen als anfangs vermutet. Ich möchte morgen Abend die jetzige letzte Version 2.11 einchecken.
Dann könnten wir uns deiner Funktion zuwenden um die non-blocking hier mit zu integrieren. Das wäre sicher eine Aufwertung für das Modul um Umsteigern den Wechsel zu DbLog zu erleichtern.
Aber für heute ist erstmal Schluß ...

Wünsche euch einen guten Start in die Woche !
Heiko

Sehe ich genau so, deswegen ist ja auch mein Modul entstanden!
Habe mich nämlich auch ewig davor gescheut auf DbLog umzustellen wegen der Altdatenmigration.
Ein paar FileLogs habe ich schon (blocking) importiert, mit dem Rest werde ich mal warten bis wir das ordentlich hinbekommen haben.
Aber zumindest sind wir ja schonmal auf dem Weg...

Gute Nacht allerseits!

Gruß
Dan

[JoeALLb]

Ich musste damals auch ewig viel Zeit inwestieren, um die Logs per Regex ordentlich aufzutrennen... das ist ein tatsächlicher
Showstopper.
@Heiko: Soll ich das drüben bei den Verbesserungsideen mit aufnehmen oder möchtest Du das lieber hier in diesem Zug mit andenken?
Auch eine integrierte non-blocking Backupmöglichkeit der DB-Daten wäre hilfreich, denn auch das normale mysqldump blockiert standardmäßig die Datenbank.

[DS_Starter]

Morgen Joe,

Nimm das Mal in deinem Verbesserungen mit auf damit wir nicht zu sehr durcheinander geraten. Ich mache heute Abend eine Arbeitsversion für die Integration von Dan's Migration.

Grüße
Heiko

[ghayne]

Hallo zusammen,

ich habe die 2.11 seit Gestern laufen (Asynchron), scheint einwanfrei zu funktionieren.

Ich speicher unsere momentan Leistungsaufnahme in Watt auf (siehe Diagram) mit ein Photodiode am Strom Meter (800 Impulse pro kWh).

Grafik sieht sauber aus. Bei 5 kW kommen die Impulse innerhalb eine Sekunde.

Zum Thema DbLog Verbessurungen: Ich werde gern eine Moeglichkeit haben die Datenstruktur des Datenbank selbst zu definieren,
das Feld EVENT koennte wegfallen um Redundanzen zu reduzieren z.B.

Regards, Garry

[JoeALLb]

Zum Thema DbLog Verbessurungen: Ich werde gern eine Moeglichkeit haben die Datenstruktur des Datenbank selbst zu definieren,
das Feld EVENT koennte wegfallen um Redundanzen zu reduzieren z.B.

Hallo Garry, danke! Optimierungsüberlegungen haben wir in einen eigennen Thread unter https://forum.fhem.de/index.php/topic,65860.0.html verschoben.
Ich sehe dies aber ähnlich wie du und könnte zusätzlich noch auf die Units-Spalte verzichten, zumindest so wie sie aktuell genutzt wird!

[ghayne]

Hi Dan und Joe,

Denke das wäre von Vorteil. Wir haben bis jetzt nur die Log-Funktion non-blocking im asynchron-Mode implementiert. Hat sich länger hingezogen als anfangs vermutet. Ich möchte morgen Abend die jetzige letzte Version 2.11 einchecken.
Dann könnten wir uns deiner Funktion zuwenden um die non-blocking hier mit zu integrieren. Das wäre sicher eine Aufwertung für das Modul um Umsteigern den Wechsel zu DbLog zu erleichtern.
Aber für heute ist erstmal Schluß ...

Wünsche euch einen guten Start in die Woche !
Heiko

Hallo Heiko,
hast du es shon eingecheckt (2.11)?
Ich habe gerade ein neu Installation gemacht und moechte wissen ob ich das noch per Hand machen soll.

Regards, Garry

[DS_Starter]

Hallo zusammen,

habe die Version 2.11.1 angehängt die ich heute Abend einchecken werde. Habe noch einige auskommentierte Teile aufgeräumt und ein paar zusätzliche Ausgaben für das Logfile hinzugefügt, falls im synchronen Mode Fehlermitteilungen bei Commit oder Rollback vorkommen sollten.

@Garry, würde es dir reichen von dir nicht benötigte Felder einfach nicht zu füllen ?
Das wäre über ein Attribut relativ einfach zu realisieren und würde keine Strukturänderung bedeuten was bei so vielen Anwendern des Moduls wahrscheinlich sehr problembehaftet wäre.
Bitte antworte in diesem Thread https://forum.fhem.de/index.php/topic,65860.0.html. Dort wollen wir allgemeine Verbesserungen diskutieren.

Garry, lade dir gleich die hier angehängte Datei herunter. Das Einchecken mache ich erst noch heute Abend, dann ist es morgen früh im Update verfügbar.

viele Grüße and Regards
Heiko

[DS_Starter]

Hallo Dan,

habe uns hier https://forum.fhem.de/index.php/topic,65860.msg573498.html#msg573498 die Arbeitsdatei für die Migration erstellt.

Grüße
Heiko

[DeeSPe]

Hallo Dan,

habe uns hier https://forum.fhem.de/index.php/topic,65860.msg573498.html#msg573498 die Arbeitsdatei für die Migration erstellt.

Grüße
Heiko

Ui ui ui, Du bist ja auf Zack!

Habe heute irgendwie kein Händchen für Code.
Probiere mich eher bescheiden gerade an BlockingCall.

Vielleicht läuft es morgen wieder besser...

Gruß
Dan

[DS_Starter]

Hallo miteinander,

habe die Version 2.11.1 eingecheckt.

@Dan

Ui ui ui, Du bist ja auf Zack!

Das täuscht .. habe nur aus meinem anderen Modul geklaut und etwas angepasst
Für mich ist aber auch wieder Schluß für heute ..

Gute Nacht allerseits ..
Heiko

[MichaelT]

Hallo Heiko,

habe Update durchgeführt, scheint alles zu funktionieren.

Danke für deine Bemühungen.

Gruß
Michael

[Sunny]

Moin Heiko,

habe mit der Version 2.11.1 wieder die Probleme, das die Plotts, nicht "komplett" gefüllt werden.
Nutze inzwischen folgende Attr:

Code Auswählen Erweitern

DbLogExclude   .*
DbLogType        Current/History
asyncMode        1
shutdownWait  10
suppressUndef  1

Ist mir gerade aufgefallen.
Werde mal schauen, ob es mit "asyncMode 0" auch auftritt.

Besten Dank
sunny

<Edit an>
Nachtrag :
Mit "asyncMode 0" scheint, das Problem gelösst. 

<Edit aus>

[DS_Starter]

Hallo sunny,

auch wenn mit asynch=0 dein Problem gelöst ist, würde ich gern noch dahinterkommen wieso du mit deiner SQLite überhaupt dieses Verhalten hast und bei mir es in beiden Modi ohne irgendwelche issues läuft. Dass SQLite scheinbar ein bisschen "speziell" sein kann, habe ich inzwischen gelernt.

Aber deswegen habe ich in der angehängten V2.11.3 die Logausgabe für bestimmte DB-Funktionen im asynchronen Mode ergänzt. Ich hoffe dass wir vllt. noch einen Hinweis darauf bekommen was bei dir die Ursache sein könnte dass es im asynch Mode zu diesem Verhalten kommt.

Wenn du magst, kannst du auch eine neue Funktionalität ausprobieren. Wenn du Attr "colEvent=0" setzt, sollte nun auch bei SQLite das Feld EVENT in der DB nicht beschrieben werden (um Platz zu sparen). Siehe auch hier: https://forum.fhem.de/index.php/topic,65860.msg574086.html#msg574086

Installiere dir mal bitte diese Version und arbeite in beiden Modi. Interessant wären dann eventuelle Ausgabe im Logfile.

viele Grüße
Heiko

[JoeALLb]

Hallo Sunny, nur zum sicher sein... auch mit async=1 wenn die Plots nicht vollständig sind, stehen hier (siehe Anhang)
in diesem Feld sämtliche Zahlen oder fehlen hier diese, den Plot "unvollständig" machen?

Ich möchte nur sicher sein dass dies nicht mit dem javascript zusammenhängt... danke!

[Sunny]

Moin JoeALLb,

die Daten sind sowohl mit async=1 oder 0 vorhanden (sqlite auf BPI und Rpi2 jeweils mit SSD als root) .
Sie fehlen nur in den SVG's bei async=0 weniger häufig.

Ein reload des Browsers  (Firefox Win10 / Android) lässt unterschiedliche Ansichten erscheinen.
(siehe Link aus letzten Antwort, das Problem von Chris und mir.)

Dein Tipp, habe ich noch nicht getestet. Komme hoffentlich am WE dazu dieses einzurichten und dann zu protokollieren.

Besten Dank
&
Viele Grüße
sunny