Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

Omega

Hallo Heiko,

das klappt mit der Version leider auch nicht.
Bei Abfrage der Test-DB (derzeit 7 MB groß) erhalte ich u.a. folgende Werte:

INFO_fhem.create_time 2017-03-23_00:09:28 2017-04-06 21:48:32
INFO_fhem.data_index_length_MB 293.08 2017-04-06 21:48:32


An der Stelle wird die falsche DB gelesen (fhem anstatt von test).

Da diesmal die Ausgabe deutlich kleiner ist, hänge ich noch mal ein list mit an:

Internals:
   DATABASE   test
   DEF        myTESTdb
   LASTCMD    tableinfo
   NAME       rep.myTESTdb
   NOTIFYDEV  global,rep.myTESTdb
   NR         244
   NTFY_ORDER 50-rep.myTESTdb
   ROLE       Client
   STATE      done
   TYPE       DbRep
   VERSION    4.12.1
   Helper:
     DBLOGDEVICE myTESTdb
   Helper:
     Dblog:
       Info_fhem.create_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-03-23_00:09:28
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-03-23_00:09:28
       Info_fhem.data_index_length_mb:
         Mydblog:
           TIME       1491508112.42359
           VALUE      293.08
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      293.08
       Info_fhem.engine:
         Mydblog:
           TIME       1491508112.42359
           VALUE      InnoDB
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      InnoDB
       Info_fhem.row_format:
         Mydblog:
           TIME       1491508112.42359
           VALUE      Compact
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      Compact
       Info_fhem.table_collation:
         Mydblog:
           TIME       1491508112.42359
           VALUE      utf8_bin
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      utf8_bin
       Info_fhem.table_type:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-03-23_00:09:28
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-03-23_00:09:28
       Info_fhem_lt.create_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-03-22_23:43:49
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-03-22_23:43:49
       Info_fhem_lt.data_index_length_mb:
         Mydblog:
           TIME       1491508112.42359
           VALUE      94.25
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      94.25
       Info_fhem_lt.engine:
         Mydblog:
           TIME       1491508112.42359
           VALUE      InnoDB
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      InnoDB
       Info_fhem_lt.row_format:
         Mydblog:
           TIME       1491508112.42359
           VALUE      Compact
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      Compact
       Info_fhem_lt.table_collation:
         Mydblog:
           TIME       1491508112.42359
           VALUE      utf8_bin
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      utf8_bin
       Info_fhem_lt.table_type:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-03-22_23:43:49
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-03-22_23:43:49
       Info_fhemlt.create_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-04-04_11:32:21
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-04-04_11:32:21
       Info_fhemlt.data_index_length_mb:
         Mydblog:
           TIME       1491508112.42359
           VALUE      86.25
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      86.25
       Info_fhemlt.engine:
         Mydblog:
           TIME       1491508112.42359
           VALUE      InnoDB
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      InnoDB
       Info_fhemlt.row_format:
         Mydblog:
           TIME       1491508112.42359
           VALUE      Compact
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      Compact
       Info_fhemlt.table_collation:
         Mydblog:
           TIME       1491508112.42359
           VALUE      utf8_bin
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      utf8_bin
       Info_fhemlt.table_type:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-04-04_11:32:21
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-04-04_11:32:21
       Info_information_schema.create_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-04-06_21:48:32
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-04-06_21:48:32
       Info_information_schema.data_index_length_mb:
         Mydblog:
           TIME       1491508112.42359
           VALUE      0.01
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      0.01
       Info_information_schema.engine:
         Mydblog:
           TIME       1491508112.42359
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      MEMORY
       Info_information_schema.row_format:
         Mydblog:
           TIME       1491508112.42359
           VALUE      Fixed
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      Fixed
       Info_information_schema.table_collation:
         Mydblog:
           TIME       1491508112.42359
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      utf8_general_ci
       Info_information_schema.table_type:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-04-06_21:48:32
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-04-06_21:48:32
       Info_test.create_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-04-04_22:09:48
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-04-04_22:09:48
       Info_test.data_index_length_mb:
         Mydblog:
           TIME       1491508112.42359
           VALUE      7.05
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      7.05
       Info_test.engine:
         Mydblog:
           TIME       1491508112.42359
           VALUE      InnoDB
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      InnoDB
       Info_test.row_format:
         Mydblog:
           TIME       1491508112.42359
           VALUE      Compact
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      Compact
       Info_test.table_collation:
         Mydblog:
           TIME       1491508112.42359
           VALUE      utf8_bin
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      utf8_bin
       Info_test.table_type:
         Mydblog:
           TIME       1491508112.42359
           VALUE      2017-04-04_22:09:48
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      2017-04-04_22:09:48
       Background_processing_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      0.0103
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      0.0103
       Sql_processing_time:
         Mydblog:
           TIME       1491508112.42359
           VALUE      0.0071
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      0.0071
       State:
         Mydblog:
           TIME       1491508112.42359
           VALUE      done
         Myfhemdb:
           TIME       1491508112.43054
           VALUE      done
   Readings:
     2017-04-06 21:48:32   INFO_fhem.create_time 2017-03-23_00:09:28
     2017-04-06 21:48:32   INFO_fhem.data_index_length_MB 293.08
     2017-04-06 21:48:32   INFO_fhem.engine InnoDB
     2017-04-06 21:48:32   INFO_fhem.row_format Compact
     2017-04-06 21:48:32   INFO_fhem.table_collation utf8_bin
     2017-04-06 21:48:32   INFO_fhem.table_type 2017-03-23_00:09:28
     2017-04-06 21:48:32   INFO_fhem_lt.create_time 2017-03-22_23:43:49
     2017-04-06 21:48:32   INFO_fhem_lt.data_index_length_MB 94.25
     2017-04-06 21:48:32   INFO_fhem_lt.engine InnoDB
     2017-04-06 21:48:32   INFO_fhem_lt.row_format Compact
     2017-04-06 21:48:32   INFO_fhem_lt.table_collation utf8_bin
     2017-04-06 21:48:32   INFO_fhem_lt.table_type 2017-03-22_23:43:49
     2017-04-06 21:48:32   INFO_fhemlt.create_time 2017-04-04_11:32:21
     2017-04-06 21:48:32   INFO_fhemlt.data_index_length_MB 86.25
     2017-04-06 21:48:32   INFO_fhemlt.engine InnoDB
     2017-04-06 21:48:32   INFO_fhemlt.row_format Compact
     2017-04-06 21:48:32   INFO_fhemlt.table_collation utf8_bin
     2017-04-06 21:48:32   INFO_fhemlt.table_type 2017-04-04_11:32:21
     2017-04-06 21:48:32   INFO_information_schema.create_time 2017-04-06_21:48:32
     2017-04-06 21:48:32   INFO_information_schema.data_index_length_MB 0.01
     2017-04-06 21:48:32   INFO_information_schema.engine MEMORY
     2017-04-06 21:48:32   INFO_information_schema.row_format Fixed
     2017-04-06 21:48:32   INFO_information_schema.table_collation utf8_general_ci
     2017-04-06 21:48:32   INFO_information_schema.table_type 2017-04-06_21:48:32
     2017-04-06 21:48:32   INFO_test.create_time 2017-04-04_22:09:48
     2017-04-06 21:48:32   INFO_test.data_index_length_MB 7.05
     2017-04-06 21:48:32   INFO_test.engine InnoDB
     2017-04-06 21:48:32   INFO_test.row_format Compact
     2017-04-06 21:48:32   INFO_test.table_collation utf8_bin
     2017-04-06 21:48:32   INFO_test.table_type 2017-04-04_22:09:48
     2017-04-06 21:48:32   background_processing_time 0.0103
     2017-04-06 21:48:32   sql_processing_time 0.0071
     2017-04-06 21:48:32   state           done
   Dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION /opt/fhem/dblog/sqldbtest.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/dblog/sqldbtest.conf (myFHEMdb.*:DbFileSize.*|myFHEMdb.*:1970-01-01__COUNT_.*|Vitocrossal:.*LastDay.*|Vitocrossal:(appCountsPerDay|appCountsPerMonth).*|Vitocrossal:state_.*|.*_avg_.*|.*_max_.*|.*_min_.*|hc.Gasverbrauch_.*:(appCountsPerDay|appCountsPerWeek|appCountsPerMonth|appCountsPerYear).*|HZ_.*:temperature.*|WW_.*:temperature.*|Raumt.*:temperature.*|mys_103.*:temperature.*|mys_103.*:humidity.*|mys_103.*:dewpoint.*|.*:deviceMsg.*|.*:statElectricity.*)
     MODE       asynchronous
     NAME       myTESTdb
     NR         242
     NTFY_ORDER 50-myTESTdb
     PID        22137
     REGEXP     (myFHEMdb.*:DbFileSize.*|myFHEMdb.*:1970-01-01__COUNT_.*|Vitocrossal:.*LastDay.*|Vitocrossal:(appCountsPerDay|appCountsPerMonth).*|Vitocrossal:state_.*|.*_avg_.*|.*_max_.*|.*_min_.*|hc.Gasverbrauch_.*:(appCountsPerDay|appCountsPerWeek|appCountsPerMonth|appCountsPerYear).*|HZ_.*:temperature.*|WW_.*:temperature.*|Raumt.*:temperature.*|mys_103.*:temperature.*|mys_103.*:humidity.*|mys_103.*:dewpoint.*|.*:deviceMsg.*|.*:statElectricity.*)
     STATE      connected
     TYPE       DbLog
     VERSION    2.14.4
     dbconn     mysql:database=test;host=192.168.0.25;port=3306
     dbuser     fhem
     Helper:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     Helper:
       Dblog:
         Dbi connect('database=test;host=192.168.0.25;port=3306','fhem',...) failed:
           Mydblog:
             TIME       1491493681.14178
             VALUE      Can't connect to MySQL server on '192.168.0.25' (111) at ./FHEM/93_DbLog.pm line 1560.

           Myfhemdb:
             TIME       1491493681.14937
             VALUE      Can't connect to MySQL server on '192.168.0.25' (111) at ./FHEM/93_DbLog.pm line 1560.

     Readings:
       2017-04-06 21:55:21   CacheUsage      7
       2017-04-06 21:55:17   NextSync        2017-04-06 21:55:47 or if CacheUsage 500 reached
       2017-04-06 21:55:17   state           connected
     Cache:
       index      21758
       Memcache:
         21752      2017-04-06 21:55:17|WW_Ruecklauf_Zirkulationspumpe|OWDEVICE|temperature: 23.5|temperature|23.5|°C
         21753      2017-04-06 21:55:17|strombezug|JSONMETER|statElectricityConsumed: Hour: 612 Day: 17139 Month: 74872 Year: 74872 (since: 2017-04-02 )|statElectricityConsumed|Hour: 612 Day: 17139 Month: 74872 Year: 74872 (since: 2017-04-02 )|
         21754      2017-04-06 21:55:17|strombezug|JSONMETER|statElectricityConsumedToday: 17139|statElectricityConsumedToday|17139|
         21755      2017-04-06 21:55:17|strombezug|JSONMETER|statElectricityPowerDay: Min: 246 Avg: 783 Max: 7317|statElectricityPowerDay|Min: 246 Avg: 783 Max: 7317|
         21756      2017-04-06 21:55:17|strombezug|JSONMETER|statElectricityPowerMonth: Min: 0 Avg: 639 Max: 7317 (since: 2017-04-01_22:29:19 )|statElectricityPowerMonth|Min: 0 Avg: 639 Max: 7317 (since: 2017-04-01_22:29:19 )|
         21757      2017-04-06 21:55:17|strombezug|JSONMETER|statElectricityPowerYear: Min: 0 Avg: 639 Max: 7317 (since: 2017-04-01_22:29:19 )|statElectricityPowerYear|Min: 0 Avg: 639 Max: 7317 (since: 2017-04-01_22:29:19 )|
         21758      2017-04-06 21:55:21|WW_OG_warm|OWDEVICE|temperature: 53.5|temperature|53.5|°C
