FHEM Forum

Das Modul ist nun im SVN unter contrib/98_FileLogConvert.pm (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_FileLogConvert.pm) zu finden.

Zu diesem neuen Modul gibt es bereits einen Beitrag unter Codeschnipsel (https://forum.fhem.de/index.php/topic,65982.msg572349.html#msg572349).

Da ich das Modul gern offiziell in's SVN einchecken möchte, hoffe ich somit auf mehr Tester und Feedback.

Mit diesem Modul ist es möglich FileLog Dateien in die DbLog zu importieren oder die FileLog Dateien in CSV oder SQL Dateien zu konvertieren.

Das Modul ist komplett non-blocking und ich habe mittlerweile damit alle meine FileLog Dateien erfolgreich in meine DbLog importiert.

Features:

• Modul ist non-blocking und kann problemlos auf Produktivsystemem eingesetzt werden
• Analyse der vorhandenen Events in den FileLog Dateien
• Import/Konvertierung nur von bestimmten Events
• es kann nur ein Import/Konvertierung/Analyse Job auf einmal gestartet werden, falls man einen neuen Job starten will und der vorherige noch nicht beendet ist, so wird eine Fehlermeldung ausgegeben
• falls das Device im Log mit selben Namen im bestehenden FHEM existiert, so wird auch dessen TYPE in die DB geschrieben, andernfalls bleibt TYPE in der DB leer
• falls vorhanden wird auch UNIT in der DB befüllt
• im Attribut logdir kann ein alternativer Ordner für die FileLog Dateien angegeben werden - dieser Ordner muss sich auch unter ".../fhem/" befinden
• in state wird der aktuelle Status (analysing/imorting/converting) dargestellt
• Eingaben bei Set und Attribut werden validiert und ggf. eine Fehlermeldung zurück gegeben
• Fehlerausgabe wenn Log Datei nicht vorhanden ist

Einrichtung

Nach dem Herunterladen der Datei "98_FileLogConvert.pm", diese in den Ordner "..../fhem/FHEM/" ablegen und mit "reload 98_FileLogConvert" in FHEM verfügbar machen.
Wenn man nur ein DbLog Device hat, so wird dieses beim Definieren des FileLogConvert Device automatisch gefunden. Andernfalls muss der Name des bestimmten DbLog Device beim Definieren mit angegeben werden.

Zitatdefine <name> FileLogConvert [DbLog-device]

Beispiel:
define LogConvert FileLogConvert dblog

Das Analysieren und Konvertieren der Dateien dauert mit unter sehr lange (abhängig von der Größe).
Der Import in die DbLog dauert noch mal wesentlich länger!
Also entspannt zurücklehnen und abwarten!!!

Man kann und sollte erst einmal die vorhandenen FileLog Datei(en) analysieren:
get <name> fileEvents FileLog-Datei.log

Es werden sämtliche vorhandenen Events im Reading events aufgelistet.
Zusätzlich werden aus den gefunden Events Vorschläge zu möglichen set Kommandos in den Readings command-csv, command-db und command-sql erstellt. Mit diesen Kommandos ist es möglich nur bestimmte vorkommende Events zu konvertieren/importieren (einfach die nicht zu importierenden/konvertierenden Events weglassen).
Die Anzahl der analysierten Zeilen wird im Reading lines-analysed angezeigt.

Sobald eine Datei konvertiert/importiert wurde, ist es nicht mehr möglich diese erneut zu konvertieren/importieren! ;)
Damit das auch beim Import nach DbLog klappt wird eine (Mini)Datei geschrieben die genau so heißt wie die FileLog Datei, aber sie trägt die Endung mit dem Namen des jeweiligen DbLog Device. Das ist darum, damit man bei mehreren vorhandenen DbLog Devices weiß wo schon importiert wurde.

Probiert es einfach mal aus.
Mir hat es schon einiges an Zeit erspart beim Importieren der Alt-Daten.

Eine komplette englische commandref ist schon enthalten.

Bitte gebt mir Feedback ob das Modul so arbeitet wie beworben und ob es bei Euch Schwierigkeiten gibt/gab.
Was sagt Ihr zu dem Namen des Moduls? Ist daraus ersichtlich was es macht? Oder sollte ich noch einmal über einen anderen Namen nachdenken?

Falls Fragen sind, immer her damit!

Viel Spaß.

Gruß
Dan

Hier mal ein Auszug aus meinem Import-Log nach DbLog, damit Ihr mal sehen könnt wie lange der Import so ca. dauern kann.
Der Import lief auf meinem Produktiv-System auf einem Brix GB-BACE-3000 mit 4 GB RAM und SSD.

2017-02-02 21:43:09 FileLogConvert LogConvert state: importing fl_Sensor-2017.log
2017-02-02 21:43:38 FileLogConvert LogConvert state: import done
2017-02-02 21:43:38 FileLogConvert LogConvert file-source: fl_Sensor-2017.log
2017-02-02 21:43:38 FileLogConvert LogConvert destination: logdb
2017-02-02 21:43:38 FileLogConvert LogConvert lines-analysed: 10123
2017-02-02 21:43:38 FileLogConvert LogConvert lines-imported: 10123

2017-02-02 21:47:14 FileLogConvert LogConvert state: importing fl_Tuer-2016.log
2017-02-02 21:47:23 FileLogConvert LogConvert state: import done
2017-02-02 21:47:23 FileLogConvert LogConvert file-source: fl_Tuer-2016.log
2017-02-02 21:47:23 FileLogConvert LogConvert destination: logdb
2017-02-02 21:47:23 FileLogConvert LogConvert lines-analysed: 6478
2017-02-02 21:47:23 FileLogConvert LogConvert lines-imported: 3170

2017-02-02 21:50:01 FileLogConvert LogConvert state: importing ku_Fenster-2016.log
2017-02-02 21:50:10 FileLogConvert LogConvert state: import done
2017-02-02 21:50:10 FileLogConvert LogConvert file-source: ku_Fenster-2016.log
2017-02-02 21:50:10 FileLogConvert LogConvert destination: logdb
2017-02-02 21:50:10 FileLogConvert LogConvert lines-analysed: 9215
2017-02-02 21:50:10 FileLogConvert LogConvert lines-imported: 2849

2017-02-02 21:53:24 FileLogConvert LogConvert state: importing ku_Heizung-2017.log
2017-02-02 21:54:06 FileLogConvert LogConvert state: import done
2017-02-02 21:54:06 FileLogConvert LogConvert file-source: ku_Heizung-2017.log
2017-02-02 21:54:06 FileLogConvert LogConvert destination: logdb
2017-02-02 21:54:06 FileLogConvert LogConvert lines-analysed: 14741
2017-02-02 21:54:06 FileLogConvert LogConvert lines-imported: 14741

2017-02-02 21:56:20 FileLogConvert LogConvert state: importing ku_Heizung-2016.log
2017-02-02 22:26:33 FileLogConvert LogConvert state: import done
2017-02-02 22:26:33 FileLogConvert LogConvert file-source: ku_Heizung-2016.log
2017-02-02 22:26:33 FileLogConvert LogConvert destination: logdb
2017-02-02 22:26:33 FileLogConvert LogConvert lines-analysed: 910771
2017-02-02 22:26:33 FileLogConvert LogConvert lines-imported: 614305

2017-02-02 23:14:09 FileLogConvert LogConvert state: importing ku_SD1-2016.log power|energy
2017-02-02 23:17:13 FileLogConvert LogConvert state: import done
2017-02-02 23:17:13 FileLogConvert LogConvert file-source: ku_SD1-2016.log
2017-02-02 23:17:13 FileLogConvert LogConvert destination: logdb
2017-02-02 23:17:13 FileLogConvert LogConvert lines-analysed: 66352
2017-02-02 23:17:13 FileLogConvert LogConvert lines-imported: 64006

2017-02-02 23:23:50 FileLogConvert LogConvert state: importing ku_SD1-2017.log
2017-02-02 23:24:01 FileLogConvert LogConvert state: import done
2017-02-02 23:24:01 FileLogConvert LogConvert file-source: ku_SD1-2017.log
2017-02-02 23:24:01 FileLogConvert LogConvert destination: logdb
2017-02-02 23:24:01 FileLogConvert LogConvert lines-analysed: 3859
2017-02-02 23:24:01 FileLogConvert LogConvert lines-imported: 3859

2017-02-02 23:24:34 FileLogConvert LogConvert state: importing ku_SD2-2017.log power|energy
2017-02-02 23:25:51 FileLogConvert LogConvert state: import done
2017-02-02 23:25:51 FileLogConvert LogConvert file-source: ku_SD2-2017.log
2017-02-02 23:25:51 FileLogConvert LogConvert destination: logdb
2017-02-02 23:25:51 FileLogConvert LogConvert lines-analysed: 26855
2017-02-02 23:25:51 FileLogConvert LogConvert lines-imported: 26855

2017-02-02 23:26:01 FileLogConvert LogConvert state: importing ku_SD2-2016.log power|energy
2017-02-02 23:27:23 FileLogConvert LogConvert state: import done
2017-02-02 23:27:23 FileLogConvert LogConvert file-source: ku_SD2-2016.log
2017-02-02 23:27:23 FileLogConvert LogConvert destination: logdb
2017-02-02 23:27:23 FileLogConvert LogConvert lines-analysed: 32346
2017-02-02 23:27:23 FileLogConvert LogConvert lines-imported: 27804

2017-02-02 23:27:56 FileLogConvert LogConvert state: importing ku_SD3-2016.log power|energy
2017-02-02 23:34:07 FileLogConvert LogConvert state: import done
2017-02-02 23:34:07 FileLogConvert LogConvert file-source: ku_SD3-2016.log
2017-02-02 23:34:07 FileLogConvert LogConvert destination: logdb
2017-02-02 23:34:07 FileLogConvert LogConvert lines-analysed: 317687
2017-02-02 23:34:07 FileLogConvert LogConvert lines-imported: 123009

2017-02-02 23:34:51 FileLogConvert LogConvert state: importing ku_SD3-2017.log power|energy
2017-02-02 23:35:06 FileLogConvert LogConvert state: import done
2017-02-02 23:35:06 FileLogConvert LogConvert file-source: ku_SD3-2017.log
2017-02-02 23:35:06 FileLogConvert LogConvert destination: logdb
2017-02-02 23:35:06 FileLogConvert LogConvert lines-analysed: 5348
2017-02-02 23:35:06 FileLogConvert LogConvert lines-imported: 5031

2017-02-02 23:35:37 FileLogConvert LogConvert state: importing ku_SD4-2016.log power|energy
2017-02-02 23:36:19 FileLogConvert LogConvert state: import done
2017-02-02 23:36:19 FileLogConvert LogConvert file-source: ku_SD4-2016.log
2017-02-02 23:36:19 FileLogConvert LogConvert destination: logdb
2017-02-02 23:36:19 FileLogConvert LogConvert lines-analysed: 25379
2017-02-02 23:36:19 FileLogConvert LogConvert lines-imported: 14688

2017-02-02 23:36:39 FileLogConvert LogConvert state: importing ku_SD4-2017.log power|energy
2017-02-02 23:36:46 FileLogConvert LogConvert state: import done
2017-02-02 23:36:46 FileLogConvert LogConvert file-source: ku_SD4-2017.log
2017-02-02 23:36:46 FileLogConvert LogConvert destination: logdb
2017-02-02 23:36:46 FileLogConvert LogConvert lines-analysed: 2624
2017-02-02 23:36:46 FileLogConvert LogConvert lines-imported: 2499

2017-02-02 23:37:12 FileLogConvert LogConvert state: importing ku_SD5-2016.log power|energy
2017-02-02 23:37:44 FileLogConvert LogConvert state: import done
2017-02-02 23:37:44 FileLogConvert LogConvert file-source: ku_SD5-2016.log
2017-02-02 23:37:44 FileLogConvert LogConvert destination: logdb
2017-02-02 23:37:44 FileLogConvert LogConvert lines-analysed: 22570
2017-02-02 23:37:44 FileLogConvert LogConvert lines-imported: 11069

2017-02-02 23:41:14 FileLogConvert LogConvert state: importing ku_SD5-2017.log power|energy
2017-02-02 23:41:31 FileLogConvert LogConvert state: import done
2017-02-02 23:41:31 FileLogConvert LogConvert file-source: ku_SD5-2017.log
2017-02-02 23:41:31 FileLogConvert LogConvert destination: logdb
2017-02-02 23:41:31 FileLogConvert LogConvert lines-analysed: 8005
2017-02-02 23:41:31 FileLogConvert LogConvert lines-imported: 5974

2017-02-02 23:41:36 FileLogConvert LogConvert state: importing ku_SD6-2016.log power|energy
2017-02-02 23:42:10 FileLogConvert LogConvert state: import done
2017-02-02 23:42:10 FileLogConvert LogConvert file-source: ku_SD6-2016.log
2017-02-02 23:42:10 FileLogConvert LogConvert destination: logdb
2017-02-02 23:42:10 FileLogConvert LogConvert lines-analysed: 23351
2017-02-02 23:42:10 FileLogConvert LogConvert lines-imported: 11427

2017-02-02 23:42:38 FileLogConvert LogConvert state: importing ku_SD6-2017.log power|energy
2017-02-02 23:44:21 FileLogConvert LogConvert state: import done
2017-02-02 23:44:21 FileLogConvert LogConvert file-source: ku_SD6-2017.log
2017-02-02 23:44:21 FileLogConvert LogConvert destination: logdb
2017-02-02 23:44:21 FileLogConvert LogConvert lines-analysed: 37672
2017-02-02 23:44:21 FileLogConvert LogConvert lines-imported: 35628

2017-02-02 23:48:01 FileLogConvert LogConvert state: importing ku_Sensor-2016.log luminance|temperature|battery
2017-02-02 23:53:14 FileLogConvert LogConvert state: import done
2017-02-02 23:53:14 FileLogConvert LogConvert file-source: ku_Sensor-2016.log
2017-02-02 23:53:14 FileLogConvert LogConvert destination: logdb
2017-02-02 23:53:14 FileLogConvert LogConvert lines-analysed: 106463
2017-02-02 23:53:14 FileLogConvert LogConvert lines-imported: 105127

2017-02-02 23:58:30 FileLogConvert LogConvert state: importing ku_Sensor-2017.log
2017-02-02 23:59:04 FileLogConvert LogConvert state: import done
2017-02-02 23:59:04 FileLogConvert LogConvert file-source: ku_Sensor-2017.log
2017-02-02 23:59:04 FileLogConvert LogConvert destination: logdb
2017-02-02 23:59:04 FileLogConvert LogConvert lines-analysed: 9282
2017-02-02 23:59:04 FileLogConvert LogConvert lines-imported: 9282

2017-02-03 00:16:19 FileLogConvert LogConvert state: importing ku_Sensor_TH1-2016.log temperature|humidity|dewpoint
2017-02-03 00:48:30 FileLogConvert LogConvert state: import done
2017-02-03 00:48:30 FileLogConvert LogConvert file-source: ku_Sensor_TH1-2016.log
2017-02-03 00:48:30 FileLogConvert LogConvert destination: logdb
2017-02-03 00:48:30 FileLogConvert LogConvert lines-analysed: 909457
2017-02-03 00:48:30 FileLogConvert LogConvert lines-imported: 645164

