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

[DS_Starter]

Hallo zusammen,

habe soeben eine neue Version mit dem Plausibility Check der Feldlänge eingecheckt.
Die Version 3.6 ist auch im Eingangsthread hinterlegt .... wer mag kann sie schon ziehen.

@DerFrickler .. habs auch mit SQLite getestet. Der Längencheck greift hier nicht und somit auch keine Auswirkung auf deine Konfiguration.

Grüße
Heiko

[pejonp]

Hallo DS_Starter,

das Modul 93_DbRep wollte ich testen um meine Auswertungen darüber zu machen. Aber ich scheitere ja schon an der Einrichtung der DbLog-instanz.
Ich habe auf einem NAS (Buffalo) eine MySQL DB laufen. Meine PV Anlage und mein Siemens-Zweirichtungszähler (TD3511) senden dort über DBLog Daten hin. Ich kann mir diese auch als Diagramm (SVG) ansehen.
Ich bekomme aber mit dem 93_DbRep keine Verbindung hin.

Def in FHEM:  define AuswertungPV DbRep fhem .

Da fehlt sicher noch etwas, ich habe aber bis jetzt nichts dazu gefunden. Muß ich eine DB-config Datei anlegen ?

fhem ist eine MySQL DB auf einem NAS.

Vielen Dank.

pejonp

[DS_Starter]

Hallo pejonp,

die Definition von der DbRep-Instanz ist fast richtig.
Du definierst es so:

define AuswertungPV DbRep <DbLog>

<DbLog> steht für den FHEM-Namen deiner DbLog-Instanz (also NICHT der DB auf dem NAS). Wenn du deine DbLog-Instanz z.B. so definiert hättest:

define LogDB DbLog ./db.conf .*:.*

... dann würde das DbRep-Device so aussehen:

Code: [Auswählen]

define AuswertungPV DbRep LogDB
Eine Config-Datei brauchst du nicht, diese Werte werden automatisch von der angegeben DbLog-Instanz ermittelt.

Grüße
Heiko

[pejonp]

Hallo DS_Starter,

vielen Dank für die schnelle Hilfe. Jetzt geht es. Ich habe mir eigentlich alle Seiten hier zum 93_DbRep Modul durchgelesen, bin aber noch nicht ganz dahintergekommen.
Deshalb meine Frage: Kann die abzufragende Datenbank einen anderen Aufbau haben als die Datenbank DBlog (current, history und die fest vergebenen Spalten).
Ich möchte nämlich die Daten meiner
Optimizer :
Date,Time,ID,Inverter,Uptime,Vmod,Vopt,Imod,Eday,Temp
2016-08-21,12:15:35,102232A6,0,19961,50.625000,43.125000,4.281250,498.250000,34.000000
2016-08-21,12:12:22,10221E46,0,19761,50.625000,42.750000,3.781250,302.000000,36.000000
2016-08-21,12:15:15,102232D0,0,10642,52.000000,47.500000,4.312500,298.250000,34.000000

und des Inverters :
Date,Time,ID,Uptime,Interval,Temp,Eday,Eac,Vac1,Vac2,Vac3,Iac1,Iac2,Iac3,Freq1,Freq2,Freq3,EdayDC,Edc,Vdc,Idc,Etot,Irdc,data21,data22,data23,CosPhi1,CosPhi2,CosPhi3,mode,GndFrR,data29,IoutDC,data31
2016-08-21,12:15:51,7E1820EA,21601,300,35.861336,6936.261230,258.701996,239.000000,238.875000,236.953125,5.101511,5.083698,5.089572,50.004982,50.005985,50.004768,4286578687,4286578687,754.000000,4286578687,8161921.000000,0.011312,4286578687,4286578687,4286578687,1.000000,1.000000,1.000000,4,6900.030762,100.000000,0.038208,1030029312

in einer Db ablegen. Wenn ich mich ans Format der DBLog halten muß, dann werden ja mehr Datensätze generiert. Datum, Uhrzeit und ID sind ja eindeutig für den Datensatz.
Vielen Dank.