Attributes:
   allowDeletion 1
   expimpfile /opt/fhem/backup/exp2sql_lt.csv
   icon       time_note
   room       DbLog
   showproctime 1
   timeout    180


Ach... jetzt sehe ich es auch  :-[ . In der Ausgabe sind ja alle DB's mit ihrer jeweiligen Größe. OK: zum Auswerten, plotten reicht das doch schon erst einmal. Ein Aufruf erschlägt mir gleich 4 DBs  :) .Danke!

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

DS_Starter

Hallo Holger, @ll,

ich habe die get tableinfo-Funktion umgebaut. Jetzt klappt es wie gewünscht (z.Z. nur MySQL).
Es werden nur noch die wesentlichen Merkmale der vorhandenen Tabellen ausgewertet (anderer select)  und auch nur die Tabellen, welche in der mit dem DbRep-Device verbundenen Datenbank (respektive verbundenen DbLog-Device) vorhanden sind.

Die neue Version 4.12.1 habe ich im Eingangsthread abgelegt.

Bitte teste(t) es bei dir/euch.

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Omega

Hallo Heiko,

Glückwunsch - das sieht schon mal sehr gut aus  :). Die Werte aller 4 DBs entsprechen den in der Console ermittelten Werten.

Einen kleinen Unterschied habe ich gesehen, dass hängt aber sicher mit mySQL zusammen.
Nach "get tablefinfo" habe ich in INFO_history.number_of_rows die Anzahl 1.526.238,
nach countEntries aber  1.467.218 Records und
das SQL-Tool HeidiSQL zeigt dagegen "nur" 1.384.927 Records an.

