FHEM Forum

FHEM => Sonstiges => Thema gestartet von: DS_Starter am 19 Mai 2016, 22:52:13

Titel: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2016, 22:52:13
Hallo zusammen,

mir kam die Idee zu diesem Modul durch den Wunsch die Energiedaten meiner PV-Anlage auszuwerten. Ich logge die Energiedaten der PV-Anlage und aller anderen FHEM-Events  über das DbLog-Modul in einer MySQL-DB und möchte mir übersichtlich zum Beispiel die Tageswerte für Einspeisung / Bezug aus der Datenbank aufbereiten.
Daneben sollten ebenfalls die Monatswerte oder auch, je nach Bedarf, für einen bestimmten abgegrenzten Zeitraum, z.B. von Datum/Zeit X bis Datum/Zeit Y usw. die Daten auswertbar sein.

siehe auch diesen Thread : https://forum.fhem.de/index.php/topic,53079.msg448026.html#msg448026 (https://forum.fhem.de/index.php/topic,53079.msg448026.html#msg448026)

Herausgekommen sind bis jetzt die hier angehängte Modulversionen (Ausgangsversion: 93_DbRep.pm bzw. Weiterentwicklungen) die neben der Erfüllung der beschriebenen Erfordernisse auch allgemein zur Auswertung und Management von DB-Inhalten, welche über das DbLog-Modul geschrieben werden, dienen kann. Der Umfang der Fubktionen wird stetig erweitert wobei darauf geachtet wird dass alle Funktionen nonblocking aufgebaut sind.

Ich benutze es aktuell (so wie meine Anforderung bestand) zur Auswertung und Reporting von Energiezählerwerten aber auch ganz allgemein zur Anzeige und Auswertung von jeglichem DB-Content den die Geräte schreiben. Meistens lasse ich mir die Datensätze der vergangenen 24h in einem DbRep-Device anzeigen um einen Überblick zu erhalten.
Für die Anzeige der Energiedaten habe ich mehrere DbRep-Devices angelegt die über Readingsgroup zusammengeführt werden. (siehe Screenshots)

Ich die bisherige Beschreibung an dieser Stelle gelöscht und im Wiki einen neuen Eintrag für das Modul begonnen.
Ergänzungen sind gerne willkommen.

Link zum Wiki-Eintrag:
http://www.fhemwiki.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten (http://www.fhemwiki.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten)

Den aktuellen Entwicklungsstand stelle ich stets im contrib-Verzeichnis bereit, den ich nach einer gewissen Testzeit regulär einchecke.

Die Version könnt ihr hier aus contrib herunterladen:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter  (Downloadbutton benutzen)

Es können dort mehrere Dateien von Modulen die ich gerade weiterentwickle vorhanden sein. Benutzt bitte den Download-Button hinter dem Dateinamen 93_DbRep.pm.

viele Grüße

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Mai 2016, 08:52:31
Ich habe noch etwas weiter gebaut und neben einigen Codeänderungen eine delete-Funktion für DB-Einträge hinzugefügt.
Daneben habe ich die Funktionen des Moduls mit SQLite als DbLog-DB ausprobiert was auch problemlos funktioniert hat.
Die Beschreibung im ersten Beitrag habe ich angepasst und auch die aktuelle Version dort hinterlegt.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Mai 2016, 22:03:28
Mit oben angehängten neuen Version (nonblocking) habe ich die Funktion "fetchrows" mit Blocking.pm auf eine nicht blockierende Arbeitsweise umgestellt. Vielleicht kriege ich das noch für alle Funktionen hin ... mal sehen.
Ein kleiner Nachteil ist dabei, dass man nach der Funktionsausführung den Browser refreshen muß um die Ergebnisse zu sehen wenn man sich in  in der Detailansicht befindet.
Zumindest ist das so wenn die Ergebnismenge ziemlich groß ist habe ich festgestellt.
Aber der Vorteil des nicht blockieren (insbesondere bei umfangreichen selects) überwiegt meiner Meinung nach. Solange die Verarbeitung läuft, wird "running" state angezeigt. Ansonsten "done".

EDIT: die Funktion "delEntries" ist nun auch nonblocking ausgeführt und die Datei als (nonblockig) im ersten Beitrag aktualisiert.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Mai 2016, 09:52:43
Die Funktion "sumValue" wird nun auch nonblocking ausgeführt  -> die aktuelle Version (nonblocking) im ersten Beitrag aktualisiert.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Mai 2016, 14:10:48
Der Code ist weiterentwickelt und die Funktion maxValue nun ebenfalls nonblocking.
Nun sind die Funktionen delEntries, fetchrows, maxValue und sumValue nonblocking ausgelegt.
Die neue Version nonbl_V2.6 ist im Eingangsthread hinterlegt.

Würde mich über Rückmeldungen freuen wie es bei euch läuft bzw. welche Fehler evtl. auftreten.
Ich sammle die evtl gemeldeten Fehler und mache weiter wenn ich wieder Zeit habe.
Also bitte nicht wundern wenn ich nicht gleich antworte ... bin erstmal anderweitig eingebunden.

VG
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Juni 2016, 21:53:26
Hallo zusammen,

nachdem ich nun wieder etwas Zeit gefunden habe, sind in der im Anfangsthread hochgeladenen Version 2.6.2 zwei fehlerhafte Routinen bzgl. der Berechnung der Wochenaggregation und der MaxVal-Werte korrigiert.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Juni 2016, 23:01:38
Mit der weiterentwickelten und angehängten Version 2.6.3 ist die Stabilität des Moduls bei Ausfall bzw. Nichterrechbarkeit der Datenbank verbessert worden.
Weitere kleinere Änderungen ...

VG
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Juni 2016, 09:29:03
Die letzten verbliebenen Funktionen countEntries, averageValue habe ich nun mit der angehängten Version 2.8.1 ebenfalls auf nonblocking umgestellt.
Daneben sind noch Änderungen bezüglich der blockingcall Routinen, den SQL-Aufrufen der Funktionen sumValue, maxValue, fetchrows sowie der main-routine eingeflossen.
Weitere kleinere Änderungen.

Da ich bis jetzt keinerlei negative Rückinfos erhalten habe (eigentlich gar keine  ;) ) werde ich das Modul nun in Kürze dokumentieren und im Repository einchecken.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Juni 2016, 19:07:49
Jetzt habe ich noch die Atribute showproctime und timout hinzugefügt. Zum Einen kann damit die SQL-Zeit (Hintergrund BlockingCall) für eine Funktion ermittelt werden und zum Anderen kann mit timeout die Zeit für den Abbruch des BlockingCall verändert werden (Standard sind 60 Sekunden).

Datei V 2.9  und die Beschreibung sind im ersten Beitrag angepasst.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 27 Juni 2016, 09:57:18
Hallo DS_Starter,

kannst Du mir nochmals etwas behilflich sein ?

Mein Define sieht so aus - Siehe 1. Anlage
Mein Device mit Reading sieht so aus - Siehe 2. Anlage
Die Datenbanktabelle sieht so aus - Siehe 3. Anlage

Es tut sich aber nix. Was mache ich verkehrt bzw. was fehlt mir
noch ? Denke es gibt auch ein Problem mit dem Reading, da
insgesamt 3 EnergyCam Devices Ihre Daten in die Tabelle schreiben,
2 davon mit dem Reading "Energy"

Wie bekomme ich eine Tages- bzw. Monatstabelle hin, wie
Du als Beispiel veröffentlicht hast ?

Version 2.9 ist im Einsatz !

Danke Sandro
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: eldrik am 27 Juni 2016, 10:33:32
Hi DS_Starter,

dein Modul setze ich derzeit noch nicht ein, doch wäre ich daran interessiert zu wissen ob die Abfrageteile, die du bereits auf nonblocking umgestellt hast im Prinzip auch für das DbLog Modul vom Maintainer übernommen oder per Patch zur Verfügung gestellt werden könnten?

Ich glaube dies wäre eine generelle Bereicherung.

Greetz
Eldrik
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2016, 10:47:35
Hi eldrik,

Die Frage könnte eigentlich nur der DbLog-Maintainer beantworten. Sicherlich wären dann einige Anpassungen am DbLog nötig. Ich versuche mich mit diesem Modul auf möglichst flexible Auswertungsscenarien zu konzentrieren um entsprechende Readings bereit zu stellen.
Vielleicht meldet sich ja der Dblog-Maintainer noch dazu.

Grüsse
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2016, 10:51:50
Hallo Sandro,

Dein define sieht erstmal gut aus. Was passiert denn wenn du ein countentries laufen lässt und nachdem der state von Running (oben) nach done gewechselt hat du ein Browser refresh durchführst ?

Gibt es im Log irgendwelche Meldungen ?

Gruß
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 27 Juni 2016, 11:00:32
Servus Heiko,

ein countEntries produziert folgenden Logeintrag:

2016.06.27 09:11:28 3: DbRep Mengen - Connection to db mysql:database=fhem;host=localhost;port=3306 established
Undefined subroutine &main::timelocal called at ./FHEM/93_DbRep.pm line 359.

Ein Browserrefresh geht dann gar nicht mehr. FHEM Server geht dann voll in die Knie
Nur ein kompletter Restart des Raspberry lässt FHEM wieder "erwachen".

Wie schon erwähnt ich nutzte die Vers. 2.9 (gestern erst gezogen!)
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2016, 11:10:16
Na das sollte nicht sein. Ich schaue mir das heute Abend genauer an. Du kannst es bitte nochmal tun mit gesetzten Zeitgrenzen auf zum Beispiel heute 00:00:00  bis aktuelle Zeit.

Grüsse
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 27 Juni 2016, 11:18:01
Nachtrag:

Wenn ich dann nach dem Neustart in das Modul schaue, ist dies disconnect (Siehe Anlage)

VG Sandro
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2016, 11:38:03
Kannst du noch einen Ausschnitt vom Log der FHEM Startsequenz posten. Dort müssten Einträge von "Mengen" drin sein.

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 27 Juni 2016, 12:41:45
Hallo Heiko hier der Output meiner Logdatei:

2016.06.27 08:44:26 0: Server started with 25 defined entities (fhem.pl:11655/2016-06-13 perl:5.020002 os:linux user:fhem pid:434)
2016.06.27 08:44:26 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2016.06.27 08:44:26 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 434
2016.06.27 08:44:26 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
2016.06.27 09:11:28 3: DbRep Mengen - Connection to db mysql:database=fhem;host=localhost;port=3306 established
Undefined subroutine &main::timelocal called at ./FHEM/93_DbRep.pm line 359.
2016.06.27 11:00:09 1: Including fhem.cfg
2016.06.27 11:00:09 3: telnetPort: port 7072 opened
2016.06.27 11:00:11 3: WEB: port 8083 opened
2016.06.27 11:00:11 3: WEBphone: port 8084 opened
2016.06.27 11:00:11 3: WEBtablet: port 8085 opened
2016.06.27 11:00:13 2: eventTypes: loaded 87 events from ./log/eventTypes.txt
2016.06.27 11:00:24 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet_eval:
2016.06.27 11:00:24 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.06.27 11:00:26 3: Opening CUL_0 device /dev/ttyACM0
2016.06.27 11:00:28 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.06.27 11:00:28 3: CUL_0 device opened
2016.06.27 11:00:31 3: CUL_0: Possible commands: BbCFiAZNkGMKUYRTVWXefmLltux
2016.06.27 11:00:31 2: Switched CUL_0 rfmode to WMBus_T
2016.06.27 11:00:34 3: StromzaehlerNT: I/O device is CUL_0
2016.06.27 11:00:34 3: StromzaehlerHT: I/O device is CUL_0
2016.06.27 11:00:40 3: Wasserzaehler: I/O device is CUL_0
2016.06.27 11:00:44 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2016.06.27 11:00:46 2: DbRep Mengen - DB connect failed. Have a look if the credentials of logdb are right !
2016.06.27 11:00:46 1: Including ./log/fhem.save
2016.06.27 11:00:47 1: usb create starting
2016.06.27 11:00:52 3: Probing CUL device /dev/ttyAMA0
2016.06.27 11:00:52 3: Can't open /dev/ttyAMA0: Permission denied
2016.06.27 11:00:53 1: usb create end
2016.06.27 11:00:53 0: Featurelevel: 5.7
2016.06.27 11:00:53 0: Server started with 23 defined entities (fhem.pl:11655/2016-06-13 perl:5.020002 os:linux user:fhem pid:432)
2016.06.27 11:00:53 3: Connecting to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2016.06.27 11:00:53 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established for pid 432
2016.06.27 11:00:53 3: Connection to db mysql:database=fhem;host=localhost;port=3306 established
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2016, 12:55:36
Hi Sandro,

DbLog wird nach DbRep geladen, deswegen kriegt DbRep nicht die Logon-Daten. Die Reihenfolge muss andersherum sein bzw. DbLog sollte ohnehin gleich am Anfang mit starten.

Die andere Sache mit timelocal ... schau mal bitte ob das Modul Time::Local bei dir installiert ist, sollte eigentlich so sein.

Z.B. mit. perldoc perlmodlib
Wenn nicht installier das mal nach.  So jetzt muß ich aber ...  :)

Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 27 Juni 2016, 19:13:54
HAllo Heiko,

das Disconnect Problem ist gelöst, habe die Modul-nr. auf 94 gesetzt nun ist er auch wieder connect.

Wenn ich einen Zeitbegrenzung bei den Attributen eingeben will, kommt folgender Fehler:

The Value for timestamp_begin is out of range - Undefined subroutine &main::timelocal called
Da scheint was zu fehlen.

Zitat
Die andere Sache mit timelocal ... schau mal bitte ob das Modul Time::Local bei dir installiert ist, sollte eigentlich so sein.

Da musst Du mir helfen: Bei mir kommt ...

pi@RPI-FHEM:/opt/fhem/FHEM $ perldoc -f
Option f needs a following argument!

 at /usr/share/perl/5.20/Pod/Perldoc/GetOptsOO.pm line 45.
Usage: perldoc [-hVriDtumFXlT] [-n nroffer_program]
    [-d output_filename] [-o output_format] [-M FormatterModule]
    [-w formatter_option:option_value] [-L translation_code]
    PageName|ModuleName|ProgramName

Examples:

    perldoc -f PerlFunc
    perldoc -q FAQKeywords
    perldoc -v PerlVar
    perldoc -a PerlAPI

The -h option prints more help.  Also try "perldoc perldoc" to get
acquainted with the system.                        [Perldoc v3.23]
pi@RPI-FHEM:/opt/fhem/FHEM $ perldoc -f perlmodlib
No documentation for perl function 'perlmodlib' found
pi@RPI-FHEM:/opt/fhem/FHEM $

raus. Ich gehe davon aus das perllibmod nachzuinstallieren ist. Wie geht das ?

Hier auch nochmals meine fheminfo:

Fhem info:
  Release  : 5.7 FeatureLevel: 5.7
  OS       : linux
  Arch     : arm-linux-gnueabihf-thread-multi-64int
  Perl     : v5.20.2
  uniqueID : e3372d4b3832bb4f0d87f3eda68eedae
  upTime   : 00:11:25

Defined modules:
  CUL           : 1
  DbLog         : 1
  FHEMWEB       : 3
  FileLog       : 4
  HTTPSRV       : 1
  SVG           : 1
  WMBUS         : 3
  autocreate    : 1
  eventTypes    : 1
  notify        : 1
  readingsGroup : 1
  telnet        : 1
  weblink       : 1

Defined models per module:
  CUL           : CUL

VG Sandro

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2016, 19:25:28
Hi Sandro,

also das Problem Time::Local war mein Fehler. Ich habe es im Modul nicht explizit geladen. Bei mir ist es nicht aufgefallen.
Das habe ich jetzt nachgeholt.

Außerdem habe ich die Initialroutine umgebaut. Jetzt sollte das Modul auch dann auf "connect" gehen wenn DbLog erst später geladen wird oder später connected.
Beim FHEM Restart kommt zuerst "initialized" und nach ca. 5 Sek "connected" .. wenn die Verbindung klappt.

Probiere mal die hier angehängte Version.
Vergiß nicht die nach 94_DbRep umbenannte Datei zu löschen !

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 28 Juni 2016, 15:11:25
Hallo Heiko,

das sieht schon vieeel besser aus.

Wo es hackt, ist wenn kein Startdatum angegeben wird, dann läuft er in ein Timeout.
Wie kann man das dynamisch halten und wie kann man die Sache insgesamt triggern ?

(Nimm's mir nicht übel, ich beschäftige mich erst seit einigen Wochen mit
FHEM, allerdings auch "nur" in Verbindung mit einem WAGO-Controller, da ich eine vernüftige Lösung
zum DatenLogging suchte :-) nun - der Appetit kam beim Probieren ... und schon war ein CUL an der Kiste)
 
Ich habe mal bissel dran rumgespielt, gefällt mir sehr sehr gut. Wenn er fertig gerechnet hat, dann muß
man nochmals den Browser refreshen und schon sind die Werte da :-)

Was mich jetzt noch interessiert, laut Deinem Screenshot logst Du bereits Differenzwerte (richtig ?)
was kann ich tun, um aus absolut Zählerständen was gescheites zu machen, Tagesverbrauch, Stundenverbrauch etc. ?

Dein 2. Screenshot ist eine ReadingGroup ? Kann man da eventuell eine Differenzberechnung ansetzen, ich würde das
nur für eine Visu benötigen, die Rohwerte können ruhig so in der DB liegen. Wenn ja, hast Du da einen Ansatz ?

VG Sandro
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2016, 15:34:21
Das ist super Sandro  :)

Den Timeout kannst du mit dem Attribut Timeout beeinflussen. Standard sind 60 Sekunden.
Hier kommt es auf die Performance deiner DB und der Datenmenge an. Hast du auch den Index wie im Eingangsthread angegeben angelegt ?

Wie ich das triggere, schreibe ich heute Abend. Das ist mir auf dem Tel jetzt zu stressig.  ;)
Aber ist ein Notify bzw. Mehrere weil ich insg. 5 DbRep Definitionen habe die alle in die Readingsgroup eingehen.

Du hast Recht, ich logge bereits Diff-Werte bzw. Einen Wert des Wechselrichters der immer seine aktuelle Leistung angibt. Dafür kann dann maxValue mit der Tagesaggregation verwendet werden.

Für deine Aufgabenstellung werde ich wohl das Modul gleich noch erweitern. DiffValue, welches  dann aus einem Periodenanfang und Ende (Aggregation) den Differenzwert in die Readings schreibt. Das wäre dann für solche Loggings wie deine wahrscheinlich eine günstige Variante.

Habe auch noch vor einen Wikieintrag anzulegen wo diese Fallbeispiele nachvollziehbar dargestellt werden.
Dauert halt alles ein bisschen  ;)

Schau dir ruhig mal Readingsgroup an. Das Tool ist sehr mächtig.
Vielleicht stellst du eine Frage dazu noch in einem anderen Umterforum. Ich müsste mich auch etwas näher damit befassen um deine Frage sicher zu beantworten.


Grüsse
Heiko

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 28 Juni 2016, 15:53:35
Hi Heiko,

vielen Dank für die schnelle Antwort. Du brauchst nicht zu hetzen, ich kann mir aber vorstellen das man froh ist, mal ein Feedback zur eigenen Entwicklung zu bekommen. :-)

Meine DB-Tabellen-Parameter siehst Du im Anhang 1 (Sollte alles richtig sein, den Idx hab ich dazugebaut, wegen nachfolgenden Sachverhalt)

Bei der Einrichtung gab/gibt es bei mir eh immer einen Fehler beim ersten Öffnen der Tabellen zumindest mit NaviCat(Light) welches ich benutze. (Siehe Anhang 2)
Dies ist aber ein anderes Ding.

Okay, wie gesagt - Danke erstmal - ich probiere weiter mit ReadingGroup etc. und zwischen drin muß ich auch noch bissel was arbeiten :-)

VG
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2016, 15:59:57
Ja, es ist gut zu erfahren dass die Arbeit nicht nur einen selbst sondern auch anderen hilft. Und dabei findet man auch Fehler die bei der eigenen Installation nicht auftreten.  ;)

Ich melde mich wieder ...
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Juni 2016, 08:30:53
Hi Sandro,

hier die kurze Beschreibung des triggerns.
Ausgangslage ist dass über meinen SMA_Energymeter und Modul SMAEM die Differenzwerte für Bezug, Einspeisung, Kosten und Vergütung in der MySQL-DB regelmäßig gespeichert werden (alle 60 sek).
Die Wechselrichterwerte für die Tageswerte sind immer die jeweilige Leistung die er momentan abgibt. Geloggt wird alle 67 sek.
Für jede dieser Werte gibt es eine DbRep-Instanz mit dem Schema:

Bezug                    -> sumValue
Einspeisung           -> sumValue
Kosten                  -> sumValue
Vergütung             -> sumValue
Tageswerte            -> maxValue

Für die Ermittlung von Bezug, Einspeisung und Tageserzeugung verwende ich drei Definitionen mit dem AT-Kommando.
Hier als Beispiel die Def von recalc_Bezug:

define recalc_Bezug AT +*00:05:05 {if ($mday == 01) {my $rcb = strftime "%Y-%m-%d", localtime(time);; fhem ("attr Bezug timestamp_begin $rcb 00:00:00");; fhem ("set Bezug sumValue") } else {fhem ("set Bezug sumValue") } }

Das if in der Def sorgt dafür dass mit jedem 01. des Monats die Datumselektion weitergeschaltet wird. In einem anderen AT wird regelmäßig ein fhem.save ausgeführt. Dadurch beibt die Weiterschaltung nach einen FHEM Restart erhalten.

Für die Ermittlung von Kosten und Vergütung verwende ich jeweils eine Notify Definition. Hier das Beispiel für recalc_Kosten:

define recalc_Kosten NOTIFY 
Bezug:.*done {if ($mday == 01) {my $rck = strftime "%Y-%m-%d", localtime(time);; fhem ("attr Kosten timestamp_begin $rck 00:00:00");; fhem ("set Kosten sumValue") } else {fhem ("set Kosten sumValue") } }

IF macht das wie oben beschrieben.
Ansonsten wird dieser Vorgang angestoßen wenn die Berechnung von Bezug fertig ist (Event Bezug:.*done).
Die Readings adaptiere ich über das Attr readingsmap zu "Bezug_Summe_(kWh)" (im Falle von Bezug). Einfach für eine bessere Lesbarkeit.

Die erzeugten Readings führe ich dann über ein Readingsgroup zusammen. Wie ich die Def gemacht habe schreibe ich am Besten mal ins Wiki.

viele Grüße
Heiko

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Juni 2016, 19:20:34
Hallo zusammen,

im Eingangsthread habe ich wieder eine weiterentwickelte/korrigierte Version V2.9.7 eingehängt.
Was wurde geändert ?

* die deutesche commandref ist dabei
* der Fehler wegen fehlender Time::Local korrigiert
* das Format der Readingnamen habe ich angepasst damit keine unsupportet Characters mehr auftreten (restart bzw. reread)
* das Attribut readingmap wurde zu readingNameMap geändert, bitte anpassen falls verwendet
* die sql-calls in den Routinen countEntries, averageValue, sumValue geändert -> fix Problem wenn kein timestamp in Verbindung mit aggregation ist gesetzt
* weitere kleine Änderungen

Nach Übernahme FHEM restarten !

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Juli 2016, 10:07:20
Hi Sandro,

du hattest mich doch nach der Readingsgroup Definition gefragt.
Ich werde sicherlich noch einige Zeit brauchen bevor ich dazu komme einen Wikieintrag zu erstellen.

Deswegen hier meine Readingsgroup Def so wie sie in der fhem.cfg steht. Soll als Anregung dienen eine eigene zu erstellen und anzupassen.

######################################################################
# Readingsgroup SMA Energy Meter Übersicht
######################################################################
define SMAEM_Uebersicht readingsGroup <%measure_power>,<01>,<>,<02>,<>,<03>,<>,<04>,<>,<05>,<>,<06>,<>,<07>,<>,<08>,<>,<09>,<>,<10>,<>,<11>,<>,<12>,<>,<13>,<>,<14>,<>,<15>,<>,<16>,<>,<17>,<>,<18>,<>,<19>,<>,<20>,<>,<21>,<>,<22>,<>,<23>,<>,<24>,<>,<25>,<>,<26>,<>,<27>,<>,<28>,<>,<29>,<>,<30>,<>,<31> Bezug:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Einspeisung:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Tageserzeugung:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Verguetung:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Kosten:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31
attr SMAEM_Uebersicht alias Tagesübersicht Einpeisung / Bezug / Ertrag
attr SMAEM_Uebersicht cellStyle { "c:0" => 'style="text-align:left;;color:green;;font-weight:normal"'}
attr SMAEM_Uebersicht group Energie Übersicht
attr SMAEM_Uebersicht mapping {Bezug => "Bezug (kWh)", Einspeisung => "Einspeisung (kWh)", Tageserzeugung => "Erzeugung (kWh)",\
Verguetung => "Ertrag (€)", Kosten => "Stromkosten (€)"}
attr SMAEM_Uebersicht nameStyle style="text-align:center;;color:black;;font-weight:bold"
attr SMAEM_Uebersicht room Energie
attr SMAEM_Uebersicht valueFormat { ($VALUE ne "-") ? "%.2f" : "-" }\

attr SMAEM_Uebersicht valueStyle style="text-align:center"
attr SMAEM_Uebersicht verbose 1

Die einzelnen Erläuterungen dazu findest du im Wiki unter http://www.fhemwiki.de/wiki/ReadingsGroup (http://www.fhemwiki.de/wiki/ReadingsGroup)

Grüsse
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Juli 2016, 16:25:19
Hallo zusammen,

die angehängte Version V2.9.9 enthält eine Korrektur für die Funktion "fetchrows". Nun werden auch Datensätze  die  Leerzeichen in der VALUE-Spalte enthalten vollständig selektiert (zum Beispiel schreibt das SYSMON-Modul solche Einträge).
Weiterhin habe ich die englische Commandref fertig ergänzt. Wenn nichts weiter auffallen solte werde ich das Modul in Kürze dem Repository hinzufügen.

(Die Version ist wieder im Eingangsthread zu finden).

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Tobias am 04 Juli 2016, 07:20:11
Hi,
DbLog ist ein Blocking Modul, wie schon richtig bemerkt ;)
Grund ist das ich bisher kein Veranlasung sah das anders zu machen. DbLog ist zum Loggen da bzw zur Anzeige von SVG´s. Um die Chartfunktion perfomant zu haben gibt es diese 2 Indices.
Ich habe 1 DBLog Instanz als postgre Datenbank auf einem Cubietruck. Meine SVGs sind sehr schnell generiert, warum sollte man also das Modul komplett umkrempeln?
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Juli 2016, 08:26:51
Hi Tobias,

deine Antwort bezieht sich sicherlich auf die Frage von eldrik aus #10.

Persönlich betreibe ich DbLog gegen eine MySQL auf Synology 415+. Im Allgemeinen habe ich keine Sorgen damit.
Auf der Syno läuft natürlich alles im Heimnetz. Neben den FHEM-Instanzen auch die Surveillance mit Kameras und das Mediastreaming.

Die SVGs generieren auch bei mir hinreichend schnell und fallen bei mir auch nicht sehr ins Gewicht. Engpässe habe ich bei Schreibvorgängen, also Logging, festgestellt, wenn viele fhem-Entitäten gleichzeitig  die Events loswerden wollen und in die DB schreiben wenn die Syno entsprechend ausgelastet ist. Dann kann es vorkommen dass Homematic etwas zickig reagiert.
In diesen Situationen wäre eine nicht blockierende Arbeitsweise von DBLog wünschenswert.

Ich denke dass jeder Nutzer entsprechend seiner Umgebung eigene Erfahrungen berichten kann. Mal schauen was eldrik evtl. mitteilt.

Aber bzgl. des hier entstehenden DbRep-Moduls .... du betreibst eine PostgreSQL. Da ich das Modul bisher nur gegen MySQL und SQLite getestet habe, würde ich dich gern bitten es mal gegen die PostgreSQL zu probieren ob alles soweit klappt.
Das wäre super  :)

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Tobias am 04 Juli 2016, 10:05:53
Poste doch mal einen voll funktionierenden Testcase so wie du ihn haben willst. Dann teste ich diesen

Meine DbLog Instanz heißt: DbLog
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Juli 2016, 10:14:23
Danke für deine Unterstützung  :)

Ich schreibe etwas heute Abend ... muß erstmal was arbeiten .

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Juli 2016, 20:30:39
Hallo Tobias,

hier das kleine Testszenario. Mit MySQL / SQLite habe ich alles hin und hergetestet. Grundsätzlich klappt alles, kommt nur darauf
an ob postgre genauso "tickt". Sollte aber, ich habe extra auf DB-spezifische SQL's bewußt verzichtet.
Nimm bitte das Modul aus dem Eingangsthread.

Definition mit:
define Test DbRep DbLog

Nach der Def sollte state von Test-Device kurz auf "initialized" gehen und nach ein paar Sekunden auf "connected".

1. Test
Ohne weitere Attr zu setzen:

set Test countEntries

In Detailansicht switched Test kurz auf "running" (im Overview-Kopf), dann auf done.
Sobald "done" abgezeigt wird -> Browser-Refresh.
Nun sollte die Anzahl aller Einträge in der DB aufgelistet sein.

2. Test
Attr device und reading auf ein Gerät und/oder Reading setzen welches in deiner DB vorkommt.
Dann

set Test countEntries 

Es sollte die Anzahl der Datensätze der in der DB vorkommenden Device/Reading-Kombination angezeigt werden nachdem "done" und
Browser refresht wurde wie in Test 1.

3. Test
wie Test 2, nur setze die Zeitgrenze timestamp_begin bzw. timestamp_end auf z.B. auf passende Werte um nur einen kleinen Zeitabschnitt
in der DB zu selektieren. z.b. timestamp_begin = 2016-07-04 13:00:00, timestamp_end = 2016-07-04 15:00:00.
Dann:

set Test countEntries  -> es sollten nicht zu viele Einträge selektiert werden , wenn ok dann ->
set Test fetchrows

Nun werden die der Device/Reading-Kombi entsprechenden Datensätze angezeigt.
Immer nach "done" im Overview-Kopf und Browserrefresh. Kannst das Device und/oder Reading auch mal löschen -> dann werden alle Datensätze
in den gegebenen Zeitgrenzen angezeigt.

4. Test
wie Test 3 nur benutze ein Reading/Device welches numerische Reading-Values schreibt und nimm die Zeitgrenzen großzügiger, z.B. einen Monat.

Dann:
set Test averageValue    bzw.
set Test sumValue        bzw.
set Test maxValue 

Das Modul berechnet nun die Durchschnitts-, Summen- und Maximalwerte entsprechend der Selektionsbedingungen.
("done" im Overview-Kopf und Browserrefresh)

5. Test
Wiederhole Test 1 - Test 4 mit praktikablen Aggregationswerten (Attr aggregation).
Es werden dann die entsprechenden Berechnungen innerhalb der jeweiligen Perioden durchgeführt. Das gilt nicht für "fetchrows", dafür wird eine evtl.
gesetzte Aggregation nicht berücksichtigt.

Optional:
Wenn das alles klappt, sollte auch die delete-Funktion (delEntries) keine Schwierigkeiten bereiten. Du kannst
sie natürlich auch gern testen wenn es bei dir testbar ist. Es würden dann alle Datensätze in den gegebenen Zeitgrenzen
und Selektionsbedingungen gegeben durch Device/Reading gelöscht und die Anzahl der Löschungen im Log protokolliert.

Danke und Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: eldrik am 05 Juli 2016, 07:49:27
Moin,

ich betreibe fhem inklusive Postgresql Datenbank für DBlog innerhalb einer virtuellen Linux Instanz unter esxi6 auf einem MacMini 4x2Ghz 16GB RAM Server.

Meine Plots generieren sich auch entsprechend zügig, Probleme habe ich in der Vergangenheit bisher bekommen wenn ich z.B. bei dem Plot meines Hausstromzählers (Digital alle 10Sek. wird ein Wert geloggt), bei der Ansicht maximal herauszoome und dann ein zwei Wochen in die Vergangenheit gehen möchte, dann lädt es sehr lange und FHEM ist für niemanden mehr erreichbar, daher hätte ich es als generelle Stabilisierung von FHEM gesehen wenn das Modul nonblocking unterstützen würde, daher die Anregung.

Bei der Nutzung von Apptime sehe ich das Modul auch regelmäßig in den Top10 meiner verbliebenen Module, die Verzögerungen >3Sek. erzeugen, ich glaube dies ist auf die von DS_Starter beschriebenen Engpässe beim Schreiben zurückzuführen.

Greetz
Eldrik
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Juli 2016, 08:15:24
Morgen eldrik,

apptime zeigt bei mir im schlechten Fall zw. 3 und 7 Sekunden (Worstcase) für die Funktion DbLog_Log (also Schreiben). Das ist natürlich abhängig von der Auslastung der Synology im Ganzen.

name             function        max    count    total      average     maxDly
LogDB            DbLog_Log   3821   7721   185153    23.98        0 HASH(LogDB); HASH(sysmon)

Ein bisschen Performance habe ich durch Parametrisierung der MySQL erreicht, aber das Grundthema bleibt trotzdem.

EDIT: Habe gerade realisiert dass du auch postgre einsetzt,  vllt. könntest du auch ein paar Tests mit DbRep ausführen wie oben beschrieben.  :) Dann wären alle von DbLog unterstützten DB's auch mit DbRep getestet

Grüße
Heiko

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: eldrik am 05 Juli 2016, 08:31:15

EDIT: Habe gerade realisiert dass du auch postgre einsetzt,  vllt. könntest du auch ein paar Tests mit DbRep ausführen wie oben beschrieben.  :) Dann wären alle von DbLog unterstützten DB's auch mit DbRep getestet

Grüße
Heiko

Hi,

will ich gerne mal ausprobieren, denke aber das ich vor nächster Woche nicht dazu kommen werde.

Greetz
Eldrik
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Tobias am 05 Juli 2016, 13:43:17
hmm, Modul vom Eingangspost heruntergleaden, umbenannt in 93_DbRep.pm und fhem neu gestartet.
Modul nicht gefunden. Mit einem Reload finde ich das im Log:
reload: Error:Modul 93_DbRep deactivated:
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Juli 2016, 14:26:27
Ist die Datei lesbar (chmod ) ?
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Juli 2016, 09:03:33
Hallo zusammen,

habe soeben eine Version 3.1 des Moduls in den Anfangsthread hochgeladen und die Beschreibung ergänzt. Hinzugekommen ist ein Attribut "timeDiffToNow" sowie kleinere Progarmmkorrekturen.
Dadurch können nun immer die letzten "timeDiffToNow"-Sekunden für die Selektion berücksichtigt werden. Also z.B. werden mit einem Wert von 86400 immer die letzten 24 Stunden in  einer DbRep-Funktion berücksichtigt. Das kann zum  Beispiel hilfreich sein um sich regelmäßig die in der DB gespeicherten Events eines Gerätes oder Readings ausgeben zu lassen, die im Zeitraum der letzten "xxx" Sekunden aufgetreten sind.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Juli 2016, 22:51:43
Hallo miteinander,

im Eingangsthread findet ihr die Version 3.2. Mit dieser Version habe ich das Db-Errorhandling in die Blockingcall Subroutinen verschoben um eventuell auftretende DB-Fehler entsprechend dort abzufangen bzw. zu loggen. Nach weiteren erfolgreichen Tests mit MySQL und SQLite checke ich diese Version heute Abend ein.
In der Commandref habe ich zunächst darauf referenziert dass bislang Tests mit MySQL und SQLite erfolgreich durchgeführt wurden. Ich ergänze es um postgre  wenn ich entsprechendes Feedback bekommen habe bzw. bekommen sollte.

viele Grüße
Heiko 
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 12 Juli 2016, 10:47:12
Hallo Heiko,

kann ich mit der kürzlichen Funktion (Ereigniosse/Werte) der letzten so und soviel Sekunden auch was nützliches bzgl. Differenzwertberechnung
machen ? Hatte mich mal versucht im PM-File was mit Differenzen zu berechen, komme aber damit nicht zurecht, insbesondere die Blocking Funktionen !

Danke nochmals für das Reading Gerüst der Auswertung nach Tagen, finde ich prima und lerne auch dabei gleich was dazu :-)

Die Sachen laufen sehr stabil und  kann nur Sagen Daumen hoch.

VG
Sandro
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juli 2016, 11:25:18
Hi Sandro,

danke für das Feedback !   :)

Die Differenzberechnung ist noch ein offenes ToDo bei mir. Habe noch vor eine solche Funktion zu implementieren. Aber brauche noch etwas Zeit, bzw. bitte um etwas Geduld ... ist Sommerzeit  ;)

Als Zwischenlösung könntest du dir evtl. mit dem statistics-Modul weiterhelfen. Schau dir mal die Möglichkeiten des statistic-Moduls in der commandref dazu an. Du könntest z.B. über dieses Modul neue (Differenz)-Readings in deinem Device erzeugen.
Diese erzeugten statistics-Readings sehen etwa so aus:

statEinspeisung_Wirkleistung_Zaehler   Hour: 0.4140 Day: 5.6034 Month: 206.3490 Year: 206.3490 (since: 2016-07-02 )
Damit du numerische Werte zur Weiterverarbeitung bekommst, könntest du nun wiederum ein/ mehrere UserReadings anlegen und diese über ein Regex mit einem Detailwert, hier z.B. dem Tageswert 5.6034, füttern.

Diese Readings dann in der Datenbank speichern lassen. Dann hast du Differenzwerte/ Maximalwerte pro Zeiteinheit zur Verfügung, die du mit den Funktionen des DbRep-Moduls maxValue/sumValue auslesen, aggregieren und zusammenfassen/weiterverarbeiten kannst.

Das ist nur so eine theoretische Idee/Lösungsansatz ohne den Prozess getestet zu haben. Aber das könnte m.M. nach funktionieren. Kannste ja mal ausprobieren ob es bei der Lösung deiner Aufgabenstellung weiterhilft.


viele Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juli 2016, 18:13:56
Hallo Sandro,

ich habe nun doch schneller als gedacht Zeit gefunden dem Modul die Funktion "diffValue" zu integrieren und die Zeit sofort genutzt.

Damit kannst du (hoffentlich) dein Problem lösen. Es berechnet die Differenzwerte von Loggings, deren Werte sich fortlaufend erhöhen und keine Differenzen wegschreiben. Zeiteingrenzungen und Aggregationen funktionieren wie gehabt.
Die neue Version 3.3 ist im Eingangsthread hinterlegt und auch die Beschreibung ergänzt.

Ich werde die neue Funktion auch noch weiteren Tests unterziehen bevor ich es einchecke und würde mich über deine Erfahrung/Testbericht damit ebenfalls freuen.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 15 Juli 2016, 18:38:01
Hallo Heiko,

ein kurzes Feedback zum neuen Modul.

Konnte dies nun erfolgreich mit dem diffValue nutzen.

Dies ist nun daraus geworden (Siehe Screenshots)

Habe eine Menge dazu gelernt (readinggroups etc.), vielen vielen Dank.

Trotzdem nochmals 3 Fragen:

1. ) Wie Du vielleicht beim Bild EC_Übersicht.png oder auch bei HT-DETAILS.png siehst, sind hier doppelte Einträge
drin ? Kann dies damit zusammenhängen, das die Readings zwei Gruppen zugeordent sind ? Seit dem ist das wohl,
vorher war das schön zusammengestellt ?

2.) Wie würdest Du eine grafische Darstellung der Zahlenstrahlen angehen ? Eine separate DB würde ich mit den
Ergebnissen des DbRep nicht füttern wollen, da ich das dann schon relativ Zeitnah immer ausführe (ca. alle 15 Minuten)
damit auch die Werte etwas leben :-) Kann ich an einen Plot von einer DbRep Abfrage speisen ? Mein Ansatz wäre:
Zusätzlich eine Text-/Logdatei schreiben lassen, die immer nur kommulativ geschrieben wird und das dann in den Plot rein.

3.) Im Übersichtsbild siehst Du in der Jahresübersicht Daten für den Januar und Dezember ! Dies haut natürlich nicht hin,
da scheint sich auch immer was zu verschieben, wie kann ich dies unterbinden, auch im Detailbild liegen die Daten von Juni/Juli
auf Jan/Feb ? Ich habe nochmals ein Bild rangeklebt wo Du die Definition des Readings siehst und dann noch ein Bild mit dem
Ergebnis !

Viele Grüße Sandro
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: kaizo am 15 Juli 2016, 21:04:32
Hallo,

Bei mir ist auch noch ein Fehler im Zeitraum. Ich summiere alle Werte meiner therm. Solaranlage. Wenn ich diese Wochenweise auswerte, den Zeitraum vom 1.1.2016 angebe, dann wird auch die Woche "week 53" als letzter Wert mit "-" angezeigt. Davor steht die richtige Woche 28.

Irgendwie wird noch die Woche 53 ermittelt.
DbRep.pm ist in aktueller Version vom 11.7.16 rev. 11785

Gruß
Kai
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Juli 2016, 22:08:39
Hallo Kai,

danke für deinen Hinweis !
Schaue ich mir mal über das WE an.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Juli 2016, 22:36:29
Hallo Sandro,

zunächst einmal finde ich große Klasse was du bereits aufgebaut und zusammengestellt hast , super ...  :)

Deine Fragen...

1 )  kann ich nicht sofort beantworten. Ich werde versuchen über das WE mal mit meiner Readingsgroup Definition nachzustellen. Welche Readings sind denn zwei Gruppen zugeordnet ?  Meinst du dass du die DbRep-Devices zwei Gruppen zugeordnet hast ?

2) das würde ich auch so machen. Die DbRep-Ergebnisse in Filelog schreiben lassen, wobei es immer mit den jeweiligen aktuellen DbRep-Werte neu überschrieben wird. Daraus dann das SVG generieren.

3) die Ursache der Verschiebung liegt wahrscheinlich darin begründet, dass  keinerlei Wert (auch nicht "0") von der Funktion geliefert wird wenn kein  Datensatz ermittelt werden konnte.  Ich habe das mal geändert und im Eingangsthread die Version 3.3.1 hinterlegt.
Damit wird "-" ausgegeben wenn keine Datensätze in der DB ermittelt werden konnten. (siehe Anhang)
Probier die Version mal bei dir und gib bitte Bescheid ob dein Prob damit gelöst werden konnte .

schönen Abend

LG
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: SandroK am 16 Juli 2016, 10:36:51
Guten Morgen Heiko,

das passt so, die Spalten werden nun korrekt angezeigt, alles Prima :-) siehe Screenshot

Bgzl. der doppelten Einträge in den Userreadings bin ich noch nicht weiter gekommen, habe nun die Gruppen Attribute
alle wieder gelöscht, so das auch keine doppelten Zuordnungen mehr da sind, (das Dashboard nutze ich nun nicht mehr)
trotzdem sind immer doppelte Einträge in den Userreadings drin, aber nur für die ausgelesenen Werte aus dem DBRep Ergebnis.

Werde nochmals ein neues anlegen und schauen, wie es sich da verhält. Schönes Wochenende erstmal und viele Grüße.

Sandro
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Juli 2016, 16:38:57
Hallo Kai,

habe mir das von dir gemeldete Problem angeschaut. Es ist tatsächlich so, dass dieses Jahr der 1.,2. und 3. Januar in der 53. Kalenderwoche liegen. Wollte es selber erst nicht glauben, aber ein Blick in Wikipedia hat mich aufgeklärt dass nach ISO 8601 die 1. Woche des Jahres diejenige ist, die den 4. Januar enthält (gibt noch weitere Definitionen, die aber im Sinn das Gleiche ergeben).

D.h. das Modul hat richtig selektiert und gerechnet, aber da die Readings alphabetisch sortiert werden, wird der Datensatz mit der KW53 ganz unten angezeigt obwohl er ganz oben hingehört um in der richtigen Folge zu bleiben.

Das Problem habe ich mit einer Erweiterung gelöst, welche in der Version 3.3.3 im Eingangthread umgesetzt ist.

Der Beginn (Datum/Stunde) der Selektionsperiode wird dem Ergebnis immer vorangestellt wo es sinnvoll ist. Bei den Funktionen maxvalue bzw. diffvalue wird der  komplette Timestamp des gefundenen Max-Wertes bzw. der komplette Timestamp der letzten Differenzermittlung vorangestellt. Das gilt auch wenn das Attr "readingNameMap" gesetzt ist.

Damit ist gewährleistet dass die richtige Anzeigereihenfolge eingehalten wird (siehe Screenshot).

Bitte mal runterladen und ausprobieren. Habe es mit allen möglichen Variationen getestet und für o.k. befunden  ;)

viele Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: kaizo am 17 Juli 2016, 09:50:22
Hallo Heiko,

klar, die ersten Tage im Jahr sind schon mal in der 53. Woche. Hätte ich auch drauf kommen können...
Hab Dein Modul 3.3.3 getestet, Sortierung funktioniert. Danke.

Danke übrigens für das Modul, hilft mir recht gut bei der Erstellung meiner Solarstatistik.


Gruß
Kai
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2016, 10:18:51
Hallo Kai,

danke für deine Rückantwort.

Ist zwar in diesem Thread etwas Off-Topic .... aber trotzdem die kurze Frage von mir womit du die Werte deiner thermischen Solaranlage erfasst ?

Ich habe neben meiner PV auch eine thermische Solaranlage installiert, aber noch nicht in FHEM eingebunden.

Wäre dir für eine kurze Info dankbar.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2016, 15:17:14
Hallo zusammen,

habe 93_DbRep.pm mit allen aktuellen Änderungen eingescheckt und ist dann morgen früh per Update verfügbar.

schönes Rest-WE
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: kaizo am 17 Juli 2016, 21:13:30
Heiko,

ich habe eine Junkers-Heizung mit Heatronic3. Da kann mit einem Adapter und einem Raspberry den Bus abgehört werden, hier kommen einige Daten raus, u.a. auch den Solarertrag pro Stunde. Es gibt ein Fhem-Modul HEATRONIC dazu.

Wenn das bei dir so nicht geht, dann gehts immer noch mit einem Wärmemengenzähler (Busfähig, Impuls, etc.) Wäre dann auch genauer als das Errechnete vom Heizungscontroller.

Gruß
Kai
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2016, 21:17:27
Hallo Kai,

danke für die Info. Bei mir käme die Variante mit dem Wärmemengenzähler in Frage. Schaue ich mal in dieser Richtung ...

Sorry für Off-Topic .... Off-Topic aus   ;)

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 31 Juli 2016, 21:16:34
######################################################################
# Readingsgroup SMA Energy Meter Übersicht
######################################################################
define SMAEM_Uebersicht readingsGroup <%measure_power>,<01>,<>,<02>,<>,<03>,<>,<04>,<>,<05>,<>,<06>,<>,<07>,<>,<08>,<>,<09>,<>,<10>,<>,<11>,<>,<12>,<>,<13>,<>,<14>,<>,<15>,<>,<16>,<>,<17>,<>,<18>,<>,<19>,<>,<20>,<>,<21>,<>,<22>,<>,<23>,<>,<24>,<>,<25>,<>,<26>,<>,<27>,<>,<28>,<>,<29>,<>,<30>,<>,<31> Bezug:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Einspeisung:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Tageserzeugung:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Verguetung:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31 Kosten:.*-01,<>,.*-02,<>,.*-03,<>,.*-04,<>,.*-05,<>,.*-06,<>,.*-07,<>,.*-08,<>,.*-09,<>,.*-10,<>,.*-11,<>,.*-12,<>,.*-13,<>,.*-14,<>,.*-15,<>,.*-16,<>,.*-17,<>,.*-18,<>,.*-19,<>,.*-20,<>,.*-21,<>,.*-22,<>,.*-23,<>,.*-24,<>,.*-25,<>,.*-26,<>,.*-27,<>,.*-28,<>,.*-29,<>,.*-30,<>,.*-31
attr SMAEM_Uebersicht alias Tagesübersicht Einpeisung / Bezug / Ertrag
attr SMAEM_Uebersicht cellStyle { "c:0" => 'style="text-align:left;;color:green;;font-weight:normal"'}
attr SMAEM_Uebersicht group Energie Übersicht
attr SMAEM_Uebersicht mapping {Bezug => "Bezug (kWh)", Einspeisung => "Einspeisung (kWh)", Tageserzeugung => "Erzeugung (kWh)",\
Verguetung => "Ertrag (€)", Kosten => "Stromkosten (€)"}
attr SMAEM_Uebersicht nameStyle style="text-align:center;;color:black;;font-weight:bold"
attr SMAEM_Uebersicht room Energie
attr SMAEM_Uebersicht valueFormat { ($VALUE ne "-") ? "%.2f" : "-" }\

attr SMAEM_Uebersicht valueStyle style="text-align:center"
attr SMAEM_Uebersicht verbose 1

Wenn Die Werte in Wh vorliegen, wo lassen sich diese am besten in kWh umrechnen?

Danke!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 August 2016, 07:51:03
Guten Morgen,

idealerweise würde ich natürlich die Werte gleich als kWh in die DB schreiben. Zum Beispiel durch Nutzung eines Userreadings mit entsprechender mathematischer Funktion.
Ansonsten kann man in Readingsgroup Berechnungen ähnlich wie bei einer Excel-Tabellenkalkulation vornehmen.
Wie das konkret funktioniert ist sehr detailliert hier im Wiki beschrieben:

http://www.fhemwiki.de/wiki/ReadingsGroup#Berechnungen (http://www.fhemwiki.de/wiki/ReadingsGroup#Berechnungen) 

Hoffe das hilft dir !

Viele Grüße
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 01 August 2016, 17:57:39
Hallo,

mal schauen was man da so machen kann, zumindest bringt es mich auf neue Ideen. Mit dem Modul kann man nicht zufällig auch Werte eintragen? Die Zählerstände vom Hausanschluss müsste ich leider noch manuell mit eintragen... einen Smart Meter besitze ich noch nicht.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 August 2016, 18:59:06
Momentan habe ich das manuelle Eintragen von Werten nicht vorgesehen. Aber das ist auch eine Idee die man dem Modul spendieren kann.

Ich schaue mal ...

viele Grüße
 
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Tobias am 02 August 2016, 10:44:38
Ich übertrage die Werte meiner solartermieanlage von der vitosol per vbus Modul in fhem

Gesendet von meinem Leap mit Tapatalk

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 02 August 2016, 12:08:25
Hallo,

der Ansatz bei mir ist etwas anders. Ich erfasse diejenigen Geräte, die Energiewerte aufzeichnen. Dazu möchte ich den Gesamtbedarf in Relation stellen, um zu sehen was noch nicht erfasst wurde. Mal sehen wie viel Prozent ich in Zukunft durch Messungen abdecken kann.

Solange ich nicht über einen SmartMeter (in welcher Form auch immer) verfüge, muss ich die Werte wohl oder übel per hand eingeben.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 August 2016, 22:02:15
Hallo,

das Modul generiert bei mir im Log elendig lange Einträge und sorgt so zum Absturz von FHEM wenn ich mal den Log aufrufe.

Gruß!

2016.08.03 21:53:18 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1017) line 1.
2016.08.03 21:53:18 3: eval: {diffval_ParseDone('DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17|TWpBeE5pMHdNUT09IDAgMjAxNi0wMS0wMQp8TWpBeE5pMHdNZz09IDAgMjAxNi0wMi0wMQp8TWpBeE5pMHdNdz09IDAgMjAxNi0wMy0wMQp8TWpBeE5pMHdOQT09IDAgMjAxNi0wNC0wMQp8TWpBeE5pMHdOUT09IDAgMjAxNi0wNS0wMQp8TWpBeE5pMHdOZz09IDAgMjAxNi0wNi0wMQp8TWpBeE5pMHdOdz09IDUzODE2NSAyMDE2LTA3LTMxIDIxOjU3OjA5CnxNakF4Tmkwd053PT0gNTM4MTY2IDIwMTYtMDctMzEgMjI6MDE6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxNjcgMjAxNi0wNy0zMSAyMjowNzowOQp8TWpBeE5pMHdOdz09IDUzODE2OCAyMDE2LTA3LTMxIDIyOjExOjA5CnxNakF4Tmkwd053PT0gNTM4MTY5IDIwMTYtMDctMzEgMjI6MTU6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxNzAgMjAxNi0wNy0zMSAyMjoxOTowOQp8TWpBeE5pMHdOdz09IDUzODE3MSAyMDE2LTA3LTMxIDIyOjIzOjA5CnxNakF4Tmkwd053PT0gNTM4MTcyIDIwMTYtMDctMzEgMjI6Mjc6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxNzMgMjAxNi0wNy0zMSAyMjozMzowOQp8TWpBeE5pMHdOdz09IDUzODE3NCAyMDE2LTA3LTMxIDIyOjM3OjA5CnxNakF4Tmkwd053PT0gNTM4MTc1IDIwMTYtMDctMzEgMjI6NDE6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxNzYgMjAxNi0wNy0zMSAyMjo0NTowOQp8TWpBeE5pMHdOdz09IDUzODE3NyAyMDE2LTA3LTMxIDIyOjUxOjA5CnxNakF4Tmkwd053PT0gNTM4MTc4IDIwMTYtMDctMzEgMjI6NTU6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxNzkgMjAxNi0wNy0zMSAyMjo1OTowOQp8TWpBeE5pMHdOdz09IDUzODE4MCAyMDE2LTA3LTMxIDIzOjAzOjA5CnxNakF4Tmkwd053PT0gNTM4MTgxIDIwMTYtMDctMzEgMjM6MDc6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxODIgMjAxNi0wNy0zMSAyMzoxMTowOQp8TWpBeE5pMHdOdz09IDUzODE4MyAyMDE2LTA3LTMxIDIzOjE1OjA5CnxNakF4Tmkwd053PT0gNTM4MTg0IDIwMTYtMDctMzEgMjM6MTc6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxODUgMjAxNi0wNy0zMSAyMzoyMTowOQp8TWpBeE5pMHdOdz09IDUzODE4NiAyMDE2LTA3LTMxIDIzOjI1OjA5CnxNakF4Tmkwd053PT0gNTM4MTg3IDIwMTYtMDctMzEgMjM6Mjc6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxODggMjAxNi0wNy0zMSAyMzozMzowOQp8TWpBeE5pMHdOdz09IDUzODE4OSAyMDE2LTA3LTMxIDIzOjM3OjA5CnxNakF4Tmkwd053PT0gNTM4MTkwIDIwMTYtMDctMzEgMjM6NDE6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxOTEgMjAxNi0wNy0zMSAyMzo0NTowOQp8TWpBeE5pMHdOdz09IDUzODE5MiAyMDE2LTA3LTMxIDIzOjQ5OjA5CnxNakF4Tmkwd053PT0gNTM4MTkzIDIwMTYtMDctMzEgMjM6NTM6MDkKfE1qQXhOaTB3Tnc9PSA1MzgxOTQgMjAxNi0wNy0zMSAyMzo1NzowOQp8TWpBeE5pMHdOdz09IDUzODE5NCAyMDE2LTA3LTMxIDIzOjU5OjU5CnxNakF4Tmkwd09BPT0gNTM4MTk1IDIwMTYtMDgtMDEgMDA6MDE6MDkKfE1qQXhOaTB3T0E9PSA1MzgxOTYgMjAxNi0wOC0wMSAwMDowNTowOQp8TWpBeE5pMHdPQT09IDUzODE5NyAyMDE2LTA4LTAxIDAwOjA5OjA5CnxNakF4Tmkwd09BPT0gNTM4MTk4IDIwMTYtMDgtMDEgMDA6MTU6MDkKfE1qQXhOaTB3T0E9PSA1MzgxOTkgMjAxNi0wOC0wMSAwMDoxOTowOQp8TWpBeE5pMHdPQT09IDUzODIwMCAyMDE2LTA4LTAxIDAwOjIzOjA5CnxNakF4Tmkwd09BPT0gNTM4MjAxIDIwMTYtMDgtMDEgMDA6Mjc6MDkKfE1qQXhOaTB3T0E9PSA1MzgyMDIgMjAxNi0wOC0wMSAwMDozMTowOQp8TWpBeE5pMHdPQT09IDUzODIwMyAyMDE2LTA4LTAxIDAwOjM3OjA5CnxNakF4Tmkwd09BPT0gNTM4MjA0IDIwMTYtMDgtMDEgMDA6NDE6MDkKfE1qQXhOaTB3T0E9PSA1MzgyMDUgMjAxNi0wOC0wMSAwMDo0NTowOQp8TWpBeE5pMHdPQT09IDUzODIwNiAyMDE2LTA4LTAxIDAwOjQ5OjA5CnxNakF4Tmkwd09BPT0gNTM4MjA3IDIwMTYtMDgtMDEgMDA6NTU6MDkKfE1qQXhOaTB3T0E9PSA1MzgyMDggMjAxNi0wOC0wMSAwMDo1OTowOQp8TWpBeE5pMHdPQT09IDUzODIxNSAyMDE2LTA4LTAxIDA2OjI2OjI4CnxNakF4Tmkwd09BPT0gNTM4MjE2IDIwMTYtMDgtMDEgMDY6Mjg6MjgKfE1qQXhOaTB3T0E9PSA1MzgyMTcgMjAxNi0wOC0wMSAwNjozMjoyOAp8TWpBeE5pMHdPQT09IDUzODIxOCAyMDE2LTA4LTAxIDA2OjM2OjI4CnxNakF4Tmkwd09BPT0gNTM4MjE5IDIwMTYtMDgtMDEgMDY6NDI6MjgKfE1qQXhOaTB3T0E9PSA1MzgyMjAgMjAxNi0wOC0wMSAwNjo0NjoyOAp8TWpBeE5pMHdPQT09IDUzODIyMSAyMDE2LTA4LTAxIDA2OjUwOjI4CnxNakF4Tmkwd09BPT0gNTM4MjIyIDIwMTYtMDgtMDEgMDY6NTQ6MjgKfE1qQXhOaTB3T0E9PSA1MzgyMjMgMjAxNi0wOC0wMSAwNjo1ODoyOAp8TWpBeE5pMHdPQT09IDUzODIyNCAyMDE2LTA4LTAxIDA3OjAyOjI4CnxNakF4Tmkwd09BPT0gNTM4MjI1IDIwMTYtMDgtMDEgMDc6MDY6MjgKfE1qQXhOaTB3T0E9PSA1MzgyMjYgMjAxNi0wOC0wMSAwNzoxMDoyOAp8TWpBeE5pMHdPQT09IDUzODIyNyAyMDE2LTA4LTAxIDA3OjE0OjI4CnxNakF4Tmkwd09BPT0gNTM4MjI4IDIwMTYtMDgtMDEgMDc6MjA6MjgKfE1qQXhOaTB3T0E9PSA1MzgyMjkgMjAxNi0wOC0wMSAwNzoyNDoyOAp8TWpBeE5pMHdPQT09IDUzODIzMCAyMDE2LTA4LTAxIDA3OjI4OjI4CnxNakF4Tmkwd09BPT0gNTM4MjMxIDIwMTYtMDgtMDEgMDc6MzI6MjgKfE1qQXhOaTB3T0E9PSA1MzgyMzIgMjAxNi0wOC0wMSAwNzozODoyOAp8TWpBeE5pMHdPQT09IDUzODIzMyAyMDE2LTA4LTAxIDA3OjQyOjI4CnxNakF4Tmkwd09BPT0gNTM4MjM0IDIwMTYtMDgtMDEgMDc6NDY6MzYKfE1qQXhOaTB3T0E9PSA1MzgyMzUgMjAxNi0wOC0wMSAwNzo1MDozNgp8TWpBeE5pMHdPQT09IDUzODIzNiAyMDE2LTA4LTAxIDA3OjU0OjM2CnxNakF4Tmkwd09BPT0gNTM4MjM3IDIwMTYtMDgtMDEgMDg6MDA6MzYKfE1qQXhOaTB3T0E9PSA1MzgyMzggMjAxNi0wOC0wMSAwODowNDozNgp8TWpBeE5pMHdPQT09IDUzODIzOSAyMDE2LTA4LTAxIDA4OjA4OjM2CnxNakF4Tmkwd09BPT0gNTM4MjQwIDIwMTYtMDgtMDEgMDg6MTI6MzYKfE1qQXhOaTB3T0E9PSA1MzgyNDEgMjAxNi0wOC0wMSAwODoxNjozNgp8TWpBeE5pMHdPQT09IDUzODI0MiAyMDE2LTA4LTAxIDA4OjIwOjM2CnxNakF4Tmkwd09BPT0gNTM4MjQzIDIwMTYtMDgtMDEgMDg6MjQ6MzYKfE1qQXhOaTB3T0E9PSA1MzgyNDQgMjAxNi0wOC0wMSAwODoyODozNgp8TWpBeE5pMHdPQT09IDUzODI0NSAyMDE2LTA4LTAxIDA4OjMyOjM2CnxNakF4Tmkwd09BPT0gNTM4MjQ2IDIwMTYtMDgtMDEgMDg6MzY6MzYKfE1qQXhOaTB3T0E9PSA1MzgyNDcgMjAxNi0wOC0wMSAwODo0MjozNgp8TWpBeE5pMHdPQT09IDUzODI0OCAyMDE2LTA4LTAxIDA4OjQ2OjM2CnxNakF4Tmkwd09BPT0gNTM4MjQ5IDIwMTYtMDgtMDEgMDg6NTA6MzYKfE1qQXhOaTB3T0E9PSA1MzgyNTAgMjAxNi0wOC0wMSAwODo1NDozNgp8TWpBeE5pMHdPQT09IDUzODI1MSAyMDE2LTA4LTAxIDA4OjU4OjM2CnxNakF4Tmkwd09BPT0gNTM4MjUyIDIwMTYtMDgtMDEgMDk6MDI6MzcKfE1qQXhOaTB3T0E9PSA1MzgyNTMgMjAxNi0wOC0wMSAwOTowODozNgp8TWpBeE5pMHdPQT09IDUzODI1NCAyMDE2LTA4LTAxIDA5OjEyOjM2CnxNakF4Tmkwd09BPT0gNTM4MjU1IDIwMTYtMDgtMDEgMDk6MTY6MzYKfE1qQXhOaTB3T0E9PSA1MzgyNTYgMjAxNi0wOC0wMSAwOToyMDozNwp8TWpBeE5pMHdPQT09IDUzODI1NyAyMDE2LTA4LTAxIDA5OjI0OjM2CnxNakF4Tmkwd09BPT0gNTM4MjU4IDIwMTYtMDgtMDEgMDk6MzA6MzcKfE1qQXhOaTB3T0E9PSA1MzgyNTkgMjAxNi0wOC0wMSAwOTozNDozNgp8TWpBeE5pMHdPQT09IDUzODI2MCAyMDE2LTA4LTAxIDA5OjM4OjM2CnxNakF4Tmkwd09BPT0gNTM4MjYxIDIwMTYtMDgtMDEgMDk6NDI6MzcKfE1qQXhOaTB3T0E9PSA1MzgyNjIgMjAxNi0wOC0wMSAwOTo0NjozNgp8TWpBeE5pMHdPQT09IDUzODI2MyAyMDE2LTA4LTAxIDA5OjUwOjM2CnxNakF4Tmkwd09BPT0gNTM4MjY0IDIwMTYtMDgtMDEgMDk6NTQ6MzYKfE1qQXhOaTB3T0E9PSA1MzgyNjcgMjAxNi0wOC0wMSAwOTo1ODozNQp8TWpBeE5pMHdPQT09IDUzODI3MiAyMDE2LTA4LTAxIDEwOjAwOjM1CnxNakF4Tmkwd09BPT0gNTM4Mjc3IDIwMTYtMDgtMDEgMTA6MDI6MzUKfE1qQXhOaTB3T0E9PSA1MzgyNzggMjAxNi0wOC0wMSAxMDowMjo0NAp8TWpBeE5pMHdPQT09IDUzODI4MSAyMDE2LTA4LTAxIDEwOjAzOjQ0CnxNakF4Tmkwd09BPT0gNTM4Mjg2IDIwMTYtMDgtMDEgMTA6MDU6NDQKfE1qQXhOaTB3T0E9PSA1MzgyODggMjAxNi0wOC0wMSAxMDowNjoyNAp8TWpBeE5pMHdPQT09IDUzODI5MSAyMDE2LTA4LTAxIDEwOjA3OjI0CnxNakF4Tmkwd09BPT0gNTM4Mjk3IDIwMTYtMDgtMDEgMTA6MDk6MjQKfE1qQXhOaTB3T0E9PSA1MzgzMDIgMjAxNi0wOC0wMSAxMDoxMToyNQp8TWpBeE5pMHdPQT09IDUzODMwOCAyMDE2LTA4LTAxIDEwOjEzOjI1CnxNakF4Tmkwd09BPT0gNTM4MzE0IDIwMTYtMDgtMDEgMTA6MTU6MjQKfE1qQXhOaTB3T0E9PSA1MzgzMjAgMjAxNi0wOC0wMSAxMDoxNzoyNAp8TWpBeE5pMHdPQT09IDUzODMyNCAyMDE2LTA4LTAxIDEwOjE4OjU1CnxNakF4Tmkwd09BPT0gNTM4MzMwIDIwMTYtMDgtMDEgMTA6MjA6NTUKfE1qQXhOaTB3T0E9PSA1MzgzMzYgMjAxNi0wOC0wMSAxMDoyMjo1NQp8TWpBeE5pMHdPQT09IDUzODM0MiAyMDE2LTA4LTAxIDEwOjI0OjU1CnxNakF4Tmkwd09BPT0gNTM4MzQ4IDIwMTYtMDgtMDEgMTA6MjY6NTUKfE1qQXhOaTB3T0E9PSA1MzgzNTQgMjAxNi0wOC0wMSAxMDoyODo1NQp8TWpBeE5pMHdPQT09IDUzODM2MCAyMDE2LTA4LTAxIDEwOjMwOjU1CnxNakF4Tmkwd09BPT0gNTM4MzY2IDIwMTYtMDgtMDEgMTA6MzI6NDQKfE1qQXhOaTB3T0E9PSA1MzgzNjkgMjAxNi0wOC0wMSAxMDozMzo0NQp8TWpBeE5pMHdPQT09IDUzODM3NSAyMDE2LTA4LTAxIDEwOjM1OjQ1CnxNakF4Tmkwd09BPT0gNTM4Mzc3IDIwMTYtMDgtMDEgMTA6MzY6MjUKfE1qQXhOaTB3T0E9PSA1MzgzODQgMjAxNi0wOC0wMSAxMDozODoyNAp8TWpBeE5pMHdPQT09IDUzODM5MSAyMDE2LTA4LTAxIDEwOjQwOjI0CnxNakF4Tmkwd09BPT0gNTM4Mzk4IDIwMTYtMDgtMDEgMTA6NDI6MjUKfE1qQXhOaTB3T0E9PSA1Mzg0MDEgMjAxNi0wOC0wMSAxMDo0MzoyNAp8TWpBeE5pMHdPQT09IDUzODQwNSAyMDE2LTA4LTAxIDEwOjQ0OjI1CnxNakF4Tmkwd09BPT0gNTM4NDEyIDIwMTYtMDgtMDEgMTA6NDY6MjQKfE1qQXhOaTB3T0E9PSA1Mzg0MTkgMjAxNi0wOC0wMSAxMDo0ODoyNQp8TWpBeE5pMHdPQT09IDUzODQyNiAyMDE2LTA4LTAxIDEwOjUwOjI0CnxNakF4Tmkwd09BPT0gNTM4NDMyIDIwMTYtMDgtMDEgMTA6NTI6MjQKfE1qQXhOaTB3T0E9PSA1Mzg0MzkgMjAxNi0wOC0wMSAxMDo1NDoyNAp8TWpBeE5pMHdPQT09IDUzODQ0MyAyMDE2LTA4LTAxIDEwOjU1OjM1CnxNakF4Tmkwd09BPT0gNTM4NDQ3IDIwMTYtMDgtMDEgMTA6NTY6MzUKfE1qQXhOaTB3T0E9PSA1Mzg0NTMgMjAxNi0wOC0wMSAxMDo1ODozNQp8TWpBeE5pMHdPQT09IDUzODQ1OCAyMDE2LTA4LTAxIDEwOjU5OjU1CnxNakF4Tmkwd09BPT0gNTM4NDYyIDIwMTYtMDgtMDEgMTE6MDE6MDQKfE1qQXhOaTB3T0E9PSA1Mzg0NjggMjAxNi0wOC0wMSAxMTowMzowNQp8TWpBeE5pMHdPQT09IDUzODQ3NSAyMDE2LTA4LTAxIDExOjA1OjA1CnxNakF4Tmkwd09BPT0gNTM4NDgyIDIwMTYtMDgtMDEgMTE6MDc6MDUKfE1qQXhOaTB3T0E9PSA1Mzg0ODkgMjAxNi0wOC0wMSAxMTowOToxNQp8TWpBeE5pMHdPQT09IDUzODQ5NiAyMDE2LTA4LTAxIDExOjExOjE1CnxNakF4Tmkwd09BPT0gNTM4NTAzIDIwMTYtMDgtMDEgMTE6MTM6MTUKfE1qQXhOaTB3T0E9PSA1Mzg1MDkgMjAxNi0wOC0wMSAxMToxNToxNQp8TWpBeE5pMHdPQT09IDUzODUxMSAyMDE2LTA4LTAxIDExOjE1OjQ1CnxNakF4Tmkwd09BPT0gNTM4NTE0IDIwMTYtMDgtMDEgMTE6MTY6NDQKfE1qQXhOaTB3T0E9PSA1Mzg1MTcgMjAxNi0wOC0wMSAxMToxNzo0NQp8TWpBeE5pMHdPQT09IDUzODUyNCAyMDE2LTA4LTAxIDExOjE5OjQ1CnxNakF4Tmkwd09BPT0gNTM4NTMwIDIwMTYtMDgtMDEgMTE6MjE6MzUKfE1qQXhOaTB3T0E9PSA1Mzg1MzMgMjAxNi0wOC0wMSAxMToyMjozNQp8TWpBeE5pMHdPQT09IDUzODU0MCAyMDE2LTA4LTAxIDExOjI0OjM1CnxNakF4Tmkwd09BPT0gNTM4NTQ3IDIwMTYtMDgtMDEgMTE6MjY6MzUKfE1qQXhOaTB3T0E9PSA1Mzg1NTQgMjAxNi0wOC0wMSAxMToyODozNQp8TWpBeE5pMHdPQT09IDUzODU2MCAyMDE2LTA4LTAxIDExOjMwOjM1CnxNakF4Tmkwd09BPT0gNTM4NTY3IDIwMTYtMDgtMDEgMTE6MzI6MzUKfE1qQXhOaTB3T0E9PSA1Mzg1NzQgMjAxNi0wOC0wMSAxMTozNDozNQp8TWpBeE5pMHdPQT09IDUzODU4MCAyMDE2LTA4LTAxIDExOjM2OjM1CnxNakF4Tmkwd09BPT0gNTM4NTg3IDIwMTYtMDgtMDEgMTE6Mzg6MzUKfE1qQXhOaTB3T0E9PSA1Mzg1OTQgMjAxNi0wOC0wMSAxMTo0MDozNQp8TWpBeE5pMHdPQT09IDUzODYwMSAyMDE2LTA4LTAxIDExOjQyOjM1CnxNakF4Tmkwd09BPT0gNTM4NjA3IDIwMTYtMDgtMDEgMTE6NDQ6MzUKfE1qQXhOaTB3T0E9PSA1Mzg2MTQgMjAxNi0wOC0wMSAxMTo0NjozNQp8TWpBeE5pMHdPQT09IDUzODYyMSAyMDE2LTA4LTAxIDExOjQ4OjM1CnxNakF4Tmkwd09BPT0gNTM4NjI3IDIwMTYtMDgtMDEgMTE6NTA6MzUKfE1qQXhOaTB3T0E9PSA1Mzg2MzQgMjAxNi0wOC0wMSAxMTo1MjozNQp8TWpBeE5pMHdPQT09IDUzODY0MSAyMDE2LTA4LTAxIDExOjU0OjM1CnxNakF4Tmkwd09BPT0gNTM4NjQ3IDIwMTYtMDgtMDEgMTE6NTY6MjUKfE1qQXhOaTB3T0E9PSA1Mzg2NTAgMjAxNi0wOC0wMSAxMTo1NzoyNQp8TWpBeE5pMHdPQT09IDUzODY1NyAyMDE2LTA4LTAxIDExOjU5OjI1CnxNakF4Tmkwd09BPT0gNTM4NjYzIDIwMTYtMDgtMDEgMTI6MDE6MjUKfE1qQXhOaTB3T0E9PSA1Mzg2NzAgMjAxNi0wOC0wMSAxMjowMzoyNQp8TWpBeE5pMHdPQT09IDUzODY3NiAyMDE2LTA4LTAxIDEyOjA1OjI1CnxNakF4Tmkwd09BPT0gNTM4NjgzIDIwMTYtMDgtMDEgMTI6MDc6MjUKfE1qQXhOaTB3T0E9PSA1Mzg2OTAgMjAxNi0wOC0wMSAxMjowOToyNQp8TWpBeE5pMHdPQT09IDUzODY5MiAyMDE2LTA4LTAxIDEyOjEwOjA1CnxNakF4Tmkwd09BPT0gNTM4NjkzIDIwMTYtMDgtMDEgMTI6MTM6NDUKfE1qQXhOaTB3T0E9PSA1Mzg2OTQgMjAxNi0wOC0wMSAxMjoxNTo0NQp8TWpBeE5pMHdPQT09IDUzODY5NSAyMDE2LTA4LTAxIDEyOjE5OjQ1CnxNakF4Tmkwd09BPT0gNTM4Njk3IDIwMTYtMDgtMDEgMTI6MjA6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3MDIgMjAxNi0wOC0wMSAxMjoyMjo1NQp8TWpBeE5pMHdPQT09IDUzODcwNyAyMDE2LTA4LTAxIDEyOjI0OjU1CnxNakF4Tmkwd09BPT0gNTM4NzEyIDIwMTYtMDgtMDEgMTI6MjY6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3MTcgMjAxNi0wOC0wMSAxMjoyODo1NQp8TWpBeE5pMHdPQT09IDUzODcyMiAyMDE2LTA4LTAxIDEyOjMwOjU1CnxNakF4Tmkwd09BPT0gNTM4NzI3IDIwMTYtMDgtMDEgMTI6MzI6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3MzIgMjAxNi0wOC0wMSAxMjozNDo1NQp8TWpBeE5pMHdPQT09IDUzODczNyAyMDE2LTA4LTAxIDEyOjM2OjU1CnxNakF4Tmkwd09BPT0gNTM4NzQyIDIwMTYtMDgtMDEgMTI6Mzg6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3NDcgMjAxNi0wOC0wMSAxMjo0MDo1NQp8TWpBeE5pMHdPQT09IDUzODc1MiAyMDE2LTA4LTAxIDEyOjQyOjU1CnxNakF4Tmkwd09BPT0gNTM4NzU3IDIwMTYtMDgtMDEgMTI6NDQ6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3NjIgMjAxNi0wOC0wMSAxMjo0Njo1NQp8TWpBeE5pMHdPQT09IDUzODc2NyAyMDE2LTA4LTAxIDEyOjQ4OjU1CnxNakF4Tmkwd09BPT0gNTM4NzcyIDIwMTYtMDgtMDEgMTI6NTA6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3NzcgMjAxNi0wOC0wMSAxMjo1Mjo1NQp8TWpBeE5pMHdPQT09IDUzODc4MiAyMDE2LTA4LTAxIDEyOjU0OjU1CnxNakF4Tmkwd09BPT0gNTM4Nzg3IDIwMTYtMDgtMDEgMTI6NTY6NTUKfE1qQXhOaTB3T0E9PSA1Mzg3OTIgMjAxNi0wOC0wMSAxMjo1ODo1NQp8TWpBeE5pMHdPQT09IDUzODc5NyAyMDE2LTA4LTAxIDEzOjAwOjU1CnxNakF4Tmkwd09BPT0gNTM4ODAyIDIwMTYtMDgtMDEgMTM6MDI6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4MDcgMjAxNi0wOC0wMSAxMzowNDo1NQp8TWpBeE5pMHdPQT09IDUzODgxMiAyMDE2LTA4LTAxIDEzOjA2OjU1CnxNakF4Tmkwd09BPT0gNTM4ODE3IDIwMTYtMDgtMDEgMTM6MDg6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4MjIgMjAxNi0wOC0wMSAxMzoxMDo1NQp8TWpBeE5pMHdPQT09IDUzODgyNyAyMDE2LTA4LTAxIDEzOjEyOjU1CnxNakF4Tmkwd09BPT0gNTM4ODMyIDIwMTYtMDgtMDEgMTM6MTQ6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4MzcgMjAxNi0wOC0wMSAxMzoxNjo1NQp8TWpBeE5pMHdPQT09IDUzODg0MSAyMDE2LTA4LTAxIDEzOjE4OjU1CnxNakF4Tmkwd09BPT0gNTM4ODQ2IDIwMTYtMDgtMDEgMTM6MjA6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4NTIgMjAxNi0wOC0wMSAxMzoyMjo1NQp8TWpBeE5pMHdPQT09IDUzODg1NiAyMDE2LTA4LTAxIDEzOjI0OjU1CnxNakF4Tmkwd09BPT0gNTM4ODYxIDIwMTYtMDgtMDEgMTM6MjY6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4NjcgMjAxNi0wOC0wMSAxMzoyODo1NQp8TWpBeE5pMHdPQT09IDUzODg3MSAyMDE2LTA4LTAxIDEzOjMwOjU1CnxNakF4Tmkwd09BPT0gNTM4ODc2IDIwMTYtMDgtMDEgMTM6MzI6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4ODEgMjAxNi0wOC0wMSAxMzozNDo1NQp8TWpBeE5pMHdPQT09IDUzODg4NiAyMDE2LTA4LTAxIDEzOjM2OjU1CnxNakF4Tmkwd09BPT0gNTM4ODkxIDIwMTYtMDgtMDEgMTM6Mzg6NTUKfE1qQXhOaTB3T0E9PSA1Mzg4OTYgMjAxNi0wOC0wMSAxMzo0MDo1NQp8TWpBeE5pMHdPQT09IDUzODkwMSAyMDE2LTA4LTAxIDEzOjQyOjU1CnxNakF4Tmkwd09BPT0gNTM4OTA2IDIwMTYtMDgtMDEgMTM6NDQ6NTUKfE1qQXhOaTB3T0E9PSA1Mzg5MTEgMjAxNi0wOC0wMSAxMzo0Njo1NQp8TWpBeE5pMHdPQT09IDUzODkxNiAyMDE2LTA4LTAxIDEzOjQ4OjU1CnxNakF4Tmkwd09BPT0gNTM4OTIxIDIwMTYtMDgtMDEgMTM6NTA6NTUKfE1qQXhOaTB3T0E9PSA1Mzg5MjYgMjAxNi0wOC0wMSAxMzo1Mjo1NQp8TWpBeE5pMHdPQT09IDUzODkzMSAyMDE2LTA4LTAxIDEzOjU0OjU1CnxNakF4Tmkwd09BPT0gNTM4OTM2IDIwMTYtMDgtMDEgMTM6NTY6NTUKfE1qQXhOaTB3T0E9PSA1Mzg5NDEgMjAxNi0wOC0wMSAxMzo1ODo1NQp8TWpBeE5pMHdPQT09IDUzODk0NiAyMDE2LTA4LTAxIDE0OjAwOjU1CnxNakF4Tmkwd09BPT0gNTM4OTUxIDIwMTYtMDgtMDEgMTQ6MDI6NTUKfE1qQXhOaTB3T0E9PSA1Mzg5NTYgMjAxNi0wOC0wMSAxNDowNDo1NQp8TWpBeE5pMHdPQT09IDUzODk2MSAyMDE2LTA4LTAxIDE0OjA2OjU1CnxNakF4Tmkwd09BPT0gNTM4OTY2IDIwMTYtMDgtMDEgMTQ6MDg6NTUKfE1qQXhOaTB3T0E9PSA1Mzg5NjkgMjAxNi0wOC0wMSAxNDoxMDozNQp8TWpBeE5pMHdPQT09IDUzODk3MCAyMDE2LTA4LTAxIDE0OjEyOjE1CnxNakF4Tmkwd09BPT0gNTM4OTcxIDIwMTYtMDgtMDEgMTQ6MTQ6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5NzIgMjAxNi0wOC0wMSAxNDoxODoxNQp8TWpBeE5pMHdPQT09IDUzODk3MyAyMDE2LTA4LTAxIDE0OjIyOjE1CnxNakF4Tmkwd09BPT0gNTM4OTc0IDIwMTYtMDgtMDEgMTQ6MjQ6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5NzUgMjAxNi0wOC0wMSAxNDoyODoxNQp8TWpBeE5pMHdPQT09IDUzODk3NiAyMDE2LTA4LTAxIDE0OjMwOjE1CnxNakF4Tmkwd09BPT0gNTM4OTc3IDIwMTYtMDgtMDEgMTQ6MzQ6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5NzggMjAxNi0wOC0wMSAxNDo0MDoxNQp8TWpBeE5pMHdPQT09IDUzODk3OSAyMDE2LTA4LTAxIDE0OjQyOjE1CnxNakF4Tmkwd09BPT0gNTM4OTgwIDIwMTYtMDgtMDEgMTQ6NDY6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5ODEgMjAxNi0wOC0wMSAxNDo0ODoxNQp8TWpBeE5pMHdPQT09IDUzODk4MiAyMDE2LTA4LTAxIDE0OjU0OjE1CnxNakF4Tmkwd09BPT0gNTM4OTgzIDIwMTYtMDgtMDEgMTQ6NTY6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5ODQgMjAxNi0wOC0wMSAxNTowMDoxNQp8TWpBeE5pMHdPQT09IDUzODk4NSAyMDE2LTA4LTAxIDE1OjAyOjE1CnxNakF4Tmkwd09BPT0gNTM4OTg2IDIwMTYtMDgtMDEgMTU6MDY6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5ODcgMjAxNi0wOC0wMSAxNToxMDoxNQp8TWpBeE5pMHdPQT09IDUzODk4OCAyMDE2LTA4LTAxIDE1OjE0OjE1CnxNakF4Tmkwd09BPT0gNTM4OTg5IDIwMTYtMDgtMDEgMTU6MTY6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5OTAgMjAxNi0wOC0wMSAxNToyMDoxNQp8TWpBeE5pMHdPQT09IDUzODk5MSAyMDE2LTA4LTAxIDE1OjI0OjE1CnxNakF4Tmkwd09BPT0gNTM4OTkyIDIwMTYtMDgtMDEgMTU6MjY6MTUKfE1qQXhOaTB3T0E9PSA1Mzg5OTMgMjAxNi0wOC0wMSAxNTozMDoxNQp8TWpBeE5pMHdPQT09IDUzODk5NCAyMDE2LTA4LTAxIDE1OjM0OjE1CnxNakF4Tmkwd09BPT0gNTM5MDI5IDIwMTYtMDgtMDEgMTc6MzY6MTQKfE1qQXhOaTB3T0E9PSA1MzkwMzAgMjAxNi0wOC0wMSAxNzozODoxNQp8TWpBeE5pMHdPQT09IDUzOTAzMSAyMDE2LTA4LTAxIDE3OjQwOjE1CnxNakF4Tmkwd09BPT0gNTM5MDM0IDIwMTYtMDgtMDEgMTc6NDI6MzUKfE1qQXhOaTB3T0E9PSA1MzkwMzcgMjAxNi0wOC0wMSAxNzo0MzozNQp8TWpBeE5pMHdPQT09IDUzOTA0NCAyMDE2LTA4LTAxIDE3OjQ1OjM0CnxNakF4Tmkwd09BPT0gNTM5MDUwIDIwMTYtMDgtMDEgMTc6NDc6MzUKfE1qQXhOaTB3T0E9PSA1MzkwNTcgMjAxNi0wOC0wMSAxNzo0OTozNQp8TWpBeE5pMHdPQT09IDUzOTA2NCAyMDE2LTA4LTAxIDE3OjUxOjM1CnxNakF4Tmkwd09BPT0gNTM5MDcxIDIwMTYtMDgtMDEgMTc6NTM6MzUKfE1qQXhOaTB3T0E9PSA1MzkwNzcgMjAxNi0wOC0wMSAxNzo1NTozNQp8TWpBeE5pMHdPQT09IDUzOTA4NCAyMDE2LTA4LTAxIDE3OjU3OjM1CnxNakF4Tmkwd09BPT0gNTM5MDkxIDIwMTYtMDgtMDEgMTc6NTk6MzUKfE1qQXhOaTB3T0E9PSA1MzkwOTcgMjAxNi0wOC0wMSAxODowMTozNQp8TWpBeE5pMHdPQT09IDUzOTEwNCAyMDE2LTA4LTAxIDE4OjAzOjM1CnxNakF4Tmkwd09BPT0gNTM5MTExIDIwMTYtMDgtMDEgMTg6MDU6MzUKfE1qQXhOaTB3T0E9PSA1MzkxMTcgMjAxNi0wOC0wMSAxODowNzozNQp8TWpBeE5pMHdPQT09IDUzOTEyNCAyMDE2LTA4LTAxIDE4OjA5OjM1CnxNakF4Tmkwd09BPT0gNTM5MTMwIDIwMTYtMDgtMDEgMTg6MTE6MzUKfE1qQXhOaTB3T0E9PSA1MzkxMzMgMjAxNi0wOC0wMSAxODoxMjozNQp8TWpBeE5pMHdPQT09IDUzOTEzNiAyMDE2LTA4LTAxIDE4OjEzOjM1CnxNakF4Tmkwd09BPT0gNTM5MTQzIDIwMTYtMDgtMDEgMTg6MTU6MzUKfE1qQXhOaTB3T0E9PSA1MzkxNDkgMjAxNi0wOC0wMSAxODoxNzozNQp8TWpBeE5pMHdPQT09IDUzOTE1MCAyMDE2LTA4LTAxIDE4OjE3OjQ1CnxNakF4Tmkwd09BPT0gNTM5MTU0IDIwMTYtMDgtMDEgMTg6MTk6MDUKfE1qQXhOaTB3T0E9PSA1MzkxNTcgMjAxNi0wOC0wMSAxODoyMDowNQp8TWpBeE5pMHdPQT09IDUzOTE2NCAyMDE2LTA4LTAxIDE4OjIyOjA1CnxNakF4Tmkwd09BPT0gNTM5MTcwIDIwMTYtMDgtMDEgMTg6MjQ6MDUKfE1qQXhOaTB3T0E9PSA1MzkxNzMgMjAxNi0wOC0wMSAxODoyNDo1NQp8TWpBeE5pMHdPQT09IDUzOTE3NiAyMDE2LTA4LTAxIDE4OjI1OjU1CnxNakF4Tmkwd09BPT0gNTM5MTgyIDIwMTYtMDgtMDEgMTg6Mjc6NTUKfE1qQXhOaTB3T0E9PSA1MzkxODMgMjAxNi0wOC0wMSAxODoyODoyNQp8TWpBeE5pMHdPQT09IDUzOTE4NyAyMDE2LTA4LTAxIDE4OjI5OjI1CnxNakF4Tmkwd09BPT0gNTM5MTkzIDIwMTYtMDgtMDEgMTg6MzE6MjUKfE1qQXhOaTB3T0E9PSA1MzkxOTYgMjAxNi0wOC0wMSAxODozMjoyNQp8TWpBeE5pMHdPQT09IDUzOTIwMCAyMDE2LTA4LTAxIDE4OjMzOjM1CnxNakF4Tmkwd09BPT0gNTM5MjA2IDIwMTYtMDgtMDEgMTg6MzU6MzUKfE1qQXhOaTB3T0E9PSA1MzkyMDcgMjAxNi0wOC0wMSAxODozNTo1NQp8TWpBeE5pMHdPQT09IDUzOTIxMyAyMDE2LTA4LTAxIDE4OjM3OjU1CnxNakF4Tmkwd09BPT0gNTM5MjE1IDIwMTYtMDgtMDEgMTg6Mzg6MzUKfE1qQXhOaTB3T0E9PSA1MzkyMTkgMjAxNi0wOC0wMSAxODozOTozNQp8TWpBeE5pMHdPQT09IDUzOTIyNSAyMDE2LTA4LTAxIDE4OjQxOjM1CnxNakF4Tmkwd09BPT0gNTM5MjMxIDIwMTYtMDgtMDEgMTg6NDM6MzUKfE1qQXhOaTB3T0E9PSA1MzkyMzcgMjAxNi0wOC0wMSAxODo0NTozNQp8TWpBeE5pMHdPQT09IDUzOTI0MiAyMDE2LTA4LTAxIDE4OjQ3OjE1CnxNakF4Tmkwd09BPT0gNTM5MjQ2IDIwMTYtMDgtMDEgMTg6NDg6MTUKfE1qQXhOaTB3T0E9PSA1MzkyNTIgMjAxNi0wOC0wMSAxODo1MDoxNQp8TWpBeE5pMHdPQT09IDUzOTI1OCAyMDE2LTA4LTAxIDE4OjUyOjE1CnxNakF4Tmkwd09BPT0gNTM5MjY0IDIwMTYtMDgtMDEgMTg6NTQ6MTUKfE1qQXhOaTB3T0E9PSA1MzkyNzEgMjAxNi0wOC0wMSAxODo1NjoxNQp8TWpBeE5pMHdPQT09IDUzOTI3MyAyMDE2LTA4LTAxIDE4OjU2OjU1CnxNakF4Tmkwd09BPT0gNTM5Mjc2IDIwMTYtMDgtMDEgMTg6NTc6NTUKfE1qQXhOaTB3T0E9PSA1MzkyODIgMjAxNi0wOC0wMSAxODo1OTo1NQp8TWpBeE5pMHdPQT09IDUzOTI4NSAyMDE2LTA4LTAxIDE5OjAxOjA1CnxNakF4Tmkwd09BPT0gNTM5Mjg4IDIwMTYtMDgtMDEgMTk6MDI6MDUKfE1qQXhOaTB3T0E9PSA1MzkyOTUgMjAxNi0wOC0wMSAxOTowNDowNQp8TWpBeE5pMHdPQT09IDUzOTMwMSAyMDE2LTA4LTAxIDE5OjA2OjA1CnxNakF4Tmkwd09BPT0gNTM5MzA3IDIwMTYtMDgtMDEgMTk6MDg6MDUKfE1qQXhOaTB3T0E9PSA1MzkzMDggMjAxNi0wOC0wMSAxOTowODoyNQp8TWpBeE5pMHdPQT09IDUzOTMxMSAyMDE2LTA4LTAxIDE5OjA5OjI1CnxNakF4Tmkwd09BPT0gNTM5MzE3IDIwMTYtMDgtMDEgMTk6MTE6MjUKfE1qQXhOaTB3T0E9PSA1MzkzMjIgMjAxNi0wOC0wMSAxOToxMjo1NQp8TWpBeE5pMHdPQT09IDUzOTMyOCAyMDE2LTA4LTAxIDE5OjE0OjU1CnxNakF4Tmkwd09BPT0gNTM5MzMwIDIwMTYtMDgtMDEgMTk6MTU6MzUKfE1qQXhOaTB3T0E9PSA1MzkzMzMgMjAxNi0wOC0wMSAxOToxNjozNQp8TWpBeE5pMHdPQT09IDUzOTMzOSAyMDE2LTA4LTAxIDE5OjE4OjM1CnxNakF4Tmkwd09BPT0gNTM5MzQyIDIwMTYtMDgtMDEgMTk6MTk6MzUKfE1qQXhOaTB3T0E9PSA1MzkzNDUgMjAxNi0wOC0wMSAxOToyMDo0NQp8TWpBeE5pMHdPQT09IDUzOTM1MiAyMDE2LTA4LTAxIDE5OjIyOjQ1CnxNakF4Tmkwd09BPT0gNTM5MzU0IDIwMTYtMDgtMDEgMTk6MjM6MjUKfE1qQXhOaTB3T0E9PSA1MzkzNTcgMjAxNi0wOC0wMSAxOToyNDoyNQp8TWpBeE5pMHdPQT09IDUzOTM2MSAyMDE2LTA4LTAxIDE5OjI1OjQ1CnxNakF4Tmkwd09BPT0gNTM5MzY0IDIwMTYtMDgtMDEgMTk6MjY6NDUKfE1qQXhOaTB3T0E9PSA1MzkzNzcgMjAxNi0wOC0wMSAxOTozMDo0NQp8TWpBeE5pMHdPQT09IDUzOTM4MyAyMDE2LTA4LTAxIDE5OjMyOjQ1CnxNakF4Tmkwd09BPT0gNTM5Mzg5IDIwMTYtMDgtMDEgMTk6MzQ6NDUKfE1qQXhOaTB3T0E9PSA1MzkzOTUgMjAxNi0wOC0wMSAxOTozNjo0NQp8TWpBeE5pMHdPQT09IDUzOTQwMSAyMDE2LTA4LTAxIDE5OjM4OjQ1CnxNakF4Tmkwd09BPT0gNTM5NDA4IDIwMTYtMDgtMDEgMTk6NDA6NDUKfE1qQXhOaTB3T0E9PSA1Mzk0MTQgMjAxNi0wOC0wMSAxOTo0Mjo0NQp8TWpBeE5pMHdPQT09IDUzOTQxNiAyMDE2LTA4LTAxIDE5OjQzOjM1CnxNakF4Tmkwd09BPT0gNTM5NDg4IDIwMTYtMDgtMDEgMjE6NDY6MDUKfE1qQXhOaTB3T0E9PSA1Mzk0ODkgMjAxNi0wOC0wMSAyMTo1MDowNQp8TWpBeE5pMHdPQT09IDUzOTQ5MCAyMDE2LTA4LTAxIDIxOjU0OjA1CnxNakF4Tmkwd09BPT0gNTM5NDkxIDIwMTYtMDgtMDEgMjE6NTg6MDUKfE1qQXhOaTB3T0E9PSA1Mzk0OTIgMjAxNi0wOC0wMSAyMjowMjowNQp8TWpBeE5pMHdPQT09IDUzOTQ5MyAyMDE2LTA4LTAxIDIyOjA4OjA1CnxNakF4Tmkwd09BPT0gNTM5NDk0IDIwMTYtMDgtMDEgMjI6MTI6MDUKfE1qQXhOaTB3T0E9PSA1Mzk0OTUgMjAxNi0wOC0wMSAyMjoxNjowNQp8TWpBeE5pMHdPQT09IDUzOTQ5NiAyMDE2LTA4LTAxIDIyOjIwOjA1CnxNakF4Tmkwd09BPT0gNTM5NDk3IDIwMTYtMDgtMDEgMjI6MjQ6MDUKfE1qQXhOaTB3T0E9PSA1Mzk0OTggMjAxNi0wOC0wMSAyMjoyODowNQp8TWpBeE5pMHdPQT09IDUzOTQ5OSAyMDE2LTA4LTAxIDIyOjMyOjA1CnxNakF4Tmkwd09BPT0gNTM5NTAwIDIwMTYtMDgtMDEgMjI6MzY6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MDEgMjAxNi0wOC0wMSAyMjo0MDowNQp8TWpBeE5pMHdPQT09IDUzOTUwMiAyMDE2LTA4LTAxIDIyOjQ0OjA1CnxNakF4Tmkwd09BPT0gNTM5NTAzIDIwMTYtMDgtMDEgMjI6NTA6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MDQgMjAxNi0wOC0wMSAyMjo1NDowNQp8TWpBeE5pMHdPQT09IDUzOTUwNSAyMDE2LTA4LTAxIDIyOjU4OjA1CnxNakF4Tmkwd09BPT0gNTM5NTA2IDIwMTYtMDgtMDEgMjM6MDI6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MDcgMjAxNi0wOC0wMSAyMzowNjowNQp8TWpBeE5pMHdPQT09IDUzOTUwOCAyMDE2LTA4LTAxIDIzOjEyOjA1CnxNakF4Tmkwd09BPT0gNTM5NTA5IDIwMTYtMDgtMDEgMjM6MTY6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MTAgMjAxNi0wOC0wMSAyMzoyMDowNQp8TWpBeE5pMHdPQT09IDUzOTUxMSAyMDE2LTA4LTAxIDIzOjI0OjA1CnxNakF4Tmkwd09BPT0gNTM5NTEyIDIwMTYtMDgtMDEgMjM6MzA6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MTMgMjAxNi0wOC0wMSAyMzozNDowNQp8TWpBeE5pMHdPQT09IDUzOTUxNCAyMDE2LTA4LTAxIDIzOjM4OjA1CnxNakF4Tmkwd09BPT0gNTM5NTE1IDIwMTYtMDgtMDEgMjM6NDI6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MTYgMjAxNi0wOC0wMSAyMzo0NjowNQp8TWpBeE5pMHdPQT09IDUzOTUxNyAyMDE2LTA4LTAxIDIzOjUwOjA1CnxNakF4Tmkwd09BPT0gNTM5NTE4IDIwMTYtMDgtMDEgMjM6NTQ6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MTkgMjAxNi0wOC0wMSAyMzo1ODowNQp8TWpBeE5pMHdPQT09IDUzOTUxOSAyMDE2LTA4LTAyIDAwOjAwOjAwCnxNakF4Tmkwd09BPT0gNTM5NTIwIDIwMTYtMDgtMDIgMDA6MDI6MDYKfE1qQXhOaTB3T0E9PSA1Mzk1MjEgMjAxNi0wOC0wMiAwMDowNjowNQp8TWpBeE5pMHdPQT09IDUzOTUyMiAyMDE2LTA4LTAyIDAwOjEwOjA1CnxNakF4Tmkwd09BPT0gNTM5NTIzIDIwMTYtMDgtMDIgMDA6MTY6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MjQgMjAxNi0wOC0wMiAwMDoyMDowNQp8TWpBeE5pMHdPQT09IDUzOTUyNSAyMDE2LTA4LTAyIDAwOjI0OjA1CnxNakF4Tmkwd09BPT0gNTM5NTI2IDIwMTYtMDgtMDIgMDA6Mjg6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MjcgMjAxNi0wOC0wMiAwMDozNDowNQp8TWpBeE5pMHdPQT09IDUzOTUyOCAyMDE2LTA4LTAyIDAwOjM4OjA1CnxNakF4Tmkwd09BPT0gNTM5NTI5IDIwMTYtMDgtMDIgMDA6NDI6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MzAgMjAxNi0wOC0wMiAwMDo0NjowNQp8TWpBeE5pMHdPQT09IDUzOTUzMSAyMDE2LTA4LTAyIDAwOjUwOjA1CnxNakF4Tmkwd09BPT0gNTM5NTMyIDIwMTYtMDgtMDIgMDA6NTQ6MDUKfE1qQXhOaTB3T0E9PSA1Mzk1MzMgMjAxNi0wOC0wMiAwMTowMDowNQp8TWpBeE5pMHdPQT09IDUzOTUzNCAyMDE2LTA4LTAyIDA2OjAyOjM1CnxNakF4Tmkwd09BPT0gNTM5NTM1IDIwMTYtMDgtMDIgMDY6MDQ6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1MzYgMjAxNi0wOC0wMiAwNjowODo0NQp8TWpBeE5pMHdPQT09IDUzOTUzNyAyMDE2LTA4LTAyIDA2OjE0OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTM4IDIwMTYtMDgtMDIgMDY6MTY6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1MzkgMjAxNi0wOC0wMiAwNjoyMDo0NQp8TWpBeE5pMHdPQT09IDUzOTU0MCAyMDE2LTA4LTAyIDA2OjI2OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTQxIDIwMTYtMDgtMDIgMDY6MzI6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NDIgMjAxNi0wOC0wMiAwNjozNDo0NQp8TWpBeE5pMHdPQT09IDUzOTU0MyAyMDE2LTA4LTAyIDA2OjM4OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTQ0IDIwMTYtMDgtMDIgMDY6NDI6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NDUgMjAxNi0wOC0wMiAwNjo0Njo0NQp8TWpBeE5pMHdPQT09IDUzOTU0NiAyMDE2LTA4LTAyIDA2OjUwOjQ1CnxNakF4Tmkwd09BPT0gNTM5NTQ3IDIwMTYtMDgtMDIgMDY6NTQ6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NDggMjAxNi0wOC0wMiAwNzowMDo0NQp8TWpBeE5pMHdPQT09IDUzOTU0OSAyMDE2LTA4LTAyIDA3OjA0OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTUwIDIwMTYtMDgtMDIgMDc6MDg6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NTEgMjAxNi0wOC0wMiAwNzoxMjo0NQp8TWpBeE5pMHdPQT09IDUzOTU1MiAyMDE2LTA4LTAyIDA3OjE4OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTUzIDIwMTYtMDgtMDIgMDc6MjI6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NTQgMjAxNi0wOC0wMiAwNzoyNjo0Ngp8TWpBeE5pMHdPQT09IDUzOTU1NSAyMDE2LTA4LTAyIDA3OjMwOjQ1CnxNakF4Tmkwd09BPT0gNTM5NTU2IDIwMTYtMDgtMDIgMDc6MzQ6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NTcgMjAxNi0wOC0wMiAwNzo0MDo0NQp8TWpBeE5pMHdPQT09IDUzOTU1OCAyMDE2LTA4LTAyIDA3OjQ0OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTU5IDIwMTYtMDgtMDIgMDc6NDg6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NjAgMjAxNi0wOC0wMiAwNzo1Mjo0NQp8TWpBeE5pMHdPQT09IDUzOTU2MSAyMDE2LTA4LTAyIDA3OjU2OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTYyIDIwMTYtMDgtMDIgMDg6MDA6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NjMgMjAxNi0wOC0wMiAwODowNDo0NQp8TWpBeE5pMHdPQT09IDUzOTU2NCAyMDE2LTA4LTAyIDA4OjA4OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTY1IDIwMTYtMDgtMDIgMDg6MTI6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NjYgMjAxNi0wOC0wMiAwODoxNjo0NQp8TWpBeE5pMHdPQT09IDUzOTU2NyAyMDE2LTA4LTAyIDA4OjIyOjQ1CnxNakF4Tmkwd09BPT0gNTM5NTY4IDIwMTYtMDgtMDIgMDg6MjY6NDUKfE1qQXhOaTB3T0E9PSA1Mzk1NjkgMjAxNi0wOC0wMiAwODozMDo0NQp8TWpBeE5pMHdPQT09IDUzOTU3MCAyMDE2LTA4LTAyIDA4OjM0OjQ1CnxNakF4Tmkwd09BPT0gNTM5NTcxIDIwMTYtMDgtMDIgMDg6Mzg6NDUKfE1qQXhOaTB3T0E9PSA1Mzk2NTUgMjAxNi0wOC0wMiAxMDo0MjoyNQp8TWpBeE5pMHdPQT09IDUzOTY2MSAyMDE2LTA4LTAyIDEwOjQ0OjI1CnxNakF4Tmkwd09BPT0gNTM5NjY3IDIwMTYtMDgtMDIgMTA6NDY6MjUKfE1qQXhOaTB3T0E9PSA1Mzk2NzMgMjAxNi0wOC0wMiAxMDo0ODowNQp8TWpBeE5pMHdPQT09IDUzOTY3NiAyMDE2LTA4LTAyIDEwOjQ5OjA1CnxNakF4Tmkwd09BPT0gNTM5NjgxIDIwMTYtMDgtMDIgMTA6NTA6MzUKfE1qQXhOaTB3T0E9PSA1Mzk2ODQgMjAxNi0wOC0wMiAxMDo1MTozNQp8TWpBeE5pMHdPQT09IDUzOTY5MSAyMDE2LTA4LTAyIDEwOjUzOjM1CnxNakF4Tmkwd09BPT0gNTQwMDE1IDIwMTYtMDgtMDIgMTI6NTU6MTUKfE1qQXhOaTB3T0E9PSA1NDAwMjAgMjAxNi0wOC0wMiAxMjo1NzoxNQp8TWpBeE5pMHdPQT09IDU0MDAyNSAyMDE2LTA4LTAyIDEyOjU5OjE1CnxNakF4Tmkwd09BPT0gNTQwMDMwIDIwMTYtMDgtMDIgMTM6MDE6MTUKfE1qQXhOaTB3T0E9PSA1NDAwMzUgMjAxNi0wOC0wMiAxMzowMzoxNQp8TWpBeE5pMHdPQT09IDU0MDA0MCAyMDE2LTA4LTAyIDEzOjA1OjE1CnxNakF4Tmkwd09BPT0gNTQwMDQ1IDIwMTYtMDgtMDIgMTM6MDc6MTUKfE1qQXhOaTB3T0E9PSA1NDAwNTAgMjAxNi0wOC0wMiAxMzowOToxNQp8TWpBeE5pMHdPQT09IDU0MDA1NSAyMDE2LTA4LTAyIDEzOjExOjE1CnxNakF4Tmkwd09BPT0gNTQwMDYwIDIwMTYtMDgtMDIgMTM6MTM6MTUKfE1qQXhOaTB3T0E9PSA1NDAwNjUgMjAxNi0wOC0wMiAxMzoxNToxNQp8TWpBeE5pMHdPQT09IDU0MDA3MCAyMDE2LTA4LTAyIDEzOjE3OjE1CnxNakF4Tmkwd09BPT0gNTQwMDc1IDIwMTYtMDgtMDIgMTM6MTk6MTUKfE1qQXhOaTB3T0E9PSA1NDAwODAgMjAxNi0wOC0wMiAxMzoyMToxNQp8TWpBeE5pMHdPQT09IDU0MDA4NSAyMDE2LTA4LTAyIDEzOjIzOjE1CnxNakF4Tmkwd09BPT0gNTQwMDkwIDIwMTYtMDgtMDIgMTM6MjU6MTUKfE1qQXhOaTB3T0E9PSA1NDAwOTUgMjAxNi0wOC0wMiAxMzoyNzoxNQp8TWpBeE5pMHdPQT09IDU0MDEwMCAyMDE2LTA4LTAyIDEzOjI5OjE1CnxNakF4Tmkwd09BPT0gNTQwMTA1IDIwMTYtMDgtMDIgMTM6MzE6MTUKfE1qQXhOaTB3T0E9PSA1NDAyMjkgMjAxNi0wOC0wMiAxNDoyMToxNQp8TWpBeE5pMHdPQT09IDU0MDIzNCAyMDE2LTA4LTAyIDE0OjIzOjE1CnxNakF4Tmkwd09BPT0gNTQwMjM5IDIwMTYtMDgtMDIgMTQ6MjU6MTUKfE1qQXhOaTB3T0E9PSA1NDAyNDQgMjAxNi0wOC0wMiAxNDoyNzoxNQp8TWpBeE5pMHdPQT09IDU0MDI0OSAyMDE2LTA4LTAyIDE0OjI5OjE1CnxNakF4Tmkwd09BPT0gNTQwMjU0IDIwMTYtMDgtMDIgMTQ6MzE6MTUKfE1qQXhOaTB3T0E9PSA1NDAyNTkgMjAxNi0wOC0wMiAxNDozMzoxNQp8TWpBeE5pMHdPQT09IDU0MDI2NCAyMDE2LTA4LTAyIDE0OjM1OjE1CnxNakF4Tmkwd09BPT0gNTQwMjY5IDIwMTYtMDgtMDIgMTQ6Mzc6MTUKfE1qQXhOaTB3T0E9PSA1NDAyNzQgMjAxNi0wOC0wMiAxNDozOToxNQp8TWpBeE5pMHdPQT09IDU0MDI3OSAyMDE2LTA4LTAyIDE0OjQxOjE1CnxNakF4Tmkwd09BPT0gNTQwMjgzIDIwMTYtMDgtMDIgMTQ6NDM6MTUKfE1qQXhOaTB3T0E9PSA1NDAyODggMjAxNi0wOC0wMiAxNDo0NToxNQp8TWpBeE5pMHdPQT09IDU0MDI5MyAyMDE2LTA4LTAyIDE0OjQ3OjE1CnxNakF4Tmkwd09BPT0gNTQwMjk4IDIwMTYtMDgtMDIgMTQ6NDk6MTUKfE1qQXhOaTB3T0E9PSA1NDAzMDMgMjAxNi0wOC0wMiAxNDo1MToxNQp8TWpBeE5pMHdPQT09IDU0MDMwOCAyMDE2LTA4LTAyIDE0OjUzOjE1CnxNakF4Tmkwd09BPT0gNTQwMzEzIDIwMTYtMDgtMDIgMTQ6NTU6MTUKfE1qQXhOaTB3T0E9PSA1NDAzMTggMjAxNi0wOC0wMiAxNDo1NzoxNQp8TWpBeE5pMHdPQT09IDU0MDMyMyAyMDE2LTA4LTAyIDE0OjU5OjE1CnxNakF4Tmkwd09BPT0gNTQwMzI4IDIwMTYtMDgtMDIgMTU6MDE6MTUKfE1qQXhOaTB3T0E9PSA1NDAzMzMgMjAxNi0wOC0wMiAxNTowMzoxNQp8TWpBeE5pMHdPQT09IDU0MDMzOCAyMDE2LTA4LTAyIDE1OjA1OjE1CnxNakF4Tmkwd09BPT0gNTQwMzQzIDIwMTYtMDgtMDIgMTU6MDc6MTUKfE1qQXhOaTB3T0E9PSA1NDAzNDggMjAxNi0wOC0wMiAxNTowOToxNQp8TWpBeE5pMHdPQT09IDU0MDM1MyAyMDE2LTA4LTAyIDE1OjExOjE1CnxNakF4Tmkwd09BPT0gNTQwMzU4IDIwMTYtMDgtMDIgMTU6MTM6MTUKfE1qQXhOaTB3T0E9PSA1NDAzNjMgMjAxNi0wOC0wMiAxNToxNToxNQp8TWpBeE5pMHdPQT09IDU0MDM2OCAyMDE2LTA4LTAyIDE1OjE3OjE1CnxNakF4Tmkwd09BPT0gNTQwMzczIDIwMTYtMDgtMDIgMTU6MTk6MTUKfE1qQXhOaTB3T0E9PSA1NDAzNzggMjAxNi0wOC0wMiAxNToyMToxNQp8TWpBeE5pMHdPQT09IDU0MDM4MiAyMDE2LTA4LTAyIDE1OjIzOjE1CnxNakF4Tmkwd09BPT0gNTQwMzg3IDIwMTYtMDgtMDIgMTU6MjU6MTUKfE1qQXhOaTB3T0E9PSA1NDAzOTIgMjAxNi0wOC0wMiAxNToyNzoxNQp8TWpBeE5pMHdPQT09IDU0MDM5NyAyMDE2LTA4LTAyIDE1OjI5OjE1CnxNakF4Tmkwd09BPT0gNTQwNDAyIDIwMTYtMDgtMDIgMTU6MzE6MTUKfE1qQXhOaTB3T0E9PSA1NDA0MDcgMjAxNi0wOC0wMiAxNTozMzoxNQp8TWpBeE5pMHdPQT09IDU0MDQxMiAyMDE2LTA4LTAyIDE1OjM1OjE1CnxNakF4Tmkwd09BPT0gNTQwNDE3IDIwMTYtMDgtMDIgMTU6Mzc6MTUKfE1qQXhOaTB3T0E9PSA1NDA0MjIgMjAxNi0wOC0wMiAxNTozOToxNQp8TWpBeE5pMHdPQT09IDU0MDQyNyAyMDE2LTA4LTAyIDE1OjQxOjE1CnxNakF4Tmkwd09BPT0gNTQwNDMyIDIwMTYtMDgtMDIgMTU6NDM6MTUKfE1qQXhOaTB3T0E9PSA1NDA0MzcgMjAxNi0wOC0wMiAxNTo0NToxNQp8TWpBeE5pMHdPQT09IDU0MDQ0MiAyMDE2LTA4LTAyIDE1OjQ3OjE1CnxNakF4Tmkwd09BPT0gNTQwNDQ3IDIwMTYtMDgtMDIgMTU6NDk6MTUKfE1qQXhOaTB3T0E9PSA1NDA0NTIgMjAxNi0wOC0wMiAxNTo1MToxNQp8TWpBeE5pMHdPQT09IDU0MDQ1NyAyMDE2LTA4LTAyIDE1OjUzOjE1CnxNakF4Tmkwd09BPT0gNTQwNDYyIDIwMTYtMDgtMDIgMTU6NTU6MTUKfE1qQXhOaTB3T0E9PSA1NDA0NjcgMjAxNi0wOC0wMiAxNTo1NzoxNQp8TWpBeE5pMHdPQT09IDU0MDQ3MiAyMDE2LTA4LTAyIDE1OjU5OjE1CnxNakF4Tmkwd09BPT0gNTQwNDc3IDIwMTYtMDgtMDIgMTY6MDE6MTUKfE1qQXhOaTB3T0E9PSA1NDA0ODIgMjAxNi0wOC0wMiAxNjowMzoxNQp8TWpBeE5pMHdPQT09IDU0MDQ4NyAyMDE2LTA4LTAyIDE2OjA1OjE1CnxNakF4Tmkwd09BPT0gNTQwNDkyIDIwMTYtMDgtMDIgMTY6MDc6MTUKfE1qQXhOaTB3T0E9PSA1NDA0OTcgMjAxNi0wOC0wMiAxNjowOToxNQp8TWpBeE5pMHdPQT09IDU0MDUwMiAyMDE2LTA4LTAyIDE2OjExOjE1CnxNakF4Tmkwd09BPT0gNTQwNTA3IDIwMTYtMDgtMDIgMTY6MTM6MTUKfE1qQXhOaTB3T0E9PSA1NDA1MTIgMjAxNi0wOC0wMiAxNjoxNToxNQp8TWpBeE5pMHdPQT09IDU0MDUxNyAyMDE2LTA4LTAyIDE2OjE3OjE1CnxNakF4Tmkwd09BPT0gNTQwNTIyIDIwMTYtMDgtMDIgMTY6MTk6MTUKfE1qQXhOaTB3T0E9PSA1NDA1MjcgMjAxNi0wOC0wMiAxNjoyMToxNQp8TWpBeE5pMHdPQT09IDU0MDg5NiAyMDE2LTA4LTAyIDE4OjI0OjA1CnxNakF4Tmkwd09BPT0gNTQwOTAxIDIwMTYtMDgtMDIgMTg6MjY6MDUKfE1qQXhOaTB3T0E9PSA1NDA5MTQgMjAxNi0wOC0wMiAxODozMDowNQp8TWpBeE5pMHdPQT09IDU0MDkyMCAyMDE2LTA4LTAyIDE4OjMyOjA2CnxNakF4Tmkwd09BPT0gNTQwOTI2IDIwMTYtMDgtMDIgMTg6MzQ6MDUKfE1qQXhOaTB3T0E9PSA1NDA5MzIgMjAxNi0wOC0wMiAxODozNjowNQp8TWpBeE5pMHdPQT09IDU0MDkzOCAyMDE2LTA4LTAyIDE4OjM4OjA1CnxNakF4Tmkwd09BPT0gNTQwOTQ0IDIwMTYtMDgtMDIgMTg6NDA6MDUKfE1qQXhOaTB3T0E9PSA1NDA5NTAgMjAxNi0wOC0wMiAxODo0MjowNwp8TWpBeE5pMHdPQT09IDU0MDk1NiAyMDE2LTA4LTAyIDE4OjQ0OjA1CnxNakF4Tmkwd09BPT0gNTQwOTYyIDIwMTYtMDgtMDIgMTg6NDY6MDUKfE1qQXhOaTB3T0E9PSA1NDA5NjkgMjAxNi0wOC0wMiAxODo0ODowNQp8TWpBeE5pMHdPQT09IDU0MDk3NSAyMDE2LTA4LTAyIDE4OjUwOjA1CnxNakF4Tmkwd09BPT0gNTQwOTgxIDIwMTYtMDgtMDIgMTg6NTI6MDYKfE1qQXhOaTB3T0E9PSA1NDA5ODcgMjAxNi0wOC0wMiAxODo1NDowNQp8TWpBeE5pMHdPQT09IDU0MDk5MyAyMDE2LTA4LTAyIDE4OjU2OjA1CnxNakF4Tmkwd09BPT0gNTQwOTk5IDIwMTYtMDgtMDIgMTg6NTg6MDUKfE1qQXhOaTB3T0E9PSA1NDEwMDUgMjAxNi0wOC0wMiAxOTowMDowNQp8TWpBeE5pMHdPQT09IDU0MTAxMSAyMDE2LTA4LTAyIDE5OjAyOjA3CnxNakF4Tmkwd09BPT0gNTQxMDE3IDIwMTYtMDgtMDIgMTk6MDQ6MDUKfE1qQXhOaTB3T0E9PSA1NDEwMjMgMjAxNi0wOC0wMiAxOTowNjowNQp8TWpBeE5pMHdPQT09IDU0MTAyOSAyMDE2LTA4LTAyIDE5OjA4OjA1CnxNakF4Tmkwd09BPT0gNTQxMDM1IDIwMTYtMDgtMDIgMTk6MTA6MDUKfE1qQXhOaTB3T0E9PSA1NDEwNDEgMjAxNi0wOC0wMiAxOToxMjowNwp8TWpBeE5pMHdPQT09IDU0MTA0NyAyMDE2LTA4LTAyIDE5OjE0OjA1CnxNakF4Tmkwd09BPT0gNTQxMDUzIDIwMTYtMDgtMDIgMTk6MTY6MDUKfE1qQXhOaTB3T0E9PSA1NDEwNTkgMjAxNi0wOC0wMiAxOToxODowNQp8TWpBeE5pMHdPQT09IDU0MTA2NSAyMDE2LTA4LTAyIDE5OjIwOjA1CnxNakF4Tmkwd09BPT0gNTQxMDcxIDIwMTYtMDgtMDIgMTk6MjI6MDUKfE1qQXhOaTB3T0E9PSA1NDEwNzcgMjAxNi0wOC0wMiAxOToyNDowNQp8TWpBeE5pMHdPQT09IDU0MTA4MiAyMDE2LTA4LTAyIDE5OjI2OjA1CnxNakF4Tmkwd09BPT0gNTQxMDgzIDIwMTYtMDgtMDIgMTk6Mjg6MDUKfE1qQXhOaTB3T0E9PSA1NDEwODQgMjAxNi0wOC0wMiAxOTozMDowNQp8TWpBeE5pMHdPQT09IDU0MTA4NSAyMDE2LTA4LTAyIDE5OjM0OjA1CnxNakF4Tmkwd09BPT0gNTQxMDg2IDIwMTYtMDgtMDIgMTk6MzY6MDUKfE1qQXhOaTB3T0E9PSA1NDEwODcgMjAxNi0wOC0wMiAxOTo0MDowNQp8TWpBeE5pMHdPQT09IDU0MTA4OCAyMDE2LTA4LTAyIDE5OjQ0OjA1CnxNakF4Tmkwd09BPT0gNTQxMDg5IDIwMTYtMDgtMDIgMTk6NDg6MDUKfE1qQXhOaTB3T0E9PSA1NDEwOTAgMjAxNi0wOC0wMiAxOTo1MjowNgp8TWpBeE5pMHdPQT09IDU0MTA5MSAyMDE2LTA4LTAyIDE5OjU0OjA1CnxNakF4Tmkwd09BPT0gNTQxMDkyIDIwMTYtMDgtMDIgMjA6MDA6MDUKfE1qQXhOaTB3T0E9PSA1NDEwOTMgMjAxNi0wOC0wMiAyMDowNDowNQp8TWpBeE5pMHdPQT09IDU0MTA5NCAyMDE2LTA4LTAyIDIwOjA4OjA1CnxNakF4Tmkwd09BPT0gNTQxMDk1IDIwMTYtMDgtMDIgMjA6MTI6MDYKfE1qQXhOaTB3T0E9PSA1NDEwOTYgMjAxNi0wOC0wMiAyMDoxNjowNQp8TWpBeE5pMHdPQT09IDU0MTA5NyAyMDE2LTA4LTAyIDIwOjIyOjA2CnxNakF4Tmkwd09BPT0gNTQxMDk4IDIwMTYtMDgtMDIgMjA6MjY6MDUKfE1qQXhOaTB3T0E9PSA1NDExMjcgMjAxNi0wOC0wMiAyMjozMDowNQp8TWpBeE5pMHdPQT09IDU0MTEyOCAyMDE2LTA4LTAyIDIyOjM0OjA1CnxNakF4Tmkwd09BPT0gNTQxMTI5IDIwMTYtMDgtMDIgMjI6Mzg6MDUKfE1qQXhOaTB3T0E9PSA1NDExMzAgMjAxNi0wOC0wMiAyMjo0MjowNwp8TWpBeE5pMHdPQT09IDU0MTEzMSAyMDE2LTA4LTAyIDIyOjQ2OjA1CnxNakF4Tmkwd09BPT0gNTQxMTM0IDIwMTYtMDgtMDIgMjM6MDI6MDUKfE1qQXhOaTB3T0E9PSA1NDExMzQgMjAxNi0wOC0wMyAwMDowMDowMAp8TWpBeE5pMHdPQT09IDU0MTE1NSAyMDE2LTA4LTAzIDA3OjI2OjExCnxNakF4Tmkwd09BPT0gNTQxMTU2IDIwMTYtMDgtMDMgMDc6MzA6MTEKfE1qQXhOaTB3T0E9PSA1NDExNTcgMjAxNi0wOC0wMyAwNzozNDoxMQp8TWpBeE5pMHdPQT09IDU0MTE1OCAyMDE2LTA4LTAzIDA3OjQwOjExCnxNakF4Tmkwd09BPT0gNTQxMTU5IDIwMTYtMDgtMDMgMDc6NDQ6MTEKfE1qQXhOaTB3T0E9PSA1NDExNjAgMjAxNi0wOC0wMyAwNzo0ODoxMQp8TWpBeE5pMHdPQT09IDU0MTE2MSAyMDE2LTA4LTAzIDA3OjUyOjExCnxNakF4Tmkwd09BPT0gNTQxMTYyIDIwMTYtMDgtMDMgMDc6NTg6MTEKfE1qQXhOaTB3T0E9PSA1NDExNjMgMjAxNi0wOC0wMyAwODowMjoxMQp8TWpBeE5pMHdPQT09IDU0MTE2NCAyMDE2LTA4LTAzIDA4OjA2OjExCnxNakF4Tmkwd09BPT0gNTQxMTY1IDIwMTYtMDgtMDMgMDg6MTA6MTEKfE1qQXhOaTB3T0E9PSA1NDExNjYgMjAxNi0wOC0wMyAwODoxNDoxMQp8TWpBeE5pMHdPQT09IDU0MTE2NyAyMDE2LTA4LTAzIDA4OjIwOjExCnxNakF4Tmkwd09BPT0gNTQxMTY4IDIwMTYtMDgtMDMgMDg6MjQ6MTEKfE1qQXhOaTB3T0E9PSA1NDExNjkgMjAxNi0wOC0wMyAwODoyODoxMQp8TWpBeE5pMHdPQT09IDU0MTE3MCAyMDE2LTA4LTAzIDA4OjMyOjExCnxNakF4Tmkwd09BPT0gNTQxMTcxIDIwMTYtMDgtMDMgMDg6MzY6MTEKfE1qQXhOaTB3T0E9PSA1NDExNzIgMjAxNi0wOC0wMyAwODo0MDoxMQp8TWpBeE5pMHdPQT09IDU0MTE3MyAyMDE2LTA4LTAzIDA4OjQ2OjExCnxNakF4Tmkwd09BPT0gNTQxMTc0IDIwMTYtMDgtMDMgMDg6NTA6MTEKfE1qQXhOaTB3T0E9PSA1NDExNzUgMjAxNi0wOC0wMyAwODo1NDoxMQp8TWpBeE5pMHdPQT09IDU0MTE3NiAyMDE2LTA4LTAzIDA4OjU4OjExCnxNakF4Tmkwd09BPT0gNTQxMTc3IDIwMTYtMDgtMDMgMDk6MDI6MTEKfE1qQXhOaTB3T0E9PSA1NDExNzggMjAxNi0wOC0wMyAwOTowNjoxMQp8TWpBeE5pMHdPQT09IDU0MTE3OSAyMDE2LTA4LTAzIDA5OjEwOjExCnxNakF4Tmkwd09BPT0gNTQxMTgyIDIwMTYtMDgtMDMgMDk6MTQ6MjEKfE1qQXhOaTB3T0E9PSA1NDExODYgMjAxNi0wOC0wMyAwOToxNToyMQp8TWpBeE5pMHdPQT09IDU0MTE5MiAyMDE2LTA4LTAzIDA5OjE3OjIxCnxNakF4Tmkwd09BPT0gNTQxMTk0IDIwMTYtMDgtMDMgMDk6MTg6MDEKfE1qQXhOaTB3T0E9PSA1NDExOTcgMjAxNi0wOC0wMyAwOToxOTowMQp8TWpBeE5pMHdPQT09IDU0MTIwMyAyMDE2LTA4LTAzIDA5OjIwOjMxCnxNakF4Tmkwd09BPT0gNTQxMjA2IDIwMTYtMDgtMDMgMDk6MjE6MzMKfE1qQXhOaTB3T0E9PSA1NDEyMTMgMjAxNi0wOC0wMyAwOToyMzozMQp8TWpBeE5pMHdPQT09IDU0MTIyMCAyMDE2LTA4LTAzIDA5OjI1OjMxCnxNakF4Tmkwd09BPT0gNTQxMjI0IDIwMTYtMDgtMDMgMDk6MjY6NDEKfE1qQXhOaTB3T0E9PSA1NDEyMjcgMjAxNi0wOC0wMyAwOToyNzo0MQp8TWpBeE5pMHdPQT09IDU0MTIzNCAyMDE2LTA4LTAzIDA5OjI5OjQxCnxNakF4Tmkwd09BPT0gNTQxMjM3IDIwMTYtMDgtMDMgMDk6MzA6NTEKfE1qQXhOaTB3T0E9PSA1NDEyNDEgMjAxNi0wOC0wMyAwOTozMTo1MQp8TWpBeE5pMHdPQT09IDU0MTI0NyAyMDE2LTA4LTAzIDA5OjMzOjUxCnxNakF4Tmkwd09BPT0gNTQxMjU0IDIwMTYtMDgtMDMgMDk6MzU6NTEKfE1qQXhOaTB3T0E9PSA1NDEyNjEgMjAxNi0wOC0wMyAwOTozNzo1MQp8TWpBeE5pMHdPQT09IDU0MTI2NSAyMDE2LTA4LTAzIDA5OjM5OjIxCnxNakF4Tmkwd09BPT0gNTQxMjY4IDIwMTYtMDgtMDMgMDk6NDA6MjEKfE1qQXhOaTB3T0E9PSA1NDEyNzIgMjAxNi0wOC0wMyAwOTo0MTozNAp8TWpBeE5pMHdPQT09IDU0MTMzOSAyMDE2LTA4LTAzIDExOjQzOjUxCnxNakF4Tmkwd09BPT0gNTQxMzQwIDIwMTYtMDgtMDMgMTE6NDc6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNDEgMjAxNi0wOC0wMyAxMTo1MTo1MQp8TWpBeE5pMHdPQT09IDU0MTM0MiAyMDE2LTA4LTAzIDExOjU1OjUxCnxNakF4Tmkwd09BPT0gNTQxMzQzIDIwMTYtMDgtMDMgMTE6NTk6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNDQgMjAxNi0wOC0wMyAxMjowMzo1MQp8TWpBeE5pMHdPQT09IDU0MTM0NSAyMDE2LTA4LTAzIDEyOjA3OjUxCnxNakF4Tmkwd09BPT0gNTQxMzQ2IDIwMTYtMDgtMDMgMTI6MTE6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNDcgMjAxNi0wOC0wMyAxMjoxNzo1MQp8TWpBeE5pMHdPQT09IDU0MTM0OCAyMDE2LTA4LTAzIDEyOjIxOjUxCnxNakF4Tmkwd09BPT0gNTQxMzQ5IDIwMTYtMDgtMDMgMTI6MjU6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNTAgMjAxNi0wOC0wMyAxMjoyOTo1MQp8TWpBeE5pMHdPQT09IDU0MTM1MSAyMDE2LTA4LTAzIDEyOjMzOjUxCnxNakF4Tmkwd09BPT0gNTQxMzUyIDIwMTYtMDgtMDMgMTI6Mzc6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNTMgMjAxNi0wOC0wMyAxMjo0Mzo1MQp8TWpBeE5pMHdPQT09IDU0MTM1NCAyMDE2LTA4LTAzIDEyOjQ3OjUxCnxNakF4Tmkwd09BPT0gNTQxMzU1IDIwMTYtMDgtMDMgMTI6NTE6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNTYgMjAxNi0wOC0wMyAxMjo1NTo1MQp8TWpBeE5pMHdPQT09IDU0MTM1NyAyMDE2LTA4LTAzIDEzOjAxOjUxCnxNakF4Tmkwd09BPT0gNTQxMzU4IDIwMTYtMDgtMDMgMTM6MDU6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNTkgMjAxNi0wOC0wMyAxMzowOTo1MQp8TWpBeE5pMHdPQT09IDU0MTM2MCAyMDE2LTA4LTAzIDEzOjEzOjUxCnxNakF4Tmkwd09BPT0gNTQxMzYxIDIwMTYtMDgtMDMgMTM6MTc6NTEKfE1qQXhOaTB3T0E9PSA1NDEzNjIgMjAxNi0wOC0wMyAxMzoyMTo1MQp8TWpBeE5pMHdPQT09IDU0MTM2MyAyMDE2LTA4LTAzIDEzOjI1OjUxCnxNakF4Tmkwd09BPT0gNTQxMzkyIDIwMTYtMDgtMDMgMTU6Mjk6NTEKfE1qQXhOaTB3T0E9PSA1NDEzOTMgMjAxNi0wOC0wMyAxNTozNTo1MQp8TWpBeE5pMHdPQT09IDU0MTM5NCAyMDE2LTA4LTAzIDE1OjM5OjUxCnxNakF4Tmkwd09BPT0gNTQxMzk1IDIwMTYtMDgtMDMgMTU6NDM6NTEKfE1qQXhOaTB3T0E9PSA1NDEzOTYgMjAxNi0wOC0wMyAxNTo0Nzo1MQp8TWpBeE5pMHdPQT09IDU0MTM5NyAyMDE2LTA4LTAzIDE1OjUxOjUxCnxNakF4Tmkwd09BPT0gNTQxMzk4IDIwMTYtMDgtMDMgMTU6NTc6NTEKfE1qQXhOaTB3T0E9PSA1NDEzOTkgMjAxNi0wOC0wMyAxNjowMTo1MQp8TWpBeE5pMHdPQT09IDU0MTQwMCAyMDE2LTA4LTAzIDE2OjA1OjUxCnxNakF4Tmkwd09BPT0gNTQxNDAxIDIwMTYtMDgtMDMgMTY6MDk6NTEKfE1qQXhOaTB3T0E9PSA1NDE0MDIgMjAxNi0wOC0wMyAxNjoxMzo1MQp8TWpBeE5pMHdPQT09IDU0MTQwMyAyMDE2LTA4LTAzIDE2OjE3OjUxCnxNakF4Tmkwd09BPT0gNTQxNDA0IDIwMTYtMDgtMDMgMTY6MjE6NTEKfE1qQXhOaTB3T0E9PSA1NDE0MDUgMjAxNi0wOC0wMyAxNjoyNTo1MQp8TWpBeE5pMHdPQT09IDU0MTQwNiAyMDE2LTA4LTAzIDE2OjI5OjUxCnxNakF4Tmkwd09BPT0gNTQxNDA3IDIwMTYtMDgtMDMgMTY6MzE6NTEKfE1qQXhOaTB3T0E9PSA1NDE0MDkgMjAxNi0wOC0wMyAxNjozNTozMQp8TWpBeE5pMHdPQT09IDU0MTQxNCAyMDE2LTA4LTAzIDE2OjM3OjMxCnxNakF4Tmkwd09BPT0gNTQxNDE5IDIwMTYtMDgtMDMgMTY6Mzk6MzEKfE1qQXhOaTB3T0E9PSA1NDE0MjMgMjAxNi0wOC0wMyAxNjo0MTozNQp8TWpBeE5pMHdPQT09IDU0MTQyOCAyMDE2LTA4LTAzIDE2OjQzOjMxCnxNakF4Tmkwd09BPT0gNTQxNDMzIDIwMTYtMDgtMDMgMTY6NDU6MzEKfE1qQXhOaTB3T0E9PSA1NDE0MzggMjAxNi0wOC0wMyAxNjo0NzozMQp8TWpBeE5pMHdPQT09IDU0MTQ0MyAyMDE2LTA4LTAzIDE2OjQ5OjMxCnxNakF4Tmkwd09BPT0gNTQxNDQ4IDIwMTYtMDgtMDMgMTY6NTE6MzEKfE1qQXhOaTB3T0E9PSA1NDE0NTIgMjAxNi0wOC0wMyAxNjo1MzozMQp8TWpBeE5pMHdPQT09IDU0MTQ1NyAyMDE2LTA4LTAzIDE2OjU1OjMxCnxNakF4Tmkwd09BPT0gNTQxNDYyIDIwMTYtMDgtMDMgMTY6NTc6MzEKfE1qQXhOaTB3T0E9PSA1NDE0NjcgMjAxNi0wOC0wMyAxNjo1OTozMQp8TWpBeE5pMHdPQT09IDU0MTQ3MiAyMDE2LTA4LTAzIDE3OjAxOjM0CnxNakF4Tmkwd09BPT0gNTQxNDc3IDIwMTYtMDgtMDMgMTc6MDM6MzEKfE1qQXhOaTB3T0E9PSA1NDE0ODIgMjAxNi0wOC0wMyAxNzowNTozMQp8TWpBeE5pMHdPQT09IDU0MTQ4NyAyMDE2LTA4LTAzIDE3OjA3OjMxCnxNakF4Tmkwd09BPT0gNTQxNDkyIDIwMTYtMDgtMDMgMTc6MDk6MzEKfE1qQXhOaTB3T0E9PSA1NDE0OTYgMjAxNi0wOC0wMyAxNzoxMTozNQp8TWpBeE5pMHdPQT09IDU0MTUwMiAyMDE2LTA4LTAzIDE3OjEzOjMxCnxNakF4Tmkwd09BPT0gNTQxNTA3IDIwMTYtMDgtMDMgMTc6MTU6MzEKfE1qQXhOaTB3T0E9PSA1NDE1MTEgMjAxNi0wOC0wMyAxNzoxNzozMQp8TWpBeE5pMHdPQT09IDU0MTUxNiAyMDE2LTA4LTAzIDE3OjE5OjMxCnxNakF4Tmkwd09BPT0gNTQxNTIxIDIwMTYtMDgtMDMgMTc6MjE6MzQKfE1qQXhOaTB3T0E9PSA1NDE1MjYgMjAxNi0wOC0wMyAxNzoyMzozMQp8TWpBeE5pMHdPQT09IDU0MTUzMSAyMDE2LTA4LTAzIDE3OjI1OjMxCnxNakF4Tmkwd09BPT0gNTQxNTM2IDIwMTYtMDgtMDMgMTc6Mjc6MzEKfE1qQXhOaTB3T0E9PSA1NDE1NDEgMjAxNi0wOC0wMyAxNzoyOTozMQp8TWpBeE5pMHdPQT09IDU0MTU0NSAyMDE2LTA4LTAzIDE3OjMxOjMxCnxNakF4Tmkwd09BPT0gNTQxNTUwIDIwMTYtMDgtMDMgMTc6MzM6MzEKfE1qQXhOaTB3T0E9PSA1NDE1NTUgMjAxNi0wOC0wMyAxNzozNTozMQp8TWpBeE5pMHdPQT09IDU0MTU2MCAyMDE2LTA4LTAzIDE3OjM3OjMxCnxNakF4Tmkwd09BPT0gNTQxNTY1IDIwMTYtMDgtMDMgMTc6Mzk6MzEKfE1qQXhOaTB3T0E9PSA1NDE1NzAgMjAxNi0wOC0wMyAxNzo0MTozMgp8TWpBeE5pMHdPQT09IDU0MTU3NSAyMDE2LTA4LTAzIDE3OjQzOjMxCnxNakF4Tmkwd09BPT0gNTQxNTgwIDIwMTYtMDgtMDMgMTc6NDU6MzEKfE1qQXhOaTB3T0E9PSA1NDE1ODQgMjAxNi0wOC0wMyAxNzo0NzozMQp8TWpBeE5pMHdPQT09IDU0MTU4OSAyMDE2LTA4LTAzIDE3OjQ5OjMxCnxNakF4Tmkwd09BPT0gNTQxNTk0IDIwMTYtMDgtMDMgMTc6NTE6MzIKfE1qQXhOaTB3T0E9PSA1NDE1OTkgMjAxNi0wOC0wMyAxNzo1MzozMQp8TWpBeE5pMHdPQT09IDU0MTYwNCAyMDE2LTA4LTAzIDE3OjU1OjMxCnxNakF4Tmkwd09BPT0gNTQxNjA5IDIwMTYtMDgtMDMgMTc6NTc6MzEKfE1qQXhOaTB3T0E9PSA1NDE2MTQgMjAxNi0wOC0wMyAxNzo1OTozMQp8TWpBeE5pMHdPQT09IDU0MTYxOSAyMDE2LTA4LTAzIDE4OjAxOjM0CnxNakF4Tmkwd09BPT0gNTQxNjIzIDIwMTYtMDgtMDMgMTg6MDM6MzEKfE1qQXhOaTB3T0E9PSA1NDE2MjggMjAxNi0wOC0wMyAxODowNTozMQp8TWpBeE5pMHdPQT09IDU0MTYzMyAyMDE2LTA4LTAzIDE4OjA3OjMxCnxNakF4Tmkwd09BPT0gNTQxNjM4IDIwMTYtMDgtMDMgMTg6MDk6MzEKfE1qQXhOaTB3T0E9PSA1NDE2NDEgMjAxNi0wOC0wMyAxODoxMDo1MQp8TWpBeE5pMHdPQT09IDU0MTY0NyAyMDE2LTA4LTAzIDE4OjEyOjUxCnxNakF4Tmkwd09BPT0gNTQxNjUwIDIwMTYtMDgtMDMgMTg6MTQ6MDEKfE1qQXhOaTB3T0E9PSA1NDE2NTYgMjAxNi0wOC0wMyAxODoxNjowMQp8TWpBeE5pMHdPQT09IDU0MTY2MSAyMDE2LTA4LTAzIDE4OjE3OjQxCnxNakF4Tmkwd09BPT0gNTQxNjYzIDIwMTYtMDgtMDMgMTg6MTg6NDEKfE1qQXhOaTB3T0E9PSA1NDE2NjkgMjAxNi0wOC0wMyAxODoyMDo0MQp8TWpBeE5pMHdPQT09IDU0MTY3NCAyMDE2LTA4LTAzIDE4OjIyOjQxCnxNakF4Tmkwd09BPT0gNTQxNjgwIDIwMTYtMDgtMDMgMTg6MjQ6NDEKfE1qQXhOaTB3T0E9PSA1NDE2ODYgMjAxNi0wOC0wMyAxODoyNjo0MQp8TWpBeE5pMHdPQT09IDU0MTY5MSAyMDE2LTA4LTAzIDE4OjI4OjQxCnxNakF4Tmkwd09BPT0gNTQxNjk2IDIwMTYtMDgtMDMgMTg6MzA6NDEKfE1qQXhOaTB3T0E9PSA1NDE3MDIgMjAxNi0wOC0wMyAxODozMjo0MQp8TWpBeE5pMHdPQT09IDU0MTcwNyAyMDE2LTA4LTAzIDE4OjM0OjQxCnxNakF4Tmkwd09BPT0gNTQxNzA5IDIwMTYtMDgtMDMgMTg6MzU6MTEKfE1qQXhOaTB3T0E9PSA1NDE3MTIgMjAxNi0wOC0wMyAxODozNjoxMQp8TWpBeE5pMHdPQT09IDU0MTcxNSAyMDE2LTA4LTAzIDE4OjM3OjIxCnxNakF4Tmkwd09BPT0gNTQxNzE4IDIwMTYtMDgtMDMgMTg6Mzg6MzEKfE1qQXhOaTB3T0E9PSA1NDE3MjEgMjAxNi0wOC0wMyAxODozOTozMQp8TWpBeE5pMHdPQT09IDU0MTcyNiAyMDE2LTA4LTAzIDE4OjQxOjMxCnxNakF4Tmkwd09BPT0gNTQxNzMxIDIwMTYtMDgtMDMgMTg6NDM6MzEKfE1qQXhOaTB3T0E9PSA1NDE3MzMgMjAxNi0wOC0wMyAxODo0NDoxMQp8TWpBeE5pMHdPQT09IDU0MTczNiAyMDE2LTA4LTAzIDE4OjQ1OjExCnxNakF4Tmkwd09BPT0gNTQxNzQxIDIwMTYtMDgtMDMgMTg6NDY6NTEKfE1qQXhOaTB3T0E9PSA1NDE3NDMgMjAxNi0wOC0wMyAxODo0Nzo1MQp8TWpBeE5pMHdPQT09IDU0MTc0OCAyMDE2LTA4LTAzIDE4OjQ5OjUxCnxNakF4Tmkwd09BPT0gNTQxNzU0IDIwMTYtMDgtMDMgMTg6NTE6NTEKfE1qQXhOaTB3T0E9PSA1NDE3NTcgMjAxNi0wOC0wMyAxODo1MzowMQp8TWpBeE5pMHdPQT09IDU0MTc2MCAyMDE2LTA4LTAzIDE4OjU0OjAxCnxNakF4Tmkwd09BPT0gNTQxNzYyIDIwMTYtMDgtMDMgMTg6NTU6MDEKfE1qQXhOaTB3T0E9PSA1NDE3NjUgMjAxNi0wOC0wMyAxODo1NjowMQp8TWpBeE5pMHdPQT09IDU0MTc3MSAyMDE2LTA4LTAzIDE4OjU4OjAxCnxNakF4Tmkwd09BPT0gNTQxNzc2IDIwMTYtMDgtMDMgMTk6MDA6MDEKfE1qQXhOaTB3T0E9PSA1NDE3NzggMjAxNi0wOC0wMyAxOTowMDozMQp8TWpBeE5pMHdPQT09IDU0MTc4MCAyMDE2LTA4LTAzIDE5OjAxOjM0CnxNakF4Tmkwd09BPT0gNTQxNzgzIDIwMTYtMDgtMDMgMTk6MDI6MzEKfE1qQXhOaTB3T0E9PSA1NDE3ODggMjAxNi0wOC0wMyAxOTowNDozMQp8TWpBeE5pMHdPQT09IDU0MTc5NCAyMDE2LTA4LTAzIDE5OjA2OjMyCnxNakF4Tmkwd09BPT0gNTQxNzk5IDIwMTYtMDgtMDMgMTk6MDg6MzEKfE1qQXhOaTB3T0E9PSA1NDE4MDQgMjAxNi0wOC0wMyAxOToxMDozMQp8TWpBeE5pMHdPQT09IDU0MTgxMCAyMDE2LTA4LTAzIDE5OjEyOjMxCnxNakF4Tmkwd09BPT0gNTQxODE1IDIwMTYtMDgtMDMgMTk6MTQ6MzEKfE1qQXhOaTB3T0E9PSA1NDE4MjEgMjAxNi0wOC0wMyAxOToxNjozNAp8TWpBeE5pMHdPQT09IDU0MTgyNiAyMDE2LTA4LTAzIDE5OjE4OjMxCnxNakF4Tmkwd09BPT0gNTQxODMxIDIwMTYtMDgtMDMgMTk6MjA6MzEKfE1qQXhOaTB3T0E9PSA1NDE4MzcgMjAxNi0wOC0wMyAxOToyMjozMQp8TWpBeE5pMHdPQT09IDU0MTg0MiAyMDE2LTA4LTAzIDE5OjI0OjMxCnxNakF4Tmkwd09BPT0gNTQxODQ4IDIwMTYtMDgtMDMgMTk6MjY6MzEKfE1qQXhOaTB3T0E9PSA1NDE4NTMgMjAxNi0wOC0wMyAxOToyODozMQp8TWpBeE5pMHdPQT09IDU0MTg1OSAyMDE2LTA4LTAzIDE5OjMwOjMxCnxNakF4Tmkwd09BPT0gNTQxODY0IDIwMTYtMDgtMDMgMTk6MzI6MzEKfE1qQXhOaTB3T0E9PSA1NDE4NjkgMjAxNi0wOC0wMyAxOTozNDozMQp8TWpBeE5pMHdPQT09IDU0MTg3NSAyMDE2LTA4LTAzIDE5OjM2OjM1CnxNakF4Tmkwd09BPT0gNTQxODgwIDIwMTYtMDgtMDMgMTk6Mzg6MzEKfE1qQXhOaTB3T0E9PSA1NDE4ODYgMjAxNi0wOC0wMyAxOTo0MDozMQp8TWpBeE5pMHdPQT09IDU0MTg5MSAyMDE2LTA4LTAzIDE5OjQyOjMxCnxNakF4Tmkwd09BPT0gNTQxODk3IDIwMTYtMDgtMDMgMTk6NDQ6MzEKfE1qQXhOaTB3T0E9PSA1NDE5MDIgMjAxNi0wOC0wMyAxOTo0NjozNAp8TWpBeE5pMHdPQT09IDU0MTkwOCAyMDE2LTA4LTAzIDE5OjQ4OjMxCnxNakF4Tmkwd09BPT0gNTQxOTEzIDIwMTYtMDgtMDMgMTk6NTA6MzEKfE1qQXhOaTB3T0E9PSA1NDE5MTkgMjAxNi0wOC0wMyAxOTo1MjozMQp8TWpBeE5pMHdPQT09IDU0MTkyNCAyMDE2LTA4LTAzIDE5OjU0OjMxCnxNakF4Tmkwd09BPT0gNTQxOTMwIDIwMTYtMDgtMDMgMTk6NTY6MzQKfE1qQXhOaTB3T0E9PSA1NDE5MzYgMjAxNi0wOC0wMyAxOTo1ODozMQp8TWpBeE5pMHdPQT09IDU0MTkzOSAyMDE2LTA4LTAzIDIwOjAwOjMxCnxNakF4Tmkwd09BPT0gNTQxOTQwIDIwMTYtMDgtMDMgMjA6MDI6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NDEgMjAxNi0wOC0wMyAyMDowNjozNAp8TWpBeE5pMHdPQT09IDU0MTk0MiAyMDE2LTA4LTAzIDIwOjEyOjMxCnxNakF4Tmkwd09BPT0gNTQxOTQzIDIwMTYtMDgtMDMgMjA6MTY6MzQKfE1qQXhOaTB3T0E9PSA1NDE5NDQgMjAxNi0wOC0wMyAyMDoyMDozMQp8TWpBeE5pMHdPQT09IDU0MTk0NSAyMDE2LTA4LTAzIDIwOjI0OjMxCnxNakF4Tmkwd09BPT0gNTQxOTQ2IDIwMTYtMDgtMDMgMjA6Mjg6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NDcgMjAxNi0wOC0wMyAyMDozMjozMQp8TWpBeE5pMHdPQT09IDU0MTk0OCAyMDE2LTA4LTAzIDIwOjM2OjMxCnxNakF4Tmkwd09BPT0gNTQxOTQ5IDIwMTYtMDgtMDMgMjA6NDA6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NTAgMjAxNi0wOC0wMyAyMDo0NDozMQp8TWpBeE5pMHdPQT09IDU0MTk1MSAyMDE2LTA4LTAzIDIwOjQ4OjMxCnxNakF4Tmkwd09BPT0gNTQxOTUyIDIwMTYtMDgtMDMgMjA6NTI6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NTMgMjAxNi0wOC0wMyAyMDo1ODozMQp8TWpBeE5pMHdPQT09IDU0MTk1NCAyMDE2LTA4LTAzIDIxOjAyOjMxCnxNakF4Tmkwd09BPT0gNTQxOTU1IDIwMTYtMDgtMDMgMjE6MDY6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NTYgMjAxNi0wOC0wMyAyMToxMDozMQp8TWpBeE5pMHdPQT09IDU0MTk1NyAyMDE2LTA4LTAzIDIxOjE2OjMxCnxNakF4Tmkwd09BPT0gNTQxOTU4IDIwMTYtMDgtMDMgMjE6MjA6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NTkgMjAxNi0wOC0wMyAyMToyNDozMQp8TWpBeE5pMHdPQT09IDU0MTk2MCAyMDE2LTA4LTAzIDIxOjI4OjMxCnxNakF4Tmkwd09BPT0gNTQxOTYxIDIwMTYtMDgtMDMgMjE6MzI6MzEKfE1qQXhOaTB3T0E9PSA1NDE5NjIgMjAxNi0wOC0wMyAyMTozNjozMgp8TWpBeE5pMHdPQT09IDU0MTk2NCAyMDE2LTA4LTAzIDIxOjQ2OjMxCnxNakF4Tmkwd09BPT0gNTQxOTY1IDIwMTYtMDgtMDMgMjE6NTI6MzEKfE1qQXhOaTB3T1E9PSAwIDIwMTYtMDktMDEKfE1qQXhOaTB4TUE9PSAwIDIwMTYtMTAtMDEKfE1qQXhOaTB4TVE9PSAwIDIwMTYtMTEtMDEKfE1qQXhOaTB4TWc9PSAwIDIwMTYtMTItMDEK|FBDECT_fritz.box.AHA.Wohnzimmer_17|energy|0.020194|0')}

Nachtrag: Die Größe das Logfiles ist dabei innerhalb weniger Minuten auf 144 MB angewachsen.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 August 2016, 22:20:05
nun noch mal zu meinem Vorhaben...

die Zahlenwerte für den Hausanschluss gebe ich aktuell manuell ein über
setreading Hauptzähler energy <Wert>
Die Unterschiedlichen Formate (Wh und kWh) gleiche ich wie folgt aus:
valueFormat {
     if ($VALUE ne "-") {
          if ($DEVICE eq "DbRep.elektrische.Energie.Hauptzaehler") {
               sprintf("%.2f",$VALUE);
          } else {
               sprintf("%.2f",$VALUE/1000);
          }
     } else {
          sprintf("-");
     }
 }

was besseres ist mir da spontan nicht eingefallen, hat aber leider den Nachteil dass der Gesamtbedarf für den Hausanschluss "$sum($ROW:1..$COLUMN-1)" auch noch mal durch 1000 dividiert wird.

DbRep.elektrische.Energie.Hauptzaehler:.*-01,.*-02,.*-03,.*-04,.*-05,.*-06,.*-07,.*-08,.*-09,.*-10,.*-11,.*-12,$sum($ROW:1..$COLUMN-1),<100%>
möglicherweise sind die userReadings in kWh pro device doch die bessere Variante.

Hat jemand eine Idee wie man jetzt anhand der vorliegenden Daten an die prozentualen Werte kommen kann?

zur Vollständigkeit noch mal die Definition:
<%measure_power>,<Januar>,<Februar>,<März>,<April>,<Mai>,<Juni>,<Juli>,<August>,<September>,<Oktober>,<November>,<Dezember>,<Gesamtbedarf>,<[%]>
DbRep.elektrische.Energie.Hauptzaehler:.*-01,.*-02,.*-03,.*-04,.*-05,.*-06,.*-07,.*-08,.*-09,.*-10,.*-11,.*-12,$sum($ROW:1..$COLUMN-1),<100%>
<hr>
<hr>
DbRep.elektrische.Energie.FBDECT_fritz.box.*:.*-01,.*-02,.*-03,.*-04,.*-05,.*-06,.*-07,.*-08,.*-09,.*-10,.*-11,.*-12,$sum($ROW:1..$COLUMN-1),<100%>
DbRep.elektrische.Energie.switchable.socket.*:.*-01,.*-02,.*-03,.*-04,.*-05,.*-06,.*-07,.*-08,.*-09,.*-10,.*-11,.*-12,$sum($ROW:1..$COLUMN-1),<100%>
<hr>
report.electricalEnergy:$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),$sum(2..$ROW),<100%>

und wie es dann aussehen kann im Anhang....
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 August 2016, 22:48:53
Hallo Frickler,

was hast du für Attribute für das DbRep-Device gesetzt ? Mach am Besten mal ein "list Device".
Auf den ersten Blick sieht es für mich so aus als ob das Feld "Value" welches du mit der Funktion "diffValue" auswertest keinen numerischen Wert enthält.

Diesen langen String den du erhälst ("TWpBeE5pMHdNUT09IDAgMjAxNi0wMS0wMQp8TWpBeE5p.....") ist der verschlüsselte Ergebnisstring der Abfrage.

Was gibt denn die Funktion "countEntries" aus ohne das du die Attribute sowie die Zeitgrenzen änderst ?

Grüße
Heiko

PS: Habe heute Abend das Modul erweitert um eine manuelle Eingabemöglichkeit (insert). Wenn ich dazu komme  ;) stelle ich die Version nachher noch hier ein.


Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 August 2016, 23:02:04
mit den nicht numerischen Werten könntest Du recht haben, da die FDDECT Geräte die Einheit "Wh" mit ausgeben

so schaut es in der DB aus:
2016-08-03 22:59:56: FBDECT_fritz.box.AHA.Wohnzimmer_17, FBDECT, energy: 541982 Wh, energy, 541982, W
so in den Readings des FBDECT:
     2016-08-03 22:59:56   energy          541982 Wh
hier das List
Internals:
   CFGFN
   DEF        Dblog
   NAME       DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17
   NR         336
   STATE      done &raquo; ProcTime: 0.0204 sec
   TYPE       DbRep
   Helper:
     DBLOGDEVICE Dblog
     Cv:
       aggregation month
       aggsec     2678400
       destr      2016-12-31
       dsstr      2016-01-01
       epoch_seconds_end 1483225199
       mestr      12
       msstr      01
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2016
       ysstr      2016
   Readings:
     2016-08-03 22:56:36   2016-01-01__elektrische.Energie__2016-01 -
     2016-08-03 22:56:36   2016-02-01__elektrische.Energie__2016-02 -
     2016-08-03 22:56:36   2016-03-01__elektrische.Energie__2016-03 -
     2016-08-03 22:56:36   2016-04-01__elektrische.Energie__2016-04 -
     2016-08-03 22:56:36   2016-05-01__elektrische.Energie__2016-05 -
     2016-08-03 22:56:36   2016-06-01__elektrische.Energie__2016-06 -
     2016-08-03 22:56:36   2016-07-31_23-59-59__elektrische.Energie__2016-07 29.0000
     2016-08-03 22:56:36   2016-08-03_22-52-31__elektrische.Energie__2016-08 3785.0000
     2016-08-03 22:56:36   2016-09-01__elektrische.Energie__2016-09 -
     2016-08-03 22:56:36   2016-10-01__elektrische.Energie__2016-10 -
     2016-08-03 22:56:36   2016-11-01__elektrische.Energie__2016-11 -
     2016-08-03 22:56:36   2016-12-01__elektrische.Energie__2016-12 -
     2016-08-03 22:56:36   sql_processing_time 0.0204
     2016-08-03 22:56:36   state           done
   Dbloghash:
     CFGFN
     CONFIGURATION /opt/fhem/DBlog.conf
     DBMODEL    SQLITE
     DEF        /opt/fhem/DBlog.conf .*:.*
     NAME       Dblog
     NR         17
     NTFY_ORDER 50-Dblog
     PID        10953
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     dbconn     SQLite:dbname=/opt/fhem/DBlog.db
     dbuser
     Readings:
       2016-08-03 00:00:00   lastRowsDeleted 0E0
       2016-08-03 22:51:27   state           connected
   Helper:
Attributes:
   DbLogExclude .*
   aggregation month
   alias      Schaltsteckdose - Wohnzimmer (TV/Video)
   device     FBDECT_fritz.box.AHA.Wohnzimmer_17
   event-on-change-reading .*
   group      TEST - Energie Meter
   reading    energy
   readingNameMap elektrische.Energie
   room       Test
   showproctime 1
   stateFormat state &raquo; ProcTime: sql_processing_time sec
   timeout    10
   timestamp_begin 2016-01-01 00:00:00
   timestamp_end 2016-12-31 23:59:59
   verbose    0
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 August 2016, 23:09:23
Ja, sieht so aus. Grenze mal bitte die Zeitgrenzen so ein dass eine Abfrage nur wenige Ergebnisse generieren kann (wenige Datensätze) und führe die Funktion "fetchrows" aus. Dann schauen wir uns mal die Readings an die ausgegeben werden.
Wenn sich unsere Vermutung bestätigt kann man mit diffValue als mathematische Funktion an dieser Stelle nicht viel anfangen.
 
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 August 2016, 23:09:49
Was gibt denn die Funktion "countEntries" aus ohne das du die Attribute sowie die Zeitgrenzen änderst ?

   Readings:
     2016-08-03 23:08:27   2016-01-01__elektrische.Energie__2016-01 -
     2016-08-03 23:08:27   2016-02-01__elektrische.Energie__2016-02 -
     2016-08-03 23:08:27   2016-03-01__elektrische.Energie__2016-03 -
     2016-08-03 23:08:27   2016-04-01__elektrische.Energie__2016-04 -
     2016-08-03 23:08:27   2016-05-01__elektrische.Energie__2016-05 -
     2016-08-03 23:08:27   2016-06-01__elektrische.Energie__2016-06 -
     2016-08-03 23:08:27   2016-07-01__elektrische.Energie__2016-07 31
     2016-08-03 23:08:27   2016-08-01__elektrische.Energie__2016-08 774
     2016-08-03 23:08:27   2016-09-01__elektrische.Energie__2016-09 -
     2016-08-03 23:08:27   2016-10-01__elektrische.Energie__2016-10 -
     2016-08-03 23:08:27   2016-11-01__elektrische.Energie__2016-11 -
     2016-08-03 23:08:27   2016-12-01__elektrische.Energie__2016-12 -
     2016-08-03 23:08:27   sql_processing_time 0.0048
     2016-08-03 23:08:27   state           done
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 August 2016, 23:13:33
...und führe die Funktion "fetchrows" aus. Dann schauen wir uns mal die Readings an die ausgegeben werden.

     2016-08-03 23:10:47   2016-08-03_22-32-54__elektrische.Energie 541975

     2016-08-03 23:10:47   2016-08-03_22-36-31__elektrische.Energie 541976

     2016-08-03 23:10:47   2016-08-03_22-40-31__elektrische.Energie 541977

     2016-08-03 23:10:47   2016-08-03_22-46-31__elektrische.Energie 541978

     2016-08-03 23:10:47   2016-08-03_22-48-31__elektrische.Energie 541979

     2016-08-03 23:10:47   2016-08-03_22-52-31__elektrische.Energie 541980

     2016-08-03 23:10:47   2016-08-03_22-56-33__elektrische.Energie 541981

     2016-08-03 23:10:47   2016-08-03_22-59-56__elektrische.Energie 541982

     2016-08-03 23:10:47   sql_processing_time 0.0227
     2016-08-03 23:10:47   state           done
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 August 2016, 23:20:11
Das sieht doch aber garnicht schlecht aus. Kann das realistisch dass immer genau 1W Unterschied zwischen den einzelnen Datensätzen sind ?
Jetzt können wir es auch wagen ein verbose 4 einzuschalten, nochmal "fetchrows" auszuführen und den Logausschnitt zu posten.
Dann sehen wir sicher noch mehr.

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 August 2016, 23:43:06
Das sieht doch aber garnicht schlecht aus. Kann das realistisch dass immer genau 1W Unterschied zwischen den einzelnen Datensätzen sind ?
Jetzt können wir es auch wagen ein verbose 4 einzuschalten, nochmal "fetchrows" auszuführen und den Logausschnitt zu posten.
Dann sehen wir sicher noch mehr.
Das mit den 1 W Unterschied passt, es handelt sich hier um einen Ausschnitt und die Geräte sollten sich alle im StandBy Modus befinden... aktuell durch die Schaltsteckdose sogar komplett ausgeschaltet. Dann kommt noch die Einstellung event-on-change-reading hinzu.

2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - -------- New selection ---------
2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Aggregation: month
2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp begin human readable: 2016-01-01 00:00:00
2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp end human readable: 2016-12-31 23:59:59
2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall fetchrows_DoParse
2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND READING = 'energy' AND TIMESTAMP BETWEEN 2016-01-01 00:00:00 AND 2016-12-31 23:59:59 ORDER BY TIMESTAMP;
2016.08.03 23:29:05 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall fetchrows_DoParse finished
2016.08.03 23:29:06 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall fetchrows_ParseDone
2016.08.03 23:29:07 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall fetchrows_ParseDone finished
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - -------- New selection ---------
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Aggregation: month
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp begin human readable: 2016-01-01 00:00:00
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp end human readable: 2016-12-31 23:59:59
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall fetchrows_DoParse
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND READING = 'energy' AND TIMESTAMP BETWEEN 2016-01-01 00:00:00 AND 2016-12-31 23:59:59 ORDER BY TIMESTAMP;
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall fetchrows_DoParse finished
2016.08.03 23:30:02 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall fetchrows_ParseDone
2016.08.03 23:30:03 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall fetchrows_ParseDone finished
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 821) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 825) line 6.
2016.08.03 23:30:07 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 828) line 6.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 854) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 858) line 6.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 884) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 911) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 915) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 919) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 923) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 927) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 931) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 935) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 939) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 947) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 951) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 955) line 1.
2016.08.03 23:30:07 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 959) line 1.
2016.08.03 23:31:05 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1050) line 1.
2016.08.03 23:31:05 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 1054) line 6.
2016.08.03 23:31:05 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 1057) line 6.
2016.08.03 23:31:05 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1083) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 1087) line 6.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1113) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1140) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1144) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1148) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1152) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1156) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1160) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1164) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1168) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1176) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1180) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1184) line 1.
2016.08.03 23:31:06 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1188) line 1.
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - -------- New selection ---------
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Aggregation: month
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp begin human readable: 2016-01-01 00:00:00
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp end human readable: 2016-12-31 23:59:59
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall fetchrows_DoParse
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND READING = 'energy' AND TIMESTAMP BETWEEN 2016-01-01 00:00:00 AND 2016-12-31 23:59:59 ORDER BY TIMESTAMP;
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall fetchrows_DoParse finished
2016.08.03 23:31:25 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall fetchrows_ParseDone
2016.08.03 23:31:26 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall fetchrows_ParseDone finished
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - -------- New selection ---------
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Aggregation: month
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp begin human readable: 2016-01-01 00:00:00
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - Timestamp end human readable: 2016-12-31 23:59:59
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall diffval_DoParse
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-01-01 00:00:00' AND '2016-02-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-02-01' AND '2016-03-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-03-01' AND '2016-04-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-04-01' AND '2016-05-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-05-01' AND '2016-06-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-06-01' AND '2016-07-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-07-01' AND '2016-08-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-08-01' AND '2016-09-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-09-01' AND '2016-10-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-10-01' AND '2016-11-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-11-01' AND '2016-12-01' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - SQL to execute: SELECT VALUE,TIMESTAMP FROM `history` where `DEVICE` = 'FBDECT_fritz.box.AHA.Wohnzimmer_17' AND `READING` = 'energy' AND TIMESTAMP BETWEEN '2016-12-01' AND '2016-12-31 23:59:59' ORDER BY TIMESTAMP;
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall diffval_DoParse finished
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> Start BlockingCall diffval_ParseDone
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-01, value: 2016-01|0|2016-01-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-02, value: 2016-02|0|2016-02-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-03, value: 2016-03|0|2016-03-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-04, value: 2016-04|0|2016-04-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-05, value: 2016-05|0|2016-05-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-06, value: 2016-06|0|2016-06-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-07, value: 2016-07|29|2016-07-31_23-59-59
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-08, value: 2016-08|3787|2016-08-03_22-59-56
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-09, value: 2016-09|0|2016-09-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-10, value: 2016-10|0|2016-10-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-11, value: 2016-11|0|2016-11-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 - runtimestring Key: 2016-12, value: 2016-12|0|2016-12-01
2016.08.03 23:31:49 4: DbRep DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 -> BlockingCall diffval_ParseDone finished
2016.08.03 23:31:54 1: PERL WARNING: Argument "49261,2" isn't numeric in numeric ge (>=) at ./FHEM/93_DbRep.pm line 1230.
2016.08.03 23:31:54 1: PERL WARNING: Argument "49261,2" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 1232.
2016.08.03 23:31:54 1: PERL WARNING: Argument "49261,3" isn't numeric in numeric ge (>=) at ./FHEM/93_DbRep.pm line 1217.
2016.08.03 23:31:54 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1286) line 1.
2016.08.03 23:31:54 3: eval: {diffval_ParseDone('DbRep.elektrische.Energie.Hauptzaehler|TWp<gekürzt>0wMQo=|Hauptzaehler|energy|0.005401|0')}
2016.08.03 23:31:54 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 1366) line 1.

da kommen jetzt mehrere von diesen Einträgen und dann etwas, was meine Einheiten Theorie durcheinander bringt... das folgende Device schreibt nur Zahlenwerte in die DB

2016.08.03 23:31:57 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 3307) line 1.
2016.08.03 23:31:57 3: eval: {diffval_ParseDone('DbRep.elektrische.Energie.switchable.socket.Wohnkeller_Pwr|<gekürzt>ItMDEK|switchable.socket.Wohnkeller_Pwr|energy|0.032254|0')}

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 August 2016, 00:08:09
Ich denke wir kommen der Sache näher.
Die Zeilen

PERL WARNING: Argument "-" isn't numeric in subroutine entry at
rühren ziemlich sicher daher dass ich im Code "-" setze wenn keine Werte geliefert wurden (Ist z.B. wichtig für Readingsgroup). Allerdings bekomme ich diese Logeinträge bei mir mit der Standardeinstellung global verbose = 3 überhaupt nicht. Aber das kann ich sicherlich korrigieren.

Aber die Einträge

Zitat
PERL WARNING: Argument "49261,2" isn't numeric in subtraction

rühren m.M. nach  daher dass  "49261,2" wegen dem Komma kein numerischer Wert ist -> müßte  "49261.2" heißen.

Kopfzerbrechen nacht mir noch woher die eval Einträge:

Zitat
eval: {diffval_ParseDone('DbRep.elektrische.Energie.Hauptzaehler|TW....

stammen. Im Modul selbst habe ich die nicht (zumindest nicht an diesen momentan zur Diskussion stehenden Stellen).
EDIT: Auch diese Einträge bekomme ich bei mir, auch bei bewußt falscher Anwendung der Selektion, nicht auf den Schirm.



Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 04 August 2016, 00:12:00
rühren m.M. nach  daher dass  "49261,2" wegen dem Komma kein numerischer Wert ist -> müßte  "49261.2" heißen.
Da hatte ich zwei oder drei Werte manuell fehlerhaft eingegeben.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 04 August 2016, 00:17:21
Kopfzerbrechen nacht mir noch woher die eval Einträge:

stammen. Im Modul selbst habe ich die nicht (zumindest nicht an diesen momentan zur Diskussion stehenden Stellen).
EDIT: Auch diese Einträge bekomme ich bei mir, auch bei bewußt falscher Anwendung der Selektion, nicht auf den Schirm.
kann man durch Log Einstellungen herausfinden wer diese Fehlereinträge generiert? Möglicherweise ist es am Ende nicht mal das DbRep Modul.

Die Werte lasse ich automatisch mit
+*00:05 set DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17 diffValue
erstellen. Ich würde die Automatik aber über nacht auch gerne weiter inaktiv lassen, damit morgen nicht meine komplette HD vollgeschrieben wurde. Ansonsten kann ich es morgen kontrolliert noch mal aktivieren.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 August 2016, 00:19:42
Zitat
rühren ziemlich sicher daher dass ich im Code "-" setze wenn keine Werte geliefert wurden

Kommando zurück, "-" setze ich tatsächlich in der eingecheckten Version erst wenn die Readings generiert werden. Haben also bei der Berechnung keinen Einfluß.

Du hast doch sicher die aktuell eingecheckte Version im Einsatz ?

-> Dann lösche doch bitte die falschen Einträge oder korrigiere sie. Dann schauen wir nochmal.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 August 2016, 00:23:02
Zitat
kann man durch Log Einstellungen herausfinden wer diese Fehlereinträge generiert

stacktrace fällt mir da ein, zu setzen im global device.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 August 2016, 00:32:19
Ich werde gleich noch die neue Version V3.4 in den Anfangsbeitrag einhängen. Es ist die Funktion "insert" zum manuellen Input von DB-Einträgen hinzugekommen. Wie es zu benutzen ist ergänze ich auch im Eingangsbeitrag.

Kannst du ja morgen mit dieser Version noch einmal testen.

Grüße und gute Nacht
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 August 2016, 18:53:04
Hallo zusammen, hallo Frickler,

um die Gefahr der Verwendung nicht numerischer Werte  in den DbRep-Funktionen mit mathematischen Berechnungen zu umgehen, habe ich in der Version 3.4.1 (im ersten Beitrag) einen Check eingebaut.
Sollte ein solcher Wert entdeckt werden, geht die Funktion auf "error" und im Log (verbose 2) wird der Überltäter ausgeschrieben:

DbRep test - ERROR - found value = 'Total:' isn't numeric in diffval function. Leaving ...
Bitte teste die Version mit deinem Problemfall. Ich vermute nach wie vor dass der Input und Auswertung von nichtnumerischen Werten mit diffValue / maxValue das eigentliche Problem darstellt.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 04 August 2016, 19:46:48
Hallo,

ich werde gleich mal einen DbRep aktivieren.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 04 August 2016, 19:58:06
das "-" Problem wird wie erwartet durch die readingsGroup und den darin enthaltenen Berechnungen ausgelöst:

2016.08.04 19:52:29 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 769) line 1.
2016.08.04 19:52:29 3: stacktrace:
2016.08.04 19:52:29 3:     main::__ANON__                      called by (eval 769) (1)
2016.08.04 19:52:29 3:     (eval)                              called by ./FHEM/33_readingsGroup.pm (498)
2016.08.04 19:52:29 3:     readingsGroup::rgCalc               called by ./FHEM/33_readingsGroup.pm (513)
2016.08.04 19:52:29 3:     main::readingsGroup_value2html      called by ./FHEM/33_readingsGroup.pm (998)
2016.08.04 19:52:29 3:     main::readingsGroup_2html           called by ./FHEM/33_readingsGroup.pm (1087)
2016.08.04 19:52:29 3:     main::readingsGroup_detailFn        called by ./FHEM/01_FHEMWEB.pm (2811)
2016.08.04 19:52:29 3:     main::FW_devState                   called by ./FHEM/01_FHEMWEB.pm (1519)
2016.08.04 19:52:29 3:     main::FW_makeDeviceLine             called by ./FHEM/01_FHEMWEB.pm (1627)
2016.08.04 19:52:29 3:     main::FW_showRoom                   called by ./FHEM/01_FHEMWEB.pm (909)
2016.08.04 19:52:29 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (454)
2016.08.04 19:52:29 3:     main::FW_Read                       called by fhem.pl (3199)
2016.08.04 19:52:29 3:     main::CallFn                        called by fhem.pl (667)

durch z.B.

DbRep.elektrische.Energie.FBDECT_fritz.box.*:.*-01,.*-02,.*-03,.*-04,.*-05,.*-06,.*-07,.*-08,.*-09,.*-10,.*-11,.*-12,$sum($ROW:1..$COLUMN-1),<100%>

im Zusammenhang mit

valueFormat { ($VALUE ne "-") ? "%.2f" : "-" }\
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 04 August 2016, 20:16:03
und jetzt das eval:

2016.08.04 20:00:40 3: eval: {diffval_ParseDone('DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17|TWpB<gekürzt>0wMQo=|FBDECT_fritz.box.AHA.Wohnzimmer_17|energy|0.027858|0')}
2016.08.04 20:00:40 3: stacktrace:
2016.08.04 20:00:40 3:     main::__ANON__                      called by (eval 4058) (1)
2016.08.04 20:00:40 3:     (eval)                              called by ./FHEM/33_readingsGroup.pm (498)
2016.08.04 20:00:40 3:     readingsGroup::rgCalc               called by ./FHEM/33_readingsGroup.pm (513)
2016.08.04 20:00:40 3:     main::readingsGroup_value2html      called by ./FHEM/33_readingsGroup.pm (1373)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1395)
2016.08.04 20:00:40 3:     main::readingsGroup_Notify          called by fhem.pl (3199)
2016.08.04 20:00:40 3:     main::CallFn                        called by fhem.pl (3121)
2016.08.04 20:00:40 3:     main::DoTrigger                     called by fhem.pl (4012)
2016.08.04 20:00:40 3:     main::readingsEndUpdate             called by ./FHEM/93_DbRep.pm (1265)
2016.08.04 20:00:40 3:     main::diffval_ParseDone             called by (eval 2210) (1)
2016.08.04 20:00:40 3:     (eval)                              called by fhem.pl (1002)
2016.08.04 20:00:40 3:     main::AnalyzePerlCommand            called by fhem.pl (1021)
2016.08.04 20:00:40 3:     main::AnalyzeCommand                called by fhem.pl (950)
2016.08.04 20:00:40 3:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (275)
2016.08.04 20:00:40 3:     main::telnet_Read                   called by fhem.pl (3199)
2016.08.04 20:00:40 3:     main::CallFn                        called by fhem.pl (667)
2016.08.04 20:00:40 1: PERL WARNING: Argument "-" isn't numeric in subroutine entry at (eval 4058) line 1.
2016.08.04 20:00:40 3: eval: {diffval_ParseDone('DbRep.elektrische.Energie.FBDECT_fritz.box.AHA.Wohnzimmer_17|TWpB<gekürzt>0wMQo=|FBDECT_fritz.box.AHA.Wohnzimmer_17|energy|0.027858|0')}
2016.08.04 20:00:40 3: stacktrace:
2016.08.04 20:00:40 3:     main::__ANON__                      called by (eval 4058) (1)
2016.08.04 20:00:40 3:     (eval)                              called by ./FHEM/33_readingsGroup.pm (498)
2016.08.04 20:00:40 3:     readingsGroup::rgCalc               called by ./FHEM/33_readingsGroup.pm (513)
2016.08.04 20:00:40 3:     main::readingsGroup_value2html      called by ./FHEM/33_readingsGroup.pm (1373)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1384)
2016.08.04 20:00:40 3:     main::updateRefs                    called by ./FHEM/33_readingsGroup.pm (1395)
2016.08.04 20:00:40 3:     main::readingsGroup_Notify          called by fhem.pl (3199)
2016.08.04 20:00:40 3:     main::CallFn                        called by fhem.pl (3121)
2016.08.04 20:00:40 3:     main::DoTrigger                     called by fhem.pl (4012)
2016.08.04 20:00:40 3:     main::readingsEndUpdate             called by ./FHEM/93_DbRep.pm (1265)
2016.08.04 20:00:40 3:     main::diffval_ParseDone             called by (eval 2210) (1)
2016.08.04 20:00:40 3:     (eval)                              called by fhem.pl (1002)
2016.08.04 20:00:40 3:     main::AnalyzePerlCommand            called by fhem.pl (1021)
2016.08.04 20:00:40 3:     main::AnalyzeCommand                called by fhem.pl (950)
2016.08.04 20:00:40 3:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (275)
2016.08.04 20:00:40 3:     main::telnet_Read                   called by fhem.pl (3199)
2016.08.04 20:00:40 3:     main::CallFn                        called by fhem.pl (667)
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 August 2016, 22:41:17
Dann setz für deine Readingsgroup verbose mal runter. Dann sollten die Warnungen weg sein... als Notlösung.

Das Valueformat habe ich bei mir genauso wie du (ohne "\"):
{ ($VALUE ne "-") ? "%.2f" : "-" }
Bei mir gibt es deswegen keine Einträge im Log der Art :

PERL WARNING: Argument "-" isn't numeric ....
Hast du mit der V3.4.1 festgestellt dass es noch irgendwelche nichtnumerischen Werte in dem Auswertungsstring gibt ?  Wenn nicht ist es an dieser Stelle sauber.

Die Aufrufe mit eval:

eval: {diffval_ParseDone('DbRep.elektrische.Energi ....
werden so wie es aussieht durch fhem.pl selbst ausgeführt. Wieso die Einträge im Log erscheinen ist mir trotzdem noch nicht transparent geworden.
Wie sieht es denn aus wenn du die Readingsgroup temprorär auf disable=1 setzt ?



Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 04 August 2016, 23:16:34
es scheint alles mit den Berechnungen in readingsGroup zusammen zu hängen. D.h., Funktionen wie z.B. $sum($ROW:1..$COLUMN-1) sind wegen der "-" nicht nutzbar.

Wie gehst Du bei Deiner Auswertung vor? Werden Ertrag und Kosten innerhalb oder ausserhalb der readingsGroup ermittelt?

Gruß!

Nachtrag:

was jetzt noch im Log steht:
DBD::SQLite::st fetchall_arrayref failed: database disk image is malformed at ./FHEM/93_DbRep.pm line 1129.
DBD::SQLite::st fetchall_arrayref failed: database disk image is malformed at ./FHEM/93_DbRep.pm line 1129.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 August 2016, 08:59:56
Guten Morgen,

Zitat
]Funktionen wie z.B. $sum($ROW:1..$COLUMN-1) sind wegen der "-" nicht nutzbar.

Du könntest in der Readingsgroup das valueFormat so umformulieren:

{ ($VALUE ne "-") ? "%.2f" : 0.00 }
Damit wären Weiterberechnungen wohl möglich, da du immer numerische Werte bekommst.

Prinzipiell sehe ich zu alle auszuwertenden Größen gleich in der Datenbank in der benötigten Form zu speichern. So ist es auch mit Ertrag und Kosten. Das verwendete SMAEM Modul hat Attribute an Bord die eine Berechnung dieser Werte gleich intern erledigen und als Readings ausgeben.

Wo das nicht der Fall ist, würde ich immer versuchen mit userreadings im jeweiligen Modul  die abzuspeichernden Größen zu berechnen und zu loggen. Readingsgroup dient dann nur noch der strukturierten Aufbereitung.

Nach deinem Fehler:

DBD::SQLite::st fetchall_arrayref failed: database disk image is malformed
habe ich mal gegoogelt und einige Reparaturhinweise gefunden. Möglicherweise hast du eine DB / Datenfile Korruption.
Schau mal ob etwas für dich zutrifft (ein Hinweis ist für Windows).

http://stackoverflow.com/questions/26962287/how-to-fix-activeperls-ppm-database-disk-image-is-malformed-error (http://stackoverflow.com/questions/26962287/how-to-fix-activeperls-ppm-database-disk-image-is-malformed-error)
http://stackoverflow.com/questions/5274202/sqlite3-database-or-disk-is-full-the-database-disk-image-is-malformed (http://stackoverflow.com/questions/5274202/sqlite3-database-or-disk-is-full-the-database-disk-image-is-malformed)
http://stackoverflow.com/questions/13675615/svn-cleanup-sqlite-database-disk-image-is-malformed (http://stackoverflow.com/questions/13675615/svn-cleanup-sqlite-database-disk-image-is-malformed)

Es gibt noch etliche Treffer mehr. Such mal ein bisschen falls dir diese Hinweise nicht helfen sollten.

Hast du denn die manuelle Insertfunktion ausprobiert ? Sollte dir helfen deine Werte problemlos in die DB zu bekommen.

Grüße
Heiko



Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 05 August 2016, 17:42:20
Guten Morgen,

Du könntest in der Readingsgroup das valueFormat so umformulieren:

{ ($VALUE ne "-") ? "%.2f" : 0.00 }
Damit wären Weiterberechnungen wohl möglich, da du immer numerische Werte bekommst.

Irgendwie hat es den Anschein dass die Konvertierung von "-" nach "0.00" bereits im DbReg erfolgen muss. Ich teste noch mal etwas rum und melde mich dann zurück.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 08 August 2016, 22:05:59
fassen wir mal zusammen... das Modul DbRep funktioniert soweit, die Probleme (bei mir) entstehen im Zusammenhang mit den Funktionen mit der readingsGroup.

Wurden Werte mit fehlerhaftem Format eingegeben wird gar nicht berechnet (diffValue). Ich hatte ja den Fall dass ich bei einem Wert ein Komma anstatt Punkt eingegeben hatte.
Meine Meinung: Ich würde vorschlagen dass man solche Werte in der Kalkulation einfach ignoriert und lediglich eine Warnung mit ausgibt. Das Modul bietet die Möglichkeit alle Datensätze zu löschen, aber keine einzelnen. Hier könnte man anhand der Warnung den fehlerhaften Wert manuell nachtragen. Alternativ kann man auch die Möglichkeit bieten einzelne Datensätze selektiv aus der DB zu löschen. Stellt sich halt die Frage was einfacher zu realisieren ist.

Manuelles Eintragen von Datensätzen in die DB...
Meine Meinung: Es funktioniert gut, nur hätte ich die Eingabe etwas reduziert... aktuell: Date,Time,Device,Reading,Value,Unit; ausreichen sollte: Date,Time,Value,Unit
Hier hätte ich erwartet dass es sich beim Device auch um das Attribut Device und beim Reading um das Attribut Reading handelt. Das würde dann die Eingabe etwas vereinfachen.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 August 2016, 22:43:39
Danke für die Rückmeldung und konstruktiven Hinweise.

In der jetzigen Version generiere ich einen Fehler mit dem Hinweis auf den fehlerhaften String im Logfile sofern man versucht String-Werte mit mathematischen Funktionen zu verarbeiten. Diesen fehlerhaften Wert müßte man momentan mit einem Datenbank-Management-Tool bereinigen. Vielleicht bekomme ich es noch hin die Möglichkeit im Modul zu schaffen.

Beim manuellen Eintragen hatte ich bewußt die Eingabe von Reading/Device unabhängig von den Attributen gestaltet weil ich es als Vorstufe einer Weiterentwicklung in Richtung Bulk-Insert über ein File angesehen hatte. D.h. man bereitet alle einzufügenden Datensätze in einem File vor, übergibt es der Funktion und läßt die Werte reinlaufen.
Aber wenn es sich als praktischer und logischer erweist bei der insert Funktion die Attribute Device/Reading zu verwenden ändere ich es gerne um, es soll ja möglichst praktisch und hilfreich sein.

Grüße
Heiko

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 09 August 2016, 00:50:32
Aber wenn es sich als praktischer und logischer erweist bei der insert Funktion die Attribute Device/Reading zu verwenden ändere ich es gerne um, es soll ja möglichst praktisch und hilfreich sein.

Grüße
Heiko

es sind halt Vorschläge zu Funktionsweisen wie ich Sie erwartet hätte. Die anderen Funktionen beziehen sich ja auch auf das jeweils angegebene Device und das Reading, demnach hätte ich diese Funktionsweise als konsequent angesehen. Ansonsten scheint die Handhabung absolut logisch und selbsterklärend.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2016, 01:03:06
Zitat
Die anderen Funktionen beziehen sich ja auch auf das jeweils angegebene Device und das Reading, demnach hätte ich diese Funktionsweise als konsequent angesehen.

Nach einiger Überlegung habe ich deinen Vorschlag aufgenommen und auch schon umgesetzt. Ich muß noch etwas testen und die Doku ändern, dann kann ich die neue Version einchecken. Es werden dann auch noch mehr Informationen zu einem fehlerhaften Datensatz (String in math. Funktion) in das Logfile geschrieben.

VG
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2016, 18:40:42
Zitat
Ich muß noch etwas testen und die Doku ändern, dann kann ich die neue Version einchecken.

Habe die neue Verssion eingecheckt und steht dann morgen früh zur Verfügung.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 09 August 2016, 18:53:46
Habe die neue Verssion eingecheckt und steht dann morgen früh zur Verfügung.
werde ich dann gerne testen...

Ich hätte da noch einen Vorschlag: wenn man timestamp_begin und timestamp_end mit Werten wie z.B. current_year_begin, current_year_end sowie previous_year_begin und previous_year_end belegen könnte.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2016, 19:06:22
Hab die neue Version 3.4.3 auch noch im ersten Thread eingehängt. Kannst du dann auch heute schon probieren.

Zitat
wenn man timestamp_begin und timestamp_end mit Werten wie z.B. current_year_begin, current_year_end sowie previous_year_begin und previous_year_end belegen könnte.

Du meinst z.B. current_year_begin stellvertretend für "2016-01-01 00:00:00" ?



Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 09 August 2016, 19:07:44
Hab die neue Version 3.4.3 auch noch im ersten Thread eingehängt. Kannst du dann auch heute schon probieren.

Du meinst z.B. current_year_begin stellvertretend für "2016-01-01 00:00:00" ?

heute ja, am 1.1.2017 steht es dann aber für "2017-01-01 00:00:00"
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2016, 19:17:59
Ja klar, verstanden. Ich denke, das sollte möglich sein. Sehe ich mal bei einem der nächsten Updates mit vor.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 09 August 2016, 19:31:14
ich hätte dann noch mal eine Frage... Bei der Berechnung der jeweiligen Monatswerte nimmst Du immer den ersten Wert und den letzten Wert im Monat? Wenn ich jetzt beispielsweise den Zählerstand am 1. und am 25. eines Monats eingebe und als nächstes für den Folgemonat am 5. des Monats, dann würde für den ersten Monat der Zählerstand vom 1. bis zum 25. berechnet und dann für den Folgemonat erst ab dem 5. des Monats? D.h., die Differenz zwischen dem 25. des ersten Monats und dem 5. des Folgemonats wird in keiner Berechnung beachtet?
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2016, 22:10:29
Also,  es ist so dass bei der Berechnung immer die verfügbaren Werte in dem jeweiligen Aggregations-Zeitabschnitt berücksichtigt werden.

Bleiben wir bei dem Beispiel und du gibst Werte für den 1., den 25. und 5. (Folgemonat) ein. Weiterhin stellst du die Aggregation auf "Monat" und gibst als Startzeitpunkt den 01.xx.xxx 00:00:00 ein.

Das Modul nimmt jeden verfügbaren Wert innerhalb der Aggregationsgrenzen... also so wie du geschrieben hast, zunächst zwischen dem 01. (bzw. Startzeitpunkt) und dem Ende des Monats ... bei dir den 25.  und ermittelt daraus die Differenz. Danach wird der Zeitraum 01. bis Ende des Folgemonats betrachtet. Wenn nur ein einzelner Wert (vom 05.) in der DB enthalten ist, dann wird die Differenz für den Folgemonat schwer ermittelbar sein, da quasi nicht vorhanden (nur ein Wert = Anfangswert = Endewert des Monats).

Wenn du alle eingegeben Werte in ihrer Gesamtheit betrachten möchtest, würde ich den Startzeitpunkt in dem Beispiel auf den 01. setzen und den Endezeitpunkt auf das Ende des Folgemonats und KEINE Aggregation. Dann wird der Startwert vom 01 und der Endewert vom 05. des Folgemonats miteinander in Beziehung gesetzt und du hast den gesamten Eingabezeitraum ausgewertet.

Ich hoffe die Erläuterung hat ungefähr den Kern deiner Frage beantworten können.

viele Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 09 August 2016, 22:24:23
Das Modul nimmt jeden verfügbaren Wert innerhalb der Aggregationsgrenzen... also so wie du geschrieben hast, zunächst zwischen dem 01. (bzw. Startzeitpunkt) und dem Ende des Monats ... bei dir den 25.  und ermittelt daraus die Differenz. Danach wird der Zeitraum 01. bis Ende des Folgemonats betrachtet. Wenn nur ein einzelner Wert (vom 05.) in der DB enthalten ist, dann wird die Differenz für den Folgemonat schwer ermittelbar sein, da quasi nicht vorhanden (nur ein Wert = Anfangswert = Endewert des Monats).

Das mit dem einen Wert im Folgemonat war jetzt sicherlich etwas dumm von mir... ich versuche es anhand eines Beispiels:
1. DB Eintrag:   7.5.2015: 38000
2. DB Eintrag: 25.5.2015: 40000
3. DB Eintrag:   5.6.2015: 41000
4. DB Eintrag: 31.6.2015: 44000

Wenn ich jetzt lediglich die Differenz aus dem ersten und letztem Datensatz eines Monats bilde, dann würde ich für dem Monat 05 den diffValue 2000 bekommen und für den Monat 06 den diffValue 3000. In der Summe würden mir dann aber 1000 fehlen... und zwar der Sprung von 40000 auf 41000.

Zugegeben, dieses Problem sollte seich lediglich bei manuell abgelesenen Werten ergeben und zwar dann nur wenn man mal vergisst die Wählerstände abzulesen. Zur not könnte man den letzten Monatswert auch manuell auf den 1. eines Monats übertragen.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2016, 22:40:52
Ja, du hast recht. Natürlich kann das Modul nur die verfügbaren Werte in der Datenbank logisch verarbeiten. Hier ist die Datenqualität in der DB entscheidend für die Brauchbarkeit des Ergebnisses.
In deinem Beispiel weißt du ja wegen der fehlenden Ablesung am 01.06. auch nicht den wahren Wert des Zählerstandes zu diesem Zeitpunkt. Die Berechnung von Monatswerten wäre unter diesen Umständen quasi eine Annäherung.

Um das bei manueller Eingabe einigermaßen realistisch zu gestalten, müßtest du wahrscheinlich den Startwert am 01.06. entsprechend des durchschnittlichen Tagesverbrauchs  schätzen und eintragen. Wenn du nur den Wert vom 25.05. überträgst, würdest du die 6 letzten Tage im Mai verbauchstechnisch "unterschlagen" und statt im Mai dem Juni hinzuschlagen.

Naja, es bleibt ein Kompromiß.
   
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 09 August 2016, 23:02:29
Um das bei manueller Eingabe einigermaßen realistisch zu gestalten, müßtest du wahrscheinlich den Startwert am 01.06. entsprechend des durchschnittlichen Tagesverbrauchs  schätzen und eintragen. Wenn du nur den Wert vom 25.05. überträgst, würdest du die 6 letzten Tage im Mai verbauchstechnisch "unterschlagen" und statt im Mai dem Juni hinzuschlagen.

Naja, es bleibt ein Kompromiß.
 
Natürlich bleibt es ein Kompromiss. Es hätte ja auch sein können, dass für den Fall, bei dem für den Monatsbeginn kein Wert vorhanden ist, man auf den letzten verfügbaren zurückgreifen würde. Aber das in Deinem Modul mit einzubringen macht nun wirklich keinen Sinn. Möglicherweise gibt es ja irgendwann Smart Meter flächendeckend oder ich muss mich um eine lokale Lösung kümmern.

Aber das ist dann auch eine wichtige Information für die Handhabung mit dem reduceLog im DBLog. Ausdünnen darf man, nur sollte dabei der erste und der letzte Wert im Monat stehenbleiben.

Aber nehmen wir mal folgende Situation:
2016-08-05_01-18-36__elektrische.Energie 621.81 2016-08-09 22:52:41
2016-08-05_03-23-35__elektrische.Energie 622.00 2016-08-09 22:52:41

Aus mir nicht erklärbaren Gründen wurden hier ein paar Zwischenwerte nicht gesendet; möglicherweise eine Störung im D-LAN. Das hätte natürlich auch zwischen dem 31.x. gegen 23:55 und dem 01.y. gegen 2:30 passieren können. Davon ausgehend dass das angeschlossene Gerät etwas konsumfreudiger bezüglich er elektrischen Energie ist, könnten so 1-2 kWh verloren gehen. Demnach würde ich Pauschal immer den letzten Monatswert als Anfangswert des kommenden Monats nehmen.

Das könnte man aber auch mit einem at Befehl in Kombination mit addLog lösen, der dann immer zum 1. eines Monats den aktuellen Wert in die DB schreibt. Mal sehen was das "Use perl function for timespec" da so bietet.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 10 August 2016, 18:33:37
Das neue Insert klappt super. Das Problem mit dem Übertrag auf den Folgemonat habe ich über ein at gelöst:
*00:00:00 {addLog("electricity.mainCounter","meterReading_kWh")}
Es ist zwar nicht jeden Tag notwendig, nur hat das Timespec beim at die Einschränkung, dass der Zeitrahmen sich auf 24 h beschränkt. Dann muss ich nur noch mal das Haus mit weiteren Mess-Steckdosen ausrüsten, damit ich näher an den Wert des Hauptzählers komme.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 August 2016, 20:47:49
Danke für die Rückmeldung .... prima  :)

Mal schauen wann ich dazu komme am Modul noch etwas weiterzumachen.
Halte euch auf dem Laufenden ...

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 August 2016, 16:52:37
Zitat
Ich hätte da noch einen Vorschlag: wenn man timestamp_begin und timestamp_end mit Werten wie z.B. current_year_begin, current_year_end sowie previous_year_begin und previous_year_end belegen könnte.

Im Eingangsbeitrag ist die neue Version 3.4.4 angehängt die ich genauso wie von dir vorgeschlagen erweitert habe. Die Erläuterung ist ebenfalls ergänzt.
Bitte mal testen ... bei mir funktioniert es tadellos.

VG und schönes WE
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 August 2016, 08:25:50
Habe noch einen Fehler in der V.3.4.4 festgestellt und korrigiert im Eingangsthread hinterlegt.

VG
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 15 August 2016, 10:56:31
ich hatte bisher noch keine Zeit zum Testen, mal sehen ob es im Laufe der Woche klappt.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 18 August 2016, 21:40:01
Hallo, klappt gut soweit.

Eine Verbesserung hätte ich dann noch... wenn sein Kommando nicht erfolgreich durchläuft könnte man es doch zeitversetzt automatisch wiederholen?

Gruß,
Karsten

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 August 2016, 09:17:48
Hallo Karsten,

prima  :).

Zitat
Eine Verbesserung hätte ich dann noch... wenn sein Kommando nicht erfolgreich durchläuft könnte man es doch zeitversetzt automatisch wiederholen?

Prinzipiell wäre soetwas sicherlich umsetzbar mit definierten Rahmenbedingungen. Also wenn Fehler,  dann x mal wiederholen mit Abstand y -> sonst Error. (Endlosschleifen vermeiden)
Welches Scenario schwebt dir denn da konkret vor ?  Es wäre wahrscheinlich nicht nötig bei jeder Selektionsvariante eine solche Zusatzfunktion vorzusehen.

Ich war auch nicht untätig und habe in das Modul ein Attribut "timeOlderThan" eingebaut was quasi das Gegenstück zu "timeDIffToNow" ist.
Wird dieses Attribut gesetzt, werden alle Selektionen bzw. Löschungen alle alten  Datensaätze in der DB BIS zu dem Zeitpunkt <aktueller Timestamp>-<timeOlderThan> (dynamisch kalkuliert) ausgeführt.

Also wenn das Attr auf z.B. 172800 (s) gesetzt ist, denn werden alle Datensätze in der DB die älter als 1 Tag sind und den sonstigen Bedingungen wie Device bzw. Reading entsprechen, gelöscht. 
Zum Beeispiel regelmäßig mit einem AT:

# DBRep Device anlegen
define Rep.Del.Sonnenstrom_Relative DbRep LogDB
attr Rep.Del.Sonnenstrom_Relative allowDeletion 1
attr Rep.Del.Sonnenstrom_Relative comment Löschen der DB-Einträge älter als 2 Tage für Device Rep.Del.Sonnenstrom_Relative.
attr Rep.Del.Sonnenstrom_Relative devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.Sonnenstrom_Relative device Sonnenstrom_Relative
attr Rep.Del.Sonnenstrom_Relative room DbLog
attr Rep.Del.Sonnenstrom_Relative showproctime 1
attr Rep.Del.Sonnenstrom_Relative timeUpToDiff 172800
attr Rep.Del.Sonnenstrom_Relative timeout 120
attr Rep.Del.Sonnenstrom_Relative verbose 3

# regelmaäßigen Löschjob laufen lassen
define At.Del.Sonnenstrom_Relative at +*24:00:00 set Rep.Del.Sonnenstrom_Relative delEntries
attr At.Del.Sonnenstrom_Relative comment Job zum Löschen der DB-Einträge älter als 2 Tage für Device Rep.Del.Sonnenstrom_Relative.
attr At.Del.Sonnenstrom_Relative room DbLog

Ich hänge die neue Version V3.5 wieder in den Eingangsthread und ergänze die Doku. Über das WE will ich die commandref noch beschreiben und das Modul mit dem Entwicklungsstand auch wieder einchecken.

viele Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 19 August 2016, 12:01:46
Prinzipiell wäre soetwas sicherlich umsetzbar mit definierten Rahmenbedingungen. Also wenn Fehler,  dann x mal wiederholen mit Abstand y -> sonst Error. (Endlosschleifen vermeiden)
Welches Scenario schwebt dir denn da konkret vor ?  Es wäre wahrscheinlich nicht nötig bei jeder Selektionsvariante eine solche Zusatzfunktion vorzusehen.
ich benutze aktuell ausschliesslich diffValue

Ich war auch nicht untätig und habe in das Modul ein Attribut "timeOlderThan" eingebaut was quasi das Gegenstück zu "timeDIffToNow" ist.
Wird dieses Attribut gesetzt, werden alle Selektionen bzw. Löschungen alle alten  Datensaätze in der DB BIS zu dem Zeitpunkt <aktueller Timestamp>-<timeOlderThan> (dynamisch kalkuliert) ausgeführt.

Also wenn das Attr auf z.B. 172800 (s) gesetzt ist, denn werden alle Datensätze in der DB die älter als 1 Tag sind und den sonstigen Bedingungen wie Device bzw. Reading entsprechen, gelöscht. 
Das geht bei aktuell noch relativ einfach über deleteOldDays, da ich alle Werte Tagesgenau kappe. Aktuell nutze ich zwei DBs, eine für die Daten die ich lediglich für 3 Tage aufbewahre (Charts) und dann noch eine die mir Zählerdaten für 2 Jahre aufbewahrt. Beide werden nachts mit Hilfe von deleteOldDays gekappt. Interessant wäre die neue Funktion für die Kurzzeitdaten... dann könnte ich bei einer einzelnen Datenbank bleiben, nur leider werden genau diese Kurzzeitdaten nicht mit DbRep ausgewertet.

Ich hänge die neue Version V3.5 wieder in den Eingangsthread und ergänze die Doku. Über das WE will ich die commandref noch beschreiben und das Modul mit dem Entwicklungsstand auch wieder einchecken.
Mal sehen ob ich in den nächsten Tagen zum Testen komme....
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 19 August 2016, 12:13:57
kann man die aktuelle Moduldatei auch direkt mit einem "sudo wget" runter laden? Ich habe gerade meinen Testrechner nicht in Reichweite und müsste die Datei remote via terminal auf's System bringen.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 August 2016, 13:02:28
Zitat
kann man die aktuelle Moduldatei auch direkt mit einem "sudo wget" runter laden?

Du kannst sie von meiner Synology runterladen:  https://gofile.me/2KVvT/mRprfHgn

Zitat
Das geht bei aktuell noch relativ einfach über deleteOldDays

Ja, ich weiß. Nur arbeitet timeOlderThan wie das gesamte Modul nonblocking. Außerdem kannst du die Selekt/Löschfunktion natürlich wieder auf ein spezielles device und/oder reading beschränken.

Zitat
nur leider werden genau diese Kurzzeitdaten nicht mit DbRep ausgewertet.

Damit meinst du sicherlich dass die Daten der Tabelle "history" betrachtet werden. Ich verwende ausschließlich die Tabelle "history" für alle Daten. Was ich nur kürzer in der DB haben möchte lösche ich halt wieder nach der Zeit x raus (mit dieser Funktion). Der Nutzen der Tabelle "current" ist mir bisher nicht so wirklich transparent geworden. Allerdings könnte ich durchaus die Funktionen wiederum über ein Attribut  wahlweise auf "current" oder "history" anwendbar machen.
War das mit "Kurzzeitdaten" gemeint ?

viele Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 19 August 2016, 13:47:26
Mit Kurzzeitdaten meine ich Daten die ich lediglich für 3-7 Tage speichere, da mich eine längere Darstellung nicht interessiert. Mit Langzeitdaten meine ich Daten die ich 2 Jahre lang speichere. Dazu gehören z.B. Zählerstände oder Verbrauchsdaten die im mit dem Vorjahr vergleiche.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 August 2016, 13:59:28
Hallo Karsten.

dann habe ich deine Anmerkung ...

Zitat
Interessant wäre die neue Funktion für die Kurzzeitdaten... dann könnte ich bei einer einzelnen Datenbank bleiben, nur leider werden genau diese Kurzzeitdaten nicht mit DbRep ausgewertet.

noch nicht richtig verstanden. Kannst du mit anderen Worten nochmal beschreiben was du damit meinst ?
Wenn ich es verstanden habe läßt sich bestimmt auch etwas machen.

Grüße,
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 19 August 2016, 16:18:50
Kurzzeitdaten: Daten die ich nur für kurze Zeit 3-7 Tage speichere
Langzeitdaten: werden für knapp 2 Jahre gespeichert

Situation:
Wenn ich alle Daten in eine DB schreiben würde, dann wären dass 3-4 unterschiedliche Readings die ich für einen längeren Zeitraum (2 Jahre) behalten möchte und den Rest lediglich für 3-7 Tage. Die 3-4 Langzeitdaten (die Readings dazu) sind recht einfach zu identifizieren (da überschaubar), die restlichen Kurzzeitdaten (die Readings dazu) separat aufzulisten ist schon etwas Arbeit.

Deshalb die 2 DBs
 DB 1: Zählerstände für 2 Jahre
 DB 2: der Rest (über include gemanagt); hier gehen auch der Einfachheit halber die selben Daten aus DB 1 mit aufgenommen, aber halt nur für die 3-7 Tage Ansicht

Wenn ich jetzt nur eine DB hätte und für die Langzeitdaten ein deleteOldDays durchführen würde, dann ist das für die Kurzzeitdaten unbedenklich, da eh für den Zeitraum nicht mehr von Interesse. Wäre die Situation jetzt genau umgekehrt... 3-4 Kurzzeitdaten und der Rest Langzeitdaten, und die 3-4 Kurzzeitdaten würden über DbRep ausgewertet, könnte ich innerhalb einer einzigen DB die Datenflut durch ein gezieltes delete (Deine neue Funktion) beheben. Leider ist es aber genau umgekehrt und ich möchte auch nicht für alle Kurzzeitdaten (die Readings dazu) ein DbRep einführen. Deshalb die beide DBs, die ich täglich mit deleteOldDays bearbeite.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 August 2016, 16:43:52
Ok, jetzt habe ich es verstanden, denke ich  ;)

Für mich heißt das , du hast (sehr) viele unterschiedliche device/reading-Kombinationen in der DB mit einem kurzen Soll-Lebenszyklus. Um diese selektiv zu löschen müßtest du dementprechend viele spezifische DbRep-Devices anlegen um dieses Sätze selektiv zu löschen. Das wäre in deinem Fall mit recht hohem (einmaligen) Aufwand versehen.

Adhoc fällt mir dazu ein dass ich die device/reading Spezifikation auf Regex (Like-Selektion in DB) umstellen könnte. Aber das habe ich mit Absicht bisher vermieden um nicht unbeabsichtigt falsche Datensätze mit zu berücksichtigen/zu löschen. Deswegen würde ich im DbRep gern darauf verzichten.

Allgemein habe ich noch vor eine Export/Import-Funktion zu implementieren, dass man Daten selektiv archivieren bzw. in eine andere Datenbank verschieben kann. Nur so als Aussicht.

viele Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 19 August 2016, 16:52:08
Das Problem mit den 2 DBs sollte jetzt nicht ein Problem sein was mit dem DbRep Modul gelöst werden sollte. Ansonsten hätte ich da noch etwas...

Ich hatte in meinen DbRep Instanzen noch ein User-Reading angelegt: currentPowerMeasurement. Kann es sein dass bei jeder Neukalkulation (diffValue) alle Readings ausnahmslos erst einmal gelöscht werden?
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 August 2016, 16:56:36
Zitat
Kann es sein dass bei jeder Neukalkulation (diffValue) alle Readings ausnahmslos erst einmal gelöscht werden?

Ja, das stimmt. Es sollen keine Readingleichen verbleiben. Die Db Selekt-Ergebnisse können sich ständig ändern. Daten gelöscht und Zeitgrenzen dynamisch verschoben werden. Aber ich sehe dein/das Problem...

EDIT. Wobei ... Userreadings ist ja ein Attribut und wird jedesmal neu berechnet. ???
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 19 August 2016, 17:28:18
EDIT. Wobei ... Userreadings ist ja ein Attribut und wird jedesmal neu berechnet. ???

wenn der Wert aus dem Originaldevice sich ändert und das notify anspricht. Aber das ist im Grunde nebensächlich.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 August 2016, 19:37:39
Ich könnte mir etwas überlegen das gewisse vorbestimmte Readings nicht gelöscht werden wenn so etwas gebraucht wird.
Bisher war es nicht im Fokus bzw. nötig.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 20 August 2016, 20:49:56
mir kam die Idee zu diesem Modul durch den Wunsch die Energiedaten meiner PV-Anlage auszuwerten.

Was für eine Anlage benutzt Du? Ich hatte vor das ganze mal im kleinen Stil in der Gartenhütte zu verbauen (natürlich ohne Einspeisung  ;) ins Stromnetz), nur suche ich noch nach einer geeigneten Installation die mir dann auch die Daten zum Haus rüber funkt bzw. mir erst mal in einer geeigneten Weise die Daten zur Verfügung stellt.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 August 2016, 10:16:49
Zitat
Was für eine Anlage benutzt Du?

Ich habe eine 5 kW -Anlage auf dem Dach. Dazu alles aus dem SMA-Programm, also STP-5000, SMA Energy Meter und Sunny Home Manager.
Wahrscheinlich eine Konstellation wie sie x-mal in D vorkommen wird und demzufolge auch nichts besonderes. Den STP und den EM konnte ich problemlos über die Speedwire Schnittstelle und die Module SMAEM bzw. SMAUtils mit SBFSpot in das Heimnetz bzw. FHEM integrieren (bin dabei auf das Modul SMAInverter umzustellen).

Ich habe einen Freund der sich eine kleine Inselanlage auch für den Garten angeschafft hat lädt damit eine Batterie die dann per Inverter 220V liefern soll. Er eruiert auch gerade wie sinnoll nutzbar das ist.
Das war ein Komplettprodukt, Name/Hersteller weiß ich momentan nicht. Allerdings hat er noch nichts über FHEM gehört. Deswegen weiß er/ich auch nicht inwieweit die Ladestation netzfähig ist und über ein Interface verfügt was man anzapfen könnte.

viele Grüße,
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Willi666 am 22 August 2016, 22:28:01
Hallo Heiko,

erstmal vielen Dank für das tolle Modul.
Ist genau das was ich gesucht habe.

Hätte da aber noch eine Frage. Wenn ich eine Auswertung diffValue fahren, dann erzeugt es als Reading immer einen Zeitstempel mit aktuellem Datum und Uhrzeit, wie z.B.:

2016-08-22_22-22-56__MeinStromzaehler__total_consumption__DIFF__all between timestamps

Wie kann ich dann auf das Variable Reading - z.B. beim Zuweisen auf einen Dummy - zugreifen, bzw. gibt es eine Möglichkeit die Uhrzeit wegzulassen?

Gruß
Willi

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 August 2016, 22:53:29
Hallo Willi,

das Reading in DbRep setzt sich immer zusammen durch Blöcke

<Datum/Zeit>__<Device aus DB>__<Reading aus DB>__<Funktion ....>   

also in deinem Fall

2016-08-22_22-22-56__MeinStromzaehler__total_consumption__DIFF__all between timestamps

Weglassen geht nicht prinzipiell, da der Timestamp am Anfang ein wichtiges Sortierkriterium in der Readingsdarstellung ist (siehe ein paar Beiträge weiter vorn, EDIT: #49), zumindest wenn mehrere Readings erzeugt werden.
Aber ich habe zwischen den Blöcken einen doppelten Unterstrich als Trenner eingeführt. Den kannst du z.B. für eine Splitfunktion bzw. Regex mit Userreadings nutzen, den du dann dem Dummy zuweist. Das sollte m.M. nach funktionieren, probiers mal aus.

EDIT: Das war jetzt nicht korrekt. Userreadings wahr schon ok, aber es dient nur dazu ein eigenes Reading aus dem vorhandenen zu erzeugen.
Also wird wohl der nächste Satz eher zutreffen ...

Ich könnte mir auch noch vorstellen ein Attr einzuführen mit dem der Nutzer bewußt den führenden Timestamp abschalten kann, sofern er sich klar darüber ist dass dann unter Umständen die Reihenfolge der Ergebnisse in der Darstellung nicht eingehalten wird.

Grüße
Heiko

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 August 2016, 18:51:37
Hallo Willi,

manchmal hilft es mal eine Nacht drüber zu schlafen ...

Zitat
Wie kann ich dann auf das Variable Reading - z.B. beim Zuweisen auf einen Dummy - zugreifen, bzw. gibt es eine Möglichkeit die Uhrzeit wegzulassen?

Im Prinzip kannst du über ein Notify die Readingswerte abgreifen und in dem Dummy speichern.
Hier als Beispiel:

# den Dummy definieren
define Dum.Rep dummy

# nun das Notify anlegen
define N.Dum.Rep notify Rep.SMAEM:(\d+).*MeinStromzaehler.* { fhem "setreading Dum.Rep DeinReading"." $EVTPART1"}


Sobald Events von dem DbRep-Device "Rep.SMAEM" mit dem Muster "Ziffer+irgendwas+Meinstromzaehler+irgendwas" eintreffen, wird das Reading "DeinReading" vom Dummy "Dum.Rep" auf den Readingswert des DbRep-Devices gesetzt.

Ich habe es getestet und zwei Screenshots angehängt. Das Konstrukt kann man sicher noch ausbauen und verfeinern auf die eigenen Belange.

Gruß
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Willi666 am 23 August 2016, 19:35:00
Hallo Heiko,

erstmal vielen Dank für Deine Hilfe  :).
Das auslesen bzw. der Zugriff mit das durch DbRep erzeugte Reading habe derzeit schon hinbekommen.
Merkwürdig ist nur, das ich unterschiedliche Namenstrukturen bekommen.

Einmal: 2016-08-23_19-22-34__MeinStromzaehler__total_consumption__DIFF__all between timestamps
Und das andere mal: 2016-08-23__MeinStromzaehler__total_consumption__DIFF__all between timestamps

Also es fehlt einmal der Zeitstempel, das Datum ist immer da. Hat mich als Anfänger hier etwas  verwirrt bzgl. Zugriff.
Werde mal Deinen Lösungsvorschlag test.
Perl ist nicht wirklich meine Stärke...

Gruß
Willi
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 August 2016, 23:15:12
Hallo Willi,

Zitat
Merkwürdig ist nur, das ich unterschiedliche Namenstrukturen bekommen.....

Der führende Timestamp wird immer dann komplett angegeben wenn neben dem Datum auch eine Uhrzeit für den entsprechenden Datensatz zur Verfügung steht. Also zum Beispiel bei "maxValue" wird der Timestamp vorangestellt der dem Datensatz mit dem Maximalwert in dem gewählten Zeitaggregationsintervall entspricht.

Zum Beispiel:
2016-04-24_22-21-45__GridConsumption__MAX__2016-04  3565.0000

bedeutet, dass am 2016-04-24 um 22:21:45 der Maximalwert des Energiebezuges von 3565 Watt in dem Aggregationszeitraum April 2016 (der letzte Block "2016-04") ermittelt wurde. Der Aggregationszeitraum ist in diesem Fall monatlich = "month".

Bei diffValue wird als führender Timestamp der des letzten berücksichtigten Datensatzes innerhalb des Aggregationszeitraums vorangestellt. Wenn keine Werte ermittelt werden konnten sieht es dann so aus:

2016-01-01__GridConsumption__DIFF__2016-01  -
Bei fetchrows ist es dann entsprechend der Timestamp des jeweiligen Datensatzes.
Irgenwann erstelle ich noch einen Wikieintrag zu dem Modul, aber das dauert noch etwas.  ;)

viele Grüße
Heiko

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Willi666 am 25 August 2016, 10:31:39
Hallo Heiko,

sorry, dass ich mich erst jetzt melde, und vielen Dank für Deine ausführlichen Erklärung.
Mit Deinem Tip $Eventpart1 habe ich es zum Laufen gebracht.

Gruß
Willi :D
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 27 August 2016, 13:47:49
Hallo,

folgendes ist mir gerade aufgefallen... das Modul versucht allem Anschein nach seit knapp 6 Minuten die Daten auszuwerten und läuft nicht in einen Timeout.

   Readings:
     2016-08-27 13:45:59   currentPowerMeasurement 46.13
     2016-08-27 13:39:52   state           running

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 August 2016, 17:09:01
Kam im Logfile auch keine Meldung bzgl. Timeout ?
Das Timeout bezieht sich auf  die Blocking-Routinen (DB-Operationen).  Ich verwende diesbezüglich die Standardfunktionen von Blocking.pm.
Habe das  Verhalten bei mir provoziert ... läuft  bei mir einwandfrei in ein Timeout wenn die SQL-Laufzeit den gesetzen Timeout überschreitet.
Kannst ja mal das Reading "sql_processing_time" (Attr showproctime setzen) vergleichen wenn die Funktion zu Ende geht (gehen sollte). Es gibt im Prinzip näherungsweise die in der Blocking Subroutine verbrauchte Zeit aus.

viele Grüße
Heiko
 
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 12:18:15
2016.08.28 11:55:32 1: Timeout for diffval_DoParse reached, terminated process 2408
DBD::SQLite::st fetchall_arrayref failed: database disk image is malformed at ./FHEM/93_DbRep.pm line 1242.

So, da haben wir eine Meldung, leider erneut mit dem "malformed" Problem. Starte ich den diffValue händisch, dann habe ich auch keine Probleme.

Ich werde mich jetzt erst mal dem malformed Problem widmen.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 12:19:36
solltest Du noch mal Langeweile verspüren, dann wäre ein Feature bei dem userReadings nicht gelöscht werden doch ganz hilfreich... wir hatten uns ja schon darüber unterhalten.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 12:40:49
Zitat
solltest Du noch mal Langeweile verspüren, dann wäre ein Feature bei dem userReadings nicht gelöscht werden doch ganz hilfreich... wir hatten uns ja schon darüber unterhalten.
ok, sehe ich bei Gelegenheit mit vor.

Grüße
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 13:18:56
ich hätte da noch einen Fahler in der Kalkulation:

2016-08-22_19-02-19__elektrische.Energie
0.01
2016-08-28 13:02:24

...

2016-08-28_12-49-28__elektrische.Energie
6.80
2016-08-28 13:02:24

ergibt:

2016-08-28_04-35-17__elektrische.Energie__2016-08
606.2000
2016-08-28 13:06:05

zur Info: insgesamt gibt es zum Reading 709 Einträge, oben stehen der erste und der letzte.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 13:31:05
Sehe den Fehler noch nicht.
Welche Funktion hast du ausgeführt und welcher Art ist "elektrische.Energie" ? D.h. ist es ein summarischer Wert den du regelmäßig vom Zähler abliest und in die DB einträgst ?
Wo liegen die Zeitgrenzen in der Auswertung , mit welcher Aggregation ?

Auf den ersten Blick sieht es aus wie die Funktion "sumValue" auf einen stetig steigenden Readingwert angewendet, was in diesem Kontext nicht richtig wäre.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 13:35:56
richtig, die Info fehlte: es ist diffValue

und ja, es ist ein summarischer Wert, der regelmässig in die DB eingetragen wird

6.80 - 0.01 sollte demnach 6.79 ergeben und nicht 606.2000

Nachtrag:

Ich bin gerade mit der Reparatur der DBs beschäftigt (malformed). Ich schicke Dir später mal ausführliche Informationen zu den Daten, der DbReg Definition und was sonst noch hilfreich sein könnte.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 13:48:47
Zitat
Ich schicke Dir später mal ausführliche Informationen zu den Daten, der DbReg Definition und was sonst noch hilfreich sein könnte.

Ja, mach mal. Habe es gerade bei mir über den Monat August nachgestellt mit diffValue und etotal vom STP5000. Keine Unkorrektheit feststellbar.
Du könntest mit den gleichen Rahmenbedingungen mal ein "fetchRows" fahren und das Ergebnis als File posten. Das sollte bei 700 Einträgen noch machbar sein.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 14:10:26
Internals:
   CFGFN
   DEF        DBlog_meterReading
   NAME       DbRep.elektrische.Energie.switchable.socket.storageCellar.fridge_Pwr
   NR         381
   STATE      connected &raquo; ProcTime: 0.0155 sec
   TYPE       DbRep
   Helper:
     DBLOGDEVICE DBlog_meterReading
   Readings:
     2016-08-28 13:10:08   2016-01-01__elektrische.Energie__2016-01 -
     2016-08-28 13:10:08   2016-02-01__elektrische.Energie__2016-02 -
     2016-08-28 13:10:08   2016-03-01__elektrische.Energie__2016-03 -
     2016-08-28 13:10:08   2016-04-01__elektrische.Energie__2016-04 -
     2016-08-28 13:10:08   2016-05-01__elektrische.Energie__2016-05 -
     2016-08-28 13:10:08   2016-06-01__elektrische.Energie__2016-06 -
     2016-08-28 13:10:08   2016-07-01__elektrische.Energie__2016-07 -
     2016-08-28 13:10:08   2016-08-28_04-35-17__elektrische.Energie__2016-08 606.2000
     2016-08-28 13:10:08   2016-09-01__elektrische.Energie__2016-09 -
     2016-08-28 13:10:08   2016-10-01__elektrische.Energie__2016-10 -
     2016-08-28 13:10:08   2016-11-01__elektrische.Energie__2016-11 -
     2016-08-28 13:10:08   2016-12-01__elektrische.Energie__2016-12 -
     2016-08-28 13:25:08   currentPowerMeasurement 0.75
     2016-08-28 13:10:08   sql_processing_time 0.0155
     2016-08-28 14:02:48   state           connected
   Dbloghash:
     CFGFN
     CONFIGURATION /opt/fhem/DBlog_meterReading.conf
     DBMODEL    SQLITE
     DEF        /opt/fhem/DBlog_meterReading.conf .*:(countHistory|energy_kWh|meterReading_kWh|meterReading_m3).*
     NAME       DBlog_meterReading
     NR         366
     NTFY_ORDER 50-DBlog_meterReading
     PID        3656
     REGEXP     .*:(countHistory|energy_kWh|meterReading_kWh|meterReading_m3).*
     STATE      connected
     TYPE       DbLog
     dbconn     SQLite:dbname=/opt/fhem/DBlog_meterReading.db
     dbuser
     Readings:
       2016-08-28 11:25:22   countCurrent    74
       2016-08-28 11:25:22   countHistory    1362918
       2016-08-28 03:00:01   lastRowsDeleted 0E0
       2016-08-28 14:02:43   state           connected
       2016-08-28 04:00:00   userCommand     "VACUUM history"
Attributes:
   DbLogExclude .*
   aggregation month
   alias      Schaltsteckdose - Vorratskeller (Kühlschrank) - DB-Report
   device     switchable.socket.storageCellar.fridge_Pwr
   event-on-change-reading .*
   group      Auswertung - Berechnung
   reading    energy_kWh
   readingNameMap elektrische.Energie
   room       03 Auswertung
   showproctime 1
   stateFormat state &raquo; ProcTime: sql_processing_time sec
   timeout    10
   timestamp_begin current_year_begin
   timestamp_end current_year_end
   userReadings currentPowerMeasurement
   verbose    0

das fetchRow:
   Readings:
     2016-08-28 14:04:25   2016-08-22_19-02-19__elektrische.Energie 0.01

     2016-08-28 14:04:25   2016-08-22_19-05-05__elektrische.Energie 0.02

     2016-08-28 14:04:25   2016-08-22_19-09-53__elektrische.Energie 0.03

     2016-08-28 14:04:25   2016-08-22_19-34-24__elektrische.Energie 0.04

     2016-08-28 14:04:25   2016-08-22_19-39-50__elektrische.Energie 0.05

     2016-08-28 14:04:25   2016-08-22_20-02-31__elektrische.Energie 0.06

     2016-08-28 14:04:25   2016-08-22_20-07-27__elektrische.Energie 0.07

     2016-08-28 14:04:25   2016-08-22_20-10-22__elektrische.Energie 0.08

     2016-08-28 14:04:25   2016-08-22_20-35-51__elektrische.Energie 0.09

     2016-08-28 14:04:25   2016-08-22_20-39-45__elektrische.Energie 0.10

     2016-08-28 14:04:25   2016-08-22_21-05-51__elektrische.Energie 0.11

     2016-08-28 14:04:25   2016-08-22_21-08-34__elektrische.Energie 0.12

     2016-08-28 14:04:25   2016-08-22_21-34-14__elektrische.Energie 0.13

     2016-08-28 14:04:25   2016-08-22_21-38-32__elektrische.Energie 0.14

     2016-08-28 14:04:25   2016-08-22_22-02-19__elektrische.Energie 0.15

     2016-08-28 14:04:25   2016-08-22_22-07-36__elektrische.Energie 0.16

     2016-08-28 14:04:25   2016-08-22_22-32-23__elektrische.Energie 0.17

     2016-08-28 14:04:25   2016-08-22_22-37-02__elektrische.Energie 0.18

     2016-08-28 14:04:25   2016-08-22_23-00-27__elektrische.Energie 0.19

     2016-08-28 14:04:25   2016-08-22_23-05-21__elektrische.Energie 0.20

     2016-08-28 14:04:25   2016-08-22_23-30-18__elektrische.Energie 0.21

     2016-08-28 14:04:25   2016-08-22_23-33-11__elektrische.Energie 0.22

     2016-08-28 14:04:25   2016-08-22_23-58-21__elektrische.Energie 0.23

     2016-08-28 14:04:25   2016-08-23_00-02-51__elektrische.Energie 0.24

     2016-08-28 14:04:25   2016-08-23_00-05-09__elektrische.Energie 0.25

     2016-08-28 14:04:25   2016-08-23_00-31-44__elektrische.Energie 0.26

     2016-08-28 14:04:25   2016-08-23_00-34-17__elektrische.Energie 0.00

     2016-08-28 14:04:25   2016-08-23_00-57-09__elektrische.Energie 0.01

     2016-08-28 14:04:25   2016-08-23_01-02-54__elektrische.Energie 0.02

     2016-08-28 14:04:25   2016-08-23_01-25-27__elektrische.Energie 0.03

     2016-08-28 14:04:25   2016-08-23_01-31-59__elektrische.Energie 0.05

     2016-08-28 14:04:25   2016-08-23_01-54-17__elektrische.Energie 0.06

     2016-08-28 14:04:25   2016-08-23_01-58-18__elektrische.Energie 0.07

     2016-08-28 14:04:25   2016-08-23_02-21-16__elektrische.Energie 0.08

     2016-08-28 14:04:25   2016-08-23_02-26-06__elektrische.Energie 0.09

     2016-08-28 14:04:25   2016-08-23_02-36-05__elektrische.Energie 0.10

     2016-08-28 14:04:25   2016-08-23_02-53-37__elektrische.Energie 0.11

     2016-08-28 14:04:25   2016-08-23_02-57-33__elektrische.Energie 0.12

     2016-08-28 14:04:25   2016-08-23_03-20-50__elektrische.Energie 0.13

     2016-08-28 14:04:25   2016-08-23_03-24-00__elektrische.Energie 0.14

     2016-08-28 14:04:25   2016-08-23_03-49-50__elektrische.Energie 0.15

     2016-08-28 14:04:25   2016-08-23_03-52-34__elektrische.Energie 0.16

     2016-08-28 14:04:25   2016-08-23_03-55-06__elektrische.Energie 0.17

     2016-08-28 14:04:25   2016-08-23_04-19-46__elektrische.Energie 0.18

     2016-08-28 14:04:25   2016-08-23_04-22-44__elektrische.Energie 0.19

     2016-08-28 14:04:25   2016-08-23_04-47-03__elektrische.Energie 0.20

     2016-08-28 14:04:25   2016-08-23_04-50-12__elektrische.Energie 0.21

     2016-08-28 14:04:25   2016-08-23_05-15-27__elektrische.Energie 0.22

     2016-08-28 14:04:25   2016-08-23_05-18-28__elektrische.Energie 0.23

     2016-08-28 14:04:25   2016-08-23_05-22-08__elektrische.Energie 0.24

     2016-08-28 14:04:25   2016-08-23_05-46-26__elektrische.Energie 0.25

     2016-08-28 14:04:25   2016-08-23_05-50-43__elektrische.Energie 0.26

     2016-08-28 14:04:25   2016-08-23_06-14-06__elektrische.Energie 0.27

     2016-08-28 14:04:25   2016-08-23_06-19-30__elektrische.Energie 0.28

     2016-08-28 14:04:25   2016-08-23_06-44-53__elektrische.Energie 0.29

     2016-08-28 14:04:25   2016-08-23_06-46-56__elektrische.Energie 0.30

     2016-08-28 14:04:25   2016-08-23_06-50-52__elektrische.Energie 0.31

     2016-08-28 14:04:25   2016-08-23_07-14-30__elektrische.Energie 0.32

     2016-08-28 14:04:25   2016-08-23_07-19-18__elektrische.Energie 0.33

     2016-08-28 14:04:25   2016-08-23_07-42-01__elektrische.Energie 0.34

     2016-08-28 14:04:25   2016-08-23_07-44-58__elektrische.Energie 0.35

     2016-08-28 14:04:25   2016-08-23_08-10-44__elektrische.Energie 0.36

     2016-08-28 14:04:25   2016-08-23_08-15-21__elektrische.Energie 0.37

     2016-08-28 14:04:25   2016-08-23_08-17-45__elektrische.Energie 0.38

     2016-08-28 14:04:25   2016-08-23_08-43-03__elektrische.Energie 0.39

     2016-08-28 14:04:25   2016-08-23_08-48-09__elektrische.Energie 0.40

     2016-08-28 14:04:25   2016-08-23_09-10-30__elektrische.Energie 0.41

     2016-08-28 14:04:25   2016-08-23_09-16-48__elektrische.Energie 0.42

     2016-08-28 14:04:25   2016-08-23_09-39-53__elektrische.Energie 0.43

     2016-08-28 14:04:25   2016-08-23_09-42-25__elektrische.Energie 0.44

     2016-08-28 14:04:25   2016-08-23_09-49-41__elektrische.Energie 0.45

     2016-08-28 14:04:25   2016-08-23_10-12-23__elektrische.Energie 0.46

     2016-08-28 14:04:25   2016-08-23_10-14-47__elektrische.Energie 0.47

     2016-08-28 14:04:25   2016-08-23_10-37-23__elektrische.Energie 0.48

     2016-08-28 14:04:25   2016-08-23_10-41-52__elektrische.Energie 0.49

     2016-08-28 14:04:25   2016-08-23_11-07-53__elektrische.Energie 0.50

     2016-08-28 14:04:25   2016-08-23_11-10-33__elektrische.Energie 0.51

     2016-08-28 14:04:25   2016-08-23_11-14-01__elektrische.Energie 0.52

     2016-08-28 14:04:25   2016-08-23_11-39-08__elektrische.Energie 0.53

     2016-08-28 14:04:25   2016-08-23_11-44-09__elektrische.Energie 0.54

     2016-08-28 14:04:25   2016-08-23_12-08-33__elektrische.Energie 0.55

     2016-08-28 14:04:25   2016-08-23_12-11-59__elektrische.Energie 0.56

     2016-08-28 14:04:25   2016-08-23_12-37-01__elektrische.Energie 0.57

     2016-08-28 14:04:25   2016-08-23_12-39-28__elektrische.Energie 0.58

     2016-08-28 14:04:25   2016-08-23_12-43-30__elektrische.Energie 0.59

     2016-08-28 14:04:25   2016-08-23_13-07-44__elektrische.Energie 0.60

     2016-08-28 14:04:25   2016-08-23_13-13-03__elektrische.Energie 0.61

     2016-08-28 14:04:25   2016-08-23_13-35-42__elektrische.Energie 0.62

     2016-08-28 14:04:25   2016-08-23_13-40-00__elektrische.Energie 0.63

     2016-08-28 14:04:25   2016-08-23_13-49-57__elektrische.Energie 0.64

     2016-08-28 14:04:25   2016-08-23_14-06-13__elektrische.Energie 0.65

     2016-08-28 14:04:25   2016-08-23_14-10-34__elektrische.Energie 0.66

     2016-08-28 14:04:25   2016-08-23_14-34-11__elektrische.Energie 0.67

     2016-08-28 14:04:25   2016-08-23_14-39-09__elektrische.Energie 0.68

     2016-08-28 14:04:25   2016-08-23_14-41-48__elektrische.Energie 0.69

     2016-08-28 14:04:25   2016-08-23_14-44-13__elektrische.Energie 0.70

     2016-08-28 14:04:25   2016-08-23_14-46-23__elektrische.Energie 0.71

     2016-08-28 14:04:25   2016-08-23_14-49-23__elektrische.Energie 0.72

     2016-08-28 14:04:25   2016-08-23_14-52-09__elektrische.Energie 0.73

     2016-08-28 14:04:25   2016-08-23_14-54-40__elektrische.Energie 0.74

     2016-08-28 14:04:25   2016-08-23_14-56-57__elektrische.Energie 0.75

     2016-08-28 14:04:25   2016-08-23_15-06-52__elektrische.Energie 0.76

     2016-08-28 14:04:25   2016-08-23_15-09-00__elektrische.Energie 0.77

     2016-08-28 14:04:25   2016-08-23_15-14-42__elektrische.Energie 0.78

     2016-08-28 14:04:25   2016-08-23_15-17-11__elektrische.Energie 0.79

     2016-08-28 14:04:25   2016-08-23_15-19-26__elektrische.Energie 0.80

     2016-08-28 14:04:25   2016-08-23_15-24-17__elektrische.Energie 0.81

     2016-08-28 14:04:25   2016-08-23_15-26-53__elektrische.Energie 0.82

     2016-08-28 14:04:25   2016-08-23_15-31-21__elektrische.Energie 0.83

     2016-08-28 14:04:25   2016-08-23_15-52-24__elektrische.Energie 0.84

     2016-08-28 14:04:25   2016-08-23_15-57-24__elektrische.Energie 0.85

     2016-08-28 14:04:25   2016-08-23_16-19-46__elektrische.Energie 0.86

     2016-08-28 14:04:25   2016-08-23_16-25-17__elektrische.Energie 0.87

     2016-08-28 14:04:25   2016-08-23_16-28-11__elektrische.Energie 0.88

     2016-08-28 14:04:25   2016-08-23_16-52-52__elektrische.Energie 0.89

     2016-08-28 14:04:25   2016-08-23_16-55-35__elektrische.Energie 0.90

     2016-08-28 14:04:25   2016-08-23_17-21-14__elektrische.Energie 0.91

     2016-08-28 14:04:25   2016-08-23_17-26-17__elektrische.Energie 0.92

     2016-08-28 14:04:25   2016-08-23_17-49-19__elektrische.Energie 0.93

     2016-08-28 14:04:25   2016-08-23_17-54-35__elektrische.Energie 0.94

     2016-08-28 14:04:25   2016-08-23_18-19-22__elektrische.Energie 0.95

     2016-08-28 14:04:25   2016-08-23_18-21-22__elektrische.Energie 0.96

     2016-08-28 14:04:25   2016-08-23_18-46-30__elektrische.Energie 0.97

     2016-08-28 14:04:25   2016-08-23_18-52-18__elektrische.Energie 0.98

     2016-08-28 14:04:25   2016-08-23_18-54-24__elektrische.Energie 0.99

     2016-08-28 14:04:25   2016-08-23_19-20-08__elektrische.Energie 1.00

     2016-08-28 14:04:25   2016-08-23_19-24-17__elektrische.Energie 1.01

     2016-08-28 14:04:25   2016-08-23_19-49-47__elektrische.Energie 1.02

     2016-08-28 14:04:25   2016-08-23_19-52-44__elektrische.Energie 1.03

     2016-08-28 14:04:25   2016-08-23_20-18-39__elektrische.Energie 1.04

     2016-08-28 14:04:25   2016-08-23_20-21-06__elektrische.Energie 1.05

     2016-08-28 14:04:25   2016-08-23_20-46-10__elektrische.Energie 1.06

     2016-08-28 14:04:25   2016-08-23_20-49-10__elektrische.Energie 1.07

     2016-08-28 14:04:25   2016-08-23_21-14-28__elektrische.Energie 1.08

     2016-08-28 14:04:25   2016-08-23_21-19-12__elektrische.Energie 1.09

     2016-08-28 14:04:25   2016-08-23_21-42-21__elektrische.Energie 1.10

     2016-08-28 14:04:25   2016-08-23_21-47-15__elektrische.Energie 1.11

     2016-08-28 14:04:25   2016-08-23_21-50-24__elektrische.Energie 1.12

     2016-08-28 14:04:25   2016-08-23_22-15-45__elektrische.Energie 1.13

     2016-08-28 14:04:25   2016-08-23_22-18-33__elektrische.Energie 1.14

     2016-08-28 14:04:25   2016-08-23_22-43-54__elektrische.Energie 1.15

     2016-08-28 14:04:25   2016-08-23_22-48-14__elektrische.Energie 1.16

     2016-08-28 14:04:25   2016-08-23_23-13-32__elektrische.Energie 1.17

     2016-08-28 14:04:25   2016-08-23_23-16-08__elektrische.Energie 1.18

     2016-08-28 14:04:25   2016-08-23_23-41-40__elektrische.Energie 1.19

     2016-08-28 14:04:25   2016-08-23_23-46-34__elektrische.Energie 1.20

     2016-08-28 14:04:25   2016-08-24_00-09-31__elektrische.Energie 1.21

     2016-08-28 14:04:25   2016-08-24_00-14-33__elektrische.Energie 1.22

     2016-08-28 14:04:25   2016-08-24_00-39-12__elektrische.Energie 1.23

     2016-08-28 14:04:25   2016-08-24_00-42-09__elektrische.Energie 1.24

     2016-08-28 14:04:25   2016-08-24_01-05-58__elektrische.Energie 1.25

     2016-08-28 14:04:25   2016-08-24_01-10-32__elektrische.Energie 1.26

     2016-08-28 14:04:25   2016-08-24_01-14-00__elektrische.Energie 1.27

     2016-08-28 14:04:25   2016-08-24_01-38-38__elektrische.Energie 1.28

     2016-08-28 14:04:25   2016-08-24_01-43-03__elektrische.Energie 1.29

     2016-08-28 14:04:25   2016-08-24_02-08-41__elektrische.Energie 1.30

     2016-08-28 14:04:25   2016-08-24_02-12-06__elektrische.Energie 1.31

     2016-08-28 14:04:25   2016-08-24_02-36-45__elektrische.Energie 1.32

     2016-08-28 14:04:25   2016-08-24_02-39-19__elektrische.Energie 1.33

     2016-08-28 14:04:25   2016-08-24_03-04-33__elektrische.Energie 1.34

     2016-08-28 14:04:25   2016-08-24_03-09-29__elektrische.Energie 1.35

     2016-08-28 14:04:25   2016-08-24_03-33-45__elektrische.Energie 1.27

     2016-08-28 14:04:25   2016-08-24_03-34-39__elektrische.Energie 1.36

     2016-08-28 14:04:25   2016-08-24_03-37-01__elektrische.Energie 1.37

     2016-08-28 14:04:25   2016-08-24_04-02-25__elektrische.Energie 1.38

     2016-08-28 14:04:25   2016-08-24_04-05-21__elektrische.Energie 1.39

     2016-08-28 14:04:25   2016-08-24_04-30-58__elektrische.Energie 1.40

     2016-08-28 14:04:25   2016-08-24_04-33-23__elektrische.Energie 1.41

     2016-08-28 14:04:25   2016-08-24_04-53-38__elektrische.Energie 1.42

     2016-08-28 14:04:25   2016-08-24_05-03-52__elektrische.Energie 1.43

     2016-08-28 14:04:25   2016-08-24_05-05-47__elektrische.Energie 1.44

     2016-08-28 14:04:25   2016-08-24_05-30-49__elektrische.Energie 1.45

     2016-08-28 14:04:25   2016-08-24_05-34-47__elektrische.Energie 1.46

     2016-08-28 14:04:25   2016-08-24_05-59-37__elektrische.Energie 1.47

     2016-08-28 14:04:25   2016-08-24_06-03-41__elektrische.Energie 1.48

     2016-08-28 14:04:25   2016-08-24_06-27-03__elektrische.Energie 1.49

     2016-08-28 14:04:25   2016-08-24_06-31-55__elektrische.Energie 1.50

     2016-08-28 14:04:25   2016-08-24_06-57-51__elektrische.Energie 1.51

     2016-08-28 14:04:25   2016-08-24_07-00-11__elektrische.Energie 1.52

     2016-08-28 14:04:25   2016-08-24_07-25-17__elektrische.Energie 1.53

     2016-08-28 14:04:25   2016-08-24_07-28-10__elektrische.Energie 1.54

     2016-08-28 14:04:25   2016-08-24_07-53-29__elektrische.Energie 1.55

     2016-08-28 14:04:25   2016-08-24_07-58-00__elektrische.Energie 1.56

     2016-08-28 14:04:25   2016-08-24_08-21-06__elektrische.Energie 1.57

     2016-08-28 14:04:25   2016-08-24_08-25-58__elektrische.Energie 1.58

     2016-08-28 14:04:25   2016-08-24_08-29-15__elektrische.Energie 1.59

     2016-08-28 14:04:25   2016-08-24_08-53-39__elektrische.Energie 1.60

     2016-08-28 14:04:25   2016-08-24_08-58-09__elektrische.Energie 1.61

     2016-08-28 14:04:25   2016-08-24_09-22-41__elektrische.Energie 1.62

     2016-08-28 14:04:25   2016-08-24_09-27-03__elektrische.Energie 1.63

     2016-08-28 14:04:25   2016-08-24_09-50-28__elektrische.Energie 1.64

     2016-08-28 14:04:25   2016-08-24_09-55-41__elektrische.Energie 1.65

     2016-08-28 14:04:25   2016-08-24_10-20-10__elektrische.Energie 1.66

     2016-08-28 14:04:25   2016-08-24_10-23-13__elektrische.Energie 1.67

     2016-08-28 14:04:25   2016-08-24_10-48-59__elektrische.Energie 1.68

     2016-08-28 14:04:25   2016-08-24_10-51-31__elektrische.Energie 1.69

     2016-08-28 14:04:25   2016-08-24_11-16-27__elektrische.Energie 1.70

     2016-08-28 14:04:25   2016-08-24_11-21-20__elektrische.Energie 1.71

     2016-08-28 14:04:25   2016-08-24_11-44-42__elektrische.Energie 1.72

     2016-08-28 14:04:25   2016-08-24_11-49-37__elektrische.Energie 1.73

     2016-08-28 14:04:25   2016-08-24_12-12-40__elektrische.Energie 1.74

     2016-08-28 14:04:25   2016-08-24_12-17-38__elektrische.Energie 1.75

     2016-08-28 14:04:25   2016-08-24_12-24-52__elektrische.Energie 1.76

     2016-08-28 14:04:25   2016-08-24_12-45-20__elektrische.Energie 1.77

     2016-08-28 14:04:25   2016-08-24_12-48-27__elektrische.Energie 1.78

     2016-08-28 14:04:25   2016-08-24_13-12-46__elektrische.Energie 1.79

     2016-08-28 14:04:25   2016-08-24_13-17-12__elektrische.Energie 1.80

     2016-08-28 14:04:25   2016-08-24_13-40-59__elektrische.Energie 1.81

     2016-08-28 14:04:25   2016-08-24_13-46-00__elektrische.Energie 1.82

     2016-08-28 14:04:25   2016-08-24_14-11-39__elektrische.Energie 1.83

     2016-08-28 14:04:25   2016-08-24_14-14-09__elektrische.Energie 1.84

     2016-08-28 14:04:25   2016-08-24_14-38-46__elektrische.Energie 1.85

     2016-08-28 14:04:25   2016-08-24_14-41-49__elektrische.Energie 1.86

     2016-08-28 14:04:25   2016-08-24_14-47-13__elektrische.Energie 1.87

     2016-08-28 14:04:25   2016-08-24_14-49-34__elektrische.Energie 1.88

     2016-08-28 14:04:25   2016-08-24_14-51-40__elektrische.Energie 1.89

     2016-08-28 14:04:25   2016-08-24_14-54-35__elektrische.Energie 1.90

     2016-08-28 14:04:25   2016-08-24_14-57-16__elektrische.Energie 1.91

     2016-08-28 14:04:25   2016-08-24_14-59-43__elektrische.Energie 1.92

     2016-08-28 14:04:25   2016-08-24_15-01-12__elektrische.Energie 1.93

     2016-08-28 14:04:25   2016-08-24_15-10-17__elektrische.Energie 1.94

     2016-08-28 14:04:25   2016-08-24_15-13-50__elektrische.Energie 1.95

     2016-08-28 14:04:25   2016-08-24_15-17-33__elektrische.Energie 1.96

     2016-08-28 14:04:25   2016-08-24_15-20-13__elektrische.Energie 1.97

     2016-08-28 14:04:25   2016-08-24_15-24-48__elektrische.Energie 1.98

     2016-08-28 14:04:25   2016-08-24_15-27-48__elektrische.Energie 1.99

     2016-08-28 14:04:25   2016-08-24_15-33-04__elektrische.Energie 2.00

     2016-08-28 14:04:25   2016-08-24_15-35-21__elektrische.Energie 2.01

     2016-08-28 14:04:25   2016-08-24_15-57-50__elektrische.Energie 2.02

     2016-08-28 14:04:25   2016-08-24_16-02-41__elektrische.Energie 2.03

     2016-08-28 14:04:25   2016-08-24_16-25-54__elektrische.Energie 2.04

     2016-08-28 14:04:25   2016-08-24_16-28-28__elektrische.Energie 2.05

     2016-08-28 14:04:25   2016-08-24_16-31-41__elektrische.Energie 2.06

     2016-08-28 14:04:25   2016-08-24_16-55-44__elektrische.Energie 2.07

     2016-08-28 14:04:25   2016-08-24_16-58-37__elektrische.Energie 2.08

     2016-08-28 14:04:25   2016-08-24_17-23-46__elektrische.Energie 2.09

     2016-08-28 14:04:25   2016-08-24_17-26-08__elektrische.Energie 2.10

     2016-08-28 14:04:25   2016-08-24_17-51-32__elektrische.Energie 2.11

     2016-08-28 14:04:25   2016-08-24_17-54-27__elektrische.Energie 2.12

     2016-08-28 14:04:25   2016-08-24_18-20-04__elektrische.Energie 2.13

     2016-08-28 14:04:25   2016-08-24_18-22-28__elektrische.Energie 2.14

     2016-08-28 14:04:25   2016-08-24_18-47-15__elektrische.Energie 2.15

     2016-08-28 14:04:25   2016-08-24_18-52-57__elektrische.Energie 2.16

     2016-08-28 14:04:25   2016-08-24_18-54-28__elektrische.Energie 2.17

     2016-08-28 14:04:25   2016-08-24_19-19-53__elektrische.Energie 2.18

     2016-08-28 14:04:25   2016-08-24_19-22-55__elektrische.Energie 2.19

     2016-08-28 14:04:25   2016-08-24_19-48-40__elektrische.Energie 2.20

     2016-08-28 14:04:25   2016-08-24_19-51-12__elektrische.Energie 2.21

     2016-08-28 14:04:25   2016-08-24_20-17-06__elektrische.Energie 2.22

     2016-08-28 14:04:25   2016-08-24_20-19-52__elektrische.Energie 2.23

     2016-08-28 14:04:25   2016-08-24_20-44-55__elektrische.Energie 2.24

     2016-08-28 14:04:25   2016-08-24_20-49-11__elektrische.Energie 2.25

     2016-08-28 14:04:25   2016-08-24_21-12-27__elektrische.Energie 2.26

     2016-08-28 14:04:25   2016-08-24_21-17-49__elektrische.Energie 2.27

     2016-08-28 14:04:25   2016-08-24_21-40-46__elektrische.Energie 2.28

     2016-08-28 14:04:25   2016-08-24_21-45-07__elektrische.Energie 2.29

     2016-08-28 14:04:25   2016-08-24_22-10-34__elektrische.Energie 2.30

     2016-08-28 14:04:25   2016-08-24_22-13-11__elektrische.Energie 2.31

     2016-08-28 14:04:25   2016-08-24_22-37-00__elektrische.Energie 2.32

     2016-08-28 14:04:25   2016-08-24_22-40-58__elektrische.Energie 2.33

     2016-08-28 14:04:25   2016-08-24_22-45-07__elektrische.Energie 2.34

     2016-08-28 14:04:25   2016-08-24_23-09-31__elektrische.Energie 2.35

     2016-08-28 14:04:25   2016-08-24_23-14-00__elektrische.Energie 2.36

     2016-08-28 14:04:25   2016-08-24_23-39-42__elektrische.Energie 2.37

     2016-08-28 14:04:25   2016-08-24_23-42-25__elektrische.Energie 2.38

     2016-08-28 14:04:25   2016-08-25_00-07-10__elektrische.Energie 2.39

     2016-08-28 14:04:25   2016-08-25_00-11-41__elektrische.Energie 2.40

     2016-08-28 14:04:25   2016-08-25_00-35-25__elektrische.Energie 2.41

     2016-08-28 14:04:25   2016-08-25_00-38-12__elektrische.Energie 2.42

     2016-08-28 14:04:25   2016-08-25_01-03-23__elektrische.Energie 2.43

     2016-08-28 14:04:25   2016-08-25_01-07-40__elektrische.Energie 2.44

     2016-08-28 14:04:25   2016-08-25_01-31-04__elektrische.Energie 2.45

     2016-08-28 14:04:25   2016-08-25_01-36-28__elektrische.Energie 2.46

     2016-08-28 14:04:25   2016-08-25_01-46-31__elektrische.Energie 2.47

     2016-08-28 14:04:25   2016-08-25_02-03-54__elektrische.Energie 2.48

     2016-08-28 14:04:25   2016-08-25_02-06-48__elektrische.Energie 2.49

     2016-08-28 14:04:25   2016-08-25_02-32-07__elektrische.Energie 2.50

     2016-08-28 14:04:25   2016-08-25_02-35-52__elektrische.Energie 2.51

     2016-08-28 14:04:25   2016-08-25_03-01-55__elektrische.Energie 2.52

     2016-08-28 14:04:25   2016-08-25_03-04-37__elektrische.Energie 2.53

     2016-08-28 14:04:25   2016-08-25_03-27-41__elektrische.Energie 2.54

     2016-08-28 14:04:25   2016-08-25_03-32-18__elektrische.Energie 2.55

     2016-08-28 14:04:25   2016-08-25_03-58-01__elektrische.Energie 2.56

     2016-08-28 14:04:25   2016-08-25_04-00-46__elektrische.Energie 2.57

     2016-08-28 14:04:25   2016-08-25_04-25-39__elektrische.Energie 2.58

     2016-08-28 14:04:25   2016-08-25_04-27-53__elektrische.Energie 2.59

     2016-08-28 14:04:25   2016-08-25_04-52-13__elektrische.Energie 2.60

     2016-08-28 14:04:25   2016-08-25_04-56-50__elektrische.Energie 2.61

     2016-08-28 14:04:25   2016-08-25_05-00-10__elektrische.Energie 2.62

     2016-08-28 14:04:25   2016-08-25_05-24-27__elektrische.Energie 2.63

     2016-08-28 14:04:25   2016-08-25_05-29-02__elektrische.Energie 2.64

     2016-08-28 14:04:25   2016-08-25_05-54-21__elektrische.Energie 2.65

     2016-08-28 14:04:25   2016-08-25_05-56-42__elektrische.Energie 2.66

     2016-08-28 14:04:25   2016-08-25_06-21-56__elektrische.Energie 2.67

     2016-08-28 14:04:25   2016-08-25_06-24-51__elektrische.Energie 2.68

     2016-08-28 14:04:25   2016-08-25_06-51-08__elektrische.Energie 2.69

     2016-08-28 14:04:25   2016-08-25_06-53-12__elektrische.Energie 2.70

     2016-08-28 14:04:25   2016-08-25_07-18-49__elektrische.Energie 2.71

     2016-08-28 14:04:25   2016-08-25_07-21-26__elektrische.Energie 2.72

     2016-08-28 14:04:25   2016-08-25_07-46-12__elektrische.Energie 2.73

     2016-08-28 14:04:25   2016-08-25_07-51-16__elektrische.Energie 2.74

     2016-08-28 14:04:25   2016-08-25_08-14-23__elektrische.Energie 2.75

     2016-08-28 14:04:25   2016-08-25_08-19-29__elektrische.Energie 2.76

     2016-08-28 14:04:25   2016-08-25_08-37-14__elektrische.Energie 2.77

     2016-08-28 14:04:25   2016-08-25_08-47-25__elektrische.Energie 2.78

     2016-08-28 14:04:25   2016-08-25_08-50-46__elektrische.Energie 2.79

     2016-08-28 14:04:25   2016-08-25_09-15-04__elektrische.Energie 2.80

     2016-08-28 14:04:25   2016-08-25_09-19-40__elektrische.Energie 2.81

     2016-08-28 14:04:25   2016-08-25_09-43-29__elektrische.Energie 2.82

     2016-08-28 14:04:25   2016-08-25_09-48-30__elektrische.Energie 2.83

     2016-08-28 14:04:25   2016-08-25_10-11-37__elektrische.Energie 2.84

     2016-08-28 14:04:25   2016-08-25_10-15-57__elektrische.Energie 2.85

     2016-08-28 14:04:25   2016-08-25_10-41-14__elektrische.Energie 2.86

     2016-08-28 14:04:25   2016-08-25_10-43-50__elektrische.Energie 2.87

     2016-08-28 14:04:25   2016-08-25_11-09-22__elektrische.Energie 2.88

     2016-08-28 14:04:25   2016-08-25_11-14-21__elektrische.Energie 2.89

     2016-08-28 14:04:25   2016-08-25_11-37-12__elektrische.Energie 2.90

     2016-08-28 14:04:25   2016-08-25_11-42-14__elektrische.Energie 2.91

     2016-08-28 14:04:25   2016-08-25_12-04-44__elektrische.Energie 2.92

     2016-08-28 14:04:25   2016-08-25_12-09-50__elektrische.Energie 2.93

     2016-08-28 14:04:25   2016-08-25_12-28-03__elektrische.Energie 2.94

     2016-08-28 14:04:25   2016-08-25_12-38-12__elektrische.Energie 2.95

     2016-08-28 14:04:25   2016-08-25_12-41-15__elektrische.Energie 2.96

     2016-08-28 14:04:25   2016-08-25_13-06-16__elektrische.Energie 2.97

     2016-08-28 14:04:25   2016-08-25_13-10-01__elektrische.Energie 2.98

     2016-08-28 14:04:25   2016-08-25_13-34-04__elektrische.Energie 2.99

     2016-08-28 14:04:25   2016-08-25_13-38-20__elektrische.Energie 3.00

     2016-08-28 14:04:25   2016-08-25_14-04-23__elektrische.Energie 3.01

     2016-08-28 14:04:25   2016-08-25_14-06-56__elektrische.Energie 3.02

     2016-08-28 14:04:25   2016-08-25_14-32-09__elektrische.Energie 3.03

     2016-08-28 14:04:25   2016-08-25_14-34-12__elektrische.Energie 3.04

     2016-08-28 14:04:25   2016-08-25_14-39-44__elektrische.Energie 3.05

     2016-08-28 14:04:25   2016-08-25_14-42-07__elektrische.Energie 3.06

     2016-08-28 14:04:25   2016-08-25_14-44-17__elektrische.Energie 3.07

     2016-08-28 14:04:25   2016-08-25_14-47-16__elektrische.Energie 3.08

     2016-08-28 14:04:25   2016-08-25_14-50-00__elektrische.Energie 3.09

     2016-08-28 14:04:25   2016-08-25_14-52-31__elektrische.Energie 3.10

     2016-08-28 14:04:25   2016-08-25_14-59-38__elektrische.Energie 3.11

     2016-08-28 14:04:25   2016-08-25_15-04-37__elektrische.Energie 3.12

     2016-08-28 14:04:25   2016-08-25_15-06-10__elektrische.Energie 3.13

     2016-08-28 14:04:25   2016-08-25_15-09-42__elektrische.Energie 3.14

     2016-08-28 14:04:25   2016-08-25_15-14-53__elektrische.Energie 3.15

     2016-08-28 14:04:25   2016-08-25_15-17-07__elektrische.Energie 3.16

     2016-08-28 14:04:25   2016-08-25_15-23-00__elektrische.Energie 3.17

     2016-08-28 14:04:25   2016-08-25_15-25-34__elektrische.Energie 3.18

     2016-08-28 14:04:25   2016-08-25_15-28-51__elektrische.Energie 3.19

     2016-08-28 14:04:25   2016-08-25_15-50-56__elektrische.Energie 3.20

     2016-08-28 14:04:25   2016-08-25_15-55-22__elektrische.Energie 3.21

     2016-08-28 14:04:25   2016-08-25_16-18-35__elektrische.Energie 3.22

     2016-08-28 14:04:25   2016-08-25_16-21-12__elektrische.Energie 3.23

     2016-08-28 14:04:25   2016-08-25_16-45-57__elektrische.Energie 3.24

     2016-08-28 14:04:25   2016-08-25_16-48-03__elektrische.Energie 3.25

     2016-08-28 14:04:25   2016-08-25_16-52-04__elektrische.Energie 3.26

     2016-08-28 14:04:25   2016-08-25_17-16-45__elektrische.Energie 3.27

     2016-08-28 14:04:25   2016-08-25_17-20-36__elektrische.Energie 3.28

     2016-08-28 14:04:25   2016-08-25_17-45-20__elektrische.Energie 3.29

     2016-08-28 14:04:25   2016-08-25_17-47-59__elektrische.Energie 3.30

     2016-08-28 14:04:25   2016-08-25_18-13-04__elektrische.Energie 3.31

     2016-08-28 14:04:25   2016-08-25_18-18-11__elektrische.Energie 3.32

     2016-08-28 14:04:25   2016-08-25_18-40-30__elektrische.Energie 3.33

     2016-08-28 14:04:25   2016-08-25_18-45-40__elektrische.Energie 3.34

     2016-08-28 14:04:25   2016-08-25_19-08-43__elektrische.Energie 3.35

     2016-08-28 14:04:25   2016-08-25_19-13-56__elektrische.Energie 3.36

     2016-08-28 14:04:25   2016-08-25_19-36-40__elektrische.Energie 3.37

     2016-08-28 14:04:25   2016-08-25_19-41-54__elektrische.Energie 3.38

     2016-08-28 14:04:25   2016-08-25_19-44-47__elektrische.Energie 3.39

     2016-08-28 14:04:25   2016-08-25_20-09-36__elektrische.Energie 3.40

     2016-08-28 14:04:25   2016-08-25_20-13-40__elektrische.Energie 3.41

     2016-08-28 14:04:25   2016-08-25_20-38-04__elektrische.Energie 3.42

     2016-08-28 14:04:25   2016-08-25_20-42-27__elektrische.Energie 3.43

     2016-08-28 14:04:25   2016-08-25_21-08-03__elektrische.Energie 3.44

     2016-08-28 14:04:25   2016-08-25_21-10-40__elektrische.Energie 3.45

     2016-08-28 14:04:25   2016-08-25_21-35-26__elektrische.Energie 3.46

     2016-08-28 14:04:25   2016-08-25_21-40-23__elektrische.Energie 3.47

     2016-08-28 14:04:25   2016-08-25_22-03-36__elektrische.Energie 3.48

     2016-08-28 14:04:25   2016-08-25_22-08-42__elektrische.Energie 3.49

     2016-08-28 14:04:25   2016-08-25_22-31-28__elektrische.Energie 3.50

     2016-08-28 14:04:25   2016-08-25_22-36-37__elektrische.Energie 3.51

     2016-08-28 14:04:25   2016-08-25_23-01-47__elektrische.Energie 3.52

     2016-08-28 14:04:25   2016-08-25_23-04-15__elektrische.Energie 3.53

     2016-08-28 14:04:25   2016-08-25_23-07-13__elektrische.Energie 3.54

     2016-08-28 14:04:25   2016-08-25_23-32-40__elektrische.Energie 3.55

     2016-08-28 14:04:25   2016-08-25_23-35-27__elektrische.Energie 3.56

     2016-08-28 14:04:25   2016-08-26_00-00-47__elektrische.Energie 3.57

     2016-08-28 14:04:25   2016-08-26_00-05-02__elektrische.Energie 3.58

     2016-08-28 14:04:25   2016-08-26_00-30-24__elektrische.Energie 3.59

     2016-08-28 14:04:25   2016-08-26_00-32-59__elektrische.Energie 3.60

     2016-08-28 14:04:25   2016-08-26_00-58-30__elektrische.Energie 3.61

     2016-08-28 14:04:25   2016-08-26_01-00-35__elektrische.Energie 3.62

     2016-08-28 14:04:25   2016-08-26_01-26-20__elektrische.Energie 3.63

     2016-08-28 14:04:25   2016-08-26_01-28-58__elektrische.Energie 3.64

     2016-08-28 14:04:25   2016-08-26_01-53-51__elektrische.Energie 3.65

     2016-08-28 14:04:25   2016-08-26_01-58-56__elektrische.Energie 3.66

     2016-08-28 14:04:25   2016-08-26_02-14-49__elektrische.Energie 3.67

     2016-08-28 14:04:25   2016-08-26_02-27-18__elektrische.Energie 3.68

     2016-08-28 14:04:25   2016-08-26_02-29-30__elektrische.Energie 3.69

     2016-08-28 14:04:25   2016-08-26_02-55-22__elektrische.Energie 3.70

     2016-08-28 14:04:25   2016-08-26_02-58-07__elektrische.Energie 3.71

     2016-08-28 14:04:25   2016-08-26_03-23-09__elektrische.Energie 3.72

     2016-08-28 14:04:25   2016-08-26_03-27-24__elektrische.Energie 3.73

     2016-08-28 14:04:25   2016-08-26_03-50-39__elektrische.Energie 3.74

     2016-08-28 14:04:25   2016-08-26_03-56-01__elektrische.Energie 3.75

     2016-08-28 14:04:25   2016-08-26_04-18-55__elektrische.Energie 3.76

     2016-08-28 14:04:25   2016-08-26_04-24-45__elektrische.Energie 3.77

     2016-08-28 14:04:25   2016-08-26_04-47-35__elektrische.Energie 3.78

     2016-08-28 14:04:25   2016-08-26_04-52-23__elektrische.Energie 3.79

     2016-08-28 14:04:25   2016-08-26_05-16-54__elektrische.Energie 3.80

     2016-08-28 14:04:25   2016-08-26_05-19-44__elektrische.Energie 3.81

     2016-08-28 14:04:25   2016-08-26_05-23-08__elektrische.Energie 3.82

     2016-08-28 14:04:25   2016-08-26_05-47-52__elektrische.Energie 3.83

     2016-08-28 14:04:25   2016-08-26_05-52-02__elektrische.Energie 3.84

     2016-08-28 14:04:25   2016-08-26_06-18-21__elektrische.Energie 3.85

     2016-08-28 14:04:25   2016-08-26_06-20-45__elektrische.Energie 3.86

     2016-08-28 14:04:25   2016-08-26_06-25-37__elektrische.Energie 3.77

     2016-08-28 14:04:25   2016-08-26_06-25-54__elektrische.Energie 3.86

     2016-08-28 14:04:25   2016-08-26_06-45-24__elektrische.Energie 3.87

     2016-08-28 14:04:25   2016-08-26_06-48-21__elektrische.Energie 3.88

     2016-08-28 14:04:25   2016-08-26_07-14-17__elektrische.Energie 3.89

     2016-08-28 14:04:25   2016-08-26_07-16-44__elektrische.Energie 3.90

     2016-08-28 14:04:25   2016-08-26_07-41-49__elektrische.Energie 3.91

     2016-08-28 14:04:25   2016-08-26_07-44-50__elektrische.Energie 3.92

     2016-08-28 14:04:25   2016-08-26_08-10-08__elektrische.Energie 3.93

     2016-08-28 14:04:25   2016-08-26_08-14-53__elektrische.Energie 3.94

     2016-08-28 14:04:25   2016-08-26_08-40-09__elektrische.Energie 3.95

     2016-08-28 14:04:25   2016-08-26_08-42-57__elektrische.Energie 3.96

     2016-08-28 14:04:25   2016-08-26_09-05-55__elektrische.Energie 3.97

     2016-08-28 14:04:25   2016-08-26_09-10-44__elektrische.Energie 3.98

     2016-08-28 14:04:25   2016-08-26_09-35-23__elektrische.Energie 3.99

     2016-08-28 14:04:25   2016-08-26_09-38-15__elektrische.Energie 4.00

     2016-08-28 14:04:25   2016-08-26_09-42-09__elektrische.Energie 4.01

     2016-08-28 14:04:25   2016-08-26_10-06-31__elektrische.Energie 4.02

     2016-08-28 14:04:25   2016-08-26_10-10-57__elektrische.Energie 4.03

     2016-08-28 14:04:25   2016-08-26_10-37-10__elektrische.Energie 4.04

     2016-08-28 14:04:25   2016-08-26_10-39-35__elektrische.Energie 4.05

     2016-08-28 14:04:25   2016-08-26_11-04-22__elektrische.Energie 4.06

     2016-08-28 14:04:25   2016-08-26_11-07-20__elektrische.Energie 4.07

     2016-08-28 14:04:25   2016-08-26_11-32-20__elektrische.Energie 4.08

     2016-08-28 14:04:25   2016-08-26_11-37-00__elektrische.Energie 4.09

     2016-08-28 14:04:25   2016-08-26_12-00-01__elektrische.Energie 4.10

     2016-08-28 14:04:25   2016-08-26_12-05-49__elektrische.Energie 4.11

     2016-08-28 14:04:25   2016-08-26_12-28-29__elektrische.Energie 4.12

     2016-08-28 14:04:25   2016-08-26_12-33-15__elektrische.Energie 4.13

     2016-08-28 14:04:25   2016-08-26_12-58-39__elektrische.Energie 4.14

     2016-08-28 14:04:25   2016-08-26_13-01-28__elektrische.Energie 4.15

     2016-08-28 14:04:25   2016-08-26_13-24-37__elektrische.Energie 4.16

     2016-08-28 14:04:25   2016-08-26_13-29-25__elektrische.Energie 4.17

     2016-08-28 14:04:25   2016-08-26_13-32-35__elektrische.Energie 4.18

     2016-08-28 14:04:25   2016-08-26_13-57-04__elektrische.Energie 4.19

     2016-08-28 14:04:25   2016-08-26_14-01-19__elektrische.Energie 4.20

     2016-08-28 14:04:25   2016-08-26_14-26-32__elektrische.Energie 4.21

     2016-08-28 14:04:25   2016-08-26_14-27-02__elektrische.Energie 4.12

     2016-08-28 14:04:25   2016-08-26_14-29-28__elektrische.Energie 4.22

     2016-08-28 14:04:25   2016-08-26_14-32-10__elektrische.Energie 4.23

     2016-08-28 14:04:25   2016-08-26_14-34-38__elektrische.Energie 4.24

     2016-08-28 14:04:25   2016-08-26_14-39-53__elektrische.Energie 4.25

     2016-08-28 14:04:25   2016-08-26_14-42-41__elektrische.Energie 4.27

     2016-08-28 14:04:25   2016-08-26_14-47-08__elektrische.Energie 4.28

     2016-08-28 14:04:25   2016-08-26_14-55-14__elektrische.Energie 4.29

     2016-08-28 14:04:25   2016-08-26_14-57-39__elektrische.Energie 4.30

     2016-08-28 14:04:25   2016-08-26_15-02-51__elektrische.Energie 4.31

     2016-08-28 14:04:25   2016-08-26_15-05-38__elektrische.Energie 4.32

     2016-08-28 14:04:25   2016-08-26_15-08-10__elektrische.Energie 4.33

     2016-08-28 14:04:25   2016-08-26_15-11-11__elektrische.Energie 4.34

     2016-08-28 14:04:25   2016-08-26_15-16-32__elektrische.Energie 4.35

     2016-08-28 14:04:25   2016-08-26_15-20-55__elektrische.Energie 4.36

     2016-08-28 14:04:25   2016-08-26_15-41-37__elektrische.Energie 4.37

     2016-08-28 14:04:25   2016-08-26_15-46-32__elektrische.Energie 4.38

     2016-08-28 14:04:25   2016-08-26_15-48-52__elektrische.Energie 4.39

     2016-08-28 14:04:25   2016-08-26_16-11-34__elektrische.Energie 4.40

     2016-08-28 14:04:25   2016-08-26_16-16-03__elektrische.Energie 4.41

     2016-08-28 14:04:25   2016-08-26_16-39-11__elektrische.Energie 4.42

     2016-08-28 14:04:25   2016-08-26_16-44-46__elektrische.Energie 4.43

     2016-08-28 14:04:25   2016-08-26_17-07-35__elektrische.Energie 4.44

     2016-08-28 14:04:25   2016-08-26_17-09-59__elektrische.Energie 4.45

     2016-08-28 14:04:25   2016-08-26_17-13-52__elektrische.Energie 4.46

     2016-08-28 14:04:25   2016-08-26_17-40-18__elektrische.Energie 4.47

     2016-08-28 14:04:25   2016-08-26_17-42-32__elektrische.Energie 4.48

     2016-08-28 14:04:25   2016-08-26_18-05-58__elektrische.Energie 4.49

     2016-08-28 14:04:25   2016-08-26_18-11-12__elektrische.Energie 4.50

     2016-08-28 14:04:25   2016-08-26_18-36-49__elektrische.Energie 4.51

     2016-08-28 14:04:25   2016-08-26_18-39-21__elektrische.Energie 4.52

     2016-08-28 14:04:25   2016-08-26_19-04-07__elektrische.Energie 4.53

     2016-08-28 14:04:25   2016-08-26_19-08-58__elektrische.Energie 4.54

     2016-08-28 14:04:25   2016-08-26_19-32-12__elektrische.Energie 4.55

     2016-08-28 14:04:25   2016-08-26_19-34-45__elektrische.Energie 4.56

     2016-08-28 14:04:25   2016-08-26_19-59-59__elektrische.Energie 4.57

     2016-08-28 14:04:25   2016-08-26_20-04-55__elektrische.Energie 4.58

     2016-08-28 14:04:25   2016-08-26_20-27-25__elektrische.Energie 4.59

     2016-08-28 14:04:25   2016-08-26_20-32-28__elektrische.Energie 4.60

     2016-08-28 14:04:25   2016-08-26_20-35-37__elektrische.Energie 4.61

     2016-08-28 14:04:25   2016-08-26_21-00-47__elektrische.Energie 4.62

     2016-08-28 14:04:25   2016-08-26_21-04-30__elektrische.Energie 4.63

     2016-08-28 14:04:25   2016-08-26_21-28-49__elektrische.Energie 4.64

     2016-08-28 14:04:25   2016-08-26_21-33-18__elektrische.Energie 4.65

     2016-08-28 14:04:25   2016-08-26_21-56-34__elektrische.Energie 4.66

     2016-08-28 14:04:25   2016-08-26_22-01-47__elektrische.Energie 4.67

     2016-08-28 14:04:25   2016-08-26_22-26-15__elektrische.Energie 4.68

     2016-08-28 14:04:25   2016-08-26_22-29-18__elektrische.Energie 4.69

     2016-08-28 14:04:25   2016-08-26_22-55-03__elektrische.Energie 4.70

     2016-08-28 14:04:25   2016-08-26_22-57-35__elektrische.Energie 4.71

     2016-08-28 14:04:25   2016-08-26_23-22-29__elektrische.Energie 4.72

     2016-08-28 14:04:25   2016-08-26_23-24-31__elektrische.Energie 4.73

     2016-08-28 14:04:25   2016-08-26_23-28-22__elektrische.Energie 4.74

     2016-08-28 14:04:25   2016-08-26_23-53-17__elektrische.Energie 4.75

     2016-08-28 14:04:25   2016-08-26_23-57-10__elektrische.Energie 4.76

     2016-08-28 14:04:25   2016-08-27_00-20-43__elektrische.Energie 4.77

     2016-08-28 14:04:25   2016-08-27_00-25-57__elektrische.Energie 4.78

     2016-08-28 14:04:25   2016-08-27_00-48-55__elektrische.Energie 4.79

     2016-08-28 14:04:25   2016-08-27_00-53-27__elektrische.Energie 4.80

     2016-08-28 14:04:25   2016-08-27_01-18-43__elektrische.Energie 4.81

     2016-08-28 14:04:25   2016-08-27_01-21-25__elektrische.Energie 4.82

     2016-08-28 14:04:25   2016-08-27_01-46-54__elektrische.Energie 4.83

     2016-08-28 14:04:25   2016-08-27_01-49-05__elektrische.Energie 4.84

     2016-08-28 14:04:25   2016-08-27_02-13-07__elektrische.Energie 4.85

     2016-08-28 14:04:25   2016-08-27_02-18-07__elektrische.Energie 4.86

     2016-08-28 14:04:25   2016-08-27_02-21-09__elektrische.Energie 4.87

     2016-08-28 14:04:25   2016-08-27_02-45-54__elektrische.Energie 4.88

     2016-08-28 14:04:25   2016-08-27_02-49-53__elektrische.Energie 4.89

     2016-08-28 14:04:25   2016-08-27_03-13-23__elektrische.Energie 4.90

     2016-08-28 14:04:25   2016-08-27_03-18-39__elektrische.Energie 4.91

     2016-08-28 14:04:25   2016-08-27_03-41-39__elektrische.Energie 4.92

     2016-08-28 14:04:25   2016-08-27_03-46-57__elektrische.Energie 4.93

     2016-08-28 14:04:25   2016-08-27_04-09-37__elektrische.Energie 4.94

     2016-08-28 14:04:25   2016-08-27_04-13-55__elektrische.Energie 4.95

     2016-08-28 14:04:25   2016-08-27_04-37-19__elektrische.Energie 4.96

     2016-08-28 14:04:25   2016-08-27_04-42-43__elektrische.Energie 4.97

     2016-08-28 14:04:25   2016-08-27_04-45-03__elektrische.Energie 4.98

     2016-08-28 14:04:25   2016-08-27_05-10-10__elektrische.Energie 4.99

     2016-08-28 14:04:25   2016-08-27_05-13-04__elektrische.Energie 5.00

     2016-08-28 14:04:25   2016-08-27_05-38-24__elektrische.Energie 5.01

     2016-08-28 14:04:25   2016-08-27_05-42-30__elektrische.Energie 5.02

     2016-08-28 14:04:25   2016-08-27_06-05-16__elektrische.Energie 5.03

     2016-08-28 14:04:25   2016-08-27_06-10-54__elektrische.Energie 5.04

     2016-08-28 14:04:25   2016-08-27_06-33-59__elektrische.Energie 5.05

     2016-08-28 14:04:25   2016-08-27_06-38-36__elektrische.Energie 5.06

     2016-08-28 14:04:25   2016-08-27_07-04-20__elektrische.Energie 5.07

     2016-08-28 14:04:25   2016-08-27_07-07-05__elektrische.Energie 5.08

     2016-08-28 14:04:25   2016-08-27_07-31-58__elektrische.Energie 5.09

     2016-08-28 14:04:25   2016-08-27_07-34-12__elektrische.Energie 5.10

     2016-08-28 14:04:25   2016-08-27_07-52-43__elektrische.Energie 5.11

     2016-08-28 14:04:25   2016-08-27_08-03-10__elektrische.Energie 5.12

     2016-08-28 14:04:25   2016-08-27_08-05-43__elektrische.Energie 5.13

     2016-08-28 14:04:25   2016-08-27_08-30-47__elektrische.Energie 5.14

     2016-08-28 14:04:25   2016-08-27_08-34-45__elektrische.Energie 5.15

     2016-08-28 14:04:25   2016-08-27_08-58-07__elektrische.Energie 5.16

     2016-08-28 14:04:25   2016-08-27_09-03-04__elektrische.Energie 5.17

     2016-08-28 14:04:25   2016-08-27_09-26-14__elektrische.Energie 5.18

     2016-08-28 14:04:25   2016-08-27_09-31-13__elektrische.Energie 5.19

     2016-08-28 14:04:25   2016-08-27_09-56-41__elektrische.Energie 5.20

     2016-08-28 14:04:25   2016-08-27_09-59-05__elektrische.Energie 5.21

     2016-08-28 14:04:25   2016-08-27_10-23-42__elektrische.Energie 5.22

     2016-08-28 14:04:25   2016-08-27_10-26-39__elektrische.Energie 5.23

     2016-08-28 14:04:25   2016-08-27_10-51-57__elektrische.Energie 5.24

     2016-08-28 14:04:25   2016-08-27_10-55-01__elektrische.Energie 5.25

     2016-08-28 14:04:25   2016-08-27_10-59-03__elektrische.Energie 5.26

     2016-08-28 14:04:25   2016-08-27_11-23-05__elektrische.Energie 5.27

     2016-08-28 14:04:25   2016-08-27_11-27-27__elektrische.Energie 5.28

     2016-08-28 14:04:25   2016-08-27_11-50-52__elektrische.Energie 5.29

     2016-08-28 14:04:25   2016-08-27_11-53-07__elektrische.Energie 5.30

     2016-08-28 14:04:25   2016-08-27_12-15-19__elektrische.Energie 5.31

     2016-08-28 14:04:25   2016-08-27_12-21-10__elektrische.Energie 5.32

     2016-08-28 14:04:25   2016-08-27_12-23-44__elektrische.Energie 5.33

     2016-08-28 14:04:25   2016-08-27_12-46-38__elektrische.Energie 5.34

     2016-08-28 14:04:25   2016-08-27_12-52-28__elektrische.Energie 5.35

     2016-08-28 14:04:25   2016-08-27_12-54-35__elektrische.Energie 5.36

     2016-08-28 14:04:25   2016-08-27_13-17-49__elektrische.Energie 5.37

     2016-08-28 14:04:25   2016-08-27_13-22-09__elektrische.Energie 5.38

     2016-08-28 14:04:25   2016-08-27_13-44-37__elektrische.Energie 5.39

     2016-08-28 14:04:25   2016-08-27_13-47-27__elektrische.Energie 5.40

     2016-08-28 14:04:25   2016-08-27_13-51-23__elektrische.Energie 5.41

     2016-08-28 14:04:25   2016-08-27_13-54-31__elektrische.Energie 5.42

     2016-08-28 14:04:25   2016-08-27_13-57-28__elektrische.Energie 5.43

     2016-08-28 14:04:25   2016-08-27_14-00-10__elektrische.Energie 5.44

     2016-08-28 14:04:25   2016-08-27_14-02-37__elektrische.Energie 5.45

     2016-08-28 14:04:25   2016-08-27_14-04-51__elektrische.Energie 5.46

     2016-08-28 14:04:25   2016-08-27_14-07-53__elektrische.Energie 5.47

     2016-08-28 14:04:25   2016-08-27_14-17-40__elektrische.Energie 5.48

     2016-08-28 14:04:25   2016-08-27_14-20-35__elektrische.Energie 5.49

     2016-08-28 14:04:25   2016-08-27_14-23-15__elektrische.Energie 5.50

     2016-08-28 14:04:25   2016-08-27_14-27-52__elektrische.Energie 5.51

     2016-08-28 14:04:25   2016-08-27_14-30-53__elektrische.Energie 5.52

     2016-08-28 14:04:25   2016-08-27_14-33-40__elektrische.Energie 5.53

     2016-08-28 14:04:25   2016-08-27_14-38-29__elektrische.Energie 5.54

     2016-08-28 14:04:25   2016-08-27_14-43-26__elektrische.Energie 5.55

     2016-08-28 14:04:25   2016-08-27_14-46-04__elektrische.Energie 5.56

     2016-08-28 14:04:25   2016-08-27_15-06-00__elektrische.Energie 5.57

     2016-08-28 14:04:25   2016-08-27_15-10-59__elektrische.Energie 5.58

     2016-08-28 14:04:25   2016-08-27_15-15-25__elektrische.Energie 5.59

     2016-08-28 14:04:25   2016-08-27_15-36-24__elektrische.Energie 5.60

     2016-08-28 14:04:25   2016-08-27_15-42-00__elektrische.Energie 5.61

     2016-08-28 14:04:25   2016-08-27_15-43-57__elektrische.Energie 5.62

     2016-08-28 14:04:25   2016-08-27_16-07-22__elektrische.Energie 5.63

     2016-08-28 14:04:25   2016-08-27_16-12-04__elektrische.Energie 5.64

     2016-08-28 14:04:25   2016-08-27_16-35-08__elektrische.Energie 5.65

     2016-08-28 14:04:25   2016-08-27_16-37-52__elektrische.Energie 5.66

     2016-08-28 14:04:25   2016-08-27_16-40-21__elektrische.Energie 5.67

     2016-08-28 14:04:25   2016-08-27_17-04-49__elektrische.Energie 5.68

     2016-08-28 14:04:25   2016-08-27_17-07-52__elektrische.Energie 5.69

     2016-08-28 14:04:25   2016-08-27_17-30-51__elektrische.Energie 5.70

     2016-08-28 14:04:25   2016-08-27_17-36-10__elektrische.Energie 5.71

     2016-08-28 14:04:25   2016-08-27_17-38-28__elektrische.Energie 5.72

     2016-08-28 14:04:25   2016-08-27_17-58-49__elektrische.Energie 5.73

     2016-08-28 14:04:25   2016-08-27_18-01-05__elektrische.Energie 5.74

     2016-08-28 14:04:25   2016-08-27_18-05-04__elektrische.Energie 5.75

     2016-08-28 14:04:25   2016-08-27_18-29-19__elektrische.Energie 5.76

     2016-08-28 14:04:25   2016-08-27_18-31-54__elektrische.Energie 5.77

     2016-08-28 14:04:25   2016-08-27_18-35-06__elektrische.Energie 5.78

     2016-08-28 14:04:25   2016-08-27_18-57-16__elektrische.Energie 5.79

     2016-08-28 14:04:25   2016-08-27_19-02-14__elektrische.Energie 5.80

     2016-08-28 14:04:25   2016-08-27_19-04-32__elektrische.Energie 5.81

     2016-08-28 14:04:25   2016-08-27_19-27-33__elektrische.Energie 5.82

     2016-08-28 14:04:25   2016-08-27_19-32-05__elektrische.Energie 5.83

     2016-08-28 14:04:25   2016-08-27_19-54-25__elektrische.Energie 5.84

     2016-08-28 14:04:25   2016-08-27_19-57-21__elektrische.Energie 5.85

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 14:33:32
Danke für die Infos. Ich stelle das mit meiner Test-Db später mal nach. Dauert ein bisschen. Melde mich wieder ...
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 17:48:37
Jetzt habe ich die Situation nachgestellt. An der Berechnung liegt es nicht. Die Differenz wird richtig berechnet.
ABER ich habe eine Theorie die ich erfolgreich simulieren konnte.
Der Device-Name (des zu loggenden Gerätes) ist zu lang. DbLog legt beim Tabellencreate die Felder mit einer Größe von nur 32 Zeichen an.
Dein Device-Name ist bei "switchable.socket.storageCellar.fridge_Pwr" bereits 42 Zeichen lang, d.h. der Devicename wird abgeschnitten und heißt dann nur noch  "switchable.socket.storageCellar.". Das geschieht übrigends auch beim "insert" und wird im Log/Reading dann auch so ausgegeben.

Wenn es nun weitere andere Geräte gibt, z.B. "switchable.socket.storageCellar.dishwash_Pwr" usw. werden die Werte dieser Geräte ungewollt mit berücksichtigt, da in der DB die Device alle nur "switchable.socket.storageCellar." heißen.

Die Readings deines letzten Posts gehen nur bis zum 27.8. 19:57
2016-08-27_19-57-21__elektrische.Energie 5.85
In deiner vorherigen Meldung bis 28.08. 12:49
2016-08-28_12-49-28__elektrische.Energie 6.80
Da fehlt ein Stück, deswegen kann ich die Theorie nicht 100%ig belegen. Aber es sieht sehr danach aus.
Da ich davon ausgegangen bin, dass die Grenze von 32 Characters bekannt ist, habe ich dbzgl. keinen Plausicheck bei der Angabe des Devices eingebaut, aber das kann ich ja noch nachholen.

Schau mal ob meine Ausführungen so bei dir zutreffen.

Gruß,
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 18:14:53
das war mir jetzt nicht so bewusst... immerhin zeigt mit ein get dblog folgendes an:

2016-08-28 17:00:33: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 7.01, energy_kWh, 7.01,
2016-08-28 17:25:50: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 7.02, energy_kWh, 7.02,
2016-08-28 17:28:26: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 7.03, energy_kWh, 7.03,
2016-08-28 17:53:57: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 7.04, energy_kWh, 7.04,
2016-08-28 17:56:02: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 7.05, energy_kWh, 7.05,
2016-08-28 17:59:58: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 7.06, energy_kWh, 7.06,
#switchable.socket.storageCellar.fridge_Pwr:energy_kWh:::
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 18:19:07
ich habe den Fehler gefunden...  :D

die Readings vom fetchRow waren leider unvollständig im Beitrag... es gibt in der Tat eine Zeile in der DB die sich fehlerhaft eingeschlichen hat.

2016-08-28 04:35:17: switchable.socket.storageCellar.fridge_Pwr, CUL_HM, energy_kWh: 606.21, energy_kWh, 606.21,

Danke für Deine Mühe!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 18:23:38
 ;D

Gern geschehen ...

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 18:34:03
Kleiner Nachtrag ... in der db_create.sql steht 32varchar für sqlite und mySQL drin, bei PostgreSQL sind es 64 Zeichen.
Du hast doch aber SQLite richtig ?
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 18:34:59
richtig, es funktioniert aber dennoch
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 18:41:10
Das ist interessant. Das muß ich mal mit meiner SQLite Spieldatenbank versuchen nachzustellen. Hatte es mit meiner MySQL probiert.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 19:38:04
Habe mir SQLite nun mal angeschaut. Es ist tatsächlich so dass trotz der Definition der Tabellenfelder mit varchar32 längere Werte (wie Readingname) gespeichert werden können.
Es sind zwei Screenshots angehängt die diesen Sachverhalt illustrieren.
Eine interessante Erfahrung ...
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 20:19:33
gerne steht Dir meine Unwissenheit des öfteren zur Verfügung  ;D

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 28 August 2016, 20:36:53
Sqlite hat ein paar Eigenheiten, unter anderem:
Zitat
Note that numeric arguments in parentheses that following the type name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite does not impose any length restrictions (other than the large global SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric values.
Quelle: https://www.sqlite.org/datatype3.html#section_3_2
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 20:38:05
Das machen wir doch irgendwo alle  ;D  Nehme deine Hinweise gerne wieder auf.
Werde dem Modul noch einen Plausi-Check gönnen wenn der DB-Type nicht gerade SQLite ist ;)
Danke für deine Mitarbeit und schönen Abend noch...

Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 20:42:02
Danke Pyromane für den Hinweis ... hilft einiges richtig einzuordnen und zu verstehen.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 August 2016, 20:52:21
Werde dem Modul noch einen Plausi-Check gönnen wenn der DB-Type noch gerade SQLite ist ;)

Das wäre dann etwas ungünstig und ich dürfte meine gesamte Config umstellen.

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 August 2016, 20:58:59
Sorry Schreibfehler  noch -> nicht ... also Plausicheck wenn DB NICHT SQLite ist.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 29 August 2016, 20:26:10
@Heiko, kannst Du mal hier mit reinschauen? https://forum.fhem.de/index.php?topic=57168.new;topicseen#new Es geht um meine Problematik mit den mathematische Funktionen in der readingsGroup und um die Frage ob bei fehlenden Werten wirklich nur ein "-" ausgegeben wird oder möglicherweise sich dort noch ein Leerzeichen versteckt.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 August 2016, 21:35:35
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: pejonp am 30 August 2016, 22:18:39
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 August 2016, 22:30:43
Hallo pejonp,

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

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

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

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

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

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: pejonp am 30 August 2016, 22:54:09
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 August 2016, 23:18:01
Zitat
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

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 September 2016, 00:03:59
Hallo zusammen,

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

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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 September 2016, 21:35:48
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.

Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 September 2016, 15:14:34
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ß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2016, 17:32:33
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 03 September 2016, 19:39:31
der Inhalt der DB:
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:
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:
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2016, 20:31:42
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.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2016, 22:21:56
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2016, 09:28:33
Ich konnte den Fehler fixen. NImm mal bitte die angehängte Version.Die neue Version checke ich auch noch ein.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 September 2016, 11:29:44
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 September 2016, 20:44:25
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
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 26 September 2016, 22:08:10
Das mit dem readingPreventFromDel klappt super!

Gruß!
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 September 2016, 00:22:08
Zitat
Das mit dem readingPreventFromDel klappt super!

Danke für die Rückmeldung !

Die neue Version 3.9 ist auch eingecheckt.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 September 2016, 23:03:47
Hallo zusammen,

ich habe wieder eine neue Version V3.10 im Eingangsthread hinterlegt.
Hinzugekommen ist ein Internal "LASTCMD" damit man immer sieht welches Kommando gerade läuft bzw. welches zuletzt ausgeführt wurde. Manchmal ist es nicht unbedingt ersichtlich (z.B. bei benutzten Readingnamemap) woraus die aktuellen Readings resultierten.
Außerderm habe ich die Berechnungsroutine für "diffValue" mit in den Blockingcall (in den Forkprozess) verschoben. Ich hatte festgestellt, dass bei sehr hohen Datenvolumen die Berechnung sehr ressourcenintensiv ist und die FHEM-Hauptschleife stark belastet hat. Dadurch konnte es zum freeze kommen.
In dem Zusammenhang haben alle Routinen ein Reading "background_processing_time" bekommen welches die verbrauchte Zeit im Hintergrund misst.  Die SQL-Zeit ist ein Teil davon und wird wie bisher für die DB-Zeit ausgewiesen.

Gerne wieder Feedback ...

VG
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: bobyg am 29 September 2016, 12:17:32
Hallo,

erstmal Danke für die Entwicklung dieses sehr braucbaren Moduls! Ich stehe zwar noch am Anfang meiner Umsetzung, allerdings ist mir aufgefallen dass es kein Gegenstück zu "maxValue", also ein "minValue" gibt. Habe ich was übersehen?, Oder gab es bislang keinen Bedarf?

Danke.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 September 2016, 12:57:42
Hallo bobyg,

Nein, du hast nichts übersehen. Bislang hatte diese Funktion niemand vermisst.
Aber das kann ich ja in einem der nächsten Updates mit vorsehen.
Aus deiner Mitteilung entnehme ich dass du daran Interesse hättest ?

Grüsse
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: bobyg am 29 September 2016, 14:20:03
Ja, ich könnte diese Funktion brauchen. Wäre klasse wenn es in einem Update implementiert würde.  ;)

Danke und viele Grüße
bobyg
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: bobyg am 29 September 2016, 23:04:44
Hallo, ich bin's nochmal

Werte, die den Timestamp YYYY-MM-DD 00:00:00 haben, wirken sich bei mir zusätzlich auf die Berechnungen des Vortags aus. Sie werden also doppelt "behandelt".
Falls ich was übersehen habe, entschuldige ich die Störung, ansonsten freu ich mich auf das Update  :D

Viele Grüße
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 September 2016, 23:40:20
Hallo bobyg,

Es ist natürlich die Frage wohin ein Wert genau auf dem Punkt YYYY-MM-DD 00:00:00 gehört, Vortag 24:00:00 oder neuer Tag 00:00:00
Das kann man unterschiedlich sehen  ;)

Ich glaube, mir ist dieser Grenzfall noch nie untergekommen, aber werde das mal näher beleuchten.

EDIT: Stell mal bitte verbose 4 ein, führe deine Selektion aus und poste einen Ausschnitt aus dem Log mit den ausgeführten SQL-Statements. Auch ein List deines DbRep Devices wäre hilfreich.

Gruß,
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: bobyg am 30 September 2016, 01:40:54
- Versuch mal 24:00:00 in Deine Datenbank einzutragen, dann reden wir weiter.  :P Aber ich sehe ein, dieser Punkt ist diskutabel.
- Allerdings erwarte ich bei einem Wert der das Datum YYYY-MM-DD hat, dass er zu diesem Datum gehört und nicht DD-1
- Und unabhäning davon ist das Problem immernoch dass für DbRep YYYY-MM-DD 00:00:00 auch DD-1 ist.

Aus dem Log könnte ich nichts verdächtiges rauslesen:
2016.09.30 00:53:09 4: DbRep dbRepOil - -------- New selection ---------
2016.09.30 00:53:09 4: DbRep dbRepOil - Aggregation: day
2016.09.30 00:53:09 4: DbRep dbRepOil - Timestamp begin human readable: 2016-08-20 00:00:00
2016.09.30 00:53:09 4: DbRep dbRepOil - Timestamp end human readable: 2016-09-30 00:53:09
2016.09.30 00:53:09 4: BlockingCall (sumval_DoParse): created child (3115), uses telnetPort to connect back
2016.09.30 00:53:09 4: DbRep dbRepOil -> Start BlockingCall sumval_DoParse
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-20 00:00:00' AND '2016-08-21' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-21' AND '2016-08-22' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-22' AND '2016-08-23' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-23' AND '2016-08-24' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-24' AND '2016-08-25' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-25' AND '2016-08-26' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-26' AND '2016-08-27' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-27' AND '2016-08-28' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-28' AND '2016-08-29' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-29' AND '2016-08-30' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-30' AND '2016-08-31' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-08-31' AND '2016-09-01' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-09-01' AND '2016-09-02' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-09-02' AND '2016-09-03' ;
2016.09.30 00:53:09 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-09-03' AND '2016-09-04' ;
...
2016.09.30 00:53:10 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-09-28' AND '2016-09-29' ;
2016.09.30 00:53:10 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-09-29' AND '2016-09-30' ;
2016.09.30 00:53:10 4: DbRep dbRepOil - SQL to execute: SELECT SUM(VALUE) FROM `history` where READING = 'Oelstand' AND TIMESTAMP BETWEEN '2016-09-30' AND '2016-09-30 00:53:09' ;
2016.09.30 00:53:10 4: DbRep dbRepOil -> BlockingCall sumval_DoParse finished
2016.09.30 00:53:10 4: Connection accepted from telnetPort_127.0.0.1_46772
2016.09.30 00:53:10 4: DbRep dbRepOil -> Start BlockingCall sumval_ParseDone
2016.09.30 00:53:10 4: DbRep dbRepOil -> BlockingCall sumval_ParseDone finished

Dieser einzelne DB-Eintrag führt zu den Readings in dem Screenshot den ich angängt habe:

"TIMESTAMP"   "DEVICE"   "TYPE"   "EVENT"   "READING"   "VALUE"   "UNIT"
"2016-09-01 00:00:00"   "Oeltank"   "HTTPMOD"   "rl_av_h"   "Oelstand"   "129.000"   ""
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 September 2016, 07:52:36
Zitat
Versuch mal 24:00:00 in Deine Datenbank einzutragen, dann reden wir weiter.

Ich weiß das es natürlich nicht möglich ist ... es war auch mehr ein philsophischer Aspekt.  ;)
Wie gesagt, ich schau es mir an.

VG
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 September 2016, 10:26:47
Hallo bobyg, @all,

ich habe dieses Grenzwertproblem gefixt und die Funktionen entsprechend angepasst.
Bitte teste(t) mal die Version 3.11.1 aus dem Eingangsthread.
Bei mir klappt das alles tadellos.

Danach würde ich mich dem "minValue" widmen.

Grüße
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: doesel am 30 September 2016, 11:05:40
Hallo,
nur mal so: Auch ich habe das minValue bisher vermisst. Wäre schon toll...
Gruß
Doesel
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: bobyg am 30 September 2016, 13:31:53
Das geht hier ja richtig schnell. Der Grenzwertproblemfix war erfolgreich.
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 September 2016, 13:46:28
Zitat
Das geht hier ja richtig schnell. Der Grenzwertproblemfix war erfolgreich.

Danke für die Rückinfo  :)  Dann checke ich diese Version auch ein. Sie ist dann morgen früh regulär mit dem Update verfügbar.
Wenn ich eine Testversion mit "minValue" habe, melde ich mich wieder und stelle sie hier wie gewohnt bereit.

schönes WE und Grüße,
Heiko
Titel: Antw:neues Modul 93_DbRep - Auswertungen und Reporting von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Oktober 2016, 12:54:40
Hallo miteinander,

die Funktion minValue habe ich in der im Eingangsthread hinterlegten Version 3.12 realisiert.
Bitte zieht sie euch runter und viel Spaß beim Test.

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Oktober 2016, 23:11:46
Hallo zusammen,

ich habe etwas weiter entwickelt und in der Version 4.1 im Eingangsbeitrag neben einigen kleineren Änderungen am Logging (weniger/andere Ausgaben beim FHEM-Start) auch eine Funktion "deviceRename" und eine neue Rolle ("Agent") eingebaut. Die neue Rolle dient dazu über einen automatisierten Prozess auf Device-Umbenennungen im System zu reagieren und die Device-Namen  in den Datenbanken bzw. DbRep-Definition nachzuziehen und konsistent zu halten.
"deviceRename" dient zum manuellen Umbenennen von Device-Namen in der Datenbank.

Bitte lest dazu die Ergänzungen im ersten Beitrag bzw. hier die Erläuterung zum Autorename:

DbRep Agent - automatisches Ändern von Device-Namen in Datenbanken und DbRep-Definitionen nach FHEM "rename"

Mit dem Attribut "role" wird die Rolle des DbRep-Device festgelegt. Die Standardrolle ist "Client". Mit der Änderung der Rolle in "Agent" wird das Device veranlasst auf Umbenennungen von Geräten in der FHEM Installation zu reagieren.

Durch den DbRep-Agenten werden folgende Features aktiviert wenn ein Gerät in FHEM mit "rename" umbenannt wird:

*  in der dem DbRep-Agenten zugeordneten Datenbank (Internal Database) wird nach Datensätzen mit dem alten Gerätenamen gesucht und dieser Gerätename in allen betroffenen Datensätzen in den neuen Namen geändert.

*  in den existierenden DbRep-Definitionen vom Typ "Client" wird ein evtl. gesetztes Attribut "device = alter Devicename" in "device = neuer Devicename" geändert. Dadurch werden Auswertungsdefinitionen bei Geräteumbenennungen automatisch konstistent gehalten.

Mit der Änderung in einen Agenten sind folgende Restriktionen verbunden die mit dem Setzen des Attributes "role = Agent" eingeschaltet und geprüft werden:

*  es kann nur einen Agenten pro Datenbank in der FHEM-Installation geben. Ist mehr als eine Datenbank mit DbLog definiert, können ebenso viele DbRep-Agenten eingerichtet werden

*  mit der Umwandlung in einen Agenten wird nur noch das Set-Komando "renameDevice" verfügbar sein sowie nur ein eingeschränkter Satz von DbRep-spezifischen Attributen zugelassen. Wird ein DbRep-Device vom bisherigen Typ "Client" in einen Agenten geändert, werden evtl. gesetzte und nun nicht mehr zugelassene Attribute glöscht.

Die Aktivitäten wie Datenbankänderungen bzw. Änderungen an anderen DbRep-Definitionen werden im Logfile mit verbose=3 protokolliert. Damit die renameDevice-Funktion bei großen Datenbanken nicht in ein timeout läuft, sollte das Attribut "timeout" entsprechend dimensioniert werden. Wie alle Datenbankoperationen des Moduls wird auch das Autorename nonblocking ausgeführt.

Beispiel für die Definition eines DbRep-Device als Agent:

                       define Rep.Agent DbRep LogDB
                      attr Rep.Agent devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
                      attr Rep.Agent icon security
                      attr Rep.Agent role Agent
                      attr Rep.Agent room DbLog
                      attr Rep.Agent showproctime 1
                      attr Rep.Agent stateFormat { ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " »; ProcTime:                               
                      ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
                     attr Rep.Agent timeout 3600


Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Oktober 2016, 13:33:52
Die Version 4.1.2 im Eingangsthread habe ich noch dahingehend verändert dass bei Umbenennung eines Devices dieses Device in der Definition des dem DbRep-Agenten angeschlossenen DbLog-Instanz ebenfalls geändert wird. Dadurch wird das umbenannte Gerät sogleich weiter in der Datanbank geloggt.

Gerne wieder feedback.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: cwagner am 08 Oktober 2016, 19:20:07
Die Idee des Rename-Agenten ist super, wie auch überhaupt die Idee zu diesem Modul.

Was mir noch nicht gelungen ist, sind RegEx in Device- oder Readingnamen. Ich möchte beispielsweise in allen PID-Devices mit Namen RR_.* (z.B. RR_Bad oder RR_Kueche) einen testweise zehntausendfach protokollierten Parameter mit Namen p_.* (z.B. p_i oder p_p oder p_d)

Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Oktober 2016, 19:36:20
Hallo Christian,

auf die Berücksichtigung von RegEX-Ausdrücken in den device/Reading-Selektionsbedingungen habe ich bis jetzt bewußt verzichtet.
Das hängt damit zusammen dass es auch Funktionen wie "delEntries" gibt, die mit Regex-Ausdrücken durchaus Schaden anrichten können bzw. nicht wie gewünscht funktionieren würden. Deswegen muß man bis dato exakte Bezeichnungen angeben.

Da müßte ich noch etwas Aufwand reinstecken um Regex-Ausdrücke ausschließlich bei "unproblematischen"  Selekt-Operationen zu erlauben, sonst nicht.
Ich denke mal darüber nach wie so etwas zu machen wäre ohne Gefahr zu laufen dass sich jemand in einem Moment der Unachtsamkeit seine Daten zerschießt ....

viele Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: cwagner am 08 Oktober 2016, 20:24:39
Moin, Heiko,

den Sicherheitsaspekt kann ich gut nachvollziehen und er hätte für mich auch höhere Priorität...

Danke, dass Du Dich mit dem Thema auseinandersetzen willst.

Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Oktober 2016, 10:42:12
Hallo zusammen,

ich habe für das Modul begonnen einen Wiki Eintrag anzulegen. Bisher habe ich die Beschreibungen aus dem Eingangsthread dorthin verlagert und auch schon begonnen Praxisbeispiele zu beschreiben.

Zum Beispiel den Export/Import von Datensätzen mit DbRep:

http://www.fhemwiki.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Datens.C3.A4tze_.28Devices.29_von_einer_Datenbank_in_eine_andere_umziehen_.28Export.2FImport.29

Ergänzung/Beiträge sind herzlich willkommen.

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2016, 00:29:00
Hi Christian, @all,

nun ist es auch möglich SQL-Wildcards in den Selektionen zu verwenden.
Hier die kurzen Hinweise dazu:

Hinweis zur SQL-Wildcard Verwendung:
Innerhalb der Attribut-Werte für "device" und "reading" können SQL-Wildcards, "%" und "_", angegeben werden. Dabei ist "%" = beliebig viele Zeichen und "_" = ein Zeichen.
Dies gilt für alle Funktionen außer "insert", "deviceRename" und "delEntries".
Die Funktion "insert" erlaubt nicht dass die genannten Attribute das Wildcard "%" enthalten, "_" wird als normales Zeichen gewertet.
Die Löschfunktion "delEntries" wertet die Zeichen "$", "_" NICHT als Wildcards und löscht nur Device/Readings die exakt wie in den Attributen angegeben in der DB gespeichert sind.

Die Version ist V4.2 im Eingangsthread.
Gerne wieder Feedback.

VG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Oktober 2016, 09:33:11
Hi @all,

habe die neue Version mit SQL-Wildcards enabled eingecheckt.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Oktober 2016, 22:19:31
Hallo zusammen,

es gibt wieder eine Version 4.5 mit neuen Funktionen. Die eingebauten Get-Kommandos liefern diverse Metainformationen der betriebenen Datenbank.
Hier wieder ein Auszug aus der Commandref:

== Get ==


Die Get-Kommandos von DbRep dienen dazu eine Reihe von Metadaten der verwendeten Datenbankinstanz abzufragen. Dies sind zum Beispiel eingestellte Serverparameter, Servervariablen, Datenbankstatus-  und Tabelleninformationen.
Die verfügbaren get-Funktionen sind von dem verwendeten Datenbanktyp abhängig. So ist für SQLite z.Zt. nur "svrinfo" verfügbar.
Die Funktionen liefern nativ sehr viele Ausgabewerte die über über funktionsspezifische Attribute abgrenzbar sind.

Hinweis:
Nach der Ausführung einer get-Funktion in der Detailsicht einen Browserrefresh durchführen um die Ergebnisse zu sehen !



* dbstatus : listet globale Informationen zum MySQL Serverstatus (z.B. Informationen zum Cache, Threads, Bufferpools, etc. ). Es werden zunächst alle verfügbaren Informationen berichtet. Mit dem [[#Attribute | Attribut]] "showStatus" kann die Ergebnismenge eingeschränkt werden, um nur gewünschte Ergebnisse abzurufen.

                   Bespiel:    attr ... showStatus %uptime%,%qcache%   
                   # Es werden nur Readings erzeugt die im Namen "uptime" und "qcache" enthalten

Detailinformationen zur Bedeutung der einzelnen Readings sind [http://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html hier] verfügbar.

* dbvars :  zeigt die globalen Werte der MySQL Systemvariablen. Enthalten sind zum Beispiel Angaben zum InnoDB-Home, dem Datafile-Pfad, Memory- und Cache-Parameter, usw. Die Ausgabe listet zunächst alle verfügbaren Informationen auf. Mit dem [[#Attribute | Attribut]] "showVariables" kann die Ergebnismenge eingeschränkt werden um nur gewünschte Ergebnisse abzurufen.

                   Bespiel:    attr ... showVariables %version%,%query_cache%
                   # Es werden nur Readings erzeugt die im Namen "version" und "query_cache" enthalten

Weitere Informationen zur Bedeutung der ausgegebenen Variablen sind [http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html hier] verfügbar.

* svrinfo : allgemeine Datenbankserver-Informationen wie z.B. die DBMS-Version, Serveradresse und Port usw. Die Menge der Listenelemente ist vom Datenbanktyp abhängig. Mit dem [[#Attribute | Attribut]] "showSvrInfo" kann die Ergebnismenge eingeschränkt werden.

                   Bespiel:    attr ... showSvrInfo %SQL_CATALOG_TERM%,%NAME%
                   # Es werden nur Readings erzeugt die im Namen "SQL_CATALOG_TERM" und "NAME" enthalten

Weitere Erläuterungen zu den gelieferten Informationen sind [https://msdn.microsoft.com/en-us/library/ms711681(v=vs.85).aspx hier] zu finden.

* tableinfo : ruft Detailinformationen der in einem MySQL-Schema angelegten Tabellen ab. Die ausgewerteten Schemata sind abhängig von den Rechten des verwendeten Datenbankusers (default: das DB-Schema der der current/history-Tabelle). Mit dem [[#Attribute | Attribut]] "showTableInfo" können die Ergebnisse eingeschränkt werden.

                   Bespiel:    attr ... showTableInfo current,history
                   # Es werden nur Information der Tabellen current,history angezeigt

Erläuterungen zu den erzeugten Readings sind [http://dev.mysql.com/doc/refman/5.7/en/show-table-status.html hier] zu finden.


Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 20 Oktober 2016, 17:05:54
aktuelle Meldung:

errortext
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_DbRep.pm line 1759.
2016-10-20 17:03:13
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Oktober 2016, 18:51:56
Hmm, kann mit der Meldung nicht viel anfangen, bzw. betrifft die Stelle im Coding an der eine DB-Verbindung aufgebaut wird.
Dieses Teilstück ist schon "ewig" nicht geändert und wird auch in jeder Funktion aufgerufen, egal ob diffValue (wie hier) oder eine andere Funktion.
Es ist immer der gleiche Aufruf:

eval {$dbh = DBI->connect("dbi:$dbconn", $dbuser, $dbpassword, { PrintError => 0, RaiseError => 1, AutoInactiveDestroy => 1 });};

Kann es bei mir auch nicht provozieren .... läuft alles.

Nach ein bisschen googeln kommt der Fehler wenn der Term "dbi:$dbconn" nicht richtig bedient wird oder ein Schreibfehler, den können wir ausschließen.
Aber "dbi:$dbconn" wird aus dem entsprechenden DbLog-Device abgeleitet. Schau mal was ein list <Dbrep-Device> sagt.
Es muß einen Teil geben der wie hier die dbconn-Variable ausschreibt:

     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=192.168.2.10;port=3306
     dbuser     fhem

Wenn das nicht der Fall sein sollte, konnte diese Variabke nicht von dem DbLog-Device bezogen/abgeleitet werden. In dem Fall schau mal bitte ob dein DbLog-Device ordnungsgemäß funktioniert und mit der DB verbunden ist.
In diesem Umfeld würde ich mal bei dir suchen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 20 Oktober 2016, 21:30:23
ich denke ich habe den Verursacher gefunden:

Messages collected while initializing FHEM:
configDB: DbLog_meterReading already defined, delete it first
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Oktober 2016, 21:51:07
Denke ich auch. Hab grad mal ein Nonsens-Device angelegt, also ein DbRep definiert mit einem DbLog was es nicht gibt.
Dann kommt der Fehler. Aber man sieht auch dass das DbRep-Device auf "disconnected" steht.
Hab mal ein Screenshot angehängt.
Sieht wahrscheinlich bei dir auch so aus.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 20 Oktober 2016, 21:52:50
ja genau, das letzte update hat mir da etwas die config zerschossen.. lässt sich aber leicht reparieren.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Oktober 2016, 15:02:38
Hallo zusammen,

das Ende der Sommerzeit hat es nötig gemacht im Modul Korrekturen einzupflegen.
Bei entsprechenden Zeitselektionen kam es zu falschen/fehlenden Ergebnissen aufgrund der Zeitverschiebung.
Ich habe die neue Version 4.6 im ersten Beitrag eingehängt.
Checke die neue Version heute Abend auch noch ein.

Bitte auch testen, ich hoffe habe alles richtig gefixt.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 November 2016, 21:49:18
Habe den "daylight saving time"-check noch verbessert um das Modul auch für die nächste Zeitumstellung vorbereitet zu haben.
Der Version 4.6.1 ist wieder im ersten Beitrag.
Ich checke die Version noch ein. Sie ist morgen wieder im update.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 November 2016, 15:13:45
Hm, warum wird bei mir das diff für 2015-11 ausgelassen?
hier habe ich fast jeden Tag Werte in der DB stehen...
2015-11-27_19-24-23__XXYY__total__DIFF__2015-10   636.9493  2016-11-11 14:47:48
2015-12-16_21-14-49__XXYY__total__DIFF__2015-12   169.1893  2016-11-11 14:47:48
Liegt das daran dass mein Zähler übersprungen hat und am 1.10 neu von 0 angefangen hat? Ich denke, das sollte berücksichtigt werden, denn das ufhem-serreading berücksichtigt das auch!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 November 2016, 15:30:11
Hallo JoeAllb,

Unabhängig von der Ursache werden mit dem Modul NUR in der DB vorhandene Werte ausgewertet. D.h. der Nutzer bzw. die schreibende Applikation hat dafür Sorge zu tragen dass die Daten im Sinne der Auswertung vollständig und integer sind.
DiffValue ermittelt den Differenzbetrag eines sich STETIG erhöhenden Wertes. Soweit zur Theorie.

Zu deinem speziellen Problem kann ich momentan nichts sagen. Dazu brauche ich mehr Infos. Mach mal bitte ein list des DbRep und auch einen verbose 4 Log. Dann sehen wir mehr.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 November 2016, 15:37:46
Nun ja, der Zähler hat halt einen Maximalwert, und wenn dieser überschritten wird, fängt er automatisch wieder bei 0 an, ähnlich wie bei einem Tacho beim Auto.
Aber in der Theorie würde es ja beim Umsprung auf 0 einen negativen DIFF-Wert geben. Den würde ich ignorieren und am nächsten Tag wieder neu die Differenz bilden...

Anbei das List:
Internals:
   DATABASE   fhem
   DEF        myDbLogSQL
   LASTCMD
   NAME       calc_solar_year
   NOTIFYDEV  global,calc_solar_year
   NR         310
   NTFY_ORDER 50-calc_solar_year
   ROLE       Client
   STATE      connected
   TYPE       DbRep
   Helper:
     DBLOGDEVICE myDbLogSQL
   Readings:
     2016-11-11 14:47:48   2000-01-17__solar__total__DIFF__2000-01 -
     2016-11-11 14:47:48   2000-02-01__solar__total__DIFF__2000-02 -
     2016-11-11 14:47:48   2000-03-01__solar__total__DIFF__2000-03 -
     2016-11-11 14:47:48   2000-04-01__solar__total__DIFF__2000-04 -
     2016-11-11 14:47:48   2000-05-01__solar__total__DIFF__2000-05 -
     2016-11-11 14:47:48   2000-06-01__solar__total__DIFF__2000-06 -
     2016-11-11 14:47:48   2000-07-01__solar__total__DIFF__2000-07 -
     2016-11-11 14:47:48   2000-08-01__solar__total__DIFF__2000-08 -
     2016-11-11 14:47:48   2000-09-01__solar__total__DIFF__2000-09 -
     2016-11-11 14:47:48   2000-10-01__solar__total__DIFF__2000-10 -
     2016-11-11 14:47:48   2000-11-01__solar__total__DIFF__2000-11 -
     2016-11-11 14:47:48   2000-12-01__solar__total__DIFF__2000-12 -
     2016-11-11 14:47:48   2001-01-01__solar__total__DIFF__2001-01 -
     2016-11-11 14:47:48   2001-02-01__solar__total__DIFF__2001-02 -
     2016-11-11 14:47:48   2001-03-01__solar__total__DIFF__2001-03 -
     2016-11-11 14:47:48   2001-04-01__solar__total__DIFF__2001-04 -
     2016-11-11 14:47:48   2001-05-01__solar__total__DIFF__2001-05 -
     2016-11-11 14:47:48   2001-06-01__solar__total__DIFF__2001-06 -
     2016-11-11 14:47:48   2001-07-01__solar__total__DIFF__2001-07 -
     2016-11-11 14:47:48   2001-08-01__solar__total__DIFF__2001-08 -
     2016-11-11 14:47:48   2001-09-01__solar__total__DIFF__2001-09 -
     2016-11-11 14:47:48   2001-10-01__solar__total__DIFF__2001-10 -
     2016-11-11 14:47:48   2001-11-01__solar__total__DIFF__2001-11 -
     2016-11-11 14:47:48   2001-12-01__solar__total__DIFF__2001-12 -
     2016-11-11 14:47:48   2002-01-01__solar__total__DIFF__2002-01 -
     2016-11-11 14:47:48   2002-03-01__solar__total__DIFF__2002-03 -
     2016-11-11 14:47:48   2002-04-01__solar__total__DIFF__2002-04 -
     2016-11-11 14:47:48   2002-05-01__solar__total__DIFF__2002-05 -
     2016-11-11 14:47:48   2002-06-01__solar__total__DIFF__2002-06 -
     2016-11-11 14:47:48   2002-07-01__solar__total__DIFF__2002-07 -
     2016-11-11 14:47:48   2002-08-01__solar__total__DIFF__2002-08 -
     2016-11-11 14:47:48   2002-09-01__solar__total__DIFF__2002-09 -
     2016-11-11 14:47:48   2002-10-01__solar__total__DIFF__2002-10 -
     2016-11-11 14:47:48   2002-11-01__solar__total__DIFF__2002-11 -
     2016-11-11 14:47:48   2002-12-01__solar__total__DIFF__2002-12 -
     2016-11-11 14:47:48   2003-01-01__solar__total__DIFF__2003-01 -
     2016-11-11 14:47:48   2003-02-01__solar__total__DIFF__2003-02 -
     2016-11-11 14:47:48   2003-03-01__solar__total__DIFF__2003-03 -
     2016-11-11 14:47:48   2003-04-01__solar__total__DIFF__2003-04 -
     2016-11-11 14:47:48   2003-05-01__solar__total__DIFF__2003-05 -
     2016-11-11 14:47:48   2003-06-01__solar__total__DIFF__2003-06 -
     2016-11-11 14:47:48   2003-07-01__solar__total__DIFF__2003-07 -
     2016-11-11 14:47:48   2003-08-01__solar__total__DIFF__2003-08 -
     2016-11-11 14:47:48   2003-09-01__solar__total__DIFF__2003-09 -
     2016-11-11 14:47:48   2003-10-01__solar__total__DIFF__2003-10 -
     2016-11-11 14:47:48   2003-11-01__solar__total__DIFF__2003-11 -
     2016-11-11 14:47:48   2003-12-01__solar__total__DIFF__2003-12 -
     2016-11-11 14:47:48   2004-01-01__solar__total__DIFF__2004-01 -
     2016-11-11 14:47:48   2004-02-01__solar__total__DIFF__2004-02 -
     2016-11-11 14:47:48   2004-03-01__solar__total__DIFF__2004-03 -
     2016-11-11 14:47:48   2004-04-01__solar__total__DIFF__2004-04 -
     2016-11-11 14:47:48   2004-05-01__solar__total__DIFF__2004-05 -
     2016-11-11 14:47:48   2004-06-01__solar__total__DIFF__2004-06 -
     2016-11-11 14:47:48   2004-07-01__solar__total__DIFF__2004-07 -
     2016-11-11 14:47:48   2004-08-01__solar__total__DIFF__2004-08 -
     2016-11-11 14:47:48   2004-09-01__solar__total__DIFF__2004-09 -
     2016-11-11 14:47:48   2004-10-01__solar__total__DIFF__2004-10 -
     2016-11-11 14:47:48   2004-11-01__solar__total__DIFF__2004-11 -
     2016-11-11 14:47:48   2004-12-01__solar__total__DIFF__2004-12 -
     2016-11-11 14:47:48   2005-01-01__solar__total__DIFF__2005-01 -
     2016-11-11 14:47:48   2005-02-01__solar__total__DIFF__2005-02 -
     2016-11-11 14:47:48   2005-03-01__solar__total__DIFF__2005-03 -
     2016-11-11 14:47:48   2005-04-01__solar__total__DIFF__2005-04 -
     2016-11-11 14:47:48   2005-05-01__solar__total__DIFF__2005-05 -
     2016-11-11 14:47:48   2005-06-01__solar__total__DIFF__2005-06 -
     2016-11-11 14:47:48   2005-07-01__solar__total__DIFF__2005-07 -
     2016-11-11 14:47:48   2005-08-01__solar__total__DIFF__2005-08 -
     2016-11-11 14:47:48   2005-09-01__solar__total__DIFF__2005-09 -
     2016-11-11 14:47:48   2005-10-01__solar__total__DIFF__2005-10 -
     2016-11-11 14:47:48   2005-11-01__solar__total__DIFF__2005-11 -
     2016-11-11 14:47:48   2005-12-01__solar__total__DIFF__2005-12 -
     2016-11-11 14:47:48   2006-01-01__solar__total__DIFF__2006-01 -
     2016-11-11 14:47:48   2006-02-01__solar__total__DIFF__2006-02 -
     2016-11-11 14:47:48   2006-03-01__solar__total__DIFF__2006-03 -
     2016-11-11 14:47:48   2006-04-01__solar__total__DIFF__2006-04 -
     2016-11-11 14:47:48   2006-05-01__solar__total__DIFF__2006-05 -
     2016-11-11 14:47:48   2006-06-01__solar__total__DIFF__2006-06 -
     2016-11-11 14:47:48   2006-07-01__solar__total__DIFF__2006-07 -
     2016-11-11 14:47:48   2006-08-01__solar__total__DIFF__2006-08 -
     2016-11-11 14:47:48   2006-10-01__solar__total__DIFF__2006-10 -
     2016-11-11 14:47:48   2006-11-01__solar__total__DIFF__2006-11 -
     2016-11-11 14:47:48   2006-12-01__solar__total__DIFF__2006-12 -
     2016-11-11 14:47:48   2007-01-01__solar__total__DIFF__2007-01 -
     2016-11-11 14:47:48   2007-02-01__solar__total__DIFF__2007-02 -
     2016-11-11 14:47:48   2007-03-01__solar__total__DIFF__2007-03 -
     2016-11-11 14:47:48   2007-04-01__solar__total__DIFF__2007-04 -
     2016-11-11 14:47:48   2007-05-01__solar__total__DIFF__2007-05 -
     2016-11-11 14:47:48   2007-06-01__solar__total__DIFF__2007-06 -
     2016-11-11 14:47:48   2007-07-01__solar__total__DIFF__2007-07 -
     2016-11-11 14:47:48   2007-08-01__solar__total__DIFF__2007-08 -
     2016-11-11 14:47:48   2007-09-01__solar__total__DIFF__2007-09 -
     2016-11-11 14:47:48   2007-10-01__solar__total__DIFF__2007-10 -
     2016-11-11 14:47:48   2007-11-01__solar__total__DIFF__2007-11 -
     2016-11-11 14:47:48   2007-12-01__solar__total__DIFF__2007-12 -
     2016-11-11 14:47:48   2008-01-01__solar__total__DIFF__2008-01 -
     2016-11-11 14:47:48   2008-02-01__solar__total__DIFF__2008-02 -
     2016-11-11 14:47:48   2008-03-31_23-00-00__solar__total__DIFF__2008-03 344.7000
     2016-11-11 14:47:48   2008-04-30_23-00-00__solar__total__DIFF__2008-04 499.6000
     2016-11-11 14:47:48   2008-05-31_23-00-00__solar__total__DIFF__2008-05 692.0000
     2016-11-11 14:47:48   2008-06-30_23-00-00__solar__total__DIFF__2008-06 511.1000
     2016-11-11 14:47:48   2008-07-31_23-00-00__solar__total__DIFF__2008-07 585.6000
     2016-11-11 14:47:48   2008-08-31_23-00-00__solar__total__DIFF__2008-08 531.9000
     2016-11-11 14:47:48   2008-09-30_23-00-00__solar__total__DIFF__2008-09 406.0000
     2016-11-11 14:47:48   2008-10-31_23-00-00__solar__total__DIFF__2008-10 276.1000
     2016-11-11 14:47:48   2008-11-30_23-00-00__solar__total__DIFF__2008-11 219.3000
     2016-11-11 14:47:48   2008-12-31_23-00-00__solar__total__DIFF__2008-12 115.8000
     2016-11-11 14:47:48   2009-01-31_23-00-00__solar__total__DIFF__2009-01 235.1200
     2016-11-11 14:47:48   2009-02-28_23-00-00__solar__total__DIFF__2009-02 140.9000
     2016-11-11 14:47:48   2009-03-31_23-00-00__solar__total__DIFF__2009-03 339.9000
     2016-11-11 14:47:48   2009-04-30_23-00-00__solar__total__DIFF__2009-04 565.0000
     2016-11-11 14:47:48   2009-05-31_23-00-00__solar__total__DIFF__2009-05 609.0000
     2016-11-11 14:47:48   2009-06-30_23-00-00__solar__total__DIFF__2009-06 522.1000
     2016-11-11 14:47:48   2009-07-31_23-00-00__solar__total__DIFF__2009-07 544.3000
     2016-11-11 14:47:48   2009-08-31_23-00-00__solar__total__DIFF__2009-08 626.5000
     2016-11-11 14:47:48   2009-09-30_23-00-00__solar__total__DIFF__2009-09 435.5000
     2016-11-11 14:47:48   2009-10-31_23-00-00__solar__total__DIFF__2009-10 238.5000
     2016-11-11 14:47:48   2009-11-30_23-00-00__solar__total__DIFF__2009-11 220.0000
     2016-11-11 14:47:48   2009-12-31_23-00-00__solar__total__DIFF__2009-12 13.7000
     2016-11-11 14:47:48   2010-01-31_23-00-00__solar__total__DIFF__2010-01 80.6000
     2016-11-11 14:47:48   2010-02-28_23-00-00__solar__total__DIFF__2010-02 219.0000
     2016-11-11 14:47:48   2010-03-31_23-00-00__solar__total__DIFF__2010-03 366.0000
     2016-11-11 14:47:48   2010-04-30_23-00-00__solar__total__DIFF__2010-04 494.6000
     2016-11-11 14:47:48   2010-05-31_23-00-00__solar__total__DIFF__2010-05 394.5900
     2016-11-11 14:47:48   2010-06-30_23-00-00__solar__total__DIFF__2010-06 263.8000
     2016-11-11 14:47:48   2010-07-31_23-00-00__solar__total__DIFF__2010-07 621.4000
     2016-11-11 14:47:48   2010-08-31_23-00-00__solar__total__DIFF__2010-08 -
     2016-11-11 14:47:48   2010-09-30_23-00-00__solar__total__DIFF__2010-09 345.9000
     2016-11-11 14:47:48   2010-10-31_23-00-00__solar__total__DIFF__2010-10 324.2000
     2016-11-11 14:47:48   2010-11-30_23-00-00__solar__total__DIFF__2010-11 1.2000
     2016-11-11 14:47:48   2010-12-31_23-00-00__solar__total__DIFF__2010-12 33.6000
     2016-11-11 14:47:48   2011-02-28_23-00-00__solar__total__DIFF__2011-01 482.4100
     2016-11-11 14:47:48   2011-03-31_23-00-00__solar__total__DIFF__2011-03 324.5000
     2016-11-11 14:47:48   2011-04-30_23-00-00__solar__total__DIFF__2011-04 367.3700
     2016-11-11 14:47:48   2011-05-31_23-00-00__solar__total__DIFF__2011-05 -
     2016-11-11 14:47:48   2011-06-30_23-00-00__solar__total__DIFF__2011-06 133.1000
     2016-11-11 14:47:48   2011-07-31_23-00-00__solar__total__DIFF__2011-07 -
     2016-11-11 14:47:48   2011-08-31_23-00-00__solar__total__DIFF__2011-08 -
     2016-11-11 14:47:48   2011-09-30_23-00-00__solar__total__DIFF__2011-09 -
     2016-11-11 14:47:48   2011-10-31_23-00-00__solar__total__DIFF__2011-10 47.9000
     2016-11-11 14:47:48   2011-11-30_23-00-00__solar__total__DIFF__2011-11 315.0000
     2016-11-11 14:47:48   2011-12-30_23-00-00__solar__total__DIFF__2011-12 102.0500
     2016-11-11 14:47:48   2012-01-01__solar__total__DIFF__2012-01 -
     2016-11-11 14:47:48   2012-02-19_23-00-00__solar__total__DIFF__2012-02 -
     2016-11-11 14:47:48   2012-03-27_23-00-00__solar__total__DIFF__2012-03 -
     2016-11-11 14:47:48   2012-04-01__solar__total__DIFF__2012-04 -
     2016-11-11 14:47:48   2012-05-28_23-00-00__solar__total__DIFF__2012-05 -
     2016-11-11 14:47:48   2012-06-01__solar__total__DIFF__2012-06 -
     2016-11-11 14:47:48   2012-07-24_23-00-00__solar__total__DIFF__2012-07 29.4000
     2016-11-11 14:47:48   2012-08-01__solar__total__DIFF__2012-08 -
     2016-11-11 14:47:48   2012-09-11_23-00-00__solar__total__DIFF__2012-09 19.4000
     2016-11-11 14:47:48   2012-10-01__solar__total__DIFF__2012-10 -
     2016-11-11 14:47:48   2012-11-01__solar__total__DIFF__2012-11 -
     2016-11-11 14:47:48   2012-12-13_23-00-00__solar__total__DIFF__2012-12 -
     2016-11-11 14:47:48   2013-01-01__solar__total__DIFF__2013-01 -
     2016-11-11 14:47:48   2013-02-01__solar__total__DIFF__2013-02 -
     2016-11-11 14:47:48   2013-03-01__solar__total__DIFF__2013-03 -
     2016-11-11 14:47:48   2013-04-01__solar__total__DIFF__2013-04 -
     2016-11-11 14:47:48   2013-05-01__solar__total__DIFF__2013-05 -
     2016-11-11 14:47:48   2013-06-01__solar__total__DIFF__2013-06 -
     2016-11-11 14:47:48   2013-07-01__solar__total__DIFF__2013-07 -
     2016-11-11 14:47:48   2013-08-01__solar__total__DIFF__2013-08 -
     2016-11-11 14:47:48   2013-09-01__solar__total__DIFF__2013-09 -
     2016-11-11 14:47:48   2013-10-01__solar__total__DIFF__2013-10 -
     2016-11-11 14:47:48   2013-11-09_23-00-00__solar__total__DIFF__2013-11 -
     2016-11-11 14:47:48   2013-12-01__solar__total__DIFF__2013-12 -
     2016-11-11 14:47:48   2014-01-22_17-33-53__solar__total__DIFF__2014-01 125.7440
     2016-11-11 14:47:48   2014-02-28_23-37-35__solar__total__DIFF__2014-02 379.9520
     2016-11-11 14:47:48   2014-03-10_14-06-18__solar__total__DIFF__2014-03 145.5893
     2016-11-11 14:47:48   2014-04-01__solar__total__DIFF__2014-04 -
     2016-11-11 14:47:48   2014-05-01__solar__total__DIFF__2014-05 -
     2016-11-11 14:47:48   2014-06-01__solar__total__DIFF__2014-06 -
     2016-11-11 14:47:48   2014-07-01__solar__total__DIFF__2014-07 -
     2016-11-11 14:47:48   2014-08-01__solar__total__DIFF__2014-08 -
     2016-11-11 14:47:48   2014-09-30_23-57-36__solar__total__DIFF__2014-09 7.8960
     2016-11-11 14:47:48   2014-10-31_23-59-49__solar__total__DIFF__2014-10 364.6693
     2016-11-11 14:47:48   2014-11-30_23-59-38__solar__total__DIFF__2014-11 258.6800
     2016-11-11 14:47:48   2014-12-31_23-56-38__solar__total__DIFF__2014-12 127.5627
     2016-11-11 14:47:48   2015-01-31_23-59-33__solar__total__DIFF__2015-01 140.7707
     2016-11-11 14:47:48   2015-02-28_23-56-35__solar__total__DIFF__2015-02 284.0000
     2016-11-11 14:47:48   2015-03-31_23-58-47__solar__total__DIFF__2015-03 502.4987
     2016-11-11 14:47:48   2015-04-30_23-59-05__solar__total__DIFF__2015-04 641.2133
     2016-11-11 14:47:48   2015-05-29_21-50-46__solar__total__DIFF__2015-05 477.6187
     2016-11-11 14:47:48   2015-06-30_23-58-32__solar__total__DIFF__2015-06 609.3093
     2016-11-11 14:47:48   2015-07-31_23-57-02__solar__total__DIFF__2015-07 720.6053
     2016-11-11 14:47:48   2015-08-31_23-59-23__solar__total__DIFF__2015-08 493.0880
     2016-11-11 14:47:48   2015-09-03_10-25-12__solar__total__DIFF__2015-09 22.2400
     2016-11-11 14:47:48   2015-11-27_19-24-23__solar__total__DIFF__2015-10 636.9493
     2016-11-11 14:47:48   2015-12-16_21-14-49__solar__total__DIFF__2015-12 169.1893
     2016-11-11 14:47:48   2016-01-31_23-55-29__solar__total__DIFF__2016-01 119.7307
     2016-11-11 14:47:48   2016-02-21_19-01-07__solar__total__DIFF__2016-02 176.5173
     2016-11-11 14:47:48   2016-03-31_23-58-15__solar__total__DIFF__2016-03 405.3307
     2016-11-11 14:47:48   2016-04-11_08-55-34__solar__total__DIFF__2016-04 129.1147
     2016-11-11 14:47:48   2016-05-01__solar__total__DIFF__2016-05 -
     2016-11-11 14:47:48   2016-06-01__solar__total__DIFF__2016-06 -
     2016-11-11 14:47:48   2016-07-31_23-58-47__solar__total__DIFF__2016-07 173.0987
     2016-11-11 14:47:48   2016-08-31_23-56-41__solar__total__DIFF__2016-08 655.4907
     2016-11-11 14:47:48   2016-09-30_17-18-19__solar__total__DIFF__2016-09 583.5653
     2016-11-11 14:47:48   2016-10-01__solar__total__DIFF__2016-10 -
     2016-11-11 14:47:48   2016-11-01__solar__total__DIFF__2016-11 -
     2016-11-11 15:17:58   state           connected
   Dbloghash:
     CONFIGURATION /opt/fhem/db-mysql.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/db-mysql.conf .*:.*
     NAME       myDbLogSQL
     NR         70
     NTFY_ORDER 50-myDbLogSQL
     PID        11765
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=1.2.3.1;port=3306
     dbuser     fhemuser
     Helper:
       Dblog:
         State:
           Mydblogsql:
             TIME       1478873901.14212
             VALUE      connected
     Readings:
       2016-01-05 11:46:03   lastReduceLogResult Rows processed: 245075, deleted: 234890, updated: 2340, time: 507.40sec
       2016-11-11 15:18:21   state           connected
Attributes:
   DbLogExclude .*
   aggregation month
   allowDeletion 0
   comment    2016-01-17 00:00:00
   device     solar
   reading    total
   timeout    600
   timestamp_begin 2000-01-17 00:00:00
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 November 2016, 16:26:11
Zitat
Aber in der Theorie würde es ja beim Umsprung auf 0 einen negativen DIFF-Wert geben. Den würde ich ignorieren und am nächsten Tag wieder neu die Differenz bilden...

Und was machen wir wenn der Nutzer eine Aggregation Woche oder Monat einstellt und der Zähler in der Mitte der Periode auf Null geht. Fängt dann die Woche oder der Monat mit 0 an ?
So einfach liegen die Dinge leider nicht ....
Möglciherweise fängt ddie neue Zählung auch garnicht bei 0 an usw.

Aber mir fehlt noch das verbose 4 log. Es kommt vor allem auf die SQL-Statemants an ob das Modul richtig selektiert. Wenn das da ist kann ich mir das mal anschauen. Aber dauert etwas weil ich momentan sehr eingespannt bin.

Gruß
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 November 2016, 18:15:34
Und was machen wir wenn der Nutzer eine Aggregation Woche oder Monat einstellt und der Zähler in der Mitte der Periode auf Null geht. Fängt dann die Woche oder der Monat mit 0 an ?

das userReading evaluiert das ja bei jedem event und zählt einfach nur die differenz dazu.
Wir müssten demnach vermutlich nach einem min suchen und schauenn ob das Min eines Monats kleiner ist als der Monatsanfang.
Die Rechnung würde dann lauten:
"letzter Eintrag vor MonatsMin"-MonatsAnfagg + MonatsEnde-MonatsMin, oder so ähnlich...

Log 4 kommt erst nächste Woche, bin unterwegs und am Handy gehts so schlecht...

Danke fürs ansehen, schönes Wochenende...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 November 2016, 09:53:58
Hi Joe,

Zitat
"letzter Eintrag vor MonatsMin"-MonatsAnfagg + MonatsEnde-MonatsMin , oder so ähnlich...

Ja genau ;)

Nehmen wir es mal ein bisschen auseinander. Nehmen wir an , es soll ein halbes Jahr in Monatsaggregationen mit diffValue ausgewertet werden. Nun werden zunächst innerhalb der vom Nutzer angegebenen Zeitgrenzen (time) die Selects in kalendarischen! Monatsscheiben (Perioden) aufgebaut, in diesem Fall 6 Scheiben der allgemeinen Art:

Select ...... where time >= Periode-begin und time < Periode-ende

und zur Abarbeitung / Auswertung an den Hintergrundprozess übergeben. Das ist wichtig damit alle Aktionen des Moduls nicht blockierend ausgeführt werden!

Nun findet in einer Periode zu einem unbekannten Zeitpunkt eine Nullung statt. Prinzipiell leicht festzustellen dass es passiert ist, nur ist völig unklar WANN es innerhalb der Periode aufgetreten ist. Um das festzustelllen, müßte nun ein neuer Evaluationsprozess initiiert werden, der über entsprechend kleinteilige Selects die betreffende Periode wiederholt untersucht und im Ergebnis eine möglichst exakte Näherung des genauen Zeitpunkts der Nullung liefert.
Wie kleinteilig die Selects sein müssen bzw. wie genau die Iteration stattfinden soll, wäre auch zu betrachten. Es ist sicherlich nachzuvollziehen, dass je ungenauer dieser Null-Zeitpunkt ermittelt wird, je größer die Abweichung des diffValue-Ergebnisses von dem tatsächlichen Differenzwertwert der entsprechenden Periode ausfallen wird.
Ggf. wäre ein ganzer Monat in Minutenscheiben! zu untersuchen. Das Verfahren kann sicherlich durch Iterationsmechanismen optimiert werden, führt aber dennoch zu einer signifikanten Komplexitätserhöhung des Gesamtprozesses.

Wäre der Nullpunkt möglichst exakt ermitttelt (time-null), wäre im nächsten Step dann die betroffene Monatsperiode in zwei kleinere Perioden zu unterteilen:

Select ...... where time >= Periode-begin und time < time-null
Select ...... where time >= time-null und time < Periode-ende

und zu summieren.  EDIT: Ggf. finden ja in einer Periode mehrere Nullungen (z.B. durch Stromausfall) statt. Dann wäre der Prozess noch weiter zu unterteilen.

Wenn dieser obige Prozess in der Gesamtheit abgeschlossen ist, könnten die restlichen Monatsscheiben abgearbeitet werden und die Ergebnisse zusammengefasst an den FHEM-Hauptprozess zurückgegeben werden um die Readings zu generieren. Auch das folgt aus den non-blocking Ansatz.

Die Vorgehensweise Datenbankinhalte auszuwerten unterscheidet sich also signifikant von einer einfachen Differenzberechnung zwischen Readingwerten beim Auftreten eines Events.

Sollte sich jemand in der Lage sehen, so etwas in den Ablauf hineinzuprogrammieren kann er mir gern einen Patch liefern.


Was man allerdings tun kann, und ich selbst mache es so, ist bei Zählerwerten immer die Differenzwerte in der DB speichern und dann mit der sumValue-Funktion des Moduls auszuwerten. Das ist eben bei Geräten sinnvoll bei denen die Gefahr besteht dass sie auf 0 zureckgesetzt werden.
In meinem Fall des SMA Energy Meters liefert das SMAEM-Modul bereits Differenzwerte bei den Messungen. Der SMA Meter wird bei Stromausfall auf 0 zurückgesetzt.

Wenn das in deinem Fall nicht nativ vom Zählermodul geliefert wird, kann wie von dir geschrieben ein userreading die Differenzen berechnen und diese Differenzen in der DB gespeichert und später ausgewertet werden.
Sollte das nicht möglich (oder gewünscht sein) könnte man die erste Auswertung an diesem Nullpunkt enden lassen und mit einem weiteren DbRep-Device die Auswertung ab diesem Nullpunkt fortführen.
Das entspräche quasi dem Begin einer neuen Abrechnungsepoche.

Ich warte dann mal auf dein verbose 4 log und schaue mir die Sache dann nächste Woche mal genauer an.

EDIT: Was auch wichtig ist zu wissen / zu beachten ist, dass diffValue IMMER mindestens ZWEI Werte innerhalb einer Aggreagtionsperiode zwingend benötigt um daraus eine Differenz zu berechnen !  D.h. wenn innerhalb der entspr. Periode nur EIN Wert enthalten ist, kann keine Differenz berechnet werden. Das werde ich demnächst in der Commandref bzw. im Wiki auch nochmal einprägsamer hinterlegen, damit man diesen Zusammenhang berücksichtigt.

Schönes WE und Grüße
Heiko



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 November 2016, 10:45:51
Ich glaube, du siehst das zu kompliziert!
Der Zeitpunkt de rnullung lässt sich leicht herausfinden!

Select timestamp, min(value) from history where device and timestamp between xx and yy.

Der unmittelbare Eintrag davor ist
select timestamp,value from history where device and timestamp < $timestampMIN order by timestamp desc limit 1

Der unmittelbare Eintrag danach ist
select timestamp,value from history where device and timestamp > $timestampMIN order by timestamp limit 1

Dann habe ich schon alles zusammen, um zu rechnen.


Eine andere, vielleicht noch einfachere Methode wäre schlichtweg:
Bilde ein Array mit allen Diffs des Zeitraums(also von Eintrag zu eintrag) , und zähle nur die positiven zusammen!
Das gibge sogar über eine temporäre tabelle...
Der Code könnte so lauten:
create temporary table mytable as
 SELECT 
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay < 0, 0 , value-@VDay) as diff,
    @VDay:= value as valueVortag
FROM history where device='powersolar' and reading='total' order by timestamp;

select sum(diff) from mytable where diff>0;
Ich kenn mich in SQL aus, leider nicht so in perl, weswegen ich hier nicht sonderlich helfen kann...

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 November 2016, 11:02:55
Zitat
Ich glaube, du siehst das zu kompliziert!

Ja, kann natürlich sein.

Dein Ansatz gefällt mir auf den ersten Blick ohne es genauer angeschaut zu haben was sich aus dem non-blocking Ansatz ergibt.

Aber dennoch ... nehme deine Verfahrens-Idee mal auf und wir schauen ob es zum Ziel führt.  :)

Danke und Gruß
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 November 2016, 14:39:40
Also der Ansatz mit einem Diff-Array scheint mir vielversprechend.
Bevor ich weiter einsteige, habe ich ein paar Versuche im SQL-Editor unternommen.
Allerdings kommt mit dem SQL

SELECT
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay < 0, '0' , value-@VDay) as diff,
    @VDay:= value as valueVortag
FROM history where device='MySTP_5000' and reading='etotal'
ORDER BY `history`.`timestamp`  DESC

immer "Null" heraus. Wobei ich ebenfalls der Meinung bin, dass das SQL so wie von dir vorgeschlagen auch funktionieren sollte. Irgenwo scheint aber noch ein Fehler zu sein. Die Ergebnis-Tabelle habe ich als Screenshot angehängt.
Hab momentan keine Zeit weiter zu forschen ... vllt. fällt dir addhoc noch etwas dazu ein.


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 November 2016, 14:55:16
Du hast die Sortierung durch das DESC umgekehrt,
darum trifft value-@VDay < 0 nie zu (außer in meinem sonderfall).
Ändere es daher in value-@VDay > 0 und es sollte gehen:

(Im Übrigen habe ich einen Sensor der nach jedem Stromausfall erneut bei 0 beginnt ;-) )

SELECT
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay > 0, '0' , value-@VDay) as diff,
    @VDay:= value as valueVortag
FROM history where device='MySTP_5000' and reading='etotal'
ORDER BY `history`.`timestamp`  DESC
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 November 2016, 15:31:28
Hmm, habs jetzt nochmal mit ">" sowie ohne DESC getestet. Hat in beiden fällen noch nicht funktioniert.
Screenshot wieder anbei.
Es ist doch so dass wenn value-@VDay < 0 zutrifft diff mit 0 bzw. mit der Differenz aus value - @VDay (der Normalfall) gefüllt wird.
Und das sollte auch so papassen.
Kann mir das momentan noch nicht erklären ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 November 2016, 15:38:45
Nö... achtung!
Entweder > UND desc, oder < ohne DESC.

mit DESC vergleichst den aktuellen Wert mit dem mit dem nächst jüngeren, ohne DESC bvergleichst Du umgekehrt.


habs getestet, bei mir funktioniert es!
Anbei noch eine Variante die das DiffTotal gleich ohne temporäre Tabelle mit berechnet.

Anbei mit Screenshot

SELECT
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay < 0, @diff:= 0 ,@diff:= value-@VDay) as diff,
       @diffTotal:= @diffTotal + @diff as diffTotal ,
    @VDay:= value as valueVortag
FROM history where device='powersolar' and reading='total'
ORDER BY `history`.`timestamp`  limit 100;
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 November 2016, 16:17:54
Zitat
Nö... achtung! Entweder > UND desc, oder < ohne DESC.

Ja das ist klar. Wollte nur sagen, habe es mit beiden Varianten bei mir getestet.

Du siehst ja auch in meinem letzten Screenshot dass auch die Variante "<" ohne DESC ebenfalls nicht das erwartete Ergebnis gebracht hat.
Nun habe ich auch noch die letzte Variante exakt genauso wie von dir geschrieben (nur andere device, readings) ausgetestet.
-> Screenshot

-> Null.  Also ich stehe da momentan vor einem Rätsel.



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 November 2016, 16:37:27
Hm... versuch mal zuvor diese Zeile, um die variablen zu definieren...

set @VDay=0,  @diff=0, @diffTotal=0;

Habs eben auf der Kommandozeile versucht, da hat es nur mit diesem Set zuvor funktioniert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 November 2016, 16:46:21
Jo, das wars.
Jetzt sieht es so aus wir erwartet.
Nun werde ich mal versuchen das Ganze in eine Testversion des Moduls zu gießen. Mal sehen wie Perls DBI mit so einem Kontrukt klarkommt.
Das wird aber eine Weile dauern. Komme sicherlich erst ab Montag wieder zu mehr.

Aber erstmal danke Jo für die Ansätze !

Schönes WE
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 November 2016, 23:50:13
Das freut mich... ich bin eh auch unterwegs, aber ich denke gerade dass diese Lösung die Performance auf dem rpi mit mysql
verbessern sollte...Ich habe übrigens das Layout der mysql-Datenbank angepaßt und hätte auch vorschläge im dblog zu verbessern, aber das wird glaub
ich recht weniggemaintenanced...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 November 2016, 22:47:49
Hallo Joe, @all,

habe die diffValue-Funktion im Modul entsprechend umgebaut und als Version 4.7 im Eingang hinterlegt.
Es hat anfangs etwas gehapert, aber nun läuft die Version.

Dadurch dass nun Nulldurchgänge erlaubt sind und entsprechend mit ausgewertet werden ist ein Nebeneffekt deutlich geworden der vorher keine Bedeutung hatte und nicht auffiel. Ich habe bei mir festgestellt, dass aus nicht erkennbaren Gründen immer mal wieder ein Nullwert durch DbLog in die DB geschrieben wird.  Es kann also zu kleinen Aussetztern in der Zahlenfolge kommen, die natürlich nicht als normale Differenz anzusehen sind und behandelt werden müssen.
Zum Beispiel:

 MjAxNi0wNA== 2016-04-13 10:03:20 8085.267 0.04399999999986903
 MjAxNi0wNA== 2016-04-13 10:04:27 8085.313 0.046000000000276486
 MjAxNi0wNA== 2016-04-13 10:05:34 8085.362 0.04899999999997817
 MjAxNi0wNA== 2016-04-13 10:06:41 8085.413 0.05099999999947613
 MjAxNi0wNA== 2016-04-13 10:07:48 8085.459 0.046000000000276486
 MjAxNi0wNA== 2016-04-13 10:08:55 8085.510 0.051000000000385626
  MjAxNi0wNA== 2016-04-13 10:10:02 0.000 0
 MjAxNi0wNA== 2016-04-13 10:11:09 8085.600 8085.6

 MjAxNi0wNA== 2016-04-13 10:12:16 8085.643 0.042999999999665306
 MjAxNi0wNA== 2016-04-13 10:13:23 8085.692 0.04899999999997817
 MjAxNi0wNA== 2016-04-13 10:14:30 8085.741 0.04899999999997817
 MjAxNi0wNA== 2016-04-13 10:15:37 8085.792 0.051000000000385626
 MjAxNi0wNA== 2016-04-13 10:16:44 8085.839 0.04699999999957072

(die letzte Zahl ist immer die Differenz, die signifikante Diff in dem Beispiel ist 8085.6)

Dabei soll nunmehr ein normales Setzen eines Energiezählers auf Null natürlich berücksichtigt werden.
Durch diesen Umstand habe ich den SQL-Select etwas verändert. Die Differenzen werden durch den DB-Server geliefert, aber die Bewertung der einzelnen Diffs auf Sinnhaftigkeit wird durch die Modullogik übernommen.

Nun kann das Modul nicht ganz allein feststellen welche Differenz ok ist und welche eventuell nicht mit einbezogen werden darf.
Um das zu lösen habe ich zunächst einen Schwellenwert (Limit) eingeführt, bis zu dessen Erreichen eine Differenz zwischen zwei unmittelbar aufeinander folgenden Messwerten als ok angesehen wird.
Sollte dieser Wert überschritten werden, passiert folgendes :

 1. dieser Differenzwert nicht berücksichtigt
 2. ein Reading mit allen Datensätzen,  die im diffValue-Lauf das diffLimit überschrittenhaben, wird generiert
 3. mit verbose=3 wird dieses Ergebnisarray ins Logfile geschrieben

 (siehe Screenshots im Anhang)

Das bedeutet also, dass man als Nutzer darauf hingeweisen wird wenn Auslassungen auftreten. Entweder igrnoriert man diese Datensätze, oder löscht sie wenn sie fehlerhaft sind und räumt so gleich die DB auf. Die relevanten Datensätze die diese Differenz verursachen sind im Reading
"diff-overrun_limit-<diffLimit>" bzw. im Log leicht ersichtlich.

Als weitere Möglichkeit kann der Nutzer das Differenzlimit mit dem Attribut "diffAccept" individuell anpassen um so eine größere Varianz zuzulassen.
Das Reading "diff-overrun_limit-<diffLimit>" zeigt im Teil <diffLimit> immer das aktuell eingestellte Limit an (als Standard habe ich 20 gewählt).

Wenn ihr also das neue Modul anwendet achtet bitte auf diese Ausgaben und macht entsprechende Justagen falls nötig/sinnvoll.
Das klingt jetzt vielleicht etwas kompliziert, aber wenn man ein paar Läufe gemacht und das Prinzip verinnerlicht hat ist es gut anwendbar und man kann dadurch auch ziemlich schnell Unregelmäßigkeiten in seinen Daten feststellen.

Es wäre schön wenn ihr auch SQLite bzw. PostgreSQL testen würdet. MySQL habe ich momentan schon gut durchgetest.

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 16 November 2016, 08:29:43
Hallo,

Vielen Dank, das sieht schon ganz gut aus!!
Das mit den 0-Einträgen habe ich nicht, vielleicht hängt das mit dem Modul deines Zählers zusammen?
Was ich sehe ist dass ich öffter doppelte Einträge in DBLog bekomme, also selbes Datum, reading, device und value.
Das verhindere ich iom Moment über einen primary key auf die Tabelle über alle diese spalten, aber vermutlich sollte ich mal in das dblog-modul reinschauen.

Was mir auffällt, das ist mir aber auch schon in der vorherigen Version aufgefallen, ist, dass
er hie raus mir unverständlichen Gründen kein Reading für  11.2015 erstellt, und stattdessen 2 Monate zusammenfasst. Hast Du dafür eine Erklärung?
2015-09-28_16-31-54__powersolar__total__DIFF__2015-09 348.7024
2015-11-30_23-57-05__powersolar__total__DIFF__2015-10 642.4555
2015-12-16_21-14-49__powersolar__total__DIFF__2015-12 169.2405

Edit 1: Nachtrag: diffAccept ist ein tolles Feature, vielen Dank dafür!!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 16 November 2016, 11:29:55
Ich weiß ja nicht ganz, wie es gedacht ist,
aber anbei  Daten von einer Mauellen Ablesung (also sehr lückenhaft!!)

"TIMESTAMP" "DEVICE" "TYPE" "EVENT" "READING" "VALUE" "UNIT" "Longterm"
"2008-01-11 00:00:00" "Manuell" "typ" "event" "Wasser" "335.61" "u" "0"
"2008-02-04 00:00:00" "Manuell" "typ" "event" "Wasser" "342.8" "u" "0"
"2008-02-29 00:00:00" "Manuell" "typ" "event" "Wasser" "349.635" "u" "0"
"2008-03-04 00:00:00" "Manuell" "typ" "event" "Wasser" "350.87" "u" "0"
"2008-03-27 00:00:00" "Manuell" "typ" "event" "Wasser" "356.581" "u" "0"
"2008-04-17 00:00:00" "Manuell" "typ" "event" "Wasser" "361.507" "u" "0"
"2008-05-07 00:00:00" "Manuell" "typ" "event" "Wasser" "366.283" "u" "0"
"2008-05-25 00:00:00" "Manuell" "typ" "event" "Wasser" "370.028" "u" "0"
"2008-06-03 00:00:00" "Manuell" "typ" "event" "Wasser" "371.447" "u" "0"
"2008-06-19 00:00:00" "Manuell" "typ" "event" "Wasser" "371.68" "u" "0"
"2008-06-20 00:00:00" "Manuell" "typ" "event" "Wasser" "372.251" "u" "0"
"2008-06-21 00:00:00" "Manuell" "typ" "event" "Wasser" "372.748" "u" "0"
"2008-07-13 00:00:00" "Manuell" "typ" "event" "Wasser" "377.134" "u" "0"
"2008-07-22 00:00:00" "Manuell" "typ" "event" "Wasser" "378.956" "u" "0"
"2008-07-23 00:00:00" "Manuell" "typ" "event" "Wasser" "379" "u" "0"
"2008-08-27 00:00:00" "Manuell" "typ" "event" "Wasser" "390.713" "u" "0"
"2008-09-18 00:00:00" "Manuell" "typ" "event" "Wasser" "396.529" "u" "0"
"2008-10-14 00:00:00" "Manuell" "typ" "event" "Wasser" "403.731" "u" "0"
"2008-10-30 00:00:00" "Manuell" "typ" "event" "Wasser" "408.307" "u" "0"
"2008-11-17 00:00:00" "Manuell" "typ" "event" "Wasser" "413.849" "u" "0"
"2008-12-03 00:00:00" "Manuell" "typ" "event" "Wasser" "417.307" "u" "0"
"2008-12-19 00:00:00" "Manuell" "typ" "event" "Wasser" "421.655" "u" "0"
"2008-12-31 00:00:00" "Manuell" "typ" "event" "Wasser" "425.871" "u" "0"

Hier ist der erste Eintrag 335,61 und der letzte ist 425,871.
Nun würde ich davon ausgehen, dass das Modul als Summe aller Monate irgendwas um die 90 aus gibt, da due Summe der Monate ja
weitestgehend der Differenz aus Jahresende-Jahresanfang entsprechen sollte.

Was ich jedoch erhalte ist: bei der monatlichen Zusammenfassung
0 7 6 0 4 1 2 0 0 5 0 9  sum(33)also eine grobe Verzerrung der Daten.

Mir ist schon bewußt, dass diese großen Lücken das problem sind, dennoch sollte das Modul (meiner Meinung nach)  keine solchen
Ergebnisse liefern.
Auch sollte der April hier im Beispiel niemals eine 0 liefern!
Die Ergebmisse waren übrigens mit der alten Version ebenfalls nicht korrekt.

Lösungsvorschlag:
Egal wie fein die Dateneinträge sind, denke ich, muss man die Lücken die differenzwerte in Minuten ausrechnen und auf jedes Ende eines Zeitblocks entsprechend die Minuten aufteilen.
Ansonsten verlierst du immer Werte dazwischen und die Gesamtzahl stimmt nicht!
Wenn der März also 31 Tage hat und die letzte Messung am 27.3. war, sollten vom nächsten Wert

Beispielsrechnung:
27.03.2008 356,58
17.04.2008 361,51
diffenzWert 4,93
differenzTage 21
diff in Minuten 30240
Betrag/Minute 0,000162897

TageMärz 5
TageApril 16
MinutenMärz 7200 (5*24*60)

EndstandMärz31.3.23:59:59   356,58 + 7200*0,000162897 = 357,7538571


Anbei noch meine Testdaten, falls Du damit direkt testen möchtest.
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-01-11 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '335.61', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-02-04 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '342.8', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-02-29 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '349.635', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-03-04 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '350.87', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-03-27 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '356.581', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-04-17 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '361.507', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-05-07 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '366.283', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-05-25 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '370.028', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-03 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '371.447', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-19 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '371.68', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-20 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '372.251', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-06-21 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '372.748', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-07-13 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '377.134', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-07-22 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '378.956', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-07-23 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '379', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-08-27 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '390.713', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-09-18 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '396.529', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-10-14 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '403.731', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-10-30 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '408.307', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-11-17 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '413.849', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-12-03 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '417.307', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-12-19 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '421.655', 'u');
INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2008-12-31 00:00:00', 'Manuell', 'typ', 'event', 'Wasser', '425.871', 'u');
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 November 2016, 20:34:32
Guten Abend JoeAllb,

ich versuche mal deine beiden Einträge von oben nach unten zu beantworten.

Zitat
Das mit den 0-Einträgen habe ich nicht, vielleicht hängt das mit dem Modul deines Zählers zusammen?

Ja, davon gehe ich auch aus. Im speziellen Fall ist es SMAUtils da die Werte von einem Solar-WR stammen. Möglicherweise hat der WR nicht geantwortet oder Null-Werte geliefert. Doch es ist gut dass ich auf diesen Fehler gelaufen bin. So konnte ich gleich entsprechenden Gegenmaßnahmen einbauen. Es ist ja nicht so abwegig dass andere User auch vor ähnlichen Problemen stehen könnten.

Zitat
Das verhindere ich iom Moment über einen primary key ...

Den primary key vermisse ich ebenfalls. Wenn es ihn gäbe könnte ich z.B. dem User sehr einfach eine Löschfunktion eines einzelnen Datensatzes über den Key in der GUI anbieten. Momentan müßte man zur eindeutigen Identifikation eines Datensatzes etliche Daten eingeben.

Zitat
Was mir auffällt, das ist mir aber auch schon in der vorherigen Version aufgefallen, ist, dass
er hie raus mir unverständlichen Gründen kein Reading für  11.2015 erstellt, und stattdessen 2 Monate zusammenfasst. Hast Du dafür eine Erklärung?

Noch nicht, aber eine gewisse Ahnung. Ich vermute hier einen Zusammenhang mit dem Wechsel von Sommer- zu Winterzeit.
Um das genauer zu sehen grenze deine Selektion temporär  zum Beispiel auf 20.10 - 30.11. ein (oder kopiere dir ein weiters DbRep-Device). Nur damit nicht so viele Daten geschrieben werden. Dann mache bitte ein verbose=5 log.

Kopiere alles ab dem Start des Selekts der im Log so ähnlich aussieht:

2016.11.16 18:54:58.661 4: DbRep Rep.Energy - -------- New selection ---------
2016.11.16 18:54:58.662 4: DbRep Rep.Energy - Aggregation: day
2016.11.16 18:54:58.662 4: DbRep Rep.Energy - Command: diffValue
2016.11.16 18:54:58.663 5: DbRep Rep.Energy - Timestamp begin epocheseconds: 1479279948
2016.11.16 18:54:58.663 4: DbRep Rep.Energy - Timestamp begin human readable: 2016-11-16 08:05:48
2016.11.16 18:54:58.663 5: DbRep Rep.Energy - Timestamp end epocheseconds: 1479318898
2016.11.16 18:54:58.663 4: DbRep Rep.Energy - Timestamp end human readable: 2016-11-16 18:54:58
2016.11.16 18:54:58.663 5: DbRep Rep.Energy - weekday of start for selection: Mi  ->  wdadd: 432000
...........................

Wahrscheinlich ist es dann gut ein separates File hier anzuhängen.
Dann schauen wir uns die Zeitgrenzen der einzelnen Statements an. Wenn meine Vermutung stimmt, haben wir einen Sprung im Oktober sodaß statt dem 31.10.  der 30.11 angezogen wird. Das Modul berücksichtigt DST von sich aus auf der Grundlage von Perl Standard localtime ob Sommer/Winterzeit (DST-Bit) vorliegt.

Auf welchem BS läuft dein FHEM ?  Wird Sommer/Winterzeit vom BS berücksichtigt ?

Zitat
diffAccept ist ein tolles Feature, vielen Dank dafür!!

Danke sehr  :) .... gebe mir Mühe das Modul mit deiner/eurer Hilfe weiter zu verbessern.

Zitat
Auch sollte der April hier im Beispiel niemals eine 0 liefern!

Wenn wir mit Aggregationen arbeiten, also mit Zeitperioden (Tag, Woche, Monat) innerhalb der gegebenen Zeitgrenzen für Start / Ende MUSS das Modul PRO Periode, in deinem Fall pro Monat, MINDESTENS zwei Werte zur Verfügung gestellt bekommen. Ansonsten kann es keine Differenz berechnen die somit "0" ist.  So wie bei dir im Januar, April, August, September ....

Wenn man bei automatischen Logvorgängen Probleme hat diese Rahmenbedingung einzuhalten, gibt es im Wiki einen Beschreibung für eine addLOg-Funktion mit der man zu jeder vollen Stunde, Tag etc. einen definierten Logeintrag schreiben lassen kann (http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden (http://www.fhemwiki.de/wiki/Plot-Abriss_vermeiden)). Es ist eine kleine Sub in der myUtils.pm mit etwas AT, NOTIFY drumherum.

Bei manuellen Eingaben muß man leider selbst darauf achten dies zu tun. Ich würde dir also vorschlagen an den Monatsgrenzen z.B. um 23:00:00 bzw. am nächsten Monat um 01:00:00 den gewünschten Ende- bzw. Startwert zu vermerken. Dann klappt es auch mit deinen Diffs und den daraus folgenden Summen.
Solltest du aber mal Tages- oder Wochenauswertungen anstoßen wollen, stehst du vor demselben Problem -> es wären keine Werte vorhanden.
Das ist ein generelles Manko der manuellen Eingabe. Der Nutzer muß dann wissen was er will und sich an bestimmte Regeln halten.

Zitat
Lösungsvorschlag:
Egal wie fein die Dateneinträge sind, denke ich, muss man die Lücken die differenzwerte in Minuten ausrechnen und auf jedes Ende eines Zeitblocks entsprechend die Minuten aufteilen.
Ansonsten verlierst du immer Werte dazwischen und die Gesamtzahl stimmt nicht!

Danke für deinen Vorschlag Joe. Ich finde diesen Wunsch auf jeden Fall nachvollziehbar und bedenkenswert.
Allerdings vertrete ich mit dem Modul einen anderen Ansatz bzw. eine andere Rollenverteilung zwischen der Datenbereitstellung und Datenauswertung.
D.h. die Datenbank ist die Etität die alle notwendigen Daten zur Verfügung stellt .... DbRep wertet diese Daten aus.

Man verliert also keine Werte .... sie werden schlichtweg nicht geliefert ! Also genau andersherum.

Das heißt auch, das schreibende Devicemodul bzw. der Nutzer selbst ist in der Rolle diese Daten je nach dem Auswertungsbedürfnis in die DB zu schreiben. Das Modul quasi zu "missbrauchen" unzulängliche oder fehlende Daten per se auszubügeln halte ich persönlich für etwas fragwürdig und in manchen Fällen vllt. sogar für schädlich.

Zwei Beispiele die mir adhoc einfallen:
Stell dir vor du bist 3 Wochen im Urlaub. Irgendwann später machst du eine Auswertung über den wöchentlichen Wasserverbrauch und wunderst dich wer in eurer Abwesenheit Wasser gezapft hat.  Oder schlimmer noch du wertest remote den Wasserverbrauch aus und vermutest ein Wasserleck weil dir gerade nicht mehr einfällt dass das Modul eine Schätzung in diesem Zeitraum ausführt. Der arme Nachbar der sich nach dem vermutlichen Leck totsucht ....  ;)
Oder zum Beispiel meine Solardaten. Der WR arbeitet nur während der Sonnenstunden, sonst nicht. Würden wir einfach mit Durchschnittswerten Fehlzeiten ausffüllen kämen zweifelhafte Werte heraus.

Ich möchte deine Idee trotzdem aufgreifen und könnte mir vorstellen dass man eine neue Funktion im Modul implementiert die, wenn vom Nutzer explizit gewünscht, fehlende Daten in einem beliebig festzulegenden Raster (10 Minuten, 1 Stunde, was auch immer ... ) in der Datenbank mit Durchschnittswerten auffüllt.
Wichtig für mich ist dass der Nutzer es ausdrücklich wünscht (er muß die Funktion ausführen) und er weiß was er tut.

Die Aussagekraft einer solchen Auffüllung würde ich allerdings eher mäßig bewerten und macht m.M. nach, wenn überhaupt, nur bei Messwerten Sinn die sich im Normalfall auch tatsächlich relativ gleichförmig über den Zeitraum verteilen.

Hmm ... mein Ethusiasmus den Programmieraufwand zu betreiben hält sich momentan in Grenzen  ;)

Aber ich könnte den User dahingehend unterstützen eine Warnung z.B. im "state" auszugeben wenn Rahmenbedingungen, wie nur ein Messwert pro Periode, oder die Überschreitung von diffAccept, vorliegen. Dann kann entsprechend reagiert werden.

Ich schlage vor wir lösen erst einmal noch dein Novemberproblem und wenn ich den aktuellen Enwicklungsstand noch dokumentiert sowie eingecheckt habe schauen wir weiter.  Deine manuellen Werte würde ich wie beschrieben als Workaround ergänzen. Das dauert schätzungsweise 15 Minuten. Dann passt das.

Grüße
Heiko



 


 
 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 16 November 2016, 21:17:17
Hallo Heiko,

Danke für deine Nachricht.

Danke für deinen Vorschlag Joe. Ich finde diesen Wunsch auf jeden Fall nachvollziehbar und bedenkenswert.
Allerdings vertrete ich mit dem Modul einen anderen Ansatz bzw. eine andere Rollenverteilung zwischen der Datenbereitstellung und Datenauswertung.
D.h. die Datenbank ist die Etität die alle notwendigen Daten zur Verfügung stellt .... DbRep wertet diese Daten aus.
 

Ich gebe Dir da völlig recht, ich bin selbst Datentechniker!
Aber ich hoffe, dass Du mit mir übereinstimmst, dass die Summe aller Monatssumme, eines Jahres zumindest gerundet den selben Wert ergeben sollte,
wie die Subtraktion von Max-Min. Ich denke, dass dies zentral wichtig ist für die Funktion dieses Moduls.


GGf. kann man ja auch den Operator auswählen, also ob man die Werte roh nimmt, oder ob man eben diese mittelwerte berechnet...
Evetuell wäre es auch hilfreich, den "errechneten" werten einen Prefix im Reading zu geben, sodass man diese farblich kennzeichnen kann?

Ich bin heute unterwegs, sehe es mir aber morgen wieder genauer an! Danke für die Rückmeldung!!

lG
Joe

PS: Du könntest ja vorschlagen, für dein Modul einen primary key zu definieren. Andere Module geben auch Indexe vor!
Ich arbeite übrigens zusätzlich mit partitionierten Tabellen, das macht da slöschen alter Einträge deutlich einfacher.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 November 2016, 22:05:49
Hi Joe,

Zitat
Aber ich hoffe, dass Du mit mir übereinstimmst, dass die Summe aller Monatssumme, eines Jahres zumindest gerundet den selben Wert ergeben sollte, wie die Subtraktion von Max-Min.

Ja, klar. Keine Frage.

Zitat
Ich arbeite übrigens zusätzlich mit partitionierten Tabellen, das macht da slöschen alter Einträge deutlich einfacher.

Das habe ich jetzt nicht wrklich verstanden. Kannst du mir mal erläutern wenn du wieder Zeit hast.

Bis dann und schönen Abend !

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 17 November 2016, 16:50:40
Zur Partition: Meine History-Tabelle sieht so aus!
Damit erreiche ich folgende Vorteile:
1. Durch den primary Index bekomme ich keine doppelten Werte in die DB.
2. Durch die mehreren Partitionen (mehrere SQL-Tabellen) habe ich seit 5 Jahren keinen Ausfall auf der SD-Speicherkarte.
3. Alle Daten die das Flag "Longterm haben" haben, bleiben dauerhaft erhalten. Kurze Zwischendaten bekommen bei Longterm eine 0.

Ich kann somit die Partition aller 6 älteren Logeinträge ohne Verzögerung (also in ca. 0 sekunden) löschen.
ALTER TABLE history DROP PARTITION monNolong ;löscht zum beispiel alle Logdaten die ich nicht dauerhaft speichern möchte, und an einem Montag abgespeichert wurden.
Da eben die ganze Partitionstabelle (=Datei) gelöscht wird, funktioniert dies auf einem RPI viel schneller.
Dadurch behalte ich zB alle Daten die jünger sind, also DI oder MI gespeichert wurden.


CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(40) NOT NULL DEFAULT '',
`TYPE` VARCHAR(32) NULL DEFAULT NULL,
`EVENT` VARCHAR(512) NULL DEFAULT NULL,
`READING` VARCHAR(45) NOT NULL DEFAULT '',
`VALUE` VARCHAR(32) NULL DEFAULT NULL,
`UNIT` VARCHAR(32) NULL DEFAULT NULL,
`Longterm` TINYINT(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`, `Longterm`),
INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE
)
COLLATE='latin1_swedish_ci'
PARTITION BY RANGE (WEEKDAY(timestamp))
SUBPARTITION BY HASH (Longterm)
(PARTITION mon VALUES LESS THAN (1)
 (SUBPARTITION monNolong ENGINE = MyISAM,
  SUBPARTITION monLong ENGINE = MyISAM),
 PARTITION tue VALUES LESS THAN (2)
 (SUBPARTITION tueNolong ENGINE = MyISAM,
  SUBPARTITION tueLong ENGINE = MyISAM),
 PARTITION wed VALUES LESS THAN (3)
 (SUBPARTITION wedNolong ENGINE = MyISAM,
  SUBPARTITION wedLong ENGINE = MyISAM),
 PARTITION thu VALUES LESS THAN (4)
 (SUBPARTITION thuNolong ENGINE = MyISAM,
  SUBPARTITION thuLong ENGINE = MyISAM),
 PARTITION fri VALUES LESS THAN (5)
 (SUBPARTITION friNolong ENGINE = MyISAM,
  SUBPARTITION friLong ENGINE = MyISAM),
 PARTITION sat VALUES LESS THAN (6)
 (SUBPARTITION satNolong ENGINE = MyISAM,
  SUBPARTITION satLong ENGINE = MyISAM),
 PARTITION sun VALUES LESS THAN (7)
 (SUBPARTITION sunNolong ENGINE = MyISAM,
  SUBPARTITION sunLong ENGINE = MyISAM))  */;

Bei gewissen Werten kann man übrigens wurderbar über eine Stored-Procedure direkt sicherstellen, dass diese als Longterm abgespeichert werden.



Für mich funktioniert dieses System wunderbar, vielleicht ist es aber nicht für jeden das optimale.

sG joe.

PS: Ich bin auf Dienstreise und mein Serverzugang ist leider versehentlich geschlossen, kann also kein Log4 machen! Ich habe dir aber oben meine Testdaten direkt angehängt, du kannd damit also einfach testen und sie ja danach leicht wieder aus deiner DB löschen...

Edit1:
Diese Fehlermeldung ist zwar gut gemeint, trifft bei mir aber nicht zu, da ich die Tabelle erweitert habe... könnte man das zumindest einstellbar machen (oder aber du fragst die Tabellenbreite direkt aus der DB ab?)
Length of "reading" is too big. Maximum lenth for database type MYSQL is 32
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 November 2016, 00:36:10
Hallo Joe, @ all,

danke für deine Erläuterungen.
Das ist doch schon eine Individuallösung, klingt aber auf jeden Fall interressant. Ich kann jetzt nicht beurteilen ob alle durch DbLog (jetzt nicht meine Baustelle) unterstützten Datanbanktypen so etwas supporten würden.

Aber der DbLog-Maintainer hat kürzlich die Feldlängen angepasst / vereinheitlicht. Ich habe das jetzt auch im DbRep nachgezogen. Es sind jetzt 64 Zeichen für Reading usw. Später will ich mal schauen ob man das über das Perl DBI direkt aus der Tabelle abfragen kann. Allerdings hab ich, als ich die get -Metadatenabfrage des Moduls gebaut habe, eine solche Möglichkeit nicht gesehen weil ich in diesem Rahmen schon mal danach gesucht habe. Muß aber nicht heißen dass es die nicht gibt.  Vielleicht hat jemand einen Tipp !!

Ich habe wieder eine neue Version 4.7.1 hinterlegt in der folgendes geändert ist:

 * Feldlängen auf den derzeitigen DbLog-Standard angepasst
 * es werden die Readings check diff-overrun_limit , not_enough_data_in_period erzeugt wenn das diffAccept-Limit überschritten wird bzw.
   falls  in einem Aggregationszeitraum für diffValue nur ein Datensatz gefunden wird und deswegen kein Diff-Wert errechnet werden kann.
   Das Reading enthält dann die betroffenen Perioden.
 * im Logfile werden mit verbose 3 die Inhalte der obigen Readings protokolliert

Joe, deine Testdaten habe ich bei mir importiert und diffValue Auswertungen gemacht. Es funktioniert bei mir auch für den November.
D.h. ist sehr wahrscheinlich ein Prob mit der DST auf deinem Rechner.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 18 November 2016, 09:48:19
Hallo Heiko,

danke! Werde das testen, sobald ich wieder Zugriff auf meinen Rechner habe. Leider habe ich versehentlich sshd beendet ;-)


Das mit den Partitionen ist eine Speziallösung, da gebe ich dir recht, und das kann auch kein sqlite!
Das schöne ist ja, dass man die Tabelle diesbezüglich verändern kann, ohne dass es den Rest von fhem tangiert.

Anbei ein SQL, mit welchem man die Spaltenbreite herausfinden kann... ob das nötig ist, kann ich gerade nicht beurteilen.
Danke für die Anpassung der Werte... ich hatte 4.7 diesbezüglich auch schon "gepatcht".

show COLUMNS from history like 'device';

Ich verwende übrigens normales Debian 8 x86  als Distribution, habe noch ein auf einem kleinen Backupgerät ein Raspbian drauf,
da werde ich es mir auch mal ansehen.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 November 2016, 11:51:03
Hi Joe,
Danke für den Tipp. Ich hatte vom Perl DBI bei der Funktion Tableinfo erwartet dass diese Info mitgeliefert würde.
Tut sie nicht, aber so komme ich sicherlich auch weiter. Sehe ich mal in der Zukunft mit vor.

Dann erstmal ein schönes WE !

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2016, 12:10:49
Hallo zusammen,

habe gerade festgestellt dass die neuen SQL-Statements (V 4.7.x) in diffValue für SQLite NICHT funktionieren.
Wer SQLite benutzt, sollte erstmal weiterhin die eingecheckte Version benutzen. Sobald ich dazu komme werde ich im Modul noch eine Fallunterscheidung innerhalb der diffValue-Funktion einbauen damit SQLite weiterhin die bisherigen SQL-Statements benutzt.
Ich wollte die neue Version heute schon einchecken und habe das Wiki bereits angepasst ... das dauert nun leider etwas....

VG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 20 November 2016, 14:33:24
Hallo Heiko,

danke...
Ich verwende leider kein sqlite, da es keine gleichzeitigen mehrfachen Zugriffe erlaubt, und für mich das Grundvoraussetzung ist.

Ich habe wieder Zugriff auf meinen Debian, musste ihn neu installieren, und nun findet er auch für den November Einträge.
Ich werde mir das morgen nochmal genauer ansehen....


sG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 20 November 2016, 16:07:18
habe gerade festgestellt dass die neuen SQL-Statements (V 4.7.x) in diffValue für SQLite NICHT funktionieren.
Nur als Idee:
Geh die einzelnen Datensätze in einer perl-schleifew mit prepare und fetchrow durch und berechnest den diffvalue dort.
Sollte von der performance her kaum einen unterschied machen und es bliebe für beide datenbanktypen gleich...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2016, 19:18:43
Hallo Joe,

für SQLite werde ich das wieder  so wie bis zur 4.6 selektieren. Nur muß ich nun den Ergebnishash gleichziehen mit MySQL damit auch solche neuen Funktionen wie diffAccept und die Warnings bei Limit-Überschreitung für alle unterstützten DBs gleichermaßen funktionieren.
Ich habe da schon einen Plan, brauche nur wieder etwas Zeit es umzusetzen und zu testen.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2016, 23:10:16
Hallo,

in der Version 4.7.3 im Eingangsthread habe ich diffValue nun auch wieder für SQLite lauffähig.
Würde mich freuen wenn SQLite-Nutzer die Version ebenfalls testen könnten.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Masterfunk am 27 November 2016, 10:05:45
Nach dem Update auf die neuste Version startet DbRep nicht mehr.

Im Logfile habe ich folgende Meldung:

2016.11.27 09:17:13 1: reload: Error:Modul 93_DbRep deactivated:
 syntax error at ./FHEM/93_DbRep.pm line 3564, near "$ch{"
syntax error at ./FHEM/93_DbRep.pm line 3566, near "$ch{"
Global symbol "$key" requires explicit package name at ./FHEM/93_DbRep.pm line 3566, <$fh> line 1489.
Global symbol "%ncp" requires explicit package name at ./FHEM/93_DbRep.pm line 3567, <$fh> line 1489.
Global symbol "%ncp" requires explicit package name at ./FHEM/93_DbRep.pm line 3570, <$fh> line 1489.
Can't use global @_ in "my" at ./FHEM/93_DbRep.pm line 3578, near "= @_"
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 3579, <$fh> line 1489.
syntax error at ./FHEM/93_DbRep.pm line 3615, near "}"

Hab jetzt wieder die alte im Einsatz, läuft einwandfrei.

Gruß Detlef
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 November 2016, 10:11:50
Morgen Detlef,

die neueste eingecheckte Version oder die aus dem Forum ?
Habe bei mir kein Prob bisher festgestellt.

Gruß
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 November 2016, 10:38:05
Habe gerade auch nochmal ein "update 93_DbRep.pm" in FHEM durchgeführt und FHEM restartet.
Die aktuelle eingecheckte Version ist:

# $Id: 93_DbRep.pm 12631 2016-11-22 21:07:28Z nasseeder1 $

Keine Probleme festgestellt ...

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Masterfunk am 27 November 2016, 11:36:14
Mit folgender habe ich das Problem:

93_DbRep.pm          12631 2016-11-22 21:07:28Z nasseeder1
Gruß Detlef
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 November 2016, 11:55:46
Genau die habe ich auch bei mir nochmal getestet (siehe oben) . Ohne Probleme ... das ist ja eigenartig.
Ich schaue es mir in Ruhe an. Wird aber erst morgen.

Können andere User das Problem mit dieser Version bestätigen oder ist das bei Detlef eine Ausnahme ?

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 27 November 2016, 13:40:28
bei mit geht sie problemlos
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 November 2016, 11:58:49
Hallo Detlef,

ich vermute du hast eine etwas niedrigere Perl-Version als ich bzw. Joe und die kam mit dem Code nicht zurecht.
Teste mal bitte die V4.7.4 aus dem Eingangsbeitrag.

@Joe, wenn du magst ...  Bei mir läuft diese ebenfalls. Es betrifft eine sub von diffValue.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Masterfunk am 28 November 2016, 23:08:52
Hallo Detlef,

ich vermute du hast eine etwas niedrigere Perl-Version als ich bzw. Joe und die kam mit dem Code nicht zurecht.
Teste mal bitte die V4.7.4 aus dem Eingangsbeitrag.

@Joe, wenn du magst ...  Bei mir läuft diese ebenfalls. Es betrifft eine sub von diffValue.

Grüße
Heiko

Die geht!

Gruß Detlef
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 November 2016, 23:39:10
Prima ... danke für die Rückmeldung. Dann checke ich diese Version ein.

Gruß
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 29 November 2016, 09:32:00
Ich konnts leide rnicht testen, war unterwegs, aber starten lässt sich fhem damit!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Xunil66 am 07 Dezember 2016, 20:30:55
Hallo Heiko,

ich bin heute bei meinen Tages / Stunden Reportings in Timeouts gelaufen  :'(
habe mir das ganze mal mit verbose 5 angeschaut und gesehen das im Modul 30 bzw 24 abfragen an die Datenbank gehen.

Kann man das ectl. mit "group by" selects erledigen ? Ich habe mir gerade mal testweise die selects zusammengebaut.
In meiner DB Komme ich auf ca. 3 Sekunden für einen kompletten Monat anstatt ca. 2 Sekunden je einzel Select.
Ich hänge mal meine SELECT an.

# Monatswerte auslesen
SELECT MONTH(TIMESTAMP) , SUM(VALUE)
FROM history
where DEVICE LIKE 'energyMeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-01-01' AND TIMESTAMP < '2016-12-31'
GROUP BY MONTH(TIMESTAMP)

# Tageswerte auslesen
SELECT DAY(TIMESTAMP) , SUM(VALUE)
FROM history
where DEVICE LIKE 'energyMeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-12-01' AND TIMESTAMP < '2016-12-31'
GROUP BY DAY(TIMESTAMP)

# Stundenwerte auslesen
SELECT HOUR(TIMESTAMP) , SUM(VALUE)
FROM history
where DEVICE LIKE 'energyMeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-12-06' AND TIMESTAMP < '2016-12-07'
GROUP BY HOUR(TIMESTAMP)

Gruß
Markus
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2016, 21:17:53
Hallo Markus,

vielleicht könnte man das. Es stellen sich sich natürlich viele Fragen:
- Klappt das für jede unterstützte DB ? wer testet alles durch ?
- die Readingsstruktur der Ergebnisse würde sich ändern, alle Funktionen wären anzupassen / zu testen, testen, testen mit jeder DB ...
- Funktioniert die Berücksichtigung Daylight Saving Time und wie steuert man rein wenn nicht ?
- Dann die Ergebnisse. Habe zum Bespiel mal schnell in der SQL-Konsole:
  SELECT DAY(TIMESTAMP) , SUM(VALUE) FROM history where DEVICE LIKE 'SMA_Energymeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-01-01' AND TIMESTAMP < '2016-12-31' GROUP BY DAY(TIMESTAMP)
ausgeführt. Ergebnis ist dass die Tage 1 ... 31 ausgegeben werden. Nichts weiter. Man erkennt nicht die Tage der Monate. Das ist sicher mit entsprechenden Aufwand aufzuarbeiten, aber wird eben nicht so einfach geliefert.

- Wie sauber klappen die Abgrenzungen ? Kann man sich darauf verlassen und wie könnte man die einzelnen Abgrenzungen loggen um die Ergebnisse überprüfbar zu machen ?
- Wie wäre dann z.B. abzubilden dass man bei der diffValue-Funktion einen Schwellwert angeben kann bei dessen Überschreitung die Diff als Fehler gewertet wird und wie logged man das für den Anwender ?

Das sind nur ein paar Gedanken die mir spontan einfallen.

Man kann sicher vieles machen. Nur wollte ich das Augenmerk mal darauf lenken wieviel Aufwand eine solche Änderung verursachen könnte.
Und man kommt immer wieder an problematische Stellen die den Aufwand alles sauber umzusetzen nach oben treiben.

Vorschlag: setze das Attribut timeout höher, dafür ist es da  ;) und dann strahlt auch wieder die Sonne  :)

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Xunil66 am 07 Dezember 2016, 21:40:31
Hallo Heiko,


Das Timeout hatte ich schon hochgesetzt. Die Sonne scheint  :D
Ich nutze mySQL als DB auf zentralem Server.

Evtl. wäre diese Abfrage das was Du für ein ganzes Jahr als Tagesabfrage suchst ?


SELECT MONTH( TIMESTAMP ) as Monat , DAY( TIMESTAMP ) as Tag, SUM( VALUE )
FROM history
WHERE DEVICE LIKE 'energyMeter'
AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff'
AND TIMESTAMP >= '2016-12-01'
AND TIMESTAMP < '2016-12-31'
GROUP BY MONTH( TIMESTAMP ) , DAY( TIMESTAMP)

Schönen Abend
Markus
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2016, 21:55:09
Hi Markus,

Zitat
Evtl. wäre diese Abfrage das was Du für ein ganzes Jahr als Tagesabfrage suchst ?

Jo klar.  Mit entsprechenden Aufwand lässt sich vieles machen und auseinandersteuern :) 

Danke für die Hinweise. Vielleicht hast du ja mal Lust von dem DbRep-Modul ausgehend eine Testversion mit deinen Selectvorschlägen zu bauen ?
MySQL nutze ich auch.
Aber es ist eben unabdingbar dass auch SQLite und eigentlich auch PostgreSQL mit dem Modul klarkommen (PostgreSQL hat aber noch keiner gemeldet).

Man muß eben immer auch Nebenbedingungen berücksichtigen. Z.B. gebe ich bei maxValue den Zeitstempel des als Maxwert selektierten Datensatzes im Reading aus. Das sind so kleine Goodies.

Ich verwende noch Zeit für den SMAInverter und dann ist erstmal wieder SSCAM dran. Lange vernachlässigt ...

Also schauen wir mal.

Grüße
Heiko



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2016, 08:45:16
Morgen Markus,

auch wenn größere Änderungen bei DbRep momentan nicht auf meiner Agenda stehen war ich doch neugierig  ;) und habe mal Für SQLite die Abfrage gestartet:

SELECT DAY(TIMESTAMP) , SUM(VALUE) FROM history where DEVICE LIKE 'SMA_Energymeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-01-01' AND TIMESTAMP < '2016-12-31' GROUP BY DAY(TIMESTAMP)
SQLite kann damit nicht umgehen:

no such function: DAY: SELECT DAY(TIMESTAMP) , SUM(VALUE) FROM history where DEVICE LIKE 'SMA_Energymeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-01-01' AND TIMESTAMP < '2016-12-31' GROUP BY DAY(TIMESTAMP)
Wenn jemand andere Ergebnisse mit SQLite vorweisen kann ... gerne posten.

Schönen Tag zusammmen,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Xunil66 am 08 Dezember 2016, 09:04:22
Morgen Heiko,

ich werde mal versuchen eine eigene Version des Moduls mit group_by selects zu bauen. Dazu noch eine kurze Frage zwecks Testsystem. Macht es mehr Sinn in FHEM alles 3 mal in die DBs ( mySQL, SQlite und Postgres) zu schicken oder per cron export import zu syncronisieren ?

Markus
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2016, 09:51:25
Hi Markus,

Ich würde mit Export Import arbeiten. DbLog ist nach wie vor blockierend und belastet dein FHEM wenn du parallel in die verschiedenen DBs schreibst.
Freue mich dass du unterstützt. :)  Das hilft mir bei meinem knappen Zeitbudget.
Ich helfe dir gerne bei Fragen, auch mit PM wenn es nicht von allgemeinem Interesse ist.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2016, 18:03:21
Hallo zusammen,

im Startbeitrag habe ich die aktualisierte V4.7.7 eingefügt.
Funktional ist lediglich hinzugekommen dass die benötigten Module hinsichtlich ihres Installationsstatus überprüft werden und die DbRep Entwicklungsversion als Internal dargestellt wird.

Ansonsten ist nur etwas Code aufgeräumt und reviewed.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2016, 11:43:06
Hi,
diese Zahlen sind meines Erachtend völlig legitim, sie lösen auch keine Warnung aus, aber das Ergebnis stimmt nicht.

INSERT IGNORE  INTO history VALUES ('2016-10-05 00:00:00','Test','typ','event','test','49047','manuell');
INSERT IGNORE  INTO history VALUES ('2016-10-07 00:00:00','Test','typ','event','test','49147','manuell');
INSERT IGNORE  INTO history VALUES ('2016-11-01 00:00:00','Test','typ','event','test','50000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-11-02 00:00:00','Test','typ','event','test','51000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-01 00:00:00','Test','typ','event','test','60000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-02 00:00:00','Test','typ','event','test','60000','manuell');

Bei diesem Zähler habe ich pro Monat 2 Werte. Lt. LOG habe ich 60000-49047, also 10953 kw Strom verbraucht.
Die Readings sehen so aus:
2016-09-01__stromverbrauch__2016-09 -
2016-10-07_00-00-00__stromverbrauch__2016-10 100.0000
2016-11-02_00-00-00__stromverbrauch__2016-11 1000.0000
2016-12-02_00-00-00__stromverbrauch__2016-12 -

Zählen also nur 1100 kw Strom.

Folgende Fehler erkenne ich daraus (denke ich):
1. Das Datum ist zu strickt eingegrenzt
2016-11-01 00:00:00 = 2016-10-31 23:59:59 [59..], sollte(muss) also für den Oktober noch mitgezählt werden! (Die FHEM-Plots rechnen diesen Datumswert ebenfalls noch mit! Siehe Screenshot))
Die letzte Sekunde geht also nahtlos in die erste und endet dort, wo der nächste tag beginnt. und das ust eben der nächste Tag um 00:00:00
2. Zwischen November und Dezember habe ich 10000kw Strom verbraucht. Die Korrektur von Fehler 1 könnte schon die Korrektur für diesen Fehler sein.

Meine Device-Config ist:
defmod calc_Test DbRep myDbLogSQL
attr calc_Test DbLogExclude .*
attr calc_Test aggregation month
attr calc_Test allowDeletion 0
attr calc_Test device test
attr calc_Test diffAccept 50000
attr calc_Test reading test
attr calc_Test readingNameMap stromverbrauch
attr calc_Test timeout 15200
attr calc_Test timestamp_begin 2016-09-01 00:00:00

Edit1:
Nachtrag: der SQL für den Oktober müsste also
select * from history where device="test" and timestamp between '2016-10-01 00:00:00' and '2016-11-01 00:00:00';lauten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2016, 12:44:06
Hi Joe,

die Abgrenzung mit between:

select * from history where device="test" and timestamp between '2016-10-01 00:00:00' and '2016-11-01 00:00:00';
hatte ich Anfangs so. Hat sich nicht bewährt weil dieser Wert dann im nächsten Abrechnungszeitraum ebenfalls, also doppelt gezogen wurde (wenn auf Zeitgrenze 00:00:00 angegeben).
Deswegen erfolgte die Änderung so wie es jetzt ist.

Da es sich um manuelle Eingaben handelt würde ich die nicht unbedingt auf die Zeitgrenze 00:00:00 legen.

Abgesehen davon hat das Modul aufgrund deiner Angaben völlig recht. Warum ? Weil du angegeben hast dass du im November 51000 - 50000 kWh verbraucht hast = 1000, im Dezember hingegen 60000 - 60000 = 0  (bzw. "-") !

Was hier fehlt ist der Endstand im November, die fehlende Differenz von 9000 kWh zwischen dem angegebenen  Endwert von 51000 im Nov und dem Anfangswert von 60000 im Dez. Möglicherweise hast du die ja garnicht verbraucht sondern nur einen andren Zähler eingebaut  ;) (philosoph. Betrachtung am Rande).

Bei manuellen Einträgen bitte immer darauf achten dass diese Angaben im Sinne der Auswertung auch Sinn machen. Der Endwert einer Auswertungsperiode sollte auch immer der Anfangswert der nächsten Periode sein (bzw. mit einer hinreichend kleinen Differenz).
In deinem Bespiel hast du zw. Nov. und Dez. 9000 kWh "unterschlagen".

Bei automatischen Erfassungen alle x-Sekunden/Minuten stellt sich diese Frage nicht.

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2016, 14:14:55
hatte ich Anfangs so. Hat sich nicht bewährt weil dieser Wert dann im nächsten Abrechnungszeitraum ebenfalls, also doppelt gezogen wurde (wenn auf Zeitgrenze 00:00:00 angegeben).
[code]INSERT IGNORE  INTO history VALUES ('2016-10-07 00:00:00','Test','typ','event','test','49000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-11-01 00:00:00','Test','typ','event','test','50000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-01 00:00:00','Test','typ','event','test','51000','manuell');
Was kann da doppelt gezählt werden?

In diesem Beispielszeitraum wurden 2000 verbraucht. Egal wie du es drehst, das Datum mit 00:00:00 wird hier niemals doppelt gezählt, daher ist dies sicher die richtige variante!
Es wäre also eklatant falsch, hier die 00:00:00 nicht mitzurechnen! Das würde maximal einen Fehler an anderer Stelle bder Berechnung beschönigen, aber richtig wird es dadurch nicht!




Abgesehen davon hat das Modul aufgrund deiner Angaben völlig recht. Warum ? Weil du angegeben hast dass du im November 51000 - 50000 kWh verbraucht hast = 1000, im Dezember hingegen 60000 - 60000 = 0  (bzw. "-") !
Nein, hat es eben nicht! Das Modul verfälscht die Werte massiv!
Ich habe ihm nicht gesagt, dass er Werte die am Monatsübergang entstanden sind einfach unberücksichtigt lassen soll...
Es ist eindeutig, dass ich in dem Zeitraum mehr Strom verbraucht habe, als dein Modul mir anzeigt. Auch die Jahressumme stimmt somit natürlich nicht.
Nur weil das Modul den 1.1. 00:00:00 nicht korrekt betrachtet, ignoriert es einfach völlig korrekte Werte.

Da es sich um manuelle Eingaben handelt würde ich die nicht unbedingt auf die Zeitgrenze 00:00:00 legen.

Nein, es sind bewußt abgefragte Werte (mit AT).
Wenn ich das korrigieren wollte müsste ich meine Datensätze verdoppeln und 2 Abfragen machen,
eine um 31.10. 23:59:59 und eine weitere um 1.11. 00:00:01. und das nur, weil das Modul mit dem korrekten Eintrag um 00:00:00 nicht zurecht kommt?
und seinen VWert dann völlig ignoriert?
Wie gesagt, andere FHEM-Module handhaben das korrekt! Sieh dir die Plots an, dort sieht man auch die Werte, die aus der Datenbank abgerufen wurden..  (Anbei ein Screenshot)
Ich finde es einfach zusätzlich verwirrend, wenn dein Modul andere

Was hier fehlt ist der Endstand im November, die fehlende Differenz von 9000 kWh zwischen dem angegebenen  Endwert von 51000 im Nov und dem Anfangswert von 60000 im Dez. Möglicherweise hast du die ja garnicht verbraucht sondern nur einen andren Zähler eingebaut  ;) (philosoph. Betrachtung am Rande).

Bei automatischen Erfassungen alle x-Sekunden/Minuten stellt sich diese Frage nicht.
Selbst wenn das Zeitfenster kleiner ist, ignorierst du immer einen Wert um  00:00:00....
selbst für wenige Minuten bedeutet dies dennoch immer eine Verfälschung der Werte.
Dies trifft auf alle Szenarien zu  und ist somit imer ein Feher! Sorry

Genau genommen ignoriet das Modul sämtliche Werte zwischen dem letzten der Vorperiode und dem ersten Messwert der Nachfolgeperiode. Egal wie viel Zeit da vergeht (bei meinem Stromzäghler manchmal 4 Stunden) wird sämtlicher Verbtauch hier einfach ignoriert. Wenn die die Monate also zusammenzähle, fehlen diese Werte komplett.  Bei jedem Periodenübergang fehlen demnach
Werte, um so mehr Periodenübergänge es gibt, umso größer wird der Fehler.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2016, 14:56:45
Hallo Joe,

zunächst sollten wir einmal davon ausgehen dass DbRep kein Abrechnungstool für Energieunternehmen ist sondern in der Datenbank vorhandene Werte auswertet.

Zitat
In diesem Beispielszeitraum wurden 2000 verbraucht. Egal wie du es drehst, das Datum mit 00:00:00 wird hier niemals doppelt gezählt, daher ist dies sicher die richtige variante!

Ich sehe es etwas anders Joe. Bitte betrachte immer die abgeschlossenen Auswertungszeiträume / Aggregationen. In deinem Beispiel sagst du es wurden 2000 verbraucht. Das ist zwar richtig, allerdings nicht wenn man den Oktober bzw. November für sich als Betrachtungszeitraum abgrenzt.
Die Aussage dass mit der Zeitangabe 00:00:00 nichts doppelt gezählt wird, wurde schon hier diskutiert: https://forum.fhem.de/index.php/topic,53584.msg496812.html#msg496812  (https://forum.fhem.de/index.php/topic,53584.msg496812.html#msg496812) und deswegen auch geändert.

Zitat
Es ist eindeutig, dass ich in dem Zeitraum mehr Strom verbraucht habe, als dein Modul mir anzeigt. Auch die Jahressumme stimmt somit natürlich nicht.

So ?  Hast du mal mit der Begin = Jahresanfang und Ende = Jahresende  und Aggregation = no gerechnet ?
Also ich gehe davon aus dass es stimmen wird.

Deine weiteren Anmerkungen möchte ich momentan nicht kommentieren.
Es können zwar immer Fehler auftreten, davor ist niemand gefeit, aber mir gefällt dieser Ton hier momentan überhaupt nicht.  :(

Zitat
Genau genommen ignoriet das Modul sämtliche Werte zwischen dem letzten der Vorperiode und dem ersten Messwert der Nachfolgeperiode.

Wie gesagt es ist kein Abrechnungstool für Energieunternahmen sondern ein Hilfsmittel um seine DB-Inhalte nach bestimmten Kriterien (die auch bestimmten Rahmenbedingungen unterliegen)  auszuwerten.

Wenn es für dich so nicht passt dann ändere das Modul doch und wir schauen ob es dann besser klappt.
Wie gesagt wir hatten schon ein paar Betrachtungen (siehe Link) durch.

Grüße
Heiko
 








Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2016, 15:24:16
Die Aussage dass mit der Zeitangabe 00:00:00 nichts doppelt gezählt wird, wurde schon hier diskutiert: https://forum.fhem.de/index.php/topic,53584.msg496812.html#msg496812  (https://forum.fhem.de/index.php/topic,53584.msg496812.html#msg496812) und deswegen auch geändert.

Da fehlt aber ein Beispiel von Bobby! Die Werte können sich nicht doppelt auswirken (Bei DIFF... bei anderen Zählmethoden schon, aber da ist der Fall ja soewieso ganz anders gelagert!
DIFF stimmt immer nur mit Berücksichtigung dieser Werte)! Kann es sein, dass Bobby's Meldung nicht bezüglich DIFFs war? ( Ich hab kein Beispiel von ihm dazu gefunden)

Ich denke, für die Kombination DIFF und AGGREGATTIOn wurde dadurch ein der Fehler erst eingeschleust.
 
So ?  Hast du mal mit der Begin = Jahresanfang und Ende = Jahresende  und Aggregation = no gerechnet ?
Also ich gehe davon aus dass es stimmen wird.
Ja klar. Dies zeigt aber eindeutig, dass die Aggregation( in Kombination mit DIFF) falsch ist (wenn dohne Aggregation korrekte Werte rauskommen, mit jedoch nicht)!

Es können zwar immer Fehler auftreten, davor ist niemand gefeit, aber mir gefällt dieser Ton hier momentan überhaupt nicht.  :(
Wie soll ich mich denn ausdrücken? Du kannst nicht sagen, dass ich mich nicht bemüht habe, und keine Zeit in Beispiele und Screenshots gesteckt habe.

Wie gesagt es ist kein Abrechnungstool für Energieunternahmen sondern ein Hilfsmittel um seine DB-Inhalte nach bestimmten Kriterien (die auch bestimmten Rahmenbedingungen unterliegen)  auszuwerten.

Verlangt auch niemand. Und dennoch geht es falsch und anders wie andere FHEM-Module mit den selben Daten und den selben Rahmenbedingungen
(gib mir einen Monatsplot <=> gib mir eine Monatsaggregation)
 um.
Bei Aggregation und DIFF liefert es immer falsche Werte. Vielleicht sollte man diese Kombination dann einfach sperren(wobei dies die einzige ist, die mich aktuell interessiert).
[/quote]
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2016, 15:51:51
Zitat
Du kannst nicht sagen, dass ich mich nicht bemüht habe, und keine Zeit in Beispiele und Screenshots gesteckt habe.

Natürlich nicht. Wir geben uns schließlich alle gemeinsam Mühe, wir haben schließlich auch schon einges mit viel Schweiß  zusammen angepasst (DIFF) oder ?
Aber ich denke du weißt was ich damit meine.

Zitat
Ja klar. Dies zeigt aber eindeutig, dass die Aggregation( in Kombination mit DIFF) falsch ist (wenn dohne Aggregation korrekte Werte rauskommen, mit jedoch nicht)!

Würde ich jetzt so global nicht unterschreiben. Ich werte sehr häufig mit DIFF und Tagesaggregation aus. Das klappt , aber ich habe auch jede Minute Messwerte

Zitat
Bei Aggregation und DIFF liefert es immer falsche Werte. Vielleicht sollte man diese Kombination dann einfach sperren(wobei dies die einzige ist, die mich aktuell interessiert).

Bloss nicht. Genau die verwende ich auch zuhauf (Tagesaggregation und Monatsaggregation) . Aber wie gesagt mit häufigen in der DB vorhandenen Messwerten. und das klappt (zumindest in der Genauigkeit von ca. 0,0x die für mich ok sind).

Mir fällt addhoc kein allgemein gültiges Lösungsszenario ein.
Du kannst ja mal für dich nur für die Diff-Funktion das Select auf "between" ändern.

Aber das löst natürlich nicht das Problem dass wenn du z.B. nur am 26.11. und am 10.12. einen Messwert hast genau am 01.12. keine Messgröße hast die man auswerten könnte. Wir hatten schon mal mit einer Auffüllfunktion gespielt die die nicht vorhandenen Werte nach einem Durchschnittsverfahren in der DB ersetzen um so ansatzweise die Abschätzung durchführen zu können. Selbst mit "between" kommt man da nicht weiter.

Eigentlich braucht man immer zwei Messwerte in der DB um einen Nullpunkt herum. Zum Beispiel wenn man eine Stundenaggregation macht genauso.
Etwas  praktikableres fällt mir dazu momentan nicht ein.

Vielleicht kommt das Modul in genau diesen Grenzfällen an seine Einsatzgrenzen.
Möglicherweise fällt uns noch etwas ein ... aber mir grad nicht. Ob es praktikabel machbar wäre für jedes denkbar mögliche Aggregationsszenario einmal in die vergangene Periode zu gucken kann ich jetzt nicht beurteilen, halte es aber für ziemlich schwierig.

Grüße
Heiko



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2016, 17:19:08
Hallo Heiko,

... danke fürs weiter mitüberlegen :D, ich denke(hoffe), wir verstehen uns schon...

Würde ich jetzt so global nicht unterschreiben. Ich werte sehr häufig mit DIFF und Tagesaggregation aus. Das klappt , aber ich habe auch jede Minute Messwerte
Die Fehlwerte sind bei minütlichen Einträgen halt sehr klein, aber auch da vorhanden ;-)

Mir fällt addhoc kein allgemein gültiges Lösungsszenario ein.

Idee: Wir könnten zum Wechselzeitpunkt(Nullpunkt) ein weiteres Reading  mit Diff erzeugen, das den "unzuordenbaren" Betrag abspeichert.
Dann stimmt die Gesamtsumme, und jedem ist ersichlich, dass es da noch einen wert gibt, der keinem Monat eindeutig zugeordnet werden konnte.
Leuten, denen x% genauigkeit ausreichen, können diese ignorieren, und ich kann mir daraus etwas überlegen, wie ich den wert anteilig aufs alte und aufs neue Monat zurechne.
Ob wir das dann in eine spätere Version des Moduls einfliesen lassen, können wir ja dann später entscheiden...
Dies hätte auch gleich den Vorteil, dass man sieht, wieviele Werte ignoriert werden...


Du kannst ja mal für dich nur für die Diff-Funktion das Select auf "between" ändern.

Ich kann nicht wirklich Perl... aber mal sehen;
Was war der Fehler von bobyg genau? Dann kann ich mitüberlegen, was die korrekte korrektur seines Fehlers wäre. Hier ist zu 100% das andere das korrekte!

Eigentlich braucht man immer zwei Messwerte in der DB um einen Nullpunkt herum. Zum Beispiel wenn man eine Stundenaggregation macht genauso.
Nein, sorry, das stimmt nicht! Wenn man GENAU den Nullpunkt nimmt, gilt dieser immer auf beiden seiten! Um beim Beispiel zu bleiben ist dieser kurze Zeitpunkt nämlich beides... Oktober und november.
Da in diesem Augenblick aber kein Strom verbraucht werden kann, weil die Zeiteinheit de rkleinst anzunehmende Wert ist, macht dies auch nichts aus und verändert keinerlei werte.
(( Under der Kurve ist die Fläche =0, ! eine Sekunde später ist die Fläche wieder >0 im November, ene sekunde davor für den Oktober...

Vielleicht kommt das Modul in genau diesen Grenzfällen an seine Einsatzgrenzen.

Mit meinem Vorschlag von oben nicht... dann wäre alles wieder ok, und wir müssten den Wert nicht über irgendwelche Formeln auf die einzelnen Monate verteilen.


Schöne Güße
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2016, 19:42:18
Hi Joe,

ich war grad beim Sport und konnte dabei nochmal in Ruhe nachdenken.

Zitat
ich denke(hoffe), wir verstehen uns schon...

Na klar, wi rlassen uns doch nicht kleinkriegen  :)

Also ich denke DiffValue kann ohne negative Nebenwirken getrost mit between bzw. => und  <= Timestamp ausgeführt werden (between ist schneller glaub ich).
Problematisch ist es eigentlich nur bei SumValue weil dann die "Grenzwerte" auf beiden Seiten addiert werden und dann die Summe über den Gesamtzeitraum mit den Aggregationen nicht stimmt.

Vielleicht habe ich sogar auch einen Ansatz gefunden der so ähnlich wie dein Vorschlag funktionieren könnte.
Ich probiere mal was wenn ich dazu komme und melde mich wieder.

Erstmal einen schönen Abend !

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2016, 20:50:30
Erstmal einen schönen Abend !

Hallo Heiko,

danke, dir auch, bzw. Wochenende!

schöne Grüße!
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2016, 13:26:05
Hallo Joe, @all,

im ersten Beitrag gibt es eine neu eVersion 4.8.1.

Hier habe ich die Funktion diffValue auf "between" umgestellt. Das bedeutet dass die Differenzen nun von <first Aggregation> 00:00:00 - <next Aggregation> 00:00:00 ausgeführt werden und Values berücksichtigen die genau auf dem "Grenzwert" in der DB abgespeichert sind.

Weiterhin habe ich eine Lösung implementiert die einen Differenzübertrag in eine neue Aggregationsperiode vornimmt.
Das bedeutet dass die Differenz zwischen dem letzten Wert der Voraggregationsperiode X und dem ersten Wert der darauf folgenden Periode X+1 in die Periode X+1 übernommen und dieser zugeschlagen wird.

Um bei Joes Beispiel zu bleiben:

INSERT IGNORE  INTO history VALUES ('2016-11-02 00:00:00','Test','typ','event','test','51000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-01 00:00:00','Test','typ','event','test','60000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-02 00:00:00','Test','typ','event','test','60000','manuell');

Die Differenz zw. 51000 (2016-11-02 00:00:00) und 60000 (2016-12-01 00:00:00) wird erkannt und diese 9000 in die Monatsaggregation 12.2016 übertragen. Damit würde (sollte) sich für die Monatsaggregation 12.2016 eine Diff von 9000 ergeben.
Das Attribut diffAccept  fließt mit ein was bedeutet dass es in dem Beispiel auf einen Wert > 9000 gesetzt werden müßte um diese Differenz akzeptieren zu lassen.

Diese Verfahren stellt m.M. nach sicher dass mathematisch nichts "verloren" geht. Vom logischen Standpunkt ist es natürlich nicht unbedingt schlüssig da der Verbrauch ja eher zwischen dem 02.11. und 30.11 anfiel. Vielleicht kriege ich das noch besser geregelt, mal schauen.

Ich hatte noch keine Zeit diese Version in allen möglichen Varianten zu testen und möchte euch bitten es als Arbeitsstand anzusehen und eigene Tests damit zu machen und die Ergebnisse zu posten. Bei mir funktioniert es in den "Standardsituationen" tadellos.

@Joe schau mal ob es im Ergebnis schon den Erfordernissen nahekommt. 

Weiteres später ... Grüße und schönes WE,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 10 Dezember 2016, 13:44:17
Wow, vielen Dank, das klingt großartig!!!
Werds heute Abend testen, wenn ich zuhause bin!


Diese Verfahren stellt m.M. nach sicher dass mathematisch nichts "verloren" geht. Vom logischen Standpunkt ist es natürlich nicht unbedingt schlüssig da der Verbrauch ja eher zwischen dem 02.11. und 30.11 anfiel. Vielleicht kriege ich das noch besser geregelt, mal schauen.

Ist denke ich schon ok, ersteres ist im Moment wichtiger als letzteres.... denn wenn mir das nicht gefällt, kann ich ja (zumindest einstweilen) mir selbst noch einen
Zwischen-Wert ausrechnen, der das Ergebnis dann besser "verteilt". Danke in diesem Zusammenhang auch für deine "insert" funktion!


Danke Heiko,
schöne Grüße Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 10 Dezember 2016, 13:52:37
Hm, konnte es doch schon jetzt testen (erstaunlich, was manchmal am handy alles so klappt).

Ivh bekomme nun öfter Minuseinträge, so wie in diesem Beispiel.
2012-07-01__stromverbrauch__2012-07 11400.9000
2016-12-10 13:49:33 2012-08-01__stromverbrauch__2012-01 -11400.9000

Ich wollte das jetzt nur melden, die genauen Daten dazu muss ich mir tatsächlich später ansehen, aber eigentlich sollte die DIFF-Funktion ja nie negativ werden, oder?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2016, 14:55:22
Hi Joe,

Zitat
aber eigentlich sollte die DIFF-Funktion ja nie negativ werden, oder?

nee, sollte nicht.

Wie gesagt ... erstmal testen und zusammentragen. Dann korrigieren wir wieder bis es richtig klappt.

Bis später ...
Grüße Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2016, 16:10:07
Hi Joe,

ich glaube das Problem mit den negativen Diffs in der V4.8.2 (Eingang) beseitigt zu haben.
Habe es mit deinen Wasserdaten vom letzten Mal durchlaufen lassen.
Klappt sogar wenn nur ein Wert im Monat vorhanden ist. Warnung kommt aber noch.

Aber jetzt muß ich echt ... bis später

Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 Dezember 2016, 09:20:35
Hallo Heiko,

meine Tests verliefen bisher sehr erfolgreich, vielen Dank für die Änderungen!
Mein Heizungszähler, der eigentlich recht häufig Werte liefert,  hat damit im letzten Jahr gleich 120KWh mehr angezeigt... das unterscheidet sich nur um 5 kwh von der
Ablesung, aber diese ist ja nicht am 31.12...
Ich werd das nochmals demnächst genau nachrechnen, aber ich gehe davon aus, dass dies jetzt stimmt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Dezember 2016, 09:28:12
Morgen Joe,

das hört sich gut an ... danke für die Rückmeldung.
Ich werde auch noch Tests in verschiedenen Konstellationen durchführen und das Ganze auch mal noch mit SQLite durchziehen.

Dauert aber noch bisschen ...

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 11 Dezember 2016, 20:40:06
aus dem Wiki:

 ALTER TABLE 'fhem'.'history' ADD INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE;
 oder:
 CREATE INDEX Reading_Time_Idx ON `fhem`.`history` (READING, TIMESTAMP);
jetzt helft doch bitte mal einen Laien in Sachen DB weiter... worin liegt der Unterschied?

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Dezember 2016, 21:52:03
Hallo,

macht faktisch keinen Unterschied außer in der obligatorischen Angabe eines Indexnamens ....

Zitat aus  http://stackoverflow.com/questions/17113149/what-is-the-difference-between-mysqls-create-index-and-alter-add-index (http://stackoverflow.com/questions/17113149/what-is-the-difference-between-mysqls-create-index-and-alter-add-index)  ->
What is the difference between MySQL's create index and alter add index?

Zitat

The implementation is the same on the server-side.

The only practical difference is that with ALTER TABLE, you have the option to create an index without specifying a name for the index. The server generates a default name, as the name of the first column in the index, with a number suffix if necessary.

Whereas with CREATE INDEX syntax, you must specify a name for the index.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 11 Dezember 2016, 22:04:43
wenn ich mit folgenden Anweisungen eine DB erstelle:

sudo sqlite3 /opt/fhem/DbLog.db

CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));

wie müsste dann die Anweisung für den INDEX aussehen?

edit:
CREATE INDEX Reading_Time_Idx ON 'history' (READING, TIMESTAMP);
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Dezember 2016, 22:22:16
Es kommt darauf an welche Felder der Index einschließen soll. Das hängt davon ab wie letztendlich die Abfrage der DB erfolgen soll.

Mein Beispiel:
CREATE INDEX Reading_Time_Idx ON `history` (READING, TIMESTAMP);
fügt nur die Felder READING und TIMESTAMP zu diesem Index hinzu. Dieser Index würde Abfragen der Form " Select  .... where Reading = .... AND TIMESTAMP = ..." beschleunigen.  Man könnte nun noch weitere und im Extremfall alle Felder der DB mit hinzufügen.

Um zum Beispiel Device noch mit hinzuzunehmen würde es etwa so aussehen:

CREATE INDEX Reading_Dev_Time_Idx ON `history` (READING, DEVICE, TIMESTAMP);
Entspechendes für die Tabelle "current" :

CREATE INDEX Reading_Dev_Time_Idx ON `current` (READING, DEVICE, TIMESTAMP);
Problem dabei ist dass diese Indizes Platz auf der DB benötigen der u.U. an die Größe der Daten selbst herankommen.
Ich weiß jetzt nicht was der Hintergrund deiner Frage ist, aber ich würde den Erfolg (Verringerung Laufzeit) des Indexaufbaus einfach austesten und wegen des benötigten Platzes nur Indizes erstellen die einen Performancegewinn verursachen.



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 11 Dezember 2016, 22:28:04
Danke erst mal für Deine Antworten.

Im Grunde überlege ich mir gerade wie ich meine DB für Logdaten am besten aufsetzte und später auch Pflege. Im Wiki zu DbRep bin ich auf den Hinweis gestossen dass aus Performancegründen ein Index erstellt werden soll. Wenn ich die DB erneut aufsetze, dann aber auch von Anfang an richtig.

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Dezember 2016, 22:34:40
Auf MySQL kannst/willst du nicht wechseln ?
Wenn ich wählen könnte (hab ich ja) würde ich auf MySQL setzen.

Während ich mit DbRep im Entwicklungsprozess mit beiden DB-Typen teste, komme ich immer wieder zu dem Ergebnis dass MySQL performanter arbeitet.
Möglicherweise ist das auch von meiner konkreten Testumgebung abhängig, doch ist dies mein Erfahrungswert. 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 12 Dezember 2016, 09:56:45
Gab es bei MySQL nicht die Einschränkung in der Länge der Device Namen?

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Dezember 2016, 11:37:38
Ja, die gibt es. Aber es etwas entspannt weil die Länge auf 64 Zeichen im DbLog abgeändert wurde.
Da!mit kommt man gut klar denke ich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Dezember 2016, 08:43:43
Ja, die gibt es. Aber es etwas entspannt weil die Länge auf 64 Zeichen im DbLog abgeändert wurde.

Und zur Not kann man die Spaltenbreite selbst bei den Tabellen noch weiter erhöhen, funktioniert bei mir bisher recht gut.
Ich habe sogar auf einem kleinen Raspi v1 eine Mysql-DB am laufen, und es klappt wunderbar.
Natürlich ist die CPU-Auslastung etwas höher als bei SQLIte, dafür ist sonst vieles um vieles angenehmer.
zB gleichzeitiger Zugriff auf die DB von fhem und vom Anwender, auswertungen, stored Procedures, ..

Ich würde hier immer wieder mysql (oder aktueller MariaDB als 1:1 Ersatz für MySQL) verwenden.

@Heiko: Bei mir läuft die VErsion gut, und da sie für mich entscheidendes verbessert, würde ich für ein Eincheckem plädieren ;-)

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2016, 17:56:11
Hallo Joe, @all,

ich habe noch etwas gefunden und mit Version 4.8.3 gefixt.
Mit dieser Version werden die Differenzüberträge auch über eine oder mehrere Leerperioden hinweg transportiert und der nächsten Aggregationsperiode die einen Wert enthält, zugeordnet.

Was ich damit meine ist an dem Beispiel erläutert.
Mit fetchrows sehen die Daten so aus:


2008-01-11_00-00-00__Manuell__Wasser   335.61   2016-12-13 17:11:18
2008-02-04_00-00-00__Manuell__Wasser   342.8   2016-12-13 17:11:18
2008-02-29_00-00-00__Manuell__Wasser   349.635   2016-12-13 17:11:18
2008-03-27_00-00-00__Manuell__Wasser   356.581   2016-12-13 17:11:18
2008-05-07_00-00-00__Manuell__Wasser   366.283   2016-12-13 17:11:18
2008-05-25_00-00-00__Manuell__Wasser   370.028   2016-12-13 17:11:18
2008-06-03_00-00-00__Manuell__Wasser   371.447   2016-12-13 17:11:18
2008-06-19_00-00-00__Manuell__Wasser   371.68   2016-12-13 17:11:18
2008-06-20_00-00-00__Manuell__Wasser   372.251   2016-12-13 17:11:18
2008-06-21_00-00-00__Manuell__Wasser   372.748   2016-12-13 17:11:18
2008-07-13_00-00-00__Manuell__Wasser   377.134   2016-12-13 17:11:18
2008-07-22_00-00-00__Manuell__Wasser   378.956   2016-12-13 17:11:18
2008-07-23_00-00-00__Manuell__Wasser   379     2016-12-13 17:11:18
2008-10-14_00-00-00__Manuell__Wasser   403.731   2016-12-13 17:11:18
2008-10-30_00-00-00__Manuell__Wasser   408.307   2016-12-13 17:11:18
2008-11-17_00-00-00__Manuell__Wasser   413.849   2016-12-13 17:11:18
2008-12-03_00-00-00__Manuell__Wasser   417.307   2016-12-13 17:11:18
2008-12-19_00-00-00__Manuell__Wasser   421.655   2016-12-13 17:11:18


Es gibt hier eine Datenlücke im April und August/September. Mit der Version 4.8.3 sieht diffValue für dieses Beispiel nun so aus:

2008-01-11_00-00-00__Manuell__Wasser__DIFF__2008-01   -           2016-12-13 17:09:52
2008-02-29_00-00-00__Manuell__Wasser__DIFF__2008-02   14.0250   2016-12-13 17:09:52
2008-03-27_00-00-00__Manuell__Wasser__DIFF__2008-03   6.9460   2016-12-13 17:09:52
2008-04-01__Manuell__Wasser__DIFF__2008-04                   -               2016-12-13 17:09:52
2008-05-25_00-00-00__Manuell__Wasser__DIFF__2008-05   13.4470   2016-12-13 17:09:52
2008-06-21_00-00-00__Manuell__Wasser__DIFF__2008-06   2.7200   2016-12-13 17:09:52
2008-07-23_00-00-00__Manuell__Wasser__DIFF__2008-07   6.2520   2016-12-13 17:09:52
2008-08-01__Manuell__Wasser__DIFF__2008-08                   -           2016-12-13 17:09:52
2008-09-01__Manuell__Wasser__DIFF__2008-09                   -           2016-12-13 17:09:52
2008-10-30_00-00-00__Manuell__Wasser__DIFF__2008-10   29.3070   2016-12-13 17:09:52
2008-11-17_00-00-00__Manuell__Wasser__DIFF__2008-11   5.5420   2016-12-13 17:09:52
2008-12-31_00-00-00__Manuell__Wasser__DIFF__2008-12   12.0220   2016-12-13 17:09:52

D.h. die Differenz zw. dem 27.03. und 25.05. wird aus 370,028 - 356,581 = 13,447 errechnet und der Aggregationsperiode 2008-05 zugeordnet (der ersten Periode mit einem Wert die auf die Leerperiode folgt).
Das gleiche funktioniert über mehrere benachbarte Leerperioden. Es gibt keinen Wert für August/September.
Hier wird die Differenz aus dem letzten Wert Oktober und dem letzten Wert Juli gebildet, also 408,307 - 379 = 29,307. Diese Diff wird wiederum der auf eine Leerperiode folgenden Aggregationsperiode (hier 2008-10) zugeordnet.

Das hat in dieser Form in V4.8.2 noch nicht funktioniert wei meine Tests gezeigt haben.

Schau(t) mal ob es auch bei euch so gut funktioniert wie bei mir.
Dann wäre ich auch für ein Check-In  :)

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Dezember 2016, 18:01:52
Danke, ja, die KWs wurden nun nochmal etwas nach oben korrigiert!!
Sehr schön! Funktioniert 1a.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2016, 18:10:12
Wow, jetzt warst du aber schnell  :)
Ich sehe zu es heute Abend noch einzuchecken. Muß noch dokumentieren....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 13 Dezember 2016, 18:13:14
Mit der DB bin ich jetzt nach MySQL umgezogen, klappt gut und die Performance ist wirklich deutlich besser. Konsequenter weise sollte ich dann ach meine configDB mit umziehen lassen.

1. Gibt es da eine einfache Methode des Datentransfers vom sqlit3 nach MySQL?

2. Bei sqlit3 habe ich regelmässig ein VACUUM gemacht, besteht die Notwendigkeit einer Optimierung bei MySQL auch und wie erfolgt das dann bei MySQL?

3. für sqlit3 gab es die Möglichkeit mittels
attr myDbLog userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
sich die große des DB-Files anzeigen zu lassen. Gibt es hier für MySQL auch eine Möglichkeit den Speicherbedarf der DB zu ermitteln?

Dann hatte ich folgendes Thema bereits in Beitrag zu DbLog angebracht...

Hintergrund: Ich schreibe in meine DB Daten die ich lediglich 7 Tage aufbewahre und Daten die ich über 2 Jahre aufbewahren möchte. Bei den Daten die ich 2 Jahre aufbewahren möchte handelt es sich um Zählerstände bei denen ich gerne das Vorjahr als Vergleichszeitraum haben möchte. Von der Datenmenge her würde es völlig ausreichen wenn ich 2 Datensätze pro Monat in der DB stehen hätte, da ich lediglich die Differenz bilde. Für den aktuellen Tag können es dann ruhig ein paar mehr sein, die sollten dann aber am folgenden Tag auf 2 Werte, den ersten und den letzten reduziert werden. Wie man sich jetzt vorstellen kann handelt es sich bei dem ersten Wert am Tag / Monat um den letzten Wert des Vortages / Vormonats (ich mache um 00:00:01 einen Übertrag auf den Folgetag), wodurch es prinzipiell auch ausreichen würde den letzten Wert des Tages / Monats in der DB stehen zu haben, da man sich ja den Wert zur Differenzbildung aus dem Vortag / Vormonat holen kann. Jetzt benötigt DbRep aber mindestens zwei Werte pro Periode. Währe es ein großer Aufwand z.B. eine Option einzubauen, die es erlaubt bei diffValue auf den letzten Wert der Vorperiode zurückzugreifen?

Alternativ hatte ich schon bei der DbLog Entwicklung (https://forum.fhem.de/index.php/topic,41089.msg535819.html#msg535819) angefragt ob man die Option im ReduceLog lediglich den letzten Wert zu behalten ausweiten kann auf den ersten und den letzten.

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Dezember 2016, 18:19:52
Mit der DB bin ich jetzt nach MySQL umgezogen, klappt gut und die Performance ist wirklich deutlich besser. Konsequenter weise sollte ich dann ach meine configDB mit umziehen lassen.
1. Gibt es da eine einfache Methode des Datentransfers vom sqlit3 nach MySQL?
ich würde zurück auf fhem.cfg gehen und wenn dir dbconfig gut gefällt, einfach wieder neu mit DBconfig für mySQL beginnen.

2. Bei sqlit3 habe ich regelmässig ein VACUUM gemacht, besteht die Notwendigkeit einer Optimierung bei MySQL auch und wie erfolgt das dann bei MySQL?

optimize table history;
Wie man sich jetzt vorstellen kann handelt es sich bei dem ersten Wert am Tag / Monat um den letzten Wert des Vortages / Vormonats (ich mache um 00:00:01 einen Übertrag auf den Folgetag), wodurch
Ich würde  00:00:00 empfehlen. Dann wird es korrekt in den Plots angezeigt und auch andere Module verwenden den Wert wie gedacht.
Da dieser Wert bei Plots automatisch als Anfag und Ende verwendet wird, würde Dir damit auch ein einziger Eintrag pro Tag ausreichen!

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2016, 18:28:02
Hallo Frickler,

darf ich deine Fragen zum Teil zurückstellen weil ich grad wenig Zeit habe, aber:

Zitat
Bei sqlit3 habe ich regelmässig ein VACUUM gemacht, besteht die Notwendigkeit einer Optimierung bei MySQL auch und wie erfolgt das dann bei MySQL?

Die Entsprechnung wäre "optimize table". Es dient auch dazu Freiplatz innerhalb der DB freizugeben bzw. der Performanceoptimierung. Ab einem bestimmten Release geht es m. Wissens sogar online nicht blockierend (Joe ? ). Dafür würde ich dann sogar noch eine Funktion in DbRep einbauen.

Zitat
die große des DB-Files anzeigen zu lassen. Gibt es hier für MySQL auch eine Möglichkeit den Speicherbedarf der DB zu ermitteln?

Ja , du kannst die Funktion "get ... tableinfo" im DbRep. Habe Screenshots im Anhang.

Zitat
Währe es ein großer Aufwand z.B. eine Option einzubauen, die es erlaubt bei diffValue auf den letzten Wert der Vorperiode zurückzugreifen?

Habe ich jetzt in der V4.8.3 (Eingang) umgesetzt. Teste mal wie es bei dir funktioniert.

Vllt. kann Joe noch etwas dazu sagen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 13 Dezember 2016, 18:43:05
ich habe irgendwie das Gefühl dass mein Setup in MySQL doch nicht so gelungen ist. Tableinfo gibt mir folgenden error text:

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.
Das Erweitern auf 64 char scheint auch nicht gefruchtet zu haben.

2016.12.13 18:36:19 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'DEVICE' at row 1 at ./FHEM/93_DbLog.pm line 613.



Die DB habe ich gemäß wiki und folgender Datei erstellt:

apt-get install mysql-server mysql-client libdbd-mysql libdbd-mysql-perl

mysql -u root -p < db_create_mysql.sql

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemUser'@'%' IDENTIFIED BY 'fhemUser01';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemUser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);

Danach noch:

ALTER TABLE current MODIFY VALUE VARCHAR(64);
ALTER TABLE history MODIFY VALUE VARCHAR(64);

Mit meinen beschränkten SQL Kenntnissen kann ich dann folgendes Ergebnis erkennen:

mysql> use fhem
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current        |
| history        |
+----------------+
2 rows in set (0,00 sec)

mysql>
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Dezember 2016, 18:49:30
Sorry, habe gerade wenig Zeit.
Mach mal folgendes, um auch die Device-Spalte zu vergrößern.

ALTER TABLE current MODIFY DEVICE VARCHAR(64);
ALTER TABLE history MODIFY DEVICE VARCHAR(64);

B ezüglich optimize:
Ich verwende MariaDB statt MySQL, dort liest sich folgendes:
https://mariadb.com/kb/en/mariadb/optimize-table/
If a MyISAM table is fragmented, concurrent inserts will not be performed until an OPTIMIZE TABLE statement is executed on that table, unless the concurrent_insert server system variable is set to ALWAYS.Für eine Logtabelle ist das so natürlich völlig ausreichend.... (normalerweise)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2016, 18:56:05
Und installiere bitte noch

sudo apt-get install libdbi-perl
Bin mir nicht sicher ob libdbd identisch ist.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 13 Dezember 2016, 18:56:25
ALTER TABLE current MODIFY DEVICE VARCHAR(64);
ALTER TABLE history MODIFY DEVICE VARCHAR(64);
Da hätte ich jetzt prinzipiell auch 'drauf kommen sollen; Danke!

B ezüglich optimize:
Ich verwende MariaDB statt MySQL, dort liest sich folgendes:
https://mariadb.com/kb/en/mariadb/optimize-table/
If a MyISAM table is fragmented, concurrent inserts will not be performed until an OPTIMIZE TABLE statement is executed on that table, unless the concurrent_insert server system variable is set to ALWAYS.Für eine Logtabelle ist das so natürlich völlig ausreichend.... (normalerweise)
Das mit den Optimize läuft leider auch ins leere:
mysql> optimize table history;
+--------------+----------+----------+-------------------------------------------------------------------+
| Table        | Op       | Msg_type | Msg_text                                                          |
+--------------+----------+----------+-------------------------------------------------------------------+
| fhem.history | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| fhem.history | optimize | status   | OK                                                                |
+--------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0,15 sec)
Laut google-Recherche kann diese Mitteilung aber ignoriert werden, da rein informell?!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 13 Dezember 2016, 19:00:32
Und installiere bitte noch

sudo apt-get install libdbi-perl
Bin mir nicht sicher ob libdbd identisch ist.

Hatte ich schon bei SQLite mit installiert:

sudo aptitude install sqlite3 libdbi-perl libdbd-sqlite3-perl

und SQLite habe ich wegen der configDB erst mal beibehalten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2016, 19:15:20
Deinen Fehler:

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.
schauen wir uns später an, muß los.
Mach erstmal ein Update auf DbRep V4.8.3 aus dem Eingangsthread und dann schauen wir weiter.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2016, 22:36:08
Hallo Frickler, @all,

die Version 4.8.4 sollte die Fehlermeldung

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.
eliminieren.

Bitte mal testen.

EDIT: In der Version habe ich auch die Doku angepasst sowie das Reading "not_enough_data_in_period" in "less_data_in_period" geändert um zu kennzeichnen dass nur 1 Datensatz in der Periode gefunden wurde, aber dennoch eine Diff berechnet wurde mit der Einschränkung der logischen Ungenauigkeit bei der Zuordnung der Diff zu den Aggregationperioden.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 14 Dezember 2016, 10:15:46
Hallo,

danke, werde ich gerne am Wochenende ausprobieren. Jetzt hätte ich noch mal eine prinzipielle Frage...

Mit dem Umstieg auf MySQL habe ich erneut den Versuch gewagt meine Langzeit- und Kurzzeitdaten in einer DB zu erfassen.
Langzeitdaten: Werden ca. 2 Jahre in der DB verweilen
Kurzzeitdaten: Werden nach ca. 1 Woche aus der DB entfernt.

Bei 2 DBs habe ich das pro DB über DbLog mit einem deleteOldDays je DB gelöst. Bei einer einzelnen DB müsste ich dann pro Device Typ über DbRep ein delEntries antriggern. Es hält sich in Grenzen, wir liegen da aber bei ca. 15 delEntries, die ich jede Nacht anstossen würde.

Warum wollte ich auf eine DB zurück? Weil mir bei einer 2 DB Strategie jedes FHEM Update die zweite DB Konfiguration zerschossen hat.

Angenommen das Problem des "Konfigurationszerschiessen" beim FHEM Update lässt sich lösen.... was wäre performancetechnisch optimaler? 2 DBs mit jeweils einem deleteOldDays oder 1 DB mit 1 einem deleteOldDay und 15 delEntries?

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 14 Dezember 2016, 10:26:51
Mal noch ein paar Anmerkungen:

1. @DerFrickler: Wenn Du InnoDB als Datenbanktyp verwendest, wird diese nicht kleiner.
    Ich verwende MyISAM oder eben Aria (Für MariaDB). Diese werden tatsächlich kleiner.
Wenn Du das möchtest, kannst du es mit
ALTER TABLE `history`ENGINE=MyISAM;umstellen. Zurück geht natürlich über den selben Weg auch wieder!

2. Wenn Dich die Datenbankgröße interessiert, nimm nicht Unicode (UTF8), sondern eine herkömmliche Datenbankcodierung. Die Readings die ich so beobachte haben fast nie Unicode-Zeichen
 (mit Ausnahme von Radio-Texten beim Abspielen von Musik, aber die interessieren mich eh nicht in der Datenbank).

Der Befehl dazu wäre
ALTER TABLE `history`COLLATE='latin2_swedish_ci';, jedoch auf eigenes Risiko. Ich nutze es und bin glücklich damit ;-)

3. @Heiko: Ist das "lenth" hier eventuell ein Vertipper und sollte length heißen?
INFO_history.data_index_lenth_MBgenerell erzeugt das extrem viele Readings, mich würde aber nur eines davon interessieren. könnte man das (irgendwann mal) noch erweitern um Parameter wie "delete-readings, all " oder eben eine separierte Liste an Readings, die mich interessieren? Wie gesagt, sicher eher nice to have.

4. Blockieren von Optimize:
Leider funktioniert das nut in der Theorie.
Um das zu lösen, nutze ich wie gesagt MariaDB. Zusätzlich nutze ich Partitionierung,
Ich speichere also alle Logeinträge eines Tages in einer Tabelle, die des nächsten Tages in einer anderen Tabelle.
Somit könnte ich heute problemlos die Partition optimieren, die mit den Daten von gestern gefüllt ist.
Der Befehl dazu ist: (mon=monday)
alter table history optimize partition mon;Einziges Manko: Leider blockiert es aktuell dennoch!

4. @DerFrickler "Warum wollte ich auf eine DB zurück? "
Ich würde immer eine DB bevorzugen. Dafür sind DBs eigentlich gemacht. Normalerweise sollte das auch kein problem darstellen, und wenn doch mal, gibt es dafür Lösungen.
Auch wenn die Plots zwischenzeitlich ebenfalls mit 2 Tabellen zurecht kommen, ist es imemr praktischer, alle Werte in einer Tabelle zu haben.
Aber Achtung: Da das danns chnell mal etwas komplexer wird würde ich mich damit nur beschäftigen, wenn es wirklich notwendig wird!

Welche Lösungen gäbe es:
a) Ich habe beispielsweise hinten eine Spalte angehängt mit dem Titel "Longterm". dort schreibe ich 1 hinein, wenn ich den Datensatz länger behalten möchte und 0, wenn er nicht wichtig ist. Mein Befehl zum löschen berücksichtigt nun einfach dieses Longterm
b) GGf. zusätzlich eine Partition der MySQL-Tabelle mit diesem Longterm als Partitionsanweisung machen. Ein Löschen sämtlicher alten Datensätze dauert damit keine Zeit, da lediglich die entsprechende Tabelle komplett gelöscht wird.
Der Befehl ist bei mir dann schlicht:
ALTER TABLE history TRUNCATE PARTITION longterm
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Dezember 2016, 18:00:11
Hallo zusammen,

ich muß mich auch mal präzisieren .... ich verwende  ebenfalls MariaDB in der Version 5.5.47. Dies ist das DB-System welches derzeit auf Synology DSM als Paket ausgeliefert wird.

@Joe:

Zitat
Ist das "lenth" hier eventuell ein Vertipper und sollte length heißen?

Richtig. Korrigiere ich.

Zitat
könnte man das (irgendwann mal) noch erweitern um Parameter wie "delete-readings, all " oder eben eine separierte Liste an Readings, die mich interessieren?

Das kannst du jetzt schon eingrenzen. Dafür gibt es je nach get-Befehl ein Attribut showStatus, showVariables, showSvrInfo, showTableInfo.
Wenn du also nach dem "get ... tableinfo" nur Informationen über history sehen möchtest, setzt du in dem DbRep-Device:

attr <DbRep-Dev> showTableInfo  %history%  (oder nur history)

Dann werden nur Infos zu dieser Tabelle generiert. Das ist dann schon sehr übersichtlich.

Und wenn du NUR die Info für "INFO_history.data_index_length_MB" sehen möchtest könntest du das Attribut suppressReading  verwenden:

attr <DbRep-Dev> suppressReading  ^(?!.*INFO_history.data_index_length_MB).*$

siehe auch: http://fhem.de/commandref_DE.html#DbRepattr (http://fhem.de/commandref_DE.html#DbRepattr)

@Frickler

Zitat
Angenommen das Problem des "Konfigurationszerschiessen" beim FHEM Update lässt sich lösen.... was wäre performancetechnisch optimaler? 2 DBs mit jeweils einem deleteOldDays oder 1 DB mit 1 einem deleteOldDay und 15 delEntries?

Ergänzend zu Joes Ausführungen würde ich diese Frage konkret so beantworten, dass ich unter Performanceaspekten zu 1 DB und der enstprechenden Anzahl DbRep's mit delEntries raten würde.
Mein Hauptargument wäre, dass DbLog nach wie vor blockierend arbeitet, also bei allen Lese- oder auch Schreibaktivitäten dein FHEM enstprechend lange/kurz anhält bis die Aktion abgeschlossen ist.
Die Löschaktivitäten von den DbRep-Devices stören deine FHEM-Schleife nicht, brauchen natürlich auch CPU-Power, das ist klar. Aber die Löschläufe mußt du ja nicht alle zur gleichen Zeit einplanen. MySQL/MariaDB kann aber gut mit gleichzeitigen Lese- bzw. Löschzugriffen umgehen, kein Problem.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 15 Dezember 2016, 11:47:46
Wollte noch einen Workaround kurz mit euch teilen:
Vor größeren Löschaktionen mache ich folgendes:

0. Erzeuge eine leere History-Tabelle
1. Ich benenne die aktuelle histopry-tabelle um und platziere eine neue, leere Tabelle dort. Dies funktioniert ohne Unterbrechung.
2. Ich lösche die Einträge in der Umbenannten Tabelle: FHEM kann somit völlig ungestört weiterarbeiten.
3. Ich benenne die Tabellen zurück um:
4. Ich kopiere die neuen Werte aus der "Temporären leeren History-Tabelle" wiede rzurück in die Haupttabelle
5. Ich lösche die Einträge de rtemporären History-Tabelle.

Die SQL Codes dazu lauten:
create table history3 like history;
rename table history to history2; rename history3 to history;
[...] Bereinige die history-tabelle, die nun history2 heißt. zB delete from history2 where reading="XY";
rename history to history3; rename history2 to history;
insert into history select * from history3;
drop table history;

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 15 Dezember 2016, 23:37:38
Hallo zusammen,

die meisten der Anmerkungen von Euch (die ich verstanden habe) habe ich umgesetzt. Vielen Dank dafür! Mal sehen wie die DB in ein paar Tagen aussieht und was es noch so zu optimieren gibt.

die Version 4.8.4 sollte die Fehlermeldung

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.
eliminieren.

leider immer noch
DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3190.

Jetzt halt in Zeile 3190

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Dezember 2016, 09:28:47
Zitat
leider immer noch

Neuer Versuch mit der Version 4.8.5.  Leider kann ich es bei mir nicht testen.
MariaDB bringt mit der bisherigen Abfrage keinen Fehler.
So wie ich im Netz gelesen habe, hat man mit MySQL 5.7 einen schon länger existierenden Industriestandard umgesetzt.

Man kann auch im Server Profil eine Anpassung vornehmen um diesen Fehler generell zu vermeiden. Hier ein Auszug aus https://blog.gabriela.io/2016/03/03/group-by-are-you-sure-you-know-it/ (https://blog.gabriela.io/2016/03/03/group-by-are-you-sure-you-know-it/)

Zitat
Change permanently

If you want to disable it permanently, add/edit the following in your my.cnf file:

sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

For this change a service restart is required:
 $ mysql service restart

Aber versuche es erst einmal mit der neuen Version.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 16 Dezember 2016, 22:34:51
Hallo,

auch mit der 4.8.5 tritt der Fehler auf:

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3193.

Demnach gibt es halt die Optionen
1. Den SQL Mode umsetzen
sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
2. Migration nach MariaDB... das sollte laut ubuntuusers.de wie folgt möglich sein:

MySQL Deinstallieren:
sudo apt-get purge mysql-server mysql-common mysql*
## Aufräumen:
sudo apt-get autoclean; sudo apt-get clean; sudo apt-get autoremove;
## Prüfen auf sql Reste:
dpkg -l | grep -i -e "sql\|maria"

MariaDB Installieren:
sudo apt-get install mariadb-server
Insbesondere bei der Migration auf MariaDB... gibt es da noch mehr zu beachten? Welche der 2 Varianten ist mit mehr Risiken behaftet?

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Dezember 2016, 22:44:43
Ich würde erstmal nur den SQL_Mode setzen in der my.cnf.
Das ist schnell gemacht.

Ich habe evtl. noch eine Idee den SQL-Mode in der Datenbanksession über das DBI-Interface im Modul zu setzen.
Das muß ich aber erst (morgen) im Modul einbauen. Dann testen wir erneut.

Versuche zunächst den Workaround über die my.cnf damit du vorankommst.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 16 Dezember 2016, 22:58:28
Ich würde erstmal nur den SQL_Mode setzen in der my.cnf.
Das ist schnell gemacht.

über ein set global oder direkt editieren?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Dezember 2016, 23:03:05
my.cnf editieren und mysql restarten wie ich es in dem Ausschnitt weiter oben gefunden hatte.
Das halte ich für eine gute Methode die Änderung permanent zu machen.
Die ursprüngliche Zeile natürlich nur auskommentieren damit man sie wieder aktivieren kann bei Bedarf.
Kann man jederzeit wieder umeditieren wenn ich das Modul angepasst habe und es klappt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2016, 08:54:47
Guten Morgen,

in der V 4.8.6 wird ONLY_FULL_GROUP_BY temporär für die Dauer der Session durch das Modul gehändelt.

@Frickler bitte testen ob das nun zieht. Falls du die my.cnf schon geändert hast bitte wieder in der ursprünglichen Zustand bringen, mysql restarten und dann testen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 17 Dezember 2016, 11:42:18
Guten Morgen,

mit der 4.8.6 funktioniert es!

Gruß!
Karsten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2016, 11:46:21
Danke Karsten !

Dann checke ich es auch ein.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 17 Dezember 2016, 14:32:12
jetzt konnte ich aber folgendes beobachten....

das Reading INFO_history.data_index_length_MB schreibe ich auch in die DB. Kann es sein dass ein tableInfo die DB eine Zeit lang blockiert?

Im Logfile kann ich dann folgendes erkennen (unmittelbar nach dem get DbRep.Info tableinfo):

2016.12.17 14:30:24 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'READING' at row 1 at ./FHEM/93_DbLog.pm line 613.

2016.12.17 14:30:24 3: Connecting to database mysql:database=fhem;host=127.0.0.1;port=3306 with user fhem
2016.12.17 14:30:24 3: Connection to db mysql:database=fhem;host=127.0.0.1;port=3306 established for pid 4279
2016.12.17 14:30:24 3: Connection to db mysql:database=fhem;host=127.0.0.1;port=3306 established
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2016, 14:59:44
Zitat
Kann es sein dass ein tableInfo die DB eine Zeit lang blockiert?
Nein.

Zitat
DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'READING' at row 1 at ./FHEM/93_DbLog.pm line 613.

Das Reading "INFO_history.data_index_length_MB" ist 33 Zeichen lang.
Die ALTE Feldlänge von DbLOg war 32 ! Zeichen. Im neueren DbLog-Releases ist die Feldlänge auf 64 angepasst.

Hast du deine Tabellen history / current mit diesen Statements angelegt ? (aus ../contrib/dblog/db_create_mysql.sql):

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);

Wenn nicht kannst du die Feldlänge nachträglich z.B. ändern mit:

ALTER TABLE `history` CHANGE `READING` `READING` VARCHAR(64) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL;

Für die anderen Felder DEVICE; TYPE usw. gilt ähnliches.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 17 Dezember 2016, 16:29:59
und da dachte ich doch dass die alle schon angepasst waren... wie man sich irren kann. Jetzt sollte aber alles soweit korrekt sein.

Danke!
Karsten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2016, 16:35:08
Prima  :)

Andre Baustelle .. bin gerade dabei die Log-Funktion von DbLog  auf non-blocking umzustellen. Läuft schon richtig gut.
Zu gegebener Zeit mache ich eine Diskussionsthread auf um dort dem DbLog-Maintainer und interessierten Testern das geänderte Modul bereitzustellen.

Ich mache euch darauf aufmerksam wenn es soweit ist.

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Dezember 2016, 20:07:20
Hallo zusammen,

zur Info.
Ich habe hier https://forum.fhem.de/index.php/topic,62998.0.html (https://forum.fhem.de/index.php/topic,62998.0.html) den Diskussionsthread zum non-blocking DbLog aufgemacht.

Wer mag kann mit testen und verbessern.

wünsche noch einen schönen Abend
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Dezember 2016, 15:51:53
Hallo zusammen,

weil ich heute darüber gestolpert bin habe ich DbRep noch mit der Funktion "set ... readingRename <alter Reading Name>,<neuer Reading Name>" ergänzt.
Es funktioniert genau wie "deviceRename" nur dass die alten Readings in der Datenbank in den neuen Namen umbenannt werden.
Vielleicht hilft es manchmal. Version 4.9 im Eingangsbeitrag.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 27 Dezember 2016, 23:03:51
Hallo,

ich habe mal gemäß wiki ein kontinuierliches Löschen einzelner Datensätze in der DB aufgesetzt

Als Argument der Attribute "device" bzw. "reading" können SQL-Wildcards "%" bzw. "_" verwendet werden.
und habe mich immer gewundert warum nichts gelöscht wird.

Folgenden Hinweis habe ich gerade nach einem Restart im Log gefunden:

2016.12.27 22:57:44 3: WARNING: unsupported character in reading window.sensor.% (not A-Za-z/\d_\.-), notify the DbRep module maintainer.

Mit der Aufforderung den DbRep module maintainer zu benachrichtigen. Das mache ich jetzt mal mit der Frage was ich da möglicherweise falsch gemacht habe.

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Dezember 2016, 09:08:52
Guten Morgen,

hier sind zwei Dinge die wir auseinanderhalten müssen.
Im Wiki, Asche auf mein Haupt, habe ich fälschlicherweise bei der Löschfunktion die Verwendungsmöglichkeit von Wildcards in Readings/devices angegeben. Momentan habe ich die Abgrenzung noch Namensscharf, d.h. ohne Wildcards implementiert.
Ich wollte es tun, war aber aus Sicherheitsgründen davon abgekommen damit man nicht ungewollt mehr löscht als beabsichtigt. Stellt sich die Frage ob ich den Wikieintrag anpasse oder tatsächlich Wildcards in der Löschfunktion erlaube.

Was wäre denn deine Meinung dazu ?

Die andere Sache ist die Warnung bzgl. verwendeter Zeichen in Readings. Hier geht es um die generierten Readings die in einem DbRep-Device als Selektion aus der DB generiert werden.
Es muß also bei dir ein DbRep-Device geben welches solche Readings mit unerlaubten Sonderzeichen enthält. Das hat aber nichts mit Wildcards in den Attributen device/reading zu tun. Du kannst auch in ../log/fhem.save danach suchen.
Gib mal ein paar mehr Infos wenn du den "schuldigen" gefunden hast.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 Dezember 2016, 11:26:41
Es muß also bei dir ein DbRep-Device geben welches solche Readings mit unerlaubten Sonderzeichen enthält. Das hat aber nichts mit Wildcards in den Attributen device/reading zu tun. Du kannst auch in ../log/fhem.save danach suchen.

nicht nur eins... Meine "Naming Convention" legt fest dass jedes Gerät mit dem Typ beginnt... z.B. die Heizkörperthermostate mit radiator.thermostat. und die Wandthermostate mit wall.thermostat.. Klever wäre jetzt sicherlich gewesen das thermostat an den Anfang zu setzten, aber...
Und auf diese Art und Weise habe ich auch die Löschfunktionen generiert: radiator.thermostat.% und wall.thermostat.%... Das ganze zieht sich dann abgesehen von den meter.reading.s durch das ganze System.

Hier als Beispiel mal den Fenstersensor Eintrag wie oben genannt:

Internals:
   CFGFN
   DATABASE   fhem
   DEF        DbLog
   LASTCMD    delEntries
   NAME       DbRep.Del.window.sensor
   NOTIFYDEV  global,DbRep.Del.window.sensor
   NR         438
   NTFY_ORDER 50-DbRep.Del.window.sensor
   ROLE       Client
   STATE      done
   TYPE       DbRep
   VERSION    4.8.6
   Helper:
     DBLOGDEVICE DbLog
     Cv:
       aggregation no
       aggsec     1
       destr      2016-12-28
       dsstr      1970-01-01
       epoch_seconds_end 1482883793
       mestr      12
       msstr      01
       testr      01:09:53
       tsstr      01:00:00
       wdadd      345600
       yestr      2016
       ysstr      1970
   Readings:
     2016-12-28 01:10:00   state           done
     2016-12-28 01:10:00   window.sensor.% --  -- DELETED ROWS --  0
   Dbloghash:
     CFGFN
     CONFIGURATION /opt/fhem/DbLog.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/DbLog.conf .*:.*
     NAME       DbLog
     NR         17
     NTFY_ORDER 50-DbLog
     PID        9037
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=127.0.0.1;port=3306
     dbuser     fhem
     Helper:
       Dblog:
         Counthistory:
           Dblog:
             TIME       1482919059.06664
             VALUE      91795
     Readings:
       2016-12-28 10:57:39   countCurrent    113
       2016-12-28 10:57:39   countHistory    91795
       2016-12-12 23:39:10   lastReduceLogResult Rows processed: 0, deleted: 0, time: 0.00sec
       2016-12-15 00:00:00   lastRowsDeleted 0E0
       2016-12-27 22:57:36   state           connected
       2016-12-12 01:00:00   userCommand     "VACUUM history"
Attributes:
   alias      DbRep - 03 - Delete Device window.sensor.%
   allowDeletion 1
   comment    löschen aller Einträge:
countHistory
in DbLog älter als 7 Tage
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     window.sensor.%
   event-on-change-reading state
   group      DbLog
   room       06 Logging
   timeOlderThan 7
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Dezember 2016, 11:47:56
Was die Löschfunktion betrifft:

Zitat
Und auf diese Art und Weise habe ich auch die Löschfunktionen generiert: radiator.thermostat.% und wall.thermostat.%

Im Moment geht die Löschfunktion schief, weil das "%" im Device-Name "radiator.thermostat.%" nicht als Wildcard sondern als normales Zeichen gewertet und an die DB gesendet wird. Im Ergebnis wird ein Reading generiert:

Zitat
Readings:
     2016-12-28 01:10:00   state           done
     2016-12-28 01:10:00   window.sensor.% --  -- DELETED ROWS --  0

welches den Devicenamen enthält -> "window.sensor.%". Das führt dann zu der Warnung bzgl. Sonderzeichen im Log.

Gibt es momentan zwei Varianten:

1. ich statte die Löschfunktion mit Wildcards aus
2. ich lasse das Modul so wie es es ist und passe den Wikieintrag an. In diesem Fall müsstest du die zu löschenden Devices konkret ageben was andererseits die Sicherheit erhöht (siehe meine Überlegungen zuvor)

Was denkst du ?

Achtung ! timeOlderThan  sind Sekunden !  d.h. timeOlderThan 7  würde alles älter 7 Sekunden löschen und nicht älter 7 Tage. -> Wohl gut dass es mit den Wildcards nicht funktioniert hat.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 Dezember 2016, 12:31:51
1. ich statte die Löschfunktion mit Wildcards aus
2. ich lasse das Modul so wie es es ist und passe den Wikieintrag an. In diesem Fall müsstest du die zu löschenden Devices konkret ageben was andererseits die Sicherheit erhöht (siehe meine Überlegungen zuvor)

Ich würde die 1 wählen.

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Dezember 2016, 12:34:33
Ok.
Ich stelle die neue Version kurzfristig wieder hier ein.
Melde mich ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Dezember 2016, 13:48:19
Hallo,

habe die neue Version 4.10 wie gehabt angehängt.

Die Löschfunktion kann nun auch Wildcards % bzw. _ an die DB übergeben.
In dem Ergebnisreading der gelöschten Datensätze wird ein evtl. vorhandenes "%" durch "/" ersetzt um die Richtlinien für Readings entsprechend einzuhalten.

Probiers mal aus, bei mir habe ich es erfolgreich durchgeetestet.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 Dezember 2016, 16:29:33
funktioniert gut!

Danke,
Karsten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Dezember 2016, 16:39:49
Thx Karsten für die Rückinfo.
Ich checke es ein.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 28 Dezember 2016, 17:20:50
wenn ich jetzt von einer bestimmten Gerätegruppe switchable.socket.% alle Einträge älter 7 Tage, bis auf ein spezifisches energy_kWh löschen möchte, gibt es da eine einfache Kombi zwischen device und reading die das in einem Rutsch löst?

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Dezember 2016, 08:43:18
Moin Karsten,

Zitat
gibt es da eine einfache Kombi zwischen device und reading die das in einem Rutsch löst?

Ich wüßte keine auf Anhieb. SQL-Wildcards sind nicht so mächtig wie ein Perl-Regex, sondern nur einfache Platzhalter für ein oder mehrere Zeichen.
Das wird sich wahrscheinlich nicht ganz so simpel lösen lassen.

schönen Tag...
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Dezember 2016, 14:59:58
Hallo zusammen,

habe eine kleine Korrektur an der Funktion importFromFile vorgenommen. Unter bestimmten Umständen kam ein quote (") mit in die DB.
-> Version 4.10.1

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DerFrickler am 14 Januar 2017, 23:05:12
jetzt noch mal eine Frage zur Optimierung der DB... bei sqlite habe ich das über das userCommand "VACUUM history" gemacht, geht das bei sql auch so einfach? oder ist da noch was zu beachten?

Gruß!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: friesenjung am 15 Januar 2017, 22:01:26
Guten Abend allerseits!

Ich teste seit kurzen ein DbLog-Device, um langfristig das Logging auf eine DB umzustellen.

Ich möchte auch das DBRep-Modul verwenden, um in erster Linie die Auto-Rename-Funktion zu verwenden.

Nun bekomme ich folgenden Fehler, wenn ich ein Device umbenenne:

Can't call method "execute" on an undefined value at ./FHEM/93_DbRep.pm line 2606
Könnte es mit den letzten Änderungen im DbLog-Modul zu tun haben, oder hat jemand eine Idee, was ich vlt. noch übersehen oder vergessen habe?

Meine Umgebung:
DbLog ( V2.8.8 ) ; Async-Mode ; Current/History
DbRep ( V4.10.1 ) ; Agent-Mode
MariaDB auf Synology


VG und danke schonmal...


PS: Logging des DbLog-Moduls und SVG-Plots etc. funktioniert ohne Probleme, keine Fehlermeldungen...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Januar 2017, 22:17:13
Hallo friesenjung,

Zitat
Könnte es mit den letzten Änderungen im DbLog-Modul zu tun haben,

eher unwahrscheinlich. Aber schwer zu sagen. Kannst du versuchen versbose 4 zu loggen ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: friesenjung am 15 Januar 2017, 22:22:27
Hallo friesenjung,

eher unwahrscheinlich. Aber schwer zu sagen. Kannst du versuchen versbose 4 zu loggen ?

hier das Ergebnis:

2017.01.15 22:20:09 4: DbRep Agent DBAgent - Evt RENAMED rec - old device: TestPush3, new device: TestPush4 -> start deviceRename in DB: fhem
2017.01.15 22:20:09 4: DbRep DBAgent - -------- New selection ---------
2017.01.15 22:20:09 4: DbRep DBAgent - Aggregation: no
2017.01.15 22:20:09 4: DbRep DBAgent - Command: deviceRename
2017.01.15 22:20:09 4: DbRep DBAgent - Timestamp begin human readable: 1970-01-01 01:00:00
2017.01.15 22:20:09 4: DbRep DBAgent - Timestamp end human readable: 2017-01-15 22:20:09
2017.01.15 22:20:09 4: DbRep DBAgent -> Start BlockingCall devren_Push
2017.01.15 22:20:09 1: PERL WARNING: Use of uninitialized value $renmode in string eq at ./FHEM/93_DbRep.pm line 2585.
2017.01.15 22:20:09 1: PERL WARNING: Use of uninitialized value $renmode in string eq at ./FHEM/93_DbRep.pm line 2595.
2017.01.15 22:20:09 1: PERL WARNING: Use of uninitialized value $renmode in string eq at ./FHEM/93_DbRep.pm line 2611.
2017.01.15 22:20:09 1: PERL WARNING: Use of uninitialized value $renmode in string eq at ./FHEM/93_DbRep.pm line 2612.
2017.01.15 22:20:09 4: DbRep DBAgent -> BlockingCall devren_Push finished
2017.01.15 22:20:09 4: DbRep DBAgent -> Start BlockingCall devren_Done
2017.01.15 22:20:09 4: DbRep DBAgent -> BlockingCall devren_Done finished

VG...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Januar 2017, 22:35:29
Das ist schon ein Anhaltspunkt ... muß ich  mir in Ruhe anschauen...
Machst du bitte noch ein ist von dem DbRep-Device ?

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: friesenjung am 15 Januar 2017, 22:39:59
hi,

Das ist schon ein Anhaltspunkt ... muß ich  mir in Ruhe anschauen...
Machst du bitte noch ein ist von dem DbRep-Device ?

Grüße
Heiko

was meinst Du mit "ist"?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Januar 2017, 22:45:56
Oben in der Kommandozeile "list <DbRep-Device> eintippen....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: friesenjung am 15 Januar 2017, 22:49:05
Oben in der Kommandozeile "list <DbRep-Device> eintippen....

hier das list:

Internals:
   CFGFN
   DATABASE   fhem
   DEF        DBLogging
   LASTCMD    dbstatus
   NAME       DBAgent
   NOTIFYDEV  global,DBReporting
   NR         3096
   NTFY_ORDER 50-DBReporting
   ROLE       Agent
   STATE      error
   TYPE       DbRep
   VERSION    4.10.1
   Helper:
     DBLOGDEVICE DBLogging
     NEWDEV     TestPush4
     OLDDEV     TestPush3
     Cv:
       aggregation no
       aggsec     1
       destr      2017-01-15
       dsstr      1970-01-01
       epoch_seconds_end 1484515209
       mestr      01
       msstr      01
       testr      22:20:09
       tsstr      01:00:00
       wdadd
       yestr      2017
       ysstr      1970
   Readings:
     2017-01-15 22:20:09   errortext       Can't call method "execute" on an undefined value at ./FHEM/93_DbRep.pm line 2606.

     2017-01-15 22:20:09   state           error
   Dbloghash:
     CONFIGURATION /opt/fhem/contrib/dblog/db.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/contrib/dblog/db.conf .*:.*
     MODE       asynchronous
     NAME       DBLogging
     NR         347
     NTFY_ORDER 50-DBLogging
     PID        6469
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     VERSION    2.8.8
     dbconn     mysql:database=fhem;host=192.168.41.198;port=3306
     dbuser     fhemuser
     Helper:
     Readings:
       2017-01-15 22:46:49   CacheUsage      0
       2017-01-15 22:46:44   NextSync        2017-01-15 22:47:14
       2016-12-27 23:53:24   countCurrent    614
       2016-12-27 23:53:24   countHistory    2
       2017-01-15 22:46:45   state           connected
     Cache:
       index      20544
       Memcache:
Attributes:
   DbLogExclude .*
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   group      Datenbank
   icon       security
   role       Agent
   room       9.7_Dienste
   timeout    3600
   verbose    4
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Januar 2017, 22:54:56
Danke ... schaue ich mir morgen an.


VG Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 16 Januar 2017, 09:55:09
Unter MySQL kannst du
optimize table history;
nutzen.
Allzuoft würde ich das jedoch nicht machen... es blockiert die Datenbank.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2017, 22:37:59
Hallo friesenjung,

habe die V4.10.2 im Eingangsbeitrag hinterlegt.
Habe den Fehler gefixt.
Probiers mal aus.
Setz dir das Attr timeout in dem Rep-Agenten gleich hoch, z.B. auf 1800 (helbe Stunde) damit die umbenennungen in der DB nicht auf ein timeout laufen wenn es mal länger dauert.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: friesenjung am 17 Januar 2017, 23:30:02
Hallo friesenjung,

habe die V4.10.2 im Eingangsbeitrag hinterlegt.
Habe den Fehler gefixt.
Probiers mal aus.
Setz dir das Attr timeout in dem Rep-Agenten gleich hoch, z.B. auf 1800 (helbe Stunde) damit die umbenennungen in der DB nicht auf ein timeout laufen wenn es mal länger dauert.

Grüße
Heiko

Hallo Heiko,
"renaming" funktioniert nun TipTop! Danke...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 23 Januar 2017, 21:37:53
Sorry für Anfängerfrage:
Ist es eigentlich üblich einen Agenten und einen Client als Device gleichzeitig zu verwenden ?
Bringt es Vor- oder Nachteile ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2017, 14:10:15
Hallo t.huber,
Üblich ist vielleicht nicht der richtige Ausdruck. Client und Agent haben andere Aufgaben.
Du kannst grundsätzlich viele DbRep-devices parallel definieren die die Client Rolle haben. Zum Beispiel für verschiedene Aufgaben. Daneben kann ein Rename Agent definiert sein, der Umbenennungen von Devices in FHEM erkennt und die Umbenennung in seinem zugeordneten DbLog- Device bzw. dessen DB nachzieht.
Es kann aber nur einen Agent pro definierten DbLog-device geben.
So gesehen kannst du Clients und Agent gleichzeitig verwenden.
Die Frage der Vorteil e ergibt sich aus der Funktion. Nachteile  ... es werden Änderungen in der DB vorgenommen. Wenn das nicht gewünscht ist dann die Agent Rolle nicht definieren.

Wenn noch Fragen sind .... Immer gerne.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 24 Januar 2017, 18:11:16
Danke für die Erläuterung !
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: awex102 am 29 Januar 2017, 14:09:28
Hallo, eine Anfängerfrage:

DbRep läuft und ich erhalte bisher

2017-01-29_11-06-29__Strom__Verbraucht__DIFF__2017-01 243.0000 2017-01-29 14:02:27

wunderbar den Stromverbrauch pro Monat.

Wie kann ich mir nun ein SVG Plot erzeugen, der mir automatisch den Stromverbrauch ausgibt?
Müssen die Daten / Readings nochmal geloggt werden? Und wie funktioniert es, dass im Plot jeweils in Ballken pro Monat ausgegeben wird (ich logge erst sei Anfang Januar, ich sehe also bisher nur ein Reading für den Januar). Wenn jetzt ein weiteres Readings für Februar dazukommt, wie erkennt der Plot dann, dass es sich um einen neuen Monat handelt?

Kann ich auch parallel Tages-., Monats und Jahresplots generieren wenn ich über aggregation day, month, year jeweils einmal die Nacht die entsprechenden Werte von DbRep genieren lassen?

Danke!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Januar 2017, 20:23:20
Hallo awex102,

ich bin nicht der Experte wenn es darum geht die Feinheiten der Ploterstellung zu vermitteln. Insofern sind meine nachfolgenden
Antworten mit Vorbehalt zu genießen und nicht unbedingt der Stein der Weisen.
Vielleicht ist es sinnvoller die Frage nochmal im Anfängerforum zu stellen oder in einem passenden Unterforum.

Aber ich würde momentan die Fragen so beantworten:

Zitat
Müssen die Daten / Readings nochmal geloggt werden?
Vermutlich ja, da ich nicht annehme dass SVG mathematische Funktionen wie Diffvalue oder sumValue beherrscht.
Das Loggen kann für die Ploterstellung wahlweise in einem Filelog oder DbLog erfolgen.

Zitat
Und wie funktioniert es, dass im Plot jeweils in Ballken pro Monat ausgegeben wird
Balken kannst du im Ploteditor mit dem Style "bars" erstellen. (siehe Screenshot)

Zitat
Wenn jetzt ein weiteres Readings für Februar dazukommt, wie erkennt der Plot dann, dass es sich um einen neuen Monat handelt?
Plot erkennt den Zeitpunkt des Readings anhand dessen Erstellungsdatums in der Datenbank bzw. dem Filelog. Meiner Meinung nach müßte man demnach z.B. für jeden Monat ein eigenes DbRep-Device erstellen um mit diesem nur das jeweilige Reading für den jeweiligen Monat wie von dir beschrieben:

2017-01-29_11-06-29__Strom__Verbraucht__DIFF__2017-01 243.0000 2017-01-29 14:02:27

zu erstellen.
In dem jeweiligen DbRep-Device darf die Readingerstellung regelmäßig ab Montasanfang, aber jeweils nur maximal bis zum Ende des jweiligen Monats (also Ende Januar beim DbRep.Januar-Device erfolgen) damit der Timestamp im Log dann stimmt und vom SVG ordentlich ausgewertet werden kann.
Kann z.B. mit einem AT realisiert werden.

Zitat
Kann ich auch parallel Tages-., Monats und Jahresplots generieren wenn ich über aggregation day, month, year jeweils einmal die Nacht die entsprechenden Werte von DbRep genieren lassen?
Ja das geht . Aber Aggregation "year" gibt es zumindest bis jetzt noch nicht.

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 01 Februar 2017, 01:22:01
Hi,
ich habe mir den ganzen Thread durchgelesen (*puh*), aber ich glaube, meine Fragen wurden nicht beantwortet:

Ich habe gerade versucht, eine readingsGroup zu erstellen.

Dabei sollen wie von dir vorgeschlagen, die Werte aus den Readings mit wildcards geholt werden (.*-01 bis .*-20)

Da das diff-Limit auf 20 steht (ich weiss, ist default, Fehler tritt aber auch bei zb 15 auf), erzeugt DbRep ein Reading

diff-overrun_limit-20
Das wird dann natürlich bei  (.*-20) entsprechend eingefügt.

Also hab ich versucht, meine Readings umzuformatieren:

attr REP_test readingNameMap Gaszaehler(kWh)
Ist leider fehlgeschlagen, da die Klammern () wohl nicht als Reading-Name erlaubt sind.

also hab ichs mit
attr REP_test readingNameMap Gaszaehlerversucht.

Dann heissen meine Readings jetzt zb
2017-01-20_23-50-52__Gaszaehler__total__DIFF__2017-01-20
Um das limit loszuwerden, müsste ich in der readings-group alle (.*-DD) umbauen in (.*Gaszaehler.*-DD)

Könntest du das limit-reading umbenennen?
und, kann ich die Ergebnis-Readings auch komplett umbenennen, oder muss ich immer mit den Datumsanhängseln umgehen?

Danke und Grüße
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 01 Februar 2017, 01:25:38
Ah, und ich hab doch noch eins:

Dachte, ich wäre vllt einfach zu blöd aber:

Ich möchte alle Tageswerte von Januar haben, um damit die rg zu füllen.
Also habe ich eingestellt:

   timestamp_begin 2017-01-01 00:00:00
   timestamp_end 2017-01-31 23:59:59

Trotzdem erstellt DbRep ein Reading
2017-02-01__Gaszaehler__total__DIFF__2017-02-01

Das gehört doch da gar nicht hin .. oder??
komplettes list findest du unten,
Danke für deine Mühe mit dem Modul, ich finds großartig!

Grüße
Stephan


Internals:
   DATABASE   fhem
   DEF        logdb
   LASTCMD    diffValue
   NAME       REP_test
   NOTIFYDEV  global,REP_test
   NR         785
   NTFY_ORDER 50-REP_test
   ROLE       Client
   STATE      Warning
   TYPE       DbRep
   VERSION    4.10.1
   Helper:
     DBLOGDEVICE logdb
     Cv:
       aggregation day
       aggsec     86400
       destr      2017-01-31
       dsstr      2017-01-01
       epoch_seconds_end 1485903599
       mestr      01
       msstr      01
       testr      23:59:59
       tsstr      00:00:00
       wdadd      86400
       yestr      2017
       ysstr      2017
   Readings:
     2017-02-01 01:21:49   2017-01-01_23-37-37__Gaszaehler__total__DIFF__2017-01-01 13.9650
     2017-02-01 01:21:49   2017-01-02_23-52-38__Gaszaehler__total__DIFF__2017-01-02 22.2250
     2017-02-01 01:21:49   2017-01-03_19-01-34__Gaszaehler__total__DIFF__2017-01-03 12.0800
     2017-02-01 01:21:49   2017-01-04_23-52-30__Gaszaehler__total__DIFF__2017-01-04 15.6700
     2017-02-01 01:21:49   2017-01-05_23-52-25__Gaszaehler__total__DIFF__2017-01-05 16.0650
     2017-02-01 01:21:49   2017-01-06_19-41-28__Gaszaehler__total__DIFF__2017-01-06 18.6350
     2017-02-01 01:21:49   2017-01-07_21-26-45__Gaszaehler__total__DIFF__2017-01-07 27.5400
     2017-02-01 01:21:49   2017-01-08_22-36-53__Gaszaehler__total__DIFF__2017-01-08 23.0250
     2017-02-01 01:21:49   2017-01-09_23-52-01__Gaszaehler__total__DIFF__2017-01-09 19.2450
     2017-02-01 01:21:49   2017-01-10_20-01-06__Gaszaehler__total__DIFF__2017-01-10 18.0700
     2017-02-01 01:21:49   2017-01-11_23-51-45__Gaszaehler__total__DIFF__2017-01-11 20.4700
     2017-02-01 01:21:49   2017-01-12_22-36-23__Gaszaehler__total__DIFF__2017-01-12 14.1550
     2017-02-01 01:21:49   2017-01-13_19-40-40__Gaszaehler__total__DIFF__2017-01-13 14.1650
     2017-02-01 01:21:49   2017-01-14_20-15-41__Gaszaehler__total__DIFF__2017-01-14 17.0550
     2017-02-01 01:21:49   2017-01-15_18-30-14__Gaszaehler__total__DIFF__2017-01-15 16.3750
     2017-02-01 01:21:49   2017-01-16_22-40-48__Gaszaehler__total__DIFF__2017-01-16 20.3900
     2017-02-01 01:21:49   2017-01-17_23-35-55__Gaszaehler__total__DIFF__2017-01-17 14.7150
     2017-02-01 01:21:49   2017-01-18_23-25-47__Gaszaehler__total__DIFF__2017-01-18 14.3600
     2017-02-01 01:21:49   2017-01-19_19-34-58__Gaszaehler__total__DIFF__2017-01-19 9.2250
     2017-02-01 01:21:49   2017-01-20_23-50-52__Gaszaehler__total__DIFF__2017-01-20 12.4150
     2017-02-01 01:21:49   2017-01-21_23-50-52__Gaszaehler__total__DIFF__2017-01-21 12.7900
     2017-02-01 01:21:49   2017-01-22__Gaszaehler__total__DIFF__2017-01-22 -
     2017-02-01 01:21:49   2017-01-23_23-56-12__Gaszaehler__total__DIFF__2017-01-23 17.9900
     2017-02-01 01:21:49   2017-01-24_23-51-19__Gaszaehler__total__DIFF__2017-01-24 20.1950
     2017-02-01 01:21:49   2017-01-25_19-50-34__Gaszaehler__total__DIFF__2017-01-25 11.9100
     2017-02-01 01:21:49   2017-01-26_20-05-41__Gaszaehler__total__DIFF__2017-01-26 12.4750
     2017-02-01 01:21:49   2017-01-27_19-15-35__Gaszaehler__total__DIFF__2017-01-27 12.9800
     2017-02-01 01:21:49   2017-01-28_20-25-53__Gaszaehler__total__DIFF__2017-01-28 12.9950
     2017-02-01 01:21:49   2017-01-29_23-31-34__Gaszaehler__total__DIFF__2017-01-29 23.9450
     2017-02-01 01:21:49   2017-01-30_21-31-07__Gaszaehler__total__DIFF__2017-01-30 20.2650
     2017-02-01 01:21:49   2017-01-31_23-26-27__Gaszaehler__total__DIFF__2017-01-31 16.2700
     2017-02-01 01:21:49   2017-02-01__Gaszaehler__total__DIFF__2017-02-01 -
     2017-02-01 01:21:49   background_processing_time 0.6062
     2017-02-01 01:21:49   diff-overrun_limit-20 2017-01-12 07:28:19 0.2400 -> 2017-01-12 07:33:20 327.8350 || 2017-01-18 20:55:16 0.0000 -> 2017-01-18 21:25:22 1542.3150 ||
     2017-02-01 01:21:49   sql_processing_time 0.3022
     2017-02-01 01:21:49   state           Warning
   Dbloghash:
     CONFIGURATION ./db_fhem.conf
     DBMODEL    MYSQL
     DEF        ./db_fhem.conf .*:.*
     NAME       logdb
     NOTIFYDEV  .*
     NR         348
     NTFY_ORDER 50-logdb
     PID        1985
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=localhost;port=3306
     dbuser     fhemuser
     Readings:
       2016-11-28 10:56:26   countCurrent    101
       2016-11-28 10:56:26   countHistory    21728026
       2016-07-19 19:30:51   lastReduceLogResult Rows processed: 12507, deleted: 0, updated: 0, time: 10.00sec
       2016-07-19 18:02:10   lastRowsDeleted 1898873
       2017-02-01 01:22:16   state           connected
Attributes:
   aggregation day
   device     Gaszaehler
   diffAccept 20
   event-on-change-reading state
   reading    total
   room       Logging
   showproctime 1
   timestamp_begin 2017-01-01 00:00:00
   timestamp_end 2017-01-31 23:59:59
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Februar 2017, 08:33:06
Hallo Stephan,

Zitat
Könntest du das limit-reading umbenennen?
Ja, ich schaue mal wie das besser wäre. Das ist wirklich unschön wenn man in dem speziellen Fall so "rumopern" muß.

Die andere Sache schaue ich mir auch mal in Ruhe an.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 01 Februar 2017, 17:24:45
Habe ein bisschen mit dem Modul rumgebastelt, und es sind mir tausend Ideen eingefallen  8)
Aber ich teil das mal in kleine Häppchen auf, nachdem ich jeweils nochmal drüber nachgedacht habe ;P

Zitat
current_year_begin, current_year_end sowie previous_year_begin und previous_year_end

Wäre es ebenfalls möglich, diese für
- month
- week
- day
- und wenn man es vollständig haben will, hour

zu implementieren?

Wobei die current_*_end ja immer in der Zukunft liegen werden...

Der Vollständigkeit halber (und Einfachheit des Benutzens) wäre hier vielleicht auch eine Dropdown-liste sinnvoll:

attr calcTimeBetween (chour,cday,cweek,cmonth,cyear;lhour,lday,lweek,lmonth,lyear)
Edit: dazu wäre es natürlich sinnvoll, ein Reading namens


2017-02-01_17-51-25__Stromzaehler__total_energy__DIFF__2017-02_lday
oder so ähnlich zu haben, damit der zugriff (zb in der rg) .*_lday heissen kann.




Grüße
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Februar 2017, 18:28:30
Hallo Stephan,

habe im ersten Beitrag die neue Version 93_DbRep_V4.10.3 hinterlegt die deine beiden beschriebenen Probleme löst. Das Reading habe ich einfach komplett mit Unterstrichen erstellt. Passt ohnehin so besser ins Bild.

Bezüglich der Tagesaggregation erinnere ich mich letztes Jahr einen Change gemacht zu haben den ich jetzt wieder zurückgenommen habe um das Problem mit diesem zusätzlichen Tag zu lösen. Es gab natürlich einen Grund warum ich das damals gemacht habe. Ich muß am WE nochmal darüber nachdenken ... habe heute / Morgen keine Zeit dafür. Falls dir etwas auffällt gib bitte Bescheid.

Teste mal die neue Version...

Zitat
Habe ein bisschen mit dem Modul rumgebastelt, und es sind mir tausend Ideen eingefallen  8)
Ja, das kenne ich zur Genüge. Der Appetit kommt beim essen und wenn man erstmal auf den Geschmack gekommen ist.  ;)

Ich schau mal was ich von deinen Vorschlägen umsetzen kann. Habe nur momentan wenig Zeit weil ich gerade noch etwas bei DbLog eingespannt bin.
Also ruhig etwas Geduld mitbringen  :D

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Hauswart am 09 Februar 2017, 15:16:52
Ist dieses Modul auch in der Lage Migrationen sqlite <=> MySQL durchzuführen?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Februar 2017, 18:13:03
Hallo Hauswart,

wenn mit "Migration" ein Transfer der Daten von einer DB in die anderen gemeint ist dann kann es das Modul.
Beschrieben habe ich es im Wiki hier :
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Datens.C3.A4tze_.28Devices.29_von_einer_Datenbank_in_eine_andere_umziehen_.28Export.2FImport.29

Du definierst die je ein DbRep für die MySQL und eines für die SQLite.
Wenn du große Datenmengen zu transferieren hast, würde ich den Export (in mehrere Files) in sinnvolle/praktikable Packete aufteilen, zb. in Halbjahresscheiben.
Das machst du über über die Attr timestamp_begin und timestamp_end, zb. 2016-01-01 00:00:00 und 2016-06-30 23:59:59.

Über das Attr "expimpfile" gibst du in beiden DbRep-Devices den Namen des Austauschfiles an. Setz die auch das attr "timeout" richtig hoch wenn der Export/Import sehr lange dauert damit das Modul nicht in einen timeout läuft.

Der Import erfolgt immer als Transaktion, d.h. das File wird komplett importiert oder garnicht. Sollte ein Fehler auftreten, dann die Ursache beseitigen und erneut importieren.

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Hauswart am 09 Februar 2017, 19:36:38
Das wollte ich doch hören :)

Ein DbRep mit einem Dblog sqlite und ein DbRep mit einem Dblog MySQL und ein Export von Dblog sqlite kann in Blog MySQL importiert werden über den Umweg DbRep.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 10 Februar 2017, 20:16:38
Ich hätte da nochmal ne frage, vermutlich rein Verständnismäßig:

Ich hab zur Zeit noch "statistics" laufen.
Das liefert mir für einen Zähler die Werte hour,day,week,month,year sowie LastHour, LastDay ...

Wenn ich mir das jetzt nachbauen will mit DbRep, brauche ich dann wirklich 10 Instanzen?

Soll heissen, ist das so vorgesehen, oder benutze ich es falsch/anders? gibt es einfachere/alternative Lösungen?
Dass ich 30 Tage sehen kann, ist ja ganz nett, aber irgendwie interessiert mich der aktuelle/kürzliche Verbrauch mehr ...

Grüße

Stephan

PS: hab jetzt schon mehrfach darüber nachgedacht, vielleicht macht es ja Sinn, SQL-Abfragen vorzudefinieren, und dann mit get DbRepInstanz Favourit1 ergebnisse abzufragen? Ich werde vllt mal versuchen, das auszuprobieren. Konnte nicht DBLog oder DBRep beliebige MySQL-Statements absetzen?.. Mal sehen ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2017, 21:11:24
Hallo Stephan,

der Focus von DbRep liegt auf der Auswertung von Datenbankinhalten. Es war nicht der Ansatz "statistics" quasi  nachzubauen.
Wenn du die verschiedenen Auswertungen wie hour,day,week,month,year usw. parallel nebeneinander haben möchtest ohne dafür eine Attributänderung vornehemen zu müssen/wollen, dann brauchst du für die gewünschten Varianten je ein DbRep-Device erstellen. Ich kopiere mir immer ein bereits erstelltes und passe es an.

Ist also sehr einfach und schnell gemacht. Einfach "copy <Vorlage-DbRep> <Neu-DbRep>" , dann Attribute wie gewünscht anpassen. Fertig. Deine gewünschten Instanzen hast du dir in wenigen Minuten definiert.

Zitat
Dass ich 30 Tage sehen kann, ist ja ganz nett, aber irgendwie interessiert mich der aktuelle/kürzliche Verbrauch mehr ...

Welche 30 Tage ?  Naja, für den aktuellen Verbrauch brauchst du keine DB-Auswertungen  ;)
Ursprünglich waren die DbRep-Auswertungen gedacht für tabellarische Darstellungen/Gegenüberstellungen (z.B. mit Readingsgroup) verschiedener definierter Auswertungsscenarien.

Zitat
Konnte nicht DBLog oder DBRep beliebige MySQL-Statements absetzen?

Ja , in DbLog kannst du mit "set .. userCommand" deine SQL's ausführen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 10 Februar 2017, 21:45:05
Ursprünglich waren die DbRep-Auswertungen gedacht für tabellarische Darstellungen/Gegenüberstellungen (z.B. mit Readingsgroup) verschiedener definierter uswerungsscenarien.

ja, so etwas hatte ich schon vermutet.
Zum Thema UserCommands habe ich bereits etwas gepostet:
https://forum.fhem.de/index.php/topic,65112.0.html (https://forum.fhem.de/index.php/topic,65112.0.html)

Grüße und Danke

Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 10 Februar 2017, 22:34:43
Hi,
ich hab mir mal erlaubt, die von mir vorgeschlagenen Änderungen (current|previous_[hour|day|month|year]_begin|end) einzuarbeiten.
Wenn du magst, schau dir die Datei an, und überleg dir, ob du es übernehmen willst.
(ich hab diff -u gemacht, hoffe das war richtig. Ansonsten is des "original" auch dabei)

Grüße
Stephan



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2017, 22:41:55
Hi Stephan,

großartig ... nehme die Untersützung gerne an.
Ich schau mir das mal am WE in Ruhe an und übernehme es dann natürlich auch.
Muß natürlich die Commandref anpassen/ergänzen.

Du hast sicherlich die Ergänzung auch schon durchgetestet nehme ich an !? (Mache ich natürlich auch noch)

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 10 Februar 2017, 22:47:34
Du hast sicherlich die Ergänzung auch schon durchgetestet nehme ich an !? (Mache ich natürlich auch noch)

Sagen wir mal so: ich hab beim anwenden und ausprobieren ein paar Unschönheiten gefunden. Die einzelnen Zeitpunkte hab ich im online-perl entwickelt und soweit ich konnte, geprüft. Systematisch getestet hab ichs aber nicht, zumal ich auch gar nicht weiss, wo da die Stolperfallen liegen. Zur Zeit funktionieren die Attribute aber so, wie ich es mir vorstelle.

Dazu noch eine Frage:
Kann ich bei ReadingsVal irgendwie mit Platzhaltern arbeiten?
ReadingsVal("meinRep",".*DIFF.*",0); funktioniert leider nicht...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2017, 22:56:46
Zitat
Sagen wir mal so: ich hab beim anwenden und ausprobieren ein paar Unschönheiten gefunden. Die einzelnen Zeitpunkte hab ich im online-perl entwickelt und soweit ich konnte, geprüft. Systematisch getestet hab ichs aber nicht, zumal ich auch gar nicht weiss, wo da die Stolperfallen liegen. Zur Zeit funktionieren die Attribute aber so, wie ich es mir vorstelle.

Alles gut, wollte nur den Teststand wissen. Ich schaue es mir genau an.

Zitat
Kann ich bei ReadingsVal irgendwie mit Platzhaltern arbeiten?
Nein, ReadingsVal verarbeitet keine Regex.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Februar 2017, 17:23:23
Hallo Stephan, @all,

habe im ersten Beitrag die Version 4.11.0 hinterlegt die deine Ergänzungswünsche bzgl. [current|previous]_[month|week|day|hour]_[begin|end] enthält.

Ich habe den guten Ansatz übernommen und so umgebaut dass nun auch die Zeitabgrenzungen und Zeitverschiebungen funktionieren. Insbesondere wenn z.B. der Vortag obendrein noch im Vormonat bzw. Vorjahr lag gab es Schwierigkeiten.
Probiert es mal aus, bei mir klappt es prima soweit ich verschiedene kritische Konstellationen testen konnte. Alles ging natürlich nicht.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 18:40:21
Hallo,

ich versuche seit einigen Stunden mein System dazu zu bewegen, mir einige Daten zu meiner DBLog auszuwerfen.

Auch nach einigen Stunden mit running bekomme ich keine Werte.
define DbLog DbLog /opt/fhem/db.conf .*:(box_rateDown|box_rateUp|cpu_temp|cpu_temp_avg|cpu_freq|eth0_diff|loadavg|ram|fs_.*|stat_cpu_percent).*
attr DbLog room 99_DbLog
attr DbLog userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m /opt/fhem/fhem.db`))[0] }

define DbRep DbRep DbLog


Ich möchte doch "nur" z.B. die Datenbankgröße bzw. Tabellengröße etc. haben.

Ich befürchte also, dass ich nicht alle Perl-Module (POSIX, Time::HiRes, Time::Local, Scalar::Util, DBI, Blocking (FHEM-Modul)) habe.

Könnte bitte jemand posten, wie ich die nachinstalliere.

Danke
Jörg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Februar 2017, 18:59:26
Hallo Jörg,

wenn Module fehlen, kämen sicherlich Fehlermeldungen beim Define oder im Log.
Kannst du bitte mal posten was in solchen Fällen hilfreich ist, also ein list vom DbRep und ein verbose 4 log wenn du deine Funktion ausführst.

Sieht bei mir so aus (tableinfo):

2017.02.19 18:56:55.424 4: DbRep Rep.Show.DbSize -> Start BlockingCall dbmeta_DoParse
2017.02.19 18:56:55.430 4: DbRep Rep.Show.DbSize - SQL execute: select
                     table_name,
                     table_schema,
                     round(sum(data_length+index_length)/1024/1024,2),
                     round(data_free/1024/1024,2),
                     row_format,
                     table_collation,
                     engine,
                     table_type,
                     create_time
                     from information_schema.tables group by 1;
2017.02.19 18:56:55.563 4: DbRep Rep.Show.DbSize -> BlockingCall dbmeta_DoParse finished
2017.02.19 18:56:55.574 4: DbRep Rep.Show.DbSize -> Start BlockingCall dbmeta_ParseDone
2017.02.19 18:56:55.587 4: DbRep Rep.Show.DbSize -> BlockingCall dbmeta_ParseDone finished

Dauert auch nur einen Wimpernschlag.  Browserrefresh nicht vergessen !

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 20:00:25
Und kaum ein Wimpernschlag später :-)

DbRep Rep.Fhem.Size -> Start BlockingCall dbmeta_DoParse
Can't locate object method "sqlite_db_filename" via package "DBI::db" at ./FHEM/93_DbRep.pm line 3301.

Danke
Jörg

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Februar 2017, 20:10:27
Na da haben wir den Übeltäter.  ;)

sudo apt-get install libdbd-sqlite3-perl
sudo apt-get install libdbi-perl

sollte alles beinhalten.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 20:16:01
Leider nein:

libdbi-perl ist schon die neueste Version.
libdbd-sqlite3-perl ist schon die neueste Version.


Ich hatte beide schon installiert (gehabt)

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Februar 2017, 20:37:38
Hmm ... mich beschleicht das Gefühl dass deine DB-Treiber Version diese Methoden nicht anbietet.

Meine Versionen:

SQL_DBMS_VER  3.8.7.1
SQL_DBMS_VERSION 3.8.7.1
perl:5.020002 os:linux

Wie sieht es bei dir aus ?

   
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 20:46:57
Hmm ... mich beschleicht das Gefühl dass deine DB-Treiber Version diese Methoden nicht anbietet.

Meine Versionen:

SQL_DBMS_VER  3.8.7.1
SQL_DBMS_VERSION 3.8.7.1
perl:5.020002 os:linux

Wie sieht es bei dir aus ?

wie lese ich die aus ??
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Februar 2017, 20:55:35
Die Perl-Version siehst du z.B. im Start-Protokoll von FHEM.
Die SQLite habe ich mit DbRep gelesen ... ok. geht nicht  ;) ...

Auf commandline:

sudo sqlite3
SQLite version 3.8.7.1 2014-10-29 13:59:56
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 21:11:32
Ich habe:

fhem.pl:13411/2017-02-14
perl:5.014002 os:linux
SQLite version 3.7.13 2012-06-11 02:05:22

Ganz komisch:
2017.02.19 20:53:20 3: DbRep Rep.Fhem.Size - connected
2017.02.19 20:53:20 4: DbRep Rep.Fhem.Size - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful

Dann habe ich get svrinfo nochmals ausgeführt und bekomme wieder:
2017.02.19 21:00:38 4: DbRep Rep.Fhem.Size -> Start BlockingCall dbmeta_DoParse
Can't locate object method "sqlite_db_filename" via package "DBI::db" at ./FHEM/93_DbRep.pm line 3301.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Februar 2017, 21:17:45
Ist jetzt eine Vermutung ... deine Version Perl/SQlite ist etwas zu niedrig.

Zitat
Ganz komisch:
2017.02.19 20:53:20 3: DbRep Rep.Fhem.Size - connected
2017.02.19 20:53:20 4: DbRep Rep.Fhem.Size - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful

Naja das Modul und wahrscheinlich alle "normalen" Funktionen wie set ... countEntries usw. werden funktionieren.
Aber es gibt Methoden des Treibers wie" object method "sqlite_db_filename" die das installierte libdbd-sqlite3-perl-Package nicht unterstützt und deswegen der Feler kommt.
Kannst ja mal einiges durchprobieren ob stimmt was ich vermute.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 21:25:46
Wie mache ich denn ein perl update?

Ich bin ja ansonsten aktuell ( auch wenn ich tatsächlich noch wheezy habe). Aber fhem und die Module halte ich immer aktuell




Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Februar 2017, 21:34:04
Da bin ich auch nicht so firm ... müßte ich googeln ob/wie es möglich ist innerhalb einer Distribution dies zu tun. Bei mir ist meine Version auch die welche mit Debian Jessie ausgeliefert/upgedated wird.
Die Aktualität von FHEM ist an dieser Stelle (ausnahmsweise) mal nicht so relevant. FHEM nutzt die Perl-Version und in diesem Fall die Datenbank-Packages.
Bemühe mal bitte deine Suchmaschine ob/wie ein Update möglich ist.
Im ungünstigsten Fall Upgrade des OS....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 19 Februar 2017, 21:37:03
Ich versuche morgen mal
sudo apt-get -f install && sudo apt-get -y install perl libdevice-serialport-perl libio-socket-ssl-perl libwww-perl libxml-simple-perl
Heute ist mir das zu riskant. Mal sehen, , was passiert.

Danke
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 25 Februar 2017, 11:08:13
Hi,
habe die neue version getestet. Für meine Anwendungsfälle funktionierts :-)

Deine Anmerkung wegen den Zeitpunkten hat mir keine Ruhe gelassen, deswegen musste ich mich da nochmal reinarbeiten.
Geht mir absolut nicht darum, welche Version jetzt in DbRep drin ist, es funktioniert ja. Geht rein um mein Ego xD.

In meiner Änderung war der Fehler, dass ich von $hour eins abgezogen habe, damit wird $hour negativ und timelocal funktioniert nicht mehr -> doof.
Nach meinem Verständnis sollte aber folgendes funktionieren:

my $ph = strftime "%Y-%m-%d %T",localtime(timelocal(0,0,$hour,$mday,$mon,$year)-3600);

} elsif (AttrVal($hash->{NAME}, "timestamp_begin", "") eq "previous_hour_begin") {
     my $rhour = $hour-1;
         my $rmday = $mday;
         my $rmon  = $mon;
         my $ryear = $year;
         if($rhour<0) {
             $rhour = 23;
                 $rmday = $mday-1;
                 if($rmday<1) {
                 $rmon--;
                     if ($rmon<0) {
                         $rmon=12;
                         $ryear--;
                     }
                         $rmday = $rmon-2?30+($rmon*3%7<4):28+!($ryear%4||$ryear%400*!($ryear%100));
                 }
         }
     $tsbegin = strftime "%Y-%m-%d %T",localtime(timelocal(0,0,$rhour,$rmday,$rmon,$ryear));

Oder hab ich da schon wieder einen Denkfehler drin?

Danke und Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Februar 2017, 22:56:39
Hi Stephan,

habe mal so wie von dir vorgeschlagen probiert. Funktioniert irgendwie nicht. Die Zeitgrenzen für die previous hour werden immer unsinnig gesetzt.
Meiner Meinung nach müßte es aber so wie von dir geschrieben ebenfalls machbar sein.
Ich kann es mir nicht erkären, habe allerdings keinen so rechten Drang die Ursache tiefer zu ergründen  ;)
Werde meine Version 4.11.1 einchecken... es klappt ja  :D

Sollte ich die Ursache für das fehlerhafte Verhalten mit der kurzen Variante noch finden, kann ich es ja noch einbauen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 16 März 2017, 19:47:48
DbRep habe ich folgendermaßen definiert:
define rep.myDbLog.Size DbRep myDbLog

Ein
sudo apt-get -f install && sudo apt-get -y install perl libdevice-serialport-perl libio-socket-ssl-perl libwww-perl libxml-simple-perl
habe ich ausgeführt mit anschließendem Neustart.

Nach einem Neustart gibt DbRep auch den Status „connected“ aus.

myDbLog liegt im Verzeichnis /opt/fhem/dblog und heißt physisch: mydblog.db. Definiert im .conf habe ich sie auch richtig: dbname=/opt/fhem/dblog/mydblog.db.
Das Reading "SQLITE_DB_FILENAME" wird auch richtig aufgelöst mit "/opt/fhem/dblog/mydblog.db".

Gebe ich nun die Anweisung
get rep.myDbLog.Size svrinfo
ein,
erhalte ich folgende Fehlermeldung (ohne Timestamp) im Log:
du: Zugriff auf „/opt/fhem/fhem.db“ nicht möglich: Datei oder Verzeichnis nicht gefunden

fhem.db gibt es wirklich nicht – von daher ist die Meldung korrekt. Der Zugriff soll ja auch auf die /opt/fhem/dblog/mydblog.db erfolgen – das geschieht aber offensichtlich nicht.
Habe ich etwas übersehen oder liegt noch ein Fehler im Modul vor?

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2017, 20:25:48
Hi Holger,

Zitat
fhem.db gibt es wirklich nicht – von daher ist die Meldung korrekt. Der Zugriff soll ja auch auf die /opt/fhem/dblog/mydblog.db erfolgen – das geschieht aber offensichtlich nicht.
Habe ich etwas übersehen oder liegt noch ein Fehler im Modul vor?

Ja, mein Fehler .... ist ein Überbleibsel meiner Tests. Da ist noch die DB fest verdrahted und sollte eigentlich eine Variable sein.
Werde ich kurzfristig korrigieren und melde mich wieder .

Danke Holger für die Meldung !

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2017, 20:48:34
Hallo Holger,

habe im Eingangsbeitrag die Version 4.11.2 hinterlegt die den Fehler fixed.
Bitte nimm die Version und wenn alles klappt checke ich sie auch ein.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 16 März 2017, 21:51:55
Hallo Heiko,

das ging ja superfix - besonderen Dank dafür!  :)

Und jetzt geht auch alles.
LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2017, 22:01:27
Prima ,  gern geschehen  :)
Ich checke die Version dann auch ein.

LG und einen schönen Abend

Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 18 März 2017, 16:38:25
Hallo Heiko,

ich bin auf ein weiteres Problem gestoßen:
Ich habe 2 DBs im Einsatz (myDbLog und myDbLog_LT). Für beide wollte ich einen Agent definieren.
Die 1. DB konnte ich auch problemlos definieren
define rep.myDbLog.Agent DbRep myLogDB
Dazu dann noch die attr aus der Commandref (stimmt das attr bei devStateIcon auch?)

Danach habe ich den 2. Agenten eingerichtet
define rep.myDbLog_LT.Agent DbRep myLogDB_LT
Sobald ich aber hier die „role Agent“ zuweise, bekomme ich die Fehlermeldung:
There is already an Agent device: rep.myDbLog.Agent defined for database !
Mein 2. Agent heißt aber rep.myDbLog_LT.Agent mit der DB myLogDB_LT.

Oh, gleich eine Ergänzung (errortext...), habe einen Blick in's Logfile geworfen.
Ein list des 1. Agenten:
Internals:
   CFGFN
   DATABASE
   DEF        myLogDB
   LASTCMD    svrinfo
   NAME       rep.myDbLog.Agent
   NOTIFYDEV  global,rep.myDbLog.Agent
   NR         10328
   NTFY_ORDER 50-rep.myDbLog.Agent
   ROLE       Agent
   STATE      disconnected »; ProcTime:  sec
   TYPE       DbRep
   VERSION    4.11.2
   Helper:
     DBLOGDEVICE myLogDB
   Helper:
     Dblog:
       Errortext:
         Mydblog:
           TIME       1489850389.85052
           VALUE      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_DbRep.pm line 3337.

       State:
         Mydblog:
           TIME       1489850576.00303
           VALUE      disconnected
   Readings:
     2017-03-18 16:19:49   errortext       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_DbRep.pm line 3337.

     2017-03-18 16:22:56   state           disconnected
   Dbloghash:
Attributes:
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   disable    1
   icon       security
   role       Agent
   room       DbLog
   showproctime 1
   stateFormat { ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " »; ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeout    3600


Und ein kleiner Auszug aus dem Log:
2017.03.18 15:56:38 1: PERL WARNING: Use of uninitialized value $dbconn in split at ./FHEM/93_DbRep.pm line 253.
2017.03.18 15:56:38 1: Error: >myLogDB< has no TYPE, but following keys: ><
2017.03.18 15:56:38 1: PERL WARNING: Use of uninitialized value $dbmodel in string eq at ./FHEM/93_DbRep.pm line 416.
2017.03.18 15:56:43 1: PERL WARNING: Use of uninitialized value $dblogname in concatenation (.) or string at ./FHEM/93_DbRep.pm line 718.
2017.03.18 15:56:43 1: PERL WARNING: Use of uninitialized value $dbconn in concatenation (.) or string at ./FHEM/93_DbRep.pm line 722.
2017.03.18 15:56:43 1: PERL WARNING: Use of uninitialized value $dbconn in concatenation (.) or string at ./FHEM/93_DbRep.pm line 726.
2017.03.18 15:56:43 1: PERL WARNING: Use of uninitialized value $dbuser in concatenation (.) or string at ./FHEM/93_DbRep.pm line 726.
2017.03.18 15:56:43 3: DbRep rep.myDbLog.Agent - Connectiontest to database  with user
2017.03.18 15:56:43 3: DbRep rep.myDbLog.Agent - Waiting for database connection
2017.03.18 15:56:43 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 692.
2017.03.18 15:56:43 2: DbRep rep.myDbLog.Agent - DB connect failed. Credentials of database  are valid and database reachable ?
2017.03.18 15:56:47 3: DbRep rep.myDbLog.Agent - Connectiontest to database  with user
2017.03.18 15:56:47 3: DbRep rep.myDbLog.Agent - Waiting for database connection
2017.03.18 15:56:51 3: DbRep rep.myDbLog.Agent - Connectiontest to database  with user
2017.03.18 15:56:51 3: DbRep rep.myDbLog.Agent - Waiting for database connection
2017.03.18 15:56:55 3: DbRep rep.myDbLog.Agent - Connectiontest to database  with user
2017.03.18 15:56:55 3: DbRep rep.myDbLog.Agent - Waiting for database connection
2017.03.18 15:57:00 3: DbRep rep.myDbLog.Agent - Connectiontest to database  with user
2017.03.18 15:57:00 3: DbRep rep.myDbLog.Agent - Waiting for database connection
2017.03.18 16:24:56 3: DbRep rep.myDbLog.Agent - Connectiontest to database  with user
2017.03.18 16:24:56 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 328041) line 1.
2017.03.18 16:24:56 3: DbRep rep.myDbLog.Agent - Waiting for database connection

Hast du eine Idee dazu?
LG
Holger

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2017, 18:35:16
Hallo Holger,

ich habe ebenfalls mehrere DB's auf meinem Testsystem im Einsatz und habe für die beiden DbLog-Devices LogDB und LogDB1 jeweils einen Agenten definiert ... hat problemlos geklapt.

Wenn ich mich jetzt nicht täusche hast du bei der Definition mit "myLogDB":

Zitat
define rep.myDbLog.Agent DbRep myLogDB

die Datenbank selbst und nicht das DbLog-Device !  agegeben. DAs würde auch die Fehler im Log erklären.

Du mußt wie in der Hilfe angegeben:

........
define <name> DbRep <Name der DbLog-instanz>

(<Name der DbLog-instanz> - es wird der Name der auszuwertenden DBLog-Datenbankdefinition angegeben nicht der Datenbankname selbst)
........

Schau mal ob ich richtig liege ....

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 20 März 2017, 19:55:15
Hallo Heiko,

ja, ich habe die Namen verwechselt - das hängt mit meinen ganzen Tests zusammen.

Ich habe jetzt beide Agenten anlegen können, aber so ganz richtig ist noch nicht alles.
Sobald ich aus dem Wiki das attr stateFormat eingebe, bekomme ich im Log folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 32340) line 1.und bei Device Overview habe ich nicht mehr das gelbe Icon sondern den Text
connected »; ProcTime: secDas Zeichen "»" habe ich schon gegen  ">>" ausgetauscht, das war es aber auch nicht.

Ich hoffe, du sieht auch hier das Problem.

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2017, 01:23:13
Hi Holger,

ja, du hast wahrscheinlich das

attr <Rep.Agent> showproctime 1

nicht gesetzt.

Stateformat habe ich so angegeben:

attr Rep.Agent stateFormat { ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}

Das ";" hinter " »" habe ich im Wiki auch entfernt.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 21 März 2017, 09:30:16
Hallo Heiko,

showproctime hatte ich gesetzt gehabt. Das ";" war's. Danke!

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: stera am 22 März 2017, 20:30:56
Hallo,

ist es eigentlich irgendwie möglich, die erstellten Readings in einem GPlot an zu zeigen?
Wäre ja interessant für Diff und MaxValues ;o)

Gruß,
SteRa

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 März 2017, 17:17:09
Hallo SteRa,

ja das kannst du machen, allerdings über Umwege. Du musst dir ja die Ausgaben von DIFF für den Plot auswertbar speichern.

Gehen wir mal für das Beispiel davon aus du hast ein Rep-Device "Rep.Energy" und im Ergebnis von diffValue Strings die so aussehen: "2017-01-30_23-59-31__MySTP_5000__etotal__DIFF__2017-01-30".

Zunächst legst du dir einen Dummy an, z.B.:

defmod Dum.Rep dummy
attr Dum.Rep room DbLog

Dazu noch ein Notify welches die Events aufgreift die mit der Funktion diffValue des DbRep-Devices "Rep.Energy" geliefert werden.
Etwa so:

defmod N.Dum.Rep notify .*Rep.Energy.*DIFF.* { fhem "setreading Dum.Rep DeinReading"." $EVTPART1"}
attr N.Dum.Rep room DbLog

Wenn du nun mit DbRep eine Auswertung fährst, werden in dem Beispiel von dem Dummy z.B.  folgende Events erzeugt:

2017-03-24 16:28:35.857 dummy Dum.Rep DeinReading: 2.3290
2017-03-24 16:28:35.860 dummy Dum.Rep DeinReading: 1.1400

Diese Events kannst du nun wiederum in DbLog bzw. Filelog speichern um dann ein Plot aus "DeinReading" zu erstellen.
Es können bei dem Verfahren je nach Umfang natürlich ordentlich Events generiert werden.
Das Verfahren hat aber den Haken dass  der Event von "DeinReading" den aktuellen Timestamp bekommt und dadurch nicht unbedingt die Realität wiedergibt ... nämlich den Zeitpunkt zu welchem die Differenz eigentlich berechnet wurde bzw. entstanden ist.

Ggf. ist da noch etwas Aufwand reinzustecken, aber es wäre ein Weg ...

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 März 2017, 10:31:57
Hallo miteinander,

die Winterzeit ist vorbei und ich habe die Version 4.11.3 im ersten Beitrag eingestellt die diesen Wechsel in den Selektionsabgrenzungen berücksichtigt.
Ich checke die Version auch ein.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 März 2017, 11:33:53
Hallo,

ich habe die Version 4.12. im Eingangsbeitrag hinterlegt.
Hinzugekommen ist die Unterstützung für primary key in den insert-Funktionen insert bzw. importFromFile.
Damit sind diese Funktionen kompatibel zu DbLog sofern man einen primary key in der Tabelle history setzt.

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 03 April 2017, 22:23:24
Eine Frage zur Ermittlung der DB-Größe:

In der Console kann ich mit folgender Anweisung
mysql -u root -pPasswort -e 'select table_schema "Database",round(sum(data_length+index_length)/1024/1024,4) "Size (MB)" from information_schema.tables group by table_schema;'die Größe der kompletten DB sehen (momentan 243,9 MB) . Ich weiß, dass die Tabelle history unwesentlich kleiner ist.
Mit dem Tool HeidiSQL kann ich auch die DB- bzw. Tabellen-Größe sehen, aktuell 243,9 MB.

Ermittle ich die DB-Größe, wie im Wiki zu DbRep beschrieben, erhalte ich in INFO_history.data_index_lenth_MB den Wert 332.89 MB. Das ist ja doch eine ziemliche Abweichung, die ich nicht verstehe.

Was muss ich zur Ermittlung der DB-Größe noch beachten?

LG
Holger


 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2017, 22:50:43
Hi Holger,

Zitat
Was muss ich zur Ermittlung der DB-Größe noch beachten?

Nichts weiter.
Ich habe natürlich gleich bei mir das gleiche ausgeführt. Die Größe lasse ich vom Modul für einen Plot regelmäßig ermitteln. Jetzt habe ich es sowohl in phpMyadmin als auch von der Konsole wie du ausgeführt und bekomme in allen Fällen die gleichen Ergebnisse wie mit DbRep (bis auf Nachkommastellen).
In DbRep wird übrigens derselbe Aufruf zur Ermittlung verwendet.

Hmm ... da kann ich Addhoc keine Erkärung für diese Abweichung finden.

Du kannst mit verbose 5 ein "get tableinfo" fahren. Es gibt dann im Log am Ende einen Eintrag "-> row_array: "  mit den Rohdaten nach der Abfrage.
Vllt. sieht man dann etwas mehr.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 April 2017, 10:07:11
Hallo Heiko,

leider ist es noch etwas komplizierter. Ich habe derzeit 2 mySQL-DBs (myFHEMdb und myFHEMdb_LT).
Nach Miternacht setze ich bei beiden DBs ein „set … countEntries“ und ein „get … tableinfo“ ab. Die Anzahl der Records ist annähernd identisch mit dem Tool HeidiSQL (myFHEMdb = 1172043, myFHEMdb_LT = 512601 Records). Die DB-Größe wird aber bei beiden DBs identisch (und falsch) angegeben mit jetzt 336.89 MB. Bei der unterschiedlichen Satzanzahl unrealistisch.

Hier ein Auszug von "get tableinfo" mit verbose 5
myFHEMdb:
2017.04.04 09:29:05 5: DbRep rep.myFHEMdb.Size -> row_array:
current.table_schema fhem current.data_index_length_MB 0.23 current.table_name fhem current.data_free_MB 4.00 current.row_format Compact current.table_collation utf8_bin current.engine InnoDB current.table_type BASE_TABLE current.create_time 2017-03-23_00:09:28 history.table_schema fhem history.data_index_length_MB 336.89 history.table_name fhem history.data_free_MB 4.00 history.row_format Compact history.table_collation utf8_bin history.engine InnoDB history.table_type BASE_TABLE history.create_time 2017-03-23_00:09:28
und myFHEMdb_LT:
2017.04.04 09:28:47 5: DbRep rep.myFHEMdb_LT.Size -> row_array:
current.table_schema fhem current.data_index_length_MB 0.23 current.table_name fhem current.data_free_MB 4.00 current.row_format Compact current.table_collation utf8_bin current.engine InnoDB current.table_type BASE_TABLE current.create_time 2017-03-23_00:09:28 history.table_schema fhem history.data_index_length_MB 336.89 history.table_name fhem history.data_free_MB 4.00 history.row_format Compact history.table_collation utf8_bin history.engine InnoDB history.table_type BASE_TABLE history.create_time 2017-03-23_00:09:28

Hier fallen mir identische „…create_time“ Einträge auf. Für die DB myFHEMdb_LT ist das aber falsch. Hier müsste 2017-03-22_23:43:49 stehen. Wird die falsche DB gelesen? In der Ergebniszeile (row_array) würde ich bei myFHEMdb_LT erwarten, dass da "current.table_schema fhem_lt" steht und nicht "current.table_schema fhem". Macht vielleicht der "_" im Namen Probleme?
Irgendwo ist ein Wurm darin…

Übersicht über meine Definitionen:
myFHEMdb:
Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/dblog/sqldb.conf
   DBMODEL    MYSQL
   DEF        /opt/fhem/dblog/sqldb.conf .*:.*
   MODE       asynchronous
   NAME       myFHEMdb
   NR         229
   NTFY_ORDER 50-myFHEMdb
   PID        4224
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   VERSION    2.14.4
   dbconn     mysql:database=fhem;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:
       Countcurrent:
         Mydblog:
           TIME       1491291632.33305
           VALUE      1535
         Myfhemdb:
           TIME       1491291632.3382
           VALUE      1535
       Counthistory:
         Mydblog:
           TIME       1491291632.32342
           VALUE      1172753
         Myfhemdb:
           TIME       1491291632.32741
           VALUE      1172753
       Lastrowsdeleted:
         Mydblog:
           TIME       1491256863.41192
           VALUE      0
         Myfhemdb:
           TIME       1491256863.41605
           VALUE      0
       State:
         Mydblog:
           TIME       1491291632.01284
           VALUE      countNbl
         Myfhemdb:
           TIME       1491291632.01807
           VALUE      countNbl
   Readings:
     2017-04-04 09:41:08   CacheUsage      18
     2017-04-04 09:41:08   NextSync        2017-04-04 09:41:38 or if CacheUsage 500 reached
     2017-04-04 09:40:32   countCurrent    1535
     2017-04-04 09:40:32   countHistory    1172753
     2017-04-04 00:01:03   lastRowsDeleted 0
     2017-04-04 09:41:08   state           connected
   Cache:
     index      109712
     Memcache:
       109695     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed: 152626|electricityConsumed|152626|
       109696     2017-04-04 09:41:08|strombezug|JSONMETER|statElectricityConsumed: Hour: 571 Day: 4710 Month: 33746 Year: 33746 (since: 2017-04-02 )|statElectricityConsumed|Hour: 571 Day: 4710 Month: 33746 Year: 33746 (since: 2017-04-02 )|
       109697     2017-04-04 09:41:08|strombezug|JSONMETER|statElectricityConsumedToday: 4710|statElectricityConsumedToday|4710|
       109698     2017-04-04 09:41:08|strombezug|JSONMETER|electricityPower: 657|electricityPower|657|
       109699     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_kWh: 152.626|electricityConsumed_kWh|152.626|
       109700     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumedToday_kWh: 4.71|electricityConsumedToday_kWh|4.71|
       109701     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_PowerCurrent: 654.545|electricityConsumed_PowerCurrent|654.545|
       109702     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_PowerDayAver: 486.392|electricityConsumed_PowerDayAver|486.392|
       109703     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyDay: 4.710|electricityConsumed_EnergyDay|4.710|
       109704     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyMonth: -4887.374|electricityConsumed_EnergyMonth|-4887.374|
       109705     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyYear: -4887.374|electricityConsumed_EnergyYear|-4887.374|
       109706     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyMeter: -4887.374|electricityConsumed_EnergyMeter|-4887.374|
       109707     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyCostDay: 1.201|electricityConsumed_EnergyCostDay|1.201|
       109708     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyCostMonth: -1246.280|electricityConsumed_EnergyCostMonth|-1246.280|
       109709     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyCostYear: -1246.280|electricityConsumed_EnergyCostYear|-1246.280|
       109710     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_EnergyCostMeter: -1246.280|electricityConsumed_EnergyCostMeter|-1246.280|
       109711     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_FinanceReserve: 2796.730|electricityConsumed_FinanceReserve|2796.730|
       109712     2017-04-04 09:41:08|strombezug|JSONMETER|electricityConsumed_CounterCurrent: 152.626|electricityConsumed_CounterCurrent|152.626|
Attributes:
   DbLogSelectionMode Exclude
   DbLogType  Current/History
   asyncMode  1
   excludeDevs LaCrosse.*,clone_ESPEasy_ESP_G16.*,ESPEasy_ESP_G16.*,d.ESP_G16_GasZaehler.*,doif..*,DS.*
   room       DbLog

myFHEMdb_LT:
Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/dblog/sqldb_lt.conf
   DBMODEL    MYSQL
   DEF        /opt/fhem/dblog/sqldb_lt.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       myFHEMdb_LT
   NR         231
   NTFY_ORDER 50-myFHEMdb_LT
   PID        4224
   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=fhem_lt;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:
       State:
         Mydblog:
           TIME       1491256740.03095
           VALUE      connected
         Myfhemdb:
           TIME       1491256740.03662
           VALUE      connected
   Readings:
     2017-04-04 09:43:44   CacheUsage      2
     2017-04-04 09:43:44   NextSync        2017-04-04 09:44:14 or if CacheUsage 500 reached
     2017-03-21 17:15:20   reduceLogState  reduceLogNbl finished. Rows processed: 0, deleted: 0, time: 0.00sec
     2017-04-04 09:43:44   state           connected
   Cache:
     index      19417
     Memcache:
       19416      2017-04-04 09:43:44|strombezug|JSONMETER|statElectricityConsumed: Hour: 604 Day: 4743 Month: 33779 Year: 33779 (since: 2017-04-02 )|statElectricityConsumed|Hour: 604 Day: 4743 Month: 33779 Year: 33779 (since: 2017-04-02 )|
       19417      2017-04-04 09:43:44|strombezug|JSONMETER|statElectricityConsumedToday: 4743|statElectricityConsumedToday|4743|
Attributes:
   DbLogSelectionMode Exclude
   DbLogType  Current/History
   asyncMode  1
   room       DbLog

Rep.myFHEMdb.Size:
Internals:
   CFGFN
   DATABASE   fhem
   DEF        myFHEMdb
   LASTCMD    tableinfo
   NAME       rep.myFHEMdb.Size
   NOTIFYDEV  global,rep.myFHEMdb.Size
   NR         18015
   NTFY_ORDER 50-rep.myFHEMdb.Size
   ROLE       Client
   STATE      done
   TYPE       DbRep
   VERSION    4.11.4
   Helper:
     DBLOGDEVICE myFHEMdb
     Cv:
       aggregation no
       aggsec     1
       destr      2017-04-04
       dsstr      1970-01-01
       epoch_seconds_end 1491290647
       mestr      04
       msstr      01
       testr      09:24:07
       tsstr      01:00:00
       wdadd      345600
       yestr      2017
       ysstr      1970
   Helper:
     Dblog:
       1970-01-01__count__all_between_timestamps:
         Mydblog:
           TIME       1491290648.78851
           VALUE      1172043
         Myfhemdb:
           TIME       1491290648.79239
           VALUE      1172043
       Info_history.data_index_length_mb:
         Mydblog:
           TIME       1491290945.37953
           VALUE      336.89
         Myfhemdb:
           TIME       1491290945.38358
           VALUE      336.89
       State:
         Mydblog:
           TIME       1491251391.14047
           VALUE      done
         Myfhemdb:
           TIME       1491251391.1444
           VALUE      done
   Readings:
     2017-04-04 09:29:05   INFO_history.data_index_length_MB 336.89
     2017-04-04 09:29:05   state           done
   Dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION /opt/fhem/dblog/sqldb.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/dblog/sqldb.conf .*:.*
     MODE       asynchronous
     NAME       myFHEMdb
     NR         229
     NTFY_ORDER 50-myFHEMdb
     PID        4224
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     VERSION    2.14.4
     dbconn     mysql:database=fhem;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:
         Countcurrent:
           Mydblog:
             TIME       1491291632.33305
             VALUE      1535
           Myfhemdb:
             TIME       1491291632.3382
             VALUE      1535
         Counthistory:
           Mydblog:
             TIME       1491291632.32342
             VALUE      1172753
           Myfhemdb:
             TIME       1491291632.32741
             VALUE      1172753
         Lastrowsdeleted:
           Mydblog:
             TIME       1491256863.41192
             VALUE      0
           Myfhemdb:
             TIME       1491256863.41605
             VALUE      0
         State:
           Mydblog:
             TIME       1491291632.01284
             VALUE      countNbl
           Myfhemdb:
             TIME       1491291632.01807
             VALUE      countNbl
     Readings:
       2017-04-04 09:44:47   CacheUsage      20
       2017-04-04 09:44:47   NextSync        2017-04-04 09:45:17 or if CacheUsage 500 reached
       2017-04-04 09:40:32   countCurrent    1535
       2017-04-04 09:40:32   countHistory    1172753
       2017-04-04 00:01:03   lastRowsDeleted 0
       2017-04-04 09:44:47   state           connected
     Cache:
       index      109868
       Memcache:
         109849     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed: 152668|electricityConsumed|152668|
         109850     2017-04-04 09:44:47|strombezug|JSONMETER|statElectricityConsumed: Hour: 613 Day: 4752 Month: 33788 Year: 33788 (since: 2017-04-02 )|statElectricityConsumed|Hour: 613 Day: 4752 Month: 33788 Year: 33788 (since: 2017-04-02 )|
         109851     2017-04-04 09:44:47|strombezug|JSONMETER|statElectricityConsumedToday: 4752|statElectricityConsumedToday|4752|
         109852     2017-04-04 09:44:47|strombezug|JSONMETER|electricityPower: 532|electricityPower|532|
         109853     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_kWh: 152.668|electricityConsumed_kWh|152.668|
         109854     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumedToday_kWh: 4.752|electricityConsumedToday_kWh|4.752|
         109855     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_PowerCurrent: 480.000|electricityConsumed_PowerCurrent|480.000|
         109856     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_PowerDayAver: 487.682|electricityConsumed_PowerDayAver|487.682|
         109857     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyDay: 4.752|electricityConsumed_EnergyDay|4.752|
         109858     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyMonth: -4887.332|electricityConsumed_EnergyMonth|-4887.332|
         109859     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyYear: -4887.332|electricityConsumed_EnergyYear|-4887.332|
         109860     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyMeter: -4887.332|electricityConsumed_EnergyMeter|-4887.332|
         109861     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyCostDay: 1.212|electricityConsumed_EnergyCostDay|1.212|
         109862     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyCostMonth: -1246.270|electricityConsumed_EnergyCostMonth|-1246.270|
         109863     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyCostYear: -1246.270|electricityConsumed_EnergyCostYear|-1246.270|
         109864     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_EnergyCostMeter: -1246.270|electricityConsumed_EnergyCostMeter|-1246.270|
         109865     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_FinanceReserve: 2796.720|electricityConsumed_FinanceReserve|2796.720|
         109866     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_CounterCurrent: 152.668|electricityConsumed_CounterCurrent|152.668|
         109867     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumed_kWh_PowerDayAver: 0.715|electricityConsumed_kWh_PowerDayAver|0.715|
         109868     2017-04-04 09:44:47|strombezug|JSONMETER|electricityConsumedToday_kWh_PowerDayAver: -0.994|electricityConsumedToday_kWh_PowerDayAver|-0.994|
Attributes:
   DbLogExclude state
   icon       time_note
   room       DbLog
   showTableInfo %history%,%current%
   showproctime 1
   suppressReading ^(?!.*(INFO_history.data_index_length_MB)|(state)|(1970-01-01__COUNT__all_between_timestamps)).*$

Rep.myFHEMdb_LT.Size:
Internals:
   CFGFN
   DATABASE   fhem_lt
   DEF        myFHEMdb_LT
   LASTCMD    tableinfo
   NAME       rep.myFHEMdb_LT.Size
   NOTIFYDEV  global,rep.myFHEMdb_LT.Size
   NR         18113
   NTFY_ORDER 50-rep.myFHEMdb_LT.Size
   ROLE       Client
   STATE      done
   TYPE       DbRep
   VERSION    4.11.4
   Helper:
     DBLOGDEVICE myFHEMdb_LT
     Cv:
       aggregation no
       aggsec     1
       destr      2017-04-04
       dsstr      1970-01-01
       epoch_seconds_end 1491290843
       mestr      04
       msstr      01
       testr      09:27:23
       tsstr      01:00:00
       wdadd      345600
       yestr      2017
       ysstr      1970
   Helper:
     Dblog:
       1970-01-01__count__all_between_timestamps:
         Mydblog:
           TIME       1491290844.20598
           VALUE      512601
         Myfhemdb:
           TIME       1491290844.21006
           VALUE      512601
       Info_history.data_index_length_mb:
         Mydblog:
           TIME       1491290927.01463
           VALUE      336.89
         Myfhemdb:
           TIME       1491290927.01863
           VALUE      336.89
       State:
         Mydblog:
           TIME       1491251610.77049
           VALUE      done
         Myfhemdb:
           TIME       1491251610.7746
           VALUE      done
   Readings:
     2017-04-04 09:28:47   INFO_history.data_index_length_MB 336.89
     2017-04-04 09:28:47   state           done
   Dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION /opt/fhem/dblog/sqldb_lt.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/dblog/sqldb_lt.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       myFHEMdb_LT
     NR         231
     NTFY_ORDER 50-myFHEMdb_LT
     PID        4224
     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=fhem_lt;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:
         State:
           Mydblog:
             TIME       1491256740.03095
             VALUE      connected
           Myfhemdb:
             TIME       1491256740.03662
             VALUE      connected
     Readings:
       2017-04-04 09:45:20   CacheUsage      5
       2017-04-04 09:45:20   NextSync        2017-04-04 09:45:50 or if CacheUsage 500 reached
       2017-03-21 17:15:20   reduceLogState  reduceLogNbl finished. Rows processed: 0, deleted: 0, time: 0.00sec
       2017-04-04 09:45:20   state           connected
     Cache:
       index      19429
       Memcache:
         19425      2017-04-04 09:45:20|mys_103_TempHum2Button|MYSENSORS_DEVICE|temperature: 16.2|temperature|16.2|°C
         19426      2017-04-04 09:45:20|mys_103_TempHum2Button|MYSENSORS_DEVICE|humidity: 55.7|humidity|55.7|%
         19427      2017-04-04 09:45:20|mys_103_TempHum2Button|MYSENSORS_DEVICE|dewpoint: 7.3|dewpoint|7.3|
         19428      2017-04-04 09:45:20|strombezug|JSONMETER|statElectricityConsumed: Hour: 618 Day: 4757 Month: 33793 Year: 33793 (since: 2017-04-02 )|statElectricityConsumed|Hour: 618 Day: 4757 Month: 33793 Year: 33793 (since: 2017-04-02 )|
         19429      2017-04-04 09:45:20|strombezug|JSONMETER|statElectricityConsumedToday: 4757|statElectricityConsumedToday|4757|
Attributes:
   DbLogExclude state
   icon       time_note
   room       DbLog
   showTableInfo %history%,%current%
   showproctime 1
   suppressReading ^(?!.*(INFO_history.data_index_length_MB)|(state)|(1970-01-01__COUNT__all_between_timestamps)).*$

Zuletzt noch die Übersicht aus der Consolenabfrage:
[font=courier]+--------------------+-----------+
| Database           | Size (MB) |
+--------------------+-----------+
| fhem               |  248.9219 |
| fhem_lt            |   89.2031 |
| information_schema |    0.0088 |
| mysql              |    0.6784 |
| performance_schema |    0.0000 |
+--------------------+-----------+[/font]

Ich hoffe, ich konnte die relevanten Infos zusammenstellen um den Fehler zu finden (der ja meistens vor dem Bildschirm sitzt  ;)) und bin froh, dass du mich unterstützt. Danke!

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 April 2017, 10:30:25
Hallo Holger,

Lass mir Mal ein bisschen Zeit um das zu analysieren, ist viel Stoff. 😉
Aber ich habe jetzt eine Vermutung ... möglicherweise liegt es an der Namensähnlichkeit deiner DBs und ich habe irgendwo im Code ein zu ungenaues Matching auf ein RegEx. Die Größe ist ja überschlägig  die Summe der history Tabelle beider DBs wenn ich das richtig sehe.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 April 2017, 10:40:43
Was mir Grad noch einfällt.... deine Anmerkung zum Unterstrich. In SQL Statements wird der Unterstrich als Platzhalter interpretiert. Ich habe jetzt den select Code nicht vor Augen, aber wenn es dir möglich ist würde ich den DB-Namen vorsorglich ändern ohne Unterstrich.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 April 2017, 12:13:44
Hallo Heiko,

jetzt habe ich eine 3. DB angelegt (in mySQL: fhemlt, unter FHEM: myFHEMdbLT) und per expimp aus myFHEMdb_LT gefüllt.
Frage ich jetzt die Größe von myFHEMdbLT ab, komme ich auf 418 MB (ungefähr die Summe aller 3 DBs).
Es liegt also nicht am "_".

Fast alle DB-Zugriffe laufen richtig - nur bei der DB-Größe kommt es zur Abweichung.

Ich glaube, etwas gefunden zu haben
In dem kompletten Listing zu tabeinfo findest du überall den Timestamp: 2017-04-04_12:00:05 außer bei den Tabellen current und history:
- INFO_current.create_time 2017-03-23_00:09:28
- INFO_history.create_time 2017-03-23_00:09:28

Die DB habe ich aber gerade eben erst angelegt. Die Timestamps 2017-03-23_00:09:28 gehören zur DB fhem (mySQL-Name) bzw. myFHEMdb in FHEM.

[code]
Internals:
   CFGFN
   DATABASE   fhemlt
   DEF        myFHEMdbLT
   LASTCMD    tableinfo
   NAME       rep.myFHEMdbLT.Agent
   NOTIFYDEV  global,rep.myFHEMdbLT.Agent
   NR         26258
   NTFY_ORDER 50-rep.myFHEMdbLT.Agent
   ROLE       Client
   STATE      done » ProcTime: 0.0087 sec
   TYPE       DbRep
   VERSION    4.11.4
   Helper:
     DBLOGDEVICE myFHEMdbLT
   Helper:
     Dblog:
       Info_character_sets.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_character_sets.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_character_sets.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_character_sets.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_character_sets.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_character_sets.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_character_sets.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_character_sets.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_character_sets.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_collations.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_collations.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collations.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collations.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_collations.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_collations.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_collations.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collations.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collations.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_collation_character_set_applicability.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_collation_character_set_applicability.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collation_character_set_applicability.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collation_character_set_applicability.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_collation_character_set_applicability.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_collation_character_set_applicability.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_collation_character_set_applicability.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collation_character_set_applicability.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collation_character_set_applicability.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_columns.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_columns.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_columns.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_columns.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MyISAM
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MyISAM
       Info_columns.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Dynamic
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Dynamic
       Info_columns.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_columns.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_columns.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_columns.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_column_privileges.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_column_privileges.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_column_privileges.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_column_privileges.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_column_privileges.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_column_privileges.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_column_privileges.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_column_privileges.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_column_privileges.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_engines.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_engines.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_engines.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_engines.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_engines.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_engines.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_engines.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_engines.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_engines.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_events.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_events.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_events.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_events.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MyISAM
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MyISAM
       Info_events.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Dynamic
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Dynamic
       Info_events.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_events.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_events.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_events.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_files.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_files.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_files.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_files.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_files.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_files.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_files.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_files.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_files.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_global_status.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_global_status.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_status.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_status.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_global_status.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_global_status.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_global_status.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_status.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_status.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_global_variables.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_global_variables.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_variables.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_variables.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_global_variables.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_global_variables.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_global_variables.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_variables.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_variables.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_buffer_page.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_buffer_page.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_buffer_page.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_buffer_page.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_buffer_page.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_buffer_page_lru.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_buffer_page_lru.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page_lru.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page_lru.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_buffer_page_lru.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_buffer_page_lru.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_buffer_page_lru.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page_lru.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page_lru.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_buffer_pool_stats.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_buffer_pool_stats.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_pool_stats.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_pool_stats.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_buffer_pool_stats.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_buffer_pool_stats.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_buffer_pool_stats.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_pool_stats.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_pool_stats.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_cmp.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_cmp.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmp.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmp.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_cmp.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_cmp.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_cmp.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmp.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmp.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_cmpmem.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_cmpmem.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmpmem.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmpmem.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_cmpmem.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_cmpmem.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_cmpmem.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmpmem
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 April 2017, 12:26:12
Das ist echt komisch, ich habe 4 fhem-Datenbanken in der MariaDB laufen und keine derartigen Effekte. Bei mir heissen sie fhem, fhemshort, fhemtest und fhemtest1. Also da muss ich nochmal in mich gehen. So etwas  müsste doch bei mir auch auftreten ... echt eigenartig.
Ich habe MariaDB 5.5.53 und Perl 5.20.2.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 April 2017, 14:11:37
Mir ist eben aufgefallen, dass in meinem letzten Beitrag die Hälfte fehlt.
Lässt die Forensoftware nur eine bestimmte Größe in code-Tags zu? Oder ich habe irgendwann versehentlich den schließenden Tag verwurstet.
Ausgerechnet die Infos zu current und history haben gefehlt.

Also noch einmal, ich hoffe, jetzt komplett...
[code]
Internals:
   CFGFN
   DATABASE   fhemlt
   DEF        myFHEMdbLT
   LASTCMD    tableinfo
   NAME       rep.myFHEMdbLT.Agent
   NOTIFYDEV  global,rep.myFHEMdbLT.Agent
   NR         26258
   NTFY_ORDER 50-rep.myFHEMdbLT.Agent
   ROLE       Client
   STATE      done » ProcTime: 0.0087 sec
   TYPE       DbRep
   VERSION    4.11.4
   Helper:
     DBLOGDEVICE myFHEMdbLT
   Helper:
     Dblog:
       Info_character_sets.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_character_sets.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_character_sets.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_character_sets.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_character_sets.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_character_sets.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_character_sets.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_character_sets.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_character_sets.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_collations.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_collations.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collations.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collations.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_collations.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_collations.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_collations.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collations.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collations.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_collation_character_set_applicability.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_collation_character_set_applicability.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collation_character_set_applicability.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_collation_character_set_applicability.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_collation_character_set_applicability.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_collation_character_set_applicability.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_collation_character_set_applicability.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collation_character_set_applicability.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_collation_character_set_applicability.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_columns.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_columns.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_columns.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_columns.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MyISAM
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MyISAM
       Info_columns.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Dynamic
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Dynamic
       Info_columns.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_columns.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_columns.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_columns.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_column_privileges.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_column_privileges.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_column_privileges.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_column_privileges.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_column_privileges.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_column_privileges.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_column_privileges.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_column_privileges.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_column_privileges.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_engines.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_engines.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_engines.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_engines.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_engines.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_engines.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_engines.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_engines.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_engines.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_events.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_events.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_events.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_events.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MyISAM
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MyISAM
       Info_events.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Dynamic
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Dynamic
       Info_events.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_events.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_events.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_events.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_files.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_files.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_files.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_files.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_files.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_files.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_files.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_files.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_files.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_global_status.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_global_status.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_status.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_status.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_global_status.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_global_status.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_global_status.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_status.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_status.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_global_variables.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_global_variables.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_variables.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_global_variables.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_global_variables.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_global_variables.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_global_variables.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_variables.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_global_variables.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_buffer_page.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_buffer_page.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_buffer_page.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_buffer_page.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_buffer_page.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_buffer_page_lru.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_buffer_page_lru.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page_lru.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_page_lru.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_buffer_page_lru.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_buffer_page_lru.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_buffer_page_lru.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page_lru.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_page_lru.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_buffer_pool_stats.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_buffer_pool_stats.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_pool_stats.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_buffer_pool_stats.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_buffer_pool_stats.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_buffer_pool_stats.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_buffer_pool_stats.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_pool_stats.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_buffer_pool_stats.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_cmp.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_cmp.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmp.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmp.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_cmp.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_cmp.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_cmp.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmp.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmp.table_type:
         Mydblog:
           TIME       1491300005.6177
           VALUE      SYSTEM_VIEW
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      SYSTEM_VIEW
       Info_innodb_cmpmem.create_time:
         Mydblog:
           TIME       1491300005.6177
           VALUE      2017-04-04_12:00:05
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      2017-04-04_12:00:05
       Info_innodb_cmpmem.data_free_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmpmem.data_index_length_mb:
         Mydblog:
           TIME       1491300005.6177
           VALUE      0.00
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      0.00
       Info_innodb_cmpmem.engine:
         Mydblog:
           TIME       1491300005.6177
           VALUE      MEMORY
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      MEMORY
       Info_innodb_cmpmem.row_format:
         Mydblog:
           TIME       1491300005.6177
           VALUE      Fixed
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      Fixed
       Info_innodb_cmpmem.table_collation:
         Mydblog:
           TIME       1491300005.6177
           VALUE      utf8_general_ci
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      utf8_general_ci
       Info_innodb_cmpmem.table_name:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmpmem.table_schema:
         Mydblog:
           TIME       1491300005.6177
           VALUE      information_schema
         Myfhemdb:
           TIME       1491300005.64944
           VALUE      information_schema
       Info_innodb_cmpmem.tabl
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 April 2017, 14:19:50
Jetzt wurde meine Änderung auch verschluckt (in der Vorschau war noch alles ok).

Der wichtige Rest (current und history). Wenn das jetzt auch nicht funktioniert, hänge ich den Output als Datei an.
     2017-04-04 12:00:05   INFO_current.create_time 2017-03-23_00:09:28
     2017-04-04 12:00:05   INFO_current.data_free_MB 18.00
     2017-04-04 12:00:05   INFO_current.data_index_length_MB 0.27
     2017-04-04 12:00:05   INFO_current.engine InnoDB
     2017-04-04 12:00:05   INFO_current.row_format Compact
     2017-04-04 12:00:05   INFO_current.table_collation utf8_bin
     2017-04-04 12:00:05   INFO_current.table_name fhem
     2017-04-04 12:00:05   INFO_current.table_schema fhem
     2017-04-04 12:00:05   INFO_current.table_type BASE_TABLE
     2017-04-04 12:00:05   INFO_history.create_time 2017-03-23_00:09:28
     2017-04-04 12:00:05   INFO_history.data_free_MB 18.00
     2017-04-04 12:00:05   INFO_history.data_index_length_MB 418.08
     2017-04-04 12:00:05   INFO_history.engine InnoDB
     2017-04-04 12:00:05   INFO_history.row_format Compact
     2017-04-04 12:00:05   INFO_history.table_collation utf8_bin
     2017-04-04 12:00:05   INFO_history.table_name fhem
     2017-04-04 12:00:05   INFO_history.table_schema fhem
     2017-04-04 12:00:05   INFO_history.table_type BASE_TABLE
     2017-04-04 12:00:05   background_processing_time 0.0101
     2017-04-04 12:00:05   sql_processing_time 0.0087
     2017-04-04 12:00:05   state           done
   Dbloghash:
     CFGFN
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION /opt/fhem/dblog/sqldblt.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/dblog/sqldblt.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       synchronous
     NAME       myFHEMdbLT
     NR         26143
     NTFY_ORDER 50-myFHEMdbLT
     PID        4224
     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=fhemlt;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:
         State:
           Mydblog:
             TIME       1491298884.62611
             VALUE      connected
           Myfhemdb:
             TIME       1491298884.62999
             VALUE      connected
     Readings:
       2017-04-04 14:02:27   CacheUsage      2
       2017-04-04 14:02:27   NextSync        2017-04-04 14:02:57 or if CacheUsage 500 reached
       2017-04-04 14:02:27   state           connected
     Cache:
       index      1122
       Memcache:
         1121       2017-04-04 14:02:27|strombezug|JSONMETER|statElectricityConsumed: Hour: 21 Day: 7604 Month: 36640 Year: 36640 (since: 2017-04-02 )|statElectricityConsumed|Hour: 21 Day: 7604 Month: 36640 Year: 36640 (since: 2017-04-02 )|
         1122       2017-04-04 14:02:27|strombezug|JSONMETER|statElectricityConsumedToday: 7604|statElectricityConsumedToday|7604|
Attributes:
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   icon       security
   room       DbLog
   showproctime 1
   stateFormat { ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeout    3600

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 04 April 2017, 15:03:07
zur Info:
Folgende Fehlermeldungen erhalte ich nach update von fhem im Log:
Use of uninitialized value $dbconn in split at ./FHEM/93_DbRep.pm line 257, <$fh> line 2754.
Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 1939, <$fh> line 3564.

vielleicht ist es was von Bedeutung?!?

sG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 April 2017, 16:39:34
Ich habe jetzt noch eine 4. DB angelegt - ganz anderer Name (test bzw. myTESTdb), um auch Probleme von Namensähnlichkeiten ausschließen zu können.

Nach Anlage der DB (ohne Import weiterer Daten) erhalte ich als Größe 423 MB - also wieder die Summe aller DBs. Auch hier wieder die falschen Timestamps bei
- INFO_current.create_time           2017-03-23_00:09:28
- INFO_history.create_time            2017-03-23_00:09:28
bzw. die in der falschen DB gelesenen Tabellen.

LG
Holger

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 April 2017, 23:38:28
Hallo Holger,

ich konnte bisher nicht wirklich einen Fehler finden.  Ist allerdings auch schon spät heute.
Bei mir werden die Daten sauber für die jeweilige fhem-DB gelistet.
Ich habe mal eine neue Version hier angehängt. Prüfe mal bei dir ob sich etwas ändert.

Vielleicht noch ein Hinweis .... ich verwende für jede einzelne DB einen separaten Nutzer der auch nur die Rechte auf diese DB hat, also 4 DBs bei mir mit 4 separaten Nutzer. Das habe ich auch aus Sicherheitsgründen so eingerichtet damit bei meiner ganzen Testerei nichts schief geht.

Checke dies auch mal bei dir. Ich kann mir eigentlich nur so etwas im Metabereich vorstellen, sonst müsste ich doch auch diese Effekte haben.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 05 April 2017, 10:29:34
Hallo Heiko,

danke für deine Unterstützung.
Leider hat sich mit der neuen Version nichts geändert.

Linux ist bei mir eine große Baustelle, d.h. Rechtevergabe, Nutzung mehrerer User für unterschiedliche DBs, die FHEM aber dann wieder übergreifend alle bearbeiten kann, übersteigt derzeitig meinen Kenntnisstand.

Die Konfiguration meiner (momentan) 4 DBs habe ich auch noch einmal überprüft (sowohl die Definition in FHEM (der Verweis auf die richtige .conf) als auch die jeweilige .conf selber): alles mMn richtig konfiguriert.

Jetzt stelle ich die Frage mal anders herum: was würde bei dir passieren, wenn du bei allen DBs den gleichen User hast? Vielleicht ist das tatsächlich der Unterschied, warum bei dir die Daten sauber separiert werden. Jede Abfrage auf eine deiner DBs kann aufgrund der Rechtevergabe nur ein eindeutiges Ergebnis liefern, d.h. die Selektion erfolgt vielleicht nicht wirklich aufgrund der DB-Angabe in der Konfiguration von DbRep in FHEM sondern aufgrund der Abgrenzung des Users in der .conf auf Systemebene. Bei mir werden beim Aufruf von get tableinfo alle vorhandenen DBs gelesen und die ermittelten Werte aufsummiert (so ähnlich wie bei dem Aufruf in der Console). get tableinfo dürfte eigentlich aber nur auf die DB zugreifen, die in DbRep festgelegt ist. Ich weiß: alles nur Spekulation - aber zumindest klingt es logisch.

Das kann aber nur bei dieser speziellen Abfrage sein. Die anderen Zugriffe, also das Zählen der Records oder das separieren und Löschen bestimmter Einträge erfolgt mMn fehlerfrei.

LG
Holger

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 April 2017, 21:06:33
Hallo Holger,

kurzer Zwischenstand.
Also es liegt an den Rechten des users. Mit root bekomme ich das gleiche Ergebnis wie du.
Hier habe ich die eine Version angehängt die dein Problem erst einmal lösen wird. Es wird aber nicht die Größe der einzelnen Tabellen ausgegeben was in ursprünglich wollte.
Aber ich schaue mal ob ich das noch besser lösen kann ...

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 06 April 2017, 22:15:48
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 April 2017, 14:18:08
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 07 April 2017, 17:24:36
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

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 April 2017, 19:58:51
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:

Zitat
The 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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 07 April 2017, 22:23:53
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 07 Mai 2017, 14:20:45
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?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Mai 2017, 14:51:10
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 07 Mai 2017, 15:05:38
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...

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Mai 2017, 15:36:47
Zitat
Ich 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 ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 08 Mai 2017, 21:20:53
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Mai 2017, 21:58:23
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 08 Mai 2017, 23:03:26
Ja, keine Hektik - bei mir läuft es ja ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Mai 2017, 19:08:23
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
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 09 Mai 2017, 22:23:29
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)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Mai 2017, 22:48:10
Hallo Johannes,

Zitat
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

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.

Zitat
Macht 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 ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Mai 2017, 23:25:00
Habe die angepasste Version 4.13.5 im Eingang hinterlegt.
Eval sollte nun auch das prepare schützen.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Mai 2017, 15:49:06
Hallo Johannes, @all,

ich habe noch etwas geändert und zusammengefasst.
Es gibt nur noch das Command "sqlCmd".

Es umfasst alle Darstellungsformen:

* separated - als Einzelreadings (default)
* sline        - Singleline
* mline       - Multiline
* table        - als Tabelle

Das Attribut zur Formatierung heißt nun "sqlResultFormat" und das Reading "SqlResult".
Das letzte Kommando wird in Reading "sqlCmd" gespeichert. Damit ist es beim Set gleich wieder vorbelegt.
Ich denke das macht alles etwas übersichtlicher und man kann sich dennoch jede gewünschte Darstellungsform auswählen.
Die Commandref ist auch erstellt.

Diese neue Version 4.13.7 befindet sich wie gehabt im 1. Beitrag.

Wenn alles soweit passt werde ich die Version demnächst mal einchecken. Ich teste aber auch noch ein bisschen.

VG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 11 Mai 2017, 23:00:17
Die Änderungen klingen alle sinnvoll, klasse! Ich komme nur leider in den nächsten Tagen wohl nicht zum Testen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Mai 2017, 10:29:50
Hallo zusammen,

die Version 4.14.0 enthält nun einen UserExit mit dem Benutzer eigenen Code zur Auführung bringen können (im ersten Beitrag).
Die Schnittstelle wird über das Attr "userExitFn" eingeschaltet und funktioniert OHNE Events und ist dazu geeignet Ergebnisse von  DbRep weiterzubearbeiten die sonst wegen der zu hohen Eventgenerierung das System zu sehr belasten würden.

Hier die Zusammenfassung der geplanten Commandref und ein konkretes Beispiel wie es sich im Wiki wiederfinden soll.


Commandref

* '''userExitFn'''  : stellt eine Schnittstelle zur Ausführung eigenen Usercodes zur Verfügung

Um die Schnittstelle zu aktivieren, wird zunächst die aufzurufende Subroutine in 99_myUtls.pm nach folgendem Beispiel erstellt:

sub UserExitFunction {
 my ($name,$reading,$value) = @_;
 my $hash = $defs{$name};
 ...
 # z.B. übergebene Daten loggen
 Log3 $name, 1, "UserExitFn $name called - transfer parameter are Reading: $reading, Value: $value " ;
 ...

return;
}

Die Aktivierung der Schnittstelle erfogt durch Setzen des Funktionsnames im Attribut.
Optional kann ein Reading:Value Regex als Argument angegeben werden. Wird kein Regex angegeben, sind alle Wertekombinationen wahr (entspricht .*:.*).

 Beispiel:
 attr <device> userExitFn UserExitFunction .*:.*
 # "UserExit" ist die Subroutine in 99_myUtils.pm. Die Routine wird bei jeder Reading/Value Kombination aufgerufen.

Grundsätzlich arbeitet die Schnittstelle OHNE Eventgenerierung. Sofern das Attribut gesetzt ist, erfolgt Die Regexprüfung NACH der Erstellung eines Readings. Ist die Prüfung WAHR, wird die angegebene Funktion aufgerufen.
Zur Weiterverarbeitung werden der aufgerufenenen Funktion die folgenden Variablen übergeben:

* $hash - der Hash des DbRep-Devices
* $reading - der Namen des erstellen Readings
* $value - der Wert des Readings

---------------------------------------------------------------------------------------------------------------------------

Wiki-Beitrag

=== finden von alten Devices in der DB und versenden/loggen einer Negativliste ===

Wenn eine Datenbank längere Zeit gelaufen ist, Devices in FHEM hinzugefügt, geändert oder gelöscht wurden oder auch das DEF des DbLog-Devices angepasst wurde, werden sich aller Wahrscheinlichkeit nach Datensätze von Devices in der DB finden die nicht mehr gewünscht sind.

Dieses Beispiel soll einen Weg zeigen wie man mit Hilfe der DbRep-sqlCmd Funktion (ab Version 4.14.0) alle in der DB enthältenen Devicenamen ermitteln und mit einer Positivliste vergleichen kann.
Die Negativliste der der nicht gewünschten Devices wird im Logfile ausgegeben bzw. mit TelegramBot versendet.

Zunächst wird das Device wieder wie im Abschnitt [[#Definieren_eines_DbRep-Devices | "Definieren eines DbRep-Devices"]] beschrieben definiert.
Dadurch wird das DbRep-Device mit einem DbLog-Device assoziiert und mit der Datenbank des DbLog-Device verbunden. Alle weiteren Operationen werden mit dieser Datenbank durchgeführt. In diesem Beispiel heißt das DbRep-Device "Report" und das DbLog-Device "LogDB".

Nach der Definition setzen wir die Attribute:

attr Report event-on-update-reading state
 attr Report sqlResultFormat separated

Es werden nun nur noch Events für "state" generiert. Das Attribut "sqlResultFormat = separated" bewirkt, dass das Ergebnis des SQL-Statements zeilenweise mit Einzelreadings zur Verfügung gestellt wird.

Nun kann getestet werden ob die Abfrage grundsätzlich funktioniert. Dazu wird das benutzerspezifische Kommano "sqlCmd" verwendet.

set Report sqlCmd select device, count(*) from history group by DEVICE;
Es sollte nun eine entsprechende Anzahl von Readings erzeugt werden (Browserrefresh), die als Wert eine Kombination aus <Device>|<Anzahl Datensätze in DB> enthalten wie in der Abbildung (Anhang) ersichtlich.

Wenn das Ergebnis wie gewünscht vorliegen, wird nun die Benutzerschnittstelle aktiviert.

attr Report userExitFn NaDevs .*:.*
"NaDevs" ist die Funktion in 99_myUtils.pm die aufgerufen werden soll. Die Angabe des Regex ".*:.*" ist optional. Nähere Informationen zur der Funktionsweise sind in der [https://fhem.de/commandref_DE.html#DbRep Commandref] zu finden.

Die "Positivliste" der in der Datenbank erlaubten Devices wird für das Beispiel in dem Attribut "comment" für den späteren Vergleich als String angegeben. Es ist natürlich auch z.B. eine Ableitung der im DEF-Regex des zugeordneten DbLog-Devices enthaltenen Device-Definitionen vorstellbar, sodass immer der aktuelle Stand dieser Definition als Grundlage für den Vergleich herangezogen wird.

attr Report comment (sysmon|MyWetter|SMA_Energymeter|STP_5000|Cam.*)
Es sollen die Devices "sysmon", "MyWetter", "SMA_Energymeter", "STP_5000" und alle Cam-Devices in der DB enthalten sein.
Alle anderen gefundenen Devices sollen in der Negativliste verzeichnet werden.

Im weiteren Schritt wird die aufzurufende Funktion in der vorhandenen 99_myUtils.pm ergänzt.

############################################################################
# $Id: myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig $
#
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.

package main;

use strict;
use warnings;

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

# Enter you functions below _this_ line.

my @dna;

...

######################################################
########    Not allowed Devs in DB ermitteln
########          UserExitFn in DbRep           
######################################################
sub NaDevs {
 my ($name,$reading,$value) = @_;
 my $hash   = $defs{$name};
 
 # DB Namen ermitteln
 my $dbconn = $hash->{dbloghash}{dbconn};
 my $db = (split("=",(split(";",$dbconn))[0]))[1];
 
 # Liste der erlaubten Devices aus Attribut "comment" lesen
 my $adevs = AttrVal($name, "comment","-");
 
 if($reading eq "state" && $value eq "running") {
     # der Select wurde gestartet
     Log3 $name, 1, "UserExitFn called by $name - new Select has been startet. Allowed devices in database are: $adevs";
     @dna=();
     return;
 }
 
 my $d = (split("\\|",$value))[0];
 
 # das Selektionsergebnis bewerten und ggf. dem Ergebnisarray hinzufügen
 if ( $reading =~ m/SqlResultRow.*/ && $d !~ m/$adevs/) {
   push(@dna,$d."\n")
 }
 
 if ($reading eq "state" && $value eq "done") {
     # Ergebnis versenden bzw. loggen
     Log3 $name, 1, "UserExitFn called by $name - Devices not allowd found in $db: @dna";
     fhem("set teleBot message Devices are not allowed found in $db: \n @dna");
 }
 
return;
}

....
1;

Die Schnittstelle übergibt der aufgerufenen Funktion den Namen des DbRep-Devices, den Namen des erstellten Readings und dessen Wert.
Der Aufruf erfolgt nach jeder Readingserstellung. Die Schnittstelle arbeitet OHNE Eventgenerierung bzw. benötigt keine Events.
Über den Namen des DbRep-Devices kann auf dessen Hash zugegriffen werden bzw. über $hash->{dbloghash}{...} ebenfalls auf den Hash des angeschlossenen DbLog-Devices.

In der Funktion "NaDevs" wird der Device-Teilstring des erzeugten Readings mit dem Wertevorrat aus dem "comment"-Attribut verglichen und bei einem negativen Ergebnis der Negativliste @dna hinzugefügt.
Nach Abschluss der Operation (signalisiert durch Reading "state = done" wird die erzeugte Liste im Logfile ausgegeben bzw. ein TelgramBot-Device versendet.

VG
Heiko


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Mai 2017, 22:44:19
Guten Abend,

es gibt eine neue Version 4.15.0 (in #1).
Es wurde einiges an der Performanceschraube gedreht. Es sollten oft spürbar schneller Ergebnisse vorliegen.
Als Wildcard wird nun nur noch "%" verwendet. "_" wird nicht mehr als Wildcard ausgewertet.

Weiterhin gibt es bei fetchrows ein Limit der Ergebnizeilen von 1000 um den Browser und damit FHEMWEB nicht zu blockieren.
Man kann über das Attribut "limit" diesen Wert für seine Umgebung anpassen.

Die Version checke ich nach einigen weiteren Tests auch ein.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: crispyduck am 22 Mai 2017, 10:54:34
Hallo,

Hätte da mal eine Frage ob und wie sich mein Vorhaben mit DbRep realisieren lässt.

Ich möchte berechnen und darstellen wann meine Wärmepumpe mit wie viel Strom WW bereitet oder geheizt hat.

Hätte mir das wie folgt vorgestellt:
Aktueller Stromverbrauch der WP wird  alle 60 sec. von einem Modbus Zähler abgefragt und in die DB geschrieben.
Betrriebsstatus der Heizung wird ebenfalls alle 60 sec. abgefragt und bei Änderung aufgezeichnet.

Daraus lässt sich dann ja berechnen wie viel Strom pro Tag für WW und wie viel für Heizen verbraucht wurden.
Ausserdem lässt sich berechnen von wann bis wann mit wie viel Strom z.B. WW bereitet wurde.

Hätte dann gerne pro Tag einen Wert für WW erzeugung als auch einen für Heizen
Und die jeweiligen WW oder Heiz Phasen mit Start, Stop Zeit und verbrauchtem Strom.
Betriebsstunden für WW und Heizen ausrechnen wäre auch noch interessant.

Lässt sich das mit DbRep realisieren und macht es auch sinn das mit DbRep zu machen?

Danke,
Crispyduck
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Mai 2017, 19:52:11
Hallo crispyduck,

ja so etwas lässt sich realisieren. Ob das sinnvoll ist, hängt nicht zuletzt von den Alternativen ab die man noch hätte.

Was du beschrieben hast wird out-of-the-box nicht möglich sein. Es wird nötig sein eigene Berechnungsroutinen in der 99_myUtils zu erstellen.
Wie man eine Auswertung mit Berechnung prinzipiell machen kann, habe ich im Wiki hier https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschu%C3%9Feinspeisung beschrieben.

In dem Artikel geht es zwar um ein ganz anderes Thema (Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschußeinspeisung), aber um eine mögliche Vorgehensweise darzustellen ist es wahrscheinlich gut geeignet.

Jetzt zu deiner Aufgabenstellung, die ich versuche ohne alles genau durchdacht zu haben als  Ansatz eines Ablaufplanes zu beschreiben . Ich weiß natürlich nicht genau wie die Daten in der DB vorliegen und mutmaße auch etwas.

Zitat
Aktueller Stromverbrauch der WP wird  alle 60 sec. von einem Modbus Zähler abgefragt und in die DB geschrieben.
Betrriebsstatus der Heizung wird ebenfalls alle 60 sec. abgefragt und bei Änderung aufgezeichnet.

Wenn ich das richtig interpretiere, ist die Datenaufzeichnung alle 60s eine Momentanaufnahme der abgenommenen Leistung (W). 
Die WP bedient ja sowohl die Heizung als auch die WW-Erzeugung wenn ich das richtig sehe. Die Leistung müßte getrennt für die WW-Erzeugung und Heizung in der DB vorliegen damit es so funktioniert wie ich es mir überlegt habe.

Um die verbrauchte Energie zu errechnen, braucht man  noch die Laufzeiten für jedes Aggregat über den Tag.

Die Laufzeiten pro Tag lässt sich ermitteln, indem man "fetchrows" in einem DbRep1 mit geeigneten Einstellungen für device und reading ausführt. Die timestamp_begin und timestamp_ende setzt man günstig auf current_day_begin und current_day_end.

Man bekommt Reading/Values-Datensätze des ganzen Tages, die etwa so aussehen (hier ein Beispiel eines Bew-Melders):

2017-05-22_07-23-35__MelderGW1__state  motion    2017-05-22 18:10:44
2017-05-22_07-24-07__MelderGW1__state  noMotion  2017-05-22 18:10:44
2017-05-22_08-38-59__MelderGW1__state  motion    2017-05-22 18:10:44
2017-05-22_08-39-30__MelderGW1__state  noMotion  2017-05-22 18:10:44
2017-05-22_11-35-21__MelderGW1__state  motion    2017-05-22 18:10:44
2017-05-22_11-35-53__MelderGW1__state  noMotion  2017-05-22 18:10:44

Die Laufzeiten wäre also die Zeitspanne zwischen "motion" und "nomotion", bei dir entsprechend der Betriebsstatus der Heizung / WW-Bereitung.
Die Berechnung lagert man in eine eigene Routine in der myUtils aus und aktiviert die Schnittstelle dorthin mit dem Attribut "exitUserFn" im DbRep1-Device.
Dadurch wird jeder erzeugte Datensatz nacheinander der Routine übergeben. In der Routine müßte dann folgendes ausprogrammiert werden:

* wenn state (DbRep1) = running (kann über den übermittelten Hash ausgewertet werden ) -> Start Aufzeichnung der Perioden in einem Hash_Perioden
   -> Aufzeichung der selektierten Perioden (Readings/Werte wie oben im Beispiel)

* Aufzeichnung abschließen bei state(DbRep2) = done -> Selektionen sind abgeschlossen.

Nun den Hash_Perioden mit den Datensätzen nach folgendem Schema auswerten: 

Periode1:
* den Timestamp des Readings extrahieren und als Startpunkt merken (z.B. 2017-05-22_07-23-35__ ) wenn Heizung / WW an -> umwandeln in "2017-05-22 07:23:35"
* den Timestamp des Readings extrahieren und als Endepunkt merken (z.B. 2017-05-22_07-24-07__ ) wenn Heizung / WW aus -> umwandeln in "2017-05-22 07:24:07"
* die ermittelten Zeitgrenzen in Unixzeit wandeln, Differenz bilden (Laufzeit der Periode1) und merken.

   -> für diese Periode in einem DbRep2-Device programmtechnisch Attr timestamp_begin auf "2017-05-22 07:23:35" setzen und timestamp_end auf "2017-05-22
       07:24:07" -> mit set-Funktion "averageValue" den Durchschnittsverbrauch von WW bzw. Heizung für Periode1 ermitteln lassen. Im zweiten DbRep-Device wieder mit
       userExitFn wieder diese Routine aufrufen und das Ergebnis mit der Laufzeit der Periode1 mutliplizieren = Energieverbrauch von WW / Heizung in Periode1.

* den ermittelten Wert in einem Dummy zur Visualisierung setzen

Periode2:
* den Timestamp des Readings extrahieren und als Startpunkt merken (z.B. 2017-05-22_08-38-59__ ) wenn Heizung / WW an -> umwandeln in "2017-05-22 08:38:59"
* den Timestamp des Readings extrahieren und als Endepunkt merken (z.B. 2017-05-22_08-39-30__ ) wenn Heizung / WW aus -> umwandeln in "2017-05-22 08:39:30"
* die ermittelten Zeitgrenzen in Unixzeit wandeln, Differenz bilden (Laufzeit der Periode2) und merken.

   -> für diese Periode in einem DbRep2-Device programmtechnisch Attr timestamp_begin auf "2017-05-22 08:38:59" setzen und timestamp_end auf "2017-05-22
       08:39:30" -> mit set-Funktion "averageValue" den Durchschnittsverbrauch von WW bzw. Heizung für Periode1 ermitteln lassen. Im zweiten DbRep-Device wieder mit
       userExitFn wieder diese Routine aufrufen und das Ergebnis mit der Laufzeit der Periode2 mutliplizieren = Energieverbrauch von WW / Heizung in Periode2.

* den ermittelten Wert in einem Dummy zur Visualisierung setzen

Für weitere Perioden (Wertepaare im Hash_Perioden) genauso verfahren. Am Ende die Energiewerte der einzelnen Perioden addieren = Energieverbrauch des ganzen Tages bzw. die gemerkten Laufzeiten addieren = Betriebsstunden (Minuten) für jedes Gerät pro Tag. Diese Werte wieder in dem Dummy setzen.

Am Ende hast du:

* den Energieverbrauch für WW / Heizung pro Tag
* die Laufzeiten (WW- bzw. Heizungsphasen) mit den jeweiligen (gemerkten) Start- / Stopzeiten mit der verbrauchten Energie in diesem Zeitraum
* die Betriebstunden pro Tag über die Summierung der ermittelten Laufperioden

Ich habe diesen Plan mal eben schnell entwickelt um einen möglichen Weg aufzuzeigen. Er ist in der jetzigen Form wahrscheinlich auch nicht fehlerfrei und optimal aber könnte gut zum Ziel führen und alle deine Wünsche soweit abdecken. Du müßtest dich natürlich ein bisschen tiefer in die Programmierung einarbeiten für die userExit-Funktion in myUtils.

Ob das so ein Weg für dich wäre kannst du nur selbst beurteilen. In dem oben genannten Wikibeitrag kann man sich recht schön das Prinzip nochmal verdeutlichen.

viele Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: crispyduck am 23 Mai 2017, 07:07:32
Danke DS_Starter!!!

Das ist ja schon sehr ausführlich und gibt mir vorallem schon einen Ansatz.

Als alternative könnte ich mir momentan nur vorstellen das ich es bei jeder Änderung der Betriebsart eine Berechnung durch ein Notify trigger.

Die Idee dahinter ist eigentlich das ich beim erstellen der Readings theoretisch doch nichts berechnen müsste und die Berechnung des Tagesverbrauchs,... dann 1x in der Nacht machen könnte.

Der Wert des Zählers ist nicht die aktuelle Leistung, sondern der Verbrauchte Strom in kWh.

Lassen wir Heizen mal weg. (Ist jetzt ohnehin mal abgedreht  ;) )

Habe "theoretisch" Readings wie folgt:
StromHeizung:                   Betriebsart Heizung:
2347,35                               0                                       2017-05-22 11:55:00
2347,35                               2                                       2017-05-22 12:35:00
2350,22                               0                                       2017-05-22 12:48:00
2360,01                               2                                       2017-05-22 15:33:00
2362,13                               0                                       2017-05-22 15:47:00
....

Ich könnte bei jeder Änderung der Betriebsart ein Get an Strom Heizung senden um zeitgleiche Readings zu haben.  (Ist der Timestamp dann aber überhaupt gleich?) Zusätzlich gibt es für StromHeizung alle 60 sec ein Reading.

0 = Heizung aus, 2 = WW bereitung (1 wäre dann Heizen)

Zwischen 2 und 0 wird somit immer WW bereitet.

Timestamps bekomme ich also so wie du es bereits mit dem Bewegungsmelder beschrieben hast.

Verbrauch pro WW Bereitung wäre dann der SromHeizung Wert vom Timestamp 2 weniger dem Strom Heizung Wert vom Timestamp bei BetriebsartHeizung wieder 0.

Da die Timestamps der Readings aber nicht gleich sein werden, wie lässt sich das dann berechnen?

Oder lassen sich sonst eie zwei Readings miteinander verknüpfen?

Lg
Crispyduck

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 23 Mai 2017, 12:41:06
@crispyduck: Wenn Du das ganze in kleinere Teile zerteilen willst, wäre es möglich über userReadings z.B. den Stromverbrauch für die letzte Phase :WW,HZ,NA als userReading ablegen. Dieser findet sich dann auch in der Datenbank und kann es erleichtern Dauer und Stromverbräuche für eine Periode auszurechnen.

Ein Ansatz wäre jeweils ein userreading zu haben, dass den Stromverbrauch und die Dauer der letzten Phase (also bei Wechsel der Betriebsart ) zu speichern. Diese Readings können ja auch noch die Betriebsart mit beinhalten also z.B.

lastUsage WW 2.87 kw
lastDuration WW 13 min
...

Als Hilfe braucht man dann noch jeweils ein Reading um die letzte Betriebsart und den letzten Stand des Zählers beim Wechsel zu merken.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: crispyduck am 23 Mai 2017, 16:49:13
Hallo viegener,

Beim fertig schreiben meines letzten Posts kam mir ein ähnlicher Gedanke; könnte ein Dummy device "Warmwasser" machen welches die Readings "Zählerstand_WW_bereitung_start" und "Zählerstand_WW_bereitung_ende" hat.

Start und Endzeit ist dann der Timestamp des Readings und der Zählerstand das value.

Würde es auf jeden Fall vereinfachen.

Die Variante von DS_Starter habe ich jetzt erst ganz verstanden. Müsste eben statt "averageValue", "diffValue" verwenden und erspare mir das Multiplizieren.
In der Berechnung müsste man dann wohl auch noch Mitternacht als eventuelles Start oder Stop berücksichtigen.
Um den ganzen Tag zu erfassen lässt man es wohl besser irgendwann in der Nacht am Folgetag laufen und nimmt previous_day_begin und previous_day_end.

Könnte man dies dann eigentlich auch statt scheduled zu berechnen und in der DB zu speichern einfach ausführen wenn man es benötigt? Also mit timestamp_begin/end eines Tages von welchem man die genauen Werte wissen will?
Nachdem ich die Summe pro Tag aber ohnehin berechnen und für einen plot speichern will, muss ich es wohl ohnehin 1x pro Tag laufen lassen, um an den gesamt Verbrauch+Laufzeit pro tag zu kommen, da loggt man wohl die par werte am besten gleich mit?!

Danke,
Crispyduck
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Mai 2017, 18:37:45
Noch zur Ergänzung von viegeners Hinweisen ....

Zitat
Der Wert des Zählers ist nicht die aktuelle Leistung, sondern der Verbrauchte Strom in kWh.
Das macht es einfacher ...

Zitat
Müsste eben statt "averageValue", "diffValue" verwenden und erspare mir das Multiplizieren.
Richtig.

Zitat
in der Berechnung müsste man dann wohl auch noch Mitternacht als eventuelles Start oder Stop berücksichtigen.
In DbLog gibt es eine addlog-Funktion. Mit einem At kannst du dir damit immer z.B. um 00:00:00 und 23:59:59 einen definierten Messpunkt setzen.

Zitat
Könnte man dies dann eigentlich auch statt scheduled zu berechnen und in der DB zu speichern einfach ausführen wenn man es benötigt? Also mit timestamp_begin/end eines Tages von welchem man die genauen Werte wissen will?
Es geht natürliches alles Mögliche. Wichtig nur dass du die Rohwerte für jedwede Auswertung in der DB vorhältst. Dann kannst du später nach Herzenslust verschiedene Perioden auswerten, darstellen etc. In meinem weiter oben angegeben Beispiel will ich die Energiebilanz noch um einen Jahreswert ergänzen ... geht ja problemlos da die zugrunde liegenden Daten in der DB vorhanden sind.  Das ist in meinen Augen der primäre Vorteil einer DB und deswegen auch DbRep entstanden.

Probiere einfach mal verschiedene Varianten aus die viegener und ich dir als Anregung gegeben haben, dann wird bestimmt vieles klarer und du kannst dich an dein Ziel rantasten.
 
Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: crispyduck am 23 Mai 2017, 19:36:57
Danke, für all die Infos und Anregungen.

So wie du sagst, sind die Vorteile einer DB ja vorallem das man die werte gut auswerten kann.

Deine Energiebilanz gefällt mir sehr und ich hoffe das ich ähnliches mal für meine zukünftige Anlage hin bekomme.
(Gerade am eigenbau einer kleinen PV Überdachung mit StecaGrid WR)

Lg
Crispyduck
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Mai 2017, 22:40:42
@ All,

ich habe etwas weiter gebaut und das Attribut sqlResultFormat noch um "json" erweitert (Version 4.16.1 im ersten Beitrag).
D.h., das Ergebnis der sqlCmd-Funktion wird als JSON-kodierter Hash im Reading SqlResult ausgegeben und auch an die userExitFn übergeben.
Die Weiterverarbeitung kann dann in 99_myUtils etwa so erfolgen:

######################################################
########   Zugriff auf  Wert aus JSON formatiertes
########   SqlResult
########   (sqlResultFormat = json)   
######################################################
sub resfromjson {
 my ($name,$reading,$value) = @_;
 my $hash   = $defs{$name};

 if ($reading eq "SqlResult") {
     # nur Reading SqlResult ist JSON formatiert
     my $data = decode_json($value);

     foreach my $k (keys(%$data)) {
             
       # ab hier eigene Verarbeitung für jedes Element
       # z.B. Ausgabe jedes Element welches "Cam" enthält
       my $ke = $data->{$k};
       if($ke =~ m/Cam/i) {
           my ($res1,$res2) = split("\\|", $ke);
           Log3($name, 1, "$name - extract element $k by userExitFn: ".$res1." ".$res2);
       }
    }
 }
 
return;
}

WICHTIG ! : Es wird fhem.pl Version mindestens 14348 2017-05-22 20:25:06Z (also von gestern Abend) benötigt !

Jedes Hash-Element (Ergebnissatz von $value) setzt sich aus der laufenden Nummer des Datensatzes (=Key) und dessen Wert (Selektionsergebnis) zusammen.
Feedback und Testergebnisse wie immer gerne.

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Juni 2017, 23:04:51
Hallo miteinander,

ich habe in DbRep eine Backup/Dump-Funktion für MySQL implementiert. Version 5.0.1 im ersten Beitrag.

Hier die Funktionsbeschreibung:

Set-Kommandos
dumpMySQL  -  erstellt einen Dump der gesamten angeschlossenen MySQL-Datenbank.
                       Der Dump wird per default im log-Verzeichnis gespeichert. Das Zielverzeichnis kann mit dem
                       Attribut "dumpDir" verändert werden. Vor dem Dump kann eine Tabellenoptimierung  optional zugeschaltet werden.
                       Über weitere Attribute das Laufzeitverhalten der Funktion beeinflusst  werden um eine Optimierung bezüglich Performance und           
                       Ressourcenbedarf zu erreichen.               
                       Die für dumpMySQL relevanten Attribute sind "dumpComment", "dumpDir", "dumpMemlimit", "dumpSpeed ",
                       "dumpFilesKeep" und "optimizeTablesBeforeDump".
                       Das erzeugte Dumpfile <dbname>_<date>_<time>.sql" kann z.B. mit:
                        
                       mysql -u &lt;user&gt; -p &lt;dbname&gt; < &lt;filename&gt;.sql                         
                       auf dem MySQL-Server ausgeführt werden um die Datenbank aus dem Dump wiederherzustellen.

cancelDump  -  bricht einen laufenden Dump ab.


Attribute:
dumpComment        - User-Kommentar. Wird im Kopf des erzeugten Dumpfile eingetragen. 
 
dumpDir                 - Zielverzeichnis für dumpMySQL-File (default: "{global}{modpath}/log/").
 
dumpMemlimit        - erlaubter Speicherverbrauch für SQL-Script zur Generierungszeit (default: 100000 Zeichen).
 
dumpSpeed            - Anzahl der in einem Call abgerufenen Selects aus der Quelldatenbank (default: 10000).
                                Dieser Parameter hat direkten Einfluß auf die Laufzeit und den Ressourcenverbrauch zur Laufzeit.

dumpFilesKeep       - Es wird die angegeben Anzahl Dumpfiles im Dumpdir gelassen (default: 3). Sind mehr (ältere) Dumpfiles
                                 vorhanden, werden diese gelöscht nachdem ein neuer Dump erfolgreich erstellt wurde. Das globale
                                 Attribut "archivesort" wird berücksichtigt.

optimizeTablesBeforeDump  - wenn "1", wird vor dem Datenbankdump ein "optimize table" ausgeführt (default: 0). 
                                          Dadurch verlängert sich die Laufzeit des Dump. <br><br>
                                         
                                          Hinweis:
                                          Die Tabellenoptimierung führt zur Sperrung der Tabellen und damit zur Blockierung von
                                          FHEM falls DbLog nicht im asynchronen Modus (DbLog-Attribut "asyncMode") betrieben wird !

Viel Spaß beim Testen und gern wieder Feedback.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 06 Juni 2017, 10:13:58
Hallo Heiko,

danke für das neue Modul, bin am Testen auf einem kleinen RPI 1 mit einer großen Datenbank.
Das Timeout musste ich stark erhöhen, dumpspeed habe ich im Moment auf 1000.

Ich werde berichten....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 06 Juni 2017, 15:10:17
leider bekome ich beim Backup immer ein timeout. mal nach 200MB, mal nach 400MB, selbst, wenn ich das Timeout auf 9000
setze und die Zeilen reduziere. (nach ca. 2-3 Stunden)

Wenn ich aus mysql heraus direkt eine CSV-Datei schreibe, ist dieses Backup mit 2,8GB nach ca. 15 Minuten beendet.(Aber MySQL blockiert natürlich in dieser Zeit)

Dazu nutze ich im Moment diese beiden Devices, um es auch elegant verwalten zu können.
Im Moment habe ich noch keinen Ansatz zum debuggen, wo genau das Problem herrscht.

defmod mySqlBackup_DI DOIF ([[00:10]])\
({fhem("set dbrepBackup sqlCmd ".AttrVal("dbrepBackup","sqlExport",""))})\

und
defmod dbrepBackup DbRep myDbLogSQL
attr dbrepBackup userattr sqlExport
attr dbrepBackup dumpDir /mnt/usbstick
attr dbrepBackup dumpFilesKeep 5
attr dbrepBackup dumpMemlimit 10000
attr dbrepBackup dumpSpeed 1000
attr dbrepBackup sqlExport SELECT *\
FROM history\
INTO OUTFILE '/mnt/usbstick/fhemDB.bak.csv'\
FIELDS TERMINATED BY ','\
ENCLOSED BY '"'\
LINES TERMINATED BY '\n';;
attr dbrepBackup timeout 5000
attr dbrepBackup widgetOverride sqlExport:textField-long


imLog habe ich nur diesen Eintrag gefunden:

2017.06.06 10:02:01 1: Timeout for mysql_DoDump reached, terminated process 20411

Nachtrag1: in diesem Beispiel aktualisiert dbrepBackup den Status nicht zurück von "running" auf etwas anderem.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Juni 2017, 15:25:14
Hi Joe,

Der dumpSpeed ist einfach zu gering bzw. dauert zu lange. Ich habe ihn bei mir auf 1000000 gesetzt und dumpMemlimit ebenfalls höher, mindestens 10 x dumpSpeed. Bei mir 100 x dumpSpeed. Damit sind meine 1,5 GB plus Views in 160s durch. Bei dir werden nur 1000 Db-Zeilen pro Select gelesen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 06 Juni 2017, 16:20:21
Hallo Heiko,

Du hast halt Monster-Hardware ;-)
Wie gesagt, ich teste (bewußt) auf einem langsamen RPI1.

Da ich auf das Timeout gestoßen bin, habe ich angefangen, die Werte zu reduzieren.
Aktuell, mit den größeren Werten läuft es bisher seit einer Stunde problemlos.

Ich warte noch auf das Endergebnis und melde mich.


sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 07 Juni 2017, 09:10:44
Leider finde ich keine Einstellungen, mit denen das Backup auf dieser Hardware durchläuft.
2 Stunden und 500MB war bisher das maximum.
Ich verstehe aber auch noch nicht ganz, wie es zu dem timeout kommt.
Wenn ich die MySQL-Prozesse beobachte, wird immer schön eine Anfrage nach der anderen an MySQL übergeben, die Antwortzeiten sind dabei sehr schnell.
Leider hatte ich bisher zum Fehlerzeitpunkt noch nie einen Blick in der MySQL-Prozessliste...

Auf etwas schnellerer Hardware konnte ich das Backup jedoch problemlos erstellen!

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Juni 2017, 10:02:16
Morgen Joe,

Vermutlich muss man als Anwender für eine derartige Applikation eben auch angemessene Hardware einsetzen um akzeptabel damit arbeiten zu können. Wenn es nicht so wäre könnte man ein SAP-System auch auf einem Handy laufen lassen.  ;). Für zu schwache Client-Hardware muss man wahrscheinlich auf einer Server gestützte Variante ausweichen, so wie du es oben gezeigt hast.
Was man noch machen könnte, ist ohne Timeout zu arbeiten. Hatte ich bisher nicht gemacht damit die Prozesse nicht ewig rumliegen. Ich habe die Zeile jetzt nicht vor mir, ist aber am Anfang von DbRep_Main. Dort nur den BlockingCall etwas kürzen. Wie genau, steht im Wiki zu BlockingCall.
Aber wenn es derart lange auf dieser Hardware dauert macht es nicht wirklich Freude.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 07 Juni 2017, 10:07:31
Ich habe auch nicht UNBEDINGT die Notwendigkeit dafür...
Mir stellt sich nur die Frage, ob man meine Systemvariante von oben im Modul unterstützen könnte.
Dann kann man zwar für ca. 15 Minuten nichts in die DB inserten, aber das könnte man ja anderwertig lösen, indem man zB
set SQL reopen 900 (oder ähnliches) absetzt. (und natürlich den asynchronen Modus nutzt).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Juni 2017, 10:28:18
Na hast du doch schon mit dem Modul gelöst  ;)

Also ich denke man könnte so etwas unterstützen. Ist auch technisch nicht so das Problem.
Ein bisschen schwierig ist es m.M. dem Anwender die unterschiedlichen implementierten Varianten verständlich zu erläutern und voneinander abzugrenzen, welche Attribute nun ziehen usw. Das klappt dann auch nicht mit einer uniformen Recoverylösung an der ich gerade bastele.
Aber ich denk Mal mit darüber nach. Du könntest deine Lösung doch im Wiki zu DbRep Mal hinterlegen als Server seitige Variante, findest du nicht ?   8)

Grüße​
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Juni 2017, 22:50:13
Hi Joe, @all,

jetzt habe ich das Modul V.5.0.3 noch um eine serverseitige Dumpmöglichkeit mit "LOAD INTO FILE ..." ergänzt.
Dadurch ändern sich die Aufrufparameter von dumpMySQL. Wird nichts angegeben, wird "clientSite" ausgeführt.

Hier der Abriß:

dumpMySQL [clientSite | serverSite] - erstellt einen Dump der angeschlossenen MySQL-Datenbank.
Abhängig von der ausgewählten Option wird der Dump auf der Client- bzw. Serverseite erstellt.

clientSite
Der Dump wird durch den Client erstellt und per default im log-Verzeichnis des Clients gespeichert. Das Zielverzeichnis kann mit dem Attribut "dumpDir" verändert werden und muß auf dem Client durch FHEM beschreibbar sein. Vor dem Dump kann eine Tabellenoptimierung optional zugeschaltet werden. Über weitere Attribute kann das Laufzeitverhalten der Funktion beeinflusst werden um eine Optimierung bezüglich Performance und Ressourcenbedarf im zu erreichen.
Die für "dumpMySQL clientSite" relevanten Attribute sind "dumpComment", "dumpDir", "dumpMemlimit", "dumpSpeed ", "dumpFilesKeep" und "optimizeTablesBeforeDump".

Die Namenskonvention des Dumpfiles ist: <dbname>_<date>_<time>.sql

Das erzeugte Dumpfile kann z.B. mit:

    mysql -u <user> -p <dbname> < <filename>.sql

auf dem MySQL-Server ausgeführt werden um die Datenbank aus dem Dump wiederherzustellen.

serverSite
Der Dump wird durch den MySQL-Server erstellt und per default im Home-Verzeichnis des MySQL-Servers gespeichert. Es wird die gesamte history-Tabelle (nicht current-Tabelle) im CSV-Format ohne Einschränkungen exportiert.
Das Zielverzeichnis kann mit dem Attribut "dumpDir" verändert werden. Es muß sich auf dem MySQL-Host gefinden und durch den MySQL-Serverprozess beschreibbar sein.
Der verwendete Datenbankuser benötigt das "FILE"-Privileg.
Die Versionsverwaltung der erzeugten Exportfiles muß der Anwender durch geeignete Maßnahmen selbst übernehmen.

Die Namenskonvention des Dumpfiles ist: <dbname>_<date>_<time>.csv

Mit der serverseitigen Variante ist mein Backup in 42s durch (auf Synology).  :D (Naja, ist nun nur noch die history-Tabelle).
Damit hat man als User eigentlich alle Entscheidungsfreiheiten. Die Varianten unterscheiden sich ja auch hinsichtlich ihres Umfanges/Ergebnisses.

Schau mal ...

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 08 Juni 2017, 10:25:35
Hallo Heiko,

das Backup funktioniert toll, herzlichen dank dafür!

Durch die Integration bekomme ich auch besser mit, wann das Backup fertig ist, was eine tolle Sache ist.

Folgendes ist mir aufgefallen:
1. Cancel Dump funktioniert nicht, es läuft einfach weiter (was mich nich tbesonders stört, ist halt aufgefallen).
2. sollte serverSite nicht serverSide heißen?
3.
Die Versionsverwaltung der erzeugten Exportfiles muß der Anwender durch geeignete Maßnahmen selbst übernehmen.Das finde ich schade... würde hier nicht der selbe code greifen wie beim clientseitigen backup? Aus Speicherplatzgründen muss ich das Backup auf 3 files beschränken.

Einen Wunsch hätte ich nocht: können wir ein Attribut ähnlich wie "execute_before" und "execute_after" erlauben? dann könnte ich darüber
aufräumarbeiten machen und/oder anschließend eine Telegram-Nachricht zur Bestätigung verschicken.
Im Moment mache ich das einfach im aufrufenden DOIF, was auch funktioniert. Ich darf nur den Befehl
set dbRep dumpMySQL  serversite nicht direkt ausführen, da dann meine synology noch nicht gestartet ist (WOL) und das Zielverzeichnis somit noch nicht zur Verfügung steht.

Ein Traum wäre, dumpFilesKeep zu berechnen über den aktuell freien Speicherplatz (am usb-stick) unter zuhilfenahme der größe des letzten Backups plus einem Buffer von xMB's,
aber vermutlich ist das aktuell auch besser in einem aufrufenden Script oder eben in "execute_before" abzudecken...

schöne Grüße
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Juni 2017, 10:43:42
Hi Joe,

Ja klar, cancelDump funktioniert nicht, weil einmal auf dem Server angstossen läuft es halt los. Muss ich rausnehmen.

Side ist natürlich richtig, das ändere ich ab.

Bezüglich der Versionsverwaltung klappt derselbe Code nur wenn du das Serververzeichnis auf dem Client gemountet hast und der dann auch so wie auf den Server heißt. Sonst braucht es ein weiteres Attribut um das zu steuern. Wie ich sagte ...  es wird immer komplexer.

Das mit den execution before und after ist eine tolle Idee, Versuche ich Mal mit vorzusehen.

Wenn dir / euch bezüglich der Versionsverwaltung auf serverSide etwas brauchbares einfällt gerne als Zuarbeit ....

VG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 08 Juni 2017, 11:13:54
Ja klar, cancelDump funktioniert nicht, weil einmal auf dem Server angstossen läuft es halt los. Muss ich rausnehmen.
Man könnte den Prozess killen, indem man sich die ProzessID merkt, aber ich denke, darauf kann verzichtet werden.


Wenn dir / euch bezüglich der Versionsverwaltung auf serverSide etwas brauchbares einfällt gerne als Zuarbeit ....

Bei mir ist es am selben Server, weswegen die Bereinigung auch funktionieren würde.
Im Moment finde ich es eher verwirrend, dass es angeboten wird, dann aber nicht funktioniert. Auf die Begründung mit dem externen Server bin ich von selbst nicht gekommen.
Idee: Es einfach zu versuchen, die Datei zu löschen. Wenns sie nicht da ist, eine Fehlermeldung in ein Reading. Dann gibts auch keine Rückfragen über "dumpFilesKeep funktioniert nicht"

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Juni 2017, 17:12:33
Hallo zusammen,

jetzt hab eich noch einiges in der V5.0.4 geändert.
Auch die Attribute haben sich geändert und erweitert damit nun auch die Versionsverwaltung für servierSide Backups funktioniert.
Es können auch Kommandos vor/nach dem Backup ausgeführt werden.

Bitte lest die geänderte Doku:

dumpMySQL [clientSide | serverSide]
- erstellt einen Dump der angeschlossenen MySQL-Datenbank.
Abhängig von der ausgewählten Option wird der Dump auf der Client- bzw. Serverseite erstellt.
Die Varianten unterscheiden sich hinsichtlich des ausführenden Systems, des Erstellungsortes, der Attributverwendung und des erzielten Ergebnisses.

clientSide
Der Dump wird durch den Client (FHEM-Rechner) erstellt und per default im log-Verzeichnis des Clients gespeichert. Das Zielverzeichnis kann mit dem Attribut "dumpDirLocal" verändert werden und muß auf dem Client durch FHEM beschreibbar sein.
Vor dem Dump kann eine Tabellenoptimierung ("optimizeTablesBeforeDump") oder ein FHEM-Kommando ("executeBeforeDump") optional zugeschaltet werden .
Nach dem Dump kann ebenfalls ein FHEM-Kommando (siehe "executeAfterDump") ausgeführt werden.
Über weitere Attribute kann das Laufzeitverhalten der Funktion beeinflusst werden um eine Optimierung bezüglich Performance und Ressourcenbedarf zu erreichen.
Die für "dumpMySQL clientSide" relevanten Attribute sind "dumpComment", "dumpDirLocal", "dumpMemlimit", "dumpSpeed ", "dumpFilesKeep", "executeBeforeDump", "executeAfterDump" und "optimizeTablesBeforeDump".
Nach einem erfolgreichen Dump werden alte Dumpfiles gelöscht und nur die Anzahl "dumpFilesKeep" (default: 3) verbleibt im Zielverzeichnis "dumpDirLocal".

Die Namenskonvention der Dumpfiles ist: <dbname>_<date>_<time>.sql

Das erzeugte Dumpfile kann z.B. mit:

    mysql -u <user> -p <dbname> < <filename>.sql

auf dem MySQL-Server ausgeführt werden um die Datenbank aus dem Dump wiederherzustellen.

serverSide
Der Dump wird durch den MySQL-Server erstellt und per default im Home-Verzeichnis des MySQL-Servers gespeichert.
Es wird die gesamte history-Tabelle (nicht current-Tabelle) im CSV-Format ohne Einschränkungen exportiert.
Die für "dumpMySQL serverSide" relevanten Attribute sind "dumpDirRemote", "dumpFilesKeep", "executeBeforeDump", "executeAfterDump" und "dumpDirLocal".
Vor und nach dem Dump kann ein FHEM-Kommando (siehe "executeBeforeDump", "executeAfterDump") ausgeführt werden.

Das Zielverzeichnis kann mit dem Attribut "dumpDirRemote" verändert werden. Es muß sich auf dem MySQL-Host gefinden und durch den MySQL-Serverprozess beschreibbar sein.
Der verwendete Datenbankuser benötigt das "FILE"-Privileg.
Soll die interne Versionsverwaltung des Moduls genutzt werden, ist das Verzeichnis "dumpDirRemote" des MySQL-Servers auf dem Client zu mounten und im Attribut "dumpDirLocal" dem DbRep-Device bekannt zu machen.

    Beispiel:
    attr <DbRep-device> dumpDirRemote /volume1/ApplicationBackup/dumps_FHEM/
    attr <DbRep-device> dumpDirLocal /sds1/backup/dumps_FHEM/
    attr <DbRep-device> dumpFilesKeep 2
    # Der Dump wird remote auf dem MySQL-Server im Verzeichnis '/volume1/ApplicationBackup/dumps_FHEM/' erstellt.
    # Die interne Versionsverwaltung sucht im lokal gemounteten Verzeichnis '/sds1/backup/dumps_FHEM/' vorhandene Dumpfiles und löscht diese bis auf die zwei letzten Versionen.

Wird die interne Versionsverwaltung genutzt, werden nach einem erfolgreichen Dump alte Dumpfiles gelöscht und nur die Anzahl "dumpFilesKeep" (default: 3) verbleibt im Zielverzeichnis "dumpDirRemote". FHEM benötigt in diesem Fall Schreibrechte auf dem Verzeichnis "dumpDirLocal".

Die Namenskonvention der Dumpfiles ist: <dbname>_<date>_<time>.csv

EDIT: hier noch etwas zu den Attributen.

executeAfterDump - Es kann ein FHEM-Kommando angegeben werden welches nach dem Dump ausgeführt werden soll.
Funktionen sind in {} einzuschließen.

    Beispiel:

    attr <DbRep-device> executeAfterDump set og_gz_westfenster off;
    attr <DbRep-device> executeAfterDump {adump ("<DbRep-device>")}
    # "adump" ist eine in 99_myUtils definierte Funktion.



executeBeforeDump - Es kann ein FHEM-Kommando angegeben werden welches vor dem Dump ausgeführt werden soll.
Funktionen sind in {} einzuschließen.

    Beispiel:

    attr <DbRep-device> executeBeforeDump set og_gz_westfenster on;
    attr <DbRep-device> executeBeforeDump {bdump ("<DbRep-device>")}
    # "bdump" ist eine in 99_myUtils definierte Funktion.

dumpDirLocal - Zielverzeichnis für die Erstellung von Dumps mit "dumpMySQL clientSide". default: "{global}{modpath}/log/" auf dem FHEM-Server.

dumpDirRemote - Zielverzeichnis für die Erstellung von Dumps mit "dumpMySQL serverSide". default: das Home-Dir des MySQL-Servers auf dem MySQL-Host
--------------

Probierts mal bitte wieder aus und Feedback wie immer gerne.

Grüße
Heiko
 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Juni 2017, 17:55:06
Noch ein kleiner Tipp.
Für die Benachrichtigung nach einem Backup eignet sich die userExitFn besser als eine Funktion mit "executeAfterDump".
Der Grund liegt darin, dass man den mit der userExitFn auch den Status der ausgeführten "executeAfterDump"-Funktion mit erhält.

Es ist einfach zu realisieren. Einfach in dem DbRep-Device, welches man für das Backup benutzt das Attribut:

attr <Device > userExitFn doafterdump
setzen. "doafterdump" ist eine Funktion die man in der 99_myUtils.pm definiert hat.
Beispielsweise so:

############################################################################################################
########       Aktion nach einem Backup     
############################################################################################################
sub doafterdump {
 my ($name,$reading,$value) = @_;
 my $hash   = $defs{$name};
 my $dbname = $hash->{DATABASE};
 
 if ($name =~ m/Rep.Fhem.*Dump/) {
   if ($reading = "state" && ReadingsVal($name,"state",'') =~ m/Database.*backup.*finished/) {
        my $dev = 'Device: '.$name.'\n';
        my $dfc = 'DumpFileCreated: '.ReadingsVal($name, "DumpFileCreated", '').'\n';
        my $dfd = 'DumpFilesDeleted: '.ReadingsVal($name, "DumpFilesDeleted", '').'\n';
my $rc  = 'DumpRowsCurrrent: '.ReadingsVal($name, "DumpRowsCurrrent", '').'\n';
my $rh  = 'DumpRowsHistory: '.ReadingsVal($name, "DumpRowsHistory", '').'\n';
my $bt  = 'Laufzeit: '.sprintf("%.0f",ReadingsVal($name, "background_processing_time", '')).' Sekunden\n';
        my $dfs = 'Status: '.ReadingsVal($name, "state", '').'\n';
 
        DebianMailnbl('<Empfänger>',
        'Dump '.$dbname.' beendet', 'Datenbank Dump ist beendet:\n\n'.$dev.$dfc.$dfd.$rc.$rh.$bt.$dfs.'\n\\nFHEM-Server' );
   }
 }
 
return;
}

DebianMailnbl ist wiederum eine selbst definierte Funktion die einen Mailversand non-blocking vornimmt. Aber das Ganze soll nur als Anregung und Beispiel dienen. Man kann dort natürlich beliebige Funktionen hinterlegen.
Der Regex "$name =~ m/Rep.Fhem.*Dump/" filtert die Funktion für Nur-Dump-DbRep-Devices. Kann auch entfallen sofern die userExitFn ohnehin nur in diesen DbRep-Devs aktiviert ist.

Die empfangene Email sieht dann so aus wie im Anhang.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 Juni 2017, 09:23:19
Hallo Heiko,

kannst Du etwas aus dieser Fehlermeldung lesen?
Too many arguments for main::deldumpfiles at ./FHEM/93_DbRep.pm line 4500, near "$bfile)"
BEGIN not safe after errors--compilation aborted at ./FHEM/93_DbRep.pm line 4876.
Ich würde davon ausgehen, dass ich irgendein Attribut löschen sollte, aber welches?

Auch bei einem neuen (leeren) Device bekomme ich diesen Fehler.

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juni 2017, 09:26:47
Morgen Joe,

da hat sich etwas in der Struktur des Codes geändert. Wenn du so etwas liest, egal welches Modul -> immer restart. Das sollte dieses Problem lösen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 Juni 2017, 10:41:03
Guten morgen, sorry,

eigentlich restarte ich immer,  hätte ich mir auch denken können ;-)
Sorry!

Den Rest habe ich getestet! Das Backup wird korrekt erstellt! Aufgefallen ist mir folgendes:

1. Als "state" bekomme ich nach genau  1 Minute  "database backup timed out", was beim Serverseitigen Backup nicht viel Sinn macht?!? Das Backup wird jedenfalls trotzdem erstellt.
2017.06.12 09:08:45 3: DbRep mySqlBackup - Starting dump of database 'fhem', table 'history'.
2017.06.12 09:09:45 1: Timeout for mysql_DoDumpServerSide reached, terminated process 22387
2017.06.12 09:09:45 1: DbRep mySqlBackup -> BlockingCall  timed out
2017.06.12 09:09:45 3: DbRep mySqlBackup - Database dump aborted with timeout !
2. Optimize_Table funktioniert bei serverseitigem Backup nicht. Gibt es dafür einen speziellen Grund? Der Befehl könnte doch auch hier direkt abgesetzt werden?!, sogar als kombinierter Befehl mit dem export...
3. Das Löschen über "dumpFilesKeep=1" habe ich nicht hinbekommen.
Ich habe dazu "dumpDirLocal" und "dumpDirRemote" auf das selbe Verzeichnis gestellt, da es bei mir lokal ja "per definition" das selbe Verzeichnis ist.
Die Berechtigungen sollten korrekt sein, im Logfile finde ich auch mit Verbose5 keinen Eintrag mehr nach dem Timeout aus Punkt1, vielleicht hängt dies zusammen?
   
Bleiben mir noch 1 Wunsch:
1. Ich bräuchte eine Option, die die Backupdateien vor dem Backup löscht (statt nachher) ( da mein USB-Stick immer recht voll wird, sollte das älteste Backup früher gelöscht werden)



herzlichen Dank, beste Grüße
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juni 2017, 10:58:58
Setz dir das Timeout Attribut einfach auf einen hohen Wert. Ich möchte nur nicht dass der  geforkte  Prozess ewig rumliegt. Ja, die fehlende Löschung hängt damit zusammen.

Optimize  table hatte ich in dieser Version noch nicht eingebaut. In der nächsten Version, die ich schon fertig habe, ist das auch bei serverSide mit dabei. Will nur noch die Commandref fertig stellen, dann kopiere ich diese V hier rein.

Das vorherige Löschen habe ich extra nicht eingebaut weil man ja nicht weiß ob das Backup erfolgreich beendet wird.
Kommst du nicht damit klar  wenn du dumpFilesKeep  um 1 reduziert ?

Edit: man diese sch... Wortergänzung ....
Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 Juni 2017, 12:05:55
1. ok, mein Timeout war einfach zu kurz....
2. Danke :D
3: hm, anders herum hätte ich halt während der Woche immer ein Backup mehr auf dem Stick zur verfügung, aber ja, auch das habe ich versucht und damit kann ich sicher leben!
3b: Hinweis: dumpFilesKeep löscht die Dateien, wenn ich das Timeout aus #1 hoch genug setze.

Schöne Grüße
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juni 2017, 12:09:18
 :)

Habe die finale Version vllt. Heute Abend mit der Commandref fertig ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 Juni 2017, 14:09:24
Sorry, noch ein Wunsch ist mir aufgefallen: Wäre es möglich, ein Reading mit der Größe des Backups zu erzeugen? Das würde ich gerne mitloggen und auch auswerten, um zu sehen, ob die Größe mal besonders abweicht oder die Datei zu klein ist.
... Ist aber nur ein Wunsch, ich könnte das im Moment sicher executeAfter erreichen....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juni 2017, 14:38:54
Ja dann wars  wieder nichts mit finaler Version  ;) ... Ich schau mal ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Juni 2017, 22:41:06
Hallo Joe, @all,

hier ist nun die Version 5.0.5 (erster Beitrag).
Ich habe noch die Ausgabe der Dumpfile-Länge als Reading (DumpFileCreatedSize) hinzugefügt für beide dumpMySQL-Varianten. Für serverSide ist nun auch "optimizeTablesBeforeDump" verfügbar.

Die Commandref ist auch erstellt. Du kannst sie dir lokal generieren mit:

cd /opt/fhem
sudo perl contrib/commandref_join.pl

Dann ist sie über den Commandref-Link (links im FHEMWEB) lokal aufrufbar.
Ich hoffe man kann die Handhabung beider Varianten auch als Anwender gut auseinanderhalten / verstehen und weiß wie man die einzelnen Attribute einsetzen muß.

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Juni 2017, 09:52:36
Hallo Heiko,

danke für die Version.
"optimizeTablesBeforeDump" scheint noch nicht ganz zu funktionieren, im Log finde ich lediglich:
2017.06.13 08:47:48 3: DbRep mySqlBackup - Table 1 `current` optimized successfully.
2017.06.13 08:47:48 3: DbRep mySqlBackup - 1 tables have been optimized.
2017.06.13 08:47:48 3: DbRep mySqlBackup - Starting dump of database 'fhem', table 'history'.
2017.06.13 08:47:48 5: DbRep mySqlBackup - Use Outfile: /tmp/fhem_history_2017_06_13_08_47.csv
, was mich vermuten lässt dass eben nur "current" und nicht "history" optimiert wird. "current" ist bei mir gar nicht in verwendung.
Aufgefallen ist mir eben auch, dass es "zu schnell" geht, weshalb ich vermutete, dass die Optimierung nicht stattfindet.

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juni 2017, 10:07:58
Hi Joe,

Klappt bei mir einwandfrei. Aber bei dir sieht es mir auch komisch aus. Knipps Mal verbose 5 an.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Juni 2017, 10:11:48
Hab ich! Oben im Log sind Verbose5 Einträge enthalten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juni 2017, 10:25:30
Mit verbose 5 kommt bei mir viel mehr. Kann ich jetzt nicht kopieren mit meinem Mobilteil.
Aber da passt etwas nicht. Das ist bestimmt kein verbose 5, sehe auch nur v3 Einträge.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juni 2017, 10:31:53
Sorry, hab Tomaten auf den Augen.
Hmmm, komisch.  Welche Engine  hat denn deine history ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Juni 2017, 10:36:38
Hier der ganze Block aus dem Log.
Aria aus MariaDB.

3: DbRep mySqlBackup - ################################################################
3: DbRep mySqlBackup - ###          New database serverSide dump                    ###
3: DbRep mySqlBackup - ################################################################
4: DbRep mySqlBackup -> Start BlockingCall mysql_DoDumpServerSide
5: DbRep mySqlBackup - current query: SHOW TABLE STATUS FROM `fhem`
3: DbRep mySqlBackup - Searching for tables inside database fhem....
5: DbRep mySqlBackup - ......... Table definition found: .........
5: DbRep mySqlBackup - Avg_row_length: 82
5: DbRep mySqlBackup - Check_time: 2014-11-12 13:08:35
5: DbRep mySqlBackup - Collation: latin1_swedish_ci
5: DbRep mySqlBackup - Comment:
5: DbRep mySqlBackup - Create_options:
5: DbRep mySqlBackup - Create_time: 2014-10-12 10:08:40
5: DbRep mySqlBackup - Data_free: 112
5: DbRep mySqlBackup - Data_length: 34264
5: DbRep mySqlBackup - Engine: MyISAM
5: DbRep mySqlBackup - Index_length: 1024
5: DbRep mySqlBackup - Max_data_length: 281474976710655
5: DbRep mySqlBackup - Name: current
5: DbRep mySqlBackup - Row_format: Dynamic
5: DbRep mySqlBackup - Update_time: 2014-11-20 15:35:51
5: DbRep mySqlBackup - Version: 10
5: DbRep mySqlBackup - ......... Table definition END ............
5: DbRep mySqlBackup - ......... Table definition found: .........
5: DbRep mySqlBackup - Avg_row_length: 90
5: DbRep mySqlBackup - Check_time: 2017-03-16 12:28:17
5: DbRep mySqlBackup - Collation: latin1_bin
5: DbRep mySqlBackup - Comment:
5: DbRep mySqlBackup - Create_options: partitioned
5: DbRep mySqlBackup - Create_time: 2017-03-14 11:49:56
5: DbRep mySqlBackup - Data_free: 0
5: DbRep mySqlBackup - Data_length: 1423007744
5: DbRep mySqlBackup - Engine: Aria
5: DbRep mySqlBackup - Index_length: 651214848
5: DbRep mySqlBackup - Max_data_length: 0
5: DbRep mySqlBackup - Name: history
5: DbRep mySqlBackup - Row_format: Page
5: DbRep mySqlBackup - Update_time: 2017-06-13 07:58:35
5: DbRep mySqlBackup - Version: 10
5: DbRep mySqlBackup - ......... Table definition END ............
3: DbRep mySqlBackup - Optimizing tables
3: DbRep mySqlBackup - Optimizing table `current` (MYISAM). It will take a while.
3: DbRep mySqlBackup - Table 1 `current` optimized successfully.
3: DbRep mySqlBackup - 1 tables have been optimized.
3: DbRep mySqlBackup - Starting dump of database 'fhem', table 'history'.
5: DbRep mySqlBackup - Use Outfile: /tmp/fhem_history_2017_06_13_08_47.csv
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juni 2017, 10:43:33
Ach ja stimmt ja, alles klar  ;). My fault ..... Muß die Engine noch  im Code berücksichtigen.
Mach ich heute Abend. Wenn du es eilig hast such Mal nach einer Subroutine optimizetable ... Dort siehst du eine IF mit Engine, einfach Aria hinzufügen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juni 2017, 18:09:52
Hallo Joe,

habe in der V5.0.6 die Aria-Engine ergänzt.
Probier mal, sollte nun alles klappen wie es soll.

EDIT: Jetzt habe ich gleich die V5.1.0 angehängt. Es wird im Ergebnis von "fetchrows" die Spalte "UNIT" mit berücksichtigt (sofern etwas enthalten ist).
Ich denke das ist ein gutes Feature.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 14 Juni 2017, 11:44:29
Hallo Heiko,

hat funktioniert!
Das einzige, was mich etwas wundert(oder auch nicht!) ist dieser Eintrag imLog:

Das liegt sicher am "cacheLimit=302", aber ist es wirklich gut/hilfreich, hier mehrmals pro Sekunde während dem Backup
zu versuchen, einen Datensatz zu schreiben? Dies betrifft aber wohl eher DbLog.


2017.06.14 09:56:34 3: DbRep rep - Database dump finished successfully.
2017.06.14 09:56:34 4: DbRep rep -> BlockingCall DumpDone finished
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:54:19, Device: log, Event: CacheUsage: 304
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:54:19, Device: log, Event: CacheUsage: 306
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:54:19, Device: log, Event: CacheUsage: 308
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:14, Device: log, Event: CacheUsage: 314
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:14, Device: log, Event: CacheUsage: 316
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:18, Device: log, Event: CacheUsage: 320
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:18, Device: log, Event: CacheUsage: 322
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:18, Device: log, Event: CacheUsage: 324
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 328
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 330
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 332
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:19, Device: log, Event: CacheUsage: 334
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:20, Device: log, Event: CacheUsage: 338
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:22, Device: log, Event: CacheUsage: 344
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:22, Device: log, Event: CacheUsage: 346
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:55:22, Device: log, Event: CacheUsage: 348
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 352
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 354
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 356
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:18, Device: log, Event: CacheUsage: 358
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 362
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 364
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 366
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:19, Device: log, Event: CacheUsage: 368
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:20, Device: log, Event: CacheUsage: 372
2017.06.14 09:56:51 3: DbLog log -> Failed to insert into history - TS: 2017-06-14 09:56:21, Device: log, Event: CacheUsage: 376
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Juni 2017, 12:43:31
Hi Joe,

Naja DbLog macht halt das was du ihm gesagt hast, nämlich bei Überschreitung von cacheLimit versuchen wegzuschreiben. Das erfolgt eventgesteuert, nicht zeitgesteuert.

Ich würde DbLog im produktiven Betrieb mit verbose 2 betreiben, dann kommen nur die "echten" Probleme hoch.

Dann werde ich das neue DbRep mal einchecken ...

Edit: du kannst auch mit executeBefore / executeAfter das Attribut cacheLimit vom DbLog-Device während des Backup abändern.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 14 Juni 2017, 13:43:00
Naja DbLog macht halt das was du ihm gesagt hast,...
Darum so vorsichtig formuliert... es ging mir mehr um die Sinnhaftigkeit... ;-)

Edit: du kannst auch mit executeBefore / executeAfter das Attribut cacheLimit vom DbLog-Device während des Backup abändern.
Korrekt!Mir schwebt aber eine globale Info über "db temporär nicht verfügbar" vor, sei es als Reading oder als globale Variable,
denn darauf würde ich zB gerne auch im Plot-Modul oder anderen Modulen reagieren.
Wennd ie DB gerade blockiert wird, macht das ewige Warten auf Plots einfach keinen Sinn, und selbst wenn man in FHEM in einen Raum ohne Plots wechselt,
bleibt der FHEM-Server blockiert oder zumindest stark ausgelastet...
Aber das ist, wie oben gesagt, eher ein Thema für den DbLog-Thread.....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Juni 2017, 13:53:20
So ein Reading kannst du dir über die Nutzung der userExitFn erstellen. Hier kann man z.B. verschiedene Status des DbRep und/oder DbLog-Device verknüpfen um sich ein "Tabelle ist geblockt" Status abzuleiten und als Reading zu setzen.
Nur Mal als Idee ohne es genau durchdacht zu haben ..,
Können wir in dem anderen Thread Mal diskutieren.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2017, 00:01:48
Hallo zusammen,

im ersten Beitrag habe ich die V5.3.0 hinterlegt.
Für MySQL kann "optimizeTable" als separater Befehl ausgeführt werden. Das verbundene DbLog-Device sollte im asynchronen Modus betrieben werden um FHEM nicht zu blockieren.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2017, 22:48:46
Mit der V5.3.1 gibt es nun ebenfalls für SQLite und PostgreSQL die Möglichkeit die Datenbank zu optimieren (vacuum).
Auch in diesem Fall muß das verbundene DbLog-Device im asynchronen Modus betrieben werden um FHEM nicht zu blockieren.
Die Commandref ist ergänzt.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Juli 2017, 23:35:44
In der Version 5.4.0 kann ein Restore (restoreMySQL) einer mit "dumpMySQL serverSide" erstellten Sicherung durchgeführt werden.
Die Funktion enthält eine Dropdown-Liste, welche die gefundenen Dateien im Verzeichnis gegeben durch Attribut "dumpDirLocal" enthält. Es werden nur die Dumpdateien der "eigenen" verbundenen Datenbank (Internal DATABASE) angezeigt.
Das Attribut  "dumpDirLocal" muß in diesem Fall das gemountete Verzeichnis des MySQL/MariaDB-Servers enthalten in dem die Dumps erstellt werden.
Es entspricht den empfohlenen Einstellungen für "dumpMySQL serverSide".

Das verwendete Verfahren ist sehr schnell. Bei meinen Versuchen wurde die DB (nur Tabelle history) mit ca. 2,8 Mio Datensätzen in 14s exportiert und innerhalb von 136s wieder importiert.

2017.07.03 21:00:34.894 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:00:34.895 3: DbRep Rep.LogDB1 - ###             New database serverSide dump                 ###
2017.07.03 21:00:34.895 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:00:34.907 3: DbRep Rep.LogDB1 - Searching for tables inside database fhemtest1....
2017.07.03 21:00:34.950 3: DbRep Rep.LogDB1 - Starting dump of database 'fhemtest1', table 'history'.
2017.07.03 21:00:48.957 3: DbRep Rep.LogDB1 - Finished backup of database fhemtest1, total time used: 14 sec.
2017.07.03 21:00:48.957 3: DbRep Rep.LogDB1 - Size of backupfile: 305.54 MB
2017.07.03 21:00:48.961 3: DbRep Rep.LogDB1 - Deleting old dumpfile 'fhemtest1_history_2017_07_03_20_37.csv'
2017.07.03 21:00:48.973 3: DbRep Rep.LogDB1 - Database dump finished successfully.
2017.07.03 21:02:36.595 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:02:36.596 3: DbRep Rep.LogDB1 - ###             New database Restore/Recovery                ###
2017.07.03 21:02:36.596 3: DbRep Rep.LogDB1 - ################################################################
2017.07.03 21:02:36.607 3: DbRep Rep.LogDB1 - Starting restore of database 'fhemtest1', table 'history'.
2017.07.03 21:04:52.136 3: DbRep Rep.LogDB1 - Restore of /volume1/ApplicationBackup/dumps_FHEM/fhemtest1_history_2017_07_03_21_00.csv into 'fhemtest1', 'history' finished - total time used: 136 sec.
2017.07.03 21:04:52.151 3: DbRep Rep.LogDB1 - Database restore finished successfully.

Funktion ist für MySQL verfügbar.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Juli 2017, 20:46:12
Hallo,

ich checke nachher die Version 5.5.0 ein.

Damit ist dann "restoreMySQL" im Repository verfügbar.

ACHTUNG: In DbLog wurde das Internal "MODEL" eingeführt. DbRep habe ich auf dieses Internal umgestellt. Falls nach dem Update von DbRep Fehler auftreten sollten bitte danach schauen dass auch DbLog aktuell ist (V 2.18.3).

VG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2017, 21:28:52
Hallo zusammen,

es gibt in der Version 5.6.1 für MySQL die Möglichkeit sich die Datenbankprozesse ausgeben zu lassen:

* '''procinfo''' : listet die existierenden Datenbank-Prozesse in einer Tabelle auf (nur MySQL).
Typischerweise werden nur die Prozesse des Verbindungsusers (angegeben in DbLog-Konfiguration) ausgegeben. Sollen alle Prozesse angezeigt werden, ist dem User das globale Recht "PROCESS" einzuräumen.
Für bestimmte SQL-Statements wird seit MariaDB 5.3 ein Fortschrittsreporting (Spalte "PROGRESS") ausgegeben. Zum Beispiel kann der Abarbeitungsgrad bei der Indexerstellung verfolgt werden.
Weitere Informationen sind hier https://mariadb.com/kb/en/mariadb/show-processlist/ (https://mariadb.com/kb/en/mariadb/show-processlist/) verfügbar.

Auch habe ich festgestellt, dass der empfohlene zusätzliche DbRep-Index bei großen Datenbanken insbesondere bei Sortierungsvorgängen nicht hilfreich ist und habe ihn entsprechend angepasst. Es ist besser ihn so anzulegen:

CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;

Bitte ersetzt den alten Reading_Time_Idx sofern ihr diesen bei euch angelegt haben solltet.
In DbLog habe ich den configCheck ab Version 2.21.1 ebenfalls auf diesen neuen Index angepasst.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 09 August 2017, 13:05:16
Hallo Heiko,

wäre es bei Gelegenheit möglich, beim attr device auch <devspec> zu verwenden?

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 August 2017, 18:06:46
Zitat
wäre es bei Gelegenheit möglich, beim attr device auch <devspec> zu verwenden?
Ich habe "befürchtet" dass früher oder später diese Frage kommt. Es wunderte mich nur dass sie solange auf sich hat warten lassen  ;)

Grundsätzlich sollte es möglich sein, allerdings habe ich bislang den Aufwand gescheut jede Funktion wieder anzufassen, umzubauen und auf ihre Funktion zu testen.
Aber ich versuche mal daran zu denken wenn die Tage wieder länger kürzer  ??? und das Wetter mieser wird....

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 09 August 2017, 19:44:43
Danke für's "auf dem Schirm haben" - eilt ja wirklich nicht. Je mehr schöne Funktionen man in FHEM entdecken kann, desto öfter möchte man die dann überall haben  ;D

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thyraz am 06 Oktober 2017, 07:33:17
Vielen Dank mal wieder für das Modul. :)

Bin wegen Charting mit Grafana (welches jetzt ja auch MySQL als Datenquelle erlaubt, womit man sich die zusätzliche InfluxDB sparen kann) von einer lokalen SQLite3 Datenbank auf MySQL (oder genauer gesagt MariaDB auf meiner Synology) umgestiegen.

Seit wir DBLog mit dem Async-Betrieb haben, ist ein kurzes Verschwinden der DBLog Verbindung (z.B. Restart NAS, oder Update MariaDB auf dem NAS) für FHEM ja kein Problem mehr.
Und dank Caching der Events verliert man ja nichtmal mehr Logevents, da die gecachten Ereignisse beim Wiederkehren der DB-Verbindung brav nachgetragen werden.

Mit aktuellem DBLog und DBRep bereitet Fhem in Verbindung mit einer Datenbank richtig Freude. ;)

Hab zum Umzug von SQLite3 in eine MySQL Datenbank einfach die Hinweise hier befolgt:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Datens.C3.A4tze_.28Devices.29_von_einer_Datenbank_in_eine_andere_umziehen_.28Export.2FImport.29
Allerdings eben das Attribut device im DBRep nicht gesetzt, so dass alle Datenbankeinträge gesichert (und danach wiederhergestellt) wurden.

Hat durch die große DB doch ein wenig gedauert bis er das alles durchgenudelt hatte, aber am Ende waren alle Einträge wieder in der neuen Datenbank vorhanden. :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Oktober 2017, 14:39:27
Hallo Thyraz,

vielen Dank für diesen Erfahrungsbericht und mich freut natürlich dass dein Vorhaben so gut mit den Werkzeugen funktioniert hat  :)

Ich muss zugeben dass die enge Verschmelzung von DbLog und DbRep mein Ziel war und dass man quasi ein Set an Werkzeugen hat um mit einer DB in FHEM möglichst reibungsfrei zu arbeiten.
Bin natürlich bemüht diesen "Werkeugkasten" stetig zu verbessern und zu erweitern.

Rudi hat ja aktuell die Blocking.pm erweitert. DbLog und DbRep habe ich angepasst damit die Abbruchfunktion (früher nur Timeout) nun auch die erweiterte Ausgabe von Blocking ausgibt.

Die Version 5.6.4 von DbRep habe ich wie gehabt im ersten Beitrag hinterlegt.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Oktober 2017, 18:33:45
Guten Abend,

es gibt im ersten Beitrag die Version 5.8.0.

Neben kleinen Fixes gibt es nun für die Funktionen countEntries und fetchrows die Möglichkeit entweder die Tabelle history oder current auszuwählen.
Damit kann man sich auch schnell einmal einen Überblick darüber verschaffen welchen Inhalt die current zur Zeit hat.

Die Version checke ich heute Abend auch noch ein.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Oktober 2017, 23:55:00
Guten Abend,

angeregt durch den Wunsch von Omega im Beitrag #459 habe ich die Version 5.8.4 (erster Beitrag) erstellt.
Damit ist es nun möglich das Device als Geräte-Spezifikation] (devspec)  https://fhem.de/commandref_DE.html#devspec anzugeben bzw. mehrere Readings als Komma separierte Liste einzugeben.



viel Spaß beim Test.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Oktober 2017, 23:32:10
Habe soeben die Version 5.8.5 eingecheckt. Sie enthält ein kleines Bugfix in "get procinfo". Manchmal kam es dazu dass die Ergebnistabelle der Datenbankprozesse nicht richtig angezeigt wurde.

LG
Heiko 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Oktober 2017, 15:35:48
Hallo zusammen,

in der Version 6.0.0 (erster Beitrag) ist es nun möglich nach einem Backup bzw. Dump das erzeugte File an einen FTP-Server zu senden.
Zur Realisierung gibt es einen Satz von Attributen die den FTP-Transfer einschalten und steuern.
Hier ein Auszug aus der Commandref:

Zitat
FTP Transfer nach Dump
Wenn diese Möglichkeit genutzt werden soll, ist das Attribut "ftpUse" oder "ftpUseSSL" zu setzen. Letzteres gilt wenn Verschlüsselung genutzt werden soll.
Weitere Attribute sind:

    ftpUse           : FTP Transfer nach dem Dump wird eingeschaltet (ohne SSL Verschlüsselung)
    ftpUser          : User zur Anmeldung am FTP-Server, default: anonymous
    ftpUseSSL      : FTP Transfer mit SSL Verschlüsselung nach dem Dump wird eingeschaltet
    ftpDebug       : Debugging des FTP Verkehrs zur Fehlersuche
    ftpDir            : Verzeichnis auf dem FTP-Server in welches das File übertragen werden soll (default: "/")
    ftpPassive      : setzen wenn passives FTP verwendet werden soll
    ftpPort           : FTP-Port, default: 21
    ftpPwd           : Passwort des FTP-Users, default nicht gesetzt
    ftpServer       : Name oder IP-Adresse des FTP-Servers. notwendig !
    ftpTimeout     : Timeout für die FTP-Verbindung in Sekunden (default: 30).

Es werden die Perl Module Net::FTP bzw. Net::FTPSSL benötigt. Sie werden aber erst geladen wenn diese Funktion genutzt wird.
Sollten sie nicht vorhanden sein wird eine entsprechende Meldung angezeigt mit dem Hinweis auf Nachinstallation.
Die Commandref ist überarbeitet und kann entsprechend mit "help DbRep" nachgelesen werden.

Das Löschen von alten Dumpfiles (Versionsverwaltung) habe ich in den Blockingcall verschoben. Dadurch werden Blockierungen von FHEM vermieden wenn die zu löschenden Files sehr groß sind und es dementsprechnd lange dauert.

Viel Spass beim Test....

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 04 November 2017, 12:39:30
Mahlzeit Heiko,

ich bin gerade ein wenig dazu gekommen DbRep(6.0.0) zu testen, um genau zu sein die "vaccum".
Dabei erhalte ich jedoch die FM:
2017.11.04 11:27:16 3: DbRep MyDbRep - ################################################################
2017.11.04 11:27:16 3: DbRep MyDbRep - ###          New optimize table / vacuum execution           ###
2017.11.04 11:27:16 3: DbRep MyDbRep - ################################################################
2017.11.04 11:27:16 2: DbRep MyDbRep - Error executing: 'SELECT pg_size_pretty(pg_database_size('fhemtest'))' ! PostgreSQL-Error: DBD::Pg::st execute failed: ERROR:  database "fhemtest" does not exist at ./FHEM/93_DbRep.pm line 4785.

Sofern ich das richtig verstehe, steht an dieser Stelle der DB Name hardcoded drinnen  ;D

Grüße
Pyro

PS: Hast du für mich einen Tipp wie der Ubuntu apt Paketname für Net::FTP ist?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 November 2017, 15:18:36
Hi Pyro,

binzur Zeit im urlaub und etwas gehandicapt. 😀
möglicherweise habe ich nach meinen Tests vergessen fhemtest gegen die variable zu tauschen.  :(
Hast du mal in die zeile geschaut ?
Net::Ftp war bei mir schon installiert (debian). Ich würde mal googlen....

edit: im zweifel über CPAN..
LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 05 November 2017, 14:54:03
Hallo Heiko,

lass dich von mir nicht im Urlaub stören, das hat Zeit :)

möglicherweise habe ich nach meinen Tests vergessen fhemtest gegen die variable zu tauschen.  :(
Hast du mal in die zeile geschaut ?

Zeile 4785 und Zeile 4820 hat sich deine Test DB eingeschlichen, einfach
$query = "SELECT pg_size_pretty(pg_database_size('fhemtest'))"; durch
$query = "SELECT pg_size_pretty(pg_database_size('$dbname'))"; ersetzen und alles funktioniert wieder.

Ich sehe gerade das die FTP Funktion für mich gar nicht relevant ist, da ich ja PostgreSQL einsetze  :D


Wünsche dir noch einen schönen Urlaub
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 November 2017, 20:21:44
Hallo Pyro,

habe nun die Version 6.0.0 gefixt wie du schon geschriebn hast und auch eingecheckt.
Ist morgen im Update.

Danke und LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 19 November 2017, 21:35:52
Hallo,

ich habe im Wiki und im Forum via Suche nichts gefunden.
(Nur die über 30 Seiten dieses Beitrags hab ich mir nicht komplett durchgelesen)
DBLog und DBRep sind installiert und laufen.

Wie kann ich aus meiner Datenbank einen bestimmten Wert zu einer bestimmten Zeit auslesen und zum Rechnen in ein Reading kopieren ?

Hintergrund: Ich möchte von einem Homematic-Zwischenschaltsteckdose mit Messfunktion für unseren Wäschetrockner das Reading energy zu einem Zeitpunkt den ich ja im Plot sehe verwenden um den Energiebedarf für einen Trocknungsvorgang zu ermitteln/ zu berechnen. Per Klick im Plot ist mir das viel zu ungenau. Und dann muss ich ja noch mit Set das Reading des Dummys bzw. Notifys einstellen.

Und falls es vieeel eifachere Methoden gibt würde ich bitte trotzdem wissen wie das gehen würde.
Allein schon aus dem Lerneffekt.
EMONITOR hab ich gestern auch mal eingerichtet. Aber ich konnte da irgendwie noch keinen praktischen Nutzen draus ziehen.
Viel Werte aber irgendwie nicht genau das was ich suche.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 November 2017, 22:11:18
Hallo t.huber,

Zitat
Wie kann ich aus meiner Datenbank einen bestimmten Wert zu einer bestimmten Zeit auslesen und zum Rechnen in ein Reading kopieren ?

Im einfachsten Fall setzt du im DbRep das Attr "timestamp_begin" und "timestamp_end" auf genau das Datum/Zeit die du auswerten möchtest, z.B. "2017-11-19 11:00:00". Dann bekommst du ein Reading mit einem Wert und kannst einen Event erzeugen. Es muß sich natürlich ein Wert zu diesem Zeitpunkt in der DB befinden !

Damit kannst du wiederum ein Setreading in z.B. einem Dummy ausführen wie hier beschrieben:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Reading_von_DbRep_nach_Dummy_.C3.BCbertragen

Und dann damit rechnen.

Eine andere und elegantere Möglichkeit wäre die Userexit-Funktiion zu nutzen, Stichwort Attribut "userExitFn". Es setzt allerdings Perl-Programmierkenntnisse voraus.
Aber in diesem Fall würdest du den interessierenden Zeitraum auswerten, d.h. den Anfagswert (kW bzw. W)  beim Beginn des Auswertungszeitraums sowie den Wert am Ende des Auswertungszeitraums ermitteln, die Differenz bilden und mit der abgelaufenen Zeit multiplizieren. Den fertig ermittelten Wert könntest du dann im W/kW dir bereitstellen.

Wie die userExitFn benutzt werden kann, ist an einem komplexen Beispiel hier beschrieben:
https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschu%C3%9Feinspeisung

Wenn du den Einarbeitungsaufwand für die userExitFn nicht scheust wäre es m.M. nach das Mittel der Wahl weil es ein sehr mächtiges Werkzeug ist mit dem man sich aus der DB alles erdenkliche herausziehen und in Zahlen ausdrücken kann ... der Knoten muss nur erst einmal platzen  :)

Edit: Über die Attribute Device/Reading im DbRep wird das relevante Device bzw. Reading (im Datensatz in der DB) eingegrenzt.

LG,
Heiko 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 19 November 2017, 23:52:45
Vielen Dank schon mal für die schnelle Antwort !
Ich werd es mir morgen gleich mal anschauen.
mfg Tobias
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 20 November 2017, 00:40:31
Hallo Heiko,

danke für den Fix!
Dürfte ich dich bitte dir das mal anzusehen:
2017.11.19 23:21:46 1: PERL WARNING: Use of uninitialized value $wdadd in concatenation (.) or string at ./FHEM/93_DbRep.pm line 1420.Danke!

Gruß und gute Nacht
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2017, 08:29:50
Morgen Pyro,

bei meinen ganzen Devices habe ich diese Warnung noch nicht gesehen.
Unter welchen Umständen erscheint sie denn ?

Es müßte entweder der Wochentag oder ein daraus resultierender Korrekturwert nicht gesetzt sein was eigentlich nicht vorkommt.
Vielleicht hilft es mir wenn du verbose 5 einstellst, die Berechnung mit dem DbRep-Device durchführst und die Logausgabe mal postest.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2017, 12:11:43
Hallo Tobias,

ich glaube für deine Aufgabenstellung gibt es eine sehr einfache Lösung.
Der HM-ES-PMSw1-Pl liefert in Reading energyCalc bereits Wh als Wert. Wenn du dieses Reading loggst (davon gehe ich aus), hast du ja bereits diese Werte in der DB. Ich benutze dafür ein userreading energyCalcKwh (in kWh).

Nun musst du nur noch im DbRep-Device die Zeitgrenzen des Beginn des Trocknungsvorganges und dem Ende des Trocknungsvorganges in den Attributen timestamp_begin bzw. timestamp_end eintragen sowie device/reading setzen.

Die verbrauchte Energie ergibt sich dann mit:

set <Name> diffValue
Wenn es exakter auswerten möchtest, wäre es sinnvoll zu Beginn des Trockungsvorganges ein definiertes addLog zu setzen um den Anfangswert von Wh zum genauen Zeitpunkt des Trochnungsvorganges festzuhalten. Dafür gibt es in DbLog eine eingebaute Funktion:

set <name> addLog <device>:<Reading>
Dieses Addlog kannst du z.B. mit einem Notify triggern wenn die Leistungsaufnahme im Zwischenstecker (Reading power) über einen bestimmten Wert steigt.
Gleiches gilt wenn die Aufnahme wieder auf 0 sinkt.

Ich denke damit wäre das Ziel erreicht was du möchtest.
Ungeachtet dessen wäre es durchaus sinnvoll sich mit der userExitFn zu befassen weil man damit viele komplexe Aufgabenstellungen lösen kann.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 20 November 2017, 12:40:41
Mahlzeit Heiko,

bei meinen ganzen Devices habe ich diese Warnung noch nicht gesehen.
Unter welchen Umständen erscheint sie denn ?
Ich habe einen FHEM Neustart durchgeführt und direkt unter den Meldungen kam eben diesen.
Am Abend werde ich versuchen die Meldung mit gesetzten Verbose 5 zu provozieren.

Gruß
Gerald
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 20 November 2017, 21:20:45
Wow !
Danke DS_Starter für den spezifischen Tipp !

Werd ich gleich mal umsetzten. Ich hoffe ich habe heute noch Zeit.  ;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 20 November 2017, 22:01:43
@DS_Starter
Das energyCalcKwh heißt dann in meinem Fall wohl 2017-11-18_21-13-28__HM_32B1AE_Pwr__energyCalc__DIFF__all_between_timestamps
Im Screenshot anbei (grün markiert)

Die Warnings gehe ich dann wahrscheinlich mit diffAccept an oder ?
Die im Screenshot orange markierten Werte sind dann irgendwie die Basis für die jeweiligen Differenzen >20 die angemahnt werden oder ?
Aber was stellen diese Einzelwerte dar ? Also z.B. in der erste Zeile 10.0000 -> 31.5000
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2017, 22:16:37
Zitat
Die Warnings gehe ich dann wahrscheinlich mit diffAccept an oder ?
Ja genau, einfach auf einen hohen Wert setzen. Das diffAccept soll nur vor Unregelmäßigkeiten schützen bzw. darauf aufmerksam machen.

Zitat
Die im Screenshot orange markierten Werte sind dann irgendwie die Basis für die jeweiligen Differenzen >20 die angemahnt werden oder ?
Auch richtig.

Zitat
Aber was stellen diese Einzelwerte dar ? Also z.B. in der erste Zeile 10.0000 -> 31.5000
Das bedeutet dass es einen Sprung von 10.000 auf 31.500 zwischen den benachbarten Werten gegeben hat.
Allerdings ist das für mich unlogisch, weil der nächste Wert 17:06 wieder 10.500 angibt.

Die Werte müßte man sich mal ansehen ... einfeach ein "set ... fetchrows history" ausführen. Dann sieht man die einzelnen Werte als Readings.

EDIT: Das Reading ebergyCalc ist eigentlich immer stetig ansteigend, so zumindest bei mir. So starke Sprünge wie ich bei dir sehe kann es eigentlich nicht geben. Dem muss man erstmal auf den Grund gehen woher das kommt.

Aber heute nicht mehr  ;)


Korrektur:  Der erste Wert (10.0000) zeigt den Diff des vorherigen DAtensatzes, der Wert 31.5000 den Diff des darauf folgenden Datensatzes. Dieser Wert überschreitet in deim Fall den Default diffAccept=20.

GN,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 21 November 2017, 01:09:32
Schnell noch ein paar Readings exportiert:  ;)
Readings
2017-11-18_16-30-56__HM_32B1AE_Pwr__energyCalc 3320.4 21.11.2017 01:01
2017-11-18_16-33-22__HM_32B1AE_Pwr__energyCalc 3320.4 21.11.2017 01:01
2017-11-18_16-35-33__HM_32B1AE_Pwr__energyCalc 3320.5 21.11.2017 01:01
2017-11-18_16-38-33__HM_32B1AE_Pwr__energyCalc 3320.5 21.11.2017 01:01
2017-11-18_16-39-34__HM_32B1AE_Pwr__energyCalc