Tschüß pejonp

[DS_Starter]

Kann die abzufragende Datenbank einen anderen Aufbau haben als die Datenbank DBlog

Nein, das geht nicht. Die SQL-Statements im DbRep-Modul sind auf die DbLog-Struktur zugeschnitten.

Abgesehen davon ist es unwahrscheinlich dass du deine Daten in eine andere Struktur als von DbLog vorgegen automatisch loggen kannst ohne das DbLog-Modul zu ändern 

Du könntest zwar mit Userreadings arbeiten und deine vielen Readings in ein komplettes "Ergebnisreading" zu bringen, aber du bist ja auch an die Feldlänge von 32 Characters (bei MySQL) gebunden, es sei denn du änderst deine DB-Struktur. Aber auch in diesem Fall gibt es Codebeschränkungen im DbLog-Modul welches die Anzahl der Characters pro Feld abhängig vom DB-Typ begrenzt. Man erkennt die Struktur ganz gut mit einem Blick in die db_create_mysql.sql .

Soweit ich es bisher überblicken kann, würde der Ansatz mit dem Userreadings evtl. funktionieren sofern du auf SQLite umsteigen würdest. Dann ziehen die Feldlängenbeschränkungen offensichtlich nicht (siehe unsere Diskussionen etwas weiter vorn).

EDIT: Mir ist deine beabsichtigte Vorgehensweise nicht wirklich transparent da alle Ausgangsreadings ohnehin den gleichen Timestamp bekommen und damit in der DB gespeichert werden. Damit ist eine saubere Auswertung möglich. Wenn du alles zusammenfügst mußt du alles wieder auseinander dividieren um die Einzelwerte zueinander in Auswertung zu bringen.

Grüße
Heiko

[DS_Starter]

Hallo zusammen,

die neue Version 3.7.1 im Eingangsbeitrag enthält eine Erweiterung zum Datenexport im CSV-Format:

Code: [Auswählen]

set .... exportToFile
Es ist das Attribut expimpfile zu setzen um das Ausgabefile festzulegen.
Weiterhin habe ich ein Reading "errortext" eingeführt welches beim Auftreten eines Fehlers den Fehlertext direkt in der Detailansicht anzeigt.

viele Grüße

[DS_Starter]

Hallo zusammen,

ich möchte gern in die Runde fragen ob es inzwischen Anwender gibt die das Modul erfolgreich mit der POSTGRESQL einsetzen.
Dann könnte ich einen entsprechenden Hinweis mit in die commandref aufnehmen.

Danke und allen ein schönes WE.

[DerFrickler]

seit kurzer Zeit läuft bei mir jeder diffVal in ein "error » ProcTime: sql_processing_time sec". alle anderen Funktionen wie contEntries, averageValue und fetchrows funktionieren einwandfrei.

Gruß!

[DS_Starter]

Bin zur Zeit unterwegs und kann nicht wirklich unterstützen.
Idee wäre verbose erhöhen und im Log schauen, auf nicht numerische Werte achten oder FHEM mal restarten (nur als Idee).

Grüße

[DerFrickler]

der Inhalt der DB:

Code: [Auswählen]

2016-08-30 00:00:00: gas.mainCounter, DUMMY, meterReading_m3: 3385.881, meterReading_m3, 3385.881,
2016-08-30 23:55:27: gas.mainCounter, DUMMY, meterReading_m3: 3386.559, meterReading_m3, 3386.559,
2016-08-31 00:00:00: gas.mainCounter, DUMMY, meterReading_m3: 3386.559, meterReading_m3, 3386.559,
2016-09-01 00:00:00: gas.mainCounter, DUMMY, meterReading_m3: 3386.559, meterReading_m3, 3386.559,
2016-09-02 00:00:00: gas.mainCounter, DUMMY, meterReading_m3: 3386.559, meterReading_m3, 3386.559,
2016-09-02 23:59:59: gas.mainCounter, DUMMY, meterReading_m3: 3386.559, meterReading_m3, 3386.559,