Ich werde aber nicht nachzählen  :D

LG
Holger

NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

DS_Starter

#393
Hallo Holger,

also ich habe mal in der MySQL-Doku nachgelesen https://dev.mysql.com/doc/refman/5.7/en/show-table-status.html,
(die habe ich auch in der commandref verlinkt zu diesem Befehl).

Dort steht:

ZitatThe number of rows. Some storage engines, such as MyISAM, store the exact count. For other storage engines, such as InnoDB, this value is an approximation, and may vary from the actual value by as much as 40 to 50%. In such cases, use SELECT COUNT(*) to obtain an accurate count.

Es ist also eher eine Schätzung ... vertraue dem "set countEntries" oder zähle doch mal nach  :D

Ok. , dann checke ich die Version ein. Bis demnächst ...

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Omega

OK, dann spare ich es mir, das Feld auszuwerten (wollte auf das select verzichten). Dann eben doch elektrisch! zählen - oder auch nicht, da die Aussagekraft doch sehr beschränkt ist. Der Speicherverbrauch dagegen ist wichtiger.

Danke noch mal
LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

viegener

Vielleicht habe ich es übersehen, aber es wäre toll, wenn es eine Art generischen SQL-Aufruf geben würde. Also etwas wo ein voller SQL-Befehl hereingeht und das Ergebnis (Tabelle ?) in einem Reading landet (oder beim get zurückgegeben wird).