2017-02-03 00:56:03 FileLogConvert LogConvert state: importing ku_Sensor_TH1-2017.log dewpoint|temperature|humidity
2017-02-03 00:59:31 FileLogConvert LogConvert state: import done
2017-02-03 00:59:31 FileLogConvert LogConvert file-source: ku_Sensor_TH1-2017.log
2017-02-03 00:59:31 FileLogConvert LogConvert destination: logdb
2017-02-03 00:59:31 FileLogConvert LogConvert lines-analysed: 71498
2017-02-03 00:59:31 FileLogConvert LogConvert lines-imported: 70800

2017-02-03 01:02:07 FileLogConvert LogConvert state: importing ku_Sensor_TH2-2017.log dewpoint|humidity|temperature
2017-02-03 01:07:04 FileLogConvert LogConvert state: import done
2017-02-03 01:07:04 FileLogConvert LogConvert file-source: ku_Sensor_TH2-2017.log
2017-02-03 01:07:04 FileLogConvert LogConvert destination: logdb
2017-02-03 01:07:04 FileLogConvert LogConvert lines-analysed: 95190
2017-02-03 01:07:04 FileLogConvert LogConvert lines-imported: 94446

2017-02-03 01:09:03 FileLogConvert LogConvert state: importing ku_Sensor_TH2-2016.log dewpoint|humidity|temperature
2017-02-03 01:48:37 FileLogConvert LogConvert state: import done
2017-02-03 01:48:37 FileLogConvert LogConvert file-source: ku_Sensor_TH2-2016.log
2017-02-03 01:48:37 FileLogConvert LogConvert destination: logdb
2017-02-03 01:48:37 FileLogConvert LogConvert lines-analysed: 962558
2017-02-03 01:48:37 FileLogConvert LogConvert lines-imported: 698800

2017-02-03 01:51:28 FileLogConvert LogConvert state: importing sz_Fenster-2016.log contact|trigger_cnt|sabotageError
2017-02-03 01:51:40 FileLogConvert LogConvert state: import done
2017-02-03 01:51:40 FileLogConvert LogConvert file-source: sz_Fenster-2016.log
2017-02-03 01:51:40 FileLogConvert LogConvert destination: logdb
2017-02-03 01:51:40 FileLogConvert LogConvert lines-analysed: 10776
2017-02-03 01:51:40 FileLogConvert LogConvert lines-imported: 3705

2017-02-03 01:52:57 FileLogConvert LogConvert state: importing ku_Sensor_TK-2016.log temperature
2017-02-03 02:01:42 FileLogConvert LogConvert state: import done
2017-02-03 02:01:42 FileLogConvert LogConvert file-source: ku_Sensor_TK-2016.log
2017-02-03 02:01:42 FileLogConvert LogConvert destination: logdb
2017-02-03 02:01:42 FileLogConvert LogConvert lines-analysed: 181408
2017-02-03 02:01:42 FileLogConvert LogConvert lines-imported: 180961

2017-02-03 02:03:41 FileLogConvert LogConvert state: importing wz_Heizung-2016.log actuator|batteryLevel|desired-temp|measured-temp
2017-02-03 02:35:00 FileLogConvert LogConvert state: import done
2017-02-03 02:35:00 FileLogConvert LogConvert file-source: wz_Heizung-2016.log
2017-02-03 02:35:00 FileLogConvert LogConvert destination: logdb
2017-02-03 02:35:00 FileLogConvert LogConvert lines-analysed: 908731
2017-02-03 02:35:00 FileLogConvert LogConvert lines-imported: 614675

2017-02-03 02:38:33 FileLogConvert LogConvert state: importing wz_Heizung-2017.log
2017-02-03 02:39:14 FileLogConvert LogConvert state: import done
2017-02-03 02:39:14 FileLogConvert LogConvert file-source: wz_Heizung-2017.log
2017-02-03 02:39:14 FileLogConvert LogConvert destination: logdb
2017-02-03 02:39:14 FileLogConvert LogConvert lines-analysed: 14747
2017-02-03 02:39:14 FileLogConvert LogConvert lines-imported: 14747

2017-02-03 02:39:48 FileLogConvert LogConvert state: importing sz_Heizung-2017.log actuator|batteryLevel|desired-temp|measured-temp
2017-02-03 02:40:40 FileLogConvert LogConvert state: import done
2017-02-03 02:40:40 FileLogConvert LogConvert file-source: sz_Heizung-2017.log
2017-02-03 02:40:40 FileLogConvert LogConvert destination: logdb
2017-02-03 02:40:40 FileLogConvert LogConvert lines-analysed: 18150
2017-02-03 02:40:40 FileLogConvert LogConvert lines-imported: 18150

2017-02-03 11:02:29 FileLogConvert LogConvert state: importing ku_Sensor_TK-2017.log
2017-02-03 11:03:29 FileLogConvert LogConvert state: import done
2017-02-03 11:03:29 FileLogConvert LogConvert file-source: ku_Sensor_TK-2017.log
2017-02-03 11:03:29 FileLogConvert LogConvert destination: logdb
2017-02-03 11:03:29 FileLogConvert LogConvert lines-analysed: 21293
2017-02-03 11:03:29 FileLogConvert LogConvert lines-imported: 21293

2017-02-03 11:07:52 FileLogConvert LogConvert state: importing sz_SD1-2017.log power|energy
2017-02-03 11:08:03 FileLogConvert LogConvert state: import done
2017-02-03 11:08:03 FileLogConvert LogConvert file-source: sz_SD1-2017.log
2017-02-03 11:08:03 FileLogConvert LogConvert destination: logdb
2017-02-03 11:08:03 FileLogConvert LogConvert lines-analysed: 3481
2017-02-03 11:08:03 FileLogConvert LogConvert lines-imported: 3457

2017-02-03 11:08:29 FileLogConvert LogConvert state: importing sz_SD2-2017.log power|energy
2017-02-03 11:08:40 FileLogConvert LogConvert state: import done
2017-02-03 11:08:40 FileLogConvert LogConvert file-source: sz_SD2-2017.log
2017-02-03 11:08:40 FileLogConvert LogConvert destination: logdb
2017-02-03 11:08:40 FileLogConvert LogConvert lines-analysed: 4162
2017-02-03 11:08:40 FileLogConvert LogConvert lines-imported: 4150

2017-02-03 11:09:14 FileLogConvert LogConvert state: importing sz_Sensor-2017.log
2017-02-03 11:09:35 FileLogConvert LogConvert state: import done
2017-02-03 11:09:35 FileLogConvert LogConvert file-source: sz_Sensor-2017.log
2017-02-03 11:09:35 FileLogConvert LogConvert destination: logdb
2017-02-03 11:09:35 FileLogConvert LogConvert lines-analysed: 7378
2017-02-03 11:09:35 FileLogConvert LogConvert lines-imported: 7378

2017-02-03 11:10:36 FileLogConvert LogConvert state: importing sz_Sensor-2016.log temperature|luminance|battery
2017-02-03 11:17:07 FileLogConvert LogConvert state: import done
2017-02-03 11:17:07 FileLogConvert LogConvert file-source: sz_Sensor-2016.log
2017-02-03 11:17:07 FileLogConvert LogConvert destination: logdb
2017-02-03 11:17:07 FileLogConvert LogConvert lines-analysed: 134520
2017-02-03 11:17:07 FileLogConvert LogConvert lines-imported: 134326

2017-02-03 12:37:30 FileLogConvert LogConvert state: importing wz_CO20-2016.log voc
2017-02-03 12:41:19 FileLogConvert LogConvert state: import done
2017-02-03 12:41:19 FileLogConvert LogConvert file-source: wz_CO20-2016.log
2017-02-03 12:41:19 FileLogConvert LogConvert destination: logdb
2017-02-03 12:41:19 FileLogConvert LogConvert lines-analysed: 76364

2017-02-03 12:45:50 FileLogConvert LogConvert state: importing wz_CO20-2017.log
2017-02-03 12:46:12 FileLogConvert LogConvert state: import done
2017-02-03 12:46:12 FileLogConvert LogConvert file-source: wz_CO20-2017.log
2017-02-03 12:46:12 FileLogConvert LogConvert destination: logdb
2017-02-03 12:46:12 FileLogConvert LogConvert lines-analysed: 7586
2017-02-03 12:46:12 FileLogConvert LogConvert lines-imported: 7586

2017-02-03 12:47:00 FileLogConvert LogConvert state: importing wz_SD1-2017.log power|energy
2017-02-03 12:48:06 FileLogConvert LogConvert state: import done
2017-02-03 12:48:06 FileLogConvert LogConvert file-source: wz_SD1-2017.log
2017-02-03 12:48:06 FileLogConvert LogConvert destination: logdb
2017-02-03 12:48:06 FileLogConvert LogConvert lines-analysed: 23377
2017-02-03 12:48:06 FileLogConvert LogConvert lines-imported: 23334

2017-02-03 12:48:49 FileLogConvert LogConvert state: importing wz_SD2-2017.log
2017-02-03 12:49:14 FileLogConvert LogConvert state: import done
2017-02-03 12:49:14 FileLogConvert LogConvert file-source: wz_SD2-2017.log
2017-02-03 12:49:14 FileLogConvert LogConvert destination: logdb
2017-02-03 12:49:14 FileLogConvert LogConvert lines-analysed: 6727
2017-02-03 12:49:14 FileLogConvert LogConvert lines-imported: 6727

2017-02-03 12:50:08 FileLogConvert LogConvert state: importing wz_SD4-2017.log power|energy
2017-02-03 12:50:15 FileLogConvert LogConvert state: import done
2017-02-03 12:50:15 FileLogConvert LogConvert file-source: wz_SD4-2017.log
2017-02-03 12:50:15 FileLogConvert LogConvert destination: logdb
2017-02-03 12:50:15 FileLogConvert LogConvert lines-analysed: 2599
2017-02-03 12:50:15 FileLogConvert LogConvert lines-imported: 2585

2017-02-03 12:50:34 FileLogConvert LogConvert state: importing wz_SD5-2017.log power|energy
2017-02-03 12:50:41 FileLogConvert LogConvert state: import done
2017-02-03 12:50:41 FileLogConvert LogConvert file-source: wz_SD5-2017.log
2017-02-03 12:50:41 FileLogConvert LogConvert destination: logdb
2017-02-03 12:50:41 FileLogConvert LogConvert lines-analysed: 2229
2017-02-03 12:50:41 FileLogConvert LogConvert lines-imported: 2192

2017-02-03 12:51:21 FileLogConvert LogConvert state: importing wz_Sensor-2017.log
2017-02-03 12:51:36 FileLogConvert LogConvert state: import done
2017-02-03 12:51:36 FileLogConvert LogConvert file-source: wz_Sensor-2017.log
2017-02-03 12:51:36 FileLogConvert LogConvert destination: logdb
2017-02-03 12:51:36 FileLogConvert LogConvert lines-analysed: 5338
2017-02-03 12:51:36 FileLogConvert LogConvert lines-imported: 5338

2017-02-03 12:52:16 FileLogConvert LogConvert state: importing wz_SD3-2017.log
2017-02-03 12:53:42 FileLogConvert LogConvert state: import done
2017-02-03 12:53:42 FileLogConvert LogConvert file-source: wz_SD3-2017.log
2017-02-03 12:53:42 FileLogConvert LogConvert destination: logdb
2017-02-03 12:53:42 FileLogConvert LogConvert lines-analysed: 31064
2017-02-03 12:53:42 FileLogConvert LogConvert lines-imported: 31064

2017-02-03 12:57:34 FileLogConvert LogConvert state: importing wz_SD3-2016.log power|energy
2017-02-03 13:00:12 FileLogConvert LogConvert state: import done
2017-02-03 13:00:12 FileLogConvert LogConvert file-source: wz_SD3-2016.log
2017-02-03 13:00:12 FileLogConvert LogConvert destination: logdb
2017-02-03 13:00:12 FileLogConvert LogConvert lines-analysed: 55685
2017-02-03 13:00:12 FileLogConvert LogConvert lines-imported: 55587

2017-02-03 13:01:26 FileLogConvert LogConvert state: importing wz_SD2-2016.log power|energy
2017-02-03 13:11:02 FileLogConvert LogConvert state: import done
2017-02-03 13:11:02 FileLogConvert LogConvert file-source: wz_SD2-2016.log
2017-02-03 13:11:02 FileLogConvert LogConvert destination: logdb
2017-02-03 13:11:02 FileLogConvert LogConvert lines-analysed: 215934
2017-02-03 13:11:02 FileLogConvert LogConvert lines-imported: 197843

2017-02-03 13:12:21 FileLogConvert LogConvert state: importing wz_Sensor-2016.log temperature|battery|luminance
2017-02-03 13:16:42 FileLogConvert LogConvert state: import done
2017-02-03 13:16:42 FileLogConvert LogConvert file-source: wz_Sensor-2016.log
2017-02-03 13:16:42 FileLogConvert LogConvert destination: logdb
2017-02-03 13:16:42 FileLogConvert LogConvert lines-analysed: 96132
2017-02-03 13:16:42 FileLogConvert LogConvert lines-imported: 90217

2017-02-03 13:21:34 FileLogConvert LogConvert state: importing wz_Sensor_Technik-2017.log dewpoint|humidity|temperature
2017-02-03 13:25:13 FileLogConvert LogConvert state: import done
2017-02-03 13:25:13 FileLogConvert LogConvert file-source: wz_Sensor_Technik-2017.log
2017-02-03 13:25:13 FileLogConvert LogConvert destination: logdb
2017-02-03 13:25:13 FileLogConvert LogConvert lines-analysed: 76582
2017-02-03 13:25:13 FileLogConvert LogConvert lines-imported: 75924

2017-02-03 13:27:45 FileLogConvert LogConvert state: importing wz_Sensor_Technik-2016.log temperature|humidity|dewpoint
2017-02-03 13:42:16 FileLogConvert LogConvert state: import done
2017-02-03 13:42:16 FileLogConvert LogConvert file-source: wz_Sensor_Technik-2016.log
2017-02-03 13:42:16 FileLogConvert LogConvert destination: logdb
2017-02-03 13:42:16 FileLogConvert LogConvert lines-analysed: 367594
2017-02-03 13:42:16 FileLogConvert LogConvert lines-imported: 296591

Nach einem "reduceLog 35" im DbLog wurde die Datenbank von 7272942 Einträgen auf 1728210 Einträge geschrumpft.

ZitatlastReduceLogResult Rows processed: 5944765, deleted: 5528207, time: 2036.02sec

UPDATE 5.2.2017

• Fix für SQLite und PSQL
• Fix2 für SQLite und PSQL
• mehr Log Ausgaben eingebaut
• Prüfung des übergebenen DbLog Device beim define

UPDATE 9.2.2017

