Neues Modul 98_FileLogConvert.pm - FileLog Import in DbLog und mehr

[DeeSPe]

Ein File wurde nicht komplett importiert, wie kann ich diesen erneut importieren?

Einfach die Datei mit selben Namen wie die zu importierende Log Datei und Endung mit Namen des DbLog Devices im Log Ordner löschen.
Dann ist ein erneuter Import möglich.

Gruß
Dan

[DS_Starter]

Hi Dan,

jetzt habe ich mal wieder hier im Thread gestöbert und dabei ist mir aufgefallen dass mindestens ein Nutzer Schwierigkeiten mit dem Import der Daten nach SQLite hatte  (#48),mit MySQL es hingegen problemlos fuinktioniert.
Hab eine Weile darüber nachgedacht und bin jetzt zu dem Schluß gekommen, dass die Verwendung der DbLog_ExecSQL für den Import deiner "Massendaten" in Verbindung mit SQLite suboptimal ist. Die DbLog_ExecSQL greift sofort über einen eigenen DB-Handle auf die DB zu. Das kann natürlich zu einem konkurrierenden Schreibprozess mit dem normalen Logging führen. MySQL und jede andere "richtige" DB kann das handeln, dafür ist es ja ein DBMS, aber wie ich SQLite kennengelernt habe .... naja.

Also ich würde dir vorschlagen, dass ich dir ein extra Interface zur Verfügung stelle an das du einfach einen String der Art:

Code Auswählen Erweitern

my $row = ($timestamp."|".$device."|".$type."|".$event."|".$reading."|".$value."|".$unit);

übergeben kannst (kann auch ein Array sein). In der Schnittstelle würde ich den String dann entsprechend des DbLog-Betriebsmodus in den Cache bzw. Push-Array einfügen und die Daten würden so gemeinsamen mit den normalen Loggingzyklen in die DB geschrieben werden. Damit würden parallele Schreibzyklen vermieden und das kann für jeden DB-Typ angewendet werden.

Als Abfallprodukt kann ich die einzelnen Bestandteile über die standard Längenbegrenzung in DBlog schicken bzw. kann der User über das Attr valueFn auf die Importdaten Einfluss nehmen (Units hinzufügen u.ä.). Dadurch entsteht sogar noch ein Mehrwert für den User, sofern er sich damit ein wenig auseinandersetzen möchte.

Das Prinzip kannst du dir in der Sub DbLog_AddLog anschauen, wobei es sich nur auf die Längenbeschneidung, valueFn und Array-Verarbeitung bezieht.

Wie denkst du darüber ?

Grüße
Heiko

[DeeSPe]

Hi Dan,

jetzt habe ich mal wieder hier im Thread gestöbert und dabei ist mir aufgefallen dass mindestens ein Nutzer Schwierigkeiten mit dem Import der Daten nach SQLite hatte  (#48),mit MySQL es hingegen problemlos fuinktioniert.
Hab eine Weile darüber nachgedacht und bin jetzt zu dem Schluß gekommen, dass die Verwendung der DbLog_ExecSQL für den Import deiner "Massendaten" in Verbindung mit SQLite suboptimal ist. Die DbLog_ExecSQL greift sofort über einen eigenen DB-Handle auf die DB zu. Das kann natürlich zu einem konkurrierenden Schreibprozess mit dem normalen Logging führen. MySQL und jede andere "richtige" DB kann das handeln, dafür ist es ja ein DBMS, aber wie ich SQLite kennengelernt habe .... naja.

Also ich würde dir vorschlagen, dass ich dir ein extra Interface zur Verfügung stelle an das du einfach einen String der Art:

Code Auswählen Erweitern

my $row = ($timestamp."|".$device."|".$type."|".$event."|".$reading."|".$value."|".$unit);

übergeben kannst (kann auch ein Array sein). In der Schnittstelle würde ich den String dann entsprechend des DbLog-Betriebsmodus in den Cache bzw. Push-Array einfügen und die Daten würden so gemeinsamen mit den normalen Loggingzyklen in die DB geschrieben werden. Damit würden parallele Schreibzyklen vermieden und das kann für jeden DB-Typ angewendet werden.

Als Abfallprodukt kann ich die einzelnen Bestandteile über die standard Längenbegrenzung in DBlog schicken bzw. kann der User über das Attr valueFn auf die Importdaten Einfluss nehmen (Units hinzufügen u.ä.). Dadurch entsteht sogar noch ein Mehrwert für den User, sofern er sich damit ein wenig auseinandersetzen möchte.

Das Prinzip kannst du dir in der Sub DbLog_AddLog anschauen, wobei es sich nur auf die Längenbeschneidung, valueFn und Array-Verarbeitung bezieht.

Wie denkst du darüber ?

Grüße
Heiko

Das klingt gut Heiko.
Ich bin wirklich kein DB-Profi, weiß allerdings wie man Daten dort rein schreibt und wie man sie wieder heraus holt.
Darum wusste ich auch nicht woher das Problem kommen kann.
Deine Aussage macht aber absolut Sinn.
Hab also nichts dagegen wenn Du da etwas besseres bereitstellen könntest. Ich nehme an das wäre eine eigene Sub dafür.

Gruß
Dan

[DS_Starter]

Ich habe auch eine Weile gebraucht um eine mögliche Ursache zu identifizieren, aber wenn ich SQLite lese gehen bei mir alle Alarmglocken an. 

Ja das wäre eigene Sub, also z.B. DbLog_Filelogconv.
An die würdest du einfach den beschriebenen String übergeben. Die Übernahme in das Logarray würde dblog quittieren.
Im synchronen mode wäre der DS dann auch in der DB, im asynchronen mode entsprechend später.

Für einen ersten Test würde ich erstmal nur mit einem String als Übergabeobjekt arbeiten.
Quasi übergibst du einen  String

Code Auswählen Erweitern

$timestamp."|".$device."|".$type."|".$event."|".$reading."|".$value."|".$unit
nach dem anderen der halt in die DB geschrieben werden soll.

Ich aber das Interface erstmal vorbereiten stelle eine Testversion zur Verfügung.

LG
Heiko

[DeeSPe]

Ich habe auch eine Weile gebraucht um eine mögliche Ursache zu identifizieren, aber wenn ich SQLite lese gehen bei mir alle Alarmglocken an. 

Ja das wäre eigene Sub, also z.B. DbLog_Filelogconv.
An die würdest du einfach den beschriebenen String übergeben. Die Übernahme in das Logarray würde dblog quittieren.
Im synchronen mode wäre der DS dann auch in der DB, im asynchronen mode entsprechend später.

Für einen ersten Test würde ich erstmal nur mit einem String als Übergabeobjekt arbeiten.
Quasi übergibst du einen  String

Code Auswählen Erweitern

$timestamp."|".$device."|".$type."|".$event."|".$reading."|".$value."|".$unit
nach dem anderen der halt in die DB geschrieben werden soll.

Ich aber das Interface erstmal vorbereiten stelle eine Testversion zur Verfügung.

LG
Heiko

Wenn Du selbst testen möchtest, Zeile 267 ändern in:

Code Auswählen Erweitern

DbLog_Filelogconv($defs{$dblog},"$i_date $i_time|$i_device|$i_type|$i_event|$i_reading|$i_value|$i_unit") if ($cmd eq "import2DbLog");
Das sollte dem entsprechen was Du Dir vorstellst.

Danke für Deinen weiterführenden Einsatz.

Gruß
Dan

[DS_Starter]

Hi Dan,

jetzt habe ich eine ganze Weile versucht das Interface im asynchronen Modus zum Laufen zu bringen. Das ist mir nicht gelungen ... bis es mir wie Schuppen von den Augen gefallen ist, dass das ja garnicht funktionieren kann. Das Interface wird ja aus einem Blockingcall heraus aufgerufen. Dadurch ist es nicht möglich Werte im Hash des Hauptprozesses zu setzen (den Cache). Dadurch ist das Konstrukt nicht möglich.

Dann würde ich sagen lassen wir es so wie es ist und ich baue ein Steuerbit ein dass im Falle der Kombination "asynchroner Mode && SQLite && ExecSQL in Ausführung" der asynchrone Schreibprozess verhindert wird, d.h. Daten bleiben im Cache und wenn ExecSQL fertig, wird er wieder freigegeben.
Denke so passt es vllt. sogar besser (auch für andere Situationen). Ich weiß ja nicht wer noch so über dieses Interface schreibt.

Grüße
Heiko   

[DeeSPe]

Hi Dan,

jetzt habe ich eine ganze Weile versucht das Interface im asynchronen Modus zum Laufen zu bringen. Das ist mir nicht gelungen ... bis es mir wie Schuppen von den Augen gefallen ist, dass das ja garnicht funktionieren kann. Das Interface wird ja aus einem Blockingcall heraus aufgerufen. Dadurch ist es nicht möglich Werte im Hash des Hauptprozesses zu setzen (den Cache). Dadurch ist das Konstrukt nicht möglich.

Dann würde ich sagen lassen wir es so wie es ist und ich baue ein Steuerbit ein dass im Falle der Kombination "asynchroner Mode && SQLite && ExecSQL in Ausführung" der asynchrone Schreibprozess verhindert wird, d.h. Daten bleiben im Cache und wenn ExecSQL fertig, wird er wieder freigegeben.
Denke so passt es vllt. sogar besser (auch für andere Situationen). Ich weiß ja nicht wer noch so über dieses Interface schreibt.

Grüße
Heiko

Hi Heiko,

ja klar, BlockingCall! Da ist nix mit Daten schreiben im Hash! In diese Falle bin ich auch schon getappt.

Dein neues Vorhaben klingt auch gut wenn Du es denn so implementiert bekommst.

Gruß
Dan

[DS_Starter]

Dein neues Vorhaben klingt auch gut wenn Du es denn so implementiert bekommst.

Geht ja genauso wenig ... ist ja das gleiche Prob wie vorhin beschrieben.
Also da bleibt wohl nur SQLite Nutzer bei Nutzung der Importfunktion aufzufordern den synchronen Mode einzuschalten, weil sich dann alles in der Hauptschleife abspielt.

[DeeSPe]

Geht ja genauso wenig ... ist ja das gleiche Prob wie vorhin beschrieben.
Also da bleibt wohl nur SQLite Nutzer bei Nutzung der Importfunktion aufzufordern den synchronen Mode einzuschalten, weil sich dann alles in der Hauptschleife abspielt.

Wenn das dann problemlos funktioniert ist das auch eine Lösung.
Manchmal muss die Lösung doch nicht programmatisch sein.

Gruß
Dan

[abc2006]

Hi,
ich habe gerade mein Test-Fhem neu aufgesetzt und wollte FileLogConvert wieder verwenden.
Dabei tritt folgendes Problem auf: auf dem Testsystem fehlt die Eingabezeile (siehe Bilder), auf dem prooduktivsystem ist alles da.
Die Versionen sind gleich, 15500.
Cache hab ich geleert, System hab ich rebootet. Fhem hab ich *nochmal* neu installiert.
Hilft aber nicht.

Ich glaube, ich hatte so ein Problem auch schon mal, aber ich kann mich nicht mehr erinnern, wie ich es gelöst hatte. Hab auch bisher leider nix gefunden dazu, deshalb wär ich für Tipps dankbar. Kann das am Modul liegen?

Grüße,
Stephan

[DeeSPe]

Welche set und get Befehle sollten Deiner Meinung nach angezeigt werden wenn es keine log Dateien gibt?

Gruß
Dan

[abc2006]

Hi,

ist okay, allerdings hätte ich erwartet, dass die Eingabefelder ausgegraut sind, oder ein Hinweis, dass keine Logfiles vorhanden sind (okay, hätte man vermuten können)...

Aber die Eingabefelder auszublenden, finde ich zumindest nicht so richtig intuitiv.

Hat aber jetzt geklappt, alles klar, kein Problem.

Danke für den hilfreichen Hinweis!

Grüße,
Stephan

[pklaus]

Hallo allerseits!

Vielen Dank für das schöne Modul! Ich habe es in Verwendung, um viele große logfiles in meine PostgreSQL Datenbank zu importieren. Damit ich nicht jeden Import-Vorgang von Hand anstoßen muss, habe ich mir ein Python-Skript geschrieben (ja, sorry, Python!). Es weist per Telnet den FHEM-Server an, eins nach dem anderen zu importieren und dann jeweils zu warten, bis das nächste dran ist.. Wenn es jemandem hilft:

https://gist.github.com/pklaus/61212fee9ba16d9834140893aec306e5

(Es läuft unter Python 3.6 und Python 2.7)

[docolli]

Hallo und ebenfalls vielen Dank für dieses hilfreiche Modul. Nach langer Zeit habe ich mich endlich ans Thema "Umstellung von FileLog auf DBLog" gemacht und dank deines Moduls auch gewagt. Es klappt.

Das einzige, was mich persönlich etwas stört, ist die Wahl von "convert2csv" als Standardauswahl beim Set-Befehl. Ich habe seit 2015 eine Menge Logfiles angesammelt (monatliche Files), sodaß ich jetzt erst mal dasitze und manuell File für File konvertieren lassen. Den Befehl habe ich in der Zwischenablage und passe nur Monat/Jahr an, aber was ich immer wieder vergesse ist, auch das Dropdown umzustellen... Ich denke, die meisten werden dein Modul zur Konvertierung in eine DB nutzen und weniger in CSV bzw. SQL. Kann man also den Standardwert des Dropdown ändern? Entweder im Code, oder gar als Attribut?

Ansonsten gibt es ja noch das Script meines Vorposters, das ich gleich testen werde, damit es automatisiert abläuft.

--------
Edit hat ein paar Tippfehler verbessert...

[Tueftler1983]

Hallo, habe alle Log's auf der SSD unter /media/ssd/log/
Allerdings wenn ich in dem device die logdir angeben will kommt immer die Meldung das das Verzeichnis nicht existiert.

Was kann ich tun