Zum Beispiel führe ich regelmässi folgenden Befehl aus (natürlich mit wechselndem Datum)
select device, count(*) from history where timestamp >= "2017-05-06 00:00:00" group by DEVICE HAVING count(*) > 2000

Hintergrund ich habe erstmal alle Devices/Readings in meinemn dblog abgelegt, und möchte nun herausfinden, wo ich finetunen muss, um die DB grösse im Griff zu halten. Bisher führe ich das über ein sqltool direkt auf der Datenbank aus und speichere mir das Ergebnis separat.

Es wäre klasse, wenn so etwas für beliebige SQL-Commands möglich wäre, oder ein Hinweis, wenn ich das übersehen habe?
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

DS_Starter

Hallo viegener,

ja du hast recht, so etwas gibt es bisher nicht.
Ich hatte es auch schon angedacht, war aber bisher an einer zündenden Idee, wie man das unbekannte Ergebnis einer unbekannten Abfrage immer zielsicher in ein Reading hineinbringen könnte, gescheitert.
Eine ähnliche Möglcihkeit gibt es ja bei DbLog, aber auch dort werden komplexere Ergabnisse von Abfragen nicht dargestellt soviel ich weiß.
Mal sehen vielleicht fällt mir da noch etwas ein .... danke für deine Anregung !

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

viegener