• Events ohne bestimmtes Reading werden nun beim Analysieren auch erfasst und aufgelistet - werden diese Events auch importiert/konvertiert, so werden sie als Reading state gewertet

UPDATE 10.2.2017

• "set analyseFileEvents" ist nun zu "get fileEvents" geworden - damit lädt die Seite nicht mehr neu
• nachfolgende Parameter für "set convert/import" können nun direkt hinter dem jeweiligen set eingegeben werden - dadurch kehrt man auch direkt auf die Details Seite des FileLogConvert Device zurück
• command-.... Readings abgeschafft, es gibt statt dessen ein neues Reading cmd, welches aber nur noch den Log Datei Namen und den möglichen Regex anzeigt - kann man kopieren, anpassen und direkt hinter dem jeweiligen set Befehl einfügen
• neues Reading regex, welches den zuletzt benutzten Regex anzeigt (zwecks Wiederverwendung)
• alle Readings werden nun beim Definieren des Device direkt (leer) angelegt
• mögliche auftretende Fehler werden nun in state reported
• Internal files_db hinzugefügt

UPDATE 5.9.2017

• Check-in SVN unter contrib/98_FileLogConvert.pm (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_FileLogConvert.pm)

Hallo Dan,

funktioniert gut - keine Probleme mit dem Modul - selbsterklärend;

Ich habe es nun auch in meinem Live System im Einsatz  und stelle langsam um auf DbLog - aktuell läuft parallel noch FileLog mit;
Aufgrund des nun so leichten leichten Imports der alten Daten kann ich ja langsam umstellen ...

Gruß

Andreas

Hallo Dan,

das ist genau das Modul, auf das ich gewartet habe um umzustellen :).

Ich probiere mich gerade mit dblog mit sqlite.
Das Logging in die db funktioniert, die Analyse der alten Logfiles auch, aber sobald ich importieren möchte bekomme ich folgenden Fehler:
--
DbLog : - Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbLog.pm line 1614
--
Muss ich noch eine Enviroment-Variabel mit irgendwas setzten?
Danke & Gruß
Martin

Hallo Martin,

danke für Dein Feedback.

Wie die Fehlermeldung schon andeutet ist es ein Problem in 93_DbLog.pm!
Ich verwende nur die Funktion DbLog_ExecSQL aus dem DbLog Modul.
Ich meine die sollte die Datenbankverbindung so herstellen wie benötigt! Aber das klappt wohl nicht immer. :o
Aber genau um solche Schwachstellen aufzudecken mache ich das ja hier. ;)

Was für eine Datenbank benutzt Du denn?
Könntest Du mal bitte das Internal "dbconn" aus Deinem DbLog Device posten?

Gruß
Dan

Zitat von: DeeSPe am 05 Februar 2017, 19:43:49
Was für eine Datenbank benutzt Du denn?
Könntest Du mal bitte das Internal "dbconn" aus Deinem DbLog Device posten?

Gruß
Dan

Aber klar doch:

dbconn     SQLite:dbname=/opt/fhem/fhem.db

Datenbank ist sqlite (3.7.13) auf einen raspberry (raspbian jessi,4.1.19+)


Viele Grüße
Martin

Zitat von: Martin W am 05 Februar 2017, 20:09:02
Aber klar doch:

dbconn     SQLite:dbname=/opt/fhem/fhem.db

Datenbank ist sqlite (3.7.13) auf einen raspberry (raspbian jessi,4.1.19+)


Viele Grüße
Martin

Okay, jetzt ist es mir klar warum es nicht funktioniert.
Klar, an SQLite hatte ich nicht gedacht dass da der dbconn String anders aussieht.
Gut dass wir den Fall jetzt haben. 8)
Ich überlege mir mal was dazu und muss wohl auch die anderen DB Optionen prüfen.
So lange bitte ich um Geduld.

Gruß
Dan

Boaaaaa,
und ich hab gedacht ich hab wieder was falsch gemacht :)
Bin seit 2 Stunden am Ochsen.
Hab auch QSLite auf meinem Raspi.

Trotz dem vielen vielen Dank schon mal im Voraus für das tolle Modul!
Freue mich schon drauf, wenn das Problem gefixt ist.

Gruß
p99p

Ich denke ich habe es gefixt.
Die Version im ersten Beitrag ist aktualisiert. ;)

Über neue Tests und Feedback freue ich mich sehr.

Gruß
Dan

Sri,
beim mir klemmt es noch :(

2017.02.05 22:35:56 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1611, <FH> line 13862.
2017.02.05 22:35:56 1: PERL WARNING: Use of uninitialized value $dbconn in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1614, <FH> line 13862.
2017.02.05 22:35:56 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1617, <FH> line 13862.
2017.02.05 22:35:56 2: DbLog : - Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbLog.pm line 1614.


EDIT: reload hab ich natürlich gemacht

Zitat von: pink99panther am 05 Februar 2017, 22:39:55
Sri,
beim mir klemmt es noch :(

Code Auswählen Erweitern

2017.02.05 22:35:56 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1611, <FH> line 13862.
2017.02.05 22:35:56 1: PERL WARNING: Use of uninitialized value $dbconn in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1614, <FH> line 13862.
2017.02.05 22:35:56 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 1617, <FH> line 13862.
2017.02.05 22:35:56 2: DbLog : - Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbLog.pm line 1614.


EDIT: reload hab ich natürlich gemacht

Dein DbLog Device funktioniert aber soweit?
So wie es mir aussieht funktioniert das schon nicht.

Dein FHEM ist sonst aktuell?

Gruß
Dan

Fhem ist aktuell

logdevice funzt

EDIT Gibt es evtl. in der Logdatei Besonderheiten?
2017-02-01_00:01:04 TempDiff T_Diff: -0.07
2017-02-01_00:01:04 TempDiff Sonne: off
2017-02-01_00:01:06 TempDiff T_Diff: -0.07
2017-02-01_00:01:06 TempDiff Sonne: off
2017-02-01_00:01:06 SonnenSensor SchattTemp: 1.75
2017-02-01_00:01:07 TempDiff T_Diff: -0.38
2017-02-01_00:01:07 TempDiff Sonne: off
2017-02-01_00:01:07 SonnenSensor SonnTemp: 1.81
2017-02-01_00:02:04 TempDiff T_Diff: 0.06
2017-02-01_00:02:04 TempDiff Sonne: off
2017-02-01_00:02:06 TempDiff T_Diff: 0.06
2017-02-01_00:02:06 TempDiff Sonne: off
2017-02-01_00:02:06 SonnenSensor SchattTemp: 1.94
2017-02-01_00:02:07 TempDiff T_Diff: -0.13
2017-02-01_00:02:07 TempDiff Sonne: off
2017-02-01_00:02:07 SonnenSensor SonnTemp: 1.87
2017-02-01_00:03:04 TempDiff T_Diff: -0.07
2017-02-01_00:03:04 TempDiff Sonne: off
2017-02-01_00:03:06 TempDiff T_Diff: -0.07
2017-02-01_00:03:06 TempDiff Sonne: off
2017-02-01_00:03:06 SonnenSensor SchattTemp: 1.87
2017-02-01_00:03:07 TempDiff T_Diff: 0
2017-02-01_00:03:07 TempDiff Sonne: off
2017-02-01_00:03:07 SonnenSensor SonnTemp: 1.75
2017-02-01_00:04:04 TempDiff T_Diff: -0.12
2017-02-01_00:04:04 TempDiff Sonne: off
2017-02-01_00:04:06 TempDiff T_Diff: -0.12
2017-02-01_00:04:06 TempDiff Sonne: off
2017-02-01_00:04:06 SonnenSensor SchattTemp: 1.75
2017-02-01_00:04:07 TempDiff T_Diff: 0
2017-02-01_00:04:07 TempDiff Sonne: off
2017-02-01_00:04:07 SonnenSensor SonnTemp: 1.75
2017-02-01_00:05:04 TempDiff T_Diff: 0
2017-02-01_00:05:05 TempDiff Sonne: off
2017-02-01_00:05:06 TempDiff T_Diff: 0
2017-02-01_00:05:06 TempDiff Sonne: off
2017-02-01_00:05:06 SonnenSensor SchattTemp: 1.87
2017-02-01_00:05:07 TempDiff T_Diff: -0.12
2017-02-01_00:05:07 TempDiff Sonne: off
2017-02-01_00:05:07 SonnenSensor SonnTemp: 1.87
2017-02-01_00:06:05 TempDiff T_Diff: 0
2017-02-01_00:06:05 TempDiff Sonne: off
2017-02-01_00:06:06 TempDiff T_Diff: 0
2017-02-01_00:06:06 TempDiff Sonne: off
2017-02-01_00:06:06 SonnenSensor SchattTemp: 1.87
2017-02-01_00:06:07 TempDiff T_Diff: 0
2017-02-01_00:06:07 TempDiff Sonne: off
2017-02-01_00:06:07 SonnenSensor SonnTemp: 1.81
2017-02-01_00:07:05 TempDiff T_Diff: -0.06
2017-02-01_00:07:05 TempDiff Sonne: off
2017-02-01_00:07:06 TempDiff T_Diff: -0.06
2017-02-01_00:07:06 TempDiff Sonne: off
2017-02-01_00:07:06 SonnenSensor SchattTemp: 1.62
2017-02-01_00:07:07 TempDiff T_Diff: 0.19
2017-02-01_00:07:07 TempDiff Sonne: off
2017-02-01_00:07:07 SonnenSensor SonnTemp: 1.56
2017-02-01_00:08:05 TempDiff T_Diff: -0.06
2017-02-01_00:08:05 TempDiff Sonne: off
2017-02-01_00:08:06 TempDiff T_Diff: -0.06
2017-02-01_00:08:06 TempDiff Sonne: off
2017-02-01_00:08:06 SonnenSensor SchattTemp: 1.50
2017-02-01_00:08:07 TempDiff T_Diff: 0.06
2017-02-01_00:08:07 TempDiff Sonne: off
2017-02-01_00:08:08 SonnenSensor SonnTemp: 1.44
2017-02-01_00:09:05 TempDiff T_Diff: -0.06
2017-02-01_00:09:05 TempDiff Sonne: off
2017-02-01_00:09:07 TempDiff T_Diff: -0.06
2017-02-01_00:09:07 TempDiff Sonne: off
2017-02-01_00:09:07 SonnenSensor SchattTemp: 1.56
2017-02-01_00:09:08 TempDiff T_Diff: -0.12
2017-02-01_00:09:08 TempDiff Sonne: off
2017-02-01_00:09:08 SonnenSensor SonnTemp: 1.44
2017-02-01_00:10:05 TempDiff T_Diff: -0.12
2017-02-01_00:10:05 TempDiff Sonne: off
2017-02-01_00:10:07 TempDiff T_Diff: -0.12
2017-02-01_00:10:07 TempDiff Sonne: off
2017-02-01_00:10:07 SonnenSensor SchattTemp: 1.50
2017-02-01_00:10:08 TempDiff T_Diff: -0.06
2017-02-01_00:10:08 TempDiff Sonne: off
2017-02-01_00:10:08 SonnenSensor SonnTemp: 1.37
2017-02-01_00:11:05 TempDiff T_Diff: -0.13
2017-02-01_00:11:05 TempDiff Sonne: off
2017-02-01_00:11:07 TempDiff T_Diff: -0.13
2017-02-01_00:11:07 TempDiff Sonne: off
2017-02-01_00:11:07 SonnenSensor SchattTemp: 1.44
2017-02-01_00:11:08 TempDiff T_Diff: -0.07
2017-02-01_00:11:08 TempDiff Sonne: off
2017-02-01_00:11:08 SonnenSensor SonnTemp: 1.31
2017-02-01_00:12:05 TempDiff T_Diff: -0.13
2017-02-01_00:12:05 TempDiff Sonne: off
2017-02-01_00:12:07 TempDiff T_Diff: -0.13
2017-02-01_00:12:07 TempDiff Sonne: off
2017-02-01_00:12:07 SonnenSensor SchattTemp: 1.37
2017-02-01_00:12:08 TempDiff T_Diff: -0.06
2017-02-01_00:12:08 TempDiff Sonne: off
2017-02-01_00:12:08 SonnenSensor SonnTemp: 1.25
2017-02-01_00:13:05 TempDiff T_Diff: -0.12
2017-02-01_00:13:05 TempDiff Sonne: off
2017-02-01_00:13:07 TempDiff T_Diff: -0.12
2017-02-01_00:13:07 TempDiff Sonne: off
2017-02-01_00:13:07 SonnenSensor SchattTemp: 1.31
2017-02-01_00:13:08 TempDiff T_Diff: -0.06
2017-02-01_00:13:08 TempDiff Sonne: off
2017-02-01_00:13:08 SonnenSensor SonnTemp: 1.25
2017-02-01_00:14:05 TempDiff T_Diff: -0.06
2017-02-01_00:14:05 TempDiff Sonne: off
2017-02-01_00:14:07 TempDiff T_Diff: -0.06
2017-02-01_00:14:07 TempDiff Sonne: off
2017-02-01_00:14:07 SonnenSensor SchattTemp: 1.37
2017-02-01_00:14:08 TempDiff T_Diff: -0.12
2017-02-01_00:14:08 TempDiff Sonne: off
2017-02-01_00:14:08 SonnenSensor SonnTemp: 1.31

Hab nun den SQL Query nochmals vereinfacht.
Update im ersten Beitrag.

Soeben habe ich mir auch selbst eine DbLog Instanz mit SQLite aufgesetzt und der Import klappt bei mir ohne Fehlermeldungen.

Gruß
Dan

EDIT: Auch der Import von Deinem Beispiel Log hat bei mir problemlos geklappt.

Zitat
     2017-02-05 23:28:53   command-csv     set LogConvertLite convert2csv test.log T_Diff|Sonne|SchattTemp|SonnTemp
     2017-02-05 23:28:53   command-db      set LogConvertLite import2DbLog test.log T_Diff|Sonne|SchattTemp|SonnTemp
     2017-02-05 23:28:53   command-sql     set LogConvertLite convert2sql test.log T_Diff|Sonne|SchattTemp|SonnTemp
     2017-02-05 23:29:18   destination     DbLogLite
     2017-02-05 23:28:53   events          T_Diff Sonne SchattTemp SonnTemp
     2017-02-05 23:28:53   file-analysed   test.log
     2017-02-05 23:29:18   file-source     test.log
     2017-02-05 23:29:18   lines-analysed  112
     2017-02-05 23:29:18   lines-imported  112
     2017-02-05 23:29:18   state           import done

Jetzt hat es funktioniert  :) :) :) :) :)
Hab das Device gelöscht die Version noch mal aktualisiert,
den Raspbi rebootet und FileLogConvert-Device neu angelegt.

Vielen Dank für die Mühe.
p99p

Zitat von: pink99panther am 06 Februar 2017, 07:35:26
Jetzt hat es funktioniert  :) :) :) :) :)
Hab das Device gelöscht die Version noch mal aktualisiert,
den Raspbi rebootet und FileLogConvert-Device neu angelegt.

Vielen Dank für die Mühe.
p99p

Na super, so soll es ja sein. 8)