was das fetchRow ausgibt entspricht dem Inhalt der DB:

Code: [Auswählen]

2016-08-30_00-00-00__Gas 3385.881 2016-09-03 19:34:43
2016-08-30_23-55-27__Gas 3386.559 2016-09-03 19:34:43
2016-08-31_00-00-00__Gas 3386.559 2016-09-03 19:34:43
2016-09-01_00-00-00__Gas 3386.559 2016-09-03 19:34:43
2016-09-02_00-00-00__Gas 3386.559 2016-09-03 19:34:43
2016-09-02_23-59-59__Gas 3386.559 2016-09-03 19:34:43
und ein Auszug aus dem Log:

Code: [Auswählen]

2016.09.03 19:36:26 4: DbRep DbRep.gas.mainCounter -> BlockingCall diffval_ParseDone finished
TIMESTAMP: 0_2016-01-01, DEVICE: gas.mainCounter, READING: meterReading_m3, VALUE: .
2016.09.03 19:36:26 2: DbRep DbRep.gas.mainCounter - ERROR - value isn't numeric in diffValue function. Faulty dataset was

 MjAxNi0xMg== 0 2016-12-01
 MjAxNi0xMQ== 0 2016-11-01
 MjAxNi0xMA== 0 2016-10-01
 MjAxNi0wOQ== 2016-09-02 23:59:59 3386.559
 MjAxNi0wOQ== 2016-09-02 00:00:00 3386.559
 MjAxNi0wOQ== 2016-09-01 00:00:00 3386.559
 MjAxNi0wOA== 2016-08-31 00:00:00 3386.559
 MjAxNi0wOA== 2016-08-30 23:55:27 3386.559
 MjAxNi0wOA== 2016-08-30 00:00:00 3385.881
 MjAxNi0wNw== 0 2016-07-01
 MjAxNi0wNg== 0 2016-06-01
 MjAxNi0wNQ== 0 2016-05-01
 MjAxNi0wNA== 0 2016-04-01
 MjAxNi0wMw== 0 2016-03-01
 MjAxNi0wMg== 0 2016-02-01

[DS_Starter]

Möglicherweise. Ist mir beim letzten Update ein Fehler passiert. Das kann ich mir aber erst anschauen wenn ich wieder zu Hause bin. Hole dir mal testweise eine vorherige Version aus dem Backup. Du kannst auch nur mal auf einen Monat die Selektion einschränken. Wenn es dann funktioniert muss ich nochmal in mich gehen.

[DS_Starter]

Ich konnte den Fehler jetzt Remote nachvollziehen und weiß auch woran es liegt. Nimm erstmal eine vorherige Version aus dem Backup bis ich den Fehler gefixt habe. Dauert aber etwas ...

Grüße
Heiko

[DS_Starter]

Ich konnte den Fehler fixen. NImm mal bitte die angehängte Version.Die neue Version checke ich auch noch ein.

Grüße
Heiko

[DS_Starter]

Hallo zusammen,

wie versprochen habe ich eine Funktion eingebaut die es ermöglicht vorhandene Readings von der Löschung bei Start einer neuen Operation auszunehmen.
Dafür kann in das Attribut "readingPreventFromDel" eine Komme separierte Liste der zu schützenden Readings eingetragen werden.

Die neue Version 3.8 befindet sind als Anhang im Eingangsbeitrag.

Bitte mal testen ... bei mir läuft es einwandfrei.

viele Grüße
Heiko

[DS_Starter]

Nun bin ich auch dazu gekommen eine Importfunktion (V3.9 im Eingangsbeitrag) zu implementieren.
Damit ist es nun auch möglich einen mit "exportToFile" erzeugten Content (oder ein selbst zusammengestelltes File) im CSV-Format in eine DbLog-Instanz zu importieren. Die Funktion ist praktisch um Device/Readings aus einer DB in eine andere umzuziehen oder manuelle Daten als Massenimport zu importieren.
Die Beschreibung ist im Eingangsbeitrag auch ergänzt.

Die Version checke ich auch noch ein.

Grüße,
Heiko