Hallo Heiko,
Danke für die Rückmeldung. Ja die SQL-Ausführung in DbLog gibt wohl nur einen Einzelwert zurück.
Die Rückgabe in Readings wäre am einfachsten sicher in der Form wert1|wert2|... und dann in einem Reading mit mehreren Zeilen dieser Art zu realisieren. Zumindest in perl lässt sich das so immer noch recht gut weiterverarbeiten (der senkrechte Strich kann ja noch im Inhalt escaped werden).

Auf Wunsch könnte dann immer noch eine zusätzliche Formatierung über Attribute (texttabelle, json, html) gesteuert werden, das ist aber dann bereits nice-to-have...

Ich liefer auch gerne Code für eine erste Version zu, wenn gewünscht, ich habe bisher nur nicht in die Tasten gegriffen...

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

DS_Starter

ZitatIch liefer auch gerne Code für eine erste Version zu, wenn gewünscht, ich habe bisher nur nicht in die Tasten gegriffen...

Ja klar, immer gerne ....
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

viegener

Zitat von: DS_Starter am 07 Mai 2017, 15:36:47
Ja klar, immer gerne ....

Ich habe mal gestern abend eine erste Version erstellt, die zwei zusätzliche set-Kommandos hinzufügt

sqlResult (Abfrage wo jede Zeile des Ergebnis ein separates Reading ergibt / Felder getrennt mit |)
sqlResultSingle (gesamtes Ergebnis in einem Reading / Zeilen getrennt durch §)

Dabei werden auch timestamp-Einschränkungen unterstützt in dem man z.b. §timestamp_begin§ und _end in das SQL-Command einsetzt, dafür werden dann die entsprechenden Timestamps entsprechend des Attributes gesetzt.

Nur für eine richtige Doku fehlte mir gestern abend die Zeit...

Hier mal angehängt als komplettes Modul - basierend auf der aktuellen (?) Version aus dem svn
Bei mir geht es soweit - aber voll getestet habe ich es nicht
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

DS_Starter

Nabend Johannes,

prima ... ging ja fix !
Ich schau mir es an und teste ....
Aber heute Abend nicht mehr, nehme ich mir für morgen vor.

Danke und VG
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

viegener

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

DS_Starter

Hallo Johannes, @all,

ausgehend von deiner Modulergänzung habe ich getestet und auch noch etwas weiter gebaut und verfeinert.
Die Version 4.13.4 habe ich wieder im ersten Beitrag zum Download/Test hinterlegt.

Das Escaping, was ich übrigens eine ganz tolle Idee finde :) , habe ich dahingehend geändert, dass der Satztrenner nun
so "]|[" aussieht. Das macht sich optisch angenehmer wenn das Ergebnis als ein langer String dargestellt wird, dann ist der
zusammengehörige Satz in "[ ...]" eingeschlossen. Außerdem erlaubt es so innerhalb der Werte das "$" Zeichen. Ich denke zwar
dass es kaum vorkommen wird, aber wer weiß.
Die Verwendung des Escaping habe ich in deinen beiden Subs etwas geändert weil es in meinen unten gezeigten Tests teilweise nicht
so funktionierte wie gewünscht. Muß mal schauen wie ich das Escaping an anderen Stellen des Moduls auch einsetzen kann, das ist
wirklich super !

Dann gibt es nun das Attribut sqlResultSingleFormat mit der Auswahl:
* sline = Single Line (Default)
* mline = Darstellung als multi Line
* table = Darstellung als Tabelle

Diese Darstellungsvarianten gelten für den Befehl sqlResultSingle und werden im Reading SqlResultAio (soll SQL Result all-in-one bedeuten)
abgebildet (bei dir war es das Reading sqlResultTable).  Ich habe im Anhang ein paar Screenshots mit den unterschiedlichen Darstellungen
angehängt.

Für das Reading SqlResultRow_xxx habe ich auch noch eine Verbesserung eingebaut sodass bei einer größeren Ergebnismenge des
Kommandos sqlResult die Sortierreihenfolge eingehalten wird, also wenn zum Bespiel das Ergebnis dreistellig ist. Dabei
wird dynamisch auf die Ergebnismenge reagiert (Screenshot Rep5).