Viel Erfolg beim Import!

Gruß
Dan

Finde die Idee top. Allerdings habe ich eine Frage. Ich würde gerne auch meine Fenster/Tür Sensoren importieren. Diese schreiben natürlich ins Logile nur open/closed/tilted rein. Gibt es dafür auch eine Möglichkeit?

Edit:
Und ich hätte gerne die Möglichkeit eine File nochmal zu converten. Mir ist zB eben ein Fehler unterlaufen und jetzt lässt mich das Modul die Datei nicht nochmal converten, da ich das bereits getan habe. Eigentlich ist die Idee gut, damit man weiß was man gemacht hat, aber das sollte man auch ausstellen können.

Edit2:
Weiterhin sollte es die Möglichkeit geben die erstelle SQL Datei (mit den gefilterten Readings) über FHEM zu impoertieren. Gerade bei größeren Dateien kann das sehr hilfreich sein, wenn die DB nur eine bestimmte Größe der Datei bzw. nur eine bestimmte Zeilen Anzahl bei SQL zulässt.

Zitat von: Amenophis86 am 07 Februar 2017, 18:33:02
Finde die Idee top. Allerdings habe ich eine Frage. Ich würde gerne auch meine Fenster/Tür Sensoren importieren. Diese schreiben natürlich ins Logile nur open/closed/tilted rein. Gibt es dafür auch eine Möglichkeit?

Ja, wie immer sogar mehrere!

• Log Datei selbst bearbeiten und vor open/closed/tilted noch "state: " schreiben (Suchen & Ersetzen).
• Gab es für solche Fälle nicht irgend sowas wie addStateEvent? Das müsste natürlich schon vorher gesetzt sein damit state gleich mit in's Log kommt.
• Du könntest mal nachsehen wie DbLog die (neuen) Einträge handhabt! Werden die überhaupt geloggt? Wird dann von DbLog automatisch das state READING ergänzt? Habe solche Fälle nicht um das zu prüfen und bin deshalb auf Feedback angewiesen, könnte natürlich auch mal die Entwickler von DbLog fragen!

Die Frage, die ich mir stelle, ist wie könnte ich das herausbekommen ob es zu state gehört? Da ich den String an den Leerzeichen trenne. Klar wenn nur open/closed/tilted drin steht ist es eindeutig, was aber wenn bei einem anderen Device Type ein Wert mit einer Einheit kommt? Ich denke dieser Spezialfall lässt sich evtl. nur durch Übergabe weiterer set Parameter realisieren.

Zitat von: Amenophis86 am 07 Februar 2017, 18:33:02
Edit:
Und ich hätte gerne die Möglichkeit eine File nochmal zu converten. Mir ist zB eben ein Fehler unterlaufen und jetzt lässt mich das Modul die Datei nicht nochmal converten, da ich das bereits getan habe. Eigentlich ist die Idee gut, damit man weiß was man gemacht hat, aber das sollte man auch ausstellen können.

Das kannst Du tun! Einfach die entsprechende Datei (Name der Logdatei + Endung Name des DbLog Device) im Log Verzeichnis löschen und die Details Seite vom FileLogConvert Device neu laden. Schon kannst Du noch einmal neu importieren. Ich sehe hier keinen Bedarf das ausstellen zu können/müssen! 8)

Zitat von: Amenophis86 am 07 Februar 2017, 18:33:02
Edit2:
Weiterhin sollte es die Möglichkeit geben die erstelle SQL Datei (mit den gefilterten Readings) über FHEM zu impoertieren. Gerade bei größeren Dateien kann das sehr hilfreich sein, wenn die DB nur eine bestimmte Größe der Datei bzw. nur eine bestimmte Zeilen Anzahl bei SQL zulässt.

Diese Möglichkeit gab es in der Pre-Beta Version des Moduls, habe das dann später aber aus folgenden Gründen entfernt:

• Es macht keinen zeitlichen Unterschied und auch keinen Unterschied in der Performance ob von der Log Datei oder der SQL Datei importiert wird.
• Aber viel wichtiger für mich: Die Gefahr ist mir einfach zu groß dass jemand seine selbst zusammengefrickelte SQL Datei dazuschiebt. Wenn dann der Import nicht klappt weil die SQL Statements nicht richtig/konsistent sind, möchte ich als Modulautor nicht den "Schwarzen Peter" zugeschoben bekommen.

Gruß
Dan

Zitat von: DeeSPe am 07 Februar 2017, 19:31:34

• Du könntest mal nachsehen wie DbLog die (neuen) Einträge handhabt! Werden die überhaupt geloggt? Wird dann von DbLog automatisch das state READING ergänzt? Habe solche Fälle nicht um das zu prüfen und bin deshalb auf Feedback angewiesen, könnte natürlich auch mal die Entwickler von DbLog fragen!

Bei meinen Devices wird in DbLog mit dem reading "state" geloggt.
Ob da s klappt oder nicht hngt auch vom entsprechenden Modul zusammen,
ob es splitFN nutzt, oder einen andere Sonderlösung implementiert hat...

Zitat von: Amenophis86 am 07 Februar 2017, 18:33:02
Ich würde gerne auch meine Fenster/Tür Sensoren importieren. Diese schreiben natürlich ins Logile nur open/closed/tilted rein. Gibt es dafür auch eine Möglichkeit?

Das ist mit dem soeben im ersten Beitrag aktualisierten Modul nun möglich.
Mögliche Events ohne Reading die als state gewertet werden könnten werden nun beim Analysieren auch aufgelistet.
Werden diese Events auch importiert oder konvertiert, so werden diese dem Reading state zugeordnet.

Gruß
Dan

Super, kam die Tage leider nicht dazu dein Fragen zu beantworten, aber haben andere ja schon gemacht. Versuche am Wochenende mal zu testen und melde mich dann. Vielen Dank.

Zitat von: Amenophis86 am 10 Februar 2017, 10:18:33
Super, kam die Tage leider nicht dazu dein Fragen zu beantworten, aber haben andere ja schon gemacht. Versuche am Wochenende mal zu testen und melde mich dann. Vielen Dank.

Das wäre klasse wenn Du das testen könntest!
Ich mache gerade noch ein paar Änderungen in der Bedienung damit diese (m.E.) noch etwas konsistenter wird - am eigentlichen Import/Konvertierung ändere ich aber nichts.

Gruß
Dan

Habe soeben das Modul im ersten Beitrag aktualisiert mit den versprochenen Änderungen bei der Bedienung.
Mir gefällt das so nun um Einiges besser.
Was denkt ihr darüber?

Changelog:

• "set analyseFileEvents" ist nun zu "get fileEvents" geworden - damit lädt die Seite nicht mehr neu
• nachfolgende Parameter für "set convert/import" können nun direkt hinter dem jeweiligen set eingegeben werden - dadurch kehrt man auch direkt auf die Details Seite des FileLogConvert Device zurück
• command-.... Readings abgeschafft, es gibt statt dessen ein neues Reading cmd, welches aber nur noch den Log Datei Namen und den möglichen Regex anzeigt - kann man kopieren, anpassen und direkt hinter dem jeweiligen set Befehl einfügen
• neues Reading regex, welches den zuletzt benutzten Regex anzeigt (zwecks Wiederverwendung)
• alle Readings werden nun beim Definieren des Device direkt (leer) angelegt

Gruß
Dan

Änderungen gefallen mir gut. Das analysieren und schreiben der States hat funktioniert. Konnte ohne Probleme in der DB importiert werden. Super. Vielen Dank dafür.

Zitat von: Amenophis86 am 10 Februar 2017, 23:27:34
Änderungen gefallen mir gut. Das analysieren und schreiben der States hat funktioniert. Konnte ohne Probleme in der DB importiert werden. Super. Vielen Dank dafür.

Sehr schön!

Ich hoffe nun ist alles so wie es sein soll!

Sobald noch ein paar mehr Tester Erfolg verkünden und sonst keine groben Änderungswünsche mehr aufkommen werde ich das Modul in SVN einchecken.

Gruß
Dan

Ich stelle gerade auf dblog um - da kommt dein Modul wie gerufen. Danke schon mal - das erspart mir viel Sucherei, wie ich die Altdaten sinnvoll importiert bekomme.

Meine Frage:

Zitat
im Attribut logdir kann ein alternativer Ordner für die FileLog Dateien angegeben werden - dieser Ordner muss sich auch unter ".../fhem/" befinden

Meine alten Logs liegen außerhalb von FHEM (lässt das globale Arribut archivedir  ja auch zu).
Es wäre schön, wenn ich da nichts ändern müsste, da ich ansonsten meine Backups anpassen müsste, wenn die alten Logs wieder innerhalb des FHEM-Ordners liegen müssen, um sie importieren zu können.

Ich hoffe, das geht ohne großen Aufwand.
LG
Holger

Probier mal ob Du den Pfad relativ zum fhem Pfad angeben kannst.
z.B.:
attr LogConv logdir ../../home/pi/logs

Gruß
Dan

Meine alten Logs liegen unter /opt/fhem-archivedir/
Die direkte Zuordnung über
attr LogConvert logdir /opt/fhem-archivedir/
hat nicht funktioniert, die indirekte über
attr LogConvert logdir ../fhem-archivedir/dagegen schon. Prima.
Werde morgen dann mal erste Tests durchführen.
Danke
Holger

Nach einem Import habe ich zunächst verzweifelt die importierten Datensätze in der DB gesucht.
Ein

select * from history order by TIMESTAMP;
zeigt mir die importierten Sätze in der Console nicht an.
Nachdem ich aber ein Plot von diesen Daten erstellt hatte, habe ich sehen können, dass sie zumindest vorhanden sind. Irritierend finde ich das schon.

Vielleicht noch ein kleiner Hinweis
a)   Die Funktion import2DbLog hätte ich gerne als default (ist ansonsten fehleranfällig)
b)   Die set-Anweisung würde ich auch noch beschreiben – ich war mir zunächst nicht sicher, wie das wirklich gemeint ist
c)     Im 1. Beitrag kann man ein Import-Log von dir sehen. Entweder ist das gut versteckt oder ich habe so ein Log nicht. Fände ich aber gut, so etwas zu haben

Ansonsten eine tolle Hilfe beim Umstieg auf DbLog.
Danke dafür.
Holger

Zitat von: Omega am 06 März 2017, 20:56:02
Nach einem Import habe ich zunächst verzweifelt die importierten Datensätze in der DB gesucht.
Ein

Code Auswählen Erweitern


select * from history order by TIMESTAMP;
zeigt mir die importierten Sätze in der Console nicht an.
Nachdem ich aber ein Plot von diesen Daten erstellt hatte, habe ich sehen können, dass sie zumindest vorhanden sind. Irritierend finde ich das schon.

Vielleicht noch ein kleiner Hinweis
a)   Die Funktion import2DbLog hätte ich gerne als default (ist ansonsten fehleranfällig)
b)   Die set-Anweisung würde ich auch noch beschreiben – ich war mir zunächst nicht sicher, wie das wirklich gemeint ist
c)     Im 1. Beitrag kann man ein Import-Log von dir sehen. Entweder ist das gut versteckt oder ich habe so ein Log nicht. Fände ich aber gut, so etwas zu haben

Ansonsten eine tolle Hilfe beim Umstieg auf DbLog.
Danke dafür.
Holger

Hmm, komisch denn der SQL Query macht bei mir was er soll.

Zu Deinen Hinweisen:

• a) genau so wie es ist finde ich es optimal, es zwingt einen zum Aufpassen und lieber wird mal auf die Schnelle ein nicht benötigtes CSV File erzeugt als einen ungewollten/fehlerhaften Import in die DB zu starten (meine Ansicht)
• b) könnte man machen, wird aber denke ich klar wenn man die erste Analyse hat laufen lassen
• c) das sind einfach die erzeugten Events/Readings aus dem Event-Monitor mit gesetztem Filter auf das FileLogConvert Device

Gruß
Dan

Hallo!

Ich möchte FileLogs importieren, die von HM-ES-PMSw1-Pl (https://wiki.fhem.de/wiki/HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung) erstellt wurden.
Allerding sollen nur bestimmte vorkommende Events konvertiert/importiert werden.

Frage:
Wie muss ich vorgehen, um nur bestimmte Event zu konvertieren/importieren?

Danke.

Frage:
Wo wird das Log für den DbLog Import geschrieben?

Zitat von: c.monty am 19 April 2017, 00:57:17
Frage:
Wie muss ich vorgehen, um nur bestimmte Event zu konvertieren/importieren?

Einfach mal "get <name> fileEvents <logfile.log>" ausführen.
Danach wird im Reading cmd ein mögliches Import/Convert Kommando erstellt welches als erstes den Namen der Log Datei enthält und danach einen RegEx mit allen zu importierenden Readings/Events.
Einfach auf die gewünschten Readings/Events kürzen und dann mit "set <name> import2DbLog <cmd>" importieren.

Zitat von: c.monty am 19 April 2017, 01:08:21
Frage:
Wo wird das Log für den DbLog Import geschrieben?

Im selben Ordner wie die Log Dateien.

EDIT: Es wird aber keine Log Datei erstellt, sondern nur eine leere Datei mit dem selben Namen wie die Log Datei. Die ist nur zur Erkennung dass der Import für diese Datei schon gemacht wurde.

Gruß
Dan

Top das Modul!!!!!!!

Hat mir seeeeeehr viel Arbeit erspart. Danke dir!!!

Besteht noch der Plan es offiziell einzuchecken? Find es weiterhin sehr gut.

Ich hatte über einen Check-in nachgedacht, es aber wieder verworfen.
Die Gründe dafür sind folgende:

• Bei einer Umstellung von FileLog auf DbLog wird das Modul nur für die Migration gebraucht, es standardmäßig an alle auszuliefern finde ich deshalb nicht optimal.
• Evtl. fließt die Funktionalität mal irgendwann in das DbLog Modul mit ein. Ich hatte da schon mal mit Heiko drüber philosophiert, aufgrund Zeitmangel aber i.M. nicht weiter verfolgt. Vielleicht baue ich im Winter mal einen Patch für DbLog.

Gruß
Dan

P.S. Evtl. macht ein Check-in nach contrib Sinn!?

Check-In nach contrib würde ich befürworten. Da findet man das Modul wahrscheinlich eher als im Forenthread.

Bis es in DBLog drin ist würde es in contrib sicher Sinn machen. Vielleicht kann man in der CommandRef noch drauf verweisen, da es gerade beim Anlegen von DBLog extrem helfen kann.

Hallo Dan,

wennn du dein Modul so wie von Ameno vorgeschlagen nach contrib bringst, würde ich diesen Hinweis auf das Modul gerne in der commandref als Hilfestellung hinterlegen.

Grüsse
Heiko

Zitat von: DS_Starter am 04 September 2017, 16:33:59
Hallo Dan,

wennn du dein Modul so wie von Ameno vorgeschlagen nach contrib bringst, würde ich diesen Hinweis auf das Modul gerne in der commandref als Hilfestellung hinterlegen.

Grüsse
Heiko

Na das wäre ja was Heiko!
Danke für das Angebot, welches ich hiermit gerne annehme.

Werde das Modul in den nächsten Tagen noch einmal prüfen und dann nach contrib einchecken.
Heiko, ich gebe Dir dann Bescheid, damit Du die Erwähnung des Moduls in die commandref mit aufnehmen kannst.

Gruß
Dan

Habe das Modul soeben unter contrib (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_FileLogConvert.pm) eingecheckt!
Das Modul im ersten Beitrag habe ich entfernt und statt dessen auf SVN verwiesen.

Gruß
Dan

Habe die DbLog V2.22.5 eingecheckt.
Sie enthält neben kleinen Fixes den Hinweis auf 98_FileLogConvert.pm und diesen Thread zur Hilfestellung.

Grüße
Heiko

Mensch Heiko, Du bist ja so "auf Zack". ;)
I brech hia glei zam...

Gruß
Dan

Hallo Dan,
vielen Dank für dieses Modul. Ich hoffe es wird mir beim Umstieg auf die DbLog viel Arbeit ersparen.
Ich habe erst heute die ersten Erfahrungen mit dem Modul gemacht.

Ein Punkt ist mir eben aufgefallen.
Ich habe eine FileLog-Datei mit den Außentemperaturen.
Diese möchte ich gerne 1:1 in DbLog importieren.
Nach einem fileEvent steht im cmd dieses:

AussenTemp-2017-09.log 10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|6|7|8|9

Also alle Temperaturen mit "Kommawerten" werden nicht konvertiert.
Wie kann ich erreichen, dass alle Werte konvertiert werden?
Ein Regex .* hat auch keinen Erfolg gebracht.

Auszug aus der Originaldatei:

...
2017-09-01_01:08:40 Event_AussenTemp 15.1
2017-09-01_01:13:40 Event_AussenTemp 15
2017-09-01_01:18:40 Event_AussenTemp 15.1
2017-09-01_01:28:40 Event_AussenTemp 15
2017-09-01_01:33:40 Event_AussenTemp 15.1
2017-09-01_01:53:40 Event_AussenTemp 15
2017-09-01_01:58:40 Event_AussenTemp 15.1
2017-09-01_02:03:40 Event_AussenTemp 15
2017-09-01_02:08:40 Event_AussenTemp 14.9
2017-09-01_02:18:40 Event_AussenTemp 14.8
2017-09-01_02:38:40 Event_AussenTemp 14.7
2017-09-01_02:48:40 Event_AussenTemp 14.6
2017-09-01_03:23:40 Event_AussenTemp 14.5
2017-09-01_03:53:40 Event_AussenTemp 14.4
2017-09-01_03:58:40 Event_AussenTemp 14.5
2017-09-01_04:03:40 Event_AussenTemp 14.4
2017-09-01_04:08:40 Event_AussenTemp 14.5
2017-09-01_04:48:40 Event_AussenTemp 14.4
2017-09-01_05:03:40 Event_AussenTemp 14.3
2017-09-01_05:08:40 Event_AussenTemp 14.2
2017-09-01_05:13:40 Event_AussenTemp 14.1
2017-09-01_05:23:40 Event_AussenTemp 14
2017-09-01_05:33:40 Event_AussenTemp 13.9
...


Zitat von: funkner am 06 Oktober 2017, 00:46:06
Hallo Dan,
vielen Dank für dieses Modul. Ich hoffe es wird mir beim Umstieg auf die DbLog viel Arbeit ersparen.
Ich habe erst heute die ersten Erfahrungen mit dem Modul gemacht.

Ein Punkt ist mir eben aufgefallen.
Ich habe eine FileLog-Datei mit den Außentemperaturen.
Diese möchte ich gerne 1:1 in DbLog importieren.
Nach einem fileEvent steht im cmd dieses:

Code Auswählen Erweitern


AussenTemp-2017-09.log 10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|6|7|8|9

Also alle Temperaturen mit "Kommawerten" werden nicht konvertiert.
Wie kann ich erreichen, dass alle Werte konvertiert werden?
Ein Regex .* hat auch keinen Erfolg gebracht.

Auszug aus der Originaldatei:

Code Auswählen Erweitern


...
2017-09-01_01:08:40 Event_AussenTemp 15.1
2017-09-01_01:13:40 Event_AussenTemp 15
2017-09-01_01:18:40 Event_AussenTemp 15.1
2017-09-01_01:28:40 Event_AussenTemp 15
2017-09-01_01:33:40 Event_AussenTemp 15.1
2017-09-01_01:53:40 Event_AussenTemp 15
2017-09-01_01:58:40 Event_AussenTemp 15.1
2017-09-01_02:03:40 Event_AussenTemp 15
2017-09-01_02:08:40 Event_AussenTemp 14.9
2017-09-01_02:18:40 Event_AussenTemp 14.8
2017-09-01_02:38:40 Event_AussenTemp 14.7
2017-09-01_02:48:40 Event_AussenTemp 14.6
2017-09-01_03:23:40 Event_AussenTemp 14.5
2017-09-01_03:53:40 Event_AussenTemp 14.4
2017-09-01_03:58:40 Event_AussenTemp 14.5
2017-09-01_04:03:40 Event_AussenTemp 14.4
2017-09-01_04:08:40 Event_AussenTemp 14.5
2017-09-01_04:48:40 Event_AussenTemp 14.4
2017-09-01_05:03:40 Event_AussenTemp 14.3
2017-09-01_05:08:40 Event_AussenTemp 14.2
2017-09-01_05:13:40 Event_AussenTemp 14.1
2017-09-01_05:23:40 Event_AussenTemp 14
2017-09-01_05:33:40 Event_AussenTemp 13.9
...


Ich kann Dir gerade nicht viel dazu sagen außer dass ich es mir bei Gelegenheit mal anschauen werde.
Hab da so eine Idee, kann aber ein paar Tage dauern.

Gruß
Dan

Hallo Forum,
ich bin Anfänger und kürzlich (vor ca. 4 Tagen) auf DbLog umgestiegen. habe mir dann auch das hier vorgestellte LogConvert eingebunden und benutzt. Ich habe einige Logfiles, die ich gerne importieren möchte. Das analysieren funktioniert und importieren scheint auch zu funktionieren.
Die DB wird immer größer. bin jetzt bei ~700 MB mit einigen importierten files. Jedoch scheint es so, als wenn bei jedem importierten File alle Daten von vorher unbrauchbar gemacht werden. Aufgegfallen ist mir dies, als ich mir die Plots ansehen wollte. Auch aktuelle Daten sind dann nur noch von 1-2h vorhanden und natürlich alle von dem gerade importierten File, aber keine von den vorigen. Ich kenne mich leider nicht so gut mit Datenbanken aus. Habe mir das DB-File aber mal aus dem FHEM runter geladen und mit DB-Browser angesehen. In der History Tabelle hab ich 722071 Einträge. Das zuletzt importierte File hatte ~600000, das davor auch ~600000 und das davor auch > 500000 usw. Die Current Tabelle hat 1166 Einträge.
Wo sind die Daten geblieben ? Gibt es irgend ein Reparatur Tool ?

gruß
Thomas

Hallo Dan,
ich hab testweise die beiden RexEx-Muster (Zeile 220 und 248) folgendermaßen geändert.

($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9_.-]+)$/)
statt
($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9_-]+)$/)

Kannst du die Änderungen bitte verifizieren und gegebenenfalls übernehmen?

Supi genau soetwas habe ich gesucht. Leider bekomme ich folgende Fehlermeldung nach dem runterladen und reload Befehl:

syntax error at ./FHEM/98_FileLogConvert.pm line 8, near "<"
Unknown regexp modifier "/t" at ./FHEM/98_FileLogConvert.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/98_FileLogConvert.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/98_FileLogConvert.pm line 9, at end of line
syntax error at ./FHEM/98_FileLogConvert.pm line 15, near "-->"
syntax error at ./FHEM/98_FileLogConvert.pm line 32, near "$(".trac-autofocus""
syntax error at ./FHEM/98_FileLogConvert.pm line 33, near "$(".trac-target-new""
syntax error at ./FHEM/98_FileLogConvert.pm line 34, near ") {"
syntax error at ./FHEM/98_FileLogConvert.pm line 35, near "$(".trac-disable-on-submit""
syntax error at ./FHEM/98_FileLogConvert.pm line 38, near ""text/javascript" src"
./FHEM/98_FileLogConvert.pm has too many errors.

Was mache ich falsch?

Hast du die aktuellste Version heruntergeladen?

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

Zitat von: supergrobi am 07 Oktober 2017, 19:29:01
Hallo Forum,
ich bin Anfänger und kürzlich (vor ca. 4 Tagen) auf DbLog umgestiegen. habe mir dann auch das hier vorgestellte LogConvert eingebunden und benutzt. Ich habe einige Logfiles, die ich gerne importieren möchte. Das analysieren funktioniert und importieren scheint auch zu funktionieren.
Die DB wird immer größer. bin jetzt bei ~700 MB mit einigen importierten files. Jedoch scheint es so, als wenn bei jedem importierten File alle Daten von vorher unbrauchbar gemacht werden. Aufgegfallen ist mir dies, als ich mir die Plots ansehen wollte. Auch aktuelle Daten sind dann nur noch von 1-2h vorhanden und natürlich alle von dem gerade importierten File, aber keine von den vorigen. Ich kenne mich leider nicht so gut mit Datenbanken aus. Habe mir das DB-File aber mal aus dem FHEM runter geladen und mit DB-Browser angesehen. In der History Tabelle hab ich 722071 Einträge. Das zuletzt importierte File hatte ~600000, das davor auch ~600000 und das davor auch > 500000 usw. Die Current Tabelle hat 1166 Einträge.
Wo sind die Daten geblieben ? Gibt es irgend ein Reparatur Tool ?

gruß
Thomas

Nachdem ich die Datenbank nochmal gelöscht und neu angelegt habe scheint es jetzt zu funktionieren. 
Danke

Zitat von: supergrobi am 18 Oktober 2017, 21:24:50
Nachdem ich die Datenbank nochmal gelöscht und neu angelegt habe scheint es jetzt zu funktionieren. 
Danke

zu früh gefreut...
nachdem ich heute wärend des Imports die Plots geöffnet hatte, wurde die DB wieder abgeschossen.
diesmal hatte ich zumindest ein Backup von gestern...
im Log gibt es dann Meldungen wie


2017.10.18 21:40:43 2: DBLog error: disk I/O error
2017.10.18 21:40:43 2: DBLog retry failed.
2017.10.18 21:54:05 2: DBLog error: database disk image is malformed
2017.10.18 21:54:05 2: DBLog retry failed.


Edit: Hiermit hat es angefangen:

2017.10.18 21:35:30 3: Defining DbLog SVG-Plots with :CURRENT is deprecated. Please define DbLog SVG-Plots with :HISTORY instead of :CURRENT. (define <mySVG> SVG <DbLogDev>:<gplotfile>:HISTORY)

die zuvor genannten Meldungen kamen nachdem ich FHEM mit Shutdown restart neu gestartet hatte...

... und wieder ist die DB Abgeschossen...
diesmal sind keine Tables mehr vorhanden.

sqlite> .tables
...bringt keine reaktion, genauso wie
sqlite> .schema

sqlite> .fullschema
/* No STAT tables available */

...hilft auch nicht mehr...
ich kann nicht sagen, ob es an SQLite liegt, oder am Modul

Ich werd mein Glück mit MySQL versuchen...

Zitat von: supergrobi am 20 Oktober 2017, 22:25:30
... und wieder ist die DB Abgeschossen...
diesmal sind keine Tables mehr vorhanden.

sqlite> .tables
...bringt keine reaktion, genauso wie
sqlite> .schema

sqlite> .fullschema
/* No STAT tables available */

...hilft auch nicht mehr...
ich kann nicht sagen, ob es an SQLite liegt, oder am Modul

Ich werd mein Glück mit MySQL versuchen...

Am Modul kann es eigentlich nicht liegen denn es nutzt die Funktion DbLog_ExecSQL aus dem DbLog Modul um die Daten in die Datenbank zu schreiben.

Gruß
Dan

Zitat von: DeeSPe am 23 Oktober 2017, 11:02:06
Am Modul kann es eigentlich nicht liegen denn es nutzt die Funktion DbLog_ExecSQL aus dem DbLog Modul um die Daten in die Datenbank zu schreiben.

Gruß
Dan

Hallo Dan,

das denke ich auch...  das SQLite scheint zu instabil zu sein.
Ich habe jetzt MySQL installiert, das läuft einwandfrei. Allerdings benötigte hier auch nicht die import funktion. Hab alle files als CSv exportiert und dann über HeidiSQL importiert. Wofür ich vorher mehr als eine Woche gebraucht hatte, ging so innerhalb eines halben Tages...

Leider ist der Raspi für MySQL zu schwach... :(
Ich versuche jetzt TinkerBoard...

lg

Zitat von: Commander am 13 Oktober 2017, 20:07:05
Supi genau soetwas habe ich gesucht. Leider bekomme ich folgende Fehlermeldung nach dem runterladen und reload Befehl:

Code Auswählen Erweitern

syntax error at ./FHEM/98_FileLogConvert.pm line 8, near "<"
Unknown regexp modifier "/t" at ./FHEM/98_FileLogConvert.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/98_FileLogConvert.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/98_FileLogConvert.pm line 9, at end of line
syntax error at ./FHEM/98_FileLogConvert.pm line 15, near "-->"
syntax error at ./FHEM/98_FileLogConvert.pm line 32, near "$(".trac-autofocus""
syntax error at ./FHEM/98_FileLogConvert.pm line 33, near "$(".trac-target-new""
syntax error at ./FHEM/98_FileLogConvert.pm line 34, near ") {"
syntax error at ./FHEM/98_FileLogConvert.pm line 35, near "$(".trac-disable-on-submit""
syntax error at ./FHEM/98_FileLogConvert.pm line 38, near ""text/javascript" src"
./FHEM/98_FileLogConvert.pm has too many errors.

Was mache ich falsch?

ich bekomme die gleiche Meldung. Das Modul habe ich von aus dem SVN link runtergeladen.

Zitat von: screetch82 am 10 November 2017, 09:52:51
ich bekomme die gleiche Meldung. Das Modul habe ich von aus dem SVN link runtergeladen.

Du hast die HTML-Datei heruntergeladen. ;)

Damit (https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/98_FileLogConvert.pm) sollte es gehen.

Gruß
Dan

Hallo,

habe das Modul erfolgreich installiert, jedoch weigert es sich meine Logfiles zu importieren und auch die Umwandlung in CSV und SQL geht nicht.
Bei meinen Versuchen habe ich zum Spass mal Logfiles genommen die ich eigentlich nicht importieren möchte und diese als CSV und SQL exportiert.
Komischerweise hat es da funktioniert.

Dann habe ich mir die beiden Logfiles mal angesehen und dabei festgestellt das in den Logfiles die nicht funktionieren ein Device mit "Punkt" im Namen vorkommen.
Also, Logfile editiert und die Punkte durch "_" ersetzt.  Siehe da, schon funktioniert es.

Beispiel:

2017-11-11_23:32:03 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDay: 18.953
2017-11-11_23:32:03 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyMonth: 152.555
2017-11-12_00:00:00 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 19.140
2017-11-13_00:00:02 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 13.901
2017-11-14_00:00:00 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 15.462
2017-11-15_00:00:03 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 20.714
2017-11-16_00:00:00 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 12.088
2017-11-16_13:48:05 Stromkalkulation CN_Stromzaehler_countsOverall_PowerDayAver: 0.000

... funktionert

2017-11-11_23:32:03 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDay: 18.953
2017-11-11_23:32:03 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyMonth: 152.555
2017-11-12_00:00:00 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 19.140
2017-11-13_00:00:02 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 13.901
2017-11-14_00:00:00 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 15.462
2017-11-15_00:00:03 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 20.714
2017-11-16_00:00:00 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 12.088
2017-11-16_13:48:05 Stromkalkulation CN.Stromzaehler_countsOverall_PowerDayAver: 0.000

... funktioniert nicht

Kann das Modul nicht mit Device-Namen umgehen die einen Punkt haben?

   Andreas

Zitat von: Loetkolben am 25 November 2017, 14:51:42
Hallo,

habe das Modul erfolgreich installiert, jedoch weigert es sich meine Logfiles zu importieren und auch die Umwandlung in CSV und SQL geht nicht.
Bei meinen Versuchen habe ich zum Spass mal Logfiles genommen die ich eigentlich nicht importieren möchte und diese als CSV und SQL exportiert.
Komischerweise hat es da funktioniert.

Dann habe ich mir die beiden Logfiles mal angesehen und dabei festgestellt das in den Logfiles die nicht funktionieren ein Device mit "Punkt" im Namen vorkommen.
Also, Logfile editiert und die Punkte durch "_" ersetzt.  Siehe da, schon funktioniert es.

Beispiel:

Code Auswählen Erweitern


2017-11-11_23:32:03 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDay: 18.953
2017-11-11_23:32:03 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyMonth: 152.555
2017-11-12_00:00:00 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 19.140
2017-11-13_00:00:02 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 13.901
2017-11-14_00:00:00 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 15.462
2017-11-15_00:00:03 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 20.714
2017-11-16_00:00:00 Stromkalkulation CN_Stromzaehler_countsOverall_EnergyDayLast: 12.088
2017-11-16_13:48:05 Stromkalkulation CN_Stromzaehler_countsOverall_PowerDayAver: 0.000

... funktionert

Code Auswählen Erweitern


2017-11-11_23:32:03 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDay: 18.953
2017-11-11_23:32:03 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyMonth: 152.555
2017-11-12_00:00:00 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 19.140
2017-11-13_00:00:02 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 13.901
2017-11-14_00:00:00 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 15.462
2017-11-15_00:00:03 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 20.714
2017-11-16_00:00:00 Stromkalkulation CN.Stromzaehler_countsOverall_EnergyDayLast: 12.088
2017-11-16_13:48:05 Stromkalkulation CN.Stromzaehler_countsOverall_PowerDayAver: 0.000

... funktioniert nicht

Kann das Modul nicht mit Device-Namen umgehen die einen Punkt haben?

   Andreas

Davicenamen mit Punkten sind schon mehrfach negativ aufgefallen.
Ich wüsste im Moment nicht warum das hier kritisch sein könnte, aber ich schaue mir das bei Gelegenheit mal an.

Gruß
Dan

Zitat von: DeeSPe am 25 November 2017, 18:40:21
Davicenamen mit Punkten sind schon mehrfach negativ aufgefallen.
Ich wüsste im Moment nicht warum das hier kritisch sein könnte, aber ich schaue mir das bei Gelegenheit mal an.

Gruß
Dan

Hallo Dan,
ich hab testweise die beiden RexEx-Muster (Zeile 219 und 233) folgendermaßen geändert.


aus
next unless ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9_-]+):\s(\S+)(\s.*)?$/
wird
next unless ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9._-]+):\s(\S+)(\s.*)?$/

aus
if ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9_-]+):\s(\S+)(\s.*)?$/)
wird
if ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9._-]+):\s(\S+)(\s.*)?$/)


Kannst du die Änderungen bitte verifizieren und gegebenenfalls übernehmen?

Zitat von: funkner am 26 November 2017, 00:32:42
Hallo Dan,
ich hab testweise die beiden RexEx-Muster (Zeile 219 und 233) folgendermaßen geändert.

Code Auswählen Erweitern


aus
next unless ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9_-]+):\s(\S+)(\s.*)?$/
wird
next unless ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9._-]+):\s(\S+)(\s.*)?$/

aus
if ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9_-]+):\s(\S+)(\s.*)?$/)
wird
if ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9._]+)\s([A-Za-z0-9._-]+):\s(\S+)(\s.*)?$/)


Kannst du die Änderungen bitte verifizieren und gegebenenfalls übernehmen?

Hab's mal mit Änderungen der RegEx eingecheckt.
Danke für den Hinweis.

Gruß
Dan

Hallo,

mit der Anpassung funktioniert es.  Danke.


   Andreas

Erst einmal vielen Dank für das Modul.
Ich habe bereits einige Log Files in my DBLog importiert.
Ein File wurde nicht komplett importiert, wie kann ich diesen erneut importieren?

Zitat von: Fredi69 am 29 November 2017, 23:15:55
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

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:

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

Zitat von: DS_Starter am 02 Dezember 2017, 19:50:32
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

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

$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

Zitat von: DS_Starter am 02 Dezember 2017, 21:54:30

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:
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

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   

Zitat von: DS_Starter am 03 Dezember 2017, 15:22:36
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

ZitatDein 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.

Zitat von: DS_Starter am 03 Dezember 2017, 22:33:46
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

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

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

Gruß
Dan

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

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)

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...

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

Zitat von: Tueftler1983 am 23 Juni 2019, 15:13:19
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

Ich zitiere mal aus der commandref:

Zitatlogdir
must be a valid (relative) subfolder of "./fhem/"
relative paths are also possible to address paths outside "./fhem/", e.g. "../../home/pi/oldlogs"

Gruß
Dan

Okay danke, hatte es auch schon versucht klappte aber am Anfang nicht mit dem ../../

Habe es dann nochmal versucht und jetzt geht es.
Danke

Hi,

ich bin auf der Suche nach einem Fehlerfreiem Import von bisherigen LogFiles, deren Einträge so aussehen:
2018-12-31_23:56:15 SensorAussen T: 7.3 H: 90 D: 5.8
Der Eintrag der durch Import in der LogDb entsteht sieht dann so aus:
+---------------------+--------------+-------+-------------------------------+---------+--------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                         | READING | VALUE        | UNIT |
+---------------------+--------------+-------+-------------------------------+---------+--------------+------+
| 2018-12-31 23:56:15 | SensorAussen |       | T: 7.3 H: 90 D: 5.8           | T       | 7.3          | H:   |
Das ist nicht das was ich wollte. Nach einigen eigenen "Erkenntnissen" war klar: stateEvent fehlt.
Mein erster Versuch war diesen in die alten Logs einfach einzufügen:
sed 's/Aussen.T:/Aussen state T:/'Das funktioniert nicht sofort wie es sollte.  :'(

Da habe ich etwas weiter ausgeholt:
- FileLog um addStateEvent erweitert.
- LogDb und FilelLog haben jetzt einheitliches regExp: SensorAussen:.*
Nun habe ich neue "Referenzwerte" und weiß wie ich die alten Logs modifizieren muss. (Dachte ich)  ;)
Die Einträge sehen nun so aus:
Eintrag FileLog
2019-08-19_13:12:35 SensorAussen state: T: 23.1 H: 54

Eintrag DBLog
2019-08-19 13:12:35 | SensorAussen | DUMMY | state: T: 23.1 H: 54 | state       | T: 23.1 H: 54 |      |

Jetzt geh ich her und exportiere diese Zeile aus dem neuen FileLog in ein neues LogFile, modifiziere die Sekunde um eins und importiere anschließend diese eine Zeile wieder in die LogDB
cat /opt/fhem/log/SensorAussen-2019.log |grep -a "2019-08-19_13:12:35"|sed 's/:35/:36/'> /opt/fhem/log/SensorAussen-2019-1.log
Der Eintrag sieht dann so aus. Oben der Originale unten der importierte aus dem FileLog:
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                 | READING     | VALUE         | UNIT |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| 2019-08-19 13:12:35 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T: 23.1 H: 54 |      |
| 2019-08-19 13:12:36 | SensorAussen | DUMMY | state: T:  23.1 H: 54 | state       | T:            | 23.1 |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
Wie man sieht wird ein Leerzeichen zwischen T: und 23.1 reingemogelt, welches offenbar zu dem fehlerhaften Import führt.
Für mich fällt mir jetzt keine Lösung ein, denn auch die Beseitigung des ursprünglichen Leerzeichens führt (fast erwartungsgemäß) nicht zum Erfolg: Aus "state: T:23.1 H: 54" wird dann "state: T:23.1  H: 54" also auch wieder ein Leerzeichen mehr drin, bloß weiter hinten :)

Hat jemand eine Idee?

Edit: Das Leerzeichen kommt aus Zeile 246 " $rest"
        $i_event .= " $rest" if ($rest);

Allerdings verhindert dort eine Änderung allein nicht die Aufteilung des Value
| 2019-08-19 13:12:39 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T:            | 23.1 |
Edit2:Das regExp in Zeile 233 nimmt nicht einfach alles nach dem ReadingName (state) als Value (wie es eigentlich geloggt wird ) sondern sucht noch nach einem Rest $6 und teilt den weiter auf.
In meinem Fall müsste der Rest als $5 als Value geschrieben werden.  :-\
Edit 3:So würde die Zeile 233 für mich arbeiten wie gewünscht:
anstatt
^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S+)(\s.*)?$
so
^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S.*)(\s.*)?$
Wenn ich das richtig verstehe wird dann aber der "restliche Rest" $6 nie ermittelt.

Die letzte Zeile sieht dann wieder aus, wie das Original in der ersten Zeile:
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                 | READING     | VALUE         | UNIT |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| 2019-08-19 13:12:35 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T: 23.1 H: 54 |      |
| 2019-08-19 13:12:36 | SensorAussen | DUMMY | state: T:  23.1 H: 54 | state       | T:            | 23.1 |
| 2019-08-19 13:12:37 | SensorAussen | DUMMY | state: T:23.1  H: 54  | state       | T:23.1        | H:   |
| 2019-08-19 13:12:39 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T:            | 23.1 |
| 2019-08-19 13:12:40 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T: 23.1 H: 54 |      |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+

Für mich ist jetzt erstmal ein Weg da: Ich patche das Modul und verwende es so. Das funktioniert für mich :)
Meine Logs für Homematic Sensoren habe ich ganz am Anfang mal alle auf dies kurze "state Form" gesetzt. Erschien mir dadurch sehr sparsam im Log. Stellt sich jetzt im Nachgang etwas "hinderlich" dar! :)

Gruß Otto

Zitat von: Otto123 am 19 August 2019, 14:17:48
Hi,

ich bin auf der Suche nach einem Fehlerfreiem Import von bisherigen LogFiles, deren Einträge so aussehen:

Code Auswählen Erweitern

2018-12-31_23:56:15 SensorAussen T: 7.3 H: 90 D: 5.8
Der Eintrag der durch Import in der LogDb entsteht sieht dann so aus:

Code Auswählen Erweitern

+---------------------+--------------+-------+-------------------------------+---------+--------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                         | READING | VALUE        | UNIT |
+---------------------+--------------+-------+-------------------------------+---------+--------------+------+
| 2018-12-31 23:56:15 | SensorAussen |       | T: 7.3 H: 90 D: 5.8           | T       | 7.3          | H:   |
Das ist nicht das was ich wollte. Nach einigen eigenen "Erkenntnissen" war klar: stateEvent fehlt.
Mein erster Versuch war diesen in die alten Logs einfach einzufügen:

Code Auswählen Erweitern

sed 's/Aussen.T:/Aussen state T:/'Das funktioniert nicht sofort wie es sollte.  :'(

Da habe ich etwas weiter ausgeholt:
- FileLog um addStateEvent erweitert.
- LogDb und FilelLog haben jetzt einheitliches regExp: SensorAussen:.*
Nun habe ich neue "Referenzwerte" und weiß wie ich die alten Logs modifizieren muss. (Dachte ich)  ;)
Die Einträge sehen nun so aus:

Code Auswählen Erweitern

Eintrag FileLog
2019-08-19_13:12:35 SensorAussen state: T: 23.1 H: 54

Eintrag DBLog
2019-08-19 13:12:35 | SensorAussen | DUMMY | state: T: 23.1 H: 54 | state       | T: 23.1 H: 54 |      |

Jetzt geh ich her und exportiere diese Zeile aus dem neuen FileLog in ein neues LogFile, modifiziere die Sekunde um eins und importiere anschließend diese eine Zeile wieder in die LogDB

Code Auswählen Erweitern

cat /opt/fhem/log/SensorAussen-2019.log |grep -a "2019-08-19_13:12:35"|sed 's/:35/:36/'> /opt/fhem/log/SensorAussen-2019-1.log
Der Eintrag sieht dann so aus. Oben der Originale unten der importierte aus dem FileLog:

Code Auswählen Erweitern

+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                 | READING     | VALUE         | UNIT |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| 2019-08-19 13:12:35 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T: 23.1 H: 54 |      |
| 2019-08-19 13:12:36 | SensorAussen | DUMMY | state: T:  23.1 H: 54 | state       | T:            | 23.1 |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
Wie man sieht wird ein Leerzeichen zwischen T: und 23.1 reingemogelt, welches offenbar zu dem fehlerhaften Import führt.
Für mich fällt mir jetzt keine Lösung ein, denn auch die Beseitigung des ursprünglichen Leerzeichens führt (fast erwartungsgemäß) nicht zum Erfolg: Aus "state: T:23.1 H: 54" wird dann "state: T:23.1  H: 54" also auch wieder ein Leerzeichen mehr drin, bloß weiter hinten :)

Hat jemand eine Idee?

Edit: Das Leerzeichen kommt aus Zeile 246 " $rest"

Code Auswählen Erweitern

        $i_event .= " $rest" if ($rest);

Allerdings verhindert dort eine Änderung allein nicht die Aufteilung des Value

Code Auswählen Erweitern

| 2019-08-19 13:12:39 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T:            | 23.1 |
Edit2:Das regExp in Zeile 233 nimmt nicht einfach alles nach dem ReadingName (state) als Value (wie es eigentlich geloggt wird ) sondern sucht noch nach einem Rest $6 und teilt den weiter auf.
In meinem Fall müsste der Rest als $5 als Value geschrieben werden.  :-\
Edit 3:So würde die Zeile 233 für mich arbeiten wie gewünscht:

Code Auswählen Erweitern

anstatt
^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S+)(\s.*)?$
so
^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S.*)(\s.*)?$
Wenn ich das richtig verstehe wird dann aber der "restliche Rest" $6 nie ermittelt.

Die letzte Zeile sieht dann wieder aus, wie das Original in der ersten Zeile:

Code Auswählen Erweitern

+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                 | READING     | VALUE         | UNIT |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+
| 2019-08-19 13:12:35 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T: 23.1 H: 54 |      |
| 2019-08-19 13:12:36 | SensorAussen | DUMMY | state: T:  23.1 H: 54 | state       | T:            | 23.1 |
| 2019-08-19 13:12:37 | SensorAussen | DUMMY | state: T:23.1  H: 54  | state       | T:23.1        | H:   |
| 2019-08-19 13:12:39 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T:            | 23.1 |
| 2019-08-19 13:12:40 | SensorAussen | DUMMY | state: T: 23.1 H: 54  | state       | T: 23.1 H: 54 |      |
+---------------------+--------------+-------+-----------------------+-------------+---------------+------+

Für mich ist jetzt erstmal ein Weg da: Ich patche das Modul und verwende es so. Das funktioniert für mich :)
Meine Logs für Homematic Sensoren habe ich ganz am Anfang mal alle auf dies kurze "state Form" gesetzt. Erschien mir dadurch sehr sparsam im Log. Stellt sich jetzt im Nachgang etwas "hinderlich" dar! :)

Gruß Otto

Moin Otto,

uff, irgendwie sehe ich hier nicht mehr richtig durch. :o
Ich möchte Dir gern helfen, weiß nur gerade nicht so richtig wie.

Hast Du jetzt eine wirkliche Lösung für Dich gefunden und wenn ja welche?

Gruß
Dan

Guten Morgen Dan,

ja ich habe für mich eine Q&D Lösung gefunden:
1. Ich modifiziere meine Log Files vorm Import nach diesem Schema.
sed 's/Aussen.T:/Aussen state: T:/'
2. Ich verändere Zeile 233 in deinem Modul

Zitat^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S.*)(\s.*)?$

Damit wird keine "UNIT" ermittelt und einfach alles nach state: als VALUE geschrieben. Damit sind die Werte erstmal richtig in der DB.

Das ist natürlich eine sehr händische Lösung und befriedigt mich nicht. :)
Ich probiere derzeit noch ein bisschen mit regEx und SQL Import um vielleicht doch eine direkte und automatische Lösung zu finden.

Und mein Ansatz ist natürlich auch falsch! Ich habe gerade nochmal in den Code geschaut:
Das Problem ist ja eher, dass Zeile 233 greift obwohl sie nicht dürfte und stattdessen Zeile 248 greifen müsste, was die aber auch nicht tun würde.

Bei meinem Logeintrag
2018-12-31_23:56:15 SensorAussen T: 7.3 H: 90 D: 5.8
wird T: als Reading erkannt -> Zeile 233 im Code greift.
Aber selbst wenn ich jetzt state: einfüge, greift dann wieder Zeile 233 und zerpflückt den "MultiValue"
Was übrigens auch mit solchen Zeilen von sysmon passiert:
2019-08-01_00:00:01 sysmon stat_cpu_percent: 1.57 0.00 2.02 96.38 0.02 0.00 0.01

Lass mich mal noch etwas probieren, vielleicht finde ich einen Ansatz. Ich denke aber man muss noch ein paar "Schalter" für Spezialfälle einbauen. Oder ist es schon da und ich habe es nicht gesehen?

Ich finde auf alle Fälle durch Zeile 246 werden die Daten "verfälscht" - aber kann sein ich habe den Sinn von dem Leerzeichen nicht verstanden:
$i_event .= " $rest" if ($rest);
die sollte so aussehen
$i_event .= "$rest" if ($rest);

Edit:
Da in Zeile 248 ff keine Unit ermittelt wird, kann doch dort wenigsten der "komplette Rest" als Value eingetragen werden? Ich würde denken, dort wäre das regEx richtiger so:
($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_].*)$/)
anstatt
($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+)$/)
Damit kommt auch der "Multivalue" komplett in die Datenbank, ansonsten bloß der erste Wert

Ist Zeile 257 eigentlich dann konsequent?
$i_event = $i_value;
Ja der Event war so, aber eigentlich wurde er ja um state: korrigiert :) und DbLog macht es doch auch so? DbLog schreibt doch auch den state dazu? Oder habe ich das an irgendeiner Stelle getan? Ich sehe es nicht, ich habe nur beim FileLog addStateEvent gesetzt.

Eigentlich wäre mein Fall (der aber sicher nicht für mich speziell ist) dadurch gelöst wenn man den Import mit "addStateEvent" erzwingen kann und das regEx in Zeile 248 nach meinem Vorschlag abgeändert wird.

LG Otto

P.S. sorry wieder viel Text :)

Ist vielleicht etwas OT aber ich habe mal mit SQL experimentiert.
Ein Script welches ein LOG welches keine Readings enthält, also das typische "state: fehlt Log" :)
Liest sich durch den SQL Syntax etwas sperrig :) und ich habe von SQL quasi keine Ahnung (kann also sein, dass der Code peinlich ist)
LOAD DATA LOCAL INFILE '/opt/fhem/log/SensorAussen-2017.log'
INTO TABLE history (@col1)
set TIMESTAMP=REGEXP_REPLACE(REGEXP_SUBSTR(@col1, '^[0-9-_:]{19}'), '_', ' '),
DEVICE=REGEXP_SUBSTR(@col1, '[[:alpha:]]+'),
READING='state',
VALUE=SUBSTRING(SUBSTRING(@col1, REGEXP_INSTR(@col1, '[[:space:]]')+1) ,REGEXP_INSTR(SUBSTRING(@col1, REGEXP_INSTR(@col1, '[[:space:]]')+1), '[[:space:]]')+1),
EVENT=CONCAT(READING,': ',VALUE),
TYPE='',
UNIT=''
;Der Import dauert  ca. 6 sec! Mit dem Modul dauert der Import ca. 2h.
Die Original Filelog Zeile:
2017-08-29_14:40:00 SensorAussen T: 29.0 H: 50 D: 17.5
Das Ergebnis im SQL Server:
+---------------------+--------------+------+------------------------------+---------+-----------------------+------+
| TIMESTAMP           | DEVICE       | TYPE | EVENT                        | READING | VALUE                 | UNIT |
+---------------------+--------------+------+------------------------------+---------+-----------------------+------+
| 2017-08-29 14:40:00 | SensorAussen |      | state: T: 29.0 H: 50 D: 17.5 | state   | T: 29.0 H: 50 D: 17.5 |      |
+---------------------+--------------+------+------------------------------+---------+-----------------------+------+

Vielleicht kann man das ja irgendwie im Modul einheiraten, wenn mal "saure Gurken Zeit" ist. 

Gruß Otto

@Otto123: Ich hatte ein ähnliches Problem, es dauerte teilweise > 12h, eine Logddatei zu importieren.

In den sourcen hab ich gesehen, dass der Code für jedes Logevent einen einzelnen SQL-Aufruf durchführt, das ist zwar so atomar wie nur möglich, aber eben aufwändig, was man bei langen Logfiles zu spüren bekommt.

Ich hab den Code für mich so (minimal) erweitert, dass immer eine gewisse Zahl (ich hab 1000 verwendet) Logeinträge eingelesen und dann auf einmal in einem SQL-Insert eingefügt werden. Das funktionierte bei mir wunderbar, aber ich bin weder Perl-Programmierer noch hab ich mich in die FHEM-Umgebung eingelesen. Bei mir hat das die Verarbeitungszeiten von >10 Stunden auf wenige Minuten für Logfiles ähnlicher Grö0ße gebracht.

@DeeSPe: magst Du Dir mal den angehängten Diff anschauen? Vielleicht könntest Du das ja in das Modul übernehmen.
Aber erstmal: vielen Dank fürs Schreiben des Moduls an sich! Ohne das hätte ich weiter nicht auf logdb gewechselt, sondern auf mittlere Sicht beides parallel laufen lassen.

diff orig/98_FileLogConvert.pm ddw/98_FileLogConvert.pm
175a176
>   my $rows_per_query = 1000;
211a213,214
>   my $query = "";
>   my $qrows = 0;
267c270,288
<       DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
---
>       if ($cmd eq "import2DbLog") # Line n-2 not changed to keep old structure and diff small.
>       {
>         $ret = "('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading','$i_value','$i_unit')";
>         if ($query eq "")
>         {
>           $query = $ret;
>         }
>         else
>         {
>           $query = $query . "," . $ret; # string manipulation is expensive, but not as expensive as SQL-calls
>         }
>         $qrows++;
>         if ($qrows == $rows_per_query)
>         {
>           DbLog_ExecSQL($defs{$dblog},"INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES " . $query . ";");
>           $query = "";
>           $qrows = 0;
>         }
>       }
269a291,296
>   }
>   if ($query ne "") # könnte noch ein Assert ($cmd eq "import2DbLog" && $qrows>0) vertragen
>   {
>     DbLog_ExecSQL($defs{$dblog},"INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES " . $query . ";");
>     $query = "";
>     $qrows = 0;


Zitat von: ddw am 27 Oktober 2019, 19:22:52
@Otto123: Ich hatte ein ähnliches Problem, es dauerte teilweise > 12h, eine Logddatei zu importieren.

In den sourcen hab ich gesehen, dass der Code für jedes Logevent einen einzelnen SQL-Aufruf durchführt, das ist zwar so atomar wie nur möglich, aber eben aufwändig, was man bei langen Logfiles zu spüren bekommt.

Ich hab den Code für mich so (minimal) erweitert, dass immer eine gewisse Zahl (ich hab 1000 verwendet) Logeinträge eingelesen und dann auf einmal in einem SQL-Insert eingefügt werden. Das funktionierte bei mir wunderbar, aber ich bin weder Perl-Programmierer noch hab ich mich in die FHEM-Umgebung eingelesen. Bei mir hat das die Verarbeitungszeiten von >10 Stunden auf wenige Minuten für Logfiles ähnlicher Grö0ße gebracht.

@DeeSPe: magst Du Dir mal den angehängten Diff anschauen? Vielleicht könntest Du das ja in das Modul übernehmen.
Aber erstmal: vielen Dank fürs Schreiben des Moduls an sich! Ohne das hätte ich weiter nicht auf logdb gewechselt, sondern auf mittlere Sicht beides parallel laufen lassen.

Code Auswählen Erweitern

diff orig/98_FileLogConvert.pm ddw/98_FileLogConvert.pm
175a176
>   my $rows_per_query = 1000;
211a213,214
>   my $query = "";
>   my $qrows = 0;
267c270,288
<       DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
---
>       if ($cmd eq "import2DbLog") # Line n-2 not changed to keep old structure and diff small.
>       {
>         $ret = "('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading','$i_value','$i_unit')";
>         if ($query eq "")
>         {
>           $query = $ret;
>         }
>         else
>         {
>           $query = $query . "," . $ret; # string manipulation is expensive, but not as expensive as SQL-calls
>         }
>         $qrows++;
>         if ($qrows == $rows_per_query)
>         {
>           DbLog_ExecSQL($defs{$dblog},"INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES " . $query . ";");
>           $query = "";
>           $qrows = 0;
>         }
>       }
269a291,296
>   }
>   if ($query ne "") # könnte noch ein Assert ($cmd eq "import2DbLog" && $qrows>0) vertragen
>   {
>     DbLog_ExecSQL($defs{$dblog},"INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES " . $query . ";");
>     $query = "";
>     $qrows = 0;


Hallo ddw,

das ist ja interessant, könntest Du mir bitte die komplette geänderte Moduldatei von Dir zukommen lassen?

Danke.

Gruß
Dan

Vielleicht noch was zum Thema "mehrere Dateien".

Habe mir folgendes gebaut, um meine alten Daten (teilweise) einzulesen, ohne dabei jeweils auf den Abschluss des laufenden Prozesses warten zu müssen oder jede Datei einzeln anzugeben. Besteht aus zwei userAttr am FileLogConvert-Gerät, einem notify und etwas myUtils-Code.

Ist evtl. was, was man auch in das Modul einbauen könnte (aber vermutlich noch einfacher zu bedienen, wenn man einen Zeilenwechsel für das split verwendet und "list -1"-Output für's füllen des myFiles-Attributs.

Das mit Attribut zu machen, ist zwar nicht optimal, aber das ganze ist ja keine Dauerlösung, sondern man braucht es einmalig. Abbrechen geht darüber (nach dem Ende des laufenden Imports, indem man eben das Attribut bzw. den Inhalt ändert:

defmod flc FileLogConvert LogDB
attr flc userattr myRegex myFiles
attr flc myFiles Thermostat_Bad_OG-2016.log Thermostat_Bad_OG-2017.log Thermostat_Buero-2016.log Thermostat_Buero-2017.log
attr flc myRegex (actuator|batteryLevel|desired-temp|measured-temp).*


defmod n_flc_next notify flc:import.done {flc_next($NAME)}

Start entweder über eine nicht im Attribut gelistete FileLog-file oder z.B. mit
trigger flc import done

##############################################
# $Id: myUtils_Testing.pm 2019-10-30 Beta-User $
#

package main;

use strict;
use warnings;
use POSIX;

sub
myUtils_Testing_Initialize($$)
{
  my ($hash) = @_;
}

# Enter you functions below _this_ line.

sub flc_next($) {
  my $device = shift (@_);
  my $regxp = AttrVal($device,"myRegex",".*");
  my $myfiles = AttrVal($device,"myFiles","");
  my @files = split(' ',$myfiles);
  return undef unless (@files);
  my $file = shift (@files);
  CommandSet(undef, "$device import2DbLog $file $regxp");
  if (@files) {
    $file = join (" ",@files);
  } else {
    $file = "";
  }
  CommandAttr(undef, "$device myFiles $file");
}

1;

Danke auf alle Fälle für die Import-Funktion!

Hallo Zusammen!

Ich stelle auch gerade bei mir alles auf DbLog um. Die Max Heizkörper und WM-Bus Gaszähler haben prima geklappt. Jetzt hängt es an den Logs von CUL_EM, das sind Mess-Steckdosen von ELV.
Die Filelog Einträge sehen so aus:
2020-01-02_12:13:49 EM_Kuehlschrank CNT: 131 CUM: 286.898  5MIN: 0.000  TOP: 0.000
Damit kommt LogConvert nicht zurecht.
Wie kann ich diese Einiträge am einfachsten importieren?

Gruß,
Burkhard

Hi,

wenn Du ein paar Einträge (bis #77) zurück gehst und liest, weißt Du warum und wie man es machen kann.

Gruß Otto

Hi!

Entweder bin ich zu doof und erkenne nicht, was mir im Beitrag #77 helfen soll oder meine Voraussetzungen sind anders.
addStateEvent  bezieht sich ja nur auf neue Einträge, mit denen hab ich kein Problem, denn die Werte werden von logdb perfekt mitgeschrieben.
Es geht um die Logs der letzten 4 Jahre.  Dafür habe ich in dem Beitrag keine Lösung gefunden.

Gruß,
Burkhard

Ich habe nicht gesagt im Beitrag 77 - aber dort fängt es an, da kommen ein paar Beiträge von mir. Das gleiche Problem wie bei Dir. Du musst halt eine halb "manuelle" Lösung schaffen. Diese "state" Logs sind für FileLog toll für dblog sind sie witzlos, Ich kann nur davon abraten mehrere Werte in einen Wert der Db zu loggen und sie dann beim plotten wieder zu zerlegen. Dauert sinnlos lange. Ich habe keine Weg gefunden es effizient zu machen.
Sorry ich will das nicht nochmal alles für deine Werte durchdenken. Ich habe das mittlerweile sein lassen, weil die ganze Arbeit überhaupt keinen Vorteil bringt.
Du bist mit deinen Programmier Kenntnissen sicher schneller, wenn Du ein sql Script baust, was Deine Datenstruktur berücksichtigt.

Hi !
Danke für die Antwort, damit kann ich arbeiten  ;).
Ich werde dann wohl ein C++ Programm schreiben, dass ein beliebiges Logfile einlesen kann und jede einzelne Zeile mit Multieinträgen in einzelne Zeilen aufteilt. Z.B.
aus
2020-01-02_12:13:49 EM_Kuehlschrank CNT: 131 CUM: 286.898  5MIN: 0.000  TOP: 0.000

wird dann:
2020-01-02_12:13:49 EM_Kuehlschrank CNT: 131
2020-01-02_12:13:49 EM_Kuehlschrank CUM: 286.898
2020-01-02_12:13:49 EM_Kuehlschrank 5MIN: 0.000
2020-01-02_12:13:49 EM_Kuehlschrank TOP: 0.000

das sollte man ja sicher importieren können.
Leider kann ich kein Perl, da könnte man das sicher gleich in LogConvert einbauen, wenn ein Logfile eingelesen wird, dass Mutliwerte enthält.

Gruß,
Burkhard

Ich denke das ist der richtige Weg :)
Aber Du kann es auch gleich in die Datenbank schreiben, die ist doch unabhängig von FHEM erreichbar.

Hi!

Dann muss ich mir ja nicht nur Gedanken über das Einlesen der Logdatei machen, sondern mich auch wieder mit SQL in c++ beschäftigen.
Ich guck mir das Perl Modul mal an, vielleicht kapiere ich ja wie das aufgebaut ist, dann bau ich das da direkt ein.

Gruß,
Burkhard

Ne guck Dir lieber mein SQL Script (#80) an, dass ist einfacher. Aber ja vielleicht hast Du recht, mach einfach andere Logs :)

So Leute,
ich hab mich mal ein wenig mit Perl beschäftigt und die Funktion zum konvertieren abgeändert wie folgt:
1. Ein paar Variablen hinzugefügt (Reading 2 - 5, Value 2-5, event 2-5)
2. einen Abschnitt, wo die Logline analysiert wird, wie viele Elemente enthalten sind, 4 mal kopiert und abgeändert, so das zusätzlich auf 2 bis 5 reading: value Pärchen geprüft wird
3. wurden in den neuen Abschnitten weitere Werte in der Zeile erkannt, wird für diese nochmals ein Datensatz mit diesen Werten in die Datenbank geschrieben.

hier die vollständige Subroutine mit den Änderungen (mit # Komentaren):

sub FileLogConvert_FileRead($)
{
#noch original, erste Änderunge weiter unten
  my ($string) = @_;
  return unless (defined $string);
  my @a       = split /\|/,$string;
  my $name    = $a[0];
  my $hash    = $defs{$name};
  my $cmd     = $hash->{helper}{filedata}{cmd};
  my $dir     = $hash->{helper}{filedata}{dir};
  my $source  = $hash->{helper}{filedata}{source};
  my $dblog   = $hash->{helper}{filedata}{dblog};
  my $eventregex = $hash->{helper}{filedata}{eventregex} ? $hash->{helper}{filedata}{eventregex} : ".*";
  my $stateregex = $hash->{helper}{filedata}{stateregex} ? $hash->{helper}{filedata}{stateregex} : ".*";
  $stateregex =~ s/:/|/g;
  delete $hash->{helper}{filedata};
  my $fname   = "$dir/$source";
  my @events;
  if (!open FH,$fname)
  {
    close(FH);
    my $err = encode_base64("could not read $fname","");
    return "$name|''|$err";
  }
  my $arows = 0;
  my $crows = 0;
  my $dest = $source;
  $dest =~ s/log$/csv/ if ($cmd eq "convert2csv");
  $dest =~ s/log$/sql/ if ($cmd eq "convert2sql");
  $dest =~ s/log$/$dblog/ if ($cmd eq "import2DbLog");
  if ($cmd =~ /^(convert2(csv|sql)|import2DbLog)$/)
  {
    if (!open WH,">>$dir/$dest")
    {
      close WH;
      my $err = encode_base64("could not write $dir/$dest","");
      return "$name|''|$err";
    }
  }
  while (my $line = <FH>)
  {
    $arows++;
    chomp $line;
    $line =~ s/\s{2,}/ /g;
    if ($cmd eq "fileEvents")
    {
      next unless ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S+)(\s.*)?$/
        || $line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+)$/);
      push @events,$4 if (!grep(/^$4$/,@events));
    }
    else
    {
      my $i_date;
      my $i_time;
      my $i_device;
      my $i_type;
      my $i_event;
      my $i_reading;
      my $i_value;
#hier die ersten Änderungen
     my $i_reading2;
      my $i_value2;
      my $i_reading3;
      my $i_value3;
      my $i_reading4;
      my $i_value4;
      my $i_reading5;
      my $i_value5;
      my $i_unit = ""; # diese Zeile ist noch orignial
      $i_reading2=undef; #bei jedem Durchlauf zurücksetzen um prüfen zu können ob sie genutzt wurden
      $i_reading3=undef;
      $i_reading4=undef;
      $i_reading5=undef;
      $i_value2=undef;
      $i_value3=undef;
      $i_value4=undef;
      $i_value5=undef;
     
#Abfrage der Logstruktur erweitert um 4 x \s([A-Za-z0-9\.\-_]+):\s(\S+)(\s.*)
      if    ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)(\s.*)?$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_reading = $4;
        $i_value = $5;
        $i_reading2 = $6;
        $i_value2 = $7;
        $i_reading3 = $8;
        $i_value3 = $9;
        $i_reading4 = $10;
        $i_value4 = $11;
        $i_reading5 = $12;
        $i_value5 = $13;
my $rest = $12 if ($12);
       
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_event = "$i_reading: $i_value";
        $i_event .= " $rest" if ($rest);
        $i_event2 = "$i_reading: $i_value";
        $i_event2 .= " $rest" if ($rest);
        $i_event3 = "$i_reading: $i_value";
        $i_event3 .= " $rest" if ($rest);
        $i_event4 = "$i_reading: $i_value";
        $i_event4 .= " $rest" if ($rest);
        $i_event5 = "$i_reading: $i_value";
        $i_event5 .= " $rest" if ($rest);
      }
      elsif    ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)(\s.*)?$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_reading = $4;
        $i_value = $5;
        $i_reading2 = $6;
        $i_value2 = $7;
        $i_reading3 = $8;
        $i_value3 = $9;
        $i_reading4 = $10;
        $i_value4 = $11;
        my $rest = $12 if ($12);
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_event = "$i_reading: $i_value";
        $i_event .= " $rest" if ($rest);
        $i_event2 = "$i_reading: $i_value";
        $i_event2 .= " $rest" if ($rest);
        $i_event3 = "$i_reading: $i_value";
        $i_event3 .= " $rest" if ($rest);
        $i_event4 = "$i_reading: $i_value";
        $i_event4 .= " $rest" if ($rest);
      }
      elsif    ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)(\s.*)?$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_reading = $4;
        $i_value = $5;
        $i_reading2 = $6;
        $i_value2 = $7;
        $i_reading3 = $8;
        $i_value3 = $9;
        my $rest = $10 if ($10);
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_event = "$i_reading: $i_value";
        $i_event .= " $rest" if ($rest);
        $i_event2 = "$i_reading: $i_value";
        $i_event2 .= " $rest" if ($rest);
        $i_event3 = "$i_reading: $i_value";
        $i_event3 .= " $rest" if ($rest);
      }
      elsif    ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)(\s.*)?$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_reading = $4;
        $i_value = $5;
        $i_reading2 = $6;
        $i_value2 = $7;
        my $rest = $8 if ($8);
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_event = "$i_reading: $i_value";
        $i_event .= " $rest" if ($rest);
        $i_event2 = "$i_reading: $i_value";
        $i_event2 .= " $rest" if ($rest);
      }
      elsif    ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s+([A-Za-z0-9\.\-_]+):\s+(\S+)(\s.*)?$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_reading = $4;
        $i_value = $5;
        my $rest = $6 if ($6);
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_event = "$i_reading: $i_value";
        $i_event .= " $rest" if ($rest);
      }
     
     
# ab hier erst mal wieder original weiter     
     
      elsif ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+):\s(\S+)(\s.*)?$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_reading = $4;
        $i_value = $5;
        my $rest = $6 if ($6);
        next if ($i_reading !~ /^($eventregex)$/);
        $i_unit = $rest ? (split " ",$rest)[0] : "";
        $i_unit = "" if ($i_unit =~ /^[\/\[\{\(]/);
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_event = "$i_reading: $i_value";
        $i_event .= " $rest" if ($rest);
      }
      elsif ($line =~ /^(\d{4}-\d{2}-\d{2})_(\d{2}:\d{2}:\d{2})\s([A-Za-z0-9\.\-_]+)\s([A-Za-z0-9\.\-_]+)$/)
      {
        $i_date = $1;
        $i_time = $2;
        $i_device = $3;
        $i_value = $4;
        next if ($i_value !~ /^($eventregex)$/);
        $i_type = IsDevice($i_device) ? uc $defs{$i_device}->{TYPE} : "";
        $i_reading = "state";
        $i_event = $i_value;
      }
      else
      {
        next;
      }
      $crows++;
      my $ret;
     
 
      { # in Klammern gesetzt zur besseren lesbarkeit, der Code in dieser Klammer ist original
$ret = "INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading','$i_value','$i_unit');" if ($cmd =~ /^(import2DbLog|convert2sql)$/);
$ret = '"'.$i_date.' '.$i_time.'","'.$i_device.'","'.$i_type.'","'.$i_event.'","'.$i_reading.'","'.$i_value.'","'.$i_unit.'"' if ($cmd eq "convert2csv");
DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
print WH $ret,"\n" if ($cmd =~ /^convert2(csv|sql)$/);
  }
# jetzt prüfen ob weitere readings gefunden wurden
  if (defined $i_reading2)# hatten wir ja zu Beginn auf undef gesetzt, wurde sie neu beschrieben? Dann die SQL Funktion mit reading2/value2 ausführen
      {
$ret = "INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading2','$i_value2','$i_unit');" if ($cmd =~ /^(import2DbLog|convert2sql)$/);
$ret = '"'.$i_date.' '.$i_time.'","'.$i_device.'","'.$i_type.'","'.$i_event.'","'.$i_reading2.'","'.$i_value2.'","'.$i_unit.'"' if ($cmd eq "convert2csv");
DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
print WH $ret,"\n" if ($cmd =~ /^convert2(csv|sql)$/);
  }
  if (defined $i_reading3)# usw.
      {
$ret = "INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading3','$i_value3','$i_unit');" if ($cmd =~ /^(import2DbLog|convert2sql)$/);
$ret = '"'.$i_date.' '.$i_time.'","'.$i_device.'","'.$i_type.'","'.$i_event.'","'.$i_reading3.'","'.$i_value3.'","'.$i_unit.'"' if ($cmd eq "convert2csv");
DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
print WH $ret,"\n" if ($cmd =~ /^convert2(csv|sql)$/);
  }
  if (defined $i_reading4)
      {
$ret = "INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading4','$i_value4','$i_unit');" if ($cmd =~ /^(import2DbLog|convert2sql)$/);
$ret = '"'.$i_date.' '.$i_time.'","'.$i_device.'","'.$i_type.'","'.$i_event.'","'.$i_reading4.'","'.$i_value4.'","'.$i_unit.'"' if ($cmd eq "convert2csv");
DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
print WH $ret,"\n" if ($cmd =~ /^convert2(csv|sql)$/);
  }
  if (defined $i_reading5)
      {
$ret = "INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('$i_date $i_time','$i_device','$i_type','$i_event','$i_reading5','$i_value5','$i_unit');" if ($cmd =~ /^(import2DbLog|convert2sql)$/);
$ret = '"'.$i_date.' '.$i_time.'","'.$i_device.'","'.$i_type.'","'.$i_event.'","'.$i_reading5.'","'.$i_value5.'","'.$i_unit.'"' if ($cmd eq "convert2csv");
DbLog_ExecSQL($defs{$dblog},$ret) if ($cmd eq "import2DbLog");
print WH $ret,"\n" if ($cmd =~ /^convert2(csv|sql)$/);
  }
#ab hier wieder original
    }
  }
  close WH if ($cmd =~ /^(convert2(csv|sql)|import2DbLog)$/);
  close FH;
  my $events = @events ? encode_base64(join(" ",@events),"") : "";
  my $regex = $eventregex ? encode_base64($eventregex,"") : "";
  return "$name|$cmd,$source,$arows,$dest,$crows,$events,$regex";
}


Ich prüfe erst auf das 5. reading:value Pärchen, dann 4.,3.,2.,1. weil 4 ja in 5 enthalten wäre usw.. Ich habe die Leerstellentoleranz erhöt, es dürfen auch mehr als eine zwischen den Werten sein.
Danach wird dann das Original mit my $rest ausgeführt.


Das Ergebnis im logdb:
Date             Time              Device                       Type        Event        Reading   Value
2020-03-27 04:25:06    EM_Kuehlschrank    CUL_EM    CNT: 88    CNT            88    
2020-03-27 04:25:06    EM_Kuehlschrank    CUL_EM    CNT: 88    CUM    79.815    
2020-03-27 04:25:06    EM_Kuehlschrank    CUL_EM    CNT: 88    5MIN    0.080    
2020-03-27 04:25:06    EM_Kuehlschrank    CUL_EM    CNT: 88    TOP            0.080    

Für mich funktioniert das jetzt.
Gruß,
Burkhard

Zitat von: DeeSPe am 01 November 2019, 09:30:02
Hallo ddw,

das ist ja interessant, könntest Du mir bitte die komplette geänderte Moduldatei von Dir zukommen lassen?

Danke.

Gruß
Dan

Hallo Dan,

ich weiss, das ist schon ein paar Tage her... - ich wollte aber trotzdem mal fragen, ob Du Dir den Vorschlag von ddw mal angeschaut hattest. Ich möchte derzeit auch eine Menge an Logfiles in meine MariaDB mittels Deines Tools importieren. Allerdings ist es auch bei mir so langsam, dass das Vorgehen so nicht praktikabel ist.

Oder gibt es noch andere Möglichkeiten den Import zu beschleunigen?

Danke und viele Grüße


- Speedy