Weiterhin habe ich die Funktionen sqlResult bzw. sqlResultSingle (gilt für beides) so erweitert, dass neben Select-Operationen
auch delete, insert, update (und weitere) Kommandos ausgeführt werden können. Zur Benutzung von delete-Kommandos muß man, wie
im Modul üblich, das Attr "allowDeletion" setzen.

Ich habe mit den verschiedensten Commands erfogreich getestet, hier einen Auswahl:


select device, count(*) from history where timestamp >= "2017-01-06 00:00:00" group by DEVICE HAVING count(*) > 2000
select device, count(*) from history where timestamp >= "2017-01-06 00:00:00" group by DEVICE HAVING count(*) > 800
select device, count(*) from history where timestamp >= "2017-05-06 00:00:00" group by device
select * from history where device like "Te%t" ORDER BY `TIMESTAMP` DESC;
select * from history where `TIMESTAMP` > "2017-05-09 18:03:00" ORDER BY `TIMESTAMP` DESC;
select * from current order by `timestamp` desc;
SELECT SUM(VALUE) AS 'Einspeisung am 04.05.2017', count(*) AS 'Anzahl' FROM `history` where `READING` = "Einspeisung_WirkP_Zaehler_Diff" AND TIMESTAMP BETWEEN '2017-05-04' AND '2017-05-05'
delete from current;
delete from history where timestamp < "2016-05-06 00:00:00"
UPDATE history SET value='TestVa$$$$ue$' WHERE value='TestVa$$$$ue'
select * from history where device = "Te§t"
insert INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES ('2017-05-09 17:00:14','Test','manuell','manuell','Tes§e','TestValue','°C')


Wie man schon sieht, kann man sich dadurch auch die current-Tabelle anschauen bzw. den Inhalt mal löschen.

Für die Tests habe ich meine MariaDB verwendet und dazu auch ein paar recht krude Einträge angelegt:


Reading:  Te§Te  Device: Te§t
2017-05-09,10:00:09,TestValue     
2017-05-09,10:00:10,TestVa§ue
2017-05-09,10:00:11,TestVa§§ue
2017-05-09,10:00:12,TestVa$$$ue
2017-05-09,10:00:13,TestVa$$$$ue
2017-05-09,17:00:13,TestValue


Auch diese Einträge kann das Modul händeln wie man in einem der Screenshots gut sieht.

Ich würde mich freuen wenn du/ihr den Stand auch nochmal bei euch testet, auch für andere DB-Typen. Dazu bin ich noch
nicht gekommen.

Die Commandref muß ich natürlich auch noch schreiben ... immer leidiges Thema ;).

viele Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

viegener

Hallo Heiko,
klappt gut, habe zwar jetzt nur ein paar Statements ausprobiert. Die Idee mit der Tabelle als Formatoption ist auch sehr gut. Aufgefallen ist mir nur folgendes:
- Bei fehlerhaftem Statement stürzt der Tochterprozess im prepare ab und bleibt auf running state. Hier wäre eine Ausführung im eval wahrscheinlich sinnvoll, um dann direkt eine Fehlermeldung
- Macht ein getrenntes sqlResultSingle wirklich noch Sinn? (mit der Formatoption ist das doch unnötig, oder)
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

DS_Starter

Hallo Johannes,

ZitatBei fehlerhaftem Statement stürzt der Tochterprozess im prepare ab und bleibt auf running state. Hier wäre eine Ausführung im eval wahrscheinlich sinnvoll, um dann direkt eine Fehlermeldung

Unbedingt. Hatte zwar auch Fehlermeldungen, die wurden jedoch durch das eval um execute abgefangen. Das werde ich erweitern wie ich es bei DbLog gemacht habe.

ZitatMacht ein getrenntes sqlResultSingle wirklich noch Sinn? (mit der Formatoption ist das doch unnötig, oder)

Ich würde sie drin lassen. Es stört nicht und vllt. bekomme ich es auch mal hin sehr umfangreiche Ergebnisse über eine seitenweise Blätterfunktion darstellen zu lassen. Es gibt immer so viele Anwendungmöglichkeiten an die man nicht unbedingt gleich denkt.

Ich mache mal  noch eine Version ...
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter