FHEM Forum

FHEM => Automatisierung => 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.

ZitatDie 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
Zitat von: DS_Starter am 05 Juli 2016, 08:15:24

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
Zitat von: DS_Starter am 03 Juli 2016, 10:07:20

######################################################################
# 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
Zitat von: DS_Starter am 03 August 2016, 22:48:53
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
Zitat von: DS_Starter am 03 August 2016, 23:09:23
...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
Zitat 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.
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

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

Zitateval: {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
Zitat von: DS_Starter am 04 August 2016, 00:08:09
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
Zitat von: DS_Starter am 04 August 2016, 00:08:09
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
Zitatrü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
Zitatkann 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
Zitat von: DS_Starter am 05 August 2016, 08:59:56
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
Zitat von: DS_Starter am 08 August 2016, 22:43:39
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
ZitatDie 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
ZitatIch 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
Zitat von: DS_Starter am 09 August 2016, 18:40:42
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.

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

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
Zitat von: DS_Starter am 09 August 2016, 22:10:29
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
Zitat von: DS_Starter am 09 August 2016, 22:40:52
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
ZitatIch 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  :).

ZitatEine 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
Zitat von: DS_Starter am 19 August 2016, 09:17:48
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

Zitat von: DS_Starter am 19 August 2016, 09:17:48
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.

Zitat von: DS_Starter am 19 August 2016, 09:17:48
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
Zitatkann man die aktuelle Moduldatei auch direkt mit einem "sudo wget" runter laden?

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

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

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

ZitatInteressant 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
ZitatKann 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
Zitat von: DS_Starter am 19 August 2016, 16:56:36
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
Zitat von: DS_Starter am 19 Mai 2016, 22:52:13
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
ZitatWas 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 ...

ZitatWie 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,

ZitatMerkwü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
Zitatsolltest 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
ZitatIch 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:
ZitatNote 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
Zitat von: DS_Starter am 28 August 2016, 20:38:05
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
ZitatKann 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
ZitatDas 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
ZitatVersuch 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
ZitatDas 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
ZitatAber 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
Zitat von: DS_Starter am 11 November 2016, 16:26:11
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
ZitatIch 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
ZitatNö... 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.

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

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

ZitatWas 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 ?

ZitatdiffAccept ist ein tolles Feature, vielen Dank dafür!!

Danke sehr  :) .... gebe mir Mühe das Modul mit deiner/eurer Hilfe weiter zu verbessern.

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

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

Zitat von: DS_Starter am 16 November 2016, 20:34:32
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,

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

ZitatIch 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
Zitat von: DS_Starter am 20 November 2016, 12:10:49
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
Zitat 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

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,

ZitatEvtl. 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
Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
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!




Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
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.

Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
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

Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
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.

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

ZitatEs 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.  :(

ZitatGenau 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
Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
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.

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
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)!

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
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.

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
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
ZitatDu 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.

ZitatJa 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

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

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
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 ;-)

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
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...


Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
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!

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
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...

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
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.

Zitatich 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
Zitat von: DS_Starter am 09 Dezember 2016, 19:42:18
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!


Zitat von: DS_Starter am 10 Dezember 2016, 13:26:05
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,

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

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

Zitat von: DerFrickler am 13 Dezember 2016, 18:13:14
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;

Zitat von: DerFrickler am 13 Dezember 2016, 18:13:14
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:

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

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

ZitatWä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
Zitat von: JoeALLb am 13 Dezember 2016, 18:49:30
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!

Zitat von: JoeALLb am 13 Dezember 2016, 18:49:30
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
Zitat 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.

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

ZitatIst das "lenth" hier eventuell ein Vertipper und sollte length heißen?

Richtig. Korrigiere ich.

Zitatkö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

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

Zitat von: DS_Starter am 13 Dezember 2016, 22:36:08
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
Zitatleider 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
Zitat 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.

ü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
ZitatKann es sein dass ein tableInfo die DB eine Zeit lang blockiert?
Nein.

ZitatDbLog: 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
Zitat von: DS_Starter am 28 Dezember 2016, 09:08:52
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:

ZitatUnd 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
Zitat von: DS_Starter am 28 Dezember 2016, 11:47:56
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,

Zitatgibt 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: ioT4db 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,

ZitatKö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: ioT4db am 15 Januar 2017, 22:22:27
Zitat von: DS_Starter am 15 Januar 2017, 22:17:13
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: ioT4db am 15 Januar 2017, 22:39:59
hi,

Zitat 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

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: ioT4db am 15 Januar 2017, 22:49:05
Zitat von: DS_Starter am 15 Januar 2017, 22:45:56
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: ioT4db am 17 Januar 2017, 23:30:02
Zitat 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

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:

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

ZitatUnd 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)

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

ZitatKann 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 Gaszaehler
versucht.

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,

ZitatKö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

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

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

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

ZitatKonnte 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
Zitat von: DS_Starter am 10 Februar 2017, 21:11:24
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
Zitat von: DS_Starter am 10 Februar 2017, 22:41:55
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
ZitatSagen 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.

ZitatKann 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
Zitat 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 ?

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,

Zitatfhem.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":

Zitatdefine 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: sec
Das 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,

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

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

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

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

Grüße
Heiko
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
ZitatIch liefer auch gerne Code für eine erste Version zu, wenn gewünscht, ich habe bisher nur nicht in die Tasten gegriffen...

Ja klar, immer gerne ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 08 Mai 2017, 21:20:53
Zitat von: DS_Starter am 07 Mai 2017, 15:36:47
Ja klar, immer gerne ....

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

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

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

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

Hier mal angehängt als komplettes Modul - basierend auf der aktuellen (?) Version aus dem svn
Bei mir geht es soweit - aber voll getestet habe ich es nicht
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,

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

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

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

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

Ich mache mal  noch eine Version ...
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.

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

ZitatDer Wert des Zählers ist nicht die aktuelle Leistung, sondern der Verbrauchte Strom in kWh.
Das macht es einfacher ...

ZitatMüsste eben statt "averageValue", "diffValue" verwenden und erspare mir das Multiplizieren.
Richtig.

Zitatin 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
Zitat von: DS_Starter am 08 Juni 2017, 10:43:42
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.


Zitat von: DS_Starter am 08 Juni 2017, 10:43:42
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
Zitat von: DS_Starter am 14 Juni 2017, 12:43:31
Naja DbLog macht halt das was du ihm gesagt hast,...
Darum so vorsichtig formuliert... es ging mir mehr um die Sinnhaftigkeit... ;-)

Zitat von: DS_Starter am 14 Juni 2017, 12:43:31
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
Zitatwä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.

  • device - Abgrenzung der DB-Selektionen auf ein bestimmtes Device.
    Es können Geräte-Spezifikationen (devspec) angegeben werden.
    Innerhalb von Geräte-Spezifikationen wird SQL-Wildcard (%) als normales ASCII-Zeichen gewertet. Die Devicenamen werden vor der Selektion aus der Geräte-Spezifikationen und den aktuell in FHEM vorhandenen Devices abgeleitet.

        Beispiele:
        attr <Name> device TYPE=DbRep
        # selektiert Datensätze von aktuell vorhandenen Devices des Typs "DbRep"
        attr <Name> device MySTP_5000
        # selektiert Datensätze vom Device "MySTP_5000"
        attr <Name> device SMA.*
        # selektiert Datensätze von Devices beginnend mit "SMA"
        attr <Name> device SMA_Energymeter,MySTP_5000
        # selektiert Datensätze der Devices "SMA_Energymeter" und "MySTP_5000"
        attr <Name> device %5000
        # selektiert Datensätze von Devices endend mit "5000"


  • reading - Abgrenzung der DB-Selektionen auf ein bestimmtes oder mehrere Readings. Mehrere Readings werden als Komma separierte Liste angegeben.

        Beispiele:
        attr <Name> reading etotal
        # selektiert Datensätze mit Reading "etotal"
        attr <Name> reading et%
        # selektiert Datensätze von Readings beginnend mit "et"
        attr <Name> reading etotal,etoday
        # selektiert Datensätze mit Reading "etotal" und "etoday"

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

Zitat von: DS_Starter am 04 November 2017, 15:18:36mö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,

ZitatWie 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,

Zitat von: DS_Starter am 20 November 2017, 08:29:50
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
ZitatDie 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.

ZitatDie im Screenshot orange markierten Werte sind dann irgendwie die Basis für die jeweiligen Differenzen >20 die angemahnt werden oder ?
Auch richtig.

ZitatAber 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 3320.5 21.11.2017 01:01
2017-11-18_16-39-42__HM_32B1AE_Pwr__energyCalc 3320.7 21.11.2017 01:01
2017-11-18_16-40-49__HM_32B1AE_Pwr__energyCalc 3322.7 21.11.2017 01:01
2017-11-18_16-40-57__HM_32B1AE_Pwr__energyCalc 3323.3 21.11.2017 01:01
2017-11-18_16-41-05__HM_32B1AE_Pwr__energyCalc 3324.1 21.11.2017 01:01
2017-11-18_16-41-19__HM_32B1AE_Pwr__energyCalc 3325.6 21.11.2017 01:01
2017-11-18_16-42-43__HM_32B1AE_Pwr__energyCalc 3335 21.11.2017 01:01
2017-11-18_16-43-51__HM_32B1AE_Pwr__energyCalc 3342.9 21.11.2017 01:01
2017-11-18_16-44-36__HM_32B1AE_Pwr__energyCalc 3348.5 21.11.2017 01:01
2017-11-18_16-46-08__HM_32B1AE_Pwr__energyCalc 3360.1 21.11.2017 01:01
2017-11-18_16-46-25__HM_32B1AE_Pwr__energyCalc 3362.3 21.11.2017 01:01
2017-11-18_16-48-11__HM_32B1AE_Pwr__energyCalc 3376.3 21.11.2017 01:01
2017-11-18_16-48-14__HM_32B1AE_Pwr__energyCalc 3376.9 21.11.2017 01:01
2017-11-18_16-50-00__HM_32B1AE_Pwr__energyCalc 3391.9 21.11.2017 01:01
2017-11-18_16-51-04__HM_32B1AE_Pwr__energyCalc 3401.1 21.11.2017 01:01
2017-11-18_16-51-47__HM_32B1AE_Pwr__energyCalc 3407.8 21.11.2017 01:01
2017-11-18_16-53-35__HM_32B1AE_Pwr__energyCalc 3424.7 21.11.2017 01:01
2017-11-18_16-53-42__HM_32B1AE_Pwr__energyCalc 3425.7 21.11.2017 01:01
2017-11-18_16-54-30__HM_32B1AE_Pwr__energyCalc 3433.6 21.11.2017 01:01
2017-11-18_16-56-05__HM_32B1AE_Pwr__energyCalc 3449.6 21.11.2017 01:01
2017-11-18_16-57-17__HM_32B1AE_Pwr__energyCalc 3462.2 21.11.2017 01:01
2017-11-18_16-58-14__HM_32B1AE_Pwr__energyCalc 3472.2 21.11.2017 01:01
2017-11-18_17-01-13__HM_32B1AE_Pwr__energyCalc 3503.7 21.11.2017 01:01
2017-11-18_17-02-16__HM_32B1AE_Pwr__energyCalc 3515.3 21.11.2017 01:01
2017-11-18_17-03-57__HM_32B1AE_Pwr__energyCalc 3533.7 21.11.2017 01:01
2017-11-18_17-05-32__HM_32B1AE_Pwr__energyCalc 3551.4 21.11.2017 01:01
2017-11-18_17-06-27__HM_32B1AE_Pwr__energyCalc 3561.9 21.11.2017 01:01
2017-11-18_17-08-28__HM_32B1AE_Pwr__energyCalc 3585.3 21.11.2017 01:01
2017-11-18_17-08-43__HM_32B1AE_Pwr__energyCalc 3588.1 21.11.2017 01:01
2017-11-18_17-10-44__HM_32B1AE_Pwr__energyCalc 3612.2 21.11.2017 01:01
2017-11-18_17-11-25__HM_32B1AE_Pwr__energyCalc 3620.7 21.11.2017 01:01
2017-11-18_17-13-34__HM_32B1AE_Pwr__energyCalc 3647.2 21.11.2017 01:01
2017-11-18_17-14-06__HM_32B1AE_Pwr__energyCalc 3653.8 21.11.2017 01:01
2017-11-18_17-14-14__HM_32B1AE_Pwr__energyCalc 3654.1 21.11.2017 01:01
2017-11-18_17-16-11__HM_32B1AE_Pwr__energyCalc 3657.8 21.11.2017 01:01
2017-11-18_17-18-32__HM_32B1AE_Pwr__energyCalc 3662.2 21.11.2017 01:01
2017-11-18_17-19-05__HM_32B1AE_Pwr__energyCalc 3663.3 21.11.2017 01:01
2017-11-18_17-19-13__HM_32B1AE_Pwr__energyCalc 3664.5 21.11.2017 01:01
2017-11-18_17-19-21__HM_32B1AE_Pwr__energyCalc 3665.8 21.11.2017 01:01
2017-11-18_17-20-13__HM_32B1AE_Pwr__energyCalc 3674.7 21.11.2017 01:01
2017-11-18_17-20-21__HM_32B1AE_Pwr__energyCalc 3676.1 21.11.2017 01:01
2017-11-18_17-20-40__HM_32B1AE_Pwr__energyCalc 3679.4 21.11.2017 01:01
2017-11-18_17-20-47__HM_32B1AE_Pwr__energyCalc 3680.9 21.11.2017 01:01
2017-11-18_17-20-55__HM_32B1AE_Pwr__energyCalc 3682.3 21.11.2017 01:01
2017-11-18_17-21-03__HM_32B1AE_Pwr__energyCalc 3683.8 21.11.2017 01:01
2017-11-18_17-23-37__HM_32B1AE_Pwr__energyCalc 3713.1 21.11.2017 01:01
2017-11-18_17-23-56__HM_32B1AE_Pwr__energyCalc 3717.1 21.11.2017 01:01
2017-11-18_17-25-48__HM_32B1AE_Pwr__energyCalc 3739.6 21.11.2017 01:01
2017-11-18_17-26-19__HM_32B1AE_Pwr__energyCalc 3745.8 21.11.2017 01:01
2017-11-18_17-26-48__HM_32B1AE_Pwr__energyCalc 3752 21.11.2017 01:01
2017-11-18_17-26-56__HM_32B1AE_Pwr__energyCalc 3752.3 21.11.2017 01:01
2017-11-18_17-28-47__HM_32B1AE_Pwr__energyCalc 3755.8 21.11.2017 01:01
2017-11-18_17-31-01__HM_32B1AE_Pwr__energyCalc 3759.8 21.11.2017 01:01
2017-11-18_17-31-46__HM_32B1AE_Pwr__energyCalc 3761.3 21.11.2017 01:01
2017-11-18_17-31-54__HM_32B1AE_Pwr__energyCalc 3762.4 21.11.2017 01:01
2017-11-18_17-32-02__HM_32B1AE_Pwr__energyCalc 3763.8 21.11.2017 01:01
2017-11-18_17-32-54__HM_32B1AE_Pwr__energyCalc 3772.8 21.11.2017 01:01
2017-11-18_17-33-10__HM_32B1AE_Pwr__energyCalc 3775.7 21.11.2017 01:01
2017-11-18_17-34-04__HM_32B1AE_Pwr__energyCalc 3785.7 21.11.2017 01:01
2017-11-18_17-34-26__HM_32B1AE_Pwr__energyCalc 3790.1 21.11.2017 01:01
2017-11-18_17-36-02__HM_32B1AE_Pwr__energyCalc 3808.9 21.11.2017 01:01
2017-11-18_17-36-53__HM_32B1AE_Pwr__energyCalc 3819 21.11.2017 01:01
2017-11-18_17-37-20__HM_32B1AE_Pwr__energyCalc 3824.8 21.11.2017 01:01
2017-11-18_17-38-19__HM_32B1AE_Pwr__energyCalc 3837 21.11.2017 01:01
2017-11-18_17-38-27__HM_32B1AE_Pwr__energyCalc 3837.3 21.11.2017 01:01
2017-11-18_17-39-27__HM_32B1AE_Pwr__energyCalc 3839.3 21.11.2017 01:01
2017-11-18_17-41-47__HM_32B1AE_Pwr__energyCalc 3843.6 21.11.2017 01:01
2017-11-18_17-43-18__HM_32B1AE_Pwr__energyCalc 3846.5 21.11.2017 01:01
2017-11-18_17-43-26__HM_32B1AE_Pwr__energyCalc 3847.6 21.11.2017 01:01
2017-11-18_17-43-34__HM_32B1AE_Pwr__energyCalc 3849 21.11.2017 01:01
2017-11-18_17-43-53__HM_32B1AE_Pwr__energyCalc 3852.1 21.11.2017 01:01
2017-11-18_17-44-21__HM_32B1AE_Pwr__energyCalc 3857.2 21.11.2017 01:01
2017-11-18_17-44-49__HM_32B1AE_Pwr__energyCalc 3862.4 21.11.2017 01:01
2017-11-18_17-46-07__HM_32B1AE_Pwr__energyCalc 3877.4 21.11.2017 01:01
2017-11-18_17-46-48__HM_32B1AE_Pwr__energyCalc 3885.3 21.11.2017 01:01
2017-11-18_17-47-58__HM_32B1AE_Pwr__energyCalc 3899.6 21.11.2017 01:01
2017-11-18_17-49-21__HM_32B1AE_Pwr__energyCalc 3916.6 21.11.2017 01:01
2017-11-18_17-49-29__HM_32B1AE_Pwr__energyCalc 3916.8 21.11.2017 01:01
2017-11-18_17-51-55__HM_32B1AE_Pwr__energyCalc 3921.4 21.11.2017 01:01
2017-11-18_17-54-07__HM_32B1AE_Pwr__energyCalc 3925.5 21.11.2017 01:01
2017-11-18_17-54-19__HM_32B1AE_Pwr__energyCalc 3926 21.11.2017 01:01
2017-11-18_17-54-27__HM_32B1AE_Pwr__energyCalc 3927.1 21.11.2017 01:01
2017-11-18_17-54-35__HM_32B1AE_Pwr__energyCalc 3928.5 21.11.2017 01:01
2017-11-18_17-55-13__HM_32B1AE_Pwr__energyCalc 3935.1 21.11.2017 01:01
2017-11-18_17-55-21__HM_32B1AE_Pwr__energyCalc 3936.6 21.11.2017 01:01
2017-11-18_17-56-08__HM_32B1AE_Pwr__energyCalc 3945.4 21.11.2017 01:01
2017-11-18_17-57-00__HM_32B1AE_Pwr__energyCalc 3955.5 21.11.2017 01:01
2017-11-18_17-57-08__HM_32B1AE_Pwr__energyCalc 3957.1 21.11.2017 01:01
2017-11-18_17-58-41__HM_32B1AE_Pwr__energyCalc 3975.7 21.11.2017 01:01
2017-11-18_17-59-55__HM_32B1AE_Pwr__energyCalc 3991 21.11.2017 01:01
2017-11-18_18-00-05__HM_32B1AE_Pwr__energyCalc 3993 21.11.2017 01:01
2017-11-18_18-00-13__HM_32B1AE_Pwr__energyCalc 3993.3 21.11.2017 01:01
2017-11-18_18-00-46__HM_32B1AE_Pwr__energyCalc 3994.4 21.11.2017 01:01
2017-11-18_18-00-54__HM_32B1AE_Pwr__energyCalc 3994.6 21.11.2017 01:01
2017-11-18_18-01-02__HM_32B1AE_Pwr__energyCalc 3994.8 21.11.2017 01:01
2017-11-18_18-02-28__HM_32B1AE_Pwr__energyCalc 3997.3 21.11.2017 01:01
2017-11-18_18-04-46__HM_32B1AE_Pwr__energyCalc 4001.5 21.11.2017 01:01
2017-11-18_18-05-04__HM_32B1AE_Pwr__energyCalc 4002.2 21.11.2017 01:01
2017-11-18_18-05-12__HM_32B1AE_Pwr__energyCalc 4003.4 21.11.2017 01:01
2017-11-18_18-05-20__HM_32B1AE_Pwr__energyCalc 4004.8 21.11.2017 01:01
2017-11-18_18-06-04__HM_32B1AE_Pwr__energyCalc 4012.5 21.11.2017 01:01
2017-11-18_18-06-30__HM_32B1AE_Pwr__energyCalc 4017.4 21.11.2017 01:01
2017-11-18_18-06-50__HM_32B1AE_Pwr__energyCalc 4021.1 21.11.2017 01:01
2017-11-18_18-07-58__HM_32B1AE_Pwr__energyCalc 4034.5 21.11.2017 01:01
2017-11-18_18-09-43__HM_32B1AE_Pwr__energyCalc 4055.5 21.11.2017 01:01
2017-11-18_18-09-53__HM_32B1AE_Pwr__energyCalc 4057.8 21.11.2017 01:01
2017-11-18_18-10-38__HM_32B1AE_Pwr__energyCalc 4067 21.11.2017 01:01
2017-11-18_18-10-46__HM_32B1AE_Pwr__energyCalc 4067.3 21.11.2017 01:01
2017-11-18_18-12-22__HM_32B1AE_Pwr__energyCalc 4070.3 21.11.2017 01:01
2017-11-18_18-14-46__HM_32B1AE_Pwr__energyCalc 4074.7 21.11.2017 01:01
2017-11-18_18-15-36__HM_32B1AE_Pwr__energyCalc 4076.3 21.11.2017 01:01
2017-11-18_18-15-44__HM_32B1AE_Pwr__energyCalc 4077.5 21.11.2017 01:01
2017-11-18_18-15-52__HM_32B1AE_Pwr__energyCalc 4078.8 21.11.2017 01:01
2017-11-18_18-16-36__HM_32B1AE_Pwr__energyCalc 4086.6 21.11.2017 01:01
2017-11-18_18-16-44__HM_32B1AE_Pwr__energyCalc 4088.1 21.11.2017 01:01
2017-11-18_18-16-56__HM_32B1AE_Pwr__energyCalc 4090.3 21.11.2017 01:01
2017-11-18_18-17-30__HM_32B1AE_Pwr__energyCalc 4096.9 21.11.2017 01:01
2017-11-18_18-19-14__HM_32B1AE_Pwr__energyCalc 4117.4 21.11.2017 01:01
2017-11-18_18-19-56__HM_32B1AE_Pwr__energyCalc 4125.7 21.11.2017 01:01
2017-11-18_18-20-13__HM_32B1AE_Pwr__energyCalc 4129.4 21.11.2017 01:01
2017-11-18_18-21-06__HM_32B1AE_Pwr__energyCalc 4140.4 21.11.2017 01:01
2017-11-18_18-21-14__HM_32B1AE_Pwr__energyCalc 4140.7 21.11.2017 01:01
2017-11-18_18-22-41__HM_32B1AE_Pwr__energyCalc 4143.5 21.11.2017 01:01
2017-11-18_18-25-12__HM_32B1AE_Pwr__energyCalc 4148 21.11.2017 01:01
2017-11-18_18-26-05__HM_32B1AE_Pwr__energyCalc 4149.8 21.11.2017 01:01
2017-11-18_18-26-13__HM_32B1AE_Pwr__energyCalc 4151 21.11.2017 01:01
2017-11-18_18-26-21__HM_32B1AE_Pwr__energyCalc 4152.4 21.11.2017 01:01
2017-11-18_18-27-05__HM_32B1AE_Pwr__energyCalc 4160.2 21.11.2017 01:01
2017-11-18_18-27-28__HM_32B1AE_Pwr__energyCalc 4164.5 21.11.2017 01:01
2017-11-18_18-27-52__HM_32B1AE_Pwr__energyCalc 4169.2 21.11.2017 01:01
2017-11-18_18-28-55__HM_32B1AE_Pwr__energyCalc 4181.5 21.11.2017 01:01
2017-11-18_18-29-30__HM_32B1AE_Pwr__energyCalc 4188.4 21.11.2017 01:01
2017-11-18_18-30-16__HM_32B1AE_Pwr__energyCalc 4197.8 21.11.2017 01:01
2017-11-18_18-31-28__HM_32B1AE_Pwr__energyCalc 4212.7 21.11.2017 01:01
2017-11-18_18-31-36__HM_32B1AE_Pwr__energyCalc 4213.4 21.11.2017 01:01
2017-11-18_18-32-22__HM_32B1AE_Pwr__energyCalc 4214.9 21.11.2017 01:01
2017-11-18_18-34-59__HM_32B1AE_Pwr__energyCalc 4219.7 21.11.2017 01:01
2017-11-18_18-36-29__HM_32B1AE_Pwr__energyCalc 4222.5 21.11.2017 01:01
2017-11-18_18-36-37__HM_32B1AE_Pwr__energyCalc 4223.7 21.11.2017 01:01
2017-11-18_18-36-45__HM_32B1AE_Pwr__energyCalc 4225.1 21.11.2017 01:01
2017-11-18_18-37-21__HM_32B1AE_Pwr__energyCalc 4231.4 21.11.2017 01:01
2017-11-18_18-37-29__HM_32B1AE_Pwr__energyCalc 4232.9 21.11.2017 01:01
2017-11-18_18-38-00__HM_32B1AE_Pwr__energyCalc 4238.7 21.11.2017 01:01
2017-11-18_18-39-24__HM_32B1AE_Pwr__energyCalc 4255.1 21.11.2017 01:01
2017-11-18_18-39-30__HM_32B1AE_Pwr__energyCalc 4256 21.11.2017 01:01
2017-11-18_18-40-45__HM_32B1AE_Pwr__energyCalc 4271.4 21.11.2017 01:01
2017-11-18_18-40-53__HM_32B1AE_Pwr__energyCalc 4273 21.11.2017 01:01
2017-11-18_18-41-01__HM_32B1AE_Pwr__energyCalc 4274.6 21.11.2017 01:01
2017-11-18_18-41-36__HM_32B1AE_Pwr__energyCalc 4281.7 21.11.2017 01:01
2017-11-18_18-41-44__HM_32B1AE_Pwr__energyCalc 4281.9 21.11.2017 01:01
2017-11-18_18-42-27__HM_32B1AE_Pwr__energyCalc 4283.3 21.11.2017 01:01
2017-11-18_18-45-11__HM_32B1AE_Pwr__energyCalc 4288.2 21.11.2017 01:01
2017-11-18_18-46-34__HM_32B1AE_Pwr__energyCalc 4290.8 21.11.2017 01:01
2017-11-18_18-46-42__HM_32B1AE_Pwr__energyCalc 4292 21.11.2017 01:01
2017-11-18_18-46-50__HM_32B1AE_Pwr__energyCalc 4293.3 21.11.2017 01:01
2017-11-18_18-47-35__HM_32B1AE_Pwr__energyCalc 4301.2 21.11.2017 01:01
2017-11-18_18-47-40__HM_32B1AE_Pwr__energyCalc 4301.9 21.11.2017 01:01
2017-11-18_18-47-47__HM_32B1AE_Pwr__energyCalc 4303.4 21.11.2017 01:01
2017-11-18_18-48-40__HM_32B1AE_Pwr__energyCalc 4313.5 21.11.2017 01:01
2017-11-18_18-49-54__HM_32B1AE_Pwr__energyCalc 4328 21.11.2017 01:01
2017-11-18_18-50-08__HM_32B1AE_Pwr__energyCalc 4330.8 21.11.2017 01:01
2017-11-18_18-51-54__HM_32B1AE_Pwr__energyCalc 4352.4 21.11.2017 01:01
2017-11-18_18-51-58__HM_32B1AE_Pwr__energyCalc 4353.2 21.11.2017 01:01
2017-11-18_18-52-13__HM_32B1AE_Pwr__energyCalc 4356.3 21.11.2017 01:01
2017-11-18_18-52-21__HM_32B1AE_Pwr__energyCalc 4356.5 21.11.2017 01:01
2017-11-18_18-54-44__HM_32B1AE_Pwr__energyCalc 4361 21.11.2017 01:01
2017-11-18_18-57-11__HM_32B1AE_Pwr__energyCalc 4365.4 21.11.2017 01:01
2017-11-18_18-57-19__HM_32B1AE_Pwr__energyCalc 4366.6 21.11.2017 01:01
2017-11-18_18-57-27__HM_32B1AE_Pwr__energyCalc 4368 21.11.2017 01:01
2017-11-18_18-58-12__HM_32B1AE_Pwr__energyCalc 4375.9 21.11.2017 01:01
2017-11-18_18-58-52__HM_32B1AE_Pwr__energyCalc 4383.4 21.11.2017 01:01
2017-11-18_18-59-40__HM_32B1AE_Pwr__energyCalc 4392.7 21.11.2017 01:01
2017-11-18_19-00-37__HM_32B1AE_Pwr__energyCalc 4404 21.11.2017 01:01
2017-11-18_19-01-47__HM_32B1AE_Pwr__energyCalc 4418 21.11.2017 01:01
2017-11-18_19-01-52__HM_32B1AE_Pwr__energyCalc 4419.2 21.11.2017 01:01
2017-11-18_19-02-46__HM_32B1AE_Pwr__energyCalc 4430.3 21.11.2017 01:01
2017-11-18_19-02-54__HM_32B1AE_Pwr__energyCalc 4430.5 21.11.2017 01:01
2017-11-18_19-04-43__HM_32B1AE_Pwr__energyCalc 4433.9 21.11.2017 01:01
2017-11-18_19-07-24__HM_32B1AE_Pwr__energyCalc 4438.8 21.11.2017 01:01
2017-11-18_19-07-44__HM_32B1AE_Pwr__energyCalc 4439.5 21.11.2017 01:01
2017-11-18_19-07-52__HM_32B1AE_Pwr__energyCalc 4440.7 21.11.2017 01:01
2017-11-18_19-08-00__HM_32B1AE_Pwr__energyCalc 4442.1 21.11.2017 01:01
2017-11-18_19-08-44__HM_32B1AE_Pwr__energyCalc 4449.8 21.11.2017 01:01
2017-11-18_19-08-53__HM_32B1AE_Pwr__energyCalc 4451.5 21.11.2017 01:01
2017-11-18_19-09-40__HM_32B1AE_Pwr__energyCalc 4460.5 21.11.2017 01:01
2017-11-18_19-09-51__HM_32B1AE_Pwr__energyCalc 4462.6 21.11.2017 01:01
2017-11-18_19-11-17__HM_32B1AE_Pwr__energyCalc 4479.5 21.11.2017 01:01
2017-11-18_19-12-04__HM_32B1AE_Pwr__energyCalc 4489.1 21.11.2017 01:01
2017-11-18_19-13-19__HM_32B1AE_Pwr__energyCalc 4504.5 21.11.2017 01:01
2017-11-18_19-13-27__HM_32B1AE_Pwr__energyCalc 4504.7 21.11.2017 01:01
2017-11-18_19-14-47__HM_32B1AE_Pwr__energyCalc 4507.3 21.11.2017 01:01
2017-11-18_19-17-15__HM_32B1AE_Pwr__energyCalc 4511.7 21.11.2017 01:01
2017-11-18_19-18-18__HM_32B1AE_Pwr__energyCalc 4513.7 21.11.2017 01:01
2017-11-18_19-18-26__HM_32B1AE_Pwr__energyCalc 4514.9 21.11.2017 01:01
2017-11-18_19-18-34__HM_32B1AE_Pwr__energyCalc 4516.3 21.11.2017 01:01
2017-11-18_19-19-18__HM_32B1AE_Pwr__energyCalc 4524 21.11.2017 01:01
2017-11-18_19-19-29__HM_32B1AE_Pwr__energyCalc 4526.1 21.11.2017 01:01
2017-11-18_19-19-34__HM_32B1AE_Pwr__energyCalc 4527 21.11.2017 01:01
2017-11-18_19-20-44__HM_32B1AE_Pwr__energyCalc 4540.5 21.11.2017 01:01
2017-11-18_19-20-52__HM_32B1AE_Pwr__energyCalc 4542 21.11.2017 01:01
2017-11-18_19-21-00__HM_32B1AE_Pwr__energyCalc 4543.5 21.11.2017 01:01
2017-11-18_19-22-32__HM_32B1AE_Pwr__energyCalc 4562 21.11.2017 01:01
2017-11-18_19-23-05__HM_32B1AE_Pwr__energyCalc 4568.8 21.11.2017 01:01
2017-11-18_19-23-44__HM_32B1AE_Pwr__energyCalc 4576.7 21.11.2017 01:01
2017-11-18_19-23-52__HM_32B1AE_Pwr__energyCalc 4576.9 21.11.2017 01:01
2017-11-18_19-25-22__HM_32B1AE_Pwr__energyCalc 4579.7 21.11.2017 01:01
2017-11-18_19-27-56__HM_32B1AE_Pwr__energyCalc 4584.2 21.11.2017 01:01
2017-11-18_19-28-42__HM_32B1AE_Pwr__energyCalc 4585.6 21.11.2017 01:01
2017-11-18_19-28-50__HM_32B1AE_Pwr__energyCalc 4586.8 21.11.2017 01:01
2017-11-18_19-28-58__HM_32B1AE_Pwr__energyCalc 4588.2 21.11.2017 01:01
2017-11-18_19-29-43__HM_32B1AE_Pwr__energyCalc 4596.1 21.11.2017 01:01
2017-11-18_19-30-14__HM_32B1AE_Pwr__energyCalc 4601.9 21.11.2017 01:01
2017-11-18_19-30-16__HM_32B1AE_Pwr__energyCalc 4602.2 21.11.2017 01:01
2017-11-18_19-31-48__HM_32B1AE_Pwr__energyCalc 4620.1 21.11.2017 01:01
2017-11-18_19-32-22__HM_32B1AE_Pwr__energyCalc 4626.8 21.11.2017 01:01
2017-11-18_19-33-18__HM_32B1AE_Pwr__energyCalc 4638.2 21.11.2017 01:01
2017-11-18_19-34-23__HM_32B1AE_Pwr__energyCalc 4651.5 21.11.2017 01:01
2017-11-18_19-34-31__HM_32B1AE_Pwr__energyCalc 4651.7 21.11.2017 01:01
2017-11-18_19-35-17__HM_32B1AE_Pwr__energyCalc 4653.2 21.11.2017 01:01
2017-11-18_19-37-58__HM_32B1AE_Pwr__energyCalc 4658 21.11.2017 01:01
2017-11-18_19-39-22__HM_32B1AE_Pwr__energyCalc 4660.5 21.11.2017 01:01
2017-11-18_19-39-30__HM_32B1AE_Pwr__energyCalc 4661.7 21.11.2017 01:01
2017-11-18_19-39-38__HM_32B1AE_Pwr__energyCalc 4663.1 21.11.2017 01:01
2017-11-18_19-40-23__HM_32B1AE_Pwr__energyCalc 4671 21.11.2017 01:01
2017-11-18_19-40-25__HM_32B1AE_Pwr__energyCalc 4671.1 21.11.2017 01:01
2017-11-18_19-40-43__HM_32B1AE_Pwr__energyCalc 4674.7 21.11.2017 01:01
2017-11-18_19-41-45__HM_32B1AE_Pwr__energyCalc 4686.5 21.11.2017 01:01
2017-11-18_19-42-37__HM_32B1AE_Pwr__energyCalc 4696.5 21.11.2017 01:01
2017-11-18_19-43-40__HM_32B1AE_Pwr__energyCalc 4709.2 21.11.2017 01:01
2017-11-18_19-45-07__HM_32B1AE_Pwr__energyCalc 4726.8 21.11.2017 01:01
2017-11-18_19-45-15__HM_32B1AE_Pwr__energyCalc 4727.1 21.11.2017 01:01
2017-11-18_19-45-38__HM_32B1AE_Pwr__energyCalc 4727.8 21.11.2017 01:01
2017-11-18_19-48-26__HM_32B1AE_Pwr__energyCalc 4732.7 21.11.2017 01:01
2017-11-18_19-50-05__HM_32B1AE_Pwr__energyCalc 4735.6 21.11.2017 01:01
2017-11-18_19-50-13__HM_32B1AE_Pwr__energyCalc 4736.8 21.11.2017 01:01
2017-11-18_19-50-21__HM_32B1AE_Pwr__energyCalc 4738.2 21.11.2017 01:01
2017-11-18_19-50-58__HM_32B1AE_Pwr__energyCalc 4744.6 21.11.2017 01:01
2017-11-18_19-51-07__HM_32B1AE_Pwr__energyCalc 4746.1 21.11.2017 01:01
2017-11-18_19-51-49__HM_32B1AE_Pwr__energyCalc 4754 21.11.2017 01:01
2017-11-18_19-53-17__HM_32B1AE_Pwr__energyCalc 4770.8 21.11.2017 01:01
2017-11-18_19-53-28__HM_32B1AE_Pwr__energyCalc 4773.1 21.11.2017 01:01
2017-11-18_19-54-49__HM_32B1AE_Pwr__energyCalc 4789.3 21.11.2017 01:01
2017-11-18_19-55-21__HM_32B1AE_Pwr__energyCalc 4795.6 21.11.2017 01:01
2017-11-18_19-55-56__HM_32B1AE_Pwr__energyCalc 4802.9 21.11.2017 01:01
2017-11-18_19-56-04__HM_32B1AE_Pwr__energyCalc 4803.2 21.11.2017 01:01
2017-11-18_19-58-14__HM_32B1AE_Pwr__energyCalc 4807 21.11.2017 01:01
2017-11-18_20-00-43__HM_32B1AE_Pwr__energyCalc 4811.2 21.11.2017 01:01
2017-11-18_20-00-51__HM_32B1AE_Pwr__energyCalc 4811.4 21.11.2017 01:01
2017-11-18_20-00-53__HM_32B1AE_Pwr__energyCalc 4811.4 21.11.2017 01:01
2017-11-18_20-00-59__HM_32B1AE_Pwr__energyCalc 4811.8 21.11.2017 01:01
2017-11-18_20-01-07__HM_32B1AE_Pwr__energyCalc 4813.1 21.11.2017 01:01
2017-11-18_20-01-15__HM_32B1AE_Pwr__energyCalc 4814.4 21.11.2017 01:01
2017-11-18_20-01-59__HM_32B1AE_Pwr__energyCalc 4822 21.11.2017 01:01
2017-11-18_20-03-11__HM_32B1AE_Pwr__energyCalc 4835.4 21.11.2017 01:01
2017-11-18_20-03-18__HM_32B1AE_Pwr__energyCalc 4836.5 21.11.2017 01:01
2017-11-18_20-04-56__HM_32B1AE_Pwr__energyCalc 4855.7 21.11.2017 01:01
2017-11-18_20-05-28__HM_32B1AE_Pwr__energyCalc 4862.1 21.11.2017 01:01
2017-11-18_20-06-27__HM_32B1AE_Pwr__energyCalc 4874 21.11.2017 01:01
2017-11-18_20-06-58__HM_32B1AE_Pwr__energyCalc 4880.2 21.11.2017 01:01
2017-11-18_20-07-06__HM_32B1AE_Pwr__energyCalc 4880.4 21.11.2017 01:01
2017-11-18_20-08-28__HM_32B1AE_Pwr__energyCalc 4882.8 21.11.2017 01:01
2017-11-18_20-11-13__HM_32B1AE_Pwr__energyCalc 4887.4 21.11.2017 01:01
2017-11-18_20-11-56__HM_32B1AE_Pwr__energyCalc 4888.7 21.11.2017 01:01
2017-11-18_20-12-04__HM_32B1AE_Pwr__energyCalc 4889.8 21.11.2017 01:01
2017-11-18_20-12-12__HM_32B1AE_Pwr__energyCalc 4891.2 21.11.2017 01:01
2017-11-18_20-12-59__HM_32B1AE_Pwr__energyCalc 4899.2 21.11.2017 01:01
2017-11-18_20-13-16__HM_32B1AE_Pwr__energyCalc 4902.3 21.11.2017 01:01
2017-11-18_20-13-44__HM_32B1AE_Pwr__energyCalc 4907.5 21.11.2017 01:01
2017-11-18_20-14-26__HM_32B1AE_Pwr__energyCalc 4915.4 21.11.2017 01:01
2017-11-18_20-16-01__HM_32B1AE_Pwr__energyCalc 4933.7 21.11.2017 01:01
2017-11-18_20-16-26__HM_32B1AE_Pwr__energyCalc 4938.8 21.11.2017 01:01
2017-11-18_20-18-03__HM_32B1AE_Pwr__energyCalc 4958.2 21.11.2017 01:01
2017-11-18_20-18-10__HM_32B1AE_Pwr__energyCalc 4959.9 21.11.2017 01:01
2017-11-18_20-18-18__HM_32B1AE_Pwr__energyCalc 4960.7 21.11.2017 01:01
2017-11-18_20-20-55__HM_32B1AE_Pwr__energyCalc 4965.1 21.11.2017 01:01
2017-11-18_20-23-12__HM_32B1AE_Pwr__energyCalc 4969 21.11.2017 01:01
2017-11-18_20-23-20__HM_32B1AE_Pwr__energyCalc 4970.1 21.11.2017 01:01
2017-11-18_20-23-28__HM_32B1AE_Pwr__energyCalc 4971.4 21.11.2017 01:01
2017-11-18_20-23-32__HM_32B1AE_Pwr__energyCalc 4971.9 21.11.2017 01:01
2017-11-18_20-24-12__HM_32B1AE_Pwr__energyCalc 4978.9 21.11.2017 01:01
2017-11-18_20-24-20__HM_32B1AE_Pwr__energyCalc 4980.4 21.11.2017 01:01
2017-11-18_20-25-08__HM_32B1AE_Pwr__energyCalc 4989.2 21.11.2017 01:01
2017-11-18_20-25-55__HM_32B1AE_Pwr__energyCalc 4997.9 21.11.2017 01:01
2017-11-18_20-26-47__HM_32B1AE_Pwr__energyCalc 5008.1 21.11.2017 01:01
2017-11-18_20-28-03__HM_32B1AE_Pwr__energyCalc 5023.1 21.11.2017 01:01
2017-11-18_20-28-43__HM_32B1AE_Pwr__energyCalc 5031.1 21.11.2017 01:01
2017-11-18_20-29-49__HM_32B1AE_Pwr__energyCalc 5044.4 21.11.2017 01:01
2017-11-18_20-29-57__HM_32B1AE_Pwr__energyCalc 5044.6 21.11.2017 01:01
2017-11-18_20-31-01__HM_32B1AE_Pwr__energyCalc 5046.5 21.11.2017 01:01
2017-11-18_20-33-45__HM_32B1AE_Pwr__energyCalc 5050.9 21.11.2017 01:01
2017-11-18_20-34-47__HM_32B1AE_Pwr__energyCalc 5052.7 21.11.2017 01:01
2017-11-18_20-34-55__HM_32B1AE_Pwr__energyCalc 5053.8 21.11.2017 01:01
2017-11-18_20-35-03__HM_32B1AE_Pwr__energyCalc 5055.1 21.11.2017 01:01
2017-11-18_20-35-48__HM_32B1AE_Pwr__energyCalc 5062.7 21.11.2017 01:01
2017-11-18_20-35-56__HM_32B1AE_Pwr__energyCalc 5064.1 21.11.2017 01:01
2017-11-18_20-36-14__HM_32B1AE_Pwr__energyCalc 5067.4 21.11.2017 01:01
2017-11-18_20-37-03__HM_32B1AE_Pwr__energyCalc 5076.5 21.11.2017 01:01
2017-11-18_20-38-29__HM_32B1AE_Pwr__energyCalc 5092.6 21.11.2017 01:01
2017-11-18_20-38-42__HM_32B1AE_Pwr__energyCalc 5095.3 21.11.2017 01:01
2017-11-18_20-40-29__HM_32B1AE_Pwr__energyCalc 5116.4 21.11.2017 01:01
2017-11-18_20-40-42__HM_32B1AE_Pwr__energyCalc 5118.9 21.11.2017 01:01
2017-11-18_20-40-50__HM_32B1AE_Pwr__energyCalc 5120.5 21.11.2017 01:01
2017-11-18_20-40-58__HM_32B1AE_Pwr__energyCalc 5122.1 21.11.2017 01:01
2017-11-18_20-41-33__HM_32B1AE_Pwr__energyCalc 5129.2 21.11.2017 01:01
2017-11-18_20-41-41__HM_32B1AE_Pwr__energyCalc 5129.4 21.11.2017 01:01
2017-11-18_20-43-19__HM_32B1AE_Pwr__energyCalc 5132.2 21.11.2017 01:01
2017-11-18_20-45-54__HM_32B1AE_Pwr__energyCalc 5136.3 21.11.2017 01:01
2017-11-18_20-46-32__HM_32B1AE_Pwr__energyCalc 5137.4 21.11.2017 01:01
2017-11-18_20-46-40__HM_32B1AE_Pwr__energyCalc 5138.6 21.11.2017 01:01
2017-11-18_20-46-48__HM_32B1AE_Pwr__energyCalc 5139.9 21.11.2017 01:01
2017-11-18_20-47-32__HM_32B1AE_Pwr__energyCalc 5147.3 21.11.2017 01:01
2017-11-18_20-47-41__HM_32B1AE_Pwr__energyCalc 5148.8 21.11.2017 01:01
2017-11-18_20-48-15__HM_32B1AE_Pwr__energyCalc 5155 21.11.2017 01:01
2017-11-18_20-49-19__HM_32B1AE_Pwr__energyCalc 5166.8 21.11.2017 01:01
2017-11-18_20-50-22__HM_32B1AE_Pwr__energyCalc 5178.5 21.11.2017 01:01
2017-11-18_20-51-07__HM_32B1AE_Pwr__energyCalc 5187.4 21.11.2017 01:01
2017-11-18_20-52-44__HM_32B1AE_Pwr__energyCalc 5206.5 21.11.2017 01:01
2017-11-18_20-53-18__HM_32B1AE_Pwr__energyCalc 5213.3 21.11.2017 01:01
2017-11-18_20-54-33__HM_32B1AE_Pwr__energyCalc 5228.3 21.11.2017 01:01
2017-11-18_20-54-41__HM_32B1AE_Pwr__energyCalc 5228.6 21.11.2017 01:01
2017-11-18_20-56-00__HM_32B1AE_Pwr__energyCalc 5230.8 21.11.2017 01:01
2017-11-18_20-58-27__HM_32B1AE_Pwr__energyCalc 5234.7 21.11.2017 01:01
2017-11-18_20-59-31__HM_32B1AE_Pwr__energyCalc 5236.5 21.11.2017 01:01
2017-11-18_20-59-39__HM_32B1AE_Pwr__energyCalc 5237.6 21.11.2017 01:01
2017-11-18_20-59-47__HM_32B1AE_Pwr__energyCalc 5238.9 21.11.2017 01:01
2017-11-18_20-59-59__HM_32B1AE_Pwr__energyCalc 5240.9 21.11.2017 01:01
2017-11-18_21-00-07__HM_32B1AE_Pwr__energyCalc 5241.1 21.11.2017 01:01
2017-11-18_21-00-40__HM_32B1AE_Pwr__energyCalc 5242 21.11.2017 01:01
2017-11-18_21-03-42__HM_32B1AE_Pwr__energyCalc 5247.1 21.11.2017 01:01
2017-11-18_21-04-58__HM_32B1AE_Pwr__energyCalc 5249.3 21.11.2017 01:01
2017-11-18_21-05-06__HM_32B1AE_Pwr__energyCalc 5250.4 21.11.2017 01:01
2017-11-18_21-05-14__HM_32B1AE_Pwr__energyCalc 5251.6 21.11.2017 01:01
2017-11-18_21-06-13__HM_32B1AE_Pwr__energyCalc 5261 21.11.2017 01:01
2017-11-18_21-06-30__HM_32B1AE_Pwr__energyCalc 5263.8 21.11.2017 01:01
2017-11-18_21-06-38__HM_32B1AE_Pwr__energyCalc 5265.1 21.11.2017 01:01
2017-11-18_21-08-55__HM_32B1AE_Pwr__energyCalc 5289.4 21.11.2017 01:01
2017-11-18_21-09-04__HM_32B1AE_Pwr__energyCalc 5291 21.11.2017 01:01
2017-11-18_21-10-34__HM_32B1AE_Pwr__energyCalc 5307.6 21.11.2017 01:01
2017-11-18_21-11-23__HM_32B1AE_Pwr__energyCalc 5316.9 21.11.2017 01:01
2017-11-18_21-12-58__HM_32B1AE_Pwr__energyCalc 5335.2 21.11.2017 01:01
2017-11-18_21-13-28__HM_32B1AE_Pwr__energyCalc 5341.1 21.11.2017 01:01
number_fetched_rows 347 21.11.2017 01:01
state done 21.11.2017 01:01
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 November 2017, 07:31:15
Das sieht gut aus und ich sehe auch keine Sprünge bzw. die Werte die angemeckert werden. Eine Erklärung habe ich momentan dafür nicht, ist etwas eigenartig. Ich würde ein Reboot des Rechners vorschlagen und diffValue neu auszuführen.
Günstig wäre auch verbose 5 zu setzen und das resultierende Log mal mit anzuhängen. Dann kann man sehen ob alles gut läuft.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 21 November 2017, 18:58:50
Reboot des Pi3 hat nichts gebracht. diffvalue bringt die gleichen Warnings.

Ein Logging mit Verbose 5 ab Shutdown Restart und anschließendem diffvalue ist anbei.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 November 2017, 19:06:10
Das Log ist sehr schwer zu lesen. Hast du NUR das DbRep-Device auf Verbose 5 gesetzt ?
Es sind zu viele andere Logmeldungen dazwischen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 November 2017, 19:20:19
Ach jetzt bin ich doch meiner eigenen Erinnerung zum Opfer gefallen  ;)

Habs programmiert und jetzt falsch interpretiert ....

Zitat2017-11-18 16:58:14 10.0000 -> 2017-11-18 17:01:13 31.5000
2017-11-18 17:06:27 10.5000 -> 2017-11-18 17:08:28 23.4000

Der rote Wert zeigt den Diff des vorherigen Datensatzes, der blaue Wert den Diff des darauf folgenden Datensatzes.
DIESE Werte überschreiten den Standard diffAccept-Wert von 20.

Du kannst also diffAccept hoch setzen, denn die Werte sind ok.  Bei mir fällt es nicht auf weil ich mit kWh arbeite und die Differenzen natürlich klein sind.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 21 November 2017, 21:39:09
^^ Dann hab ich es ja wieder erfolgreich in Erinnerung gerufen.

Und ja ich hatte nicht nur das DBRep auf Verbose 5 gesetzt, sondern in der fhem.cfg verbose 5 gesetzt.

;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 November 2017, 21:42:41
ZitatDann hab ich es ja wieder erfolgreich in Erinnerung gerufen.

Hast du gut gemacht  ;)

Und was sagt das Ergebnis, Ziel erreicht ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t.huber am 22 November 2017, 00:23:12
Jepp hat natürlich funktioniert. DiffAccept ist jetzt auf 40 und damit herrscht Ruhe.  ;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 November 2017, 21:16:25
Hallo miteinander,

habe im Wiki eine Anleitung hinterlegt wie man eine datenbankgestützte Auswertung von "EIN"-Zeiten von Geräten auswerten kann, also wie lange war mein Kühlschrank die letzte Woche eingeschaltet, oder die Heizung usw.

Innerhalb des Beispiels wird auch die Verwendung der userExit-Funktion für individuelle Auswertungen und daraus folgenden Aktionen erläutert.
Es ist sicher etwas Einarbeitung nötig um die Arbeitsweise zu verstehen, aber es kann sehr dabei helfen komplexe Auswertunegn zu erstellen und Aktionen daraus abzuleiten.

Wiki: https://wiki.fhem.de/wiki/Summe_aller_Einschaltzeiten_eines_Ger%C3%A4tes#DbRep-Device

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thyraz am 23 November 2017, 08:59:27
Hab deine Lösung jetzt nicht bis in die letzte Perl Zeile nachvollzogen.
Ein Gedanke dazu, weil ich neulich eine ähnliche Problemstellung hier vollzogen habe:
https://forum.fhem.de/index.php/topic,77724.msg717020.html#msg717020

Was passiert wenn 5min vor dem abgefragten 24h Zyklus der Zustand auf "On" geht und dann 6h so bleibt?
Werden die 5h 55min einberechnet?

Wahrscheinlich nicht, da man ein zusätzliches Select benötigen würde, welches den letzten Wert vor dem Zeitraum holt und den dann als Startwert des Zeitraumes nutzt oder?

Man könnte wahrscheinlich auch mein verlinktes SQL Statement leicht verändert über die DbRep sqlCmd Funktion ausführen.
Allerdings muss man sich dann in SQL einfuchsen und inwiefern die von DBLog unterstützten Datenbanken in ihrer Syntax voneinander abweichen weiß ich auch nicht. ;)

Auf der Haben-Seite wäre dafür, dass man keine extra Hilfsfunktionen in Perl braucht...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 November 2017, 09:46:34
Morgen Thyraz,

ZitatWas passiert wenn 5min vor dem abgefragten 24h Zyklus der Zustand auf "On" geht und dann 6h so bleibt?
Werden die 5h 55min einberechnet?
Ja, das wird berücksichtigt. Der Code reagiert nicht auf Flanken, sondern den Zustand/Inhalt jedes einzelnen Daten satzes.

Aber dennoch werde ich mir mal deine Ansätze anschauen, bin immer an so etwas interessiert.  :)

Ich wollte mit diesem Beispiel darstellen wie man diese userExit-Funktion für eigene Problemlösungen nutzen kann und die  Nutzer ermutigen sich damit zu beschäftigen. Kann für viele Aufgabenstellunge hilfreich sein.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 November 2017, 21:36:37
Hallo zusammen,

im ersten Beitrag ist die V6.2.1 hinterlegt.

Es gibt eine neue Funktion delSeqDoublets. Damit können sequentielle Dubletten aus der DB entfernt werden und so die Datenbank verkleinert werden.
Siehe auch diesen Thread: https://forum.fhem.de/index.php/topic,79931.0.html

Auszug aus der Commandref:

delSeqDoublets [adviceRemain | adviceDelete | delete]

zeigt bzw. löscht Datensätze wenn gleiche Werte von Device/Reading-Kombinationen aufeinanderfolgen. Nicht gelöscht werden der erste und der letzte Datensatz eines Tages sowie die Datensätze vor oder nach einem Wertewechsel (Datenbankfeld VALUE).
Die Attribute zur Zeit-,Device- und Reading-Abgrenzung werden dabei berücksichtigt.

    adviceRemain    : simuliert die nach der Operation in der DB verbleibenden Datensätze (es wird nichts gelöscht !)
    adviceDelete    : simuliert die zu löschenden Datensätze (es wird nichts gelöscht !)
    delete    : löscht die sequentiellen Dubletten (siehe Beispiel)

Wie immer würde ich mich über Testergebnisse freuen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Dezember 2017, 15:53:39
Hallo,

habe die Funktion delSeqDoublets noch etwas ausgebaut.
Es werden nun alle Aggregationsperioden unterstützt, nicht nur "day".
Das bedeutet dass man sich auch den ersten und letzten Wert einer Stunde (oder Woche) sich bei der Bereinigung erhalten kann.
Dazu muss man nur das Attribut aggregation entsprechend setzen.

Wenn nicht gesetzt (oder "no") wird automatisch der default "day" verwendet.

Version 6.2.2 im ersten Beitrag.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Dezember 2017, 20:00:14
Hallo miteinander,

ich war es leid, in den Attributen timeDiffToNow und timeOlderThan, welche einen Relativwert zur aktuellen Zeit darstellen, immer Sekunden angeben zu müssen. Wollte ich die Priode um x Tage verschieben, musste man das Ganze in Sekunden umrechnen.

Das Ungemach hat nun mit der V6.3.1 im ersten Beitrag ein Ende  :D. Es gibt nun folgende Eingabemöglichkeiten für diese beiden Attribute:

Eingabeformat Beispiel:

attr <Name> timeDiffToNow 86400
# die Startzeit wird auf "aktuelle Zeit - 86400 Sekunden" gesetzt
attr <Name> timeDiffToNow d:2 h:3 m:2 s:10
# die Startzeit wird auf "aktuelle Zeit - 2 Tage 3 Stunden 2 Minuten 10 Sekunden" gesetzt
attr <Name> timeDiffToNow m:600
# die Startzeit wird auf "aktuelle Zeit - 600 Minuten" gesetzt
attr <Name> timeDiffToNow h:2.5
# die Startzeit wird auf "aktuelle Zeit - 2,5 Stunden" gesetzt

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Dezember 2017, 22:15:05
Mit der V6.3.2 im ersten Beitrag kann mit dem Attribut fetchRoute die Leserichtung in der Datenbank zwischen absteigend und aufsteigend geändert werden.
Relevant wenn zu viele Datensätze existieren um sie anzuzeigen und dabei die ältesten statt die neuesten x interessieren.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: AndreasR am 06 Dezember 2017, 11:01:39
Hallo zusammen,

ich nutze das modul um einen SqlDump (clientside) zu speichern .. habe dabei nur das Problem das es um die 5 stunden dauert ..

Datenbank ist Mysql auf einem raspi3;
ca. 6 mio Datensätze in der History;
async eingestellt;


defmod DbBackUp DbRep logdb
attr DbBackUp DbLogExclude .*
attr DbBackUp DbLogInclude DumpRowsHistory
attr DbBackUp dumpDirLocal /mnt/tc/mySqlBackUp/     
attr DbBackUp dumpFilesKeep 6
attr DbBackUp event-on-update-reading state,DumpRowsHistory
attr DbBackUp executeAfterDump msg mySQL Der Dump wurde erfolgreich erstellt
attr DbBackUp executeBeforeDump set logdb commitCache
attr DbBackUp optimizeTablesBeforeDump 1
attr DbBackUp room ArbeitsRaum



defmod logdb DbLog ./configDB.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogInclude state,countCurrent,countHistory,userCommand,userCommandResult,statCountHistoryDayLast,statCountHistoryHourLast,statCountHistoryMonthLast,statCountHistoryYearLast
attr logdb DbLogSelectionMode Exclude/Include
attr logdb DbLogType History
attr logdb asyncMode 1
attr logdb event-on-change-reading state,countCurrent,countHistory,userCommand,userCommandResult,statCountHistoryDayLast,statCountHistoryHourLast,statCountHistoryMonthLast,statCountHistoryYearLast
attr logdb group Datenbank
attr logdb room ArbeitsRaum,system
attr logdb shutdownWait 60


index in der DB

...
KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`),
KEY `Report_Idx` (`TIMESTAMP`,`READING`) USING BTREE,
KEY `IDX_HISTORY` (`DEVICE`,`READING`,`TIMESTAMP`,`VALUE`) USING BTREE
...


hat jemand eine Idee ob das normal ist das es so lange dauert?  Oder an welcher Schraube ich drehen sollte  ...

Mit freundlichen Grüßen

AndreasR
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Dezember 2017, 11:44:06
Hallo Andreas,

ja du hast Möglichkeiten auf die Geschwindigkeit Einfluss zu nehmen.
Zu diesem Zweck gibt es speziell für die clientSide Option die Attribute:

* dumpMemlimit, dumpSpeed

Die Parameter sind zunächst sehr konservativ eingestellt. Du kannst sie setzen zum Beispiel auf:


dumpMemlimit  100000000
dumpSpeed      10000000


Es muss dabei ein Verhältnisfaktor von mindestens 1:10 eingehalten werden, was aber durch das Modul geprüft wird.

Du kannst mit diesem Parametern spielen um für deine Hardware die optimale Einstellung zu finden. Achte natürlich darauf dass du deinen Raspi nicht überforderst und du dein System lahmlegst wenn du zuviel zweist. Geh am Besten vorsichtig in kleinen Schritten vor und beobachte dabei den Ressourcenverbrauch (CPU/RAM).

Nähere Infos dazu stehen in der Commandref.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: AndreasR am 06 Dezember 2017, 13:38:12
Danke Heiko,

mein erster versuch mit: 


dumpMemlimit  1000000
dumpSpeed      100000


nur noch 38 Minuten. Die Belastung für das System ist im Vergleich zu den Standardeinstellungen nicht gestiegen.

und  beim  Versuch mit 5000000 / 500000  ist er in 19 Minuten durch ..

Das reicht mir erstmal :-)

Danke

AndreasR
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 06 Dezember 2017, 18:43:54
EDIT: Falscher Thread, wollte nach 93_DbLog....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2017, 12:48:12
Hallo AndreasR,

ich habe mal eine Frage, da ich keinen Raspi im Einsatz habe.

Zitat
mein erster versuch mit:

dumpMemlimit  1000000
dumpSpeed      100000

nur noch 38 Minuten. Die Belastung für das System ist im Vergleich zu den Standardeinstellungen nicht gestiegen.

Wäre es aus deiner Sicht verantwortbar die Default-Werte auf diese/deine Einstellung zu ändern ?
Die defaults waren für Raspi-Nutzer gedacht, aber wie es ausschaut kann man die durchaus etwas anheben. Dadurch hat der Nutzer nicht gleich am Anfang eine negative Erfahrung durch die lange Laufzeit.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: AndreasR am 07 Dezember 2017, 20:22:31
Hallo Heiko,

Ich denke das es für den Raspi3 ok ist - und für jene die einen älteren einsetzen könnte man das in commandref und dem Wiki hervorheben.

Mit freundlichen Grüßen

Andreas


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sascha_F am 09 Dezember 2017, 12:03:12
Hi DS_Starter,

ist nichts großes, aber mir würde es sehr helfen, wenn die Auswahlmöglichkeiten für "timestamp_begin" und "timestamp_end" per DropDown zur Verfügung stehen würden.

Aktuell würde dieses aber ja mit der freien Angabe "YYYY-MM-DD HH:MM:SS" kollidieren. Vielleicht eine Möglichkeit, per DropDown "eigener Zeitraum" zu wählen und diesen über ein weiteres ATTR abzufragen?

Viele Grüße
Sascha
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2017, 13:27:24
... oder per standard-widgetoverride einfach das Datumsauswahlfeld festlegen?
(nur so als Idee)

SG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2017, 14:15:25
Zitatoder per standard-widgetoverride einfach das Datumsauswahlfeld festlegen?
An welches Standard-Widget, also was nicht extra nachinstalliert werden muss, dachtest du dabei ?

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 09 Dezember 2017, 15:14:20
Warum darf es nicht nachinstalliert werden?
So könnte der Benutzer selbst entscheiden, ob er es benötigt oder nicht...

Ich dachte an etwas wie

attr calc_Test widgetOverride timestamp_begin:datetime,datepicker:true,weeks:false,dayOfWeekStart:1,inline:true,format:Y-m-d_H:i

aber da fehlt noch etwas finetuning mit dem Format-Attribut hinten.
Bin jedoch unterwegs und am Handy lässt sich das schwer testen.

Das Widget befindet sich im CONTRIB unter
https://svn.fhem.de/fhem/trunk/fhem/contrib/Widgets/DateTimePicker/

Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2017, 15:36:51
Hi Joe,

da haben wir uns wahrscheinlich falsch verstanden.
Ich meinte, dass ich per default im Code nur die Widgets verankern kann, die jeder Nutzer auch per default in seiner Installation zur Verfügung hat.

Natürlich kann sich jeder nach seinem Geschmack weitere Widgets nachinstallieren und anwenden.
So auch für diese Attribute.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2017, 17:26:31
Hallo zusammen,

in der Version 6.4.0 (erster Beitrag) habe ich die Unterstützung für das datetime-Widget für Attribute timestamp_begin,timestamp_end mit aufgenommen.
Ich musste ein paar kleine Anpassungen machen weil das Widget das verlangte Format nicht so wie benötigt rausbringt.
Wenn ihr es nutzen wollt geht so vor:

* installatiion des Widget: https://forum.fhem.de/index.php/topic,35736.0.html

* im DbRep-Device das Attr widgetOverride folgendermaßen setzen:
  attr widgetOverride timestamp_begin:datetime,theme:default,inline:true,step:1,dayOfWeekStart:1,timepicker:true,format:Y-m-d_H:i timestamp_end:datetime,theme:default,inline:true,step:1,dayOfWeekStart:1,timepicker:true,format:Y-m-d_H:i

* restart

Danach können die Zeiten per Widget ausgewählt werden. Nachteil ist, dass keine Sekunden ausgewählt werden können (zumindest mir nicht bekannt).
D.h. Sekunden setze ich im Modul in dem Fall immer auf "00".

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 12 Dezember 2017, 23:23:34
Hallo Heiko,

könntest Du mir bitte die Version 6.3.2 noch mal schicken?
Ich komme mit dem Widget nit klar und kann jetzt kein Timestamp_begin/end mehr eintragen.

gruß
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2017, 08:47:46
Hallo Thomas,

hier nochmal die V6.3.2.
Aber du musst eigentlich nur das Attr widgetOverride  löschen, Browser refresh und dann geht alles wieder wie gewohnt.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: AndreasR am 13 Dezember 2017, 10:23:56
Hallo Heiko,

denkst du das es möglich ist das ein weiteres Format zu den sqlResultFormat hinzugefügt wird?

Ich verwende aktuell "mline" und lasse mir das SqlResult via Telegramm schicken wenn zu viele Datensätze in der letzten stunde aufgelaufen sind. Leider ist es jedoch so das die Trennzeichen | stören - und Telegramm (oder msg) die einräge zwischen den Trennzeichen verschluckt ..
Daher wäre es großartig wenn ein Format Text, nur mit Zeilenwechseln, zur verfügung stehen würde. Klar das ich das Ergebniss auch selbst durch eine Funktion in der 99_utils parsen könnte - aber eingebaut wäre eleganter :-)

Danke

Andreas 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 13 Dezember 2017, 10:27:34
Hallo Andreas,

Du kannst doch mit Perl in {}
und einer normalen Ersetzungsfunktion ganz einfach die | durch beliebige Zeichen ersetzen und die die Ausgabe somit so zusammenbauen, wie du
sie benötigst. Das geht auch direkt im selben notify|DOIF, je nachdem was du für den Telegramaufruf nutzt....

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Dezember 2017, 21:59:59
Hi Andreas, hi Joe,

habe die Idee/den Wunsch von Andreas mal aufgenommen und ein Attribut "sqlResultFieldSep" aufgenommen, welches eine Auswahl von möglichen Feldseparatoren "| : /" zur Verfügung stellt. Damit kann man den default "|" bei Kommando sqlCmd abändern.

Bitte pobierts mal aus -> V6.4.1 im ersten Beitrag.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 Dezember 2017, 10:07:47
Zitat von: DS_Starter am 13 Dezember 2017, 08:47:46
Hallo Thomas,

hier nochmal die V6.3.2.
Aber du musst eigentlich nur das Attr widgetOverride  löschen, Browser refresh und dann geht alles wieder wie gewohnt.

Grüße
Heiko

Hallo Heiko,

wenn ich in der V6.4.0 als Attribut Timestamp_xxx auswähle, ist das Attributfeld nur noch als DropDown ohne Inhalt auswählbar. Ich kann keinen Wert ala "2017_10_10 00:00:00" eingeben.

ich hab es jetzt mit der 6.3.2 versucht, adviceRemain und adviceDelete funktioniert. Wenn ich jedoch die Zeilen mit delete löschen will, kommt Fehlermeldung: DBD::mysql::st execute failed: called with 2 bind variables when 0 are needed at ./FHEM/93_DbRep.pm line 3954.

FHEM hab ich nach Reload neu gestartet...

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Dezember 2017, 10:47:35
Hallo Thomas,

Zitatwenn ich in der V6.4.0 als Attribut Timestamp_xxx auswähle, ist das Attributfeld nur noch als DropDown ohne Inhalt auswählbar. Ich kann keinen Wert ala "2017_10_10 00:00:00" eingeben
Komisch, konnte ich bei mir nicht feststellen. vllt. eine Browsersache wegen javascript.

Wegen dem bind- Fehler .... mach mal bitte ein verbose 4 log , sowie list und stelle es hier rein. Ich habe das schon mal an anderer Stelle gelesen und konnte es bei mir bisher nicht nachvollziehen.


Grüsse
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 Dezember 2017, 11:08:13
ich hoffe ich hab das richtig gemacht...:
2017.12.14 11:05:44 4: DbRep DBReporting - -------- New selection ---------
2017.12.14 11:05:44 4: DbRep DBReporting - Aggregation: no
2017.12.14 11:05:44 4: DbRep DBReporting - Command: delSeqDoublets
2017.12.14 11:05:44 4: DbRep DBReporting - Timestamp begin human readable: 2017-08-01 00:00:00
2017.12.14 11:05:44 4: DbRep DBReporting - Timestamp end human readable: 2017-11-01 00:00:00
2017.12.14 11:05:44 4: DbRep DBReporting -> Start BlockingCall delseqdoubl_DoParse
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-01 00:00:00' AND TIMESTAMP < '2017-08-02' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-02' AND TIMESTAMP < '2017-08-03' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-03' AND TIMESTAMP < '2017-08-04' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-04' AND TIMESTAMP < '2017-08-05' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-05' AND TIMESTAMP < '2017-08-06' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-06' AND TIMESTAMP < '2017-08-07' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-07' AND TIMESTAMP < '2017-08-08' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-08' AND TIMESTAMP < '2017-08-09' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-09' AND TIMESTAMP < '2017-08-10' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-10' AND TIMESTAMP < '2017-08-11' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-11' AND TIMESTAMP < '2017-08-12' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-12' AND TIMESTAMP < '2017-08-13' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-13' AND TIMESTAMP < '2017-08-14' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-14' AND TIMESTAMP < '2017-08-15' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-15' AND TIMESTAMP < '2017-08-16' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-16' AND TIMESTAMP < '2017-08-17' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-17' AND TIMESTAMP < '2017-08-18' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-18' AND TIMESTAMP < '2017-08-19' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-19' AND TIMESTAMP < '2017-08-20' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-20' AND TIMESTAMP < '2017-08-21' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-21' AND TIMESTAMP < '2017-08-22' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-22' AND TIMESTAMP < '2017-08-23' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-23' AND TIMESTAMP < '2017-08-24' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-24' AND TIMESTAMP < '2017-08-25' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-25' AND TIMESTAMP < '2017-08-26' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-26' AND TIMESTAMP < '2017-08-27' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-27' AND TIMESTAMP < '2017-08-28' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-28' AND TIMESTAMP < '2017-08-29' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-29' AND TIMESTAMP < '2017-08-30' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-30' AND TIMESTAMP < '2017-08-31' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-31' AND TIMESTAMP < '2017-09-01' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-01' AND TIMESTAMP < '2017-09-02' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-02' AND TIMESTAMP < '2017-09-03' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-03' AND TIMESTAMP < '2017-09-04' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-04' AND TIMESTAMP < '2017-09-05' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-05' AND TIMESTAMP < '2017-09-06' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-06' AND TIMESTAMP < '2017-09-07' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-07' AND TIMESTAMP < '2017-09-08' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-08' AND TIMESTAMP < '2017-09-09' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-09' AND TIMESTAMP < '2017-09-10' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-10' AND TIMESTAMP < '2017-09-11' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-11' AND TIMESTAMP < '2017-09-12' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-12' AND TIMESTAMP < '2017-09-13' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-13' AND TIMESTAMP < '2017-09-14' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-14' AND TIMESTAMP < '2017-09-15' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-15' AND TIMESTAMP < '2017-09-16' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-16' AND TIMESTAMP < '2017-09-17' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-17' AND TIMESTAMP < '2017-09-18' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-18' AND TIMESTAMP < '2017-09-19' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-19' AND TIMESTAMP < '2017-09-20' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-20' AND TIMESTAMP < '2017-09-21' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-21' AND TIMESTAMP < '2017-09-22' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-22' AND TIMESTAMP < '2017-09-23' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-23' AND TIMESTAMP < '2017-09-24' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-24' AND TIMESTAMP < '2017-09-25' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-25' AND TIMESTAMP < '2017-09-26' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-26' AND TIMESTAMP < '2017-09-27' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-27' AND TIMESTAMP < '2017-09-28' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-28' AND TIMESTAMP < '2017-09-29' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-29' AND TIMESTAMP < '2017-09-30' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-30' AND TIMESTAMP < '2017-10-01' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-01' AND TIMESTAMP < '2017-10-02' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-02' AND TIMESTAMP < '2017-10-03' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-03' AND TIMESTAMP < '2017-10-04' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-04' AND TIMESTAMP < '2017-10-05' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-05' AND TIMESTAMP < '2017-10-06' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-06' AND TIMESTAMP < '2017-10-07' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-07' AND TIMESTAMP < '2017-10-08' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-08' AND TIMESTAMP < '2017-10-09' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-09' AND TIMESTAMP < '2017-10-10' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-10' AND TIMESTAMP < '2017-10-11' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-11' AND TIMESTAMP < '2017-10-12' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-12' AND TIMESTAMP < '2017-10-13' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-13' AND TIMESTAMP < '2017-10-14' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-14' AND TIMESTAMP < '2017-10-15' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-15' AND TIMESTAMP < '2017-10-16' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-16' AND TIMESTAMP < '2017-10-17' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-17' AND TIMESTAMP < '2017-10-18' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-18' AND TIMESTAMP < '2017-10-19' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-19' AND TIMESTAMP < '2017-10-20' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-20' AND TIMESTAMP < '2017-10-21' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-21' AND TIMESTAMP < '2017-10-22' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-22' AND TIMESTAMP < '2017-10-23' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-23' AND TIMESTAMP < '2017-10-24' ;
2017.12.14 11:05:44 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 00:24:18' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 00:39:19' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 00:54:19' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 01:09:29' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 01:24:30' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 01:39:31' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 01:54:32' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 02:09:34' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 02:24:36' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 02:39:38' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 02:54:38' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 03:09:40' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 03:24:42' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 03:39:42' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 03:54:43' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 04:09:44' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 04:24:45' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 04:39:47' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 04:54:47' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 05:09:49' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 05:24:49' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 05:39:50' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 05:54:50' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 06:09:51' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 06:24:51' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 06:39:52' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 06:54:55' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 07:09:56' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 07:24:57' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 07:40:05' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 07:55:07' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 08:10:08' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 08:25:09' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 08:40:10' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 08:55:31' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='1';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 09:10:32' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='1';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 09:29:04' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 09:44:06' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 09:59:08' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 10:14:08' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 10:29:09' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 10:44:09' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 10:59:10' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 11:14:11' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 11:29:11' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 11:44:12' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 11:59:14' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 12:14:14' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 12:29:15' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 12:44:16' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 12:59:16' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 13:14:17' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 13:29:19' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 13:44:21' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 13:59:21' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 14:14:23' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 14:29:28' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 14:44:28' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 14:59:29' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 15:14:31' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 15:29:33' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 15:44:33' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 15:59:35' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 16:14:35' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 16:29:35' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 16:44:35' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 16:59:36' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 17:14:37' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 17:29:38' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 17:44:38' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 17:59:39' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 18:14:39' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 18:29:39' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 18:44:40' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 18:59:41' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 19:14:43' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 19:42:51' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 19:57:51' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 20:12:53' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 20:27:57' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 20:42:59' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 20:57:59' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 21:13:00' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 21:28:01' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 21:43:01' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 21:58:03' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 22:13:05' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 22:28:05' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 22:43:05' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 22:58:05' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 23:13:06' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: delete FROM history where TIMESTAMP = '2017-10-23 23:28:07' AND DEVICE = 'MAX_159796' AND READING = 'onoff' AND VALUE ='0';
2017.12.14 11:05:45 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-24' AND TIMESTAMP < '2017-10-25' ;
2017.12.14 11:05:45 2: DbRep DBReporting - DBD::mysql::st execute failed: called with 2 bind variables when 0 are needed at ./FHEM/93_DbRep.pm line 3954.

2017.12.14 11:05:45 4: DbRep DBReporting -> BlockingCall delseqdoubl_DoParse finished
2017.12.14 11:05:45 4: DbRep DBReporting -> Start BlockingCall delseqdoubl_ParseDone
2017.12.14 11:05:45 4: DbRep DBReporting -> BlockingCall delseqdoubl_ParseDone finished
2017.12.14 11:05:56 3: ESPEasy: set ESPEasy_NodeMCU_2 neopixel 85 0 0 0


Edit: Hier noch das Listing...

[code]
Internals:
   DATABASE   fhem
   DEF        DbLog
   LASTCMD    delSeqDoublets delete
   NAME       DBReporting
   NOTIFYDEV  global,DBReporting
   NR         625
   NTFY_ORDER 50-DBReporting
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       0
   VERSION    6.3.2
   HELPER:
     DBLOGDEVICE DbLog
     CV:
       aggregation day
       aggsec     86400
       destr      2017-11-01
       dsstr      2017-08-01
       epoch_seconds_end 1509490800
       mestr      11
       msstr      08
       testr      00:00:00
       tsstr      00:00:00
       wdadd     
       yestr      2017
       ysstr      2017
   Helper:
     DBLOG:
       2017-10-21_07-23-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241586.09021
           VALUE      0

       2017-10-21_07-38-54__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_07-53-56__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_08-08-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_08-23-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_08-38-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241586.09021
           VALUE      1

       2017-10-21_08-53-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-21_09-08-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-21_09-21-19__MAX_159796__onoff:
         DbLog:
           TIME       1513241586.09021
           VALUE      0

       2017-10-21_09-36-20__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_09-51-31__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-06-32__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-21-32__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-36-35__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-52-20__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_11-51-53__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-08-03__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-23-04__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-38-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-53-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-08-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-23-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-38-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-53-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_14-22-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_14-37-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_14-52-56__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-07-57__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-22-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-37-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-52-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-08-00__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-23-01__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-38-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-53-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-08-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-23-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-38-11__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-53-17__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-08-21__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-23-22__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-38-43__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-53-57__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-08-59__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-23-59__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-39-01__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-54-02__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-09-03__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-24-04__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-39-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-54-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-09-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-24-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-39-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-54-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-09-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-24-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-39-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-54-12__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_23-09-14__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_23-24-14__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_23-39-16__MAX_159796__onoff:
         DbLog:
           TIME       1513241586.09021
           VALUE      0

       2017-10-21_23-54-17__MAX_159796__onoff:
         DbLog:
           TIME       1513241586.09021
           VALUE      0

       2017-10-22_00-09-18__MAX_159796__onoff:
         DbLog:
           TIME       1513241586.09021
           VALUE      0

       2017-10-22_00-24-19__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_00-39-29__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_00-54-30__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-09-30__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-24-32__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-39-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-54-38__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_02-09-40__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_02-24-42__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
    &n
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Dezember 2017, 11:23:57
Hast du alles richtig gemacht. Ich kann nur die Ursache des Fehlers nicht erkennen.
Mach nochmal ein list von deinem DBrep device.
und nochmal einen erneuten Lauf, aber mit Endtermin 24.10.

Grüsse
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 Dezember 2017, 11:39:30
hier das neue Log:

2017.12.14 11:36:40 4: DbRep DBReporting - -------- New selection ---------
2017.12.14 11:36:40 4: DbRep DBReporting - Aggregation: no
2017.12.14 11:36:40 4: DbRep DBReporting - Command: delSeqDoublets
2017.12.14 11:36:40 4: DbRep DBReporting - Timestamp begin human readable: 2017-08-01 00:00:00
2017.12.14 11:36:40 4: DbRep DBReporting - Timestamp end human readable: 2017-10-24 00:00:00
2017.12.14 11:36:40 4: DbRep DBReporting -> Start BlockingCall delseqdoubl_DoParse
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-01 00:00:00' AND TIMESTAMP < '2017-08-02' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-02' AND TIMESTAMP < '2017-08-03' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-03' AND TIMESTAMP < '2017-08-04' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-04' AND TIMESTAMP < '2017-08-05' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-05' AND TIMESTAMP < '2017-08-06' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-06' AND TIMESTAMP < '2017-08-07' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-07' AND TIMESTAMP < '2017-08-08' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-08' AND TIMESTAMP < '2017-08-09' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-09' AND TIMESTAMP < '2017-08-10' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-10' AND TIMESTAMP < '2017-08-11' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-11' AND TIMESTAMP < '2017-08-12' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-12' AND TIMESTAMP < '2017-08-13' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-13' AND TIMESTAMP < '2017-08-14' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-14' AND TIMESTAMP < '2017-08-15' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-15' AND TIMESTAMP < '2017-08-16' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-16' AND TIMESTAMP < '2017-08-17' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-17' AND TIMESTAMP < '2017-08-18' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-18' AND TIMESTAMP < '2017-08-19' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-19' AND TIMESTAMP < '2017-08-20' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-20' AND TIMESTAMP < '2017-08-21' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-21' AND TIMESTAMP < '2017-08-22' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-22' AND TIMESTAMP < '2017-08-23' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-23' AND TIMESTAMP < '2017-08-24' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-24' AND TIMESTAMP < '2017-08-25' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-25' AND TIMESTAMP < '2017-08-26' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-26' AND TIMESTAMP < '2017-08-27' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-27' AND TIMESTAMP < '2017-08-28' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-28' AND TIMESTAMP < '2017-08-29' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-29' AND TIMESTAMP < '2017-08-30' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-30' AND TIMESTAMP < '2017-08-31' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-08-31' AND TIMESTAMP < '2017-09-01' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-01' AND TIMESTAMP < '2017-09-02' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-02' AND TIMESTAMP < '2017-09-03' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-03' AND TIMESTAMP < '2017-09-04' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-04' AND TIMESTAMP < '2017-09-05' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-05' AND TIMESTAMP < '2017-09-06' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-06' AND TIMESTAMP < '2017-09-07' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-07' AND TIMESTAMP < '2017-09-08' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-08' AND TIMESTAMP < '2017-09-09' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-09' AND TIMESTAMP < '2017-09-10' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-10' AND TIMESTAMP < '2017-09-11' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-11' AND TIMESTAMP < '2017-09-12' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-12' AND TIMESTAMP < '2017-09-13' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-13' AND TIMESTAMP < '2017-09-14' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-14' AND TIMESTAMP < '2017-09-15' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-15' AND TIMESTAMP < '2017-09-16' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-16' AND TIMESTAMP < '2017-09-17' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-17' AND TIMESTAMP < '2017-09-18' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-18' AND TIMESTAMP < '2017-09-19' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-19' AND TIMESTAMP < '2017-09-20' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-20' AND TIMESTAMP < '2017-09-21' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-21' AND TIMESTAMP < '2017-09-22' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-22' AND TIMESTAMP < '2017-09-23' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-23' AND TIMESTAMP < '2017-09-24' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-24' AND TIMESTAMP < '2017-09-25' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-25' AND TIMESTAMP < '2017-09-26' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-26' AND TIMESTAMP < '2017-09-27' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-27' AND TIMESTAMP < '2017-09-28' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-28' AND TIMESTAMP < '2017-09-29' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-29' AND TIMESTAMP < '2017-09-30' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-09-30' AND TIMESTAMP < '2017-10-01' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-01' AND TIMESTAMP < '2017-10-02' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-02' AND TIMESTAMP < '2017-10-03' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-03' AND TIMESTAMP < '2017-10-04' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-04' AND TIMESTAMP < '2017-10-05' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-05' AND TIMESTAMP < '2017-10-06' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-06' AND TIMESTAMP < '2017-10-07' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-07' AND TIMESTAMP < '2017-10-08' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-08' AND TIMESTAMP < '2017-10-09' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-09' AND TIMESTAMP < '2017-10-10' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-10' AND TIMESTAMP < '2017-10-11' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-11' AND TIMESTAMP < '2017-10-12' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-12' AND TIMESTAMP < '2017-10-13' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-13' AND TIMESTAMP < '2017-10-14' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-14' AND TIMESTAMP < '2017-10-15' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-15' AND TIMESTAMP < '2017-10-16' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-16' AND TIMESTAMP < '2017-10-17' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-17' AND TIMESTAMP < '2017-10-18' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-18' AND TIMESTAMP < '2017-10-19' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-19' AND TIMESTAMP < '2017-10-20' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-20' AND TIMESTAMP < '2017-10-21' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-21' AND TIMESTAMP < '2017-10-22' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-22' AND TIMESTAMP < '2017-10-23' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-23' AND TIMESTAMP < '2017-10-24' ;
2017.12.14 11:36:40 4: DbRep DBReporting - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE FROM history where DEVICE = 'MAX_159796' AND READING = 'onoff' AND TIMESTAMP >= '2017-10-24' AND TIMESTAMP < '2017-10-24 00:00:00' ;
2017.12.14 11:36:40 4: DbRep DBReporting -> BlockingCall delseqdoubl_DoParse finished
2017.12.14 11:36:40 4: DbRep DBReporting -> Start BlockingCall delseqdoubl_ParseDone
2017.12.14 11:36:40 4: DbRep DBReporting -> BlockingCall delseqdoubl_ParseDone finished


und das List...

[code]
Internals:
   DATABASE   fhem
   DEF        DbLog
   LASTCMD    delSeqDoublets delete
   NAME       DBReporting
   NOTIFYDEV  global,DBReporting
   NR         625
   NTFY_ORDER 50-DBReporting
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   VERSION    6.3.2
   HELPER:
     DBLOGDEVICE DbLog
     CV:
       aggregation day
       aggsec     86400
       destr      2017-10-24
       dsstr      2017-08-01
       epoch_seconds_end 1508796000
       mestr      10
       msstr      08
       testr      00:00:00
       tsstr      00:00:00
       wdadd     
       yestr      2017
       ysstr      2017
   Helper:
     DBLOG:
       2017-10-21_07-23-08__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-21_07-38-54__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_07-53-56__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_08-08-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_08-23-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_08-38-07__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      1

       2017-10-21_08-53-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-21_09-08-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-21_09-21-19__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-21_09-36-20__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_09-51-31__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-06-32__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-21-32__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-36-35__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_10-52-20__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_11-51-53__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-08-03__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-23-04__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-38-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_12-53-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-08-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-23-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-38-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_13-53-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_14-22-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_14-37-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_14-52-56__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-07-57__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-22-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-37-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_15-52-58__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-08-00__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-23-01__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-38-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_16-53-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-08-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-23-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-38-11__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_17-53-17__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-08-21__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-23-22__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-38-43__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_18-53-57__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-08-59__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-23-59__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-39-01__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_19-54-02__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-09-03__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-24-04__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-39-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_20-54-06__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-09-07__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-24-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-39-08__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_21-54-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-09-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-24-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-39-10__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_22-54-12__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_23-09-14__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_23-24-14__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-21_23-39-16__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-21_23-54-17__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-22_00-09-18__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-22_00-24-19__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_00-39-29__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_00-54-30__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-09-30__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-24-32__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-39-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_01-54-38__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_02-09-40__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_02-24-42__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_02-39-44__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_02-54-45__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_03-09-46__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_03-24-46__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_03-39-47__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_03-54-49__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_04-10-16__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_04-25-17__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_04-40-18__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_04-55-18__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_05-10-20__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_05-25-21__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_05-40-21__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_05-55-22__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_06-10-24__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_06-25-25__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_06-40-25__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_06-55-26__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_07-10-27__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_07-25-28__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_07-40-29__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_07-55-30__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_08-10-31__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_08-25-33__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_08-40-34__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_08-55-36__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_09-10-37__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_09-25-39__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_09-40-40__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_09-55-41__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_10-10-42__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_10-25-44__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_10-40-44__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_10-55-47__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_11-10-47__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_11-25-50__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_11-40-50__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_11-55-52__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_12-10-54__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_12-18-37__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      1

       2017-10-22_12-33-38__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-22_12-48-40__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-22_13-03-41__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-22_13-13-54__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-22_13-13-56__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      1

       2017-10-22_13-28-57__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      1

       2017-10-22_13-37-07__MAX_159796__onoff:
         DbLog:
           TIME       1513247718.29388
           VALUE      0

       2017-10-22_13-52-09__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_14-07-11__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_14-22-11__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_14-37-12__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_14-52-13__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_15-07-14__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_15-22-15__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_15-37-16__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_15-52-17__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_16-07-18__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_16-22-19__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_16-37-21__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_16-52-22__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_17-07-22__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_17-22-24__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_17-37-25__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_17-52-27__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_18-07-29__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_18-22-29__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_18-37-30__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_18-52-31__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_19-07-33__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_19-22-35__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_19-37-36__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_19-53-40__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_20-08-59__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_20-24-00__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_20-39-00__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_20-54-01__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_21-09-02__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_21-24-02__MAX_159796__onoff:
         DbLog:
           TIME       1513241832.72518
           VALUE      0

       2017-10-22_21-39-04__MAX_159796__onoff:
   
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Dezember 2017, 11:46:33
Hmmm, das list bringt auch keine neuen Erkenntnisse. Aberves wird klar dass das delete funktioniert, nur irgendwann gibt es in dem abzuarbeitenden Datensätzen einen der nicht den Anforderungen entspricht und dann kommt der Fehler.
Du kannst die Läufe mit verschiedenen Zeitabgrenzungen wiederholen.

Aber ich muss am WE schauen  ob ich das verbose 4 logging etwas verändern kann um mehr zu sehen.

Grüsse
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 Dezember 2017, 19:43:17
Hallo Heiko,

danke Dir.
Mir ist aufgefallen, dass der Fehler bei kleinen Datenmengen (<62 Zeilen) nicht auftritt. Wobei ich noch nicht genau sagen kann ab welcher Grenze es zu dem Fehler kommt. Bei zu löschenden Zeilen = 62 trat der Fehler auf, die Zeilen wurden jedoch komplett gelöscht. Bei 185 zu löschenden Zeilen trat der Fehler auf, es wurden 92 gelöscht. Nach erneutem Aufruf (gleiche Parameter) wurde der Rest gelöscht (mit Fehlermeldung).
Danach hatte ich einen Monat ausgewählt. Hier war wohl die Zeilenmenge zu groß und FHEM hat sich aufgehängt. Der Perl Task lief mit ~75% CPU Last und FHEM meldete sich nach ca. 3h nicht mehr. Stop/Start FHEM oder Kill half da auch nicht mehr.

lg

Edit: hatte gestern noch etwas rumgespielt. Habe einen Tag aufgerufen bei dem >30000 Lines gelöscht werden sollten. Nach der Analyse mit adviceDelete blieb der fhem/perl Thread bei ~70% CPU Last. FHEM reagierte zwar noch, war aber dadurch halt sehr träge. Erst nach shutdown restart war alles wieder gut... zum löschen bin ich noch nicht gekommen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2017, 11:45:39
Hallo Thomas, @all,

habe das Problem bzgl. der "delSeqDoublets delete" Funktion gefunden und beseitigen können. Nachdem ich das bei mir nachstellen konnte, hat es sich herauskristallisiert, dass der Fehler nur auftrat nachdem ein tatsächlicher Löschvorgang durchgeführt wurde und danach ein weiterer Select vollzogen wurde (die Anzahl der Datensätze war nebensächlich) -> habe dann den Progammierfehler (Asche auf mein Haupt :) ) auch gleich gefunden.

Die andere Sache, Thomas, bezüglich:
ZitatNach der Analyse mit adviceDelete blieb der fhem/perl Thread bei ~70% CPU Last. FHEM reagierte zwar noch, war aber dadurch halt sehr träge. Erst nach shutdown restart war alles wieder gut... zum löschen bin ich noch nicht gekommen.

Das hat etwas damit zu tun, dass im Falle sehr großer an den Client zurückgelieferter Datenmengen (anzuzeigende Datensätze), es zu einer Übrlastung der Browsersession kommen kann. Das hat dann die dargestellten negativen Auswirkungen.
In der neuen Version habe ich die Berücksichtigung des Attributes "limit" (default: 1000) mit eingebaut. Bis jetzt war das bei "fetchrows" der Fall, wer das kennt.
Es wirkt sich so aus, dass bei "delSeqDoublets adviceDelete" bzw. "delSeqDoublets adviceRemain" nur die durch "limit" begrenzte Anzahl von Datensätzen zur Anzeige im Browser zurückgeliefert werden. Das bewahrt dann vor Überlastsituationen wenn z.B. 100000 zu löschende Datensätze angezeigt werden sollen.
Durch das Attribut "limit" kann man sich die Menge der anzuzeigenden Datensätze abändern.

Auf die eigentliche Löschfunktion  "delSeqDoublets delete" hat diese Einstellung keinen Einfluss.

V6.4.2 im ersten Beitrag, probierts mal bitte aus ...

EDIT:  setzt euch das Attribut "event-on-update-reading" generell auf state, damit nicht bei jedem generierten Reading ein Event erzeugt wird.
Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 15 Dezember 2017, 12:15:45
perfekt, Danke Dir!

ich probier das nachher mal aus.
hoffentlich krieg ich das hin ohne dem Widget :)

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 15 Dezember 2017, 16:03:37
Vielen Dank!
es läuft.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2017, 16:06:54
ZitatVielen Dank!
es läuft.

sehr schön  :)
Ich mache die Version fertig und checke sie dann ein.
Danke für den Test !

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 15 Dezember 2017, 17:23:43
Hi,
ich hab ein Geschwindigkeits-Issue bemerkt:

mit phpmyadmin:
select * from history limit 1;
Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0522 Sekunden.)

mit DbRep:
state running 2017-12-15 17:17:21
( jetzt ist es mittlerweile 17:22:46)

Es laufen drei weitere tw. große Abfragen auf die Datenbank. Aber dass phpmyadmin *soo* viel schneller ist...

Grüße.
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2017, 19:13:44
Mein DbRep ist sogar noch schneller als dein phpMyAdmin. Guckst du:

Readings
SqlResultRow_1                                   2017-12-01 22:46:09|sysmon|SYSMON|stat_cpu2_percent: 0.30 0.00 0.17 99.53 0.00 0.00 0.00|stat_cpu2_percent|0.30 0.00 0.17 99.53 0.00 0.00 0.00|                                                                          2017-12-15 19:08:40
background_processing_time               0.0336                                    2017-12-15 19:08:40
sqlCmd                                                  select * from history limit 1;   2017-12-15 19:08:40
sqlResultNumRows                                1                                            2017-12-15 19:08:40
sql_processing_time                             0.0319                                    2017-12-15 19:08:40
state                                                     done                                       2017-12-15 19:08:40

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: choenig am 17 Dezember 2017, 10:49:22
Hi Heiko,

vielen Dank erstmal für das 'delSeqDoublets', sowas suche ich schon lange :-).

Ich habe aber Probleme mit Strings, die ' oder " enthalten, solche werden nicht gelöscht und erzeuge Fehler.

Lösung für ' ist um Zeile ~3995 herum das $val zu escapen:
$val =~ s/'/''/g; # escape ' with '' for MySQL

Edit: Das selbe sollte auch für die $read gemacht werden (mindestens).

Das Problem mit " rührt daher, dass Du in Zeile 3995 alle " und \n löscht:
$val =~ tr/"\n"//d;

Ich kann leider nicht nachvollziehen, wieso Du das machst, entferne ich aber die " dann funktioniert es erstmal für meine betroffenen Strings aus dem SONOS Umfeld. Falls es aber Einträge mit \n gibt, würden die vermutlich weiterhin nicht gelöscht werden.

LG
Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: choenig am 17 Dezember 2017, 11:53:39
Hi,

ich habe leider noch ein Problem gefunden, ausgelöst durch krude Werte von Pushover:

Folgender Eintrag in der history-Tabelle führt zu einem Fehler:

+---------------------+----------+----------+---------------------------------------------------------------------------------------------------------+------------------------------------------------------------+--------------------------------------+------+
| TIMESTAMP           | DEVICE   | TYPE     | EVENT                                                                                                   | READING                                                    | VALUE                                | UNIT |
+---------------------+----------+----------+---------------------------------------------------------------------------------------------------------+------------------------------------------------------------+--------------------------------------+------+
| 2017-10-14 11:53:23 | Pushover | PUSHOVER | msg title='' device='my_iPhone6:' priority=0 url_title="" message='status_EG.Eingang.Briefkasten: dead' | msg title='' device='my_iPhone6:' priority=0 url_title=""  | dead'                                |      |


Hier der ausgeführte SQL-Query:
2017.12.17 11:39:05.739 4: DbRep dbRep__full - SQL execute: delete FROM history where TIMESTAMP = 'title='' device='my_iPhone6:' priority=0 url_title=""  2017-10-14 11:53:23' AND DEVICE = 'Pushover' AND READING = 'msg' AND VALUE ='dead''';


DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'my_iPhone6:' priority=0 url_title="" 2017-10-14 11:53:23' AND DEVICE = 'P' at line 1 at ./FHEM/93_DbRep.pm line 4006

(Die Zeilennummer kann durch hinzugefügte Log-Einträge von mir von der svn-Version abweichen!)

Hier enden leider mein Perl-Skills, so dass ich nur den Fehler reporten kann :-\.

LG
Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2017, 12:04:51
Hi Christian,

danke für die Mitteilungen. Ich schaue mir das in Ruhe an.
Dazu muss ich mir mal solche verqueren Datensätze in der DB erzeugen.
Melde mich wieder ...

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: choenig am 17 Dezember 2017, 12:21:23
Hi Heiko,

vielen Dank :-)

Als workaround habe ich jetzt erstmal das Leerzeichen im Timestamp direkt escaped, dann funktioniert der Rest:

@row_array = map { $_->[0]."_ESC_".$_->[1]."_ESC_".($_->[2] =~ s/ /_ESC_/r)."_ESC_".$_->[3]."\n" } @{$sth->fetchall_arrayref()};


Und dazu natürlich noch die Zeile auskommentiert:
#     s/ /_ESC_/ for @row_array;             # Leerzeichen in TIMESTAMP escapen

LG
Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2017, 21:26:33
Hallo Christian, @all,

da ich gerade dabei war die DbRep-Version 7.0.0 zu erstellen, habe ich mich entschieden den Fix gleich in dieser Version mit einzubauen.

Zitat@row_array = map { $_->
  • ."_ESC_".$_->[1]."_ESC_".($_->[2] =~ s/ /_ESC_/r)."_ESC_".$_->[3]."\n" } @{$sth->fetchall_arrayref()};
Das erleichtert den Ablauf Christian, habe ich gleich so übernommen.

Ansonsten habe ich das Escapen von ' in device/reading gleich in den anderen Funktionen auch verallgemeinert. Es wird zwar (hoffentlich) nicht allzu oft vorkommen dass solche kruden Datensätze geloggt werden ... aber man weiß ja nie.

Außer deinem Fix (danke für den Änderungsvorschlag !) habe ich in der V7.0.0 noch folgendes getan:

* neues Kommando get blockinginfo
  Damit kann man sich systemweit die laufenden BlockingCalls anschauen. Die Ausgabe erfolgt als Tabelle mit gekürzten Informationen falls zuviel Daten
  angezeigt werden sollten (Schutz vor Browserlock)

* Wenn keine Zeitgrenzen UND keine Aggregation angegeben ist, wird auf die Verwendung von Timestamp-Vergleichen im Select verzichtet.
  Das bringt in diesen Fällen Geschwindigkeitsvorteile.

* DbRep-Device erkennt nun wenn das verbundene DbLog-Device die Verbindung zur DB temporär geschlossen hat (reopen xxx läuft) und führt keine
  Aktivitäten aus (Mitteilung in Log und state)

* weitere Codereviews

Ist im ersten Beitrag enthalten und bitte wie immer rege Rückmeldung  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: choenig am 17 Dezember 2017, 21:33:29
Hallo Heiko,

ich werde die neue Version ausprobieren, heute aber nicht mehr, hoffentlich morgen. Ich gebe Dir dann Feedback.

Danke für's schnelle fixen :-).

LG
Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 18 Dezember 2017, 11:52:23
Hallo Zusammen!

Ich hätte noch einen Wunsch an delSeqDoublets.
Ich habe viele Temperatursensoren, die manchmal leider um 0.01° nach oben und unten schwanken.
Diese Genauigkeit benötige ich nur am aktuellen Tag, an älteren Tagen jedoch nicht.

Schön wäre es also, wenn ich bei delSeqDoublets angeben könnte, welche Value-Abweichung ignoriert wird und als "Doublets" angesehen wird.

Danke für das neuen Feature!!!

sG und frohe Weihnachten euch allen!
Joe

Edit: Also so etwas wie "diffAccept" für delSeqDoublets, welches jedoch auch Float-Zahlen erlaubt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Dezember 2017, 19:51:26
Hi Joe,

ZitatSchön wäre es also, wenn ich bei delSeqDoublets angeben könnte, welche Value-Abweichung ignoriert wird und als "Doublets" angesehen wird.
Ja, schaue ich mir mal an. Wird aber sicherlich erst nach den Feiertagen.

viele Grüße und ebenfalls schöne Festtage allen !

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: choenig am 23 Dezember 2017, 09:18:54
Hallo Heiko,

hab Deine neue Version jetzt (endlich) ausprobiert, und sie läuft einwandfrei :-).

Vielen Dank!

LG und frohe Weihnachten
Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 25 Dezember 2017, 15:28:38
Hi,
hab grade festgestellt, dass das dbRep-Modul trotz "disable 1" weiterhin versucht, die Datenbank zu erreichen:

Internals:
   DATABASE   fhem
   DEF        logdb
   LASTCMD     
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         46
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      disconnected
   TYPE       DbRep
   UTF8       1
   VERSION    7.0.0
   HELPER:
     DBLOGDEVICE logdb
   READINGS:
     2017-12-25 15:26:17   state           disconnected
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION db.conf
     DEF        db.conf neversaveanything
     MODE       synchronous
     MODEL      MYSQL
     NAME       logdb
     NR         20
     NTFY_ORDER 50-logdb
     PID        30284
     REGEXP     neversaveanything
     STATE      disconnected
     TYPE       DbLog
     UTF8       1
     VERSION    3.5.0
     dbconn     mysql:database=fhem;host=localhost;port=3306
     dbuser     fhemuser
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   initialized
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2017-12-25 15:26:18   state           disconnected
     cache:
       index      0
Attributes:
   disable    1


2017.12.25 15:27:26 3: DbRep repdb - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2017.12.25 15:27:26 3: DbRep repdb - Waiting for database connection


ich hätte das nicht erwartet... ich dachte, disable = mach gar nix mehr, sei nur noch definiert...

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Dezember 2017, 19:12:15
Hi Stephan,

folgt nur aus einem Testvorgang. Aber du hast recht .... ich fixe das nach den Feiertagen.

Grüsse,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Dezember 2017, 16:55:08
Hallo zusammen,

ich habe die V7.2.0 im ersten Beitrag bereitgestellt.
Darin sind enthalten:

* bugfix für disable=1 (von Stephan gemeldet)

* neues Zeit-Attribut "timeYearPeriod"
   Mit Hilfe dieses Attributes wird eine jährliche Zeitperiode für die Datenbankselektion bestimmt. Die Zeitgrenzen werden zur Ausführungszeit dynamisch 
   berechnet. Es wird immer eine Jahresperiode bestimmt. Eine unterjährige Angabe ist nicht möglich.
   Dieses Attribut ist vor allem dazu gedacht Auswertungen synchron zu einer Abrechnungsperiode, z.B. der eines Energie- oder Gaslieferanten,
   anzufertigen.

    Beispiel:

    attr <DbRep-device> timeYearPeriod 06-25 06-24

    # wertet die Datenbank in den Zeitgrenzen 25. Juni AAAA bis 24. Juni BBBB aus.
    # Das Jahr AAAA bzw. BBBB wird in Abhängigkeit des aktuellen Datums errechnet.
    # Ist das aktuelle Datum >= 25. Juni und =< 31. Dezember, dann ist AAAA = aktuelles Jahr und BBBB = aktuelles Jahr+1
    # Ist das aktuelle Datum >= 01. Januar und =< 24. Juni, dann ist AAAA = aktuelles Jahr-1 und BBBB = aktuelles Jahr

* neues Attribut "seqDoubletsVariance" (Joe)
   akzeptierte Abweichung (+/-) für das Kommando "set <Name> delSeqDoublets".
   Der Wert des Attributs beschreibt die Abweichung bis zu der aufeinanderfolgende numerische Werte (VALUE) von Datensätze als gleich angesehen und
   gelöscht werden sollen. "seqDoubletsVariance" ist ein absoluter Zahlenwert, der sowohl als positive als auch negative Abweichung verwendet wird.

    Beispiele:
    attr <Name> seqDoubletsVariance 0.0014
    attr <Name> seqDoubletsVariance 1.45

Viel Spaß beim Test und gerne Feedback.

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: blaxbox am 04 Januar 2018, 20:12:23
Hallo zusammen,

also entweder habe ich einen grundlegenden Denkfehler, oder es stimmt wirklich was nicht dem timestamp "previous_month_begin" bzw. "previous_month_end".
Mir ist es nur aufgefallen, da JETZT ja Jänner ist und ich in timestamp_begin "previous_month_begin" verwende. Hier ist neuerdings FHEM komplett gecrashed u. ich habe nach einigem suchen nur die banale Meldung im log gefunden:

Month '12' out of range 0..11 at ./FHEM/93_DbRep.pm line 1314.

Das hat mich dann stutzig gemacht u. hätte da in 93_DbRep.pm tatsächlich gefunden, dass bei "previous_month_begin" bzw. "previous_month_end" das monat nach "12" gesetzt wird, und nicht auf "11". Codesnip: $rmon  = ($mon-1<0)?12:$mon-1;
timelocal kann meines Wissens aber nur Werte von 0-11.
Ich habe das bei mir einmal auf "11" geändert - und es funktioniert so wie es soll (analog natürlich auch bei "previous_month_end").

Vielleicht kann mir hier jemand sagen ob dies tatsächlich ein Fehler ist, oder ich nur wieder einmal ums Eck denke....

Grüsse


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Januar 2018, 20:27:29
Hi Rainer,

nee, du hast natürlich vollkommen recht. Da habe ich beim Jahresverschieber doch tatsächlich Mist gebaut  :o
Weiß natürlich dass der Wertebereich 0-11 ist ... aber wenn man so beim proggen ist vergißt man das leicht.
Ich fixe das und checke es ein.

Danke und Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Januar 2018, 20:52:32
ZitatIch fixe das und checke es ein.
erledigt. -> V7.2.1
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: blaxbox am 05 Januar 2018, 11:01:05
Zitat von: DS_Starter am 04 Januar 2018, 20:52:32
erledigt. -> V7.2.1

THX!

Grüsse
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Januar 2018, 12:57:56
Hallo zusammen,

in V7.3.0 habe ich die exportToFile-, importFromFile-Funktion verbessert.

Beim Export wird ein Zeichenfilter verwendet der Steuerzeichen/Umbrüche und dgl. entfernt die beim Import Probleme bereiten können.
Weiterhin ist die Speicherverwendung verbessert. Werden sehr viele Daten aus großen Datenbanken exportiert, konnte es bisher zum "died prematurely" Fehler kommen. In der neuen Version kann das verhindert werden indem man das Attribut "aggregation" setzt. Dadurch werden die zu exportierenden Daten in Zeitscheiben (z.B. Monatsscheiben bei aggregation=month) aus der DB selektiert und in das Exportfile geschrieben.
Beim Import wird bei einem eventuellen Formatfehler wie bisher die Zeilennummer und zusätzlich das fehlerhafte Feld (z.B. reading) ausgegeben.

viele Grüße
Heiko
Titel: Problem :Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ioT4db am 07 Januar 2018, 23:33:11
Hallo Heiko,

nachdem ich heute FHEM wieder mal ein "update" verpasst habe, gibt es bei mir dieses Problem:

Auszug aus dem Log:
"Please define DBAgent first"

DBAgent ist mein DbRep-Device, welches als "Agent" fungiert.

Die beim Update eingespielte Version war 7.2.1. Meine DbRep-Version zuvor, also mit der es noch lief, war 6.4.2.

Nachdem ich die Modulversion wieder auf den alten Stand gebracht hatte, läuft es nun wieder.

Hier noch ein paar Infos, die ich bei der Fehlersuche sammeln konnte:

Ein "reload" des Moduls (V7.2.1) brachte im Event Monitor folgendes:
syntax error at ./FHEM/93_DbRep.pm line 6394, near "$h{"
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6396.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6396.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6396.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6397.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6397.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6397.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6400.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6400.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6401.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6401.
Global symbol "$h" requires explicit package name at ./FHEM/93_DbRep.pm line 6402.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6406.
Global symbol "@rows" requires explicit package name at ./FHEM/93_DbRep.pm line 6408.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6409.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6410.
Global symbol "@rows" requires explicit package name at ./FHEM/93_DbRep.pm line 6420.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6426.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6427.
Global symbol "@rows" requires explicit package name at ./FHEM/93_DbRep.pm line 6427.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6429.
Global symbol "$hash" requires explicit package name at ./FHEM/93_DbRep.pm line 6430.
syntax error at ./FHEM/93_DbRep.pm line 6433, near "}"
./FHEM/93_DbRep.pm has too many errors.


Im Log stand:

2018.01.07 23:12:06 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at ./FHEM/01_FHEMWEB.pm line 2687.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Initialize redefined at ./FHEM/93_DbRep.pm line 290.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Define redefined at ./FHEM/93_DbRep.pm line 354.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Set redefined at ./FHEM/93_DbRep.pm line 392.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Get redefined at ./FHEM/93_DbRep.pm line 651.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Attr redefined at ./FHEM/93_DbRep.pm line 715.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Notify redefined at ./FHEM/93_DbRep.pm line 942.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Undef redefined at ./FHEM/93_DbRep.pm line 1013.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_firstconnect redefined at ./FHEM/93_DbRep.pm line 1033.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Connect redefined at ./FHEM/93_DbRep.pm line 1061.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_Main redefined at ./FHEM/93_DbRep.pm line 1099.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine createTimeArray redefined at ./FHEM/93_DbRep.pm line 1233.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine collaggstr redefined at ./FHEM/93_DbRep.pm line 1603.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine averval_DoParse redefined at ./FHEM/93_DbRep.pm line 1773.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine averval_ParseDone redefined at ./FHEM/93_DbRep.pm line 1901.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine count_DoParse redefined at ./FHEM/93_DbRep.pm line 1962.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine count_ParseDone redefined at ./FHEM/93_DbRep.pm line 2079.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine maxval_DoParse redefined at ./FHEM/93_DbRep.pm line 2143.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine maxval_ParseDone redefined at ./FHEM/93_DbRep.pm line 2318.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine minval_DoParse redefined at ./FHEM/93_DbRep.pm line 2384.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine minval_ParseDone redefined at ./FHEM/93_DbRep.pm line 2560.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine diffval_DoParse redefined at ./FHEM/93_DbRep.pm line 2626.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine diffval_ParseDone redefined at ./FHEM/93_DbRep.pm line 2900.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine sumval_DoParse redefined at ./FHEM/93_DbRep.pm line 2988.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine sumval_ParseDone redefined at ./FHEM/93_DbRep.pm line 3116.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine del_DoParse redefined at ./FHEM/93_DbRep.pm line 3177.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine del_ParseDone redefined at ./FHEM/93_DbRep.pm line 3250.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine insert_Push redefined at ./FHEM/93_DbRep.pm line 3307.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine insert_Done redefined at ./FHEM/93_DbRep.pm line 3402.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine currentfillup_Push redefined at ./FHEM/93_DbRep.pm line 3452.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine currentfillup_Done redefined at ./FHEM/93_DbRep.pm line 3619.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine devren_Push redefined at ./FHEM/93_DbRep.pm line 3669.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine devren_Done redefined at ./FHEM/93_DbRep.pm line 3769.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine fetchrows_DoParse redefined at ./FHEM/93_DbRep.pm line 3831.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine fetchrows_ParseDone redefined at ./FHEM/93_DbRep.pm line 3921.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine delseqdoubl_DoParse redefined at ./FHEM/93_DbRep.pm line 3989.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine delseqdoubl_ParseDone redefined at ./FHEM/93_DbRep.pm line 4173.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine expfile_DoParse redefined at ./FHEM/93_DbRep.pm line 4243.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine expfile_ParseDone redefined at ./FHEM/93_DbRep.pm line 4336.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine impfile_Push redefined at ./FHEM/93_DbRep.pm line 4385.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine impfile_PushDone redefined at ./FHEM/93_DbRep.pm line 4545.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine sqlCmd_DoParse redefined at ./FHEM/93_DbRep.pm line 4588.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine sqlCmd_ParseDone redefined at ./FHEM/93_DbRep.pm line 4700.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine dbmeta_DoParse redefined at ./FHEM/93_DbRep.pm line 4808.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine dbmeta_ParseDone redefined at ./FHEM/93_DbRep.pm line 5021.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DbRep_optimizeTables redefined at ./FHEM/93_DbRep.pm line 5077.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine OptimizeDone redefined at ./FHEM/93_DbRep.pm line 5271.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine mysql_DoDumpClientSide redefined at ./FHEM/93_DbRep.pm line 5313.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine mysql_DoDumpServerSide redefined at ./FHEM/93_DbRep.pm line 5774.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DumpDone redefined at ./FHEM/93_DbRep.pm line 5935.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine mysql_RestoreServerSide redefined at ./FHEM/93_DbRep.pm line 6002.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine RestoreDone redefined at ./FHEM/93_DbRep.pm line 6072.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine RestoreAborted redefined at ./FHEM/93_DbRep.pm line 6111.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine ParseAborted redefined at ./FHEM/93_DbRep.pm line 6134.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine DumpAborted redefined at ./FHEM/93_DbRep.pm line 6151.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine OptimizeAborted redefined at ./FHEM/93_DbRep.pm line 6187.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine createSelectSql redefined at ./FHEM/93_DbRep.pm line 6204.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine createDeleteSql redefined at ./FHEM/93_DbRep.pm line 6236.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine specsForSql redefined at ./FHEM/93_DbRep.pm line 6272.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine checktimeaggr redefined at ./FHEM/93_DbRep.pm line 6302.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine ReadingsSingleUpdateValue redefined at ./FHEM/93_DbRep.pm line 6335.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine ReadingsBulkUpdateValue redefined at ./FHEM/93_DbRep.pm line 6349.
2018.01.07 23:14:13 1: PERL WARNING: Subroutine ReadingsBulkUpdateTimeState redefined at ./FHEM/93_DbRep.pm line 6363.


Eine Idee, woran das liegen könnte?

VG
Daniel
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Januar 2018, 09:44:43
Hallo Daniel,

inzwischen ist die 7.3.0 aktuell. Was mich wundert ist die Zeile 6394. Die sieht bei mir etwas anders aus.
Sei es drum, mach erstmal ein update auf die aktuelle V und Restart !

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ioT4db am 08 Januar 2018, 15:18:07
Hallo Heiko,

gerade eben auf die 7.3 ge-updatet. Leider gleiches Verhalten.

Was meinst Du mit: bei Zeile 6394 steht bei Dir was anderes drin? Bei gleicher Modulversion, sollte der code doch identisch sein.

VG...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Januar 2018, 15:26:48
Die V7.3 läuft bei mir einwandfrei. Syntaxfehler bringt mein Sytem auch nicht raus.
Ich tippe mal stark auf perl version.

Kannst du mal bitte die Ausschrift des Syntaxfehlers wie er jetzt in V7.3 im Log erscheint und auch mal deine perl version posten ?
Könntest du denn auf deinem System perl updaten ?

Edit:. deine Frage habe ganz vergessen .... die Zeile ist geringfügig anders, etwa  %$h{, da fehlte mir das % . Habe es gerade nicht vor mir. Schaue ich heute Abend.  Ich glaube mit dieser Syntax hatte ich mit älteren Perl Versionen schonmal bisschen Stress.

Grüsse
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ioT4db am 08 Januar 2018, 16:14:20
also ich habe die Version 5.14.2.

die scheint schon etwas älter.

Ich dachte eigentlich immer, dass ich mit sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get autoremove -y && sudo reboot beim raspi unter Debian (wheezy) auch die Perl-Pakete aktuell halte  :-\ ???

Welche Version sollte man denn mindestens haben?

VG...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Januar 2018, 18:36:56
Hallo Daniel,

ich habe die relevanten Zeile(n) nun so umgeschrieben dass sie auch für deine Version passen sollte -> V7.3.1 im ersten Beitrag.

Deine Version ist schon älter.
Deine Methode zum Update ist schon ok. Nach kurzer Überlegung ist es wohl so dass das Perl-Mainrelease an dem OS-Release des Herstellers hängt.
Also wheezy kommt mit perl-base 5.14 und jessie (habe ich) mit perl-base 5.20. Die wurde durch update mittlerweile auf 5.22 angehoben.
siehst du auch hier:

https://packages.debian.org/de/wheezy/perl
https://packages.debian.org/de/jessie/perl

Vielleicht fragst du nochmal in entsprechenden Unterforen, aber ohne BS-Upgrade wirst du wohl m.M. nach auch kein höheres Perl bekommen.

ZitatWelche Version sollte man denn mindestens haben?
Diesbezüglich hat man schonmal hier https://forum.fhem.de/index.php/topic,65154.msg563946.html#msg563946 diskutiert.
Mit deiner Version sollte das meiste funktionieren, es sei denn ein Modulauthor hat, wie ich gerade, eine Syntax verwendet die mit deiner Version nicht funktioniert. Das kann man ja wieder umschreiben.
Aber tendenziell wäre es sicherlich hilfreich wenn du mal eine Version mindestens 5.20 ins Auge fasst. Wenn man auf der Statistics-Seite schaut (https://fhem.de/stats/statistics.html) verwenden ca. 3/4 aller User Perl 5.20 und höher.

Sag mir dann bitte Bescheid ob es bei dir nun klappt !

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 08 Januar 2018, 19:06:12
Zitat von: DS_Starter am 08 Januar 2018, 18:36:56

Aber tendenziell wäre es sicherlich hilfreich wenn du mal eine Version mindestens 5.20 ins Auge fasst. Wenn man auf der Statistics-Seite schaut (https://fhem.de/stats/statistics.html) verwenden ca. 3/4 aller User Perl 5.20 und höher.


Nur als Anmerkung hier, da ich auch auf dem Produktivsystem noch wheezy und perl 5.14 einsetze. Gerade da es das Produktivsystem betrifft, gibt es vermutlich einige Leute, die dieses System (genau wie ich) auch noch einige Zeit weiterbetrieben möchten.

Schön, dass Du das 5.14 kompatibel gehalten hast, denn FHEM wird bei mir schon regelmässig auf neue Versionen gehoben...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Januar 2018, 19:10:46
ZitatSchön, dass Du das 5.14 kompatibel gehalten hast, denn FHEM wird bei mir schon regelmässig auf neue Versionen gehoben...
Na klar, mache ich gerne  :)

Habe ich mit meiner Aussage recht dass das Perl Release am BS hängt, oder kennst du eine separate Perl-Upgrademöglichkeit ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: viegener am 08 Januar 2018, 19:31:23
Zitat von: DS_Starter am 08 Januar 2018, 19:10:46
Na klar, mache ich gerne  :)

Habe ich mit meiner Aussage recht dass das Perl Release am BS hängt, oder kennst du eine separate Perl-Upgrademöglichkeit ?

Generell ist das wohl so bei Debian, es gibt wohl auch die Möglichkeit es upzugraden (ich habe da einen Verweis auf eine upgrade-Möglichkeit via cpan gefunden), aber ich würde das selber eher nicht machen (nicht-standard - bei Problemen steht man eher alleine da). Dann schon lieber ein Upgrade der Debian-Version, denn das haben viele gemacht...

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ioT4db am 08 Januar 2018, 22:09:54
Hallo Heiko,

mit der V7.3.1 läuft es nun wieder. Danke!

Also das mit den Perl-Versionen hatte ich so auch noch nicht aufm Schirm.

Zumal man als User eigentlich keine Chance hat zu sehen, ob ein etwaiges Problem bzw. Fehlermeldungen vlt. aus einer inkompatiblen Perl-Version kommt. Uiuiui, wird nie langweilig ;)

VG...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Januar 2018, 22:15:45
ZitatUiuiui, wird nie langweilig ;)

Nee, wird es nicht  8)

Ja, das ist so eine Sache. Dem Modulentwickler sollte es auffallen wenn du den Fehler mitteilst ... naja aber manchmal sieht man das auch nicht gleich und ist am Haare raufen ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ioT4db am 08 Januar 2018, 22:46:25
habs nochmal hier angesprochen: https://forum.fhem.de/index.php/topic,65027.msg745149.html, da das andere Thema wohl geschlossen ist...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Januar 2018, 23:22:56
Hallo zusammen,

im ersten Beitrag gibt es die weiterentwickelte V7.4.0.

Weil ich in letzter Zeit immer häufiger darüber gestolpert bin dass SQLite-User kein oder nur altes/unbrauchbares Backup haben, ist nun hier eine Backup/Restore-Funktion eingebaut die über die SQLite Online API es ermöglicht im laufenden Betrieb konsistente Backups zu fahren.
Jetzt sollte jeder ein aktuelles Backup anfertigen können  ;)

Was ist neu ?

* Kommandos dumpSQLite/restoreSQLite zum Online-Backup / Restore von SQLite-Datenbanken

* backup/restore (MySQL/SQLite), optimizeTables, vacuum,restoreMySQL, restoreSQLite ist jetzt verfügbar auch wenn im DbLog-Device ein "reopen xxxx" läuft

* vor und nach den Backup/Restore-Kommandos sowie optimizeTables, vacuum kann jetzt ein FHEM-Kommando bzw. Perl-Code {} ausgeführt werden. Bisher war dies nur bei dumpMySQL implementiert.

ACHTUNG: Um die Attribute executeBeforeDump & executeAfterDump allgemein gültig zu machen, wurden die Attribute umbenannt nach executeBeforeProc & executeAfterProc.

Dadurch ist es nun möglich z.B. vor einem restoreMySQL/restoreSQLite das zugehörige DbLog von der DB zu trennen bzw. nichts zu loggen und nach dem Restore wieder zu verbinden. Das ist auch nach einem Timeout o.ä. in der AbortFn implementiert.

Dazu ganz einfach die Attribute setzen z.B.:

attr <Rep> executeBeforeProc set LogDB1 reopen 3600
attr <Rep> executeAfterProc set LogDB1 reopen


Die auflaufenden Evnts werden im DbLog asynchronen Mode in dieser Zeit im Cache gehalten und nach Abschluss der Operation nachgefahren.
Das ist auch für ein Vacuum oder optimizeTables günstig.

Wenn ich Zeit habe erstelle ich mal einen Wikibeitrag mit Beispielen zu Backup/Restore.

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 11 Januar 2018, 09:59:23
Hallo Heiko.

Ich hätte da noch einen Wunsch:

Ich habe in versch. Zimmern PIR Sensoren. Die melden bei Bewegung on/off. Wenn sich jetzt jemand oft bewegt kommt halt auch oft die Meldung. Aber manchmal reicht auch schon ein Luftzug oder die Heizung um viele aufeinanderfolgende Meldungen zu erzeugen. Könntest du hier vielleicht auch in dem selSeqDoublets eine Funktion anbauen, mit der man oft wiederkehrende Folgen einfach löschen kann? Also wenn z.B. ab 19:30:10 das erste mal die Meldung "on" auftaucht, 19:30:11 "off" und dann jede Sekunde (die Zeit der Abstände bis zum Neuen Ereignis vielleicht einstellbar) erneut on/off usw. bis z.B. 20:00:00 ein "off" mit längerer Pause auftaucht...
Das erste "on" und das letzte "off" sollten stehen bleiben und dazwischen die oft wiederkehrenden ereignisse sollten gelöscht werden. So weis ich das in der Zeit Bewegung stattgefunden hat.

lg
Thomas

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2018, 18:56:47
Hallo Thomas,

ich habe jetzt eine Weile auf dein Anliegen geschaut und gegrübelt ob und wie ich so etwas umsetzen könnte ohne dass die Komplexität ins uferlose steigt, die bisherige Funktionalität erhalten bleibt und das Ganze noch durch mich oder den User beherrschbar ist  ;)

Also ich muß da passen. Vielleicht gibt es jemanden der mir dafür einen Patch für die selSeqDoublets -funktion liefern kann ?

Was aber vorstellbar wäre, ist die userExitFn zu nutzen und ein Script für die 99_MyUtils zu erstellen, welches für genau deinen Anwendungsfall gebaut ist. Ohne genau darüber nachgedacht wie man das machen könnte, wäre so etwas nur sinnvoll, wenn du danach in der Lage wärst mit eigenem Perl Know-How Änderungen in dem Script vorzunehmen, um es an deine Belange anpassen und abändern zu können.

Wie ist deine Meinung dazu ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 12 Januar 2018, 08:04:53
Hallo Heiko,

es war nur ein wunsch :) scheinbar bin ich auch der einzige mit diesem Wunsch. Das dafür der Aufwand zu groß ist, kann ich verstehen und bin dir deswegen auch nicht böse. Du hast mir ja schon sehr mit dem löschen der aufeinanderfolgenden Werte geholfen. Hier bin ich auch sehr dankbar.

Leider sind meine Kenntnisse in Perl und SQL noch nicht so weit fortgeschritten das ich es selbst machen könnte. Aber es wird täglich mehr. Die 99_MyUtils kenne ich, aber die userExitFn noch nicht. Ich werde mich hierzu im Wiki mal einlesen.

gruß
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Januar 2018, 08:25:43
Hallo Thomas,

also ich bleibe da dran und vielleicht ist es auch eine schöne Aufgabe für dich zur übung im Umgang mit Perl und der myUtils. Wenn am Ende noch etwas dabei rauskommt, können wir ja auch einen Wikibeitrag erstellen zur Nachnutzung.

Vielleicht ist dann ja sogar mehr Leuten geholfen wenn sie wissen wie eigene Anpassungen umgesetzt werden können.
Mal schauen wie ich Zeit finde und dazu komme.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 17 Januar 2018, 17:13:28
Hallo DS_Starter,

zunächst herzlichen Dank für die Entwicklung und die Pflege des DbRep-Moduls. Ich bin dabei meine FHEM Installation auf DbLog umzustellen und verwende dazu eine SQLite DB. FHEM und Db laufen auf einem Raspberry PI eigentlich schon seit Jahren zuverlässig.
Ich verwende den Include Mode und logge ca. 40 Einträge pro Minute in der Db.

Ein Backup der Db mache ich jetzt mit den neuen Möglichkeiten des Moduls mit SQLiteDump und den entsprechend konfigurierten Attributen. Über die Attribute executeBeforeProc und executeAfterProc verschicke ich jeweils zu Beginn und am Ende des Backups eine E-Mail, wie ich es auch an anderen Stellen in FHEM mache. Das funktioniert im Prinzip auch, nur bekomme ich den Inhalt des Readings background_processing_time nicht in der E-Mail angezeigt. Ich verwende folgenden Perl Einzeiler:

{ my $duration = ReadingsVal("BackupDb","background_processing_time"," ");; exmail('test1@meinedomain.de','Backup DB Ende','Backup DB wurde nach ' .$duration. ' sec. beendet') }


Wenn ich genau diesen Einzeiler mit c&p z.B. in ein notify oder at einsetze, funktioniert alles wie erwartet.

Woran könnte das liegen?

Getriggert wird das Backup über ein at-Device in der Nacht.

FHEH auf aktuellem Stand/Update, Raspberry Pi, Raspbian Stretch

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Januar 2018, 21:20:25
Hallo Wolfgang,

freut mich dass du dein Backup mit der (relativ neuen) SQLiteDump-Funktion erfolgreich erstellen kannst.
Dei Problem liegt daran, dass ich ungünstigerweise die Readingerstellung für "background_processing_time" nach der Ausführung von "executeAfterProc " programmiert hatte.
Mit der Version 7.5.1 im ersten Beitrag habe ich das geändert.
Probiere mal ob es damit nun so klappt wie du es möchtest.

Nicht wundern, die Version enthält neue Funktionalitäten für Summen-, Differenz- , Maximum- , Minimum- und Durchschnittswertberechnungen die du mit "help dbrep" erläutert bekommst. Ich schreibe aber noch etwas extra dazu.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 18 Januar 2018, 22:29:23
Hallo Heiko,
herzlichen Dank für die schnelle Reaktion und die Bereitstellung der Version 7.5.1. Ich habe die neue Version installiert und FHEM neu gestartet.
Was ich bis jetzt beobachten konnte, scheint die Verarbeitung von background_processing_time jetzt richtig zu funktionieren.

Nochmals vielen Dank.

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2018, 22:55:23
Guten Abend miteinander,

wie versprochen hier noch ein paar Erläuterungen zur neuen Version 7.5.1 (im Eingangsbeitrag nochmal geändert!).

Die Version enthält die Möglichkeit bei den Summen-, Differenz- , Maximum- , Minimum- und Durchschnittswertberechnungen diese Ergebnisse wieder in der Datenbank zu speichern. Dazu werden keine Events erstellt oder benötigt.
Dazu gibt es neu zwei Aufrufoptionen display und writeToDB. "display" ist gleichbedeutend ohne Aufrufoption, was weiterhin aus Kompatibilitätsgründen funktioniert.

Hier stellvertretend ein Auszug aus Commandref für die maxValue Funktion:

* maxValue [display | writeToDB]

berechnet den Maximalwert eines Readingwertes (DB-Spalte "VALUE") in den Zeitgrenzen (Attribute) "timestamp_begin", "timestamp_end" bzw. "timeDiffToNow / timeOlderThan". Es muss das auszuwertende Reading über das Attribut "reading" angegeben sein. Die Auswertung enthält den Zeitstempel des ermittelten Maximumwertes innerhalb der Aggregation bzw. Zeitgrenzen. Im Reading wird der Zeitstempel des letzten Auftretens vom Maximalwert ausgegeben falls dieser Wert im Intervall mehrfach erreicht wird.
Ist keine oder die Option "display" angegeben werden die Ergebnisse nur angezeigt. Mit der Option "writeToDB" werden die Berechnungsergebnisse mit einem neuen Readingnamen in der Datenbank gespeichert.
Der neue Readingnamen wird aus einem Präfix und dem originalen Readingnamen gebildet. Der Präfix setzt sich aus der Bildungsfunktion und der Aggregation zusammen.
Der Timestamp der neuen Readings in der Datenbank wird von der eingestellten Aggregationsperiode abgeleitet, sofern kein eindeutiger Zeitpunkt des Ergebnisses bestimmt werden kann. Das Feld "EVENT" wird mit "calculated" gefüllt.

    Beispiel neuer Readingname gebildet aus dem Originalreading "totalpac":
    max_day_totalpac
    # <Bildungsfunktion>_<Aggregation>_<Originalreading>

Im Wiki gibt es noch ein Anwendungsbeispiel: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Speichern_von_Berechnungswerten_in_der_Datenbank_und_Erstellen_eines_Plots_.28ab_Version_7.5.1.29

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 23 Januar 2018, 08:49:05
Hallo Heiko,

erst einmal vielen Dank für den tolles Reporting Tool. Ich nutze es und bin begeistert davon.
Ich glaube deine Mittelwert Berechnung ist nicht ganz richtig. Ich logge die Tagesaußentemperaturen und möchte einen Tagesmittelwert bilden. Wenn ich nun deine Funktion aufrufe erhalte ich natürlich einen Mittelwert. Wenn ich nun die doppelten Einträge aus der Datenbank lösche, erwarte ich natürlich das der Mittelwert identisch ist dem vorherigen. Dies ist leider nicht der Fall. Mir ist jetzt nicht klar ob das Rundungsfehler sind, oder ob dein Berechnungsverfahren daran schuld ist. Berücksichtigst du die unterschiedlichen Zeitabstände die entstehen, wenn die Doppelten Datensätze gelöscht werden?

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 09:17:25
Gute Morgen Martin,

ZitatIch glaube deine Mittelwert Berechnung ist nicht ganz richtig.

Naja, die averageValue Funktion basiert in diesem Fall auf der Datenbank eigenen AVG-Funktion. Das heißt der Ergebniswert wird nicht durch mich (das Modul) berechnet, sondern durch die Datenbank ermittelt und geliefert. Ich glaube nicht, dass diese Funktion fehlerhaft arbeitet.  ;)
Allerdings ist das noch keine Erklärung für deine Beobachtung. Muss mir das mal durchdenken oder ein Beispiel durchspielen.

Man muss aber bedenken, dass es bei delSqDoublets zwar gleiche aufeinander folgende Sätze gelöscht werden, aber immer der erste und letzte Wert einer Aggregationsperiode erhalten bleibt (das ist/war so gewollt). Daraus können sich leichte Änderungen im AVG ergeben. Vielleicht muss ich mir die Logik an den Grenzen der Aggregationsperiode nochmal vornehmen.
Ich weiß jetzt nicht von welchen Größenordnungen du sprichst. Kannst du mal ein Beispiel geben ?

LG,
Heiko


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 23 Januar 2018, 09:33:05
Grüß euch,

ist es nicht so, dass AVG die Anzahl der Vorkommen mittelt, den zeitlichen Abstand jedoch ignoriert?
Von daher wäre es logisch, dass die Kurve im Plott anders aussieht als die per AVG gemittelte.

Siehe dazu den Screenshot im Excel:
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 09:57:13
Hi Joe,

du hast recht. Abgesehen davon erscheint es auch logisch wenn das mehrfache Auftreten eines gleichen Wertes (die 10 in deinem Besipiel) den Durchschnitt einer Periode anders beeinflusst als wenn dieser Wert nur 2 mal in dieser Periode auftritt.
Insofern wäre der Durchschnittswert von Temperaturen eines Tages nur aussagefähig, wenn diese Temperaturen in gleichen und kurzen Zeitabständen gemessen werden. Im Extremfall (nur theoretisch) fängt der Tag mit 15 Grad an und fällt dann sofort auf 5 Grad, bleibt den ganzen Tag so und steigt am Ende wieder auf 15 Grad. Löscht man alles raus außer die Wechsel am Anfang/Ende kommt ein Durchschnitt von 10 heraus (15+5+5+15/4). Wenn man nur 2 x 5 Grad-Werte mehr stehen lästt, werden daraus 7,5 Grad usw.

In dem Zusammenhang erscheint mir das Löschen von Datensätzen kontraproduktiv und man sollte es dann wohl besser nicht tun.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thyraz am 23 Januar 2018, 10:23:47
Das ist ja aber allgemein ein Problem beim Berechnen von Durchschnittstemperaturen.
Dazu braucht man noch gar nicht mit DBRep auszudünnen um das zu bemerken.

Auch wenn man z.B. einen Sensor hat der nicht in festem Zeitraster sendet (sondern z.B. bei einem bestimmten Temperaturdelta) oder Event-On-Change-Reading aktiviert,
ist das Zeitraster zwischen den Messwerten ja nicht immer gleich.

Die Gewichtung der DB-Einträge bei einer Mittelwertberechnung entspricht also nicht dem was wir uns wünschen.

Ich mache das für meine Tagesdurchschnittsauswertung so, dass ich einen aktuellen Wert für jede volle Stunde von 0 bis 23 Uhr bestimme (https://de.wikipedia.org/wiki/Tagesmitteltemperatur).
Dazu gibt es natürlich keine genauen Treffer in der DB, sondern man muss immer nach dem letzten geloggten Wert VOR der vollen Stunde suchen.
Dieser ist ja der Wert, der zu dem Zeitpunkt der nächsten vollen Stunde noch gültig ist (sonst hätte es einen weiteren DB-Eintrag danach gegeben).
Wenn die Temperatur sich über mehrere Stunden nicht verändert haben sollte, dann kann der selbe Logeintrag für mehrere Stunden gelten.

Über diese 24 Werte bilde ich dann den Mittelwert.

Und ja, die Kurven weichen zu meiner früher verwendeten Mittelwertberechnung (habe da auch einfach alle Werte in der DB addiert und daraus den Mittelwert gebildet) durchaus ab.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 23 Januar 2018, 10:54:06
Leider ist es komplexer.
Eigentlich müsste man hier schlicht eine andere "AVG"-Funktion benutzt werden. Man müsste die Temperatur auf Sekunden umrechnen. An wievielen Sekunden war die Temperatur 10°, an wievielen war sie 12. Nicht das Auftreten der Anzahl von Zahlen ist relevant, sondern die haltedauer, wie lange evben solch eine Zahl "gilt".
Das Löschen der Zwischenergebnisse wäre demnach nicht hinderlich, und, genau genommen würde es selbst mit allen Werten keinen ordentlichen Durchschnitt ergeben, da die Temperaturperioden ja im Normalfall nie exakt gleich lang sind.

Wenn 10 Grad an 2 Stunden gemessen wird, hat es mehr Gewicht (bleibt die Fläche under der Kurve im Grafen kleiner) als wenn es nur für 10 Minuten gemessen wurde und danach auf 11° gestiegen ist.

Hier in diesem Thread geht es auch darum und dort wurde eine Lösung dafür für TimeSeries.pm entwickelt.
https://forum.fhem.de/index.php/topic,38479.30.html

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 10:58:49
Meiner Meinung nach hängt es ja auch davon ab ob die eigene Berechnung der offiziellen Vorschrift folgen soll oder nicht.
Dann wäre es speziell für Temperaturen eventuell sinvoll eine  Funktion anzubieten die den Regularien des Wetterdienstes Rechnung trägt und somit auch der offiziellen Berechnungsvorschrift entspricht. Dann könnte man die DB auch problemlos mit aggregation=hour ausdünnen, da immer der letzte Datensatz der Stunde erhalten bleibt.

Gäbe es Bedarf für eine solche spezielle Funktion ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 23 Januar 2018, 11:05:05
Hallo Heiko,

nun, es betrifft nicht nur Temperatur (also "offiziellen Berechnungsvorschrift"), sondern auch Stromverbrauch, etc. eigentlich also sämtliche Messwerte, deren Messintervalle nicht
immer einheitlich lange sind. Speziell durch event-on-update sind in fhem die Messintervalle bewußt oft nicht gleich lange. Daher wäre es ein Nice-to-have,
eine AVG-Funktion zu haben, die trotz dem Fehlen von einzelnen Messungen korrekt mittelt.

Von daher würde ich sagen ja, ich habe interesse! :D

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 11:13:15
Ok, dann lasst es uns mal angehen. Ich hoffe auf eure Mithilfe  :)

Aber nochmal die Frage, ob eine Variante die der offiziellen Vorschrift des Wetterdienstes Rechnung trägt von Interresse wäre ? Thyraz hat ja berechtigterweise darauf hingewiesen. Es wäre ja auch bezüglich Vergleichbarkeit meteorologischer Beobachtungen vllt. nicht unwichtig.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 23 Januar 2018, 11:13:59
Hi,
für mich reicht die AVG-berechnung von Mysql völlig aus, da ich lediglich meine Vorlauftemperatur darüber bestimme. Und da wirken sich 1-2° nicht so sehr aus.

Allerdings bin ich auch dafür, wenn es eine offizielle Berechnungsmethode gibt, diese zu verwenden. Nur: ob das im Datenbankmodul sein muss? Du stellst ja ein Frontend zur Datenbank zur Verfügung. Damit kann man die Werte abrufen und im Wetter-, oder myUtils-"Modul" verarbeiten.

Ein gutes Beispiel finde ich SVG: allein dort gibts schon drei Möglichkeiten, "steps" darzustellen. Und alle drei Darstellungen ergäben unterschiedliche Mittelwerte. Das ist halt ein Thema, wo man massiv abhängig ist, was man erreichen will ...

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 11:19:57
Hi Stephan,

auch eine gute Variante. Es gibt ja die userExitFn. Mit der kann man eine eigene Routine in myutils ansteuern. Damit könnte ein Beispiel entwickelt und im Wiki abgelegt werden. Damit hätte jeder die Möglichkeit auf eigene Variantrn.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 23 Januar 2018, 11:23:33
Damit könnte man die Datenbank aber nicht auf dauer bereinigen (wenn es nur in SVG genutzt wird).... Wenn diese Funktion in DbRep zur Verfügung gestellt würde, könnte man problemlos sich vieler alter Datensätze entledigen...

sG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 11:29:34
Bitte diskutiert das Thema noch etwas !
Ich muss da wohl erstmal eine Nacht drüber schlafen ...  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 23 Januar 2018, 11:32:31
SVG war nur als Beispiel für die vielen unterschiedlichen Auslegungen von diskreten Werten gemeint ^^

Als Ergebnis will man ja einen einzelnen Wert haben (für einen bestimmten Zeitraum), um dann damit zu rechnen oder anzuzeigen..

Die Datenbankbereinigung ist von der rechenweise völlig unabhängig.
Was ich vielleicht damit sagen will: Es kommt darauf an, was man daraus macht. Es gibt kein "richtig", oder "falsch", es gibt nur ein "anders".
Dann müsste man korrekterweise auch noch einen arithmetischen, quadratischen und geometrischen Mittelwert anbieten, jeweils gewichtet oder ungewichtet ...

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 20:33:56
Hallo zusammen,

ich habe in der V7.5.3 (1.Beitrag) zunächst einmal folgende Änderungen/Erweiterungen implementiert:

* Attribut dumpFilesKeep kann nun auch auf "0" gesetzt werden. Die Einstellung kann hilfreich sein, wenn Dumpfiles ausschließlich im FTP-Ziel erhalten bleiben sollen. Die Dumpfiles in <dumpDirLocal> werden nach der Übertragung in diesem Fall gelöscht.

* die Versionsverwaltung ist nun auch für den FTP-Prozess verfügbar. Dazu gibt es das neue Attribut "ftpDumpFilesKeep". Somit ist die Anzahl der aufzubewahrenden Files im FTP-Dir getrennt vom lokal wirkenden "dumpFilesKeep" einstellbar und man benötigt keine eigene Versionsverwaltung auf dem FTP-Server mehr.

* bezüglich averageValue .... in der commandref explizit darauf hingewiesen, dass es sich hierbei um das arithmetische Mittel handelt.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 23 Januar 2018, 21:14:14
Gude,
ich habe zur Zeit mal ne sqlite zum rumspielen. RAM, HDD und CPU sind *genug* vorhanden... (ist nicht mein FHEM-Server mit den DbLog-Problemen :)

Die Datenbank ist 2 GB groß, hab ich in den letzten Tagen per FileLogConvert eingelesen.
Dabei hab ich schon einigen Mist weggeworfen.

Jetzt habe ich ein set repdb delseqdoublets adviceDelete ausgeführt. Aufgrund des Hinweises in der commandref "max 1000 Lines" dachte ich, dass das Ding in wenigen Sekunden erledigt wäre. Leider läuft das Ding seit ein paar Stunden. blockinginfo liefert einen.. "langen" Text:

[code]
Save config
LOG
System
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Pid:15558 Fn:delseqdoubl_DoParse Arg:repdb§adviceDelete§%§%§1970-01-01#1970-01-01 01:00:00#1970-01-02|1970-01-02#1970-01-02#1970-01-03|1970-01-03#1970-01-03#1970-01-04|1970-01-04#1970-01-04#1970-01-05|1970-01-05#1970-01-05#1970-01-06|1970-01-06#1970-01-06#1970-01-07|1970-01-07#1970-01-07#1970-01-08|1970-01-08#1970-01-08#1970-01-09|1970-01-09#1970-01-09#1970-01-10|1970-01-10#1970-01-10#1970-01-11|1970-01-11#1970-01-11#1970-01-12|1970-01-12#1970-01-12#1970-01-13|1970-01-13#1970-01-13#1970-01-14|1970-01-14#1970-01-14#1970-01-15|1970-01-15#1970-01-15#1970-01-16|1970-01-16#1970-01-16#1970-01-17|1970-01-17#1970-01-17#1970-01-18|1970-01-18#1970-01-18#1970-01-19|1970-01-19#1970-01-19#1970-01-20|1970-01-20#1970-01-20#1970-01-21|1970-01-21#1970-01-21#1970-01-22|1970-01-22#1970-01-22#1970-01-23|1970-01-23#1970-01-23#1970-01-24|1970-01-24#1970-01-24#1970-01-25|1970-01-25#1970-01-25#1970-01-26|1970-01-26#1970-01-26#1970-01-27|1970-01-27#1970-01-27#1970-01-28|1970-01-28#1970-01-28#1970-01-29|1970-01-29#1970-01-29#1970-01-30|1970-01-30#1970-01-30#1970-01-31|1970-01-31#1970-01-31#1970-02-01|1970-02-01#1970-02-01#1970-02-02|1970-02-02#1970-02-02#1970-02-03|1970-02-03#1970-02-03#1970-02-04|1970-02-04#1970-02-04#1970-02-05|1970-02-05#1970-02-05#1970-02-06|1970-02-06#1970-02-06#1970-02-07|1970-02-07#1970-02-07#1970-02-08|1970-02-08#1970-02-08#1970-02-09|1970-02-09#1970-02-09#1970-02-10|1970-02-10#1970-02-10#1970-02-11|1970-02-11#1970-02-11#1970-02-12|1970-02-12#1970-02-12#1970-02-13|1970-02-13#1970-02-13#1970-02-14|1970-02-14#1970-02-14#1970-02-15|1970-02-15#1970-02-15#1970-02-16|1970-02-16#1970-02-16#1970-02-17|1970-02-17#1970-02-17#1970-02-18|1970-02-18#1970-02-18#1970-02-19|1970-02-19#1970-02-19#1970-02-20|1970-02-20#1970-02-20#1970-02-21|1970-02-21#1970-02-21#1970-02-22|1970-02-22#1970-02-22#1970-02-23|1970-02-23#1970-02-23#1970-02-24|1970-02-24#1970-02-24#1970-02-25|1970-02-25#1970-02-25#1970-02-26|1970-02-26#1970-02-26#1970-02-27|1970-02-27#1970-02-27#1970-02-28|1970-02-28#1970-02-28#1970-03-01|1970-03-01#1970-03-01#1970-03-02|1970-03-02#1970-03-02#1970-03-03|1970-03-03#1970-03-03#1970-03-04|1970-03-04#1970-03-04#1970-03-05|1970-03-05#1970-03-05#1970-03-06|1970-03-06#1970-03-06#1970-03-07|1970-03-07#1970-03-07#1970-03-08|1970-03-08#1970-03-08#1970-03-09|1970-03-09#1970-03-09#1970-03-10|1970-03-10#1970-03-10#1970-03-11|1970-03-11#1970-03-11#1970-03-12|1970-03-12#1970-03-12#1970-03-13|1970-03-13#1970-03-13#1970-03-14|1970-03-14#1970-03-14#1970-03-15|1970-03-15#1970-03-15#1970-03-16|1970-03-16#1970-03-16#1970-03-17|1970-03-17#1970-03-17#1970-03-18|1970-03-18#1970-03-18#1970-03-19|1970-03-19#1970-03-19#1970-03-20|1970-03-20#1970-03-20#1970-03-21|1970-03-21#1970-03-21#1970-03-22|1970-03-22#1970-03-22#1970-03-23|1970-03-23#1970-03-23#1970-03-24|1970-03-24#1970-03-24#1970-03-25|1970-03-25#1970-03-25#1970-03-26|1970-03-26#1970-03-26#1970-03-27|1970-03-27#1970-03-27#1970-03-28|1970-03-28#1970-03-28#1970-03-29|1970-03-29#1970-03-29#1970-03-30|1970-03-30#1970-03-30#1970-03-31|1970-03-31#1970-03-31#1970-04-01|1970-04-01#1970-04-01#1970-04-02|1970-04-02#1970-04-02#1970-04-03|1970-04-03#1970-04-03#1970-04-04|1970-04-04#1970-04-04#1970-04-05|1970-04-05#1970-04-05#1970-04-06|1970-04-06#1970-04-06#1970-04-07|1970-04-07#1970-04-07#1970-04-08|1970-04-08#1970-04-08#1970-04-09|1970-04-09#1970-04-09#1970-04-10|1970-04-10#1970-04-10#1970-04-11|1970-04-11#1970-04-11#1970-04-12|1970-04-12#1970-04-12#1970-04-13|1970-04-13#1970-04-13#1970-04-14|1970-04-14#1970-04-14#1970-04-15|1970-04-15#1970-04-15#1970-04-16|1970-04-16#1970-04-16#1970-04-17|1970-04-17#1970-04-17#1970-04-18|1970-04-18#1970-04-18#1970-04-19|1970-04-19#1970-04-19#1970-04-20|1970-04-20#1970-04-20#1970-04-21|1970-04-21#1970-04-21#1970-04-22|1970-04-22#1970-04-22#1970-04-23|1970-04-23#1970-04-23#1970-04-24|1970-04-24#1970-04-24#1970-04-25|1970-04-25#1970-04-25#1970-04-26|1970-04-26#1970-04-26#1970-04-27|1970-04-27#1970-04-27#1970-04-28|1970-04-28#1970-04-28#1970-04-29|1970-04-29#1970-04-29#1970-04-30|1970-04-30#1970-04-30#1970-05-01|1970-05-01#1970-05-01#1970-05-02|1970-05-02#1970-05-02#1970-05-03|1970-05-03#1970-05-03#1970-05-04|1970-05-04#1970-05-04#1970-05-05|1970-05-05#1970-05-05#1970-05-06|1970-05-06#1970-05-06#1970-05-07|1970-05-07#1970-05-07#1970-05-08|1970-05-08#1970-05-08#1970-05-09|1970-05-09#1970-05-09#1970-05-10|1970-05-10#1970-05-10#1970-05-11|1970-05-11#1970-05-11#1970-05-12|1970-05-12#1970-05-12#1970-05-13|1970-05-13#1970-05-13#1970-05-14|1970-05-14#1970-05-14#1970-05-15|1970-05-15#1970-05-15#1970-05-16|1970-05-16#1970-05-16#1970-05-17|1970-05-17#1970-05-17#1970-05-18|1970-05-18#1970-05-18#1970-05-19|1970-05-19#1970-05-19#1970-05-20|1970-05-20#1970-05-20#1970-05-21|1970-05-21#1970-05-21#1970-05-22|1970-05-22#1970-05-22#1970-05-23|1970-05-23#1970-05-23#1970-05-24|1970-05-24#1970-05-24#1970-05-25|1970-05-25#1970-05-25#1970-05-26|1970-05-26#1970-05-26#1970-05-27|1970-05-27#1970-05-27#1970-05-28|1970-05-28#1970-05-28#1970-05-29|1970-05-29#1970-05-29#1970-05-30|1970-05-30#1970-05-30#1970-05-31|1970-05-31#1970-05-31#1970-06-01|1970-06-01#1970-06-01#1970-06-02|1970-06-02#1970-06-02#1970-06-03|1970-06-03#1970-06-03#1970-06-04|1970-06-04#1970-06-04#1970-06-05|1970-06-05#1970-06-05#1970-06-06|1970-06-06#1970-06-06#1970-06-07|1970-06-07#1970-06-07#1970-06-08|1970-06-08#1970-06-08#1970-06-09|1970-06-09#1970-06-09#1970-06-10|1970-06-10#1970-06-10#1970-06-11|1970-06-11#1970-06-11#1970-06-12|1970-06-12#1970-06-12#1970-06-13|1970-06-13#1970-06-13#1970-06-14|1970-06-14#1970-06-14#1970-06-15|1970-06-15#1970-06-15#1970-06-16|1970-06-16#1970-06-16#1970-06-17|1970-06-17#1970-06-17#1970-06-18|1970-06-18#1970-06-18#1970-06-19|1970-06-19#1970-06-19#1970-06-20|1970-06-20#1970-06-20#1970-06-21|1970-06-21#1970-06-21#1970-06-22|1970-06-22#1970-06-22#1970-06-23|1970-06-23#1970-06-23#1970-06-24|1970-06-24#1970-06-24#1970-06-25|1970-06-25#1970-06-25#1970-06-26|1970-06-26#1970-06-26#1970-06-27|1970-06-27#1970-06-27#1970-06-28|1970-06-28#1970-06-28#1970-06-29|1970-06-29#1970-06-29#1970-06-30|1970-06-30#1970-06-30#1970-07-01|1970-07-01#1970-07-01#1970-07-02|1970-07-02#1970-07-02#1970-07-03|1970-07-03#1970-07-03#1970-07-04|1970-07-04#1970-07-04#1970-07-05|1970-07-05#1970-07-05#1970-07-06|1970-07-06#1970-07-06#1970-07-07|1970-07-07#1970-07-07#1970-07-08|1970-07-08#1970-07-08#1970-07-09|1970-07-09#1970-07-09#1970-07-10|1970-07-10#1970-07-10#1970-07-11|1970-07-11#1970-07-11#1970-07-12|1970-07-12#1970-07-12#1970-07-13|1970-07-13#1970-07-13#1970-07-14|1970-07-14#1970-07-14#1970-07-15|1970-07-15#1970-07-15#1970-07-16|1970-07-16#1970-07-16#1970-07-17|1970-07-17#1970-07-17#1970-07-18|1970-07-18#1970-07-18#1970-07-19|1970-07-19#1970-07-19#1970-07-20|1970-07-20#1970-07-20#1970-07-21|1970-07-21#1970-07-21#1970-07-22|1970-07-22#1970-07-22#1970-07-23|1970-07-23#1970-07-23#1970-07-24|1970-07-24#1970-07-24#1970-07-25|1970-07-25#1970-07-25#1970-07-26|1970-07-26#1970-07-26#1970-07-27|1970-07-27#1970-07-27#1970-07-28|1970-07-28#1970-07-28#1970-07-29|1970-07-29#1970-07-29#1970-07-30|1970-07-30#1970-07-30#1970-07-31|1970-07-31#1970-07-31#1970-08-01|1970-08-01#1970-08-01#1970-08-02|1970-08-02#1970-08-02#1970-08-03|1970-08-03#1970-08-03#1970-08-04|1970-08-04#1970-08-04#1970-08-05|1970-08-05#1970-08-05#1970-08-06|1970-08-06#1970-08-06#1970-08-07|1970-08-07#1970-08-07#1970-08-08|1970-08-08#1970-08-08#1970-08-09|1970-08-09#1970-08-09#1970-08-10|1970-08-10#1970-08-10#1970-08-11|1970-08-11#1970-08-11#1970-08-12|1970-08-12#1970-08-12#1970-08-13|1970-08-13#1970-08-13#1970-08-14|1970-08-14#1970-08-14#1970-08-15|1970-08-15#1970-08-15#1970-08-16|1970-08-16#1970-08-16#1970-08-17|1970-08-17#1970-08-17#1970-08-18|1970-08-18#1970-08-18#1970-08-19|1970-08-19#1970-08-19#1970-08-20|1970-08-20#1970-08-20#1970-08-21|1970-08-21#1970-08-21#1970-08-22|1970-08-22#1970-08-22#1970-08-23|1970-08-23#1970-08-23#1970-08-24|1970-08-24#1970-08-24#1970-08-25|1970-08-25#1970-08-25#1970-08-26|1970-08-26#1970-08-26#1970-08-27|1970-08-27#1970-08-27#1970-08-28|1970-08-28#1970-08-28#1970-08-29|1970-08-29#1970-08-29#1970-08-30|1970-08-30#1970-08-30#1970-08-31|1970-08-31#1970-08-31#1970-09-01|1970-09-01#1970-09-01#1970-09-02|1970-09-02#1970-09-02#1970-09-03|1970-09-03#1970-09-03#1970-09-04|1970-09-04#1970-09-04#1970-09-05|1970-09-05#1970-09-05#1970-09-06|1970-09-06#1970-09-06#1970-09-07|1970-09-07#1970-09-07#1970-09-08|1970-09-08#1970-09-08#1970-09-09|1970-09-09#1970-09-09#1970-09-10|1970-09-10#1970-09-10#1970-09-11|1970-09-11#1970-09-11#1970-09-12|1970-09-12#1970-09-12#1970-09-13|1970-09-13#1970-09-13#1970-09-14|1970-09-14#1970-09-14#1970-09-15|1970-09-15#1970-09-15#1970-09-16|1970-09-16#1970-09-16#1970-09-17|1970-09-17#1970-09-17#1970-09-18|1970-09-18#1970-09-18#1970-09-19|1970-09-19#1970-09-19#1970-09-20|1970-09-20#1970-09-20#1970-09-21|1970-09-21#1970-09-21#1970-09-22|1970-09-22#1970-09-22#1970-09-23|1970-09-23#1970-09-23#1970-09-24|1970-09-24#1970-09-24#1970-09-25|1970-09-25#1970-09-25#1970-09-26|1970-09-26#1970-09-26#1970-09-27|1970-09-27#1970-09-27#1970-09-28|1970-09-28#1970-09-28#1970-09-29|1970-09-29#1970-09-29#1970-09-30|1970-09-30#1970-09-30#1970-10-01|1970-10-01#1970-10-01#1970-10-02|1970-10-02#1970-10-02#1970-10-03|1970-10-03#1970-10-03#1970-10-04|1970-10-04#1970-10-04#1970-10-05|1970-10-05#1970-10-05#1970-10-06|1970-10-06#1970-10-06#1970-10-07|1970-10-07#1970-10-07#1970-10-08|1970-10-08#1970-10-08#1970-10-09|1970-10-09#1970-10-09#1970-10-10|1970-10-10#1970-10-10#1970-10-11|1970-10-11#1970-10-11#1970-10-12|1970-10-12#1970-10-12#1970-10-13|1970-10-13#1970-10-13#1970-10-14|1970-10-14#1970-10-14#1970-10-15|1970-10-15#1970-10-15#1970-10-16|1970-10-16#1970-10-16#1970-10-17|1970-10-17#1970-10-17#1970-10-18|1970-10-18#1970-10-18#1970-10-19|1970-10-19#1970-10-19#1970-10-20|1970-10-20#1970-10-20#1970-10-21|1970-10-21#1970-10-21#1970-10-22|1970-10-22#1970-10-22#1970-10-23|1970-10-23#1970-10-23#1970-10-24|1970-10-24#1970-10-24#1970-10-25|1970-10-25#1970-10-25#1970-10-26|1970-10-26#1970-10-26#1970-10-27|1970-10-27#1970-10-27#1970-10-28|1970-10-28#1970-10-28#1970-10-29|1970-10-29#1970-10-29#1970-10-30|1970-10-30#1970-10-30#1970-10-31|1970-10-31#1970-10-31#1970-11-01|1970-11-01#1970-11-01#1970-11-02|1970-11-02#1970-11-02#1970-11-03|1970-11-03#1970-11-03#1970-11-04|1970-11-04#1970-11-04#1970-11-05|1970-11-05#1970-11-05#1970-11-06|1970-11-06#1970-11-06#1970-11-07|1970-11-07#1970-11-07#1970-11-08|1970-11-08#1970-11-08#1970-11-09|1970-11-09#1970-11-09#1970-11-10|1970-11-10#1970-11-10#1970-11-11|1970-11-11#1970-11-11#1970-11-12|1970-11-12#1970-11-12#1970-11-13|1970-11-13#1970-11-13#1970-11-14|1970-11-14#1970-11-14#1970-11-15|1970-11-15#1970-11-15#1970-11-16|1970-11-16#1970-11-16#1970-11-17|1970-11-17#1970-11-17#1970-11-18|1970-11-18#1970-11-18#1970-11-19|1970-11-19#1970-11-19#1970-11-20|1970-11-20#1970-11-20#1970-11-21|1970-11-21#1970-11-21#1970-11-22|1970-11-22#1970-11-22#1970-11-23|1970-11-23#1970-11-23#1970-11-24|1970-11-24#1970-11-24#1970-11-25|1970-11-25#1970-11-25#1970-11-26|1970-11-26#1970-11-26#1970-11-27|1970-11-27#1970-11-27#1970-11-28|1970-11-28#1970-11-28#1970-11-29|1970-11-29#1970-11-29#1970-11-30|1970-11-30#1970-11-30#1970-12-01|1970-12-01#1970-12-01#1970-12-02|1970-12-02#1970-12-02#1970-12-03|1970-12-03#1970-12-03#1970-12-04|1970-12-04#1970-12-04#1970-12-05|1970-12-05#1970-12-05#1970-12-06|1970-12-06#1970-12-06#1970-12-07|1970-12-07#1970-12-07#1970-12-08|1970-12-08#1970-12-08#1970-12-09|1970-12-09#1970-12-09#1970-12-10|1970-12-10#1970-12-10#1970-12-11|1970-12-11#1970-12-11#1970-12-12|1970-12-12#1970-12-12#1970-12-13|1970-12-13#1970-12-13#1970-12-14|1970-12-14#1970-12-14#1970-12-15|1970-12-15#1970-12-15#1970-12-16|1970-12-16#1970-12-16#1970-12-17|1970-12-17#1970-12-17#1970-12-18|1970-12-18#1970-12-18#1970-12-19|1970-12-19#1970-12-19#1970-12-20|1970-12-20#1970-12-20#1970-12-21|1970-12-21#1970-12-21#1970-12-22|1970-12-22#1970-12-22#1970-12-23|1970-12-23#1970-12-23#1970-12-24|1970-12-24#1970-12-24#1970-12-25|1970-12-25#1970-12-25#1970-12-26|1970-12-26#1970-12-26#1970-12-27|1970-12-27#1970-12-27#1970-12-28|1970-12-28#1970-12-28#1970-12-29|1970-12-29#1970-12-29#1970-12-30|1970-12-30#1970-12-30#1970-12-31|1970-12-31#1970-12-31#1971-01-01|1971-01-01#1971-01-01#1971-01-02|1971-01-02#1971-01-02#1971-01-03|1971-01-03#1971-01-03#1971-01-04|1971-01-04#1971-01-04#1971-01-05|1971-01-05#1971-01-05#1971-01-06|1971-01-06#1971-01-06#1971-01-07|1971-01-07#1971-01-07#1971-01-08|1971-01-08#1971-01-08#1971-01-09|1971-01-09#1971-01-09#1971-01-10|1971-01-10#1971-01-10#1971-01-11|1971-01-11#1971-01-11#1971-01-12|1971-01-12#1971-01-12#1971-01-13|1971-01-13#1971-01-13#1971-01-14|1971-01-14#1971-01-14#1971-01-15|1971-01-15#1971-01-15#1971-01-16|1971-01-16#1971-01-16#1971-01-17|1971-01-17#1971-01-17#1971-01-18|1971-01-18#1971-01-18#1971-01-19|1971-01-19#1971-01-19#1971-01-20|1971-01-20#1971-01-20#1971-01-21|1971-01-21#1971-01-21#1971-01-22|1971-01-22#1971-01-22#1971-01-23|1971-01-23#1971-01-23#1971-01-24|1971-01-24#1971-01-24#1971-01-25|1971-01-25#1971-01-25#1971-01-26|1971-01-26#1971-01-26#1971-01-27|1971-01-27#1971-01-27#1971-01-28|1971-01-28#1971-01-28#1971-01-29|1971-01-29#1971-01-29#1971-01-30|1971-01-30#1971-01-30#1971-01-31|1971-01-31#1971-01-31#1971-02-01|1971-02-01#1971-02-01#1971-02-02|1971-02-02#1971-02-02#1971-02-03|1971-02-03#1971-02-03#1971-02-04|1971-02-04#1971-02-04#1971-02-05|1971-02-05#1971-02-05#1971-02-06|1971-02-06#1971-02-06#1971-02-07|1971-02-07#1971-02-07#1971-02-08|1971-02-08#1971-02-08#1971-02-09|1971-02-09#1971-02-09#1971-02-10|1971-02-10#1971-02-10#1971-02-11|1971-02-11#1971-02-11#1971-02-12|1971-02-12#1971-02-12#1971-02-13|1971-02-13#1971-02-13#1971-02-14|1971-02-14#1971-02-14#1971-02-15|1971-02-15#1971-02-15#1971-02-16|1971-02-16#1971-02-16#1971-02-17|1971-02-17#1971-02-17#1971-02-18|1971-02-18#1971-02-18#1971-02-19|1971-02-19#1971-02-19#1971-02-20|1971-02-20#1971-02-20#1971-02-21|1971-02-21#1971-02-21#1971-02-22|1971-02-22#1971-02-22#1971-02-23|1971-02-23#1971-02-23#1971-02-24|1971-02-24#1971-02-24#1971-02-25|1971-02-25#1971-02-25#1971-02-26|1971-02-26#1971-02-26#1971-02-27|1971-02-27#1971-02-27#1971-02-28|1971-02-28#1971-02-28#1971-03-01|1971-03-01#1971-03-01#1971-03-02|1971-03-02#1971-03-02#1971-03-03|1971-03-03#1971-03-03#1971-03-04|1971-03-04#1971-03-04#1971-03-05|1971-03-05#1971-03-05#1971-03-06|1971-03-06#1971-03-06#1971-03-07|1971-03-07#1971-03-07#1971-03-08|1971-03-08#1971-03-08#1971-03-09|1971-03-09#1971-03-09#1971-03-10|1971-03-10#1971-03-10#1971-03-11|1971-03-11#1971-03-11#1971-03-12|1971-03-12#1971-03-12#1971-03-13|1971-03-13#1971-03-13#1971-03-14|1971-03-14#1971-03-14#1971-03-15|1971-03-15#1971-03-15#1971-03-16|1971-03-16#1971-03-16#1971-03-17|1971-03-17#1971-03-17#1971-03-18|1971-03-18#1971-03-18#1971-03-19|1971-03-19#1971-03-19#1971-03-20|1971-03-20#1971-03-20#1971-03-21|1971-03-21#1971-03-21#1971-03-22|1971-03-22#1971-03-22#1971-03-23|1971-03-23#1971-03-23#1971-03-24|1971-03-24#1971-03-24#1971-03-25|1971-03-25#1971-03-25#1971-03-26|1971-03-26#1971-03-26#1971-03-27|1971-03-27#1971-03-27#1971-03-28|1971-03-28#1971-03-28#1971-03-29|1971-03-29#1971-03-29#1971-03-30|1971-03-30#1971-03-30#1971-03-31|1971-03-31#1971-03-31#1971-04-01|1971-04-01#1971-04-01#1971-04-02|1971-04-02#1971-04-02#1971-04-03|1971-04-03#1971-04-03#1971-04-04|1971-04-04#1971-04-04#1971-04-05|1971-04-05#1971-04-05#1971-04-06|1971-04-06#1971-04-06#1971-04-07|1971-04-07#1971-04-07#1971-04-08|1971-04-08#1971-04-08#1971-04-09|1971-04-09#1971-04-09#1971-04-10|1971-04-10#1971-04-10#1971-04-11|1971-04-11#1971-04-11#1971-04-12|1971-04-12#1971-04-12#1971-04-13|1971-04-13#1971-04-13#1971-04-14|1971-04-14#1971-04-14#1971-04-15|1971-04-15#1971-04-15#1971-04-16|1971-04-16#1971-04-16#1971-04-17|1971-04-17#1971-04-17#1971-04-18|1971-04-18#1971-04-18#1971-04-19|1971-04-19#1971-04-19#1971-04-20|1971-04-20#1971-04-20#1971-04-21|1971-04-21#1971-04-21#1971-04-22|1971-04-22#1971-04-22#1971-04-23|1971-04-23#1971-04-23#1971-04-24|1971-04-24#1971-04-24#1971-04-25|1971-04-25#1971-04-25#1971-04-26|1971-04-26#1971-04-26#1971-04-27|1971-04-27#1971-04-27#1971-04-28|1971-04-28#1971-04-28#1971-04-29|1971-04-29#1971-04-29#1971-04-30|1971-04-30#1971-04-30#1971-05-01|1971-05-01#1971-05-01#1971-05-02|1971-05-02#1971-05-02#1971-05-03|1971-05-03#1971-05-03#1971-05-04|1971-05-04#1971-05-04#1971-05-05|1971-05-05#1971-05-05#1971-05-06|1971-05-06#1971-05-06#1971-05-07|1971-05-07#1971-05-07#1971-05-08|1971-05-08#1971-05-08#1971-05-09|1971-05-09#1971-05-09#1971-05-10|1971-05-10#1971-05-10#1971-05-11|1971-05-11#1971-05-11#1971-05-12|1971-05-12#1971-05-12#1971-05-13|1971-05-13#1971-05-13#1971-05-14|1971-05-14#1971-05-14#1971-05-15|1971-05-15#1971-05-15#1971-05-16|1971-05-16#1971-05-16#1971-05-17|1971-05-17#1971-05-17#1971-05-18|1971-05-18#1971-05-18#1971-05-19|1971-05-19#1971-05-19#1971-05-20|1971-05-20#1971-05-20#1971-05-21|1971-05-21#1971-05-21#1971-05-22|1971-05-22#1971-05-22#1971-05-23|1971-05-23#1971-05-23#1971-05-24|1971-05-24#1971-05-24#1971-05-25|1971-05-25#1971-05-25#1971-05-26|1971-05-26#1971-05-26#1971-05-27|1971-05-27#1971-05-27#1971-05-28|1971-05-28#1971-05-28#1971-05-29|1971-05-29#1971-05-29#1971-05-30|1971-05-30#1971-05-30#1971-05-31|1971-05-31#1971-05-31#1971-06-01|1971-06-01#1971-06-01#1971-06-02|1971-06-02#1971-06-02#1971-06-03|1971-06-03#1971-06-03#1971-06-04|1971-06-04#1971-06-04#1971-06-05|1971-06-05#1971-06-05#1971-06-06|1971-06-06#1971-06-06#1971-06-07|1971-06-07#1971-06-07#1971-06-08|1971-06-08#1971-06-08#1971-06-09|1971-06-09#1971-06-09#1971-06-10|1971-06-10#1971-06-10#1971-06-11|1971-06-11#1971-06-11#1971-06-12|1971-06-12#1971-06-12#1971-06-13|1971-06-13#1971-06-13#1971-06-14|1971-06-14#1971-06-14#1971-06-15|1971-06-15#1971-06-15#1971-06-16|1971-06-16#1971-06-16#1971-06-17|1971-06-17#1971-06-17#1971-06-18|1971-06-18#1971-06-18#1971-06-19|1971-06-19#1971-06-19#1971-06-20|1971-06-20#1971-06-20#1971-06-21|1971-06-21#1971-06-21#1971-06-22|1971-06-22#1971-06-22#1971-06-23|1971-06-23#1971-06-23#1971-06-24|1971-06-24#1971-06-24#1971-06-25|1971-06-25#1971-06-25#1971-06-26|1971-06-26#1971-06-26#1971-06-27|1971-06-27#1971-06-27#1971-06-28|1971-06-28#1971-06-28#1971-06-29|1971-06-29#1971-06-29#1971-06-30|1971-06-30#1971-06-30#1971-07-01|1971-07-01#1971-07-01#1971-07-02|1971-07-02#1971-07-02#1971-07-03|1971-07-03#1971-07-03#1971-07-04|1971-07-04#1971-07-04#1971-07-05|1971-07-05#1971-07-05#1971-07-06|1971-07-06#1971-07-06#1971-07-07|1971-07-07#1971-07-07#1971-07-08|1971-07-08#1971-07-08#1971-07-09|1971-07-09#1971-07-09#1971-07-10|1971-07-10#1971-07-10#1971-07-11|1971-07-11#1971-07-11#1971-07-12|1971-07-12#1971-07-12#1971-07-13|1971-07-13#1971-07-13#1971-07-14|1971-07-14#1971-07-14#1971-07-15|1971-07-15#1971-07-15#1971-07-16|1971-07-16#1971-07-16#1971-07-17|1971-07-17#1971-07-17#1971-07-18|1971-07-18#1971-07-18#1971-07-19|1971-07-19#1971-07-19#1971-07-20|1971-07-20#1971-07-20#1971-07-21|1971-07-21#1971-07-21#1971-07-22|1971-07-22#1971-07-22#1971-07-23|1971-07-23#1971-07-23#1971-07-24|1971-07-24#1971-07-24#1971-07-25|1971-07-25#1971-07-25#1971-07-26|1971-07-26#1971-07-26#1971-07-27|1971-07-27#1971-07-27#1971-07-28|1971-07-28#1971-07-28#1971-07-29|1971-07-29#1971-07-29#1971-07-30|1971-07-30#1971-07-30#1971-07-31|1971-07-31#1971-07-31#1971-08-01|1971-08-01#1971-08-01#1971-08-02|1971-08-02#1971-08-02#1971-08-03|1971-08-03#1971-08-03#1971-08-04|1971-08-04#1971-08-04#1971-08-05|1971-08-05#1971-08-05#1971-08-06|1971-08-06#1971-08-06#1971-08-07|1971-08-07#1971-08-07#1971-08-08|1971-08-08#1971-08-08#1971-08-09|1971-08-09#1971-08-09#1971-08-10|1971-08-10#1971-08-10#1971-08-11|1971-08-11#1971-08-11#1971-08-12|1971-08-12#1971-08-12#1971-08-13|1971-08-13#1971-08-13#1971-08-14|1971-08-14#1971-08-14#1971-08-15|1971-08-15#1971-08-15#1971-08-16|1971-08-16#1971-08-16#1971-08-17|1971-08-17#1971-08-17#1971-08-18|1971-08-18#1971-08-18#1971-08-19|1971-08-19#1971-08-19#1971-08-20|1971-08-20#1971-08-20#1971-08-21|1971-08-21#1971-08-21#1971-08-22|1971-08-22#1971-08-22#1971-08-23|1971-08-23#1971-08-23#1971-08-24|1971-08-24#1971-08-24#1971-08-25|1971-08-25#1971-08-25#1971-08-26|1971-08-26#1971-08-26#1971-08-27|1971-08-27#1971-08-27#1971-08-28|1971-08-28#1971-08-28#1971-08-29|1971-08-29#1971-08-29#1971-08-30|1971-08-30#1971-08-30#1971-08-31|1971-08-31#1971-08-31#1971-09-01|1971-09-01#1971-09-01#1971-09-02|1971-09-02#1971-09-02#1971-09-03|1971-09-03#1971-09-03#1971-09-04|1971-09-04#1971-09-04#1971-09-05|1971-09-05#1971-09-05#1971-09-06|1971-09-06#1971-09-06#1971-09-07|1971-09-07#1971-09-07#1971-09-08|1971-09-08#1971-09-08#1971-09-09|1971-09-09#1971-09-09#1971-09-10|1971-09-10#1971-09-10#1971-09-11|1971-09-11#1971-09-11#1971-09-12|1971-09-12#1971-09-12#1971-09-13|1971-09-13#1971-09-13#1971-09-14|1971-09-14#1971-09-14#1971-09-15|1971-09-15#1971-09-15#1971-09-16|1971-09-16#1971-09-16#1971-09-17|1971-09-17#1971-09-17#1971-09-18|1971-09-18#1971-09-18#1971-09-19|1971-09-19#1971-09-19#1971-09-20|1971-09-20#1971-09-20#1971-09-21|1971-09-21#1971-09-21#1971-09-22|1971-09-22#1971-09-22#1971-09-23|1971-09-23#1971-09-23#1971-09-24|1971-09-24#1971-09-24#1971-09-25|1971-09-25#1971-09-25#1971-09-26|1971-09-26#1971-09-26#1971-09-27|1971-09-27#1971-09-27#1971-09-28|1971-09-28#1971-09-28#1971-09-29|1971-09-29#1971-09-29#1971-09-30|1971-09-30#1971-09-30#1971-10-01|1971-10-01#1971-10-01#1971-10-02|1971-10-02#1971-10-02#1971-10-03|1971-10-03#1971-10-03#1971-10-04|1971-10-04#1971-10-04#1971-10-05|1971-10-05#1971-10-05#1971-10-06|1971-10-06#1971-10-06#1971-10-07|1971-10-07#1971-10-07#1971-10-08|1971-10-08#1971-10-08#1971-10-09|1971-10-09#1971-10-09#1971-10-10|1971-10-10#1971-10-10#1971-10-11|1971-10-11#1971-10-11#1971-10-12|1971-10-12#1971-10-12#1971-10-13|1971-10-13#1971-10-13#1971-10-14|1971-10-14#1971-10-14#1971-10-15|1971-10-15#1971-10-15#1971-10-16|1971-10-16#1971-10-16#1971-10-17|1971-10-17#1971-10-17#1971-10-18|1971-10-18#1971-10-18#1971-10-19|1971-10-19#1971-10-19#1971-10-20|1971-10-20#1971-10-20#1971-10-21|1971-10-21#1971-10-21#1971-10-22|1971-10-22#1971-10-22#1971-10-23|1971-10-23#1971-10-23#1971-10-24|1971-10-24#1971-10-24#1971-10-25|1971-10-25#1971-10-25#1971-10-26|1971-10-26#1971-10-26#1971-10-27|1971-10-27#1971-10-27#1971-10-28|1971-10-28#1971-10-28#1971-10-29|1971-10-29#1971-10-29#1971-10-30|1971-10-30#1971-10-30#1971-10-31|1971-10-31#1971-10-31#1971-11-01|1971-11-01#1971-11-01#1971-11-02|1971-11-02#1971-11-02#1971-11-03|1971-11-03#1971-11-03#1971-11-04|1971-11-04#1971-11-04#1971-11-05|1971-11-05#1971-11-05#1971-11-06|1971-11-06#1971-11-06#1971-11-07|1971-11-07#1971-11-07#1971-11-08|1971-11-08#1971-11-08#1971-11-09|1971-11-09#1971-11-09#1971-11-10|1971-11-10#1971-11-10#1971-11-11|1971-11-11#1971-11-11#1971-11-12|1971-11-12#1971-11-12#1971-11-13|1971-11-13#1971-11-13#1971-11-14|1971-11-14#1971-11-14#1971-11-15|1971-11-15#1971-11-15#1971-11-16|1971-11-16#1971-11-16#1971-11-17|1971-11-17#1971-11-17#1971-11-18|1971-11-18#1971-11-18#1971-11-19|1971-11-19#1971-11-19#1971-11-20|1971-11-20#1971-11-20#1971-11-21|1971-11-21#1971-11-21#1971-11-22|1971-11-22#1971-11-22#1971-11-23|1971-11-23#1971-11-23#1971-11-24|1971-11-24#1971-11-24#1971-11-25|1971-11-25#1971-11-25#1971-11-26|1971-11-26#1971-11-26#1971-11-27|1971-11-27#1971-11-27#1971-11-28|1971-11-28#1971-11-28#1971-11-29|1971-11-29#1971-11-29#1971-11-30|1971-11-30#1971-11-30#1971-12-01|1971-12-01#1971-12-01#1971-12-02|1971-12-02#1971-12-02#1971-12-03|1971-12-03#1971-12-03#1971-12-04|1971-12-04#1971-12-04#1971-12-05|1971-12-05#1971-12-05#1971-12-06|1971-12-06#1971-12-06#1971-12-07|1971-12-07#1971-12-07#1971-12-08|1971-12-08#1971-12-08#1971-12-09|1971-12-09#1971-12-09#1971-12-10|1971-12-10#1971-12-10#1971-12-11|1971-12-11#1971-12-11#1971-12-12|1971-12-12#1971-12-12#1971-12-13|1971-12-13#1971-12-13#1971-12-14|1971-12-14#1971-12-14#1971-12-15|1971-12-15#1971-12-15#1971-12-16|1971-12-16#1971-12-16#1971-12-17|1971-12-17#1971-12-17#1971-12-18|1971-12-18#1971-12-18#1971-12-19|1971-12-19#1971-12-19#1971-12-20|1971-12-20#1971-12-20#1971-12-21|1971-12-21#1971-12-21#1971-12-22|1971-12-22#1971-12-22#1971-12-23|1971-12-23#1971-12-23#1971-12-24|1971-12-24#1971-12-24#1971-12-25|1971-12-25#1971-12-25#1971-12-26|1971-12-26#1971-12-26#1971-12-27|1971-12-27#1971-12-27#1971-12-28|1971-12-28#1971-12-28#1971-12-29|1971-12-29#1971-12-29#1971-12-30|1971-12-30#1971-12-30#1971-12-31|1971-12-31#1971-12-31#1972-01-01|1972-01-01#1972-01-01#1972-01-02|1972-01-02#1972-01-02#1972-01-03|1972-01-03#1972-01-03#1972-01-04|1972-01-04#1972-01-04#1972-01-05|1972-01-05#1972-01-05#1972-01-06|1972-01-06#1972-01-06#1972-01-07|1972-01-07#1972-01-07#1972-01-08|1972-01-08#1972-01-08#1972-01-09|1972-01-09#1972-01-09#1972-01-10|1972-01-10#1972-01-10#1972-01-11|1972-01-11#1972-01-11#1972-01-12|1972-01-12#1972-01-12#1972-01-13|1972-01-13#1972-01-13#1972-01-14|1972-01-14#1972-01-14#1972-01-15|1972-01-15#1972-01-15#1972-01-16|1972-01-16#1972-01-16#1972-01-17|1972-01-17#1972-01-17#1972-01-18|1972-01-18#1972-01-18#1972-01-19|1972-01-19#1972-01-19#1972-01-20|1972-01-20#1972-01-20#1972-01-21|1972-01-21#1972-01-21#1972-01-22|1972-01-22#1972-01-22#1972-01-23|1972-01-23#1972-01-23#1972-01-24|1972-01-24#1972-01-24#1972-01-25|1972-01-25#1972-01-25#1972-01-26|1972-01-26#1972-01-26#1972-01-27|1972-01-27#1972-01-27#1972-01-28|1972-01-28#1972-01-28#1972-01-29|1972-01-29#1972-01-29#1972-01-30|1972-01-30#1972-01-30#1972-01-31|1972-01-31#1972-01-31#1972-02-01|1972-02-01#1972-02-01#1972-02-02|1972-02-02#1972-02-02#1972-02-03|1972-02-03#1972-02-03#1972-02-04|1972-02-04#1972-02-04#1972-02-05|1972-02-05#1972-02-05#1972-02-06|1972-02-06#1972-02-06#1972-02-07|1972-02-07#1972-02-07#1972-02-08|1972-02-08#1972-02-08#1972-02-09|1972-02-09#1972-02-09#1972-02-10|1972-02-10#1972-02-10#1972-02-11|1972-02-11#1972-02-11#1972-02-12|1972-02-12#1972-02-12#1972-02-13|1972-02-13#1972-02-13#1972-02-14|1972-02-14#1972-02-14#1972-02-15|1972-02-15#1972-02-15#1972-02-16|1972-02-16#1972-02-16#1972-02-17|1972-02-17#1972-02-17#1972-02-18|1972-02-18#1972-02-18#1972-02-19|1972-02-19#1972-02-19#1972-02-20|1972-02-20#1972-02-20#1972-02-21|1972-02-21#1972-02-21#1972-02-22|1972-02-22#1972-02-22#1972-02-23|1972-02-23#1972-02-23#1972-02-24|1972-02-24#1972-02-24#1972-02-25|1972-02-25#1972-02-25#1972-02-26|1972-02-26#1972-02-26#1972-02-27|1972-02-27#1972-02-27#1972-02-28|1972-02-28#1972-02-28#1972-02-29|1972-02-29#1972-02-29#1972-03-01|1972-03-01#1972-03-01#1972-03-02|1972-03-02#1972-03-02#1972-03-03|1972-03-03#1972-03-03#1972-03-04|1972-03-04#1972-03-04#1972-03-05|1972-03-05#1972-03-05#1972-03-06|1972-03-06#1972-03-06#1972-03-07|1972-03-07#1972-03-07#1972-03-08|1972-03-08#1972-03-08#1972-03-09|1972-03-09#1972-03-09#1972-03-10|1972-03-10#1972-03-10#1972-03-11|1972-03-11#1972-03-11#1972-03-12|1972-03-12#1972-03-12#1972-03-13|1972-03-13#1972-03-13#1972-03-14|1972-03-14#1972-03-14#1972-03-15|1972-03-15#1972-03-15#1972-03-16|1972-03-16#1972-03-16#1972-03-17|1972-03-17#1972-03-17#1972-03-18|1972-03-18#1972-03-18#1972-03-19|1972-03-19#1972-03-19#1972-03-20|1972-03-20#1972-03-20#1972-03-21|1972-03-21#1972-03-21#1972-03-22|1972-03-22#1972-03-22#1972-03-23|1972-03-23#1972-03-23#1972-03-24|1972-03-24#1972-03-24#1972-03-25|1972-03-25#1972-03-25#1972-03-26|1972-03-26#1972-03-26#1972-03-27|1972-03-27#1972-03-27#1972-03-28|1972-03-28#1972-03-28#1972-03-29|1972-03-29#1972-03-29#1972-03-30|1972-03-30#1972-03-30#1972-03-31|1972-03-31#1972-03-31#1972-04-01|1972-04-01#1972-04-01#1972-04-02|1972-04-02#1972-04-02#1972-04-03|1972-04-03#1972-04-03#1972-04-04|1972-04-04#1972-04-04#1972-04-05|1972-04-05#1972-04-05#1972-04-06|1972-04-06#1972-04-06#1972-04-07|1972-04-07#1972-04-07#1972-04-08|1972-04-08#1972-04-08#1972-04-09|1972-04-09#1972-04-09#1972-04-10|1972-04-10#1972-04-10#1972-04-11|1972-04-11#1972-04-11#1972-04-12|1972-04-12#1972-04-12#1972-04-13|1972-04-13#1972-04-13#1972-04-14|1972-04-14#1972-04-14#1972-04-15|1972-04-15#1972-04-15#1972-04-16|1972-04-16#1972-04-16#1972-04-17|1972-04-17#1972-04-17#1972-04-18|1972-04-18#1972-04-18#1972-04-19|1972-04-19#1972-04-19#1972-04-20|1972-04-20#1972-04-20#1972-04-21|1972-04-21#1972-04-21#1972-04-22|1972-04-22#1972-04-22#1972-04-23|1972-04-23#1972-04-23#1972-04-24|1972-04-24#1972-04-24#1972-04-25|1972-04-25#1972-04-25#1972-04-26|1972-04-26#1972-04-26#1972-04-27|1972-04-27#1972-04-27#1972-04-28|1972-04-28#1972-04-28#1972-04-29|1972-04-29#1972-04-29#1972-04-30|1972-04-30#1972-04-30#1972-05-01|1972-05-01#1972-05-01#1972-05-02|1972-05-02#1972-05-02#1972-05-03|1972-05-03#1972-05-03#1972-05-04|1972-05-04#1972-05-04#1972-05-05|1972-05-05#1972-05-05#1972-05-06|1972-05-06#1972-05-06#1972-05-07|1972-05-07#1972-05-07#1972-05-08|1972-05-08#1972-05-08#1972-05-09|1972-05-09#1972-05-09#1972-05-10|1972-05-10#1972-05-10#1972-05-11|1972-05-11#1972-05-11#1972-05-12|1972-05-12#1972-05-12#1972-05-13|1972-05-13#1972-05-13#1972-05-14|1972-05-14#1972-05-14#1972-05-15|1972-05-15#1972-05-15#1972-05-16|1972-05-16#1972-05-16#1972-05-17|1972-05-17#1972-05-17#1972-05-18|1972-05-18#1972-05-18#1972-05-19|1972-05-19#1972-05-19#1972-05-20|1972-05-20#1972-05-20#1972-05-21|1972-05-21#1972-05-21#1972-05-22|1972-05-22#1972-05-22#1972-05-23|1972-05-23#1972-05-23#1972-05-24|1972-05-24#1972-05-24#1972-05-25|1972-05-25#1972-05-25#1972-05-26|1972-05-26#1972-05-26#1972-05-27|1972-05-27#1972-05-27#1972-05-28|1972-05-28#1972-05-28#1972-05-29|1972-05-29#1972-05-29#1972-05-30|1972-05-30#1972-05-30#1972-05-31|1972-05-31#1972-05-31#1972-06-01|1972-06-01#1972-06-01#1972-06-02|1972-06-02#1972-06-02#1972-06-03|1972-06-03#1972-06-03#1972-06-04|1972-06-04#1972-06-04#1972-06-05|1972-06-05#1972-06-05#1972-06-06|1972-06-06#1972-06-06#1972-06-07|1972-06-07#1972-06-07#1972-06-08|1972-06-08#1972-06-08#1972-06-09|1972-06-09#1972-06-09#1972-06-10|1972-06-10#1972-06-10#1972-06-11|1972-06-11#1972-06-11#1972-06-12|1972-06-12#1972-06-12#1972-06-13|1972-06-13#1972-06-13#1972-06-14|1972-06-14#1972-06-14#1972-06-15|1972-06-15#1972-06-15#1972-06-16|1972-06-16#1972-06-16#1972-06-17|1972-06-17#1972-06-17#1972-06-18|1972-06-18#1972-06-18#1972-06-19|1972-06-19#1972-06-19#1972-06-20|1972-06-20#1972-06-20#1972-06-21|1972-06-21#1972-06-21#1972-06-22|1972-06-22#1972-06-22#1972-06-23|1972-06-23#1972-06-23#1972-06-24|1972-06-24#1972-06-24#1972-06-25|1972-06-25#1972-06-25#1972-06-26|1972-06-26#1972-06-26#1972-06-27|1972-06-27#1972-06-27#1972-06-28|1972-06-28#1972-06-28#1972-06-29|1972-06-29#1972-06-29#1972-06-30|1972-06-30#1972-06-30#1972-07-01|1972-07-01#1972-07-01#1972-07-02|1972-07-02#1972-07-02#1972-07-03|1972-07-03#1972-07-03#1972-07-04|1972-07-04#1972-07-04#1972-07-05|1972-07-05#1972-07-05#1972-07-06|1972-07-06#1972-07-06#1972-07-07|1972-07-07#1972-07-07#1972-07-08|1972-07-08#1972-07-08#1972-07-09|1972-07-09#1972-07-09#1972-07-10|1972-07-10#1972-07-10#1972-07-11|1972-07-11#1972-07-11#1972-07-12|1972-07-12#1972-07-12#1972-07-13|1972-07-13#1972-07-13#1972-07-14|1972-07-14#1972-07-14#1972-07-15|1972-07-15#1972-07-15#1972-07-16|1972-07-16#1972-07-16#1972-07-17|1972-07-17#1972-07-17#1972-07-18|1972-07-18#1972-07-18#1972-07-19|1972-07-19#1972-07-19#1972-07-20|1972-07-20#1972-07-20#1972-07-21|1972-07-21#1972-07-21#1972-07-22|1972-07-22#1972-07-22#1972-07-23|1972-07-23#1972-07-23#1972-07-24|1972-07-24#1972-07-24#1972-07-25|1972-07-25#1972-07-25#1972-07-26|1972-07-26#1972-07-26#1972-07-27|1972-07-27#1972-07-27#1972-07-28|1972-07-28#1972-07-28#1972-07-29|1972-07-29#1972-07-29#1972-07-30|1972-07-30#1972-07-30#1972-07-31|1972-07-31#1972-07-31#1972-08-01|1972-08-01#1972-08-01#1972-08-02|1972-08-02#1972-08-02#1972-08-03|1972-08-03#1972-08-03#1972-08-04|1972-08-04#1972-08-04#1972-08-05|1972-08-05#1972-08-05#1972-08-06|1972-08-06#1972-08-06#1972-08-07|1972-08-07#1972-08-07#1972-08-08|1972-08-08#1972-08-08#1972-08-09|1972-08-09#1972-08-09#1972-08-10|1972-08-10#1972-08-10#1972-08-11|1972-08-11#1972-08-11#1972-08-12|1972-08-12#1972-08-12#1972-08-13|1972-08-13#1972-08-13#1972-08-14|1972-08-14#1972-08-14#1972-08-15|1972-08-15#1972-08-15#1972-08-16|1972-08-16#1972-08-16#1972-08-17|1972-08-17#1972-08-17#1972-08-18|1972-08-18#1972-08-18#1972-08-19|1972-08-19#1972-08-19#1972-08-20|1972-08-20#1972-08-20#1972-08-21|1972-08-21#1972-08-21#1972-08-22|1972-08-22#1972-08-22#1972-08-23|1972-08-23#1972-08-23#1972-08-24|1972-08-24#1972-08-24#1972-08-25|1972-08-25#1972-08-25#1972-08-26|1972-08-26#1972-08-26#1972-08-27|1972-08-27#1972-08-27#1972-08-28|1972-08-28#1972-08-28#1972-08-29|1972-08-29#1972-08-29#1972-08-30|1972-08-30#1972-08-30#1972-08-31|1972-08-31#1972-08-31#1972-09-01|1972-09-01#1972-09-01#1972-09-02|1972-09-02#1972-09-02#1972-09-03|1972-09-03#1972-09-03#1972-09-04|1972-09-04#1972-09-04#1972-09-05|1972-09-05#1972-09-05#1972-09-06|1972-09-06#1972-09-06#1972-09-07|1972-09-07#1972-09-07#1972-09-08|1972-09-08#1972-09-08#1972-09-09|1972-09-09#1972-09-09#1972-09-10|1972-09-10#1972-09-10#1972-09-11|1972-09-11#1972-09-11#1972-09-12|1972-09-12#1972-09-12#1972-09-13|1972-09-13#1972-09-13#1972-09-14|1972-09-14#1972-09-14#1972-09-15|1972-09-15#1972-09-15#1972-09-16|1972-09-16#1972-09-16#1972-09-17|1972-09-17#1972-09-17#1972-09-18|1972-09-18#1972-09-18#1972-09-19|1972-09-19#1972-09-19#1972-09-20|1972-09-20#1972-09-20#1972-09-21|1972-09-21#1972-09-21#1972-09-22|1972-09-22#1972-09-22#1972-09-23|1972-09-23#1972-09-23#1972-09-24|1972-09-24#1972-09-24#1972-09-25|1972-09-25#1972-09-25#1972-09-26|1972-09-26#1972-09-26#1972-09-27|1972-09-27#1972-09-27#1972-09-28|1972-09-28#1972-09-28#1972-09-29|1972-09-29#1972-09-29#1972-09-30|1972-09-30#1972-09-30#1972-10-01|1972-10-01#1972-10-01#1972-10-02|1972-10-02#1972-10-02#1972-10-03|1972-10-03#1972-10-03#1972-10-04|1972-10-04#1972-10-04#1972-10-05|1972-10-05#1972-10-05#1972-10-06|1972-10-06#1972-10-06#1972-10-07|1972-10-07#1972-10-07#1972-10-08|1972-10-08#1972-10-08#1972-10-09|1972-10-09#1972-10-09#1972-10-10|1972-10-10#1972-10-10#1972-10-11|1972-10-11#1972-10-11#1972-10-12|1972-10-12#1972-10-12#1972-10-13|1972-10-13#1972-10-13#1972-10-14|1972-10-14#1972-10-14#1972-10-15|1972-10-15#1972-10-15#1972-10-16|1972-10-16#1972-10-16#1972-10-17|1972-10-17#1972-10-17#1972-10-18|1972-10-18#1972-10-18#1972-10-19|1972-10-19#1972-10-19#1972-10-20|1972-10-20#1972-10-20#1972-10-21|1972-10-21#1972-10-21#1972-10-22|1972-10-22#1972-10-22#1972-10-23|1972-10-23#1972-10-23#1972-10-24|1972-10-24#1972-10-24#1972-10-25|1972-10-25#1972-10-25#1972-10-26|1972-10-26#1972-10-26#1972-10-27|1972-10-27#1972-10-27#1972-10-28|1972-10-28#1972-10-28#1972-10-29|1972-10-29#1972-10-29#1972-10-30|1972-10-30#1972-10-30#1972-10-31|1972-10-31#1972-10-31#1972-11-01|1972-11-01#1972-11-01#1972-11-02|1972-11-02#1972-11-02#1972-11-03|1972-11-03#1972-11-03#1972-11-04|1972-11-04#1972-11-04#1972-11-05|1972-11-05#1972-11-05#1972-11-06|1972-11-06#1972-11-06#1972-11-07|1972-11-07#1972-11-07#1972-11-08|1972-11-08#1972-11-08#1972-11-09|1972-11-09#1972-11-09#1972-11-10|1972-11-10#1972-11-10#1972-11-11|1972-11-11#1972-11-11#1972-11-12|1972-11-12#1972-11-12#1972-11-13|1972-11-13#1972-11-13#1972-11-14|1972-11-14#1972-11-14#1972-11-15|1972-11-15#1972-11-15#1972-11-16|1972-11-16#1972-11-16#1972-11-17|1972-11-17#1972-11-17#1972-11-18|1972-11-18#1972-11-18#1972-11-19|1972-11-19#1972-11-19#1972-11-20|1972-11-20#1972-11-20#1972-11-21|1972-11-21#1972-11-21#1972-11-22|1972-11-22#1972-11-22#1972-11-23|1972-11-23#1972-11-23#1972-11-24|1972-11-24#1972-11-24#1972-11-25|1972-11-25#1972-11-25#1972-11-26|1972-11-26#1972-11-26#1972-11-27|1972-11-27#1972-11-27#1972-11-28|1972-11-28#1972-11-28#1972-11-29|1972-11-29#1972-11-29#1972-11-30|1972-11-30#1972-11-30#1972-12-01|1972-12-01#1972-12-01#1972-12-02|1972-12-02#1972-12-02#1972-12-03|1972-12-03#1972-12-03#1972-12-04|1972-12-04#1972-12-04#1972-12-05|1972-12-05#1972-12-05#1972-12-06|1972-12-06#1972-12-06#1972-12-07|1972-12-07#1972-12-07#1972-12-08|1972-12-08#1972-12-08#1972-12-09|1972-12-09#1972-12-09#1972-12-10|1972-12-10#1972-12-10#1972-12-11|1972-12-11#1972-12-11#1972-12-12|1972-12-12#1972-12-12#1972-12-13|1972-12-13#1972-12-13#1972-12-14|1972-12-14#1972-12-14#1972-12-15|1972-12-15#1972-12-15#1972-12-16|1972-12-16#1972-12-16#1972-12-17|1972-12-17#1972-12-17#1972-12-18|1972-12-18#1972-12-18#1972-12-19|1972-12-19#1972-12-19#1972-12-20|1972-12-20#1972-12-20#1972-12-21|1972-12-21#1972-12-21#1972-12-22|1972-12-22#1972-12-22#1972-12-23|1972-12-23#1972-12-23#1972-12-24|1972-12-24#1972-12-24#1972-12-25|1972-12-25#1972-12-25#1972-12-26|1972-12-26#1972-12-26#1972-12-27|1972-12-27#1972-12-27#1972-12-28|1972-12-28#1972-12-28#1972-12-29|1972-12-29#1972-12-29#1972-12-30|1972-12-30#1972-12-30#1972-12-31|1972-12-31#1972-12-31#1973-01-01|1973-01-01#1973-01-01#1973-01-02|1973-01-02#1973-01-02#1973-01-03|1973-01-03#1973-01-03#1973-01-04|1973-01-04#1973-01-04#1973-01-05|1973-01-05#1973-01-05#1973-01-06|1973-01-06#1973-01-06#1973-01-07|1973-01-07#1973-01-07#1973-01-08|1973-01-08#1973-01-08#1973-01-09|1973-01-09#1973-01-09#1973-01-10|1973-01-10#1973-01-10#1973-01-11|1973-01-11#1973-01-11#1973-01-12|1973-01-12#1973-01-12#1973-01-13|1973-01-13#1973-01-13#1973-01-14|1973-01-14#1973-01-14#1973-01-15|1973-01-15#1973-01-15#1973-01-16|1973-01-16#1973-01-16#1973-01-17|1973-01-17#1973-01-17#1973-01-18|1973-01-18#1973-01-18#1973-01-19|1973-01-19#1973-01-19#1973-01-20|1973-01-20#1973-01-20#1973-01-21|1973-01-21#1973-01-21#1973-01-22|1973-01-22#1973-01-22#1973-01-23|1973-01-23#1973-01-23#1973-01-24|1973-01-24#1973-01-24#1973-01-25|1973-01-25#1973-01-25#1973-01-26|1973-01-26#1973-01-26#1973-01-27|1973-01-27#1973-01-27#1973-01-28|1973-01-28#1973-01-28#1973-01-29|1973-01-29#1973-01-29#1973-01-30|1973-01-30#1973-01-30#1973-01-31|1973-01-31#1973-01-31#1973-02-01|1973-02-01#1973-02-01#1973-02-02|1973-02-02#1973-02-02#1973-02-03|1973-02-03#1973-02-03#1973-02-04|1973-02-04#1973-02-04#1973-02-05|1973-02-05#1973-02-05#1973-02-06|1973-02-06#1973-02-06#1973-02-07|1973-02-07#1973-02-07#1973-02-08|1973-02-08#1973-02-08#1973-02-09|1973-02-09#1973-02-09#1973-02-10|1973-02-10#1973-02-10#1973-02-11|1973-02-11#1973-02-11#1973-02-12|1973-02-12#1973-02-12#1973-02-13|1973-02-13#1973-02-13#1973-02-14|1973-02-14#1973-02-14#1973-02-15|1973-02-15#1973-02-15#1973-02-16|1973-02-16#1973-02-16#1973-02-17|1973-02-17#1973-02-17#1973-02-18|1973-02-18#1973-02-18#1973-02-19|1973-02-19#1973-02-19#1973-02-20|1973-02-20#1973-02-20#1973-02-21|1973-02-21#1973-02-21#1973-02-22|1973-02-22#1973-02-22#1973-02-23|1973-02-23#1973-02-23#1973-02-24|1973-02-24#1973-02-24#1973-02-25|1973-02-25#1973-02-25#1973-02-26|1973-02-26#1973-02-26#1973-02-27|1973-02-27#1973-02-27#1973-02-28|1973-02-28#1973-02-28#1973-03-01|1973-03-01#1973-03-01#1973-03-02|1973-03-02#1973-03-02#1973-03-03|1973-03-03#1973-03-03#1973-03-04|1973-03-04#1973-03-04#1973-03-05|1973-03-05#1973-03-05#1973-03-06|1973-03-06#1973-03-06#1973-03-07|1973-03-07#1973-03-07#1973-03-08|1973-03-08#1973-03-08#1973-03-09|1973-03-09#1973-03-09#1973-03-10|1973-03-10#1973-03-10#1973-03-11|1973-03-11#1973-03-11#1973-03-12|1973-03-12#1973-03-12#1973-03-13|1973-03-13#1973-03-13#1973-03-14|1973-03-14#1973-03-14#1973-03-15|1973-03-15#1973-03-15#1973-03-16|1973-03-16#1973-03-16#1973-03-17|1973-03-17#1973-03-17#1973-03-18|1973-03-18#1973-03-18#1973-03-19|1973-03-19#1973-03-19#1973-03-20|1973-03-20#1973-03-20#1973-03-21|1973-03-21#1973-03-21#1973-03-22|1973-03-22#1973-03-22#1973-03-23|1973-03-23#1973-03-23#1973-03-24|1973-03-24#1973-03-24#1973-03-25|1973-03-25#1973-03-25#1973-03-26|1973-03-26#1973-03-26#1973-03-27|1973-03-27#1973-03-27#1973-03-28|1973-03-28#1973-03-28#1973-03-29|1973-03-29#1973-03-29#1973-03-30|1973-03-30#1973-03-30#1973-03-31|1973-03-31#1973-03-31#1973-04-01|1973-04-01#1973-04-01#1973-04-02|1973-04-02#1973-04-02#1973-04-03|1973-04-03#1973-04-03#1973-04-04|1973-04-04#1973-04-04#1973-04-05|1973-04-05#1973-04-05#1973-04-06|1973-04-06#1973-04-06#1973-04-07|1973-04-07#1973-04-07#1973-04-08|1973-04-08#1973-04-08#1973-04-09|1973-04-09#1973-04-09#1973-04-10|1973-04-10#1973-04-10#1973-04-11|1973-04-11#1973-04-11#1973-04-12|1973-04-12#1973-04-12#1973-04-13|1973-04-13#1973-04-13#1973-04-14|1973-04-14#1973-04-14#1973-04-15|1973-04-15#1973-04-15#1973-04-16|1973-04-16#1973-04-16#1973-04-17|1973-04-17#1973-04-17#1973-04-18|1973-04-18#1973-04-18#1973-04-19|1973-04-19#1973-04-19#1973-04-20|1973-04-20#1973-04-20#1973-04-21|1973-04-21#1973-04-21#1973-04-22|1973-04-22#1973-04-22#1973-04-23|1973-04-23#1973-04-23#1973-04-24|1973-04-24#1973-04-24#1973-04-25|1973-04-25#1973-04-25#1973-04-26|1973-04-26#1973-04-26#1973-04-27|1973-04-27#1973-04-27#1973-04-28|1973-04-28#1973-04-28#1973-04-29|1973-04-29#1973-04-29#1973-04-30|1973-04-30#1973-04-30#1973-05-01|1973-05-01#1973-05-01#1973-05-02|1973-05-02#1973-05-02#1973-05-03|1973-05-03#1973-05-03#1973-05-04|1973-05-04#1973-05-04#1973-05-05|1973-05-05#1973-05-05#1973-05-06|1973-05-06#1973-05-06#1973-05-07|1973-05-07#1973-05-07#1973-05-08|1973-05-08#1973-05-08#1973-05-09|1973-05-09#1973-05-09#1973-05-10|1973-05-10#1973-05-10#1973-05-11|1973-05-11#1973-05-11#1973-05-12|1973-05-12#1973-05-12#1973-05-13|1973-05-13#1973-05-13#1973-05-14|1973-05-14#1973-05-14#1973-05-15|1973-05-15#1973-05-15#1973-05-16|1973-05-16#1973-05-16#1973-05-17|1973-05-17#1973-05-17#1973-05-18|1973-05-18#1973-05-18#1973-05-19|1973-05-19#1973-05-19#1973-05-20|1973-05-20#1973-05-20#1973-05-21|1973-05-21#1973-05-21#1973-05-22|1973-05-22#1973-05-22#1973-05-23|1973-05-23#1973-05-23#1973-05-24|1973-05-24#1973-05-24#1973-05-25|1973-05-25#1973-05-25#1973-05-26|1973-05-26#1973-05-26#1973-05-27|1973-05-27#1973-05-27#1973-05-28|1973-05-28#1973-05-28#1973-05-29|1973-05-29#1973-05-29#1973-05-30|1973-05-30#1973-05-30#1973-05-31|1973-05-31#1973-05-31#1973-06-01|1973-06-01#1973-06-01#1973-06-02|1973-06-02#1973-06-02#1973-06-03|1973-06-03#1973-06-03#1973-06-04|1973-06-04#1973-06-04#1973-06-05|1973-06-05#1973-06-05#1973-06-06|1973-06-06#1973-06-06#1973-06-07|1973-06-07#1973-06-07#1973-06-08|1973-06-08#1973-06-08#1973-06-09|1973-06-09#1973-06-09#1973-06-10|1973-06-10#1973-06-10#1973-06-11|1973-06-11#1973-06-11#1973-06-12|1973-06-12#1973-06-12#1973-06-13|1973-06-13#1973-06-13#1973-06-14|1973-06-14#1973-06-14#1973-06-15|1973-06-15#1973-06-15#1973-06-16|1973-06-16#1973-06-16#1973-06-17|1973-06-17#1973-06-17#1973-06-18|1973-06-18#1973-06-18#1973-06-19|1973-06-19#1973-06-19#1973-06-20|1973-06-20#1973-06-20#1973-06-21|1973-06-21#1973-06-21#1973-06-22|1973-06-22#1973-06-22#1973-06-23|1973-06-23#1973-06-23#1973-06-24|1973-06-24#1973-06-24#1973-06-25|1973-06-25#1973-06-25#1973-06-26|1973-06-26#1973-06-26#1973-06-27|1973-06-27#1973-06-27#1973-06-28|1973-06-28#1973-06-28#1973-06-29|1973-06-29#1973-06-29#1973-06-30|1973-06-30#1973-06-30#1973-07-01|1973-07-01#1973-07-01#1973-07-02|1973-07-02#1973-07-02#1973-07-03|1973-07-03#1973-07-03#1973-07-04|1973-07-04#1973-07-04#1973-07-05|1973-07-05#1973-07-05#1973-07-06|1973-07-06#1973-07-06#1973-07-07|1973-07-07#1973-07-07#1973-07-08|1973-07-08#1973-07-08#1973-07-09|1973-07-09#1973-07-09#1973-07-10|1973-07-10#1973-07-10#1973-07-11|1973-07-11#1973-07-11#1973-07-12|1973-07-12#1973-07-12#1973-07-13|1973-07-13#1973-07-13#1973-07-14|1973-07-14#1973-07-14#1973-07-15|1973-07-15#1973-07-15#1973-07-16|1973-07-16#1973-07-16#1973-07-17|1973-07-17#1973-07-17#1973-07-18|1973-07-18#1973-07-18#1973-07-19|1973-07-19#1973-07-19#1973-07-20|1973-07-20#1973-07-20#1973-07-21|1973-07-21#1973-07-21#1973-07-22|1973-07-22#1973-07-22#1973-07-23|1973-07-23#1973-07-23#1973-07-24|1973-07-24#1973-07-24#1973-07-25|1973-07-25#1973-07-25#1973-07-26|1973-07-26#1973-07-26#1973-07-27|1973-07-27#1973-07-27#1973-07-28|1973-07-28#1973-07-28#1973-07-29|1973-07-29#1973-07-29#1973-07-30|1973-07-30#1973-07-30#1973-07-31|1973-07-31#1973-07-31#1973-08-01|1973-08-01#1973-08-01#1973-08-02|1973-08-02#1973-08-02#1973-08-03|1973-08-03#1973-08-03#1973-08-04|1973-08-04#1973-08-04#1973-08-05|1973-08-05#1973-08-05#1973-08-06|1973-08-06#1973-08-06#1973-08-07|1973-08-07#1973-08-07#1973-08-08|1973-08-08#1973-08-08#1973-08-09|1973-08-09#1973-08-09#1973-08-10|1973-08-10#1973-08-10#1973-08-11|1973-08-11#1973-08-11#1973-08-12|1973-08-12#1973-08-12#1973-08-13|1973-08-13#1973-08-13#1973-08-14|1973-08-14#1973-08-14#1973-08-15|1973-08-15#1973-08-15#1973-08-16|1973-08-16#1973-08-16#1973-08-17|1973-08-17#1973-08-17#1973-08-18|1973-08-18#1973-08-18#1973-08-19|1973-08-19#1973-08-19#1973-08-20|1973-08-20#1973-08-20#1973-08-21|1973-08-21#1973-08-21#1973-08-22|1973-08-22#1973-08-22#1973-08-23|1973-08-23#1973-08-23#1973-08-24|1973-08-24#1973-08-24#1973-08-25|1973-08-25#1973-08-25#1973-08-26|1973-08-26#1973-08-26#1973-08-27|1973-08-27#1973-08-27#1973-08-28|1973-08-28#1973-08-28#1973-08-29|1973-08-29#1973-08-29#1973-08-30|1973-08-30#1973-08-30#1973-08-31|1973-08-31#1973-08-31#1973-09-01|1973-09-01#1973-09-01#1973-09-02|1973-09-02#1973-09-02#1973-09-03|1973-09-03#1973-09-03#1973-09-04|1973-09-04#1973-09-04#1973-09-05|1973-09-05#1973-09-05#1973-09-06|1973-09-06#1973-09-06#1973-09-07|1973-09-07#1973-09-07#1973-09-08|1973-09-08#1973-09-08#1973-09-09|1973-09-09#1973-09-09#1973-09-10|1973-09-10#1973-09-10#1973-09-11|1973-09-11#1973-09-11#1973-09-12|1973-09-12#1973-09-12#1973-09-13|1973-09-13#1973-09-13#1973-09-14|1973-09-14#1973-09-14#1973-09-15|1973-09-15#1973-09-15#1973-09-16|1973-09-16#1973-09-16#1973-09-17|1973-09-17#1973-09-17#1973-09-18|1973-09-18#1973-09-18#1973-09-19|1973-09-19#1973-09-19#1973-09-20|1973-09-20#1973-09-20#1973-09-21|1973-09-21#1973-09-21#1973-09-22|1973-09-22#1973-09-22#1973-09-23|1973-09-23#1973-09-23#1973-09-24|1973-09-24#1973-09-24#1973-09-25|1973-09-25#1973-09-25#1973-09-26|1973-09-26#1973-09-26#1973-09-27|1973-09-27#1973-09-27#1973-09-28|1973-09-28#1973-09-28#1973-09-29|1973-09-29#1973-09-29#1973-09-30|1973-09-30#1973-09-30#1973-10-01|1973-10-01#1973-10-01#1973-10-02|1973-10-02#1973-10-02#1973-10-03|1973-10-03#1973-10-03#1973-10-04|1973-10-04#1973-10-04#1973-10-05|1973-10-05#1973-10-05#1973-10-06|1973-10-06#1973-10-06#1973-10-07|1973-10-07#1973-10-07#1973-10-08|1973-10-08#1973-10-08#1973-10-09|1973-10-09#1973-10-09#1973-10-10|1973-10-10#1973-10-10#1973-10-11|1973-10-11#1973-10-11#1973-10-12|1973-10-12#1973-10-12#1973-10-13|1973-10-13#1973-10-13#1973-10-14|1973-10-14#1973-10-14#1973-10-15|1973-10-15#1973-10-15#1973-10-16|1973-10-16#1973-10-16#1973-10-17|1973-10-17#1973-10-17#1973-10-18|1973-10-18#1973-10-18#1973-10-19|1973-10-19#1973-10-19#1973-10-20|1973-10-20#1973-10-20#1973-10-21|1973-10-21#1973-10-21#1973-10-22|1973-10-22#1973-10-22#1973-10-23|1973-10-23#1973-10-23#1973-10-24|1973-10-24#1973-10-24#1973-10-25|1973-10-25#1973-10-25#1973-10-26|1973-10-26#1973-10-26#1973-10-27|1973-10-27#1973-10-27#1973-10-28|1973-10-28#1973-10-28#1973-10-29|1973-10-29#1973-10-29#1973-10-30|1973-10-30#1973-10-30#1973-10-31|1973-10-31#1973-10-31#1973-11-01|1973-11-01#1973-11-01#1973-11-02|1973-11-02#1973-11-02#1973-11-03|1973-11-03#1973-11-03#1973-11-04|1973-11-04#1973-11-04#1973-11-05|1973-11-05#1973-11-05#1973-11-06|1973-11-06#1973-11-06#1973-11-07|1973-11-07#1973-11-07#1973-11-08|1973-11-08#1973-11-08#1973-11-09|1973-11-09#1973-11-09#1973-11-10|1973-11-10#1973-11-10#1973-11-11|1973-11-11#1973-11-11#1973-11-12|1973-11-12#1973-11-12#1973-11-13|1973-11-13#1973-11-13#1973-11-14|1973-11-14#1973-11-14#1973-11-15|1973-11-15#1973-11-15#1973-11-16|1973-11-16#1973-11-16#1973-11-17|1973-11-17#1973-11-17#1973-11-18|1973-11-18#1973-11-18#1973-11-19|1973-11-19#1973-11-19#1973-11-20|1973-11-20#1973-11-20#1973-11-21|1973-11-21#1973-11-21#1973-11-22|1973-11-22#1973-11-22#1973-11-23|1973-11-23#1973-11-23#1973-11-24|1973-11-24#1973-11-24#1973-11-25|1973-11-25#1973-11-25#1973-11-26|1973-11-26#1973-11-26#1973-11-27|1973-11-27#1973-11-27#1973-11-28|1973-11-28#1973-11-28#1973-11-29|1973-11-29#1973-11-29#1973-11-30|1973-11-30#1973-11-30#1973-12-01|1973-12-01#1973-12-01#1973-12-02|1973-12-02#1973-12-02#1973-12-03|1973-12-03#1973-12-03#1973-12-04|1973-12-04#1973-12-04#1973-12-05|1973-12-05#1973-12-05#1973-12-06|1973-12-06#1973-12-06#1973-12-07|1973-12-07#1973-12-07#1973-12-08|1973-12-08#1973-12-08#1973-12-09|1973-12-09#1973-12-09#1973-12-10|1973-12-10#1973-12-10#1973-12-11|1973-12-11#1973-12-11#1973-12-12|1973-12-12#1973-12-12#1973-12-13|1973-12-13#1973-12-13#1973-12-14|1973-12-14#1973-12-14#1973-12-15|1973-12-15#1973-12-15#1973-12-16|1973-12-16#1973-12-16#1973-12-17|1973-12-17#1973-12-17#1973-12-18|1973-12-18#1973-12-18#1973-12-19|1973-12-19#1973-12-19#1973-12-20|1973-12-20#1973-12-20#1973-12-21|1973-12-21#1973-12-21#1973-12-22|1973-12-22#1973-12-22#1973-12-23|1973-12-23#1973-12-23#1973-12-24|1973-12-24#1973-12-24#1973-12-25|1973-12-25#1973-12-25#1973-12-26|1973-12-26#1973-12-26#1973-12-27|1973-12-27#1973-12-27#1973-12-28|1973-12-28#1973-12-28#1973-12-29|1973-12-29#1973-12-29#1973-12-30|1973-12-30#1973-12-30#1973-12-31|1973-12-31#1973-12-31#1974-01-01|1974-01-01#1974-01-01#1974-01-02|1974-01-02#1974-01-02#1974-01-03|1974-01-03#1974-01-03#1974-01-04|1974-01-04#1974-01-04#1974-01-05|1974-01-05#1974-01-05#1974-01-06|1974-01-06#1974-01-06#1974-01-07|1974-01-07#1974-01-07#1974-01-08|1974-01-08#1974-01-08#1974-01-09|1974-01-09#1974-01-09#1974-01-10|1974-01-10#1974-01-10#1974-01-11|1974-01-11#1974-01-11#1974-01-12|1974-01-12#1974-01-12#1974-01-13|1974-01-13#1974-01-13#1974-01-14|1974-01-14#1974-01-14#1974-01-15|1974-01-15#1974-01-15#1974-01-16|1974-01-16#1974-01-16#1974-01-17|1974-01-17#1974-01-17#1974-01-18|1974-01-18#1974-01-18#1974-01-19|1974-01-19#1974-01-19#1974-01-20|1974-01-20#1974-01-20#1974-01-21|1974-01-21#1974-01-21#1974-01-22|1974-01-22#1974-01-22#1974-01-23|1974-01-23#1974-01-23#1974-01-24|1974-01-24#1974-01-24#1974-01-25|1974-01-25#1974-01-25#1974-01-26|1974-01-26#1974-01-26#1974-01-27|1974-01-27#1974-01-27#1974-01-28|1974-01-28#1974-01-28#1974-01-29|1974-01-29#1974-01-29#1974-01-30|1974-01-30#1974-01-30#1974-01-31|1974-01-31#1974-01-31#1974-02-01|1974-02-01#1974-02-01#1974-02-02|1974-02-02#1974-02-02#1974-02-03|1974-02-03#1974-02-03#1974-02-04|1974-02-04#1974-02-04#1974-02-05|1974-02-05#1974-02-05#1974-02-06|1974-02-06#1974-02-06#1974-02-07|1974-02-07#1974-02-07#1974-02-08|1974-02-08#1974-02-08#1974-02-09|1974-02-09#1974-02-09#1974-02-10|1974-02-10#1974-02-10#1974-02-11|1974-02-11#1974-02-11#1974-02-12|1974-02-12#1974-02-12#1974-02-13|1974-02-13#1974-02-13#1974-02-14|1974-02-14#1974-02-14#1974-02-15|1974-02-15#1974-02-15#1974-02-16|1974-02-16#1974-02-16#1974-02-17|1974-02-17#1974-02-17#1974-02-18|1974-02-18#1974-02-18#1974-02-19|1974-02-19#1974-02-19#1974-02-20|1974-02-20#1974-02-20#1974-02-21|1974-02-21#1974-02-21#1974-02-22|1974-02-22#1974-02-22#1974-02-23|1974-02-23#1974-02-23#1974-02-24|1974-02-24#1974-02-24#1974-02-25|1974-02-25#1974-02-25#1974-02-26|1974-02-26#1974-02-26#1974-02-27|1974-02-27#1974-02-27#1974-02-28|1974-02-28#1974-02-28#1974-03-01|1974-03-01#1974-03-01#1974-03-02|1974-03-02#1974-03-02#1974-03-03|1974-03-03#1974-03-03#1974-03-04|1974-03-04#1974-03-04#1974-03-05|1974-03-05#1974-03-05#1974-03-06|1974-03-06#1974-03-06#1974-03-07|1974-03-07#1974-03-07#1974-03-08|1974-03-08#1974-03-08#1974-03-09|1974-03-09#1974-03-09#1974-03-10|1974-03-10#1974-03-10#1974-03-11|1974-03-11#1974-03-11#1974-03-12|1974-03-12#1974-03-12#1974-03-13|1974-03-13#1974-03-13#1974-03-14|1974-03-14#1974-03-14#1974-03-15|1974-03-15#1974-03-15#1974-03-16|1974-03-16#1974-03-16#1974-03-17|1974-03-17#1974-03-17#1974-03-18|1974-03-18#1974-03-18#1974-03-19|1974-03-19#1974-03-19#1974-03-20|1974-03-20#1974-03-20#1974-03-21|1974-03-21#1974-03-21#1974-03-22|1974-03-22#1974-03-22#1974-03-23|1974-03-23#1974-03-23#1974-03-24|1974-03-24#1974-03-24#1974-03-25|1974-03-25#1974-03-25#1974-03-26|1974-03-26#1974-03-26#1974-03-27|1974-03-27#1974-03-27#1974-03-28|1974-03-28#1974-03-28#1974-03-29|1974-03-29#1974-03-29#1974-03-30|1974-03-30#1974-03-30#1974-03-31|1974-03-31#1974-03-31#1974-04-01|1974-04-01#1974-04-01#1974-04-02|1974-04-02#1974-04-02#1974-04-03|1974-04-03#1974-04-03#1974-04-04|1974-04-04#1974-04-04#1974-04-05|1974-04-05#1974-04-05#1974-04-06|1974-04-06#1974-04-06#1974-04-07|1974-04-07#1974-04-07#1974-04-08|1974-04-08#1974-04-08#1974-04-09|1974-04-09#1974-04-09#1974-04-10|1974-04-10#1974-04-10#1974-04-11|1974-04-11#1974-04-11#1974-04-12|1974-04-12#1974-04-12#1974-04-13|1974-04-13#1974-04-13#1974-04-14|1974-04-14#1974-04-14#1974-04-15|1974-04-15#1974-04-15#1974-04-16|1974-04-16#1974-04-16#1974-04-17|1974-04-17#1974-04-17#1974-04-18|1974-04-18#1974-04-18#1974-04-19|1974-04-19#1974-04-19#1974-04-20|1974-04-20#1974-04-20#1974-04-21|1974-04-21#1974-04-21#1974-04-22|1974-04-22#1974-04-22#1974-04-23|1974-04-23#1974-04-23#1974-04-24|1974-04-24#1974-04-24#1974-04-25|1974-04-25#1974-04-25#1974-04-26|1974-04-26#1974-04-26#1974-04-27|1974-04-27#1974-04-27#1974-04-28|1974-04-28#1974-04-28#1974-04-29|1974-04-29#1974-04-29#1974-04-30|1974-04-30#1974-04-30#1974-05-01|1974-05-01#1974-05-01#1974-05-02|1974-05-02#1974-05-02#1974-05-03|1974-05-03#1974-05-03#1974-05-04|1974-05-04#1974-05-04#1974-05-05|1974-05-05#1974-05-05#1974-05-06|1974-05-06#1974-05-06#1974-05-07|1974-05-07#1974-05-07#1974-05-08|1974-05-08#1974-05-08#1974-05-09|1974-05-09#1974-05-09#1974-05-10|1974-05-10#1974-05-10#1974-05-11|1974-05-11#1974-05-11#1974-05-12|1974-05-12#1974-05-12#1974-05-13|1974-05-13#1974-05-13#1974-05-14|1974-05-14#1974-05-14#1974-05-15|1974-05-15#1974-05-15#1974-05-16|1974-05-16#1974-05-16#1974-05-17|1974-05-17#1974-05-17#1974-05-18|1974-05-18#1974-05-18#1974-05-19|1974-05-19#1974-05-19#1974-05-20|1974-05-20#1974-05-20#1974-05-21|1974-05-21#1974-05-21#1974-05-22|1974-05-22#1974-05-22#1974-05-23|1974-05-23#1974-05-23#1974-05-24|1974-05-24#1974-05-24#1974-05-25|1974-05-25#1974-05-25#1974-05-26|1974-05-26#1974-05-26#1974-05-27|1974-05-27#1974-05-27#1974-05-28|1974-05-28#1974-05-28#1974-05-29|1974-05-29#1974-05-29#1974-05-30|1974-05-30#1974-05-30#1974-05-31|1974-05-31#1974-05-31#1974-06-01|1974-06-01#1974-06-01#1974-06-02|1974-06-02#1974-06-02#1974-06-03|1974-06-03#1974-06-03#1974-06-04|1974-06-04#1974-06-04#1974-06-05|1974-06-05#1974-06-05#1974-06-06|1974-06-06#1974-06-06#1974-06-07|1974-06-07#1974-06-07#1974-06-08|1974-06-08#1974-06-08#1974-06-09|1974-06-09#1974-06-09#1974-06-10|1974-06-10#1974-06-10#1974-06-11|1974-06-11#1974-06-11#1974-06-12|1974-06-12#1974-06-12#1974-06-13|1974-06-13#1974-06-13#1974-06-14|1974-06-14#1974-06-14#1974-06-15|1974-06-15#1974-06-15#1974-06-16|1974-06-16#1974-06-16#1974-06-17|1974-06-17#1974-06-17#1974-06-18|1974-06-18#1974-06-18#1974-06-19|1974-06-19#1974-06-19#1974-06-20|1974-06-20#1974-06-20#1974-06-21|1974-06-21#1974-06-21#1974-06-22|1974-06-22#1974-06-22#1974-06-23|1974-06-23#1974-06-23#1974-06-24|1974-06-24#1974-06-24#1974-06-25|1974-06-25#1974-06-25#1974-06-26|1974-06-26#1974-06-26#1974-06-27|1974-06-27#1974-06-27#1974-06-28|1974-06-28#1974-06-28#1974-06-29|1974-06-29#1974-06-29#1974-06-30|1974-06-30#1974-06-30#1974-07-01|1974-07-01#1974-07-01#1974-07-02|1974-07-02#1974-07-02#1974-07-03|1974-07-03#1974-07-03#1974-07-04|1974-07-04#1974-07-04#1974-07-05|1974-07-05#1974-07-05#1974-07-06|1974-07-06#1974-07-06#1974-07-07|1974-07-07#1974-07-07#1974-07-08|1974-07-08#1974-07-08#1974-07-09|1974-07-09#1974-07-09#1974-07-10|1974-07-10#1974-07-10#1974-07-11|1974-07-11#1974-07-11#1974-07-12|1974-07-12#1974-07-12#1974-07-13|1974-07-13#1974-07-13#1974-07-14|1974-07-14#1974-07-14#1974-07-15|1974-07-15#1974-07-15#1974-07-16|1974-07-16#1974-07-16#1974-07-17|1974-07-17#1974-07-17#1974-07-18|1974-07-18#1974-07-18#1974-07-19|1974-07-19#1974-07-19#1974-07-20|1974-07-20#1974-07-20#1974-07-21|1974-07-21#1974-07-21#1974-07-22|1974-07-22#1974-07-22#1974-07-23|1974-07-23#1974-07-23#1974-07-24|1974-07-24#1974-07-24#1974-07-25|1974-07-25#1974-07-25#1974-07-26|1974-07-26#1974-07-26#1974-07-27|1974-07-27#1974-07-27#1974-07-28|1974-07-28#1974-07-28#1974-07-29|1974-07-29#1974-07-29#1974-07-30|1974-07-30#1974-07-30#1974-07-31|1974-07-31#1974-07-31#1974-08-01|1974-08-01#1974-08-01#1974-08-02|1974-08-02#1974-08-02#1974-08-03|1974-08-03#1974-08-03#1974-08-04|1974-08-04#1974-08-04#1974-08-05|1974-08-05#1974-08-05#1974-08-06|1974-08-06#1974-08-06#1974-08-07|1974-08-07#1974-08-07#1974-08-08|1974-08-08#1974-08-08#1974-08-09|1974-08-09#1974-08-09#1974-08-10|1974-08-10#1974-08-10#1974-08-11|1974-08-11#1974-08-11#1974-08-12|1974-08-12#1974-08-12#1974-08-13|1974-08-13#1974-08-13#1974-08-14|1974-08-14#1974-08-14#1974-08-15|1974-08-15#1974-08-15#1974-08-16|1974-08-16#1974-08-16#1974-08-17|1974-08-17#1974-08-17#1974-08-18|1974-08-18#1974-08-18#1974-08-19|1974-08-19#1974-08-19#1974-08-20|1974-08-20#1974-08-20#1974-08-21|1974-08-21#1974-08-21#1974-08-22|1974-08-22#1974-08-22#1974-08-23|1974-08-23#1974-08-23#1974-08-24|1974-08-24#1974-08-24#1974-08-25|1974-08-25#1974-08-25#1974-08-26|1974-08-26#1974-08-26#1974-08-27|1974-08-27#1974-08-27#1974-08-28|1974-08-28#1974-08-28#1974-08-29|1974-08-29#1974-08-29#1974-08-30|1974-08-30#1974-08-30#1974-08-31|1974-08-31#1974-08-31#1974-09-01|1974-09-01#1974-09-01#1974-09-02|1974-09-02#1974-09-02#1974-09-03|1974-09-03#1974-09-03#1974-09-04|1974-09-04#1974-09-04#1974-09-05|1974-09-05#1974-09-05#1974-09-06|1974-09-06#1974-09-06#1974-09-07|1974-09-07#1974-09-07#1974-09-08|1974-09-08#1974-09-08#1974-09-09|1974-09-09#1974-09-09#1974-09-10|1974-09-10#1974-09-10#1974-09-11|1974-09-11#1974-09-11#1974-09-12|1974-09-12#1974-09-12#1974-09-13|1974-09-13#1974-09-13#1974-09-14|1974-09-14#1974-09-14#1974-09-15|1974-09-15#1974-09-15#1974-09-16|1974-09-16#1974-09-16#1974-09-17|1974-09-17#1974-09-17#1974-09-18|1974-09-18#1974-09-18#1974-09-19|1974-09-19#1974-09-19#1974-09-20|1974-09-20#1974-09-20#1974-09-21|1974-09-21#1974-09-21#1974-09-22|1974-09-22#1974-09-22#1974-09-23|1974-09-23#1974-09-23#1974-09-24|1974-09-24#1974-09-24#1974-09-25|1974-09-25#1974-09-25#1974-09-26|1974-09-26#1974-09-26#1974-09-27|1974-09-27#1974-09-27#1974-09-28|1974-09-28#1974-09-28#1974-09-29|1974-09-29#1974-09-29#1974-09-30|1974-09-30#1974-09-30#1974-10-01|1974-10-01#1974-10-01#1974-10-02|1974-10-02#1974-10-02#1974-10-03|1974-10-03#1974-10-03#1974-10-04|1974-10-04#1974-10-04#1974-10-05|1974-10-05#1974-10-05#1974-10-06|1974-10-06#1974-10-06#1974-10-07|1974-10-07#1974-10-07#1974-10-08|1974-10-08#1974-10-08#1974-10-09|1974-10-09#1974-10-09#1974-10-10|1974-10-10#1974-10-10#1974-10-11|1974-10-11#1974-10-11#1974-10-12|1974-10-12#1974-10-12#1974-10-13|1974-10-13#1974-10-13#1974-10-14|1974-10-14#1974-10-14#1974-10-15|1974-10-15#1974-10-15#1974-10-16|1974-10-16#1974-10-16#1974-10-17|1974-10-17#1974-10-17#1974-10-18|1974-10-18#1974-10-18#1974-10-19|1974-10-19#1974-10-19#1974-10-20|1974-10-20#1974-10-20#1974-10-21|1974-10-21#1974-10-21#1974-10-22|1974-10-22#1974-10-22#1974-10-23|1974-10-23#1974-10-23#1974-10-24|1974-10-24#1974-10-24#1974-10-25|1974-10-25#1974-10-25#1974-10-26|1974-10-26#1974-10-26#1974-10-27|1974-10-27#1974-10-27#1974-10-28|1974-10-28#1974-10-28#1974-10-29|1974-10-29#1974-10-29#1974-10-30|1974-10-30#1974-10-30#1974-10-31|1974-10-31#1974-10-31#1974-11-01|1974-11-01#1974-11-01#1974-11-02|1974-11-02#1974-11-02#1974-11-03|1974-11-03#1974-11-03#1974-11-04|1974-11-04#1974-11-04#1974-11-05|1974-11-05#1974-11-05#1974-11-06|1974-11-06#1974-11-06#1974-11-07|1974-11-07#1974-11-07#1974-11-08|1974-11-08#1974-11-08#1974-11-09|1974-11-09#1974-11-09#1974-11-10|1974-11-10#1974-11-10#1974-11-11|1974-11-11#1974-11-11#1974-11-12|1974-11-12#1974-11-12#1974-11-13|1974-11-13#1974-11-13#1974-11-14|1974-11-14#1974-11-14#1974-11-15|1974-11-15#1974-11-15#1974-11-16|1974-11-16#1974-11-16#1974-11-17|1974-11-17#1974-11-17#1974-11-18|1974-11-18#1974-11-18#1974-11-19|1974-11-19#1974-11-19#1974-11-20|1974-11-20#1974-11-20#1974-11-21|1974-11-21#1974-11-21#1974-11-22|1974-11-22#1974-11-22#1974-11-23|1974-11-23#1974-11-23#1974-11-24|1974-11-24#1974-11-24#1974-11-25|1974-11-25#1974-11-25#1974-11-26|1974-11-26#1974-11-26#1974-11-27|1974-11-27#1974-11-27#1974-11-28|1974-11-28#1974-11-28#1974-11-29|1974-11-29#1974-11-29#1974-11-30|1974-11-30#1974-11-30#1974-12-01|1974-12-01#1974-12-01#1974-12-02|1974-12-02#1974-12-02#1974-12-03|1974-12-03#1974-12-03#1974-12-04|1974-12-04#1974-12-04#1974-12-05|1974-12-05#1974-12-05#1974-12-06|1974-12-06#1974-12-06#1974-12-07|1974-12-07#1974-12-07#1974-12-08|1974-12-08#1974-12-08#1974-12-09|1974-12-09#1974-12-09#1974-12-10|1974-12-10#1974-12-10#1974-12-11|1974-12-11#1974-12-11#1974-12-12|1974-12-12#1974-12-12#1974-12-13|1974-12-13#1974-12-13#1974-12-14|1974-12-14#1974-12-14#1974-12-15|1974-12-15#1974-12-15#1974-12-16|1974-12-16#1974-12-16#1974-12-17|1974-12-17#1974-12-17#1974-12-18|1974-12-18#1974-12-18#1974-12-19|1974-12-19#1974-12-19#1974-12-20|1974-12-20#1974-12-20#1974-12-21|1974-12-21#1974-12-21#1974-12-22|1974-12-22#1974-12-22#1974-12-23|1974-12-23#1974-12-23#1974-12-24|1974-12-24#1974-12-24#1974-12-25|1974-12-25#1974-12-25#1974-12-26|1974-12-26#1974-12-26#1974-12-27|1974-12-27#1974-12-27#1974-12-28|1974-12-28#1974-12-28#1974-12-29|1974-12-29#1974-12-29#1974-12-30|1974-12-30#1974-12-30#1974-12-31|1974-12-31#1974-12-31#1975-01-01|1975-01-01#1975-01-01#1975-01-02|1975-01-02#1975-01-02#1975-01-03|1975-01-03#1975-01-03#1975-01-04|1975-01-04#1975-01-04#1975-01-05|1975-01-05#1975-01-05#1975-01-06|1975-01-06#1975-01-06#1975-01-07|1975-01-07#1975-01-07#1975-01-08|1975-01-08#1975-01-08#1975-01-09|1975-01-09#1975-01-09#1975-01-10|1975-01-10#1975-01-10#1975-01-11|1975-01-11#1975-01-11#1975-01-12|1975-01-12#1975-01-12#1975-01-13|1975-01-13#1975-01-13#1975-01-14|1975-01-14#1975-01-14#1975-01-15|1975-01-15#1975-01-15#1975-01-16|1975-01-16#1975-01-16#1975-01-17|1975-01-17#1975-01-17#1975-01-18|1975-01-18#1975-01-18#1975-01-19|1975-01-19#1975-01-19#1975-01-20|1975-01-20#1975-01-20#1975-01-21|1975-01-21#1975-01-21#1975-01-22|1975-01-22#1975-01-22#1975-01-23|1975-01-23#1975-01-23#1975-01-24|1975-01-24#1975-01-24#1975-01-25|1975-01-25#1975-01-25#1975-01-26|1975-01-26#1975-01-26#1975-01-27|1975-01-27#1975-01-27#1975-01-28|1975-01-28#1975-01-28#1975-01-29|1975-01-29#1975-01-29#1975-01-30|1975-01-30#1975-01-30#1975-01-31|1975-01-31#1975-01-31#1975-02-01|1975-02-01#1975-02-01#1975-02-02|1975-02-02#1975-02-02#1975-02-03|1975-02-03#1975-02-03#1975-02-04|1975-02-04#1975-02-04#1975-02-05|1975-02-05#1975-02-05#1975-02-06|1975-02-06#1975-02-06#1975-02-07|1975-02-07#1975-02-07#1975-02-08|1975-02-08#1975-02-08#1975-02-09|1975-02-09#1975-02-09#1975-02-10|1975-02-10#1975-02-10#1975-02-11|1975-02-11#1975-02-11#1975-02-12|1975-02-12#1975-02-12#1975-02-13|1975-02-13#1975-02-13#1975-02-14|1975-02-14#1975-02-14#1975-02-15|1975-02-15#1975-02-15#1975-02-16|1975-02-16#1975-02-16#1975-02-17|1975-02-17#1975-02-17#1975-02-18|1975-02-18#1975-02-18#1975-02-19|1975-02-19#1975-02-19#1975-02-20|1975-02-20#1975-02-20#1975-02-21|1975-02-21#1975-02-21#1975-02-22|1975-02-22#1975-02-22#1975-02-23|1975-02-23#1975-02-23#1975-02-24|1975-02-24#1975-02-24#1975-02-25|1975-02-25#1975-02-25#1975-02-26|1975-02-26#1975-02-26#1975-02-27|1975-02-27#1975-02-27#1975-02-28|1975-02-28#1975-02-28#1975-03-01|1975-03-01#1975-03-01#1975-03-02|1975-03-02#1975-03-02#1975-03-03|1975-03-03#1975-03-03#1975-03-04|1975-03-04#1975-03-04#1975-03-05|1975-03-05#1975-03-05#1975-03-06|1975-03-06#1975-03-06#1975-03-07|1975-03-07#1975-03-07#1975-03-08|1975-03-08#1975-03-08#1975-03-09|1975-03-09#1975-03-09#1975-03-10|1975-03-10#1975-03-10#1975-03-11|1975-03-11#1975-03-11#1975-03-12|1975-03-12#1975-03-12#1975-03-13|1975-03-13#1975-03-13#1975-03-14|1975-03-14#1975-03-14#1975-03-15|1975-03-15#1975-03-15#1975-03-16|1975-03-16#1975-03-16#1975-03-17|1975-03-17#1975-03-17#1975-03-18|1975-03-18#1975-03-18#1975-03-19|1975-03-19#1975-03-19#1975-03-20|1975-03-20#1975-03-20#1975-03-21|1975-03-21#1975-03-21#1975-03-22|1975-03-22#1975-03-22#1975-03-23|1975-03-23#1975-03-23#1975-03-24|1975-03-24#1975-03-24#1975-03-25|1975-03-25#1975-03-25#1975-03-26|1975-03-26#1975-03-26#1975-03-27|1975-03-27#1975-03-27#1975-03-28|1975-03-28#1975-03-28#1975-03-29|1975-03-29#1975-03-29#1975-03-30|1975-03-30#1975-03-30#1975-03-31|1975-03-31#1975-03-31#1975-04-01|1975-04-01#1975-04-01#1975-04-02|1975-04-02#1975-04-02#1975-04-03|1975-04-03#1975-04-03#1975-04-04|1975-04-04#1975-04-04#1975-04-05|1975-04-05#1975-04-05#1975-04-06|1975-04-06#1975-04-06#1975-04-07|1975-04-07#1975-04-07#1975-04-08|1975-04-08#1975-04-08#1975-04-09|1975-04-09#1975-04-09#1975-04-10|1975-04-10#1975-04-10#1975-04-11|1975-04-11#1975-04-11#1975-04-12|1975-04-12#1975-04-12#1975-04-13|1975-04-13#1975-04-13#1975-04-14|1975-04-14#1975-04-14#1975-04-15|1975-04-15#1975-04-15#1975-04-16|1975-04-16#1975-04-16#1975-04-17|1975-04-17#1975-04-17#1975-04-18|1975-04-18#1975-04-18#1975-04-19|1975-04-19#1975-04-19#1975-04-20|1975-04-20#1975-04-20#1975-04-21|1975-04-21#1975-04-21#1975-04-22|1975-04-22#1975-04-22#1975-04-23|1975-04-23#1975-04-23#1975-04-24|1975-04-24#1975-04-24#1975-04-25|1975-04-25#1975-04-25#1975-04-26|1975-04-26#1975-04-26#1975-04-27|1975-04-27#1975-04-27#1975-04-28|1975-04-28#1975-04-28#1975-04-29|1975-04-29#1975-04-29#1975-04-30|1975-04-30#1975-04-30#1975-05-01|1975-05-01#1975-05-01#1975-05-02|1975-05-02#1975-05-02#1975-05-03|1975-05-03#1975-05-03#1975-05-04|1975-05-04#1975-05-04#1975-05-05|1975-05-05#1975-05-05#1975-05-06|1975-05-06#1975-05-06#1975-05-07|1975-05-07#1975-05-07#1975-05-08|1975-05-08#1975-05-08#1975-05-09|1975-05-09#1975-05-09#1975-05-10|1975-05-10#1975-05-10#1975-05-11|1975-05-11#1975-05-11#1975-05-12|1975-05-12#1975-05-12#1975-05-13|1975-05-13#1975-
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 21:29:20
Hi Stephan,

aber das das "NUR" fett gedruckt ist, hast du nicht gesehen ... ;)


Zitat
Die Anzahl der anzuzeigenden Datensätze der Kommandos "delSeqDoublets adviceDelete", "delSeqDoublets adviceRemain" ist zunächst begrenzt (default 1000) und kann durch das Attribut "limit" angepasst werden. Die Einstellung von "limit" hat keinen Einfluss auf die "delSeqDoublets delete" Funktion, sondern beeinflusst NUR die Anzeige der Daten.

Das heißt, es wird natürlich die gesamte DB (eventuell begrenzt durch Time-Eingrenzung, device, reading) entsprechend der gewählten Aggregation ausgewertet. Es wird dir nach Abschluß die Anzahl der Sätze die gelöscht werden würden ausgegeben, aber nur 1000 Datensätze angezeigt. Kannst du mit "limit" einstellen. Stell dir vor dein Browser soll 100000 zu löschende Datensätze ausgeben .... das würde sehr lange dauern.

EDIT: den langen String den du in der blockinginfo siehst, ist das Timestamp-Array was ausgewertet werden soll. Das ist ohne Einschränkung über die gesamte DB mit täglicher Aggregation soweit ich sehe.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 23 Januar 2018, 21:46:22
Zitat von: DS_Starter am 23 Januar 2018, 21:29:20
aber das das "NUR" fett gedruckt ist, hast du nicht gesehen ... ;)

Hups. Okay, nächste Runde geht auf mich  :-[

Das bedeutet für den praktischen Einsatz, dass das *NUR* :) mit Timestamp (und Device) Grenzen einsetzbar ist.
Werd ich testen.

Zitatdas Timestamp-Array was ausgewertet werden soll. Das ist ohne Einschränkung über die gesamte DB mit täglicher Aggregation soweit ich sehe.
Das ist default. Ich habe (wie du bereits bemerkt hast :) nichts eingestellt ...

Grüße,
Stephan


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 21:54:21
Ja, aber dein Test ist ein guter Hinweis darauf, dass es durchaus Sinn macht die Logik etwas zu ändern. Wenn man ohne EInschränkungen mit großen Datenbanken auf schwachen Systemen hantiert, kann das schnell mal den Speicher auslasten.
Hab da schon eine Idee.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 23 Januar 2018, 22:05:08
Mir ist gerade aufgefallen, dass nach dem update auf Revision
Latest Revision: 15962
der "blockinginfo" -Befehl nicht mehr vorhanden ist.

https://forum.fhem.de/index.php/topic,83222.0.html

In der DbRep.pm scheinst du ohne diesen auszukommen... ist die Funktionalität gleich?

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2018, 22:19:06
Zitat
Mir ist gerade aufgefallen, dass nach dem update auf Revision
Latest Revision: 15962
der "blockinginfo" -Befehl nicht mehr vorhanden ist.

Sicher ? Ich habe auch 15962 im Einsatz, aber blockinginfo gibts noch.

ZitatIn der DbRep.pm scheinst du ohne diesen auszukommen... ist die Funktionalität gleich?
Sie ist ähnlich. Nachgebaut und abgeändert damit es dem gewünschten Umfang entspricht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 24 Januar 2018, 09:21:16
Hallo,

ich bin völlig überrascht über die zahlreichen Reaktionen durch meinen Beitrag.
Es wäre natürlich schön dies direkt mit in das Tool zu implementieren. Wenn nicht, sollte dies aber im Wiki erwähnt werden, auf welche Weise der Mittelwert gebildet wird.
Ich kann mir natürlich eine Perlfunktion bauen die die Mittelwertberechnung übernimmt. Diese kann ich wenn ihr wollt dann natürlich auch hier zur Verfügung stellen.


Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2018, 09:35:49
Hallo Martin,

war ich selber auch überrascht.  ;)
Darauf, dass es sich bei der averageValue Funktion um das arithmetische Mittel handelt, habe ich jetzt in der commandref explizit hingewiesen. Damit sollte die Bildung eindeutig  beschrieben sein.
Gern kannst du uns deine Perlfunktion zur Mittelwertberechnung  zur Verfügung stellen.

Ich stelle es mir momentan so vor, dass die bisherige averageValue  Funktion als arithmetischer Mittelwertbildung so erhalten bleibt wie sie ist.
Zusätzlich könnte man eine Funktion "averageValueSpecial" mit verschiedenen Aufrufoptionen, "meteoTemperature" etc. anzubieten.
Dort könnten dann die "besonderen" Mittelwertbildungen abgebildet sein.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2018, 21:08:12
Hallo Stephan, @all,

in der V7.5.4 ist die "delSeqDoublets"-Funktion hinsichtlich Laufzeit und Ressorcenverbrauch optimiert.

Auf meinem Testsystem auf SQLite wird für die Analyse mit "delSeqDoublets adviceRemain" von 2,5 GB und 12 Mio Datensätzen ohne Eingrenzung eine Laufzeit von nur noch 155 Sekunden erreicht.

Die Attribute "executeBeforeProc", "executeAfterProc" sind nun auch für "delSeqDoublets" verfügbar.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 26 Januar 2018, 10:24:02
alles klar, wird geladen und getestet. Puh, grad hab ich einige Baustellen, das muss in die queue.

Habe gerade versucht, etwas aus einer Datenbank zu löschen. Dieser Befehl schlägt fehl.

Aufbau:
octocore mit 16GB RAM
SQLite mit 400 MB
countCurrent 220 2018-01-26 10:08:06
countHistory 2840982 2018-01-26 10:08:06

logdb:
Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./dabafhem_db.conf
   DEF        ./dabafhem_db.conf .*:.*
   MODE       synchronous
   MODEL      SQLITE
   NAME       logdb
   NR         17
   NTFY_ORDER 50-logdb
   PID        5193
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   VERSION    3.7.1
   dbconn     SQLite:dbname=/opt/fhem/dabafhem.db
   dbuser     
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
   READINGS:
     2018-01-26 10:08:06   countCurrent    220
     2018-01-26 10:08:06   countHistory    2840982
     2018-01-26 09:53:25   state           connected
   cache:
     index      0
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Include
   DbLogType  SampleFill/History
   room       LOG


repdb:
Internals:
   DATABASE   /opt/fhem/dabafhem.db
   DEF        logdb
   LASTCMD    sqlCmd delete
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         19
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       0
   VERSION    7.5.5
   HELPER:
     DBLOGDEVICE logdb
     CV:
       aggregation no
       aggsec     1
       destr      2018-01-20
       dsstr      2018-01-10
       epoch_seconds_end 1516402800
       mestr      01
       msstr      01
       testr      00:00:00
       tsstr      00:00:00
       wdadd      432000
       yestr      2018
       ysstr      2018
   READINGS:
     2018-01-26 10:08:01   errortext       DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

     2018-01-26 10:08:01   state           error
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./dabafhem_db.conf
     DEF        ./dabafhem_db.conf .*:.*
     MODE       synchronous
     MODEL      SQLITE
     NAME       logdb
     NR         17
     NTFY_ORDER 50-logdb
     PID        5193
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     VERSION    3.7.1
     dbconn     SQLite:dbname=/opt/fhem/dabafhem.db
     dbuser     
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2018-01-26 10:08:06   countCurrent    220
       2018-01-26 10:08:06   countHistory    2840982
       2018-01-26 09:53:25   state           connected
     cache:
       index      0
Attributes:
   DbLogExclude .*
   allowDeletion 1
   room       LOG
   timestamp_begin 2018-01-10 00:00:00
   timestamp_end 2018-01-20 00:00:00


Befehl:
set repdb sqlCmd delete from history where DEVICE='global'
Fehler:
DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

LOG:
Zitat2018.01.26 10:21:21.811 4: DbLog logdb -> ################################################################
2018.01.26 10:21:21.812 4: DbLog logdb -> ###              start of new Logcycle                       ###
2018.01.26 10:21:21.812 4: DbLog logdb -> ################################################################
2018.01.26 10:21:21.812 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:21:21.812 4: DbLog logdb -> check Device: repdb , Event: state: error
2018.01.26 10:21:21.812 5: DbLog logdb -> parsed Event: repdb , Event: state: error
2018.01.26 10:21:21.812 4: DbRep repdb -> BlockingCall sqlCmd_ParseDone finished
2018.01.26 10:21:49.705 4: DbLog logdb -> ################################################################
2018.01.26 10:21:49.705 4: DbLog logdb -> ###              start of new Logcycle                       ###
2018.01.26 10:21:49.705 4: DbLog logdb -> ################################################################
2018.01.26 10:21:49.705 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:21:49.706 4: DbLog logdb -> check Device: repdb , Event: state: running
2018.01.26 10:21:49.706 5: DbLog logdb -> parsed Event: repdb , Event: state: running
2018.01.26 10:21:49.706 4: DbRep repdb - -------- New selection ---------
2018.01.26 10:21:49.706 4: DbRep repdb - Command: sqlCmd delete from history where DEVICE='global'
2018.01.26 10:21:49.707 5: DbRep repdb - Timestamp begin epocheseconds: 1515538800
2018.01.26 10:21:49.707 4: DbRep repdb - Timestamp begin human readable: 2018-01-10 00:00:00
2018.01.26 10:21:49.707 5: DbRep repdb - Timestamp end epocheseconds: 1516402800
2018.01.26 10:21:49.708 4: DbRep repdb - Timestamp end human readable: 2018-01-20 00:00:00
2018.01.26 10:21:49.708 5: DbRep repdb - weekday of start for selection: Mi  ->  wdadd: 432000
2018.01.26 10:21:49.708 4: DbRep repdb - Aggregation: no
2018.01.26 10:21:49.728 4: DbRep repdb -> Start BlockingCall sqlCmd_DoParse
2018.01.26 10:21:49.729 4: DbRep repdb - SQL execute: delete from history where DEVICE='global';
2018.01.26 10:22:19.791 2: DbRep repdb - ERROR - DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

2018.01.26 10:22:19.792 4: DbRep repdb -> BlockingCall sqlCmd_DoParse finished
2018.01.26 10:22:19.794 4: DbRep repdb -> Start BlockingCall sqlCmd_ParseDone
2018.01.26 10:22:19.795 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.795 4: DbLog logdb -> ###              start of new Logcycle                       ###
2018.01.26 10:22:19.795 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.795 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:22:19.796 4: DbLog logdb -> check Device: repdb , Event: errortext: DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

2018.01.26 10:22:19.796 5: DbLog logdb -> parsed Event: repdb , Event: errortext: DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.

2018.01.26 10:22:19.798 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.798 4: DbLog logdb -> ###              start of new Logcycle                       ###
2018.01.26 10:22:19.798 4: DbLog logdb -> ################################################################
2018.01.26 10:22:19.798 4: DbLog logdb -> number of events received: 1 for device: repdb
2018.01.26 10:22:19.798 4: DbLog logdb -> check Device: repdb , Event: state: error
2018.01.26 10:22:19.799 5: DbLog logdb -> parsed Event: repdb , Event: state: error
2018.01.26 10:22:19.799 4: DbRep repdb -> BlockingCall sqlCmd_ParseDone finished

Wie kann das kommen?
Ich hoff ich hab keine Infos vergessen..

ah, dazu hätt ich noch nen feature-wunsch.
Ich weiss nicht, ob das einfach geht, aber in den letzten Tagen wünschte ich mir immer sehnlicher eine Funktion, die mir .. die letzten, ka, 5 Befehle als Button zur Verfügung stellt, damit ich nicht den ganzen Text nochmal tippen muss ...


Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 26 Januar 2018, 10:31:37
Zitat von: DS_Starter am 24 Januar 2018, 21:08:12
in der V7.5.4

ich hab ausm *update* bereits die 7.5.5?

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Januar 2018, 10:48:01
Moin Stephan,

Zitat2018.01.26 10:22:19.791 2: DbRep repdb - ERROR - DBD::SQLite::st execute failed: database is locked at ./FHEM/93_DbRep.pm line 4808.
Ja sowas kann kommen wenn du zum Beispiel einen SQL-Editor aufhast und die DB geladen ist. SQLite ist da nicht so gentle wie MySQL.

Zitatich hab ausm *update* bereits die 7.5.5?
Ja, bin grad fleißig  ;)

ZitatIch weiss nicht, ob das einfach geht, aber in den letzten Tagen wünschte ich mir immer sehnlicher eine Funktion, die mir .. die letzten, ka, 5 Befehle als Button zur Verfügung stellt, damit ich nicht den ganzen Text nochmal tippen muss ...
Ich denk mal drüber nach. Habe ja das gleiche Problem. Behelfe mir momentan damit dass ich meine am häufigsten benötigten Statements in das Attribut comment im Device eintrage und dann per Coppy&Paste ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 26 Januar 2018, 10:51:05
Moin Heiko,

Zitat von: DS_Starter am 26 Januar 2018, 10:48:01
Ja sowas kann kommen wenn du zum Beispiel einen SQL-Editor aufhast und die DB geladen ist. SQLite ist da nicht so gentle wie MySQL.
Hab ich aber nicht. Nur logdb und repdb.
und auch nur ein device.
und weils grade brandneu installiert ist, auch *keine* sonstigen Events.
und weil die mit DbLogExclude ausgeschlossen sind, schon gar keine Events.


ZitatJa, bin grad fleißig  ;)
Klasse, weiter so ;)

ZitatAttribut comment im Device eintrage und dann per Coppy&Paste ...


dito. ist aber auch nicht userfreundlich, wenn sich die Statements öfter verändern :)
Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Januar 2018, 10:56:00
Zitat
Hab ich aber nicht. Nur logdb und repdb.
und auch nur ein device.
und weils grade brandneu installiert ist, auch *keine* sonstigen Events.
und weil die mit DbLogExclude ausgeschlossen sind, schon gar keine Events.

Das war nur ein Beispiel was sein könnte. Musst du mal googeln. SQLite ist auch nicht gerade mein Liebling unter den DB's ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Januar 2018, 19:05:16
Hallo Stephan, @all,

die V7.6.0 steht nun zum Download und Test bereit.

Was ist neu ?

* Die Ergebnisreadings von fetchrows beinhalten nun nach dem Datum/Zeit-Feld einen Index. Dieser ist  bei jedem unikaten Datensatz "1".  Gibt es multiple Vorkommen, d.h. exakt gleiche Datensätze im Selektionsbereich, wird der Index mit jedem Duplikat hochgezählt. Dadurch erkennt man doppelte Sätze leicht, da die Readings sich sonst überdecken. Sieht etwa so aus:

Zitat
     2018-01-26 18:35:14   2017-10-22_02-56-36_1__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_1__sysmon1__loadavg 0.09 0.04 0.01 
     2018-01-26 18:35:14   2017-10-22_02-56-36_1__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_1__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00 
     2018-01-26 18:35:14   2017-10-22_02-56-36_1__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB,  0.27 %, Free: 1289.52 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_2__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_2__sysmon1__loadavg 0.09 0.04 0.01 
     2018-01-26 18:35:14   2017-10-22_02-56-36_2__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_2__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00 
     2018-01-26 18:35:14   2017-10-22_02-56-36_2__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB,  0.27 %, Free: 1289.52 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_3__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB  
     2018-01-26 18:35:14   2017-10-22_02-56-36_3__sysmon1__loadavg 0.09 0.04 0.01 
     2018-01-26 18:35:14   2017-10-22_02-56-36_3__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_3__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00 
     2018-01-26 18:35:14   2017-10-22_02-56-36_3__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB,  0.27 %, Free: 1289.52 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_4__sysmon1__eth0_diff RX: 2.17 MB, TX: 0.22 MB, Total: 2.39 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_4__sysmon1__loadavg 0.09 0.04 0.01 
     2018-01-26 18:35:14   2017-10-22_02-56-36_4__sysmon1__ram Total: 2010.07 MB, Used: 342.15 MB, 17.02 %, Free: 1667.92 MB 
     2018-01-26 18:35:14   2017-10-22_02-56-36_4__sysmon1__stat_cpu_percent 0.26 0.00 0.12 99.36 0.26 0.00 0.00 
     2018-01-26 18:35:14   2017-10-22_02-56-36_4__sysmon1__swap Total: 1293.00 MB, Used: 3.47 MB,  0.27 %, Free: 1289.52 MB

* fetchrows kann nun auch Ergebniswerte darstellen, die ein Pipe "|" enthalten. Die Änderung wurde notwendig, da DbLog in der aktuellen (noch nicht eingecheckten Version) diese Daten nun auch loggen kann.

* es gibt ein neues Set-Komando "sqlCmdHistory" (Stephan wird sich hoffentlich freuen  :D)
Dieses Command enthält eine Drop-Downliste der bisher verwendeten SQL-Statements mit "sqlCmd". Dieses Set-Kommando taucht erst auf, wenn man mindestens einmal ein "set .. sqlCmd xxxx" ausgeführt hat. Die Liste habe ich momentan auf 10 beschränkt, kann aber leicht abgeändert werden. In der Liste gibt es immer am Schluß den Eintrag "___purge_historylist___". Mit dieser Selektion kann man die Liste löschen. Die Historie ist auch nach einem Restart noch vorhanden, weil sie in einem CacheFile gesichert wird. Jedes DbRep-Device führt seine eigene History-Liste. Ein einmal verwendetes Kommando wird nicht noch einmal eingetragen.
(siehe Screeshot).

Ich hoffe diese Erweiterungen stellen einen weiteren Mehrwertgewinn im Modul dar. Viel Spaß beim Testen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Januar 2018, 09:41:14
Guten Morgen,

da vielleicht nicht jeder eine History-Liste haben möchte und darüber hinaus es wünschenswert wäre, die Länge dieser Liste einstellbar zu haben wenn man sie nutzen möchte, habe ich mit der V7.6.1 das Verhalten etwas geändert.

Mit dem neuen Attribut "sqlCmdHistoryLength" schaltet man die Verwendung ein und kann dabei die Länge in 5er Stufen bis z.Zt. 50 festlegen.

EDIT: Habe noch ein Highlighting für mehrfach vorkommende Datensätze eingebaut. Wer möchte setzt sich das Attribut "fetchMarkDuplicates". Es sind ein paar Farben vordefiniert. Aber mit widgetoverride kann man sich an dieser Stelle den colorpicker einbauen:


attr <dbrep> widgetOverride fetchMarkDuplicates:colorpicker


Das Ergebnis ist im Screenshot zu sehen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 27 Januar 2018, 16:15:58
Moin Heiko,

klasse Idee!

Eine Bitte: könntest du mal hier reinschauen:
https://forum.fhem.de/index.php?topic=73490.msg756527#msg756527

Da geht's unter anderem um meine Memory-Thematik...

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Januar 2018, 16:33:44
Hallo Stephan,

habe da mal reingeschaut und auch gleich mal "fhemdebug memusage" ausgeführt.
Stürzt aber nichts ab und gibt einwandfrei Rückmeldung.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Januar 2018, 11:34:14
Hallo zusammen,

nachdem ich die V7.6.1 recht ausgiebig getestet habe, werde ich sie wahrscheinlich heute noch einchecken. Vielleicht findet sich noch der eine oder andere der bis dahin Feedback gibt.

Danach würde ich mich mal der Average-Thematik zuwenden.

Allerdings ist mir während der Arbeit an 7.6.1 aufgefallen, dass es wohl zur Zeit keine Löschmöglichkeit für echte Dubletten gibt, also für Datensätze die tatsächlich doppelt/mehrfach in der DB vorhanden sind (nicht zu verwechseln mit den sequentiellen Datensätzen mit unterschiedlichen Timestamps und deren Wertegleichheit).
Mit herkömmlichen SQL-Mitteln kann man die ja auch nicht löschen, da in diesem Fall wegen eines fehlenden eindeutigen Schlüssels sowohl die Dubletten als auch der Ausgangsdatensatz gelöscht werden.

Da das Modul jetzt in der Lage ist Dubletten zu behandeln, steht natürlich die Frage ob eine Erweiterung für die Löschung von echten Dubletten benötigt/gewünscht ist ?
Oder übersehe ich Möglichkeiten mit einfachen SQL-Statements und so etwas wäre überflüssig ?

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 28 Januar 2018, 12:27:41
Zitat von: DS_Starter am 28 Januar 2018, 11:34:14
Oder übersehe ich Möglichkeiten mit einfachen SQL-Statements und so etwas wäre überflüssig ?

In Oracle gibt es dazu die virtuelle spalte ROWID. Damit kann man zumindest den einen identischen Wert behalten, restliche löschen. In MySQL gibt es sowas nicht direkt, aber scheinbar einen Workaround ...
https://stackoverflow.com/questions/2728413/equivalent-of-oracle-s-rowid-in-mysql

Link habe ich aber nicht getestet. Aber alles mit Aufwand verbunden. Andere DB's weiß ich nicht.

Ansonten umständlicher Weg den Satz lokal zwischenspeichern, doppelte Sätze löschen und im Anschluss wieder einfügen.

Normal sollten aber überhaupt keine doppelten Sätze (alle Felder identisch) vorhanden sein ... also Aufwand wahrscheinlich höher als Nutzen. Unique-Index wäre aus DB-Design die sauberste Lösung, ohne irgendwelchen Nachteil. Im Falle einer Duplette --> Insert-Fehler ins Log.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Januar 2018, 12:37:49
Hallo kadettilac89,

danke für den Link, schaue ich mir mal an.

Meine Frage war eher allgemeiner Natur, weil es immer wieder Nutzer gibt die über doppelte Datensätze klagen.
Ich persönlich arbeite mit primary key seit ich die Unterstützung dafür in DbLog eingebaut habe, aber nicht jeder Nutzer tut das und ist ja auch nicht der "default" bei der Einrichtung von DbLog.

Außerdem muß ich mit DbLog/DbRep auch SQLite und Postgre SQL unterstützen.

ZitatAnsonten umständlicher Weg den Satz lokal zwischenspeichern, doppelte Sätze löschen und im Anschluss wieder einfügen.
Genau ein solches/ähnliches Verfahren würde ich in ein set-Kommando gießen als Pflegetool ... sofern eben Bedarf besteht.

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2018, 14:42:12
Hallo Martin (knxler), @all,

Mit der Version 7.7.0 habe ich begonnen, die Voraussetzung für die Verwendung unterschiedlicher Mittelwertberechnungsmethoden zu implementieren.
Der set-Befehl "averageValue" bleibt unverändert und stellt durch SQL-AVG die einfache arithmetische Mittelwertberechnung dar.
Zusätzlich habe ich die Variante für die Berechnung des Tagesmittels entsprechend der Vorschriften des DWD eingebaut.

Für die averageValue-Funktion gibt es nun das Attribut "averageCalcForm" mit zur Zeit zwei Auswahlmöglichkeiten:

* avgArithmeticMean - Berechnung arithmetischer Mittelwert (default) -> ist gleichbedeutend wenn Attr nicht gesetzt (wie bisher)
* avgDailyMeanGWS - Berechnung des Tagesmittels von Temperaturen gemäß den Vorschriften des deutschen Wetterdienstes (https://www.dwd.de/DE/leistungen/klimadatendeutschland/beschreibung_tagesmonatswerte.html),  GWS = German Weather Service

Wird "avgDailyMeanGWS" benutzt, wird automatisch die aggregation=day verwendet. Entsprechend der Eingrenzung über timestamp_begin (z.B. previous_month_begin) kann man sich damit die Durchschnittstemperaturen der Tage entsprechend der DWD-Regeln für einen ganzen Monat usw. ermitteln. Mit der Verwendung von "set ... averageValue writeToDB" kann man die berechneten Werte wie gweohnt in die DB zurückschreiben  -> SVG-Anzeige.

Sollten die Messwerte eines Tages gemäß den DWD-Richtlinien ungenügend sein, wird im Ergebnis des Tages "insufficient values" ausgegeben.
Für die Berechnung mit "avgArithmeticMean" könnten jedoch genügend Werte vorliegen !

Die unterschiedlichen Ergebnisse beider Methoden sieht man recht gut in den angehängten Screenshots.
Wenn ich wieder Zeit habe, schaue ich mir die Average-Methode an auf die Joe hingewiesen hat und würde mich bis dahin über Feedback freuen.

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Februar 2018, 10:23:19
Guten Morgen,

manchmal macht man eine DB-Auswertung oder Anzeige die jede Menge Readings erzeugt.
Dann ist es lästig wenn man herunterscrollen muss um Attribute nachzuschauen, zu ändern etc. Außerdem wird die ganze Readingliste in fhem.save gespeichert.
Eine erzeugte Liste mit 7000 Reading verbraucht auch etwas Hauptspeicher.

Damit man sich ganz einfach der Daten entledigen kann, gibt es nun den set-Befehl "eraseReadings". Er löscht alle erzeugten Readings im Device außer "state" und Readings, die in der Ausnahmeliste (Attribut "readingPreventFromDel") enthalten sind.

Version 7.8.0 im ersten Beitrag.

schönes WE,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 05 Februar 2018, 15:42:59
Hallo Heiko,

danke für die schnelle Reaktion. Leider kann ich mit diesem Mittelwert nichts anfangen. Ich bin dabei meine Vissmann Heizung fein zu tunen. Dabei hilft mir nur der gemittelte wert über die Zeit. Da ich genau wissen möchte, wie war die Temperatur gestern.
Mir ist aber aufgefallen, das deine Bereichsangabe nicht so funktioniert wie ich es erwartet habe. Wenn du den Bereich von 2018-02-20 00:00:00 bis 2018-02-02 23:59:59 angibst und einen Datensatzexport machst, sollte dann nicht auch ein existierender Wert bei 23:59:59 mit in das File geschrieben werden? Bei mir wird dann der letzte Wert weggelassen.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Februar 2018, 19:08:42
Hallo Martin,

ZitatLeider kann ich mit diesem Mittelwert nichts anfangen.
Die Mittelwertberechnung des DWD war nur der Anfang und diente gleich dazu die notwendige Struktur im Modul für unterschiedliche Average-Berechnungen zu schaffen.
Jetzt kommt die zeitgewichtete Funktion dran, die dir hoffentlich die benötigten Ergebnisse bringt... bin dabei.

Zitat
Mir ist aber aufgefallen, das deine Bereichsangabe nicht so funktioniert wie ich es erwartet habe. Wenn du den Bereich von 2018-02-20 00:00:00 bis 2018-02-02 23:59:59 angibst und einen Datensatzexport machst, sollte dann nicht auch ein existierender Wert bei 23:59:59 mit in das File geschrieben werden? Bei mir wird dann der letzte Wert weggelassen.
Habe ich global mit Version 7.8.1 im ersten Beitrag korrigiert. 
Probiers mal bitte bei dir aus. Sollte nun wie erwartet reagieren.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 05 Februar 2018, 22:54:49
Hallo Heiko,

leider fehlt noch immer der letzte Wert.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Februar 2018, 23:08:27
Hi Martin,

mach mal bitte ein verbose 4 log und poste die SQL-Statements aus dem Log.
Du hast das Modul auch nach 93_DbRep umbenannt und FHEM restartet bzw. reload 93_DbRep gemacht ?

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 06 Februar 2018, 07:59:14
Hallo Heiko,

hier die Logs von DBRep

Zitat2018.02.06 07:54:20.493 4: DbRep DBReport - -------- New selection ---------
2018.02.06 07:54:20.493 4: DbRep DBReport - Command: exportToFile
2018.02.06 07:54:20.495 4: DbRep DBReport - Timestamp begin human readable: 2018-02-02 00:00:00
2018.02.06 07:54:20.496 4: DbRep DBReport - Timestamp end human readable: 2018-02-02 23:59:59
2018.02.06 07:54:20.497 4: DbRep DBReport - Aggregation: no
2018.02.06 07:54:20.532 4: DbRep DBReport -> Start BlockingCall expfile_DoParse
2018.02.06 07:54:20.551 4: DbRep DBReport - SQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where READING = 'Temp_Aussen_Tiefpass' AND TIMESTAMP >= '2018-02-02 00:00:00' AND TIMESTAMP <= '2018-02-02 23:59:59' ORDER BY TIMESTAMP;
2018.02.06 07:54:20.845 4: DbRep DBReport -> BlockingCall expfile_DoParse finished
2018.02.06 07:54:20.852 4: DbRep DBReport -> Start BlockingCall expfile_ParseDone
2018.02.06 07:54:20.881 3: DbRep DBReport - Number of exported datasets from fhem to file ./log/dbexport.log: / -- Temp_Aussen_Tiefpass -- 129.
2018.02.06 07:54:20.881 4: DbRep DBReport -> BlockingCall expfile_ParseDone finished

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 06 Februar 2018, 08:04:40
Hallo noch einmal,

zu deinen Fragen. Ja ich habe das Modul umbenannt und ich habe neu gestartet. Im DeviceOverview von DBReport wird die Version 7.8.1 angezeigt.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Februar 2018, 08:28:37
Hallo Martin,

ZitatSQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where READING = 'Temp_Aussen_Tiefpass' AND TIMESTAMP >= '2018-02-02 00:00:00' AND TIMESTAMP <= '2018-02-02 23:59:59' ORDER BY TIMESTAMP;

Also die Selektion ist korrekt. Ich kann mir momentan nicht vorstellen wieso der Datensatz mit dem Timestamp 23:59:59 nicht exportiert werden sollte.
Kannst du bitte noch ein verbose 5 anfertigen.
Das kann ziemlich groß werden. Vllt. als File anhängen. Und wenn möglich auch das resultierende Exportfile.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 06 Februar 2018, 10:14:53
Hallo Heiko,

hier der Output.
Ich habe den Zeitraum bei den Output_Daten bewusst erweitert, damit du siehst das es um 23:59:59 einen Datensatz gibt.
Kann es sein, dass der Select einen Datensatz um 23:59:59.000 erwartet?
Der Datensatz ist natürlich ein paar 1000stel später. Kannst du den Select entsprechend auf 23:59:59.999 erweitern?

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 06 Februar 2018, 10:16:40
Hallo

hier die Logeinträge mit Loglevel 5

Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Februar 2018, 12:23:55
Also wenn ich nichts übersehen habe, werden doch alle datensätze in die output_daten exportiert oder interpretiere ich das file falsch ?
Komischerweise zeigt tatsächlich das log dass der letzte satz nicht geschrieben werden würde wobei er ja in output_daten drin steht.
Wo siehst du dass der letzte timestamp  23:59:59.xxx ist ? deine Db scheint doch ebenfalls wie es der standard im logging ist ohne millisekunden zu arbeiten.

bekomme es momentan noch nicht zusammen. vllt. kannst nochmal erläutern was ich falsch sehe oder falsch interpretiere.

lg,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 06 Februar 2018, 13:18:45
Hallo Heiko,

ich habe für die Output_Daten den timestamp_end auf 2018-02-03 00:20:59 gesetzt, damit du siehst das es dort auch einen Datensatz gibt. Der wird aber wenn ich timestamp_end auf 2018-02-02 23:59:59 setze nicht mit ausgegeben.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Februar 2018, 18:49:07
Hallo Martin,

konnte es jetzt bei mir nachstellen und bin momentan etwas ratlos.
Es betrifft genau den Satz um 23:59:59. Aber nur bei exportToFile. Mit der gleichen Selektion, was intern auch das gleiche Selectstatement ist, bringt fetchrows den Datensatz mit raus.
Kannst du bei dir auch mal probieren.

Das ist schon ziemlich kurios.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Februar 2018, 19:14:57
Also es hat tatsächlich etwas mit den Millisekunden zu tun. Wenn ich 23:59:59.999 ergänze wird der Datensatz auch bei exportToFile mit selektiert. Mir ist aber absolut nicht klar womit das zusammenhängen könnte da das Statement von fetchrows gleich ist und dort auch so funktioniert.
Ich muss mal schauen wie ich das eingebaut bekomme damit es auch bei Postgre/Sqlite keine Probleme gibt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 06 Februar 2018, 19:22:44
Hallo Heiko,

fetchrows funktioniert auch bei mir.
Das ist dann aber wirklich komisch.
Wenn ich dir irgendwie helfen kann lass es mich wissen.

Grüße
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Februar 2018, 22:07:39
Hallo Martin,

das hat jetzt eine Weile gedauert bis ich das Problem identifizieren konnte. Das hatte etwas damit zu tun wie ich mit Platzhaltern in SQL-Staements umgehe.
Habe auch schon viel getestet und sieht gut aus.
Die Version 7.8.1 im ersten Beitrag habe ich erneut nochgeladen.

Probier es mal bitte bei dir aus.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 Februar 2018, 19:28:49
Hallo Heiko,

leider habe ich erst jetzt Zeit gefunden deine neue Version zu testen.
Leider ist der Fehler aber immer noch da. Der letzte Datensatz fehlt.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2018, 20:11:04
Hi Martin,

habe es gerade bei nochmal ausgeführt. Funktioniert prima...


"2018-02-05 00:04:18","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 00:14:19","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 00:24:20","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 00:34:21","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 00:44:21","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 00:54:22","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 01:04:23","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 01:14:24","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 01:24:25","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 01:34:25","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 01:44:26","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 01:54:27","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 02:04:28","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 02:14:29","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 02:24:29","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 02:34:30","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 02:44:31","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 02:54:32","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 03:04:33","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 03:14:33","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 03:24:34","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 03:34:35","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 03:44:36","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 03:54:37","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 04:04:37","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 04:14:38","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 04:24:39","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 04:34:40","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 04:44:40","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 04:54:41","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 05:04:42","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 05:14:43","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 05:24:44","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 05:34:44","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 05:44:45","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 05:54:46","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 06:04:47","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 06:14:48","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 06:24:48","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 06:34:49","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 06:44:50","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 06:54:51","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 07:04:52","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 07:14:52","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 07:24:53","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 07:34:54","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 07:44:55","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 07:54:56","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 08:04:56","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 08:14:57","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 08:24:58","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 08:34:59","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 08:45:00","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 08:55:00","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 09:05:02","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 09:15:03","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 09:25:04","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 09:35:04","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 09:45:05","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 09:55:06","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 10:05:07","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 10:15:07","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 10:25:08","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 10:35:09","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 10:45:10","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 10:55:10","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 11:05:11","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 11:15:12","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 11:25:12","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 11:35:13","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 11:45:14","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 11:55:15","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 12:05:15","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 12:15:16","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 12:25:17","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 12:35:17","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 12:45:18","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 12:55:19","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 13:05:20","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 13:15:20","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 13:25:21","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 13:35:22","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 13:45:23","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 13:55:23","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 14:05:24","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 14:15:25","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 14:25:25","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 14:35:26","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 14:45:27","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 14:55:28","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 15:05:28","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 15:15:29","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 15:25:30","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 15:35:30","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 15:45:31","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 15:55:32","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 16:05:33","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 16:15:33","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 16:25:34","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 16:35:35","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 16:45:36","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 16:55:36","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 17:05:37","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 17:15:38","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 17:25:39","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 17:35:39","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 17:45:40","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 17:55:41","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 18:05:41","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 18:15:42","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 18:25:43","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 18:35:44","MyWetter","WEATHER","temperature: 0","temperature","0","C"
"2018-02-05 18:45:44","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 18:55:45","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 19:05:46","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 19:15:47","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 19:25:47","MyWetter","WEATHER","temperature: -1","temperature","-1","C"
"2018-02-05 19:35:48","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 19:45:49","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 19:55:49","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 20:05:50","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 20:15:51","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 20:25:52","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 20:35:52","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 20:45:53","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 20:55:54","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 21:05:55","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 21:15:55","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 21:25:56","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 21:35:57","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 21:45:58","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 21:55:58","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 22:05:59","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 22:16:00","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 22:26:01","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 22:36:01","MyWetter","WEATHER","temperature: -2","temperature","-2","C"
"2018-02-05 22:46:02","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 22:56:03","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 23:06:04","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 23:16:04","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 23:26:05","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 23:36:06","MyWetter","WEATHER","temperature: -3","temperature","-3","C"
"2018-02-05 23:46:07","MyWetter","WEATHER","temperature: -5","temperature","-5","C"
"2018-02-05 23:56:07","MyWetter","WEATHER","temperature: -5","temperature","-5","C"
"2018-02-05 23:59:59","MyWetter","WEATHER","temperature: -6","temperature","-6","C"


Mach mir mal bitte ein List von deinem DbRep-Device.
Jetzt fällt mir wirklich langsam nichts mehr ein.  :(

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 Februar 2018, 20:35:15
Hallo Heiko,

hier mein list.

Gruß
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2018, 20:56:08
List ist ok.  Ich habe dir ein verbose 5 Log von mir angehängt zum Vergleich.
Schau mal ob du irgendetwas siehst was dir auffält im Unterschied zu deinem Log.


2018.02.07 20:53:12.888 4: DbRep Rep.LogDB1 - -------- New selection ---------
2018.02.07 20:53:12.890 4: DbRep Rep.LogDB1 - Command: exportToFile
2018.02.07 20:53:12.892 5: DbRep Rep.LogDB1 - Timestamp begin epocheseconds: 1517785200
2018.02.07 20:53:12.893 4: DbRep Rep.LogDB1 - Timestamp begin human readable: 2018-02-05 00:00:00
2018.02.07 20:53:12.894 5: DbRep Rep.LogDB1 - Timestamp end epocheseconds: 1517871599
2018.02.07 20:53:12.895 4: DbRep Rep.LogDB1 - Timestamp end human readable: 2018-02-05 23:59:59
2018.02.07 20:53:12.896 5: DbRep Rep.LogDB1 - weekday of start for selection: Mo  ->  wdadd: 604800
2018.02.07 20:53:12.897 4: DbRep Rep.LogDB1 - Aggregation: no
2018.02.07 20:53:12.909 4: DbRep Rep.LogDB1 -> Start BlockingCall expfile_DoParse
2018.02.07 20:53:12.916 5: DbRep Rep.LogDB1 - IsTimeSet: 1, IsAggrSet: 0
2018.02.07 20:53:12.917 5: DbRep Rep.LogDB1 - Timestamp-Array:
no_aggregation#2018-02-05 00:00:00#2018-02-05 23:59:59
2018.02.07 20:53:12.918 5: DbRep Rep.LogDB1 - Device specifications use for select: MyWetter
2018.02.07 20:53:12.920 5: DbRep Rep.LogDB1 - Reading specification use for select: temperature
2018.02.07 20:53:12.921 5: DbRep Rep.LogDB1 - Device specifications use for select: MyWetter
2018.02.07 20:53:12.922 5: DbRep Rep.LogDB1 - Reading specification use for select: temperature
2018.02.07 20:53:12.923 4: DbRep Rep.LogDB1 - SQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where DEVICE = 'MyWetter' AND READING = 'temperature' AND TIMESTAMP >= '2018-02-05 00:00:00' AND TIMESTAMP <= '2018-02-05 23:59:59' ORDER BY TIMESTAMP;
2018.02.07 20:53:12.931 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 00:04:18 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.932 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 00:14:19 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.933 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 00:24:20 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.934 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 00:34:21 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.935 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 00:44:21 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.935 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 00:54:22 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.936 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 01:04:23 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.937 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 01:14:24 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.937 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 01:24:25 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.938 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 01:34:25 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.939 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 01:44:26 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.939 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 01:54:27 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.940 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 02:04:28 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.941 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 02:14:29 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.941 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 02:24:29 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.942 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 02:34:30 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.943 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 02:44:31 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.943 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 02:54:32 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.944 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 03:04:33 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.945 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 03:14:33 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.946 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 03:24:34 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.947 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 03:34:35 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:12.948 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 03:44:36 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.949 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 03:54:37 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.950 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 04:04:37 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.950 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 04:14:38 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.951 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 04:24:39 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.952 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 04:34:40 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.953 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 04:44:40 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.954 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 04:54:41 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.955 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 05:04:42 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.956 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 05:14:43 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.957 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 05:24:44 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.958 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 05:34:44 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.959 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 05:44:45 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.968 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 05:54:46 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.972 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 06:04:47 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.973 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 06:14:48 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.973 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 06:24:48 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.974 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 06:34:49 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.975 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 06:44:50 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.975 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 06:54:51 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.976 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 07:04:52 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.976 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 07:14:52 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.977 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 07:24:53 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.978 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 07:34:54 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.978 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 07:44:55 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.979 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 07:54:56 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.980 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 08:04:56 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.980 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 08:14:57 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.981 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 08:24:58 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.982 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 08:34:59 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.982 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 08:45:00 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.983 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 08:55:00 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.983 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 09:05:02 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.984 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 09:15:03 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.985 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 09:25:04 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.985 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 09:35:04 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.986 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 09:45:05 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.986 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 09:55:06 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.987 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 10:05:07 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.988 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 10:15:07 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.988 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 10:25:08 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.989 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 10:35:09 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:12.989 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 10:45:10 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.990 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 10:55:10 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.991 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 11:05:11 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.991 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 11:15:12 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.992 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 11:25:12 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.993 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 11:35:13 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.993 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 11:45:14 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.994 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 11:55:15 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.994 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 12:05:15 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.995 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 12:15:16 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.996 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 12:25:17 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.996 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 12:35:17 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:12.997 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 12:45:18 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.998 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 12:55:19 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.998 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 13:05:20 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.999 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 13:15:20 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:12.999 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 13:25:21 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.001 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 13:35:22 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.002 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 13:45:23 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.003 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 13:55:23 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.003 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 14:05:24 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.004 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 14:15:25 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.005 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 14:25:25 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.005 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 14:35:26 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.006 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 14:45:27 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.006 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 14:55:28 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.007 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 15:05:28 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.008 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 15:15:29 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.008 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 15:25:30 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.009 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 15:35:30 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.010 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 15:45:31 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.010 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 15:55:32 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.011 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 16:05:33 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.011 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 16:15:33 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.012 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 16:25:34 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.013 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 16:35:35 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.013 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 16:45:36 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.014 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 16:55:36 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.015 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 17:05:37 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.015 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 17:15:38 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.016 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 17:25:39 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.016 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 17:35:39 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.017 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 17:45:40 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.018 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 17:55:41 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.018 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 18:05:41 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.019 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 18:15:42 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.020 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 18:25:43 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.020 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 18:35:44 MyWetter WEATHER temperature: 0 temperature 0 �C
2018.02.07 20:53:13.021 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 18:45:44 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.022 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 18:55:45 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.022 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 19:05:46 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.023 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 19:15:47 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.024 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 19:25:47 MyWetter WEATHER temperature: -1 temperature -1 �C
2018.02.07 20:53:13.024 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 19:35:48 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.025 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 19:45:49 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.025 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 19:55:49 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.026 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 20:05:50 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.027 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 20:15:51 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.027 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 20:25:52 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.028 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 20:35:52 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.029 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 20:45:53 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.030 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 20:55:54 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.030 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 21:05:55 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.031 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 21:15:55 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.032 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 21:25:56 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.032 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 21:35:57 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.033 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 21:45:58 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.033 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 21:55:58 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.034 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 22:05:59 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.035 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 22:16:00 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.035 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 22:26:01 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.036 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 22:36:01 MyWetter WEATHER temperature: -2 temperature -2 �C
2018.02.07 20:53:13.037 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 22:46:02 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.037 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 22:56:03 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.038 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:06:04 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.039 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:16:04 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.039 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:26:05 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.040 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:36:06 MyWetter WEATHER temperature: -3 temperature -3 �C
2018.02.07 20:53:13.041 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:46:07 MyWetter WEATHER temperature: -5 temperature -5 �C
2018.02.07 20:53:13.041 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:56:07 MyWetter WEATHER temperature: -5 temperature -5 �C
2018.02.07 20:53:13.042 5: DbRep Rep.LogDB1 -> write row:  2018-02-05 23:59:59 MyWetter WEATHER temperature: -6 temperature -6 C
2018.02.07 20:53:13.044 4: DbRep Rep.LogDB1 -> BlockingCall expfile_DoParse finished
2018.02.07 20:53:13.046 4: DbRep Rep.LogDB1 -> Start BlockingCall expfile_ParseDone
2018.02.07 20:53:13.052 3: DbRep Rep.LogDB1 - Number of exported datasets from fhemtest1 to file /sds1/backup/export.txt: MyWetter -- temperature -- 145.
2018.02.07 20:53:13.056 4: DbRep Rep.LogDB1 -> BlockingCall expfile_ParseDone finished

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 Februar 2018, 22:11:09
Hallo Heiko,

ich kann nichts finden.
Kann es sein das du den alten Source eventuell hochgeladen hast? Die Version ist ja identisch zur vorherigen?

Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2018, 22:20:36
Kann natürlich sein. Habe die V7.9.0 hochgeladen.
Hier ist auch schon die zeitgewichtet Durchschnittsberechnung integriert. Ich hatte inzwischen weiterentwickelt.
Jetzt kannst du gleich beides austesten  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 Februar 2018, 22:40:17
Hallo noch einmal,

ich habe die 7.9.0 geladen. Der letzte Datensatz fehlt aber weiterhin.
Mit welchen set kann ich denn den neuen Mittelwert berechnen?

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 Februar 2018, 22:48:01
Hallo,

ich habe mal andere Tage genommen.
Bei exportToFile fehlt immer der letzte Datensatz und bei fetchrows wird der letzte ausgegeben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2018, 22:52:21
Zitatich habe die 7.9.0 geladen. Der letzte Datensatz fehlt aber weiterhin.
wirklich eigenartig.  grenze mal time begin bis ende auf zwei Tage ein und aggregation auf day. Dann bitte wieder ein verbose 5. mal schauen wie es dann bei dir aussieht.
Ich kann mir wirklich nicht erklären wieso der letzte Wert bei mir kommt und bei dir nicht.

ZitatMit welchen set kann ich denn den neuen Mittelwert berechnen?
Du stellst Attribut averageCalcForm = avgTimeWeightMean. Die Berechnung ist wie üblich mit set averageValue zu starten.
Zeitabgrenzung und aggregation wie üblich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2018, 23:06:56
Wir schauen morgen nochmal. Vielleicht fällt mir bis dahin noch etwas ein.

GN,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 08 Februar 2018, 19:35:59
Hallo Heiko,

leider habe ich momentan nicht viel Zeit.
Hier nun der neue Select über 2 Tage.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2018, 19:51:31
Hallo Martin,

habe die V7.9.0 im ersten Beitrag neu hochgeladen. Die export Funktion ist umgebaut und verwendet nun die Architektur wie fetchrows.
Funktioniert bei mir nach wie vor einwandfrei und nun hoffe ich natürllich dass du auch positives Feddback geben kannst.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 08 Februar 2018, 20:02:26
Hallo noch einmal,

ich habe nun auch den Mittelwert auch mal getestet. Der passt auch nicht ganz.

Ich habe mal meine Excelliste angehängt wie ich den Wert berechne.

Grüße
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 08 Februar 2018, 20:08:59
Hallo Heiko,

jetzt habe ich auch den letzten Datensatz. Super.

Danke!!

Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2018, 20:15:57
Zitatjetzt habe ich auch den letzten Datensatz. Super.
Dann haben wir das schonmal geschafft.  :)

Also ich berechne den gewichteten Mittelwert so wie auf der Seite http://massmatics.de/merkzettel/#!837:Gewichteter_Mittelwert beschrieben:

         # zeitgewichteten Mittelwert berechnen
         # http://massmatics.de/merkzettel/#!837:Gewichteter_Mittelwert
         #
         # $tsum = timestamp letzter Messpunkt - timestamp erster Messpunkt
         # $t1 = timestamp wert1
         # $t2 = timestamp wert2
         # $dt = $t2 - $t1
         # $t1 = $t2
         # .....
         # (val1*$dt/$tsum) + (val2*$dt/$tsum) + .... + (valn*$dt/$tsum)
         #

Deine Excel habe ich gelesen, kann aber nicht genau erkennen was/wo es nicht ganz passt. Kannst du noch einen Hinweis geben was du genau meinst ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 08 Februar 2018, 20:51:47
Also deine Berechnung entspricht meiner.
Ich habe dein Verfahren in meine Excelliste eingegeben -> selbes Ergebnis.
Ich vermute mal das es Rundungsfehler sind. Eventuell ist es von Vorteil mit großen Werten zu rechnen.
Also erst Multiplizieren und Summe bilden und dann Zuletzt durch die  Anzahl der Sekunden teilen.
Da beim rechnen mit kleinen Werten ein Rundungsfehler entstehen kann. Ist mir mal in einem C-Programm auf einem uC aufgefallen.
Mir ist nicht klar mit welcher Genauigkeit Perl rechnet.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2018, 21:12:20

2018.02.08 21:02:34.559 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.48538011695906
2018.02.08 21:02:34.560 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.49242344337798
2018.02.08 21:02:34.561 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.4994667697969
2018.02.08 21:02:34.561 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.50651009621582
2018.02.08 21:02:34.562 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.51354170328962
2018.02.08 21:02:34.563 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.52058502970854
2018.02.08 21:02:34.563 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.52762835612746
2018.02.08 21:02:34.564 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.53467168254638
2018.02.08 21:02:34.564 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.54170328962018
2018.02.08 21:02:34.565 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.5487466160391
2018.02.08 21:02:34.566 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.55578994245802
2018.02.08 21:02:34.566 2: DbRep Rep.LogDB1 - Row: Time: 200, Value: -1, Summe: -1.55813381148262
2018.02.08 21:02:34.567 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.56517713790153
2018.02.08 21:02:34.568 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.57220874497533
2018.02.08 21:02:34.568 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.57925207139425
2018.02.08 21:02:34.569 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.58629539781317
2018.02.08 21:02:34.570 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.59332700488697
2018.02.08 21:02:34.570 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.60037033130589
2018.02.08 21:02:34.571 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.60741365772481
2018.02.08 21:02:34.571 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.6144452647986
2018.02.08 21:02:34.572 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.62148859121752
2018.02.08 21:02:34.573 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.62853191763644
2018.02.08 21:02:34.573 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.63556352471024
2018.02.08 21:02:34.574 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.64260685112916
2018.02.08 21:02:34.575 2: DbRep Rep.LogDB1 - Row: Time: 601, Value: -1, Summe: -1.64965017754808
2018.02.08 21:02:34.575 2: DbRep Rep.LogDB1 - Row: Time: 600, Value: -1, Summe: -1.65668178462188


Die Berechnung erfolgt bis 14 Stellen hinter dem Komma. Erst später im Reading wird gerundet.
Ich habe die Average Funktionen auch noch auf das Verfahren wie bei fetchrows umgestellt und neu als 7.9.0 hochgeladen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 08 Februar 2018, 22:13:25
Hallo Heiko,

ich glaube, dass ich einen Grund gefunden habe. Die Mittelwertbildung hat Probleme mit meinen über eine Routine hinzugefügten Werte.
Ich habe den Log angehängt.

Gruß
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2018, 22:26:11
Ja stimmt, weil der String <<addlog mit enthalten ist, ist es kein numerischer Feldwert.
Du müsstest in VALUE nur den Wert als solchen eintragen. Im addlog von DbLog mache ich es so, dass ich addlog als EVENT eintrage. Dann sieht man das in der DB.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 08 Februar 2018, 22:40:55
Hallo noch mal,

ich werde mich am Wochenende mal um meine Routine kümmern und mich dann melden.
Habe ich die Möglichkeit mit deinem Tool die Daten entsprechend abzuändern?
Wenn nein, dann werde ich es mal per SQL probieren.
Erst einmal vielen Dank für deine Bemühungen.

Bis dann Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Februar 2018, 08:38:48
Hallo Martin,

sowas kannst du mit DbRep auch nur mit "set ... sqlCmd" machen. Also einem eigenen Statement.
Man kann zwar Devies und Readings umbenennen, aber Values verändern geht noch nicht. Sollte ich aber mal mit vorsehen. Möglicherweise kann man das ganz gut gebrauchen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Februar 2018, 11:57:18
Hallo Martin,

Den Versionsstand 7.9.0 habe ich noch in der commandref nachgezogen und auch noch einen Filter in die Average-Berchnung eingebaut der nichtnumerische Zeichen aus dem VALUE eliminiert. Das sollte nun auch bei deinen Daten ohne Abänderung so funktionieren.
Den Stand würde ich dann auch einchecken.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2018, 13:19:58
Hallo Martin, @all,

die weiterentwickelte Version 7.10.0 enthält ein neues SET command "changeValue".

Damit ist es nun möglich die Werte der Readings (Spalte VALUE) zu ändern. Die Attribute device, reading sowie die Attribute zur Zeiteingrenzung (time.*) werden berücksichtigt. Dadurch können zu ändernde Werte eines Readings selektiv eingegrenzt werden.

Syntax:

set name changeValue "alter Wert","neuer Wert"

Die Werte alt/neu können Leerzeichen enthalten. Die Quotes sind Bestandteil der Syntax und wesentlich.

@Martin, damit kannst du deine addlog-Datensätze umarbeiten wenn du möchtest.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 11 Februar 2018, 20:58:26
Hallo Heiko,

es gibt immer noch einen kleinen Unterschied zwischen dem Mittelwert von deinem Tool und wenn ich den Wert mit Excel berechne. Kannst du mal die einzelnen berechneten Werte im Log-Level 5 ausgeben, dann werde ich einmal die Einzelwerte mit denen in meiner Excelliste vergleichen.

Zu deinem changeValue, so wie ich das verstehe, muss ich jeden einzelnen Wert auslesen und dann Step by Step ändern. Ober habe ich das falsch verstanden?

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2018, 21:26:11
Halo Martin,

die V7.10.0 habe ich mit verbose 5 an der Stelle stark erweitert.

ZitatZu deinem changeValue, so wie ich das verstehe, muss ich jeden einzelnen Wert auslesen und dann Step by Step ändern. Ober habe ich das falsch verstanden?

Ja, d.h. falsch verstanden. Du setzt das Attr device auf das relevante Device und lässt changeValue wie beschrieben laufen. Dann wird in der ganzen DB der Wert des Readings, welcher auf den angegebenen "alter Wert" matcht, auf "neuer Wert" geändert sofern der Datensatz auch das gesetzte Device enthält.
Du kannst auch noch das Reading angeben. Aber sowohl device als auch reading dienen nur der Eingrenzung beim Select.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 11 Februar 2018, 22:23:21
Hallo Heiko,

kannst du auch noch den Dividenden ausgeben? Ich glaube du benutzt einen anderen Dividenden.

Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2018, 22:31:33
gemacht.

Zur Erläuterung:  Es wird die Summenzeit verwendet, die sich aus der Differenz des Timestamp des letzten und des ersten Datensatzes ergibt, d.h. nicht unbedingt einen Tag = 86400 Sekunden. Die Summe aller Differenzzeiten zw. den Datensätzen ist gleich der Summenzeit.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Februar 2018, 18:15:12
Hallo zusammen,

für SQLite Benutzer habe ich in der Version 7.11.0 eine Möglichkeit eingebaut eine korrupte DB automatisiert zu reparieren.
Die Reparatur ist nicht garantiert (siehe Hinweis), aber sicherlich in sehr vielen Fällen eine gute Möglichkeit die DB wieder operabel zu machen.
Man kann es mit einer nicht kaputten DB ebenfalls testen.

repairSQLite - repariert eine korrupte SQLite-Datenbank.
Eine Korruption liegt im Allgemeinen vor wenn die Fehlermitteilung "database disk image is malformed" im state des DbLog-Devices erscheint. Wird dieses Kommando gestartet, wird das angeschlossene DbLog-Device zunächst automatisch für 10 Stunden (36000 Sekunden) von der Datenbank getrennt (Trennungszeit). Nach Abschluss der Reparatur erfolgt wieder eine sofortige Neuverbindung zur reparierten Datenbank.
Dem Befehl kann eine abweichende Trennungszeit (in Sekunden) als Argument angegeben werden.
Die korrupte Datenbank wird als <database>.corrupt im gleichen Verzeichnis gespeichert.

    Beispiel:
    set <name> repairSQLite
    # Die Datenbank wird repariert, Trennungszeit beträgt 10 Stunden
    set <name> repairSQLite 600
    # Die Datenbank wird repariert, Trennungszeit beträgt 10 Minuten

    Hinweis:
    Es ist nicht garantiert, dass die Reparatur erfolgreich verläuft und keine Daten verloren gehen. Je nach Schwere der Korruption kann Datenverlust 
    auftreten oder die Reparatur scheitern, auch wenn kein Fehler im Ablauf signalisiert wird. Ein Backup der Datenbank sollte unbedingt vorhanden sein !


Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Februar 2018, 09:34:17
Hallo zusammen,

für die Backupfunktionen dumpMySQL bzw. dumpSQLite gibt es nun die Möglichkeit die erstellten Dumpfiles zu komprimieren.
Dazu gibt es das Attribut "dumpCompress".

Die entsprechnden Restorefunktionen können die komprimierten Files direkt verarbeiten. Sie werden im Drop-Down-Menü mit angezeigt.

File im ersten Beitrag.

viele Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 16 Februar 2018, 19:10:06
Hallo Heiko,

sorry das ich mich erst jetzt melde. Leider habe ich momentan nicht so viel Zeit um mich um mein FHEM zu kümmern.
Nun aber die Info zu deinem Mittelwert. Der ist Korrekt. Excel scheint offenbar beim Umgang mit Zeitdifferenzen ein Problem zu haben und macht dann bei Divisionen oder Multiplikationen in den letzten Stellen einen Fehler.
Kannst du mir jetzt noch einmal näher erläutern wie ich es schaffe meinen Text aus den Datenfeldern zu löschen?

Gruß und Danke!!

Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Februar 2018, 19:39:00
Hallo Martin,

danke für die Rückmeldung.  :)

ZitatKannst du mir jetzt noch einmal näher erläutern wie ich es schaffe meinen Text aus den Datenfeldern zu löschen?
Für eine einfache Ersetzung hatte ich vorgesehen:

set name changeValue "alter String","neuer String"
Das klappt aber nur wenn der Zahlenwert in "alter String" immer gleich ist, sonst würde man den Wert falsch ersetzen.

Ich arbeite zur Zeit an einer Erweiterung der changeValue-Funktion mit der man dann universelle Ersetzungen vornehmen kann.
Ein bisschen Geduld müstest du noch haben ...

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Februar 2018, 16:59:56
Hallo zusammen,

die V7.13.0 im ersten Beitrag bietet nun in der Funktion changeValue dem Nutzer umfangreiche Möglichkeiten der Einflussnahme zur Werteänderung.

* changeValue - ändert den gespeicherten Wert eines Readings. Ist die Selektion auf bestimmte Device/Reading-Kombinationen durch die Attribute "device" bzw. "reading" beschränkt, werden sie genauso berücksichtigt wie gesetzte Zeitgrenzen (Attribute time.*).
Fehlen diese Beschränkungen, wird die gesamte Datenbank durchsucht und der angegebene Wert geändert.

    Syntax:
    set <name> changeValue "<alter String>","<neuer String>"

    Die Strings werden in Doppelstrich eingeschlossen und durch Komma getrennt. Dabei kann "String" sein:

    <alter String> : * ein einfacher String mit/ohne Leerzeichen, z.B. "OL 12"
                            * ein String mit Verwendung von SQL-Wildcard, z.B. "%OL%"
                     
    <neuer String> : * ein einfacher String mit/ohne Leerzeichen, z.B. "12 kWh"
                              * Perl Code eingeschlossen in {}, z.B. {$VALUE = (split(",",$VALUE))[1]}.
                                 Dem Perl-Ausdruck werden die Variablen $VALUE und $UNIT übergeben. Sie können innerhalb
                                 des Perl-Code geändert werden. Der zurückgebene Wert von $VALUE und $UNIT wird in dem Feld
                                 VALUE bzw. UNIT des Datensatzes gespeichert.                       

    Beispiele:
    set <name> changeValue "OL","12 OL"
    # der alte Feldwert "OL" wird in "12 OL" geändert.

    set <name> changeValue "%OL%","12 OL"
    # enthält das Feld VALUE den Teilstring "OL", wird es in "12 OL" geändert.

    set <name> changeValue "12 kWh","{$VALUE,$UNIT = split(" ",$VALUE)}"
    # der alte Feldwert "12 kWh" wird in VALUE=12 und UNIT=kWh gesplittet und in den Datenbankfeldern gespeichert

    set <name> changeValue "24%","{$VALUE = (split(" ",$VALUE))[0]}"
    # beginnt der alte Feldwert mit "24", wird er gesplittet und VALUE=24 gespeichert (z.B. "24 kWh")

    Zusammengefasst sind die zur Steuerung von changeValue relevanten Attribute:

        device    : Selektion nur von Datensätzen die <device> enthalten
        reading    : Selektion nur von Datensätzen die <reading> enthalten
        time.*    : eine Reihe von Attributen zur Zeitabgrenzung
        executeBeforeProc    : ausführen FHEM Kommando (oder perl-Routine) vor Start changeValue
        executeAfterProc    : ausführen FHEM Kommando (oder perl-Routine) nach Ende changeValue


    Hinweis:
    Obwohl die Funktion selbst non-blocking ausgelegt ist, sollte das zugeordnete DbLog-Device im asynchronen Modus betrieben werden um ein Blockieren von FHEMWEB zu vermeiden (Tabellen-Lock).


@Martin, damit kannst du deine Aufgabenstellung nun umsetzen. Falls Fragen sind ... gerne posten.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ToKa am 25 Februar 2018, 14:29:30
Hallo Heiko,

ich fange gerade an, Dein tolles Modul zu nutzen. Dabei würde ich gerne in meiner Datenbank bei einigen Readings die Spalte Value um die Einheiten bereinigen, so wie Du es beschreibst.

Zitat von: DS_Starter am 17 Februar 2018, 16:59:56
    <neuer String> : * ein einfacher String mit/ohne Leerzeichen, z.B. "12 kWh"
                              * Perl Code eingeschlossen in {}, z.B. {$VALUE = (split(",",$VALUE))[1]}.
                                 Dem Perl-Ausdruck werden die Variablen $VALUE und $UNIT übergeben. Sie können innerhalb
                                 des Perl-Code geändert werden. Der zurückgebene Wert von $VALUE und $UNIT wird in dem Feld
                                 VALUE bzw. UNIT des Datensatzes gespeichert.                       

    set <name> changeValue "12 kWh","{$VALUE,$UNIT = split(" ",$VALUE)}"
    # der alte Feldwert "12 kWh" wird in VALUE=12 und UNIT=kWh gesplittet und in den Datenbankfeldern gespeichert

Mein Problem sind aber Einträge, die als Einheit das Prozentzeichen haben. Wie muss ich denn z.B. für Wert von "98 %" das %-Zeichen im Set-Befehl maskieren / escapen? Könnte man für alle Einträge, die mit "%" im Value vorhanden sind, mit Wildcards arbeiten oder muss ich für jeden einzelnen Wert den Befehl ausführen? (Habe leider bei Google zum Thema % ins SQL escapen nichts gefunden.)

Besten Dank und Grüße
Torsten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2018, 14:40:08
Hallo Torsten,

ich glaube, für diesen Fall muss ich noch etwas einbauen.  Gibt doch immer wieder genau das woran man noch nicht gedacht hat  ;)
Melde mich wieder ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2018, 15:13:46
Hi Torsten,

also klappt mit der vorliegenden Implementierung schon einwandfrei.
Habe es gerade nochmal getestet.
Wenn du z.B. Datensätze hast mit:


"OL %"


kannst du ausführen:


"%","{$VALUE= (split(" ",$VALUE))[0]}"  oder
"%","{$VALUE,$UNIT= split(" ",$VALUE) }"


Der Datensatz wird dann in Value = OL und Unit = % aufgesplittet und die Werte gesetzt.
Ich würde aber die Selektion mit den Attributen device und/oder reading sowie den Zeitattributen einschränken, damit er nicht durch jeden Datensatz durchgeht.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Februar 2018, 23:51:54
Guten Abend,

in der Version 7.14.0 ist es nun möglich Datensätze direkt aus der Quelldatenbank in eine weitere (Standby) Datenbank zu übertragen.

Für die Standby-Datenbank definiert man ein nicht loggendes DbLog-Device z.B. so:

define LogSQLITE1 DbLog ./db_sqlite1.conf aaaa:bbbbb

Dann kann man einfach mit

set <DbRep> syncStandby LogSQLITE1

Datensätze aus der mit DbRep verbundenen Datenbank in die DB "LogSQLITE1" übertragen.

Aus der Commandref:

* syncStandby <DbLog-Device Standby>

- Es werden die Datensätze aus der angeschlossenen Datenbank (Quelle) direkt in eine weitere Datenbank (Standby-Datenbank) übertragen. Dabei ist "<DbLog-Device Standby>" das DbLog-Device, welches mit der Standby-Datenbank verbunden ist.

Es werden alle Datensätze übertragen, die durch Timestamp-Attribute bzw. die Attribute "device", "reading" bestimmt sind.
Die Datensätze werden dabei in Zeitscheiben entsprechend der eingestellten Aggregation übertragen. Hat das Attribut "aggregation" den Wert "no" oder "month", werden die Datensätze automatisch in Tageszeitscheiben zur Standby-Datenbank übertragen. Quell- und Standby-Datenbank können unterschiedlichen Typs sein.

Die zur Steuerung der syncStandby Funktion relevanten Attribute sind:

    aggregation    : Einstellung der Zeitscheiben zur Übertragung (hour,day,week)
    device            : Übertragung nur von Datensätzen die <device> enthalten
    reading            : Übertragung nur von Datensätzen die <reading> enthalten
    time.*            : Attribute zur Zeitabgrenzung der zu übertragenden Datensätze.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 28 Februar 2018, 23:39:44
Hallo Heiko,

um die aktuellen Devices in der current Tabelle zu haben, habe ich diese geleert und wollten dann diese neu erstellen:
2018.02.28 23:32:00 4: DbRep MyDbRep - -------- New selection ---------
2018.02.28 23:32:00 4: DbRep MyDbRep - Command: tableCurrentPurge
2018.02.28 23:32:00 4: DbRep MyDbRep -> Start BlockingCall del_DoParse
2018.02.28 23:32:00 4: DbRep MyDbRep - SQL execute: delete FROM current;
2018.02.28 23:32:00 4: DbRep MyDbRep -> BlockingCall del_DoParse finished
2018.02.28 23:32:00 4: DbRep MyDbRep -> Start BlockingCall del_ParseDone
2018.02.28 23:32:00 3: DbRep MyDbRep - Entries of fhemdaten.current deleted: 967
2018.02.28 23:32:00 4: DbRep MyDbRep -> BlockingCall del_ParseDone finished
2018.02.28 23:32:05 4: DbRep MyDbRep - -------- New selection ---------
2018.02.28 23:32:05 4: DbRep MyDbRep - Command: tableCurrentFillup
2018.02.28 23:32:05 4: DbRep MyDbRep - Timestamp begin human readable: not set
2018.02.28 23:32:05 4: DbRep MyDbRep - Timestamp end human readable: not set
2018.02.28 23:32:05 4: DbRep MyDbRep -> Start BlockingCall currentfillup_Push
2018.02.28 23:32:05 4: DbRep MyDbRep - SQL execute: INSERT INTO current (TIMESTAMP,DEVICE,READING) SELECT '',device,reading FROM history where true group by device,reading ORDER BY 2 ASC, 3 ASC;
2018.02.28 23:32:05 2: DbRep MyDbRep - Insert new dataset into database failed: DBD::Pg::st execute failed: ERROR:  invalid input syntax for type timestamp: ""
LINE 1: ...RT INTO current (TIMESTAMP,DEVICE,READING) SELECT '',device,...
                                                             ^ at ./FHEM/93_DbRep.pm line 3981.

2018.02.28 23:32:05 4: DbRep MyDbRep -> BlockingCall currentfillup_Push finished
2018.02.28 23:32:05 4: DbRep MyDbRep -> Start BlockingCall currentfillup_Done
2018.02.28 23:32:05 4: DbRep MyDbRep -> BlockingCall currentfillup_Done finished


Grüße Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Februar 2018, 23:46:37
Hallo Pyro,

da ist mir so wie es aussieht ein Syntaxfehler für Postgre unterlaufen.
Schaue ich mir morgen an und fixe das ...

EDIT: der Fehler tritt bei Postgre nur auf wenn kein timestamp-Eingrenzung gemacht ist. Wenn du es eilig hast, setze die z.B. timeDiffToNow = d:180.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 01 März 2018, 08:33:10
Guten Morgen Heiko,

danke für die schnelle Antwort und den Workaround.
Mach dir keinen Stress mit der Behebung, ich kann meine Devices auch händisch in die SVG eintragen :)

Grüße
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RoKoInfo am 01 März 2018, 22:29:06
Hallo DS_Starter, hallo in die Runde,

Error bei "set DbRep delSeqDoublets delete"?

Ich bin weder ein Rechner- noch ein Fhem-Neuling, aber neu bei DbRep/DbLog. Obige Funktion finde ich toll, und diese hat auch einmal prächtig funktioniert: Pro Stunde laufen hier etwa 350 Datensätze auf, und der erste Versuch hat das Volumen auf etwa 17% (von damals etwa 20T Sätzen) reduziert.

Nun habe ich drei weitere Versuche hinter mir (mit dem gleichen, dublettenbereinigten Datensatz, der sich halt wieder verlängert hat), die alle mit einem Fehler


DBD::SQLite::st execute failed: database disk image is malformed at /usr/share/fhem/FHEM/93_DbRep.pm line 4549. 2018-03-01 21:50:08


abbrechen (nach etwa 1h bei 50T Datensätzen insgesamt). Das ganze läuft auf einem RPi mit Arch Linux seit längerem (ohne DbLog/DbRep natürlich) sehr stabil.


version =

Latest Revision: 16296

File              Rev   Last Change

fhem.pl           16291 2018-02-28 21:09:20Z rudolfkoenig
...
93_DbLog.pm       16271 2018-02-25 19:14:46Z DS_Starter (3.8.6)
93_DbRep.pm       16292 2018-02-28 21:23:28Z DS_Starter (7.14.0)
...



SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
sqlite> .version
SQLite 3.22.0 2018-01-22 18:45:57 ...
gcc-7.2.1 20180116
sqlite>



Die beiden ersten erfolglosen Versuche sind mit geringfügig älteren Versionen gelaufen, aber im wesentlichen das gleiche Fehlerbild.

Was könnte das sein? Ich kann Daten nachliefern, aber aus der Fehlerbeschreibung werde ich nicht so recht schlau. Vielen Dank im voraus.

Viele Grüße
RoKoInfo
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 März 2018, 23:14:16
Hallo RoKoInfo,

das kann eine DB-Korruption sein.

Führe aus im DbRep:

set ... repairSQLite

Wenn die DB wieder repariert ist, setze dir :


executeAfterProc set <DbLog-Device> reopen
executeBeforeProc set <DbLog-Device> reopen 3600


DbLog-Device ist das mit DbRep verbundene Device.
Durch diese Massnahme wird vermieden, dass während des Löschens von Datensätzen DbLog versucht seinerseits Daten zu schreiben.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 März 2018, 11:48:12
Hallo Pyro,

in der V7.14.1 habe ich die Syntax für Postgre gefixt.
Bitte teste es mal auch bei dir.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 03 März 2018, 09:21:37
Guten Morgen Heiko,

ich vermute mal dein Anhang hat sich heimlich davon geschlichen  ;D
Per Update kam nur 7.14.0

Grüße
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2018, 09:32:51
Morgen Pyro,

sorry ... ist immer im ersten Beitrag des Threads  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 03 März 2018, 09:38:55
Hallo Heiko,

Schande über mein Haupt, dort hätte ich auch nachschauen können.

Dafür habe ich gleich auch gute Nachrichten: funktioniert wieder wie gewünscht :)

Grüße
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2018, 09:50:32
ZitatDafür habe ich gleich auch gute Nachrichten: funktioniert wieder wie gewünscht :)

Prima, dann checke ich es ein ... ist dann morgen wirklich im Update  ;)

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 03 März 2018, 22:55:03
Hallo Heiko,

eine Kleinigkeit am Rande:
2018.03.03 21:29:21 1: PERL WARNING: Use of uninitialized value $wdadd in concatenation (.) or string at ./FHEM/93_DbRep.pm line 1785.
kam nachdem ich set delSeqDoublets adviceDelete ausgeführt habe.

Grüße
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2018, 07:34:10
Morgen Pyro,

kann ich bei mir gerade nicht nachvollziehen, d.h. bei mir kommt die Warnung nicht.
Vielleicht kommt sie nur in einer bestimmten Konstellation.
Kannst du mir dazu bitte mal ein List deines benutzten Devices machen damit ich das nachstellen kann ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 04 März 2018, 14:17:16
Hallo Heiko,

damit du nicht über die unterschiedlichen Zeiten wunderst, die Warnung stammt aus meinem Echtsystem und heute hab ich mal im Log vom Testsystem nachgeschaut:

2018.03.03 16:41:19 4: DbRep MyDbRep - -------- New selection ---------
2018.03.03 16:41:19 4: DbRep MyDbRep - Command: delSeqDoublets adviceRemain
2018.03.03 16:41:19 5: DbRep MyDbRep - Timestamp begin epocheseconds: 3600
2018.03.03 16:41:19 4: DbRep MyDbRep - Timestamp begin human readable: 1970-01-01 01:00:00
2018.03.03 16:41:19 5: DbRep MyDbRep - Timestamp end epocheseconds: 1520095279
2018.03.03 16:41:19 4: DbRep MyDbRep - Timestamp end human readable: 2018-03-03 16:41:19
2018.03.03 16:41:19 1: PERL WARNING: Use of uninitialized value $wdadd in concatenation (.) or string at ./FHEM/93_DbRep.pm line 1802.


Internals:
   DATABASE   fhemdaten
   DEF        myDbLog
   LASTCMD    delSeqDoublets delete
   NAME       MyDbRep
   NOTIFYDEV  global,MyDbRep
   NR         12
   NTFY_ORDER 50-MyDbRep
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   VERSION    7.14.1
   HELPER:
     DBLOGDEVICE myDbLog
     CV:
       aggregation day
       aggsec     86400
       destr      2018-03-03
       dsstr      1970-01-01
       epoch_seconds_end 1520102116
       mestr      03
       msstr      01
       testr      18:35:16
       tsstr      01:00:00
       wdadd     
       yestr      2018
       ysstr      1970
   Helper:
     DBLOG:
       2017-11-19_22-44-35__MyDbRep__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      running
       2017-11-19_22-44-38__MyDbRep__/--/----DELETED_ROWS_HISTORY--:
         myDbLog:
           TIME       1520099208.42687
           VALUE      583507
       2017-11-19_22-44-38__MyDbRep__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      done
       2017-11-19_22-44-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1879
       2017-11-19_22-44-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.16 MB, Total: 0.16 MB
       2017-11-19_22-44-48__mySysMon__fs_boot:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
       2017-11-19_22-44-48__mySysMon__fs_root:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 30110 MB, Used: 1635 MB, 6 %, Available: 26923 MB at /
       2017-11-19_22-44-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.45 0.40 0.35
       2017-11-19_22-44-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.48 MB, 1.26 %, Free: 5786.57 MB
       2017-11-19_22-44-56__myDbLog__countHistory:
         myDbLog:
           TIME       1520099208.42687
           VALUE      9
       2017-11-19_22-44-56__myDbLog__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      countNbl
       2017-11-19_22-45-40__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      UPDATE
       2017-11-19_22-45-44__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      SHUTDOWN
       2017-11-19_22-45-52__MyDbRep__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      connected
       2017-11-19_22-46-03__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      DELETEATTR MyDbRep ftpPwd
       2017-11-19_22-46-04__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      DELETEATTR MyDbRep ftpServer
       2017-11-19_22-46-06__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      DELETEATTR MyDbRep ftpUse
       2017-11-19_22-46-08__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      DELETEATTR MyDbRep ftpUser
       2017-11-19_22-46-09__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      SAVE
       2017-11-19_22-46-19__myDbLog__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      connected
       2017-11-19_22-46-40__myDbLog__countCurrent:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0
       2017-11-19_22-46-40__myDbLog__countHistory:
         myDbLog:
           TIME       1520099208.42687
           VALUE      19
       2017-11-19_22-46-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      2046
       2017-11-19_22-46-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 2.25 MB, TX: 0.16 MB, Total: 2.41 MB
       2017-11-19_22-46-48__mySysMon__fs_root:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 30110 MB, Used: 1673 MB, 6 %, Available: 26886 MB at /
       2017-11-19_22-46-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.26 0.35 0.33
       2017-11-19_22-46-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.32 MB, 1.32 %, Free: 5600.36 MB
       2017-11-19_22-47-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      580
       2017-11-19_22-47-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.03 MB, TX: 0.02 MB, Total: 0.05 MB
       2017-11-19_22-47-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.17 0.31 0.32
       2017-11-19_22-47-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.25 MB, 1.32 %, Free: 5600.43 MB
       2017-11-19_22-48-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1062
       2017-11-19_22-48-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_22-48-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.15 0.28 0.31
       2017-11-19_22-48-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.46 MB, 1.33 %, Free: 5600.19 MB
       2017-11-19_22-49-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1909
       2017-11-19_22-49-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_22-49-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.30 0.30 0.32
       2017-11-19_22-49-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.59 MB, 1.33 %, Free: 5600.06 MB
       2017-11-19_22-50-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      730
       2017-11-19_22-50-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_22-50-48__mySysMon__fs_root:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 30110 MB, Used: 1673 MB, 6 %, Available: 26886 MB at /
       2017-11-19_22-50-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.11 0.25 0.29
       2017-11-19_22-50-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.66 MB, 1.33 %, Free: 5599.99 MB
       2017-11-19_22-51-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      2004
       2017-11-19_22-51-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_22-51-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.16 0.24 0.29
       2017-11-19_22-51-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.66 MB, 1.33 %, Free: 5583.99 MB
       2017-11-19_22-52-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      560
       2017-11-19_22-52-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.01 MB, Total: 0.02 MB
       2017-11-19_22-52-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.25 0.24 0.28
       2017-11-19_22-52-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.70 MB, 1.33 %, Free: 5583.96 MB
       2017-11-19_22-53-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1919
       2017-11-19_22-53-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_22-53-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.15 0.21 0.27
       2017-11-19_22-53-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.76 MB, 1.33 %, Free: 5583.89 MB
       2017-11-19_22-54-47__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1249
       2017-11-19_22-54-48__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_22-54-48__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.22 0.22 0.27
       2017-11-19_22-54-48__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 81.77 MB, 1.33 %, Free: 5583.88 MB
       2017-11-19_23-16-47__MyDbRep__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      connected
       2017-11-19_23-17-14__myDbLog__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      connected
       2017-11-19_23-17-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      564
       2017-11-19_23-17-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-17-43__mySysMon__fs_root:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 30110 MB, Used: 1689 MB, 6 %, Available: 26870 MB at /
       2017-11-19_23-17-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.34 0.35 0.30
       2017-11-19_23-17-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 76.21 MB, 1.24 %, Free: 5954.34 MB
       2017-11-19_23-18-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      571
       2017-11-19_23-18-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.27 0.33 0.30
       2017-11-19_23-18-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 76.51 MB, 1.25 %, Free: 5878.46 MB
       2017-11-19_23-19-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      778
       2017-11-19_23-19-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-19-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.50 0.38 0.31
       2017-11-19_23-19-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 76.43 MB, 1.24 %, Free: 5878.54 MB
       2017-11-19_23-20-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1084
       2017-11-19_23-20-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-20-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.22 0.32 0.30
       2017-11-19_23-20-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 76.45 MB, 1.24 %, Free: 5878.51 MB
       2017-11-19_23-21-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1060
       2017-11-19_23-21-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.02 MB, TX: 0.02 MB, Total: 0.04 MB
       2017-11-19_23-21-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.24 0.31 0.29
       2017-11-19_23-21-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.06 MB, 1.25 %, Free: 5877.41 MB
       2017-11-19_23-21-46__MyDbRep__1970-01-01__/__/__COUNT_history__all_between_timestamps:
         myDbLog:
           TIME       1520099208.42687
           VALUE      88
       2017-11-19_23-21-46__MyDbRep__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      done
       2017-11-19_23-22-19__myDbLog__countHistory:
         myDbLog:
           TIME       1520099208.42687
           VALUE      91
       2017-11-19_23-22-19__myDbLog__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      countNbl
       2017-11-19_23-22-41__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      SAVE
       2017-11-19_23-22-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1097
       2017-11-19_23-22-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.09 MB, TX: 0.08 MB, Total: 0.17 MB
       2017-11-19_23-22-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.31 0.31 0.29
       2017-11-19_23-22-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.17 MB, 1.26 %, Free: 5876.63 MB
       2017-11-19_23-23-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1008
       2017-11-19_23-23-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.03 MB, TX: 0.03 MB, Total: 0.06 MB
       2017-11-19_23-23-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.22 0.28 0.28
       2017-11-19_23-23-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.14 MB, 1.26 %, Free: 5876.64 MB
       2017-11-19_23-24-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1086
       2017-11-19_23-24-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-24-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.17 0.26 0.27
       2017-11-19_23-24-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.20 MB, 1.26 %, Free: 5876.58 MB
       2017-11-19_23-25-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      805
       2017-11-19_23-25-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-25-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.23 0.27 0.27
       2017-11-19_23-25-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.18 MB, 1.26 %, Free: 5876.11 MB
       2017-11-19_23-26-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      716
       2017-11-19_23-26-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-26-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.23 0.26 0.27
       2017-11-19_23-26-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.12 MB, 1.26 %, Free: 5876.16 MB
       2017-11-19_23-27-42__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1118
       2017-11-19_23-27-43__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.03 MB, TX: 0.03 MB, Total: 0.06 MB
       2017-11-19_23-27-43__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.28 0.27 0.27
       2017-11-19_23-27-43__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.41 MB, 1.26 %, Free: 5875.82 MB
       2017-11-19_23-28-05__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      ATTR myMail verbose 5
       2017-11-19_23-28-17__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      ATTR MyDbRep verbose 5
       2017-11-19_23-28-19__global__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      SAVE
       2017-11-19_23-28-29__MyDbRep__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      connected
       2017-11-19_23-28-56__myDbLog__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      connected
       2017-11-19_23-29-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      847
       2017-11-19_23-29-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.13 MB, TX: 0.18 MB, Total: 0.31 MB
       2017-11-19_23-29-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.48 0.34 0.29
       2017-11-19_23-29-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.31 MB, 1.26 %, Free: 5875.66 MB
       2017-11-19_23-30-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      554
       2017-11-19_23-30-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-30-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.23 0.29 0.27
       2017-11-19_23-30-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.36 MB, 1.26 %, Free: 5875.32 MB
       2017-11-19_23-31-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1090
       2017-11-19_23-31-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-31-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.29 0.31 0.28
       2017-11-19_23-31-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.39 MB, 1.26 %, Free: 5875.28 MB
       2017-11-19_23-32-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1106
       2017-11-19_23-32-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-32-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.35 0.31 0.28
       2017-11-19_23-32-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.48 MB, 1.26 %, Free: 5875.09 MB
       2017-11-19_23-33-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1122
       2017-11-19_23-33-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-33-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.58 0.37 0.30
       2017-11-19_23-33-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.48 MB, 1.26 %, Free: 5875.07 MB
       2017-11-19_23-34-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      502
       2017-11-19_23-34-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.05 MB, TX: 0.05 MB, Total: 0.10 MB
       2017-11-19_23-34-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.67 0.42 0.32
       2017-11-19_23-34-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.46 MB, 1.26 %, Free: 5875.09 MB
       2017-11-19_23-35-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      2073
       2017-11-19_23-35-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.03 MB, Total: 0.04 MB
       2017-11-19_23-35-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.55 0.43 0.33
       2017-11-19_23-35-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.34 MB, 1.26 %, Free: 5875.18 MB
       2017-11-19_23-36-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      498
       2017-11-19_23-36-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.02 MB, TX: 0.01 MB, Total: 0.03 MB
       2017-11-19_23-36-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.46 0.43 0.33
       2017-11-19_23-36-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.47 MB, 1.26 %, Free: 5875.05 MB
       2017-11-19_23-37-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1089
       2017-11-19_23-37-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-37-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.50 0.44 0.35
       2017-11-19_23-37-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.49 MB, 1.26 %, Free: 5875.02 MB
       2017-11-19_23-38-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      718
       2017-11-19_23-38-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-38-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.22 0.37 0.33
       2017-11-19_23-38-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.48 MB, 1.26 %, Free: 5875.02 MB
       2017-11-19_23-39-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      754
       2017-11-19_23-39-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-39-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.25 0.35 0.32
       2017-11-19_23-39-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.47 MB, 1.26 %, Free: 5875.02 MB
       2017-11-19_23-40-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1174
       2017-11-19_23-40-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-40-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.49 0.41 0.34
       2017-11-19_23-40-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.40 MB, 1.26 %, Free: 5875.08 MB
       2017-11-19_23-41-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1179
       2017-11-19_23-41-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.76 0.49 0.38
       2017-11-19_23-41-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.51 MB, 1.26 %, Free: 5874.96 MB
       2017-11-19_23-42-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      834
       2017-11-19_23-42-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-42-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.51 0.47 0.38
       2017-11-19_23-42-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.47 MB, 1.26 %, Free: 5874.99 MB
       2017-11-19_23-43-25__Statistik__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Next
       2017-11-19_23-43-25__myDbLog__countHistory:
         myDbLog:
           TIME       1520099208.42687
           VALUE      185
       2017-11-19_23-43-25__myDbLog__state:
         myDbLog:
           TIME       1520099208.42687
           VALUE      countNbl
       2017-11-19_23-43-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1465
       2017-11-19_23-43-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.02 MB, TX: 0.02 MB, Total: 0.04 MB
       2017-11-19_23-43-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.62 0.52 0.40
       2017-11-19_23-43-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 78.10 MB, 1.27 %, Free: 5874.09 MB
       2017-11-19_23-44-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1045
       2017-11-19_23-44-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.04 MB, TX: 0.02 MB, Total: 0.06 MB
       2017-11-19_23-44-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.38 0.47 0.39
       2017-11-19_23-44-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.41 MB, 1.26 %, Free: 5874.43 MB
       2017-11-19_23-45-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      480
       2017-11-19_23-45-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-45-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.32 0.44 0.38
       2017-11-19_23-45-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.48 MB, 1.26 %, Free: 5874.21 MB
       2017-11-19_23-46-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1041
       2017-11-19_23-46-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.01 MB, Total: 0.01 MB
       2017-11-19_23-46-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.65 0.51 0.41
       2017-11-19_23-46-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.49 MB, 1.26 %, Free: 5874.19 MB
       2017-11-19_23-47-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1066
       2017-11-19_23-47-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.02 MB, TX: 0.01 MB, Total: 0.03 MB
       2017-11-19_23-47-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.54 0.51 0.41
       2017-11-19_23-47-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.57 MB, 1.26 %, Free: 5874.10 MB
       2017-11-19_23-48-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      762
       2017-11-19_23-48-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-48-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.36 0.46 0.40
       2017-11-19_23-48-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.60 MB, 1.26 %, Free: 5874.06 MB
       2017-11-19_23-49-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1446
       2017-11-19_23-49-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-49-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.32 0.43 0.40
       2017-11-19_23-49-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.58 MB, 1.26 %, Free: 5874.06 MB
       2017-11-19_23-50-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1122
       2017-11-19_23-50-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-50-25__mySysMon__fs_boot:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 0 MB, Used: 0 MB, 0 %, Available: 0 MB at /boot (not available)
       2017-11-19_23-50-25__mySysMon__fs_root:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 30110 MB, Used: 1689 MB, 6 %, Available: 26870 MB at /
       2017-11-19_23-50-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.29 0.40 0.38
       2017-11-19_23-50-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.60 MB, 1.26 %, Free: 5874.04 MB
       2017-11-19_23-51-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      1097
       2017-11-19_23-51-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
       2017-11-19_23-51-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.36 0.40 0.38
       2017-11-19_23-51-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.54 MB, 1.26 %, Free: 5874.09 MB
       2017-11-19_23-52-25__mySysMon__cpu_freq:
         myDbLog:
           TIME       1520099208.42687
           VALUE      602
       2017-11-19_23-52-25__mySysMon__eth0_diff:
         myDbLog:
           TIME       1520099208.42687
           VALUE      RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
       2017-11-19_23-52-25__mySysMon__loadavg:
         myDbLog:
           TIME       1520099208.42687
           VALUE      0.64 0.45 0.40
       2017-11-19_23-52-25__mySysMon__ram:
         myDbLog:
           TIME       1520099208.42687
           VALUE      Total: 6144.00 MB, Used: 77.57 MB, 1.26 %, Free: 5874.05 MB


Tante EDIT: nachträglich Code Tag geschlossen, da das **** Forum einfach den Beitrag gekürzt hat.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2018, 14:36:44
Leider sieht man die gesetzten attribute nicht. Kannst du die bitte nochmal posten ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 04 März 2018, 14:46:34
In der Vorschau hat es noch brav alles angezeigt und beim Speichern scheinbar abgeschnitten....
Noch dazu meinen Text unten drunter einfach ins Datennirwana geschickt....  >:( >:( >:(

Vollständiges List im Anhang, hier der gewünschte Auszug:
READINGS:
     2018-03-03 19:43:30   number_rows_deleted 70286
     2018-03-03 19:43:30   state           done
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db.conf
     DEF        ./db.conf .*:.*
     MODE       asynchronous
     MODEL      POSTGRESQL
     NAME       myDbLog
     NR         9
     NTFY_ORDER 50-myDbLog
     PID        2813
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     VERSION    3.8.6
     dbconn     Pg:database=fhemdaten;host=localhost
     dbuser     fhem
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     Helper:
       DBLOG:
         countCurrent:
           myDbLog:
             TIME       1520170598.42667
             VALUE      26
         countHistory:
           myDbLog:
             TIME       1520170598.42556
             VALUE      453129
         state:
           myDbLog:
             TIME       1520170598.24708
             VALUE      countNbl
     READINGS:
       2018-03-04 13:38:44   CacheUsage      4
       2018-03-04 13:38:31   NextSync        2018-03-04 13:39:01 or if CacheUsage 500 reached
       2018-03-04 13:36:38   countCurrent    26
       2018-03-04 13:36:38   countHistory    453129
       2018-03-04 13:38:31   state           connected
     cache:
       index      10875
Attributes:
   allowDeletion 1




Dazu hätte ich auch noch einen kleinen Wunsch/Verbesserung, der die Performance deutlich steigern sollten:
Sollte kein Startwert gesetzt sein (       dsstr      1970-01-01), dann automatisch per SQL den ersten Timestamp auslesen und diesen verwenden:
SELECT min(history.TIMESTAMP) FROM fhem.history


Gruß
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RoKoInfo am 04 März 2018, 15:11:04
Zu #658

Hallo Heiko,

danke für die prompte Antwort: mittlerweile zweimal hier erfolgreich getestet mit set DbLog reopen 36000 zum Start von set DbRep delSeqDoublets delete, und set DbLog reopen zum Ende. Es funktioniert.

Eine Inkonsistenz der Datenbank hatte ich nie (immer wieder mit pragma integrity_check; kontrolliert).

Danke für die Arbeit  8)

RoKoInfo
RoKoInfo
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2018, 17:58:01
@RoKoInfo, danke für die Rückmeldung und schön dass es nun damit klappt.  :)

@Pyro... hab die Ursache der Warnung gefunden, behoben und eingecheckt. Ist dann morgen wieder im Update.

Deinen Vorschlag finde ich prima. Nur passt der nicht richtig in das non-blocking Konzept.
Die Zeitgrenzen, Aggregationen und daraus resultierenden Abfrage-Arrays werden im "Vordergrund" zusammengestellt und dann dem Hintergrundprozess (Blockingcall) übergeben. Dort passieren auch alle DB-Abfragen. Sollte etwas nicht funktionieren, die DB nicht verfügbar sein etc. hat das keine Auswirkungen auf fhem im Sinne einer Blockierung. Anders ist es wenn ich gleich am Anfang den erwähnten Select ausführe. Im Normalfall kein Problem, aber im Fehlerfall schon.
Ich werden mal darüber nachdenken, aber im Moment ist mir noch keine Lösung eingefallen ohne das gesamte Modul umbauen zu müssen.
Mal schauen ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2018, 20:54:15
Hallo Pyro, @all,

mir ist eine Idee gekommen deinen Vorschlag umzusetzen.
In der V7.14.3 (erster Beitrag) wird beim Start von FHEM einmalig der Timestamp des ältesten Datensatzes ermittelt und gespeichert sofern der Wert ermittelbar war. Man sieht den ältetsten Timestamp mit "list device" in Sektion HELPER:


   HELPER:
     DBLOGDEVICE LogSQLITE
     MINTS      2017-10-22 02:56:36


Sofern keine Beginnzeit gesetzt wurde, wird dieser Timestamp verwendet, ansonsten wie bisher.
Ich habe zwar noch nicht alles durchgetestet, aber es sieht tastsächlich gut aus.

Teste es doch auch einmal bei dir ... bzw. wer gern möchte !
Ein Restart ist erforderlich.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 März 2018, 18:29:35
Hallo Heiko,

ich habe erst heute Zeit gefunden dein changeValue zu testen. Leider klappt das nicht.
Meine db-Einträge sind z.B. "3.5 << addLog"
Mein Aufruf erfolgt mit folgender Sequenz: " << addLog","{$VALUE = (split(" ",$VALUE))[0]}
Ich habe auch mal " << addLog","{$VALUE = (split(/<+/,$VALUE))[0]}" versucht, da mit Trenner Leerzeichen entstehen ja drei Werte.
Mein executeBeforeProc steht auf 1.
Wo ist mein Fehler?

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 18:49:13
Hallo Martin,

so sollte es passen:


set <dbrep> changeValue "%<< addLog","{$VALUE = (split("<<",$VALUE))[0]}


Da vor deinem "<<" immer irgendeine Zahl kommt muss man anstelle der Zahl ein SQL-Wildcard setzen.
Wenn zwischen Zahl und "<<"  ein Leerzeichen ist (kann ich nicht erkennen), würde es besser so gehen:


set <dbrep> changeValue "%<< addLog","{$VALUE = (split(" ",$VALUE))[0]}


Edit: Noch ein Hinweis. Im Attribut "executeBeforeProc" muss man ein FHEM Kommando, z.B. "set <device> off"  oder einen Perl-Ausdruck in {} eintragen den man vor dem DbRep-Kommando ausführen möchte. Eine "1" ist da nicht richtig.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 März 2018, 19:16:26
Hallo Heiko,

leider funktionieren beide Vorschläge nicht.
Ich setze den Befehl changeValue ab, dann fetchrows.
Dann sind die Einträge aber immer noch vorhanden mit "<< addLog"
Ich habe einen Bereich definiert.
Wird der Befehl changeValue automatisch auf history angewendet?

Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 19:19:45
Ja, der behandelt die history.
Sehr komisch.
Setze doch mal verbose 4 bzw. 5 und schaue mal ins logfile.
Vllt. kommt dann der Aha-Effekt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 19:26:03
Martin, ich habe ein " hinten vergessen:


set <dbrep> changeValue "%<< addLog","{$VALUE = (split("<<",$VALUE))[0]}"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 20:16:16
Ich habe es gerade erfolgeich getestet mit :

"%addlog%","{$VALUE = (split("<<",$VALUE))[0]}"


Setze dir hinter addlog noch ein "%". Möglicherweise folgt dort noch ein nicht sichtbares Zeichen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 März 2018, 20:40:38
Hallo Heiko,

ich habe "%addlog%","{$VALUE = (split("<<",$VALUE))[0]}" und "%addlog","{$VALUE = (split("<<",$VALUE))[0]}" probiert.
Beides ohne Erfolg.
Hier mein verbous = 5 logging:

2018.03.07 20:30:31.137 1: DBReport done
2018.03.07 20:30:31.267 4: DbRep DBReport -> BlockingCall fetchrows_ParseDone finished
2018.03.07 20:30:31.538 1: set_Heizungs_val noting to do at_NiveauHK1: set_val: 7 = read_val: 7
2018.03.07 20:30:38.181 1: HMUARTLGW HMLAN1:keepAlive KeepAlive sent 4.991s too late, this might cause a disconnect!
2018.03.07 20:30:38.289 1: 192.168.0.203:2001 disconnected, waiting to reappear (HMLAN1:keepAlive)
2018.03.07 20:30:38.305 1: 192.168.0.203:2000 disconnected, waiting to reappear (HMLAN1)
2018.03.07 20:30:38.510 1: 192.168.0.203:2000 reappeared (HMLAN1)
2018.03.07 20:31:32.380 1: RCV L:0E N:21 F:82 CMD:02 SRC:Wohnzimmer_Fensterbereich_Ventil DST:Wohnzimmer_Tuer_Thermometer 0101000049 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x49) (,WAKEMEUP,RPTEN)
2018.03.07 20:32:09.427 4: DbRep DBReport - -------- New selection ---------
2018.03.07 20:32:09.428 4: DbRep DBReport - Command: changeValue
2018.03.07 20:32:09.431 5: DbRep DBReport - Timestamp begin epocheseconds: 1517526000
2018.03.07 20:32:09.431 4: DbRep DBReport - Timestamp begin human readable: 2018-02-02 00:00:00
2018.03.07 20:32:09.431 5: DbRep DBReport - Timestamp end epocheseconds: 1517612399
2018.03.07 20:32:09.432 4: DbRep DBReport - Timestamp end human readable: 2018-02-02 23:59:59
2018.03.07 20:32:09.432 5: DbRep DBReport - weekday of start for selection: Fr  ->  wdadd: 259200
2018.03.07 20:32:09.433 4: DbRep DBReport - Aggregation: no
2018.03.07 20:32:09.472 4: DbRep DBReport -> Start BlockingCall change_Push
2018.03.07 20:32:09.479 5: DbRep DBReport -> Change old value "%addlog%" to new value "{$VALUE = (split(<<,$VALUE))[0]}" in database DBLogData
2018.03.07 20:32:09.480 5: DbRep DBReport - IsTimeSet: 1, IsAggrSet: 0
2018.03.07 20:32:09.494 5: DbRep DBReport - Device specifications use for select: %
2018.03.07 20:32:09.495 5: DbRep DBReport - Reading specification use for select: Temp_Aussen_Tiefpass
2018.03.07 20:32:09.495 4: DbRep DBReport - SQL execute: UPDATE history SET TIMESTAMP=TIMESTAMP,VALUE='{$VALUE = (split(<<,$VALUE))[0]}' WHERE VALUE='%addlog%' AND READING = 'Temp_Aussen_Tiefpass' AND TIMESTAMP >= '2018-02-02 00:00:00' AND TIMESTAMP <= '2018-02-02 23:59:59' ;
2018.03.07 20:32:10.102 4: DbRep DBReport -> BlockingCall change_Push finished
2018.03.07 20:32:10.110 4: DbRep DBReport -> Start BlockingCall change_Done
2018.03.07 20:32:10.161 1: DBReport done
2018.03.07 20:32:10.171 4: DbRep DBReport -> BlockingCall change_Done finished

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 20:59:41
Nimm mal bitte die neuste Version aus dem ersten Beitrag.

Bei mir sieht es nämlich etwas anders aus:


2018.03.07 20:04:54.357 4: DbRep Rep.LogDB1 - -------- New selection ---------
2018.03.07 20:04:54.359 4: DbRep Rep.LogDB1 - Command: changeValue
2018.03.07 20:04:54.364 4: DbRep Rep.LogDB1 - timeDiffToNow - day: 30, hour: , min: , sec: 
2018.03.07 20:04:54.365 4: DbRep Rep.LogDB1 - Time difference to current time for calculating Timestamp begin: 2592001 sec
2018.03.07 20:04:54.366 4: DbRep Rep.LogDB1 - Timestamp begin human readable: 2018-02-05 20:04:53
2018.03.07 20:04:54.367 4: DbRep Rep.LogDB1 - Timestamp end human readable: 2018-03-07 20:04:54
2018.03.07 20:04:54.371 4: DbRep Rep.LogDB1 - Aggregation: day
2018.03.07 20:04:54.386 4: DbRep Rep.LogDB1 - SQL execute: SELECT DEVICE,READING,TIMESTAMP,VALUE,UNIT FROM history where DEVICE = 'USV' AND TIMESTAMP >= '2018-02-05 20:04:53' AND TIMESTAMP < '2018-02-06' AND VALUE LIKE '%addlog%';


Wichtig ist das like in "AND VALUE LIKE '%addlog%';"  Bei dir wird "=" verwendet.

Edit: Ich hatte die Funktion mit Version 7.13.0 abgeändert. Weiß nicht welche V du einsetzt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 März 2018, 21:11:25
Hallo Heiko,

leider ohne Erfolg.

Hier mein Logging
2018.03.07 21:07:29.716 4: DbRep DBReport - -------- New selection ---------
2018.03.07 21:07:29.717 4: DbRep DBReport - Command: changeValue
2018.03.07 21:07:29.719 5: DbRep DBReport - Timestamp begin epocheseconds: 1517526000
2018.03.07 21:07:29.719 4: DbRep DBReport - Timestamp begin human readable: 2018-02-02 00:00:00
2018.03.07 21:07:29.720 5: DbRep DBReport - Timestamp end epocheseconds: 1517612399
2018.03.07 21:07:29.720 4: DbRep DBReport - Timestamp end human readable: 2018-02-02 23:59:59
2018.03.07 21:07:29.721 5: DbRep DBReport - weekday of start for selection: Fr  ->  wdadd: 259200
2018.03.07 21:07:29.721 4: DbRep DBReport - Aggregation: no
2018.03.07 21:07:29.863 4: DbRep DBReport -> Start BlockingCall change_Push
2018.03.07 21:07:29.869 5: DbRep DBReport -> Change old value "%addlog%" to new value "{$VALUE = (split(<<,$VALUE))[0]}" in database DBLogData
2018.03.07 21:07:29.870 5: DbRep DBReport - IsTimeSet: 1, IsAggrSet: 0
2018.03.07 21:07:29.883 5: DbRep DBReport - Device specifications use for select: %
2018.03.07 21:07:29.884 5: DbRep DBReport - Reading specification use for select: Temp_Aussen_Tiefpass
2018.03.07 21:07:29.884 4: DbRep DBReport - SQL execute: UPDATE history SET TIMESTAMP=TIMESTAMP,VALUE='{$VALUE = (split(<<,$VALUE))[0]}' WHERE VALUE='%addlog%' AND READING = 'Temp_Aussen_Tiefpass' AND TIMESTAMP >= '2018-02-02 00:00:00' AND TIMESTAMP <= '2018-02-02 23:59:59' ;
2018.03.07 21:07:30.484 4: DbRep DBReport -> BlockingCall change_Push finished
2018.03.07 21:07:30.492 4: DbRep DBReport -> Start BlockingCall change_Done
2018.03.07 21:07:30.544 1: DBReport done
2018.03.07 21:07:30.555 4: DbRep DBReport -> BlockingCall change_Done finished
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 21:15:14
Irgendwas stimmt noch nicht. In der aktuellsten Version gibt es die Ausgaben:


4: DbRep DBReport -> Start BlockingCall change_Push


nicht mehr.
Hast du das Modul nach dem Download umbenannt nacht 93_DbRep und fhem neu gestartet ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: knxler am 07 März 2018, 21:20:21
Hallo Heiko,

das wars. Ich habe nur ein Reload_CFG gemacht.
Danke!!

Noch einen schönen Abend.

Gruß Martin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2018, 21:21:52
Prima .... wünsche ich dir auch.
Die V aus dem 1. Beitrag checke ich heute auch noch ein. Ist dann morgen im normalen Update.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 09 März 2018, 20:02:48
Zitat von: DS_Starter am 04 März 2018, 20:54:15
Hallo Pyro, @all,

mir ist eine Idee gekommen deinen Vorschlag umzusetzen.

Hallo Heiko,

irgendwie habe ich die Antwort übersehen und habe das Update erst heute gesehen.

Funktioniert wie gewünscht:
MINTS      2017-11-19 22:44:35

Herzlichen Dank!

Wünsche ein schönes Wochenende!
Gruß
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 11 März 2018, 17:25:41
Hallo Heiko,

heute habe ich das Update auf meinem produktiv System eingespielt und erhalte nach einem
get MyDbRep MinTimestamp
folgende Einträge im Log (hab die Abfrage mehrfach ausgeführt)
2018.03.11 17:03:26 1: Timeout for DbRep_getMinTs reached, terminated process 3673
2018.03.11 17:03:26 1: DbRep MyDbRep -> BlockingCall DbRep_getMinTs pid:3675 Timeout: process terminated
2018.03.11 17:03:31 1: Timeout for DbRep_getMinTs reached, terminated process 3675
2018.03.11 17:03:31 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 1370.
2018.03.11 17:03:31 1: DbRep MyDbRep -> BlockingCall  pid: Timeout: process terminated
2018.03.11 17:04:05 1: Timeout for DbRep_getMinTs reached, terminated process 3705
2018.03.11 17:04:05 1: DbRep MyDbRep -> BlockingCall DbRep_getMinTs pid:3705 Timeout: process terminated


Ein List sieht danach wie folgt aus:
Internals:
   DATABASE   fhemdaten
   DEF        myDbLog
   LASTCMD    minTimestamp
   NAME       MyDbRep
   NOTIFYDEV  global,MyDbRep
   NR         9
   NTFY_ORDER 50-MyDbRep
   ROLE       Client
   STATE      disconnected
   TYPE       DbRep
   UTF8       0
   VERSION    7.14.3
   HELPER:
     DBLOGDEVICE myDbLog
   Helper:
     DBLOG:
       errortext:
         myDbLog:
           TIME       1520784245.61213
           VALUE      Timeout
       state:
         myDbLog:
           TIME       1520784245.61213
           VALUE      disconnected
   READINGS:
     2018-03-11 17:04:05   errortext       Timeout: process terminated
     2018-03-11 17:04:05   state           disconnected
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db.conf
     DEF        ./db.conf .*:.*
     MODE       asynchronous
     MODEL      POSTGRESQL
     NAME       myDbLog
     NR         6
     NTFY_ORDER 50-myDbLog
     PID        1488
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     VERSION    3.8.9
     dbconn     Pg:database=fhemdaten;host=localhost
     dbuser     fhem
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     Helper:
       DBLOG:
         state:
           myDbLog:
             TIME       1520784206.43397
             VALUE      connected
     READINGS:
       2018-03-11 17:06:12   CacheUsage      20
       2018-03-11 17:05:56   NextSync        2018-03-11 17:06:26 or if CacheUsage 500 reached
       2018-02-28 23:18:20   countCurrent    967
       2018-03-11 17:01:38   countHistory    27924284
       2018-03-11 17:05:56   state           connected
     cache:
       index      358
Attributes:
   allowDeletion 1
   timestamp_begin 2017-12-31 23:56:46
   verbose    5


Kann es sein dass der Timeout etwas zu kurz gesetzt ist?
Auf der Konsole dauert die Abfrage meines ältesten Datensatzes ca 14 Sekunden.

Grüße
Gerald
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 März 2018, 17:35:13
Hallo Gerald,

Zitat
Kann es sein dass der Timeout etwas zu kurz gesetzt ist?
Auf der Konsole dauert die Abfrage meines ältesten Datensatzes ca 14 Sekunden.

So isses. Ich ändere das und stelle ein update in ein paar Minuten zur Verfügung.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 März 2018, 17:41:09
So, ist im ersten Beitrag. HAbe den Timeout für diese Spezialfunktion auf 90 Sek. erhöht. Sollte jetzt auch bei dir passen und genug Luft sein.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 12 März 2018, 00:03:17
Zitat von: DS_Starter am 11 März 2018, 17:41:09
So, ist im ersten Beitrag. HAbe den Timeout für diese Spezialfunktion auf 90 Sek. erhöht. Sollte jetzt auch bei dir passen und genug Luft sein.

Funktioniert wie vorgesehen. Herzlichen Dank für den schnellen Fix!

Wünsche eine angenehme Nachtruhe
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ToKa am 17 März 2018, 16:08:46
Hallo Heiko,

bin heute endlich dazugekommen meine Batterie-Werte mit changeValue von den %-Zeichen zu befreien. Mit den von Dir gemachten Angaben hat das nicht ganz geklappt. Der Wert war OK, aber die Unit wurde bei allen Einträgen auf 2 gesetzt. Konnte das dann aber wieder reparieren und ein %-Zeichen eintragen. Im Log tauchten außerdem die nachfolgenden Meldungen auf.

2018.03.17 15:58:21 1: PERL WARNING: Use of uninitialized value $dn in substr at ./FHEM/93_DbLog.pm line 3739.
2018.03.17 15:58:21 1: PERL WARNING: Use of uninitialized value $dt in substr at ./FHEM/93_DbLog.pm line 3740.
2018.03.17 15:58:21 1: PERL WARNING: Use of uninitialized value $evt in substr at ./FHEM/93_DbLog.pm line 3741.
2018.03.17 15:58:21 1: PERL WARNING: Use of uninitialized value $rd in substr at ./FHEM/93_DbLog.pm line 3742.


Eingeschränkt hatte ich auf reading="battery" und den Zeitraum auf das aktuelle Jahr.

Beste Grüße
Torsten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2018, 19:30:21
Hallo Torsten,

da fällt es mir gerade wie Schuppen von den Augen:

ZitatMit den von Dir gemachten Angaben hat das nicht ganz geklappt. Der Wert war OK, aber die Unit wurde bei allen Einträgen auf 2 gesetzt

Der Ausdruck "$VALUE,$UNIT" hätte in Klammern gesetzt werden müssen, also -> { ($VALUE,$UNIT) = split(" ",$VALUE) }.
Blöder Fehler ...

Bezüglich der Warnung in DbLog brauchst du dir keine Gedanken machen. Das ist nur eine programmtechnische "Unsauberkeit" die ich fixen werde.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ToKa am 17 März 2018, 20:17:34
Hallo Heiko,

ist ja noch mal gut gegangen ;)

Aber die Commandref solltet Du dann auch noch anpassen, da ist der gleiche Fehler drin.

Auf jeden Fall vielen Dank für das tolle Modul und die Arbeit, die Du da rein steckst.

Beste Grüße
Torsten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2018, 22:15:04
Hi Torsten,

ZitatAber die Commandref solltet Du dann auch noch anpassen, da ist der gleiche Fehler drin.
Hast recht ... habe es geändert und eingecheckt.

Danke für den Hinweis !

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Smarti am 18 März 2018, 17:16:20
Hallo,

ich hätte eine Frage zum DpRep. Auf jeden Fall ein großen Lob da das Modul selbst! Macht vieles einfacher!

Ich würde gerne Daten aus einem bestimmten Zeitraum exportieren z.B. alle Events eine Monats. Bevor ich ein ReduceLog durchführe.

Vergleichbar dem FileLog, dass ich z.B. Monatsweise einen Dump, der Datensätze des entsprechenden Zeitraums in ein eigenes DBfile oder CSV schreiben kann.

Wie müsste ich das anstellen?

Vielen Dank!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Pyromane am 18 März 2018, 17:32:47
Hallo,

sollte sich mit den Attributen:

  • timestamp_begin
  • timestamp_end
  • aggregation
sowie dem Setbefehl bewerkstelligen lassen:

  • exportToFile

Im Commandref zu exportToFile sind ein paar Möglichkeiten aufgezählt.

Grüße
Pyro
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 März 2018, 18:05:27
Hallo Smarti,

Pyro hat dich schon auf den richtigen Weg hingewiesen.

Ergänzend dazu noch der Hinweis, wenn du

  • timestamp_begin = current_month_begin
  • timestamp_end   = current_month_end
setzt, werden immer alle Datensätze des aktuellen Monats exportiert. Dazu darf dann das Attribut device/reading nicht gesetzt sein.
Erstelle dir für die Export-Aufgabe am Besten ein separates DbRep-Device um es entsprechend einzustellen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 März 2018, 22:18:46
Hallo zusammen,

im ersten Beitrag ist die V7.14.6 hinterlegt.
Ich habe die Möglichkeiten des Attributes "expimpfile" erweitert um Wildcards (ähnlich Filelog) verwenden zu können.

Hier die neue Beschreibung:

* expimpfile - Pfad/Dateiname für Export/Import in/aus einem File.

Der Dateiname kann Platzhalter enthalten die gemäß der nachfolgenden Tabelle ersetzt werden. Weiterhin können %-wildcards der POSIX strftime-Funktion des darunterliegenden OS enthalten sein (siehe auch strftime Beschreibung).
Zur POSIX Wildcardverwendung siehe auch die Erläuterungen zu Filelog.
Allgemein gebräuchliche Wildcards sind:

    %d    : Tag des Monats (01..31)
    %m    : Monat (01..12)
    %Y    : Jahr (1970...)
    %w    : Wochentag (0..6); beginnend mit Sonntag (0)
    %j    : Tag des Jahres (001..366)
    %U    : Wochennummer des Jahres, wobei Wochenbeginn = Sonntag (00..53)
    %W    : Wochennummer des Jahres, wobei Wochenbeginn = Montag (00..53)
    %L    : wird ersetzt durch den Wert des global logdir Attributs
    %TSB    : wird ersetzt durch den (berechneten) Wert des timestamp_begin Attributs


    Beispiele:
    attr <name> expimpfile /sds1/backup/exptest_%TSB.csv
    attr <name> expimpfile /sds1/backup/exptest_%Y-%m-%d.csv 

Ich denke damit ist ein weiterer Mehrwert gegeben.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2018, 23:58:38
Hallo zusammen,

nun habe ich auch noch die Funktionen exportToFile, importFromFile etwas erweitert. (V7.14.7 im ersten Beitrag)
Beim Start dieser Funktionen kann nun alternativ direkt ein Filename mit angegeben werden.
Die neuen Beschreibungen:

* exportToFile [<File>] - exportiert DB-Einträge im CSV-Format in den gegebenen Zeitgrenzen.
Einschränkungen durch die Attribute "device" bzw. "reading" gehen in die Selektion mit ein. Der Exportfilename wird durch das Attribut "expimpfile" bestimmt.
Optional kann dem Kommando der Exportfilename (/Pfad/Datei) angegeben werden und übersteuert ein eventuell gesetztes Attribut "expimpfile". Der Filename kann Wildcards enthalten (siehe Attribut "expimpfile").
Durch das Attribut "aggregation" wird der Export der Datensätze in Zeitscheiben der angegebenen Aggregation vorgenommen. Ist z.B. "aggregation = month" gesetzt, werden die Daten in monatlichen Paketen selektiert und in das Exportfile geschrieben. Dadurch wird die Hauptspeicherverwendung optimiert wenn sehr große Datenmengen exportiert werden sollen und vermeidet den "died prematurely" Abbruchfehler.

Die für diese Funktion relevanten Attribute sind:

    aggregation            : Festlegung der Selektionspaketierung
    device                    : Einschränkung des Exports auf ein bestimmtes Device
    reading                    : Einschränkung des Exports auf ein bestimmtes Reading
    executeBeforeProc    : FHEM Kommando (oder perl-Routine) vor dem Export ausführen
    executeAfterProc    : FHEM Kommando (oder perl-Routine) nach dem Export ausführen
    expimpfile            : der Name des Exportfiles
    time.*                    : eine Reihe von Attributen zur Zeitabgrenzung


* importFromFile [<File>] - importiert Datensätze im CSV-Format aus einem File in die Datenbank. Der Filename wird durch das Attribut "expimpfile" bestimmt.
Optional kann dem Kommando der Importfilename (/Pfad/Datei) angegeben werden und übersteuert ein eventuell gesetztes Attribut "expimpfile". Der Filename kann Wildcards enthalten (siehe Attribut "expimpfile").

    Datensatzformat:
    "TIMESTAMP","DEVICE","TYPE","EVENT","READING","VALUE","UNIT"

    # Die Felder "TIMESTAMP","DEVICE","TYPE","EVENT","READING" und "VALUE" müssen gesetzt sein. Das Feld "UNIT" ist optional. Der Fileinhalt wird als Transaktion importiert, d.h. es wird der Inhalt des gesamten Files oder, im Fehlerfall, kein Datensatz des Files importiert. Wird eine umfangreiche Datei mit vielen Datensätzen importiert, sollte KEIN verbose=5 gesetzt werden. Es würden in diesem Fall sehr viele Sätze in das Logfile geschrieben werden was FHEM blockieren oder überlasten könnte.

    Beispiel:
    "2016-09-25 08:53:56","STP_5000","SMAUTILS","etotal: 11859.573","etotal","11859.573",""

    Die für diese Funktion relevanten Attribute sind:

        executeBeforeProc    : FHEM Kommando (oder perl-Routine) vor dem Export ausführen
        executeAfterProc    : FHEM Kommando (oder perl-Routine) nach dem Export ausführen
        expimpfile                    : der Name des Importfiles

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 21 März 2018, 11:01:09
Hallo Zusammen,

vermutlich übersehe ich gerade etwas:
Wenn ich mit DbRep die maxValue in die DB schreibt, schreibt er dort keine "0" Values, sondern nur die von den Tagen mit Values >0. Im Display-Modus zeigt er jedoch 0 Values an.
Gibt es einen Parameter, der mir erlaubt, die 0 Werte zu schreiben?

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 21 März 2018, 11:28:38
Grüß Euch, anbei noch eine Idee:

Ich baue gerade eine neue Installation auf und suche dabei Devices, die noch zu oft loggen.
Mit diesem Select konnte ich solche Devices ausfindig machen und deren Parameter anpassen. Er gibt zB die 50 häufigsten Loggingeinträge der letzten 2 Tage an.

select Device, reading, count(0) AS `countA` from history
where ( TIMESTAMP > (now() - interval 2 day)) group by DEVICE, READING
order by countA desc, DEVICE limit 50;


Dabei stellte ich zB fest, dass gewisse Temperatursensoren über 32000 mal pro Tag einen logeintrag hinterließen...

Vielleicht wäre ein Überblick über die häufigsten Logeinträge ein interessantes Feature für dieses Modul?

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2018, 21:15:56
Hallo Joe,

ZitatWenn ich mit DbRep die maxValue in die DB schreibt, schreibt er dort keine "0" Values, sondern nur die von den Tagen mit Values >0
Hast nichts übersehen ... das war ein Bug den ich mit V7.14.8 (im ersten Beitrag) gefixt habe. Die V checke ich heute noch ein, aber vllt. magst du es schon testen.

ZitatVielleicht wäre ein Überblick über die häufigsten Logeinträge ein interessantes Feature für dieses Modul?
Ja, ich habe die Idee ein set zu definieren, z.B. "sqlSpecial".
Als Option dieser Funktion wären dann per Dropdown-Liste diese Selektion bzw. auch weitere spezielle (aber von allgemeinem Interresse) SQLs ausführbar.
Damit wäre es gut beherrschbar auch wenn noch mehr solcher spezieller Auswertungen vorgeschlagen werden.
Das Statement müssen wir aber noch bezüglich der Lauffähigkeit auf SQLite, Postgre prüfen !

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 22 März 2018, 08:56:25
Hallo Heiko,

Zitat von: DS_Starter am 21 März 2018, 21:15:56
Die V checke ich heute noch ein, aber vllt. magst du es schon testen.
Bitte entschuldige, da ich erst am 19. ein Update über den offiziellen Weg bekommen habe, dachte ich, das sei dort schon enthalten.
Ich hatte die Versionsnummern nicht überprüft. Sorry.

Zitat von: DS_Starter am 21 März 2018, 21:15:56
Ja, ich habe die Idee ein set zu definieren, z.B. "sqlSpecial".
So ähnlich waren meine Gedanken auch... eventuell könnte man dort dann sogar im Ergebnis gewisse Dinge zukünftig "anklickbar" machen, ähnlich wie in DOIF,
um Aktionen wie zB eine Bereinigung starten zu können.

Natürlich könnte so eine Abfrage auch als Art "configCheck", analog zu DbLog, genutzt werden, denn über 30000 Logs pro Tag für ein Reading deuten eigentlich immer auf einen Fehler hin ;-)


sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 März 2018, 18:15:44
Hallo Joe, @all,

in der V 7.15.0 habe ich das neue Kommando "sqlSpecial" umgesetzt. (erster Beitrag)

* sqlSpecial - Die Funktion bietet eine Drop-Downliste mit einer Auswahl vorbereiter Auswertungen an.
Das Ergebnis des Statements wird im Reading "SqlResult" dargestellt. Die Ergebnis-Formatierung kann durch das Attribut "sqlResultFormat" ausgewählt, sowie der verwendete Feldtrenner durch das Attribut "sqlResultFieldSep" festgelegt werden.

Die für diese Funktion relevanten Attribute sind:

    sqlResultFormat    : Auswahl des Trennzeichen zwischen Ergebnisfeldern
    sqlResultFieldSep  : Optionen der Ergebnisformatierung


Es sind die folgenden vordefinierte Auswertungen auswählbar:

    50mostFreqLogsLast2days    : ermittelt die 50 am häufigsten vorkommenden Loggingeinträge der letzten 2 Tage
    allDevReadCount                  : Anzahl aller in der Datenbank vorkommender Device/Reading-Kombinationen


Wenn es noch weitere aus eurer Sicht interressante SQL's geben sollte die hierhin gehören würde ich sie mit aufnehmen bevor ich einchecke.
Schön wäre es wenn es sowohl unter MySQL, SQLite, Postgre schon getestet wurde  ;)
Joe, deine SQL habe ich für SQLite, Postgre entsprechend angepastt.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 April 2018, 08:29:23
Hallo Heiko,

vielen Dank für das erlauben von
textlong für sqlCmd.

Nun, wäre es noch schön, wenn man das sqlCmd als Perlcode angeben könnte, um Stellen wie die datetime-Angaben dynamisch zu generieren.

{ return "select value from ( ( select *, TIMESTAMPDIFF(SECOND, '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."', timestamp) as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."' order by timestamp asc  limit 1 ) union ( select *, TIMESTAMPDIFF(SECOND, timestamp, '2018-04-10 09:45:00') as diff from history where  device='kitchen.hygro' and reading='temperature' and timestamp < '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."' order by timestamp desc limit 1 ) ) x order by diff limit 1"}

Ein EVAL wenn der String mit "{" beginnt müsste dafür eigentlich ausreichend sein?


sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 12 April 2018, 08:45:08
Hallo Heiko,

entschuldige... so kann ich es natürlich jetzt schon lösen, ohne dass etwas geändert werden muss:

{ fhem("set <rep> sqlCmd select value from ( ( select *, TIMESTAMPDIFF(SECOND, '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."', timestamp) as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."' order by timestamp asc  limit 1 ) union ( select *, TIMESTAMPDIFF(SECOND, timestamp, '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."') as diff from history where  device='kitchen.hygro' and reading='temperature' and timestamp < '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."' order by timestamp desc limit 1 ) ) x order by diff limit 1")}


sg
joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 April 2018, 16:10:52
Hallo Joe, @all,

im ersten Beitrag gibt es die V7.16.0.

Enthalten ist eine Funktion "get ... dbValue <SQL-Statement>".
Diese Funktion arbeitet Blocking speziell für die Verwendung in User-eigenen Prozeduren/Prozessen. Die Eingabe akzeptiert Mehrzeiler und gibt ebenso mehrzeilige Ergebisse zurück (sofern vorhanden). Werden mehrere Felder selektiert und zurück gegeben erfolgt die Feldtrennung mit dem Trenner des Attr "sqlResultFieldSep" (default "|"), die Ergebniszeilen mit Newline "\n":

Hier einige Beispiele wie es angewendet werden kann.

In der FHEMWEB Kommandozeile:

{fhem("get Rep.LogDB1 dbValue select device,count(*) from history where timestamp > '2018-04-01' group by device")}

oder

get Rep.LogDB1 dbValue select device,count(*) from history where timestamp > '2018-04-01' group by device"

oder

{CommandGet(undef,"Rep.LogDB1 dbValue select device,count(*) from history where timestamp > '2018-04-01' group by device")}

Erstellt man eine kleine Routine in 99_myUtils, kann es so aussehen:


###########################################
#   dbvalue
###########################################
sub dbval ($$) {
  my ($name,$cmd) = @_;
  my $ret = CommandGet(undef,"$name dbValue $cmd"); 
return $ret;
}


Und dann in der FHEMWEB Kommandozeile:

{dbval("Rep.LogDB1","select count(*) from history")}

bzw. in einem eigenen Programm:

my $ret = dbval("Rep.LogDB1","select count(*) from history")


Vielleicht noch nicht 100%ig rund.
Wie immer freue ich mich über Testergebnisse oder Vorschläge.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 April 2018, 22:45:48
Ich habe noch etwas weiterentwickelt (V7.17.0 im ersten Beitrag)
Zunächst für MYSQL habe ich DbReadingsVal implementiert. Danke an Joe für das Statement !

Aus der Commandref:

Sobald ein DbRep-Device definiert ist, wird die Funktion DbReadingsVal zur Verfügung gestellt. Mit dieser Funktion läßt sich, ähnlich dem allgemeinen ReadingsVal, der Wert eines Readings aus der Datenbank abrufen. Die Funktionsausführung erfolgt blockierend. Die Befehlssyntax ist:

    DbReadingsVal("<name>","<device:reading>","<timestamp>","<default>")

    Beispiele:
    $ret = DbReadingsVal("Rep.LogDB1","MyWetter:temperature","2018-01-13 08:00:00","");
    attr <name> userReadings oldtemp {DbReadingsVal("Rep.LogDB1","MyWetter:temperature","2018-04-13 08:00:00","")}

    <name>               : Name des abzufragenden DbRep-Device
    <device:reading>    : Device:Reading dessen Wert geliefert werden soll
    <timestamp>        : Zeitpunkt des zu liefernden Readingwertes (*) in der Form "YYYY-MM-DD hh:mm:ss"
    <default>             : Defaultwert falls kein Readingwert ermittelt werden konnte


(*) Es wird der zeitlich zu <timestamp> passendste Readingwert zurück geliefert, falls kein Wert exakt zu dem angegebenen Zeitpunkt geloggt wurde.

Für SQLite und PostgreSQL muss das Statement noch angepast werden um es auch für diese DB's zu implementieren.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 15 April 2018, 04:09:54
Hallo Heiko,

Wow, tolle Entwicklung, herzlichen Dank!!
Komme jedoch etwas ab Montag dazu mir das näher anzusehen, bin das WE über unterwegs....

SG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 April 2018, 08:30:34
Hi Joe,

dein Statement arbeitet sehr schnell auf meinen Marias. Da ist die blocking Verarbeitung auch überhaupt kein Problem.
Super !
Nur die Statements für SQLite und Postgre fehlen nun noch. Mal schauen ob ich das alleine hinbekomme.

Bis dann,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 15 April 2018, 08:52:22
Da könnte ich leider nur durch googeln helfen, nutze das selber nirgends.

Die Idee, da es schnell sein muss, ist eben den Union zu nehmen, statt
  order by abs(timestampaSoll-timestamp) , wo das Ergebnis für jeden Datensatz ausgerechnet werden (also mit füll Tablet scan)

Im Prinzip sollte das bei den anderen ganz ähnlich funktionieren....

SG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 April 2018, 10:55:27
Für SQLIte habe ich es nun auch hinbekommen  ;)  und die Version neu hochgeladen.
Nun fehlt noch Postgre  ... aber jetzt ist erstmal WE ..

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 16 April 2018, 11:39:08
Hallo Heiko,

funktioniert toll!

Beispiel:
Über
attr VorlaufGesamt stateFormat {\
sprintf "%4.1f° ".\
             "(%4.1f°) ", \
  ReadingsNum($name,"temperature",undef),\
  DbReadingsVal("dbRep","$name:temperature",strftime("%Y-%m-%d %H:%M:%S", localtime(time-60*10)),"-100");;\
}

kann ich mir nun immer den Temperaturwert von vor 10 Minuten im Status mit anzeigen lassen. Somit lässt sich ein Trend leicht erkennen :D

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 April 2018, 18:45:02
Hi Joe,

na das ist doch prima.  :D

Da ich es auch noch für Postgre hinbekommen hatte, kann ich den neuen Stand auch einchecken.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 20 April 2018, 10:42:35
Hallo Heiko,
ich schließe mich der Lobgemeinde zu Deinem dbrep-Modul (V7.17.0) an.

Allerdings habe ich ein Problem mit einem sqlCmd, mit dem ich ein maxValue-Wert in der DB umbenennen möchte.
define Rep.HT_Tagesenergieaufnahme DbRep DBLogging
attr Rep.HT_Tagesenergieaufnahme aggregation day
attr Rep.HT_Tagesenergieaufnahme device HT_Tagesenergieaufnahme
attr Rep.HT_Tagesenergieaufnahme reading state
attr Rep.HT_Tagesenergieaufnahme showproctime 1
attr Rep.HT_Tagesenergieaufnahme timestamp_begin previous_day_begin
attr Rep.HT_Tagesenergieaufnahme timestamp_end previous_day_end

define Vortag.Rep.HT_Tagesenergieaufnahme_max at *00:02:40 set Rep.HT_Tagesenergieaufnahme maxValue writeToDB

define N.Vortag.Rep.HT_Tagesenergieaufnahme_max notify Rep.HT_Tagesenergieaufnahme:(\d).*HT_Tagesenergieaufnahme__state__MAX.* {fhem("set Tagesgesamtenergieaufnahme_HT $EVTPART1 ;; set Rep.HT_Tagesenergieaufnahme sqlCmd UPDATE history SET timestamp = timestamp, device = 'Tagesgesamtenergieaufnahme_HT', reading = 'state' where TIMESTAMP >= §timestamp_begin§ and TIMESTAMP <= §timestamp_end§ and device = 'HT_Tagesenergieaufnahme' and reading = 'max_day_state'")}


Das führt zu folgendem Fehler:
DbRep Rep.HT_Tagesenergieaufnahme - ERROR - DBD::mysql::st execute failed: Unknown column 'timestamp_begin' in 'where clause' at ./FHEM/93_DbRep.pm line 5267

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 April 2018, 12:19:49
Hallo Thowe,

Zitat
Das führt zu folgendem Fehler:
DbRep Rep.HT_Tagesenergieaufnahme - ERROR - DBD::mysql::st execute failed: Unknown column 'timestamp_begin' in 'where clause' at ./FHEM/93_DbRep.pm line 5267

Ja,der Programmierer hat einen Fehler gemacht  :o
Habs mit der V7.17.1 im ersten Beitrag korrigiert, probiers mal bei dir.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 20 April 2018, 13:01:16
Hallo Heiko,
Respekt, Deine Response-Zeiten und das Ergebnis: Funktioniert!

Vielen Dank,
Thowe

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 April 2018, 13:11:13
 :D... ich checke die Version ein. Ist dann morgen früh im Regelupdate.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 22 April 2018, 17:10:47
Hallo Heiko,

ich erhalte mit
define Rep.Monatskosten.HNT_Energie DbRep DBLogging
attr Rep.Monatskosten.HNT_Energie aggregation no
attr Rep.Monatskosten.HNT_Energie device Tageskosten.HNT_Energie
attr Rep.Monatskosten.HNT_Energie reading state
attr Rep.Monatskosten.HNT_Energie showproctime 1
attr Rep.Monatskosten.HNT_Energie timestamp_begin current_month_begin

define Calc.Rep.Monatskosten.HNT_Energie at *00:03:00 set Rep.Monatskosten.HNT_Energie sumValue writeToDB

und DB-Inhalt:

mysql> select * from history where device like '%HNT%';
+---------------------+-------------------------+-------+--------------------------+---------+-------------------+------+
| TIMESTAMP           | DEVICE                  | TYPE  | EVENT                    | READING | VALUE             | UNIT |
+---------------------+-------------------------+-------+--------------------------+---------+-------------------+------+
| 2018-04-21 23:59:59 | Tageskosten.HNT_Energie | DUMMY | state: 0.322139537113933 | state   | 0.322139537113933 |      |
+---------------------+-------------------------+-------+--------------------------+---------+-------------------+------+

keinen Eintrag in die DB und folgende Warning:
If you want write results back to database, attributes "device" and "reading" must be set.
In that case "device" mustn't be a devspec and mustn't contain SQL-Wildcard (%).
The "reading" to evaluate has to be a single reading and no list.

Diese Meldung macht m.M.n. in dieser Situation keinen Sinn.

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 April 2018, 17:42:05
Hallo Thowe,

ZitatDiese Meldung macht m.M.n. in dieser Situation keinen Sinn.
Da hast du Recht.
Ich schaue mir das an und melde mich ....

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 April 2018, 18:44:43
Hallo Thowe,

habe es mit V7.17.2 abgeändert. (erster Beitrag)

Checke es mal bitte bei dir ob das Ergebnis den Erwartungen entspricht.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 22 April 2018, 20:03:13
Hallo Heiko,

sogar sonntags Support 8)
Und mit Erfolg, vielen Dank
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 April 2018, 20:05:56
Prima... dann wie gehabt morgen früh im Update.

Schönen Wochenstart !
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 23 April 2018, 21:17:07
Guten Abend, ich nutze das tolle Modul, habe es aber heute nicht geschafft, alte Einträge zu löschen. Da ich DbLog erst seit vier Monaten verwende, sollte doch folgendes leicht gehen:

Internals:
   DATABASE   fhem
   DEF        DbLog
   LASTCMD    delEntries
   MODEL      Client
   NAME       DbLogRep
   NOTIFYDEV  global,DbLogRep
   NR         108
   NTFY_ORDER 50-DbLogRep
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       0
   VERSION    7.15.2
   HELPER:
     DBLOGDEVICE DbLog
     CV:
       aggregation no
       aggsec     1
       destr      2018-01-13
       dsstr      1970-01-01
       epoch_seconds_end 1515870764
       mestr      01
       msstr      01
       testr      20:12:44
       tsstr      01:00:00
       wdadd      345600
       yestr      2018
       ysstr      1970
   READINGS:
     2018-04-23 21:13:37   errortext       DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 3669.

     2018-04-23 21:13:37   state           error
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db.conf
     DEF        ./db.conf (sysmon:.*|Stromzaehler:.*|Viessmann:.*NurGestern.*|Viessmann:.*temperatur.*|Garagensensor:Temperatur:.*|Heizungskeller:Gasverbrauch:.*|Heizungskeller:Wasser:.*|DECT1:temperature.*|Sonoff_pow1:.*|Sonoff_TH10a:myTemperature.*|Sonoff_TH10a:mypower.*|BresserTemeo_1:temperature.*|SensorHydrAbgleich.*:.*Temperatur.*|DECT1:power.*)
     MODE       synchronous
     MODEL      MYSQL
     NAME       DbLog
     NR         20
     NTFY_ORDER 50-DbLog
     PID        32119
     REGEXP     (sysmon:.*|Stromzaehler:.*|Viessmann:.*NurGestern.*|Viessmann:.*temperatur.*|Garagensensor:Temperatur:.*|Heizungskeller:Gasverbrauch:.*|Heizungskeller:Wasser:.*|DECT1:temperature.*|Sonoff_pow1:.*|Sonoff_TH10a:myTemperature.*|Sonoff_TH10a:mypower.*|BresserTemeo_1:temperature.*|SensorHydrAbgleich.*:.*Temperatur.*|DECT1:power.*)
     STATE      connected
     TYPE       DbLog
     UTF8       0
     VERSION    3.10.6
     dbconn     mysql:database=fhem;host=127.0.0.1;port=3306
     dbuser     root
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2018-04-15 13:59:53   lastRowsDeleted 800717
       2018-04-23 21:16:15   state           connected
     cache:
       index      0
Attributes:
   allowDeletion 1
   timeOlderThan 8640000


Statt dessen kommt (auch mit größeren Zahlenwerten bei OlderThan)
2018.04.23 21:13:37 2: DbRep DbLogRep - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 3669.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 April 2018, 21:27:16
Hallo andies,

ZitatDBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction

Das ist kein Problem des Moduls, sondern eine Reaktion darauf dass die Tabelle für die anstehende Aktion nicht gesperrt werden konnte
(Lock wait timeout ) = Datenbankproblematik

Was bringt denn  "get ... procinfo" ?

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 23 April 2018, 21:50:08
danke - das hier:
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 April 2018, 21:56:09
Sieht jetzt aber sauber aus, es gibt nur den query prozess den du gerade abgesetzt hast.

Du kannst jetzt folgendes tun:

1. die Aktion einfach wiederholen
2. DbLog in des asynchronen Mode setzen und die Aktion wiederholen
3. in der my.cnf von mysql den Wert für innodb_lock_wait_timeout hochsetzen und die DB restarten (würde ich aber erstmal nicht machen)

Probiere erstmal 1 und 2 ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 23 April 2018, 22:02:25
danke, sieht gut aus. Scheint zu laufen (Nr. 2).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 April 2018, 22:05:36
Hatte ich vermutet. Ein Prozess von dblog (Nr. 49) in deinem Screenshot hatte die history wahrscheinlich noch gelockt obwohl im sleep.
Bei grafana bin ich mir nicht sicher wie sich das verhält. Musst du mal darauf achten falls dir das nochmal auffällt.

Edit: vergiß grafana, ist eine ganz andere Tabelle  ???
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 24 April 2018, 10:40:21
Hallo Heiko,

ich hänge wieder an einem systematischen Problem fest.
Mit:
define Rep.NT_365d_Energieaufnahme DbRep DBLogging
attr Rep.NT_365d_Energieaufnahme aggregation no
attr Rep.NT_365d_Energieaufnahme device Tagesgesamtenergieaufnahme_NT
attr Rep.NT_365d_Energieaufnahme reading state
attr Rep.NT_365d_Energieaufnahme showproctime 1
attr Rep.NT_365d_Energieaufnahme timeDiffToNow d:365
attr Rep.NT_365d_Energieaufnahme verbose 5

define Calc.Rep.NT_365d_Energieaufnahme at *00:02:56 set Rep.NT_365d_Energieaufnahme sumValue writeToDB


... erhalte ich folgenden Log:
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - -------- New selection ---------
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Command: sumValue writeToDB
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - timeDiffToNow - day: 365, hour: , min: , sec: 
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Time difference to current time for calculating Timestamp begin: 31536001 sec
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Timestamp begin epocheseconds: 1493021749
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Timestamp begin human readable: 2017-04-24 10:15:49
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Timestamp end epocheseconds: 1524557750
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Timestamp end human readable: 2018-04-24 10:15:50
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - weekday of start for selection: Mo  ->  wdadd: 604800
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - Aggregation: no
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - IsTimeSet: 1, IsAggrSet: 0
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Timestamp-Array:
no_aggregation#2017-04-24 10:15:49#2018-04-24 10:15:50
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Device specifications use for select: Tagesgesamtenergieaufnahme_NT
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - Reading specification use for select: state
2018.04.24 10:15:50 4: DbRep Rep.NT_365d_Energieaufnahme - SQL execute: SELECT SUM(VALUE) FROM history where DEVICE = 'Tagesgesamtenergieaufnahme_NT' AND READING = 'state' AND TIMESTAMP >= '2017-04-24 10:15:49' AND TIMESTAMP <= '2018-04-24 10:15:50' ;
2018.04.24 10:15:50 5: DbRep Rep.NT_365d_Energieaufnahme - SQL result: 0.2
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme -> Primary Key used in fhem.history: none
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme -> Primary Key used in fhem.current: DEVICE,READING
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme - data prepared to db write:
2018.04.24 10:15:51 5: DbRep Rep.NT_365d_Energieaufnahme - 2017-04-24 23:59:58|Tagesgesamtenergieaufnahme_NT|dummy|calculated|sum_no_state|0.2000|
2018.04.24 10:15:51 3: DbRep Rep.NT_365d_Energieaufnahme - number of lines updated in "DBLogging": 1
2018.04.24 10:15:51 3: DbRep Rep.NT_365d_Energieaufnahme - number of lines inserted into "DBLogging": 0


In die DB wird jedoch nichts eingetragen und das Notify wird nicht ausgelöst:
define N.Rep.NT_365d_Energieaufnahme_sum notify Rep.NT_365d_Energieaufnahme:(\d).*Tagesgesamtenergieaufnahme_NT__state__SUM__no_aggregation {fhem("set NT_365d_Energieaufnahme $EVTPART1")}

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 April 2018, 11:45:05
Hallo Thowe,

habe gerade bei mir nachgestellt. Der Event erscheint im Eventmonitor. Sieh mal bei dir dort rein in einem zweiten browserfenster wenn du die Aktion durchführst.
Ich denke das ist ein Problem der notify definition. Möglicherweise hilft es so:

... Rep.NT_365d_Energieaufnahme:.*(\d).*Tagesgesamt....

Allerdings habe ich den Sinn des notify nicht verstanden. was willst damit tun ?

Der Wert wird bestimmt in die db geschrieben. Schau mal nach diesem timestamp in der db "2017-04-24 23:59:58".
Bin da schon selber darüber gestolpert weil ich dachte es kommt nichts an.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 24 April 2018, 12:55:33
Hallo Heiko,
wieder ein Danke für die schnelle Antwort. Sorry, meine Fehler.
Mit
select * from history where device = 'Tagesgesamtenergieaufnahme_NT';
wird der in der Zukunft liegende Eintrag nicht angezeigt - zumindest mit mysql. Alles OK, der DB-Eintrag wurde geschrieben.

Mit dem Notify übertrage ich den Summenwert in einen Dummy, weil ich mehrere DB-Summationen mit Tagesgesamtenergieaufnahme_NT ausführe. Ich ging davon aus, dass das Event erst gesetzt wird, wenn auch der DB-Eintrag abgesetzt wurde. Ich hätte auch readingRename benutzen können, aber das ändert die gesamte DB. Deshalb benenne ich den von dbrep in die DB eingetragenen Wert mit sqlCmd update ... um (hatte ich im Post weggelassen).
Das Notify funktioniert jetzt. Ich hatte im Suchmuster das abschließende .* unterlassen, da kommt ja noch der Readingvalue...

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 April 2018, 13:24:56
sehr schön  :)

Aber geht die Übertragung zum dummy nicht einfacher ?

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Reading_von_DbRep_nach_Dummy_.C3.BCbertragen

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 24 April 2018, 13:50:30
Hallo Heiko,

danke für den Tipp. Abgesehen von den längeren Device-/Reading-Bezeichnern entsprechen sich die Dummy-Übertragungen?
Eine Alternative wäre, den Dummy mit DbReadingsVal zu befüllen. Aber da kann wegen asynchronem Schreibzugriff der aktuelle Wert noch fehlen, d.h. ich müsste erst ein commit erzwingen. Da erscheint mir Deine Methode aus dem Wiki besser.
Und um den Wert in der DB nicht doppelt zu haben, entweder Dummy loggen und Timestamp anpassen oder vom dbrep-Eintrag Device und Reading umbenennen.

Viele Grüße,
Thowe

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 April 2018, 14:00:09
DercWiki Beitrag ist schon etwas älter. Inzwischen gibt es das Attr userExitFn mit dem man ein paar feine Sachen machen kann, etwas perl Kenntnisse vorausgesetzt. Wenn das etwas für dich wäre können wir heute Abend nochmal schreiben.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 26 April 2018, 12:49:17
Hallo Heiko,

das Bessere ist der Feind des Guten...
Perl beherrsche ich nicht, aber das ist kein Hinderungsgrund. Die userExitFn habe ich in Anwendungsbeispielen gesehen. D.h. als dritte Alternative führe ich die DB-Aktion (z.B. Monatssumme) ohne writeToDB aus und schreibe in der Exitfunktion den Wert in den Dummy und unter dessen Device-Bezeichner mit INSERT in die DB? Generiert der Dummy ein Event während der Abarbeitung der Exitfunktion oder erst nach deren Abschluss?

Das Problem ist letztendlich hausgemacht: Ich muss über ein identisches Device/reading mit gleicher Aggregation aber unterschiedlichen Zeitbereichen in der DB unterscheidbare Einträge erzeugen, Beispiel: Monatsertrag und Vergleichsmonatsertrag.

Noch eine Frage: Ist die writeToDB-Opperation bei Eintritt in die Exitfunktion abgeschlossen, bzw. würde in der Exitfunktion eine Operation auf einer asynchronen DB-Instanz erst nach dem writeToDB-Zugriff ausgeführt werden?

Und wo ich gerade am Fragen bin: Ich bekomme im Ablauf von mehreren aufeinander abfolgenden DB-Operation mit dbrep mitunter:
WARNING - old process nnnn will be killed now to start a new BlockingCall
Kann das zu Datenverlust führen?

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 April 2018, 13:40:30
Hallo Thowe,

bin zur Zeit unterwegs und kann nur kurz antworten. Deswegen vllt. erstmal auf diese Fragen ..

ZitatNoch eine Frage: Ist die writeToDB-Opperation bei Eintritt in die Exitfunktion abgeschlossen, bzw. würde in der Exitfunktion eine Operation auf einer asynchronen DB-Instanz erst nach dem writeToDB-Zugriff ausgeführt werden?

Die writeToDB-Opperation wird _immer_ sofort ausgeführt, unabhängig davon wie das DbLog-Device eingestellt ist. D.H. wenn Exitfunktion ausgeführt wird (bei der Generierung eines jeden Readings), ist die writeToDB-Opperation abgeschlossen.

Zitat
Ich bekomme im Ablauf von mehreren aufeinander abfolgenden DB-Operation mit dbrep mitunter:
Code: [Auswählen]

WARNING - old process nnnn will be killed now to start a new BlockingCall

Kann das zu Datenverlust führen?

Jein.  Wenn es sich um lesende Operationen handelt passiert nichts. Sollte es sich dabei um Schreiboperationen handeln wäre es nicht so gut. Allerdings gibt es dafür prinzipiell eine einfache Lösung.
Grundsätzlich sind das Zeitprobleme, d.h. die eine Operation ist noch nicht abgeschlossen, aber eine weitere sol beginnen ... und zwar mit dem gleichen DbRep-Device ! (Eine Folge der Forderung dass nur ein BlockingCall für ein Device laufen soll)
In solchen Fällen lege dir mehrere DbReps an (copy und dann einstellen) und führe die jeweiligen Operationen auf getrennten Reps aus. Dann hast du das Problem nicht.

Zitat
Das Problem ist letztendlich hausgemacht: Ich muss über ein identisches Device/reading mit gleicher Aggregation aber unterschiedlichen Zeitbereichen in der DB unterscheidbare Einträge erzeugen, Beispiel: Monatsertrag und Vergleichsmonatsertrag.

Hmm.... auf den ersten Blick nicht ganz so simpel. Das bringt mich auf die Idee noch eine Abhängigkeit des resultierenden Readingnamens in der writeToDB-Opperation vom Attribut ReadingNameMap zu berücksichtigen. Dann wäre die Unterscheidung in Fällen die du gerade beschrieben hast recht einfach umzusetzen.
Das kann ich mir aber erst genauer anschauen wenn mein Kurzurlaub vorbei ist  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: stera am 27 April 2018, 18:42:00
Hallo,

gibt es irgendwo die Möglichkeit eine "0" zu setzen anstatt "-", wenn kein Werte vorliegen? Das bereitete mir gerade Probleme bei den Differenz-Berechnungen vom Gaszähler.

Ansonsten muss ich das nochmal umprogrammieren im Notify oder Userreadings.

Gruß,
SteRa




Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 April 2018, 18:47:37
Hallo Stera,

nein, wenn keine Werte vorliegen wird absichtlich nicht 0 ausgegeben weil es sonst vorgaukelt es wären Werte vorhanden, die aber eben 0 sind.
Um das konsequent abzugrenzen wird in dem Fall - statt 0 ausgegeben.

Edit: wäre aber über ein Attr machbar wenn es sinnvoll wäre diese Änderung einzubauen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 28 April 2018, 14:48:47
Hallo Heiko,
die Lösung mit der Übernahme des ReadingNameMap für writeToDB wäre super. Halte ich im Übrigen für konsequent, weil im Event das Mapping übernommen wird.

BTW: Ich könnte bei attr <name> timeDiffToNow auch noch gut ein "Y:1" benötigen. Vorteil ggü. "d:365" wäre, dass unabhängig vom Schaltjahr immer mit dem selben Datum im Monat gerechnet wird. Das könnte für den Monat Februar auch bei "M:1" einsetzbar sein. 

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 April 2018, 15:26:18
Hallo Thowe,

Ok, ReadingNameMap baue ich dort noch mit rein.
Die Zeitenrechnug mit Year hatte ich noch auf der Agenda. Es fehlt ja auch noch die Jahresaggregation.
Ich hatte das wegen der Schaltjahrproblematik vor mir hergeschoben.  ;)

Melde mich wieder ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 29 April 2018, 02:06:24
Hallo Heiko,

Danke für die Antworten. Konzentriere Dich erst einmal auf Deinen Urlaub, die Ideen werden bestimmt nicht weniger...
Z.B. Jahresaggregation: Ich erzeuge mir täglich mit timeDiffToNow einen Jahreswert für Summe von Kosten, Energieaufnahme, etc. beginnend 365 Tage vor bis zum laufenden Tag. Lässt sich dieser Wert für alle Tage in einem vorgebbaren Bereich "out-of-theBox" berechnen? Bislang habe ich jedes mal solche Daten extern berechnet und anschließend importiert.
Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 April 2018, 15:29:35
Hallo Thowe,

mit der V7.17.3 im ersten Beitrag kann man nun bei "writeToDB" den Readingnamen mit dem Attribut "readingNameMap" übersteuern.
Die andere Sache mit der Zeitenrechnung braucht etwas mehr Arbeit, Zeit und Test.
Da der Urlaub bald richtig losgeht  :D ... nehme ich mir das für die Zeit danach vor.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2018, 18:46:29
Hallo zuammen,

im ersten Beitrag ist die 7.18.0 hinterlegt.
Neben kleineren Bugfixes kann man mit dieser Version in den Attributen timeDiffToNow, timeOlderThan auch dynamisch Jahre angeben in der Form y:<Zahl>.

Beispiel:

attr name timeDiffToNow y:1 h:2.5
# die Startzeit wird auf "aktuelle Zeit - 1 Jahr und 2,5 Stunden" gesetzt
                        
attr name timeDiffToNow y:1.5
# die Startzeit wird auf "aktuelle Zeit - 1,5 Jahre gesetzt

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 04 Juni 2018, 08:47:37
Hallo Heiko, @All.

Wie im Thread DbLog besprochen, anbei ein Vorschlag, wie die Partitionierung der MySQL-Tabelle zur verbesserung der Lösch-Performance führen kann.

Anbei ein Tabellenlayout, das die Daten nach Wochentage und anschließend noch nach der neuen Spalte "Longterm" partitioniert. (Als Diskussionsgrundlage).
CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(64) NOT NULL DEFAULT '',
`TYPE` VARCHAR(32) NULL DEFAULT NULL,
`EVENT` VARCHAR(512) NULL DEFAULT NULL,
`READING` VARCHAR(64) 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 = Aria,
  SUBPARTITION monLong ENGINE = Aria),
PARTITION tue VALUES LESS THAN (2)
(SUBPARTITION tueNolong ENGINE = Aria,
  SUBPARTITION tueLong ENGINE = Aria),
PARTITION wed VALUES LESS THAN (3)
(SUBPARTITION wedNolong ENGINE = Aria,
  SUBPARTITION wedLong ENGINE = Aria),
PARTITION thu VALUES LESS THAN (4)
(SUBPARTITION thuNolong ENGINE = Aria,
  SUBPARTITION thuLong ENGINE = Aria),
PARTITION fri VALUES LESS THAN (5)
(SUBPARTITION friNolong ENGINE = Aria,
  SUBPARTITION friLong ENGINE = Aria),
PARTITION sat VALUES LESS THAN (6)
(SUBPARTITION satNolong ENGINE = Aria,
  SUBPARTITION satLong ENGINE = Aria),
PARTITION sun VALUES LESS THAN (7)
(SUBPARTITION sunNolong ENGINE = Aria,
  SUBPARTITION sunLong ENGINE = Aria)) ;


Diese Tabelle kann so jetzt schon in FHEM verwendet werden, ohne Codeänderung.
(Jedoch können die möglichen Vorteile noch nicht direkt genutzt werden.)
Somit könnte die Codeunterstützung jedoch schritt für schritt einfach ergänzt werden!

Eventuell sollte der default bei Longterm statt 0 auf 1 gesetzt werden.
(Man kann Longterm natürlich auch um die Werte 2,3,4,5, etc. ergänzen, wenn es sinn macht. Zb. analog zum Verbose level.

Beispielszenario:
Ein Insert eines Datenwertes HEUTE würde mit dieser Tabelle in der Partitionstabelle "monNoLong" landen.
Wenn ich Longterm auf 1 setzem landet er in der Partitionstabelle "monLong".

Ich packe also alle Werte, die ich nicht dauerhaft speichern möchte, in die Tabelle "*NoLong" und die anderen in "*Long".
Am Ende des Tages nehme ich die Werte aus der NoLong-Tabelle und berechne daraus meine Stundenmittel, etc.
Anschließend lösche ich sämtliche Daten (fast) verzögerungsfrei über

ALTER TABLE history TRUNCATE PARTITION monNoLong;


Hilfreiche Codeunterstützung wäre dafür meines Erachtens nach (durchaus in dieser Reihenfolge als einzelne Punkte realisierbar):
1# Erlauben des direkten Setzens von Longterm auf definierte Werte über ein DbLogexclude/Include Attribut. 
      ((im Moment mache ich das in MySQL direkt über einen inserttrigger)))
2# Unterstützung der Tabellenkonfiguration (zB über set DbRep updateHistoryTable [no]partition)
3# Unterstutzung der neuen Löschmöglichkeiten in DbRep
4# Erlauben der Umkategorisierung von Daten von NoLong auf Long über das Modul nach gewissen Parametern.


Edit: Fragen, die wir noch festlegen sopllten:
#1 Werden mehr als 2 Aufbewahrungszeiten (Longterm NoLongterm) benötigt? Ich bin mir hier nicht so sicher, denn die Komplexität steigt dadurch enorm.


sG
Joe


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Juni 2018, 21:49:48
Hi Joe,

danke für den umfangreichen Beitrag.
Ich werde das Thema nicht vergessen, bin nur momentan mit einer größeren Weiterentwicklungen vom SSCam-Modul beschäftigt.
Stelle das Thema erstmal etwas zurück und komme später wieder dazu.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 Juni 2018, 07:54:07
Hallo Heiko,

danke. Ich nutze es ja schon so und habs deswegen nicht übertrieben eilig ;-)
Du könntest abe rmal, falls es dich interessiert, einfach deine Datenbank umstellen.
Sollte danach noch alles so funktionieren wie zuvor und ich denke so wird die Idee dahinter gleich mal klarer.


sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 13 Juni 2018, 20:41:09
Hallo zusammen,

ich hänge meine Frage mal in diesen Thread. Hat aber mit der vorhergehenden Frage nichts zu tun aber es geht um das Modul DbRep.

Ich habe folgendes Problem:
- ich habe eine korrupte SQLite Datenbank mit ca. 600MB
- habe dann mit DbRep ein repairSQLite gemacht. Danach war die DB nur noch ca. 250MB groß und es haben viele Jahresmesswerte gefehlt.
- ich mache jede Nacht mir DbRep ein DB-Backup und bewahre immer 10 Backupdateien auf
- da ich zu spät gemerkt habe, dass an der Datenbank etwas korrupt war, da lief dann auch kein Backup mehr, habe ich auf der reparierten DB weiter geloggt.
- meine Idee war jetzt aus einem noch 'guten' Backup die Readings der Jahresmesswerte zu exportieren und danach wieder in die aktuelle DB einzulesen. Mir ist schon klar, dass mir dann ein paar Tage fehlen, aber eben hoffentlich nicht Monate.
- das Ganze wollte ich auf einem Testsystem erledigen, scheitere jetzt aber daran, ein restore des DB-Backups durchzuführen. Ich habe auf dem Testsystem eine dort vorhandene Db so umbenannt, dass Sie zu dem Db-Backup passt. Entsprechende Einträge in db.conf usw. entsprechend abgeändert. Die Db geht auch in den Zustand 'connected'. Nun wollte ich mit DbRep ein restoreSQLite durchführen, kann den entsprechenden File auch auswählen, aber das restore wird sofort mit der Fehlermeldung:

DBD::SQLite::db sqlite_backup_from_file failed: sqlite_backup_from_file failed with error attempt to write a readonly database at ./FHEM/93_DbRep.pm line 6902

abgebrochen. In raspbian die Dateirechte kontrolliert und die sind richtig. Ich habe auch schon das Attribute allowDeletion 1 gesetzt, was aber nichts geändert hat.
Vielleicht kann man ja tatsächlich nur ein restore auf die DB machen, von der auch das Backup erfolgt ist, wie kann ich dann aber meinen Fall lösen, aus einem Db Backup nur bestimmte readings zu exportieren?

Vielen Dank für einen Tipp
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juni 2018, 21:13:44
Hallo Wolfgang,

deine Vorgehensweise ist erstmal richtig.

ZitatVielleicht kann man ja tatsächlich nur ein restore auf die DB machen, von der auch das Backup erfolgt ist
Nein, diese Beschränkung gibt es nicht. Aber nimm doch nicht schon eine bestehende DB auf deinem Testsystem, sondern lege dir dort eine neue Datenbank ganz nach Vorschrift mit dem Namen der alten DB (sicherheitshalber) an als wolltest du anfangen mit loggen und setzte dir dann im DbLog DEF den Regex so dass nichts reinläuft und connecte dir dann das DbRep-Device. Dann sollte es kein Problem mit dem Restore geben. Achte darauf das user/group fhem/dialout Schreibrechte besitzen.

Zitatwie kann ich dann aber meinen Fall lösen, aus einem Db Backup nur bestimmte readings zu exportieren?
Wenn die DB läuft beschränkste du mit dem Attribut "reading" auf das was du willst und machst dann einen set ... exportToFile.
Danach dann ein importFromFile auf der Zieldatenbank.

Grüße
Heiko


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 13 Juni 2018, 21:47:17
Hallo Heiko,

herzlichen Dank für die schnelle Antwort. Bin schon mal froh, dass mein Ansatz richtig war. Werde Deinen Vorschlag mal so nachvollziehen. Vielleicht hat sich ja durch Verwendung einer schon vorhandenen DB irgend etwas 'verhakt'.

VG Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 23 Juni 2018, 13:40:49
Hallo Heiko,
ich muss diesen Thread leider nochmals 'aufwärmen'. DbRep Version 7.18.1
Ich habe jetzt, wie von Dir beschrieben, eine neue Datenbank mit gleichem Namen angelegt. In das gleiche Verzeichnis das Backup kopiert und dann mit DbRep mit folgender Konfiguration ein restoreSQLite versucht:


defmod RestoreDbWhng3 DbRep dblog_test_whng3
attr RestoreDbWhng3 dumpDirLocal /opt/fhem/db_recover_whng3/
attr RestoreDbWhng3 dumpFilesKeep 6
attr RestoreDbWhng3 executeAfterProc { fhem("set dblog_test_whng3 reopen");;;;my $duration = ReadingsVal("RestoreDbWhng3","background_processing_time"," ");;;; exmail('test1@xxxxx.de','Restore DB Ende','Restore DB wurde nach ' .$duration. ' sec. beendet') }
attr RestoreDbWhng3 executeBeforeProc { fhem("set dblog_test_whng3 reopen 7200");;;;exmail('test1@xxxxx.de','Restore DB Start','Restore DB wurde gestartet') }
attr RestoreDbWhng3 room DB,Server
attr RestoreDbWhng3 showproctime 1
attr RestoreDbWhng3 verbose 5

setstate RestoreDbWhng3 error
setstate RestoreDbWhng3 2018-06-23 12:00:09 errortext DBD::SQLite::db sqlite_backup_from_file failed: sqlite_backup_from_file failed with error attempt to write a readonly database at ./FHEM/93_DbRep.pm line 6902.\

setstate RestoreDbWhng3 2018-06-23 12:00:09 state error



Die Dateirechte in raspbian sehen folgendermaßen für das Verzeichnis so aus:


drwxr-xr-x  2 fhem dialout    4096 Jun 23 12:00 db_recover_whng3


und für die Dateien so:

-rwxrwxrwx 1 fhem dialout 632127488 Jun 22 18:40 fhem_2018_06_07_00_39.sqlitebkp
-rw-rw-rw- 1 fhem dialout      4096 Jun 23 11:58 fhem.db
-rwxrwxrwx 1 fhem dialout 168099840 Jun 22 20:28 fhem.db.saved


Aus meiner Sicht sind die so 'ausreichend'. Leider wird das restore nicht ausgeführt und mit der Fehlermeldung, siehe oben abgebrochen. Im Log steht auch mit Verbose 5 nicht mehr drin.

Wie könnte ich mich dem Problem noch nähern?

Danke für Deine Unterstützung

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Juni 2018, 15:41:38
Hallo Wolfgang,

ich habe das mal bei mir nachvollzogen.
Ich habe eine SQLite-DB in /opt. Sie heißt fhem.db. Von dieser ziehe ich täglich Backups.
Das letzte Backupfile heißt: fhem_2018_06_22_17_25.sqlitebkp.gzip (Ordner /sds1/backup/dumps_FHEM)

Das dazugehörige DbRep-Device ist so definiert:

defmod Rep.SQLite.Backup DbRep LogSQLITE
attr Rep.SQLite.Backup allowDeletion 1
attr Rep.SQLite.Backup devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.SQLite.Backup disable 0
attr Rep.SQLite.Backup dumpCompress 1
attr Rep.SQLite.Backup dumpDirLocal /sds1/backup/dumps_FHEM
attr Rep.SQLite.Backup dumpFilesKeep 1
attr Rep.SQLite.Backup event-on-update-reading state
attr Rep.SQLite.Backup ftpDir /ftp
attr Rep.SQLite.Backup ftpDumpFilesKeep 1
attr Rep.SQLite.Backup ftpPwd ftpftp1
attr Rep.SQLite.Backup ftpServer sds1.myds.me
attr Rep.SQLite.Backup ftpUse 0
attr Rep.SQLite.Backup ftpUser ftpuser
attr Rep.SQLite.Backup optimizeTablesBeforeDump 0
attr Rep.SQLite.Backup room DbLog
attr Rep.SQLite.Backup showproctime 1
attr Rep.SQLite.Backup verbose 3

setstate Rep.SQLite.Backup Database backup finished
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpFileCreated /sds1/backup/dumps_FHEM/fhem_2018_06_22_17_25.sqlitebkp.gzip
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpFileCreatedSize 485.18 MB
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpFilesDeleted fhem_2018_06_21_17_25.sqlitebkp.gzip
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpRowsCurrent n.a.
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpRowsHistory n.a.
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 background_processing_time 141.2785
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 state Database backup finished


Für den Restore-Test habe ich in /opt eine Sqlite-DB mit dem Namen fhem1.db angelegt. Mit dem DEF "./db_sqlite1.conf aaaa:bbbbb" im
DbLog-Device wird nichts geloggt. Die Rechte der DB habe ich so gesetzt:


sudo chmod 664 /opt/fhem1.db
stehen also auf: -rw-rw-r--   fhem dialout

 
Nun habe ich noch ein DbRep-Device für den Resore angelegt. Das ist so definiert:

defmod Rep.SQLite1.Restore DbRep LogSQLITE1
attr Rep.SQLite1.Restore aggregation no
attr Rep.SQLite1.Restore allowDeletion 1
attr Rep.SQLite1.Restore devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.SQLite1.Restore disable 0
attr Rep.SQLite1.Restore dumpDirLocal /sds1/backup/dumps_FHEM
attr Rep.SQLite1.Restore dumpFilesKeep 1
attr Rep.SQLite1.Restore event-on-update-reading state
attr Rep.SQLite1.Restore executeAfterProc set LogSQLITE1 reopen
attr Rep.SQLite1.Restore executeBeforeProc set LogSQLITE1 reopen 3600
attr Rep.SQLite1.Restore room DbLog
attr Rep.SQLite1.Restore showproctime 1
attr Rep.SQLite1.Restore verbose 3


Damit der Cross-Restore funktioniert habe ich das bestehende BackupFile kopiert:

cp /sds1/backup/dumps_FHEM/fhem_2018_06_22_17_25.sqlitebkp.gzip /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp.gzip

Das File muß mit "fhem1" beginnen, weil die Zieldatenbank so heißt und das File sonst vom DbRep nicht gefunden wird (Feature).
Den Restore habe ich nun mit dem "Rep.SQLite1.Restore"-Device gestartet.
Das ca. 3GB große Backupfile mit rund 15 Mio Datensätzen wurde in rund 440 Sekunden reingefahren.

Hier das Log noch dazu:

2018.06.23 15:21:40.137 3: DbRep Rep.SQLite1.Restore - ################################################################
2018.06.23 15:21:40.138 3: DbRep Rep.SQLite1.Restore - ###             New database Restore/Recovery                ###
2018.06.23 15:21:40.139 3: DbRep Rep.SQLite1.Restore - ################################################################
2018.06.23 15:21:40.140 3: DbRep Rep.SQLite1.Restore - execute command before restore: 'set LogSQLITE1 reopen 3600'
2018.06.23 15:21:40.144 2: DbLog LogSQLITE1: Connection closed until 16:21:40 (3600 seconds).
2018.06.23 15:21:40.166 3: DbRep Rep.SQLite1.Restore - uncompress file /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp.gzip
2018.06.23 15:22:34.630 3: DbRep Rep.SQLite1.Restore - file uncompressed to output file: /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp
2018.06.23 15:22:34.645 3: DbRep Rep.SQLite1.Restore - Size of uncompressed file: 3236.36 MB
2018.06.23 15:22:34.646 3: DbRep Rep.SQLite1.Restore - Starting restore of database 'fhem1.db'
2018.06.23 15:29:09.218 3: DbRep Rep.SQLite1.Restore - Restore of /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp into 'fhem1.db' finished - total time used: 449 seconds.
2018.06.23 15:29:09.227 3: DbLog LogSQLITE1: Reopen requested.
2018.06.23 15:29:09.228 3: DbLog LogSQLITE1 - Creating Push-Handle to database SQLite:dbname=/opt/fhem1.db with user
2018.06.23 15:29:09.240 3: DbLog LogSQLITE1 - Push-Handle to db SQLite:dbname=/opt/fhem1.db created
2018.06.23 15:29:09.249 2: DbRep Rep.SQLite1.Restore - command message after restore: "Reopen executed."
2018.06.23 15:29:09.254 3: DbRep Rep.SQLite1.Restore - Database restore finished successfully.


Hat also so geklappt wie es soll.
Das hilft dir jetzt wahrscheinlich noch nicht weiter, aber ich konnte deinen Fehler bei mir nicht nachvollziehen, was auch unschön ist.
Hast du mal Google befragt ? Ich denke mal noch etwas darüber nach.
Je nachdem wie groß dein File ist kannst du es vllt. mal bei Dropbox ablegen. Dann könnte ich es mal bei mir probieren, falls dir das recht sein sollte.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Juni 2018, 16:02:57
Hallo Wolfgang,

habe mal schnell die SuFu angeworfen und gefunden:

Zitat
2
down vote

In Linux command shell, I did:

chmod 777 <db_folder>

Where contains the database file.

It works. Now I can access my database and make insert queries.

aus: https://stackoverflow.com/questions/1518729/change-sqlite-database-mode-to-read-write

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 23 Juni 2018, 18:14:27
Hallo Heiko,
herzlichen Dank für die schnelle und professionelle Hilfe. Da bekommt man ja schon fast ein schlechtes Gewissen für die Zeit, die Du da investiertst.
Das Verzeichnis hatte ich schon auf 777 eingestellt, was aber nicht von Erfolg beschieden war. Ich hatte auch noch ein paar andere DbRep auf die Datenbank definiert, die als Status 'connected' angezeigt haben. Die habe ich über das Attribut 'disable 1' jetzt alle mal vorsichtshalber disabled, nicht dass es da irgend welche Nebeneffekte gibt. Aber auch das hat an der Situation nichts geändert.

Auf dem System gibt es zwei defines für DbLog (unterschiedliche Datenbanken). Könnte das noch ein Problem sein?

Ich hätte jetzt kein Problem, Dir das Backup der Datenbank auf Dropbox hochzuladen. Also wenn Du die Zeit wirklich spendieren möchtest, kannst Du mir den Dropbox Link schicken. Ich vertraue Dir, dass die Daten in Deiner Hand bleiben.

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Juni 2018, 18:48:48
Hallo Wolfgang,

ZitatAuf dem System gibt es zwei defines für DbLog (unterschiedliche Datenbanken). Könnte das noch ein Problem sein?
Nein, kann ich mir nicht vorstellen. Das sind andere Handles.

Ist das dazugehörige DbLog auf asynchron eingestellt ? Wenn nicht, könnte das ein Problem sein.

ZitatIch hätte jetzt kein Problem, Dir das Backup der Datenbank auf Dropbox hochzuladen. Also wenn Du die Zeit wirklich spendieren möchtest, kannst Du mir den Dropbox Link schicken. Ich vertraue Dir, dass die Daten in Deiner Hand bleiben.
Die Daten werde ich nach dem Test natürlich wieder löschen. Einen Versuch wäre es wert.

Ich habe auf meinem Testsystem 6 Datenbanken mit den dazu gehörigen DbLogs drauf und vielleicht 40 DbReps. Gegen die zu restorende DB arbeiten 2 DbReps und hat auch nicht gestört.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 23 Juni 2018, 22:37:09
Hallo Heiko,
jetzt bin ich einen anderen Weg zur Rettung der Daten gegangen.

Nachdem ich irgendwo im WEB gelesen habe, dass man das sqlite-backup als DB mit sqlite3 auf der Kommandozeile öffnen kann, habe ich das versucht und das hat auch geklappt.
Dann auf der sqlite-Kommandozeile pragma integrity_check ausgeführt und siehe da, das Backup hatte einige Fehler. Dann wie im DbLog-Wiki beschrieben, einen kompletten sql-Dump der DB gemacht und alle weiteren Schritte, wie im Wiki beschrieben, durchgeführt. Also neue DB mit .read aus dem sql-Dump befüllen. sqlite verlassen, DB umbenennen, Rechte und Owner anpassen.
Dann wieder fhem gestartet und testweise mit DbRep ein backup -> restore durchgeführt. Das hat jetzt funktioniert. Ich schließe daraus, dass DbRep restore mit der korrupten DB ein Problem hatte und es deshalb nicht auf dem direkten Weg, wie wir ihn heute Nachmittag diskutiert haben, funktioniert hat.
Erste Daten habe ich jetzt mit DbRep export als .csv gesichert um diese dann in die originale DB wieder einlesen zu können. Ich bin mir sicher, dass ich damit dann alle Daten wieder herstellen kann.

Falls Du das defekte backup, bei dem immer der Fehler
DBD::SQLite::db sqlite_backup_from_file failed: sqlite_backup_from_file failed with error attempt to write a readonly database at ./FHEM/93_DbRep.pm line 6902.\ aufgetreten ist, für einen Test haben möchtest, kann ich es Dir schicken.

Also nochmals herzlichen Dank für die Unterstützung. Ich hoffe, dass ich so schnell nicht wieder eine defekte DB habe.

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Juni 2018, 22:55:45
Na das ist doch eine gute Nachricht. :)

ZitatIch schließe daraus, dass DbRep restore mit der korrupten DB ein Problem hatte und es deshalb nicht auf dem direkten Weg, wie wir ihn heute Nachmittag diskutiert haben, funktioniert hat.
Nicht ganz. DbRep verwendet eine von SQLite bereit gestellte Funktion zum Restore. Die meldet diesen Fehler und DbRep schiebt ihn durch.

Die Daten brauche ich dann nicht mehr denke ich.
Na dann viel Glück beim weiteren Loggen  :)

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 08 Juli 2018, 10:02:26
Hallo Forum,

als Anfänger benötige ich bitte noch mal eure Hilfe...
Wenn ich das DBReporting tool als SQL Abfrage benutze, kann ich mir z.B. mit

set DBReporting sqlCmd select MAX(CAST(VALUE AS double)) from history where device = 'LaCrosse_3E' and READING = 'temperature' and TIMESTAMP like '2018-05%';

...die maximale Außentemperatur vom Monat Mai Anzeigen lassen.
Als Ergebnis kommt dann
SqlResultRow_1    35.5

Soweit alles gut. Jetzt aber die Anfängerfrage:
Wie kann ich diesen Wert jetzt einem Dummy zuweisen, das ich mir das täglich berechnen und in die DB speichern kann...? ALso sozusagen einen Watchdog ala
define sun_riseSet_timer at *03:00:00 { my $s = sunrise("REAL");; fhem("set Sonnenaufgang $s");; $s = sunset("REAL");; fhem("set Sonnenuntergang $s");; }


ist das machbar?

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Juli 2018, 11:05:05
Hallo Thomas,

ja, ist machbar. Es gibt mindestens zwei Varianten. Eine ist im Wiki beschrieben: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten

Die andere Variante betrifft die Verwendung des Attr userExitFn. Dafür muss man etwas selbst programmieren, kann dadurch aber mehr.
Schau im Wiki ma! zuerst.

EDIT:
Eine weitere Variante ohne Umwege könnte folgende sein. Setze dir im DbRep die Attribute:


device = LaCrosse_3E
reading = temperature
timestamp_begin = current_month_begin
timestamp_end = current_month_end
aggregation = month


Dann könntest du:


set <DbRep> maxValue writeToDb


regelmäßig laufen lassen um den Maximalwert des aktuelle Monats immer in die DB schreiben zu lassen. Ist bereits ein Wert in der DB, wird er aktualisiert.
Der Maximalwert wird für das Device "LaCrosse_3E" mit dem neuen Readingnamen "max_month_temperature" in die DB geschrieben.

Lg
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 08 Juli 2018, 21:32:33
Hallo Heiko,

danke für die Hilfe. Ich werde mich die Tage dann mal durch das Wiki kämpfen. beim überfliegen hab ich es noch nicht verstanden.
dein Beispiel hier hat auch nicht das gewünschte ergebnis gebracht. Zumindest wird kein Reading im LaCrosse eingetragen...
Wenn ich hinterher eine Abfrage der DB mache (select * from history where device = 'LaCrosse_3E' and reading like 'max%' and Timestamp like '201%';)
liefert er 0 Ergebnisse
Attribute:

aggregation = day
device = LaCrosse_3E
reading = temperature
timestamp_begin = 2018-07-07 00:00:00
timestamp_end = 2018-07-08 00:00:00


Mein Gedanke, oder mein wunsch ist eigentlich für viele verschiedene Devices eine Min/Max/AVG Temperatur für Tag/Monat abzuspeichern.
Ebenso für Stromverbrauch einen Max...

Gruß
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Juli 2018, 21:50:25
Hallo Thomas,

hier nochmal der Link für den konkreten Abschnitt: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Reading_von_DbRep_nach_Dummy_.C3.BCbertragen

Das ging vorhin in der Kürze nicht.

Wenn du verbose 4 im DbRep einstellst siehst du wenn/welches Ergebnis mit "set <DbRep> maxValue writeToDb" abgespeichert wird.
Schau nochmal bzw. poste mal was da kommt.

Zitat
Mein Gedanke, oder mein wunsch ist eigentlich für viele verschiedene Devices eine Min/Max/AVG Temperatur für Tag/Monat abzuspeichern.
Ebenso für Stromverbrauch einen Max...
Ja, so etwas ähnliches mache ich auch. Ich benutze mehrere DbReps um die Summenwerte der Energieverbräuche/Erzeugung zu ermitteln und per Readingsgroup darzustellen.
siehe Anhang

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 09 Juli 2018, 11:36:25
Hallo Heiko,

nach unserer letzten Konversation in diesem Thread im Juni bezüglich retten von Daten aus einer korrupten SQLITE DB habe ich mir mit DOIF einen E-Mail Alarm eingerichtet, der alarmiert, wenn der DB Zustand 'connected' verlassen wird.

Eine Änderung von 'connected' zu einem anderen Zustand tritt geplant ein, wenn ich vor dem nächtlichen Backup ein reopen xxxxsec absetze, dann ist die DB im Zustand 'closed' bzw. in 'reopen' nach dem Backup und dann wieder in 'connected'. Das ist für mich schlüssig.
Zu einem anderen regelmäßigen Zeitpunkt in der Nacht, wenn ich Einträge älter als 31 bzw. 10 Tage weglösche ändert sich der Zustand in 'Commit already running - resync at NextSync'. Das könnte ich wahrscheinlich vermeiden, wenn ich vor den Löschaktionen auch ein reopen xxxxsec einfügen würde.

Was mich aber eigentlich verunsichert ist, dass zu beliebigen Zeitpunkten die DB immer mal wieder in den Zustand 'Commit already running - resync at NextSync' geht. Ich habe jetzt im Forum schon gesucht und auch im WEB gegoogelt, aber noch nichts gefunden, wo ich sagen würde, das beschreibt mein Problem.
Woher kommt der Zustand 'Commit already running - resync at NextSync' , ist das 'gefährlich' oder gibt es eine Abhilfe dafür?

Danke schon mal für eine Erklärung.

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Juli 2018, 11:58:55
Hallo Wolfgang,

Zitat
Zu einem anderen regelmäßigen Zeitpunkt in der Nacht, wenn ich Einträge älter als 31 bzw. 10 Tage weglösche ändert sich der Zustand in 'Commit already running - resync at NextSync'. Das könnte ich wahrscheinlich vermeiden, wenn ich vor den Löschaktionen auch ein reopen xxxxsec einfügen würde.
Ja, genau. Wenn du das machst, wäre für DbLog von vornherein klar, dass es momentan keine Schreibaktion auf der DB ausführen soll.

ZitatWas mich aber eigentlich verunsichert ist, dass zu beliebigen Zeitpunkten die DB immer mal wieder in den Zustand 'Commit already running - resync at NextSync' geht.....Woher kommt der Zustand 'Commit already running - resync at NextSync' , ist das 'gefährlich' oder gibt es eine Abhilfe dafür?
Grundsätzlich ist die Meldung 'Commit already running - resync at NextSync' erstmal nichts gefährliches.
Sie beschreibt den Zustand, dass ein Schreibzyklus in die DB stattfinden soll (z.B. durch erreichen syncInterval oder cacheLimit), aber bereits ein Schreibzyklus läuft der noch nicht abgeschlossen ist.
Dann passiert nichts anderes, als das die Daten weiterhin im Cache bleiben und nach einer gewissen Periode wieder versucht wird in die DB zu schreiben.
Wenn das also "immer mal" passiert, ist das nichts gravierendes, wenn es über einen längeren Zeitraum permanent in dem Zustand bleibt, sollte man sich mal darum kümmern.

Im Grunde kann sowas passieren wenn deine DB relativ langsam im Vergleich zu deinem eingestellten syncInterval (cacheLimit) ist, oder aber ein anderer Prozess temporär ein Schreiben verhindert weil der die Tabelle history gerade sperrt. Zum Beispiel beim Löschen von Daten oder Tabellenreorganisation (vacuum).

D.h. DbLog will seine Daten schreiben und startet den Hintergrundprzess dafür, der muss im Hintergrund warten weil die history Tabelle gerade nicht beschrieben werden kann (warum auch immer) ... in der Zwischenzeit wird SyncInterval/cacheLimit erreicht und der nächste Schreibprozess will starten und kann es nicht weil der Vorherige noch läuft --->  dann wird die Meldung 'Commit already running - resync at NextSync'  generiert !

Ich hoffe der Zusammenhang wurde jetzt ein bisschen klarer.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: pechnase am 09 Juli 2018, 13:21:18
Hallo Heiko,

danke für die, wie immer, fixe Antwort auf meine Frage. Zu dem einen Fall habe ich jetzt das executeBefore und executeAfter Attribut gesetzt. Mal sehen was heute Nacht dann gemeldet wird.
Für die sporadischen 'Commit already running - resync at NextSync' habe ich jetzt mal versuchsweise syncInterval von 30 auf 60 abgeändert. Der Fall kommt so 0 - 4 mal in 24h vor.

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 11 Juli 2018, 11:27:24
Hallo Heiko,

wieder einmal Danke für die schnelle Hilfe. Leider ist es wieder komplizierter, oder ich stell mich wieder zu blöd dazu an...


define Energy.Tag.Kuehlschrank dummy
attr Energy.Tag.Kuehlschrank room Energy

define N.Energy.Tag.Kuehlschrank notify DBReporting:(\d).*Grid.* { fhem "setreading Energy.Tag.Kuehlschrank".(split(":",$EVTPART0))[0]." $EVTPART1"}
attr N.Energy.Tag.Kuehlschrank room Energy


dies sind mein angelegtes Test-Dummy und dazu das notify.
So wie ich das verstehe, sollte doch jetzt alles an Readings, das beim Aufruf von DBReporting (DBRep heißt bei mir so) erscheint, auf das Dummy übertragen werden. So also bei
set DBReporting sqlCmd select MAX(VALUE) from history where DEVICE = "FBDECT_fbahahttp_08761_0044555" AND TIMESTAMP like "2018-07-09%" AND READING = "energy";

sollte er den W/h Zähler auf das Dummy übetragen... oder ?

weil es passiert nix.

im DBReporting werden die Readings erzeugt:
Readings

SqlResultRow_1 423962 2018-07-11 11:15:31
sqlCmd select MAX(VALUE) from history where DEVICE = "FBDECT_fbahahttp_08761_0044555" AND TIMESTAMP like "2018-07-09%" AND READING = "energy"; 2018-07-11 11:15:31
sqlResultNumRows 1 2018-07-11 11:15:31
state done 2018-07-11 11:15:31

aber im dummy ist nix.

was mache ich falsch?

gruß
Thomas

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Juli 2018, 11:39:22
du triggerst dein notify auf DBReporting:(\d).*Grid.* , aber dein Reading / Event heisst doch SqlResultRow_1 ?!
bin grad unterwegs, deswegen kurz und knapp.

lg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 11 Juli 2018, 11:57:13
...richtig.
ich kenne Perl nicht und bin wohl fälschlicherweise davon ausgegangen, das DBReporting:(\d).*Grid.*  das komplette Grid  abholt  :o
dem ist wohl nicht so. Jetzt rätsel ich also darüber, was das (\d) eigentlich tut :) das *Grid* wird wohl irgendwas aus deinen Aufbau sein. Hier sollte dann wohl das SqlResultRow_1 rein...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Juli 2018, 12:06:03
Du musst das notify ntürlich anpassen. \d ist perl für eine ziffer und grid ist einfach
der string grid.  ;)
Du müsstest also DBReporting:.*SqlResultRow_1.*  probieren .... und etwas perl lernen  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 11 Juli 2018, 13:34:40
Hallo Heiko,

Danke für die Hilfe. Ich weiß ich muss Perl lernen. Leider ist es schwierig, das ganze mit FHEM in Verbindung zu bringen.
Dein Vorschlag DBReporting:.*SqlResultRow_1.*  funktioniert leider genauso wenig...
DBReporting:.*SqlResultRow_1.* { fhem "setreading Energy.Tag.Kuehlschrank".(split(":",$EVTPART0))[0]." $EVTPART1"}

ich dachte der "." oder das "*" wäre da irgendwie falsch. Ich konnte mich dran erinnern, das es bei einigen ESP Devices so aussieht: Lampe:Relay
Also hab ich auch DBReporting:SqlResultRow_1.* { fhem "setreading Energy.Tag.Kuehlschrank".(split(":",$EVTPART0))[0]." $EVTPART1"}
usw. probiert
Aber das Ding will einfach nicht. Das Dummy behält seine ? ? ?

Könnte bei mir bitte jemand kurz die "Holzhammermethode" anwenden? :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Juli 2018, 13:45:34
probiers doch erstmal ganz simpel mit
DBReporting:.*SqlResultRow_1.* { fhem "setreading Energy.Tag.Kuehlschrank test test"}

Ein event kommt ja ? du könntest dir im Eventmonitor auch ein notify generieren lassen und dann anpassen.


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 11 Juli 2018, 13:49:44
pahhh!

das geht...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Juli 2018, 13:53:44
 :)
damit kannst du dich langsam vorwärts hangeln. Du schaffst das !

Lg
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 11 Juli 2018, 13:57:36
Danke Dir...

ich hab den Fehler gefunden... :)
DBReporting:SqlResultRow_1.* { fhem "setreading Energy.Tag.Kuehlschrank ".(split(":",$EVTPART0))[0]." $EVTPART1"}

es fehlte das Leerzeichen zwischen Kuehlschrank und " ::)

jetzt kommt ich weiter !!!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 13 Juli 2018, 11:33:46
Hallo Heiko,

ich schon wieder...
würde so etwas funktionieren?:
define Temperatur.Tag.berechnen at *02:00:00 { fhem "set DBReporting sqlCmd select MIN(CAST(VALUE as double)) from history where DEVICE = """LaCrosse_3E""" AND TIMESTAMP like "$year"-"$month"-"$mday-1"% AND READING = """temperature""";"}

oder wie bekomme ich das bei solch eine Abfrage dynamisch hin?
dann könnte ich mir ein "at" basteln, in dem einmal täglich die Berechnung gemacht wird...

zur Erläuterung ... [Edit]
ich kann mir z.B. mit
set DBReporting sqlCmd select MIN(CAST(VALUE as double)) from history where DEVICE = "LaCrosse_3E" AND TIMESTAMP like "2018-07-05%" AND READING = "temperature";

die aktuelle Min(/Max/Avg) Temperatur des ausgewählten Tages ausgeben lassen.
Diese möchte ich in ein Dummy schreiben und dadurch in der DB speichern.
dazu möchte ich ein "At" benutzen.
Für das "at" müsste ich aber den Tag von gestern Dynamisch auswählen...

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Juli 2018, 18:07:42
Hallo Thomas,

am einfachsten wäre es wahrscheinlich wenn du dir ein dbrep definierst mit den Attributen

device=LaCrosse_3E
reading=temperature
aggregation=day
timestamp_begin=previous_day_begin
timestamp_end=previous_day_end


Jetzt kannst du dir ein at definieren und ein

set dbrep minValue     oder max/avgValue

regelmässig aufrufen, auf den dummy übertragen ... was auch immer.

Noch einfacher hast du es wenn du ein

set dbrep minValue writeToDB     (oder max/avgValue)

verwendest. Dann bekommst du für jeden Tag den min/max/avg Wert automatisch in die Db geliefert. Schau dir mal dazu die Erläuterungen in der commandref an.

Wenn du mit sqlCmd arbeiten möchtest, kannst du Platzhalter verwenden um die Timestamp-Einstellungen des Dbrep devices zu übernehmen (also previous_day_begin z.b.). Steht auch in der commandref erläutert.

Ps: dein Ansatz würde am 1. des Monats zum Absturz von fhem führen weil $mday-1 ungültig wäre.

Lg
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 16 Juli 2018, 09:40:09
Hallo Heiko,
Danke für die wie immer ausführliche Hilfe.

verstehe ich das richtig, das ich dann, wie in deinem Beispiel für jedes Device - Min/Max/Avg einen eigenen DBRep anlegen muss ?

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Juli 2018, 09:50:13
Müssen nicht. Aber es macht es einfacher und übersichtlicher.

Lg,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 16 Juli 2018, 15:59:05
Hallo Forum,

ich traue es mir nicht, das hier zu sagen :)
ich möchte versuchen, nicht für jedes Device ein eigenes DBRep aufzumachen und hab deshalb ein "at" wie folgt definiert...

define at.Energy.Tag.Kuehlschrank at *15:52:00 attr DBReporting_LaCrosse device LaCrosse_3E;;\
attr DBReporting_LaCrosse reading temperature;;\
attr DBReporting_LaCrosse aggregation day;;\
attr DBReporting_LaCrosse timestamp_begin previous_day_begin;;\
attr DBReporting_LaCrosse timestamp_end previous_day_end;;\
set DBReporting_LaCrosse minValue writeToDB;;\
set DBReporting_LaCrosse mmaxValue writeToDB;;\
set DBReporting_LaCrosse avgValue writeToDB
attr at.Energy.Tag.Kuehlschrank room Energy


dabei gibt es nun ein timeout, der process wird terminated... (set DBReporting_LaCrosse minValue writeToDB)
Ich nehme an, die DB suche dauert zu lange und es wird bereits die nächste Zeile gestartet.
kann man das umgehen? Ich weiß ich muss noch einiges lernen. Aber zu meiner Entschuldigung... das versuche ich ja hiermit

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Juli 2018, 17:28:16
Hi Thomas,
den grund für die Problematik hast du richtig erkannt, er liegt in der asynchronen Arbeitsweise begründet.
Es gibt nun mindestens zwei Ansätze. Entweder definierst du drei at und setzt in jedem at die notwendigen Attribute vor dem set Befehl, so wie du es bereits gemacht hast. Aber eben für minValue, maxValue, avgValue jeweils ein at. Den Abstand zwischen den at wählst du genügend groß.

Der zweite Ansatz ist die Verwendung von userExitFn. damit kannst du eine Queue aufbauen die nacheinander minValue , maxValue, avgValue ausführt sobald der vorherige Befehl ausgeführt ist.
Bin momentan im Urlaub und kann deswegen nicht soviel Zeit für Erklärungen aufwenden, aber vielleicht gelingt es dir ja mit Hilfe anderer User sowas aufzubauen.
Später kann ich wieder mehr unterstützen.

edit, die Attribute musst du in den at nicht setzen, die ändern sich ja nicht. einmal im dbrep definiert reicht.

Lg
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2018, 10:19:39
Hallo Heiko,

danke für die Hilfe. Solch "Denk-Anstöße" sind immer sehr Hilfreich :)
...Aber das Benutzen der userExitFn ist mir momentan noch zu weit fortgeschritten.

ich probiere es dann erst einmal mit einzelnen Aufrufen.

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2018, 12:10:32
ich mache es jetzt so...

define at.Energy.Tag.Kuehlschrank1 at *11:51:00 attr DBReporting_LaCrosse device LaCrosse_3E;;\
attr DBReporting_LaCrosse reading temperature;;\
attr DBReporting_LaCrosse aggregation day;;\
attr DBReporting_LaCrosse timestamp_begin previous_day_begin;;\
attr DBReporting_LaCrosse timestamp_end previous_day_end;;\
set DBReporting_LaCrosse averageValue writeToDB\
attr at.Energy.Tag.Kuehlschrank1 room Energy


jedoch hab ich immer noch nicht rausgefunden wo die Werte mit writeToDB hingeschrieben werden...
als Rückmeldung gibt es:


2018-07-16__LaCrosse_3E__temperature__AVERAGE__2018-07-16 22.4021 2018-07-17 11:51:00
state done 2018-07-17 11:51:00

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2018, 12:39:25
Das siehst du wenn du mal verbose 4 oder 5 einschaltest
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2018, 15:03:46
hier mal Verbose 4 und Verbose 5...:


2018-07-17 14:57:36 DbRep DBReporting_LaCrosse running
2018-07-17 14:57:36 DbRep DBReporting_LaCrosse 2018-07-16__LaCrosse_3E__temperature__AVERAGE__2018-07-16: 22.4021
2018-07-17 14:57:36 DbRep DBReporting_LaCrosse done
2018-07-17 14:58:02 Global global ATTR DBReporting verbose 5
2018-07-17 14:58:14 DbRep DBReporting_LaCrosse running
2018-07-17 14:58:14 DbRep DBReporting_LaCrosse 2018-07-16__LaCrosse_3E__temperature__AVERAGE__2018-07-16: 22.4021
2018-07-17 14:58:14 DbRep DBReporting_LaCrosse done


wenn ich jetzt in der DB nach %AVERAGE% suche, kommen 0 Datensätze :(
was mach ich falsch? Es reicht aber, wenn Du mir nach deinem Urlaub antwortest :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2018, 18:07:24
Naja der geht noch eine Weile  :)
Mit verbose 4 musst du aber ins logfile schauen und nicht auf den Eventmonitor.
Dann siehst du etwa folgendes

2018.07.17 15:28:53.029 4: DbRep Rep.SMAEM.Bezug - -------- New selection ---------
2018.07.17 15:28:53.030 4: DbRep Rep.SMAEM.Bezug - Command: averageValue writeToDB
2018.07.17 15:28:53.032 4: DbRep Rep.SMAEM.Bezug - Timestamp begin human readable: 2018-07-16 00:00:00
2018.07.17 15:28:53.033 4: DbRep Rep.SMAEM.Bezug - Timestamp end human readable: 2018-07-16 23:59:59
2018.07.17 15:28:53.034 4: DbRep Rep.SMAEM.Bezug - Aggregation: no
2018.07.17 15:28:53.035 4: DbRep Rep.SMAEM.Bezug - averageValue calculation sceme: avgArithmeticMean
2018.07.17 15:28:53.054 4: DbRep Rep.SMAEM.Bezug - SQL execute: SELECT AVG(VALUE) FROM history where DEVICE = 'SMA_Energymeter' AND READING = 'Bezug_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2018-07-16 00:00:00' AND TIMESTAMP <= '2018-07-16 23:59:59' ;
2018.07.17 15:28:53.069 4: DbRep Rep.SMAEM.Bezug - data prepared to db write:
2018.07.17 15:28:53.070 4: DbRep Rep.SMAEM.Bezug -
2018-07-16 23:59:58|SMA_Energymeter|SMAEM|calculated|avgam_no_Bezug_WirkP_Zaehler_Diff|0.0019|
2018.07.17 15:28:53.223 3: DbRep Rep.SMAEM.Bezug - number of lines updated in "LogDB": 0
2018.07.17 15:28:53.224 3: DbRep Rep.SMAEM.Bezug - number of lines inserted into "LogDB": 1


Nach dem " data prepared to db write:" findest du auch das neue reading und den Wert mit dem timestamp der in der DB abgespeichert wird.

LG
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2018, 20:10:18
Hallo Heiko,

es tut mir leid. In welches Logfile muss ich schauen?
In den FHEM Logfile finde ich keine Einträge. Zu diesem Zeitpunkt waren nur diese Einträge:

2018.07.17 14:57:08 2: ESPEasy espBridge: httpReq failed:  192.168.2.134 NodeMCU_2 'neopixel 85,0,60,0'
2018.07.17 14:57:28 3: ESPEasy: set ESPEasy_NodeMCU_2 neopixel 85 0 60 0
2018.07.17 14:57:31 2: ESPEasy espBridge: httpReq failed:  192.168.2.134 NodeMCU_2 'neopixel 85,0,60,0'
2018.07.17 14:58:05 3: ESPEasy: set ESPEasy_NodeMCU_2 neopixel 85 0 60 0
2018.07.17 14:58:08 2: ESPEasy espBridge: httpReq failed:  192.168.2.134 NodeMCU_2 'neopixel 85,0,60,0'
2018.07.17 14:58:29 3: ESPEasy: set ESPEasy_NodeMCU_2 neopixel 85 0 60 0
2018.07.17 14:58:32 2: ESPEasy espBridge: httpReq failed:  192.168.2.134 NodeMCU_2 'neopixel 85,0,60,0'
2018.07.17 14:59:06 3: ESPEasy: set ESPEasy_NodeMCU_2 neopixel 85 0 60 0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2018, 20:56:54
Ja im normalen fhem logfile fimdest du die einträge. Verbose 4 stellst du im dbtep ein.
Die infos die ich schrieb findest du dann auf jeden fall im fhem logfile. Sonst  wäre ja irgendwas faul.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2018, 14:33:01
Danke, ich hab es gefunden...

das hab ich gemacht:
set DBReporting_LaCrosse averageValue writeToDB

aber komischerweise kommt das writeToDB nicht an:


2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse - -------- New selection ---------
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse - Aggregation: day
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse - Command: averageValue
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse - Timestamp begin human readable: 2018-07-17 00:00:00
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse - Timestamp end human readable: 2018-07-17 23:59:59
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse -> Start BlockingCall averval_DoParse
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse - SQL execute: SELECT AVG(VALUE) FROM history where DEVICE = 'LaCrosse_3E' AND READING = 'temperature' AND TIMESTAMP >= '2018-07-17 00:00:00' AND TIMESTAMP < '2018-07-17 23:59:59' ;
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse -> BlockingCall averval_DoParse finished
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse -> Start BlockingCall averval_ParseDone
2018.07.18 14:27:04 4: DbRep DBReporting_LaCrosse -> BlockingCall averval_ParseDone finished


man sieht bei Command kommt nur ein "averageValue" es fehlt das "writeToDB", wie man es bei Dir sehen kann.
muss ich hierfür irgendwo noch ein allow setzen?

DBLogType steht auf Current/History

lg
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2018, 14:47:27
Nein musst sonst nichts setzen. Welche DbRep Version hast du ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2018, 14:50:29
Version 6.4.2
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2018, 14:54:17
na dann mach mal ein update vom dbrep.  :) die Funktion kam erst später.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2018, 15:13:59
danke, geht!

sorry für meine Dummheit.

ich versuchte immer mit "update DBReporting" aktuell zu halten. Aber das musste man ja direkt runterladen.
Du bist ja schon bei v 7.18
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2018, 15:15:57
Also wenn dann update oder update DbRep  :D Dann musst du auch nicht direkt runterladen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 August 2018, 13:00:42
Hallo zusammen,

habe gerade eine Version eingecheckt die das Attribut "valueFilter" enthält.
Damit ist es nun bei der Funktion fetchrows möglich die Datensätze zusätzlich zu filtern.
Hilfreich kann es zum Beispiel sein, wenn die Kriterien Device, Reading allein nicht ausreichen. Zum Beispiel um Syslog-Datensätze, die
in einer DB gespeichert wurden, anhand ihrer Severity Eigenschaften (Warning, Error, etc.) aus der DB zu selektieren und anzuzeigen.

LG,
Heiko   
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 September 2018, 22:36:22
Ich habe eine Version 8.0.0 zum Test nach contrib geladen.
Neu ist, dass "set <name> restoreMySQL ..." nun auch Dumps einspielen kann, die mit einem clientSide Backup erstellt wurden.
Es können nun beide Arten vonMySQL- Dumps mit dem Modul wieder eingespielt werden.

Die Version könnt ihr hier aus contrib herunterladen:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 September 2018, 19:00:39
Das Feature ist eingecheckt und die Datei aus contrib wieder entfernt.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 19 September 2018, 09:22:25
Hallo Heiko,

Nach dem Update gestern startet mein FHEM nicht mehr.
Ein Downgrade des DbRep-Moduls hat gereicht.

In der Log hatte ich nur immer wiederkehrende Einträge dieser Art, direkt nach dem Start.
1: DbRep rep.maxday -> BlockingCall DbRep_getMinTs pid:2916 Timeout: process terminated

FHEM schien danach in einer Schleife zu laufen, die Weboberfläche war nie erreichbar.

Nach dem Downgrade kommt die de meldung ebenfalls, FHEM startet jedoch "normal" und ist erreichbar.


sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 September 2018, 09:50:49
Morgen Joe,

kann ich momentan noch nicht nachvollziehen, weil es 1. bei mir nicht passiert und 2. ich an dieser Funktion schon ewig nichts geändert habe.

Geh doch mal bitte in das aktuelle Modul und ändere das Timeout $to in Zeile 1336 auf einen höheren Wert:

sub DbRep_firstconnect($) {
  my ($hash) = @_;
  my $name       = $hash->{NAME};
  my $to         = "120";


Der ist auf 2 Minuten eingestellt. Das ist schon sehr lange. Kann es sein dass deine DB nicht erreichbar ist zu diesem Zeitpunkt ?.
Aber trotzdem darf FHEM nicht blockieren, da es ja ein blockingCall ist.
Bisschen undurchsichtig gerade.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 19 September 2018, 10:56:27
Hallo Heiko,

habe fast befürchtet, dass es "undurchsichtig" ist, jedoch gab das Log leider nicht mehr her und es war reproduzierbar.
Jetzt allerding funktioniert es wieder ganz normal. Meine DB war eigentlich nicht ausgelastet und ist relativ performant!

Jedoch sind jetzt auch die Timeout-Meldungen von DbRep später im Log, also erst, nachdem die Weboberfläche verfügbar ist.

Sieh mal wie lange dieser Test hier durchgeführt wird:

2018.09.19 10:48:51 3: DbRep rep.samplefill - Connectiontest to database mysql:database=fhem;mysql_socket=/var/run/mysqld/mysqld.sock with user fhemuser
2018.09.19 10:49:34 4: DbRep rep.samplefill - Connectiontest to db mysql:database=fhem;mysql_socket=/var/run/mysqld/mysqld.sock successful


Wobei eine normale Abfrage mit Connectionaufbau sehr schnell am System geht:

time echo "select * from history limit 1;" | mysql -pXXXX fhem
TIMESTAMP       DEVICE  TYPE    EVENT   READING VALUE   UNIT    datatype
2018-01-09 10:49:36     sql     DBLOG   CacheUsage: 0   CacheUsage      0               0

real    0m0,029s
user    0m0,016s
sys     0m0,012s


Hilft das irgendwie weiter?

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 September 2018, 12:06:30
So richtig kann ich mir noch keinen Reim machen. Der Test darf ruhig etwas länger dauern, es wird der kleinste Timestamp innerhalb der DB ermittelt.
Das passiert aber eben auch in einem blockingCall und darf deshalb keine Auswirkunge auf FHEM haben. Hat es bei mir auch nicht.
Kann es sein, dass die Definition des DbRep-Devices in der fhem.cfg vor der Definition des DbLog-Devices passiert ?
Wobei dann eigentlich Fehler kommen müssten ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 September 2018, 21:31:14
Hallo Joe,

habe soeben eine geänderte Version von DbRep eingecheckt.
Die Ermittlung des kleinsten Timestamp in der DB geht nun deutlich schneller (habe dein statement verwendet).
Außerdem wird ein eventuell gefundener invalider Timestamp im state angezeigt:


invalid timestamp "0000-00-00 00:00:00" found in database - please delete it


Das kann z.B. vorkommmen falls die DB älter ist und Altlasten enthält die damals noch nicht abgefangen wurden.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 24 September 2018, 14:54:40
Hallo Heiko,

Danke, damit bekomme ich die Fehlermeldunge nicht mehr.
Was ich aber nicht ganz verstehe ist:

DbRep ist konzipiert, dass man mehrere Devices für verschiedene Aufgaben anlegt. Ich habe 18 solche Devices, die alle meistens nichts zu tun haben,
da ich nur einmal im Quartal meine DB bereinige.
Wenn ich es korrekt sehe, greifen jedoch zumindest beim FHEM-Start alle 18 Devices auf die Datenbank zu und machen dort eine Abfrage um danach auf den Status "connected" zu springen. Ist das korrekt? Wenn ich also zB die Anzahl der gleichzeitigen Connections auf 3 reduziere, könnte es hier zu "stau" kommen?!.

sG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 September 2018, 15:15:03
Hi Joe,

ich habe sogar 112 Devices in meinem Prod ....  ;)

Du hast richtig beobachtet, dass beim Start jedes Device einen kurzen connect zur DB macht. Brauche ich um bestimmte Infos zu holen.
Aber wenn du genau hinschaust wirst du sehen, dass die Devices nicht alle gleichzeitig in die Db greifen und der Status connected nach und nach bei allen Devices eintritt.
Im Modul habe ich dafür die Aufrufe nach dem Zufallsprinzip innerhalb einer von mir definierten Zeit organisiert. Die Gefahr eines gleichzeitigen Aufrufs ist dadurch gering, wenn auch nicht unmöglich.
Du wirst wahrscheinlich kein Problem bekommen, wenn du die Anzahl der gleichzeitigen db- connects begrenzt. Aber ich würde in dem Fall auch die Anzahl der möglichen gleichzeitigen Blockingcalls im fhem begrenzen. Dann dürfte es kein spürbares Problem geben.

Lg,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 25 September 2018, 10:50:07
Zitat von: DS_Starter am 24 September 2018, 15:15:03
Aber ich würde in dem Fall auch die Anzahl der möglichen gleichzeitigen Blockingcalls im fhem begrenzen. Dann dürfte es kein spürbares Problem geben.

Hallo Heiko,

danke für den Tip! das werde ich mal beobachten!!!

sG
Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 09 Oktober 2018, 19:21:19
Hallo,
seit kurzem, leider weiss ich nicht seit wann, weil ich nur sporadisch dort reinschaue, zählt dbrep (Count) nicht mehr richtig.
Die Definition ohne Attribut "timeOlderThan" ist noch ok, der Zähler stimmt. Setze ich das Attribut auf nur "1", wird nur ein Bruchteil aus der DB gezählt.
Also zb. ohne sind es 115000 Datensätze, mit nur noch 290. Timestamps sind aber ok, lt. SQL-Manager.
Ich bitte mal den Entwickler, sich das anzuschauen. Ich bereinige damit die Datenbank.
Danke.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Oktober 2018, 19:39:22
Hast du die aktuellste Version ?

Ich habe das versucht bei mir nachzustellen, funktioniert aber einwandfrei:


2018.10.09 19:35:56.121 4: DbRep Rep.CPU - -------- New selection ---------
2018.10.09 19:35:56.121 4: DbRep Rep.CPU - Command: countEntries history
2018.10.09 19:35:56.122 4: DbRep Rep.CPU - Timestamp begin human readable: 2016-04-10 07:00:00
2018.10.09 19:35:56.122 4: DbRep Rep.CPU - Time difference to current time for calculating Timestamp end: 1 sec
2018.10.09 19:35:56.123 4: DbRep Rep.CPU - Timestamp end human readable: 2018-10-09 19:35:55
2018.10.09 19:35:56.123 4: DbRep Rep.CPU - Aggregation: no
2018.10.09 19:35:56.137 4: DbRep Rep.CPU - SQL execute: SELECT COUNT(*) FROM history where DEVICE = 'sysmon' AND READING = 'stat_cpu_percent' AND TIMESTAMP >= '2016-04-10 07:00:00' AND TIMESTAMP <= '2018-10-09 19:35:55' ;


Setze dir bitte verbose 4 und poste mal den Logausschnitt und auch den List deines DbRep.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 10 Oktober 2018, 07:08:29
Hallo,
die Version ist aktuell von gestern, hier das Log:
018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - -------- New selection ---------
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Command: countEntries history
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Timestamp begin human readable: 2018-10-06 18:51:10
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Time difference to current time for calculating Timestamp end: 86400 sec
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Timestamp end human readable: 2018-10-09 07:05:29
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - Aggregation: no
2018.10.10 07:05:29 4: DbRep db_g8_var_Z1 - SQL execute: SELECT COUNT(*) FROM history where DEVICE = 'var_Z1' AND TIMESTAMP >= '2018-10-06 18:51:10' AND TIMESTAMP <= '2018-10-09 07:05:29' ;


und hier die DEF:

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        myDbLog
   LASTCMD    countEntries history
   MODEL      Client
   NAME       db_g8_var_Z1
   NOTIFYDEV  global,db_g8_var_Z1
   NR         627
   NTFY_ORDER 50-db_g8_var_Z1
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   VERSION    8.2.1
   HELPER:
     DBLOGDEVICE myDbLog
     MINTS      2018-10-06 18:51:10
     RDPFDEL    .*
     SQLHIST   
     CV:
       aggregation no
       aggsec     1
       destr      2018-10-09
       dsstr      2018-10-06
       epoch_seconds_end 1539061529.34278
       mestr      10
       msstr      10
       testr      07:05:29
       tsstr      18:51:10
       wdadd      172800
       yestr      2018
       ysstr      2018
   READINGS:
     2018-10-10 07:05:29   2018-10-06__var_Z1__/__COUNT_history__no_aggregation 1455
     2018-10-10 06:59:12   __var_Z1__/__COUNT_history__no_aggregation 115242
     2018-10-10 07:05:29   state           done
     2018-10-10 07:05:29   timeOlderThan_days 1
   dbloghash:
     CFGFN     
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION /etc/fhem/db.conf
     DEF        /etc/fhem/db.conf .*:.*
     MODE       synchronous
     MODEL      MYSQL
     NAME       myDbLog
     NR         52
     NTFY_ORDER 50-myDbLog
     PID        11514
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     UTF8       0
     VERSION    3.12.2
     dbconn     mysql:database=fhem;host=192.168.1.212;port=3306
     dbuser     fhemuser
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     Helper:
       DBLOG:
         countCurrent:
           myDbLog:
             TIME       1539122581.47579
             VALUE      1089
         countHistory:
           myDbLog:
             TIME       1539122581.42609
             VALUE      1639384
         state:
           myDbLog:
             TIME       1539104596.32857
             VALUE      connected
     READINGS:
       2018-10-10 00:03:01   countCurrent    1089
       2018-10-10 00:03:01   countHistory    1639384
       2018-07-21 00:03:40   lastRowsDeleted 87785
       2018-10-10 07:07:42   state           connected
     cache:
       index      0
Attributes:
   DbLogExclude .*
   allowDeletion 0
   device     var_Z1
   group      DB-Delete-G8
   readingPreventFromDel .*
   room       50-DBRep
   timeOlderThan 86400
   userReadings timeOlderThan_days {AttrVal($NAME,"timeOlderThan","0") / 3600 / 24 ;}
   userattr   dbRepDel
   verbose    4


Das userattr dbRepDel ist aktuell noch nicht belegt.....
Was ich gerade bemerke:  Das Reading zählt(?)  vom 6.10.18, an diesem Tag habe ich das Device angelegt.... Die ältesten Einträge in der DB sind vom März 2018...
Danke.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Oktober 2018, 08:23:30
Das sieht doch erstmal völlig in Ordnung aus. Es werden über 1Mio Einträge gezählt.
EDIT: habe gerade gesehen dass diese Zahl der Wert aus dblog ist.

Das die Selektion am 06.10. beginnt liegt daran, dass beim Start der älteste in der DB vorhandene Datensatz ermittelt wird. Und der ist augenscheinlich mit dem Timestamp MINTS = 2018-10-06 18:51:10.


   HELPER:
     DBLOGDEVICE myDbLog
     MINTS      2018-10-06 18:51:10


Führe mal bitte ein "get ... minTimestamp" aus. Was zeigt dann das Reading "timestamp_oldest_dataset" ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Oktober 2018, 10:27:11
Und bitte auch noch ausführen


set dbrep sqlCmd select TIMESTAMP from history order by TIMESTAMP limit 1;


was steht dann im Reading SqlResultRow_1?

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 10 Oktober 2018, 11:11:55
Wurden die Timestamp-Werte nachträglich bearbeitet, oder ggf. später welche importiert?
In diesem Fall kann eine Abfrage ohne "order by", also nur
set dbrep sqlCmd select TIMESTAMP from history limit 1;
ein anderes Ergebnis liefern.

Bleibt also die Entscheidung, ob man die Datenbank nach einem Ändern mal "neu sortiert" und
die schnelle Abfrage
select TIMESTAMP from history limit 1; belässt oder eben die sichere Abfrage
mit "order by" nimmt..


sG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Oktober 2018, 11:21:20
Hi Joe,

ich tendiere dazu order by mit hinzuzufügen.
Warten wir die Info von oldscout mal ab, es ist der erste Fall dieser Art.
Aber meine Vermutung ging auch in die von dir beschriebenen e Richtung.

Lg
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Oktober 2018, 18:16:41
Bin jetzt schon mal prophylaktisch auf die sichere Seite gewechselt und habe im Modul die Abfrage um "order by" ergänzt.
Das ist sicherer und vermeidet proaktiv Probleme, unabhängig davon was oldscout  noch berichten wird.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 11 Oktober 2018, 06:55:42
Hallo,
also nachträglich wurde nichts importiert.
Hier das Reading:
timestamp_oldest_dataset   2018-10-06 19:55:52
das ist m.E. falsch, das älteste Datum für dieses Device ist der 23.3.18 laut MySQL Workbench.

set dbrep sqlCmd select TIMESTAMP from history limit 1; ergibt: auch den 6.10.18, im Workbench jedoch 23.3.18

Ich mache wöchentlich ein configdb reorg, das war auch am 6.10.18 das letzte Mail.

Mich irritiert die Zeile:
SQL execute: SELECT COUNT(*) FROM history where DEVICE = 'var_Z1' AND TIMESTAMP >= '2018-10-06 18:51:10' AND TIMESTAMP <= '2018-10-09 07:05:29' ;

Ich  habe doch nur das Attribut timeOlder Than gesetzt und trotzdem gibt es die Zeitspanne von bis ??

Heute früh:
ich habe nochmal ein neues DBrep Device angelegt, gleiches device im Attribut, folgender Fehler kommt:

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

Die bereits angelegten Devices mit DbRep funktionieren aber noch!!!

Ist das ev. die Ursache??

Dieser Fehler kommt auch in der Modulversion 17377 vom 20.9.18

Habe eben auch nochmal ein bereits definiertes Device gecheckt:
Sobald timeOlderThan gesetzt ist, wird falsch gezählt, ist das Attribut gelöscht stimmt der Zähler mit Workbench überein.

Gruß




Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 Oktober 2018, 08:06:17
Servus,

Zitat von: oldscout am 11 Oktober 2018, 06:55:42
set dbrep sqlCmd select TIMESTAMP from history limit 1; ergibt: auch den 6.10.18, im Workbench jedoch 23.3.18

Es fehlt das Ergebnis von
set dbrep sqlCmd select TIMESTAMP from history order by timestamp limit 1;
Kannst Du das bitte noch schicken?

configDb ist eine andere Datenbank, also unabhängig.


sG Joe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 13:01:54
ZitatHeute früh:
ich habe nochmal ein neues DBrep Device angelegt, gleiches device im Attribut, folgender Fehler kommt:

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

Die bereits angelegten Devices mit DbRep funktionieren aber noch!!!

Ist das ev. die Ursache??

Nein, das sind zwei paar Schuhe.
Dieser Fehler kommt wenn das DbLog Device noch nicht geladen ist, aber schon dbrep. die startreihenfolge wird normalerweise durch die fhem.cfg vorgegeben. Ich weiss nicht wie configdb dies sicherstellt.
Insbesondere wenn ein configdb reorg durchgeführt wird.
Allerdings gibt es mir zu denken dass der letzte reorg genau auf dieses datum fällt. Benutzt configdb dieselbe Datenbank (andere Tabellen natürlich) ?
Ich werde versuchen dbrep unempfindlich gegenüber diesem problem zu machen, wobei es nur ein hilfreicher workaround sein kann ... die startreihenfolge sollte eingehalten werden.

EDIT: das gleiche Problem tritt auf wenn man sich bei der Angabe des DbLog Device im DEF verschreibt. Bitte nochmal checken !

ZitatHabe eben auch nochmal ein bereits definiertes Device gecheckt:
Sobald timeOlderThan gesetzt ist, wird falsch gezählt, ist das Attribut gelöscht stimmt der Zähler mit Workbench überein.
Das hängt mit der falschen Ermittlung des min timestamps zusammen.

deswegen bitte das Statement ausführen wie von Joe geschrieben und das Ergebnis posten !

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 11 Oktober 2018, 15:16:56
Hallo,
hier das Ergebnis von
set dbrep sqlCmd select TIMESTAMP from history order by timestamp limit 1;

SQLResultRow_1: 2018-03-23 00:00:13

Entspricht also dem Datum von der Workbench.

Danke für Eure Unterstützung bisher.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 15:22:15
Das entspricht jetzt meinen Erwartungen.
Ich hatte die Erweiterung bereits ins Modul eingebaut und eingecheckt. Wenn du jetzt ein update machen würdest, wäre dieses problem und deine fehlerhaften Zählungen beseitigt.

Sag mal Bescheid ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 11 Oktober 2018, 15:56:39
Hallo,
es funktionert wieder, auch andere bereits definierte zählen bzw. löschen wieder korrekt. Die Initialisierung nach dem Neustart dauert aber nun wesentlich länger.... aber damit kann man sicher leben.
Was aber nach wie vor noch nicht geht, ist die Neuanlage eines DbRep-Devices wie schon beschrieben.
Frage nebenbei: wird die fhem.cfg noch benutzt obwohl fhem auf DBLog umgestellt ist?
Bezug hierauf:
ZitatNein, das sind zwei paar Schuhe.
Dieser Fehler kommt wenn das DbLog Device noch nicht geladen ist, aber schon dbrep. die startreihenfolge wird normalerweise durch die fhem.cfg vorgegeben. Ich weiss nicht wie configdb dies sicherstellt.
Danke.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 Oktober 2018, 16:05:43
Heiko, reicht es nicht, beim Start der Aktion den ältesten Datensatz zu ermitteln, und nicht schon  beim Start von FHEM?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 16:06:37
Ja, die Initialisierung beim Neustart war eigentlich der Grund weshalb ich das Statement mal abgeändert hatte, aber hier geht Zuverlässigkeit vor Schnelligkeit. Ist ja ohnehin non-blocking.

Sehr schön ...

ZitatFrage nebenbei: wird die fhem.cfg noch benutzt obwohl fhem auf DBLog umgestellt ist?
Dblog hat damit nichts zu tun. du meinst sicherlich configdb. dann wird die fhem.cfg nicht mehr genutzt.

Wegen der Neuanlage ... funktioniert denn das Kopieren eines dbrep auf ein neues ?
Trotz des Fehlers wird das device angelegt ?
ist die im DEF benannte DbLog Device online ?


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 16:12:36
ZitatHeiko, reicht es nicht, beim Start der Aktion den ältesten Datensatz zu ermitteln, und nicht schon  beim Start von FHEM

Leider ist das modultechnisch nicht umsetzbar ohne komplexe umbauten vornehmen zu müssen. Andere Variante wäre wieder auf meine ursprüngliche Verwendung der festen Größe 1970 als Start zurück zu gehen. Und das ist/war aus anderen Gründen wieder ungünstig.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 16:25:38
@Joe, was ich mir allerdings vorstellen könnte ist ein, sagen wir Qickstart Attribut anzubieten, weches der Advanced User verwenden kann.

Habe noch etwas recherchiert ... allgemein wird empfohlen auf min() statt auf "order by" zu gehen bzgl. der Performance.
Das werdecich dann nochmal anpassen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: JoeALLb am 11 Oktober 2018, 16:54:59
Oder eine Art Funktion, die "reload cache" heist, und dabei den minimalen Timestamp erneut ermittelt. das könnte dann ja in ein internal oder vielleicht auch in ein Attribut geschrieben werden. Bei einem define könnte dieser Wert ja auch einmalig erzeugt werden, oder?
Würde es Sinn machen, wenn diese Funktion auch andere Daten vorab cached? zB die Datenbanksettings?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 17:02:55
So eine Funktion gibt es intern ja schon und der min timestamp wird in einen helper geschrieben und immer wieder verwendet. diese funktion wird auch beim get minTimestamp aufgerufen, was deinem reload cache entsprechen würde.
Und du hast recht, die Speicherung anderer db-werte wie Spaltenbreite etc. habe ich schon auf meiner todo.  ;)

Hmm ... müssen wir nochmal drüber nachdenken.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 18:20:54
Als ich jetzt nach Hause gefahren bin, kam mir doch noch eine Idee wie ich vielleicht die Ermittlung des MinTS von der Startsequenz entkoppeln könnte und dabei noch die Vorraussetzungen für die weiteren Ziele schaffen könnte.  ;)

Ich programmiere mal etwas und dann schauen wir uns das an ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 11 Oktober 2018, 18:26:40
Hallo,
kopieren eines dbRep Dev funktioniert.
Bei der Neuanlage kommt erst initialized, sobald das device attribut gesetzt wird kommt der Fehler.
Gruss
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Oktober 2018, 19:14:13
Zitatsobald das device attribut gesetzt ....

Das Attribut "device" ... wirklich ? 
Habe ich bei mir gemacht und funktioniert einwandfrei.

Mach mir mal bitte ein list von einem neuen initial angelegten DbRep-Device.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 12 Oktober 2018, 06:48:35
Hallo,
hier bitte schön:
Internals:
   CFGFN     
   DATABASE   
   LASTCMD     
   MODEL      Client
   NAME       test
   NOTIFYDEV  global,test
   NR         10079
   NTFY_ORDER 50-test
   ROLE       Client
   STATE      initialized
   TYPE       DbRep
   UTF8       0
   VERSION    8.2.2
   HELPER:
     DBLOGDEVICE
     SQLHIST   
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1539319636.3901
           VALUE      initialized
   READINGS:
     2018-10-12 06:47:16   state           initialized
   dbloghash:
     HELPER:
Attributes:


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Oktober 2018, 09:29:18
Das DbLog Device myDbLog ist nicht connected und nur initialized. DbLog muss auf connected stehen wenn alles in Ordnung wäre.
Kannst du bitte noch ein list von myDbLog liefern und auch das define mit dem du test angelegt hattest ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 12 Oktober 2018, 10:38:06
Hallo,
ich verzieh mich in die äusserste Ecke.......
ich habe beim Define die DbLog Instanz versäumt anzugeben......
bisher habe ich die Devs immer nur kopiert....... und da gings natürlich..... was mich hier geritten hat, das mal von "Null" zu machen.....

Sorry, meine Dummheit.

Danke aber bei der Lösung des anderen Problems mit der Zählerei.
Schönes WE.
Gruss
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Oktober 2018, 11:42:27
Alles klar  :)
Aber ich muss diesen Fehler abfangen, damit sowas nicht vorkommen kann.

Ebenfalls ein schönes WE,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maci am 15 Oktober 2018, 19:48:16
Ich habe zwar schon etwas mitgelesen bei dem langen Thread. Aber was ich nicht finden konnte:
Ist es mit dem Modul möglich, Werte aus der Datenbank zu lesen und diese in einem Dummy auszugeben.

Ich frage nur nach, weil ich überlege, meinen 2. Fhem Server ebenfalls in die DBLog am Hauptserver einzubinden.

Oder bin ich da am falschem Dampfer?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Oktober 2018, 19:59:30
Ja, das geht mit verschiedenen Möglichkeiten.
Im Wiki steht eine davon

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Reading_von_DbRep_nach_Dummy_.C3.BCbertragen

Du kannst auch mit der userExitFn arbeiten. Das ist zugegeben etwas advanced weil etwas Programmierung nötig ist. Aber dafür sehr flexibel.
Gibt bestimmt noch mehr ...

Aber vllt. umreisst du dein Szenario kurz was du vorhast, möglicherweise geht alles einfacher.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maci am 17 Oktober 2018, 08:20:53
Hallo Heiko,

Ich werde mir zuerst nochmals das Wiki zu Gemüte führen.

Das was ich vorhabe, ist einfach erklärt.

Ich habe 2 Fhem Instanzen.
Derzeit logge ich die 2. Instanz über Fhem2Fhem. Doch habe ich Probleme damit. Da meine 2. Instanz nicht immer online ist. Diese ist offline wenn ich diese Dienste nicht benötige.
Nun hängt sich meine Hauptinstanz immer auf, wenn ich die 2. Instanz wieder starte. Da hier dann Fhem hier glaubt der Port 7072 ist schon belegt.

Mir kommt es einfach einfacher vor, die benötigten Werte in der Hauptinstanz aus der Log DB wieder zu holen und auszugeben. Es geht immer nur um Infos ob ein Gerät on oder off ist. Die Temperaturwerte hole ich mir immer direkt aus dem OWserver.
Wobei es auch sein kann, dass ich später auch noch andere Werte holen will.

Gesteuert wird die 2. Instanz nicht aus der Hauptinstanz. Ich brauche eben nur Infos.

Gruß
Georg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Oktober 2018, 09:08:07
Morgen Georg,

in dem Fall fällt mir noch etwas ein. Sobald du ein dbrep device definiert hast, steht die Funktion

DbReadingsVal("<name>","<device:reading>","<timestamp>","<default>")

Zur Verfügung. Gleich am Anfang der Hilfe von dbrep gibt es weitere Erläuterungen und Beispiel dazu.
Damit kannst du dir immer den aktuellsten Wert deines device/readings aus der db holen und einen dummy setzen oder was auch immer. Als timestamp nimmst du einfach die aktuelle zeit mit Formatumwandlung wie die Funktion es benötigt.
Die Funktion ist blockierend, d.h. du musst mal schauen ob die Geschwindigkeit für dein System passt.
Aber ansonsten wahrscheinlich genau was du verwenden könntest.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maci am 17 Oktober 2018, 15:32:21
Danke Heiko,

Das werde ich mir gleich, wenn ich wieder zu Hause bin ansehen.
Werde berichten

Gruß
Georg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Oktober 2018, 16:50:12
Hallo zusammen,

ich habe eine neue Version nach contrib geladen. Ihr könnt sie euch hier herunterladen und testen:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

In dieser Version ist reduceLog aus DbLog integriert und an die Arbeitsweise von DbRep angepasst worden. Die Aufrufsyntax hat sich verändert. Unten habe ich die neue Commandref dazu eingefügt.
Obwohl das Kommando nur reduceLog heißt, arbeitet es selbstverständlich non-blocking. Da alle Funktionen in DbRep (bis auf Ausnahmen) non-blocking arbieten, konnte ich auf den Zusatz "Nbl" verzichten.

Weiterhin ist das set sqlCmd per default ein longtext-Feld, d.h. es geht ein entsprechendes Editorfenster auf. Das ist einfach viel freundlicher wenn man umfangreiche SQL-Statements einfügen will. Die Attribute "timeOlderThan" und "timeDiffToNow" können nun gemeinsam verwendet werden um Zeitabschnitte dynamisiert verwenden zu können.

Hier die Commandref zu reduceLog:

* reduceLog [average[=day]] [exclude=device1:reading1,device2:reading2,...] [include=device:reading]
Reduziert historische Datensätze innerhalb der durch die "time.*"-Attribute bestimmten Zeitgrenzen auf einen Eintrag (den ersten) pro Stunde je Device & Reading.
Es muss mindestens eines der "time.*"-Attribute gesetzt sein (siehe Tabelle unten). Die jeweils fehlende Zeitabgrenzung wird in diesem Fall durch das Modul errechnet.

Die für diese Funktion relevanten Attribute sind:

    executeBeforeProc    : FHEM Kommando (oder perl-Routine) vor dem Export ausführen
    executeAfterProc    : FHEM Kommando (oder perl-Routine) nach dem Export ausführen
    timeOlderThan    : es werden Datenbankeinträge älter als dieses Attribut reduziert
    timestamp_end    : es werden Datenbankeinträge älter als dieses Attribut reduziert
    timeDiffToNow    : es werden Datenbankeinträge neuer als dieses Attribut reduziert
    timestamp_begin    : es werden Datenbankeinträge neuer als dieses Attribut reduziert


Das Reading "reduceLogState" enthält das Ausführungsergebnis des letzten reduceLog-Befehls.

Durch die optionale Angabe von 'average' wird nicht nur die Datenbank bereinigt, sondern alle numerischen Werte einer Stunde werden auf einen einzigen Mittelwert reduziert.
Durch die optionale Angabe von 'average=day' wird nicht nur die Datenbank bereinigt, sondern alle numerischen Werte eines Tages auf einen einzigen Mittelwert reduziert. (impliziert 'average')

Optional kann als letzer Parameter "exclude=device1:reading1,device2:reading2,...." angegeben werden um device/reading Kombinationen von reduceLog auszuschließen.
Tipp: Wird "exclude=.*:.*" angegeben, wird nichts in der Datenbank gelöscht. Das kann z.B. verwendet werden um vorab die gesetzten Zeitgrenzen und die Anzahl der zu bearbeitenden Datenbankeinträge zu checken.

Optional kann als letzer Parameter "include=device:reading" angegeben werden um die auf die Datenbank ausgeführte SELECT-Abfrage einzugrenzen, was die RAM-Belastung verringert und die Performance erhöht.

    Beispiel:

    attr <name> timeOlderThan = d:200
    set <name> reduceLog
    # Datensätze die älter als 200 Tage sind, werden auf den ersten Eintrag pro Stunde je Device & Reading reduziert.

    attr <name> timeDiffToNow = d:10
    attr <name> timeOlderThan = d:5
    set <name> reduceLog average include=Luftdaten_remote:%
    # Datensätze die älter als 5 und neuer als 10 Tage sind, werden bereinigt. Numerische Werte einer Stunde werden auf einen    Mittelwert reduziert

Feedback ist wie immer sehr willkommen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Oktober 2018, 22:05:47
@Georg, ich habe den Wiki-Artikel zur Dummy-Verwendung komplett überarbeitet und ergänzt:

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Readingwerte_von_DbRep_nach_Dummy_.C3.BCbertragen

Damit sollte es dir leichter fallen dein Szenario umzusetzen.
Bei Fragen einfach fragen  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2018, 08:51:54
Hallo zusammen,

wie von oldscout hier https://forum.fhem.de/index.php/topic,92038.0.html#msg845814 (https://forum.fhem.de/index.php/topic,92038.0.html#msg845814) requestet, habe ich die countEntries Funktion so umgebaut, dass sofern mehr als ein Reading im Attribut "reading" angegeben ist, die Anzahl jedes einzelnen Readings und zusaätzlich die Summary aller angegebenen Readings gezählt und ausgegeben wird. Dies erfolgt für jedes Zeitintervall falls aggregation gesetzt ist.

Download erstmal aus contrib hier:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Danke für die Anregung oldscout ! Das ist ein echter Mehrwert für das Modul und den Anwender wie ich finde.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2018, 20:47:59
Ich habe die countEntries-Funktion nochmal dahin abgeändert, dass man die detaillierte count-Readings Ausgabe mit dem neuen Attribut "countEntriesDetail" einschalten kann. Sonst wird nur die Summary wie bisher ausgegeben. Ich hatte festgestellt dass man sonst eine u.U. sehr lange Liste bekommt wenn man alle EInträge in der DB zählt.

Zitat aus Commandref:

Zitat
...
Standardmäßig wird die Summe aller Datensätze, gekennzeichnet mit "ALLREADINGS", erstellt. Ist das Attribut "countEntriesDetail" gesetzt, wird die Anzahl jedes einzelnen Readings zusätzlich ausgegeben.
....

Grüße
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Oktober 2018, 22:29:25
Die Version 8.4.0 ist eingecheckt und morgen früh per update verfügbar.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Oktober 2018, 09:14:47
Guten Morgen,

ich habe meine To-Do Liste etwas weiter abgearbeitet und ein Feature eingebaut um Datensätze mit devices/readings nicht nur einschließen, sondern explizit ausschließen zu können.
Die Anforderung geht zurück auf diesen Beitrag von der-pw: https://forum.fhem.de/index.php/topic,91357.msg838605.html#msg838605

Dadurch erweitert sich die Syntax der Attribute device/reading:

* device - Abgrenzung der DB-Selektionen auf ein bestimmtes oder mehrere Devices.
Es können Geräte-Spezifikationen (devspec) angegeben werden.
Innerhalb von Geräte-Spezifikationen wird SQL-Wildcard (%) als normales ASCII-Zeichen gewertet. Die Devicenamen werden vor der Selektion aus der Geräte-Spezifikationen und den aktuell in FHEM vorhandenen Devices abgeleitet.
Wird dem Device bzw. der Device-Liste oder Geräte-Spezifikation ein "EXCLUDE=" vorangestellt, werden diese Devices von der Selektion ausgeschlossen.

    Beispiele:
    attr <name> device TYPE=DbRep
    attr <name> device MySTP_5000
    attr <name> device SMA.*,MySTP.*
    attr <name> device SMA_Energymeter,MySTP_5000
    attr <name> device %5000
    attr <name> device TYPE=SSCam EXCLUDE=SDS1_SVS
    attr <name> device EXCLUDE=SDS1_SVS
    attr <name> device EXCLUDE=TYPE=SSCam


* reading - Abgrenzung der DB-Selektionen auf ein bestimmtes oder mehrere Readings sowie exkludieren von Readings. Mehrere Readings werden als Komma separierte Liste angegeben.
SQL Wildcard (%) wird in einer Liste als normales ASCII-Zeichen gewertet.
Wird dem Reading bzw. der Reading-Liste ein "EXCLUDE=" vorangestellt, werden diese Readings von der Selektion ausgeschlossen.

    Beispiele:
    attr <name> reading etotal
    attr <name> reading et%
    attr <name> reading etotal,etoday
    attr <name> reading etotal,etoday EXCLUDE=state
    attr <name> reading etotal,etoday EXCLUDE=Einspeisung%


Download erstmal aus contrib hier:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Oktober 2018, 00:06:42
Die Version 8.6.0 mit den beschriebenen Erweiterungen und weiteren Verbesserungen in reduceLog ist eingecheckt.
Bitte in commandref nachlesen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 November 2018, 19:25:54
Im contrib Verzeichnis

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

gibt es eine neue DbRep-Version.
In dieser Version habe ich das Attribut "valueFilter", was es ja schon einige Zeit gibt, auch für die folgenden Funktionen verfügbar gemacht:

averageValue, changeValue, countEntries, delEntries,delSeqDoublets, diffValue, exportToFile, fetchrows, maxValue, minValue, reduceLog, sumValue, syncStandby

Der in valueFilter gesetzte Wert wird als REGEXP auf das DB-Feld "VALUE" angewendet und kann dazu dienen, zusätzlich zu den vorhandenen Möglichkeiten die Auswahl der Datensätze hinsichtlich ihres im Feld VALUE enthaltenen Wertes einzuschränken.
Welche regulären Ausdrücke das jeweilige Datenbanksystem verwenden kann, ist der REGEXP-Doku des jeweiligen DB-Systems zu entnehmen.
Für MariaDB kann man sie z.B. hier lesen: https://mariadb.com/kb/en/library/regular-expressions-overview/

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 November 2018, 20:44:43
Hallo zusammen,

ich habe noch etwas weiter am Modul gearbeitet und das Attribut "fastStart" implementiert.
Was es bewirkt:

* fastStart -
Normalerweise verbindet sich jedes DbRep-Device beim FHEM-Start kurz mit seiner Datenbank um benötigte Informationen abzurufen und das Reading "state" springt bei Erfolg auf "connected". Ist dieses Attribut gesetzt, erfolgt die initiale Datenbankverbindung erst dann wenn das DbRep-Device sein erstes Kommando ausführt.
Das Reading "state" verbleibt nach FHEM-Start solange im Status "initialized". Diese Einstellung kann hilfreich sein wenn viele DbRep-Devices definiert sind.

Liegt im contrib-Verzeichnis.

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 November 2018, 22:36:06
Version 8.8.0 ist eingecheckt und morgen früh per update verfügbar.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 November 2018, 15:20:03
Hallo zusammen,

ist zwar momentan eher ein Monolog hier  ;) , aber ich möchte euch darüber informieren, dass im contrib Verzeichnis eine neue Version von DbRep liegt
in der ich einen Befehl zur Datenbankbereinigung doppelter (bzw. mehrfacher) Datensätze implementiert habe.

* delDoublets [adviceDelete | delete] - zeigt bzw. löscht doppelte / mehrfach vorkommende Datensätze. Dazu wird Timestamp, Device,Reading und Value ausgewertet.
Die Attribute zur Aggregation,Zeit-,Device- und Reading-Abgrenzung werden dabei berücksichtigt. Ist das Attribut "aggregation" nicht oder auf "no" gesetzt, wird im Standard die Aggregation "day" verwendet.

    adviceDelete    : ermittelt die zu löschenden Datensätze (es wird nichts gelöscht !)
    delete    : löscht die Dubletten


Aus Sicherheitsgründen muss das Attribut "allowDeletion" für die "delete" Option gesetzt sein.
Die Anzahl der anzuzeigenden Datensätze des Kommandos "delDoublets adviceDelete" ist zunächst begrenzt (default 1000) und kann durch das Attribut "limit" angepasst werden. Die Einstellung von "limit" hat keinen Einfluss auf die "delDoublets delete" Funktion, sondern beeinflusst NUR die Anzeige der Daten.
Vor und nach der Ausführung von "delDoublets" kann ein FHEM-Kommando bzw. Perl-Routine ausgeführt werden. (siehe Attribute "executeBeforeProc", "executeAfterProc")

    Beispiel:

    Ausgabe der zu löschenden Records inklusive der Anzahl mit "delDoublets adviceDelete":

    2018-11-07_14-11-38__Dum.Energy__T 260.9_|_2
    2018-11-07_14-12-37__Dum.Energy__T 260.9_|_2
    2018-11-07_14-15-38__Dum.Energy__T 264.0_|_2
    2018-11-07_14-16-37__Dum.Energy__T 264.0_|_2

    Im Werteteil der erzeugten Readings wird nach "_|_" die Anzahl der entsprechenden Datensätze ausgegeben, die mit "delDoublets delete" gelöscht werden.


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: MarkusN am 16 November 2018, 09:22:53
Um deinen Monolog mal ein bisschen zu unterbrechen  ;D

Ich habe diverse Zähler (Gas, Strom) bei denen ich den aktuellen Tagesverbrauch in eine MySQL DB logge (Module GasCalculator/ElectricityCalculator). Dieser Verbrauch wird jede Nacht zurückgesetzt. Genau genommen interessieren mich hierbei nur die jeweils höchsten Werte pro Tag, alles andere ist eigentlich nur Ballast. Ermöglicht mir dieses Modul alle anderen Werte außer die Tageshöchstwerte zu löschen?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 November 2018, 10:05:48
 :D

Grundsätzlich kann ich deine Frage bejahen.
Erste Möglichkeit die mir einfällt ... man überlegt sich ein schlaues SQL Statement was diese Aufgabe erfüllt und lässt es regelmäßig mit sqlCmd laufen.

Mit den zur Zeit eingebauten Möglichkeiten könntest du auch so vorgehen:

- Attribute device, reading und die Zeitabgrenzung timeDiffToNow = d:3, aggregation = day setzen
- set ... maxValue writeToDB ausführen

Dadurch wird mit jedem Lauf der Tages-Maximalwert des betrachteten Readings mit einem neuen Readingnamen in die DB geschrieben. Betrachtet werden bei jedem Lauf die letzten 3 Tage.
Die neuen Readings kannst du dann in Diagrammen darstellen etc.

Und wenn alles so ist wie du dir es wünscht kannst du mit delEntries alle Originalreadings löschen die älter sind als 3 Tage. Das machst du dann mit einem anderen DbRep Device was entsprechend eingestellt ist.
Ist also auch so möglich vorzugehen.

Vielleicht nehme ich eine solche Funktion noch mit als sqlSpecial auf.  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 16 November 2018, 17:37:09
Zitat von: DS_Starter am 09 November 2018, 15:20:03
ich möchte euch darüber informieren, dass im contrib Verzeichnis eine neue Version von DbRep liegt
in der ich einen Befehl zur Datenbankbereinigung doppelter (bzw. mehrfacher) Datensätze implementiert habe.

* delDoublets [adviceDelete | delete] - zeigt bzw. löscht doppelte / mehrfach vorkommende Datensätze. Dazu wird Timestamp, Device,Reading und Value ausgewertet.
Was ist denn der Unterschied zu
set DbLogRep delSeqDoublets delete
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 November 2018, 08:32:58
Guten Morgen,

Zitat
Was ist denn der Unterschied zu
Code: [Auswählen]

set DbLogRep delSeqDoublets delete

Hinter delSeqDoublets  steckt eine andere Logik. Bei dieser Funktion werden nicht nur echte Dubletten (also Datensätze mit identischen Werten in den Feldern TIMESTAMP,DEVICE,READING,VALUE) gelöscht, sondern es werden auch die nachfolgenden Datensätze mit den Werten in DEVICE,READING,VALUE geprüft und bei Gleichheit gelöscht. Wenn du in der Commandref schaust ist die Funktionslogik genau beschrieben.

Die Funktion delDoublets löscht tatsächlich nur echte Dubletten.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: topa_LE am 10 Dezember 2018, 09:05:01
Guten Morgen,

hab das nun auch mal umgesetzt dbRep zu nutzen.

Folgendes möchte ich machen:

die current mit AT und Notify automatisch löschen und aus der history Daten in die leere current auffüllen.

Alles eingerichtet, nach dem Wiki:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#d.29_Arbeitsweise_und_Raw-Definitionen

vor erst zum Testen manuell mit:
set Rep_FillCurr_fhem tableCurrentPurge

die current geleert, das klappt.

Möchte ich nun mit:
set Rep_FillCurr_fhem tableCurrentFillup
die leere current Table mit Werten aus der history neu befüllen, fehlen mir die Type,Events,Value und Unit.

Nur die Device und Readings werden in die current geschrieben.

Wo liegt mein Fehler?
 



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: topa_LE am 10 Dezember 2018, 09:13:07
Noch die Define:


defmod Rep_FillCurr_fhem DbRep DBLogging
attr Rep_FillCurr_fhem DbLogExclude .*
attr Rep_FillCurr_fhem alias [current] Tabelle erneuern FHEM DB
attr Rep_FillCurr_fhem allowDeletion 1
attr Rep_FillCurr_fhem devStateIcon connected:10px-kreis-gruen .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep_FillCurr_fhem event-on-update-reading state,--DELETED_ROWS_CURRENT--
attr Rep_FillCurr_fhem group DB Current Table - Management
attr Rep_FillCurr_fhem icon database
attr Rep_FillCurr_fhem room Logging
attr Rep_FillCurr_fhem showproctime 1
attr Rep_FillCurr_fhem timeDiffToNow d:30
attr Rep_FillCurr_fhem verbose 3

setstate Rep_FillCurr_fhem done
setstate Rep_FillCurr_fhem 2018-12-10 08:52:02 background_processing_time 3.6404
setstate Rep_FillCurr_fhem 2018-12-10 08:52:02 number_lines_inserted 140
setstate Rep_FillCurr_fhem 2018-12-10 08:52:02 sql_processing_time 3.6066
setstate Rep_FillCurr_fhem 2018-12-10 08:52:02 state done
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2018, 10:05:04
ZitatNur die Device und Readings werden in die current geschrieben.

Wo liegt mein Fehler?
Es liegt kein Fehler vor. Works as designed.
Die Device / Reading Kombination benutzt du für die Auswahl im SVG Editor.
Wofür benötigst du die anderen Feldwerte ?

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: topa_LE am 10 Dezember 2018, 10:20:33
Hallo Heiko,

ok, das kein Fehler vorliegt und ich alles korrekt gemacht habe ich ja gut ...  :D

Naja die ursprüngliche current ist ja auch vollständig. Ich nutze keine SVG Plots sondern Grafana.

Gut eigentlich wollte ich die current immer aktuell halten und bei neuen devices die schon für dblog exclude eingestellt haben nicht nochmal in die current schreiben. Aber das ist nun nicht so tragisch.

Dann stell ich den Dblogtype: SampleFill/History wieder auf Current/History um. Unbedingt benötige brauche ich es ja nicht, dachte nur weil im Wiki steht, das aus der history die current gefüllt wird. Da geht man ja von aus, das die dann vollständig ist.

Ok, danke für die Aufklärung.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2018, 19:27:40
Hallo topa_LE,

jetzt habe ich mir dein Anliegen noch einmal durch den Kopf gehen lassen. Aber so richtig klar ist es mir noch nicht geworden.
Es wäre ja nicht so schwierig eine Funktion zu implementieren, die nicht nur die Device/Reading Kombinationen in die current schreibt, sondern zum Beispeil alle Datensätze der letzten x Tage um sie zur Auswertung aus der current zu lesen.

Aber es ist mir nicht klar geworden warum du die current nutzen willst und nicht die Daten in der history Tabelle was der Normalfall wäre ?

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: topa_LE am 12 Dezember 2018, 19:15:38
Hallo Heiko,

danke dir, dass du dir da Gedanken machst. ;-) Muss aber nicht sein.

Naja im Normalfall nutze ich auch meine history. Hab nur vor einiger Zeit dein Modul installiert, weil es einige nützliche Funktionen hat.

Da in meiner current trotz :

defmod n_DbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*
attr n_DbLogExclude DbLogExclude .*
attr n_DbLogExclude alias Für neue Geräte dbExclude setzen
attr n_DbLogExclude group Logging
attr n_DbLogExclude icon database
attr n_DbLogExclude room Logging


Defines dort listet, obwohl ich das nur per dbloginclude einzeln definiere, fand ich die Option, das die current regelmäßig bereinigt wird und danach sauber aus der history mit Begrenzungen (Tage) neu erstellt wird, einfach gut.

Grundsätzlich brauche ich die current nicht, da ich per Grafana alles aus der history lese.

Mich wunderte eben nur das geschriebene im Wiki etwas und verwirrte.
Das die current für SVG Auswahl grundsätzlich nur die Readings/Device benötigt, wusste ich nicht.

Stellt mir eben aber gerade die Frage, für was dann die Funktion der current Bereinigung ...  :-[

Im Normalfall (DbLogType=Current/History) ist ja die current auch komplett befüllt. Aber falls du das noch implementieren willst ok, für mich brauchste das aber nicht machen ;-)

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Dezember 2018, 19:38:00
Zitat
Mich wunderte eben nur das geschriebene im Wiki etwas und verwirrte.
Das die current für SVG Auswahl grundsätzlich nur die Readings/Device benötigt, wusste ich nicht.
Hatte ich allerdings geschrieben dass die current mit Device/Readings-Kombinationen aufgefüllt wird. Kommt vielleicht nicht so deutlich raus, ich besser nach ...

ZitatStellt mir eben aber gerade die Frage, für was dann die Funktion der current Bereinigung ...  :-[
Naja, dafür gibt es zwei Überlegungen.
Zum einen ist/war es oft so, dass sich in der current Kombinationen von Device/Readings wiederfinden die es vllt. nicht mehr gibt und weg können, auch Mehrfachvorkommen bzw. Redundanzen wurden genannt.
Andererseits will man vielleicht Plots von Werten erstellen die es als reales Gerät nicht mehr gibt, aber noch in der DB enthalten sind.
Man sich natürlich in allen Fällen manuell im Editor behelfen, aber diese Funktion gibt die Chance die current als Editorhilfe aktuell zu halten. Außerdem kann durch die Einstellung in DbLog das ständige (synchrone) Schreiben in die current vermieden werden falls man den asynchronen Modus nicht verwendet.

Naja, ich würde mir nur Arbeit für Erweiterungen machen wenn es dafür eine sinnvolle Verwendung gibt.  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: topa_LE am 12 Dezember 2018, 20:08:22
Ah ok, danke Dir. Hab's verstanden.

Nun gut, für mich persönlich wäre die "normale" Current Table nur von neuen Defines zu bereinigen, die ich nicht grundsätzlich loggen möchte. Dafür kann ich aber auch schnell die current manuell löschen.

Daher ist alles gut so. ;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 27 Dezember 2018, 18:39:46
Hi, ich habe ein Problem mit DbRep: nach dem Anlegen und dem Absetzen des Befehls countEntries (also die ersten Zeilen aus dem Wiki) erhalte ich den State "disconnected",
Log (verbose 5):
2018.12.27 18:10:01.849 3: DbRep test - WARNING - old process 8806 will be killed now to start a new BlockingCall
2018.12.27 18:10:01.866 1: DbRep test -> BlockingCall DbRep_getInitData pid:8806 Timeout: process terminated
2018.12.27 18:10:01.928 3: DbRep test - get initial structure information of database "fhem", remaining attempts: 3
2018.12.27 18:10:01.930 3: DbRep test - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2018.12.27 18:10:02.047 3: DbRep test - WARNING - old process 8855 will be killed now to start a new BlockingCall
2018.12.27 18:10:02.048 1: DbRep test -> BlockingCall DbRep_getInitData pid:8855 Timeout: process terminated
2018.12.27 18:10:02.121 3: DbRep test - get initial structure information of database "fhem", remaining attempts: 2
2018.12.27 18:10:02.123 3: DbRep test - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser

list:
Internals:
   CFGFN     
   DATABASE   fhem
   DEF        logdb
   LASTCMD    countEntries current
   MODEL      Client
   NAME       test
   NOTIFYDEV  global,test
   NR         83087
   NTFY_ORDER 50-test
   ROLE       Client
   STATE      disconnected
   TYPE       DbRep
   UTF8       1
   VERSION    8.9.6
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  1
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     RUNNING_PID:
       abortFn    DbRep_getInitDataAborted
       arg        test|countEntries|current|DbRep_Main
       bc_pid     3588
       finishFn   DbRep_getInitDataDone
       fn         DbRep_getInitData
       loglevel   5
       pid        8856
       telnet     telnetPort_127.0.0.1_58680
       timeout    120
       abortArg:
   READINGS:
     2018-12-27 18:10:02   errortext       Timeout: process terminated
     2018-12-27 18:10:02   state           disconnected
   dbloghash:
     COLUMNS    field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db_fhem.conf
     DEF        ./db_fhem.conf .*:.*
     MODE       asynchronous
     MODEL      MYSQL
     NAME       logdb
     NR         307
     NTFY_ORDER 50-logdb
     PID        654
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     UTF8       1
     VERSION    3.13.0
     dbconn     mysql:database=fhem;host=localhost;port=3306
     dbuser     fhemuser
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   0
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
     READINGS:
       2018-12-27 18:11:48   CacheUsage      12
       2018-12-27 18:11:42   NextSync        2018-12-27 18:12:12 or if CacheUsage 100 reached
       2018-01-30 17:16:35   lastCachefile   ./log/cache_logdb_2018-01-25_03-37-17 import successful
       2018-12-27 18:11:43   state           connected
     cache:
       index      159920
Attributes:
   verbose    5


Das LogDB-Device funktioniert einwandfrei, in selbst geschriebenen Routinen kann ich Werte aus der Datenbank abrufen.
Achso, die version ist noch interessant:
93_DbRep.pm            17773 2018-11-18 07:48:35Z DS_Starter

EDIT: ich hab grad das Update auf die aktuellste Version gemacht, was aber keine anderen Ergebnisse liefert.

Andere Abfragen funktionieren auch nicht. Weitere Datenbankzugriffe hab ich erstmal nicht getestet.
"Früher" gings mal, dann hab ichs jetzt länger nicht benutzt.
Achso, kann das an der Datenbank liegen? Diese hab ich nämlich .. neulich .. durch MariaDB ersetzt...
Das DbLog-Device funktioniert (soweit ich beurteilen kann) noch einwandfrei.
Wo kann ich noch suchen?
Soll ich besser nen eigenen Thread aufmachen?

Danke und Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Dezember 2018, 19:15:03
Hallo Stephan,

setze dir das Attribut "fastStart = 1" und Restart.

Vor einiger Zeit habe ich die Startroutine wegen noch kommender Weiterentwicklungen angepasst. Wenn der initiale Datenabruf zu lange dauert, kommt es zu dem Timeout.
An MariaDB an sich liegt es nicht. Kann aber sein, dass sich deine DB-Zeiten (ziemlich) erhöht haben ?
Das würdest du sehen wenn du dir im DbLog-Device das Attribut "showproctime = 1" setzt.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 27 Dezember 2018, 19:39:12
Hi,
danke für die schnelle Antwort.


restart = shutdown restart von fhem?

showproctime im DbLog:
background_processing_time 0.1267

Ist das zuviel?

Die Abfrage scheint trotz disconnect gelaufen zu sein, denn ich habe ein Ergebnis:
__/__ALLREADINGS__COUNT_history__no_aggregation 57910707

Danke und Grüße,

Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Dezember 2018, 19:50:32
Zitatrestart = shutdown restart von fhem?
Ja, genau. Dann zieht das fastStart.

Zitatshowproctime im DbLog:
background_processing_time 0.1267

Ist das zuviel?
No, das ist ok.

Vllt. nur ab und zu einen "Hänger" ? Schwer zu sagen jetzt.

Mit dem gesetzten Attribut geht dein DbRep nach dem Start erstmal auf "initialized". Erst wenn die erste Aktion gestartet wird, werden die Initialinfos abgerufen. Das Verfahren ist besonders hilfreich wenn man viele DbRep definiert hat, die sonst alle bei FHEM Start zur DB connecten wollen um ihre Infos abzurufen.
Deswegen hatte ich mit derV8.8.0 vom 06.11.2018 das fastStart implementiert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: vuffiraa am 05 Januar 2019, 20:05:51
Hallo,

ich habe auch ein Problem mit DbRep und der Funktion diffValues. Da ich meine Datenbank neu befüllen durfte, kommen bei einem Select die Einträge nicht mehr in der erwarteten Reihenfolge. Dadurch kommt dann auch die Funktion diffValues durcheinander.

Spricht etwas dagegen, im Modul in den Zeilen 3321 und 3323 den letzten (leeren) Parameter in 'ORDER BY TIMESTAMP' zu ändern?

Gruß VuffiRaa
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2019, 00:11:58
Hallo VuffiRaa,

auf den ersten Blick spricht da nichts dagegen. Ich schaue es mir am Vormittag genauer an und melde mich wieder.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2019, 07:56:19
Guten Morgen,

ich habe die gewünschte Änderung in diffValue noch etwas getestet und sieht für mich gut aus.
Werde im Laufe des Tages noch ein paar Vergleichsläufe beobachten, aber habe die geänderte Version 8.9.9 für nach contrib geladen:

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

und checke sie ein wenn mir nichts mehr auffallen sollte.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: vuffiraa am 06 Januar 2019, 17:33:35
Hallo Heiko,

danke für die prompte Bedienung  :)

Hab das geänderte Modul übernommen und jetzt entsprechen die Statistiken wieder meinen Erwartungen.

Gruß VuffiRaa
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2019, 18:16:55
Danke für die Info. Ist eingecheckt und morgen Früh im Regelupdate.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2019, 23:43:34
Hallo zusammen,

habe einen Vorschlag aus https://forum.fhem.de/index.php/topic,96056.msg892890.html#msg892890 umgesetzt.
DbRep ist so erweitert, dass man beim Export die Filegröße begenzen kann:

* exportToFile [</Pfad/File>] [MAXLINES=<lines>] - exportiert DB-Einträge im CSV-Format in den gegebenen Zeitgrenzen.

Der Dateiname wird durch das Attribut "expimpfile" bestimmt. Alternativ kann "/Pfad/File" als Kommando-Option angegeben werden und übersteuert ein eventuell gesetztes Attribut "expimpfile". Optional kann über den Parameter "MAXLINES" die maximale Anzahl von Datensätzen angegeben werden, die in ein File exportiert werden. In diesem Fall werden mehrere Files mit den Extensions "_part1", "_part2", "_part3" usw. erstellt (beim Import berücksichtigen !).
.........

Man kann die MAXLINES-Option sowohl im Kommando als auch im Attribut expimpfile verwenden.

Die Version 8.11.0 ist eingecheckt und morgen im Update.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 10 Februar 2019, 15:21:28
Hallo,
ich nutze mysql und dbrep.
Jedoch führt das Report-Define die executeAfterProc nicht aus, wenn das set seinerseits eine Report-Aktion startet.
im Beispiel unten wird nach Beendigung des sqlcmd das executeAfterProc "set Rep_HH_Tagesenergie_max maxValue writeToDB" nicht ausgeführt
Ist das so gewollt? MUSS das mit der Chain-Funktion oder über eine benutzerdefinierte Perl-Routine gelöst werden?

Viele Grüße,
Thowe

define Rep_HH_Tagesenergie_Corr DbRep DBLogging
attr Rep_HH_Tagesenergie_Corr timestamp_begin previous_day_begin
attr Rep_HH_Tagesenergie_Corr timestamp_end previous_day_end
attr Rep_HH_Tagesenergie_Corr executeAfterProc set Rep_HH_Tagesenergie_max maxValue writeToDB

define Rep_HH_Tagesenergie_max DbRep DBLogging
attr Rep_HH_Tagesenergie_max aggregation day
attr Rep_HH_Tagesenergie_max device HH_Tagesenergie
attr Rep_HH_Tagesenergie_max reading state
attr Rep_HH_Tagesenergie_max timestamp_begin previous_day_begin
attr Rep_HH_Tagesenergie_max timestamp_end previous_day_end

define Correct_Rep_HH_Tagesenergie_timestamp at *00:05:00 set Rep_HH_Tagesenergie_Corr sqlCmd UPDATE history SET timestamp = DATE_SUB(timestamp, INTERVAL (minute(timestamp)*60 + second(timestamp)+1) second) where TIMESTAMP >= §timestamp_end§ and device = 'HH_Tagesenergie' and value > '1.0'
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2019, 15:41:02
Hallo Thowe,

die executeAfterProc (executeBeforeProc) ist für sqlCmd noch nicht umgesetzt.
Ich kann das aber gern tun und stelle dir kurzfristig eine Version bereit die ich nach erfogreichem Test auch einschecke.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 10 Februar 2019, 16:21:58
Hallo Heiko,

sogar sonntags am Gerät?! :)
Ja, gerne. Ich habe allerdings auch die gleichen Probleme mit anderen dbrep-Funktionen, das executeAfterProc zu starten:
sumValue und maxValue

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2019, 16:34:56
Hi Thowe,

Zitatsogar sonntags am Gerät?! :)
Naja, gerade so mieses Wetter. Will heute aber noch ins Kino  ;)

Für die sqlCmd-Familie hab ich es umgesetzt und nach contrib geladen:

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

Wie üblich restart oder reload nach dem Download.
Schaue mir das für sumValue und maxValue auch noch an ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2019, 17:10:07
Für sumValue, maxValue, minValue und diffValue ist es nun auch umgesetzt und nach contrib geladen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 10 Februar 2019, 17:23:12
Hallo Heiko,

perfekt, mit V8.13.0  funktioniert executeAfterProc für alle umgesetzten Befehle, vielen Dank!!
Führt dbrep vor dem executeAfterProc noch ein commit aus, so dass eine DB-Änderung für den nachfolgenden Befehl immer wirksam ist?

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2019, 17:37:37
So und jetzt ist es noch für averageValue umgesetzt.  :)

ZitatFührt dbrep vor dem executeAfterProc noch ein commit aus, so dass eine DB-Änderung für den nachfolgenden Befehl immer wirksam ist?
Im Prinzip ja, implizit durch die finish/disconnect Befehle im Hintergrund wenn die session beendet wird.

EDIT: den zweiten Satz habe ich gelöscht, war Unfug  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2019, 17:48:38
Habe nachgeschaut und gesehen dass ich sogar ein commit explizit drin habe sofern kein Autocommit wirksam ist.
Also mit Sicherheit "Ja".
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ptr201711 am 11 Februar 2019, 16:00:14
Hallo,habe das Modul im Einsatz. Funktioniert auch.

Ich greife damit auf eine Nicht-FHEM-Datenbank zu z.B. mit "sqlCmd select summe from heizung.protokoll order by datum desc limit 1".

Es kommen auch richtige Werte zurück (in diesem Fall einer), der auch im Modul unter dem Reading SqlResultRow_1 angezeigt wird. Leider habe ich auf dieses Reading keinen Zugriff. Die Sequenz 'ReadingsVal("sql_conn","SqlResultRow_1","155")' gibt mir immer nur den Ersatzwert (155) zurück. "sql_conn" ist der Name meines Devices, das Reading hat den korrekten Wert 925.

Wenn ich den Wert nach FHEM logge steht in der Mysql-Datenbank folgendes:
2019-02-11 15:54:23 | sql_conn         | SqlResultRow_1         | 925       

Dies ist korrekt.                       |

Der Sinn dahinter ist folgender: Ich erfasse den Tanklevel meiner Öltanks von Hand und trage diese in eine von FHEM unabhängige Datenbank ein. Ich lese den letzten eingetragenen Wert zurück, was auch korrekt funktioniert. Nur leider lässt sich das Reading des DbRep devices nicht über FHEM greifen. Ich möchte dieses gern in einem Floorplan anzeigen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2019, 16:19:30
Hallo Peter,

Auf die Ergebnisreadings von DbRep zuzugreifen ist nicht so ohne weiteres wie bei anderen FHEM-Devices möglich. Der Grund ist die asynchrone Arbeitsweise.
Wenn unmittelbar nach Absetzen eines DbRep-Befehls versucht wird auf SqlResultRow_1 zuzugreifen, dann existiert es noch nicht, da es erst nach Vorliegen des Ergebnisses aus einem Parallelprozess erzeugt wird.

Vorschlag für eine Lösungsvariante ist, dass du dir einen Dummy erzeugst und den in deinem Floorplan zur Anzeige einbindest. In diesem Dummy kannst du dir ein Reading über ein Notify setzen. Diese Möglichkeit ist im Wiki hier beschrieben:

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Werte_mittels_Event_.C3.BCbetragen

Es gibt auch noch die Variante über die userExitFn (Attribut im DbRep). Sie bietet maximale Flexibiliät und Möglichkeiten, ist aber mit etwas Programmierung verbunden. Die prinzipielle Funktionseise und wie man sie nutzen kann ist hier an einem Beispiel gezeigt:

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Abarbeitung_einer_sequentiellen_Befehlskette_mittels_non-blocking_sqlCmd-Kommandos

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ptr201711 am 11 Februar 2019, 17:25:36
Danke für die Hilfe mit notify bekomme ich das hin. Wahrscheinlich muss aber doch auf die Utils gehen für die endgültige Lösung. :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maci am 11 Februar 2019, 18:23:54
Hallo,

Ich benutze derzeit noch die normale (blocking) Variante der Abfrage und Befüllung des Dummys.
Diese  möchte ich jetzt zeitnah in die nonblocking Variante umbauen.

Was ich aber derzeit noch suche, ist: Wie kann ich mehrere Werte eines Devices aus dem DBLog in eine Dummydevice packen.
Ich habe ein Thermostat-Device (Netatmo) das beinhaltet die akt. Temperatur, die Solltemperatur und das aktuelle laufende Programm.
Nun möchte ich aber die Infos per DbRep auch in meiner anderen Fhem Instanz haben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2019, 18:34:50
Hallo maci,

Zitat
Wie kann ich mehrere Werte eines Devices aus dem DBLog in eine Dummydevice packen.
Ich habe ein Thermostat-Device (Netatmo) das beinhaltet die akt. Temperatur, die Solltemperatur und das aktuelle laufende Programm.
Nun möchte ich aber die Infos per DbRep auch in meiner anderen Fhem Instanz haben.

Ich muss zugeben, die Aufgabenstellung nicht wirklich verstanden zu haben. Ich versuche es mal mit meinen Worten.
Du hast ein Thermostat-Device (Netatmo), das beinhaltet die akt. Temperatur, die Solltemperatur und das aktuelle laufende Programm als Readings. Diese Readings werden in eine Datenbank geloggt.
Jetzt möchtest du diese Readings bzw. deren Werte mit DbRep aus der DB lesen und in ein Dummydevice packen.
Das Ganze soll auf einer anderen FHEM Instanz passieren.

Habe ich das so richtig wiedergegeben ?

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maci am 11 Februar 2019, 19:28:11
Zitat von: DS_Starter am 11 Februar 2019, 18:34:50
Hallo maci,

Ich muss zugeben, die Aufgabenstellung nicht wirklich verstanden zu haben. Ich versuche es mal mit meinen Worten.
Du hast ein Thermostat-Device (Netatmo), das beinhaltet die akt. Temperatur, die Solltemperatur und das aktuelle laufende Programm als Readings. Diese Readings werden in eine Datenbank geloggt.
Jetzt möchtest du diese Readings bzw. deren Werte mit DbRep aus der DB lesen und in ein Dummydevice packen.
Das Ganze soll auf einer anderen FHEM Instanz passieren.

Habe ich das so richtig wiedergegeben ?


Grüße
Heiko

Hallo Heiko,

Ja das ist so richtig wiedergegeben.
Das Auslesen erfolgt in einer andern Fhem Instanz.

Gruß Georg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2019, 20:29:20
Hallo Georg,

Ok, das ist eigentlich auch nicht so schwer.
Auf der anderen FHEM-Instanz definierst du dir ein DbLog-Device welches nichts loggt. Z.B.

define LogDB1 DbLog ./db.conf aaaaa:bbbbb

Das dient nur zur Herstellung der Verbindung. Nun erstellst du auf der anderen FHEM Instanz noch ein DbRep Device mit der Angabe von LogDB1.
Nun kannst du mit dem DbRep auf der anderen FHEM-Instanz alle Werte aus der Quelldatenbank lesen.

Die erstellten Readings kannst du wieder auf einen Dummy schreiben wie im Wiki beschrieben oder über die bereits erwähnte userExitFn.

Was denkst du ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 12 Februar 2019, 14:21:44
Hallo Heiko,

mal eine kleine Frage am Rande,
werden bei set XXX sqlCmd xxx
die Attribute "timestamp_begin" und "timestamp_end" berücksichtigt?

danke & Grüße
Frank
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Februar 2019, 14:50:25
Hi Frank,

ja, aber du musst dafür Platzhalter in deinem SQL verwenden. Ich glaube so -> §timestamp_begin§. Schau aber besser mal in die Commandref.

Lg
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maci am 12 Februar 2019, 20:33:37
Hallo Heiko,

Alles erledigt und es funktioniert alles. Weiters habe ich alles auf nonblocking umgebaut.

Danke!

Gruß
Georg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Girgl am 03 März 2019, 22:16:30
Hallo,

habe Probleme mit "delDoublets". Sowohl bei adviceDelete als auch bei delete habe ich folgende Fehlermeldung:
2019-03-03 21:29:41 DbRep DbWolfStarts running
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - -------- New selection ---------
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Command: delDoublets adviceDelete
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - Timestamp begin epocheseconds: 1551640791
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Timestamp begin human readable: 2019-03-03 20:19:51
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - Timestamp end epocheseconds: 1551644981
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Timestamp end human readable: 2019-03-03 21:29:41
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - weekday of start for selection: So -> wdadd: 86400
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - Daylight savings changed: 0 (on Mon Mar 4 20:19:51 2019)
2019.03.03 21:29:41 5 : DbRep DbWolfStarts - runtime_string: 2019-03-03, runtime_string_first: 2019-03-03 20:19:51, runtime_string_next: 2019-03-03 21:29:41
2019.03.03 21:29:41 4 : DbRep DbWolfStarts - Aggregation: day
2019.03.03 21:31:02 1 : DbRep DbWolfStarts -> BlockingCall deldoublets_DoParse pid:DEAD:970 Process died prematurely
2019-03-03 21:31:02 DbRep DbWolfStarts Process died prematurely


"delSeqDoublets" arbeitet einwandfrei. Ebenso alle anderen Befehle. Ich habe mittlerweile eine neue Datenbank angelegt und die geforderten Module überprüft. Keine Besserung.

Meine Datenbank:
define DbLog DbLog ./db.conf .*:(temperature|humidity|Rain|gustSpeed|wind|Super|Diesel|Wolf|Wb_).*
setuuid DbLog 5c62fc7d-f33f-bf9c-5b32-c9c6bcfc41cb2980
attr DbLog DbLogExclude state
attr DbLog DbLogSelectionMode Exclude
attr DbLog DbLogType Current/History
attr DbLog asyncMode 1
attr DbLog disable 0
attr DbLog room logs
attr DbLog syncInterval 180


DbRep:
define DbWolfStarts DbRep DbLog
setuuid DbWolfStarts 5c673196-f33f-bf9c-1e09-481a8a7e44d80705
attr DbWolfStarts allowDeletion 1
attr DbWolfStarts device Wolf_betrd
attr DbWolfStarts room logs
attr DbWolfStarts showproctime 1
attr DbWolfStarts verbose 5


Habs auch schon mit Zeitangaben oder definiertem reading getestet. Immer das gleiche Ergebnis! Ebenso mit reopenDatabase-Parametern.

Weiss jemand Rat?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2019, 22:29:23
Hallo Girgl,

der Fehler hat eher etwas mit deiner Hardware zu tun. Typischerweise passiert es wenn dein RAM/SWAP knapp wird.
Oder vllt. Platte voll ?
Schau mal an diesen Stellen nach oder schreib mal was dazu.

Edit: Es könnte dir helfen das Attribut "aggregation = hour" zu setzen !

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Girgl am 03 März 2019, 22:43:08
Fhem läuft auf dem Raspberry 3b+, raspbian stretch frisch aufgesetzt. Abfragen der Speicher ergibt nichts aussergewöhnliches. Momentan kümmert sich der RPi nur um fhem, mpd, einen cul und ein freigegebenes DVD-Laufwerk. Ein RPi-Zero, der sich um die Heizung (ebus/1-wire) ist via fhem2fhem verbunden. Die Datenbank hat kaum Einträge.

pi@rpi-3b:~ $ df -h
Dateisystem                                                          Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root                                                              13G    6,3G  5,6G   53% /
devtmpfs                                                              460M       0  460M    0% /dev
tmpfs                                                                 464M       0  464M    0% /dev/shm
tmpfs                                                                 464M     13M  452M    3% /run
tmpfs                                                                 5,0M    4,0K  5,0M    1% /run/lock
tmpfs                                                                 464M       0  464M    0% /sys/fs/cgroup
/dev/mmcblk0p6                                                         68M     23M   46M   33% /boot
tmpfs                                                                  93M       0   93M    0% /run/user/1000
/dev/mmcblk0p5                                                         30M    398K   28M    2% /media/pi/SETTINGS

pi@rpi-3b:~ $ cat /proc/swaps
Filename Type Size Used Priority
/var/swap                               file 102396 0 -2
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Girgl am 03 März 2019, 22:53:00
Ach ja, der Ram:

pi@rpi-3b:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949448      161380      513812       18488      274256      717868
Swap:        102396           0      102396
pi@rpi-3b:~ $



Ich werde DbRep mal auf dem Laptop(Ubuntu) testen.

Danke erstmal und schöne Grüsse
Girgl
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2019, 22:54:56
Wenn kaum Einträge vorhanden sind ist es wirklich ein merkwürdiges verhalten.
Habe es sicherheitshalber bei gerade ausprobert -> no Problem. DbRep-Version ist aktuell nehme ich an.
Versuche noch bitte mit aggregation = hour, wird aber wegen der wenigen Einträge wohl nichts bringen.

Ich weiß nicht ob du Gelegenheit hast den Speicherverbrauch während des Laufs zu beobachten, oder ob der Abbruch sehr schnell kommt.
Heute ist es schon spät geworden ...ich schaue morgen auch nochmal nach Hinweisen.

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Girgl am 03 März 2019, 23:57:43
Hab jetzt nochmal rumprobiert und im Log folgenden Hinweis gefunden:

db prepare_cached failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857

2019.03.03 23:49:25 2: AttrTemplates: got 55 entries
2019.03.03 23:49:50 4: DbRep DbWolfStarts - -------- New selection ---------
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Command: delDoublets adviceDelete
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Timestamp begin epocheseconds: 1551640791
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Timestamp begin human readable: 2019-03-03 20:19:51
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Timestamp end epocheseconds: 1551653390
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Timestamp end human readable: 2019-03-03 23:49:50
2019.03.03 23:49:50 5: DbRep DbWolfStarts - weekday of start for selection: So  ->  wdadd: 86400
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Sun Mar  3 21:19:51 2019)
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Sun Mar  3 22:19:51 2019)
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Sun Mar  3 23:19:51 2019)
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Daylight savings changed: 0 (on Mon Mar  4 00:19:51 2019)
2019.03.03 23:49:50 4: DbRep DbWolfStarts - Aggregation: hour
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Timestamp-Array:
2019-03-03_20#2019-03-03 20:19:51#2019-03-03 21 2019-03-03_21#2019-03-03 21#2019-03-03 22 2019-03-03_22#2019-03-03 22#2019-03-03 23 2019-03-03_23#2019-03-03 23#2019-03-03 23:49:50
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Devices for operation - included: Wolf_betrd , excluded:
2019.03.03 23:49:50 5: DbRep DbWolfStarts - Readings for operation - included: Wb_Aussentemp, excluded: 
DBD::SQLite::db prepare_cached [b]failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857[/b].
2019.03.03 23:49:59 1: DbRep DbWolfStarts -> BlockingCall deldoublets_DoParse pid:DEAD:2065 Process died prematurely


Wie angekündigt habe ich das Ganze mal auf dem Laptop(andere Daten/Hardware) nachgestellt und bekomme im Log dieselbe Fehlermeldung:
2019.03.03 23:29:00 3: DbLog Amilo - Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2019.03.03 23:29:00 3: DbLog Amilo - Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
2019.03.03 23:29:28 3: DbRep Ami - Connectiontest to database SQLite:dbname=/opt/fhem/fhem.db with user
2019.03.03 23:29:28 3: DbRep Ami - Initial data information retrieved successfully - total time used: 0.001927 seconds
2019.03.03 23:29:28 3: DbRep Ami - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful
DBD::SQLite::db prepare_cached failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857.
2019.03.03 23:30:00 1: DbRep Ami -> BlockingCall deldoublets_DoParse pid:DEAD:15128 Process died prematurely
2019.03.03 23:39:38 4: DbRep Ami - -------- New selection ---------
2019.03.03 23:39:38 4: DbRep Ami - Command: delDoublets adviceDelete
2019.03.03 23:39:38 5: DbRep Ami - Timestamp begin epocheseconds: 1551650443
2019.03.03 23:39:38 4: DbRep Ami - Timestamp begin human readable: 2019-03-03 23:00:43
2019.03.03 23:39:38 5: DbRep Ami - Timestamp end epocheseconds: 1551652778
2019.03.03 23:39:38 4: DbRep Ami - Timestamp end human readable: 2019-03-03 23:39:38
2019.03.03 23:39:38 5: DbRep Ami - weekday of start for selection: So  ->  wdadd: 86400
2019.03.03 23:39:38 5: DbRep Ami - Daylight savings changed: 0 (on Mon Mar  4 00:00:43 2019)
2019.03.03 23:39:38 4: DbRep Ami - Aggregation: hour
2019.03.03 23:39:38 5: DbRep Ami - Timestamp-Array:
2019-03-03_23#2019-03-03 23:00:43#2019-03-03 23:39:38
2019.03.03 23:39:38 5: DbRep Ami - Devices for operation - included: sysmon , excluded:
2019.03.03 23:39:38 5: DbRep Ami - Readings for operation - included: cpu_freq, excluded: 
DBD::SQLite::db prepare_cached [b]failed: near "ASC": syntax error at ./FHEM/93_DbRep.pm line 4857[/b].
2019.03.03 23:39:56 1: DbRep Ami -> BlockingCall deldoublets_DoParse pid:DEAD:15322 Process died prematurely


Grüße Girgl
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2019, 07:56:59
Guten Morgen,

alles klar.
Konnte das Problem bei mir auch nachstellen. Es trifft bei SQLite zu. Normalerweise verwende ich MySQL und bei dieser Datenbank ist die Syntax ok.
Ich werde für SQLite eine ANpassung vornehmen und stelle dir eine Version zum Test heute Abend bereit.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2019, 09:01:11
Kannst schonmal testen.

Download der Version  hier aus meinem contrib herunterladen:

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

Danach shutdown restart oder reload 93_DbRep.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Girgl am 04 März 2019, 09:43:30
Hallo Heiko,

habs grad auf die schnelle getestet und es klappt jetzt. Werde es noch mit der "alten" großen Datenbank testen, dazu komme ich heute aber nicht mehr.

Danke und Schöne Grüße!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 März 2019, 21:19:34
Hallo zusammen,

ich habe soeben die aktuelle Version von DbRep eingecheckt.
Es wird der obige Fix für SQLite ausgeliefert.
Außerdem ist es nun möglich readingRename nur auf die Readings eines bestimmten Devices anzuwenden.

* readingRename <[Device:]alterReadingname>,<neuerReadingname>
Benennt den Namen eines Readings innerhalb der angeschlossenen Datenbank (siehe Internal DATABASE) um. Der Readingname wird immer in der gesamten Datenbank umgesetzt. Eventuell gesetzte Zeitgrenzen oder Beschränkungen durch die Attribute Device bzw. Reading werden nicht berücksichtigt.
Optional kann eine Device angegeben werden. In diesem Fall werden nur die alten Readings dieses Devices in den neuen Readingnamen umgesetzt.

    Beispiele:
    set <name> readingRename TotalConsumption,L1_TotalConsumption
    set <name> readingRename Dum.Energy:TotalConsumption,L1_TotalConsumption
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 März 2019, 07:54:30
Hallo Heiko,

ich habe mal die Backup Funktion ausgeführt.

(set xxx dumpMySQL clientside)

nach nun knapp 22h ist er auch damit fertig geworden.

DumpFileCreated ./log/fhem_2019_03_13_10_04.sql.gzip 2019-03-14 07:15:26
DumpFileCreatedSize 113.38 MB 2019-03-14 07:15:26
DumpRowsCurrent 6632 2019-03-14 07:15:26
DumpRowsHistory 11346422 2019-03-14 07:15:26
background_processing_time 76264.9506 2019-03-14 07:15:26
state Database backup finished 2019-03-14 07:15:27


die DB läuft auf einem zweiten Raspi.
Gibt es da eine Möglichkeit, das zu beschleunigen?

Gruß
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2019, 08:08:07
Morgen Thomas,

ja, das gibt es. Für clientSide gibt zwei mögliche Attribute die Abhängigkeiten zueinander haben.
Das sind dumpMemlimit und dumpSpeed. Das sind Parameter für den Ressourcenverbrauch.
Du kannst dich dem richtigen Wert iterativ nähern um möglichst viel aber nicht zuviel Ressourcen (CPU, RAM) für den Dump zu verwenden.
Aber viel schneller geht die Variante serverSide. Dahinter steht auch eine andere Technik. Die Unterschiede sind in der commandRef beschrieben.
Hast du serverSide schonmal ausprobiert ?

liebe Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 März 2019, 08:20:59
Ich wollte eigentlich clientside nutzen, da dann das Backup über ein komplettes FHEM-Backup auf dem NAS gesichert wird.
So wie ich es aus der commandRef verstanden habe, wird das serverside Backup auch als .csv abgelegt und nicht als SQL.

bin ich da richtig?

was bewirkt optimizeTablesBeforeDump?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2019, 08:33:50
Zitat
Ich wollte eigentlich clientside nutzen, da dann das Backup über ein komplettes FHEM-Backup auf dem NAS gesichert wird.
So wie ich es aus der commandRef verstanden habe, wird das serverside Backup auch als .csv abgelegt und nicht als SQL.
Das ist alles genau richtig. Insofern hast du die richtige Wahl getroffen.
Meine Einstellungen bei clientSide sind z.B.

dumpMemlimit  100000000
dumpSpeed     1000000

Damit sichert clientSide 21 Mio Datensätze in rund 25 Minuten (auf einem NUC).

Mit optimizeTablesBeforeDump = 1 wird vor dem Dump die Tabelle history (im Prinzip auch current) optimiert, d.h. es wird Platz freigegeben. Hat nur Sinn wenn vorher (viele) Daten gelöscht wurden. Das braucht aber zusätzlich Zeit. Wenn der Dump ohnehin schon viel Zeit benötigt würde ich das nicht machen und ggf. einen Lauf zur Optmierung separat einplanen mit set ... optimzeTables.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 März 2019, 09:14:12
danke dir, ich probier das mal aus...

edit: eine Frage hab ich noch, wird das dumpMemlimit in Bytes angegeben? Also in deinem Beispiel wären das dann 100MB ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2019, 10:22:32
Naja, es sind eigentlich Zeichen, die ausgewertet werden. Aber wenn man ein Zeichen mit einem Byte gleichsetzt stimmen Byte im Großen und Ganzen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 14 März 2019, 11:04:07
Wow !

... bin jetzt bei ~19 min, 17 min ohne compress
RAM Max war hier bei 1618 MB, Load bei ~0.9
damit kann man leben :)
danke !

Attributes:
   aggregation day
   allowDeletion 1
   device     LaCrosse_3E
   dumpCompress 1
   dumpMemlimit 500000000
   dumpSpeed  4000000
   group      DBLog
   reading    temperature
   room       Energy,System
   timestamp_begin current_day_begin
   timestamp_end current_day_end
   verbose    1

   READINGS:
     2019-03-14 10:54:35   DumpFileCreated ./log/fhem_2019_03_14_10_35.sql.gzip
     2019-03-14 10:54:35   DumpFileCreatedSize 113.66 MB
     2019-03-14 10:54:35   DumpFilesDeleted fhem_2019_03_13_10_04.sql.gzip
     2019-03-14 10:54:35   DumpRowsCurrent 6651
     2019-03-14 10:54:35   DumpRowsHistory 11360885
     2019-03-14 10:54:35   background_processing_time 1124.5978
     2019-03-14 10:54:35   state           Database backup finished


... läuft auf nem TinkerBoard mit 2GB Ram
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 28 März 2019, 12:15:58
Hallo Heiko,
nach einem set Rep_HH_Eingangsleistung_delete_older delEntries mit:
define Rep_HH_Eingangsleistung_delete_older DbRep DBLogging
setuuid Rep_HH_Eingangsleistung_delete_older 5c9c935b-f33f-7c4f-2e23-094ad81859f7bee8
attr Rep_HH_Eingangsleistung_delete_older allowDeletion 1
attr Rep_HH_Eingangsleistung_delete_older device HH_Eingangsleistung
attr Rep_HH_Eingangsleistung_delete_older reading state
attr Rep_HH_Eingangsleistung_delete_older showproctime 1
attr Rep_HH_Eingangsleistung_delete_older timeOlderThan d:14

verbleiben in der DB:
mysql> select distinct date(timestamp), device, reading from history where device = 'HH_Eingangsleistung' and reading = 'state';
+-----------------+---------------------+---------+
| date(timestamp) | device              | reading |
+-----------------+---------------------+---------+
| 2019-03-02      | HH_Eingangsleistung | state   |
| 2019-03-03      | HH_Eingangsleistung | state   |
| 2019-03-04      | HH_Eingangsleistung | state   |
| 2019-03-05      | HH_Eingangsleistung | state   |
| 2019-03-06      | HH_Eingangsleistung | state   |
| 2019-03-07      | HH_Eingangsleistung | state   |
| 2019-03-08      | HH_Eingangsleistung | state   |
| 2019-03-09      | HH_Eingangsleistung | state   |
| 2019-03-10      | HH_Eingangsleistung | state   |
| 2019-03-11      | HH_Eingangsleistung | state   |
| 2019-03-12      | HH_Eingangsleistung | state   |
| 2019-03-13      | HH_Eingangsleistung | state   |
| 2019-03-14      | HH_Eingangsleistung | state   |
| 2019-03-15      | HH_Eingangsleistung | state   |
| 2019-03-16      | HH_Eingangsleistung | state   |
| 2019-03-17      | HH_Eingangsleistung | state   |
| 2019-03-18      | HH_Eingangsleistung | state   |
| 2019-03-19      | HH_Eingangsleistung | state   |
| 2019-03-20      | HH_Eingangsleistung | state   |
| 2019-03-21      | HH_Eingangsleistung | state   |
| 2019-03-22      | HH_Eingangsleistung | state   |
| 2019-03-23      | HH_Eingangsleistung | state   |
| 2019-03-24      | HH_Eingangsleistung | state   |
| 2019-03-25      | HH_Eingangsleistung | state   |
| 2019-03-26      | HH_Eingangsleistung | state   |
| 2019-03-27      | HH_Eingangsleistung | state   |
| 2019-03-28      | HH_Eingangsleistung | state   |
+-----------------+---------------------+---------+
24 rows in set (45.43 sec)

Lt. Logdaten wird der Befehl wie folgt umgesetzt:
2019.03.28 12:01:16 4: DbRep Rep_HH_Eingangsleistung_delete_older - SQL execute: delete FROM history where DEVICE = 'HH_Eingangsleistung' AND READING = 'state' AND TIMESTAMP >= '1970-01-01 01:00:00' AND TIMESTAMP <= '2019-03-02 12:01:15' ;
Der jüngere Timestamp müsste auf '2019-03-14 12:01:15' gesetzt sein, oder?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 März 2019, 12:46:52
Bin auch deiner Meinung. Mach mir mal bitte einen verbose 4 Auszug mit dem gleichen Befehl.
Also komplett ab dem Start des Befehls. Da kommen noch ein paar Zeilen vorher.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 März 2019, 15:16:59
Hallo Thowe,

jetzt habe ich ein Rep-Device bei mir identisch zu deinem konfiguriert und laufen lassen.
Bei mir wird der Select korrekt aufgebaut (wird natürlich nichts gelöscht weil ich diese Datensätze nicht habe):


2019.03.28 15:08:48.470 4: DbRep Test - -------- New selection ---------
2019.03.28 15:08:48.471 4: DbRep Test - Command: delEntries
2019.03.28 15:08:48.472 4: DbRep Test - timeOlderThan - year: , day: 14, hour: , min: , sec: 
2019.03.28 15:08:48.473 4: DbRep Test - Year 2016 is leap year
2019.03.28 15:08:48.473 4: DbRep Test - Timestamp begin human readable: 2016-04-10 07:00:00
2019.03.28 15:08:48.474 4: DbRep Test - Time difference to current time for calculating Timestamp end: 1213201 sec
2019.03.28 15:08:48.475 4: DbRep Test - Timestamp end human readable: 2019-03-14 14:08:47
2019.03.28 15:08:48.475 4: DbRep Test - Aggregation: no
2019.03.28 15:08:48.509 4: DbRep Test - SQL execute: delete FROM history where DEVICE = 'HH_Eingangsleistung' AND READING = 'state' AND TIMESTAMP >= '2016-04-10 07:00:00' AND TIMESTAMP <= '2019-03-14 14:08:47' ;
2019.03.28 15:08:48.605 3: DbRep Test - Entries of fhemtest.history deleted: HH_Eingangsleistung--state--0


Verwendung findet die aktuell eingecheckte Version 8.17.0. Welchen Wert ? siehst du denn bei dir von:

Time difference to current time for calculating Timestamp end: 1213201 sec
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 März 2019, 18:43:52
Ich habe weitergeforscht und einen Kalkulationsfehler bei der Berücksichtigung von Schaltjahren identifiziert.
Melde mich wieder mit einer Korrekturversion.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 März 2019, 22:17:09
Hallo Thowe,

ich habe die Berücksichtigung der Schaltjahre korrigiert und etliche Kombinationen durchgetestet.

Die Version kannst du hier aus dem contrib zum Testen herunterladen:

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

Danach auf jeden Fall restarten !

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 29 März 2019, 13:47:27
Hallo Heiko,
Danke für die schnelle Reaktion. Mit 18.7.2 wurde der richtige jüngere Timestamp berechnet.

Ich habe mir die Logdaten nochmal angesehen vom Zeitraum, bevor der Fehler auftrat. Es gab während der Initialisierungsphase tatsächlich einen DB-Neustart, so dass eine Erklärung für den Fehler auch sein könnte, dass DbRep_getInitData von Rep_HH_Eingangsleistung_delete_older nicht korrekt beendet wurde.

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 März 2019, 14:02:59
Hi Thowe,

danke für deine Rückmeldung. Ungeachtet dessen hast du mich dadurch auf einen Fehler in der Schaltjahrberücksichtigung aufmerksam gemacht  ;)
Werde die Version einchecken, sodass sie morgen früh im Update verfügbar ist.
Falls dir noch etwas auffallen sollte melde dich gerne wieder.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 April 2019, 23:33:03
Hallo zusammen,

ich habe im DbRep die Aggregation "year" eingebaut. Damit ist es nun möglich, Auswertungen und Vergleiche auf Kalenderjahr-Ebene einzustellen.

Wie gewöhnlich wieder zunächst aus dem contrib laden zum Test wer möchte:

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

Grüße
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 April 2019, 23:52:07
Ich habe soeben die Version 8.20.0 eingecheckt. Mit dieser Version gibt es ein "set ... index" Command mit dem man leicht die benötigten Indexe für DbLog und DbRep managen kann.

* index <Option> - Listet die in der Datenbank vorhandenen Indexe auf bzw. legt die benötigten Indexe an. Ist ein Index bereits angelegt, wird er erneuert (gelöscht und erneut angelegt)

Die möglichen Optionen sind:

    list_all    :                        listet die vorhandenen Indexe auf
    recreate_Search_Idx  :    erstellt oder erneuert (falls vorhanden) den Index Search_Idx in Tabelle history (Index für DbLog)
    drop_Search_Idx    :        löscht den Index Search_Idx in Tabelle history
    recreate_Report_Idx   :   erstellt oder erneuert (falls vorhanden) den Index Report_Idx in Tabelle history (Index für DbRep)
    drop_Report_Idx    :        löscht den Index Report_Idx in Tabelle history


Die Version ist morgen früh im Regelupdate verfügbar.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 29 Mai 2019, 21:12:34
Zitat von: DS_Starter am 26 Februar 2018, 23:51:54
Es werden alle Datensätze übertragen, die durch Timestamp-Attribute bzw. die Attribute "device", "reading" bestimmt sind.
Die Datensätze werden dabei in Zeitscheiben entsprechend der eingestellten Aggregation übertragen. Hat das Attribut "aggregation" den Wert "no" oder "month", werden die Datensätze automatisch in Tageszeitscheiben zur Standby-Datenbank übertragen. Quell- und Standby-Datenbank können unterschiedlichen Typs sein.

Die zur Steuerung der syncStandby Funktion relevanten Attribute sind:

    aggregation    : Einstellung der Zeitscheiben zur Übertragung (hour,day,week)
    device            : Übertragung nur von Datensätzen die <device> enthalten
    reading            : Übertragung nur von Datensätzen die <reading> enthalten
    time.*            : Attribute zur Zeitabgrenzung der zu übertragenden Datensätze.

LG,
Heiko

Hallo Heiko,

ich bin durch einen deiner Posts in eine anderen Forum auf die Funition gestoßen. Wenn ich meine DB in eine andere syncen will - Initialload mit device .* - erhalte ich fortlaufend Fehler.


DBD::mysql::st execute failed: Incorrect datetime value: '2015-03-29 02:08:40' for column 'TIMESTAMP' at row 1 at ./FHEM/93_DbRep.pm line 10407.

Wenn ich den Lauf wiederhole kommt der selbe Fehler. Wenn ich den entsprechenden Eintrag lösche findert er immer wieder weitere. Meine DB hat etwa 750.000 Sätze. In der RemoteDB wurden ungefähr 150.000 übertragen, es ist also kein genereller Fehler. Der Fehler sagt, dass Timestamp falsches Format hat, es entspricht aber dem ISO-Format der DB.

Irgend eine Idee? Habe dir 2 SQL-Files angehängt falls du die genauen Daten sehen willst. Ein Datensatz der erfolgreich geladen wurde ist auch angehängt. Ich sehe hier keinen Unterschied im Timestamp.

Wo muss ich ein "or die" setzen damit im Fehlerfall weiter geladen wird und ein Fehler im Log erscheint.

Danke schon mal!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2019, 07:17:31
Guten Morgen,

ad hoc habe ich noch keine Idee, schaue es mir aber gerne (morgen  ;) ) an.
Gib mir mal bitte noch die Releases der Quell- und Zieldatenbank. Ich muss wahrscheinlich in dieser Richtung forschen.

ZitatWo muss ich ein "or die" setzen damit im Fehlerfall weiter geladen wird und ein Fehler im Log erscheint.
Meinst du damit, dass die fehlerhaften Sätze einfach übersprungen werden (mit Log-Info) aber der Prozess weiterlaufen soll ?
Also "or die" ist eine schlechte Idee. Ich würde mir aber gleich mit Gedanken machen ob/wie man dem Befehl eine solche Option mitgeben kann.

Edit: Noch eine Frage. Siehst du bei den besagten Datensätzen beim Timestamp irgendwelche zusätzlichen Zeichen wenn du ein Admintool (phpmyAdmin etc.) benutzt ? Ich vermute als ersten Ansatz dass in diesen Feldern irgenwelchen Steuerzeichen mit drin sind, wie auch immer die dort reingekommen sein könnten.

Danke und einen schönen Feiertag !

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 Mai 2019, 08:24:30
Hallo Heiko,

dir auch einen schönen Feiertag und danke für das Angebot, ich erwarte gar keine Anpassung im Modul, hätte einfach die Fehler übersprungen und weiter gearbeitet. Das Ganze eilt nicht.

Den Fehler habe ich gefunden. "Daylight saving time" sprich Sommerzeit. Meine Systeme laufen alle auf CET/CEST [edit Mischung UTC/CET s. u.] und da gibt / gab es das Problem, dass durch Verzögerung ein paar Sätze zu nicht existierenden Zeiten geschrieben wurden, es geht nur um ein paar Sekunden (02:00:08). Ich lösche die Sätze einfach und gut.

Beide Datenbanken sind MariaDB 10 (MySql).

Noch 2 Fragen zu der Bedienung ...
- Gibt das Modul im Erfolgsfall ein Event aus, in dem auch syncStandby vorkommt? Oder sehe ich irgend wo den Zeitpunkt der letzten erfolgreichen Syncronisierung?
- wie müsste ich time.* setzen damit z. B.  timestamp  >= 2019-05-28 10:00:00   übertrage?

Edit: eine Datenbank läuft in Docker (Original) und da ist Systemzeit UTC, die andere auf der Synology (STandby), da ist Systemzeit CET ... muss mal schaun, irgend was mit "--skip-tz-utc"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2019, 08:56:08
ZitatDen Fehler habe ich gefunden. "Daylight saving time" sprich Sommerzeit.
Ah, interessant. Heißt für mich Problem an sich gelöst ?

ZitatGibt das Modul im Erfolgsfall ein Event aus, in dem auch syncStandby vorkommt? Oder sehe ich irgend wo den Zeitpunkt der letzten erfolgreichen Syncronisierung?
Ja, es gibt das Reading "number_lines_inserted_Standby", welches nach jedem erfolgreichen Sync aktualisiert wird. Daraus kannst du ja auch den jeweiligen Zeitpunkt ableiten (FHEM ReadingsTimestamp).
Alternativ könntest du im Attribut "executeAfterProc" einen FHEM Trigger Befehl (https://fhem.de/commandref_DE.html#trigger) absetzen der einen Event erzeugt den du möchtest. Im Attribut "executeAfterProc" kannst du beliebige FHEM-Befehle oder eine eigene Perl-Routine abarbeiten lassen.

Zitatie müsste ich time.* setzen damit z. B.  timestamp  >= 2019-05-28 10:00:00   übertrage?
Das wäre:

attr <Name> timestamp_begin 2019-05-28 10:00:00


Wenn du Verbesserungen siehst, lass es mich gerne wissen.

EDIT: Attr changed

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 30 Mai 2019, 09:16:19
Denke die Frage ist jetzt eher wie die ungültigen Daten geloggt wurden und was genau falsch ist.

Geloggt wurde ja vom dblog Modul.

Gesendet von meinem Doogee S60 mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2019, 09:35:09
ZitatDenke die Frage ist jetzt eher wie die ungültigen Daten geloggt wurden und was genau falsch ist.

Geloggt wurde ja vom dblog Modul.
Gute Frage, ich sehe bei "Verzögerung ein paar Sätze zu nicht existierenden Zeiten geschrieben wurden, es geht nur um ein paar Sekunden (02:00:08)" -> 02:00:08 auch keinen unzulässigen Timestamp.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 Mai 2019, 11:49:12
Fehler war durch den Timestamp der in die Stunde der Sommerzeitumstellung hineinragte. Da gibt MySql eine Warnung " Warning: #1299 Ungültiger TIMESTAMP-Wert in Feld 'TIMESTAMP', Zeile 1" aus


INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2015-03-29 02:00:09', 'Wetter_Nuernberg', 'WEATHER', 'humidity: 86', 'humidity', '86', '%');


Ich habe nun 35 Werte mit ähnlichem Aussehen der Jahre 2014 - 2017 gelöscht. Nun kann ich es vollständig laufen lassen.

2018 und 2019 habe ich keine Fehler gefunden.

Zitat von: DS_Starter am 30 Mai 2019, 08:56:08
Wenn du Verbesserungen siehst, lass es mich gerne wissen.

Meinst du damit ob ich Verbesserungsvorschläge habe? .... ja :)

Vorweg, es ist aktuell nur eine Spielerei und vielleicht den Aufwand gar nicht wert. Ich kann mir das auch selber programmieren.

Folgender Anwendungsfall: Jemand, wie ich, möchte seine Standby Datenbank so aktuell wie möglich halten, der Server auf dem die Standby läuft ist aber nicht immer. Hintergrund, mein NAS läuft nur wenn ich zu Hause bin.

Ich möchte nicht jedesmal einen Fullload machen sondern mit Deltascheiben arbeiten. Jede Stunde, Tag, Woche einmal, sollte erstmal keinen Unterschied machen.

Hier 2 Wünsche.
- Der "von - bis" Zeitraum als Parameter oder irgendwie dynamisch. Aktuell ist es ein Attribut. Dann muss ich immer Speichern wenn ich per Script was ändere. Wenn dynamisch könnte ich aus dem Reading das Datum extrahieren und dann als Start-Datum verwenden.

- Wenn ich einen Lauf erneut starte weil der erste fehlerhaft war, wird ja wieder mit insert gearbeitet. Dazu würde ich ggf. einen unique-index anlegen. Dann gäbe es beim Einfügen aber einen Fehler der das Script auch wieder abbrechen würde. Der Fehler sollte aber die Bearbeitung nicht abbrechen ... ich weiß nicht, ob du irgendwo angeben kannst welche Fehler ignoriert werden sollen. Ich glaube der duplicate ist Fehler #1062 in MySql.
--> Alternative hierzu ... ein Modify Modus, erst lesen ob Sätze schon da sind, wenn ja, UPdate sonst Insert. Mir ist bewusst, dass es die Laufzeit erhöhen würde.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 30 Mai 2019, 13:09:43
Könnte man die standby DB nicht als zweite DB anlegen?
Fhem würde dann das bulk Update machen sobald die Db erreichbar ist und cachen wenn sie offline ist.

Gesendet von meinem Doogee S60 mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2019, 13:47:16
Zitat- Wenn ich einen Lauf erneut starte weil der erste fehlerhaft war, wird ja wieder mit insert gearbeitet. Dazu würde ich ggf. einen unique-index anlegen. Dann gäbe es beim Einfügen aber einen Fehler der das Script auch wieder abbrechen würde.
Du kannst einen Primary Index anlegen. Dieser wird berücksichtigt und es bricht nichts ab. Doppelte DS werden vermieden.

Zitat- Der "von - bis" Zeitraum als Parameter oder irgendwie dynamisch. Aktuell ist es ein Attribut. Dann muss ich immer Speichern wenn ich per Script was ändere. Wenn dynamisch könnte ich aus dem Reading das Datum extrahieren und dann als Start-Datum verwenden.
Bislang kannst du z.B. mit timeDiffToNow = d:1 arbeiten, also beginne immer mit einem Tag in der Vergangenheit. Das ist dynamisch. Vllt. reicht das schon.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2019, 14:50:43
@Frank,

ZitatKönnte man die standby DB nicht als zweite DB anlegen?
Fhem würde dann das bulk Update machen sobald die Db erreichbar ist und cachen wenn sie offline ist.
Im Prinzip ja. Allerdings war der asynchrone Mode ursprünglich nicht dazu gedacht einen Tag lang oder länger die Events im Cache zu halten (Fehlerfall ausgenommen). Mir ging es damals nur um Minuten und dabei dir DB von FHEM zu entkoppeln.
Nachteil wäre falls FHEM abstürzt der Verlust der ganzen Events.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 Mai 2019, 14:56:00
Zitat von: DS_Starter am 30 Mai 2019, 13:47:16
Du kannst einen Primary Index anlegen. Dieser wird berücksichtigt und es bricht nichts ab. Doppelte DS werden vermieden.
Ich dachte wenn schon eine Warnung wegen Timestamp das Script stoppt dann erst recht ein Doppelter Eintrag. Damit ist Punkt ein erledigt.


Zitat von: DS_Starter am 30 Mai 2019, 13:47:16
Bislang kannst du z.B. mit timeDiffToNow = d:1 arbeiten, also beginne immer mit einem Tag in der Vergangenheit. Das ist dynamisch. Vllt. reicht das schon.
Ich sag mal, damit kann ich  leben. Ich lege mir 2 DbRep-Devices mit unterschiedlichen Werten an. Du könntest die Doku etwas erweitern, du schreibst


Die zur Steuerung der syncStandby Funktion relevanten Attribute sind:

aggregation : Einstellung der Zeitscheiben zur Übertragung (hour,day,week)
device : einschließen oder ausschließen von Datensätzen die <device> enthalten
reading : einschließen oder ausschließen von Datensätzen die <reading> enthalten
time.* : Attribute zur Zeitabgrenzung der zu übertragenden Datensätze.
valueFilter : ein zusätzliches REGEXP um die Datenselektion zu steuern. Der REGEXP wird auf das Datenbankfeld 'VALUE' angewendet.


Ich dachte die anderen Attribute werden hier nicht herangezogen da sie nicht gelistet waren. Das Modul ist sehr mächtig, hat viele Attribute und Funktionen. Vielleicht ist es besser eine 2-dim-Tabelle zu machen mit einem Kreuzchen welche Attribute wo verwendet werden. Wäre sicher auch für dich einfacher zu pflegen wenn du ein Attribut einführst oder eine Änderung machst.

Danke dir.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 Mai 2019, 14:58:47
Zitat von: DS_Starter am 30 Mai 2019, 14:50:43
Nachteil wäre falls FHEM abstürzt der Verlust der ganzen Events.
bei mir wäre das sogar im Normalbetrieb so. Bin zum Teil die ganze Woche, ggf. sogar länger beruflich weg. Meine Updates Docker und OS mache ich automatisiert. Da wird auch mal Fhem einfach runtergefahren.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Mai 2019, 15:05:49
Zitatch dachte die anderen Attribute werden hier nicht herangezogen da sie nicht gelistet waren. Das Modul ist sehr mächtig, hat viele Attribute und Funktionen. Vielleicht ist es besser eine 2-dim-Tabelle zu machen mit einem Kreuzchen welche Attribute wo verwendet werden. Wäre sicher auch für dich einfacher zu pflegen wenn du ein Attribut einführst oder eine Änderung machst.
Oh ja danke dir. Ich checke das. Manchmal vergesse ich auch mal was .  ;)
Die Idee mit der Tabelle ist nicht schlecht. Das probiere ich aus wie das zu pflegen ist.

Zitatbei mir wäre das sogar im Normalbetrieb so. Bin zum Teil die ganze Woche, ggf. sogar länger beruflich weg. Meine Updates Docker und OS mache ich automatisiert. Da wird auch mal Fhem einfach runtergefahren.
Einfach runterfahren tut nichts, da wird alles weggeschrieben. Mir ging es um einen harten Absturz.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 30 Mai 2019, 15:11:46


Zitat von: DS_Starter am 30 Mai 2019, 15:05:49
Einfach runterfahren tut nichts, da wird alles weggeschrieben. Mir ging es um einen harten Absturz.
Könnte dieses wegschreiben dann nicht evtl zyklisch alle 5min gemacht werden?
Damit wäre eine Backup DB recht einfach anzulegen ohne viel Pflege und syncaufwand.
Je nachdem wieviel neues kommt ist das syncen ja nicht unerheblich.
Noch dazu wäre es ein live Backup. [emoji16]

Gesendet von meinem Doogee S60 mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 Mai 2019, 15:14:41
Zitat von: DS_Starter am 30 Mai 2019, 15:05:49
Einfach runterfahren tut nichts, da wird alles weggeschrieben. Mir ging es um einen harten Absturz.
Ich meinte die Aussage - Synology ist als Standby DB down da ich nicht zu Hause bin. Gleichzeitig würde Fhem geplant wegen Update restartet. Dann würde ich Sätze verlieren.

Normales runterfahren bei verbundener DB ist kein Problem, das hätte ich schon festgestellt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 30 Mai 2019, 15:21:05
Ist die Frage wie Heiko dieses "wegschreiben" gemeint hat.
Wegschreiben in die DB,
Oder wegschreiben in ein Temp file.

Im ersten Fall wären die Einträge weg.

Gesendet von meinem Doogee S60 mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 Mai 2019, 17:24:57
Zitat von: Frank_Huber am 30 Mai 2019, 15:21:05
Ist die Frage wie Heiko dieses "wegschreiben" gemeint hat.
Wegschreiben in die DB,
Oder wegschreiben in ein Temp file.

Im ersten Fall wären die Einträge weg.

Gesendet von meinem Doogee S60 mit Tapatalk
beides ginge ... :)

wegschreiben in DB läuft in regelmäßigen Abständen ... Sinn und Zweck des Caches
wegschreiben in Temp-File geht mit "set <name> exportCache" bzw. dem entsprechenden import-Statement. Man könnte sich da sicherlich was basteln aber dafür ist es eigentlich nicht gebaut.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Mai 2019, 11:08:20
@kadettilac89, habe die commandRef bzgl. Attribute zu syncStandby ergänzt. Sollte ich noch etwas vergessen haben oder du noch weitere Infos dort hilfreich platziert sehen würdest, sag Bitte Bescheid.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 02 Juni 2019, 11:23:27
Zitat von: DS_Starter am 31 Mai 2019, 11:08:20
@kadettilac89, habe die commandRef bzgl. Attribute zu syncStandby ergänzt. Sollte ich noch etwas vergessen haben oder du noch weitere Infos dort hilfreich platziert sehen würdest, sag Bitte Bescheid.

danke dir. Ich muss zugeben, dass ich jetzt erst die Doku den "relevanten Attributen" verstanden. "time.*" ist kein einzelnes Attribut sondern ein Platzhalter und beinhaltet z. B. timeDiffToNow. Vielleicht setzt du das Wort "mehrere" vorndran. Aber will nicht rumjammern, ich habs jetzt verstanden.


mehrere time*-Attribute:
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 Juli 2019, 10:36:50
Ich beschäftige mich gerade mit einigen Umbenennungen (im wesentlichen HM-Devices mit mehreren Kanälen). Trotz Lesens der Doku habe ich noch Fragen.

Meine Vermutung:
Wenn ich mit

set <hm-device> deviceRename name-alt name-neu

arbeite (damit das Device und alle seine Kanäle umbenannt werden), bekommt der DbRep-Agent davon nichts mit und ich muss zusätzlich

set <dbrep-agent> deviceRename name-alt,name-neu

ausführen.
Wirkt hier deviceRename wie bei Homematic, d.h. das Device inkl. der dazugehörenden Kanäle wird bearbeitet oder muss ich in DbRep dann doch jeden Kanal einzeln umbenennen?

Benenne ich dagegen ein einzelnes Device in FHEM um (rename alt neu), führen meine 2 DbRep-Agents (2 DB's) dies automatisch im Hintergrund in den beiden Datenbanken durch und ich muss nichts weiter machen, als die Bearbeitung abzuwarten, um dann das nächste Device umbenennen zu können.

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Juli 2019, 13:01:34
Hallo Holger,

die DbRep-Agenten arbeiten Event basiert, d.h. die reagieren auf den RENAME Event.
Nun weiß ich nicht add-hoc ob die rename Funktion bei Homematic Events erzeugt.
Wenn nicht, wäre der Weg genau wie von dir beschrieben.

ZitatWirkt hier deviceRename wie bei Homematic, d.h. das Device inkl. der dazugehörenden Kanäle wird bearbeitet oder muss ich in DbRep dann doch jeden Kanal einzeln umbenennen?
Vielleicht habe ich die Frage nicht richtig verstanden, aber deviceRename in DbRep ausgeführt wirkt IMMER nur auf die Datensätze innerhalb der DB und ändert nicht die Devicenamen im FHEM an sich.

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 04 Juli 2019, 22:50:46
Hallo Heiko,
danke für deine Klarstellung.

Dann werde ich Device und Kanäle einzeln umbenennen in der Annahme, dass DbRep dann seinerseits daraufhin reagiert. Falls nicht habe ich halt etwas Fleißarbeit vor mir  ;).

Danke.
LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 21 Juli 2019, 18:29:29
Hallo Heiko,
ich könnte zum Reduzieren von Daten eine DB-Funktion gebrauchen, die bei aufsteigenden Values (z.B. von integrierenden Parametern, aber auch Zeitstempel s. Beispiel, die untertags zurückgesetzt werden) auf "negative Flanken" reagiert und dann den letzten hohen und den ersten nach Zurücksetzen in der DB nachbehält.
Beispiel (timestamp,device,value):
Vor Reduktion:
...
2019-07-07 10:01:15;Statusdauer;240:45:26,1
2019-07-07 10:02:15;Statusdauer;240:46:26,1
2019-07-07 10:10:45;Statusdauer;240:54:56,6
2019-07-07 10:13:07;Statusdauer;0:01:27,4
2019-07-07 10:16:16;Statusdauer;0:04:36,3
...

Nach Reduktion:
...
2019-07-07 10:10:45;Statusdauer;240:54:56,6
2019-07-07 10:13:07;Statusdauer;0:01:27,4
...

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Juli 2019, 18:46:18
Hallo Thowe,

möglicherweise reicht dir schon die Funktion "delSeqDoublets" ?
Hast du dir die scho mal angeschaut ? Es ist nicht 100% das was du suchst, kommt dem aber schon nahe.
Ansonsten meldest dich wieder und ich nehme es auf meine ToDo-Liste.
LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 21 Juli 2019, 19:40:47
Hallo Heiko,
danke für die schnelle Rückmeldung - am Sonntag!
Die Funktion "delSeqDoublets" führt in meinem Fall zu keiner sauberen Datenreduzierung, weil sich der Value von Eintrag zu Eintrag unterschiedlich vergrößert und delSeqDoublets auf beide Flanken reagiert. ich müsste seqDoubletsVariance unter den kleinsten Wert meiner negativen Flanken einstellen, und da rutschen mir zu viele positive Flanken durch, also es verbleiben aufsteigende Datensequenzen in der DB. Falls es getrennte Attribute, z.B. seqDoubletsDiffpos und  seqDoubletsDiffneg inkl. für Zeitwerte gäbe, könnte ich es dafür nutzen.

Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Juli 2019, 20:30:22
Hallo Thowe,

habe ich verstanden, glaube ich  :D
Nehme es mal auf meine ToDo. Mal sehen ob ich es noch vor meinem Urlaub schaffe. Bin gerade mit meinem Log2Syslog beschäftigt.
Aber ich vergesse es nicht.  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Juli 2019, 20:36:57
Aber noch eine Frage ... was genau meinst du mit "..  inkl. für Zeitwerte .." ?
Inwiefern sollen die mit eingehen ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 21 Juli 2019, 21:55:17
Hallo Heiko,
super, wenn Du Dich der Sache annehmen würdest. Aber Urlaub geht vor!
Zu den Zeitwerten: In meinem Beispiel weiter oben hatte ich diesen Value für Statusdauer verwendet. Meine Heizung liefert eine Statusdauer in willkürlichen Abständen. Mit dem letzten hohen und ersten niedrigen Statusdauer-Wert und den jeweiligen Timestamps errechne ich mir eine genauere Dauer des Heizbetriebes bzw. der Ruhezeit.
Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 03 August 2019, 05:37:15
Hallo Heiko,

gibt es eigentlich die Möglichkeit die großartigen Funktionen delDoublets und delSeqDoublets auch standalone (als einzelne Programme ohne FHEM) zu verwenden?
Hintergrund ist dass mein FHEM PI momentan aus allen Löchern pfeift, sodass die Ausführung daraus über meine mittlerweile 3 Jahre alte DB den Pi sehr schnell ins Stocken bringt.
Da meine DB aber auf einem NAS läuft der eigentlich genug Ressourcen zur Verfügung hat würde ich das große Aufräumen gern darauf ausführen.


Danke und Gruß
Alex
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 August 2019, 08:47:57
Hallo Alex,

Das wird leider nicht stand alone funktionieren. Neben sql werden auch Perl Routinen eingesetzt.
Vielleicht hast du die Möglichkeit auf dem nas eine (minimale) fhem instanz zu installieren ?

Lg vom Nordmeer,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 03 August 2019, 10:31:44
Hallo Heiko,

Danke Dir für die Rückmeldung (sogar aus dem Urlaub)!
Darüber habe ich auch schon nachgedacht, werde ich wohl demnächst mal probieren.

Gruß aus Vietnam ;-)
Alex
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 August 2019, 22:13:14
Hallo zusammen,

ich habe begonnen meine ToDo-Liste für DbRep abzuarbeiten.

Aktuell wurde das Modul um das Attribut "fetchValueFn" erweitert.
Es besteht nun die Möglichkeit zusammengesetzte Werte im Datenbankfeld VALUE über eine Userfunktion einen interessierenden Einzelwert in den Readings anzuzeigen bzw. weiterzuverarbeiten.

Zum Beispiel das "ram"-Reading des sysmon-Devices sieht mit fetchrows im DbRep so aus:


Total: 986.02 MB, Used: 427.56 MB, 43.36 %, Free: 343.90 MB


Will man z.B. nur den Used-Wert angezeigt bekommen, setzt man im DbRep:


attr Rep.Sysmon.UsedRam fetchValueFn { $VALUE =~ s/^.*Used:\s(.*)\sMB,.*/$1." MB"/e }


Damit ergibt sich nur diese Anzeige:


657.67 MB


Die neue Version 8.22.0 habe ich eingecheckt und ist morgen im update. Für ganz eilige liegt sie auch in meinem contrib (siehe footer)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 September 2019, 15:12:22
Hallo zusammen,

bisher wurden die im Attribut "device" enthaltenen Einträge, welche ein SQL Wildcard (%) im Namen enthielten nur als solche behandelt wenn sie NICHT Bestandteil einer Liste waren. In letzterem Fall wurde der Eintrag als normaler String gewertet.
Mit der Version 8.25.0 in meinem contrib werden Einträge mit Wildcard auch als solche behandelt, wenn sie sich in einer Liste befinden.

Die Weiterentwicklung geht zurück auf die Frage von pechnase hier: https://forum.fhem.de/index.php/topic,101756.msg952253.html#msg952253

Sie bezieht sich zwar auf das Attr readings. Dies werde ich in einem weiteren Schritt umsetzen.

Würde mich über den einen oder anderen Tester freuen bevor ich die neue Version einchecke.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 September 2019, 22:54:40
Für das Attribut "reading" habe ich die Änderung nun auch umgesetzt, d.h. SQL Wildcard (%) kann auch in Reading-Listen verwendet werden und wird dort nicht mehr wie bisher als normaler String ausgewertet.

Version 8.26.0 ist zunächst in meinem contrib bereitgestellt (siehe footer).

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 September 2019, 21:39:45
Hallo miteinander,

Thowe hatte im Beitrag #935 (hat leider etwas länger gedauert  :( ) eine Aufwertung der Funktion "delSeqDoublets" gewünscht.
Das habe ich versucht umzusetzen und eine neue Version von DbRep zum Test in meinem contrib bereitgestellt.
@Thowe, leider kann ich die Varianz nur für numerische Werte umsetzen, Strings kann ich so nicht behandeln.

Das Attribut seqDoubletsVariance ist nun so erweitert:

* seqDoubletsVariance <positive Abweichung [negative Abweichung] [EDGE=negative]>
Akzeptierte Abweichung für das Kommando "set <name> delSeqDoublets".
Der Wert des Attributs beschreibt die Abweichung bis zu der aufeinanderfolgende numerische Werte (VALUE) von Datensätzen als gleich angesehen werden sollen. Ist in "seqDoubletsVariance" nur ein Zahlenwert angegeben, wird er sowohl als positive als auch negative Abweichung verwendet und bilden den "Löschkorridor". Optional kann ein zweiter Zahlenwert für eine negative Abweichung, getrennt durch Leerzeichen, angegeben werden. Es sind immer absolute, d.h. positive Zahlenwerte anzugeben.
Ist der Zusatz "EDGE=negative" angegeben, werden Werte an einer negativen Flanke (z.B. beim Wechel von 4.0 -> 1.0) nicht gelöscht auch wenn sie sich im "Löschkorridor" befinden.

    Beispiele:
    attr <name> seqDoubletsVariance 0.0014
    attr <name> seqDoubletsVariance 1.45
    attr <name> seqDoubletsVariance 3.0 2.0
    attr <name> seqDoubletsVariance 1.5 EDGE=negative

Download aus meinem contrib über die Webeingabe:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

EDIT: Ich habe die Möglichkeiten des Attributs seqDoubletsVariance  noch verfeinert und das Modul neu ins contrib geladen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Oktober 2019, 23:15:00
Habe die weiterentwickelte Version gerade eingecheckt. Es gibt nu auch noch EDGE=positive.
Ist morgen früh im Update.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 November 2019, 16:25:35
Hallo liebe DbRep-Nutzer,

in meinem contrib liegt die Version 8.29.0.
In dieser Version habe ich wie versprochen ein Feature zur FullDay-Erweiterung eingebaut, welches hier https://forum.fhem.de/index.php/topic,104710.msg986236.html#msg986236 requestet/besprochen wurde.

Die Erweiterung gilt für timeOlderThan / timeDiffToNow gleichermaßen. Hier ein Auszug aus der aktualisierten ComRef:

* timeDiffToNow - der Selektionsbeginn wird auf den Zeitpunkt "<aktuelle Zeit> - <timeDiffToNow>" gesetzt. Die Timestampermittlung erfolgt dynamisch zum Ausführungszeitpunkt. Optional kann mit der Zusatzangabe "FullDay" der Selektionsbeginn und das Selektionsende auf Beginn / Ende des jeweiligen Tages erweitert werden (wirkt nur wenn Zeitdifferenz >= 1 Tag).

    Eingabeformat Beispiel:
    attr <name> timeDiffToNow 86400
    # die Startzeit wird auf "aktuelle Zeit - 86400 Sekunden" gesetzt
    attr <name> timeDiffToNow d:2 h:3 m:2 s:10
    # die Startzeit wird auf "aktuelle Zeit - 2 Tage 3 Stunden 2 Minuten 10 Sekunden" gesetzt
    attr <name> timeDiffToNow m:600
    # die Startzeit wird auf "aktuelle Zeit - 600 Minuten" gesetzt
    attr <name> timeDiffToNow h:2.5
    # die Startzeit wird auf "aktuelle Zeit - 2,5 Stunden" gesetzt
    attr <name> timeDiffToNow y:1 h:2.5
    # die Startzeit wird auf "aktuelle Zeit - 1 Jahr und 2,5 Stunden" gesetzt
    attr <name> timeDiffToNow y:1.5
    # die Startzeit wird auf "aktuelle Zeit - 1,5 Jahre gesetzt
    attr <name> timeDiffToNow d:8 FullDay
    # die Startzeit wird auf "aktuelle Zeit - 8 Tage gesetzt, der Selektionszeitraum wird auf Beginn / Ende des jeweiligen Tages erweitert


Sind die Attribute "timeDiffToNow" und "timeOlderThan" gleichzeitig gesetzt, wird der Selektionszeitraum zwischen diesen Zeitpunkten dynamisch kalkuliert.

Wer mag, kann sich das Modul einfach so aus der Kommandozeile herunterladen und ausprobieren:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 08 November 2019, 16:31:07
Danke Heiko! :-)
Ist installiert. Ich werde berichten!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 November 2019, 16:39:15
Na das ging ja fix  :D 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Frank_Huber am 08 November 2019, 18:04:23
Zitat von: DS_Starter am 08 November 2019, 16:39:15
Na das ging ja fix  :D
Ach, wenn ich im Büro bin hab ich das Forum immer nebenher offen. :-)

Ich melde mit v5 Log, es funktioniert!

2019.11.08 17:44:15 4: DbRep logdb_clean_3days - -------- New selection ---------
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - Command: delEntries
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - timeOlderThan - year: , day: 3, hour: , min: , sec:
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - startMonth: 11 endMonth: 10 lastleapyear:  baseYear: 2019 diffdaylight:0 isdaylight:0
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - FullDay option: 1
2019.11.08 17:44:15 5: DbRep logdb_clean_3days - Timestamp begin epocheseconds: 1481842800
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - Timestamp begin human readable: 2016-12-16 00:00:00
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - Time difference to current time for calculating Timestamp end: 259201 sec
2019.11.08 17:44:15 5: DbRep logdb_clean_3days - Timestamp end epocheseconds: 1572994799
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - Timestamp end human readable: 2019-11-05 23:59:59
2019.11.08 17:44:15 5: DbRep logdb_clean_3days - weekday of start for selection: Fr  ->  wdadd: 259200
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - Aggregation: no
2019.11.08 17:44:15 5: DbRep logdb_clean_3days - IsTimeSet: 1, IsAggrSet: 0
2019.11.08 17:44:15 5: DbRep logdb_clean_3days - Devices for operation -
included (23): HM_Powermeter_1,HM_Powermeter_1_Pwr,HM_Powermeter_1_SenF,HM_Powermeter_1_SenI,HM_Powermeter_1_SenPwr,HM_Powermeter_1_SenU,HM_Powermeter_1_Sw,HM_Powermeter_2,HM_Powermeter_2_Pwr,HM_Powermeter_2_SenF,HM_Powermeter_2_SenI,HM_Powermeter_2_SenPwr,HM_Powermeter_2_SenU,HM_Powermeter_2_Sw,HM_Powermeter_3,HM_Powermeter_3_Pwr,HM_Powermeter_3_SenF,HM_Powermeter_3_SenI,HM_Powermeter_3_SenPwr,HM_Powermeter_3_SenU,HM_Powermeter_3_Sw,APC_USV,Stromzaehler
included with wildcard: 
excluded (0): 
excluded with wildcard:
2019.11.08 17:44:15 5: DbRep logdb_clean_3days - Readings for operation -
included (1): %
included with wildcard: 
excluded (0): 
excluded with wildcard:
2019.11.08 17:44:15 4: DbRep logdb_clean_3days - SQL execute: delete FROM history where ( DEVICE IN ('HM_Powermeter_1','HM_Powermeter_1_Pwr','HM_Powermeter_1_SenF','HM_Powermeter_1_SenI','HM_Powermeter_1_SenPwr','HM_Powermeter_1_SenU','HM_Powermeter_1_Sw','HM_Powermeter_2','HM_Powermeter_2_Pwr','HM_Powermeter_2_SenF','HM_Powermeter_2_SenI','HM_Powermeter_2_SenPwr','HM_Powermeter_2_SenU','HM_Powermeter_2_Sw','HM_Powermeter_3','HM_Powermeter_3_Pwr','HM_Powermeter_3_SenF','HM_Powermeter_3_SenI','HM_Powermeter_3_SenPwr','HM_Powermeter_3_SenU','HM_Powermeter_3_Sw','APC_USV','Stromzaehler') ) AND TIMESTAMP >= '2016-12-16 00:00:00' AND TIMESTAMP <= '2019-11-05 23:59:59' ;
2019.11.08 17:44:16 5: DbRep logdb_clean_3days - Number of deleted rows: 14105
2019.11.08 17:44:16 3: DbRep logdb_clean_3days - Entries of fhem.history deleted: HM_Powermeter_.//APC_USV/Stromzaehler--/--14105
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 November 2019, 19:46:43
Hi Frank,

good news !  8)
Ich teste auch bei mir noch etwas und wenn mir nichts mehr auffällt, checke ich den Stand heute Abend oder morgen ein.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 November 2019, 17:04:23
In meinem contrib befindet sich die weiterntwickelte Version 8.30.0.
Mit dieser Version gibt es nun die Möglichkeit, Datenbankoperationen mit einem privilegierten (administrativen) User auszuführen. Momentan kann man ihn bei den Sets "sqlCmd" und "index" verwenden.
Bei diesen beiden Commands war es mir als sinnvoll bzw. notwendig aufgefallen.

Dazu gibt es ein neues set/get/Attribut. Hier ein Auszug aus der comref:

* adminCredentials <User> <Passwort> - Speichert einen User / Passwort für den privilegierten bzw. administrativen Datenbankzugriff. Er wird bei Datenbankoperationen benötigt, die mit einem privilegierten User ausgeführt werden müssen. Siehe auch Attribut 'useAdminCredentials'.

* storedCredentials - Listet die im Device gespeicherten User / Passworte für den Datenbankzugriff auf.

* useAdminCredentials - Wenn gesetzt, wird ein zuvor mit "set <Name> adminCredentials" gespeicherter User für bestimmte Datenbankoperationen verwendet.

Wie immer freue ich mich über evtl. Tester.
Download aus meinem contrib über die Webeingabe:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Grüße und ein schönes WE,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ironalf am 22 Januar 2020, 12:09:28
Hallo Heiko,

ich betreibe eine FHEM Installation mit einer PostgreSQL.
Ich wollte mit Modul DbRep doppelte Einträge löschen.
Bei der Ausführung erhalte ich aber diese Fehlermeldung:
2020-01-22 11:54:35 CET [8618-695] fhem@fhem ERROR:  syntax error at or near "limit" at character 188
2020-01-22 11:54:35 CET [8618-696] fhem@fhem STATEMENT:  delete FROM history WHERE TIMESTAMP = '2003-12-13 00:00:00' AND DEVICE = 'Gas' AND READING = ' statTotal' AND VALUE = 'Hour: 0.00 Day: 0.00 Month: 00.00 Year: 39.89 (since: 2003-01-01 )' limit 1;
PostgreSQL unterstützt bei ,,update" und ,,delete" ,,limit" nicht.
Wäre es möglich das Modul so anzupassen, dass ,,delDoublets" auch bei PostgreSQL funktioniert.

Danke und VG
Alfons
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Januar 2020, 14:11:58
Hallo Alfons,

das passe ich gerne für Postgre noch an.
Könntest du eine für Postgre passende Syntax liefern, die Limit unterstützt ?
Wenn nicht, muss ich selbst erstmal forschen. Machbar sollte sein. Denke nicht dass Postgre soetwas generell nicht kennt.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ironalf am 23 Januar 2020, 12:42:59
Hallo Heiko,

Leider kann ich dir keine passende Syntax zur Verfügung stellen, ich kenne mich leider mit Datenbanken nicht wirklich aus.
Vielleicht hilft dir das weiter:
https://www.dataqualityapps.de/know-how/123-postgresql-nach-dubletten-suchen.html
https://stackoverflow.com/questions/5170546/how-do-i-delete-a-fixed-number-of-rows-with-sorting-in-postgresql

Danke und VG
Alfons
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: lichtimc am 23 Januar 2020, 13:17:30

Hallo DS_Starter,


fällt dir ein Grund ein, weshalb ich beim Setzen von:set DbRep adminCredentials root test
... immer folgende Fehlermeldung erhalte?:
Unknown argument adminCredentials, choose one of eraseReadings deviceRename adminCredentials


Ich danke dir für die Arbeit und deine Unterstützung!


lg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2020, 14:41:36
Zitatfällt dir ein Grund ein, weshalb ich beim Setzen von:set DbRep adminCredentials root test
... immer folgende Fehlermeldung erhalte?:
Ja, weil der Modulautor Mist gemacht hat.  ;)
Der Typ deines Device ist wahrscheinlich Agent. Ich wollte diesen Setter eigentlich nicht in einem Agenten setzbar machen, weil er diese Möglichkeit nicht haben soll. D.h. adminCredentials sollte nur im Set eines DbRep Typ Client erscheinen. Dort klappt auch das setzen aktuell.

Werde ich heute Abend mit korrigieren.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2020, 22:13:22
Hallo Alfons,

Zitat
Leider kann ich dir keine passende Syntax zur Verfügung stellen, ich kenne mich leider mit Datenbanken nicht wirklich aus.
Vielleicht hilft dir das weiter:
https://www.dataqualityapps.de/know-how/123-postgresql-nach-dubletten-suchen.html
https://stackoverflow.com/questions/5170546/how-do-i-delete-a-fixed-number-of-rows-with-sorting-in-postgresql

Danke für die Links. Ich habe schon einiges ausprobiert, aber bis jetzt nichts brauchbares gefunden. Entweder ist es schlicht nicht anwendbar weil keine eindeutige Zeilen-Id bei uns vorhanden ist oder die SQL ist derart langsam, dass es einfach so nicht nutzbar ist.
Ich schaue weiter ...

Wenn noch jemand etwas dazu beisteuern kann, dann nehme ich es gerne entgegen.

EDIT: Kaum habe ich es geschrieben, habe ich auch schon eine Lösung gefunden.  :D
Ich teste noch etwas und stelle das Modul zum Test zur Verfügung wenn ich soweit bin.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Januar 2020, 22:59:19
Hallo Alfons, @all,

ich habe die überarbeitete Version bereitgestellt. delDoublets klappt nun auch für PostgreSQL.

Liegt in meinem contrib.

Download, komplett mit "" so im FHEMWEB ausführen:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Danach FHEM restarten.

Probiers mal bitte bei dir/euch aus. Bei mir waren die Tests alle positiv.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: MarcusR am 24 Januar 2020, 00:38:56
Hallo DS_Starter,

nach Deinem Tip in https://forum.fhem.de/index.php/topic,92458.msg849985.html#msg849985 (https://forum.fhem.de/index.php/topic,92458.msg849985.html#msg849985) habe ich mir eine Backup-Lösung mit syncStandby aufgesetzt. Ich hatte die Funktion der Methode so verstanden, dass sie im konfigurierten Umfang und Fragmenten eine Datenbank zu einer anderen abgleicht und bereits kopierte Zeilen nicht ein zweites Mal kopiert. Vulgo 1-Wege-Sync. Ich meine auch, das hinreichend ausprobiert zu haben. Jetzt habe ich aber festgestellt, dass er jedes Mal, wenn ich die Methode aufrufe, die gleichen Zeilen wieder und wieder in die Zieldatenbank schreibt.

Hier meine beiden dbRep-Devices zum syncen:

define logdb.sync_daily DbRep logdb
setuuid logdb.sync_daily 5cfe4b71-f33f-c353-3373-1ae195c977a4b689
attr logdb.sync_daily aggregation day
attr logdb.sync_daily group Log
attr logdb.sync_daily room Technik
attr logdb.sync_daily timeDiffToNow d:2

define logdb.sync_weekly DbRep logdb
setuuid logdb.sync_weekly 5cfe4b71-f33f-c353-6026-7e7569a0d087caff
attr logdb.sync_weekly aggregation day
attr logdb.sync_weekly group Log
attr logdb.sync_weekly room Technik
attr logdb.sync_weekly timeDiffToNow d:10

define logdb.sync.timer at *00:15:00 {\
    if(  # Immer Montags\
($wday == 1)\
  ) \
{\
        Log (1,"logdb.sync.timer: wday: ".$wday.", Wochen-Sync wird durchgeführt.");;\
fhem("set logdb.sync_weekly syncStandby archivedb");;\
} else {\
Log (1,"logdb.sync.timer: Tages-Sync wird durchgeführt.");;\
fhem("set logdb.sync_daily syncStandby archivedb");;\
};;\
\
}
setuuid logdb.sync.timer 5cfe4b71-f33f-c353-7d83-4d282dae45c78845


Ein at-Device entscheidet dann einmal am Tag, ob der Tages- oder der Wochen-Sync aufgerufen wird.

Habe ich nun die Methode falsch verstanden (und auch mal falsch getestet) oder hat sich mit einem Update was an der Funktionalität geändert?

Viele Grüße
Marcus
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2020, 08:59:17
Guten Morgen Marcus,

das hast du nicht ganz richtig interpretiert.

ZitatIch hatte die Funktion der Methode so verstanden, dass sie im konfigurierten Umfang und Fragmenten eine Datenbank zu einer anderen abgleicht und bereits kopierte Zeilen nicht ein zweites Mal kopiert.
Nein, es werden die Datensätze , die durch die Zeit- ,Reading- ,Device- und auch valueFilter aus der Quelldatenbank in die Standby-Datenbank übertragen. Das passiert bei jedem Lauf.

Der Nutzer muss also selbst darauf achten nichts doppelt zu schreiben. Aber das ist reativ einfach.
Eine nicht ganz so elegante Methode ist, das at immer auf den Beginn eines Tages also 00:00:00 zu setzen und im DbRep Device timeDiffToNow d:1 zu setzen. Das würde ein doppeltes Schreiben verhindern.

Aber diese Methode hat Nachteile, weil diese Nahtlosigkeit nicht garantiert werden kann wenn mal ein System nicht da ist oder andere Umstände.

Deswegen ist es am effektivsten, in der Standby-Datenbank die history-Tabelle mit einem primary Key aufzubauen. Dann verhindert die DB von sich aus doppelte Einträge und du kannst dein Verfahren so lassen wie du es engstellt hast.

Du hast doch eine MySQL als Archiv wenn ich mich nicht irre. Dann dropst du am Besten deine history Tabelle in der Standby nochmal und erstellst sie neu mit einem primary Key so:


drop table history;

CREATE TABLE `fhemtest`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
ALTER TABLE `fhemtest`.`history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);


Dann kannst du neu Syncen und den Lauf so oft wiederholen wie du willst, die Zeiträume können sich dabei überlappen. Alles kein Problem. Die DB verhindert dass doppelte Einträge entstehen.

Wenn ich Zeit finde, erstelle ich auch mal einen Wiki-Beitrag dazu.
Probiers mal aus ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2020, 15:55:01
Hallo zusammen,

ich habe das ganze Verfahren zur Synchronisation einer Standby-Datenbank im Wiki genau beschrieben.
Falls Fragen/Ergänzungen bestehen ... gerne melden.

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2020, 21:19:52
Ich habe die Logausgaben für den Befehl syncStandby noch etwas verbessert.


2020.01.24 20:47:09.383 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 14930
2020.01.24 20:47:48.007 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 168164
2020.01.24 20:48:17.547 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 132427
2020.01.24 20:48:39.390 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 100402
2020.01.24 20:49:02.580 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 99906
2020.01.24 20:49:27.012 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 99685
2020.01.24 20:49:46.452 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 86970
2020.01.24 20:49:46.453 3: DbRep Rep.LogDB1.syncStandby - number of lines inserted into "LogStby": 20705


Es werden sowohl die an die Standby-Datenbank übertragenen Datensätze (total lines transfered) als auch die davon tatsächlich eingefügten Datensätze (number of lines inserted) getrennt voneinander ausgewiesen. Die "number of lines inserted" werden im Reading "number_lines_inserted_Standby" ausgegeben.
Damit sieht man deutlich wie der primary Key wirkt und das doppelte Datensätze vermieden werden.

Die Version 8.30.7 liegt noch in meinem contrib, Download mit:

Zitat
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ironalf am 25 Januar 2020, 11:31:14
Zitat von: DS_Starter am 23 Januar 2020, 22:59:19
Hallo Alfons, @all,

ich habe die überarbeitete Version bereitgestellt. delDoublets klappt nun auch für PostgreSQL.

Liegt in meinem contrib.

Download, komplett mit "" so im FHEMWEB ausführen:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Danach FHEM restarten.

Probiers mal bitte bei dir/euch aus. Bei mir waren die Tests alle positiv.

Grüße,
Heiko

Hallo Heiko,

ich habe es getestet und es hat funktioniert.

Danke und viele Grüße
Alfons
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Januar 2020, 12:55:53
Danke für die Rückmeldung Alfons. Dann checke ich die Version heute ein. Sie ist dann morgen früh im Regelupdate enthalten.
Da hat sich dann einiges getan. Ihr seht es dann in den Updatehinweisen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Januar 2020, 14:39:45
Ich weiß nicht mehr wo/wann genau es war, aber es gab mal einen Featurerequest eines Users um bei der Ausführung von maxValue alle anderen Datensätze außer dem Datensatz mit dem maximum Wert zu löschen.
Das habe ich nun umsetzt. Es gibt eine Option "deleteOther" beim maxValue.

* maxValue [display | writeToDB | deleteOther]
.....

Wird die Option deleteOther verwendet, werden alle Datensätze außer dem Datensatz mit dem ermittelten Maximalwert aus der Datenbank innerhalb der definierten Grenzen gelöscht. 
....


Die Version 8.31.0 liegt in meinem contrib zum Test bereit wer mag.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


Danach FHEM restart.

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Januar 2020, 11:28:30
Habe die Option deleteOther auch noch für die minValue-Funktion verfügbar gemacht.
Die neue DbRep Version 8.32.0 ist eingecheckt und morgen früh im Regelupdate enthalten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: booster am 07 Februar 2020, 21:52:12
Hallo, das mit der neuen Funktion bei maxValue und deleteOther werden die maximalen Werte aller devices pro aggregation zusammengelegt und nur der höchste (egal von welchem device) behalten und der Rest gelöscht. Somit werden die maxWerte der anderen auch mit gelöscht.
Ich dachte das die Funktion jedes Device/Reading Eigenständig betrachtet und den maxValue ermittelt.

Auch habe ich festgestellt, das bei einem delEntries Aufruf mit timeolderthan 30 Tagen nicht alle Werte bis in die Vergangenheit bearbeitet bzw. gelöscht werden. Es wird nur eine bestimmte Anzahl gelöscht. Gibt es da eine Begrenzung im Modul?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2020, 22:05:27
ZitatIch dachte das die Funktion jedes Device/Reading Eigenständig betrachtet und den maxValue ermittelt.
Der User gibt ja in den Attributen device/reading an welche Devices/Readings betrachtet werden sollen. Der User muss dafür Sorge tragen, dass die "richtigen" bearbeitet werden. Works as designed.

Zitat
Auch habe ich festgestellt, das bei einem delEntries Aufruf mit timeolderthan 30 Tagen nicht alle Werte bis in die Vergangenheit bearbeitet bzw. gelöscht werden. Es wird nur eine bestimmte Anzahl gelöscht. Gibt es da eine Begrenzung im Modul?
Eine Begrenzung gibt es nicht und ich kann es momentan auch nicht nachvollziehen. Du müsstest mal verbose 4 einschalten und ein Log eines Laufs von delEntries posten. Möglichst ein List vom Device noch dazu.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: booster am 07 Februar 2020, 22:47:56
Ich habe von 2017 bis heute Datensätze in der Datenbak und wollte die jetzt ausdünnen. Mit deinem Tool kann man das sehr gut machen., jedoch bearbeitet es nicht alle Werte.


DBrep ist wie folgt definiert
efmod DBLogging_DbRep_Cleaner3 DbRep DBLogging
attr DBLogging_DbRep_Cleaner3 aggregation day
attr DBLogging_DbRep_Cleaner3 alias Datenbank-Log Cleaner SeqDoublets (DbRep)
attr DBLogging_DbRep_Cleaner3 allowDeletion 1
attr DBLogging_DbRep_Cleaner3 comment Löschen von aufeinander folgenden identische Datensätzen.
attr DBLogging_DbRep_Cleaner3 devStateIcon .*connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr DBLogging_DbRep_Cleaner3 device cnKW271Brenner
attr DBLogging_DbRep_Cleaner3 group Logging
attr DBLogging_DbRep_Cleaner3 icon recycling
attr DBLogging_DbRep_Cleaner3 reading countsPerDay
attr DBLogging_DbRep_Cleaner3 room Logs
attr DBLogging_DbRep_Cleaner3 showproctime 1


Wenn ich die Werte in der DB zähle dann dürften max. 1500...2000 Werte nach der ausführung von maxValue deleteOther enthalten sein. Jedoch habe ich noch ca. 200000 Werte in der Datenbank. Im Plot kann ich erkennen, das die Datensätze nur von etwa 1 Jahr gelöscht wurden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2020, 23:02:37
Naja wie gesagt, poste mal bitte ein verbose 4 Log von einem Delete Lauf. Man muß sich die SQL-Statements anschauen können die ausgeführt werden, sonst kann man nichts sagen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: booster am 08 Februar 2020, 07:41:18
Bitte entschuldige, hier der Log Eintrag.

2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - -------- New selection ---------
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Command: delEntries
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - timeOlderThan - year: , day: 90, hour: , min: , sec:
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Year 2020 is leap year
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - startMonth: 9 endMonth: 10 lastleapyear: 2020 baseYear: 2019 diffdaylight:0 isdaylight:0
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - FullDay option: 0
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Timestamp begin human readable: 2017-10-29 22:35:56
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Time difference to current time for calculating Timestamp end: 7862401 sec
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Timestamp end human readable: 2019-11-09 07:24:01
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - Aggregation: no
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - SQL execute: delete FROM history where ( DEVICE IN ('MAX_0f8852','MAX_0f8880','MAX_0f8983','MAX_0ffd00','MAX_10176e','MAX_1056a0','MAX_11b8a6','MAX_11b8a9','MAX_1483f9','MAX_16434e','MAX_1663b9','MAX_185056','Garage','Heizungsraum','WW_Ausgang','WW_Zirkulation','HK1_RL','HK1_VL','HK2_RL','HK2_VL','ESPEasy1','ESPEasy_esp1_SONOFF_TH10_clima','ESPEasy_esp1_SONOFF_TH10_output','xiaomiButton1','xiaomiButton2','xiaomiButton3','xiaomiTempSensor1','xiaomiTempSensor2','HM_4D1493_IEC_01','Shelly_DRHZ_N','Shelly_DRHZ_SW','Shelly_TeichPumpe') ) AND TIMESTAMP >= '2017-10-29 22:35:56' AND TIMESTAMP <= '2019-11-09 07:24:01' ;
2020.02.08 07:24:02 4: DbRep DBLogging_DbRep_Cleaner1 - execute command after delEntries: 'setstate IFTimeDBcleanFHEM -'
2020.02.08 07:24:02 3: DbRep DBLogging_DbRep_Cleaner1 - Entries of fhem.history deleted: MAX.//Garage/Heizungsraum/WW.//HK.//ESPEasy.//xiaomi.//HM_4D1493_IEC_01/Shelly./--/--0


und die configuration

defmod DBLogging_DbRep_Cleaner1 DbRep DBLogging
attr DBLogging_DbRep_Cleaner1 alias Datenbank-Log Cleaner (DbRep) (90d)
attr DBLogging_DbRep_Cleaner1 allowDeletion 1
attr DBLogging_DbRep_Cleaner1 comment Löschen von Einträgen welche älter als 90 Tage sind.
attr DBLogging_DbRep_Cleaner1 devStateIcon .*connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr DBLogging_DbRep_Cleaner1 device MAX.*,Garage,Heizungsraum,WW.*,HK.*,ESPEasy.*,xiaomi.*,HM_4D1493_IEC_01,Shelly.*
attr DBLogging_DbRep_Cleaner1 event-on-change-reading state
attr DBLogging_DbRep_Cleaner1 event-on-update-reading state
attr DBLogging_DbRep_Cleaner1 executeAfterProc setstate IFTimeDBcleanFHEM -
attr DBLogging_DbRep_Cleaner1 group Logging
attr DBLogging_DbRep_Cleaner1 icon recycling
attr DBLogging_DbRep_Cleaner1 room Logs
attr DBLogging_DbRep_Cleaner1 showproctime 1
attr DBLogging_DbRep_Cleaner1 timeOlderThan d:90
attr DBLogging_DbRep_Cleaner1 verbose 4


Bei mir wurden jetzt seltsamerweise doch die Einträge gelöscht. Nach der Ausführung hat es noch ca. 1/2 Tag gedauert bis diese aus der DB verschwunden sind. Bin grad etwas verwirrt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2020, 08:09:15
Guten Morgen,

danke fürs Log. Also das SQL-Statement ist absolut in Ordnung und tut das was du möchtest.
Als Tipp ... du verwendest im Attribut device DevSpec (HK.*,ESPEasy.*,xiaomi.*...) also Regex. Das ist auch absolut in Ordnung und ist so vorgesehen. Aber man muss dazu wissen, dass in diesem Fall die realen Devices für den Select anhand der aktuell im System vorhandenen Geräte aufgelöst werden.
Sind alte Devices in der DB, werden die nicht aufgelöst und auch nicht gelöscht. Das würde man aber in der IN-Klausel des SQLs sehen bzw. die Devices dort vermissen.
In solchen Fällen benutzt man dann SQL-Wildcard (%) was aber deutlich langsamer arbeitet.

ZitatNach der Ausführung hat es noch ca. 1/2 Tag gedauert bis diese aus der DB verschwunden sind. Bin grad etwas verwirrt.
Das wäre ich auch.  :)   Nach dem Löschen muss die DB noch einen Commit durchführen um die Einträge tatsächlich zu entfernen. Allerdings ist der Löschlauf in dieser Zeit noch im state "running" und noch nicht fertig. 1/2 Tag wäre aber auch extrem lang.
Wie schnell ist denn deine DB so ? (Reading sql_processing_time).

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: booster am 08 Februar 2020, 08:10:20
Ich hab da nochmal eine Frage zu dem maxValue Thema in bezug mit dem deleteOther. Wie kann ich mit einem dbRep-Device eine Vielzahl an Einträgen bearbeiten, so das die Readings pro device immer betrachtet werden? Es soll jedes Reading aus der reading-list einzel bearbeitet werden.

Device: A, B, C
Reading Atest1, Atest2, Btest1, Btest2, Ctest1

Ich möchte gerne vom jedem Reading den maxValue einzeln erhalten, und nicht den maxValue von den zusammengefassten Readings.

Mit dieser Config habe ich es versucht, aber das ist falsch,. Wie mache ich das besser, bzw. geschickter?

Das ist ein Setting nur für ein Device und Reading was funktioniert wie ich es mir vorstelle.
defmod DBLogging_DbRep_Calc2 DbRep DBLogging
attr DBLogging_DbRep_Calc2 aggregation day
attr DBLogging_DbRep_Calc2 alias Datenbank-Log Calc2 (DbRep) (Shrink) (90d)
attr DBLogging_DbRep_Calc2 allowDeletion 1
attr DBLogging_DbRep_Calc2 comment Ermittelt die täglichen Maximalwerte von Einträgen und entfernt die restlichen welche älter als 90 Tage sind.
attr DBLogging_DbRep_Calc2 devStateIcon .*connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr DBLogging_DbRep_Calc2 device cnKW271Brenner
attr DBLogging_DbRep_Calc2 event-on-change-reading state
attr DBLogging_DbRep_Calc2 event-on-update-reading state
attr DBLogging_DbRep_Calc2 group Logging
attr DBLogging_DbRep_Calc2 icon edit_settings
attr DBLogging_DbRep_Calc2 reading countsPerDay
attr DBLogging_DbRep_Calc2 room Logs
attr DBLogging_DbRep_Calc2 showproctime 1
attr DBLogging_DbRep_Calc2 timeOlderThan d:90



Und das ist mein Problemkind.

  - device: myElectricityCalc
  - reading: HM_4D1493_IEC_01_energyCounterValue_EnergyDay,HM_4D1493_IEC_01_energyCounterValue_EnergyMonth,HM_4D1493_IEC_01_energyCounterValue_EnergyYear,HM_4D1493_IEC_01_energyCounterValue_EnergyDayLast,HM_4D1493_IEC_01_energyCounterValue_EnergyMonthLast,HM_4D1493_IEC_01_energyCounterValue_EnergyYearLast,HM_4D1493_IEC_01_energyCounterValue_EnergyMeter
  - aggregation: day


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2020, 08:44:43
DbRep ist ganz allgemein so aufgebaut, dass man für jede Aufgabe ein Device erstellt, es parametrisiert und dann damit (regelmäßig) arbeitet. Also nicht ständig umkonfiguriert.

In deinem speziellen Fall wirst du also nicht drumherum kommen mehrere Devices zu erstellen und sie so einzustellen dass nur die in einem Lauf zu berücksichtigenden Device/Reading-Kombinationen berücksichtigt werden.

Das klingt jetzt aufwändig, ist es aber nicht wirklich. Ich kopiere dazu immer ein bereits erstelltes (und schon ähnlich eingestelltes Device) und passe es dann nur noch an.

Wenn es z.B. das Reading HM_4D1493_IEC_01_energyCounterValue_EnergyMonth  in allen Devices A,B,C gibt und über alle drei Devices (zusammen !) der Max-Wert dieses Readings ermittelt werden soll, reicht ein DbRep-Device mit devices = A,B,C und reading = HM_4D1493_IEC_01_energyCounterValue_EnergyMonth.

Sonst müsstest du weitere Devices erstellen und auch das Attr devices weiter aufdröseln.

Eine weitere Variante wäre ein eigenes, spezifisches  SQL zu entwerfen welches alle relevanten Devices und Readings getrennt voneinander ermittelt und als Reading ausgibt. Das geht mit "set ... sqlCmd". Dazu braucht man ein paar SQL-Kenntnisse oder Hilfe im Forum.
Dann kann man delEntries in einem zweiten DbRep anwenden mit dem Attr valueFilter welches so engestellt wird, dass Datensätze mit diesem Wert nicht gelöscht werden. Das ganze Verfahren ließe sich mit der userExitFn noch verknüpfen und automatisieren.

Also die zweite Alternative ist schon recht anspruchsvoll und mit Eigeninitiative verbunden, aber dafür absolut flexibel und elegant individeull angepasst lösbar.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: MarcusR am 11 Februar 2020, 14:13:56
Zitat von: DS_Starter am 24 Januar 2020, 08:59:17
Guten Morgen Marcus,

das hast du nicht ganz richtig interpretiert.
Nein, es werden die Datensätze , die durch die Zeit- ,Reading- ,Device- und auch valueFilter aus der Quelldatenbank in die Standby-Datenbank übertragen. Das passiert bei jedem Lauf.

Der Nutzer muss also selbst darauf achten nichts doppelt zu schreiben. Aber das ist reativ einfach.
Eine nicht ganz so elegante Methode ist, das at immer auf den Beginn eines Tages also 00:00:00 zu setzen und im DbRep Device timeDiffToNow d:1 zu setzen. Das würde ein doppeltes Schreiben verhindern.

Aber diese Methode hat Nachteile, weil diese Nahtlosigkeit nicht garantiert werden kann wenn mal ein System nicht da ist oder andere Umstände.

Deswegen ist es am effektivsten, in der Standby-Datenbank die history-Tabelle mit einem primary Key aufzubauen. Dann verhindert die DB von sich aus doppelte Einträge und du kannst dein Verfahren so lassen wie du es engstellt hast.

Du hast doch eine MySQL als Archiv wenn ich mich nicht irre. Dann dropst du am Besten deine history Tabelle in der Standby nochmal und erstellst sie neu mit einem primary Key so:


drop table history;

CREATE TABLE `fhemtest`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
ALTER TABLE `fhemtest`.`history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);


Dann kannst du neu Syncen und den Lauf so oft wiederholen wie du willst, die Zeiträume können sich dabei überlappen. Alles kein Problem. Die DB verhindert dass doppelte Einträge entstehen.

Wenn ich Zeit finde, erstelle ich auch mal einen Wiki-Beitrag dazu.
Probiers mal aus ...

LG,
Heiko

Hi Heiko,

ich habe mir nun mit der (periodisch aufgerufenen) Methode delDoublets beholfen, das funktioniert ganz gut. Bei einem zusammengesetzten Schlüssel hatte ich Bedenken, dass bei iner Schlüsselverletzung die ganze Transaktion fehlschlägt, und ich das irgendwie überwachen muss  ::)

Aber das rauslöschen der Dubletten klappt gut, vielen Dank !

Viele Grüße
Marcus
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2020, 15:00:43
Hi Marcus,

ZitatBei einem zusammengesetzten Schlüssel hatte ich Bedenken, dass bei iner Schlüsselverletzung die ganze Transaktion fehlschlägt, und ich das irgendwie überwachen muss
Brauchst keine Bedenken haben. Genau diese Möglichkeit habe ich im Modul berücksichtigt.

Aber schön dass du eine Lösung für dich gefunden hast.  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 06 März 2020, 16:02:00
Hallo Heiko,

im Modul gibt es die Dump-Option und auch einen Restore dieser Files.

Ist es igendwie möglich, dem Dump einen Zeitraum mitzugeben?

Mir ist heute beim automatisierten Backup meine Installation abgeraucht. Fhem-Container lief noch halbwegs (unhealthy) aber auf die DB kam ich nicht mehr. Habe nicht näher analysiert sondern das Backup von gestern zurückgespielt. Keine Zeit für Analyse ... dadurch fehlen mir 24 Stunden (etwas weniger da ich den Cache der DBLog noch gesichert hatte).

Ich würde gerne einen stündlichen Dump machen. Ein voller Dump stündlich ist mir zu groß. Eine Art Incremential Backup. Irgend eine Idee? Es soll kein Feature-Request sein da zu speziell, dachte nur wenn es irgendwie so geht wäre das schön. Wenn es nicht geht dann mache ich das per cron ..

Das SQL ist relativ einfach ... select * from history where timestamp > "jetzt -1 Stunde" ... und das in ein SQL-Dumpfile damit auch Restore funktioniert.

Danke dir!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 März 2020, 16:28:24
Es gibt aktuell noch die Funktion exportToFile  bzw. importFromFile.
Dort kannst du Zeitgrenzen eingeben und theoretisch auch Devices/Readings abgrenzen.

Es entstehen dabei CSV-Files die du wieder einspielen kannst bei Bedarf.

Zum Beispiel könntest du ein Full-Dump machen und jeden Tag / Stunde (what ever) danach mit  exportToFile  Daten aus der DB schreiben.
Wenn du die Zeitattribute z.B. auf previous_day_begin und current_day_end setzt, hast du immer genügend Überschneidung der Zeitscheiben.
Beim Import stört das nicht wenn du in der DB history einen primary key gesetzt hast, sodass keine doppelten Datensätze entstehen. (Ich glaube den hast du wenn ich mich nicht irre.)

Würde dir das reichen ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 06 März 2020, 17:25:09
Zitat von: DS_Starter am 06 März 2020, 16:28:24
Würde dir das reichen ?

Hi, das reicht. Habe ich in der Commandref übersehen. Das suche ich, teste ich mal. Vielen DAnk!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 10 März 2020, 18:09:53
Hallo Heiko,

ich habe FHEM neu eingerichtet und möchte die Verbindung zu Synology / MariaDB testen (bisher mySQL im gleichen System). Geht leider nicht, die "adminCredentials" fallen mir auf die Füße.
Ich habe aus dem produktiven FHEM (gleicher Softwarestand) aus der fhem.cfg die DB- und DbRep-Definitionen in das neue Umfeld kopiert.
Der Zugriff auf die DB als solches ist lt. Log auch möglich.
Jetzt wollte ich im DbRep-Device folgendes ausführen:
set <name> index recreate_Report_Idx
Dabei bekomme ich die Fehlermeldung: "errortext Can't use admin credentials for database access, see logfile"
Ich habe aber gar keine adminCredentials definiert. Müsste dann doch eigentlich auch so gehen oder? Und falls ich sie dennoch benötige: wie ist denn die Syntax in der Eingabe? Vor allem, wenn das aktuelle Passwort leer ist? Auch "useAdminCredentials" benutze ich nicht.

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 März 2020, 18:25:17
Hi Holger,

das ist sicherlich ein Fehler. Mach bitte noch ein verbose 4 log. Ich schaue es mir nachher an, bin noch unterwegs.

Grüsse,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 10 März 2020, 19:48:29
Hallo Heiko,

verbose 4 habe ich im DbRep-Device gesetzt, als Ausgabe nach
set rep.myFHEMdb index recreate_Report_Idx kommen nur die folgenden Zeilen im Log:

2020.03.10 19:43:27 3: DbRep rep.myFHEMdb - ################################################################
2020.03.10 19:43:27 3: DbRep rep.myFHEMdb - ###                    New Index operation                   ###
2020.03.10 19:43:27 3: DbRep rep.myFHEMdb - ################################################################
2020.03.10 19:43:27 3: DbRep rep.myFHEMdb - Command: index recreate_Report_Idx
2020.03.10 19:43:27 2: DbRep rep.myFHEMdb - ERROR - adminCredentials not set. Use "set rep.myFHEMdb adminCredentials" first.
2020.03.10 19:43:27 2: DbRep rep.myFHEMdb - ERROR - admin credentials are needed for database access, but can't use it


Zur Vervollständigung noch ein list vom DbRep-Device:
Internals:
   DATABASE   myFHEMdb
   DEF        myFHEMdb
   FUUID      5e67dee9-f33f-e100-c079-e1841c04d7584c99
   FVERSION   93_DbRep.pm:v8.32.2-s21329/2020-03-01
   LASTCMD    index recreate_Report_Idx
   MODEL      Client
   NAME       rep.myFHEMdb
   NOTIFYDEV  global,rep.myFHEMdb
   NR         17
   NTFY_ORDER 50-rep.myFHEMdb
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE myFHEMdb
     GRANTS     DELETE,INSERT,USAGE,UPDATE,SELECT
     IDRETRIES  3
     MINTS      2020-03-10 17:03:15
     PACKAGE    main
     VERSION    8.32.2
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       background_processing_time:
         myFHEMdb:
           TIME       1583865617.58589
           VALUE      0.0040
       errortext:
         myFHEMdb:
           TIME       1583865807.34897
           VALUE      Can't use admin credentials for database access, see logfile !
       index_state:
         myFHEMdb:
           TIME       1583865617.58589
           VALUE      Index Report_Idx doesn't exist. Please create the index by "set rep.myFHEMdb index recreate_Report_Idx" command !
       sql_processing_time:
         myFHEMdb:
           TIME       1583865617.58589
           VALUE      0.0023
       state:
         myFHEMdb:
           TIME       1583865807.35082
           VALUE      error
   OLDREADINGS:
   READINGS:
     2020-03-10 19:43:27   errortext       Can't use admin credentials for database access, see logfile !
     2020-03-10 19:43:27   state           error
Attributes:
   allowDeletion 1
   device     KG.Flur.Thermostat,KG.Werkzeug.Thermostat
   expimpfile /opt/fhem/backup/exp_myFHEMdb.sql
   icon       time_note
   reading    measured-temp
   room       Technik->DbLog
   showproctime 1
   timestamp_begin 2019-11-01 00:00:00
   timestamp_end 2019-11-01 10:44:00
   verbose    4


LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 März 2020, 21:24:02
Hallo Holger,

jetzt hab ich es wieder ... dem DB-User fehlen die Rechte gemäß commandref:

Zitat
Der verwendete Datenbank-Nutzer benötigt das ALTER, CREATE und INDEX Privileg.

Da die nicht vorhanden sind versucht das Modul den Admin-User zu verwenden der auch nicht gesetzt ist.
Du müstest also entweder dem verwendeten DB-User diese Rechte zuweisen oder einen Admin-User mit Passwort setzen:


set <name> adminCredentials <User> <Passwort>


Einen Admin-User ohne Passwort habe ich bis jetzt aus Security Gründen nicht vorgesehen.
Aber ich werde die Log-Ausschriften etwas abändern damit man gleich darauf kommt.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Omega am 10 März 2020, 22:55:58
Hallo Heiko,

danke, jetzt habe ich es auch verstanden und korrekt umsetzen können (weiteren User angelegt mit entsprechenden Rechten und Passwort und den dann eingetragen).
Prompt hat alles funktioniert.

Danke noch einmal und einen schönen Abend.

LG
Holger
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 März 2020, 22:59:42
Danke, dir auch.
Die Dbrep Version mit ein paar aussagefähigeren Logeinträgen für diesen Fall checke ich noch ein und ist morgen früh im Update.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 März 2020, 18:37:38
Hallo,
ich habe da ein SQL Problem mit einer MariaDB / MSQL DB und finde den SQL Fehler nicht.


MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE,LAG(VALUE) OVER w AS 'DELTA' FROM history WINDOW w AS (ORDER BY TIMESTAMP) where DEVICE = 'PV_Anlage_1' AND TIMESTAMP > "2020-03-14_00:00:00";
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'w AS 'DELTA' FROM history WINDOW w AS (ORDER BY TIMESTAMP) where DEVICE = 'PV_Anla' at line 1


Hier waere die mysql Doku https://dev.mysql.com/doc/refman/8.0/en/window-function-descriptions.html#function_lag (https://dev.mysql.com/doc/refman/8.0/en/window-function-descriptions.html#function_lag)
mit diesem Beispiel

mysql> SELECT
         t, val,
         LAG(val)        OVER w AS 'lag',
         LEAD(val)       OVER w AS 'lead',
         val - LAG(val)  OVER w AS 'lag diff',
         val - LEAD(val) OVER w AS 'lead diff'
       FROM series
       WINDOW w AS (ORDER BY t);
+----------+------+------+------+----------+-----------+
| t        | val  | lag  | lead | lag diff | lead diff |
+----------+------+------+------+----------+-----------+
| 12:00:00 |  100 | NULL |  125 |     NULL |       -25 |
| 13:00:00 |  125 |  100 |  132 |       25 |        -7 |
| 14:00:00 |  132 |  125 |  145 |        7 |       -13 |
| 15:00:00 |  145 |  132 |  140 |       13 |         5 |
| 16:00:00 |  140 |  145 |  150 |       -5 |       -10 |
| 17:00:00 |  150 |  140 |  200 |       10 |       -50 |
| 18:00:00 |  200 |  150 | NULL |       50 |      NULL |
+----------+------+------+------+----------+-----------+
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2020, 19:26:19
Ich muß vorausschicken dass ich die Windows function mit over nicht kenne bzw. noch nicht benutzt habe. Hatte noch keinen Anwendungsfall bei dem ich es gebraucht hätte.

Aber ich würde erstmal schauen ob deine DB Version so etwas überhaupt kann. Bei MariaDB hat man es erst ab Version 10.2 implementiert soweit ich weiß.
Die Syntax ist hier beschrieben: https://mariadb.com/kb/en/window-functions-overview/

Setzt du MariaDB oder MySQL ein und in welcher Version ?

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2020, 20:00:32
Dieses Statement läuft bei mir:


SELECT TIMESTAMP,DEVICE,READING,VALUE,LAG(VALUE) OVER (ORDER BY TIMESTAMP) AS DELTA FROM history where DEVICE = "MySTP_5000" AND TIMESTAMP > "2020-03-14 00:00:00";


Version 10.3.21-MariaDB
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 März 2020, 09:29:18
Okay,
ich habe einfach einen Docker Container verwendet. Der ist wohl zu alt.


MySQL [fhem]> select version();
+-----------------+
| version()       |
+-----------------+
| 5.5.60-0+deb7u1 |
+-----------------+


Hast Du einen Link zu einem aktuellen Container und ne Schnellanleitung fuer den Umzug?
Einen Dump mit DBRep habe ich schon getestet, das wird sicher der schnellste weg sein.
Welches MySQL oder Maria Image verwendet Ihr? Am liebsten waere mir ein Docker Container, weil man ja nicht alles selber machen kann :-)

Im Container habe ich mal einen update versucht...

root@raspberrypi:/# apt-get install mysql-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
mysql-server is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
root@raspberrypi:/#
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 März 2020, 12:09:57
Hi Christian(?),

ZitatWelches MySQL oder Maria Image verwendet Ihr? Am liebsten waere mir ein Docker Container, weil man ja nicht alles selber machen kann :-)
Ich selbst benutze Docker im DB Umfeld nicht sondern verwende die Pakete auf meiner Synology und greife remote darauf zu.

Aber wie sieht es damit aus ?  -> https://hub.docker.com/r/mariadb/server

Scheint mir perfekt.
Ansonsten wäre es vielelicht besser für diese Frage einen separaten Thread aufzumachen. Sonst denke ich geht die Fragestellung hier möglicherweise unter.

Für den Umzug....
Zitat
Einen Dump mit DBRep habe ich schon getestet, das wird sicher der schnellste weg sein.
Ja, passt.
Alternativ würde ich persönlich, weil meine DB auch schon recht groß ist, die Variante mit Standby-DB wählen. Beschrieben habe ich es hier im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Vorteil ist, dass das Ganze smooth parallel im Hintergrund abläuft. Wenn man zu Beginn wegen fehlender Übung Fehler macht ist das auch nicht kritisch. Standby gelöscht und neu created -> neuer Versuch bis es rennt.

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 März 2020, 18:38:02
Hallo Heiko,

vielen Dank fuer die Tipps.
Ich habe mir DBRep mal naeher angeschaut, da ist so wie ich das sehe alles drin, was ich brauche. Somit macht es sinn, dass ich da erst mal weiter mache.

Mein Export ist erst 890 MB gross und ich raeme immer sehr streng auf. Was interessiert mich das wetter von vor drei Monaten ;-)
Firmenbedingt stehe ich auch eher auf Hotstandby DB, aber alles zu seiner Zeit und es sollte im Rahmen bleiben.

Viele Gruesse
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 16 März 2020, 10:43:52
Hallöchen zusammen,

ich habe mein Aufräumwahn lange nicht mehr aktiv gehabt, weil ich (auf dem LiveSystem) relativ gute Einstellungen hinbekommen hab um möglichst viele Infos mit mögichst wenigen Daten zu bekommen. Auf dem Testsystem läuft aktuell ein Wetter Modul mit einem neuen Gerät, was ich mir angeschafft hab und 4 Stromzähler. Dass hier die Daten nicht klein gehalten werden können, ist klar  :o

onTopic:
Zitat von: DS_Starter am 08 November 2019, 16:25:35
in meinem contrib liegt die Version 8.29.0.
In dieser Version habe ich wie versprochen ein Feature zur FullDay-Erweiterung eingebaut, welches hier https://forum.fhem.de/index.php/topic,104710.msg986236.html#msg986236 requestet/besprochen wurde.

Ich hätte gern die Wetter Daten so detailliert wie sie sind - Allerdings nur für 7 Tage. Danach sollen sie zusammengefasst werden (reduceLog)
Allerdings habe ich auch noch andere Daten, die erst nach 30 oder 60 Tagen in ReduceLog zusammen gefasst werden sollen.

Wie löst man das mit den neuen Attributen "timeDiffToNow" und "timeOlderThan"?

Hier kann ich nach meinem Verständniss lediglich einmal älter als angeben und nicht mal 7 mal 30 mal 60 Tage  ???

Edith ergänzt noch: Entweder ich habe es übersehen oder was war vorher auch besser zu löschen? Wenn ich jetzt über delEntries nicht aufpasse und falschen Tag drin hab, lösche ich mehr als gewollt. Da muss ich sagen fand ich die vorherige Einschränkung  "delentries XX[:yy] besser, weil man BEWUSST bei jedem löschen einen Zeitraum angegeben hab und nicht auf ein Attribut zurück gegriffen hat  :-\

Für jegliche Tipps, vielen Dank im Voraus
Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 16 März 2020, 11:12:08
Hallo Andreas,
Wie wäre ein DBRep Device pro Anforderung?
Gruß Christian

Gesendet von meinem SM-G930F mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 16 März 2020, 11:15:57
Hai Christian,

Zitat von: ch.eick am 16 März 2020, 11:12:08
Wie wäre ein DBRep Device pro Anforderung?

wäre eine Möglichkeit..... Ich finde sie nur .....sagen wir.... unsinnig. Ich habe ja dann schon pro automatisiertes Bereinigung ein at (oder ähnliches). Dann ein zusätzliches RepDevice, dann steigt die Anzahl unnötig hoch ?
Mit Optionen kann ich es bewusst nur für diese eine Ausführung machen und nicht "aus versehen" falsche Anzahl an Tagen löschen.

Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2020, 11:38:10
Hallo Andreas,

Zitat
Ich habe ja dann schon pro automatisiertes Bereinigung ein at (oder ähnliches). Dann ein zusätzliches RepDevice, dann steigt die Anzahl unnötig hoch ?

Christian hat schon recht mit mehreren DbReps für die unterschiedlichen Anforderungen. Allerdings kannst du das alles mit nur  einem at Device antriggern. Stichwort heisst Chain mit den Attribut executeAfterProc.
Ich glaube ich habe es im Wiki näher erläutert, wenn nicht, kann ich heute Abend weiter unterstützen. Habe grad keine Zeit.

Die Verwendung von Attr statt Optionen ist wie immer Ansichtssache. Andere User sagen sie möchten es lieber einmal fest einstellen und die Einstellung kontrollieren, dann kann man sich nicht durch Unachtsamkeit vertippen.  ;)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 16 März 2020, 15:30:42
Hallo Heiko,

auch Dir vielen Dank für die schnelle Antwort  :)

Die Ausführungen mit den at muss ich mir nochmal genauer anschauen. Diese Attribute sagen mir bis dato nichts. Muss ich aber dann in Ruhe mal lesen  ;)

Was die Optionen in den Befehlen angeht:
Als ich mal ein Hilfs"device" (war kein Modul, sondern eine universell einsetzbare myUtils Erweiterung) vorgestellt habe (jaja es war eine sehr sehr kleine, meine erste und ich war irgendwie sehr stolz drauf  ;D), wurde mir u.a auch der Hinweis gegeben solche Angaben eben über Optionen oder (damit sie nicht jedes Mal eingetippt werden müssen, aber dennoch anpassbar sind) diese als readings zu machen.
Hat eben den Vorteil dass man automatisiert Optionen anpassen kann UND es nicht das Böse Fragezeichen in der Config gibt, weil Attribute geändert wurden......

Mir ist es einfach aus dem Grund aufgefallen, weil ich meine Testsystem Datenbank genauso aufräumen wollte wie damals meine LiveSystem. Dort waren dann eben schnelle Anpassungen möglich lösche älter als x... Lösche älter als y wenn..... Usw. ReducelLog 60 xy.....  ReducelLog 30....... Reduce log 7......  Das war eine Sache  von wenigen Minuten.

Nun muss ich jedesmal die Attribute ändern und wehe ich vertippe mich hier mal oder vergesse d:7 aufd:60 zu ändern vor dem Löschen.... Dann ist eine Menge weg  :-[
Ich persönlich sehe hier die viel größeren Gefahren als ein einfaches Vertippen. Wenn man ehrlich ist, nutzt kaum ein Anfänger dieses Tool.
Ich habe zb früher mal was mit Datenbanken gemacht aber erst nach ca. 1 jahr  von Log datei auf DBLog umgestellt.... Config bis heute nicht getraut -.-

Viele Grüße
Andreas

P. S. Unsinnige groß klein / Schreibfehler bitte ignorieren..... Bin unterwegs und das Tablett hat eine sagen wir eigensinnige Autokorrektur
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2020, 18:53:35
Hallo Andreas,

ZitatNun muss ich jedesmal die Attribute ändern und wehe ich vertippe mich hier mal oder vergesse d:7 aufd:60 zu ändern vor dem Löschen.... Dann ist eine Menge weg 
Naja, so ist die Philosophie der DbRep-Anwendung nicht gedacht.
Es sollen keinesfalls immer die Attribute eines Devices geändert werden. Die Idee hinter DbRep ist, dass man sich für alle regelmäßig anfallenden Auswertungsaufgaben ein DbRep anlegt, mit den Attributen einstellt und dann wiederholt ausführt.

Als Beispiel sei die Auswertung einer PV-Anlage genannt -> https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung

Alle Werten in der dort dargestellten Tabelle werden durch jeweils ein DbRep Device geliefert. Das ist das ursprüngliche Einsatzgebiet des Moduls und deswegen werden grundlegende EInstellungen über Attribute gemacht.

Aber ich kann auch nachvollziehen, dass in bestimmten Fällen eine etwas mehr "dynamische" Verwendungsmöglichkeit gewünscht ist. Bei manchen Funktionen habe ich die Verwendbarkeit von optionalen Angaben bereits eingebaut.

So könnte ich mir speziell bei den Funktionen delEntries und reduceLog einen Einbau/Erweiterung von optionalen Angaben vorstellen. Allerdings kann es nicht den kompletten Umfang der möglichen Zeitabgrenzungen, die DbRep bietet, umfassen.
Es kann maximal eine einfache Angabe der zu berücksichtigenden +/- Tage sein, sonst wird es zu kompliziert.
Ich schaue mir das mal an.

Momentan kannst du wie schon geschrieben das Attribut executeAfterProc nutzen um eine sequentielle Ausführung von mehreren DbRep-Devices zu verketten. D.h. einmal angestartet, wird nacheinander jedes verkettete DbRep ausgeführt und arbeitet seine jeweils eingestellten Aufgaben ab.

Grüße,
Heiko



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 16 März 2020, 21:17:23
Hallöchen nochmal,

vielen herzlichen Dank für die ausführliche Erklärung der Arbeitsweise... Je länger ich darüber nachdenke umso mehr Sinn macht es auch.

Zitat von: DS_Starter am 16 März 2020, 18:53:35
Naja, so ist die Philosophie der DbRep-Anwendung nicht gedacht.

Ich habe mir das o.g. Beispiel mal angeschaut und klar, wenn ich täglich solche Auswertungen machen möchte, die ich dann ggf. anpasse macht es natürlich mehr Sinn für jedes Teil ein eigenes DBRep Device zu erstellen, anstatt wie es manch ein anderer machen würde: Ein DBRep Device, einen Dummy der das steuert, ein AT das dieses aktiviert und eine DOIF wenn weil deshalb was passiert.

WENN ich meine kompletten FileLog Dateien importiert habe, wird einmal mit der groben Kelle aufgeräumt und dann lege ich mir für die wichtigsten Dinge DBRep Devices zu, die dann Ordnung in der Datenbank halten. Mit dem Hinweis auf die Mehrfachausführung in dem AT habe ich auf jeden Fall noch ganz andere Möglichkeiten (die Aufgabe auch mit anderen Dingen zu verknüpfen)

ZitatSo könnte ich mir speziell bei den Funktionen delEntries und reduceLog einen Einbau/Erweiterung von optionalen Angaben vorstellen. Allerdings kann es nicht den kompletten Umfang der möglichen Zeitabgrenzungen, die DbRep bietet, umfassen.
Es kann maximal eine einfache Angabe der zu berücksichtigenden +/- Tage sein, sonst wird es zu kompliziert.
Ich schaue mir das mal an
Ich weiss nicht welchen vollständigen Umfang Du meinst. Aber ich für meinen Teil, wäre für meine regelmäßigen NICHT automatisierten Reinigungsaktionen vollkommen zufrieden, wenn ich bei beiden bestimmten kann welches Reading und welcher Zeitraum. Das waren für mich persönlich bisher die beiden wichtigsten Funktionen. Sicherlich kann das Ding noch mehr aber bsw. del(seq)Doublets kann man auch wunderbar automatisch einsetzen, WENN man es eh in eine Abfrage setzen kann :)

Vielen Dank
und viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DoubleD am 17 März 2020, 10:56:59
Hallo zusammen,

ich hänge mich hier mal ran weil das Problem ein Ähnlich ist!

@DS_Starter
Ich verwende eine SQLite Datenbank lokal am RPi ohne user und passwort!
Muss ich zwingend eine user und passwort vergeben um das Modul nutzen zu können?

Die Logausgabe mit Verbose 4

2020.03.17 10:44:50 2: DbRep DatenbankReport - user "" doesn't have rights "INDEX" and "ALTER" as needed - try use adminCredentials automatically !
2020.03.17 10:44:50 2: DbRep DatenbankReport - ERROR - adminCredentials not set. Use "set DatenbankReport adminCredentials" first.
2020.03.17 10:44:50 2: DbRep DatenbankReport - ERROR - admin credentials are needed for database operation, but are not set or can't read it
2020.03.17 10:51:35 3: DbRep DatenbankReport - ################################################################
2020.03.17 10:51:35 3: DbRep DatenbankReport - ###                    New Index operation                   ###
2020.03.17 10:51:35 3: DbRep DatenbankReport - ################################################################
2020.03.17 10:51:35 3: DbRep DatenbankReport - Command: index recreate_Report_Idx
2020.03.17 10:51:35 2: DbRep DatenbankReport - user "" doesn't have rights "INDEX" and "ALTER" as needed - try use adminCredentials automatically !
2020.03.17 10:51:35 2: DbRep DatenbankReport - ERROR - adminCredentials not set. Use "set DatenbankReport adminCredentials" first.
2020.03.17 10:51:35 2: DbRep DatenbankReport - ERROR - admin credentials are needed for database operation, but are not set or can't read it
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2020, 11:35:44
HI,

ZitatMuss ich zwingend eine user und passwort vergeben um das Modul nutzen zu können?
Nein, braucht SQLite ohnehin nicht.

Diese Logs sind irreführend und ich hatte sie in der aktuellen Version eliminiert.
Update DbRep bitte mal (aktuell auf 8.32.4-s21429/2020-03-15). Dann sollte das passen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ritter_runkel am 17 März 2020, 16:04:06
Hallo Gemeinde,
ich habe ein Verständnisproblem.

Folgendes DBRep soll eine Summierung von DB-Einträgen durchführen und das Ergebnis in die Datenbank schreiben:


defmod Rep.Einspeisung.Strom.Jahr DbRep DBLOG
attr Rep.Einspeisung.Strom.Jahr aggregation no
attr Rep.Einspeisung.Strom.Jahr devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Einspeisung.Strom.Jahr device SMA_Energy_Meter
attr Rep.Einspeisung.Strom.Jahr diffAccept 2300
attr Rep.Einspeisung.Strom.Jahr event-on-update-reading state
attr Rep.Einspeisung.Strom.Jahr group Berechnungen Solar
attr Rep.Einspeisung.Strom.Jahr reading Einspeisung_WirkP_Zaehler_Diff
attr Rep.Einspeisung.Strom.Jahr room System
attr Rep.Einspeisung.Strom.Jahr showproctime 1
attr Rep.Einspeisung.Strom.Jahr timeout 180
attr Rep.Einspeisung.Strom.Jahr timestamp_begin current_year_begin
attr Rep.Einspeisung.Strom.Jahr timestamp_end current_year_end
attr Rep.Einspeisung.Strom.Jahr userExitFn setDumEnergy .*:.*
attr Rep.Einspeisung.Strom.Jahr verbose 2


Dabei werden immer 2 Einträge in der Datenbank erzeugt. Das ist unabhängig vom Zeitraum über den gerechnet wird. Es erfolgen immer jeweils ein Eintrag am Anfang des Zeitraums (bspw. 2020-01-01 00:00:01) und am Ende des Zeitraums.
Im Idealfall wird nur ein Eintrag am Ende des Zeitraums erzeugt. Das macht sich auch für Grafiken sehr schön.

Ist das so gewollt?

Das ist für mich sehr unglücklich, da ich Zeiträume kaskadierend summiere und die Daten der untersten Stufe (minütliche Erfassung bspw. von SMAEM) löschen will. Bei meiner Summierung


Hat jemand eine andere Idee?

Grüße aus Leipzig
Erik
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2020, 16:48:53
Hallo Erik,

ja das ist so gewollt bei Aggregierungsfunktionen die keinen definierten Zeitpunkt des Auftretens haben (averageValue, sumValue).
Es folgt aus der Diskussion hier https://forum.fhem.de/index.php/topic,105787.msg1014562.html#msg1014562 und ff.

Ich könnte mit vorstellen zusätzlich zu der Option writeToDB eine weitere Option  writeToDBSingle (z.B.) anzubieten die generell nur einen Point schreibt.
Überlege aber grad noch ob sich evtl. schon mit den jetzt eingebauten Mitteln dieses Verhalten erreichen lässt ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ritter_runkel am 17 März 2020, 19:30:56
Hallo Heiko,
danke für das Angebot. Ich nehm das gerne an.
Hintergrund der ganzen Aktion (Du hast es vielleicht am Listing gesehen) ist die Idee Deine PV-Auswertung aus dem WIKI mit mehr Datensparsamkeit zu erledigen.
Am Ende des Jahres möchte ich je interessanter Kategorie (Erzeugung, Bezug, Einspeisung) maximal 365 Datensätze zzgl. der Monatsscheiben und des Jahreswertes haben. Das sind dann auch Mengen, die man lange aufheben kann.

Idealerweise gäbe es eine Funktion, die einen Wert direkt in ein anderes Reading schreibt - also den Umweg über das Notify aus dem Wiki spart.
Für mich würde das Sinn machen ;-)

Egal was raus kommt - herzlichen Dank, dass Du Dir die Zeit nimmst.

Grüße
Erik
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2020, 19:38:22
Hi Erik,

ja mir ist auch nichts besseres eingefallen, ich werde die zusätzliche Option mal einbauen und zum Test stellen.

ZitatIdealerweise gäbe es eine Funktion, die einen Wert direkt in ein anderes Reading schreibt - also den Umweg über das Notify aus dem Wiki spart.
Was soll ich sagen ... die Anforderung gab es schon mal und steht auf meiner ToDo ... Habs aber immer wieder nach hinten geschoben  ::)  Jetzt bekommt das Feature wieder etwas Rückenwind.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DoubleD am 18 März 2020, 08:50:55
Zitat von: DS_Starter am 17 März 2020, 11:35:44
HI,
Nein, braucht SQLite ohnehin nicht.

Diese Logs sind irreführend und ich hatte sie in der aktuellen Version eliminiert.
Update DbRep bitte mal (aktuell auf 8.32.4-s21429/2020-03-15). Dann sollte das passen.

LG,
Heiko

Funktioniert! Danke!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DoubleD am 18 März 2020, 08:51:56
Zitat von: DS_Starter am 17 März 2020, 16:48:53

Ich könnte mit vorstellen zusätzlich zu der Option writeToDB eine weitere Option  writeToDBSingle (z.B.) anzubieten die generell nur einen Point schreibt.
Überlege aber grad noch ob sich evtl. schon mit den jetzt eingebauten Mitteln dieses Verhalten erreichen lässt ...

Wäre super!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DoubleD am 18 März 2020, 08:53:18
Zitat von: ritter_runkel am 17 März 2020, 19:30:56

Idealerweise gäbe es eine Funktion, die einen Wert direkt in ein anderes Reading schreibt - also den Umweg über das Notify aus dem Wiki spart.
Für mich würde das Sinn machen ;-)


+1 Wäre eine große Hilfe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 März 2020, 22:01:55
Hallo miteinander,

ich habe einiges abgearbeitet und eine neue Version zum Test bereitgestellt.
Neu ist:

* das Kommando reduceLog kann man zur schnellen, dynamischen Nutzung nun auch mit Zeitoptionen (Tagen) aufrufen, z.B.
   set <Name> reduceLog 100:200 average=day EXCLUDE=device1:reading1,device2:reading2

   Die Syntax ist genauso wie bei DbLog und es werden bei Verwendung der Optionen evtl gesetzte Attribute übersteuert.
   Man kann dort nur Tage angeben (keine Wochen etc.), sonst wäre es einfach zu komplex.

* Für averageValue und sumValue gibt es nun die Aufrufoption writeToDBSingle. Mit dieser Option wird nur ein
   Berechnungswert pro Periode in die DB weggeschrieben anstatt zwei mit writeToDB.

Für alle diese Funktionen habe ich die Commandref überarbeitet. Nach dem Download des Moduls einfach mit

help dbrep

anzeigen.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


Würde mich über eure Testergebnisse freuen. Die weiteren Wünsche schaue ich mir auch noch an.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ritter_runkel am 19 März 2020, 07:53:05
Hallo Heiko,
Corona machte vermutlich möglich - vielen Dank für die Funktion "writeToDBSingle"

Hab es gerade mal getestet - sieht gut aus.

Beste Grüße aus Leipzig.
Erik
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 März 2020, 08:27:46
Moin Erik,

ZitatCorona machte vermutlich möglich - vielen Dank für die Funktion "writeToDBSingle"
Wenn ich ehrlich bin, habe ich gerade jetzt mehr Stress als sonst. Es müssen in der Situation Wege gefunden und organisiert werden um den Betrieb stabil zu halten, sodass der Kunde (fast) nichts merkt. Ich arbeite an den Modulen meist bis (sehr) spät Abends um etwas zu bauen und zu testen.

Schön, dass es funktioniert.  :)
Die anderen requesteten Punkte schaue ich mir auch noch an und melde mich wieder ...

Grüße,
Heiko 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 19 März 2020, 09:45:07
Moin.
Vielen Dank für den tollen Einsatz.

Habt Ihr bereits etwas als Muster für einen Kostal Plenticore WR? Bevor ich alles nochmal konfiguriere.
Ich versuche gerade Reports von den SMA Mustern zu adaptieren, nur bin ich noch nicht so weit die readings passend zu zu ordnen. Ich vermute der Plenticore hat nicht 1 zu 1 die selben Werte.

Gesendet von meinem SM-G930F mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 März 2020, 11:26:14
Hallo Christian,

bin mir etwas unsicher ob deine Anfrage hier nicht untergeht.
Würde an deine Stelle in     FHEM - Anwendungen »   Solaranlagen  was platzieren und ggf. hierher verlinken.

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 19 März 2020, 12:06:29
Okay danke

Gesendet von meinem SM-G930F mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 19 März 2020, 19:02:21
Hallöchen,

Zitat von: DS_Starter am 18 März 2020, 22:01:55
Hallo miteinander,

ich habe einiges abgearbeitet und eine neue Version zum Test bereitgestellt.
Neu ist:

Alter Schwede 😳 Schneller als die Polizei erlaubt..... Schon jetzt einmal vielen herzlichen Dank dafür.

Wenn ich heute Abend dazu komme, werde ich einiges testen und berichten. Wenn nicht heute Abend dann spätestens in den nächsten 2-3 Tagen  :)

Grüße
Andreas

Danke!!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 19 März 2020, 19:28:13
Schneller als wie der Schall :-)

Ich habe mir da mal SQL ueberlegt und frage mich nun wohin damit

Ich habe bei den Devices event_on_change eingestellt, wodurch die Values jetzt natuerlich nicht alle zur selben Zeit erscheinen.
Mit der folgenden Abfrage bekommt man die aktuellsten Readings, egal wann sie geloggt wurden.

SET @device = 'Heizung';
SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
  FROM history t1
  INNER JOIN
   (select max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
      from history
      where DEVICE    = @device and
            TIMESTAMP > NOW() - INTERVAL 1 DAY
      group by READING) x
  ON x.TIMESTAMP = t1.TIMESTAMP AND
     x.DEVICE    = t1.DEVICE    AND
     x.READING   = t1.READING;

z.B.
MySQL [fhem]> SET @device = 'Heizung';
Query OK, 0 rows affected (0.001 sec)

MySQL [fhem]> SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
    ->   FROM history t1
    ->   INNER JOIN
    ->    (select max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
    ->       from history
    ->       where DEVICE    = @device and
    ->             TIMESTAMP > NOW() - INTERVAL 1 DAY
    ->       group by READING) x
    ->   ON x.TIMESTAMP = t1.TIMESTAMP AND
    ->      x.DEVICE    = t1.DEVICE    AND
    ->      x.READING   = t1.READING;
+---------------------+---------+---------------------------+-------------------+
| TIMESTAMP           | DEVICE  | READING                   | VALUE             |
+---------------------+---------+---------------------------+-------------------+
| 2020-03-19 19:21:15 | Heizung | ambientTemperature        | 12.4              |
| 2020-03-19 19:16:15 | Heizung | averageAmbientTemperature | 11.5              |
| 2020-03-19 06:56:14 | Heizung | counterHeatQHeating       | 6978.9            |
| 2020-03-19 12:01:14 | Heizung | counterHeatQPool          | 992.8             |
| 2020-03-19 12:01:14 | Heizung | counterHeatQTotal         | 12897.0           |
| 2020-03-19 11:56:14 | Heizung | flowDispersion            | 10.4              |
| 2020-03-19 19:21:15 | Heizung | flowTemperature           | 24.5              |
| 2020-03-19 19:16:15 | Heizung | heatingBufferTemperature  | 27.1              |
| 2020-03-19 19:06:15 | Heizung | heatingSystemCircPump     | off               |
| 2020-03-19 19:21:15 | Heizung | heatSourceIN              | 16.5              |
| 2020-03-19 12:01:14 | Heizung | heatSourceMotor           | off               |
| 2020-03-19 18:36:15 | Heizung | hotWaterCircPumpExtern    | off               |
| 2020-03-19 19:01:15 | Heizung | hotWaterTemperature       | 59.4              |
| 2020-03-19 12:21:14 | Heizung | hotWaterTemperatureTarget | 50.0              |
| 2020-03-19 12:06:14 | Heizung | opStateHeatPump1          | Wärmepumpe steht  |
| 2020-03-19 19:21:15 | Heizung | opStateHeatPump2          | seit 07:23:21     |
| 2020-03-19 12:06:14 | Heizung | opStateHeatPump3          | Keine Anforderung |
| 2020-03-19 14:01:15 | Heizung | opStateHotWater           | Temp. OK          |
| 2020-03-19 19:16:15 | Heizung | returnTemperature         | 27.1              |
| 2020-03-19 19:06:15 | Heizung | returnTemperatureExtern   | 28.7              |
| 2020-03-19 19:01:15 | Heizung | returnTemperatureHeating  | 27.4              |
| 2020-03-19 19:16:15 | Heizung | returnTemperatureTarget   | 24.1              |
| 2020-03-19 12:21:14 | Heizung | SWTin_PV-Eigenverbrauch   | 0                 |
+---------------------+---------+---------------------------+-------------------+
23 rows in set (0.132 sec)



MySQL [fhem]> SET @device = 'PV_Anlage_1';
Query OK, 0 rows affected (0.001 sec)

MySQL [fhem]> SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
    ->   FROM history t1
    ->   INNER JOIN
    ->    (select max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
    ->       from history
    ->       where DEVICE    = @device and
    ->             TIMESTAMP > NOW() - INTERVAL 1 DAY
    ->       group by READING) x
    ->   ON x.TIMESTAMP = t1.TIMESTAMP AND
    ->      x.DEVICE    = t1.DEVICE    AND
    ->      x.READING   = t1.READING;
+---------------------+-------------+-------------------------------------------------------+------------+
| TIMESTAMP           | DEVICE      | READING                                               | VALUE      |
+---------------------+-------------+-------------------------------------------------------+------------+
| 2020-03-19 19:26:20 | PV_Anlage_1 | Actual_battery_charge_-minus_or_discharge_-plus_Power | 401        |
| 2020-03-19 19:15:21 | PV_Anlage_1 | Actual_battery_charge_usable_Power                    | 7347       |
| 2020-03-19 19:15:21 | PV_Anlage_1 | Act_state_of_charge                                   | 92.00      |
| 2020-03-19 19:25:22 | PV_Anlage_1 | Battery_temperature                                   | 24.10      |
| 2020-03-19 19:26:16 | PV_Anlage_1 | Daily_yield                                           | 36913.14   |
| 2020-03-19 19:26:14 | PV_Anlage_1 | Home_own_consumption_from_battery                     | 367.83     |
| 2020-03-19 19:26:18 | PV_Anlage_1 | Home_own_consumption_from_grid                        | 3.00       |
| 2020-03-19 19:26:15 | PV_Anlage_1 | Home_own_consumption_from_PV                          | 0.17       |
| 2020-03-19 00:02:15 | PV_Anlage_1 | Inverter_state                                        | 6          |
| 2020-03-19 19:26:20 | PV_Anlage_1 | Monthly_yield                                         | 385511.69  |
| 2020-03-19 19:26:14 | PV_Anlage_1 | Power_DC1                                             | -0.12      |
| 2020-03-19 19:21:17 | PV_Anlage_1 | Power_DC2                                             | -0.11      |
| 2020-03-19 19:26:20 | PV_Anlage_1 | Power_DC_Sum                                          | -0.23      |
| 2020-03-19 19:26:20 | PV_Anlage_1 | Total_DC_Power                                        | 401.50     |
| 2020-03-19 19:26:20 | PV_Anlage_1 | Total_DC_Power_Max                                    | 400.6228   |
| 2020-03-19 19:00:22 | PV_Anlage_1 | Total_PV_Power_reserve                                | 0          |
| 2020-03-19 19:26:13 | PV_Anlage_1 | Total_yield                                           | 1400978.38 |
| 2020-03-19 19:26:20 | PV_Anlage_1 | Voltage_DC1                                           | 18.83      |
| 2020-03-19 19:26:22 | PV_Anlage_1 | Voltage_DC2                                           | 9.61       |
| 2020-03-19 19:26:18 | PV_Anlage_1 | Yearly_yield                                          | 952188.25  |
+---------------------+-------------+-------------------------------------------------------+------------+
26 rows in set (0.214 sec)


Viel Spass beim Testen
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 März 2020, 19:36:10
Hallo Christian,

ZitatIch habe mir da mal SQL ueberlegt und frage mich nun wohin damit
Naja, es gibt doch im DbRep das "set ... sqlSpecial".
Dort könnte es unterbringen. Ich müsste es nur etwas anpassen dass es auch für SQLite und PostgreSQL funktioniert.
Mal schauen, ich probiere und melde mich ...

cool Sache  8)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 19 März 2020, 20:33:58
Manchmal kann ich auch was

Gesendet von meinem SM-G930F mit Tapatalk

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 März 2020, 21:54:19
Hallo miteinander

zwei Dinge habe ich jetzt noch hinzugefügt

* das Kommando delEntries kann nun ebenfalls mit Zeitoptionen (Tagen) dynamisch aufgerufen werden, z.B.
   set <Name> delEntries 100:200

   Eventuell gesetzte time.*-Attribute werden damit übersteuert

* der Spezial SQL von Christian ist eingebaut. Aufruf mit

   set <name> sqlSpecial recentReadingsOfDevice

   Mit dem Attr sqlResultFormat kann man das Ausgabe Format festlegen. Mit "table" ergibt sich eine Tabelle wie im Anhang.
   Das Device wird wie üblich über das Attr device festgelegt. Muss in diesem Fall aber ein konkretes Device sein, kein TYPE= o.ä.
   Für MySQL und SQLite läuft es schon. Postgre muss ich noch machen.
   PostgreSQL läuft ebenfalls.
   Die Comref muss ich noch anpassen.


Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Probierts mal aus....

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 20 März 2020, 00:23:12
WOW  :o 8)

Ich bin wirklich beeindruckt. Mal abgesehen davon, dass ich (ein wenig) weiß wie umfangreich manche Sachen zu programmieren sind, finde ich die Geschwindigkeit mit der Du etwas umsetzt schon genial. *Daumenhoch*  Noch dazu, weil es auch entsprechend zu funktionieren scheint ...

Ich kann natürlich nicht alles testen, aber das was ich bisher getestet hab ... läuft und zwar so wie es für mich perfekt ist. Ich habe die Option einzelne Devices anzulegen ( dazu eine Frage unten ) und ich habe auch die Möglichkeit mit den Optionen Speziell bei ReduceLog mich an die Grenzen heran zu tasten, wenn die Datenbank mal zu groß werden sollte (Was ich zu vermeiden hoffe ).

Nun eine Funktionsfrage, ob ich das richtig verstanden habe:

In beiden Fällen habe ich das Attribut timeDiffToNow auf 3600und 86400 geändert, ansonsten nur noch das Reading attribut drin.....

2020-03-19 23:42:41 Global global ATTR SQL_Rep timeDiffToNow 3600
2020-03-19 23:42:42 HP1000 Wetterstation wind_speed: 0.4
2020-03-19 23:42:44 DbRep SQL_Rep running
2020-03-19 23:42:44 DbRep SQL_Rep 2020-03-19__/__wemoszaehler_OG_current_5min__AVGAM__no_aggregation: 9.8150
2020-03-19 23:42:44 DbRep SQL_Rep done

2020-03-19 23:43:02 Global global ATTR SQL_Rep timeDiffToNow 86400
2020-03-19 23:43:09 DbRep SQL_Rep running
2020-03-19 23:43:09 DbRep SQL_Rep 2020-03-19__/__wemoszaehler_OG_current_5min__AVGAM__no_aggregation: 4.7490


List (zur Sicherheit)
Internals:
   DATABASE   testsystem_fhem
   DEF        SQL_Log
   FUUID      5e6bf086-f33f-8d79-ce6c-1037df4f23ecb31c
   FVERSION   93_DbRep.pm:v8.32.4-s21429/2020-03-15
   LASTCMD    averageValue display
   MODEL      Client
   NAME       SQL_Rep
   NOTIFYDEV  global,SQL_Rep
   NR         40
   NTFY_ORDER 50-SQL_Rep
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE SQL_Log
     GRANTS     TRIGGER,REPLICATION SLAVE,EXECUTE,CREATE,DROP,CREATE TEMPORARY TABLES,EVENT,PROCESS,DELETE,REFERENCES,INDEX,RELOAD,INSERT,REPLICATION CLIENT,SHOW VIEW,CREATE VIEW,LOCK TABLES,ALTER ROUTINE,FILE,SELECT,CREATE ROUTINE,ALTER,UPDATE
     IDRETRIES  3
     MINTS      2020-01-26 00:00:00
     PACKAGE    main
     SQLHIST   
     VERSION    8.32.4
     CV:
       aggregation no
       aggsec     1
       destr      2020-03-19
       dsstr      2020-03-19
       epoch_seconds_end 1584658549
       mestr      03
       msstr      03
       testr      23:55:49
       tsstr      01:09:09
       wdadd      345600
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     REDUCELOG:
       SQL_Rep
       reduceLog
       52:53
       average
       INCLUDE=Nebenzaehler:wemoszaehler_EG_current_5min
   OLDREADINGS:
   READINGS:
     2020-03-19 23:55:49   2020-03-19__/__wemoszaehler_OG_current_5min__AVGAM__no_aggregation 4.7837
     2020-03-19 23:55:49   state           done
Attributes:
   allowDeletion 1
   reading    wemoszaehler_OG_current_5min
   room       DB Log_Rep,
   timeDiffToNow 86400
   verbose    3


Verstehe ich die Doku und entsprechende Einstellungen richtig, dass in meinem Fall der Durchschnitt für den Zeitraum aktuelleZeit-3600(bzw 86400)sek -> BIS aktuelleZeit berechnet wird ?

Ich frage aus dem Grund, weil ich Daten mit großen Mengen gerne von vorne herein korrekt machen würde und ich gerade wie erwähnt auf meinem Testsystem Stromzähler und ein eigenes Wetter Device (Modul) teste.  In beiden Fällen gibt es eine richtige Datenflut, die ich (idealerweise) quasi on the fly im zaun halten möchte, als sie hinterher zu korrigieren.

Beide Devices ansich sind schon mit Event-Beschränkungen eingesetzt (even-aggregator event-on-change usw) Beim Stromzähler übernimmt der event-aggregator einen 5 und 30 Minuten Schnitt, der allerdings natürlich dennoch für viele Events sorgt und nicht alle 5 Minuten den Aktuellen 5 Min Schnitt bringt.  Jetzt ist mir mit dem (halb)Wissen durch das Lesen hier und die Erkenntnis, dass eine DB sich besser zum Rechnen eignet als eine Heimautomatisierungssoftware auf einem RaspberryPi, die Idee gekommen sämtliche Mittelwert Berechnung von der Datenbank(Synology Diskstation) und nicht vom Raspberry(Fhem) übernehmen zu lassen.

OFF TOPIC:

Meine Idee wäre dann 1-7 Tage mit ungefilterten Werten arbeiten (anzeigen)
Der 5 und 30 Minuten Schnitt wird "live" von der DB erzeugt
Livedaten werden alle 7-x Tage mit Reduce Log dann auf Stunden Schnitt verringert und die 5-30 Minuten Schnittwerte sind ja immernoch vorhanden

Was halten die Datenbankexperten von der Idee ? Macht es Sinn ? Oder mache ich mir zu viel Gedanken um Performance / Speicher, bei solch einer "kleinen" Aufgabe ? (auch im Hinblick auf die Zukunft... Denn je besser die Sachen in FHEM funktionieren, kommt auch immer mehr dazu - Wobei ich mit ca 50 Geräten und 150 Devices sicherlich nicht am Anfang der Automatisierung hänge ...  )

Würde mich aber sehr freuen, wenn jemand zum OffTopic auch Stellung nehmen könnte.Falls es mehr Sinn macht dafür einen neuen Beitag zu erstellen, mache ich das ;)

Vielen Dank für Deine Arbeit Heiko und auch die Ideen / Vorschläge der anderen mit "Bastler" :)

und auch wenn ich den Spruch selbst nicht mehr so oft hören mag - er aber umso wichtiger ist:
Viele Grüße und bleibt gesund
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 März 2020, 07:53:58
Zitat von: DS_Starter am 19 März 2020, 21:54:19
* der Spezial SQL von Christian ist eingebaut. Aufruf mit

   set <name> sqlSpecial recentReadingsOfDevice

Wow, damit hatte ich jetzt nicht gerechnet, ich hatte gerade mal eine Stunde ueber etwas nachgedacht und schon scheint es zu einer interessanten Abfrage geworden zu sein.
Der Test war erfolgreich...

Vielen Dank fuer die Amerkennung
      Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2020, 09:37:57
Moin zusammen,

@Andreas ... freut mich dass deine Test auch erfolgreich waren und wow ... herzlichen Dank! War überrascht und freue mich natürlich sehr über die Anerkennung !  :D

ZitatVerstehe ich die Doku und entsprechende Einstellungen richtig, dass in meinem Fall der Durchschnitt für den Zeitraum aktuelleZeit-3600(bzw 86400)sek -> BIS aktuelleZeit berechnet wird ?

Ja, ist richtig.
Allgemein gilt ... wenn ihr euch unsicher seid ob die Attribut-Einstellungen im Device richtig sind und richtig umgesetzt werden, dann stellt verbose 4
ein und führt z.B. countEntries aus. Im Log seht ihr dann das ausgeführte SQL Statement. Ihr könnt dort ablesen ob die Zeitgrenzen richtig eingesetzt werden,
die richtigen Devices und Readings includiert/excludiert werden usw.
Sollte etwas noch nicht so eingestellt sein wie gewünscht, könnt ihr es leicht korrigieren. Ein countEntries tut nicht weh.


ZitatOFF TOPIC:

Meine Idee wäre dann 1-7 Tage mit ungefilterten Werten arbeiten (anzeigen)
Der 5 und 30 Minuten Schnitt wird "live" von der DB erzeugt
Livedaten werden alle 7-x Tage mit Reduce Log dann auf Stunden Schnitt verringert und die 5-30 Minuten Schnittwerte sind ja immernoch vorhanden

Finde ich einen interessanten Ansatz und ich persönlich würde es so machen.
Hat aber auch ein bisschen damit zu tun, dass ich ein wenig Datenbank affin bin und gerne die Rohdaten in der originären Form vorliegen habe sie dann nach
Lust und Laune(Notwendigleit) auswerten zu können. Ich finde allein schon die Beschäftigung damit interssant und lehrreich und man wird dadurch auch nicht dümmer.
Sollten die Daten doch mal zu viel werden ... naja, ein beherztes deleteEntries macht dem Spuk ein Ende  :). Mit einer DB kann man seine Daten ja sehr gut
verwalten.
So wie ich hast du deine DB auch auf der Synology laufen. Ich habe ja einige davon am Start, bedingt durch die DbLog/DbRep-Entwicklung. Die sind jetzt teilweise
bis 8 GB groß (Daten zum Testen) und das FHEM-System lässt das kalt.

Nicht so DB affine User sehen das vielleicht anders, machen einen Bogen um die DB-Nutzung und nutzen lieber FHEM-Mittel.
Wie immer wird es verschiedene Vorlieben und Meinungen geben.

@Christian , prima ... danke für den tollen Input.

ZitatWow, damit hatte ich jetzt nicht gerechnet, ich hatte gerade mal eine Stunde ueber etwas nachgedacht und schon scheint es zu einer interessanten Abfrage geworden zu sein.

Abgesehen davon, dass ich diese Abfrage nützlich/hilfreich finde, ist es vllt. ein Anregung für andere User. Wie oben schon angedeutet, kann man sich mit verbose 4
das SQL anschauen was DbRep generiert und daraus Ideen für eigene Auswertungen ziehen.
Unter diesem Aspekt sehe ich die Rubrik "sqlSpecial" auch als "Fundgrube" und baue da gerne noch etwas ein was für andere User interessant sein könnte.
Erweiterungen sind recht leicht möglich, weil das Rahmenwerk ja vorhanden ist. Blöd ist immer, dass die Syntax zw. MySQL, SQLite, PostgreSQL teilweise nicht
identisch ist. Gerade bei solchen specials ...

Ich finalisiere den Stand noch und checke die Version im laufe des Tages ein wenn nichts mehr auffallen sollte.
Danach schaue ich mir noch die Sache mit der Funktion an, die einen Wert direkt in ein anderes Reading schreibt. Das dauert dann ein bisschen  ;)


LG,
Heiko 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 20 März 2020, 15:16:13
Tach,

Zitat von: DS_Starter am 20 März 2020, 09:37:57
@Andreas ... freut mich dass deine Test auch erfolgreich waren und wow ... herzlichen Dank! War überrascht und freue mich natürlich sehr über die Anerkennung !  :D

Halte das eigentlich immer so: Wenn ich merke dass jemand nicht nur insg. viel Zeit in die Entwicklung eines Moduls / Erweiterung was auch immer, gesteckt hat und auch weiterhin versucht es für alle so zu machen, dass möglichst vieles vereinfacht wird, haben sie es sich auch mehr als verdient, dass man eben auch mal Anerkennung zeigt. Mal davon ab, wenn es JEDER machen würde der die Module eines Devs häufiger nutzt, würden die Devs sich freuen, weil ihre Arbeit (auch wenn es Hobbyarbeit ist) honorriert wird und User würden von der steigernden Motivation der Devs profitieren, weil sie einfach mehr Mittel und Möglichkeiten haben etwas zu entwickeln / programmieren. Ich für meinen Teil freue mich, dass es Leute wie Dich und andere Devs gibt, mit deren Hilfe ich eben viele besser / schneller / einfacher oder auch nur schöner erledigen kann.

OnTopic:
Ich denke mal das wird eine schön komplizierte Nummer, bis ich mich da mal wieder hinein gelesen hab (meine ersten SQL Gehversuche sind ca 15-18 Jahre her -.- ) Aber ich glaube auch, dass es mehr Sinn macht, komplexere Berechnungen von einer Datenbank übernehmen zu lassen und dafür eben die Rohdaten zur Verfügung zu haben.

Verbose 4 ist n guter Tipp, werde ich auf jeden Fall bei der nächsten Bastelei mal testen und sehen an was ich mich alles erinnern kann, was die SQL Befehle angeht   ;D

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2020, 15:29:48
Hallo miteinander,

die Version 8.36.0 ist eingecheckt und morgen früh im Regelupdate.

@Andreas ... wenn du Unterstützung bei SQL's brauchst, bist du hier https://forum.fhem.de/index.php/topic,65860.0.html wahrscheinlich ganz gut aufgehoben denke ich.
Habe mir inzwischen auch ein SQL-Buch zugelegt, SQL ist sehr mächtig wenn man es gut/richtig anzuwenden vermag.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 März 2020, 16:07:30
Hallo Heiko,

hast so etwas schon?

Das rechnet die Differenz zwischen aufeinanderfolgenden Werten eines Readings aus inklusive der Zeitdifferenz in Minuten :-)
Ich wollte mal sehen wie der Temperaturverlust meines Pufferspeichers ist, also wieviel Kelvin pro Zeit. Das ist noch nicht ganz fertig, da ich lieber noch die
Abkuehl- und Aufheizphasen als komplette Zeitspanne sehen moechte. Hier sind es teilweise nur 5 Minuten und manchmal halbe oder ganze Stunden,
was natuerlich Zeiten sind in denen Wasser gezapft wurde.
Ich meine zu erkennen, das es ca, 0,1 Kelvin in 15 Minuten sind, wobei fuer solch kurze Zeiten einfach die Temperaturmessung zu ungenau ist.

Device und Reading waeren noch als Variable zu verwenden.

MySQL [fhem]> SET @diff=0;
Query OK, 0 rows affected (0.001 sec)

MySQL [fhem]> SET @delta=NULL;
Query OK, 0 rows affected (0.001 sec)

MySQL [fhem]> SELECT t1.TIMESTAMP,t1.READING,t1.VALUE,t1.DIFF,t1.DELTA
    ->   FROM
    ->     (
    -> SELECT TIMESTAMP,READING,VALUE,
    ->        cast((VALUE-@diff) AS DECIMAL(3,1))    AS DIFF,
    ->        @diff:=VALUE                           AS curr_V,
    ->        TIMESTAMPDIFF(MINUTE,@delta,TIMESTAMP) AS DELTA,
    ->        @delta:=TIMESTAMP                      AS curr_T
    ->   FROM  history
    ->   WHERE DEVICE = 'Heizung'              AND
    ->         READING = 'hotWaterTemperature' AND
    ->         TIMESTAMP >= NOW() - INTERVAL 1 DAY
    ->   ORDER BY TIMESTAMP
    ->     ) t1;
+---------------------+---------------------+-------+------+-------+
| TIMESTAMP           | READING             | VALUE | DIFF | DELTA |
+---------------------+---------------------+-------+------+-------+
| 2020-03-19 15:11:15 | hotWaterTemperature | 60.7  | 60.7 |  NULL |
| 2020-03-19 15:16:15 | hotWaterTemperature | 60.9  |  0.2 |     5 |
| 2020-03-19 15:21:15 | hotWaterTemperature | 60.7  | -0.2 |     5 |
| 2020-03-19 16:16:15 | hotWaterTemperature | 60.6  | -0.1 |    55 |
| 2020-03-19 16:21:15 | hotWaterTemperature | 60.7  |  0.1 |     5 |
| 2020-03-19 16:26:15 | hotWaterTemperature | 60.6  | -0.1 |     5 |
| 2020-03-19 17:21:15 | hotWaterTemperature | 60.4  | -0.2 |    55 |
| 2020-03-19 18:11:15 | hotWaterTemperature | 60.0  | -0.4 |    50 |
| 2020-03-19 18:35:20 | hotWaterTemperature | 59.9  | -0.1 |    24 |
| 2020-03-19 18:41:15 | hotWaterTemperature | 59.7  | -0.2 |     5 |
| 2020-03-19 18:46:15 | hotWaterTemperature | 59.5  | -0.2 |     5 |
| 2020-03-19 19:01:15 | hotWaterTemperature | 59.4  | -0.1 |    15 |
| 2020-03-19 19:31:15 | hotWaterTemperature | 59.2  | -0.2 |    30 |
| 2020-03-19 19:56:21 | hotWaterTemperature | 59.0  | -0.2 |    25 |
| 2020-03-19 20:16:21 | hotWaterTemperature | 58.9  | -0.1 |    20 |
| 2020-03-19 20:21:21 | hotWaterTemperature | 59.0  |  0.1 |     5 |
| 2020-03-19 20:26:21 | hotWaterTemperature | 58.9  | -0.1 |     5 |
| 2020-03-19 20:46:24 | hotWaterTemperature | 58.7  | -0.2 |    20 |
| 2020-03-19 21:11:24 | hotWaterTemperature | 58.5  | -0.2 |    25 |
| 2020-03-19 21:16:24 | hotWaterTemperature | 58.7  |  0.2 |     5 |
| 2020-03-19 21:21:24 | hotWaterTemperature | 58.5  | -0.2 |     5 |
| 2020-03-19 21:41:24 | hotWaterTemperature | 58.4  | -0.1 |    20 |
| 2020-03-19 21:46:24 | hotWaterTemperature | 58.5  |  0.1 |     5 |
| 2020-03-19 21:51:24 | hotWaterTemperature | 58.4  | -0.1 |     5 |
| 2020-03-19 22:11:24 | hotWaterTemperature | 58.2  | -0.2 |    20 |
| 2020-03-19 22:35:20 | hotWaterTemperature | 58.0  | -0.2 |    23 |
| 2020-03-19 22:36:24 | hotWaterTemperature | 57.9  | -0.1 |     1 |
| 2020-03-19 22:41:25 | hotWaterTemperature | 57.7  | -0.2 |     5 |
| 2020-03-19 22:51:24 | hotWaterTemperature | 57.6  | -0.1 |     9 |
| 2020-03-19 23:10:00 | hotWaterTemperature | 57.4  | -0.2 |    18 |
| 2020-03-19 23:16:24 | hotWaterTemperature | 57.2  | -0.2 |     6 |
| 2020-03-19 23:21:24 | hotWaterTemperature | 56.9  | -0.3 |     5 |
| 2020-03-19 23:31:24 | hotWaterTemperature | 56.8  | -0.1 |    10 |
| 2020-03-19 23:36:24 | hotWaterTemperature | 56.9  |  0.1 |     5 |
| 2020-03-19 23:41:24 | hotWaterTemperature | 56.8  | -0.1 |     5 |
| 2020-03-20 00:01:24 | hotWaterTemperature | 56.6  | -0.2 |    20 |
| 2020-03-20 00:26:24 | hotWaterTemperature | 56.5  | -0.1 |    25 |
| 2020-03-20 00:46:24 | hotWaterTemperature | 56.3  | -0.2 |    20 |
| 2020-03-20 01:06:25 | hotWaterTemperature | 56.1  | -0.2 |    20 |
| 2020-03-20 01:26:25 | hotWaterTemperature | 56.0  | -0.1 |    20 |
| 2020-03-20 01:56:25 | hotWaterTemperature | 55.8  | -0.2 |    30 |
| 2020-03-20 02:16:25 | hotWaterTemperature | 55.7  | -0.1 |    20 |
| 2020-03-20 02:36:25 | hotWaterTemperature | 55.5  | -0.2 |    20 |
| 2020-03-20 03:01:25 | hotWaterTemperature | 55.4  | -0.1 |    25 |
| 2020-03-20 03:36:25 | hotWaterTemperature | 55.2  | -0.2 |    35 |
| 2020-03-20 03:51:25 | hotWaterTemperature | 55.1  | -0.1 |    15 |
| 2020-03-20 04:11:25 | hotWaterTemperature | 54.9  | -0.2 |    20 |
| 2020-03-20 04:41:25 | hotWaterTemperature | 54.8  | -0.1 |    30 |
| 2020-03-20 05:06:25 | hotWaterTemperature | 54.6  | -0.2 |    25 |
| 2020-03-20 05:26:25 | hotWaterTemperature | 54.5  | -0.1 |    20 |
| 2020-03-20 05:30:20 | hotWaterTemperature | 54.3  | -0.2 |     3 |
| 2020-03-20 05:36:25 | hotWaterTemperature | 53.9  | -0.4 |     6 |
| 2020-03-20 05:41:25 | hotWaterTemperature | 53.7  | -0.2 |     5 |
| 2020-03-20 05:56:25 | hotWaterTemperature | 53.6  | -0.1 |    15 |
| 2020-03-20 06:00:20 | hotWaterTemperature | 53.4  | -0.2 |     3 |
| 2020-03-20 06:01:25 | hotWaterTemperature | 53.3  | -0.1 |     1 |
| 2020-03-20 06:06:25 | hotWaterTemperature | 52.9  | -0.4 |     5 |
| 2020-03-20 06:11:25 | hotWaterTemperature | 52.7  | -0.2 |     5 |
| 2020-03-20 06:21:25 | hotWaterTemperature | 52.6  | -0.1 |    10 |
| 2020-03-20 06:31:25 | hotWaterTemperature | 52.4  | -0.2 |    10 |
| 2020-03-20 06:46:25 | hotWaterTemperature | 52.3  | -0.1 |    15 |
| 2020-03-20 06:56:25 | hotWaterTemperature | 52.2  | -0.1 |    10 |
| 2020-03-20 07:11:25 | hotWaterTemperature | 52.0  | -0.2 |    15 |
| 2020-03-20 07:26:25 | hotWaterTemperature | 51.9  | -0.1 |    15 |
| 2020-03-20 07:41:25 | hotWaterTemperature | 51.7  | -0.2 |    15 |
| 2020-03-20 07:56:25 | hotWaterTemperature | 51.6  | -0.1 |    15 |
| 2020-03-20 08:05:20 | hotWaterTemperature | 51.3  | -0.3 |     8 |
| 2020-03-20 08:06:25 | hotWaterTemperature | 51.2  | -0.1 |     1 |
| 2020-03-20 08:11:25 | hotWaterTemperature | 50.8  | -0.4 |     5 |
| 2020-03-20 08:16:25 | hotWaterTemperature | 50.7  | -0.1 |     5 |
| 2020-03-20 08:21:25 | hotWaterTemperature | 50.5  | -0.2 |     5 |
| 2020-03-20 08:35:20 | hotWaterTemperature | 50.2  | -0.3 |    13 |
| 2020-03-20 08:36:25 | hotWaterTemperature | 50.1  | -0.1 |     1 |
| 2020-03-20 08:41:25 | hotWaterTemperature | 49.7  | -0.4 |     5 |
| 2020-03-20 08:46:25 | hotWaterTemperature | 49.4  | -0.3 |     5 |
| 2020-03-20 09:06:25 | hotWaterTemperature | 49.3  | -0.1 |    20 |
| 2020-03-20 09:11:25 | hotWaterTemperature | 49.4  |  0.1 |     5 |
| 2020-03-20 09:16:25 | hotWaterTemperature | 49.3  | -0.1 |     5 |
| 2020-03-20 09:36:25 | hotWaterTemperature | 49.2  | -0.1 |    20 |
| 2020-03-20 09:56:26 | hotWaterTemperature | 49.0  | -0.2 |    20 |
| 2020-03-20 10:06:26 | hotWaterTemperature | 48.9  | -0.1 |    10 |
| 2020-03-20 10:11:26 | hotWaterTemperature | 48.5  | -0.4 |     5 |
| 2020-03-20 10:16:26 | hotWaterTemperature | 45.4  | -3.1 |     5 |
| 2020-03-20 10:21:26 | hotWaterTemperature | 43.6  | -1.8 |     5 |
| 2020-03-20 10:26:26 | hotWaterTemperature | 44.1  |  0.5 |     5 |
| 2020-03-20 10:31:26 | hotWaterTemperature | 45.5  |  1.4 |     5 |
| 2020-03-20 10:36:26 | hotWaterTemperature | 47.5  |  2.0 |     5 |
| 2020-03-20 10:41:26 | hotWaterTemperature | 49.7  |  2.2 |     5 |
| 2020-03-20 10:46:26 | hotWaterTemperature | 51.6  |  1.9 |     5 |
| 2020-03-20 10:51:26 | hotWaterTemperature | 53.4  |  1.8 |     5 |
| 2020-03-20 10:56:26 | hotWaterTemperature | 54.9  |  1.5 |     5 |
| 2020-03-20 11:01:26 | hotWaterTemperature | 56.5  |  1.6 |     5 |
| 2020-03-20 11:06:26 | hotWaterTemperature | 58.0  |  1.5 |     5 |
| 2020-03-20 11:11:26 | hotWaterTemperature | 59.5  |  1.5 |     5 |
| 2020-03-20 11:16:26 | hotWaterTemperature | 60.7  |  1.2 |     5 |
| 2020-03-20 11:21:26 | hotWaterTemperature | 61.1  |  0.4 |     5 |
| 2020-03-20 11:41:26 | hotWaterTemperature | 61.3  |  0.2 |    20 |
| 2020-03-20 11:56:26 | hotWaterTemperature | 61.1  | -0.2 |    15 |
| 2020-03-20 12:01:26 | hotWaterTemperature | 61.3  |  0.2 |     5 |
| 2020-03-20 13:06:26 | hotWaterTemperature | 61.1  | -0.2 |    65 |
| 2020-03-20 14:51:26 | hotWaterTemperature | 60.9  | -0.2 |   105 |
| 2020-03-20 15:21:26 | hotWaterTemperature | 60.7  | -0.2 |    30 |
+---------------------+---------------------+-------+------+-------+
102 rows in set (0.017 sec)


Gruss
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2020, 16:55:22
Hallo Christian,

nicht in dieser Form. Bestimmt wieder super brauchbar, cool und danke Christian 8)
Ich übernehme es ins nächste Release und gebe es dir/euch vorher zum Test ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 März 2020, 17:40:31
Zitat von: DS_Starter am 20 März 2020, 16:55:22
nicht in dieser Form. Bestimmt wieder super brauchbar, cool und danke Christian 8)

Wenn es das schon gibt, habe ich es nur noch nicht gefunden. Wenn es schon da ist, dann ist es auch gut.
Wo kann ich denn sowas finden, auch als Anregung fuer neue Projekte?

Gruss
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2020, 18:05:11
Hi Christian,

das "nicht in dieser Form" bezog sich darauf, dass das Verfahren in einer ähnlichen Form für diffValue verwendet wird.
Aber das ist für den User ja nicht transparent und im Ergebnis ja auch etwas anders. Also insofern ist dieser Anwendungsfall wieder neu für den User und so nicht vorhanden.  :)
Du findest es nur indirekt im Modul so ab Zeile 3773 (V8.36.0), musst dich aber in den verschachtelten Code reinlesen weil der SQL-Code nicht so einfach dasteht, sondern im Modul zusammengesetzt wird.

Am einfachsten ist tatsächlich verbose 4 um das je nach ausgeführter Funktion erstellte SQL zu sehen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 März 2020, 18:31:23
@Christian, ich bräuchte einen sprechenden Namen für diesen select in der sqlSpecial DropDown-Liste. Hast du eine Idee dafür ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 März 2020, 19:07:15
Zitat
ich bräuchte einen sprechenden Namen für diesen select in der sqlSpecial DropDown-Liste. Hast du eine Idee dafür ?
Ich denk  morgen wieder ;-)

Wie waere "readingsDifferenceByTimeDelta"
aber wie bereits geschrieben versuche ich es noch zu verbessern...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 21 März 2020, 10:52:12
Holla,

ich muss mal mit nem kleinen Problem ankommen:

Ich hab folgenden Befehl auf der Testumgebung gefühlte 100 x angegeben (mit anderen Readings und Zeiten)

set DBRep reduceLog 120:150 average INCLUDE=read_OG_SZ_conditions:Humidity

Auf dem Testsystem funktionierte es einwandfrei auf dem Live System hab ich es heute Nacht noch mit dem händischen Update getestet, heute Morgendann mit dem LiveUpdate und leider mit dem gleichen Ergebnis: Mein Fhem stürzt komplett ab. Die einzige für mich erkennbare aber nicht verwertbare  Fehlermeldung ist
Month '-1' out of range 0..11 at ./FHEM/93_DbRep.pm line 2086.
Sonst kommt auch mit verbose 5 nicht mehr bei raus ;(

2020.03.21 10:44:31.071 3: DbRep DBRep - ################################################################
2020.03.21 10:44:31.072 3: DbRep DBRep - ###                    new reduceLog run                     ###
2020.03.21 10:44:31.073 3: DbRep DBRep - ################################################################
2020.03.21 10:44:31.114 4: DbRep DBRep - -------- New selection ---------
2020.03.21 10:44:31.114 4: DbRep DBRep - Command: reduceLog
2020.03.21 10:44:31.116 4: DbRep DBRep - Timestamp begin human readable: not set
2020.03.21 10:44:31.116 4: DbRep DBRep - Timestamp end human readable: not set
Month '-1' out of range 0..11 at ./FHEM/93_DbRep.pm line 2086.


Hoffe Du hast da ne Idee, Heiko (oder vielleicht auch jemand anderes)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2020, 12:27:02
Hallo Andreas,

böse Falle denke ich. Kann es sein dass du keines der time.*-Attribute gesetzt hast ?
Also timeDiffToNow usw. ....

Wenn nicht mach das. Ich baue eine Prüfung ein.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 21 März 2020, 12:47:43
Hey,

vielen Dank für die schnelle Rückmeldung...


Zitat von: DS_Starter am 21 März 2020, 12:27:02
böse Falle denke ich. Kann es sein dass du keines der time.*-Attribute gesetzt hast ?
Also timeDiffToNow usw. ....

Nein, habe ich nicht. Aber (jetzt bin ich verwirrt ???)das war doch Sinn der Sache, wenn ich ....reduceLog 120:150... eingebe, oder  ? 

Wenn die beiden eingegeben werden müssen, dann könnte ich timeDiffToNow 370 und timeOlderThan 365 einstellen und davon ausgehen, dass aus Versehen schon mal nichts gelöscht wird, das jünger als 1 Jahr ist ?

teil list vom db Rep
Attributes:
   DbLogExclude .*
   allowDeletion 1
   group      FileLog
   icon       own-log@darkgrey
   room       System->Log & Web
[b]   timeDiffToNow d:155
   timeOlderThan d:150[/b]
   verbose    4


Damit funktioniert es dann, wie gewollt :)

2020.03.21 12:42:03.182 4 : DbRep DBRep - -------- New selection ---------
2020.03.21 12:42:03.182 4 : DbRep DBRep - Command: reduceLog
2020.03.21 12:42:03.185 4 : DbRep DBRep - timeDiffToNow - year: , day: 150, hour: , min: , sec:
2020.03.21 12:42:03.185 4 : DbRep DBRep - Year 2020 is leap year
2020.03.21 12:42:03.186 4 : DbRep DBRep - startMonth: 9 endMonth: 2 lastleapyear: 2020 baseYear: 2019 diffdaylight:1 isdaylight:0
2020.03.21 12:42:03.187 4 : DbRep DBRep - timeOlderThan - year: 0, day: 120, hour: 0, min: 0, sec: 0
2020.03.21 12:42:03.188 4 : DbRep DBRep - Year 2020 is leap year
2020.03.21 12:42:03.189 4 : DbRep DBRep - startMonth: 8 endMonth: 10 lastleapyear: 2020 baseYear: 2019 diffdaylight:0 isdaylight:0
2020.03.21 12:42:03.189 4 : DbRep DBRep - FullDay option: 0
2020.03.21 12:42:03.190 4 : DbRep DBRep - Time difference to current time for calculating Timestamp begin: 13050001 sec
2020.03.21 12:42:03.191 4 : DbRep DBRep - Timestamp begin human readable: 2019-10-22 12:42:02
2020.03.21 12:42:03.192 4 : DbRep DBRep - Time difference to current time for calculating Timestamp end: 10454401 sec
2020.03.21 12:42:03.192 4 : DbRep DBRep - Timestamp end human readable: 2019-11-21 12:42:02
2020-03-21 12:42:03.263 DbRep DBRep reduceLog database is running - be patient and see Logfile !


Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2020, 12:53:58
Zitatjetzt bin ich verwirrt ???)das war doch Sinn der Sache, wenn ich ....reduceLog 120:150... eingebe, oder  ? 
Das glaube ich dir, dass du jetzt verwirrt bist, sorry  ???
Es gibt nur innerhalb des Programmablaufs eine Logik die mit den time.*-Attributen arbeitet. Die 120:150 übertseuern die Attribute wie gewollt, soweit so gut. Nur wenn keine Zeitattribute gesetzt sind, gibt auch nichts zu übersteuern ... Rest kannst du dir denken ...  ;)
Ich korrigiere das gerade ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 21 März 2020, 13:00:23
Holla,

Zitat von: DS_Starter am 21 März 2020, 12:53:58
Es gibt nur innerhalb des Programmablaufs eine Logik die mit den time.*-Attributen arbeitet. Die 120:150 übertseuern die Attribute wie gewollt, soweit so gut. Nur wenn keine Zeitattribute gesetzt sind, gibt auch nichts zu übersteuern ... Rest kannst du dir denken ...  ;)
Ich korrigiere das gerade ...

Ok mit der Erklärung macht es Sinn, warum das Ding dann abstürzt, wenn die Kontrolle der Attribute nicht abgefangen wird  :D
Jetzt ist die Verwirrung auch schon wieder weg und macht direkt einen Vorschlag draus (der vielleicht mehr Arbeit macht) :

Wäre es von der Ablaufstruktur des Modules nicht vielleicht sinnvoller erst zu kontrollieren ob time.* Attribute ODER xx:yy eingegeben wurde und dann entsprechend zu überspringen ?
Alternativ wäre ein Befehl alá "ReducelLogManuell" ja auch vielleicht eine Idee. Dann musst Du nie an Deine vorhandene Struktur ran, wenn sich am ReduceLog was ändert wie zuletzt mit den time* device und reading angaben
Nur so meine 2Cent Ideen  ;)

Vielen Dank für die schnelle Umsetzung und btw:
Hab die o.g. Attribute eingesetzt und mit verschiedenen Tagen gebastelt ... funktioniert einwandfrei.

Grüße
Andreas

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2020, 16:55:49
Hallo Andreas, @all,

im contrib gibt es eine neue Version.

Was ist neu:

* bugfix der von Andreas gemeldeten Problematik wenn die Timeoptionen verwendet werden aber kein time.*-Attribut gesetzt
   ist

* bei diversen sqlCmd bzw. sqlSpecial Commands werden durch die SQL-Ergebnisse Headerdaten erzeugt. Die werden jetzt
   auch mit ausgegeben

* den letzten SQL von Christian habe ich als sqlSpecial diffBetweenValuesOfReading readingsDifferenceByTimeDelta etwas abweichend für MySQL
   implementiert. Die Zeitgrenzen der Auswertung werden der gesetzten time.*-Attribute entnommen. Die Attribute
   device/reading wie gehabt. Die Precision habe ich auch hochgesetzt, damit man auch kleine 0.xxx Werte vergleichen kann.

Ich habe readingsDifferenceByTimeDelta erstmal nur für MySQL implementiert. Für SQLite und Postgre muss die Syntax erst noch übersetzt werden.
Wenn ein SQLite / Postgre -Spezi mir einen Vorschlag zuliefern könnte würde ich mich freuen.  :)

@Andeas ... danke fürs mitdenken.  :)  Aber meine Problembeschreibung oben war schon etwas stark vereinfacht. Es gibt bereits entsprechend etablierte (und verzahnte!) Strukturen im Modul. Diese Abhängigkeiten entsprechend aufzulösen war nicht sehr schwer, ich musste mich dessen nur erstmal bewusst werden. War bei meinen Test nicht drauf gestoßen weil die time.*-Attr immer gesetzt waren.

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2020, 17:12:37
@Christian ... habe deinen Vorschlag jetzt erst gesehen. Gefällt mir aber besser als mein verwendeter Name und habe ihn schon übernommen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: baumix am 22 März 2020, 11:27:31
Moin zusammen,

irgendwas ist bei einem der letzten offiziellen Updates kaputt gegangen, das Löschen alter Einträge wirft einen Fehler:

Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !

Hier mal ein List des dbrep-Devices, was bis vor 14 Tage noch funktioniert hat:

Internals:
   DATABASE   fhemdb
   DEF        logdb
   FUUID      5c729a24-f33f-dfd6-1187-471cb684065376b3
   FVERSION   93_DbRep.pm:v8.38.0-s21473/2020-03-21
   LASTCMD    delEntries 1000
   MODEL      Client
   NAME       dbrep.deleteoldentries
   NOTIFYDEV  global,dbrep.deleteoldentries
   NR         210
   NTFY_ORDER 50-dbrep.deleteoldentries
   ROLE       Client
   STATE      Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     GRANTS     SELECT,INDEX,INSERT,CREATE,TRIGGER,EXECUTE,FILE,ALTER,UPDATE,SHOW VIEW,CREATE VIEW,CREATE TEMPORARY TABLES,DROP,DELETE,EVENT,CREATE ROUTINE,ALTER ROUTINE
     IDRETRIES  3
     MINTS      2018-07-26 21:55:41
     PACKAGE    main
     SQLHIST   
     VERSION    8.38.0
     CV:
       aggregation no
       aggsec     1
       destr      2017-06-25
       dsstr      2018-07-26
       epoch_seconds_end 1498379517
       mestr      06
       msstr      07
       testr      10:31:57
       tsstr      21:55:41
       wdadd      345600
       yestr      2017
       ysstr      2018
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     DELENTRIES:
       dbrep.deleteoldentries
       delEntries
       1000
   OLDREADINGS:
   READINGS:
     2020-03-22 10:31:58   state           Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !
Attributes:
   alias      DBRep Device zum Löschen alter Einträge
   allowDeletion 1
   event-on-update-reading state
   icon       security
   room       92_Database
   showproctime 1
   timeOlderThan y:2
   timeout    86400


Im Normalfall wird das einfach per Zeitsteuerung so aufgerufen:

set dbrep.deleteoldentries delEntries

Das Attribut timeOlderThan ist ja auf  y:2 gesetzt. Nachdem das aber so nicht mehr ging, habe ich nun auch mal mit

set dbrep.deleteoldentries delEntries 1000

versucht, kommt aber der gleiche Fehler ... habe ich eine notwendige Änderung übersehen?

Grüße und bleibt gesund
Baumix

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 März 2020, 12:04:15
Hallo Baumix,

ich vermute das Modul hat recht.  :)

Dein ältester Datensatz in der DB ist

MINTS      2018-07-26 21:55:41

d.h. jünger als zwei Jahre. Dieser Timestamp wird implizit verwendet als timediffToNow (d.h. newer than) falls das Attribut timediffToNow  nicht gesetzt ist (war schon immer so).
Das gleiche gilt für

set dbrep.deleteoldentries delEntries 1000

Hier sollen Daten älter als 1000 Tage gelöscht werden.

Neu ist, dass ich durch die Einführung der möglichen Optionsangabe bei delEntries und reduceLog eine schärfere Prüfung implementiert habe, die deine etwas unglückliche Konfig ans Licht bringt.
Momentan löscht du ja in deiner DB nichts ...

Wenn du verbose 4 einschaltest, sieht man die Zusammenhänge recht gut im Log. Kannst du ja mal machen und posten. Aber ich denke es ist so wie beschrieben.

Du kannst es auch so prüfen:

set dbrep.deleteoldentries delEntries 1000:1010

Dadurch wird timediffToNow (= newer than) explizit auf 1010 Tage gesetzt und überschreibt MINTS. Damit wird es dann funktionieren.

Ebenfalls wird es funktionieren, wenn du zuätzlich

timediffToNow  y:3

setzt. Auch in diesem Fall ist die Forderung erfüllt.

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: baumix am 22 März 2020, 16:37:11
Hallo Heiko,

Zitat von: DS_Starter am 22 März 2020, 12:04:15
ich vermute das Modul hat recht.  :)

Naja, hat es  ;)

ZitatDein ältester Datensatz in der DB ist

MINTS      2018-07-26 21:55:41

d.h. jünger als zwei Jahre. Dieser Timestamp wird implizit verwendet als timediffToNow (d.h. newer than) falls das Attribut timediffToNow  nicht gesetzt ist (war schon immer so).

Tja, auf MINTS hatte ich tatsächlich nicht geachtet und ich war der festen Überzeugung, dass Einträge durch das Löschen aus der Datenbank fliegen ... war aber wohl nur delSeqDoublets und Konsorten ... ist ja auch ein Löschen ...

ZitatEbenfalls wird es funktionieren, wenn du zuätzlich

timediffToNow  y:3

setzt. Auch in diesem Fall ist die Forderung erfüllt.

Jepp, das hat funktioniert und ich habe sogar verstanden, warum ... war wohl meine Konfig von Anfang an kaputt, ist nur jetzt erst aufgefallen  ;D
Danke für die schnelle Hilfe!

Grüße
Baumix
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 27 März 2020, 00:03:13
Hallo Heiko,

ich muss nochmal meine Idee aufgreifen, die ich die Tage schon mal erwähnt habe:

Zitat von: flummy1978 am 20 März 2020, 00:23:12
Meine Idee wäre dann 1-7 Tage mit ungefilterten Werten arbeiten (anzeigen)
Der 5 und 30 Minuten Schnitt wird "live" von der DB erzeugt
Livedaten werden alle 7-x Tage mit Reduce Log dann auf Stunden Schnitt verringert und die 5-30 Minuten Schnittwerte sind ja immernoch vorhanden

ich hab jetzt ein wenig mit AverageValue rumgespielt, allerdings bin ich nicht so wirklich "zufrieden" mit dem Ergebnis. Ich versuche mal zu erklären, was ich gerne machen möchte. Vielleicht ist meine Herangehensweise aber auch vollkommener Blödsinn:

Ich habe ein Wettermodul, das mir sowohl Windgeschwindigkeit als auch Böen als Wert liefert. Da ich das Ganze als Schutz für eine Markise benötige, sind für mich die Böen wichtiger, als die normale Windgeschwindigkeit. Wenn ich jetzt allerdings normale Böen-Werte mitlogge habe ich ständig Sprünge von +4 -> 0 -> +4 ->  -> 0 usw .... teilweise nach einer Std (was ok ist) teilweise aber auch innerhalb von wenigen Sekunden.

Nun war meine Idee hier, ein at zu aktivieren, das immerwieder die Funktion averageValue aufruft und einen Schnitt der Böen über meinetwegen 30 Minuten erstellt. Diesen dann in die DB speichert und die alten Werte löscht. Den Durchschnitt berechnen und alles eintragen lassen, bekomme ich hin. Genauso wie ich nach einer gewissen Zeit dann auch die Einträge einfach löschen kann. Allerdings erfüllt die Funktion "WriteToDB[Single]" leider nicht das, was ich an der Stelle erwartet habe:
Der Wert wird nicht an die Stelle geschrieben, an der die Messung begonnen hat (in meinem Fall also JETZT bis JETZT -30 Min) sondern am ende des heutigen Tages. Das wäre für diese Funktion doch sehr unglücklich......
Im Endeffekt wäre diese Funktion doch dann im Prinzip das Gleiche wie "ReduceLog" nur zusätzlich mit Optionen anderen zeitraum als Schnitt zu nehmen, als nur Day oder Stunde - Aber Eintragen geht nur "Day" Grenze ???

Hab ich jetzt hier einen kompletten Denkfehler, oder ..... ?

Alternativ wäre (für mein Vorhaben) und für viele andere Möglichkeiten die mir grad so einfallen, auch der ReduceLog Befehl perfekt dafür, wenn man hier noch die Optionen hätte zwischen
ReduceLog average blubla ReduceLog average=day blubla zusätzlich auch die Mögichkeit hätte von ReduceLog average=30min blubla oder ReduceLog average=1800sek blubla oder oder oder ....

Bin mal gespannt was die Anregung dazu sagt ....  8)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 März 2020, 09:04:09
Morgen Andreas,

die Anregung weitere Aggregationen bei reduceLog anzubieten gab es schon mal. Ich würde das auch gerne machen, war bisher aber an der dann doch hohen Komplexität gescheitert (oder war nicht zielstrebig genug  ;) ).

Was aber vermutlich relativ gut machbar wäre, das WriteToDB[Single] so zu erweitern, dass die Auswertungszeitraumgrenzen mit berücksichtigt werden.
Ich probiere mal was und melde mich wieder ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 27 März 2020, 11:21:46
Guten Morgen die Damen (und Herren),

Zitat von: DS_Starter am 27 März 2020, 09:04:09
die Anregung weitere Aggregationen bei reduceLog anzubieten gab es schon mal. Ich würde das auch gerne machen, war bisher aber an der dann doch hohen Komplexität gescheitert (oder war nicht zielstrebig genug  ;) ).

Ich probiere mal was und melde mich wieder ...

Ich habe mir den betroffenen teil im Modul mit meinen bescheidenen Kentnissen angeschaut.... Kein Wunder, dass Dir bei sowas irgendwann mal der Kopf raucht  ;D
Wenn es kompletter Blödsinn ist, ignoriere es bitte schnell wieder. Ich hatte schon länger nicht mehr komplexer mit DBs zu tun - Perl in Verbindung mit DB in der Komplexität wie in Deinem Modul noch nie (selbst gebaut) ... aber vielleicht sehe ich ja einen Baum, den Du vor lauter Bäumen nicht siehst.....

8802 Log3 ($name, 4, "DbRep $name - UPDATE history SET TIMESTAMP=$updDate $updHour:30:00, EVENT='rl_av_h', VALUE=$average WHERE DEVICE=$hourHash->{$hourKey}->[1] AND READING=$hourHash->{$hourKey}->[3] AND TIMESTAMP=$hourHash->{$hourKey}->[0] AND VALUE=$hourHash->{$hourKey}->[4]->[0]");


In dem Bereich (die 5 Zeilen davor) wird der Durchschnitt errechnet richtig ?
Wäre es nicht sinnvoll an der Stelle mit den vorhanden Variablen Werten und den eingegebenen Werten (average, average=hour, average=1800(sek) usw .... ), einen Befehl wie

"SELECT Avg( VALUE ) AS 'rl_av_h[m][s]' FROM `history` WHERE `TIMESTAMP` BETWEEN '2020-03-27 08:00:00.000000' AND '2020-03-27 08:15:00.000000' AND DEVICE ....... AND READING LIKE '%humidity%' " zu generieren ?

------------Schnitt in der DB----------------------------------------------------------------------------Startzeit---------------------------------Endzeit-----------------------------------..... usw.
Die Endzeit wäre dann auch der Zeitpunkt zu dem man dann den Schnitt eintragen würde UND man könnte direkt in einem Abwasch die alten Werte löschen. (weil man ja die Veriablen Bedingungen in der gleichen Zeile genutzt hat)

Wie gesagt bitte ignorieren, wenn es kompletter Blödsinn ist  ??? Aber wenn nicht, hilft es ja vielleicht ein wenig ;)


Bitte nur keinen Stress, nur weil ICH es möchte ;)
Wenn es für andere auch hilfreich ist, wäre es natürlich toll. Für mich wäre es in diesem Fall eine sehr gute Hilfe....

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 März 2020, 21:07:38
Hallo Andreas, @all,

ich habe eine neue DbRep Version zum Test in mein contrib geladen.
Die Funktionen sumValue und averageValue sind nun ergänzt um die Option writeToDBInTime.
Diese Option dürfte dir schon weiterhelfen Andreas.

Die Optionen stellen nun folgende Möglichkeiten zur Verfügung:

writeToDB                : schreibt jeweils einen Wert mit den Zeitstempeln 00:00:01 und 23:59:59 innerhalb der jeweiligen Auswertungsperiode (wie bisher)
writeToDBSingle       : schreibt nur einen Wert mit dem Zeitstempel 23:59:59 am Ende einer Auswertungsperiode (wie bisher)
writeToDBInTime      : schreibt jeweils einen Wert am Anfang und am Ende der Zeitgrenzen einer Auswertungsperiode

Die Möglichkeiten bzgl. reduceLog schaue ich mir auch noch an. Vllt. kann ich dem User dort noch eine flexible Aggregationsmöglichkeit bieten, mal schauen. Vorher will ich mir allerdings die etwas weiter vorn schon erwähnte Möglichkeit des direkten Übertragens von Ergebnissen in ein Reading anschauen und ggf. umsetzen.

Download:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Wie immer freue ich mich um Testergebnisse, Meinungen anderer Anwender.  :)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 29 März 2020, 17:23:16
Hallöchen,

Zitat von: DS_Starter am 28 März 2020, 21:07:38
ich habe eine neue DbRep Version zum Test in mein contrib geladen.
Die Funktionen sumValue und averageValue sind nun ergänzt um die Option writeToDBInTime.
(Für mich) absolut perfekt. Macht genau das was es tun soll inkl. richtigem Zeitpunkt. Aktuell läuft es automatisch mit einem at alle 10 Min aber auch die 60-90 Min Tests mit "display" Ausgabe waren erfolgreich  :) *thumbsup*

Für mich dennoch immernoch sehr interessant: Gibt es eine Möglichkeit die Funktionen die Du dort nutzt (egal ob reduceLog, delEntries oder auch delSeqDoublets), irgendwie "hintenrum" (direkter Perl Befehl oder sonst etwas) mit entsprechenden Variablen zu übergeben,ohne dafür jedes mal ein neues DBRep Device zu nutzen ?
Ich frag einfach aus dem Grund, weil ich das für viele andere Sachen gern nutzuen würde (auch ältere Daten), wo ich dann aus dem Device heraus sowas aufrufen kann und nicht für jede Abfrage ein extra DBRep device brauche.

Dann nochmal eine ganz andere Frage:
Zitat von: DS_Starter am 16 März 2020, 11:38:10
..... Allerdings kannst du das alles mit nur  einem at Device antriggern. Stichwort heisst Chain mit den Attribut executeAfterProc.
Das habe ich probiert und in dem DBRep Device, das den neuen Befehl alle 10 Min ausführen soll, ein
attr DBrep_Wetter_windgust executeAfterProc set DBrep_Wetter_windgust delEntries
hinzugefügt.
Dummerweise führt er dann diesen Befehl nicht einmal aus, sondern ständig. Ich denke mal es liegt daran, dass ich das gleiche Device aufrufen wie das, das den Befehl "executeAfterProc" beinhaltet und mir damit ungewollt eine Endlosschleife bastele. Ich weiss nicht ob das übersehen habe, oder das nirgendwo erwähnt wird. Vielleicht wäre es eine Idee, das mit in die Doku aufzunehmen.
(Mit executebeforeProc isses noch schlimmer, weil man nichts anderes mehr ausgeführt wird, da gibts dann nur noch den bösen kill ;) )
Hast Du (oder jemand anders) n Tipp für mich, wie ich das umgehen / lösen kann ?

Da du auf meine Vorschlag nicht eingegangen bist, geh ich mal davon aus, dass es vollkommener Blödsinn war was ich gefunden / mir gedacht habe?  ::) :P

Auf jeden Fall vielen herzlichen Dank für die schnelle / geniale Umsetzung

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 März 2020, 17:48:37
Hallo Andreas,

ich fange mal hinten an ...

ZitatDa du auf meine Vorschlag nicht eingegangen bist, geh ich mal davon aus, dass es vollkommener Blödsinn war was ich gefunden / mir gedacht habe?  ::)
Ganz und garnicht. Ich arbeite nur meinen Plan schrittweise ab. Das kommt noch dran. Momentan bin ich dabei die automatische Übertragung von Readings in andere Devices zu implementieren.

ZitatDummerweise führt er dann diesen Befehl nicht einmal aus, sondern ständig. Ich denke mal es liegt daran, dass ich das gleiche Device aufrufen wie das, das den Befehl "executeAfterProc" beinhaltet und mir damit ungewollt eine Endlosschleife bastele.
Das ist richtig. Naja, ich dachte es ist relativ klar dass man sich nicht immer selbst aufrufen sollte.  ;)  Im Wiki-Beispiel habe ich auch geschriebendass man 4 verschiedene DbReps anlegt/kopiert ... Aber ich hebe es nochmal hervor  :)

ZitatFür mich dennoch immernoch sehr interessant: Gibt es eine Möglichkeit die Funktionen die Du dort nutzt (egal ob reduceLog, delEntries oder auch delSeqDoublets), irgendwie "hintenrum" (direkter Perl Befehl oder sonst etwas) mit entsprechenden Variablen zu übergeben,ohne dafür jedes mal ein neues DBRep Device zu nutzen ?
Das kann so pauschal nicht beantwortet werden. Wenn es reines SQL ist, kannst du es einem Rep mit sqlCmd übergeben. Kann natürlich immer ein anderes Statement sein.
Ansonsten kann man sich das anschauen wenn du mal ein ganz konkretes Beispiel / Aufgabe hast du du lösen möchtest. Es greift vieles ineinander, zum Beispiel auch die non-Blocking Implementierung. Die müstest du nachbauen. Meist kommt dann eins zu anderem. Ich glaube ich habe über 100 Devices ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 29 März 2020, 18:32:18
Hey,

vielen Dank für die schnelle Antwort :)
ob Du auf meinen Vorschlag eingehst oder nicht, war jetzt nicht so wichtig. Ich war in der Hinsicht nur neugierig, ob ich da mal was richtig erkannt habe oder ob es wirklich vollkommener Blödsinn war ;)  Vielleicht erfahr ich das ja dann später, wenn das an der Reihe ist.

Zitat von: DS_Starter am 29 März 2020, 17:48:37
Ich glaube ich habe über 100 Devices ...
:o Das erklärt einiges  :-\  (Nein es ist sicherlich nicht schlecht - siehe Erklärung, aber für mich "Neuland")

Als ich mich angefangen habe mit FHEM zu beschäftigen, haben mich immer Config Übersichten, die 500 Geräte (davon 400 Dummys) total abgeschreckt, weil es einfach nicht nachvollziehbar war. Wenn sich ein virt_Geräte sich im Hintergrund um 20 reale Geräte kümmert, ist es auch nicht immer übersichtlich aber leichter nachzuvollziehen. In diesem Fall wäre das so, dass sich ein Gerät um die Datenbank in Verbindung mit Wetterdaten kümmern soll, eines um Stromverbrauchsdaten und eines um das "normale" Aufräumen. Hier wäre es eben von Nöten verschiedene Befehle mit verschiedenen Attributen / Optionen in dem jeweiligen Device aufzurufen.  Ich müsste alternativ eben für jede Abfrage / korrektur oder sonst etwas jeweils ein neues Gerät erstellen.

Ich versuche einfach mit so wenig verschiedenen Geräten auszukommen wie möglich, damit innerhalb von Fhem eine Übersicht bleibt.
Automatische Timer / Verzögerung für Bewegungsmelder  (https://forum.fhem.de/index.php/topic,109585.msg1036256.html#msg1036256) oder Benachrichtigung / Auto-on-for-Timer für Geräte die bestimmte Attribute haben (https://forum.fhem.de/index.php/topic,109531.msg1035466.html#msg1035466) sind 2 Beispiele, die ich hier schon im Forum vorgestellt habe.

Vielleicht ist es aber auch so, dass ich da (noch) keine gescheite Idee für eine GUTE Struktur habe um eben NICHT die Übersicht zu verlieren, auch wenn es alleine von einem Type 100 Devices gibt Wenn Du mal Lust und Laune haben solltest, würde mich ein Auszug aus Deiner Config bzw die Übersicht der einzelnen Devices interessieren :)

Edith trägt noch etwas nach:  Wenn man das Device alle 10 Min ausführt, gibts n volles Log Gibt es eine Möglichkeit das im Log zu unterbinden (und dennoch nicht unbedingt gravierende Fehler zu übersehen?)
2020.03.30 03:34:15.305 3: DbRep DBrep_Wetter_windgust - number of lines updated in "DBLogging": 1
2020.03.30 03:34:15.306 3: DbRep DBrep_Wetter_windgust - number of lines inserted into "DBLogging": 1


Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 März 2020, 10:37:32
Hallo Heiko,

ich habe im Log folgende Meldung ... PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 67142) line 1.

Modul: # $Id: 93_DbRep.pm 21473 2020-03-21 21:09:33Z DS_Starter $

Kann man da was dagegen tun? Kennst du die Meldung schon? :)

Befehl:
set myDbRep exportToFile;

Danke

List des Devices:

Internals:
   DATABASE   fhem
   DEF        myDbLog
   FUUID      5c575e19-f33f-4fe4-eeb6-712d9409654163f4
   FVERSION   93_DbRep.pm:v8.38.0-s21473/2020-03-21
   LASTCMD    exportToFile
   MODEL      Client
   NAME       myDbRep
   NOTIFYDEV  global,myDbRep
   NR         506
   NTFY_ORDER 50-myDbRep
   ROLE       Client
   STATE      done » ProcTime:  sec
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE myDbLog
     GRANTS     CREATE ROUTINE,CREATE TEMPORARY TABLES,REFERENCES,CREATE VIEW,SHOW VIEW,USAGE,INDEX,EXECUTE,UPDATE,EVENT,TRIGGER,LOCK TABLES,ALTER,DROP,CREATE,SELECT,INSERT,DELETE,ALTER ROUTINE
     IDRETRIES  3
     MINTS      2014-06-09 09:32:12
     PACKAGE    main
     VERSION    8.38.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-03-30
       dsstr      2020-03-30
       epoch_seconds_end 1585557228
       mestr      03
       msstr      03
       testr      10:33:48
       tsstr      08:33:47
       wdadd      604800
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2020-03-30 10:33:48   state           done
Attributes:
   device     .*
   dumpCompress 1
   dumpDirLocal /opt/fhem/backup/db/
   event-on-change-reading .*
   expimpfile /opt/fhem/backup/db/%Y%m%d_%T.csv
   group      DB-Log
   optimizeTablesBeforeDump 1
   room       Server
   stateFormat { ReadingsVal($name,"state", undef) eq "running" ? "renaming" : ReadingsVal($name,"state", undef). " » ProcTime: ".ReadingsVal($name,"sql_processing_time", undef)." sec"}
   timeDiffToNow h:2


Stacktrace:


2020.03.30 10:29:53.775 1:     main::CallFn                        called by fhem.pl (757)
2020.03.30 10:29:53.775 1:     main::telnet_Read                   called by fhem.pl (3772)
2020.03.30 10:29:53.775 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2020.03.30 10:29:53.775 1:     main::AnalyzeCommand                called by fhem.pl (1100)
2020.03.30 10:29:53.775 1:     main::AnalyzePerlCommand            called by fhem.pl (1171)
2020.03.30 10:29:53.775 1:     (eval)                              called by fhem.pl (1146)
2020.03.30 10:29:53.774 1:     main::expfile_ParseDone             called by (eval 66785) (1)
2020.03.30 10:29:53.774 1:     main::readingsEndUpdate             called by ./FHEM/93_DbRep.pm (5895)
2020.03.30 10:29:53.774 1:     main::evalStateFormat               called by fhem.pl (4748)
2020.03.30 10:29:53.774 1:     (eval)                              called by fhem.pl (4645)
2020.03.30 10:29:53.774 1:     main::__ANON__                      called by (eval 66786) (1)
2020.03.30 10:29:53.774 1: stacktrace:
2020.03.30 10:29:53.774 1: eval: {expfile_ParseDone('myDbRep|568|0.01366,0.016039|0|.*|%|/opt/fhem/backup/db/20200330_10:29:53.csv')}
2020.03.30 10:29:53.774 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 66786) line 1.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 März 2020, 11:20:42
Moin zusammen,

im contrib gibt es nun eine erweiterte Version 8.40.0.
Mit dieser Version ist es nun möglich DbRep-Ergebnisse automatisch in andere Devices (z.B. dummy) zu übertragen.
Dafür gibt es das Attribut autoForward.

Auszug:

* autoForward - wenn aktiviert, werden die Ergebnisreadings einer Funktion in ein oder mehrere Devices übertragen.
Die Definition erfolgt in der Form:

{
  "<source-reading> => "<dest.device> [=> <dest.-reading>]",
  "<source-reading> => "<dest.device> [=> <dest.-reading>]",
  ...
}                               
                             

In der Angabe <source-reading> sind Wildcards (.*) erlaubt.

    Beispiel:

    {
      ".*"               => "Dum.Rep.All",             
      ".*AVGAM.*"  => "Dum.Rep     => average", 
      ".*SUM.*"      => "Dum.Rep.Sum => summary",
    } 
    # alle Readings werden zum Device "Dum.Rep.All" übertragen, Readingname bleibt im Ziel erhalten
    # Readings mit "AVGAM" im Namen werden zum Device "Dum.Rep" in das Reading "average" übertragen
    # Readings mit "SUM" im Namen werden zum Device "Dum.Rep.Sum" in das Reading "summary" übertragen

Wiki ergänze ich noch.

@Andreas ... verbose 2 einstellen. Kritische Meldungen erstelle ich im Modul immer mit verbose 2 oder 1.

@kadettilac89 ... Hmm, kannte ich noch nicht und kommt bei mir auch nicht. Habe eine Weile auf den Code geschaut und kam momentan noch nicht dahinter. Vermutung: du verwendest in deinem stateFormat eine Auswertung des Readings sql_processing_time, erzeugst es aber nicht. D.h. die angegebene Verknüpfung sollte auf jeden Fall eine Warnung werfen.

Edit: @Andreas ... ich habe 126 DbRep-Devs. Habe mit jsonlist2 eine Übersicht erzeugt. Das ist ganz schön viel. Was interessiert dich daran bzw. wozu brauchst du das?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kadettilac89 am 30 März 2020, 13:42:43
Zitat von: DS_Starter am 30 März 2020, 11:20:42
@kadettilac89 ... Hmm, kannte ich noch nicht und kommt bei mir auch nicht. Habe eine Weile auf den Code geschaut und kam momentan noch nicht dahinter. Vermutung: du verwendest in deinem stateFormat eine Auswertung des Readings sql_processing_time, erzeugst es aber nicht. D.h. die angegebene Verknüpfung sollte auf jeden Fall eine Warnung werfen.


Habe mal alle stateformat, alles was processing time beinhaltet rausgeworfen und die Readings des DBLog devices gelöscht. Meldung ist weg. danke
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 März 2020, 13:59:04
So kannst du es alternativ verwenden:


stateFormat { ReadingsVal($name,"state", "") eq "running" ? "renaming" : ReadingsVal($name,"state", ""). " » ProcTime: ".ReadingsVal($name,"sql_processing_time", "")." sec"}


Das wirft dann auch keine Fehler.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 30 März 2020, 15:04:46
Hallöchen,

zunächst einmal mehr ein RIESEN Lob, für Deine Arbeit... Ich weiss dass jeder seine eigene Art hat danke zu sagen, aber ich finde bei den Devs darf gerne mal ein Blick in die Signatir geworfen werden ;)

@Topic:
Ich GLAUBE, dass ich einen kleinen Bug entdeckt hab:

Berechnungsgrundlage: Der Durchschnitt der letzten 10 Minuten soll gerechnet werden.
List
Internals:
   .FhemMetaInternals 1
   DATABASE   user_fhem
   DEF        DBLogging
   FUUID      5e809fec-f33f-8d79-7131-84e8c885a567a522
   FVERSION   93_DbRep.pm:v8.39.0-s21473/2020-03-21
   LASTCMD    averageValue writeToDBInTime
   MODEL      Client
   NAME       DBrep_Wetter_windgust
   NOTIFYDEV  global,DBrep_Wetter_windgust
   NR         276
   NTFY_ORDER 50-DBrep_Wetter_windgust
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   .attraggr:
   .attrminint:
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     CREATE TEMPORARY TABLES,RELOAD,ALTER ROUTINE,UPDATE,INSERT,SHOW VIEW,CREATE VIEW,DELETE,DROP,TRIGGER,REPLICATION CLIENT,REFERENCES,INDEX,REPLICATION SLAVE,CREATE,CREATE ROUTINE,LOCK TABLES,EXECUTE,PROCESS,SELECT,ALTER,EVENT,FILE
     IDRETRIES  3
     MINTS      2019-09-22 01:30:00
     PACKAGE    main
     SQLHIST   
     VERSION    8.39.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-03-30
       dsstr      2020-03-30
       epoch_seconds_end 1585570932
       mestr      03
       msstr      03
       testr      14:22:12
       tsstr      14:12:12
       wdadd      604800
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2020-03-30 07:52:13   .associatedWith Wetterstation
     2020-03-30 14:22:13   2020-03-30__Wetterstation__wind_gust__AVGAM__no_aggregation 8.0000
     2020-03-30 14:22:13   db_lines_processed 2
     2020-03-30 14:22:13   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 1
   device     Wetterstation
   group      FileLog
   icon       own-log@darkgrey
   reading    wind_gust
   room       System->Datenbank
   timeDiffToNow m:10
   timeOlderThan m:0
   verbose    2


Ergebnis:

1. 2020-03-30 02:04:14 Wetterstation HP1000 calculated avgam_no_wind_gust 502790
2. 2020-03-30 02:34:14 Wetterstation HP1000 calculated avgam_no_wind_gust  0.0000 502823


Ich konnte noch nicht herausfinden, wann er den Wert LEER lässt und wann er eine 0.000 einfügt.

Das Problem ist allerdings bei dem Leeren Wert, wird beim Aufruf der entsprechenden Plots der Log vollgespamt:
2020.03.30 08:05:21.042 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 2130.
2020.03.30 08:05:21.043 1: stacktrace:
2020.03.30 08:05:21.043 1:     main::__ANON__                      called by ./FHEM/98_SVG.pm (2130)
2020.03.30 08:05:21.044 1:     main::SVG_render                    called by ./FHEM/98_SVG.pm (1186)
2020.03.30 08:05:21.044 1:     main::SVG_doShowLog                 called by ./FHEM/98_SVG.pm (258)
2020.03.30 08:05:21.044 1:     main::SVG_FwFn                      called by ./FHEM/01_FHEMWEB.pm (2042)
2020.03.30 08:05:21.045 1:     main::FW_showRoom                   called by ./FHEM/01_FHEMWEB.pm (1159)
2020.03.30 08:05:21.045 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.03.30 08:05:21.045 1:     main::FW_Read                       called by fhem.pl (3772)
2020.03.30 08:05:21.046 1:     main::CallFn                        called by fhem.pl (757)


Könnte man hier vielleicht eine Abfrage einsetzen, dass er einen Wert "NULL" oder eben leer gar nicht einfügt, sondern dann eben nichts / den letzten übernimmt oder der oder?

ZitatAuszug:

* autoForward - wenn aktiviert, werden die Ergebnisreadings einer Funktion in ein oder mehrere Devices übertragen.
Die Definition erfolgt in der Form:

{
  "<source-reading> => "<dest.device> [=> <dest.-reading>]",
  "<source-reading> => "<dest.device> [=> <dest.-reading>]",
  ...
}
Das ist gemein, je mehr Du einbaust umso mehr Möglichkeiten / Ideen kommen mir, wie ich SQL mehr Arbeit überlassen kann, statt FHEM  ::) ;D Die Wildcards .* werden sicherlich viele erfreuen, die sich mit DBs nicht auskennen. Ich denke es ist auf jeden Fall eine große Erleichterung, weil man die "Schreibstruktur" aus den anderen Modulen,Attributen etc von FHEM behalten kann.
Falls Du hier ein paar Tests "erwartest" würde das zumindest bei mir einiges dauern. Meine ToDo Liste ist grad ewig lang und ich komme kaum nach  :-\

ZitatEdit: @Andreas ... ich habe 126 DbRep-Devs. Habe mit jsonlist2 eine Übersicht erzeugt. Das ist ganz schön viel. Was interessiert dich daran bzw. wozu brauchst du das?
Ich lerne gern von anderen, die etwas womit ich mich einigermaßen auskenne, bereits wesentlich besser / intensiver / strukturierter einsetzen als ich. Bedeutet: Zwingend brauchen, würde ich von Dir nichts direkt, aber mich würde die Struktur interessieren. Du hast ja mal geschrieben, dass Du gern mit Rohdaten arbeitest und diese dann gezielt filterst. Das macht in vielen Fällen durchaus Sinn, benötigt aber auch ein gewisses Vorgehen. Als Beispiel:

Nummeriert einzelne Devices.

  • Daten der PV Anlage werden ungefiltert erfasst (ggf separate DB / Tabelle)
  • DBRep errechnet einen Zeitraum X-Schnitt für einen Detaillierten Überblick (aber deutlich weniger Daten)
  • SVG Plot für den live Überblick
  • DBRep errechnet einen Zeitraum Y-Schnitt für historische Daten
  • Ggf SVG Plot für historisches
  • DBRep verschiebt Durchschnittsdaten in eine andere Tabelle / Reading / was auch immer
  • DBRep bereinigt die Tabelle nach Zeitraum X avg=day
  • DBRep bereinigt die Tabelle nach Zeitraum Y avg=hour
  • usw
Das wäre jetzt eine Idee / Beispiel wie man mehrere Geräte für eine bestimmte Funktion bräuchte, die allerdings die Grundvorteile (und noch einige mehr) dass man ALLE Daten hätte, die man haben möchte oder behalten möchte UND Plots, Übersichtsseiten usw keine Unmengen auslesen müssten, weil entsprechende Schnittwerte vorhanden sind....

Ich hab grad massive Probleme in der umsortierung meiner Räume. Den Fehler würde ich gern beim Aufbau mit / um meine DB herum gern vermeiden. Genauso möchte ich auch vermeiden wie es hier mal zu finden war: ".....Meine DB hat 5 Mio Einträge in der DB und das Auslesen / Sichern / wiedereinspielen dauert ewig oder ist zu groß ...."

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 März 2020, 16:51:09
Danke Andreas  :),

Also ...

Zitat
Ich konnte noch nicht herausfinden, wann er den Wert LEER lässt und wann er eine 0.000 einfügt.
Ein 0.000 wird wenn der berechnete/ermittelte Wert tatsächlich 0 ergibt, wohingegen leer geliefert wird wenn wegen fehlender Werte kein Ergebnis berechnet/ermittelt werden konnte.
Allerdings bin ich der Meinung, dass im letzteren Fall immer ein "-" geliefert wird. Sollte das nicht so sein, muss ich tatsächlich nochmal danach schauen. Bräuchte dann mal ein konkretes Beispiel, also die konkret ausgeführte Aktion.

Bezüglich der Vorgehnsweise PV-Anlage... hattest du dir im Wiki schon mal das angeschaut:
https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung ?

Ist zwar schon etwas älter und DbRep kann inzwischen noch mehr, aber dennoch ein guter Einstieg denke ich.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 März 2020, 17:20:28
Ha, ich habe doch noch den kleinen Bug gefunden der dazu geführt hat, dass LEER als Value in die DB geschrieben hat wenn das Berechnungsergebnis leer oder "-" war.

Danke Andreas für den Stubs darauf !

Ist wieder im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 30 März 2020, 17:22:45
Leider nein. Das Beispiel oben ist exakt das Ergebnis aus der Tabelle gewesen. Es ist also nichts eingetragen gewesen kein NULL und auch nicht - Ich gehe davon aus, dass das daher rührt weil es in diesem Zeitraum keinerlei Daten gab - Das kann ich jetzt erstmal nicht mehr nachvollziehen, weil ich die leeren gelöscht habe. Das konkrete Beispiel ist exakt aus dem Device das ich oben gepostet habe. Oder was brauchst Du zusätzlich ?
Erledigt  8)
War grad dabei das zu schreiben ;) - Nicht dafür Du hilfst mir / uns - Da ist Bug Reporting inkl *grins*

Bezüglich der Vorgehnsweise PV-Anlage...
Ich habe keine PV Anlage ;D Das war jetzt nur ein Beispiel für die Menge der Devices. Es hätte auch Stromverbrauch, Temperatur oder oder oder sein können ;)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 März 2020, 21:36:42
Hallo zusammen,

habe den gegenwärtigen Stand eingecheckt (morgen früh im Update).

Das Wiki ist auch ergänzt: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Werte_automatisch_durch_DbRep_.C3.BCbertragen_lassen_.28ab_Version_8.40.0.29

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 31 März 2020, 13:18:50
Zitat von: DS_Starter am 30 März 2020, 16:51:09
Bezüglich der Vorgehnsweise PV-Anlage... hattest du dir im Wiki schon mal das angeschaut:
https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung ?

Ist zwar schon etwas älter und DbRep kann inzwischen noch mehr, aber dennoch ein guter Einstieg denke ich.
Ich denke mit den PV-Daten kann ich dienen, ich werde mich mal dran setzen und versuchen das Beispiel zu adaptieren.
Eine Uebertragung auf meine Kostal Plenticore ist nicht ganz so einfach, da nicht alle Werte exact so geliefert werden. Ich hoffe da einen Weg mit
DBrep zu finden, um die Berechnungen direkt aus der DB nutzen zu koennen.

Gruss
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 31 März 2020, 15:15:22
Hey Christian,

Zitat von: ch.eick am 31 März 2020, 13:18:50
DBrep zu finden, um die Berechnungen direkt aus der DB nutzen zu koennen.

ich denke mal für andere wäre das sicherlich interessant und sinnvoll ... unser Dach ist leider nach Norden, ich hoffe dass Du das nicht auf mein Beispiel bezogen hast. Daher muss ich nochmal wiederholen:
"...............Bezüglich der Vorgehnsweise PV-Anlage...
Ich habe keine PV Anlage ;D Das war jetzt nur ein Beispiel für die Menge der Devices. Es hätte auch Stromverbrauch, Temperatur oder oder oder sein können........"

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 31 März 2020, 19:31:51
Zitat von: flummy1978 am 31 März 2020, 15:15:22
Ich habe keine PV Anlage ;D
Alles gut, ich schreibe auch manchmal mit mir selber...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 28 April 2020, 15:12:09
Mahlzeit,

ich hab da (mal wieder) ein kleines Anliegen:

Wenn ich das nachfolgende Device mit "average Value writeToDBInTime" ausführe, kommt die Meldung:

ZitatIf you want write results back to database, attributes "device" and "reading" must be set. In that case "device" mustn't be a devspec and mustn't contain SQL-Wildcard (%). The "reading" to evaluate has to be a single reading and no list.

Demnach muss das Reading einzeln sein und keine Liste haben. In der Attr Erklärung ist aber explizit von einer Liste die Rede:
Zitatreading - Abgrenzung der DB-Selektionen auf ein bestimmtes oder mehrere Readings sowie exkludieren von Readings. Mehrere Readings werden als Komma separierte Liste angegeben. Es können SQL Wildcard (%) verwendet werden.
Wird dem Reading bzw. der Reading-Liste ein "EXCLUDE=" vorangestellt, werden diese Readings nicht inkludiert.

    Beispiele:
    attr <name> reading etotal
    attr <name> reading et%
    attr <name> reading etotal,etoday
    attr <name> reading eto%,Einspeisung EXCLUDE=etoday
    attr <name> reading etotal,etoday,Ein% EXCLUDE=%Wirkleistung

Bedeutet das zwangsläufig, dass es bei dieser Abfrage keine Möglichkeit gibt mehrere Readings eines Devices auf einen Schlag zu bearbeiten, oder hab ich da nen kleinen Bug gefunden, anstatt das Feature zu nutzen ?  ;D

Internals:
   .FhemMetaInternals 1
   .triggerUsed 0
   DATABASE   user_fhem
   DEF        DBLogging
   FUUID      5e809fec-f33f-8d79-7131-84e8c885a567a522
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    averageValue writeToDBInTime
   MODEL      Client
   NAME       DBrep_Wetter_windgust
   NOTIFYDEV  global,DBrep_Wetter_windgust
   NR         269
   NTFY_ORDER 50-DBrep_Wetter_windgust
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   .attraggr:
   .attrminint:
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     INSERT,DROP,UPDATE,LOCK TABLES,CREATE TEMPORARY TABLES,EVENT,REPLICATION CLIENT,REPLICATION SLAVE,SHOW VIEW,ALTER ROUTINE,ALTER,FILE,RELOAD,EXECUTE,CREATE,DELETE,INDEX,REFERENCES,CREATE ROUTINE,PROCESS,CREATE VIEW,SELECT,TRIGGER
     IDRETRIES  3
     MINTS      2019-09-22 01:30:00
     PACKAGE    main
     SQLHIST   
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-04-28
       dsstr      2020-04-28
       epoch_seconds_end 1588078598
       mestr      04
       msstr      04
       testr      14:56:38
       tsstr      14:46:38
       wdadd      518400
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2020-04-27 20:41:08   .associatedWith Wetterstation
     2020-04-28 14:56:39   2020-04-28__Wetterstation__wind_gust__AVGAM__no_aggregation -
     2020-04-28 14:56:39   db_lines_processed 0
     2020-04-28 14:56:39   state           done
Attributes:
   DbLogExclude .*
   alias      Windspitzen Schnitt errechnen
   allowDeletion 1
   device     Wetterstation
   group      Automatische DB Bereinigung
   icon       own-log@darkgrey
   reading    wind_gust,luminosity
   room       System->Datenbank
   timeDiffToNow m:10
   timeOlderThan m:0
   verbose    2


Ich bleibe ja dabei...... Das Modul ist genial  8) ;)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 April 2020, 15:51:35
ZitatBedeutet das zwangsläufig, dass es bei dieser Abfrage keine Möglichkeit gibt mehrere Readings eines Devices auf einen Schlag zu bearbeiten, oder hab ich da nen kleinen Bug gefunden, anstatt das Feature zu nutzen ?
Da muss ich selbst auch erstmal eine Weile drüber sinnieren  :) .. melde mich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 28 April 2020, 15:55:29
Zitat von: DS_Starter am 28 April 2020, 15:51:35
Da muss ich selbst auch erstmal eine Weile drüber sinnieren  :) .. melde mich.

Oh man ... irgendwann wirst Du mich hassen :-X ....oder warum muss ich immer sowas finden *lach*

Wenn es zu umständlich wird, sag bescheid, dann mache ich halt mehrere Geräte. So eine Abfrage mit einem Device zu erstellen wäre schon nice
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 April 2020, 17:12:56
Hallo Andreas,

Zitat
Bedeutet das zwangsläufig, dass es bei dieser Abfrage keine Möglichkeit gibt mehrere Readings eines Devices auf einen Schlag zu bearbeiten, oder hab ich da nen kleinen Bug gefunden, anstatt das Feature zu nutzen ? 
Also das ist kein Bug (hoffentlich bist du jetzt nicht enttäuscht  :D ), sondern ich habe es absichtlich so beschränkt.
Grund ist/war, dass ich für das Rückschreiben in die DB einen eindeutigen (regelkonformen) Devicenamen brauche und ebenfalls einen eindeutigen Readingnamen. Beides ist bei einer Liste mit Wildcards nicht gegeben.

Allerdings, wenn ich die ganze Sache mit etwas Abstand betrachte, könnte man sowohl für den Devicenamen  als auch Readingnamen generische Bezeichner erstellen wenn der User Listen verwendet.

Bezüglich Reading ist es sogar einfach. Hier kann ich den User verpflichten in solchen Fällen zwangsweise das Attribut readingNameMap zu setzen. Schwieriger ist es beim Devicenamen wenn mehrere Devices bzw. Namen mit Wildcards
verwendet werden.

Wenn man also das Problem des eindeutigen Devicenamens organisatorisch gelöst bekommt, könnte man diese Begrenzungen beseitigen.
Werde es mal auf meine ToDo setzen , bin aber auch für Ideen offen...  :)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 30 April 2020, 22:31:55
Hallo Heiko,

vielen Dank für die Erklärung. Wenn man (also ich) genauer drüber nachdenkt, macht es auch Sinn und ist auch gut so, dass Du ursprünglich daran gedacht hast ;)

Zitat von: DS_Starter am 30 April 2020, 17:12:56
Bezüglich Reading ist es sogar einfach. Hier kann ich den User verpflichten in solchen Fällen zwangsweise das Attribut readingNameMap zu setzen. Schwieriger ist es beim Devicenamen wenn mehrere Devices bzw. Namen mit Wildcards
verwendet werden.
Wenn man also das Problem des eindeutigen Devicenamens organisatorisch gelöst bekommt, könnte man diese Begrenzungen beseitigen.
Werde es mal auf meine ToDo setzen , bin aber auch für Ideen offen...  :)
readingNameMap wäre in der Tat eine Möglichkeit ...

Je länger ich darüber nachdenke umso mehr fallen mir nur zwei eine Möglichkeiten ein die für eine Mehrauswahl funktionieren würden:
1. Device:Reading - Liste .... d.h. JEDEM Reading muss auch von einem Device vorangestellt werden
Ist es nicht, gilt (wie bisher) das Device aus dem attr device (das könnte man ja prüfen ob die readings mit oder ohne device angegeben sind)
2. Mehrere Angaben von Reading NUR OHNE wildcards bei den Devices möglich .... (also DEVICE_ohneWildcard:READING_mitWildcard)

Wenn einem dann schon so viel erspart wird, kann man die paar Devices von Hand eingeben  ::)

Man könnte also die Prüfung ansetzen "nur Reading" -> dann gehen auch wildcards -> device:reading -> dann sind Wildcards nicht möglich (bzw nur auf reading beschränkt)

Ist zwar ziemlich gequillter Hirnschmalz, weil ich für heute schon mehr oder weniger durch bin, aber imho eine Möglichkeit....

Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Mai 2020, 20:01:08
Hallo Andreas,

ich glaube es liegt ein grundlegendes Mißverständnis vor ... vermutlich.  :)
Wenn man eine Liste bzw. Angaben mit Wildcards angibt, werden die Werte der auf diese Liste/Wildcards zutreffenden Devices und Readings _alle_ gemeinsam bewertet und aus _allen_ diesen Werten wird z.B. ein Durchschnitt oder Maxvalue usw. berechnet.

Um für eine solche Selektion und Berechnung einen _eindeutigen_ generischen Devicenamen für das Zurückschreiben in die DB zu erstellen, der außerdem auch einen Bezug zu der verwendeten Selektion enthält, erscheint mir momentan recht schwierig.

Vermutlich ist es aber garnicht das was du möchtest. Sondern ich vermute du willst eine Liste von Devices und Readings angeben deren Werte in einem Lauf ermittelt, aber im Ergebnis getrennt voneinander berechnet werden. Das wäre nicht möglich und mit getrennten DbReps zu machen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 01 Mai 2020, 20:11:17
Hey Heiko,

danke dass Du das Hirnjogging mit mir teilst  ;D

Zitat von: DS_Starter am 01 Mai 2020, 20:01:08
Vermutlich ist es aber garnicht das was du möchtest. Sondern ich vermute du willst eine Liste von Devices und Readings angeben deren Werte in einem Lauf ermittelt, aber im Ergebnis getrennt voneinander berechnet werden. Das wäre nicht möglich und mit getrennten DbReps zu machen.

Genau darum ging es ... es sollten natürlich nicht diversteste Werte über diverseste Readings zusammen gefasst und im Durchschnitt gerechnet werden, sondern wie Du schon vermutet hast (in meinem Fall):







Device                        Reading
Wetterstationwind_gust
Wetterstationluminosity
HauptzaehlerSchnitt_30min
NEbenzaehlerSchnitt_30min
uswusf

Irgendwie befürchte ich gerade dass der Raum mit meinen Datenbankdevices grad droht zu überfüllen  ::) :P

Vielen Dank dennoch, dass Du Dir mit mir die Gedanken gemacht hast

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Mai 2020, 21:08:40
ZitatIrgendwie befürchte ich gerade dass der Raum mit meinen Datenbankdevices grad droht zu überfüllen  ::)
Da ist immer noch Luft  :D

Kleiner Hinweis....
Wenn du sehr viele DbReps hast, setze dir überall das Attribute fastStart = 1:

attr TYPE=DbRep fastStart 1

Dadurch kontaktieren die Devices nicht die DB beim FHEM Start, sondern erst wenn sie das erste Mal eine Aktion ausführen.

LG,
Heiko 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 01 Mai 2020, 22:14:46
Zitat von: DS_Starter am 01 Mai 2020, 21:08:40
Da ist immer noch Luft  :D

attr TYPE=DbRep fastStart 1

Dadurch kontaktieren die Devices nicht die DB beim FHEM Start, sondern erst wenn sie das erste Mal eine Aktion ausführen.

Ich glaub auch ... so wie Du (100 ? oder wieviel war das noch ? ) werde ich wohl nicht hinkommen,also ist da immer Luft nach oben  ::)

Sehr sehr guter (Performence) Hinweis ... aber dann mal so als Idee... wäre das nicht grundsätzlich gut das als Standard zu machen ? Und nur wenn man es unbedingt will (wobei sich da für mich kein wirklicher Grund erschließt) dann fastStart 0 setzen zu müssen ?

VG
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Mai 2020, 22:18:22
ZitatSehr sehr guter (Performence) Hinweis ... aber dann mal so als Idee... wäre das nicht grundsätzlich gut das als Standard zu machen ? Und nur wenn man es unbedingt will (wobei sich da für mich kein wirklicher Grund erschließt) dann fastStart 0 setzen zu müssen ?
Ja, habe ich auch schon dran gedacht. Werde ich wohl machen wenn ich mal wieder am Modul arbeite.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 03 Mai 2020, 17:07:27
Ich mache offenbar hier etwas falsch da ich mit DbRep keinen Zugriff auf die Datenbank bekomme.

DbLog ist wie folgt definiert:


defmod Libelium_DbLog DbLog ./db.conf .*:.*

setstate Libelium_DbLog connected
setstate Libelium_DbLog 2020-05-03 17:02:32 state connected


db.conf sieht folgendermassen aus:

%dbconfig= (
    connection => "mysql:database=database;host=db;port=3306",
    user => "user",
    password => "password",
);


DbRep sieht folgendermassen aus:

defmod Libelium_Db DbRep Libelium_DbLog
attr Libelium_Db verbose 5

setstate Libelium_Db disconnected
setstate Libelium_Db 2020-05-03 16:53:33 errortext DBI connect('database=database;;host=192.168.1.171;;port=3306','user',...) failed: Unknown database 'database' at ./FHEM/93_DbRep.pm line 1841.\

setstate Libelium_Db 2020-05-03 16:53:33 state disconnected


Mir scheint ich hätte gemäss Vorgaben alle Perl Module installiert. Ich habe auch user und password über adminCredentials eingegeben.

Kann es damit zu tun haben dass die MySQL Datenbank extern angelegt wurde und die Tabellen "history" und "current" fehlen, dafür aber eine Tabelle mit einer anderen Bezeichnung vorhanden ist?

Hat da jemand eine Idee?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Mai 2020, 18:52:28
Momentan frage ich mich ob deine DB wirklich 'database'  heißt ? Ist ein bisschen ungewöhnlich und außerdem ist die Fehlermeldung recht eindeutig:

failed: Unknown database 'database'

ZitatMir scheint ich hätte gemäss Vorgaben alle Perl Module installiert. Ich habe auch user und password über adminCredentials eingegeben.
Damit hat es ganz sicher nichts zu tun. Dann kämen ganz andere Fehler.

Zitat
Kann es damit zu tun haben dass die MySQL Datenbank extern angelegt wurde und die Tabellen "history" und "current" fehlen, dafür aber eine Tabelle mit einer anderen Bezeichnung vorhanden ist?
What ?  :)  Wenn "history" und "current" fehlen, sollte DbLog aber auch Probleme haben. Weniger mit dem connect an sich, wohl aber beim Logging. Das gilt auch für DbRep beim Zugriff auf die Tabellen. Die Connect-Infos werden direkt aus dem angegebenen DbLog-Device gezogen.

Also ich habe noch kein richtiges Bild.
Poste mal bitte ein List vom DbLog 'list Libelium_DbLog' und vor allem auch die Ausgabe von "set Libelium_DbLog configCheck".

Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 03 Mai 2020, 21:58:03
Danke für die rasche Antwort. Die Datenbank heisst MeshliumDB. Hier die Listings:

'list Libelium_DbLog:

Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:.*
   FUUID      5eaeca15-f33f-8d74-606d-aa6c4b8136403502
   FVERSION   93_DbLog.pm:v4.9.12-s21801/2020-04-29
   MODE       synchronous
   MODEL      MYSQL
   NAME       Libelium_DbLog
   NR         191
   NTFY_ORDER 50-Libelium_DbLog
   PID        1083
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   UTF8       0
   dbconn     mysql:database=meshliumDB;host=192.168.1.171;port=3306
   dbuser     root
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    4.9.12
   Helper:
     DBLOG:
       state:
         Libelium_DbLog:
           TIME       1588535549.30821
           VALUE      connected
   READINGS:
     2020-05-03 21:52:29   state           connected
Attributes:


'set Libelium_DbLog config Check':

Result of version check

Used Perl version: 5.26.1
Used DBI (Database independent interface) version: 1.643
Used DBD (Database driver) version mysql: 4.046
Used DbLog version: 4.9.12.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=meshliumDB;host=192.168.1.171;port=3306, User -> root, Password -> read o.k.

Result of connection check

Connection to database was not successful.
Recommendation: Plese check logfile for further information.


Die Information zu den Tables in der Datenbank ist wie folgt:

MySQL [MeshliumDB]> show tables;
+----------------------+
| Tables_in_MeshliumDB |
+----------------------+
| bluetoothData        |
| currentSensors       |
| encryptionData       |
| gpsData              |
| last_data            |
| meshlium             |
| sensorParser         |
| sensors              |
| tokens               |
| users                |
| waspmote             |
| wifiScan             |
| zigbeeData           |
+----------------------+
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Mai 2020, 22:41:45
Schau mal configCheck sagt:


Result of connection check

Connection to database was not successful.
Recommendation: Plese check logfile for further information.

Wieso im state "connected" steht, kann ich mir noch nicht erklären.
Aber ich behaupte in diese DB wird nichts geschrieben, wohin auch ?
Es gibt keine history / current Tabellen.

Stehen denn im Logfile keine DbLog-Fehler ?  Das müsste doch eigentlich überlaufen  ;)

Morgen schaue ich weiter ...

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Mai 2020, 14:43:16
@uwirt, hast du noch Infos bzgl. Logausgaben von DbLog ?
(nicht das du jetzt auf irgendwas wartest  ;) )

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 05 Mai 2020, 17:09:20
Ich hatte da einen Schreibfehler - der Name der Datenbank ist nicht meshliumDB sondern MeshliumDB.
Das Logfile sieht nun folgendermassen aus:


2020.05.05 17:00:33 2: DbLog Libelium_DbLog -> Error table history - DBD::mysql::st execute_array failed: Table 'MeshliumDB.history' doesn't exist [err was 1146 now 2000000000]


Offenbar möchte ich etwas was man mit der Kombination DbLog und DbRep gar nicht tun kann, nämlich mit FHEM eine Tabelle aus einer MySql Datenbank auslesen, welche weder "history" noch "current" heisst?!

Aber immerhin: mit dem set Befehl "sqlCmd SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'" kriege ich schon mal die Werte meiner Sensoren als Readings dargestellt:


SqlResultRow_01

ID|ID_WASP|ID_SECRET|FRAME_TYPE|FRAME_NUMBER|SENSOR|VALUE|TIMESTAMP|SYNC|RAW|PARSER_TYPE

2020-05-05 17:22:55
SqlResultRow_02

1|sur001|403470039|128|72|TCB|16.37|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_03

2|sur001|403470039|128|72|HUMB|85.8|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_04

3|sur001|403470039|128|72|SOILT|15.83|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_05

4|sur001|403470039|128|72|UV|26.78|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_06

5|sur001|403470039|128|72|TCC|14.31|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_07

6|sur001|403470039|128|72|SOIL|5524.86|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_08

7|sur001|403470039|128|72|LW|0.000|2020-05-05 17:13:38|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_09

8|sur002|403470039|128|73|IN_TEMP|17.00|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_10

9|sur002|403470039|128|73|BAT|98|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_11

10|sur002|403470039|128|73|GMT|54|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_12

11|sur002|403470039|128|73|RSSI|85|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_13

12|sur002|403470039|128|73|RAM|73|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_14

13|sur002|403470039|128|73|STR|0|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
SqlResultRow_15

14|sur002|403470039|128|73|RAD|4.180645|2020-05-05 17:14:03|0|noraw|1

2020-05-05 17:22:55
sqlCmd

SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'

2020-05-05 17:22:55
sqlResultNumRows

14

2020-05-05 17:22:55
state

done

2020-05-05 17:22:55


Meine Frage wäre nun ob man wie man den Befehl sqlCmd regelmässig ausführen lassen kann?


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Mai 2020, 17:50:07
ZitatOffenbar möchte ich etwas was man mit der Kombination DbLog und DbRep gar nicht tun kann, nämlich mit FHEM eine Tabelle aus einer MySql Datenbank auslesen, welche weder "history" noch "current" heisst?!
Das ist richtig. Aktuell müssen die Tabellen genau so heißen. Allerdings hatte ich bereits angefangen, eigene Tabellennamen zu ermöglichen. Das ist aber noch nicht fertig umgesetzt und ist noch bisschen Zukunftsmusik.

ZitatAber immerhin: mit dem set Befehl "sqlCmd SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'" kriege ich schon mal die Werte meiner Sensoren als Readings dargestellt:...

Meine Frage wäre nun ob man wie man den Befehl sqlCmd regelmässig ausführen lassen kann?
sqlCmd ist "frei". Da kannst du quasi alles mit machen und auch andere Tabellen auswerten sofern der User die Rechte hat.
Du kannst sqlCmd wie jeden anderen Befehl auch zum Beispiel mit einem einfachen at-Device regelmäßig ausführen. Gibt ja auch noch mehr ... DOIF, timer ... und möglicherwiese noch weitere.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 05 Mai 2020, 21:33:55
Na dann freue ich mich wenn es mit den eigenen Tabellennamen so weit ist.

Kannst Du mir ein Beispiel für einen at-Device geben, ich muss dort ja wohl auch den Weg zur Datenbank nennen?!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Mai 2020, 21:44:40
Das ist nichts anderes als dein schon genanntes Beispiel von:

sqlCmd SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'

Das Statement nimmst du und packst es in ein at.
Hier mal ein von mir:


define At.DbRep.LogDB.FindNaDevs at +*72:00:00 set Rep.LogDB.FindNaDevs sqlCmd select device, count(*) from history group by DEVICE
attr At.DbRep.LogDB.FindNaDevs icon clock
attr At.DbRep.LogDB.FindNaDevs room Datenbank->Produktiv


Mit deinem Statement wäre es dann:

define At.DbRep.LogDB.FindNaDevs at +*72:00:00 set Rep.LogDB.FindNaDevs sqlCmd SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'
attr At.DbRep.LogDB.FindNaDevs icon clock
attr At.DbRep.LogDB.FindNaDevs room Datenbank->Produktiv


Der Weg zur DB und den damit verbundenen Angaben (credentials) sind ja in dem verwendeten DbRep (Rep.LogDB.FindNaDevs) bereits vorhanden. DbRep weiß welche DB es sein soll, nur mit history / current kannst du halt nicht operieren. Deswegen geht auch nur das sqlCmd weil dort die Tabelle, hier sensorParser, frei angeben kannst.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 06 Mai 2020, 07:19:57
Hallo Heiko,

ich habe eine Frage zu syncStandby:

Die SyncDB kann nur im gleichen Pfad liegen oder es ist z.B. auf dem NAS eine weitere DB-Instanz nötig (Client)!?

Aktuell mache ich einen Dump auf meinen Router (mit Samba). Da ist der Raspi ca. 2h sehr gut beschäftigt.

Ich würde gerne dort die SyncDB anlegen, alternativ ein 2. USB-Stick auf dem Raspi als Backup. Dazu müsste es die Möglichkeit geben für MariaDB unterschiedliche DB-Pfade anzugeben. Jedoch habe ich aktuell keine Infos gefunden, ob dies möglich ist.

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 08:25:20
Moin Bernd,

ZitatDie SyncDB kann nur im gleichen Pfad liegen oder es ist z.B. auf dem NAS eine weitere DB-Instanz nötig (Client)!?
Die SyncDB kann irgendwo liegen, also auch auf einem NAS oder bei AWS zB.
Wenn du sie beispielsweise auf dem NAS einrichtest, defininierst du auf deinem _lokalen_ FHEM ein zweites DbLog-Device welches die Verbindung zu dem NAS herstellt. Du verhinderst aber das irgendwas geloggt wird (z.B. wie im Wiki beschrieben).

-> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Dieses neue DbLog-Device (DbLog_Standby im Beispiel) gibst du im Sync-Kommando an:

set DbRep_Source syncStandby DbLog_Standby

DbRep_Source ist dein DbRep welches mit der Quelldatenbank (auf dem Raspi) verbunden ist, d.h. mit dem DbLog-Device welches in deine Quelldatenbank loggt.

Hoffe das hilft dir weiter. Ansonsten gerne fragen.  :)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 06 Mai 2020, 09:34:31
Danke Heiko,

soweit hatte ich das verstanden.

Aktuell liegt die Datenbank auf einem USB-Stick der am Raspi angeschlossen ist.

In der my.cnf ist datadir entsprechend angepasst.

Für das NAS etc. brauche ich, soweit mein Verständnis,  einen Mariadb-Client oder einen weiteren Mariadb-Server. Dafür dürfte der Router zu schwach sein!?

Mein NAS ist älter, das muss ich erst noch umbauen (andere FW/ freies Debian o.ä.).

Wenn ich nun auf dem Raspi mit Mariadb die SyncDB anlege, liegt diese auf dem gleichen USB-Stick oder kann ich ein zweites datadir angeben?

Dann könnte ich einen weiteren USB-Stick mounten oder den "Router" als Pfad nutzen.


Kurz:
Kann man ein zweites datadir anlegen?
Würde der Router (TP-WR1043 mit openWRT) für einen Mariadb-Client reichen?

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 11:16:03
Hallo Bernd,

ich glaube jetzt habe ich deine Fragen verstanden.

ZitatFür das NAS etc. brauche ich, soweit mein Verständnis,  einen Mariadb-Client oder einen weiteren Mariadb-Server. Dafür dürfte der Router zu schwach sein!?
Router würde ich komplett ausschließen für MariaDB-Server. Falls das überhaupt geht handelt man sich mM nach nur Schwierigkeiten ein.

Thema NAS ... du brauchst auf dem NAS den Mariadb-Server. Den Mariadb-Client installiert man einfach mit, aber den braucht man grundsätzlich auf dem Gerät von welchem aus man auf den Server zugreifen will, also dem Raspi. Den wirst du dort auch bereits haben.

ZitatWenn ich nun auf dem Raspi mit Mariadb die SyncDB anlege, liegt diese auf dem gleichen USB-Stick oder kann ich ein zweites datadir angeben?
Verschiedene datadir geht nicht in einer my.cnf. Das ist ja die Konfiguration für den einen vorhandenen MaraDB Server.
Allerdings kannst du durchaus mehrere MySQL/MariaDB Server auf einer Hardware betreiben wenn diese Hardware die Leistungsfähigkeit (CPU,RAM) mitbringt.

Für dieses Setup musst du aber etwas mehr machen und dich etwas einfuchsen. Hier ->
http://download.nust.na/pub6/mysql/doc/refman/5.1/de/multiple-servers.html
ist zum Beispiel beschrieben wie man sowas erstellen kann.

Hoffe jetzt hab ich es getroffen.  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 06 Mai 2020, 11:31:48
Jetzt passt es[emoji6]

Danke nochmals.

Schönen Tag noch und bleib gesund.
Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 12:13:08
Danke du auch !

BTW... du kannst alsStandby DB auch erstmal nur eine SQLite einsetzen. syncStandy kann ja auch mit unterschiedlichen Typen arbeiten.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 06 Mai 2020, 13:35:40
Ich habe das "at" wie beschrieben gemacht und erhalte folgenden Fehler im logfile:


2020.05.06 13:19:03 3: At.DbRep.LogDB.FindNaDevs: Please define Rep.LogDB.FindNaDevs first


Muss ich das zusätzlich definieren oder gibt es da einen Schreibfehler?

Ach ja und - wie kann ich die andauernd wiederkehrende Fehlermeldung im DbLog betreffend den fehlenden Tables unterbinden?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 13:57:16
ZitatMuss ich das zusätzlich definieren oder gibt es da einen Schreibfehler?
Naja, das war ja nur ein Beispiel  ;) Du must natürlich dein eigenes DbRep-Device statt "Rep.LogDB.FindNaDevs" eintragen welches du für das sqlCmd verwenden willst.

ZitatAch ja und - wie kann ich die andauernd wiederkehrende Fehlermeldung im DbLog betreffend den fehlenden Tables unterbinden?
verbose 0 im DbLog sollte helfen oder du könntest das DbLog-Device überhaupt mit disable = 1 deaktivieren. Du kannst eh nichts loggen und brauchst das Device nur für die Definition des DbRep.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 06 Mai 2020, 14:57:54
Ok - danke, das funktioniert jetzt soweit. Ich versuche jetzt auch mittels timeOlderThan/allowDeletion die Anzahl der Readings auf die letzte halbe Stunde zu limiteren. Mal sehen ob das klappt?!

Nun meine nächste Frage. Wie kann ich aus der Kombination Reading/Value:


SqlResultRow_121       120|sur001|403470039|128|42|TCB|15.99|2020-05-06 13:59:16|0|noraw|1       2020-05-06 14:48:43


ein Reading/Value


TCB    15.99


zaubern?

Das ursprüngliche Reading "SqlResultRow_121" hat unterschiedliche Nummern.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 06 Mai 2020, 15:22:51
Holla,

den Anstoß, dass es jemand anders eingerichtet hat und für mich jetzt hier demnächst der Umzug auf die neue Diskstation anliegt, hab ich das zweite Log Device und alles andere auch bei mir auch mal eingerichtet und hab 2 Fragen / Probleme damit:

1. Beim Ausführen des ganzen mit den Einstellungen aus dem Wiki  (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29)  u.a. attr DbRep_syncStandby_LiveDB timeDiffToNow d:5 - Denke das ist hier von Bedeutung.

list von dem betroffenem Device
Internals:
   .FhemMetaInternals 1
   CFGFN     
   DATABASE   user_fhem
   DEF        DBLogging
   FUUID      5eb2a8fc-f33f-8d79-0d07-0169629de19e3382
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    syncStandby DBLoggingMonnestation
   MODEL      Client
   NAME       DbRep_syncStandby_LiveDB
   NOTIFYDEV  global,DbRep_syncStandby_LiveDB
   NR         153824
   NTFY_ORDER 50-DBLogging_Monnestation_syncStandby
   ROLE       Client
   STATE      error : SQL-Zeit:
   TYPE       DbRep
   UTF8       1
   .attraggr:
   .attreour:
     state
   .attrminint:
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     INDEX,CREATE ROUTINE,TRIGGER,DELETE,REPLICATION CLIENT,RELOAD,SHUTDOWN,ALTER,CREATE USER,INSERT,PROCESS,SHOW VIEW,EXECUTE,SHOW DATABASES,SELECT,ALTER ROUTINE,UPDATE,REPLICATION SLAVE,LOCK TABLES,CREATE VIEW,CREATE TEMPORARY TABLES,REFERENCES,FILE,DROP,EVENT,CREATE
     IDRETRIES  3
     MINTS      2019-09-22 01:30:00
     PACKAGE    main
     SQLHIST   
     VERSION    8.40.0
     CV:
       aggregation day
       aggsec     86400
       destr      2020-05-06
       dsstr      2020-05-01
       epoch_seconds_end 1588770211
       mestr      05
       msstr      05
       testr      15:03:31
       tsstr      15:03:31
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1588766972.09021
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2020-05-06 15:04:35   errortext       DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 11322.

     2020-05-06 15:04:35   state           error
Attributes:
   DbLogExclude .*
   aggregation no
   event-on-update-reading state
   fastStart  1
   group      FileLog
   icon       own-log
   role       Client
   room       System->Datenbank
   showproctime 1
   stateFormat { (ReadingsVal($name,"state", ""))." : SQL-Zeit: ".(ReadingsVal($name,"sql_processing_time", "")) }
   timeDiffToNow d:5
   verbose    4


Hier sieht man schon, dass die Abfragen einwandfrei funktionieren bis hin zu ....  errortext       DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.....
Ausschnitt aus dem Log, nach dem Ausführen:
2020.05.06 15:04:27.277 3: DbRep DbRep_syncStandby_LiveDB - total lines transfered to standby database: 11084
2020.05.06 15:04:27.278 3: DbRep DbRep_syncStandby_LiveDB - number of lines inserted into "DBLoggingMonnestation": 11084
2020.05.06 15:04:27.293 4: DbRep DbRep_syncStandby_LiveDB - SQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where TIMESTAMP >= '2020-05-06' AND TIMESTAMP <= '2020-05-06 15:03:31' ;
2020.05.06 15:04:34.440 1: PERL WARNING: Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 15:04:34.440 1: stacktrace:
2020.05.06 15:04:34.441 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 15:04:34.441 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 15:04:34.441 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 15:04:34.442 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 15:04:34.442 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 15:04:34.442 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 15:04:34.442 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 15:04:34.443 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 15:04:34.443 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 15:04:34.443 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 15:04:34.443 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 15:04:34.444 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 15:04:34.444 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 15:04:34.444 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 15:04:34.444 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 15:04:34.445 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 15:04:34.445 1: stacktrace:
2020.05.06 15:04:34.445 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 15:04:34.446 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 15:04:34.446 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 15:04:34.446 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 15:04:34.446 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 15:04:34.447 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 15:04:34.447 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 15:04:34.447 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 15:04:34.448 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 15:04:34.448 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 15:04:34.448 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 15:04:34.448 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 15:04:34.449 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 15:04:34.449 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 15:04:34.449 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 15:04:34.450 2: DbRep DbRep_syncStandby_LiveDB - DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 11322.

2020.05.06 15:04:34.991 2: DbRep DbRep_syncStandby_LiveDB - DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 11322.

2020.05.06 15:04:35.027 4: DbRep DbRep_syncStandby_LiveDB -> BlockingCall change_Done finished


Kann da jemand sehen wo das Problem liegt ? *grübel*

2. Es handelt sich um ein "copyStandby" nicht syncStandby richtig ? Wenn ich den o.g. Teil 2 mal ausführe, hab ich auch von allen Einträgen 2 in der ZielDB. Oder gibt es auch hier nochmal irgedwo eine Möglichkeit, wo vielleicht auch gelöschte Einträge mit synchronisiert werden ?

2020-05-05 23:59:49 read_OG_SZ_conditions READINGSPROXY Humidity: 50.4 Humidity 50.4 94065
2020-05-05 23:59:49 read_OG_SZ_conditions READINGSPROXY Humidity: 50.4 Humidity 50.4 44323


Ansonsten.... mal ehrlich Heiko. Mit jeder Funktioni die ich hier oder auch im DbLog eingesetzt hab, bin ich begeisterter von den beiden Modulen.. ist der Hammer :)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 15:32:40
Du könntest das Attribut sqlResultFormat = json setzen und es selbst dekodieren (siehe ComRef) oder du wendest das Modul expandJSON darauf an. Das wäre nur _ein_ möglicher Weg.
Schau dir auch mal das Wiki an -> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Readingwerte_von_DbRep_in_ein_anderes_Device_.C3.BCbertragen

@Andreas

- das erste Problem kommt sicherlich daher dass du in deiner Quell-DB Datensätze ohne gültiges Datum hast, must du suchen und rausschmeißen

- das zweite Problem umgeht man am Besten indem man die Tabellen in der SyncDB mit einem primary Key anlegt. Steht direkt gleich zu Beginn des Kapitels im Wiki beschrieben -> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Danke Andreas  :) ... da ist jahrelanges Entwickeln eingeflossen ....

Wenn ich mit Rasenmähen fertig bin kann ich weiter mit dir und Andreas fachsimpeln.  :D

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 06 Mai 2020, 15:59:01
Zitat von: DS_Starter am 06 Mai 2020, 15:32:40
- das erste Problem kommt sicherlich daher dass du in deiner Quell-DB Datensätze ohne gültiges Datum hast, must du suchen und rausschmeißen

- das zweite Problem umgeht man am Besten indem man die Tabellen in der SyncDB mit einem primary Key anlegt. Steht direkt gleich zu Beginn des Kapitels im Wiki beschrieben -> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29
Genau das war mein Ansatz .. aber egal wie ich in der Tabelle suche, ich finde einfach auf Teufel komm raus keinen eintrag ohne Datum ;( Hast Du eine Idee dafür ?
Siehe da ... während ich den Beitrag geschrieben hab, hat die Geschichte mit dem Primary Key das Problem genauso gelöst. Wenn ich es jetzt doppelt ausführe gibt es 1. keine Fehlermeldung mehr und 2. keine doppelten Einträge

Aaahhh Schande über mein Haupt .... den Satz hab ich zig mal gelesen und gedacht "Ja stimmt .. hab ich eingefügt". Aber Depp wie ich bin, hab ich meine vorhandene Tabelle kopiert, statt die SQL Anweisung aus dem Wiki zu nehmen -.-  Sorry ......
Aber es löscht immernoch keine Einträge richtig ? D.h. Einträge die gesynct wurden und später in der QuellDB gelöscht werden, werden dann in der ZielDB nicht mehr aktualisiert oder ?

Tante Edith ergänzt noch einen Schönheitsfehler
Nach jeder Abfrage kommt mit verbose 4 die Fehlermeldung Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm betroffener Logteil:

2020.05.06 16:52:00.813 1: PERL WARNING: Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 16:52:00.814 1: stacktrace:
2020.05.06 16:52:00.820 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 16:52:00.820 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 16:52:00.821 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 16:52:00.821 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 16:52:00.821 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 16:52:00.822 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 16:52:00.822 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 16:52:00.823 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 16:52:00.823 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 16:52:00.823 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 16:52:00.824 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 16:52:00.824 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 16:52:00.824 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 16:52:00.825 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 16:52:00.825 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 16:52:00.826 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 16:52:00.826 1: stacktrace:
2020.05.06 16:52:00.826 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 16:52:00.827 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 16:52:00.827 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 16:52:00.828 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 16:52:00.828 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 16:52:00.828 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 16:52:00.829 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 16:52:00.829 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 16:52:00.829 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 16:52:00.830 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 16:52:00.830 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 16:52:00.831 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 16:52:00.831 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 16:52:00.831 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 16:52:00.832 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 16:52:02.736 3: DbRep DbRep_syncStandby_LiveDB - total lines transfered to standby database: 7781
2020.05.06 16:52:02.737 3: DbRep DbRep_syncStandby_LiveDB - number of lines inserted into "DBLoggingMonnestation": 354


Zitat... da ist jahrelanges Entwickeln eingeflossen ....
Wenn ich mit Rasenmähen fertig bin kann ich weiter mit dir und Andreas fachsimpeln. 
Das merkt man sofort ... Schönes Fachwissen super umgesetzt :)
Och Du .... ich hätte hier auch nochmal 350 m² zu mähen  ;D  Wobei .... 300 davon übernimmt der (Määäääh)Robbi .. das hält sich also in Grenzen ;)

Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 16:58:15
So .. fertsch  :)

ZitatWobei .... 300 davon übernimmt der (Määäääh)Robbi .. das hält sich also in Grenzen
Das wird bei mir immer Handarbeit bleiben ... wegen der Bewegung  ;) Sonst sonst man tatsächlich nur noch vor der Kiste, ohne Witz. Außerdem stehe ich mittlerweile den Dingern wegen dem Naturschutz etwas ablehnend gegenüber. Viele Kleintiere wie z.B. Igel fallen diesen Geräten zum Opfer. Vielleicht auch weil die Besitzer sie nicht richtig handhaben, mag sein :-\.

ZitatAber es löscht immernoch keine Einträge richtig ? D.h. Einträge die gesynct wurden und später in der QuellDB gelöscht werden, werden dann in der ZielDB nicht mehr aktualisiert oder ?
Ja, du hast recht, müßte eigentlich copyStandby heißen. Es würde den Eintrag nicht löschen.
Sollte ursprünglich ein richtiges Sync werden, ist aber "nur" ein kopieren geworden und nun scheue ich mich den Set Befehl umzubenennen. Vielleicht baue ich es ja auch noch aus ... wer weiß.  :)

Aber ich setze das Problem wegen dem fehlenden Timestamp mal auf meine ToDo. Wenn DbRep sowas unter die Finger bekommt, soll der Sync nicht abbrechen, sondern nur einen Logeintrag schreiben und den Datensatz beim Übertragen ignorieren. Dabei wird die Warnung:

PERL WARNING: Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.

gleich mit korrigiert.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 06 Mai 2020, 21:33:41
Das mit dem limitieren der Grösse des json-Readouts mit timeOlderThan/allowDeletion auf die letzte halbe Stunde zu machen funktioniert nicht.


defmod Libelium_Db DbRep Libelium_DbLog
attr Libelium_Db userattr reading01Name reading01Regex
attr Libelium_Db allowDeletion 1
attr Libelium_Db reading01Name air_temperature
attr Libelium_Db reading01Regex (?s)HUMB\|([0-9.]+)
attr Libelium_Db sqlResultFormat json
attr Libelium_Db timeOlderThan 900

setstate Libelium_Db done
setstate Libelium_Db 2020-05-06 21:18:43 SqlResult {"001":"ID|ID_WASP|ID_SECRET|FRAME_TYPE|FRAME_NUMBER|SENSOR|VALUE|TIMESTAMP|SYNC|RAW|PARSER_TYPE","002":"1|sur001|403470039|128|22|TCB|13.22|2020-05-06
12:07:43|0|noraw|1","003":"2|sur001|403470039|128|22|HUMB|86.7|2020-05-06
12:07:43|0|noraw|1","004":"3|sur001|403470039|128|22|SOILT|14.60|2020-05-06
12:07:43|0|noraw|1","005":"4|sur001|403470039|128|22|UV|32.27|2020-05-06
12:07:43|0|noraw|1","006":"5|sur001|403470039|128|22|TCC|12.00|2020-05-06
12:07:43|0|noraw|1","007":"6|sur001|403470039|128|22|SOIL|5571.03|2020-05-06
12:07:43|0|noraw|1","008":"7|sur001|403470039|128|22|LW|0.000|2020-05-06

... etc ...

21:13:25|0|noraw|1","585":"584|sur002|403470039|128|121|GMT|54|2020-05-06
21:13:25|0|noraw|1","586":"585|sur002|403470039|128|121|RSSI|52|2020-05-06
21:13:25|0|noraw|1","587":"586|sur002|403470039|128|121|RAM|40|2020-05-06
21:13:25|0|noraw|1","588":"587|sur002|403470039|128|121|STR|0|2020-05-06
21:13:25|0|noraw|1","589":"588|sur002|403470039|128|121|RAD|4.180645|2020-05-06
21:13:25|0|noraw|1"}
setstate Libelium_Db 2020-05-06 21:18:43 sqlCmd SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'
setstate Libelium_Db 2020-05-06 21:18:43 sqlResultNumRows 588
setstate Libelium_Db 2020-05-06 21:18:43 state done


Muss ich da was anders machen?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2020, 21:58:16
ZitatMuss ich da was anders machen?
Ja, mal die CommandRef zum sqlCmd lesen.  ;)

Dort steht:
....
Sollen die im Modul gesetzten Attribute "timestamp_begin" bzw. "timestamp_end" im Statement berücksichtigt werden, können die Platzhalter "§timestamp_begin§" bzw. "§timestamp_end§" dafür verwendet werden.
...

Es gibt auch Beispiele zur Verwendung.
Im Gegensatz zu anderen Befehlen weiß ich ja nicht was der User für SQL Statements absetzen möchte. Deswegen muss man an der Stelle Platzhalter verwenden um sie an der richtigen Stelle einzufügen.
D.h. die Attributwerte timestamp_begin bzw. timestamp_end werden in deinem Statement an den Stellen eingefügt wo du die Platzhalter platziert hast.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 07 Mai 2020, 11:14:58
Moin,

Ich denke mal Du hast das schon korrekt und nicht als irgendwie Kritik verstanden ;).... Ich schreibe hier ziemlich alles auf, was mir persönlich auffällt. Wenn es so gewollt ist oder ein Fehler von meiner Seite ist es ja ok. Wenn es ein mini Fehler wie "Use of uninitialized value..." den ich durch Zufall finde, hilft es Dir ja sicher auch

Zitat von: DS_Starter am 06 Mai 2020, 16:58:15
Ja, du hast recht, müßte eigentlich copyStandby heißen. Es würde den Eintrag nicht löschen.
Sollte ursprünglich ein richtiges Sync werden, ist aber "nur" ein kopieren geworden und nun scheue ich mich den Set Befehl umzubenennen. Vielleicht baue ich es ja auch noch aus ... wer weiß.  :)
Ich (und bin mir sicher einige andere auch) hätte da vermutlich nichts dagegen, wenn Du da mal wieder Lust zu basteln hättest. Ich weiss nicht wie andere das DB Log ansich einsetzen, aber durch meine anderen Beiträge hier merkt man, dass ich zu den leuten gehöre die in 1-2 Jahren nicht in ihre DB schauen wollen und feststellen OooOOoo die DB hat 10 GB  OooOOoo  jetzt weiß ich auch warum das Ding immer langsamer wurde, in den letzten Wochen / Monaten.
Sprich ich nutze meine DB im aktuellen Zustand mit sehr vielen "Spammer" Werten. Aber manche Werte wie Wind, Regen, Helligkeit (vom Wetter), Messwerte der Stromzähler und andere werden teilweise im Live Betrieb nach 15 Min (Stichwort averageValue und writeToDbInTime ;) )oder nach 1 Woche oder 3 Monaten reduziert.  Teilweise gibt es Daten die möchte man noch einen Monat später ins Detail wissen, oft reicht aber auch ein 15 min oder 1 Std Schnitt. Da wäre natürlich ein richtiges Syncen schon besser, weil man das perfekt als Backup nutzen könnte.

Wie gesagt ... je öfter ich mit den Modulen zu tun hab .... umso mehr schwärm ich davon  8)

Komplett OT:
Zitat von: DS_Starter am 06 Mai 2020, 16:58:15
Das wird bei mir immer Handarbeit bleiben ... wegen der Bewegung  ;) Sonst sonst man tatsächlich nur noch vor der Kiste, ohne Witz. Außerdem stehe ich mittlerweile den Dingern wegen dem Naturschutz etwas ablehnend gegenüber. Viele Kleintiere wie z.B. Igel fallen diesen Geräten zum Opfer. Vielleicht auch weil die Besitzer sie nicht richtig handhaben, mag sein :-\.
Ich hab hier noch so viel Handarbeit drum herum, da bin ich echt froh, dass ich das nicht zwingend machen muss. Körperlich betonter Job und n "selber-Kernsanierer-Haus", verlangt einem schon viel ab, aber dennoch kann ich irgendwo auch Deine Skepsis nachvollziehen. Das liegt in der Tat (oftmals) an der falschen Handhabe, weil man sie bei bestimmtem Wetter / Jahreszeit einfach mal weglassen muss. Dann hat man es nicht verhindert, aber schon minimiert.

VG
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 07 Mai 2020, 11:47:40
Ich habe das wohl mit dem regelmässigen löschen der Tabelle offenbar nicht richtig verstanden. Ich habe mir jetzt ein "Lösch-DbRep" gemacht dass ich dann per "at" regelmässig auslösen möchte.

Nur leider wen ich das per "set" Befehl händisch auslösen möchte z.B. mit:


set Libelium_Db.Del delEntries 1:2


kriege ich einen Fehler:


Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !



defmod Libelium_Db.Del DbRep Libelium_DbLog
attr Libelium_Db.Del allowDeletion 1
attr Libelium_Db.Del comment löschen aller Einträge in Libelium_Db älter als 30 Minuten
attr Libelium_Db.Del devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Libelium_Db.Del event-on-update-reading state
attr Libelium_Db.Del room Datenbank->Produktiv
attr Libelium_Db.Del timeOlderThan 1800

setstate Libelium_Db.Del Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !
setstate Libelium_Db.Del 2020-05-07 11:36:32 state Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !


Weiss da jemand weiter?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 07 Mai 2020, 11:54:36
Habs grad fix bei mir getestet, weil ich hier auch grad rumspiele:

Zitat von: uwirt am 07 Mai 2020, 11:47:40

set Libelium_Db.Del delEntries 1:2


Wenn Du das exakt so eingibst, wäre wohl die Log Ausgabe interessant (verbose 4).

Wenn ich set DbRep_syncStandby_LiveDB 250:251 eingebe, versucht er auch laut log, zu löschen wo nichts zu löschen ist... funktioniert also wie gewollt ;)

Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 07 Mai 2020, 12:01:05
Das LogFile mit verbose 4 sieht folgendermassen aus:


2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - -------- New selection ---------
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Command: delEntries
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - timeDiffToNow - year: , day: 2, hour: , min: , sec:
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Year 2020 is leap year
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - startMonth: 4 endMonth: 4 lastleapyear:  baseYear: 2020 diffdaylight:1 isdaylight:1
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - timeOlderThan - year: 0, day: 1, hour: 0, min: 0, sec: 0
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Year 2020 is leap year
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - startMonth: 0 endMonth: 4 lastleapyear: 1 baseYear: 2020 diffdaylight:1 isdaylight:1
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - FullDay option: 0
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Time difference to current time for calculating Timestamp begin: 172801 sec
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Timestamp begin human readable: 2020-05-05 11:59:42
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Time difference to current time for calculating Timestamp end: 172801 sec
2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Timestamp end human readable: 2020-05-05 11:59:42
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 07 Mai 2020, 12:07:15
Aber hier musst Du dann wohl auf Heiko(DS_Starter) warten  ::)
Entweder hast Du nen Bug gefunden oder ......
Zitat
2020.05.07 11:52:41.182 4 : DbRep DbRep_syncStandby_LiveDB - -------- New selection ---------
2020.05.07 11:52:41.182 4 : DbRep DbRep_syncStandby_LiveDB - Command: delEntries
2020.05.07 11:52:41.184 4 : DbRep DbRep_syncStandby_LiveDB - timeDiffToNow - year: , day: 251, hour: , min: , sec:
2020.05.07 11:52:41.185 4 : DbRep DbRep_syncStandby_LiveDB - Year 2020 is leap year
2020.05.07 11:52:41.185 4 : DbRep DbRep_syncStandby_LiveDB - startMonth: 7 endMonth: 4 lastleapyear: 2020 baseYear: 2019 diffdaylight:1 isdaylight:1
2020.05.07 11:52:41.186 4 : DbRep DbRep_syncStandby_LiveDB - timeOlderThan - year: 0, day: 250, hour: 0, min: 0, sec: 0
2020.05.07 11:52:41.187 4 : DbRep DbRep_syncStandby_LiveDB - Year 2020 is leap year
2020.05.07 11:52:41.187 4 : DbRep DbRep_syncStandby_LiveDB - startMonth: 8 endMonth: 7 lastleapyear: 2020 baseYear: 2019 diffdaylight:1 isdaylight:1
2020.05.07 11:52:41.188 4 : DbRep DbRep_syncStandby_LiveDB - FullDay option: 0
2020.05.07 11:52:41.188 4 : DbRep DbRep_syncStandby_LiveDB - Time difference to current time for calculating Timestamp begin: 21772801 sec
2020.05.07 11:52:41.189 4 : DbRep DbRep_syncStandby_LiveDB - Timestamp begin human readable: 2019-08-29 11:52:40
2020.05.07 11:52:41.189 4 : DbRep DbRep_syncStandby_LiveDB - Time difference to current time for calculating Timestamp end: 21686401 sec
2020.05.07 11:52:41.190 4 : DbRep DbRep_syncStandby_LiveDB - Timestamp end human readable: 2019-08-30 11:52:40
2020.05.07 11:52:41.422 3 : DbRep DbRep_syncStandby_LiveDB - Entries of user_fhem.history deleted: /--/--0

So sieht die Ausgabe bei mir mit 250:251 aus ... also exakt richtig und mit Deiner gleich, bis hin zu  2020.05.07 11:59:43 4: DbRep Libelium_Db.Del - Timestamp begin human readable: 2020-05-05 11:59:42 hier müsste 2020-05-04 11:59:42 stehen ...

Kannst Du es ggf. mit anderen zahlen testen ? 2:3[22:23] (dabei reading so wirr schreiben, dass er Dir nix löscht - wenn es eine live DB ist)

Wie gesagt, ich versuche nur zu helfen, auswendig kenne ich das Modul sicher nicht, kann also vollkommener Blödsinn sein, den ich schreibe ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Mai 2020, 12:37:52
Moin,

@Andreas ...

ZitatIch denke mal Du hast das schon korrekt und nicht als irgendwie Kritik verstanden ;)
Wie kommst du denn darauf, wieso sollte ich ?

Konstruktive Hinweise/Kritik ist doch immer willkommen weil

a) ich / das Modul dadurch immer besser werden
b) die User sehr oft geniale Ideen haben, die man selbst wegen der oft eingefahrenen/einseitigen Sichtweise garnicht bekommt
c) ich machmal auch richtig Schrott produziere  :o  ;)

Ich hätte soviel an den ganzen Modulen zu tun und zu überarbeiten (auch manch dusslige Stelle) dass der Tag mehr als 24 Stunden haben könnte. Aber das geht nicht und ich muß mich auch mal selbst maßregeln, dass das andere Leben nicht zu kurz kommt, gerade jetzt im nahen Sommer -> Natur.  :D
Deswegen kommt so manches auf die ToDo ... wird aber meist nicht vergessen und kommt irgendwann.

@uwirt ...

ich vermute du hast nicht die aktuelle DbRep Version  93_DbRep.pm:v8.40.0-s21546/2020-03-30.
Das war mal ein Bug der schon gefixt ist und jetzt nicht mehr auftritt (gerade probiert).

Aber unabhängig davon wird dir das nichts nützen. Du verwendest keine history/current Tabellen. Deswegen werden bis auf Ausnahmen (z.B. sqlCmd) die Standardbefehle bei dir nicht funktionieren.
Du müsstest dir alles über eigene Statements zusammenbauen die du über sqlCmd dann ausführst.
Das wäre zumindest solange der Weg bis ich dem User die Möglichkeit gegebenen habe history/current durch Äquivalente ersetzen zu können.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 07 Mai 2020, 13:03:27
Danke für deine rasche Antwort Heiko - ich glaube jetzt habe ich es kapiert!

Kann ich dann das entsprechende sqlCmd von einem anderen "at" aus auf dieselbe DbRep loslassen oder muss ich pro "at" ein eigenes DbRep erstellen?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Mai 2020, 13:37:17
ZitatKann ich dann das entsprechende sqlCmd von einem anderen "at" aus auf dieselbe DbRep loslassen oder muss ich pro "at" ein eigenes DbRep erstellen?
Technisch geht sowohl als auch. Ich empfehle für jede Aufgabe ein separates Device. Vor allem wenn man diverse Attribute gesetzt hat um zum Beispiel in deinem Fall die Ausgabe von sqlCmd zu formatieren.
Ist ein bisschen Geschmackssache.

BTW: wenn du es dir zutraust, könntest du im gesamten Modul "history" gegen <deine Tabelle> tauschen, bzw. current ebenfalls. Geht mit einem Editor ganz schnell. Dann solltest du alle Fnktionen nutzen können. Musst das Modul dann natürlich vom Update ausnehmen bis ich so eine Äquivalenzmöglichkeit eingebaut habe.
Sollte aber gehen ...

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 13:42:09
ZitatDas geht alles in einem DbRep Device.
Es wird allerdings hier OT. Deswegen kopiere dir mal bitte das Rep.STP5000.Erzeugung.Monat  auf ein anderes, zum Beispiel Rep.Report.

Und stelle dann ein List davon in den DbRep Thread oder mache wegen mir auch einen neuen auf. Dann schauen wir uns das am späten Nachmittag gemeinsam an. Bin grad etwas beschäftigt.  ;)

Wenn du allein schon mal schauen willst, fetchrows istvdas Stichwort für DbRep.

LG,
Heiko

Hallo Heiko,

ich denke der Übeltäter ist gefunden:

2020-05-17_20-57-41__1__SMA_Wechselrichter__etotal    455.958           2020-05-18 13:07:09
2020-05-18_04-55-24__1__SMA_Wechselrichter__etotal    4294967.295       2020-05-18 13:07:09
2020-05-18_05-28-56__1__SMA_Wechselrichter__etotal    455.958           2020-05-18 13:07:09


CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec26a8e-f33f-cd72-b513-8c4f195609a12cf4
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       Rep.Report
   NOTIFYDEV  global,Rep.Report
   NR         33412
   NTFY_ORDER 50-Rep.Report
   ROLE       Client
   STATE      <html>done - Warning: present rows exceed specified limit, adjust attribute <a href='https://fhem.de/commandref_DE.html#limit' target='_blank'>limit</a></html>
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-31
       dsstr      2020-05-01
       epoch_seconds_end 1590962399
       mestr      05
       msstr      05
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589800029.40616
           VALUE      <html>done - Warning
   OLDREADINGS:
   READINGS:
     2020-05-18 13:07:09   2020-05-17_09-58-04__1__SMA_Wechselrichter__etotal 421.511
     2020-05-18 13:07:09   2020-05-17_09-59-05__1__SMA_Wechselrichter__etotal 421.587
     2020-05-18 13:07:09   2020-05-17_10-00-06__1__SMA_Wechselrichter__etotal 421.663
     2020-05-18 13:07:09   2020-05-17_10-01-07__1__SMA_Wechselrichter__etotal 421.739
     2020-05-18 13:07:09   2020-05-17_10-02-08__1__SMA_Wechselrichter__etotal 421.816
     2020-05-18 13:07:09   2020-05-17_10-03-09__1__SMA_Wechselrichter__etotal 421.893
     2020-05-18 13:07:09   2020-05-17_10-04-10__1__SMA_Wechselrichter__etotal 421.97
     2020-05-18 13:07:09   2020-05-17_10-05-11__1__SMA_Wechselrichter__etotal 422.047
     2020-05-18 13:07:09   2020-05-17_10-06-12__1__SMA_Wechselrichter__etotal 422.124
     2020-05-18 13:07:09   2020-05-17_10-07-13__1__SMA_Wechselrichter__etotal 422.202
     2020-05-18 13:07:09   2020-05-17_10-08-14__1__SMA_Wechselrichter__etotal 422.28
     2020-05-18 13:07:09   2020-05-17_10-09-15__1__SMA_Wechselrichter__etotal 422.358
     2020-05-18 13:07:09   2020-05-17_10-10-16__1__SMA_Wechselrichter__etotal 422.435
     2020-05-18 13:07:09   2020-05-17_10-11-17__1__SMA_Wechselrichter__etotal 422.514
     2020-05-18 13:07:09   2020-05-17_10-12-18__1__SMA_Wechselrichter__etotal 422.593
     2020-05-18 13:07:09   2020-05-17_10-13-19__1__SMA_Wechselrichter__etotal 422.672
     2020-05-18 13:07:09   2020-05-17_10-14-20__1__SMA_Wechselrichter__etotal 422.751
     2020-05-18 13:07:09   2020-05-17_10-15-21__1__SMA_Wechselrichter__etotal 422.831
     2020-05-18 13:07:09   2020-05-17_10-16-22__1__SMA_Wechselrichter__etotal 422.911
     2020-05-18 13:07:09   2020-05-17_10-17-23__1__SMA_Wechselrichter__etotal 422.991
     2020-05-18 13:07:09   2020-05-17_10-18-23__1__SMA_Wechselrichter__etotal 423.069
     2020-05-18 13:07:09   2020-05-17_10-19-24__1__SMA_Wechselrichter__etotal 423.15
     2020-05-18 13:07:09   2020-05-17_10-20-25__1__SMA_Wechselrichter__etotal 423.229
     2020-05-18 13:07:09   2020-05-17_10-21-26__1__SMA_Wechselrichter__etotal 423.31
     2020-05-18 13:07:09   2020-05-17_10-23-28__1__SMA_Wechselrichter__etotal 423.473
     2020-05-18 13:07:09   2020-05-17_10-24-29__1__SMA_Wechselrichter__etotal 423.555
     2020-05-18 13:07:09   2020-05-17_10-26-31__1__SMA_Wechselrichter__etotal 423.719
     2020-05-18 13:07:09   2020-05-17_10-27-32__1__SMA_Wechselrichter__etotal 423.801
     2020-05-18 13:07:09   2020-05-17_10-28-33__1__SMA_Wechselrichter__etotal 423.883
     2020-05-18 13:07:09   2020-05-17_10-32-37__1__SMA_Wechselrichter__etotal 424.212
     2020-05-18 13:07:09   2020-05-17_10-33-38__1__SMA_Wechselrichter__etotal 424.295
     2020-05-18 13:07:09   2020-05-17_10-34-39__1__SMA_Wechselrichter__etotal 424.379
     2020-05-18 13:07:09   2020-05-17_10-35-40__1__SMA_Wechselrichter__etotal 424.462
     2020-05-18 13:07:09   2020-05-17_10-36-41__1__SMA_Wechselrichter__etotal 424.545
     2020-05-18 13:07:09   2020-05-17_10-37-42__1__SMA_Wechselrichter__etotal 424.629
     2020-05-18 13:07:09   2020-05-17_10-38-43__1__SMA_Wechselrichter__etotal 424.713
     2020-05-18 13:07:09   2020-05-17_10-39-44__1__SMA_Wechselrichter__etotal 424.797
     2020-05-18 13:07:09   2020-05-17_10-40-45__1__SMA_Wechselrichter__etotal 424.882
     2020-05-18 13:07:09   2020-05-17_10-41-46__1__SMA_Wechselrichter__etotal 424.966
     2020-05-18 13:07:09   2020-05-17_10-42-47__1__SMA_Wechselrichter__etotal 425.05
     2020-05-18 13:07:09   2020-05-17_10-43-48__1__SMA_Wechselrichter__etotal 425.134
     2020-05-18 13:07:09   2020-05-17_10-44-49__1__SMA_Wechselrichter__etotal 425.219
     2020-05-18 13:07:09   2020-05-17_10-45-50__1__SMA_Wechselrichter__etotal 425.305
     2020-05-18 13:07:09   2020-05-17_10-46-51__1__SMA_Wechselrichter__etotal 425.39
     2020-05-18 13:07:09   2020-05-17_10-47-52__1__SMA_Wechselrichter__etotal 425.476
     2020-05-18 13:07:09   2020-05-17_10-48-53__1__SMA_Wechselrichter__etotal 425.561
     2020-05-18 13:07:09   2020-05-17_10-49-54__1__SMA_Wechselrichter__etotal 425.647
     2020-05-18 13:07:09   2020-05-17_10-50-55__1__SMA_Wechselrichter__etotal 425.733
     2020-05-18 13:07:09   2020-05-17_10-51-56__1__SMA_Wechselrichter__etotal 425.819
     2020-05-18 13:07:09   2020-05-17_10-52-56__1__SMA_Wechselrichter__etotal 425.906
     2020-05-18 13:07:09   2020-05-17_10-53-57__1__SMA_Wechselrichter__etotal 425.992
     2020-05-18 13:07:09   2020-05-17_10-54-58__1__SMA_Wechselrichter__etotal 426.078
     2020-05-18 13:07:09   2020-05-17_10-55-59__1__SMA_Wechselrichter__etotal 426.165
     2020-05-18 13:07:09   2020-05-17_10-57-00__1__SMA_Wechselrichter__etotal 426.251
     2020-05-18 13:07:09   2020-05-17_10-58-01__1__SMA_Wechselrichter__etotal 426.338
     2020-05-18 13:07:09   2020-05-17_10-59-02__1__SMA_Wechselrichter__etotal 426.425
     2020-05-18 13:07:09   2020-05-17_11-00-03__1__SMA_Wechselrichter__etotal 426.512
     2020-05-18 13:07:09   2020-05-17_11-01-04__1__SMA_Wechselrichter__etotal 426.6
     2020-05-18 13:07:09   2020-05-17_11-02-05__1__SMA_Wechselrichter__etotal 426.688
     2020-05-18 13:07:09   2020-05-17_11-04-07__1__SMA_Wechselrichter__etotal 426.863
     2020-05-18 13:07:09   2020-05-17_11-06-09__1__SMA_Wechselrichter__etotal 427.04
     2020-05-18 13:07:09   2020-05-17_11-07-10__1__SMA_Wechselrichter__etotal 427.129
     2020-05-18 13:07:09   2020-05-17_11-08-11__1__SMA_Wechselrichter__etotal 427.218
     2020-05-18 13:07:09   2020-05-17_11-09-12__1__SMA_Wechselrichter__etotal 427.308
     2020-05-18 13:07:09   2020-05-17_11-10-13__1__SMA_Wechselrichter__etotal 427.397
     2020-05-18 13:07:09   2020-05-17_11-11-14__1__SMA_Wechselrichter__etotal 427.486
     2020-05-18 13:07:09   2020-05-17_11-12-16__1__SMA_Wechselrichter__etotal 427.575
     2020-05-18 13:07:09   2020-05-17_11-13-16__1__SMA_Wechselrichter__etotal 427.664
     2020-05-18 13:07:09   2020-05-17_11-14-17__1__SMA_Wechselrichter__etotal 427.752
     2020-05-18 13:07:09   2020-05-17_11-15-18__1__SMA_Wechselrichter__etotal 427.841
     2020-05-18 13:07:09   2020-05-17_11-16-19__1__SMA_Wechselrichter__etotal 427.931
     2020-05-18 13:07:09   2020-05-17_11-17-20__1__SMA_Wechselrichter__etotal 428.02
     2020-05-18 13:07:09   2020-05-17_11-18-21__1__SMA_Wechselrichter__etotal 428.109
     2020-05-18 13:07:09   2020-05-17_11-19-22__1__SMA_Wechselrichter__etotal 428.199
     2020-05-18 13:07:09   2020-05-17_11-20-23__1__SMA_Wechselrichter__etotal 428.29
     2020-05-18 13:07:09   2020-05-17_11-21-24__1__SMA_Wechselrichter__etotal 428.381
     2020-05-18 13:07:09   2020-05-17_11-22-25__1__SMA_Wechselrichter__etotal 428.471
     2020-05-18 13:07:09   2020-05-17_11-23-26__1__SMA_Wechselrichter__etotal 428.563
     2020-05-18 13:07:09   2020-05-17_11-24-27__1__SMA_Wechselrichter__etotal 428.655
     2020-05-18 13:07:09   2020-05-17_11-25-28__1__SMA_Wechselrichter__etotal 428.746
     2020-05-18 13:07:09   2020-05-17_11-26-29__1__SMA_Wechselrichter__etotal 428.837


     2020-05-18 13:07:09   background_processing_time 0.0247
     2020-05-18 13:07:09   number_fetched_rows 1000
     2020-05-18 13:07:09   sql_processing_time 0.0216
     2020-05-18 13:07:09   state           <html>done - Warning: present rows exceed specified limit, adjust attribute <a href='https://fhem.de/commandref_DE.html#limit' target='_blank'>limit</a></html>
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_month_begin
   timestamp_end current_month_end
   userExitFn setDumEnergy .*:.*
   verbose    3


Wie muss ich den Eintrag jetzt löschen?

Danke und VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 16:44:34
Hallo Dieter,

ja, das ist der Datensatz.
Ich zeige dir die Löschmöglichkeit in DbRep mit der man ohne SQL-Kenntnisse auskommt (geht auch mit sqlCmd).

Stell dir bitte die Zeitattribute auf den Timestamp des Datensatzes ein:

   
timestamp_begin 2020-05-18 04:55:24
timestamp_end   2020-05-18 04:55:24


Und führe dann ein fetchrows aus. Es darf nur noch dieser eine Datensatz angezeigt werden !!
Wenn das so ist,schalte dir die Löschfunktion des Devices frei mit:

attr <name> allowDeletion 1

Und dann löscht du den Satz mit:

set <name> delEntries

In den Readings wird die Anzahl der gelöschten Datensätze angezeigt, im Idealfall nur einer  ;)
Danach schaltest du aus Sicherheitsgründen die Löschfreigabe wieder aus -> "allowDeletion 0".

Und ein erneuter fetchrow-Lauf zeigt dir dass der Datensatz gelöscht ist. Fertig.
Das neue Device kannst du behalten, kann man immer mal gebrauchen für einen Blick in die DB oder diverse Pflegeaktionen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 17:03:54
Noch mal Danke für deine Hilfe.

Alles so gemacht wie beschrieben.

Nach erneutem fetchrows sieht es so aus:

CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec26a8e-f33f-cd72-b513-8c4f195609a12cf4
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       Rep.Report
   NOTIFYDEV  global,Rep.Report
   NR         33412
   NTFY_ORDER 50-Rep.Report
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-14
       dsstr      2020-03-24
       epoch_seconds_end 1589468429.79918
       mestr      05
       msstr      03
       testr      17:00:29
       tsstr      17:00:29
       wdadd      518400
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     DELENTRIES:
       Rep.Report
       delEntries
       2020-05-18
       04:55:24
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589814030.85593
           VALUE      done
   OLDREADINGS:
   READINGS:
     2020-05-18 17:00:30   2020-05-14_16-50-55__1__SMA_Wechselrichter__etotal 325.952
     2020-05-18 17:00:30   2020-05-14_16-51-56__1__SMA_Wechselrichter__etotal 325.985
     2020-05-18 17:00:30   2020-05-14_16-52-57__1__SMA_Wechselrichter__etotal 326.032
     2020-05-18 17:00:30   2020-05-14_16-53-58__1__SMA_Wechselrichter__etotal 326.079
     2020-05-18 17:00:30   2020-05-14_16-54-59__1__SMA_Wechselrichter__etotal 326.124
     2020-05-18 17:00:30   2020-05-14_16-56-00__1__SMA_Wechselrichter__etotal 326.168
     2020-05-18 17:00:30   2020-05-14_16-58-02__1__SMA_Wechselrichter__etotal 326.252
     2020-05-18 17:00:30   2020-05-14_16-59-03__1__SMA_Wechselrichter__etotal 326.278
     2020-05-18 17:00:30   2020-05-14_17-00-04__1__SMA_Wechselrichter__etotal 326.303
     2020-05-18 17:00:30   background_processing_time 0.0028
     2020-05-18 17:00:30   number_fetched_rows 9
     2020-05-18 17:00:30   sql_processing_time 0.0003
     2020-05-18 17:00:30   state           done
Attributes:
   aggregation no
   allowDeletion 0
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin 2020-05-18 04:55:24
   timestamp_end 2020-05-18 04:55:24
   userExitFn setDumEnergy .*:.*
   verbose    3


Da stimmt doch mit dem Datum was nicht?

Wenn ich begin + end wieder auf Monat stelle, erhalte ich auch nicht mehr Einträge.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 17:31:50
Wieviel Sätze hat er angezeigt die gelöscht wurden ?

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 17:32:55
Asche auf mein Haupt.
Nicht geguckt  ???
Habe aber exakt nach deiner Anleitung gehandelt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 17:40:42
Lösch mal die beiden Zeitattribute und setze

timeDiffToNow  d:1

Dann nochmal fetchrows.
Das sieht doch echt merkwürdig aus. Habe bei mir auch mal einen DS gelöscht und war alles gut.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 18:11:57
sieht genauso aus.
Ich befürchte das alle Einträge futsch sind.

Habe übrigens das gefunden:

2020.05.18 16:50:29.425 3: DbRep Rep.Report - Entries of /opt/fhem/fhem.db.history deleted: SMA_Wechselrichter--etotal--2451
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 18:28:13
Ja da wurde zuviel gelöscht  :o
Da muss man echt aufpassen ...

Restore der DB !



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 18:31:16
Bevor ich noch mehr zerschieße....

Restore DB mache ich wie?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 18:42:50
Du hast SQLite wenn ich das richtig sehe. Hast du ein Backup der DB ? D.h. sicherst du die DB regelmäßig mit DbRep oder anders ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 18:45:13
nein, habe ich nicht gemacht. Läuft auch erst seit paar Tagen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 18:47:27
Ah ok ... Lessons learned.
Niemals ohne Backup unterwegs sein !

Das richten wir jetzt zusammen ein damit du immer eine Sicherung hast wenn du möchtest.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 18:50:07
Super wie hilfsbereit du bist. Vielen Dank hierfür.

Heißt also auch, die Daten sind futsch?

Dann ist demnach auch der ganze Monat vermurkst?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 18:52:32
Ja leider. Es sei denn du hast kürzlich noch eine Filesicherung von /opt/fhem/ gemacht wo die SQLite mit drauf ist.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 18:54:21
nur ein Backup von fhem von Gestern.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 18:56:43
Dann könnten wir Glück haben. Schau mal ob dort das File /opt/fhem/fhem.db drauf ist.
War zu dem Zeitpunkt der Filesichrung FHEM laufend oder heruntergefahren ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 19:02:51
fhem war am laufen.

Die Sicherung ist ein ...tar.gz

Wie sehe ich da ob das File /opt/fhem/fhem.db dabei ist?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 19:09:26
Das ist blöd dass FHEM lief. Da könnte es sein dass das File der DB nicht zu gebrauchen ist. Aber das gucken wir uns später an.

Jetzt erstmal das Backup.
Kopiere die das DbRep erstmal nach Rep.SQLite.Backup und lösche alle Zeit-Attribute, timeout, reading, device.
Dann zeige bitte nochmal ein list.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 19:21:04
das mache ich alles in fhem?

Du meinst das DbRep das ich kopiert hatte?
Nicht die eigentlichen Rep.SMAEM....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 19:23:35
Zitatdas mache ich alles in fhem?
Verstehe die Frage nicht, was meinst du ?

ZitatDu meinst das DbRep das ich kopiert hatte?
Nicht die eigentlichen Rep.SMAEM....
Das spielt keine Rolle.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 19:27:39
Ob ich das alles in der Weboberfläche von fhem machen soll.

Hier das Ergebnis:

CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec2c4f7-f33f-cd72-91f5-f58c6964ed304ce0
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD     
   MODEL      Client
   NAME       Rep.SQLite.Backup
   NOTIFYDEV  global,Rep.SQLite.Backup
   NR         40732
   NTFY_ORDER 50-Rep.SQLite.Backup
   ROLE       Client
   STATE      connected
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589822742.84872
           VALUE      connected
   OLDREADINGS:
   READINGS:
     2020-05-18 19:25:42   background_processing_time 0.0021
     2020-05-18 19:25:42   index_state     Index Report_Idx exists
     2020-05-18 19:25:42   sql_processing_time 0.0009
     2020-05-18 19:25:42   state           connected
Attributes:
   aggregation no
   allowDeletion 0
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   event-on-update-reading state
   room       Photovoltaik
   showproctime 1
   userExitFn setDumEnergy .*:.*
   verbose    3
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 19:36:11
Ach so. Ja alles im FHEMWEB.

Im Device noch löschen die Attribute aggregation, userExitFn, allowDeletion. Den room ggf. noch anpassen.

Jetzt die Frage in welches Verzeichnis die Dumps geschrieben werden sollen ? Default ist /opt/fhem/log.
Und wieviele Generationen du im Verzeichnis aufheben willst. Default sind 3. D.h. also drei Backup-Files.
Wenn du genug Platz hast, kannst du das erhöhen.


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 19:38:40
alles gelöscht, Rest lasse ich wie default
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 19:48:07
Gut, jetzt setzen:

dumpCompress 1  -> die Dumfiles werden komprimiert
fastStart 1            -> Device verbindet sich erst mit der DB wenn es eine Aufgabe erledigen soll

Dann Backup starten mit

set Rep.SQLite.Backup dumpSQLite

-> Backup startet

Was zeigt das Logfile ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 20:09:15
habe nach wiki konfiguriert:

CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec2c4f7-f33f-cd72-91f5-f58c6964ed304ce0
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    dumpSQLite
   MODEL      Client
   NAME       Rep.SQLite.Backup
   NOTIFYDEV  global,Rep.SQLite.Backup
   NR         40732
   NTFY_ORDER 50-Rep.SQLite.Backup
   ROLE       Client
   STATE      Warning - dump finished, but command message after dump appeared
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     VERSION    8.40.0
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589825103.96432
           VALUE      Warning - dump finished, but command message after dump appeared
   OLDREADINGS:
   READINGS:
     2020-05-18 20:05:03   DumpFileCreated ./log/fhem_2020_05_18_20_05.sqlitebkp
     2020-05-18 20:05:03   DumpFileCreatedSize 452.95 MB
     2020-05-18 20:05:03   DumpRowsCurrent n.a.
     2020-05-18 20:05:03   DumpRowsHistory n.a.
     2020-05-18 20:05:03   afterdump_message Reopen executed.
     2020-05-18 20:05:03   background_processing_time 14.3588
     2020-05-18 20:05:03   state           Warning - dump finished, but command message after dump appeared
Attributes:
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   event-on-update-reading state
   executeAfterProc set logdb reopen
   executeBeforeProc set logdb reopen 3600
   optimizeTablesBeforeDump 1
   room       Photovoltaik
   showproctime 1
   verbose    3




2020.05.18 20:04:49.523 3: DbRep Rep.SQLite.Backup - ################################################################
2020.05.18 20:04:49.524 3: DbRep Rep.SQLite.Backup - ###                    New SQLite dump                       ###
2020.05.18 20:04:49.524 3: DbRep Rep.SQLite.Backup - ################################################################
2020.05.18 20:04:49.524 3: DbRep Rep.SQLite.Backup - execute command before dump: 'set logdb reopen 3600'
2020.05.18 20:04:49.596 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem/fhem.db before optimize (MB): 479
2020.05.18 20:04:49.596 3: DbRep Rep.SQLite.Backup - VACUUM database /opt/fhem/fhem.db....
2020.05.18 20:05:00.501 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem/fhem.db after optimize (MB): 453
2020.05.18 20:05:00.502 3: DbRep Rep.SQLite.Backup - Starting dump of database 'fhem.db'
2020.05.18 20:05:03.940 3: DbRep Rep.SQLite.Backup - Size of backupfile: 452.95 MB
2020.05.18 20:05:03.942 3: DbRep Rep.SQLite.Backup - Finished backup of database fhem - total time used (hh:mm:ss): 00:00:14
2020.05.18 20:05:03.956 2: DbRep Rep.SQLite.Backup - command message after dump: "Reopen executed."
2020.05.18 20:05:03.966 3: DbRep Rep.SQLite.Backup - Database dump finished successfully.


...habe übrigens auch in den asynchronen Modus geschaltet.
Kann das bleiben od. soll ich das wieder ändern?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 20:17:12
sehr gut !  :)

ZitatKann das bleiben od. soll ich das wieder ändern?
Kann so bleiben. Sollte sogar.

Jetzt kannst du mit einem at (DOIF) regelmäßig Backups deiner DB machen.
FHEM kann laufen. Diese Sicherungen können online gemacht werden und sind valide.

Mit "restoreSQLite" kannst du dir einen Stand wieder zurückladen.


Jetzt zu deiner Filesicherung.
Ich  denke mit

tar -tzf <Archiv>.tar.gz | grep fhem.db

müsstest du sehen ob das File drin ist

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 20:21:20
Ausgabe lautet:

./fhem.db
./fhem.db-shm
./fhem.db-wal

also wohl Pech gehabt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 20:25:50
Im Gegenteil, die Datei(en) sind offensichtil drin. Frage nur ob sie brauchbar sind.
Wir müssen sie jetzt unter einen anderen Namen wieder entpacken.
Muß mal googeln .... nutze ich so nicht ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 20:28:40
sollte hier eigentlich noch etwas angepasst werden?

COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:.*
   FUUID      5eb961f7-f33f-cd72-b3f6-f6ca8383a8350f4c
   FVERSION   93_DbLog.pm:v4.9.12-s21801/2020-04-29
   MODE       asynchronous
   MODEL      SQLITE
   NAME       logdb
   NR         423
   NTFY_ORDER 50-logdb
   PID        32441
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   dbconn     SQLite:dbname=/opt/fhem/fhem.db
   dbuser     
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    4.9.12
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589825089.56124
           VALUE      closed until 21:04:49 (3600 seconds)
   READINGS:
     2020-05-18 20:27:52   CacheUsage      92
     2020-05-18 20:27:36   NextSync        2020-05-18 20:28:06 or if CacheUsage 500 reached
     2020-05-18 20:27:36   state           connected
Attributes:
   asyncMode  1
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 20:31:00
Zitatsollte hier eigentlich noch etwas angepasst werden?

Was sagt die Ausgabe von "set logdb configCheck"  ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 20:31:53
Result of version check

Used Perl version: 5.26.1
Used DBI (Database independent interface) version: 1.64
Used DBD (Database driver) version SQLite: 1.56
Used DbLog version: 4.9.12.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> SQLite:dbname=/opt/fhem/fhem.db, User -> , Password -> read o.k.

Result of connection check

Connection to database /opt/fhem/fhem.db successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by DB /opt/fhem/fhem.db: UTF-8
Recommendation: This is only an information about text encoding used by the main database.

Result of logmode check

Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.

Result of insert mode check

Insert mode of DbLog-device logdb is: Array
Recommendation: Setting attribute "bulkInsert" to "1" may result a higher write performance in most cases. Feel free to try this mode.

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.

WEB: plotfork=0 / plotEmbed=0
WEBphone: plotfork=0 / plotEmbed=0
WEBtablet: plotfork=0 / plotEmbed=0

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".


Result of table 'history' check

Column width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in DB current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 20:35:22
Sieht doch gut aus. Kannst noch

attr bulkInsert 1

setzen und auch deine FHEMWEB Devices bzgl. der SVG-Erstellung optimieren:

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.

WEB: plotfork=0 / plotEmbed=0
WEBphone: plotfork=0 / plotEmbed=0
WEBtablet: plotfork=0 / plotEmbed=0

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 20:44:38
ok, alles gemacht.

Schon Ergebnisse vom googeln?

Falls man es nicht wieder herstellen kann, wie bekomme ich die Warnungen von Rep.STP5000.Erzeugung.Monat + Rep.STP5000.Erzeugung.Jahr wieder weg?

Oder erledigt sich das morgen von selbst?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 20:46:10
Die Datei aus dem tar entpacken sollte so gehen

tar -zxvf <Archiv>.tar.gz -O ./fhem.db > /opt/fhemold.db
tar -zxvf <Archiv>.tar.gz -O ./fhem.db-shm > /opt/fhemold.db-shm
tar -zxvf <Archiv>.tar.gz -O ./fhem.db-wal > /opt/fhemold.db-wal
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 21:10:09
dieter@intelnuc:~$ sudo tar -zxvf FHEM-20200517_080519.tar.gz -O ./fhem.db > /opt/fhemold.db
-bash: /opt/fhemold.db: Permission denied

Ich denke wir versuchen Morgen weiter unser Glück.

Was ist mit den bestehenden Warnungen?
Sind die nach dem Tageswechsel weg?
Oder muss noch mehr gelöscht werden?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 21:11:36
ZitatIch denke wir versuchen Morgen weiter unser Glück.
Können wir machen.

ZitatWas ist mit den bestehenden Warnungen?
Welche sind das nochmal genau ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 21:13:42
ZitatFalls man es nicht wieder herstellen kann, wie bekomme ich die Warnungen von Rep.STP5000.Erzeugung.Monat + Rep.STP5000.Erzeugung.Jahr wieder weg?

Datenbank ist ja wohl futsch.

Alle Daten in der Datenbank löschen und ab Morgen neu?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 21:16:49
ZitatDatenbank ist ja wohl futsch.
Das wissen wir erst wenn die Daten aus der alten DB nicht mehr rausgelesen werden können.

ZitatFalls man es nicht wieder herstellen kann, wie bekomme ich die Warnungen von Rep.STP5000.Erzeugung.Monat + Rep.STP5000.Erzeugung.Jahr wieder weg?
Ja weiß ich ... nur welche Warnungen sind das ? Die Diff - Warnungen ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 21:18:34
diff_overrun_limit_20     2020-05-17 20:57:41 0.0010 -> 2020-05-18 04:55:24 4294511.3370 ||

je bei Monat + Jahr
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 21:24:11
Wenn du diese Auswertungen jetzt laufen lässt, kommen diese Warnungen nicht mehr.


ZitatAlle Daten in der Datenbank löschen und ab Morgen neu?
NEIN !
Du hast jetzt eine laufende Datenbank die du regelmäßig sicherst. Mit der machst du ganz normal weiter.

Die Daten aus der alten DB holen wir (wenn möglich) heraus und importieren sie in der aktuell laufenden produktiven Datenbank.
Dazu werden die Dateien unter einem anderen Namen aus dem Archiv geholt, ein temporäres DbLog/DbRep angelegt, die Daten exportiert sofern möglich und in die aktuell laufende importiert. DAmit wäre alles wieder io.

Das  ist der Plan.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 18 Mai 2020, 21:28:42
Auswertung laufen lassen, Warnung noch da.

Morgen geht´s weiter.

Vielen Dank noch mal und eine angenehme Nacht.
Bis Morgen....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Mai 2020, 21:31:28
Also jetzt verstehe ich Bahnhof. Wenn genau diese

2020-05-17 20:57:41 0.0010 -> 2020-05-18 04:55:24 4294511.3370 ||

Warnungen noch da sind, würden die Datensätze ja noch existieren  ???

Naja, vielleicht doch schon zu spät .... bis morgen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 08:51:33
Hallo Heiko,

auf ein Neues  ;)

Hier die beiden DbRep mit den Warnungen:

DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5eb97981-f33f-cd72-5c15-46c14b9754c5f0b3
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    diffValue
   MODEL      Client
   NAME       Rep.STP5000.Erzeugung.Monat
   NOTIFYDEV  global,Rep.STP5000.Erzeugung.Monat
   NR         428
   NTFY_ORDER 50-Rep.STP5000.Erzeugung.Monat
   ROLE       Client
   STATE      Warning
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-31
       dsstr      2020-05-01
       epoch_seconds_end 1590962399
       mestr      05
       msstr      05
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589869866.34035
           VALUE      Warning
   OLDREADINGS:
   READINGS:
     2020-05-19 08:31:06   2020-05-19_08-31-01__SMA_Wechselrichter__etotal__DIFF__no_aggregation 174.9610
     2020-05-19 08:31:06   background_processing_time 0.0754
     2020-05-19 08:31:06   diff_overrun_limit_20 2020-05-17 20:57:41 0.0010 -> 2020-05-18 04:55:24 4294511.3370 ||
     2020-05-19 08:31:06   sql_processing_time 0.0480
     2020-05-19 08:31:06   state           Warning
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_month_begin
   timestamp_end current_month_end
   userExitFn setDumEnergy .*:.*
   verbose    2


DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5eba3f24-f33f-cd72-2148-2952d1c6b3d2b651
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    diffValue
   MODEL      Client
   NAME       Rep.STP5000.Erzeugung.Jahr
   NOTIFYDEV  global,Rep.STP5000.Erzeugung.Jahr
   NR         434
   NTFY_ORDER 50-Rep.STP5000.Erzeugung.Jahr
   ROLE       Client
   STATE      Warning
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-12-31
       dsstr      2020-01-01
       epoch_seconds_end 1609455599
       mestr      12
       msstr      01
       testr      23:59:59
       tsstr      00:00:00
       wdadd      432000
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589830033.7351
           VALUE      Warning
   OLDREADINGS:
   READINGS:
     2020-05-18 21:27:13   2020-05-18_20-53-47__SMA_Wechselrichter__etotal__DIFF__no_aggregation 171.8660
     2020-05-18 21:27:13   background_processing_time 0.0705
     2020-05-18 21:27:13   diff_overrun_limit_20 2020-05-17 20:57:41 0.0010 -> 2020-05-18 04:55:24 4294511.3370 ||
     2020-05-18 21:27:13   sql_processing_time 0.0434
     2020-05-18 21:27:13   state           Warning
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_year_begin
   timestamp_end current_year_end
   userExitFn setDumEnergy .*:.*
   verbose    2


Demnach funktioniert auch die Anzeige im Dummy für Monat und Jahr nicht.

VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 08:58:45
Moin Dieter,

na dann los  :)

Führe im Rep.STP5000.Erzeugung.Jahr mal spasseshalber ein einfaches "fetchrows" aus.
Was zeigt das ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 09:04:36
DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5eba3f24-f33f-cd72-2148-2952d1c6b3d2b651
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       Rep.STP5000.Erzeugung.Jahr
   NOTIFYDEV  global,Rep.STP5000.Erzeugung.Jahr
   NR         434
   NTFY_ORDER 50-Rep.STP5000.Erzeugung.Jahr
   ROLE       Client
   STATE      <html>done - Warning: present rows exceed specified limit, adjust attribute <a href='https://fhem.de/commandref_DE.html#limit' target='_blank'>limit</a></html>
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-12-31
       dsstr      2020-01-01
       epoch_seconds_end 1609455599
       mestr      12
       msstr      01
       testr      23:59:59
       tsstr      00:00:00
       wdadd      432000
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589871727.31775
           VALUE      <html>done - Warning
   OLDREADINGS:
   READINGS:
     2020-05-19 09:02:07   2020-05-17_20-39-23__1__SMA_Wechselrichter__etotal 455.947
     2020-05-19 09:02:07   2020-05-17_20-40-24__1__SMA_Wechselrichter__etotal 455.948
     2020-05-19 09:02:07   2020-05-17_20-41-25__1__SMA_Wechselrichter__etotal 455.949
     2020-05-19 09:02:07   2020-05-17_20-43-27__1__SMA_Wechselrichter__etotal 455.95
     2020-05-19 09:02:07   2020-05-17_20-45-29__1__SMA_Wechselrichter__etotal 455.952
     2020-05-19 09:02:07   2020-05-17_20-46-30__1__SMA_Wechselrichter__etotal 455.953
     2020-05-19 09:02:07   2020-05-17_20-48-32__1__SMA_Wechselrichter__etotal 455.954
     2020-05-19 09:02:07   2020-05-17_20-49-33__1__SMA_Wechselrichter__etotal 455.955
     2020-05-19 09:02:07   2020-05-17_20-51-35__1__SMA_Wechselrichter__etotal 455.956
     2020-05-19 09:02:07   2020-05-17_20-53-37__1__SMA_Wechselrichter__etotal 455.957
     2020-05-19 09:02:07   2020-05-17_20-57-41__1__SMA_Wechselrichter__etotal 455.958
     2020-05-19 09:02:07   2020-05-18_04-55-24__1__SMA_Wechselrichter__etotal 4294967.295
     2020-05-19 09:02:07   2020-05-18_05-28-56__1__SMA_Wechselrichter__etotal 455.958
     2020-05-19 09:02:07   2020-05-18_05-58-24__1__SMA_Wechselrichter__etotal 455.959
     2020-05-19 09:02:07   2020-05-18_05-59-25__1__SMA_Wechselrichter__etotal 455.96
     2020-05-19 09:02:07   2020-05-18_06-00-26__1__SMA_Wechselrichter__etotal 455.961
     2020-05-19 09:02:07   2020-05-18_06-01-27__1__SMA_Wechselrichter__etotal 455.962
     2020-05-19 09:02:07   2020-05-18_06-02-28__1__SMA_Wechselrichter__etotal 455.963
.
.
.
     2020-05-19 09:02:07   2020-05-19_08-58-28__1__SMA_Wechselrichter__etotal 502.37
     2020-05-19 09:02:07   2020-05-19_08-59-29__1__SMA_Wechselrichter__etotal 502.429
     2020-05-19 09:02:07   2020-05-19_09-00-29__1__SMA_Wechselrichter__etotal 502.489
     2020-05-19 09:02:07   2020-05-19_09-01-30__1__SMA_Wechselrichter__etotal 502.548
     2020-05-19 09:02:07   background_processing_time 0.0170
     2020-05-19 09:02:07   number_fetched_rows 1000
     2020-05-19 09:02:07   sql_processing_time 0.0147
     2020-05-19 09:02:07   state           <html>done - Warning: present rows exceed specified limit, adjust attribute <a href='https://fhem.de/commandref_DE.html#limit' target='_blank'>limit</a></html>
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_year_begin
   timestamp_end current_year_end
   userExitFn setDumEnergy .*:.*
   verbose    2
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 09:08:24
Ok, der Datensatz ist noch drin. Das passt dann.
Der erste SAtz in der DB ist vom 2020-05-17_20-39-23, alle davor sind raus, richtig ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 09:12:14
ich vermute das es der Erste ist,wissen tue ich es nicht.

Leider muss ich jetzt hier unterbrechen.
Ich hoffe weiterhin auf deine super Hilfe und melde mich heute Nachmittag wieder.

VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 09:12:46
Alles klar .. meldst dich einfach ...
Bis dann.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 11:24:41
Hallo Dieter,

habe inzwischen das Entpacken der Dateien aus einem tar Archiv bei mir getestet.

So hat es funktioniert:

sudo mkdir /opt/temp
sudo chmod 777 /opt/temp     # das ist nur temporär, wir löschen hinterher wieder alles


Entpacken hat auch funktioniert mit

tar -zxvf test.tar.gz -O opt/fhem.db > /opt/temp/fhemold.db
tar -zxvf test.tar.gz -O opt/fhem.db-shm > /opt/temp/fhemold.db-shm
tar -zxvf test.tar.gz -O opt/fhem.db-wal > /opt/temp/fhemold.db-wal


Dann habe ich eine DB-config Datei /opt/fhem/oldsqlite.conf angelegt mit:

%dbconfig= (
      connection => "SQLite:dbname=/opt/temp/fhemold.db",
      user => "",
      password => ""
);



Weiterhin ein DbLog definiert, welches aber keinerlei Events in die DB loggt.
Brauchen wir nur damit damit ein DbRep angelegt werden kann:

define tempSQLITE DbLog ./oldsqlite.conf aaaaaa:bbbbbbbb

Damit nun ein DbRep definiert:

define Rep.tempSQLITE DbRep tempSQLITE


Wow ... nach kurzer "Denkpause" war der Status "connected". :)
Kurz ein fetchrows angetestet ... Freude, DB war zugreifbar.

Nun die Daten exportieren. Dazu gibt es das Kommando "exportToFile".
Es exportiert in eine csv-Datei die im Attribut "expimpfile" angegeben wird.
Ich habe gesetzt:

attr Rep.tempSQLITE expimpfile export.csv


Man kann noch einen Pfad davorsetzen. Ohne Pfad wird des Exportfile in /opt/fhem erzeugt.
Export mit:

set Rep.tempSQLITE exportToFile

Je nach Umfang dauert das entsprechend. Bei dir wird es schnell gehen.

Am Ende schreibt Rep.tempSQLITE die Anzahl der Datensätze in die Readings die exportiert wurden.
Und es gibt die Datei /opt/fhem/export.csv.

Wenn du bis hierhin gekommen bist sieht es schonmal gut aus. Die Daten importieren wir dann
mit deinem Rep.Report.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 15:40:35
Servus Heiko,

bin wieder zurück.

Leider komme ich nur bis hierher:

dieter@intelnuc:/opt/fhem/backup$ tar -zxvf FHEM-20200517_080519.tar.gz -O opt/fhem.db > /opt/temp/fhemold.db
tar: opt/fhem.db: Not found in archive
tar: Exiting with failure status due to previous errors
dieter@intelnuc:/opt/fhem/backup$


dieter@intelnuc:/opt/fhem/backup$ tar -tzf FHEM-20200517_080519.tar.gz | grep fhem.db
./fhem.db
./fhem.db-shm
./fhem.db-wal
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 15:50:38
Hi,

naja, du müsstest deine Pfade einsetzen ... so:


tar -zxvf test.tar.gz -O ./fhem.db > /opt/temp/fhemold.db
tar -zxvf test.tar.gz -O ./fhem.db-shm > /opt/temp/fhemold.db-shm
tar -zxvf test.tar.gz -O ./fhem.db-wal > /opt/temp/fhemold.db-wal


äh mit deinem Archiv:


tar -zxvf FHEM-20200517_080519.tar.gz -O ./fhem.db > /opt/temp/fhemold.db
tar -zxvf FHEM-20200517_080519.tar.gz -O ./fhem.db-shm > /opt/temp/fhemold.db-shm
tar -zxvf FHEM-20200517_080519.tar.gz -O ./fhem.db-wal > /opt/temp/fhemold.db-wal


probier mal
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 16:00:19
ok, jetzt bin ich soweit:

ZitatWow ... nach kurzer "Denkpause" war der Status "connected". :)
Kurz ein fetchrows angetestet ... Freude, DB war zugreifbar.

Inhalt kompletter fhem log.

Muss hier noch ein Pfad angegeben werden?

Sorry für die vielen Fragen, blick bald nicht mehr durch  ???

Wer lesen kann.....
Fhem log vom 17.05.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 16:05:12
Alles gut ... tief durchatmen  :)

fetchrows zeigt dir jetzt also die ganzen Daten wenn ich dirch richtig verstanden habe.

Dann setzt du jetzt für den Export einfach

attr Rep.tempSQLITE DbRep expimpfile export.csv

Dann landet alles im Pfad /opt/fhem/export.csv.
Sollte bei dir passen denke ich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 16:09:14
das gibt es so nicht

attr Rep.tempSQLITE DbRep expimpfile export.csv

nur ohne DbRep
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 16:10:45
Ja natürlich, ich hab zu schnell geschrieben  ???

attr Rep.tempSQLITE expimpfile export.csv

Edit: Habe die Anleitung weiter vorne gleich noch korrigiert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 16:12:20
set exportToFile ohne weitere Angaben?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 16:15:20
Ja. Du kannst ja vorher nochmal dein Rep.tempSQLITE anschauen.
Dort muss nun das Attribut

expimpfile  = export.csv

gesetzt sein. Das benutzt der Export dann.

Du kannst ja vllt. noch ein fetchrows ausführen und mir dann ein list zeigen wenn es nicht zu groß ist. Dann sehe ich ob das attr drin ist.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 16:19:54
/ -- / -- -- ROWS EXPORTED TO FILE(S) --     1753049     2020-05-19 16:17:58


Datei vorhanden
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 16:24:51
sehr gut :)

So aufpassen, jetzt gehen wir in dein gestern angelegtes Rep.SQLite.Backup  und machen ein dumpSQLite wie gestern geübt.

Wenn das fertig ist, setzt du in diesem Rep auch das Attribut expimpfile für den Import:

attr Rep.SQLite.Backup expimpfile export.csv

Dann kommt der Import dran mit

set Rep.SQLite.Backup importFromFile
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 16:34:16
Ich bin beeindruckt welche Geduld du mit mir aufbringst. Danke.
Leider muss ich ein kleine Pause einlegen.
Muss was erledigen.
Melde mich später wieder.....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 16:38:33
Das Thema ist nicht ganz trivial für User die sich nicht ständig damit beschäftigen, da kann man niemanden alleine sterben lassen.
Außerdem macht diese Problemlösung Spaß und glücklicherweise habe ich etwas Zeit.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 16:58:54
2020.05.19 16:54:10.909 3: DbRep Rep.SQLite.Backup - ################################################################
2020.05.19 16:54:10.910 3: DbRep Rep.SQLite.Backup - ###                    New SQLite dump                       ###
2020.05.19 16:54:10.910 3: DbRep Rep.SQLite.Backup - ################################################################
2020.05.19 16:54:10.910 3: DbRep Rep.SQLite.Backup - execute command before dump: 'set logdb reopen 3600'
2020.05.19 16:54:11.015 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem/fhem.db before optimize (MB): 522
2020.05.19 16:54:11.016 3: DbRep Rep.SQLite.Backup - VACUUM database /opt/fhem/fhem.db....
2020.05.19 16:54:22.541 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem/fhem.db after optimize (MB): 513
2020.05.19 16:54:22.542 3: DbRep Rep.SQLite.Backup - Starting dump of database 'fhem.db'
2020.05.19 16:54:26.570 3: DbRep Rep.SQLite.Backup - Size of backupfile: 512.74 MB
2020.05.19 16:54:26.573 3: DbRep Rep.SQLite.Backup - Finished backup of database fhem - total time used (hh:mm:ss): 00:00:15
2020.05.19 16:54:26.588 2: DbRep Rep.SQLite.Backup - command message after dump: "Reopen executed."
2020.05.19 16:54:26.600 3: DbRep Rep.SQLite.Backup - Database dump finished successfully.


Attribut gesetzt.

Woher weiß das DbRep Rep.SQLite.Backup welche Datei bzw. wo sie liegt?

CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec2c4f7-f33f-cd72-91f5-f58c6964ed304ce0
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    dumpSQLite
   MODEL      Client
   NAME       Rep.SQLite.Backup
   NOTIFYDEV  global,Rep.SQLite.Backup
   NR         40732
   NTFY_ORDER 50-Rep.SQLite.Backup
   ROLE       Client
   STATE      Warning - dump finished, but command message after dump appeared
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     VERSION    8.40.0
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589900066.59703
           VALUE      Warning - dump finished, but command message after dump appeared
   OLDREADINGS:
   READINGS:
     2020-05-19 16:54:26   DumpFileCreated ./log/fhem_2020_05_19_16_54.sqlitebkp
     2020-05-19 16:54:26   DumpFileCreatedSize 512.74 MB
     2020-05-19 16:54:26   DumpRowsCurrent n.a.
     2020-05-19 16:54:26   DumpRowsHistory n.a.
     2020-05-19 16:54:26   afterdump_message Reopen executed.
     2020-05-19 16:54:26   background_processing_time 15.5753
     2020-05-19 16:54:26   state           Warning - dump finished, but command message after dump appeared
Attributes:
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   dumpDirLocal ./log
   dumpFilesKeep 3
   event-on-update-reading state
   executeAfterProc set logdb reopen
   executeBeforeProc set logdb reopen 3600
   expimpfile export.csv
   fastStart  1
   optimizeTablesBeforeDump 1
   room       Photovoltaik
   showproctime 1
   verbose    3
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 17:01:46
ZitatWoher weiß das DbRep Rep.SQLite.Backup welche Datei bzw. wo sie liegt?

Aus dem gesetzten Attribut expimpfile. Wenn kein Pfad dabei steht nimmt das Rep den eingebauten Standard und sollte es finden. Man kann natürlich auch einen Pfad mit angeben.

Na dann ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 17:05:41
-- ROWS IMPORTED FROM FILE --    1753049


....muss leider schon wieder Pause einlegen.....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 17:09:16
Jo, so soll es sein.

Jetzt machst du wieder ein Backup mit dumpSQLite. Wenn das durch ist haben wir erstmal den Datenbestand gerettet und gesichert.
Dann kümmern wir uns um den Rest.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 17:13:46
auch mit dem DbRep Rep.SQLite.Backup ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 17:15:47
Ja, sichern immer mit diesem Teil. Das benutzt du jetzt quasi immer und regelmäßig ! für ein Datenbank-Backup (mit at oder so)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 17:17:08
2020.05.19 17:16:15.421 3: DbRep Rep.SQLite.Backup - ################################################################
2020.05.19 17:16:15.421 3: DbRep Rep.SQLite.Backup - ###                    New SQLite dump                       ###
2020.05.19 17:16:15.421 3: DbRep Rep.SQLite.Backup - ################################################################
2020.05.19 17:16:15.421 3: DbRep Rep.SQLite.Backup - execute command before dump: 'set logdb reopen 3600'
2020.05.19 17:16:15.511 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem/fhem.db before optimize (MB): 868
2020.05.19 17:16:15.511 3: DbRep Rep.SQLite.Backup - VACUUM database /opt/fhem/fhem.db....
2020.05.19 17:16:35.614 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem/fhem.db after optimize (MB): 853
2020.05.19 17:16:35.615 3: DbRep Rep.SQLite.Backup - Starting dump of database 'fhem.db'
2020.05.19 17:16:42.952 3: DbRep Rep.SQLite.Backup - Size of backupfile: 852.34 MB
2020.05.19 17:16:42.954 3: DbRep Rep.SQLite.Backup - Deleting old dumpfile 'fhem_2020_05_18_20_05.sqlitebkp'
2020.05.19 17:16:42.956 3: DbRep Rep.SQLite.Backup - Finished backup of database fhem - total time used (hh:mm:ss): 00:00:27
2020.05.19 17:16:42.973 2: DbRep Rep.SQLite.Backup - command message after dump: "Reopen executed."
2020.05.19 17:16:43.006 3: DbRep Rep.SQLite.Backup - Database dump finished successfully.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 17:22:14
Ok.

Jetzt kannst du im Prinzip das Verzeichnis /opt/temp und die Devices Rep.tempSQLITE und tempSQLITE (DbLog) löschen. Kannst es natürlich auch behalten um noch etwas zu üben und damit zu spielen.

Wir verwenden jetzt wieder dein DbRep Rep.Report was wir anfangs kopiert hatten. Hieß das so ?

Zeig mir bitte nochmal ein List von dem Rep ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 17:24:16
CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec26a8e-f33f-cd72-b513-8c4f195609a12cf4
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       Rep.Report
   NOTIFYDEV  global,Rep.Report
   NR         33412
   NTFY_ORDER 50-Rep.Report
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-15
       dsstr      2020-03-25
       epoch_seconds_end 1589525914.87634
       mestr      05
       msstr      03
       testr      08:58:34
       tsstr      08:58:34
       wdadd      432000
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     DELENTRIES:
       Rep.Report
       delEntries
       2020-05-18
       04:55:24
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589871515.9789
           VALUE      done
   OLDREADINGS:
   READINGS:
     2020-05-19 08:58:35   2020-05-14_16-50-55__1__SMA_Wechselrichter__etotal 325.952
     2020-05-19 08:58:35   2020-05-14_16-51-56__1__SMA_Wechselrichter__etotal 325.985
     2020-05-19 08:58:35   2020-05-14_16-52-57__1__SMA_Wechselrichter__etotal 326.032
     2020-05-19 08:58:35   2020-05-14_16-53-58__1__SMA_Wechselrichter__etotal 326.079
     2020-05-19 08:58:35   2020-05-14_16-54-59__1__SMA_Wechselrichter__etotal 326.124
     2020-05-19 08:58:35   2020-05-14_16-56-00__1__SMA_Wechselrichter__etotal 326.168
.
.
.
     2020-05-19 08:58:35   2020-05-15_08-54-28__1__SMA_Wechselrichter__etotal 331.904
     2020-05-19 08:58:35   2020-05-15_08-55-29__1__SMA_Wechselrichter__etotal 331.917
     2020-05-19 08:58:35   2020-05-15_08-56-30__1__SMA_Wechselrichter__etotal 331.929
     2020-05-19 08:58:35   2020-05-15_08-57-31__1__SMA_Wechselrichter__etotal 331.943
     2020-05-19 08:58:35   2020-05-15_08-58-32__1__SMA_Wechselrichter__etotal 331.961
     2020-05-19 08:58:35   background_processing_time 0.0135
     2020-05-19 08:58:35   number_fetched_rows 334
     2020-05-19 08:58:35   sql_processing_time 0.0109
     2020-05-19 08:58:35   state           done
Attributes:
   aggregation no
   allowDeletion 0
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_month_begin
   timestamp_end current_month_end
   userExitFn setDumEnergy .*:.*
   verbose    3
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 17:31:54
Das sieht doch schonmal gut aus, deine alten Daten sind mit drin.
Wenn du ein neues fetchrows ausführst, sollten alle Daten zu finden sein.

EDIT: Lösche dort mal das Attribut userExitFn. Hat in diesem Device nichts zu suchen, ist nur für die PV-Auswertung.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 17:54:02
...wieder da. Attr gelöscht...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 17:55:24
Führ mal ein neues fetchrows aus ... was kommt da ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 17:57:12
die Daten ab 15.05.
1000 an der Zahl, dann ist Schluss.

done - Warning: present rows exceed specified limit, adjust attribute limit
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:03:11
sehr gut  :)

Jatzt müssen wir noch den Datensatz löschen.
Die Warnung in den Auswertungsreps kommt doch noch ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:05:30
ja, noch da

diff_overrun_limit_20    2020-05-17 20:57:41 0.0010 -> 2020-05-18 04:55:24 4294511.3370 ||
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:08:40
Ok, jetzt Attribute setzen

timestamp_begin 2020-05-18 00:00:00
timestamp_end   2020-05-18 05:00:00

Und wieder ein fetchrows ... was kommt ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:13:52
immer noch die Daten vom 15.05.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:16:04
Kannst du ein List zeigen, das kann ich fast nicht glauben....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:18:16
CFGFN     
   DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5ec26a8e-f33f-cd72-b513-8c4f195609a12cf4
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    fetchrows history
   MODEL      Client
   NAME       Rep.Report
   NOTIFYDEV  global,Rep.Report
   NR         33412
   NTFY_ORDER 50-Rep.Report
   ROLE       Client
   STATE      <html>done - Warning: present rows exceed specified limit, adjust attribute <a href='https://fhem.de/commandref_DE.html#limit' target='_blank'>limit</a></html>
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-15
       dsstr      2020-03-25
       epoch_seconds_end 1589559193.7198
       mestr      05
       msstr      03
       testr      18:13:13
       tsstr      18:13:13
       wdadd      432000
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     DELENTRIES:
       Rep.Report
       delEntries
       2020-05-18
       04:55:24
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589904794.84027
           VALUE      <html>done - Warning
   OLDREADINGS:
   READINGS:
     2020-05-19 18:13:14   2020-05-15_09-21-54__1__SMA_Wechselrichter__etotal 332.546
     2020-05-19 18:13:14   2020-05-15_09-21-54__2__SMA_Wechselrichter__etotal 332.546
     2020-05-19 18:13:14   2020-05-15_09-22-56__1__SMA_Wechselrichter__etotal 332.593
     2020-05-19 18:13:14   2020-05-15_09-22-56__2__SMA_Wechselrichter__etotal 332.593
     2020-05-19 18:13:14   2020-05-15_09-24-57__1__SMA_Wechselrichter__etotal 332.748
     2020-05-19 18:13:14   2020-05-15_09-24-57__2__SMA_Wechselrichter__etotal 332.748
     2020-05-19 18:13:14   2020-05-15_09-26-59__1__SMA_Wechselrichter__etotal 332.892
     2020-05-19 18:13:14   2020-05-15_09-26-59__2__SMA_Wechselrichter__etotal 332.892
     2020-05-19 18:13:14   2020-05-15_09-28-00__1__SMA_Wechselrichter__etotal 332.961
     2020-05-19 18:13:14   2020-05-15_09-28-00__2__SMA_Wechselrichter__etotal 332.961
     2020-05-19 18:13:14   2020-05-15_09-29-01__1__SMA_Wechselrichter__etotal 333.001
     2020-05-19 18:13:14   2020-05-15_09-29-01__2__SMA_Wechselrichter__etotal 333.001
     2020-05-19 18:13:14   2020-05-15_09-30-02__1__SMA_Wechselrichter__etotal 333.048
     2020-05-19 18:13:14   2020-05-15_09-30-02__2__SMA_Wechselrichter__etotal 333.048
     2020-05-19 18:13:14   2020-05-15_09-31-03__1__SMA_Wechselrichter__etotal 333.104
     2020-05-19 18:13:14   2020-05-15_09-31-03__2__SMA_Wechselrichter__etotal 333.104
.
.
.
     2020-05-19 18:13:14   2020-05-15_18-09-25__1__SMA_Wechselrichter__etotal 367.983
     2020-05-19 18:13:14   2020-05-15_18-09-25__2__SMA_Wechselrichter__etotal 367.983
     2020-05-19 18:13:14   2020-05-15_18-10-26__1__SMA_Wechselrichter__etotal 367.991
     2020-05-19 18:13:14   2020-05-15_18-10-26__2__SMA_Wechselrichter__etotal 367.991
     2020-05-19 18:13:14   2020-05-15_18-11-27__1__SMA_Wechselrichter__etotal 367.999
     2020-05-19 18:13:14   2020-05-15_18-11-27__2__SMA_Wechselrichter__etotal 367.999
     2020-05-19 18:13:14   2020-05-15_18-12-28__1__SMA_Wechselrichter__etotal 368.007
     2020-05-19 18:13:14   2020-05-15_18-12-28__2__SMA_Wechselrichter__etotal 368.007
     2020-05-19 18:13:14   background_processing_time 0.0242
     2020-05-19 18:13:14   number_fetched_rows 1000
     2020-05-19 18:13:14   sql_processing_time 0.0213
     2020-05-19 18:13:14   state           <html>done - Warning: present rows exceed specified limit, adjust attribute <a href='https://fhem.de/commandref_DE.html#limit' target='_blank'>limit</a></html>
Attributes:
   aggregation no
   allowDeletion 0
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin 2020-05-18 00:00:00
   timestamp_end 2020-05-18 05:00:00
   verbose    3
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:21:41
Ok, ich sehe es ... du müsstest dein FHEM mal restarten.
Save vorher nicht vergessen damit die Einstellung der Attribute bleibt.

Da ist etwas von gestern übrig geblieben:

     DELENTRIES:
       Rep.Report
       delEntries
       2020-05-18
       04:55:24


Der Eintrag versaut uns die Datumeingrenzung. Hattest du delEntries gestern mit dem Zusatz " 2020-05-18 04:55:24" gestartet ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:25:55
geht doch  ;)

2020-05-18_04-55-24__1__SMA_Wechselrichter__etotal     4294967.295     2020-05-19 18:25:06
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:29:27
Jepp  :)

Jetzt ein

set Rep.Report sqlCmd select * from history where DEVICE='SMA_Wechselrichter' and READING='etotal' and VALUE='4294967.295';
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:32:29
hab ich genau so gemacht.
Wieder Neustart? Weil Eintrag nach fetchrows noch da
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:33:42
Nein, sorry ... ich wollte die Ausgabe sehen was nach dem select ... in den Readings angezeigt wird.  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:36:44
READINGS:
     2020-05-19 18:34:57   SqlResultRow_1  TIMESTAMP|DEVICE|TYPE|EVENT|READING|VALUE|UNIT
     2020-05-19 18:34:57   SqlResultRow_2  2020-05-18 04:55:24|SMA_Wechselrichter|SMAINVERTER|etotal: 4294967.295|etotal|4294967.295|
     2020-05-19 18:34:57   background_processing_time 0.0248
     2020-05-19 18:34:57   sqlCmd          select * from history where DEVICE='SMA_Wechselrichter' and READING='etotal' and VALUE='4294967.295';
     2020-05-19 18:34:57   sqlResultNumRows 1
     2020-05-19 18:34:57   sql_processing_time 0.0236
     2020-05-19 18:34:57   state           done


nach diffValue im Rep.STP5000.Erzeugung.Monat

diff_overrun_limit_20     2020-05-17 20:57:41 0.0010 -> 2020-05-18 04:55:24 4294511.3370 ||
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:39:36
Genau, nur ein Datensatz. Das wollte ich sehen.

JETZT werden wir das Ding los. Erst Attribut setzen

allowDeletion = 1

und dann

set Rep.Report sqlCmd delete from history where DEVICE='SMA_Wechselrichter' and READING='etotal' and VALUE='4294967.295';

Danach bitte zeigen was die Readings sagen ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:41:18
READINGS:
     2020-05-19 18:40:44   SqlResultRow_1  1
     2020-05-19 18:40:44   background_processing_time 0.0282
     2020-05-19 18:40:44   sqlCmd          delete from history where DEVICE='SMA_Wechselrichter' and READING='etotal' and VALUE='4294967.295';
     2020-05-19 18:40:44   sqlResultNumRows 1
     2020-05-19 18:40:44   sql_processing_time 0.0269
     2020-05-19 18:40:44   state           done


wenn ich brav das mache was du sagst, klappt es auch  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:42:49
Nur ein DS gelöscht  ;)
Und was sagen die PV Auswertungen jetzt ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:45:23
Monat + Jahr hat funktioniert.

Nur stimmen halt die Werte in der Dummy Übersicht nicht.

READINGS:
     2020-05-19 18:43:58   AutarkyQuote    100
     2020-05-19 18:33:03   AutarkyQuoteDay 65
     2020-05-19 18:42:19   AutarkyQuoteMonth 220
     2020-05-19 18:42:49   AutarkyQuoteYear 220
     2020-05-19 18:43:57   GridConsumption 0.0
     2020-05-19 18:33:03   GridConsumptionDay 3.2
     2020-05-19 18:42:19   GridConsumptionMonth 63.0
     2020-05-19 18:42:49   GridConsumptionYear 63.0
     2020-05-19 18:43:57   GridFeedIn      49.6
     2020-05-19 18:33:02   GridFeedInDay   34.5
     2020-05-19 18:42:19   GridFeedInMonth 440.7
     2020-05-19 18:42:49   GridFeedInYear  440.7
     2020-05-19 18:43:58   PV              294.0
     2020-05-19 18:33:02   PVDay           40.4
     2020-05-19 18:42:18   PVMonth         325.1
     2020-05-19 18:42:48   PVYear          325.1
     2020-05-19 18:43:58   SelfConsumptionQuote 83
     2020-05-19 18:33:03   SelfConsumptionQuoteDay 15
     2020-05-19 18:42:19   SelfConsumptionQuoteMonth -36
     2020-05-19 18:42:49   SelfConsumptionQuoteYear -36
     2020-05-19 18:43:58   TotalConsumption 244.4
     2020-05-19 18:33:03   TotalConsumptionDay 9.1
     2020-05-19 18:42:19   TotalConsumptionMonth -52.6
     2020-05-19 18:42:49   TotalConsumptionYear -52.6
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Mai 2020, 18:50:32
Das renkt sich wieder ein. Die Werte werden durch die userExitFn gesetzt wenn die Devices alle laufen.
Da können wir morgen nochmal schauen.

Dieter ... du hast es geschafft !  8)
Jetzt schockiert dich so leicht nichts mehr wenn die DB zickt  ;)

Denke daran die DB wieder zu sichern und auch ein at dafür einzuplanen.

Komm wir klatschen mal in die Hände ... und ich genehmige mir jetzt einen schönen Whisky.  :D

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 19 Mai 2020, 18:53:53
Yep, super klasse Unterstützung.
Vielen, vielen Dank für die Hilfe.
Ich werde morgen berichten.
Prost  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 06:10:54
Guten Morgen Heiko,
hoffe dein Whisky hat geschmeckt  ;)

Leider stimmen die Werte im Dummy heute immer noch nicht:

READINGS:
     2020-05-20 06:06:32   AutarkyQuote    20
     2020-05-19 23:30:42   AutarkyQuoteDay 56
     2020-05-20 06:05:42   AutarkyQuoteMonth 236
     2020-05-19 20:15:00   AutarkyQuoteYear 222
     2020-05-20 06:06:32   GridConsumption 245.8
     2020-05-20 06:00:42   GridConsumptionDay 1.7
     2020-05-20 06:05:42   GridConsumptionMonth 66.4
     2020-05-19 20:15:00   GridConsumptionYear 63.4
     2020-05-20 06:06:32   GridFeedIn      0.0
     2020-05-20 06:00:42   GridFeedInDay   0
     2020-05-20 06:05:42   GridFeedInMonth 440.7
     2020-05-19 20:15:00   GridFeedInYear  440.7
     2020-05-20 06:06:32   PV              63.0
     2020-05-20 06:00:42   PVDay           0
     2020-05-20 06:05:42   PVMonth         325.5
     2020-05-19 20:15:00   PVYear          325.5
     2020-05-20 06:06:32   SelfConsumptionQuote 100
     2020-05-19 23:30:42   SelfConsumptionQuoteDay 15
     2020-05-20 06:05:42   SelfConsumptionQuoteMonth -35
     2020-05-19 20:15:00   SelfConsumptionQuoteYear -35
     2020-05-20 06:06:32   TotalConsumption 308.8
     2020-05-20 06:00:42   TotalConsumptionDay 1.7
     2020-05-20 06:05:42   TotalConsumptionMonth -48.8
     2020-05-19 20:15:00   TotalConsumptionYear -51.8


Kann man das noch "grade" ziehen oder erledigt sich das beim Monatswechsel?

VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 08:04:43
Moin Dieter,

ja, war lecker.  :D

Picken wir mal einen raus. Welchen zum Beispiel ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 08:14:54
Wie? Einen rauspicken?

Laut den Daten hätte ich mehr eingespeist als erzeugt und einen negativen Eigenverbrauch.
Vermutlich fehlen ja einfach nur Werte von der Erzeugung.
Laut Excel Export aus dem Wechselrichter sind ja im Prinzip alle Daten noch da.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 08:21:22
Naja, das meinte ich mit rauspicken, also

GridFeedInMonth 440.7  im Vergleich zu
PVMonth             325.5 

Also gucken wir uns mal die Listings an von

Rep.SMAEM.Einspeisung.Monat  im Vergleich zu
Rep.STP5000.Erzeugung.Monat
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 08:28:28
brauchst du jetzt nur je ein list oder vorher wieder ein fetchrows machen, dann das list?
Da werden doch dann wieder nur 1000 Werte angezeigt, oder?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 08:37:37
Na jetzt kein fetchrows, sondern ein list um die normalen berechneten Readings zu sehen. Diese Auswertungen sind ja diffValue Auswertungen etc.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 08:39:46
DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5eb9790a-f33f-cd72-259f-ccd2fe26eab837c6
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    sumValue
   MODEL      Client
   NAME       Rep.SMAEM.Einspeisung.Monat
   NOTIFYDEV  global,Rep.SMAEM.Einspeisung.Monat
   NR         427
   NTFY_ORDER 50-Rep.SMAEM.Einspeisung.Monat
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     SQLHIST   
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-31
       dsstr      2020-05-01
       epoch_seconds_end 1590962399
       mestr      05
       msstr      05
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589955942.62236
           VALUE      done
   OLDREADINGS:
   READINGS:
     2020-05-20 08:25:42   2020-05-01__SMA_Zaehler__Einspeisung_WirkP_Zaehler_Diff__SUM__no_aggregation 441.4257
     2020-05-20 08:25:42   background_processing_time 0.0505
     2020-05-20 08:25:42   sql_processing_time 0.0495
     2020-05-20 08:25:42   state           done
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Zaehler
   event-on-update-reading state
   reading    Einspeisung_WirkP_Zaehler_Diff
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_month_begin
   timestamp_end current_month_end
   userExitFn setDumEnergy .*:.*
   verbose    2


DATABASE   /opt/fhem/fhem.db
   DEF        logdb
   FUUID      5eb97981-f33f-cd72-5c15-46c14b9754c5f0b3
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    diffValue
   MODEL      Client
   NAME       Rep.STP5000.Erzeugung.Monat
   NOTIFYDEV  global,Rep.STP5000.Erzeugung.Monat
   NR         428
   NTFY_ORDER 50-Rep.STP5000.Erzeugung.Monat
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     SQLHIST   
     UEFN_REGEXP .*:.*
     USEREXITFN setDumEnergy
     VERSION    8.40.0
     CV:
       aggregation no
       aggsec     1
       destr      2020-05-31
       dsstr      2020-05-01
       epoch_seconds_end 1590962399
       mestr      05
       msstr      05
       testr      23:59:59
       tsstr      00:00:00
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1589955942.54029
           VALUE      done
   OLDREADINGS:
   READINGS:
     2020-05-20 08:25:42   2020-05-20_08-24-46__SMA_Wechselrichter__etotal__DIFF__no_aggregation 326.9490
     2020-05-20 08:25:42   background_processing_time 0.1381
     2020-05-20 08:25:42   sql_processing_time 0.0739
     2020-05-20 08:25:42   state           done
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    etotal
   room       Photovoltaik
   showproctime 1
   timeout    180
   timestamp_begin current_month_begin
   timestamp_end current_month_end
   userExitFn setDumEnergy .*:.*
   verbose    2
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 08:44:06
Ok. Jetzt mal bitte ein fetchrows bei Rep.SMAEM.Einspeisung.Monat und den list zeigen. Können sehr viele Werte sein. Mal schauen was geht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 08:55:32
So wird das nix Dieter  :)
Wenn du magst schlage ich dir vor dass wir mal heute Nachmittag zusammen telefonieren und ggf. eine Teamviewer Session machen.
Aber ich gehe davon aus., dass sich zum Monatswechsel das Problem erledigt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 09:04:59
es klappt nicht, weil das "code einfügen" hier im Forum nicht mehr zulässt.

Gibt es noch eine Möglichkeit dir das list zukommen zu lassen?

Zum Monatswechsel ist es im Monat behoben, aber ich vermute bei der Jahres Bilanz nicht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 09:17:53
Das ist richtig. Frage ist woher die Differenz kommt.
In diesen beiden Devices kannst du mal bitte

get <name> minTimestamp

ausfürhen. Welche Ergebnisse zeigen die beiden ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 09:20:48
Einspeisung
READINGS:
     2020-05-20 09:18:56   background_processing_time 0.0019
     2020-05-20 09:18:56   sql_processing_time 0.0007
     2020-05-20 09:18:56   state           done
     2020-05-20 09:18:56   timestamp_oldest_dataset 2020-04-13 21:54:39


Erzeugung
READINGS:
     2020-05-20 09:20:07   background_processing_time 0.0019
     2020-05-20 09:20:07   sql_processing_time 0.0008
     2020-05-20 09:20:07   state           done
     2020-05-20 09:20:07   timestamp_oldest_dataset 2020-04-13 21:54:39
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 09:30:47
Damit gibt es für beide den gleich Startzeitpunkt.
Jetzt müsste man noch herausbekommen ob bei einem von beiden in der Zeitschiene einen GAP hat.
Den könnte man mit einem zusätzlichen DAtensatz in der DB korrigieren.
Aber das kann man sich quasi nur online anschauen.
Vielleicht bekommst du etwas heraus wenn du dir die DAten per fetchrows durchschaust und irgendwo Unregelmäßigkeiten feststellst. Die könntest du mir nochmal zeigen.

Damit du mehr Daten (alle) anzeigen kannst, stellst du dir das Attribut "limit" auf zum Beispiel 6000 um 6000 Readings anzeigen zu können. Antwortzeit beachten ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 09:40:59
Mir ist noch etwas eingefallen.
Zeig mir doch bitte ein list von dem Rep.tempSQLITE DbRep  gestern mit dem wir den Export nach export.csv gemacht haben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 09:54:34
Unregelmäßigkeiten zu erkennen ist aussichtslos. Ich sehe da nix.

Was denkst du habe ich mit dem Rep.tempSQLITE DbRep gemacht?  ;) ???

Gelöscht natürlich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 09:59:04
Soso  ;)
Na vllt. gibt es das export.csv noch. Poste doch mal daraus einen Auschnitt, vllt. die ersten 200 -500 Zeilen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 11:32:14
sorry, musste zwischendrin tatsächlich noch was arbeiten  ;)

Die export.csv gibt es noch.
Daraus die ersten ca. 500 Zeilen????
Da ist doch der ganze log von fhem enthalten???

Und hierzu gleich die nächste Frage.
Sollte man das Loggen nicht besser nur auf Einspeisung und Erzeugung usw. beschränken?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 11:44:46
Zitatsorry, musste zwischendrin tatsächlich noch was arbeiten 
geht mir auch so  ;)

Zitat
Daraus die ersten ca. 500 Zeilen????
Da ist doch der ganze log von fhem enthalten???
Genau das wolte ich checken ob dort alles drin ist, oder vllt. nur SMA_Energymeter oder der WR.

ZitatSollte man das Loggen nicht besser nur auf Einspeisung und Erzeugung usw. beschränken?
Kommt drauf an was du sonst noch auswertest. Ich logge auch andere Dinge die ich benötige und grenze diese Dinge in den DbReps über die attribute device, reading ab. Teilweise nutze ich auch separate Datenbanken, z.B. für Events die ich über Log2Syslog als Collector von anderen Nicht-FHEM Devices (z.B. WLAN Access Points) sammle.

Kommt eben auf dein Gesamtkonzept an.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 20 Mai 2020, 11:47:52
was ist ein "Gesamtkonzept"  ;D ;D ;D

Also, es steht alles drin, nicht nur SMA...
Soll ich es noch posten?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 12:13:34
Ja, gerne. Mal einen Blick riskieren.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 20 Mai 2020, 12:23:51
Hey Ihr zwei,

sorry dass ich Eure traute Zweisamkeit hier ein wenig stören muss, aber auch wenn ich es jetzt nicht komplett gelesen habe:

Macht es Sinn den Beitrag hier mit der Anleitung voll zu machen ? - Wenn dort etwas wichtiges in den letzten 8 Seiten passiert ist, dann nehme ich alles zurück und behaupte das Gegenteil  ;D  Aber wenn dort "nur die Anleitung der Datenrettung" drin ist. Dann macht es für andere Forumsteilnehmer keinen bzw den Gegenteiligen Sinn.
Wenn ich einen Beitrag den ich beobachte (zu einem Modul das mich interessiert) sehe und dort innerhalb von 2 Tagen 8 Seiten dazu gekommen sind, dann befürchte ich erstmal ein Riesenproblem dort.....

Bitte nicht böse nehmen, ist nicht böse gemeint, sondern eher die Hoffnung einen Thread wie diesen, der zu einem Super Modul gehört, auch übersichtlicher zu lassen ... Mir hat die Suche hier schon das ein oder andere mal geholfen ... das geht nur wenn gewisse Befehle nicht zig mal auftauchen :)

Drücke dennoch weiter die Daumen, dass die Datenrettung erfolgreich verläuft  8)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Mai 2020, 12:37:34
Hallo Andreas,

hast recht, hat sich ein wenig aufgeplustert.
Die Datenrettung ist ja de facto abgeschlossen. Sind jetzt ein paar Feinheiten.
@Dieter, wenn noch Bedarf besteht können wir das auch per PM erledigen.
Dann stören wir niemenden hier.  ;)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 02 Juni 2020, 16:34:11
Hallo Heiko,

ich habe da mal wieder etwas, was unter customized query passen wuerde

Das ganze spuckt den ersten und den letzten Wert in einem Zeitraum, aus der DB raus.
Ich verwende das, wenn ich z.B. einen Strom Zaehler habe und den Verbrauch in dem Zeitraum ermitteln moechte.


SET @begin_time='2020-06-02 12:30:00';SET @end_time='2020-06-02 18:00:00';

SET @device='shelly02';SET @reading='energy_0';

SELECT TIMESTAMP,READING,round(VALUE/1000,0) AS VALUE
   FROM (
     (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device  AND  READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP LIMIT 1)
     UNION ALL 
     (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP DESC LIMIT 1)
  ) AS X1;

+---------------------+----------+-------+
| TIMESTAMP           | READING  | VALUE |
+---------------------+----------+-------+
| 2020-06-02 12:31:01 | energy_0 |    69 |
| 2020-06-02 16:31:05 | energy_0 |    73 |
+---------------------+----------+-------+


Oder mit Berechnung der Differenz
Hierbei ist zu beachten, dass die einzel Selects vertauscht wurden, um den TIMESTAMP des ersten Select zu bekommen. Die Subtraktion wurde durch "mal Minus Eins" des kleineren Wertes erreicht.

SET @begin_time='2020-06-02 12:30:00';SET @end_time='2020-06-02 18:00:00';

SET @device='shelly02';SET @reading='energy_0';

SELECT TIMESTAMP,READING,round(sum(VALUE)/1000,0) AS VALUE
   FROM (
     (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP DESC LIMIT 1)
     UNION ALL 
     (SELECT TIMESTAMP,READING,(VALUE * -1) AS VALUE FROM history WHERE DEVICE = @device  AND  READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP LIMIT 1)
  ) AS X1;

+---------------------+----------+-------+
| TIMESTAMP           | READING  | VALUE |
+---------------------+----------+-------+
| 2020-06-02 16:31:05 | energy_0 |     4 |
+---------------------+----------+-------+


Die Formatierung sollte eventuell weg gelassen werden, da diese natuerlich zum zu erwartenden Ergebnis passen muss.

round(sum(VALUE)/1000,0) AS VALUE


Gruss
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Juni 2020, 20:23:15
Hallo Christian,

ein sehr schönes Statement, danke !  :)

Ich versuche es als sqlSpecial abzubilden.
Vieleicht wäre es auch eine gute Idee im Wiki bei DbRep eine Rubrik für hilfreiche SQLs aufzumachen ?

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 02 Juni 2020, 20:56:36
Das wäre sicherlich eine gute Idee,  bei meinen abwegigen Einfällen kommt da eventuell einiges zusammen ;-)

So kann mal sich dann Behelfsskripte im FHEM sparen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Juni 2020, 09:42:43
Hallo zusammen,

ich habe im DbRep-Wiki eine Rubrik hilfreiche SQLs (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#hilfreiche_SQL_Statements) angelegt.
Das Beispiel von Christian ist dort schonmal abgelegt.

Fühlt euch bitte eingeladen diesen Teil mit eigenen Ergänzungen zu erweitern. Die Struktur seht ihr ja und jeder kann sich einen Wiki-Benutzer holen um Einträge zu machen.
Vergesst bitte nicht zu erwähnen mit welcher DB (SQLite etc.) ihr eure Statements ausführt, denn nicht jede Syntax passt für alle DB's.
Und auf evtl. Gefahren auch hinweisen.  ;)

Ich werde auch noch ein paar Dinge einfügen aus meinem Fundus.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Juni 2020, 13:34:46
Zitat von: DS_Starter am 05 Juni 2020, 09:42:43
Das Beispiel von Christian ist dort schonmal abgelegt.
Ich war schon fleissig, koenntest Du mal nachschauen, ob es so okay ist?

Bei der sqlSpecial fuer die Werte Differenzen habe ich dort noch eine Korrektur abgelegt. So passt es jetzt besser.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Juni 2020, 13:48:33
perfekt  :)

Einzige Anmerkung: Die Ergebnistabelle für die Beispiele würde ich auf ein paar Zeilen einkürzen. Die lange Tabelle stört nur und der Nachnutzer hat keinen Mehrwert wenn er _ALLE_ Ergebniszeilen lesen muss.

LG,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Juni 2020, 15:27:28
Zitat von: DS_Starter am 05 Juni 2020, 13:48:33
Einzige Anmerkung: Die Ergebnistabelle für die Beispiele würde ich auf ein paar Zeilen einkürzen. Die lange Tabelle stört nur und der Nachnutzer hat keinen Mehrwert wenn er _ALLE_ Ergebniszeilen lesen muss.
Ich habe es gekuerzt, wenn es noch kuerzer werden soll, dann muss ich auch die Anmerkungen mit der Erklaerung raus nehmen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Juni 2020, 15:29:52
Alles gut, war auch nur eine Empfehlung.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 05 Juni 2020, 15:40:42
Maaaaaahlzeit  8)

Ich weiss nicht ob ICH es richtig verstanden habe... aber kleine Anmerkung von mir und für diejenigen die hier nicht den Zusammenhang dieser Befehle gelesen haben:  Ggf wäre es von Vorteil auch das entsprechende DbRep Device auch einmal zu posten bzw ein Beispiel zu bringen....  Wenn der SQL Befehl in FHEM eingesetzt werden soll (und kann) muss man auch verstehen, wie es dort eingesetzt werden kann.

Aber ansosnten kann ich nur loben ... sieht wirklich SUPER aus. Alleine die Übersichtlichkeit in den Befehlen finde ich persönlich MEGA. Durch die Zeilenumbrüche kann man jeden einzelnen Befehl erkennen. Dadurch ist es für Anfänger (oder wenig erfahrene wie mich) leichter den Befehl nachzuvollziehen, wie er zusammen gesetzt wird und daraus lernen. Zu guter Letzt: Wenn man einen Befehlteil nicht kennt, kann man diesen besser rausfiltern und entsprechend danach suchen.... daher: wie immer, alle vorhandenen Daumen hoch  :)

Viele Grüße
Andreas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Juni 2020, 16:14:48
Zitat von: flummy1978 am 05 Juni 2020, 15:40:42
Ich weiss nicht ob ICH es richtig verstanden habe... aber kleine Anmerkung von mir und für diejenigen die hier nicht den Zusammenhang dieser Befehle gelesen haben:  Ggf wäre es von Vorteil auch das entsprechende DbRep Device auch einmal zu posten bzw ein Beispiel zu bringen....  Wenn der SQL Befehl in FHEM eingesetzt werden soll (und kann) muss man auch verstehen, wie es dort eingesetzt werden kann.

Aber ansosnten kann ich nur loben ... sieht wirklich SUPER aus. Alleine die Übersichtlichkeit in den Befehlen finde ich persönlich MEGA. Durch die Zeilenumbrüche kann man jeden einzelnen Befehl erkennen. Dadurch ist es für Anfänger (oder wenig erfahrene wie mich) leichter den Befehl nachzuvollziehen, wie er zusammen gesetzt wird und daraus lernen. Zu guter Letzt: Wenn man einen Befehlteil nicht kennt, kann man diesen besser rausfiltern und entsprechend danach suchen.... daher: wie immer, alle vorhandenen Daumen hoch  :)
Ich bedanke mich dehmuetig fuer das Lob...

Diese SQL Statements verwende ich oft in einem separaten Datenbank Zugriff

fhem@raspberrypi:~$ mysql -h [IP-Adresse] --port 3306 --database fhem -u fhemuser -p
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 42516
Server version: 5.5.60-0+deb7u1 (Debian)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [fhem]>

Das kann nuetzlich sein, wenn man mal schnell etwas Uebersicht haben moechte.
Den Aufruf mit DBRep als FHEM device findet man auch in der Dokumentation.
Heiko war auch so nett und hat einige SQL Statements als "sqlSpecial" bereits mit ins Modul eingebaut. Diese findest Du unter:

set [device] sqlSpecial

readingsDifferenceByTimeDelta waere dann ==> "9.2 Temperaturdifferenz eines Pufferspeichers über die Zeit ermitteln"

Hier fehlt noch die Referenz in der Wiki Page, die ich jetzt noch eintrage.

Gruss
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Juni 2020, 18:38:59
Im Start der Rubrik im Wiki hatte ich erwähnt wie man die SQL Statements grundsätzlich mit sqlCmd im DbRep ausführt und das Ergebnisdesign anpassen kann. Das gilt dann ja für alle nachfolgend aufgezeigten Statements.
Man muss sie nur einsetzen. Geht mit copy & paste denn sqlCmd ist ja ein großes Editor-Textfeld und nicht nur eine Zeile.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 27 Juni 2020, 04:04:00
Hallo Heiko,

seit ein Paar Tagen habe ich ein seltsames Phaenomen, die Average Werte werden nicht mehr berechnet, in den Readings steht dann "insufficient values", ich kann aber keine Auffälligkeiten an den Werten finden.
Die Max und Min Werte werden problemlos berechnet.

List:
Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      5d855dda-f33f-69d4-59da-2c00db9bd37e3d8c
   FVERSION   93_DbRep.pm:v8.40.1-s21965/2020-05-18
   LASTCMD    averageValue writeToDB
   MODEL      Client
   NAME       Report.Wetter
   NOTIFYDEV  global,Report.Wetter
   NR         171
   NTFY_ORDER 50-Report.Wetter
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE logdb
     GRANTS     SELECT,USAGE,UPDATE,INSERT,DELETE
     IDRETRIES  3
     MINTS      2018-10-06 11:45:06
     PACKAGE    main
     SQLHIST   
     VERSION    8.40.1
     CV:
       aggregation day
       aggsec     86400
       destr      2020-06-26
       dsstr      2020-06-01
       epoch_seconds_end 1593187199
       mestr      06
       msstr      06
       testr      23:59:59
       tsstr      00:00:00
       wdadd     
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1593222219.24083
           VALUE      done
   OLDREADINGS:
   READINGS:
     2020-06-27 09:43:39   2020-06-01__Luftquali__temperature__AVGDMGWS__2020-06-01 16.1
     2020-06-27 09:43:39   2020-06-02__Luftquali__temperature__AVGDMGWS__2020-06-02 18.4
     2020-06-27 09:43:39   2020-06-03__Luftquali__temperature__AVGDMGWS__2020-06-03 insufficient values
     2020-06-27 09:43:39   2020-06-04__Luftquali__temperature__AVGDMGWS__2020-06-04 16.8
     2020-06-27 09:43:39   2020-06-05__Luftquali__temperature__AVGDMGWS__2020-06-05 19.5
     2020-06-27 09:43:39   2020-06-06__Luftquali__temperature__AVGDMGWS__2020-06-06 21.8
     2020-06-27 09:43:39   2020-06-07__Luftquali__temperature__AVGDMGWS__2020-06-07 25.3
     2020-06-27 09:43:39   2020-06-08__Luftquali__temperature__AVGDMGWS__2020-06-08 28.8
     2020-06-27 09:43:39   2020-06-09__Luftquali__temperature__AVGDMGWS__2020-06-09 24.5
     2020-06-27 09:43:39   2020-06-10__Luftquali__temperature__AVGDMGWS__2020-06-10 21.3
     2020-06-27 09:43:39   2020-06-11__Luftquali__temperature__AVGDMGWS__2020-06-11 21.3
     2020-06-27 09:43:39   2020-06-12__Luftquali__temperature__AVGDMGWS__2020-06-12 25.1
     2020-06-27 09:43:39   2020-06-13__Luftquali__temperature__AVGDMGWS__2020-06-13 24.4
     2020-06-27 09:43:39   2020-06-14__Luftquali__temperature__AVGDMGWS__2020-06-14 20.8
     2020-06-27 09:43:39   2020-06-15__Luftquali__temperature__AVGDMGWS__2020-06-15 19.5
     2020-06-27 09:43:39   2020-06-16__Luftquali__temperature__AVGDMGWS__2020-06-16 24.5
     2020-06-27 09:43:39   2020-06-17__Luftquali__temperature__AVGDMGWS__2020-06-17 25.9
     2020-06-27 09:43:39   2020-06-18__Luftquali__temperature__AVGDMGWS__2020-06-18 22.9
     2020-06-27 09:43:39   2020-06-19__Luftquali__temperature__AVGDMGWS__2020-06-19 23.4
     2020-06-27 09:43:39   2020-06-20__Luftquali__temperature__AVGDMGWS__2020-06-20 insufficient values
     2020-06-27 09:43:39   2020-06-21__Luftquali__temperature__AVGDMGWS__2020-06-21 23.1
     2020-06-27 09:43:39   2020-06-22__Luftquali__temperature__AVGDMGWS__2020-06-22 insufficient values
     2020-06-27 09:43:39   2020-06-23__Luftquali__temperature__AVGDMGWS__2020-06-23 insufficient values
     2020-06-27 09:43:39   2020-06-24__Luftquali__temperature__AVGDMGWS__2020-06-24 insufficient values
     2020-06-27 09:43:39   2020-06-25__Luftquali__temperature__AVGDMGWS__2020-06-25 insufficient values
     2020-06-27 09:43:39   2020-06-26__Luftquali__temperature__AVGDMGWS__2020-06-26 insufficient values
     2020-06-27 09:43:39   background_processing_time 2.2513
     2020-06-27 09:43:39   db_lines_processed 38
     2020-06-27 09:43:39   sql_processing_time 2.2298
     2020-06-27 09:43:39   state           done
Attributes:
   aggregation day
   allowDeletion 1
   averageCalcForm avgDailyMeanGWS
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     Luftquali
   event-on-update-reading state
   group      DB
   icon       security
   reading    temperature
   room       Datenbank
   showproctime 1
   sortby     33
   timestamp_begin current_month_begin
   timestamp_end previous_day_end
   verbose    5



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2020, 07:55:32
Guten Morgen,

du berechnest die Tagesdurchschnitte nach den Richtlinien des deutschen Wetterdienstes.
In der CommandRef zum Attribut averageCalcForm = avgDailyMeanGWS ist der Hinweis enthalten:


berechnet die Tagesmitteltemperatur entsprechend den Vorschriften des deutschen Wetterdienstes (siehe "get <name> versionNotes 2").
Diese Variante verwendet automatisch die Aggregation "day".


Wenn man dem Hinweis folgt und "get <name> versionNotes 2" aufruft, erhält man den Link zu den Regularien des deutschen Wetterdienstes. Dort ist die Vorschrift zur Berechnung der Tagesdurchschnitte enthalten:


Ab dem 01.04.2001 wurde der Standard wie folgt geändert:

  *  Berechnung der Tagesmittel aus 24 Stundenwerten
  *  Wenn mehr als 3 Stundenwerte fehlen -> Berechnung aus den 4 Hauptterminen (00, 06, 12, 18 UTC)
   * Bezugszeit für einen Tag i.d.R. 23:51 UTC des Vortages bis 23:50 UTC


Das heißt also, dass deine verfügbaren Rohdaten eine Berechnung nicht erlauben, weil zu den relevanten Zeiten Daten fehlen. Wenn die erste Bedingung nicht eingehalten werden kann und mehr als 3 Stundenwerte fehlen, werden die Haupttermine verwendet. Wenn nur ein Haupttermin fehlt, kommt "insufficient values".

Ich habe mir jetzt nicht die Mühe gemacht alle Werte zu durchschauen, aber das wäre der Ansatz.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 27 Juni 2020, 12:08:29
Hallo Heiko,

danke für die Info, hab mir die Daten angeschaut, da fehlen einige Daten zu den relevanten Stunden (hatte Probleme mit dem Tempsensor), habe erstmal auf das arithmetische Mittel umgestellt.

Gruß
Alex
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Juni 2020, 13:36:27
Hallo Alex,

habe get <> versionNotes 2 gleich noch etwas aufgewertet und eingecheckt.
Jetzt kommt in diesem Fall:


     2020-06-27 13:29:48   2020-06-25__Dum.Energy__AutarkyQuote__AVGDMGWS__2020-06-25 52.3
     2020-06-27 13:29:48   2020-06-26__Dum.Energy__AutarkyQuote__AVGDMGWS__2020-06-26 51.6
     2020-06-27 13:29:48   2020-06-27__Dum.Energy__AutarkyQuote__AVGDMGWS__2020-06-27 insufficient values - execute get Rep.CPU versionNotes 2 for further information


Und wenn man das tut ... siehe Anhang.
Sollte jetzt deutlicher werden.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 27 Juni 2020, 14:49:08
perfekt, hilft auf jeden Fall weiter!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 30 Juni 2020, 19:30:30
Hallo zusammen,
hier kommt mal wieder eins von Christians specialSQL für MySQL Datenbanken;-)

Es wird das letzte reading eines Monats der letzten 12 Monate ermittelt.

Der Hintergrund ist, dass ich einen Plot z.B. der PV Erträge der letzten Monate erstellen möchte. Hierbei ist das device Dum.Energy meine PV Bilanz und das reading PVMonth steigt stundenweise über den ganzen Monat. Im anhängenden Bild wird es eventuell klarer. Somit zeigt der letzte Eintrag in jedem Monat den gesamt Monatsertrag. Es werden nur drei Monate angezeigt, weil ich es noch nicht länger laufen habe.

SET @device = 'Dum.Energy';SET @reading='PVMonth';

SELECT TIMESTAMP,READING, VALUE
   FROM (
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  0 month) AND LAST_DAY(NOW() - interval  0 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  1 month) AND LAST_DAY(NOW() - interval  1 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  2 month) AND LAST_DAY(NOW() - interval  2 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  3 month) AND LAST_DAY(NOW() - interval  3 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  4 month) AND LAST_DAY(NOW() - interval  4 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  5 month) AND LAST_DAY(NOW() - interval  5 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  6 month) AND LAST_DAY(NOW() - interval  6 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  7 month) AND LAST_DAY(NOW() - interval  7 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  8 month) AND LAST_DAY(NOW() - interval  8 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval  9 month) AND LAST_DAY(NOW() - interval  9 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval 10 month) AND LAST_DAY(NOW() - interval 10 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)
     UNION ALL
     (SELECT TIMESTAMP,READING,VALUE FROM (SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP BETWEEN LAST_DAY(NOW() - interval 11 month) AND LAST_DAY(NOW() - interval 11 month) + interval 1 day ORDER BY TIMESTAMP DESC LIMIT 2) AS X1 ORDER BY TIMESTAMP ASC LIMIT 1)

  ) AS X1 ORDER BY TIMESTAMP;
+---------------------+---------+--------+
| TIMESTAMP           | READING | VALUE  |
+---------------------+---------+--------+
| 2020-04-30 23:00:00 | PVMonth | 563.77 |
| 2020-05-31 23:00:00 | PVMonth | 511.61 |
| 2020-06-30 19:00:00 | PVMonth | 465.54 |
+---------------------+---------+--------+


@Heiko Wie könnte ich daraus im DBRep einen SVG Plot erstellen? Ich gestehe, dass ich das noch nicht erarbeitet habe :-(

Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      5e57f222-f33f-61a8-e514-be207ebe812c1bee
   FVERSION   93_DbRep.pm:v8.40.2-s22287/2020-06-27
...
   MODEL      Client
   NAME       LogDBRep
   NOTIFYDEV  global,LogDBRep
   NR         420
   NTFY_ORDER 50-LogDBRep
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     ALL PRIVILEGES,USAGE
     IDRETRIES  3
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST   
     VERSION    8.40.2
     CV:
       aggregation no
       aggsec     1
       destr      2020-06-30
       dsstr      2020-06-30
       epoch_seconds_end 1593554399
       mestr      06
       msstr      06
       testr      23:59:59
       tsstr      00:00:00
       wdadd      518400
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2020-06-30 19:33:16   SqlResultRow_1  TIMESTAMP|READING|VALUE
     2020-06-30 19:33:16   SqlResultRow_2  2020-04-30 00:00:00|PVMonth|545.34
     2020-06-30 19:33:16   SqlResultRow_3  2020-05-31 00:00:00|PVMonth|492.22
     2020-06-30 19:33:16   SqlResultRow_4  2020-06-30 00:00:00|PVMonth|451.55
     2020-06-30 19:33:16   sqlCmd          ...Mein Select...
     2020-06-30 19:33:16   sqlResultNumRows 3
     2020-06-30 19:33:16   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 0


Viele Gruesse
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Juni 2020, 21:01:28
Hallo Christian,

ich denke das geht einfacher oder ich habe etwas nicht verstanden.
Also grundsätzlich kannst du nur Werte mit SVG plotten die sich in der DB befinden.

Wenn du aber schon ein Reading PVMonth in der DB hast, reicht ein

set <> maxValue display


mit gesetzten Attribut

aggregation = month

Dann bekommst du die max. Werte jeden Monats in den gesetzten time* Grenzen.

Und wenn du jetzt


set <> maxValue writeToDB


ausführst, werden die ermittelten MAX Werte mit neuem Readingnamen in die DB zurückgeschrieben und du kannst sie plotten.  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 Juli 2020, 09:02:30
Okay, das werde ich mal testen.

EDIT: Das ist es was ich gesucht hatte, mein SQL war somit eine schöne Uebung und klappt auf dem MySQL Promt.

Hier die Attribute und readings mit DBLog
Anmerkung: Der erste Wert im Monat um 00-00-00 gehört leider zum Vormonat, aber da schaue ich nochmal mit meinem Timing...

Attributes:
   aggregation month
   device     Dum.Energy
   reading    PVMonth
    timestamp_begin current_year_begin
   timestamp_end current_day_end


   READINGS:
     2020-07-01 11:05:02   2020-01-01__Dum.Energy__PVMonth__MAX__2020-01 0.0000
     2020-07-01 11:05:02   2020-02-01__Dum.Energy__PVMonth__MAX__2020-02 0.0000
     2020-07-01 11:05:02   2020-03-01__Dum.Energy__PVMonth__MAX__2020-03 0.0000
     2020-07-01 11:05:02   2020-04-30_23-00-00__Dum.Energy__PVMonth__MAX__2020-04 563.7700
     2020-07-01 11:05:02   2020-05-01_00-00-00__Dum.Energy__PVMonth__MAX__2020-05 564.1500
     2020-07-01 11:05:02   2020-06-01_00-00-00__Dum.Energy__PVMonth__MAX__2020-06 512.1700
     2020-07-01 11:05:02   2020-07-01_00-00-00__Dum.Energy__PVMonth__MAX__2020-07 467.5600


Vielen Dank Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 Juli 2020, 14:01:15
Hallo nochmal,

jetzt habe ich die max_month_PVMonth Werte am letzten Tag des Monats um 23:59 Uhr in der DBLog.
Die Krönung wäre natürlich, wenn man die Beschriftung under den bar verschieben könnte, aber so reicht es auch :-)

Wenn ich das nun mit SVG visualisiere sieht das Ganze wie folgt aus:

# Created by FHEM/98_SVG.pm, 2020-07-01 13:57:43
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'PV_Bilanz'
set ytics
set y2tics
set grid
set ylabel ""
set y2label ""

#LogDB Dum.Energy:max_month_PVMonth::

plot "<IN>" using 1:2 axes x1y2 title 'PVMonth' ls l2 lw 1 with bars


Vielen Dank fuer die Hilfe
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Juli 2020, 14:19:07
Hi Christian,

prima.  :D

ZitatDie Krönung wäre natürlich, wenn man die Beschriftung under den bar verschieben könnte, aber so reicht es auch :-)
Kannst du ja mal im SVG Forum nachfragen. Ich bin da nicht so der Experte der Feinheiten vom SVG.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Juli 2020, 14:21:57
@CHristian,

es wäre trotzdem schön wenn du dein Statement wieder im Wiki einbringen würdes. Man kann davon eigene Übungen ableiten.  8)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 Juli 2020, 14:30:04
Zitat von: DS_Starter am 01 Juli 2020, 14:21:57
es wäre trotzdem schön wenn du dein Statement wieder im Wiki einbringen würdes. Man kann davon eigene Übungen ableiten.  8)
Waere es da nicht besser das von Dir verwendete SQL, das den Monatswert ermittelt, zu dokumentieren?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Juli 2020, 14:31:24
Naja, das sieht man ja wenn man verbose 4, respective 5,  einschaltet  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 Juli 2020, 15:47:55
Zitat von: DS_Starter am 01 Juli 2020, 14:31:24
Naja, das sieht man ja wenn man verbose 4, respective 5,  einschaltet  ;)
Dokumentation im Code war schon immer geil :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Juli 2020, 15:59:25
 :) ... ich komme einfach nicht mehr hinterher bei allem was ich momentan an den verschiedensten Module so weiterentwickle. Sonst dokumentiere ich auch gerne und viel ...

EDIT: Will damit sagen wenn jemand gerne das Wiki mit Doku abgeleitet aus DbRep-Statements ergänzen möchte ist er gern eingeladen und ich freue mich über die Unterstützung !
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 11:00:30
Hallo,

gibt es eine Möglichkeit doppelte bzw. zeitlich kurz aufeinanderfolgende (<15 sec.) Datensätze zu identifizieren und dann zu löschen?

Doppelter Datensatz mit ...Diff_1

     2020-07-14 19:14:17   2020-07-14_05-00-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 19:14:17   2020-07-14_05-00-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0518


Zeitabstand sollte ca. 60 sec sein. Hier nur 2 sec, daher löschen.

    2020-07-14 19:14:17   2020-07-14_05-41-30__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0031
    2020-07-14 19:14:17   2020-07-14_05-41-32__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2383


Für Ideen sind Heiko und ich dankbar  ;)

VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 11:12:43
Ich überlege mal mit, kann aber etwas dauern.
Als erstes würde ich das Abfrageintervall schon mal verlängern :-)
Gruß Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Juli 2020, 11:17:36
Danke fürs Mitdenken Christian :)

Die Aussage

Zitat
Doppelter Datensatz mit ...Diff_1

ist nicht ganz korrekt.. Die Werte sind different, bei doppelten DS wären sie identisch.
Deswegen reduziert sich die Aufgabe DS zeitlich in einem bestimmten kleinen Intervall zu identifizieren und den späteren von beiden zu löschen.
Ein geschicktes SQL wird gesucht.  :D

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 11:23:54
Zitat von: ch.eick am 15 Juli 2020, 11:12:43
Ich überlege mal mit, kann aber etwas dauern.
Als erstes würde ich das Abfrageintervall schon mal verlängern :-)
Gruß Christian

Danke für deine Unterstützung.

Das Abfrageintervall liegt bei 60 sec. wie hier beschrieben:

https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung (https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung)

Bei mir wurden nur, aus welchem Grund auch immer, irgendwelche dubiosen Werte geloggt.
Die gilt es aufzuspüren und zu löschen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 14:05:29
Zitat von: DS_Starter am 15 Juli 2020, 11:17:36
Danke fürs Mitdenken Christian :)

Die Aussage

ist nicht ganz korrekt.. Die Werte sind different, bei doppelten DS wären sie identisch.
Deswegen reduziert sich die Aufgabe DS zeitlich in einem bestimmten kleinen Intervall zu identifizieren und den späteren von beiden zu löschen.

Hier sollte eventuell noch die Wichtigkeit der Werte mit beruecksichtigt werden ;-)

Es gibt doch beim beim DBRep ein maxValue mit aggregation, da waere die Zeit zwar auf Stunde, aber eventuell koennte man das ja auf Minutenbasis verwenden.
Dann waere entweder der Hoehere oder der Niedrigere Wert weg. Das Ergebnis wird als neues reading in die DB geschrieben und muesste dann noch umbenannt werden.

Die Schritte im einzelnen:

- aggregieren auf Minuten Basis
- Es werden neue Eintraege geschrieben z.B. 2020-06-30_23-59-00__SMA_Zaehler__Bezug_WirkP_Zaehler__MAX__2020-06-.......
- Loeschen aller alten Eintraege in dem Zeitraum von timestamp_begin bis timestamp_end
- Umbenennen der neuen Eintraege auf den reading Namen der urspruenglichen readings


Bitte gib doch mal ein Beispiel Select der original Eintraege als Muster. Also das Select und den Output ;-)

Gruss
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 14:17:06
Ich hoffe das ist das was du wolltest  ???

     2020-07-14 20:20:28   2020-07-14_04-37-54__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-38-54__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-39-55__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-40-56__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-41-57__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-42-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0063
     2020-07-14 20:20:28   2020-07-14_04-43-59__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0250
     2020-07-14 20:20:28   2020-07-14_04-45-00__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-46-01__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-47-02__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-48-03__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-49-04__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-49-04__2__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-50-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-50-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0047
     2020-07-14 20:20:28   2020-07-14_04-51-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0094
     2020-07-14 20:20:28   2020-07-14_04-52-08__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-52-44__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0141
     2020-07-14 20:20:28   2020-07-14_04-53-11__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0189
     2020-07-14 20:20:28   2020-07-14_04-54-11__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-54-12__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0237
     2020-07-14 20:20:28   2020-07-14_04-55-13__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0283
     2020-07-14 20:20:28   2020-07-14_04-56-14__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_04-56-26__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0330
     2020-07-14 20:20:28   2020-07-14_04-57-17__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0377
     2020-07-14 20:20:28   2020-07-14_04-58-19__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_04-58-19__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0424
     2020-07-14 20:20:28   2020-07-14_04-59-21__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0470
     2020-07-14 20:20:28   2020-07-14_04-59-21__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0047
     2020-07-14 20:20:28   2020-07-14_05-00-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_05-00-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0518
     2020-07-14 20:20:28   2020-07-14_05-01-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0564
     2020-07-14 20:20:28   2020-07-14_05-02-23__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0046
     2020-07-14 20:20:28   2020-07-14_05-03-08__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0612
     2020-07-14 20:20:28   2020-07-14_05-03-55__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0659
     2020-07-14 20:20:28   2020-07-14_05-04-40__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0704
     2020-07-14 20:20:28   2020-07-14_05-05-41__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0054
     2020-07-14 20:20:28   2020-07-14_05-05-50__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0749
     2020-07-14 20:20:28   2020-07-14_05-06-31__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0793
     2020-07-14 20:20:28   2020-07-14_05-07-32__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0057
     2020-07-14 20:20:28   2020-07-14_05-07-32__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0849
     2020-07-14 20:20:28   2020-07-14_05-08-33__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0063
     2020-07-14 20:20:28   2020-07-14_05-08-34__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0914
     2020-07-14 20:20:28   2020-07-14_05-09-36__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0063
     2020-07-14 20:20:28   2020-07-14_05-09-45__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0976
     2020-07-14 20:20:28   2020-07-14_05-10-39__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1037
     2020-07-14 20:20:28   2020-07-14_05-11-39__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0058
     2020-07-14 20:20:28   2020-07-14_05-11-39__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.1095
     2020-07-14 20:20:28   2020-07-14_05-12-41__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1143
     2020-07-14 20:20:28   2020-07-14_05-12-41__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0049
     2020-07-14 20:20:28   2020-07-14_05-13-42__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_05-13-46__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1190
     2020-07-14 20:20:28   2020-07-14_05-14-45__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1237
     2020-07-14 20:20:28   2020-07-14_05-15-46__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0050
     2020-07-14 20:20:28   2020-07-14_05-16-46__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1332
     2020-07-14 20:20:28   2020-07-14_05-17-47__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_05-17-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1382
     2020-07-14 20:20:28   2020-07-14_05-18-53__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0049
     2020-07-14 20:20:28   2020-07-14_05-19-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1429
     2020-07-14 20:20:28   2020-07-14_05-20-19__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1477
     2020-07-14 20:20:28   2020-07-14_05-20-57__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1524
     2020-07-14 20:20:28   2020-07-14_05-21-56__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1571
     2020-07-14 20:20:28   2020-07-14_05-22-57__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0047
     2020-07-14 20:20:28   2020-07-14_05-23-59__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1618
     2020-07-14 20:20:28   2020-07-14_05-23-59__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0047
     2020-07-14 20:20:28   2020-07-14_05-24-48__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1666
     2020-07-14 20:20:28   2020-07-14_05-25-49__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0074
     2020-07-14 20:20:28   2020-07-14_05-26-05__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1749
     2020-07-14 20:20:28   2020-07-14_05-27-07__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0038
     2020-07-14 20:20:28   2020-07-14_05-28-08__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0034
     2020-07-14 20:20:28   2020-07-14_05-28-08__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.1820
     2020-07-14 20:20:28   2020-07-14_05-29-10__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0034
     2020-07-14 20:20:28   2020-07-14_05-29-10__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.1854
     2020-07-14 20:20:28   2020-07-14_05-30-11__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1905
     2020-07-14 20:20:28   2020-07-14_05-31-13__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0051
     2020-07-14 20:20:28   2020-07-14_05-31-23__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.1955
     2020-07-14 20:20:28   2020-07-14_05-32-15__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2006
     2020-07-14 20:20:28   2020-07-14_05-33-16__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0051
     2020-07-14 20:20:28   2020-07-14_05-33-16__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.2056
     2020-07-14 20:20:28   2020-07-14_05-34-18__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0050
     2020-07-14 20:20:28   2020-07-14_05-34-25__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2106
     2020-07-14 20:20:28   2020-07-14_05-35-27__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0056
     2020-07-14 20:20:28   2020-07-14_05-35-35__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2155
     2020-07-14 20:20:28   2020-07-14_05-36-37__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0062
     2020-07-14 20:20:28   2020-07-14_05-36-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2203
     2020-07-14 20:20:28   2020-07-14_05-37-23__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2251
     2020-07-14 20:20:28   2020-07-14_05-38-24__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0036
     2020-07-14 20:20:28   2020-07-14_05-39-26__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2288
     2020-07-14 20:20:28   2020-07-14_05-39-26__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0032
     2020-07-14 20:20:28   2020-07-14_05-39-28__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2320
     2020-07-14 20:20:28   2020-07-14_05-40-29__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2351
     2020-07-14 20:20:28   2020-07-14_05-41-30__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0031
     2020-07-14 20:20:28   2020-07-14_05-41-32__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2383
     2020-07-14 20:20:28   2020-07-14_05-42-33__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2414
     2020-07-14 20:20:28   2020-07-14_05-42-33__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0031
     2020-07-14 20:20:28   2020-07-14_05-43-36__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0034
     2020-07-14 20:20:28   2020-07-14_05-44-14__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2447
     2020-07-14 20:20:28   2020-07-14_05-45-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2484
     2020-07-14 20:20:28   2020-07-14_05-45-53__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2518
     2020-07-14 20:20:28   2020-07-14_05-46-55__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0040
     2020-07-14 20:20:28   2020-07-14_05-47-27__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2549
     2020-07-14 20:20:28   2020-07-14_05-48-29__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0057
     2020-07-14 20:20:28   2020-07-14_05-48-41__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2612
     2020-07-14 20:20:28   2020-07-14_05-49-43__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0026
     2020-07-14 20:20:28   2020-07-14_05-49-43__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.2637
     2020-07-14 20:20:28   2020-07-14_05-50-44__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0032
     2020-07-14 20:20:28   2020-07-14_05-50-44__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.2669
     2020-07-14 20:20:28   2020-07-14_05-51-44__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0028
     2020-07-14 20:20:28   2020-07-14_05-52-40__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2698
     2020-07-14 20:20:28   2020-07-14_05-52-45__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2721
     2020-07-14 20:20:28   2020-07-14_05-53-46__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2744
     2020-07-14 20:20:28   2020-07-14_05-54-49__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0023
     2020-07-14 20:20:28   2020-07-14_05-54-49__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.2767
     2020-07-14 20:20:28   2020-07-14_05-55-49__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0022
     2020-07-14 20:20:28   2020-07-14_05-56-48__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2789
     2020-07-14 20:20:28   2020-07-14_05-57-02__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2811
     2020-07-14 20:20:28   2020-07-14_05-57-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2832
     2020-07-14 20:20:28   2020-07-14_05-58-53__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2854
     2020-07-14 20:20:28   2020-07-14_05-59-54__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0020
     2020-07-14 20:20:28   2020-07-14_05-59-57__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2875
     2020-07-14 20:20:28   2020-07-14_06-00-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0042
     2020-07-14 20:20:28   2020-07-14_06-00-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.2915
     2020-07-14 20:20:28   2020-07-14_06-02-00__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0041
     2020-07-14 20:20:28   2020-07-14_06-02-12__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2957
     2020-07-14 20:20:28   2020-07-14_06-03-00__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.2983
     2020-07-14 20:20:28   2020-07-14_06-04-03__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0086
     2020-07-14 20:20:28   2020-07-14_06-04-03__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.3066
     2020-07-14 20:20:28   2020-07-14_06-05-03__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0051
     2020-07-14 20:20:28   2020-07-14_06-06-03__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3164
     2020-07-14 20:20:28   2020-07-14_06-07-04__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0042
     2020-07-14 20:20:28   2020-07-14_06-07-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3207
     2020-07-14 20:20:28   2020-07-14_06-08-07__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3252
     2020-07-14 20:20:28   2020-07-14_06-09-08__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3327
     2020-07-14 20:20:28   2020-07-14_06-10-09__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0114
     2020-07-14 20:20:28   2020-07-14_06-10-11__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3442
     2020-07-14 20:20:28   2020-07-14_06-11-13__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0094
     2020-07-14 20:20:28   2020-07-14_06-12-10__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3533
     2020-07-14 20:20:28   2020-07-14_06-13-12__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0115
     2020-07-14 20:20:28   2020-07-14_06-13-15__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3650
     2020-07-14 20:20:28   2020-07-14_06-14-15__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3684
     2020-07-14 20:20:28   2020-07-14_06-15-16__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0034
     2020-07-14 20:20:28   2020-07-14_06-15-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3719
     2020-07-14 20:20:28   2020-07-14_06-16-21__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.3979
     2020-07-14 20:20:28   2020-07-14_06-17-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0262
     2020-07-14 20:20:28   2020-07-14_06-18-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4349
     2020-07-14 20:20:28   2020-07-14_06-19-23__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0252
     2020-07-14 20:20:28   2020-07-14_06-20-25__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0058
     2020-07-14 20:20:28   2020-07-14_06-21-27__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0053
     2020-07-14 20:20:28   2020-07-14_06-21-38__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4713
     2020-07-14 20:20:28   2020-07-14_06-22-39__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0051
     2020-07-14 20:20:28   2020-07-14_06-22-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4759
     2020-07-14 20:20:28   2020-07-14_06-23-59__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0045
     2020-07-14 20:20:28   2020-07-14_06-24-03__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4790
     2020-07-14 20:20:28   2020-07-14_06-24-34__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4821
     2020-07-14 20:20:28   2020-07-14_06-25-35__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0031
     2020-07-14 20:20:28   2020-07-14_06-26-04__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4851
     2020-07-14 20:20:28   2020-07-14_06-27-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0048
     2020-07-14 20:20:28   2020-07-14_06-27-47__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4915
     2020-07-14 20:20:28   2020-07-14_06-28-48__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0027
     2020-07-14 20:20:28   2020-07-14_06-28-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4939
     2020-07-14 20:20:28   2020-07-14_06-30-00__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0028
     2020-07-14 20:20:28   2020-07-14_06-30-05__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.4960
     2020-07-14 20:20:28   2020-07-14_06-31-07__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0030
     2020-07-14 20:20:28   2020-07-14_06-31-43__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5002
     2020-07-14 20:20:28   2020-07-14_06-32-44__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0021
     2020-07-14 20:20:28   2020-07-14_06-32-46__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5023
     2020-07-14 20:20:28   2020-07-14_06-33-47__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0021
     2020-07-14 20:20:28   2020-07-14_06-33-47__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5043
     2020-07-14 20:20:28   2020-07-14_06-34-50__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0019
     2020-07-14 20:20:28   2020-07-14_06-35-50__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5080
     2020-07-14 20:20:28   2020-07-14_06-36-51__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0018
     2020-07-14 20:20:28   2020-07-14_06-36-51__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5098
     2020-07-14 20:20:28   2020-07-14_06-37-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0019
     2020-07-14 20:20:28   2020-07-14_06-37-52__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5116
     2020-07-14 20:20:28   2020-07-14_06-38-53__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0019
     2020-07-14 20:20:28   2020-07-14_06-38-53__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5136
     2020-07-14 20:20:28   2020-07-14_06-39-55__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0021
     2020-07-14 20:20:28   2020-07-14_06-40-57__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0020
     2020-07-14 20:20:28   2020-07-14_06-40-57__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5177
     2020-07-14 20:20:28   2020-07-14_06-41-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0018
     2020-07-14 20:20:28   2020-07-14_06-41-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5195
     2020-07-14 20:20:28   2020-07-14_06-42-59__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0016
     2020-07-14 20:20:28   2020-07-14_06-44-00__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0014
     2020-07-14 20:20:28   2020-07-14_06-44-00__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5224
     2020-07-14 20:20:28   2020-07-14_06-45-01__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5237
     2020-07-14 20:20:28   2020-07-14_06-46-02__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0014
     2020-07-14 20:20:28   2020-07-14_06-46-04__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5251
     2020-07-14 20:20:28   2020-07-14_06-47-06__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0009
     2020-07-14 20:20:28   2020-07-14_06-47-14__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5260
     2020-07-14 20:20:28   2020-07-14_06-48-10__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5267
     2020-07-14 20:20:28   2020-07-14_06-49-11__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0008
     2020-07-14 20:20:28   2020-07-14_06-49-48__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5275
     2020-07-14 20:20:28   2020-07-14_06-50-12__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5282
     2020-07-14 20:20:28   2020-07-14_06-51-15__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0006
     2020-07-14 20:20:28   2020-07-14_06-52-16__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0122
     2020-07-14 20:20:28   2020-07-14_06-53-18__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0141
     2020-07-14 20:20:28   2020-07-14_06-53-58__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5550
     2020-07-14 20:20:28   2020-07-14_06-54-17__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5567
     2020-07-14 20:20:28   2020-07-14_06-55-19__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0012
     2020-07-14 20:20:28   2020-07-14_06-55-19__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5579
     2020-07-14 20:20:28   2020-07-14_06-56-19__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5583
     2020-07-14 20:20:28   2020-07-14_06-57-21__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0
     2020-07-14 20:20:28   2020-07-14_06-57-21__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5583
     2020-07-14 20:20:28   2020-07-14_06-58-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.5583
     2020-07-14 20:20:28   2020-07-14_06-58-22__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.0001
     2020-07-14 20:20:28   2020-07-14_06-59-24__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0001
     2020-07-14 20:20:28   2020-07-14_06-59-24__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff_1 0.5584
     2020-07-14 20:20:28   2020-07-14_07-00-26__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0
     2020-07-14 20:20:28   2020-07-14_07-03-47__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0.0002
     2020-07-14 20:20:28   2020-07-14_07-04-48__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0
     2020-07-14 20:20:28   2020-07-14_07-05-48__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0
     2020-07-14 20:20:28   2020-07-14_07-06-49__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0
     2020-07-14 20:20:28   2020-07-14_07-07-50__1__SMA_Zaehler__Bezug_WirkP_Zaehler_Diff 0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 15:06:41
Zitat von: dk3572 am 15 Juli 2020, 14:17:06
Ich hoffe das ist das was du wolltest  ???
Das sieht fuer mich aus, wie eine DBRep ausgabe??? Ich wuerde gerne die original Eintraege aus der DB sehen.

Auf der SQL Konsole z.B. soetwas

select * from history
where DEVICE  = 'SMA_Zaehler'  AND READING  = 'Bezug_WirkP_Zaehler_Diff' AND
        TIMESTAMP >= '2020-07-14 04:37:54' and TIMESTAMP < '2020-07-14 07:07:50'
  ORDER BY TIMESTAMP
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 15:09:23
Das weiß ich leider nicht wie das funktioniert.  :-[
Falls du mir die nötigen Schritte zeigst, kann ich das gerne liefern.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 15:32:51
Zitat von: dk3572 am 15 Juli 2020, 15:09:23
Das weiß ich leider nicht wie das funktioniert.  :-[
Falls du mir die nötigen Schritte zeigst, kann ich das gerne liefern.

Ich habe schon mal in das SMAEM Modul geschaut und folgendes in der Doku gefunden
Zitat
diffAccept
legt fest, bis zu welchem Schwellenwert eine berechnete positive Werte-Differenz
  zwischen zwei unmittelbar aufeinander folgenden Zählerwerten (Readings mit *_Diff) akzeptiert werden
  soll (Standard ist 10).
  Damit werden eventuell fehlerhafte Differenzen mit einem unverhältnismäßig hohen Differenzwert von der Berechnung
  ausgeschlossen und der Messzyklus verworfen.
Ich denke, da ist ein bekanntes Verhalten, fuer dass es bereits eine Umgehung gibt. Das koenntest Du in dem anderen SMAEM thread mal posten und somit die Ursache der DB Eintraege beseitigen.


Kannst Du Dich in einer Terminalsession an Deiner SQL Datenbank anmelden?

fhem@raspberrypi:~$ mysql -h <IP-Adresse der Datenbank> --port 3306 --database fhem -u <Username aus der Konfiguration> -p
Enter password:
Server version: 5.5.60-0+deb7u1 (Debian)
MySQL [fhem]> select * from history where DEVICE  = 'StromZaehler_Heizung'  AND READING  = 'SMAEM1901401955_Saldo_Wirkleistung_Zaehler' AND         TIMESTAMP >= '2020-07-14 04:37:54' and TIMESTAMP < '2020-07-15 07:07:50'   ORDER BY TIMESTAMP;
+---------------------+----------------------+-------+-----------------------------------------------------+--------------------------------------------+---------+------+
| TIMESTAMP           | DEVICE               | TYPE  | EVENT                                               | READING                                    | VALUE   | UNIT |
+---------------------+----------------------+-------+-----------------------------------------------------+--------------------------------------------+---------+------+
| 2020-07-14 06:02:02 | StromZaehler_Heizung | SMAEM | SMAEM1901401955_Saldo_Wirkleistung_Zaehler: -2166.7 | SMAEM1901401955_Saldo_Wirkleistung_Zaehler | -2166.7 | kWh  |
| 2020-07-14 07:41:42 | StromZaehler_Heizung | SMAEM | SMAEM1901401955_Saldo_Wirkleistung_Zaehler: -2166.8 | SMAEM1901401955_Saldo_Wirkleistung_Zaehler | -2166.8 | kWh  |
| 2020-07-14 08:58:59 | StromZaehler_Heizung | SMAEM | SMAEM1901401955_Saldo_Wirkleistung_Zaehler: -2166.9 | SMAEM1901401955_Saldo_Wirkleistung_Zaehler | -2166.9 | kWh  |
snip...
| 2020-07-15 06:25:53 | StromZaehler_Heizung | SMAEM | SMAEM1901401955_Saldo_Wirkleistung_Zaehler: -2169.8 | SMAEM1901401955_Saldo_Wirkleistung_Zaehler | -2169.8 | kWh  |
+---------------------+----------------------+-------+-----------------------------------------------------+--------------------------------------------+---------+------+
32 rows in set (0.024 sec)

MySQL [fhem]>
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 16:23:47
Ich konnte mich hierdurch anmelden: sudo sqlite3 /opt/fhem/fhem.db

Aber das zeigt nichts:

Zitat von: ch.eick am 15 Juli 2020, 15:06:41

select * from history
where DEVICE  = SMA_Zaehler  AND READING  = Bezug_WirkP_Zaehler_Diff AND
        TIMESTAMP >= '2020-07-14 04:37:54' and TIMESTAMP < '2020-07-14 07:07:50'
  ORDER BY TIMESTAMP

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 16:52:52
Zitat von: dk3572 am 15 Juli 2020, 16:23:47
Ich konnte mich hierdurch anmelden: sudo sqlite3 /opt/fhem/fhem.db
Ich habe den vorherigen Post noch mal mit einem Beispiel editiert.
Eventuell ist der Syntax nicht identisch, weil Du sqlite und ich mysql verwende.
Gab es eine Fehlermeldung?
Hast Du den Device Namen und das Reading richtig angepasst? Da ist noch ein Fehler drin gewesen, die Namen muessen in ' ' gesetzt werden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 17:01:27
select * from history where DEVICE = 'SMA_Zaehler' AND READING = 'Bezug_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2020-07-14 04:37:54' and TIMESTAMP < '2020-07-15 07:07:50' ORDER BY TIMESTAMP;

Error: no such table: history
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 17:08:31
Zitat von: dk3572 am 15 Juli 2020, 17:01:27
Error: no such table: history
Da muss der Tabellenname der sqlite Datenbank rein.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 17:12:39
Zitat von: ch.eick am 15 Juli 2020, 17:08:31
Da muss der Tabellenname der sqlite Datenbank rein.

sorry, wo muss welcher Name rein?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 17:20:46
Zitat von: dk3572 am 15 Juli 2020, 17:12:39
sorry, wo muss welcher Name rein?

Bei "select * from history ..." , hier weiss ich nicht, wie Deine fhem Datenbank und Tabelle heisst.
Du muesstest Dich als fhem user an der Datenbank anmelden, damit Du auch die Tabelle im Zugriff hast.

So kann ich die Groesse der fhem Datenbank abfragen und die Tabellen anzeigen lassen.

MySQL [fhem]> SELECT table_schema "DB Name",
    ->        Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
    ->   FROM  information_schema.tables
    ->   GROUP BY table_schema;
+--------------------+---------------+
| DB Name            | DB Size in MB |
+--------------------+---------------+
| fhem               |        2816.7 |
| information_schema |           0.0 |
+--------------------+---------------+

MySQL [fhem]> SHOW TABLES;
+----------------+
| Tables_in_fhem |
+----------------+
| current        |
| history        |
+----------------+

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 17:34:14
leider komme ich nicht weiter.
Ich habe die SQLite Datenbank damals nach dieser Anleitung angelegt:

https://wiki.fhem.de/wiki/DbLog (https://wiki.fhem.de/wiki/DbLog)

und mich eben mit sudo sqlite3 /opt/fhem/fhem.db angemeldet.

Laut Wiki sollte das gehen: select * from history order by TIMESTAMP;
Funktioniert auch nicht.

Error: no such table: history

Habe auch ein .dbinfo ?DB? versucht.

Ergibt: unable to read database header



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 17:56:11
Zitat von: dk3572 am 15 Juli 2020, 17:34:14
und mich eben mit sudo sqlite3 /opt/fhem/fhem.db angemeldet.

Fuer mich sieht das so aus, dass Du nicht mit dem fhem user angemeldet bist und somit nicht die richtigen Tabellen sehen kannst.
sqlite kenne ich bisher noch nicht.

Waere /opt/fhem/fhem.db  den auch die richtige Datenbank, oder eventuell eine alte Testdatenbank?

EDIT: Das habe ich im Netz gefunden

There are a few steps to see the tables in an SQLite database:

List the tables in your database:
.tables

List how the table looks:
.schema tablename

Print the entire table:     <<<< Achtung, nicht mit der ganzen history !!!!
SELECT * FROM tablename;       <<<<< hier waere dann mein Vorschlag einzusetzen
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Juli 2020, 18:08:47
Ich weiß von füher dass die DB bei dk3572 falsch ist. Muss sein

/opt/fhem.db

nicht

/opt/fhem/fhem.db

Bin schon wiede weg ... ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 18:16:46
Zitat von: DS_Starter am 15 Juli 2020, 18:08:47
Ich weiß von füher dass die DB bei dk3572 falsch ist. Muss sein
Bin schon wiede weg ... ;)

:-) :-) lol, schoen, dass Du alle Installationen auswendig kennst. Kannst aber gerne noch bleiben.
Bin ich den gedanklich auf dem richtigen Weg???
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Juli 2020, 18:30:24
Naja, nur die eine wegen viel PM hin und her.  ;)

Würde gerne noch bleiben, bin aber grad bei SSCam am Support und weiterentwickeln ... vllt. später.


Ja, ich denke dein Weg aus #1246 klingt vielversprechend. Ihr könnt auch alle Statements in DbRep sqlCmd ausführen. Dann fallen solche Fehler wie in den letten Posts weg, da die Session aufgebaut ist.

LG, Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 18:30:35
Tsss.....wie blöd kann man sein  :-[ ???

Heiko hat natürlich recht.

2020-07-14 04:37:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:38:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:39:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:40:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:41:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:42:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0063|Bezug_WirkP_Zaehler_Diff|0.0063|
2020-07-14 04:43:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0250|Bezug_WirkP_Zaehler_Diff|0.0250|
2020-07-14 04:45:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:46:01|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:47:02|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:48:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:49:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:49:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:50:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:50:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:51:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0094|Bezug_WirkP_Zaehler_Diff|0.0094|
2020-07-14 04:52:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:52:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0141|Bezug_WirkP_Zaehler_Diff|0.0141|
2020-07-14 04:53:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0189|Bezug_WirkP_Zaehler_Diff|0.0189|
2020-07-14 04:54:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:54:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0237|Bezug_WirkP_Zaehler_Diff|0.0237|
2020-07-14 04:55:13|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0283|Bezug_WirkP_Zaehler_Diff|0.0283|
2020-07-14 04:56:14|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:56:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0330|Bezug_WirkP_Zaehler_Diff|0.0330|
2020-07-14 04:57:17|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0377|Bezug_WirkP_Zaehler_Diff|0.0377|
2020-07-14 04:58:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0424|Bezug_WirkP_Zaehler_Diff|0.0424|
2020-07-14 04:58:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:59:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:59:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0470|Bezug_WirkP_Zaehler_Diff|0.0470|
2020-07-14 05:00:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0518|Bezug_WirkP_Zaehler_Diff|0.0518|
2020-07-14 05:00:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 05:01:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0564|Bezug_WirkP_Zaehler_Diff|0.0564|
2020-07-14 05:02:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0046|Bezug_WirkP_Zaehler_Diff|0.0046|
2020-07-14 05:03:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0612|Bezug_WirkP_Zaehler_Diff|0.0612|
2020-07-14 05:03:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0659|Bezug_WirkP_Zaehler_Diff|0.0659|
2020-07-14 05:04:40|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0704|Bezug_WirkP_Zaehler_Diff|0.0704|
2020-07-14 05:05:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0054|Bezug_WirkP_Zaehler_Diff|0.0054|
2020-07-14 05:05:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0749|Bezug_WirkP_Zaehler_Diff|0.0749|
2020-07-14 05:06:31|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0793|Bezug_WirkP_Zaehler_Diff|0.0793|
2020-07-14 05:07:32|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0849|Bezug_WirkP_Zaehler_Diff|0.0849|
2020-07-14 05:07:32|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0057|Bezug_WirkP_Zaehler_Diff|0.0057|
2020-07-14 05:08:33|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0063|Bezug_WirkP_Zaehler_Diff|0.0063|
2020-07-14 05:08:34|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0914|Bezug_WirkP_Zaehler_Diff|0.0914|
2020-07-14 05:09:36|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0063|Bezug_WirkP_Zaehler_Diff|0.0063|
2020-07-14 05:09:45|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0976|Bezug_WirkP_Zaehler_Diff|0.0976|
2020-07-14 05:10:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1037|Bezug_WirkP_Zaehler_Diff|0.1037|
2020-07-14 05:11:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1095|Bezug_WirkP_Zaehler_Diff|0.1095|
2020-07-14 05:11:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0058|Bezug_WirkP_Zaehler_Diff|0.0058|
2020-07-14 05:12:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0049|Bezug_WirkP_Zaehler_Diff|0.0049|
2020-07-14 05:12:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1143|Bezug_WirkP_Zaehler_Diff|0.1143|
2020-07-14 05:13:42|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 05:13:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1190|Bezug_WirkP_Zaehler_Diff|0.1190|
2020-07-14 05:14:45|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1237|Bezug_WirkP_Zaehler_Diff|0.1237|
2020-07-14 05:15:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0050|Bezug_WirkP_Zaehler_Diff|0.0050|
2020-07-14 05:16:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1332|Bezug_WirkP_Zaehler_Diff|0.1332|
2020-07-14 05:17:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 05:17:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1382|Bezug_WirkP_Zaehler_Diff|0.1382|
2020-07-14 05:18:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0049|Bezug_WirkP_Zaehler_Diff|0.0049|
2020-07-14 05:19:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1429|Bezug_WirkP_Zaehler_Diff|0.1429|
2020-07-14 05:20:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1477|Bezug_WirkP_Zaehler_Diff|0.1477|
2020-07-14 05:20:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1524|Bezug_WirkP_Zaehler_Diff|0.1524|
2020-07-14 05:21:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1571|Bezug_WirkP_Zaehler_Diff|0.1571|
2020-07-14 05:22:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 05:23:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 05:23:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1618|Bezug_WirkP_Zaehler_Diff|0.1618|
2020-07-14 05:24:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1666|Bezug_WirkP_Zaehler_Diff|0.1666|
2020-07-14 05:25:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0074|Bezug_WirkP_Zaehler_Diff|0.0074|
2020-07-14 05:26:05|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1749|Bezug_WirkP_Zaehler_Diff|0.1749|
2020-07-14 05:27:07|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0038|Bezug_WirkP_Zaehler_Diff|0.0038|
2020-07-14 05:28:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1820|Bezug_WirkP_Zaehler_Diff|0.1820|
2020-07-14 05:28:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0034|Bezug_WirkP_Zaehler_Diff|0.0034|
2020-07-14 05:29:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1854|Bezug_WirkP_Zaehler_Diff|0.1854|
2020-07-14 05:29:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0034|Bezug_WirkP_Zaehler_Diff|0.0034|
2020-07-14 05:30:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1905|Bezug_WirkP_Zaehler_Diff|0.1905|
2020-07-14 05:31:13|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0051|Bezug_WirkP_Zaehler_Diff|0.0051|
2020-07-14 05:31:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.1955|Bezug_WirkP_Zaehler_Diff|0.1955|
2020-07-14 05:32:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2006|Bezug_WirkP_Zaehler_Diff|0.2006|
2020-07-14 05:33:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2056|Bezug_WirkP_Zaehler_Diff|0.2056|
2020-07-14 05:33:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0051|Bezug_WirkP_Zaehler_Diff|0.0051|
2020-07-14 05:34:18|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0050|Bezug_WirkP_Zaehler_Diff|0.0050|
2020-07-14 05:34:25|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2106|Bezug_WirkP_Zaehler_Diff|0.2106|
2020-07-14 05:35:27|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0056|Bezug_WirkP_Zaehler_Diff|0.0056|
2020-07-14 05:35:35|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2155|Bezug_WirkP_Zaehler_Diff|0.2155|
2020-07-14 05:36:37|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0062|Bezug_WirkP_Zaehler_Diff|0.0062|
2020-07-14 05:36:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2203|Bezug_WirkP_Zaehler_Diff|0.2203|
2020-07-14 05:37:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2251|Bezug_WirkP_Zaehler_Diff|0.2251|
2020-07-14 05:38:24|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0036|Bezug_WirkP_Zaehler_Diff|0.0036|
2020-07-14 05:39:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0032|Bezug_WirkP_Zaehler_Diff|0.0032|
2020-07-14 05:39:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2288|Bezug_WirkP_Zaehler_Diff|0.2288|
2020-07-14 05:39:28|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2320|Bezug_WirkP_Zaehler_Diff|0.2320|
2020-07-14 05:40:29|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2351|Bezug_WirkP_Zaehler_Diff|0.2351|
2020-07-14 05:41:30|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0031|Bezug_WirkP_Zaehler_Diff|0.0031|
2020-07-14 05:41:32|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2383|Bezug_WirkP_Zaehler_Diff|0.2383|
2020-07-14 05:42:33|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0031|Bezug_WirkP_Zaehler_Diff|0.0031|
2020-07-14 05:42:33|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2414|Bezug_WirkP_Zaehler_Diff|0.2414|
2020-07-14 05:43:36|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0034|Bezug_WirkP_Zaehler_Diff|0.0034|
2020-07-14 05:44:14|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2447|Bezug_WirkP_Zaehler_Diff|0.2447|
2020-07-14 05:45:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2484|Bezug_WirkP_Zaehler_Diff|0.2484|
2020-07-14 05:45:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2518|Bezug_WirkP_Zaehler_Diff|0.2518|
2020-07-14 05:46:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0040|Bezug_WirkP_Zaehler_Diff|0.0040|
2020-07-14 05:47:27|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2549|Bezug_WirkP_Zaehler_Diff|0.2549|
2020-07-14 05:48:29|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0057|Bezug_WirkP_Zaehler_Diff|0.0057|
2020-07-14 05:48:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2612|Bezug_WirkP_Zaehler_Diff|0.2612|
2020-07-14 05:49:43|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2637|Bezug_WirkP_Zaehler_Diff|0.2637|
2020-07-14 05:49:43|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0026|Bezug_WirkP_Zaehler_Diff|0.0026|
2020-07-14 05:50:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2669|Bezug_WirkP_Zaehler_Diff|0.2669|
2020-07-14 05:50:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0032|Bezug_WirkP_Zaehler_Diff|0.0032|
2020-07-14 05:51:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0028|Bezug_WirkP_Zaehler_Diff|0.0028|
2020-07-14 05:52:40|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2698|Bezug_WirkP_Zaehler_Diff|0.2698|
2020-07-14 05:52:45|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2721|Bezug_WirkP_Zaehler_Diff|0.2721|
2020-07-14 05:53:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2744|Bezug_WirkP_Zaehler_Diff|0.2744|
2020-07-14 05:54:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2767|Bezug_WirkP_Zaehler_Diff|0.2767|
2020-07-14 05:54:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0023|Bezug_WirkP_Zaehler_Diff|0.0023|
2020-07-14 05:55:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0022|Bezug_WirkP_Zaehler_Diff|0.0022|
2020-07-14 05:56:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2789|Bezug_WirkP_Zaehler_Diff|0.2789|
2020-07-14 05:57:02|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2811|Bezug_WirkP_Zaehler_Diff|0.2811|
2020-07-14 05:57:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2832|Bezug_WirkP_Zaehler_Diff|0.2832|
2020-07-14 05:58:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2854|Bezug_WirkP_Zaehler_Diff|0.2854|
2020-07-14 05:59:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0020|Bezug_WirkP_Zaehler_Diff|0.0020|
2020-07-14 05:59:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2875|Bezug_WirkP_Zaehler_Diff|0.2875|
2020-07-14 06:00:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2915|Bezug_WirkP_Zaehler_Diff|0.2915|
2020-07-14 06:00:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0042|Bezug_WirkP_Zaehler_Diff|0.0042|
2020-07-14 06:02:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0041|Bezug_WirkP_Zaehler_Diff|0.0041|
2020-07-14 06:02:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2957|Bezug_WirkP_Zaehler_Diff|0.2957|
2020-07-14 06:03:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.2983|Bezug_WirkP_Zaehler_Diff|0.2983|
2020-07-14 06:04:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3066|Bezug_WirkP_Zaehler_Diff|0.3066|
2020-07-14 06:04:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0086|Bezug_WirkP_Zaehler_Diff|0.0086|
2020-07-14 06:05:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0051|Bezug_WirkP_Zaehler_Diff|0.0051|
2020-07-14 06:06:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3164|Bezug_WirkP_Zaehler_Diff|0.3164|
2020-07-14 06:07:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0042|Bezug_WirkP_Zaehler_Diff|0.0042|
2020-07-14 06:07:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3207|Bezug_WirkP_Zaehler_Diff|0.3207|
2020-07-14 06:08:07|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3252|Bezug_WirkP_Zaehler_Diff|0.3252|
2020-07-14 06:09:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3327|Bezug_WirkP_Zaehler_Diff|0.3327|
2020-07-14 06:10:09|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0114|Bezug_WirkP_Zaehler_Diff|0.0114|
2020-07-14 06:10:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3442|Bezug_WirkP_Zaehler_Diff|0.3442|
2020-07-14 06:11:13|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0094|Bezug_WirkP_Zaehler_Diff|0.0094|
2020-07-14 06:12:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3533|Bezug_WirkP_Zaehler_Diff|0.3533|
2020-07-14 06:13:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0115|Bezug_WirkP_Zaehler_Diff|0.0115|
2020-07-14 06:13:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3650|Bezug_WirkP_Zaehler_Diff|0.3650|
2020-07-14 06:14:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3684|Bezug_WirkP_Zaehler_Diff|0.3684|
2020-07-14 06:15:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0034|Bezug_WirkP_Zaehler_Diff|0.0034|
2020-07-14 06:15:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3719|Bezug_WirkP_Zaehler_Diff|0.3719|
2020-07-14 06:16:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.3979|Bezug_WirkP_Zaehler_Diff|0.3979|
2020-07-14 06:17:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0262|Bezug_WirkP_Zaehler_Diff|0.0262|
2020-07-14 06:18:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4349|Bezug_WirkP_Zaehler_Diff|0.4349|
2020-07-14 06:19:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0252|Bezug_WirkP_Zaehler_Diff|0.0252|
2020-07-14 06:20:25|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0058|Bezug_WirkP_Zaehler_Diff|0.0058|
2020-07-14 06:21:27|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0053|Bezug_WirkP_Zaehler_Diff|0.0053|
2020-07-14 06:21:38|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4713|Bezug_WirkP_Zaehler_Diff|0.4713|
2020-07-14 06:22:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0051|Bezug_WirkP_Zaehler_Diff|0.0051|
2020-07-14 06:22:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4759|Bezug_WirkP_Zaehler_Diff|0.4759|
2020-07-14 06:23:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0045|Bezug_WirkP_Zaehler_Diff|0.0045|
2020-07-14 06:24:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4790|Bezug_WirkP_Zaehler_Diff|0.4790|
2020-07-14 06:24:34|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4821|Bezug_WirkP_Zaehler_Diff|0.4821|
2020-07-14 06:25:35|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0031|Bezug_WirkP_Zaehler_Diff|0.0031|
2020-07-14 06:26:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4851|Bezug_WirkP_Zaehler_Diff|0.4851|
2020-07-14 06:27:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 06:27:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4915|Bezug_WirkP_Zaehler_Diff|0.4915|
2020-07-14 06:28:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0027|Bezug_WirkP_Zaehler_Diff|0.0027|
2020-07-14 06:28:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4939|Bezug_WirkP_Zaehler_Diff|0.4939|
2020-07-14 06:30:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0028|Bezug_WirkP_Zaehler_Diff|0.0028|
2020-07-14 06:30:05|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.4960|Bezug_WirkP_Zaehler_Diff|0.4960|
2020-07-14 06:31:07|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0030|Bezug_WirkP_Zaehler_Diff|0.0030|
2020-07-14 06:31:43|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5002|Bezug_WirkP_Zaehler_Diff|0.5002|
2020-07-14 06:32:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0021|Bezug_WirkP_Zaehler_Diff|0.0021|
2020-07-14 06:32:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5023|Bezug_WirkP_Zaehler_Diff|0.5023|
2020-07-14 06:33:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5043|Bezug_WirkP_Zaehler_Diff|0.5043|
2020-07-14 06:33:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0021|Bezug_WirkP_Zaehler_Diff|0.0021|
2020-07-14 06:34:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0019|Bezug_WirkP_Zaehler_Diff|0.0019|
2020-07-14 06:35:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5080|Bezug_WirkP_Zaehler_Diff|0.5080|
2020-07-14 06:36:51|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5098|Bezug_WirkP_Zaehler_Diff|0.5098|
2020-07-14 06:36:51|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0018|Bezug_WirkP_Zaehler_Diff|0.0018|
2020-07-14 06:37:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5116|Bezug_WirkP_Zaehler_Diff|0.5116|
2020-07-14 06:37:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0019|Bezug_WirkP_Zaehler_Diff|0.0019|
2020-07-14 06:38:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5136|Bezug_WirkP_Zaehler_Diff|0.5136|
2020-07-14 06:38:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0019|Bezug_WirkP_Zaehler_Diff|0.0019|
2020-07-14 06:39:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0021|Bezug_WirkP_Zaehler_Diff|0.0021|
2020-07-14 06:40:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5177|Bezug_WirkP_Zaehler_Diff|0.5177|
2020-07-14 06:40:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0020|Bezug_WirkP_Zaehler_Diff|0.0020|
2020-07-14 06:41:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5195|Bezug_WirkP_Zaehler_Diff|0.5195|
2020-07-14 06:41:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0018|Bezug_WirkP_Zaehler_Diff|0.0018|
2020-07-14 06:42:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0016|Bezug_WirkP_Zaehler_Diff|0.0016|
2020-07-14 06:44:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5224|Bezug_WirkP_Zaehler_Diff|0.5224|
2020-07-14 06:44:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0014|Bezug_WirkP_Zaehler_Diff|0.0014|
2020-07-14 06:45:01|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5237|Bezug_WirkP_Zaehler_Diff|0.5237|
2020-07-14 06:46:02|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0014|Bezug_WirkP_Zaehler_Diff|0.0014|
2020-07-14 06:46:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5251|Bezug_WirkP_Zaehler_Diff|0.5251|
2020-07-14 06:47:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0009|Bezug_WirkP_Zaehler_Diff|0.0009|
2020-07-14 06:47:14|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5260|Bezug_WirkP_Zaehler_Diff|0.5260|
2020-07-14 06:48:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5267|Bezug_WirkP_Zaehler_Diff|0.5267|
2020-07-14 06:49:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0008|Bezug_WirkP_Zaehler_Diff|0.0008|
2020-07-14 06:49:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5275|Bezug_WirkP_Zaehler_Diff|0.5275|
2020-07-14 06:50:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5282|Bezug_WirkP_Zaehler_Diff|0.5282|
2020-07-14 06:51:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0006|Bezug_WirkP_Zaehler_Diff|0.0006|
2020-07-14 06:52:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0122|Bezug_WirkP_Zaehler_Diff|0.0122|
2020-07-14 06:53:18|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0141|Bezug_WirkP_Zaehler_Diff|0.0141|
2020-07-14 06:53:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5550|Bezug_WirkP_Zaehler_Diff|0.5550|
2020-07-14 06:54:17|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5567|Bezug_WirkP_Zaehler_Diff|0.5567|
2020-07-14 06:55:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5579|Bezug_WirkP_Zaehler_Diff|0.5579|
2020-07-14 06:55:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0012|Bezug_WirkP_Zaehler_Diff|0.0012|
2020-07-14 06:56:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5583|Bezug_WirkP_Zaehler_Diff|0.5583|
2020-07-14 06:57:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5583|Bezug_WirkP_Zaehler_Diff|0.5583|
2020-07-14 06:57:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 06:58:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0001|Bezug_WirkP_Zaehler_Diff|0.0001|
2020-07-14 06:58:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5583|Bezug_WirkP_Zaehler_Diff|0.5583|
2020-07-14 06:59:24|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.5584|Bezug_WirkP_Zaehler_Diff|0.5584|
2020-07-14 06:59:24|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0001|Bezug_WirkP_Zaehler_Diff|0.0001|
2020-07-14 07:00:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:03:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0002|Bezug_WirkP_Zaehler_Diff|0.0002|
2020-07-14 07:04:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:05:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:06:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:07:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:08:51|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:09:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:10:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:11:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:12:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:13:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:14:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:15:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:16:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:18:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:19:01|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:20:02|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:21:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:22:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:23:05|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:24:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:25:07|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:26:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:27:09|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:28:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:29:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:30:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:31:13|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:32:14|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:33:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:34:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:35:17|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:36:18|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:37:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:38:20|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:39:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:40:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:41:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:42:24|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:43:25|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:44:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:45:27|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:46:28|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:47:29|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:48:30|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:49:31|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:50:32|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:51:33|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:52:34|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:53:35|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:54:36|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:55:37|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:56:38|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:57:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0001|Bezug_WirkP_Zaehler_Diff|0.0001|
2020-07-14 07:58:40|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 07:59:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:00:42|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:01:43|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:02:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:03:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:04:45|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:05:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:06:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:07:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:08:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:09:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0013|Bezug_WirkP_Zaehler_Diff|0.0013|
2020-07-14 08:10:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0014|Bezug_WirkP_Zaehler_Diff|0.0014|
2020-07-14 08:11:51|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0006|Bezug_WirkP_Zaehler_Diff|0.0006|
2020-07-14 08:12:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:13:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:14:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:15:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:16:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:17:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:18:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:19:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:21:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:22:01|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:23:02|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:24:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:25:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:26:05|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:27:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:28:07|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:29:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:30:09|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:31:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:32:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:33:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:34:13|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:35:14|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:36:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:37:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:38:17|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:39:18|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:40:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:41:20|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:42:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:43:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:44:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:45:24|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:46:25|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:47:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:48:27|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:49:28|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:50:29|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:51:30|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:52:31|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:53:32|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:54:33|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:55:34|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:56:35|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:57:36|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:58:37|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 08:59:38|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:00:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:01:40|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:02:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:03:42|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:04:43|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:05:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:06:45|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:07:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:08:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:09:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:10:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:11:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:12:51|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:13:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:14:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:15:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:16:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:17:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:18:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:19:57|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:20:58|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:21:59|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:23:00|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:24:01|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:25:02|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:26:03|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:27:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:28:05|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:29:06|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:30:07|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:31:08|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:32:09|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:33:10|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:34:11|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:35:12|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:36:13|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:37:14|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:38:15|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:39:16|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:40:17|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:41:18|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:42:19|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:43:20|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:44:21|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:45:22|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:46:23|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:47:24|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:48:25|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:49:26|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:50:27|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:51:28|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:52:29|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:53:30|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:54:31|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:55:32|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:56:33|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:57:34|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:58:35|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 09:59:36|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:00:37|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:01:38|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:02:39|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:03:40|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:04:41|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:05:42|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:06:43|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:07:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:08:44|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:09:45|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:10:46|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:11:47|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:12:48|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:13:49|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:14:50|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:15:51|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:16:52|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:17:53|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
2020-07-14 10:18:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0|Bezug_WirkP_Zaehler_Diff|0|
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 18:34:07
Boa, Du erschlaegst uns, mach bitte code tags um das Listing ;-)
Wenn das Listing zu lang ist, wird es unten abgeschnitte, also auch einkuerzen!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 18:38:42
Zitat von: ch.eick am 15 Juli 2020, 18:34:07
Boa, Du erschlaegst uns, mach bitte code tags um das Listing ;-)
Wenn das Listing zu lang ist, wird es unten abgeschnitte, also auch einkuerzen!

code tags hatte ich gemacht, in der Vorschau war auch noch alles gut, die Liste ist zu lang.
Gibt es einen Trick?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 18:48:47
- Also, ich wuerde im SMAEM Device mal event-on-update umsetzen und nur die gewuenschten Readings angeben.
- Hier kommt wohl wirklich ein Event in sehr kurzer Folge. Der Timestamp geht ja nur bis in den Sekundenbereich und es kann ja trotzdem noch Millisekunden spaeter ein weiterer Eintrag kommen.
  Das muesstest Du im SMAEM Thread klaeren lassen. Eventuell hilft mein Kommentar von weiter vorne.
  Mit event-on-change-reading sollte dieser Eintrag aber trotzdem nicht kommen, das waere aber nicht die Ursache.

2020-07-14 04:38:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:39:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:40:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
snip...
2020-07-14 04:49:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:49:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|


Bitte pruef auch nochmal, ob Du wirklich den Intervall auf 60 Sek stehen hast. Das passt nicht wirklich immer.
Im fhem event monitor kannst Du das dann auch mal beobachten.

Dann solltest Du auch mal ueberlegen, ob Du diese Eintraege wirklich loggen moechtest??? Laut Doku wird das wohl fuer ein wiederaufsetzen nach Stromausfall benoetigt, Aber dann eher im Device und nicht in der Datenbank.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 18:49:59
Zitat von: dk3572 am 15 Juli 2020, 18:38:42
Gibt es einen Trick?

Das Listing kuerzen und am Ende \[/code\] wieder hinschreiben
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 19:11:48
Zitat von: ch.eick am 15 Juli 2020, 18:48:47
- Also, ich wuerde im SMAEM Device mal event-on-update umsetzen und nur die gewuenschten Readings angeben.
- Hier kommt wohl wirklich ein Event in sehr kurzer Folge. Der Timestamp geht ja nur bis in den Sekundenbereich und es kann ja trotzdem noch Millisekunden spaeter ein weiterer Eintrag kommen.
  Das muesstest Du im SMAEM Thread klaeren lassen. Eventuell hilft mein Kommentar von weiter vorne.
  Mit event-on-change-reading sollte dieser Eintrag aber trotzdem nicht kommen, das waere aber nicht die Ursache.

2020-07-14 04:38:54|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:39:55|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
2020-07-14 04:40:56|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0048|Bezug_WirkP_Zaehler_Diff|0.0048|
snip...
2020-07-14 04:49:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
2020-07-14 04:49:04|SMA_Zaehler|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|


Bitte pruef auch nochmal, ob Du wirklich den Intervall auf 60 Sek stehen hast. Das passt nicht wirklich immer.
Im fhem event monitor kannst Du das dann auch mal beobachten.

Dann solltest Du auch mal ueberlegen, ob Du diese Eintraege wirklich loggen moechtest??? Laut Doku wird das wohl fuer ein wiederaufsetzen nach Stromausfall benoetigt, Aber dann eher im Device und nicht in der Datenbank.

wie bereits erwähnt hatte ich mich bei der Einrichtung an Heiko´s wiki gehalten.
Dort ist der Intervall auf 60.
event-on-update und nur die gewuenschten Readings sind eingestellt.

FD         31
   FUUID      5eb01954-f33f-cd72-1fef-9e8d3e186772924e
   FVERSION   77_SMAEM.pm:v4.2.0-s21706/2020-04-16
   GRIDIN_SUM_3006949425 1827.5633
   GRIDOUT_SUM_3006949425 336.8228
   INTERVAL   60
   LASTUPDATE_3006949425 15.07.2020 / 19:08:28
   MODEL      HM 2.0 >= 2.03.4.R
   NAME       SMA_Zaehler
   NR         385
   STATE      <font color="Yellow"><b>Einspeisung: 317.9 W </b></font>
   TYPE       SMAEM
   HELPER:
     ALLSERIALS 3006949425
     FAULTEDCYCLES 0
     LASTUPDATE_3006949425 1594832908.89565
     PACKAGE    main
     STARTTIME  1594793027.0873
     VERSION    4.2.0
   Helper:
     DBLOG:
       Bezug_WirkP_Kosten_Diff:
         logdb:
           TIME       1594832908.91522
           VALUE      0.0000
       Bezug_WirkP_Zaehler_Diff:
         logdb:
           TIME       1594832908.91522
           VALUE      0
       Einspeisung_WirkP_Verguet_Diff:
         logdb:
           TIME       1594832908.91522
           VALUE      0.0631
       Einspeisung_WirkP_Zaehler_Diff:
         logdb:
           TIME       1594832908.91522
           VALUE      0.0055
   READINGS:
     2020-07-15 19:08:28   Bezug_Blindleistung 0.0
     2020-07-15 19:08:28   Bezug_Blindleistung_Zaehler 13.6
     2020-07-15 19:08:28   Bezug_Scheinleistung 0.0
     2020-07-15 19:08:28   Bezug_Scheinleistung_Zaehler 578.6
     2020-07-15 19:08:28   Bezug_WirkP_Kosten_Diff 0.0000
     2020-07-15 19:08:28   Bezug_WirkP_Zaehler_Diff 0
     2020-07-15 19:08:28   Bezug_Wirkleistung 0.0
     2020-07-15 19:08:28   Bezug_Wirkleistung_Zaehler 336.8228
     2020-07-15 19:08:28   CosPhi          0.622
     2020-07-15 19:08:28   Einspeisung_Blindleistung 400.6
     2020-07-15 19:08:28   Einspeisung_Blindleistung_Zaehler 586.4
     2020-07-15 19:08:28   Einspeisung_Scheinleistung 511.4
     2020-07-15 19:08:28   Einspeisung_Scheinleistung_Zaehler 1871.6
     2020-07-15 19:08:28   Einspeisung_WirkP_Verguet_Diff 0.0631
     2020-07-15 19:08:28   Einspeisung_WirkP_Zaehler_Diff 0.0055
     2020-07-15 19:08:28   Einspeisung_Wirkleistung 317.9
     2020-07-15 19:08:28   Einspeisung_Wirkleistung_Zaehler 1827.5633
     2020-07-15 19:08:28   GridFreq        49.968
     2020-07-15 19:08:28   L1_Bezug_Blindleistung 0.0
     2020-07-15 19:08:28   L1_Bezug_Blindleistung_Zaehler 6.3
     2020-07-15 19:08:28   L1_Bezug_Scheinleistung 0.0
     2020-07-15 19:08:28   L1_Bezug_Scheinleistung_Zaehler 143.6
     2020-07-15 19:08:28   L1_Bezug_Wirkleistung 0.0
     2020-07-15 19:08:28   L1_Bezug_Wirkleistung_Zaehler 92.3
     2020-07-15 19:08:28   L1_CosPhi       0.972
     2020-07-15 19:08:28   L1_Einspeisung_Blindleistung 36.3
     2020-07-15 19:08:28   L1_Einspeisung_Blindleistung_Zaehler 93.1
     2020-07-15 19:08:28   L1_Einspeisung_Scheinleistung 153.4
     2020-07-15 19:08:28   L1_Einspeisung_Scheinleistung_Zaehler 674.1
     2020-07-15 19:08:28   L1_Einspeisung_Wirkleistung 149.0
     2020-07-15 19:08:28   L1_Einspeisung_Wirkleistung_Zaehler 670.4
     2020-07-15 19:08:28   L1_Saldo_Wirkleistung 149.0
     2020-07-15 19:08:28   L1_Saldo_Wirkleistung_Zaehler 578.1
     2020-07-15 19:08:28   L1_Spannung     233.7
     2020-07-15 19:08:28   L1_Strom        0.68
     2020-07-15 19:08:28   L2_Bezug_Blindleistung 0.0
     2020-07-15 19:08:28   L2_Bezug_Blindleistung_Zaehler 18.8
     2020-07-15 19:08:28   L2_Bezug_Scheinleistung 0.0
     2020-07-15 19:08:28   L2_Bezug_Scheinleistung_Zaehler 173.3
     2020-07-15 19:08:28   L2_Bezug_Wirkleistung 0.0
     2020-07-15 19:08:28   L2_Bezug_Wirkleistung_Zaehler 80.2
     2020-07-15 19:08:28   L2_CosPhi       0.736
     2020-07-15 19:08:28   L2_Einspeisung_Blindleistung 144.9
     2020-07-15 19:08:28   L2_Einspeisung_Blindleistung_Zaehler 195.0
     2020-07-15 19:08:28   L2_Einspeisung_Scheinleistung 214.0
     2020-07-15 19:08:28   L2_Einspeisung_Scheinleistung_Zaehler 680.2
     2020-07-15 19:08:28   L2_Einspeisung_Wirkleistung 157.5
     2020-07-15 19:08:28   L2_Einspeisung_Wirkleistung_Zaehler 656.1
     2020-07-15 19:08:28   L2_Saldo_Wirkleistung 157.5
     2020-07-15 19:08:28   L2_Saldo_Wirkleistung_Zaehler 575.9
     2020-07-15 19:08:28   L2_Spannung     233.9
     2020-07-15 19:08:28   L2_Strom        0.94
     2020-07-15 19:08:28   L3_Bezug_Blindleistung 0.0
     2020-07-15 19:08:28   L3_Bezug_Blindleistung_Zaehler 10.8
     2020-07-15 19:08:28   L3_Bezug_Scheinleistung 0.0
     2020-07-15 19:08:28   L3_Bezug_Scheinleistung_Zaehler 331.8
     2020-07-15 19:08:28   L3_Bezug_Wirkleistung 0.0
     2020-07-15 19:08:28   L3_Bezug_Wirkleistung_Zaehler 213.0
     2020-07-15 19:08:28   L3_CosPhi       0.052
     2020-07-15 19:08:28   L3_Einspeisung_Blindleistung 219.4
     2020-07-15 19:08:28   L3_Einspeisung_Blindleistung_Zaehler 320.5
     2020-07-15 19:08:28   L3_Einspeisung_Scheinleistung 219.7
     2020-07-15 19:08:28   L3_Einspeisung_Scheinleistung_Zaehler 582.4
     2020-07-15 19:08:28   L3_Einspeisung_Wirkleistung 11.4
     2020-07-15 19:08:28   L3_Einspeisung_Wirkleistung_Zaehler 549.8
     2020-07-15 19:08:28   L3_Saldo_Wirkleistung 11.4
     2020-07-15 19:08:28   L3_Saldo_Wirkleistung_Zaehler 336.7
     2020-07-15 19:08:28   L3_Spannung     232.8
     2020-07-15 19:08:28   L3_Strom        1.27
     2020-07-15 19:08:28   OBISnewItems    none
     2020-07-15 19:08:28   SUSyID          372
     2020-07-15 19:08:28   Saldo_Wirkleistung 317.9
     2020-07-15 19:08:28   Saldo_Wirkleistung_Zaehler 1490.7
     2020-07-15 19:08:28   SerialNumber    3006949425
     2020-07-15 19:08:28   SoftwareVersion 2.03.05.R
     2020-07-15 19:08:28   state           317.9
Attributes:
   DbLogExclude .*
   DbLogInclude Bezug_WirkP_Zaehler_Diff,Bezug_WirkP_Kosten_Diff,Einspeisung_WirkP_Zaehler_Diff,Einspeisung_WirkP_Verguet_Diff
   alias      SMA Zähler
   disableSernoInReading 1
   event-min-interval state:120
   event-on-update-reading state,Saldo_Wirkleistung,Bezug_WirkP_Zaehler_Diff,Einspeisung_WirkP_Zaehler_Diff,Einspeisung_WirkP_Verguet_Diff,Bezug_WirkP_Kosten_Diff,Bezug_Wirkleistung,Einspeisung_Wirkleistung,Bezug_Wirkleistung_Zaehler,Einspeisung_Wirkleistung_Zaehler
   feedinPrice 11.47
   icon       measure_power
   interval   60
   powerCost  26.67
   room       Photovoltaik
   stateFormat { my $Wert = ReadingsNum($name,"state",0);
    my $string  = ' ';
if ($Wert > 0) {
    $string  = sprintf("Einspeisung: %.1f W ",$Wert);
}
elsif ($Wert <= 0) {
    $string  = sprintf("Bezug: %.1f W ",$Wert);
}
  if ($Wert > 1 && $Wert < 2000) {
    return '<font color="Yellow"><b>' . $string . '</b></font>'}
  elsif ($Wert >= 2000 && $Wert < 4000 ) {
    return '<font color="Cyan"> <b>' . $string . '</b></font>'}
  elsif ($Wert >= 4000) {
    return '<font color="Lime"><b>' . $string . '</b></font>'}
  elsif ($Wert <= 0) {
    return '<font color="White"><b>' . $string . '</b></font>'}
  else {return $string }
}
   timeout    90
   verbose    3


Wie soll das ganze dann funktionieren wenn ich das nicht mehr logge?

Übrigens danke für deine Unterstützung bis hierher  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 19:48:21
Zitat von: dk3572 am 15 Juli 2020, 19:11:48
wie bereits erwähnt hatte ich mich bei der Einrichtung an Heiko´s wiki gehalten.
Dort ist der Intervall auf 60.
event-on-update und nur die gewuenschten Readings sind eingestellt.


Attributes:
   DbLogInclude Bezug_WirkP_Zaehler_Diff,Bezug_WirkP_Kosten_Diff,Einspeisung_WirkP_Zaehler_Diff,Einspeisung_WirkP_Verguet_Diff



Okay, dann muesstest Du damit jetzt in Heiko's Thread wechseln, um die nicht gewuenschten Events zu eliminieren.

Zum Entfernen der ueberschuessigen Log Eintraege hatte ich ja bereits meine Idee geposted. Ansonsten faellt mir da jetzt auch nichts mehr ein.
Die Schritte im einzelnen:

- aggregieren auf Minuten Basis
- Es werden neue Eintraege geschrieben z.B. 2020-06-30_23-59-00__SMA_Zaehler__Bezug_WirkP_Zaehler__MAX__2020-06-.......
- Loeschen aller alten Eintraege in dem Zeitraum von timestamp_begin bis timestamp_end
- Umbenennen der neuen Eintraege auf den reading Namen der urspruenglichen readings


Bei mir ist der SMAEM nur ein teurer Unterzaehler. Alles andere habe ich auf Basis von Kostal mit Modbus/TCP , alle Werte werden bereits vom WR geliefert.

Einen schoenen Abend noch
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 19:58:23
Zitat von: ch.eick am 15 Juli 2020, 19:48:21
Zum entfernen der ueberschuessigen Log Eintraege hatte ich ja bereits meine Idee geposted. Ansonsten faellt mir da jetzt auch nichts mehr ein.

Die Idee hast du vermutlich geposted, aber mir als Laie nicht verraten wie ich es anstelle  ;)

Trotzdem Vielen Dank und Gruß
Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Juli 2020, 20:09:37
Zitat von: dk3572 am 15 Juli 2020, 19:58:23
Die Idee hast du vermutlich geposted, aber mir als Laie nicht verraten wie ich es anstelle  ;)

Im DBRep kannst Du mit maxValue aggregieren, jedoch momentan nur bis runter zur Stundenbasis.   <<< hier koennte Heiko ja eventuell auch noch Minuten einbauen ;-) , wenn er wieder Zeit hat.
Das erzeugt neue Eintraege, lies dazu nochmal die Doko vom DBRep
Wenn die Eintraege dann da sind koenntest Du mit dem SQL Terminal die ungewuenschten Eintraege loeschen und
im Anschluss auch im SQL Terminal die neuen Eintraege umbenennen, sodass die alten Namen wieder da sind.

Ich habe z.B. auch Werte, die ueber den Monat immer mehr ansteigen. Bei denen mache ich dann auch solch einen Lauf und lasse nur z.B. den hoechsten wert des Tages, der Woche und des Monats stehen.
Alles andere wird dann aus der DB entfernt, weil niemand sich mehr fuer die Minuten werte interessiert. Das ist ein normaler Prozess, um die Datenbank schlank zu halten.
Innerhalb des aktuellen Monats steht natuerlich alles noch zur Verfuegung.

Ich habe auch schon einige Beispiel SQL Statements ins Wiki gestellt, das kann man als Muster fuer eigene Ideen verwenden.
Die Konsolidierung, die ich gerade beschrieben habe ist jedoch noch nicht fertig, das dauert noch etwas.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 15 Juli 2020, 20:13:59
ok, ich lese mich ein und warte (hoffe) auf Heiko  ;)

Schönen Abend noch, tschau.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Juli 2020, 00:09:40
Hallo zusammen,

ich habe in einer neuen DbRep-Version den Lösungsvorschlag von Christian aus dem Beitrag #1246 umgesetzt
und eine aggregation "minute" eingebaut.

Damit sollte das Bereinigungsproblem von dk3572 recht elegant lösbar sein.

@Dieter, folgende Schritte sollten deine Aufgabe lösen:

1. Sicherung der DB anlegen !
2. die Auswertungszeitgrenzen mit den bekannten Attributen festlegen
3. device / reading mit den bekannten Attributen festlegen
4. die Datensätze des Zeitraums mit set <> exportToFile </Pfad/Datei> exportieren (kann einfach wieder importiert werden)
5. Attr aggregation = minute einstellen
6. set <> maxValue deleteOther  (es wird der Maximalwert jeder Minute ermittelt und die anderen Werte gelöscht)

   oder alternativ (je nachdem was du löschen / behalten willst)
   
6. set <> minValue deleteOther  (es wird der Minimalwert jeder Minute ermittelt und die anderen Werte gelöscht)

Du solltest vorher natürlich mal ein "set <> ... display" ausführen und schauen ob die erscheinenden Werte die Erwartung widerspiegeln.
Sofern vorhanden sollte das Verfahren auch mal mit einer Testdatenbank erprobt werden (bei mir hat es einwandfrei funktioniert).
Sollte etwas schiefgehen, kann man mit delEntries alles in dem Zeitraum löschen und die im Punkt 4 exportierten Datensätze schnell wieder importieren.
Im worst case Fall muß die Datensicherung wieder eingespielt werden.

Falls du Schwierigkeiten haben solltest, mache am Besten einen neuen Thread auf.

Download der neuen Version aus meinem contrib und restart:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 23 Juli 2020, 09:42:25
Zitat von: DS_Starter am 23 Juli 2020, 00:09:40
ich habe in einer neuen DbRep-Version den Lösungsvorschlag von Christian aus dem Beitrag #1246 umgesetzt
und eine aggregation "minute" eingebaut.

Damit sollte das Bereinigungsproblem von dk3572 recht elegant lösbar sein.
Und ich danke Heiko mal wieder fuer die Anerkennung :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 Juli 2020, 23:10:18
Hab die neue Version eingecheckt und ist morgen im Regelupdate.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 August 2020, 09:24:11
Hallo Heiko,

ich habe nach langer Zeit mal wieder ein Update von DBRep gemacht.
ich benutze die Average Funktion um mir täglich einen Durchnittswert zu Berechnen:
Internals:
   COMMAND    attr DBReporting_LaCrosse device FBDECT_fbahahttp_08761_0044555;
attr DBReporting_LaCrosse reading power;
attr DBReporting_LaCrosse aggregation day;
attr DBReporting_LaCrosse timestamp_begin previous_day_begin;
attr DBReporting_LaCrosse timestamp_end previous_day_end;
set DBReporting_LaCrosse averageValue writeToDB

   DEF        *00:06:00 attr DBReporting_LaCrosse device FBDECT_fbahahttp_08761_0044555;
attr DBReporting_LaCrosse reading power;
attr DBReporting_LaCrosse aggregation day;
attr DBReporting_LaCrosse timestamp_begin previous_day_begin;
attr DBReporting_LaCrosse timestamp_end previous_day_end;
set DBReporting_LaCrosse averageValue writeToDB

   FUUID      xxxxxx
   NAME       at.Energy.Tag.Kuehlschrank
   NR         528
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 00:06:00
   TIMESPEC   00:06:00
   TRIGGERTIME 1597788360
   TRIGGERTIME_FMT 2020-08-19 00:06:00
   TYPE       at
   .attraggr:
   .attrminint:
   READINGS:
     2020-08-18 00:06:00   state           Next: 00:06:00
Attributes:
   DbLogExclude .*
   room       Energy


seit dem Update bekomme ich jetzt täglich zwei Werte:
"2020-08-17 00:00:01" "FBDECT_fbahahttp_08761_0044555" "FBDECT" "calculated" "avgam_day_power" "40.1753" \N
"2020-08-17 23:59:59" "FBDECT_fbahahttp_08761_0044555" "FBDECT" "calculated" "avgam_day_power" "40.1753" \N


wobei der 00:00:01 Wert auch am heutigen Tag (also einen Tag später) erzeugt wird.
Hab ich etwas übersehen oder falsch gemacht?

Gruß
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 August 2020, 09:39:45
Moin Thomas,

es gab einige Seiten zuvor diverse Wünsche von Usern den Funktionsumfang zu erweitern.
Es gibt für averageValue (andere auch ) erweiterte Aufrufoptionen.
Wahrscheinlich musst du bei dir die Auswertung jetzt mit writeToDBSingle aufrufen.
Schau dir mal die comRef für averageValue an. Dort siehst du was hinzugekommen ist.
Die Erweiterungen sind aber wirklich schon einige Zeit her.  ;)

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 August 2020, 09:49:00
Danke für die Info.
Du hast Recht, ich hab schon ewig (>1 Jahr) kein Update gemacht.
Ich schaue mir das mal an...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 September 2020, 11:10:31
Hallo zusammen,

kann ich auch ein SQL SELECT direkt aus der myUtils gegen die Datenbank absetzen ohne über ein DbRep Device zu gehen, damit das Ergebnis direkt verfügbar ist?

z.B.

SELECT VALUE FROM history WHERE DEVICE='PV_Anlage_1' and READING='Solar_Calculation_fc1'  and TIMESTAMP = '2020-09-03 12:00:00';
4421


Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2020, 11:43:52
Moin Christian,

momentan nicht, zumindest nicht ohne selbst einiges zu programmieren.
Ich könnte aber ein sqlBlockingCmd implementieren mit dem man das machen könnte.


Eine blockierende Variante der SQL-Befehlsausführung kann mit "get <> dbValue" ausgeführt werden.

FHEM würde blockieren falls die DB nicht antwortet. Deswegen passiert in DbRep ansonsten alles asynchron bis auf wenige, benannte Ausnahmen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 September 2020, 11:48:14
Zitat von: DS_Starter am 03 September 2020, 11:43:52
momentan nicht, zumindest nicht ohne selbst einiges zu programmieren.
Ich könnte aber ein sqlBlockingCmd implementieren mit dem man das machen könnte.

Wie der Name schon sagt würde FHEM blockieren falls die DB nicht antwortet. Deswegen passiert in DbRep alles asynchron bis auf wenige, benannte Ausnahmen.
Hmm, dann kann ich auch mit einem sqlCmd arbeiten und muss halt das reading abwarten.
Ich denke nochmal drüber nach :-)

EDIT: Das sollte die Lösung sein

DbReadingsVal("<name>","<device:reading>","<timestamp>","<default>")
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2020, 12:28:12
Ja, DbReadingsVal hatte ich bereits implementiert. Ist auch blockierend !
Das gibt es als FHEM Kommando und auch als aufrufbare Funktion aus einem Script heraus. Das letztere wäre dann wohl die Möglichkeit deiner Wahl.

Ist aber kein freies SQL Kommando welches man gestalten kann wie man will. Dafür "get <> dbValue" verwenden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 September 2020, 12:47:11
Zitat von: DS_Starter am 03 September 2020, 12:28:12
Ja, DbReadingsVal hatte ich bereits implementiert. Ist auch blockierend !
Das gibt es als FHEM Kommando und auch als aufrufbare Funktion aus einem Script heraus. Das letztere wäre dann wohl die Möglichkeit deiner Wahl.

Ist aber kein freies SQL Kommando welches man gestalten kann wie man will.
Das pass jedoch zu dem was ich gerade benötige.


dbReadingsVal LogDBRep_select_PV_Forecast PV_Anlage_1:Solar_Calculation_fc1 2020-09-03_12:00:00 0
4421


Zu dem "blockierend", es wäre natürlich toll, wenn es da eine Timeout gerade in den beiden Funktionen geben würde.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2020, 12:54:45
Zitat
Zu dem "blockierend", es wäre natürlich toll, wenn es da eine Timeout gerade in den beiden Funktionen geben würde.

Ich denk mal drüber nach.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2020, 23:53:18
Hallo Christian,

in meinem contrib liegt eine Version zum Test. Es werden die blockierenden Funktionen Perl Funktion DbReadingsVal als auch die FHEM Kommandos dbReadingsVal bzw. "get <> dbValue" mit einem Timeout überwacht.
Der Timeout kann wie üblich mit dem Attribut "timeout" eingestellt werden.

Übrigens hatte ich bereits mit dem "get <> dbValue" eine Variante eingebaut mit der man SQL Befehle synchron (also blockierend) ausgeführt werden können.
Ich muss also meine Aussage weiter oben revidieren... alles schon vorhanden.  :D

Teste mal bitte die Version.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 04 September 2020, 10:57:42
Zitat von: DS_Starter am 03 September 2020, 23:53:18
Der Timeout kann wie üblich mit dem Attribut "timeout" eingestellt werden.

Übrigens hatte ich bereits mit dem "get <> dbValue" eine Variante eingebaut mit der man SQL Befehle synchron (also blockierend) ausgeführt werden können.
Ich muss also meine Aussage weiter oben revidieren... alles schon vorhanden.  :D


# MySQL läuft
{my $timestamp = POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time));;DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",$timestamp,0);;}
3753

# MySQL gestoppt
{my $timestamp = POSIX::strftime("%Y-%m-%d 12:00:00",localtime(time));;DbReadingsVal("LogDBRep_select_PV_Forecast","PV_Anlage_1:Solar_Calculation_fc0",$timestamp,0);;}
DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Can't connect to MySQL server on '192.168.178.40' (115) at ./FHEM/93_DbRep.pm line 11534.


Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2020, 11:04:59
Moin Christian,

jo, passt so. Was wolltest du jetzt sagen ?  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 04 September 2020, 11:05:57
Zitat von: DS_Starter am 04 September 2020, 11:04:59
jo, passt so. Was wolltest du jetzt sagen ?  :)
Du bist der Beste ;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2020, 11:10:34
:)

Aber du müsstest mal zum Test timeout auf z.B. 5 Sekunden stellen und eine länger laufende SQL mit  dbReadingsVal absetzen. Dann muß/sollte der Timeout zuschlagen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 04 September 2020, 11:13:16
Zitat von: DS_Starter am 04 September 2020, 11:10:34
Aber du müsstest mal zum Test timeout auf z.B. 5 Sekunden stellen und eine länger laufende SQL mit  dbReadingsVal absetzen. Dann muß/sollte der Timeout zuschlagen.
Ich laufe so optimiert, da habe ich keine Langläufer :-) Ich behalte es im Kopf und teste es, wenn ich mal was habe, was über 1 Sekunde läuft.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2020, 11:17:31
ZitatIch laufe so optimiert, da habe ich keine Langläufer :-)
Das ist natürlich dramatisch  8)

Du könntest es auch mit einem "get <> dbValue" und einem aufwändigerem Select testen.

BTW... den getter dbValue halte ich von der Namensgebung her für etwas unglücklich. Ich würde es gern in sqlBlockingCmd  sqlCmdBlocking umbenennen.
Das trifft die Verwendung besser. Gibt es Gegenstimmen / Zustimmung ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2020, 14:48:05
Nun habe ich die neue Version finalisiert.
Der getter dbValue ist umbenannt in sqCmdBlocking. Um die Kompatibilität zu gewährleisten, kann man "dbValue" vorerst in Scripten weiterhin verwenden.
Im Log gibt es dann eine Meldung:


2020.09.04 14:29:50.666 1: Rep.CPU - WARNING - the command "dbValue" is deprecated and will be removed soon. Please use "sqlCmdBlocking" instead.


Die ComRef ist auch angepasst und der get-Bereich gleich bereinigt und aufgewertet. Es wird die Online-Hilfe für die getter  im FHEMWEB mit angezeigt.

Bitte nochmal testen wer mag.
Wenn mir / euch im Laufe des Tages nichts mehr auffällt, checke ich die neue Version ein. Sie ist dann morgen früh wie gewohnt im Update enthalten.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 Oktober 2020, 11:49:27
EDIT: Ich habe schon mal ein SELECT geschrieben, dass alle zu löschenden Einträge ausliest.

Moin Heiko,
ich suche gerade eine Möglichkeit zB "reduceLog" um den letzten Eintrag eines Zeitraums zu behalten

Commandref von reduceLog, aber Bezug auf "(den ersten) pro Stunde"

set <name> reduceLog <no>[:<nn>] [average[=day]] [exclude=device1:reading1,device2:reading2,...]

Reduziert historische Datensätze, die älter sind als <no> Tage und (optional) neuer sind als <nn> Tage auf einen Eintrag (den ersten) pro Stunde je Device & Reading.


Hierbei geht es mir um einen Zähler, der den ganzen Tag ansteigt. Um das aufzuräumen können später alle Einträge bis auf den letzten gelöscht werden.
Die nächsten Schritte wären dann beim Monatszähler die jeweiligen Wochen zu behalten und
beim Jahreszähler die jeweiligen Monate.


MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_API' And READING='Statistic_GridFeedInDay' AND TIMESTAMP LIKE '2020-10-21%' order BY TIMESTAMP DESC;
+---------------------+-----------------+-------------------------+-------+
| TIMESTAMP           | DEVICE          | READING                 | VALUE |
+---------------------+-----------------+-------------------------+-------+
| 2020-10-21 23:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
| 2020-10-21 22:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
| 2020-10-21 21:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
snip ...
| 2020-10-21 02:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 0.00  |
| 2020-10-21 01:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 0.00  |
| 2020-10-21 00:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 0.00  |
+---------------------+-----------------+-------------------------+-------+
24 rows in set (2.623 sec)

## Und den möchte ich behalten
MySQL [fhem]> SELECT TIMESTAMP,DEVICE,READING,VALUE FROM history WHERE DEVICE='PV_Anlage_1_API' And READING='Statistic_GridFeedInDay' AND TIMESTAMP LIKE '2020-10-21%' order BY TIMESTAMP DESC limit 1;
+---------------------+-----------------+-------------------------+-------+
| TIMESTAMP           | DEVICE          | READING                 | VALUE |
+---------------------+-----------------+-------------------------+-------+
| 2020-10-21 23:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
+---------------------+-----------------+-------------------------+-------+
1 row in set (0.003 sec)


wenn das mit reduceLog nicht klappt, müsste ich wieder special SQLs erstellen und das will ja keiner ;-)


SET @device = 'PV_Anlage_1_API'; SET @reading = 'Statistic_GridFeedInDay'; SET @startdate = '2020-10-21';
SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
  FROM history t1
  INNER JOIN
    (SELECT TIMESTAMP,DEVICE,READING,VALUE
       FROM history
       WHERE DEVICE    = @device    AND
             READING   = @reading   AND
             TIMESTAMP > @startdate AND
             TIMESTAMP < DATE_ADD(@startdate,INTERVAL 1 DAY)
       ORDER BY TIMESTAMP DESC LIMIT 1
    ) x
  ON  x.TIMESTAMP != t1.TIMESTAMP AND
      x.DEVICE     = t1.DEVICE    AND
      x.READING    = t1.READING
  WHERE t1.DEVICE    = @device    AND
        t1.READING   = @reading   AND
        t1.TIMESTAMP > @startdate AND
        t1.TIMESTAMP < DATE_ADD(@startdate,INTERVAL 1 DAY)
  ORDER BY TIMESTAMP;

## Da kommt jetzt alles raus, das gelöscht werden soll. Somit braucht man das Select nun nur noch in ein DELETE umzuschreiben
+---------------------+-----------------+-------------------------+-------+
| TIMESTAMP           | DEVICE          | READING                 | VALUE |
+---------------------+-----------------+-------------------------+-------+
| 2020-10-21 00:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 0.00  |
| 2020-10-21 01:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 0.00  |
snip...
| 2020-10-21 21:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
| 2020-10-21 22:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
+---------------------+-----------------+-------------------------+-------+
## das ist genau bis '2020-10-21 22:57:00' und somit fehlt nur der Eintrag der bleibt


SELECT TIMESTAMP,DEVICE,READING,VALUE        FROM history        WHERE DEVICE=@device And READING=@reading AND TIMESTAMP LIKE @timelike        ORDER BY TIMESTAMP DESC LIMIT 1;
+---------------------+-----------------+-------------------------+-------+
| TIMESTAMP           | DEVICE          | READING                 | VALUE |
+---------------------+-----------------+-------------------------+-------+
| 2020-10-21 23:57:00 | PV_Anlage_1_API | Statistic_GridFeedInDay | 39.38 |
+---------------------+-----------------+-------------------------+-------+


Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 Oktober 2020, 18:18:31
Und schon habe ich die nächste Frage :-)

Es gibt einen Jahreszähler, den ich gerne in Wochen aufteilen möchte, was auch soweit klappt.
Nun gibt es die vermaledeiten Wochen, die über die Monatsgrenze gehen, oder die am Tag der Ausführung noch nicht abgeschlossen sind.

Nun habe ich einen Lauf mit "timestamp_end previous_month_end" gemacht und es wurde ein Wert für 2020-09-30 erstellt.
Danach kam ein Lauf mit gelöschtem "timestamp_end", auch hier endet die Berechnung nicht am Ende der letzten vollständigen Woche.

1.) Beim zweiten Lauf wurde der Eintrag vom '2020-09-30 19:05:00' nicht gelöscht (auch nicht mit allowDeletion = 1)
2.) Es wäre toll, wenn beim ersten Lauf die Berechnung der letzten angefangenen Woche nicht geschrieben würde.
3.) mal angenommen ich würde das nun jede Woche laufen lassen und das timestamp_begin jeweils auf previous_month_begin setzen,
    dann überschreibt es mir auch immer wieder die erste Woche des Laufes, wenn sie nicht vollständig ist.
    >>>> auch der Beginn darf nur auf vollständige Wochen zugreifen

EDIT: Das kleinste Problem habe ich jetzt schon beseitigt. Mit "timestamp_end = previous_week_end" habe ich natürlich keine angefangene Woche mehr ;-)
   Nun bleibt halt nur das Problem mit den Zeiträumen, bei denen dann Wochen am Anfang oder Ende nicht komplett sind.

Gruß
    Christian


| 2020-09-13 19:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 161360.0000 |
| 2020-09-20 18:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 147630.0000 |
| 2020-09-27 17:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 74480.0000  |
| 2020-09-30 19:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 28230.0000  |    <<<<< erster Lauf mit timestamp_end = previous_month_end
| 2020-10-04 19:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 47480.0000  |
| 2020-10-11 16:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 8760.0000   |
| 2020-10-18 14:05:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 450.0000    |
| 2020-10-22 17:57:00 | PV_Anlage_1_API | diff_week_Statistic_GridFeedInYear | 612.8400    |   <<<<< zweiter Lauf mit ohne timestamp_end
+---------------------+-----------------+------------------------------------+-------------+



defmod LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week DbRep LogDB
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week DbLogExclude .*
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week aggregation week
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week allowDeletion 0
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week device PV_Anlage_1_API
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week diffAccept 15000
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week reading Statistic_GridFeedInYear
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week room Strom->Energie,System
attr LogDBRep_Statistic_EnergyFeedInGrid_Month_diff_Week timestamp_begin current_year_begin
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2020, 19:26:49
Hallo Christian,

ich mache gerade ein bisschen Urlaub und bin gerade von einer Wanderung zurück gekommen.
Mal sehen ob es mir gelingt ein paar sinnvolle Gedanken in FHEM zu investieren.  :D

Zu deiner ersten Frage ...
Zitat
Hierbei geht es mir um einen Zähler, der den ganzen Tag ansteigt. Um das aufzuräumen können später alle Einträge bis auf den letzten gelöscht werden.
Die nächsten Schritte wären dann beim Monatszähler die jeweiligen Wochen zu behalten und
beim Jahreszähler die jeweiligen Monate.

Also wenn es sich um einen stetig steigenden Zähler handelt, kannst du einfach mit maxValue und dem Zusatz "deleteOther" arbeiten.
Konkret könnte es so aussehen, dass du die Zeitattribute auf current_Day_begin bzw. current_Day_end stellst und aggregation = day + device, reading. Danach:


set <> maxValue deleteOther


Übrig bleibt der höchte (=letzte) Wert des Tages.
Das gleiche kannst du machen mit current_week_begin und aggregation=week  oder current_month_begin und aggregation = month usw.
Ich denke du verstehst wie ich das Konstrukt meine.
Dein SQL übernehme ich gerne wieder mit ins Wiki. Irgendwann werde ich mich mal wieder intensiver mit DbRep befassen und SQL-specials einbauen.  ;)

Über deine zweite FRage denke ich mal nach ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 Oktober 2020, 19:41:42
Erst mal einen schönen Urlaub

Zitat von: DS_Starter am 22 Oktober 2020, 19:26:49
Also wenn es sich um einen stetig steigenden Zähler handelt, kannst du einfach mit maxValue und dem Zusatz "deleteOther" arbeiten.
Konkret könnte es so aussehen, dass du die Zeitattribute auf current_Day_begin bzw. current_Day_end stellst und aggregation = day + device, reading. Danach:


set <> maxValue deleteOther

Übrig bleibt der höchte (=letzte) Wert des Tages.
Das gleiche kannst du machen mit current_week_begin und aggregation=week  oder current_month_begin und aggregation = month usw.
Das erzeugt aber einen weiteren Eintrag mit einem generierten Namen :-)

Zitat
Dein SQL übernehme ich gerne wieder mit ins Wiki. Irgendwann werde ich mich mal wieder intensiver mit DbRep befassen und SQL-specials einbauen.  ;)
Da solltest Du Dich bitte gegebenenfalls vorher melden, damit Du auch aktuelles hast. Ich denke die Zeit für das Wiki finde ich auch noch.

Zitat
Über deine zweite Frage denke ich mal nach ....
Immer wieder gerne...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2020, 19:43:55
So jetzt die zweite Frage ...

Wenn ich alles richtig verstanden habe, würde ich es so lösen:

1. Zeigrenze timestamp_begin auf current_year_begin setzen (wenn das aufzuteile Jahr das aktuelle ist)
2. aggregation = week einstellen
3. maxValue laufen lassen (wenn MAX gesucht ist), ggf. auch hier wieder mit deleteOther wenn das gewünscht ist

Damit bekommst du für jede Kalenderwoche deinen Wert, auch wenn innerhalb der Woche ein Monatwechsel oder Jahreswechsel stattfindet.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2020, 19:49:08
Danke für deine Wünsche.  :)

Zitat
Das erzeugt aber einen weiteren Eintrag mit einem generierten Namen :-)
Denke nicht, das wäre bei writeToDB der Fall  ;)

Zitat
Da solltest Du Dich bitte gegebenenfalls vorher melden, damit Du auch aktuelles hast. Ich denke die Zeit für das Wiki finde ich auch noch.
Mache ich gerne, dauert auch noch etwas weil ich momentan ein neues Modul für die Integration der Synology File Station erstelle.
Freue mich auch darüber wenn du den Eintrag ins Wiki übernehmen würdest. Dann kann ich die Zeit für die Weiterarbeit am Modul nutzen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 Oktober 2020, 20:08:44
Zitat von: DS_Starter am 22 Oktober 2020, 19:49:08
Denke nicht, das wäre bei writeToDB der Fall  ;)
Tja, da soll es ja hin :-) oder halt alle anderen löschen, das SQL ist fast fertig, muss aber noch getestet werden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2020, 20:25:26
ZitatTja, da soll es ja hin :-) oder halt alle anderen löschen
Naja ich hatte es so verstanden dass du eigentlich nur den höchsten = letzten Wert einfach nur behalten wolltest und alle anderen im Bewertungszeitraum löschen. Egal, viele Wege führen nach Rom :-)
Bin gespannt auf deine fertiges SQL ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 Oktober 2020, 21:07:30
Zitat von: DS_Starter am 22 Oktober 2020, 20:25:26
Naja ich hatte es so verstanden dass du eigentlich nur den höchsten = letzten Wert einfach nur behalten wolltest und alle anderen im Bewertungszeitraum löschen. Egal, viele Wege führen nach Rom :-)
Das ist schon richtig, wenn man jedoch wieder einen neuen reading Namen erzeugt, muss man den auch wieder in den Plot bringen.
Ich dachte eher daran, die Werte nur auszudünnen, dann sind die aktuellen im Plot noch dichter und werden beim Zurückblättern halt weniger granular.

Okay, mann kann auch alle readings im Plot definieren und die Kurven ergänzen sich dann grafisch. Das mache ich manchmal mit positiven Werten in Grün und negative Werte in rot.
Was mich halt etwas stört ist, dass man dann bei einem Select immer daran denken muss beide Readings zu definieren.

Viele Grüße in den Urlaub
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2020, 21:20:28
ZitatDas ist schon richtig, wenn man jedoch wieder einen neuen reading Namen erzeugt, muss man den auch wieder in den Plot bringen.
Aber in dem oben beschriebenen Verfahren wird doch kein neuer Readingnamen erzeugt. Es bleibt nur der letzte = höchste Wert in der Reihe erhalten und alle anderen gelöscht. Der original Readingname bleibt dabei erhalten.
Mag sein dass ich heute bisschen auf der Leitung stehe ...  :o

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 Oktober 2020, 22:40:36
Zitat von: DS_Starter am 22 Oktober 2020, 21:20:28
Wenn ich writeToDB verwende wird also ein neues reading erzeugt.
Wenn ich nur den maxValue verwende und gleichzeitig deleteOther, wird dann alles bis auf den Max Wert gelöscht. Das hört sich dann nach meinem Wunsch an.
Hier fehlte noch die Bestätigung und es ist genau wie Heiko sagte.

Bei "deleteOther" wird einfach alles andere gelöscht und
bei "writeToDB" entsteht ein zusätzlicher Eintrag mit anderem reading Namen.
                      Den Namen kann man mit "readingNameMap" teilweise ändern.

In diesem Zeitraum wurde mit "maxValue", "week" und "deleteOther" gearbeitet.

select TIMESTAMP,DEVICE,READING,VALUE   from  history   where DEVICE = 'Thermostat_WO' AND TIMESTAMP>'2020-08-10' AND TIMESTAMP<'2020-09-13' order by TIMESTAMP limit 100;
+---------------------+---------------+-----------+-------+
| TIMESTAMP           | DEVICE        | READING   | VALUE |
+---------------------+---------------+-----------+-------+
| 2020-08-12 19:56:23 | Thermostat_WO | room-temp | 28.0  |
| 2020-08-21 22:18:01 | Thermostat_WO | room-temp | 26.5  |
| 2020-08-29 21:26:10 | Thermostat_WO | room-temp | 24.5  |
| 2020-09-05 18:19:50 | Thermostat_WO | room-temp | 24.0  |
| 2020-09-12 21:16:02 | Thermostat_WO | room-temp | 25.0  |
+---------------------+---------------+-----------+-------+


Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Oktober 2020, 22:44:15
Zitat
Wenn ich writeToDB verwende wird also ein neues reading erzeugt.
Wenn ich nur den maxValue verwende und gleichzeitig deleteOther, wird dann alles bis auf den Max Wert gelöscht.
Genau  :D

Bin auf dein Ergebnis gespannt. Bis morgen ...

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: awex102 am 26 Oktober 2020, 17:36:27
Hallo,

dein Modul DBRep habe ich im Einsatz, um mir aus einem Außentemperaturfühler das Tagesmittel ausgeben zu lassen.

Jetzt bin ich auf das Thema Grünlandtemperatursumme gestoßen und möchte das Thema gerne als Anregung in die Roadmap geben.

Es werden die positiven Tagesmitteltemperaturen addiert, bis sie 200 erreichen. Negative Tagesmitteltemperaturen werden verworfen. Zusätzlich wird ein ein Faktor pro Monat erstellt:
Aus Wikipedia: Es werden ab Jahresbeginn alle positiven Tagesmittel erfasst. Im Januar wird mit dem Faktor 0,5 multipliziert, im Februar mit dem Faktor 0,75, und ab März geht dann der ,,volle" Tageswert (mal Faktor 1) in die Rechnung ein.

Die GTS gibt in der Agrarwirtschaft den Zeitpunkt an, ab dem Pflanzen zu wachsen beginnen.

Was ich mir sehr gut in Kombi mit deiner Tagesmitteltemperatur - Berechnung vorstellen könnte, ist die Berechnung des GTS pro Jahr.
Z.B. ein get, das den tagesaktuellen Wert der Grünlandtemperatursumme zurückgibt. Bei GTS >= 200 gibt das reading keine neuen Werte aus, bleibt also stehen und man kann den Stichtagtag ablesen bzw. darauf in fhem reagieren und notify oder doif nutzen um z.B. eine Notification ans Handy zu senden. Und im nächsten Jahr von vorne.

Die Berechnung der Tagesmitteltemperaturen muss nach den Vorgaben des DWD erfolgen.

Danke und Gruß!

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 26 Oktober 2020, 17:58:30
Zitat von: awex102 am 26 Oktober 2020, 17:36:27
Jetzt bin ich auf das Thema Grünlandtemperatursumme gestoßen und möchte das Thema gerne als Anregung in die Roadmap geben.

Es werden die positiven Tagesmitteltemperaturen addiert, bis sie 200 erreichen. Negative Tagesmitteltemperaturen werden verworfen. Zusätzlich wird ein ein Faktor pro Monat erstellt:
Aus Wikipedia: Es werden ab Jahresbeginn alle positiven Tagesmittel erfasst. Im Januar wird mit dem Faktor 0,5 multipliziert, im Februar mit dem Faktor 0,75, und ab März geht dann der ,,volle" Tageswert (mal Faktor 1) in die Rechnung ein.

Die GTS gibt in der Agrarwirtschaft den Zeitpunkt an, ab dem Pflanzen zu wachsen beginnen.

Was ich mir sehr gut in Kombi mit deiner Tagesmitteltemperatur - Berechnung vorstellen könnte, ist die Berechnung des GTS pro Jahr.
Z.B. ein get, das den tagesaktuellen Wert der Grünlandtemperatursumme zurückgibt. Bei GTS >= 200 gibt das reading keine neuen Werte aus, bleibt also stehen und man kann den Stichtagtag ablesen bzw. darauf in fhem reagieren und notify oder doif nutzen um z.B. eine Notification ans Handy zu senden. Und im nächsten Jahr von vorne.

Die Berechnung der Tagesmitteltemperaturen muss nach den Vorgaben des DWD erfolgen.

Hallo awex102,

ich denke, das wird so nichts :-) Das ist schon eher eine Anwendungs-, als eine Datenbankfrage.

In solch einem Fall könntest Du ein SQL Statement erstellen und hier vorstellen.
Wenn das dann eine mehrfach zu verwendende Abfrage ist, kann man diese als "sqlSpecial" in DbRep integrieren.
So sind bereits zwei SQLs von mir mit aufgenommen worden, aber die Vorarbeit musste ich schon abliefern.

Siehe auch hier bei den Beispielen hilfreiche_SQL_Statements (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#hilfreiche_SQL_Statements)

Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 November 2020, 12:59:19
Hallo Heiko, hallo alle anderen interessierten.
Nach meinem letzten demotivierenden Post möchte ich nun nochmal ein sqlSpecial zur Diskussion stellen :-)

Das Problem:
Bei einigen Einträgen, die sich vom Minimum zum Maximum innerhalb eines Tages steigern kommt es vor, dass der erste Eintrag eigentlich der letze vom Vortag ist.
Bildet man nun den maxValue so erkennt man, dass das Maximum anstatt am Ende des Tages nun zu beginn des Tages ist.
Weiterhin kann es sein, dass das Maximum trotzdem am Tages Ende ist, jedoch ist dann das Maximum vom Vortag etwas zu gering.

Die Idee, um das zu beheben:
Der erste Wert des Tages muss überprüft werde, ob er noch zum Vortag gehört und dann auf z.B. 23:59 des Vortages verschoben werden.

Bei diesem SQL wird eine LAG() Funktion verwendet, falls jemand das noch mal im Netz näher nachschlagen möchte.

Ein Beispiel inklusive des korrigierten TIMESTAMP

## vor der Korrektur
+---------------------+-----------------+-------------------------------+-------+
| TIMESTAMP           | DEVICE          | READING                       | VALUE |
+---------------------+-----------------+-------------------------------+-------+
| 2020-09-01 23:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 16910 |
| 2020-09-02 00:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 17340 |   <<< das ist viel zu hoch
| 2020-09-02 01:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 220   |
+---------------------+-----------------+-------------------------------+-------+

## die Vorbereitung
+---------------------+---------------------+-----------------+-------------------------------+-------+
| TIMESTAMP_new       | TIMESTAMP           | DEVICE          | READING                       | VALUE |
+---------------------+---------------------+-----------------+-------------------------------+-------+
| 2020-09-01 23:59:00 | 2020-09-02 00:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 17340 |
| 2020-09-02 23:59:00 | 2020-09-03 00:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 16490 |
+---------------------+---------------------+-----------------+-------------------------------+-------+

## nach der Korrektur
+---------------------+-----------------+-------------------------------+-------+
| TIMESTAMP           | DEVICE          | READING                       | VALUE |
+---------------------+-----------------+-------------------------------+-------+
| 2020-09-01 23:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 16910 |
| 2020-09-01 23:59:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 17340 |
| 2020-09-02 01:57:00 | PV_Anlage_1_API | Statistic_EnergyHomePvSum_Day | 220   |
+---------------------+-----------------+-------------------------------+-------+


Hiermit wird ein Zeitraum analysiert und der neue TIMESTAMP hinzugefügt

## Für welches DEVICE und READING soll es gelten
SET @device='PV_Anlage_1_API';SET @reading='Statistic_EnergyHomePvSum_Day';

## welcher Zeitraum soll überprüft werden
SET @interval=NOW() - INTERVAL 12 Month;

## Diese Variablen müssen vor jedem Lauf zurück gesetzt werden
SET @diff=0;SET @temp=0;
SELECT TIMESTAMPADD(MINUTE,23*60+59,DATE(DATE_SUB(t1.TIMESTAMP, INTERVAL 1 DAY))) AS TIMESTAMP_new,
       t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
  FROM
    (
     SELECT TIMESTAMP,DEVICE,READING,VALUE,
            if(@diff  = 0,NULL, @temp:=cast((VALUE-@diff) AS DECIMAL(6,2))),
            if(@temp <= 0,NULL, @temp)               AS DIFF,
            @diff:=VALUE                             AS curr_V
       FROM  history
       WHERE  TIMESTAMP  >=   @interval
         AND  DEVICE      =   @device
         AND  READING     =   @reading
         AND (TIMESTAMP LIKE '% 23:%' OR
              TIMESTAMP LIKE '% 00:%')
       ORDER BY TIMESTAMP
    ) t1
  WHERE TIMESTAMP NOT LIKE '% 23:%'
    AND DIFF   IS NOT NULL ;


Achtung, ab hier wäre ein Backup von Vorteil, wenn mal etwas schief geht ;-)

Das vorherige SELECT wird nun in ein UPDATE eingebettet.
Das UPDATE hat zwei Tabellen (dest und src) in Verwendung.
Besonders wichtig ist natürlich die WHERE Klausel im UPDATE, damit auch wirklich der richtige Eintrag in der Datenbank geändert wird.

## Für welches DEVICE und READING soll es gelten
SET @device='PV_Anlage_1_API';SET @reading='Statistic_EnergyHomePvSum_Day';

## welcher Zeitraum soll bearbeitet werden
SET @interval=NOW() - INTERVAL 12 Month;

## Diese Variablen müssen vor jedem Lauf zurück gesetzt werden
SET @diff=0;SET @temp=0;
UPDATE history AS dest,
  (
   SELECT TIMESTAMPADD(MINUTE,23*60+59,DATE(DATE_SUB(t1.TIMESTAMP, INTERVAL 1 DAY))) AS TIMESTAMP_new,
          t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
     FROM
       (
        SELECT TIMESTAMP,DEVICE,READING,VALUE,
               if(@diff  = 0,NULL, @temp:=cast((VALUE-@diff) AS DECIMAL(6,2))),
               if(@temp <= 0,NULL, @temp)               AS DIFF,
               @diff:=VALUE                             AS curr_V
          FROM  history
          WHERE  TIMESTAMP  >=   @interval
            AND  DEVICE      =   @device
            AND  READING     =   @reading
            AND (TIMESTAMP LIKE '% 23:%' OR
                 TIMESTAMP LIKE '% 00:%')
          ORDER BY TIMESTAMP
       ) t1
     WHERE TIMESTAMP NOT LIKE '% 23:%'
       AND DIFF   IS NOT NULL
  ) AS src

  SET   dest.TIMESTAMP = src.TIMESTAMP_new,
        dest.DEVICE    = src.DEVICE,
        dest.READING   = src.READING,
        dest.VALUE     = src.VALUE

  WHERE dest.TIMESTAMP = src.TIMESTAMP AND
        dest.DEVICE    = src.DEVICE    AND
        dest.READING   = src.READING   AND
        dest.VALUE     = src.VALUE ;


Die Laufzeit des SELECT beträgt bei mir ca. 50 Sekunden, wobei es nicht stark variiert wenn der Zeitraum kürzen ist.
Der UPDATE lief dann ebenfalls ca. um eine Minute für 12 Monate und etwa 140 Einträge, die aus dem SELECT gekommen sind.

Ich werde das nun noch bei allen anderen Problemfällen anwenden und dann von weiteren Erfahrungen hier berichten.
Sollte jemand eine einfachere oder bessere Lösung haben, so mag er jetzt schreiben :-)

Viele Grüße
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 November 2020, 13:11:09
Hallo zusammen,

Da hat sich während meines Urlaubs einiges gestaut. Ich lese mit, werde aber alles nach und nach abarbeiten können.
Smaportal und meine synology module brauchen auch noch etwas aufmerksamkeit.  ;)

Aber zu gegebener zeit nehme ich mir dbrep wieder vor.

Lg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 November 2020, 20:47:01
Hallo awex102, @all,

ich habe in einer Testversion die Bereitstellung der Grünlandtemperatur umgesetzt. Dazu habe ich auch etwas im Netz gelesen und finde diesen Kennwert insgesamt recht interessant.
Da ich in meiner Datenbank auch immer schon die Temperaturen aufzeichne um sie vielleicht irgendwann mal auszuwerten, konnte ich mit diesen Daten auch gleich einen Praxistest durchführen. Ich kam für dieses Jahr auf das gleiche Ergebnis wie auf dieser Karte (http://www.hossi-im-netz.de/wordpress/gruenlandtemperatur/) für 2020 dargestellt.

Die Grünlandtemperatur ist eine Ergänzung zur  Berechnung des Tagesdurchschnitts des DWD, der eine bestimmte festgelegte Vorschrift der Temperaturermittlung vorgibt. Dazu gibt es einen neuen Wert für das Attribut:

averageCalcForm = avgDailyMeanGWSwithGTS

Ist dieses Attrbut gesetzt, wird mit einem

set <> averagevalue

neben der Tagesmitteltemperatur auch die Grünlandtemperatur berechnet und ausgegeben, sofern die erforderlichen Werte gemäß Vorschrift des DWD vorhanden sind.
Damit das sinnvol geschehen kann, muß man natürlich den timestamp_begin auf z.B. current_year_begin oder 01.01.XXXX setzen. Das Attr timestamp_end kann zwar beliebig sein, aber in diesem Kontext reicht es auf z.B. auf 01.05.XXXX zu setzen. Da der Wert jeder einzelnen Stunde berücksichtigt/bewertet werden muß, ist der Lauf relativ (zeit)aufwändig.

Hier eine Beispieldefinition eines Devices für die Grünlandtemperatur Ermittlung:


defmod Rep.Temp.greenland DbRep LogDB
attr Rep.Temp.greenland averageCalcForm avgDailyMeanGWSwithGTS
attr Rep.Temp.greenland devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Temp.greenland device MyWetter
attr Rep.Temp.greenland fastStart 1
attr Rep.Temp.greenland reading temperature
attr Rep.Temp.greenland room DbLog
attr Rep.Temp.greenland showproctime 1
attr Rep.Temp.greenland timestamp_begin current_year_begin
attr Rep.Temp.greenland timestamp_end 2020-03-01 00:00:00
attr Rep.Temp.greenland verbose 3


Das Ergebnis:


   READINGS:
     2020-11-08 20:07:24   2020-01-01__MyWetter__temperature__AVGDMGWS__2020-01-01 1.5
     2020-11-08 20:07:24   2020-01-01__MyWetter__temperature__GrasslandTemperatureSum 0.8
     2020-11-08 20:07:24   2020-01-02__MyWetter__temperature__AVGDMGWS__2020-01-02 1.0
     2020-11-08 20:07:24   2020-01-02__MyWetter__temperature__GrasslandTemperatureSum 1.3
     2020-11-08 20:07:24   2020-01-03__MyWetter__temperature__AVGDMGWS__2020-01-03 5.2
     2020-11-08 20:07:24   2020-01-03__MyWetter__temperature__GrasslandTemperatureSum 3.9
     2020-11-08 20:07:24   2020-01-04__MyWetter__temperature__AVGDMGWS__2020-01-04 4.2
     2020-11-08 20:07:24   2020-01-04__MyWetter__temperature__GrasslandTemperatureSum 6.0
     2020-11-08 20:07:24   2020-01-05__MyWetter__temperature__AVGDMGWS__2020-01-05 2.8
     2020-11-08 20:07:24   2020-01-05__MyWetter__temperature__GrasslandTemperatureSum 7.4
     2020-11-08 20:07:24   2020-01-06__MyWetter__temperature__AVGDMGWS__2020-01-06 3.5
     2020-11-08 20:07:24   2020-01-06__MyWetter__temperature__GrasslandTemperatureSum 9.1
     2020-11-08 20:07:24   2020-01-07__MyWetter__temperature__AVGDMGWS__2020-01-07 2.5
     2020-11-08 20:07:24   2020-01-07__MyWetter__temperature__GrasslandTemperatureSum 10.4
     2020-11-08 20:07:24   2020-01-08__MyWetter__temperature__AVGDMGWS__2020-01-08 5.5
     2020-11-08 20:07:24   2020-01-08__MyWetter__temperature__GrasslandTemperatureSum 13.2
     2020-11-08 20:07:24   2020-01-09__MyWetter__temperature__AVGDMGWS__2020-01-09 8.3
     2020-11-08 20:07:24   2020-01-09__MyWetter__temperature__GrasslandTemperatureSum 17.4
     2020-11-08 20:07:24   2020-01-10__MyWetter__temperature__AVGDMGWS__2020-01-10 8.8
     2020-11-08 20:07:24   2020-01-10__MyWetter__temperature__GrasslandTemperatureSum 21.8
     2020-11-08 20:07:24   2020-01-11__MyWetter__temperature__AVGDMGWS__2020-01-11 4.1
     2020-11-08 20:07:24   2020-01-11__MyWetter__temperature__GrasslandTemperatureSum 23.8
     2020-11-08 20:07:24   2020-01-12__MyWetter__temperature__AVGDMGWS__2020-01-12 3.0
     2020-11-08 20:07:24   2020-01-12__MyWetter__temperature__GrasslandTemperatureSum 25.3
     2020-11-08 20:07:24   2020-01-13__MyWetter__temperature__AVGDMGWS__2020-01-13 4.7
     2020-11-08 20:07:24   2020-01-13__MyWetter__temperature__GrasslandTemperatureSum 27.7
     2020-11-08 20:07:24   2020-01-14__MyWetter__temperature__AVGDMGWS__2020-01-14 7.5
     2020-11-08 20:07:24   2020-01-14__MyWetter__temperature__GrasslandTemperatureSum 31.5
     2020-11-08 20:07:24   2020-01-15__MyWetter__temperature__AVGDMGWS__2020-01-15 10.3
     2020-11-08 20:07:24   2020-01-15__MyWetter__temperature__GrasslandTemperatureSum 36.6
     2020-11-08 20:07:24   2020-01-16__MyWetter__temperature__AVGDMGWS__2020-01-16 8.0
     2020-11-08 20:07:24   2020-01-16__MyWetter__temperature__GrasslandTemperatureSum 40.6
     2020-11-08 20:07:24   2020-01-17__MyWetter__temperature__AVGDMGWS__2020-01-17 4.9
     2020-11-08 20:07:24   2020-01-17__MyWetter__temperature__GrasslandTemperatureSum 43.1
     2020-11-08 20:07:24   2020-01-18__MyWetter__temperature__AVGDMGWS__2020-01-18 5.3
     2020-11-08 20:07:24   2020-01-18__MyWetter__temperature__GrasslandTemperatureSum 45.7
     2020-11-08 20:07:24   2020-01-19__MyWetter__temperature__AVGDMGWS__2020-01-19 3.0
     2020-11-08 20:07:24   2020-01-19__MyWetter__temperature__GrasslandTemperatureSum 47.2
     2020-11-08 20:07:24   2020-01-20__MyWetter__temperature__AVGDMGWS__2020-01-20 2.2
     2020-11-08 20:07:24   2020-01-20__MyWetter__temperature__GrasslandTemperatureSum 48.4
     2020-11-08 20:07:24   2020-01-21__MyWetter__temperature__AVGDMGWS__2020-01-21 0.5
     2020-11-08 20:07:24   2020-01-21__MyWetter__temperature__GrasslandTemperatureSum 48.6
     2020-11-08 20:07:24   2020-01-22__MyWetter__temperature__AVGDMGWS__2020-01-22 0.4
     2020-11-08 20:07:24   2020-01-22__MyWetter__temperature__GrasslandTemperatureSum 48.8
     2020-11-08 20:07:24   2020-01-23__MyWetter__temperature__AVGDMGWS__2020-01-23 2.0
     2020-11-08 20:07:24   2020-01-23__MyWetter__temperature__GrasslandTemperatureSum 49.8
     2020-11-08 20:07:24   2020-01-24__MyWetter__temperature__AVGDMGWS__2020-01-24 -0.2
     2020-11-08 20:07:24   2020-01-25__MyWetter__temperature__AVGDMGWS__2020-01-25 -0.1
     2020-11-08 20:07:24   2020-01-26__MyWetter__temperature__AVGDMGWS__2020-01-26 0.9
     2020-11-08 20:07:24   2020-01-26__MyWetter__temperature__GrasslandTemperatureSum 50.2
     2020-11-08 20:07:24   2020-01-27__MyWetter__temperature__AVGDMGWS__2020-01-27 5.1
     2020-11-08 20:07:24   2020-01-27__MyWetter__temperature__GrasslandTemperatureSum 52.8
     2020-11-08 20:07:24   2020-01-28__MyWetter__temperature__AVGDMGWS__2020-01-28 5.2
     2020-11-08 20:07:24   2020-01-28__MyWetter__temperature__GrasslandTemperatureSum 55.4
     2020-11-08 20:07:24   2020-01-29__MyWetter__temperature__AVGDMGWS__2020-01-29 3.8
     2020-11-08 20:07:24   2020-01-29__MyWetter__temperature__GrasslandTemperatureSum 57.3
     2020-11-08 20:07:24   2020-01-30__MyWetter__temperature__AVGDMGWS__2020-01-30 5.7
     2020-11-08 20:07:24   2020-01-30__MyWetter__temperature__GrasslandTemperatureSum 60.1
     2020-11-08 20:07:24   2020-01-31__MyWetter__temperature__AVGDMGWS__2020-01-31 11.1
     2020-11-08 20:07:24   2020-01-31__MyWetter__temperature__GrasslandTemperatureSum 65.7
     2020-11-08 20:07:24   2020-02-01__MyWetter__temperature__AVGDMGWS__2020-02-01 11.1
     2020-11-08 20:07:24   2020-02-01__MyWetter__temperature__GrasslandTemperatureSum 74.0
     2020-11-08 20:07:24   2020-02-02__MyWetter__temperature__AVGDMGWS__2020-02-02 7.7
     2020-11-08 20:07:24   2020-02-02__MyWetter__temperature__GrasslandTemperatureSum 79.8
     2020-11-08 20:07:24   2020-02-03__MyWetter__temperature__AVGDMGWS__2020-02-03 8.9
     2020-11-08 20:07:24   2020-02-03__MyWetter__temperature__GrasslandTemperatureSum 86.5
     2020-11-08 20:07:24   2020-02-04__MyWetter__temperature__AVGDMGWS__2020-02-04 4.8
     2020-11-08 20:07:24   2020-02-04__MyWetter__temperature__GrasslandTemperatureSum 90.1
     2020-11-08 20:07:24   2020-02-05__MyWetter__temperature__AVGDMGWS__2020-02-05 2.9
     2020-11-08 20:07:24   2020-02-05__MyWetter__temperature__GrasslandTemperatureSum 92.3
     2020-11-08 20:07:24   2020-02-06__MyWetter__temperature__AVGDMGWS__2020-02-06 2.8
     2020-11-08 20:07:24   2020-02-06__MyWetter__temperature__GrasslandTemperatureSum 94.4
     2020-11-08 20:07:24   2020-02-07__MyWetter__temperature__AVGDMGWS__2020-02-07 4.4
     2020-11-08 20:07:24   2020-02-07__MyWetter__temperature__GrasslandTemperatureSum 97.7
     2020-11-08 20:07:24   2020-02-08__MyWetter__temperature__AVGDMGWS__2020-02-08 4.2
     2020-11-08 20:07:24   2020-02-08__MyWetter__temperature__GrasslandTemperatureSum 100.9
     2020-11-08 20:07:24   2020-02-09__MyWetter__temperature__AVGDMGWS__2020-02-09 9.2
     2020-11-08 20:07:24   2020-02-09__MyWetter__temperature__GrasslandTemperatureSum 107.8
     2020-11-08 20:07:24   2020-02-10__MyWetter__temperature__AVGDMGWS__2020-02-10 7.7
     2020-11-08 20:07:24   2020-02-10__MyWetter__temperature__GrasslandTemperatureSum 113.6
     2020-11-08 20:07:24   2020-02-11__MyWetter__temperature__AVGDMGWS__2020-02-11 4.3
     2020-11-08 20:07:24   2020-02-11__MyWetter__temperature__GrasslandTemperatureSum 116.8
     2020-11-08 20:07:24   2020-02-12__MyWetter__temperature__AVGDMGWS__2020-02-12 4.0
     2020-11-08 20:07:24   2020-02-12__MyWetter__temperature__GrasslandTemperatureSum 119.8
     2020-11-08 20:07:24   2020-02-13__MyWetter__temperature__AVGDMGWS__2020-02-13 3.6
     2020-11-08 20:07:24   2020-02-13__MyWetter__temperature__GrasslandTemperatureSum 122.5
     2020-11-08 20:07:24   2020-02-14__MyWetter__temperature__AVGDMGWS__2020-02-14 5.6
     2020-11-08 20:07:24   2020-02-14__MyWetter__temperature__GrasslandTemperatureSum 126.7
     2020-11-08 20:07:24   2020-02-15__MyWetter__temperature__AVGDMGWS__2020-02-15 6.3
     2020-11-08 20:07:24   2020-02-15__MyWetter__temperature__GrasslandTemperatureSum 131.4
     2020-11-08 20:07:24   2020-02-16__MyWetter__temperature__AVGDMGWS__2020-02-16 12.3
     2020-11-08 20:07:24   2020-02-16__MyWetter__temperature__GrasslandTemperatureSum 140.7
     2020-11-08 20:07:24   2020-02-17__MyWetter__temperature__AVGDMGWS__2020-02-17 9.8
     2020-11-08 20:07:24   2020-02-17__MyWetter__temperature__GrasslandTemperatureSum 148.0
     2020-11-08 20:07:24   2020-02-18__MyWetter__temperature__AVGDMGWS__2020-02-18 7.0
     2020-11-08 20:07:24   2020-02-18__MyWetter__temperature__GrasslandTemperatureSum 153.3
     2020-11-08 20:07:24   2020-02-19__MyWetter__temperature__AVGDMGWS__2020-02-19 5.5
     2020-11-08 20:07:24   2020-02-19__MyWetter__temperature__GrasslandTemperatureSum 157.4
     2020-11-08 20:07:24   2020-02-20__MyWetter__temperature__AVGDMGWS__2020-02-20 5.2
     2020-11-08 20:07:24   2020-02-20__MyWetter__temperature__GrasslandTemperatureSum 161.3
     2020-11-08 20:07:24   2020-02-21__MyWetter__temperature__AVGDMGWS__2020-02-21 6.0
     2020-11-08 20:07:24   2020-02-21__MyWetter__temperature__GrasslandTemperatureSum 165.8
     2020-11-08 20:07:24   2020-02-22__MyWetter__temperature__AVGDMGWS__2020-02-22 8.5
     2020-11-08 20:07:24   2020-02-22__MyWetter__temperature__GrasslandTemperatureSum 172.2
     2020-11-08 20:07:24   2020-02-23__MyWetter__temperature__AVGDMGWS__2020-02-23 9.5
     2020-11-08 20:07:24   2020-02-23__MyWetter__temperature__GrasslandTemperatureSum 179.3
     2020-11-08 20:07:24   2020-02-24__MyWetter__temperature__AVGDMGWS__2020-02-24 5.7
     2020-11-08 20:07:24   2020-02-24__MyWetter__temperature__GrasslandTemperatureSum 183.6
     2020-11-08 20:07:24   2020-02-25__MyWetter__temperature__AVGDMGWS__2020-02-25 8.9
     2020-11-08 20:07:24   2020-02-25__MyWetter__temperature__GrasslandTemperatureSum 190.3
     2020-11-08 20:07:24   2020-02-26__MyWetter__temperature__AVGDMGWS__2020-02-26 3.5
     2020-11-08 20:07:24   2020-02-26__MyWetter__temperature__GrasslandTemperatureSum 192.9
     2020-11-08 20:07:24   2020-02-27__MyWetter__temperature__AVGDMGWS__2020-02-27 3.2
     2020-11-08 20:07:24   2020-02-27__MyWetter__temperature__GrasslandTemperatureSum 195.3
     2020-11-08 20:07:24   2020-02-28__MyWetter__temperature__AVGDMGWS__2020-02-28 3.2
     2020-11-08 20:07:24   2020-02-28__MyWetter__temperature__GrasslandTemperatureSum 197.7
     2020-11-08 20:07:24   2020-02-29__MyWetter__temperature__AVGDMGWS__2020-02-29 7.2
     2020-11-08 20:07:24   2020-02-29__MyWetter__temperature__GrasslandTemperatureSum 203.1
     2020-11-08 20:07:24   2020-03-01__MyWetter__temperature__AVGDMGWS__2020-03-01 7.1
     2020-11-08 20:07:24   2020-03-01__MyWetter__temperature__GrasslandTemperatureSum 210.2
     2020-11-08 20:07:24   background_processing_time 36.3184
     2020-11-08 20:07:24   sql_processing_time 36.3164
     2020-11-08 20:07:24   state           done


Es werden auch entsprechende Events für jeden einzelnen Tagwert erstellt, die ggf. über ein notify oder über eine userExitFn ausgewertet werden können. z.B.:


2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-01__MyWetter__temperature__GrasslandTemperatureSum: 0.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-02__MyWetter__temperature__GrasslandTemperatureSum: 1.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-03__MyWetter__temperature__GrasslandTemperatureSum: 3.9
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-04__MyWetter__temperature__GrasslandTemperatureSum: 6.0
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-05__MyWetter__temperature__GrasslandTemperatureSum: 7.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-06__MyWetter__temperature__GrasslandTemperatureSum: 9.1
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-07__MyWetter__temperature__GrasslandTemperatureSum: 10.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-08__MyWetter__temperature__GrasslandTemperatureSum: 13.2
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-09__MyWetter__temperature__GrasslandTemperatureSum: 17.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-10__MyWetter__temperature__GrasslandTemperatureSum: 21.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-11__MyWetter__temperature__GrasslandTemperatureSum: 23.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-12__MyWetter__temperature__GrasslandTemperatureSum: 25.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-13__MyWetter__temperature__GrasslandTemperatureSum: 27.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-14__MyWetter__temperature__GrasslandTemperatureSum: 31.5
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-15__MyWetter__temperature__GrasslandTemperatureSum: 36.6
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-16__MyWetter__temperature__GrasslandTemperatureSum: 40.6
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-17__MyWetter__temperature__GrasslandTemperatureSum: 43.1
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-18__MyWetter__temperature__GrasslandTemperatureSum: 45.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-19__MyWetter__temperature__GrasslandTemperatureSum: 47.2
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-20__MyWetter__temperature__GrasslandTemperatureSum: 48.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-21__MyWetter__temperature__GrasslandTemperatureSum: 48.6
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-22__MyWetter__temperature__GrasslandTemperatureSum: 48.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-23__MyWetter__temperature__GrasslandTemperatureSum: 49.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-26__MyWetter__temperature__GrasslandTemperatureSum: 50.2
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-27__MyWetter__temperature__GrasslandTemperatureSum: 52.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-28__MyWetter__temperature__GrasslandTemperatureSum: 55.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-29__MyWetter__temperature__GrasslandTemperatureSum: 57.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-30__MyWetter__temperature__GrasslandTemperatureSum: 60.1
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-01-31__MyWetter__temperature__GrasslandTemperatureSum: 65.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-01__MyWetter__temperature__GrasslandTemperatureSum: 74.0
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-02__MyWetter__temperature__GrasslandTemperatureSum: 79.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-03__MyWetter__temperature__GrasslandTemperatureSum: 86.5
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-04__MyWetter__temperature__GrasslandTemperatureSum: 90.1
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-05__MyWetter__temperature__GrasslandTemperatureSum: 92.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-06__MyWetter__temperature__GrasslandTemperatureSum: 94.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-07__MyWetter__temperature__GrasslandTemperatureSum: 97.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-08__MyWetter__temperature__GrasslandTemperatureSum: 100.9
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-09__MyWetter__temperature__GrasslandTemperatureSum: 107.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-10__MyWetter__temperature__GrasslandTemperatureSum: 113.6
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-11__MyWetter__temperature__GrasslandTemperatureSum: 116.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-12__MyWetter__temperature__GrasslandTemperatureSum: 119.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-13__MyWetter__temperature__GrasslandTemperatureSum: 122.5
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-14__MyWetter__temperature__GrasslandTemperatureSum: 126.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-15__MyWetter__temperature__GrasslandTemperatureSum: 131.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-16__MyWetter__temperature__GrasslandTemperatureSum: 140.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-17__MyWetter__temperature__GrasslandTemperatureSum: 148.0
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-18__MyWetter__temperature__GrasslandTemperatureSum: 153.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-19__MyWetter__temperature__GrasslandTemperatureSum: 157.4
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-20__MyWetter__temperature__GrasslandTemperatureSum: 161.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-21__MyWetter__temperature__GrasslandTemperatureSum: 165.8
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-22__MyWetter__temperature__GrasslandTemperatureSum: 172.2
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-23__MyWetter__temperature__GrasslandTemperatureSum: 179.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-24__MyWetter__temperature__GrasslandTemperatureSum: 183.6
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-25__MyWetter__temperature__GrasslandTemperatureSum: 190.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-26__MyWetter__temperature__GrasslandTemperatureSum: 192.9
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-27__MyWetter__temperature__GrasslandTemperatureSum: 195.3
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-28__MyWetter__temperature__GrasslandTemperatureSum: 197.7
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-02-29__MyWetter__temperature__GrasslandTemperatureSum: 203.1
2020-11-08 20:07:24.555 DbRep Rep.Temp.greenland 2020-03-01__MyWetter__temperature__GrasslandTemperatureSum: 210.2
 

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


Bin auf dein/euer Testergebnis gespannt.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 13:26:39
Hallo zusammen,

ich mache gerade meinen ersten sync in eine weitere Datenbank, mit welchem timeDiffToNow bekomme ich denn alles rüber?

Dieser Parameter läuft gerade und es sind bereits 1,7 von 3,2 Gb drüben.

timeDiffToNow y:1


Das Endziel ist alles synchron zu haben und dann das Logging auf der neuen Datenbank weiter laufen zu lassen.

Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 November 2020, 13:35:59
Hi Christian,

wenn du alles haben willst, brauchst du die time.* Attr zur Abgrenzung nicht setzen.
Jetzt hast du schon soviel übertragen. Dann machst du noch eine weiteren Lauf wenn der fertig ist mit timeOlderThan.

Damit der RAM nicht strapaziert wird, kannst du Attribut "aggregation" benutzen. Aber hast du sicher gelesen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 13:59:51
Zitat von: DS_Starter am 10 November 2020, 13:35:59
wenn du alles haben willst, brauchst du die time.* Attr zur Abgrenzung nicht setzen.
Jetzt hast du schon soviel übertragen. Dann machst du noch eine weiteren Lauf wenn der fertig ist mit timeOlderThan.

Damit der RAM nicht strapaziert wird, kannst du Attribut "aggregation" benutzen. Aber hast du sicher gelesen.
Leider war ich Dumm und experimentierfreudig :-(

Ich habe

aggregation no
timeDiffToNow y:1


Dann ist wohl der Index noch noch da. Gerade läuft ein "delDoublets delete" und dann erstelle ich noch den Index.

Was müsste ich dann genau setzen, um den Rest zu transferieren? Die Laufzeit ist nicht so kritisch.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 November 2020, 14:06:41
Einfach nur

timeOlderThan y:1

damit alle Daten älter als ein Jahr übertragen werden die im vorherigen Lauf ausgegrenzt hast.
Wenn du im Ziel einen PK angelegt hast, kannst du den Zeitraum auch etwas überlappen lassen ohne das doppelte DS entstehen. Kennst du ja.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 14:13:56
Zitat von: DS_Starter am 10 November 2020, 14:06:41
Einfach nur

timeOlderThan y:1

damit alle Daten älter als ein Jahr übertragen werden die im vorherigen Lauf ausgegrenzt hast.
Wenn du im Ziel einen PK angelegt hast, kannst du den Zeitraum auch etwas überlappen lassen ohne das doppelte DS entstehen. Kennst du ja.

Ich werde immer gewandter in Datenbanken ;-)

Übrigens habe ich bei DbRep kein next_day_begin oder end gefunden.
Das wäre für meine Prognose recht praktisch, weil ich heute schon Einträge für den nächsten Tag habe.
Mit Angabe des Datums geht es natürlich, da muss man dann allerdings jedesmal rechnen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 November 2020, 14:18:37
ZitatÜbrigens habe ich bei DbRep kein next_day_begin oder end gefunden.
Richtig, gibts bisher nicht. Das wäre ein Featurerequest.  ;)

ZitatIch werde immer gewandter in Datenbanken ;-)
Das ist gut. Dann kannst du mir mit ausgebufften SQLs unter die Arme greifen. Ehrlich.
Ich habe kaum noch Zeit und Muße dazu.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 14:25:33
Zitat von: DS_Starter am 10 November 2020, 14:18:37
Richtig, gibts bisher nicht. Das wäre ein Featurerequest.  ;)
Request, request,request :-)

Zitat
Das ist gut. Dann kannst du mir mit ausgebufften SQLs unter die Arme greifen. Ehrlich.
Ich habe kaum noch Zeit und Muße dazu.
Was fehlt Dir denn?

Der letzte von mir war doch schon mal gut  ::)
Der verschiebt den ersten Eintrag am Tag, wenn er größer ist als der zweite, zurück auf den Vortag.
Das passiert bei mir schon mal, da die PV_Anlage den Tagesabschluss zu spät macht. Dann war nachts vor 01:00 Uhr bereits das Maximum des Tages erreicht :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 November 2020, 14:29:32
 :)  Ich nehme den Request mit auf. Erst will ich GTS aber ordentlich beenden und einchecken.

Aktuell fehlt mir nichts. Das war jetzt ganz allgemein bemerkt und natürlich auch ernst gemeint, da du inzwischen stark eingestiegen bist. Allerdings immer dran denken es muss auch für SQLite und Postgre laufen, nicht nur MySQL Brille.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 14:35:29
Zitat von: DS_Starter am 10 November 2020, 14:29:32
Allerdings immer dran denken es muss auch für SQLite und Postgre laufen, nicht nur MySQL Brille.  :)
Ich versuche immer nur Basis Funktionalitäten zu verwenden und anders DBs habe ich noch nicht verwendet.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 19:35:48
Da ich ja sooo net gebeten wurde mal wieder SQL zu liefern :-)

Hier ein SQL, mit dem man überprüfen kann, ob ein Primary Key durchlaufen würde

SELECT
  TIMESTAMP, COUNT(TIMESTAMP),
  DEVICE, COUNT(DEVICE),
  READING, COUNT(READING)
FROM history
GROUP BY
  TIMESTAMP,
  DEVICE,
  READING
HAVING COUNT(TIMESTAMP)>1
  AND COUNT(DEVICE)>1
  AND COUNT(READING)>1;

+---------------------+------------------+----------------------+---------------+------------------------------------+----------------+
| TIMESTAMP           | COUNT(TIMESTAMP) | DEVICE               | COUNT(DEVICE) | READING                            | COUNT(READING) |
+---------------------+------------------+----------------------+---------------+------------------------------------+----------------+
| 2020-03-11 08:54:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
| 2020-03-11 11:36:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
| 2020-03-11 12:48:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_PV       |              2 |
| 2020-03-11 13:00:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
| 2020-03-11 14:06:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
| 2020-03-11 14:18:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
| 2020-03-12 11:06:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
| 2020-03-12 11:06:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_PV       |              2 |
| 2020-03-12 12:18:00 |                2 | PV_Anlage_1          |             2 | Home_own_consumption_from_battery  |              2 |
snip...

# Dann diese Einträge löschen, oder zumindest einen davon
# und schon sollte die erstellung des Primary key durchlaufen
ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);


Außer man macht mittendrin mal das Fenster auf :-)

MySQL [fhem]> ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
ERROR 1062 (23000): Duplicate entry '2020-11-10 19:03:42-KU_S_Fenster-state' for key 'PRIMARY'
MySQL [fhem]> delete from history where DEVICE='KU_S_Fenster' and READING='state' and TIMESTAMP = '2020-11-10 19:03:42';
Query OK, 3 rows affected (0.029 sec)


Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 22:30:33
Hey Heiko,
ich habe jetzt den Primary Key eingerichtet und nochmals ein syncStandby laufen lassen. Jetzt sind beide Datenbank ca gleich groß.

Was soll ich denn morgen für Attribute für den letzten Sync setzen, damit die Nacht noch dazu kommt? Mir fehlt momentan die Konzentration ein wenig.
Und wie wäre der Weg zur Umschaltung auf die neue DB dann am einfachsten.

Ich würde einfach beide stoppen und die Ports tauschen. Geht das so, oder bekomme ich da Probleme mit den Timestamps?
Auf ein paar Logs kann ich gut verzichten, ich muss eh noch aufräumen.

EDIT:
Kann das sein, dass das Logging parallel in beide Datenbanken geht? Wenn ich einen Update auf ein Device mache erscheinen die Meldungen direkt in Beiden Datenbanken.
Die eine ist über Port 3306 und die andere über 3307 erreichbar.
Im Fhem habe ich zwei DbLog Devices, die aber mit unterschiedlichen db.conf konfiguriert sind. eine halt mit HostIP:3306 und die andere mit HostIP:3307 .
Das ist natürlich praktisch, weil ich mir dann den letzten sync sparen kann, aber verstehen tue ich es nicht.
Okay, es ist das selbe interne Docker Netzwerk, aber da ist ja die IP Adresse unterschiedlich.

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 November 2020, 23:01:26
Hallo Christian,

ZitatWas soll ich denn morgen für Attribute für den letzten Sync setzen, damit die Nacht noch dazu kommt? Mir fehlt momentan die Konzentration ein wenig.
Da du einen PK gesetzt hast, brauchst du dir nicht so viel Gedanken über eine Time-Überschneidung zu machen.
Du stellst den timeDiffToNow auf das Anfang des ersten Synclaufs, d.h. die Zeit als du den ersten Lauf gestartet hast, z.B. heute früh um 8:00 oder so. Kannst auch einen Tag zurück gehen zur Sicherheit.
Dann läuft alles rein was noch dazu kam. Der PK schützt vor doppelten DS.

ZitatUnd wie wäre der Weg zur Umschaltung auf die neue DB dann am einfachsten.
Kommt darauf an, wie du mit DbLog arbeitest. Am einfachsten übernimmst du den Regex im DEF des alten DbLog und loggst erstmal parallel.
Dann stellst du nach und nach deine SVG, DbRep etc. um. Das neue DbLog hat ja einen neuen Namen.
Während dessen kannst du beide parallel laufen lassen.
Wenn du fertig bist stellst du das alte DbLog auf disable und irgendwann wirfst du alles Alte weg.

ODER

Nach dem Sync stellst du beide DbLog auf disable. Benennst das alte um und benennst das neue DbLog in den alten Namen um. Danach das neue DbLog wieder enablen.
Dadurch gehen ein paar Events verloren, aber du brauchst dir nicht die Arbeit zu machen alle SVG etc. anzupassen.
So würde ich es wohl machen wenn viele Auswertungen existieren.

Grüße.
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 November 2020, 23:03:58
Oh, Du bist noch wach.
Ich habe gerade im alten post noch eine Merkwürdigkeit nachgetragen.

Okay, in Deiner Antwort steht auch schon die Erklärung, warum es bei mir doppelt logged.

Danke und gute Nacht
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 November 2020, 23:08:01
ZitatOh, Du bist noch wach.
Aber gleich nicht mehr  :)

ZitatKann das sein, dass das Logging parallel in beide Datenbanken geht?
Ja klar. Ich habe auf meinem Testsystem vllt. 6 parallele DB's ... MySQL, SQLite und Postgre um die Ergebnisse vergleichen zu können bei der Entwicklung.

Ein Dblog Device ist ja defacto auch nur ein notify mit angehängter Datenbank  ;)

Gute Nacht...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 November 2020, 22:48:24
Die neue Version mit dem Feature der Berechnung eine Grünlandtemperatursumme ist finalisiert und eingecheckt. Morgen früh wie üblich im Update.
Ich habe noch ein Reading "reachedGTSthreshold" implemntiert welches das Datum des erstmaligen Erreichens des Schwellwertes 200 enthält. Auch darauf kann man dann gut über ein Event reagieren.

Ein paar kleine Bugfixes sind auch enthalten.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 November 2020, 09:35:19
Hallo Christian,

in meinem contrib liegt die Version 8.42.0.
Dort gibt es nun die Möglichkeit next_day_begin und next_day_end zu spezifizieren.

Mal für mein Verständnis.... wozu braucht man die Auswertung der DB für den kommenden Tag. Dafür gibt es i.A. noch keine Werte in der DB oder fügst du sie mit irgendeiner Routine vorher ein ?

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 November 2020, 10:44:11
Zitat von: DS_Starter am 15 November 2020, 09:35:19
in meinem contrib liegt die Version 8.42.0.
Dort gibt es nun die Möglichkeit next_day_begin und next_day_end zu spezifizieren.

Mal für mein Verständnis.... wozu braucht man die Auswertung der DB für den kommenden Tag. Dafür gibt es i.A. noch keine Werte in der DB oder fügst du sie mit irgendeiner Routine vorher ein ?
Hallo Heiko,
ich bin doch meiner Zeit voraus ;-)

Bei der PV_Anlage Implementierung für den Kostal Plenticore Plus ist auch ein Forecast implementiert. Hierbei wird die Wetterprognose mit Sonnenstrahlung, Wolken und Regen in Stundenwerte für die zu erwartende Leistung berechnet. Der Forecast fc_0 ist der aktuelle Tag und wird auch mit diesem Datum in die Datenbank geschrieben. fc_1 ist der Forecast für den nächsten Tag, der dann auch vordatiert auf den nächsten Tag in die Datenbank geschrieben wird. Hierdurch bekomme ich dann im Diagramm zu einem bestimmten Tag die Daten, die am vortag geschrieben wurden und die vom aktuellen Tag gleichzeitig angezeigt.

Ein request, der an mich gestellt wurde war die Summe der Tagesleistung von morgen zu berechnen :-) , um daraufhin eine Entscheidung zu treffen, ob ein Verbraucher jetzt gestartet werden kann oder ob es besser wäre bis morgen zu warten.

Und da ich dafür gerne DbRep verwende und rechnen lasse, habe ich diesen Wunsch geäußert.

Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 November 2020, 10:51:33
Danke für die Erläuterung. Habs verstanden.  ;)
Vielleicht kann ich sowas auch für das Modul SMAPortal implementieren, da dieses Modul ebenfalls bei entsprechender Parametrisierung Prognosedaten liefert. Hat aber noch niemend diesen Wunsch geäußert es loggen zu wollen.

Na dann teste mal  :) ... Bei mir sieht es gut aus und wenn nichts gegenteiliges zurück kommt checke ich die Version heute Abend ein und du/deine Moduluser haben die Version dann ab morgen früh im Update.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 November 2020, 11:36:04
Zitat von: DS_Starter am 15 November 2020, 10:51:33
Danke für die Erläuterung. Habs verstanden.  ;)
Vielleicht kann ich sowas auch für das Modul SMAPortal implementieren, da dieses Modul ebenfalls bei entsprechender Parametrisierung Prognosedaten liefert. Hat aber noch niemand diesen Wunsch geäußert es loggen zu wollen.
Beim SMA hatte ich auch mal gespickt :-)
Plenticore hat eine WR Interne Prognose, die jedoch manchmal daneben liegt, wenn es von gutem zu schlechten Wetter übergeht.
Dank KölnSolar habe ich dann mit der eigenen Berechnung begonnen und das passt echt gut :-)
Der Bedarf entsteht nur, wenn Du auch Verbraucher hast, die man schieben kann. Also schiebe ich die erlaubte Pool Startzeit zwischen einer Sommer und einer Winterzeit hin und her, jenachdem wie die Prognose aussieht. Wird das Wetter schlechter startet der Pool eher und ist dann auf Temperatur, wenn er verwendet wird.
Du findest es ja im Wiki.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 November 2020, 15:21:53
Hallo Heiko,
das next_day[begin|end] hat funktioniert. Vielen Dank
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 November 2020, 16:55:59
Ist eingecheckt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 15 November 2020, 19:26:12
Hi,

ich habe einen kleinen Fehler im Wiki entdeckt:

Beim Anlegen der Sync-Datenbank fehlt bei
Zitat
1. Anlegen der DB und Tabellen
wie in diesem Link hinterlegt, erfolgt die Erstellung mit den Befehlen für MySQL:
...
ALTER TABLE `fhemtest`.`history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
...
die Angabe der Tabelle.


Könnte das bitte jemand korrigieren, bevor sich noch jemand den Kopf zerbrechen muss. ;)

Danke Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 November 2020, 19:39:38
Danke für den Hinweis Bernd. Habe es ergänzt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 17 November 2020, 20:12:43
Ist hier der DbRep thread :-) :-)

Hallo Heiko,
beim sqlCmd kann man den reading Namen nicht verändern.

SELECT sum(VALUE) AS 'Solar_calculation_fc1_tomorrow' FROM history WHERE DEVICE = 'PV_Anlage_1' AND READING = 'Solar_Calculation_fc1' AND TIMESTAMP > DATE_ADD(DATE(now()),INTERVAL 1 DAY) AND TIMESTAMP < DATE_ADD(DATE(now()),INTERVAL 2 DAY);
+--------------------------------+
| Solar_calculation_fc1_tomorrow |
+--------------------------------+
|                           9288 |
+--------------------------------+

## man kann auch den Header auf leer setzen ;-)
## Im DbRep ist aber immer SqlResultRow_1 fest für die Überschriften gesetzt, aber das ist sicherlich mySQL spezifisch :-)
SELECT sum(VALUE) AS '' FROM history WHERE DEVICE = 'PV_Anlage_1' AND READING = 'Solar_Calculation_fc1' AND TIMESTAMP > DATE_ADD(DATE(now()),INTERVAL 1 DAY) AND TIMESTAMP < DATE_ADD(DATE(now()),INTERVAL 2 DAY);
+------+
|      |
+------+
| 9288 |
+------+

Und es wird brutal der Spaltenname in Großbuchstaben umgewandelt, was nicht aus dem SQL kommt.

SqlResultRow_1 SOLAR_CALCULATION_FC1_TOMORROW
SqlResultRow_2 9288
readingNameMap Solar_calculation_fc1_tomorrow

Variante eins wäre schön

SqlResultRow_1 Solar_calculation_fc1_tomorrow
SqlResultRow_2 9288

Oder Variante zwei mit as '' und readingNameMap

Solar_calculation_fc1_tomorrow_1 9288
readingNameMap Solar_calculation_fc1_tomorrow

Ups, jetzt fällt es mir gerade auf, Variante zwei ohne die SqlResultRow_1 wäre nur Möglich, wenn keine Columne Überschrift kommt, also bei mehrspaltigen Abfragen.
Ich lasse es einfach mal zur Diskussion hier so stehen.

VG
  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 November 2020, 00:22:25
Hallo Christian,

ZitatUnd es wird brutal der Spaltenname in Großbuchstaben umgewandelt, was nicht aus dem SQL kommt.
Das hab ich im Code so hinterlegt, damit man die Überschriften leicht als solche erkennt. Der Header wird übrigens auch bei mehrspaltigen Ausgaben ausgegeben sofern diese geliefert werden, z.B. bei get <> procInfo.
Der Header wird vom DBI-Interface geliefert, siehe -> https://metacpan.org/pod/DBI#NAME1

Grüße,
Heiko


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2020, 18:45:39
Nabend Christian,

das ist hsitorisch bedingt. Als ich vor ein paar Jahren Dblog begonnen hatte zu übernehmen, war die Column Struktur bereits gegeben.
Allerdings hatte ich später die Attribute colEvent, colReading und colValue eingebaut.
Damit kann man die Breite verändern, aber auch mit

colEvent=0

das Datenbankfeld EVENT nicht füllen lassen. Das dann freie Feld könnte man für eigene Zwecke verwenden, z.B. um mit einem DbRep SQL Werte dort eintragen.
Ich kann dir auch nicht sagen wozu man ursprünglich die EVENT Column verwendet hat.

Edit: Uuuups, wo ist die Frage hin ?  ;)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 November 2020, 18:58:53
Zitat von: DS_Starter am 20 November 2020, 18:45:39
Edit: Uuuups, wo ist die Frage hin ?  ;)
Vielen dank für die super schnelle Antwort. Ich hatte dann nochmal gesucht und den anderen Thread gefunden.
DbLog Datenbankstruktur MySQL (https://forum.fhem.de/index.php/topic,111567.0.html)
Da wollte ich Dich nicht hier nochmal nerven.

Ich habe das colEvent=0 gesetzt.

select * from history where DEVICE='PV_Anlage_1_API' and READING='Statistic_EnergyHomePvSum_Day' and TIMESTAMP >= '2020-11-20 18:00:00';
+---------------------+-----------------+---------+-------+-------------------------------+---------+------+
| TIMESTAMP           | DEVICE          | TYPE    | EVENT | READING                       | VALUE   | UNIT |
+---------------------+-----------------+---------+-------+-------------------------------+---------+------+
| 2020-11-20 18:57:04 | PV_Anlage_1_API | HTTPMOD |       | Statistic_EnergyHomePvSum_Day | 4320.29 |      |
+---------------------+-----------------+---------+-------+-------------------------------+---------+------+

Jetzt läuft noch ein optimizeTablesBeforeDump und dann der Dump.

EDIT: Oh man, ignoriere mich heute besser :-)

Danach möchte ich die EVENT Spalte leeren. Hast Du da einen SQL Vorschlag?

UPDATE history
SET EVENT = NULL
WHERE EVENT is not null;


Sorry
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 November 2020, 19:05:01
Ich würde es so machen:

ALTER TABLE history DROP COLUMN EVENT

und danach wieder anlegen.
Kommt darauf an wie groß die DB ist wegen der Laufzeit.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 30 November 2020, 17:12:34
Zitat von: DS_Starter am 20 November 2020, 19:05:01
ALTER TABLE history DROP COLUMN EVENT

und danach wieder anlegen.
Kommt darauf an wie groß die DB ist wegen der Laufzeit.
Dieser Weg hat hervorragend funktioniert und die Datenbank um 45% verkleinert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 30 November 2020, 17:21:08
Nun beobachte ich ein Phonemen, wo ich nicht richtig weiter komme.

HW RPI4 mit 4G RAM , Fhem, MySQL, Grafana,... in Docker auf einer SSD
DbLog asyncron mit Indix, ohne Event Spalte und aufgeräumt. Ich habe von >4GB auf 1,4 GB reduziert und die Tabelle nach dem Löschen von Einträgen auch wieder optimiert.

Nun kommt es immer wieder zu Hängern, bei denen das Grafana, keine Daten mehr bekommt.
Auch Fhem gibt nur zögerlich Rückmeldung, wohingegen das Debian immer noch flüssig läuft.
Mit attr global 3 und Verbose 5 habe ich schon diverse Devices überprüft. Wenn die Datenbank Abfrage hängt sehe ich nichts verdächtiges im Log oder bei den Events.

Mit apptime max sehe ich, dass DbLog immer on the Top ist.

Durch die Fhem Events habe ich mich ebenfalls optimiert und es wird auch nur mit event-on-change-reading gearbeitet.

Wie könnte ich nun dem Datenbankproblem auf die schliche kommen?
Wenn das Problem auftritt ist die SSD LED munter am blinken...

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Dezember 2020, 22:21:49
Hallo Christian,

ich habe darüber schon länger nachgedacht. (Ist übrigens im falsche Thread, auch wenn DbRep stark mit DbLog verwoben ist).
Kann mir momentan keinen Reim darauf machen wieso bei einer "hängenden" DB der asynchrone Modus von DbLog bei apptime max oben ist. Das passiert ja noch nicht einmal wenn die DB heruntergefahren ist.

Vielleicht sieht man mehr wenn du die apptime Ausgaben mal postest.

Ansonsten wirst du vermutlich bei dieser Sache eher etwas finden wenn du dir das Datenbanklog auf Betriebssystemebene mal anschaust. Es gibt z.B. auch bei phpMyAdmin eine Monitoringmöglichkeit. Dort sieht man laufende DB-Prozesse bzw. Statements. Das klappt auch mit DbRep get <> procinfo sofern FHEM noch an die DB rankommt.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 Dezember 2020, 22:24:46
Danke für die Info.
gibt es phpMyAdmin im Docker für nen RPI ? Das würde Arbeit sparen.

Ich vermute ja es ist Grafana, 22 Abfragen in vier Diagrammen auf einem Dashboard. Ist das viel?
VG
  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Dezember 2020, 22:29:27
Ich habe das hier gefunden:
https://github.com/JackGruber/docker_phpmyadmin

(Habe doch Synology  ;) )

Zu Grafana kann ich dir nichts sagen, da fragst du am besten in dem Board mit den Grafana Experten
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 01 Dezember 2020, 22:31:02
Zitat von: DS_Starter am 01 Dezember 2020, 22:29:27
https://github.com/JackGruber/docker_phpmyadmin
Das check ich mal morgen, danke.

EDIT: phpMyAdmin läuft auf dem RPI in Docker

.yml Einträge

  phpMyAdmin:
    image: jackgruber/phpmyadmin
    restart: always
    ports:
        - '8081:80'
    links:
        - mysql
    environment:
        PMA_HOST: mysql
        PMA_PORT: 3306
    depends_on:
      - "mysql"

Es ist leider kein Konfiguration Speicher definiert, aber das findet sich auch noch.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 15:10:19
Hallo Heiko,
ich habe gerade mal Fhem aktualisiert und somit auch DbRep.
93_DbRep.pm:v8.42.1-s23214/2020-11-22
Beim "set <device> DiffValue ... " ist die Liste mit Display oder writeToDb aufeinmal weg :-) Ist das ein Bug oder ein feature? ;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2020, 15:31:39
Hallo Christian,

weder noch ... bei mir ist sie vorhanden.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 16:27:56
Zitat von: DS_Starter am 15 Dezember 2020, 15:31:39
weder noch ... bei mir ist sie vorhanden.
Ja und nun isset wech :-) ich kann Zaubern :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2020, 16:36:59
Na du kannst Sachen machen.  :)
Vllt. mal Browsercache leeren.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 17:07:08
Zitat von: DS_Starter am 15 Dezember 2020, 16:36:59
Na du kannst Sachen machen.  :)
Vllt. mal Browsercache leeren.

- nun habe ich mehrfach den cache gelöscht
- shutdown restart
- docker container stop/start

Leider ist der Fehler immer noch da. Da muss es eventuell noch einen anderen Update gegeben haben, der da rein spielt.

Auch die alte DbRep Version tut's nun auch nicht mehr :-(

EDIT: Kann es das eventuell sein

2020.12.15 14:02:50.616 1: UPD FHEM/01_FHEMWEB.pm


Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2020, 17:54:28

EDIT: Kann es das eventuell sein
Code: [Auswählen]

2020.12.15 14:02:50.616 1: UPD FHEM/01_FHEMWEB.pm


Nein. Habe gerade komplett upgedated und läuft absolut korrekt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 18:12:31
Zitat von: DS_Starter am 15 Dezember 2020, 17:54:28
Nein. Habe gerade komplett upgedated und läuft absolut korrekt.
Sehr dubios, ich habe auch mal das style sheet geändert, aber die Auswahl ist einfach weg.
Nun bin ich ratlos
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2020, 18:21:42
Diese Oberfläche wird ja durch Javascript (fhemweb.js) gestaltet.
Hast du mal einen anderen Browser verwendet ? Oder deinen PC/Laptop restartet ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 19:16:09
Zitat von: DS_Starter am 15 Dezember 2020, 18:21:42
Diese Oberfläche wird ja durch Javascript (fhemweb.js) gestaltet.
Hast du mal einen anderen Browser verwendet ? Oder deinen PC/Laptop restartet ?
Hab jetzt auch den RPI restarted, es bleibt einfach weg. Auch vom Handy oder Tablet ist es einfach weg.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2020, 19:18:49
Puh ... da fällt mir grad nix mehr ein ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 19:20:48
Zitat von: DS_Starter am 15 Dezember 2020, 19:18:49
Puh ... da fällt mir grad nix mehr ein ...
Ich habe noch mehr getestet, wenn man auf room geht, erscheint normaler weise ein Popup Fenster, das ist auch weg.
Das mit dem Java scheint schon die richtige Idee zu sein, aber wo man das wieder gerade biegen kann weiß ich auch nicht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Dezember 2020, 19:27:51
Frag doch mal im FHEMWEB Forum ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Dezember 2020, 19:28:31
Zitat von: DS_Starter am 15 Dezember 2020, 19:27:51
Frag doch mal im FHEMWEB Forum ...
Mache ich gerade, danke.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 02 Januar 2021, 15:25:54
Hallo Heiko,
dbrep ermittelt '-' für einen sumValue über einen einzigen Eintrag in der DB mit value=0. Ist das gewollt?

   READINGS:
     2021-01-02 14:21:11   2021-01-01__Solar_Monatsenergieertrag_calc__no_aggregation -
     2021-01-02 14:21:11   background_processing_time 0.0067
     2021-01-02 14:21:11   sql_processing_time 0.0026
     2021-01-02 14:21:11   state           done
Attributes:
   aggregation no
   device     Tagesgesamtenergieertrag_Solar
   reading    state
   readingNameMap Solar_Monatsenergieertrag_calc
   showproctime 1
   timestamp_begin current_month_begin
   timestamp_end previous_day_end

mit DB-Eintrag:

MariaDB [fhem]> select * from history where device = 'Tagesgesamtenergieertrag_Solar' and timestamp >= '2021-01-01 00:00:00';
+---------------------+--------------------------------+-------+----------+---------+-------+------+
| TIMESTAMP           | DEVICE                         | TYPE  | EVENT    | READING | VALUE | UNIT |
+---------------------+--------------------------------+-------+----------+---------+-------+------+
| 2021-01-01 23:59:59 | Tagesgesamtenergieertrag_Solar | DUMMY | state: 0 | state   | 0     |      |
+---------------------+--------------------------------+-------+----------+---------+-------+------+


SQL:
MariaDB [fhem]> select sum(value) from history where device = 'Solar_Monatsenergieertrag' and timestamp >= '2021-01-01 00:00:00';
+------------+
| sum(value) |
+------------+
|          0 |
+------------+
1 row in set (0.001 sec)



Viele Grüße,
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Januar 2021, 16:18:13
Hallo Thowe,

Nein, da sollte evenfalls 0 kommen.
Werde es am we korrigieren.

Danke für den Hinweis.

Lg,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2021, 10:19:57
Hallo Thowe, @all,

habe das von dir gemeldete Problem gefixt und eingecheckt.

Außerdem habe ich fastStart (siehe Attribut fastStart) als Standard für Clients eingebaut.
Das bedeutet, dass sich die DbRep-Devices erst mit der DB verbinden wenn sie etwas zu tun bekommen und nicht sofort bei FHEM Start. Insbesondere bei vielen definierten DbReps kann es sonst bei Start unter Umständen zu Verzögerungen bzw. RAM-Belastung durch Perl-fork kommen.

Devices vom Typ "Agent" verbindne sich nach wie vor sofort zur DB.

Ist morgen früh im Update. Wer es gleich einbauen möchte, kann die neue V downloaden.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 03 Januar 2021, 19:18:05
Hallo Heiko,
sumValue über value=0 funktioniert, vielen Dank.
Mit guten Wünschen für das neue Jahr
Thowe
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2021, 22:52:50
Danke für die Info und das Gleiche für 2021 !

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 29 Januar 2021, 21:40:25
Hab ein issue in der Doku entdeckt:

bei sumValue:

writeToDBSingle : writes only one value with the time stamp XX:XX:59 at the end of an evaluation period


Nach meinem Verständnis (und meinen Tests) müsste es heissen "at the end of an aggregation period" - oder?
Zumindest schreibt er bei
attr aggregation day
die Werte jeden Tag um 23:59:59 in die Datenbank und nicht nur am datum timestamp_end.
Falls nicht, erklär mir doch bitte den Hintergrund - den hab ich dann nicht verstanden.

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Januar 2021, 21:52:13
Hallo Stephan,

danke für den Hinweis. Es ist ist so wie du geschrieben hast.
Werde die commandref anpassen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 30 Januar 2021, 11:03:01
Hallo Heiko,

ich wollte in einem sqlCmd auf die readings, die man als Attribut setzen kann zugreifen. Geht das überhaupt?


LASTCMD

SELECT DATE,
       READING,
       cast(avg(VALUE) AS DECIMAL(6,2)) AS AVG,
       WEEKDAY
  FROM
    (
     SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d') AS DATE,
            READING,max(VALUE)                 AS VALUE,
            weekday(TIMESTAMP)                 AS WEEKDAY
     FROM history
     WHERE DEVICE    =  §device§
       AND READING   =  §reading§
       AND TIMESTAMP >= §timestamp_begin§
       AND TIMESTAMP <= §timestamp_end§
     GROUP BY DATE
    ) t1
  GROUP BY WEEKDAY;

Es kommt folgender Fehler

errortext DBD::mysql::st execute failed: Unknown column '§device§' in 'where clause' at ./FHEM/93_DbRep.pm line 6414.


Den Syntax habe ich aus einem sqlSpecial entnommen :-)

Die Abfrage würde einen Zählerstand, der über den Tag wächst, als Durchschnitt pro Wochentag ausgeben.
Ich würde dann im Forum meine diversen SQLs auf DbRep angepasst veröffentlichen, da nicht alle Anwender direkt in MySQL abfragen können/möchten.

Viele Grüße
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2021, 11:53:07
Hallo Christian,

momentan kann man über sqlCmd nur auf §timestamp_begin§, §timestamp_end§ zugreifen, aber nicht §device§, §reading§ zugreifen.

Im Prinzip kann man diese Möglichkeit auch relativ einfach einbauen. Ich habe das bisher vermieden weil es für die Attribute device, reading vielfältige Eingabemöglichkeiten gibt die im ungünstigen Fall in einem sqlCmd zu Fehlern führen können.
Eingabemöglichkeiten wären zum Beispiel:


Beispiele:
attr <name> device TYPE=DbRep
attr <name> device MySTP_5000
attr <name> device SMA.*,MySTP.*
attr <name> device SMA_Energymeter,MySTP_5000
attr <name> device %5000
attr <name> device TYPE=SSCam EXCLUDE=SDS1_SVS
attr <name> device TYPE=SSCam,TYPE=ESPEasy EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=TYPE=SSCam


Für das Attr reading sieht es ähnlich aus.
Ich denke du weißt was ich meine.
Wäre es denn dir sehr wichtig einen solchen Zugriff zu haben ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 30 Januar 2021, 12:28:56
Zitat von: DS_Starter am 30 Januar 2021, 11:53:07
momentan kann man über sqlCmd nur auf §timestamp_begin§, §timestamp_end§ zugreifen, aber nicht §device§, §reading§ zugreifen.

Im Prinzip kann man diese Möglichkeit auch relativ einfach einbauen. Ich habe das bisher vermieden weil es für die Attribute device, reading vielfältige Eingabemöglichkeiten gibt die im ungünstigen Fall in einem sqlCmd zu Fehlern führen können.
Eingabemöglichkeiten wären zum Beispiel:


Beispiele:
attr <name> device TYPE=DbRep
attr <name> device MySTP_5000
attr <name> device SMA.*,MySTP.*
attr <name> device SMA_Energymeter,MySTP_5000
attr <name> device %5000
attr <name> device TYPE=SSCam EXCLUDE=SDS1_SVS
attr <name> device TYPE=SSCam,TYPE=ESPEasy EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=TYPE=SSCam


Für das Attr reading sieht es ähnlich aus.
Ich denke du weißt was ich meine.
Wäre es denn dir sehr wichtig einen solchen Zugriff zu haben ?
Okay, das würde dann zu einem SQL Error führen.
Ich hatte simpler gedacht. wenn timestamp_* geht, geht auch device und reading :-) Jetzt wo ich das weiß, kann ich es ja auch direkt ins SQL schreiben, die readings wären natürlich flexibler und durchgängiger.
Für mich alle brauchst Du da natürlich keine Zeit zu investieren, Du hast ja momentan eh genug zu tun.

Manchmal kommt es mir vor, das nur wir zwei DbRep verwenden ;-)

Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 31 Januar 2021, 09:15:09
Guten Morgen, ich habe jetzt die 92 Seiten nicht gelesen, aber die commandref und kapiere es nicht. Ich möchte gern alle Daten löschen, die älter als 50 Tage sind. In der commandref ist das so angegeben
ZitatdelEntries [<no>[:<nn>]] - löscht alle oder die durch die Attribute device und/oder reading definierten Datenbankeinträge. Die Eingrenzung über Timestamps erfolgt folgendermaßen:...
"timeOlderThan" gesetzt -> gelöscht werden DB-Einträge älter als aktuelle Zeit minus "timeOlderThan"

Es werden aber anscheinend nur die aktuell letzten 50 Tage gelöscht. Was mache ich da falsch?

Mein List ist
Internals:
   DATABASE   fhem
   DEF        DbLog
   FUUID      5e244bd9-f33f-1115-8e73-a46a39d31299868e
   FVERSION   93_DbRep.pm:v8.42.3-s23462/2021-01-03
   LASTCMD    delEntries
   MODEL      Client
   NAME       DbLogRep
   NOTIFYDEV  global,DbLogRep
   NR         33
   NTFY_ORDER 50-DbLogRep
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE DbLog
     GRANTS     INSERT,ALL PRIVILEGES,UPDATE,DELETE,SELECT
     IDRETRIES  2
     MINTS      2020-07-04 17:41:39
     PACKAGE    main
     SQLHIST   
     VERSION    8.42.3
     CV:
       aggregation no
       aggsec     1
       destr      2021-01-31
       dsstr      2020-12-12
       epoch_seconds_end 1612079258
       mestr      01
       msstr      12
       testr      08:47:38
       tsstr      08:47:37
       wdadd      172800
       yestr      2021
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2021-01-31 08:47:41   /--/----DELETED_ROWS_HISTORY-- 33310
     2021-01-31 08:47:41   state           done
Attributes:
   allowDeletion 1
   group      intern
   timeDiffToNow d:50
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Januar 2021, 10:35:00
Guten Morgen,

Zitatich habe jetzt die 92 Seiten nicht gelesen ...
Commandref sollte reichen  :)

ZitatEs werden aber anscheinend nur die aktuell letzten 50 Tage gelöscht. Was mache ich da falsch?
Du hast das Attr timeDiffToNow d:50 statt timeOlderThan gesetzt. Richtig wäre timeOlderThan d:50.
Die Angabe  [<no>[:<nn>]] im Setter ist optional und wird nicht benötigt wenn das Attribut verwendet wird.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 03 Februar 2021, 12:25:54
Ich habe gerade seit ein paar Tagen dbrep auf meine Datenbank losgelassen, um doubletten zu löschen.
Dabei habe ich die Parameter

Attributes:
   allowDeletion 1
   fastStart  1
   reading    EXCLUDE=.*work.*
   room       System->Logging
   showproctime 1
   sqlCmdHistoryLength 50
   timeout    864000
   timestamp_begin previous_year_begin


gesetzt.
Recht erschrocken war ich, als ich in der Processlist von mysql dann folgende Information fand:
Zitat|  8742 | fhemuser | localhost | fhem | Query   |    0 | query end | delete FROM history where TIMESTAMP = '2020-03-04 00:00:38' AND DEVICE = 'D_WMZ_Heizung_main' AND READING = 'work' AND VALUE = '8.16'

Warum wurde diese Abfrage nicht ausgeschlossen? Oder interpretiere ich da was falsch?

Hier nochmal das ganze Device:
Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      6015d946-f33f-4040-6784-2b12d3e3044ec15f
   FVERSION   93_DbRep.pm:v8.42.3-s23462/2021-01-03
   LASTCMD    delDoublets delete
   MODEL      Client
   NAME       repdb_delDoublets
   NOTIFYDEV  global,repdb_delDoublets
   NR         565
   NTFY_ORDER 50-repdb_delDoublets
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     GRANTS     USAGE,SELECT,DELETE,UPDATE,INSERT
     IDRETRIES  2
     MINTS      2014-03-26 22:59:59
     PACKAGE    main
     SQLHIST   
     VERSION    8.42.3
     CV:
       aggregation day
       aggsec     86400
       destr      2021-02-02
       dsstr      2020-01-01
       epoch_seconds_end 1612304892
       mestr      02
       msstr      01
       testr      23:28:12
       tsstr      00:00:00
       wdadd      432000
       yestr      2021
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2021-02-03 09:47:55   errortext       DBD::mysql::st execute failed: Lost connection to MySQL server during query at ./FHEM/93_DbRep.pm line 5540.

     2021-02-03 09:47:55   state           error
Attributes:
   allowDeletion 1
   fastStart  1
   reading    EXCLUDE=.*work.*
   room       System->Logging
   showproctime 1
   sqlCmdHistoryLength 50
   timeout    864000
   timestamp_begin previous_year_begin

Grüße,
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Februar 2021, 12:33:58
Hallo Stephan,

falsche Verwendung des Attr. bzw. der Perl Wildcards .* -> SQL Wildcard % !

Auszug aus Commandref:

reading - Abgrenzung der DB-Selektionen auf ein bestimmtes oder mehrere Readings sowie exkludieren von Readings. Mehrere Readings werden als Komma separierte Liste angegeben. Es können SQL Wildcard (%) verwendet werden.
Wird dem Reading bzw. der Reading-Liste ein "EXCLUDE=" vorangestellt, werden diese Readings nicht inkludiert.

    Beispiele:
    attr <name> reading etotal
    attr <name> reading et%
    attr <name> reading etotal,etoday
    attr <name> reading eto%,Einspeisung EXCLUDE=etoday
    attr <name> reading etotal,etoday,Ein% EXCLUDE=%Wirkleistung

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 03 Februar 2021, 13:00:51
tjaaa... das war dämlich von mir.

Mal sehen, was ich retten kann...
Danke!
Stephan
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Februar 2021, 14:03:28
Zitat von: abc2006 am 03 Februar 2021, 13:00:51
tjaaa... das war dämlich von mir.
Mal sehen, was ich retten kann...
Du kannst aus der Sicherung, die Du davor gemacht hast die Einträge einzeln wiederherstellen, ohne die gesamte Sicherung zurück zu spielen.

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: abc2006 am 03 Februar 2021, 14:17:46
Tja, das birgt das generelle Problem bei großen Datenmengen. Ich weiss nicht genau, was alles gelöscht wurde, und müsste jetzt quasi die gesamte Sicherung einspielen, und dann nochmal ein delDoublets machen. Da hat meine Datenbank ein paar Tage zu tun.
Einen PK habe ich leider noch nicht.
Ich habe ein paar kurze Tests gemacht und die wichtigsten Daten scheinen noch da zu sein.
Ich arbeite mich gerade in syncStandby ein und werde eine zweite Datenbank mit den wichtigeren Sachen anlegen. Was mir dabei auffällt (aber vielleicht gibts da ja auch schon eine Lösung), dass ich ja dann einen Workaround brauche, wenn ich an den Übergang von alten zu aktuellen Daten (die dann ja in einer anderen DB sind) komme.
Naja, mal sehen.
Grüße,
Stephan

PS: vielleicht könnte man im ConfigCheck anzeigen, ob und welcher PK genutzt wird.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Februar 2021, 15:21:58
Zitat von: abc2006 am 03 Februar 2021, 14:17:46
Tja, das birgt das generelle Problem bei großen Datenmengen. Ich weiss nicht genau, was alles gelöscht wurde, und müsste jetzt quasi die gesamte Sicherung einspielen, und dann nochmal ein delDoublets machen. Da hat meine Datenbank ein paar Tage zu tun.
Einen PK habe ich leider noch nicht.
Ich habe ein paar kurze Tests gemacht und die wichtigsten Daten scheinen noch da zu sein.
Ich arbeite mich gerade in syncStandby ein und werde eine zweite Datenbank mit den wichtigeren Sachen anlegen. Was mir dabei auffällt (aber vielleicht gibts da ja auch schon eine Lösung), dass ich ja dann einen Workaround brauche, wenn ich an den Übergang von alten zu aktuellen Daten (die dann ja in einer anderen DB sind) komme.
PS: vielleicht könnte man im ConfigCheck anzeigen, ob und welcher PK genutzt wird.
Du hast ja mit einer Maske gelöscht und es laufen jetzt ja von den Devices weiter Daten rein.
Damm mach mal ein Select mit der selben Maske und schau was da so alles kommt.
Dann such mit einem grep und der selben Maske das Backup File durch. Zuerst in ein less pipen und wenn es passt in ein anderes File.
Dieses differenz File kannst Du dann in die Datenbank laden. Es sollte so sein, das Du keine duplicate keys zugelassen hast, somit wird nur das reingeladen, was Du nicht mehr in der DB hast.

Für eine zweite Datenbank kannst Du ja einen Sync machen oder halt selectiv übertragen. Auch da sollte es einen primary key geben.

Da hatte ich gestern schon mal was passendes geschrieben. (https://forum.fhem.de/index.php/topic,117864.msg1128436.html#msg1128436) Den private key kannst Du ja auch nachträglich definieren.
Titel: Bin ich zu blöd, oder was läuft hier falsch
Beitrag von: wowogiengen am 08 Februar 2021, 09:22:37
Hallo,
ich benutze das dbRep-Modul, um Tages- und Monatsdurchschnittswerte meiner Raumtemperaturen aus der Datenbank zu ermitteln.
Dafür verwende ich zB. folgendes at:

define atdbRepBad3 at *00:40 set dbRepBad3 averageValue writeToDB
attr atdbRepBad3 room DbLog
attr atdbRepBad3 verbose 1
attr atdbRepBad3 webCmd execNow
attr atdbRepBad3 widgetOverride execNow

setstate atdbRepBad3 Next: 00:40:00
setstate atdbRepBad3 2021-02-08 00:40:00 state Next: 00:40:00



das zugehörige dbRepBad3 sieht so aus:

defmod dbRepBad3 DbRep mySQLDB
attr dbRepBad3 aggregation month
attr dbRepBad3 allowDeletion 1
attr dbRepBad3 devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr dbRepBad3 device HzgThermostatBad
attr dbRepBad3 event-on-update-reading state
attr dbRepBad3 reading measured-temp
attr dbRepBad3 room DbLog,LogFiles,System
attr dbRepBad3 timestamp_begin previous_year_begin
attr dbRepBad3 timestamp_end previous_day_end
attr dbRepBad3 verbose 1

setstate dbRepBad3 done
setstate dbRepBad3 2020-12-17 22:28:27 .associatedWith HzgThermostatBad
setstate dbRepBad3 2021-02-08 09:09:14 2020-01-01__HzgThermostatBad__measured-temp__AVGAM__2020-01 23.1718
setstate dbRepBad3 2021-02-08 09:09:14 2020-02-01__HzgThermostatBad__measured-temp__AVGAM__2020-02 23.0269
setstate dbRepBad3 2021-02-08 09:09:14 2020-03-01__HzgThermostatBad__measured-temp__AVGAM__2020-03 23.0446
setstate dbRepBad3 2021-02-08 09:09:14 2020-04-01__HzgThermostatBad__measured-temp__AVGAM__2020-04 22.9332
setstate dbRepBad3 2021-02-08 09:09:14 2020-05-01__HzgThermostatBad__measured-temp__AVGAM__2020-05 22.3761
setstate dbRepBad3 2021-02-08 09:09:14 2020-06-01__HzgThermostatBad__measured-temp__AVGAM__2020-06 22.9846
setstate dbRepBad3 2021-02-08 09:09:14 2020-07-01__HzgThermostatBad__measured-temp__AVGAM__2020-07 22.5617
setstate dbRepBad3 2021-02-08 09:09:14 2020-08-01__HzgThermostatBad__measured-temp__AVGAM__2020-08 23.0202
setstate dbRepBad3 2021-02-08 09:09:14 2020-09-01__HzgThermostatBad__measured-temp__AVGAM__2020-09 22.4993
setstate dbRepBad3 2021-02-08 09:09:14 2020-10-01__HzgThermostatBad__measured-temp__AVGAM__2020-10 22.9706
setstate dbRepBad3 2021-02-08 09:09:14 2020-11-01__HzgThermostatBad__measured-temp__AVGAM__2020-11 22.8690
setstate dbRepBad3 2021-02-08 09:09:14 2020-12-01__HzgThermostatBad__measured-temp__AVGAM__2020-12 23.3856
setstate dbRepBad3 2021-02-08 09:09:14 2021-01-01__HzgThermostatBad__measured-temp__AVGAM__2021-01 22.9356
setstate dbRepBad3 2021-02-08 09:09:14 2021-02-01__HzgThermostatBad__measured-temp__AVGAM__2021-02 23.2030
setstate dbRepBad3 2021-02-08 09:09:14 state done


Diese Readings habe ich nun in einen plot eingebaut, der auch gut funktioniert hat (zumindest am Anfang). Jetzt habe ich nach einiger Zeit mal wieder auf den Plot geschaut und muss sehen, dass da täglich Werte berechnet worden sind - gut das at-Kommando läuft jeden Tag. Aber

set dbRepBad3 averageValue display
zeigt mir ja auch nur die Monatswerte an...

Woher kommen dann die vielen "Zwischenwerte" für jeden Tag, die ich in der SQL-Datenbank auch sehe...

Viele Grüße
Wolfgang
Titel: Antw:Bin ich zu blöd, oder was läuft hier falsch
Beitrag von: ch.eick am 08 Februar 2021, 09:35:40
Zitat von: wowogiengen am 08 Februar 2021, 09:22:37
zeigt mir ja auch nur die Monatswerte an...

Woher kommen dann die vielen "Zwischenwerte" für jeden Tag, die ich in der SQL-Datenbank auch sehe...
Hallo Wolfgang,
ich gebe jetzt mal meine Prognose an.
Da Du täglich den Monatsdurchschnitt berechnest, wird auch jeden Tag der neue Durchschnitt des laufenden Monats in die DB eingetragen ;-)
Wenn Du mit deleteOther arbeitest, werden alle Einzelwerte gelöscht und es steht nur noch der Durchschnitt in der DB.
Nun gibt es zwei Varianten:
1. Der Monatsdurchschnitt wird erst zu Beginn des Folgemonats berechnet, was dann nur ein mal passiert.
2. Du löscht vor der Berechnung den Durchschnittswert des laufenden Monats und lässt Ihn dann wieder neu erstellen. Dadurch hast Du dann einen sich ändernden Durchschnittswert im laufenden Monat.

Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: wowogiengen am 08 Februar 2021, 10:52:35
Hallo,
wenn der Monatsdurchschnitt sich immer auf 30 Tage bezieht (ausgehend vom Attribut "timestamp_end previous_day_end"),dann ist klar, dass jeden Tag ein anderer Mittelwert rauskommt.

Wenn ich die beiden timestamp-Attribute lösche, wird dann bei einmaliger Berechnung für alle vergangenen Monate pro Monat ein Wert berechnet? Ich sollte natürlich vorher die bereits in der DB eingetragenen Mittelwerte löschen...

Viele Grüße
Wolfgang

[Edit, nachdem ich zu Hause bin...]...

Mir ist jetzt klar, wieso jeden Tag ein neuer Wert dazu kommt... das ist ja dann der Mittelwert des aktuellen Monats, aber nur bis "heute" eben...
In anderen Threads des Forums habe ich gelesen, wie ich mit einer if-Abfrage das at-Kommando so modifizieren kann, dass es nur noch am ersten des Monats triggert - wobei das bestimmt auch mit einem DoIf möglich wäre...

VG
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Februar 2021, 18:20:58
Zitat von: wowogiengen am 08 Februar 2021, 10:52:35
Mir ist jetzt klar, wieso jeden Tag ein neuer Wert dazu kommt... das ist ja dann der Mittelwert des aktuellen Monats, aber nur bis "heute" eben...
In anderen Threads des Forums habe ich gelesen, wie ich mit einer if-Abfrage das at-Kommando so modifizieren kann, dass es nur noch am ersten des Monats triggert - wobei das bestimmt auch mit einem DoIf möglich wäre...
Okay, das wäre dann meine beschriebene Variante, das DbRep nur einmal am Monatsanfang laufen zu lassen, um den Durchschnitt des letzten Monats zu berechnen.

Im DOIF...

...
DOELSEIF
([01:07] and ($mday==1))

...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: wowogiengen am 08 Februar 2021, 18:25:31
Hallo,

die Lösung für mein Problem wird jetzt wohl so sein, dass ich die beiden Attribute

attr dbRepBad3 timestamp_begin previous_month_begin
attr dbRepBad3 timestamp_end previous_month_end

entsprechend setze, und dann noch das at modifiziere (siehe https://forum.fhem.de/index.php/topic,49461.msg414143.html#msg414143 (https://forum.fhem.de/index.php/topic,49461.msg414143.html#msg414143)):


define atdbRepBad3 at *00:40 {if ((strftime "%d",localtime time) eq "01") {set dbRepBad3 averageValue writeToDB}}
attr atdbRepBad3 room DbLog
attr atdbRepBad3 verbose 1
attr atdbRepBad3 webCmd execNow
attr atdbRepBad3 widgetOverride execNow

setstate atdbRepBad3 Next: 00:40:00
setstate atdbRepBad3 2021-02-08 18:21:14 state Next: 00:40:00



Damit sollte es dann gehen.

Viele Grüße
Wolfgang
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: wowogiengen am 08 Februar 2021, 19:54:41
Hallo,
ich hänge hier nochmal alles wesentliche ran, was für meine 4 Räume gedacht ist...
Am Ende hab ich dann doch noch mal eine Frage...


- Suffix 1 heißt max. Einschaltdauer PWMR / Heizungsventil pro Tag
- Suffix 2 heißt Tagesdurchschnitt Temperatur
- Suffix 3 heißt Monatsdurchschnitt Temperatur

Zunächst mal die at-Befehle, um die max. Werte der Einschaltdauer der Heizung für jeden Raum abzulegen:

define atdbRepBad1 at *00:00 set dbRepBad1 maxValue writeToDB
define atdbRepBuero1 at *01:00 set dbRepBuero1 maxValue writeToDB
define atdbRepSchlafzimmer1 at *02:00 set dbRepSchlafzimmer1 maxValue writeToDB
define atdbRepWohnzimmer1 at *03:00 set dbRepWohnzimmer1 maxValue writeToDB


Dann das selber für die Durchschnittstemperatur im Raum:


define atdbRepBad2 at *00:20 set dbRepBad2 averageValue writeToDB
define atdbRepBuero2 at *01:20 set dbRepBuero2 averageValue writeToDB
define atdbRepSchlafzimmer2 at *02:20 set dbRepSchlafzimmer2 averageValue writeToDB
define atdbRepWohnzimmer2 at *03:20 set dbRepWohnzimmer2 averageValue writeToDB



Und schlussendlich, einmal im Monat, für jeden Raum die Durchschnittstemperatur pro Monat

define atdbRepBad3 at *00:40 {if ((strftime "%d",localtime time) eq "01") {set dbRepBad3 averageValue writeToDB}}
define atdbRepBuero3 at *00:40 {if ((strftime "%d",localtime time) eq "01") {set dbRepBuero3 averageValue writeToDB}}
define atdbRepSchlafzimmer3 at *00:40 {if ((strftime "%d",localtime time) eq "01") {set dbRepSchlafzimmer3 averageValue writeToDB}}
define atdbRepWohnzimmer3 at *00:40 {if ((strftime "%d",localtime time) eq "01") {set dbRepWohnzimmer3 averageValue writeToDB}}


Jetzt für jeden Raum die einzelnen DbRep-Kommandos, nach Raum getrennt:
Tageshöchstwerte

define dbRepBad1 DbRep mySQLDB
attr dbRepBad1 aggregation day
attr dbRepBad1 allowDeletion 1
attr dbRepBad1 reading pulseTimePerDay
attr dbRepBad1 timestamp_begin previous_day_begin
attr dbRepBad1 timestamp_end previous_day_end



define dbRepBuero1 DbRep mySQLDB
attr dbRepBuero1 aggregation day
attr dbRepBuero1 allowDeletion 1
attr dbRepBuero1 reading pulseTimePerDay
attr dbRepBuero1 timestamp_begin previous_day_begin
attr dbRepBuero1 timestamp_end previous_day_end



define dbRepSchlafzimmer1 DbRep mySQLDB
attr dbRepSchlafzimmer1 aggregation day
attr dbRepSchlafzimmer1 allowDeletion 1
attr dbRepSchlafzimmer1 reading pulseTimePerDay
attr dbRepSchlafzimmer1 timestamp_begin previous_day_begin
attr dbRepSchlafzimmer1 timestamp_end previous_day_end



define dbRepWohnzimmer1 DbRep mySQLDB
attr dbRepWohnzimmer1 aggregation day
attr dbRepWohnzimmer1 allowDeletion 1
attr dbRepWohnzimmer1 reading pulseTimePerDay
attr dbRepWohnzimmer1 timestamp_begin previous_day_begin
attr dbRepWohnzimmer1 timestamp_end previous_day_end

Tagesdurchschnitte

define dbRepBad2 DbRep mySQLDB
attr dbRepBad2 aggregation day
attr dbRepBad2 allowDeletion 1
attr dbRepBad2 reading measured-temp
attr dbRepBad2 timestamp_begin previous_day_begin
attr dbRepBad2 timestamp_end previous_day_end



define dbRepBuero2 DbRep mySQLDB
attr dbRepBuero2 aggregation day
attr dbRepBuero2 allowDeletion 1
attr dbRepBuero2 reading measured-temp
attr dbRepBuero2 timestamp_begin previous_day_begin
attr dbRepBuero2 timestamp_end previous_day_end



define dbRepSchlafzimmer2 DbRep mySQLDB
attr dbRepSchlafzimmer2 aggregation day
attr dbRepSchlafzimmer2 allowDeletion 1
attr dbRepSchlafzimmer2 reading measured-temp
attr dbRepSchlafzimmer2 timestamp_begin previous_day_begin
attr dbRepSchlafzimmer2 timestamp_end previous_day_end


define dbRepWohnzimmer2 DbRep mySQLDB
attr dbRepWohnzimmer2 aggregation day
attr dbRepWohnzimmer2 allowDeletion 1
attr dbRepWohnzimmer2 reading measured-temp
attr dbRepWohnzimmer2 timestamp_begin current_year_begin


Monatsdurchschnitte



define dbRepBad3 DbRep mySQLDB
attr dbRepBad3 aggregation month
attr dbRepBad3 allowDeletion 1
attr dbRepBad3 reading measured-temp
attr dbRepBad3 timestamp_begin previous_month_begin
attr dbRepBad3 timestamp_end previous_month_end




define dbRepBuero3 DbRep mySQLDB
attr dbRepBuero3 aggregation month
attr dbRepBuero3 allowDeletion 1
attr dbRepBuero3 reading measured-temp
attr dbRepBuero3 timestamp_begin previous_month_begin
attr dbRepBuero3 timestamp_end previous_month_end



define dbRepSchlafzimmer3 DbRep mySQLDB
attr dbRepSchlafzimmer3 aggregation month
attr dbRepSchlafzimmer3 allowDeletion 1
attr dbRepSchlafzimmer3 reading measured-temp
attr dbRepSchlafzimmer3 timestamp_begin previous_month_begin
attr dbRepSchlafzimmer3 timestamp_end previous_month_end



define dbRepWohnzimmer3 DbRep mySQLDB
attr dbRepWohnzimmer3 aggregation month
attr dbRepWohnzimmer3 allowDeletion 1
attr dbRepWohnzimmer3 reading measured-temp
attr dbRepWohnzimmer3  timestamp_begin previous_month_begin
attr dbRepWohnzimmer3  timestamp_end previous_month_end


Zum einen hab ich jetzt hier für jeden Raum 3 x ein AT, und 3 x ein dbRep, um mir die 3 Werte berechnen zu lassen.
Ich brauche also hier 12 AT-Devices und 12 DbRep-Devices. zum Glück kommen keine Räume mehr dazu, in den anderen ist zwar ein Thermostat drin, aber keine Heizung an...

Kann man das nicht eleganter lösen, so dass man es auch einfacher warten kann?
Die at-Befehle kann ich auch nicht gleichzeitig ausführen lassen, da die dbRep sich gegenseitig sperren... der erste geht, und die nachfolgenden bekommen Fehler beim DB-Zugriff.


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Februar 2021, 22:06:46
Zitat
Kann man das nicht eleganter lösen, so dass man es auch einfacher warten kann?
Die at-Befehle kann ich auch nicht gleichzeitig ausführen lassen, da die dbRep sich gegenseitig sperren... der erste geht, und die nachfolgenden bekommen Fehler beim DB-Zugriff.
Ich bin ein Freund von DOIF, somit könntest Du alles in ein DOIF, eventuell mit einem gewünschtem wait abarbeiten.
Dann könntest Du die Statistiken auch eventuell in einem SQL Skript abarbeiten.

@Heiko: Kann man eigentlich alle "maxValue writeToDB"  in ein DbRep mit einer reading Maske eintragen?

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Februar 2021, 23:00:48
Hallo zusammen,
Ich rufe folgendes auf, um einen Wert zur vollen Stunde abzufragen:
$i läuft dabei von 7-19

my $Solar_Correction_Faktor_fc0 = DbReadingsVal("LogDBRep_select_PV_Forecast","PV_1:fc0_Factor",sprintf("%4d-%02d-%02d_%02d:00:00",$year,$mon,$mday,$i),1) ;


Nach 17:00 Uhr sollte dann eigentlich nichts mehr kommen und der Faktor auf 1 gesetzt werden

SELECT * from history where DEVICE='PV_1' AND READING='fc0_Factor' AND TIMESTAMP > CURDATE();
+---------------------+--------+------+-------+------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE | EVENT | READING    | VALUE | UNIT |
+---------------------+--------+------+-------+------------+-------+------+
| 2021-02-08 09:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 6.9   | NULL |
| 2021-02-08 10:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 5.0   | NULL |
| 2021-02-08 11:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.9   | NULL |
| 2021-02-08 12:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.9   | NULL |
| 2021-02-08 13:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.8   | NULL |
| 2021-02-08 14:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.9   | NULL |
| 2021-02-08 15:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 2.0   | NULL |
| 2021-02-08 16:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 2.0   | NULL |
+---------------------+--------+------+-------+------------+-------+------+


Das List vom DbRep nach dem Lauf

Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      5f50bc9b-f33f-61a8-e635-e249a4e08a2531c6
   FVERSION   93_DbRep.pm:v8.42.3-s23462/2021-01-03
   LASTCMD    sqlCmdBlocking select value from (
                ( select *, TIMESTAMPDIFF(SECOND, '2021-02-08 19:00:00', timestamp) as diff from history
                  where device='PV_1' and reading='fc0_Factor' and timestamp >= '2021-02-08 19:00:00' order by timestamp asc limit 1
                )
                union
                ( select *, TIMESTAMPDIFF(SECOND, timestamp, '2021-02-08 19:00:00') as diff from history
                  where device='PV_1' and reading='fc0_Factor' and timestamp < '2021-02-08 19:00:00' order by timestamp desc limit 1
                )
              ) x order by diff limit 1;
   MODEL      Client
   NAME       LogDBRep_select_PV_Forecast
   NOTIFYDEV  global,LogDBRep_select_PV_Forecast
   NR         478
   NTFY_ORDER 50-LogDBRep_select_PV_Forecast
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     IDRETRIES  3
     PACKAGE    main
     SQLHIST   
     VERSION    8.42.3
   OLDREADINGS:
   READINGS:
     2021-01-04 15:40:02   index_state     Index Report_Idx exists
     2021-02-08 22:49:51   state           done
Attributes:
   DbLogExclude .*
   readingNameMap VALUE
   room       System


Habe ich da ein Attribut vergessen?

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 09 Februar 2021, 18:17:19
EDIT: Jetzt habe ich es geschafft.
1. Es darf nur ein SQL Command sein.
2. Die Set Statements kommen ins Attribut sqlCmdVars
3. Das SQL DELETE habe ich ins INSERT integriert

Dann sieht das jetzt so als RAW aus

defmod LogDBRep_insert_PV_Forecast_correction DbRep LogDB
attr LogDBRep_insert_PV_Forecast_correction DbLogExclude .*
attr LogDBRep_insert_PV_Forecast_correction room System
attr LogDBRep_insert_PV_Forecast_correction sqlCmdVars SET @days:=3, @corr:=0.7, @diff:=0, @temp:=0, @device:='PV_1', @reading1:='Total_DC_Power_(sumOfAllPVInputs)', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;;

Und wird so aufgerufen :-) :-)

set LogDBRep_insert_PV_Forecast_correction sqlCmd   INSERT INTO history  (TIMESTAMP,DEVICE,READING,VALUE)  SELECT  TIMESTAMP,DEVICE,READING,VALUE  FROM (  SELECT  DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,  t2.DEVICE,  @readingname AS READING,  cast(if(avg(t2.FACTOR) > 1.6, 1.6,  avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE  FROM (  SELECT * FROM (  SELECT  t1.TIMESTAMP,  t1.HOUR,  t1.DEVICE,  t1.READING,  t1.VALUE,  if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,  cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(2,1)) AS FACTOR,  @diff:=t1.VALUE AS curr_V  FROM (  SELECT  TIMESTAMP,  date(TIMESTAMP) AS DATE,  hour(TIMESTAMP) AS HOUR,  DEVICE,  READING,  VALUE  FROM history  WHERE DEVICE = @device  AND (READING = @reading1 OR READING = @reading2)  AND TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY)  AND TIMESTAMP <= CURDATE()  AND MINUTE(TIMESTAMP) = 0  AND VALUE >= 0  GROUP BY DATE,HOUR,READING  )t1  )tx  WHERE  READING != @reading2  )t2  GROUP BY t2.HOUR  )t3  WHERE  t3.VALUE != 0  ON DUPLICATE KEY UPDATE  VALUE=t3.VALUE;


Im Perl baut man das dann lieber folgendermaßen ein, damit man es auch lesen kann.

         # Neuberechnung der stündlichen Autokorrektur Faktoren in der Datenbank. Das DbRep Device LogDBRep_insert_PV_Forecast_correction muss vorhanden sein.
         # Achtung, beim SQL muss '@' mit '\@' maskiert werden.
         CommandSet(undef, "LogDBRep_insert_PV_Forecast_correction sqlCmd ".sprintf("
                INSERT INTO history
                 (TIMESTAMP,DEVICE,READING,VALUE)
                  SELECT
                    TIMESTAMP,DEVICE,READING,VALUE
                  FROM (
                    SELECT
                      DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,
                      t2.DEVICE,
                      \@readingname                             AS READING,
                      cast(if(avg(t2.FACTOR) > 1.6, 1.6,
                              avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE
                    FROM (
                      SELECT * FROM (
                        SELECT
                          t1.TIMESTAMP,
                          t1.HOUR,
                          t1.DEVICE,
                          t1.READING,
                          t1.VALUE,
                          if(\@diff = 0,NULL, \@temp:=cast((t1.VALUE-\@diff) AS DECIMAL(6,2))) AS DIFF,
                          cast((t1.VALUE/(t1.VALUE+(-1*\@temp))*\@corr) AS DECIMAL(2,1))       AS FACTOR,
                          \@diff:=t1.VALUE                                                     AS curr_V
                        FROM (
                          SELECT
                            TIMESTAMP,
                            date(TIMESTAMP) AS DATE,
                            hour(TIMESTAMP) AS HOUR,
                            DEVICE,
                            READING,
                            VALUE
                          FROM history
                          WHERE DEVICE    =  \@device
                            AND (READING  =  \@reading1 OR READING = \@reading2)
                            AND TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL \@days DAY)
                            AND TIMESTAMP <= CURDATE()
                            AND MINUTE(TIMESTAMP) = 0
                            AND VALUE >= 0
                          GROUP BY DATE,HOUR,READING
                         )t1
                       )tx
                        WHERE
                          READING != \@reading2
                     )t2
                      GROUP BY t2.HOUR
                   )t3
                    WHERE
                      t3.VALUE != 0
                    ON DUPLICATE KEY UPDATE
                      VALUE=t3.VALUE;
           ") # Ende sprintf()
         );   # Ende CommandSet()



==============================================================================
Moin,
dann habe ich noch ein sqlCmd :-) Okay, es ist schon ein Skript :-)


SET @device='PV_1';
SET @reading1='Total_DC_Power_(sumOfAllPVInputs)';
SET @reading2='Solar_Calculation_fc0';
SET @readingname='Solar_Correction_Faktor_auto';

DELETE FROM history WHERE DEVICE=@device AND READING=@readingname AND TIMESTAMP >= CURDATE();

SET @diff=0;SET @temp=0;
INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE)
  SELECT TIMESTAMP,DEVICE,READING,VALUE
    FROM (

SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,
       t2.DEVICE,
       @readingname                              AS READING,
       cast(if(avg(t2.FACTOR) > 1.6, 1,
               avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE
  FROM
    (
     SELECT t1.TIMESTAMP,
            t1.HOUR,
            t1.DEVICE,
            t1.READING,
            t1.VALUE,
            if(@diff  = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,
            cast((t1.VALUE/(t1.VALUE+(-1*@temp))*0.5) AS DECIMAL(2,1))         AS FACTOR,
            @diff:=t1.VALUE                                                    AS curr_V
       FROM
         (
          SELECT TIMESTAMP,
                 date(TIMESTAMP) AS DATE,
                 hour(TIMESTAMP) AS HOUR,
                 DEVICE,
                READING,
                 VALUE
            FROM history
            WHERE
              DEVICE    =    @device    AND
              (READING  =    @reading1  OR
               READING  =    @reading2) AND
              TIMESTAMP >=   DATE_SUB(DATE(now()),INTERVAL 30 DAY) AND
              TIMESTAMP <    CURDATE()  AND
              TIMESTAMP LIKE '%:00:%'   AND
              VALUE >= 0
           GROUP BY DATE,HOUR,READING
         )t1
       WHERE
         READING != @reading2 AND
         VALUE   != 0
    )t2
    GROUP BY t2.HOUR

  )t3
  WHERE
    t3.VALUE != 0;

SELECT * FROM history WHERE DEVICE=@device AND READING=@readingname AND TIMESTAMP >= CURDATE();

+---------------------+--------+------+-------+------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE | EVENT | READING    | VALUE | UNIT |
+---------------------+--------+------+-------+------------+-------+------+
| 2021-02-09 08:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.1   | NULL |
| 2021-02-09 09:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.0   | NULL |
| 2021-02-09 10:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.0   | NULL |
| 2021-02-09 11:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 1.0   | NULL |
| 2021-02-09 12:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.7   | NULL |
| 2021-02-09 13:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.5   | NULL |
| 2021-02-09 14:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.5   | NULL |
| 2021-02-09 15:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.4   | NULL |
| 2021-02-09 16:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.2   | NULL |
| 2021-02-09 17:00:00 | PV_1   | NULL | NULL  | fc0_Factor | 0.1   | NULL |
+---------------------+--------+------+-------+------------+-------+------+


Aber DbRep sagt syntax Error

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        LogDB
   FUUID      6022bc3d-f33f-61a8-b1e2-254f5e37a3bd4fbd
   FVERSION   93_DbRep.pm:v8.42.3-s23462/2021-01-03
   LASTCMD    sqlCmd SET @device='PV_1'; SET @reading1='Total_DC_Power_(sumOfAllPVInputs)'; SET @reading2='Solar_Calculation_fc0'; SET @readingname='fc0_Factor'; SET @diff=0;SET @temp=0; DELETE from history where DEVICE=@device AND READING=@readingname AND TIMESTAMP >= CURDATE(); INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE)  SELECT TIMESTAMP,DEVICE,READING,VALUE  FROM (  SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,  t2.DEVICE,  @readingname AS READING,  cast(if(avg(t2.FACTOR) > 1.6, 1,  avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE  FROM  (  SELECT t1.TIMESTAMP,  t1.HOUR,  t1.DEVICE,  t1.READING,  t1.VALUE,  if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,  cast((t1.VALUE/(t1.VALUE+(-1*@temp))*0.5) AS DECIMAL(2,1)) AS FACTOR,  @diff:=t1.VALUE AS curr_V  FROM   (  SELECT TIMESTAMP,  date(TIMESTAMP) AS DATE,  hour(TIMESTAMP) AS HOUR,  DEVICE,  READING,  VALUE  FROM history  WHERE  DEVICE = @device AND  (READING = @reading1 OR  READING = @reading2) AND  TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL 30 DAY) AND  TIMESTAMP < CURDATE() AND  TIMESTAMP LIKE '%:00:%' AND  VALUE >= 0  GROUP BY DATE,HOUR,READING  )t1  WHERE  READING != @reading2 AND  VALUE != 0  )t2  GROUP BY t2.HOUR   )t3  WHERE  t3.VALUE != 0;  SELECT * from history where DEVICE=@device AND READING=@readingname AND TIMESTAMP >= CURDATE();
   MODEL      Client
   NAME       LogDBRep_insert_PV_Forecast_correction
   NOTIFYDEV  global,LogDBRep_insert_PV_Forecast_correction
   NR         148652
   NTFY_ORDER 50-LogDBRep_insert_PV_Forecast_correction
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     USAGE,ALL PRIVILEGES
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST   
     VERSION    8.42.3
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1612889149.94504
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2021-02-09 17:52:40   errortext       DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE)  SELECT TIMESTAMP,DEVICE,RE' at line 1 at ./FHEM/93_DbRep.pm line 6414.

     2021-02-09 17:52:40   state           error
Attributes:
   DbLogExclude .*
   allowDeletion 1
   room       System
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 Februar 2021, 10:54:58
Hi, ich nochmal mit einer weiteren Frage.

Ich verwende DbReadingsVal() zum Auslesen einzelner Werte aus der DB, jedoch stimmen die Rückgabewerte nicht.
Wenn ein Eintrag nicht vorhanden ist, soll 1 als Default kommen, jedoch wird 0.1 geliefert.

{ DbReadingsVal("LogDBRep_select_PV_Forecast","PV_1:Solar_Correction_Faktor_auto","2021-02-10_09:00:00",1) }


Die Daten

select * FROM history WHERE DEVICE=@device AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP >= CURDATE();
+---------------------+--------+------+-------+------------------------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE | EVENT | READING                      | VALUE | UNIT |
+---------------------+--------+------+-------+------------------------------+-------+------+
| 2021-02-10 08:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.1   | NULL |
| 2021-02-10 09:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 1.5   | NULL |
| 2021-02-10 10:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 1.0   | NULL |
| 2021-02-10 11:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 1.0   | NULL |
| 2021-02-10 12:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.7   | NULL |
| 2021-02-10 13:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.5   | NULL |
| 2021-02-10 14:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.5   | NULL |
| 2021-02-10 15:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.4   | NULL |
| 2021-02-10 16:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.2   | NULL |
| 2021-02-10 17:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.1   | NULL |
+---------------------+--------+------+-------+------------------------------+-------+------+
10 rows in set (0.026 sec)

{ DbReadingsVal("LogDBRep_select_PV_Forecast","PV_1:Solar_Correction_Faktor_auto","2021-02-10_09:00:00",1) }
==> 1.5

MySQL [fhem]> delete FROM history WHERE DEVICE=@device AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP >= CURDATE();
Query OK, 10 rows affected (0.036 sec)

MySQL [fhem]> select * FROM history WHERE DEVICE=@device AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP >= CURDATE();
Empty set (0.021 sec)

{ DbReadingsVal("LogDBRep_select_PV_Forecast","PV_1:Solar_Correction_Faktor_auto","2021-02-10_09:00:00",1) }
==> 0.1


Das verwendete SELECT findet wohl den letzen Eintrag in der Datenbank, also bei mir vom Vortag.

select * FROM history WHERE DEVICE=@device AND READING='Solar_Correction_Faktor_auto'  AND TIMESTAMP >= '2021-02-09' and TIMESTAMP < '2021-02-10';
+---------------------+--------+------+-------+------------------------------+-------+------+
| TIMESTAMP           | DEVICE | TYPE | EVENT | READING                      | VALUE | UNIT |
+---------------------+--------+------+-------+------------------------------+-------+------+
...snip...
| 2021-02-09 17:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.1   | NULL |
+---------------------+--------+------+-------+------------------------------+-------+------+

select value from (
                 ( select *, TIMESTAMPDIFF(SECOND, '2021-02-10 09:00:00', timestamp) as diff from history
                   where device='PV_1' and reading='Solar_Correction_Faktor_auto' and timestamp >= '2021-02-10 09:00:00' order by timestamp asc limit 1
                 )
                 union
                 ( select *, TIMESTAMPDIFF(SECOND, timestamp, '2021-02-10 09:00:00') as diff from history
                   where device='PV_1' and reading='Solar_Correction_Faktor_auto' and timestamp < '2021-02-10 09:00:00' order by timestamp desc limit 1
                 )
               ) x order by diff limit 1;
+-------+
| value |
+-------+
| 0.1   |
+-------+


select *, TIMESTAMPDIFF(SECOND, timestamp, '2021-02-10 09:00:00') as diff from history
                    where device='PV_1' and reading='Solar_Correction_Faktor_auto' and timestamp < '2021-02-10 09:00:00' order by timestamp desc limit 1 ;
+---------------------+--------+------+-------+------------------------------+-------+------+-------+
| TIMESTAMP           | DEVICE | TYPE | EVENT | READING                      | VALUE | UNIT | diff  |
+---------------------+--------+------+-------+------------------------------+-------+------+-------+
| 2021-02-09 17:00:00 | PV_1   | NULL | NULL  | Solar_Correction_Faktor_auto | 0.1   | NULL | 57600 |
+---------------------+--------+------+-------+------------------------------+-------+------+-------+


Ich denke die Art der SQL Abfrage wird eine besondere Bewandtnis haben, bzw mit der Datenbank Kompatibilität zusammen hängen.

Gruß
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Februar 2021, 18:11:37
Hallo zusammen,
eins der geledeten Problem hat sich jetzt erledigt:
DbRep mit ziemlich langem SQL (https://forum.fhem.de/index.php/topic,53584.msg1130748.html#msg1130748)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Februar 2021, 20:42:20
Hallo Christian,

ZitatWenn ein Eintrag nicht vorhanden ist, soll 1 als Default kommen, jedoch wird 0.1 geliefert.
Dann gibt es wahrscheinlich noch einen Wert in der zeitlichen "Nähe".

Commandref sagt dazu:

(*) Es wird der zeitlich zu <timestamp> passendste Readingwert zurück geliefert, falls kein Wert exakt zu dem angegebenen Zeitpunkt geloggt wurde.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Februar 2021, 22:59:59
EDIT: Ich habe nun nochmal diverse Abfragen getestet.

1.) Wenn es das reading überhaupt nicht gibt, wird der Defaultwerte zurück gegeben.
2.) Wenn ich in einem Zeitraum weit vor dem ersten Eintrag abfrage wird 0.1 , was wohl der erste oder letzte Eintrag ist, zurückgemeldet.

Es scheint mir so, als ob immer der nächstliegende Wert ermittelt wird, egal wie weit er entfernt ist.
Das ist leider nichts, was ich für meine Anwendung verwenden könnte, da es nur Einträge gibt, die >0 sind und auch meistens 12h auseinander, oder auch mal Tagelang gar keine.

Wenn die Funktion so gedacht ist und es sich um keinen Fehler handelt würde ich für mich nach einer anderen Lösung suchen.
EDIT: Als Workaround verwende ich nun folgendes

$Solar_Correction_Faktor_auto = CommandGet(undef, $logdbrep." sqlCmdBlocking SELECT VALUE FROM history WHERE DEVICE='".$logdevice."' AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP='2021-02-16 12:00:00';") ;
if($Solar_Correction_Faktor_auto eq "") { $Solar_Correction_Faktor_auto = 1; };

Hierbei ist jedoch etwas unschön, das das Attribut sqlCmdVars wohl beim sqlCmd, jedoch nicht beim sqlCmdBlocking eine Wirkung hat.
Das bewirkt, dass man die Variablen dann doch wieder aus dem Perl Code heraus setzen muss.

Für meine Anforderung läuft es nun, ich stehe jedoch für eventuelle tests zur Verfügung :-)

VG
   Christian

====================================================================================
Hallo Heiko,
da biste ja wieder :-)

Zitat von: DS_Starter am 15 Februar 2021, 20:42:20
Dann gibt es wahrscheinlich noch einen Wert in der zeitlichen "Nähe".

Commandref sagt dazu:

(*) Es wird der zeitlich zu <timestamp> passendste Readingwert zurück geliefert, falls kein Wert exakt zu dem angegebenen Zeitpunkt geloggt wurde.
Das war mir schon bekannt und ich habe direkt mal nachgesehen. Der letzte Eintrag war am Vortag, ich versuche es morgen nochmal nachzustellen.
Wenn ich aber einen Wert um 7:00 abfrage darf nicht der letzte Wert vom Vortag kommen. Wofür ist ansonsten der Default Wert in der Funktion.
Wie soll man denn "passendste" definieren? Minuten,Stunden; der letze in der Datenbank?
Es ist natürlich schön, wenn man nicht exact die Zeit treffen muss, das macht es etwas einfacher bei den häufigen Werten.
In meinem Fall ist der Wert jedoch 12 Stunden alt und ich hatte erwartet, dass dann die 1 als Default kommt, die ich der Funktion mitgegeben hatte.

Das sollte nochmal geklärt werden, oder ich muss es halt wieder als eigenes SQL abbilden, da ich ja nicht überblicken kann, wie es andere verwenden.

Gibt es eventuell eine Abfrage, die ich alternativ verwenden könnte?

VG Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 25 Februar 2021, 10:54:39
Grünlandtemperaturberechnung:

Moin

ich habe es jetzt soweit, dass die Grünladtemperatur ausgegeben wird.
Mit dem manuellen Befehl set Rep.Temp.greenland writetodb werden n verschiedene Readings geschrieben, die ich aber nicht auswerten kann.

Wie kann man das nun einstellen, dass der die Berechnung jeden Tag macht und für dieses Datum einen Wert ablegt?
Ziel ist es, das für jeden Tag die Grünladtemperatur in die Datenbank geschrieben werden soll, damit ich auch ein Plot daraus erstellen kann. Also die Entwicklung der Werte visualisieren.
Danke für die Unterstützung.

Gruß
Kobi
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 Februar 2021, 11:09:25
Zitat von: kobi1980 am 25 Februar 2021, 10:54:39
Wie kann man das nun einstellen, dass der die Berechnung jeden Tag macht und für dieses Datum einen Wert ablegt?
Ziel ist es, das für jeden Tag die Grünladtemperatur in die Datenbank geschrieben werden soll, damit ich auch ein Plot daraus erstellen kann. Also die Entwicklung der Werte visualisieren.
Über eine Timer das DbRep aufrufen :-)
Ich mag DOIF und verwende das für Scheduling Aufgaben, oder halt WeekdayTimer, oder was auch immer.

VG Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 25 Februar 2021, 12:04:56
Moin

Das mit dem DOIF macht schon Sinn :-)

Und wie bekomme ich das hin, dass diese Werte für nen Plot genutzt werden können ?

Die ermittelten Readings sehen ja so aus:
2021-02-16__WEEWX__Aussentemperatur__GrasslandTemperatureSum 1.8
2021-02-17__WEEWX__Aussentemperatur__GrasslandTemperatureSum 5.9
2021-02-18__WEEWX__Aussentemperatur__GrasslandTemperatureSum 11.5
2021-02-19__WEEWX__Aussentemperatur__GrasslandTemperatureSum 16.2

Es müsste doch jeden Tag solch ein Wert gespeichert werden, damit man auch einen Plot erstellen kann
Timestamp = DOIF Datum/Zeit
Reading = z.B. Gruenlandtemperatursumme


@Heiko warum wird die GrasslandTemperatureSum nicht richtig ermittelt?

READINGS:
     2021-02-25 11:46:35   2021-02-15__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-15 -0.7
     2021-02-25 11:46:35   2021-02-15__WEEWX__Aussentemperatur__GrasslandTemperatureSum 0.0
     2021-02-25 11:46:35   2021-02-16__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-16 2.3
     2021-02-25 11:46:35   2021-02-16__WEEWX__Aussentemperatur__GrasslandTemperatureSum 1.8
     2021-02-25 11:46:35   2021-02-17__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-17 5.5
     2021-02-25 11:46:35   2021-02-17__WEEWX__Aussentemperatur__GrasslandTemperatureSum 5.9
     2021-02-25 11:46:35   2021-02-18__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-18 7.5
     2021-02-25 11:46:35   2021-02-18__WEEWX__Aussentemperatur__GrasslandTemperatureSum 11.5
     2021-02-25 11:46:35   2021-02-19__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-19 6.2
     2021-02-25 11:46:35   2021-02-19__WEEWX__Aussentemperatur__GrasslandTemperatureSum 16.2
     2021-02-25 11:46:35   2021-02-20__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-20 8.6
     2021-02-25 11:46:35   2021-02-20__WEEWX__Aussentemperatur__GrasslandTemperatureSum 22.6
     2021-02-25 11:46:35   2021-02-21__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-21 10.3
     2021-02-25 11:46:35   2021-02-21__WEEWX__Aussentemperatur__GrasslandTemperatureSum 30.3
     2021-02-25 11:46:35   2021-02-22__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-22 10.4
     2021-02-25 11:46:35   2021-02-22__WEEWX__Aussentemperatur__GrasslandTemperatureSum 38.1
     2021-02-25 11:46:35   2021-02-23__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-23 11.5
     2021-02-25 11:46:35   2021-02-23__WEEWX__Aussentemperatur__GrasslandTemperatureSum 46.8
     2021-02-25 11:46:35   2021-02-24__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-24 13.5
     2021-02-25 11:46:35   2021-02-24__WEEWX__Aussentemperatur__GrasslandTemperatureSum 56.9
     2021-02-25 11:46:35   background_processing_time 0.5401
     2021-02-25 11:46:35   db_lines_processed 20
     2021-02-25 11:46:35   sql_processing_time 0.5175
     2021-02-25 11:46:35   state           done
Attributes:
   averageCalcForm avgDailyMeanGWSwithGTS
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     WEEWX
   fastStart  1
   reading    Aussentemperatur
   showproctime 1
   timestamp_begin previous_week_begin
   timestamp_end previous_day_end
   verbose    3



Gruß
Korbinian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 Februar 2021, 12:29:33
Zitat von: kobi1980 am 25 Februar 2021, 10:54:39
Mit dem manuellen Befehl set Rep.Temp.greenland writetodb werden n verschiedene Readings geschrieben, die ich aber nicht auswerten kann.

writetodb schreibt die Werte doch in die Datenbank, dort wird jedoch ein neuer Name für READING verwendet.
Im Diagramm kannst Du dann diesen neuen Namen verwenden.

Um Dir alle readings anzuzeigen, die zuletzt geschrieben wurden habe ich mal ein SQL geschrieben, was Du unter sqlSpecial findest,
falls Du selber kein SQL kannst.

attr Rep.Temp.greenland device <Dein Device Name>
set Rep.Temp.greenland sqlSpecial recentReadingsOfDevice

Dort sollten dann auch die neuen readings zu erkennen sein.

EDIT: Sorry, ich habe jetzt erst das Bild angeschaut ;-)
     Man kann wohl auch den Basis Namen für die neuen readings überschreiben.   >>> Attribut readingNameMap
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 25 Februar 2021, 12:54:26
hmm.. klappt so leider nicht

readingNameMap GTS

alt:   2021-02-25 11:46:35   2021-02-24__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-24 13.5
neu: 2021-02-25__GTS__2021-02-25

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 Februar 2021, 13:04:23
Zitat von: kobi1980 am 25 Februar 2021, 12:54:26
hmm.. klappt so leider nicht

readingNameMap GTS

alt:   2021-02-25 11:46:35   2021-02-24__WEEWX__Aussentemperatur__AVGDMGWS__2021-02-24 13.5
neu: 2021-02-25__GTS__2021-02-25
Beschreibe bitte mal, wo genau das Problem ist? Eventuell meldet sich dann noch jemand zu Wort :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2021, 18:03:52
Hallo Korbinian,

gehen wir mal schrittweise vor ...

Zitat
@Heiko warum wird die GrasslandTemperatureSum nicht richtig ermittelt?
Wieso denkst du dass die GrasslandTemperatureSum nicht richtig ermittelt wird ?

Hinweis: Du musst timestamp_begin auf den Jahresanfang setzen (z.B. current_year_begin). Steht auch so in der Hilfe zum Attribut averageCalcForm = avgDailyMeanGWSwithGTS.

writeToDb kann in diesem Fall nicht verwendet weren, da es nur ein Zusatz zu avgDailyMeanGWS ist. Aber auch dafür gibt es eine Lösung. Aber das im zweiten Schritt.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 25 Februar 2021, 18:31:15
Hi

bei mit wird die Grünlandtemperatursumme täglich immer nur größer und hat bei "0" angefangen:
Die beiden Start / Ende Attribute hatte ich gesetzt, habe es jetzt aber auf current_year_begin gestellt.


Zitat von: kobi1980 am 25 Februar 2021, 12:04:56
     2021-02-25 11:46:35   2021-02-15__WEEWX__Aussentemperatur__GrasslandTemperatureSum 0.0
     2021-02-25 11:46:35   2021-02-16__WEEWX__Aussentemperatur__GrasslandTemperatureSum 1.8
     2021-02-25 11:46:35   2021-02-17__WEEWX__Aussentemperatur__GrasslandTemperatureSum 5.9
     2021-02-25 11:46:35   2021-02-18__WEEWX__Aussentemperatur__GrasslandTemperatureSum 11.5
     2021-02-25 11:46:35   2021-02-19__WEEWX__Aussentemperatur__GrasslandTemperatureSum 16.2
     2021-02-25 11:46:35   2021-02-20__WEEWX__Aussentemperatur__GrasslandTemperatureSum 22.6
     2021-02-25 11:46:35   2021-02-21__WEEWX__Aussentemperatur__GrasslandTemperatureSum 30.3
     2021-02-25 11:46:35   2021-02-22__WEEWX__Aussentemperatur__GrasslandTemperatureSum 38.1
     2021-02-25 11:46:35   2021-02-23__WEEWX__Aussentemperatur__GrasslandTemperatureSum 46.8
     2021-02-25 11:46:35   2021-02-24__WEEWX__Aussentemperatur__GrasslandTemperatureSum 56.9

Attributes:
   averageCalcForm avgDailyMeanGWSwithGTS
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     WEEWX
   fastStart  1
   reading    Aussentemperatur
   showproctime 1
   timestamp_begin previous_week_begin
   timestamp_end previous_day_end
   verbose    3

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2021, 18:39:57
Zitatbei mit wird die Grünlandtemperatursumme täglich immer nur größer und hat bei "0" angefangen:
Ja, so soll es auch sein.  ;)

Hier nochmal die Definition für diese Kennzahl:

Zitat
Die Grünlandtemperatursumme (GTS) ist eine Spezialform der Wachstumsgradtage, die in der Agrarmeteorologie verwendet wird. Sie wird herangezogen, um in Mitteleuropa den Termin für das Einsetzen der Feldarbeit nach dem Winter zu bestimmen.
Es werden ab Jahresbeginn alle positiven Tagesmittel erfasst. Im Januar wird mit dem Faktor 0,5 multipliziert, im Februar mit dem Faktor 0,75, und ab März geht dann der ,,volle" Tageswert (mal Faktor 1) in die Rechnung ein.
Wird im Frühjahr die Summe von 200 überschritten, ist der nachhaltige Vegetationsbeginn erreicht. Hintergrund ist die Stickstoffaufnahme und -verarbeitung des Bodens, welcher von dieser Temperatursumme abhängig ist. In mittleren Breiten wird das meist im Laufe des März, an der Wende von Vorfrühling zu Mittfrühling erreicht.
(siehe auch Grünlandtemperatursumme in Wikipedia)

Das kannst du auch nachlesen mit "get <> versionNotes 5" bzw. bei https://de.wikipedia.org/wiki/Gr%C3%BCnlandtemperatursumme.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 25 Februar 2021, 19:00:33
Alles klar.. mein Fehler.
Dann stimmen die Werte ja..

wie gehts mit Schritt 2 weiter :-)
Zitat von: DS_Starter am 25 Februar 2021, 18:03:52

writeToDb kann in diesem Fall nicht verwendet weren, da es nur ein Zusatz zu avgDailyMeanGWS ist. Aber auch dafür gibt es eine Lösung. Aber das im zweiten Schritt.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2021, 19:25:18
Ok, also wir können ja nicht wirklich die entstehenden Events aus der Berechnung in der DB speichern, weil der Timestamp des berechneten Readings nicht den wirklichen Bezug zum Zeitpunkt des berechneten Ergebnisses wiedergibt, z.B.:


2021-02-21__MyWetter__temperature__GrasslandTemperatureSum   69.8


sagt aus dass der GTS-Wert für den 21.02.2021 gilt, wobei dieser Wert mit dem Zeitpunkt in der DB landen würde der dem DbRep Lauf entspricht, also jetzt zum Beispiel.

Man kann folgendermaßen vorgehen:

1. definieren eines Notify welches den Event des DbRep-Devices und dem Reading .*GrasslandTemperatureSum.* abgreift
2. In dem Notify das relevante Datum extrahieren (steht ja am Anfang des Readings) und in die geforderte Zeitform für eine
    Speicherung in der DB überführen, d.h. in die Form "YYYY-MM-TT hh:mm:ss"
3. Im DbLog-Device einen Cache Eintrag erstellen, der dann in die DB geschrieben wird. Es gibt dazu einen addCacheLine Befehl
    im DbLog (set <dblog> addCacheLine YYYY-MM-DD HH:MM:SS|<device>|<type>|<event>|<reading>|<value>| )

DbLog muß dafür im asynchronen Mode laufen, aber das sollte ohnehin so sein.

Willst du dich mal an einer solchen Umsetzung versuchen ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 25 Februar 2021, 21:58:26
hi
danke für die Unterstützung, aber ich habe leider nicht mehr die Zeit, mich in das einzulesen, Foreneinträge und Wikieinträge querzulesen.
Mir reicht es dann per Knopfdruck die Daten zu erstellen und mir diese dann in Klartext und nicht per Plot anzuschauen.

VG Kobi
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2021, 22:02:56
Na vielleicht schreibe ich einen Wiki-Beitrag (DbRep) der genau dieses Szenario beschreibt.
Möglicherweise interessiert das auch andere User. Mal schauen.
Ist nicht so sehr umfangreich.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 Februar 2021, 22:09:42
Hallo Heiko,
hattest Du schon mal Zeit Dir das hier anzuschauen?
https://forum.fhem.de/index.php/topic,53584.msg1132896.html#msg1132896 (https://forum.fhem.de/index.php/topic,53584.msg1132896.html#msg1132896)
Da sind noch ein, zwei Merkwürdigkeiten.

1.) Die Abfrage eines definierten Wertes, wenn dieser nicht in der Datenbank ist.
  Dann wird ein Werte in der Nähe geliefert, der aber auch sehr weit zurück liegt, anstatt der Default Wert, der beim Abruf mitgeliefert wurde.

2.) Bei Abruf mit sqlCmdBlocking hat sqlCmdVars keine Wirkung.


Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Februar 2021, 22:39:26
Hallo Christian,

Zitat
1.) Die Abfrage eines definierten Wertes, wenn dieser nicht in der Datenbank ist.
  Dann wird ein Werte in der Nähe geliefert, der aber auch sehr weit zurück liegt, anstatt der Default Wert, der beim Abruf mitgeliefert wurde.
Ja, das ist so gewollt. Der nächstliegende Wert soll geliefert werden. Der Standardwert wird zurück gegeben, wenn es keinen Wert der angefragten Device/Reading Kombination in der DB gibt.

Zitat
2.) Bei Abruf mit sqlCmdBlocking hat sqlCmdVars keine Wirkung.
Ja das kann sein. Muss ich schauen. Die sqlCmdVars hatte ich vor nicht allzu langer Zeit eingebaut, vllt. hab ich es vergessen dort nachzuziehen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 26 Februar 2021, 10:26:37
Zitat von: DS_Starter am 25 Februar 2021, 22:39:26
Ja, das ist so gewollt. Der nächstliegende Wert soll geliefert werden. Der Standardwert wird zurück gegeben, wenn es keinen Wert der angefragten Device/Reading Kombination in der DB gibt.
Danke für die Rückmeldung.
Gibt es denn noch eine andere Möglichkeit, mit einer Funktion exact nach einem Wert abzufragen?
Momentan gehe ich den Umweg mit einem SELECT über das DbRep Device

$Solar_Correction_Faktor_auto = CommandGet(undef, $logdbrep." sqlCmdBlocking SELECT VALUE FROM history WHERE DEVICE='".$logdevice."' AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP='".sprintf("%4d-%02d-%02d %02d:00:00",$year,$mon,$mday,$i)."';") ;

if($Solar_Correction_Faktor_auto eq "") { $Solar_Correction_Faktor_auto = 1; };  ## hier wird der Default gesetzt, wenn nichts zurück kommt.


VG und danke für den unermüdlichen Support
       Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Februar 2021, 09:33:01
Hallo kobi, @all,

im Wiki (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Gr.C3.BCnlandtemperatursumme_ermitteln_und_in_SVG-Grafik_darstellen) habe ich eine Beitrag erstellt wie man die ermittelte Grünlandtemperatursumme in die Datenbank zurückspeichert und daraus dann eine SVG-Grafik erstellt.
Das Verfahren kann natürlich für andere, ähnlich gelagerte Aufgabenstellungen adaptiert werden.

@Christian,in meinem contrib liegt eine neue DbRep-Version zum Testen. Das  sqlCmdBlocking sollte nun ebenfalls das Attr sqlCmdVars berücksichtigen.Versuchs mal bitte.
Grüße,Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: kobi1980 am 28 Februar 2021, 00:41:44
Moin Heiko

verrückt.. vielen Dank, es funktioniert!

Zitat von: DS_Starter am 27 Februar 2021, 09:33:01
Hallo kobi, @all,

im Wiki (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Gr.C3.BCnlandtemperatursumme_ermitteln_und_in_SVG-Grafik_darstellen) habe ich eine Beitrag erstellt wie man die ermittelte Grünlandtemperatursumme in die Datenbank zurückspeichert und daraus dann eine SVG-Grafik erstellt.
Das Verfahren kann natürlich für andere, ähnlich gelagerte Aufgabenstellungen adaptiert werden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 Februar 2021, 09:37:57
Zitat von: kobi1980 am 28 Februar 2021, 00:41:44
verrückt.. vielen Dank, es funktioniert!
Das ist nicht verrückt, der Heiko kann was :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 Februar 2021, 10:06:21
Zitat von: DS_Starter am 27 Februar 2021, 09:33:01
@Christian,in meinem contrib liegt eine neue DbRep-Version zum Testen. Das  sqlCmdBlocking sollte nun ebenfalls das Attr sqlCmdVars berücksichtigen.Versuchs mal bitte.
Es hat funktioniert. Ich habe es nun eingebaut und würde mich bei Problemen melden.

- Die sqlCmdHistory ist auch nur beim sqlCmd vorhanden. Würde das beim sqlCmdBlocking auch Sinn machen?
- Mein SQL ist wie immer recht lang :-) könnte man das im sql[Cmd|CmdBlocking] eventuell mehrzeilig umbrechen?
- Kann man beim sql[Cmd|CmdBlocking] auch kleine Skripte mit mehreren SQL Kommandos verarbeiten?

Vielen Danke für Deinen tollen Support
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Februar 2021, 10:39:16
Moin Christian,

gerne :).

ZitatDie sqlCmdHistory ist auch nur beim sqlCmd vorhanden. Würde das beim sqlCmdBlocking auch Sinn machen?
Weiß nicht. sqlCmdBlocking ist eher für Ausführungen in einem Script gedacht und nicht für den Dialogbetrieb (wegen Blocking).

Zitat
Mein SQL ist wie immer recht lang :-) könnte man das im sql[Cmd|CmdBlocking] eventuell mehrzeilig umbrechen?
Versuch doch  mal:


attr <> widgetOverride sqlCmdBlocking:textField-long sqlCmd:textField-long


ZitatKann man beim sql[Cmd|CmdBlocking] auch kleine Skripte mit mehreren SQL Kommandos verarbeiten?
Momentan dürfte es nicht gehen, aber wäre einbaubar.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 Februar 2021, 11:44:18
Zitat von: DS_Starter am 28 Februar 2021, 10:39:16
Weiß nicht. sqlCmdBlocking ist eher für Ausführungen in einem Script gedacht und nicht für den Dialogbetrieb (wegen Blocking).
Das leuchtet ein, man könnte dann jedoch sehen, was als letztes so alles aufgerufen wurde und für Tests dieses dann wiederholen.
Zitat
Versuch doch  mal:

attr <> widgetOverride sqlCmdBlocking:textField-long sqlCmd:textField-long

Jetzt ist es schon zum sqlCmdBlocking gerutscht :-) :-)

Dann habe ich noch folgende Meldungen, muss ich mir da Sorgen machen?
Bekomme ich die noch weg? Außer dem global attr verbose 3 habe ich im Device kein verbose gesetzt.

2021.02.27 14:00:00.120 3: DbRep LogDBRep_PV_Forecast_SQL - WARNING - old process 31994 will be killed now to start a new BlockingCall
2021.02.27 14:00:00.121 1: DbRep LogDBRep_PV_Forecast_SQL -> BlockingCall  pid: Timeout: process terminated
2021.02.27 14:00:00.136 2: DbRep LogDBRep_PV_Forecast_SQL - Database command aborted due to "Timeout: process terminated"
2021.02.27 14:00:01.460 3: DbRep LogDBRep_PV_Forecast_SQL - Number of entries processed in db fhem: 11 by INSERT


Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Februar 2021, 11:58:28
Die Meldungen sind nicht so gut.
Es bedeutet folgendes. Du startest eine Aktivität und während die läuft (und noch nicht fertig ist) startest du mit dem gleichen Device wieder eine neue Aktion. Das Device bricht daraufhin seine laufende Aktivität ab was zu der Meldung führt "WARNING - old process 31994 will be killed now to start a new BlockingCall".

Da solltest du mal schauen wieso diese Überschneidungen auftreten und ggf. die Abläufe ändern oder verschiedene DbReps nutzen wenn möglich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 Februar 2021, 12:42:29
Zitat von: DS_Starter am 28 Februar 2021, 11:58:28
Die Meldungen sind nicht so gut.
Es bedeutet folgendes. Du startest eine Aktivität und während die läuft (und noch nicht fertig ist) startest du mit dem gleichen Device wieder eine neue Aktion. Das Device bricht daraufhin seine laufende Aktivität ab was zu der Meldung führt "WARNING - old process 31994 will be killed now to start a new BlockingCall".

Da solltest du mal schauen wieso diese Überschneidungen auftreten und ggf. die Abläufe ändern oder verschiedene DbReps nutzen wenn möglich.
Okay, ich habe es behoben, danke.

Ich hatte ein sqlCmd abgesetzt und etwas später ein sqlCmdBlocking.
Jetzt ist beides auf sqlCmdBlocking und die Meldungen sind weg.

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Februar 2021, 14:24:33
ZitatIch hatte ein sqlCmd abgesetzt und etwas später ein sqlCmdBlocking.
Ah das ist interessant. Gut dass du das erwähnst. Diese beiden Kommandos können parallel laufen.
Im kommenden Release werde ich es entkoppeln. Dann können solche Konstrukte ablaufen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Februar 2021, 16:57:37
Hallo Christian,

ich habe mal den Code gecheckt und auch ausprobiert. Auch jetzt schon sind sqlCmd und sqlCmdBlocking voneinander entkoppelt.
D.h. die von dir erwähnten Meldungen müssen einen anderen Zusammenhang haben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 Februar 2021, 17:01:52
Zitat von: DS_Starter am 28 Februar 2021, 16:57:37
ich habe mal den Code gecheckt und auch ausprobiert. Auch jetzt schon sind sqlCmd und sqlCmdBlocking voneinander entkoppelt.
D.h. die von dir erwähnten Meldungen müssen einen anderen Zusammenhang haben.
Das sqlCmd war ein "DELETE" und das zweite ein "INSERT", die DB läuft mit cache.
Ich versuche es nochmal nachzustellen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 März 2021, 16:45:27
Hallo Heiko,
ich habe jetzt die Version aus dem contrib einige tage laufen und es nichts weiter aufgetreten.
Hattest Du das schon eingechecked?

VG  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2021, 17:16:45
Habe sie noch nicht eingecheckt weil ich erst noch auf weitere Rückinfod zu meiner Erweiterung in DbLog -> https://forum.fhem.de/index.php/topic,118817.0.html 
gewartet hatte.

Aber da dort nichts weiter gekommen ist, werde ich DbRep / DbLog heute oder morgen einchecken.
Will es beides zusammen erledigen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2021, 21:02:14
Die neue DbRep-Version ist jetzt eingecheckt.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: cwagner am 10 März 2021, 17:50:24
Bin jetzt auf GTS gestoßen, gerade noch rechtzeitig bevor ich mir mit DOIF einen eigenen Zähler mit allen Schmerzen gebaut hätte. Seit langem benutze ich schon die Aufzeichnung der DWD-gerechten Tagesmitteltemperatur AVGDMGWS, starte einmal kurz vor Mitternacht zeitgesteuert
set RP.T.Aussen.MinMax averageValue writeTODBSingle und habe den jeweiligen Tageswert sauber als Event "calculated" in der Datenbank.

Nun ist mir unklar, warum dasselbe mit dem Attribut averageCalcForm für avgDailyMeanGWSwithGTS nicht funktioniert und ich wie im tollen Wiki-Eintrag beschrieben den Umweg über eine user-definierte Funktion gehen muss.

Mir ist es jedenfalls nicht gelungen, die Werte mit writeTODB oder writeTODBSingle in die Datenbank zu bekommen - über die userEXITFn geht es zwar, ist aber für mich verwirrend.

Danke für eine Aufklärung, wenn möglich

Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 März 2021, 19:21:38
Hallo Christian,

Zitat
Mir ist es jedenfalls nicht gelungen, die Werte mit writeTODB oder writeTODBSingle in die Datenbank zu bekommen - über die userEXITFn geht es zwar, ist aber für mich verwirrend.
Das hat programmtechnische Ursachen. Die Berechnung des GTS über die CalcForm avgDailyMeanGWSwithGTS  ist lediglich eine "Erweiterung" von avgDailyMeanGWS. Die Berechnung habe ich wegen eines Userwunsches später "aufgepfropft".
Ich bin diesbezüglich intern an eine Designgrenze gestoßen und diese aufzulösen hätte mir zuviel Arbeit bereitet (aktuell).
Deswegen dieser im Wiki beschriebene Workaround. Damit kommt man als User aber auch gut klar denke ich.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: cwagner am 10 März 2021, 22:42:51
Vielen Dank für die schnelle und offene Antwort. Immerhin bist Du ja auf den Wunsch eingegangen und hast dieses spannende Thema programmatisch umgesetzt. - ok, dann werde ich mal Erfahrung sammeln mit der Lösung - spontan hatte ich die Sorge, das ich mir mit jedem Lauf praktisch die bereits errechneten Werte zurückliegender Tage erneut in die Datenbank hole...

Herzliche Grüße

Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: cwagner am 12 März 2021, 12:28:12
Darf ich doch noch einmal auf das Thema zurückkommen? Der im Wiki vorgeschlagene Weg mit einer User-Funktion funktioniert prima mit einem herben Aspekt: Wenn ich täglich auf dem Laufenden bleiben will, erzeuge ich jeden Tag für alle zurückliegenden Tage in der Datenbank einen neuen, gleichen Eintrag. Hätte ich am 1.1. angefangen, wären das heute am 71. Tag des Jahres bereits 2556 Datenbankeinträge statt 71.
Siehst Du eine Option, die Ausgabe auf den jeweils letzten Tag einzugrenzen oder im GTSSave nur das letzte Reading zu verarbeiten?

BG Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 März 2021, 12:46:07
Hallo Christian,

adhoc mehre Möglichkeiten:

1. in der DB einen primarary Key anlegen. Der verhindert generell doppelte Datensätze. Im Nachhinein nicht einfach zu implementieren, deswegen eher für Neuanfang

2. Im DbLog das Attr valueFn benutzen und mit einer kleinen Perl-Routine nur den Wert des aktuellen Tages durchlassen (Stichwort $IGNORE)

3. einfach ein DbRep device benutzen und mit delDoublets regelmäßig evtl. doppelt vorkommende Datensätze löschen

Gibt sicherlich noch mehr, aber 3. ist simpel und schnell eingerichtet.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 12 März 2021, 13:36:23
Zitat von: DS_Starter am 12 März 2021, 12:46:07
1. in der DB einen primarary Key anlegen. Der verhindert generell doppelte Datensätze. Im Nachhinein nicht einfach zu implementieren, deswegen eher für Neuanfang

2. Im DbLog das Attr valueFn benutzen und mit einer kleinen Perl-Routine nur den Wert des aktuellen Tages durchlassen (Stichwort $IGNORE)

3. einfach ein DbRep device benutzen und mit delDoublets regelmäßig evtl. doppelt vorkommende Datensätze löschen
3 wäre ne gute Vorbereitung für 1 :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: cwagner am 12 März 2021, 18:40:30
Zitat von: ch.eick am 12 März 2021, 13:36:23
3 wäre ne gute Vorbereitung für 1 :-)
Das habe ich beim Einlesen und Umsetzen auch gemerkt :-) und vermutlich war das auch der Hintersinn "Im Nachhinein nicht so einfach..."
Gut die ersten 41.000 Doubletten aus anderen Devices werden gerade getilgt...

Danke für die Bestärkung, dass ich auf einem zielführenden Weg bin.

Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Mumpitz am 27 März 2021, 09:48:34
Hallo zusammen

Ich bräuchte mal euer Schwarmwissen. Ich bin stolzer Besitzer eine PV Anlage inkl. Stromspeicher. Die Anlage habe ich in fhem eingebunden. Die Statistiken dazu werden jede Stunde per HTTPMOD abgerufen und in das Device WR_Plenticore_API geschrieben. Die Readings werden in ein DBLog geschrieben.

Nun ist es so, dass natürlich diverse Tagesreadings mitgeloggt werden, welche allesamt auf *._Day enden. Diesbezüglich ist jedoch historisch gesehen nur der letzte Wert am Ende des Tages massgebend. Daher möchte ich die Werte unter Tage jeweils einmal die Woche oder Monat löschen.

Dafür gibt es bekanntlich die Funktion des maxValue. Ich könnte natürlich nun ein Device anlegen und des Reading einzeln mittels maxValue bearbeiten lassen. Ich bin aber der Meinung das dies sicherlich auch über alle Readings des entpsrechenden Devices gehen wird. Ich habe folgendes versucht:

defmod LogDBRep_delete_Statistic_Day_max_Day DbRep DBLogging
attr LogDBRep_delete_Statistic_Day_max_Day DbLogExclude .*
attr LogDBRep_delete_Statistic_Day_max_Day aggregation day
attr LogDBRep_delete_Statistic_Day_max_Day allowDeletion 1
attr LogDBRep_delete_Statistic_Day_max_Day device WR_Plenticore_API
attr LogDBRep_delete_Statistic_Day_max_Day group Delete_neu
attr LogDBRep_delete_Statistic_Day_max_Day reading *._Day
attr LogDBRep_delete_Statistic_Day_max_Day room Log
attr LogDBRep_delete_Statistic_Day_max_Day timestamp_begin previous_year_begin
attr LogDBRep_delete_Statistic_Day_max_Day timestamp_end previous_day_end


Das Resultat davon war, dass er gesamthaft nur ein Reading, welches auf *._Day geendet hat, behalten wurde.

Dann habe ich versucht, alle Readings unter Reading einzutragen:
attr LogDBRep_delete_Statistic_Day_max_Day reading Statistic_Autarky_Day,Statistic_CO2Saving_Day,Statistic_EnergyChargeGrid_Day,Statistic_EnergyChargeInvIn_Day,Statistic_EnergyChargePv_Day,Statistic_EnergyDischargeGrid_Day,Statistic_EnergyDischarge_Day,Statistic_EnergyFeedInGrid_Day,Statistic_EnergyHomeBat_Day,Statistic_EnergyHomeGrid_Day,Statistic_EnergyHomePvSum_Day,Statistic_EnergyHomePv_Day,Statistic_EnergyHome_Day,Statistic_EnergyPv1_Day,Statistic_EnergyPv2_Day,Statistic_EnergyPv3_Day,Statistic_OwnConsumptionRate_Day,Statistic_TotalConsumption_Day,Statistic_Yield_Day,Statistic_Yield_NoBat_Day,

Auch hier hat er nur ein Reading behalten.

Habt ihr eine Idee, wie die Readings auf einen rutsch bereinigt werden können?

Statistic_Autarky_Day,
Statistic_CO2Saving_Day,
Statistic_EnergyChargeGrid_Day,
Statistic_EnergyChargeInvIn_Day,
Statistic_EnergyChargePv_Day,
Statistic_EnergyDischargeGrid_Day,
Statistic_EnergyDischarge_Day,
Statistic_EnergyFeedInGrid_Day,
Statistic_EnergyHomeBat_Day,
Statistic_EnergyHomeGrid_Day,
Statistic_EnergyHomePvSum_Day,
Statistic_EnergyHomePv_Day,
Statistic_EnergyHome_Day,
Statistic_EnergyPv1_Day,
Statistic_EnergyPv2_Day,
Statistic_EnergyPv3_Day,
Statistic_OwnConsumptionRate_Day,
Statistic_TotalConsumption_Day,
Statistic_Yield_Day,
Statistic_Yield_NoBat_Day

Besten Dank!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: adn77 am 27 März 2021, 11:52:05
Hallo zusammen,

ich bin ein großer Fan von DbLog und nutze es auch auf Embedded Geräten. Allerdings kommt es seit ein paar Jahren immer wieder vor, dass meine RAM Disk, auf der die SQLite fhem.db liegt vollläuft (selbstverständlich logge ich nur die notwendigen Events ;)).
Die Ursache ist das Write-Ahead-Log, welches inzwischen sowohl von FHEM als auch von SQLite als Standard verwendet wird. Da meine Ansprüche an die Datenintegrität eher bescheiden sind, habe ich den Verbindungsparameter im Code nach jedem Update manuell überschrieben.

Evtl. nutzt diese Einstellung aber auch Anderen, die FHEM auf Fritzbox, Raspi-Lite, etc. laufen haben. Deshalb habe ich einen Patch mit entsprechenden Warnungen in der Dokumentation erstellt.

Alex
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 März 2021, 12:17:10
Hallo Mumpitz,

Zitat
Das Resultat davon war, dass er gesamthaft nur ein Reading, welches auf *._Day geendet hat, behalten wurde.
Ja, maxValue betrachtet alle Datensätze die sich aus dem Einschluß/Ausschlauß des Attr reading ergeben und ermittelt aus all diesen Werten den max. Wert.
Du könntest in einem Script (at, DOIF,...) vor dem maxValue Lauf jeweils das Attr auf das gewünschte Reading setzen und nach Abschluß des Laufs die nächste Bereinigung starten. Ist nicht sehr schön.
Alternativ kopierst du deine DbRep-Definition x-mal und passt jeweils das Attr reading an. Je nach RAM Verfügbarkeit kannst du das maxValue mit einem Rutsch per at,DOIF etc. starten.
Weitere Möglichkeit wäre ein zugeschnittenes SQL zu entwerfen und per sqlCmd laufen zu lassen. Da muss man aber erstmal drüber nachdenken.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 März 2021, 12:21:29
Hallo Alex,

vielen Dank für den Patch.
Ich bin jetzt nicht so der SQLite Nutzer (nutze MariaDB).
Schaue es mir an und erweitere DbLog wenn ich mich mal wieder damit befasse.

Danke und VG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 29 März 2021, 22:29:00
Zitat von: DS_Starter am 27 März 2021, 12:17:10
Ja, maxValue betrachtet alle Datensätze die sich aus dem Einschluß/Ausschlauß des Attr reading ergeben und ermittelt aus all diesen Werten den max. Wert.
Du könntest in einem Script (at, DOIF,...) vor dem maxValue Lauf jeweils das Attr auf das gewünschte Reading setzen und nach Abschluß des Laufs die nächste Bereinigung starten. Ist nicht sehr schön.
Alternativ kopierst du deine DbRep-Definition x-mal und passt jeweils das Attr reading an. Je nach RAM Verfügbarkeit kannst du das maxValue mit einem Rutsch per at,DOIF etc. starten.
Weitere Möglichkeit wäre ein zugeschnittenes SQL zu entwerfen und per sqlCmd laufen zu lassen. Da muss man aber erstmal drüber nachdenken.  :)
Ich könnte ja mal wieder ein SQL zusammenbauen :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 März 2021, 22:46:10
ZitatIch könnte ja mal wieder ein SQL zusammenbauen :-)
Aber gerne doch Christian.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 März 2021, 22:48:47
Ich habe den Patch von Alex im DbLog eingebaut.
Es ist zwar jetzt nicht der richtige Thread hier, aber wer mag kann die neue DbLog Version aus meinem contrib testen.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:


"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"


@Alex, würde mich über deinen Test freuen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 30 März 2021, 16:37:53
Zitat von: DS_Starter am 29 März 2021, 22:46:10
Aber gerne doch Christian.  :)
Da isser schon :-)

Das habe ich Mumpitz zum Testen geschickt.

Wichtig ist, dass die Werte wirklich aufsteigend sind, also Tageszähler! Bei Mumpitzs Liste war das z.B. bei der Statistic_Aurtarky_Day nicht der Fall.
Wird ein Speicher am WR betrieben, dann liefert dieser früh morgens auch noch, wodurch dann die Autarkie nach Mitternacht noch 100% hat. Sobald der Speicher leer ist geht diese dann runter, wodurch das Maximum nicht am Tages Ende ist. Bei der Autarkie kann es somit interessant sein, ob diese sich durch den Tag verändert, aber das ist ein anderes Thema :-)

===================
Hier definiert man  ab welchem Tag es los geht und wieviel Tage bearbeitet werden sollen.
Die Einstellung gilt dann für die gesamte Session!

SET @device:='WR_1_API',@days:=1,@startdate:='2021-03-01';
===================
Dann das SELECT für den ersten Test, es wird alles angezeigt, was erhalten bleibt.

           SELECT x1.TIMESTAMP,x1.DEVICE,x1.READING,x1.VALUE
             FROM (SELECT                      max(TIMESTAMP) AS TIMESTAMP,
                     date(TIMESTAMP) AS DATE,
                     DEVICE,
                     READING,
                     max(cast(VALUE AS DECIMAL(6,2))) AS VALUE
                   FROM history
                   WHERE DEVICE    =  @device
                     AND READING   IN ('Statistic_EnergyHomeBat_Day','Statistic_EnergyHomeGrid_Day','Statistic_EnergyHomePvSum_Day','Statistic_EnergyHome_Day','Statistic_TotalConsumption_Day')
                     AND TIMESTAMP > @startdate
                     AND TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY)
                   GROUP BY READING,DATE
                  ) x1
===================
Jetzt kann man noch die Liste der zu löschenden Einträge sehen und diese bitte mal mit einem anderen SELECT vergleichen.

        SELECT
          t1.TIMESTAMP,
          t1.DEVICE,
          t1.READING,
          t1.VALUE
        FROM history t1
        INNER JOIN
          (
           SELECT x1.TIMESTAMP,x1.DEVICE,x1.READING,x1.VALUE
             FROM (SELECT
                     max(TIMESTAMP) AS TIMESTAMP,
                     date(TIMESTAMP) AS DATE,
                     DEVICE,
                     READING,
                     max(cast(VALUE AS DECIMAL(6,2))) AS VALUE
                   FROM history
                   WHERE DEVICE    =  @device
                     AND READING   IN ('Statistic_EnergyHomeBat_Day','Statistic_EnergyHomeGrid_Day','Statistic_EnergyHomePvSum_Day','Statistic_EnergyHome_Day','Statistic_TotalConsumption_Day')
                     AND TIMESTAMP > @startdate
                     AND TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY)
                   GROUP BY READING,DATE
                  ) x1
          ) x2
        ON    x2.TIMESTAMP != t1.TIMESTAMP
          AND x2.DEVICE     = t1.DEVICE
          AND x2.READING    = t1.READING
        WHERE
              t1.DEVICE    = @device
          AND t1.READING   = x2.READING
          AND t1.TIMESTAMP > @startdate
          AND t1.TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY)
        ORDER BY READING,TIMESTAMP;

===================
Wer mutig ist kann dann mal so löschen

        DELETE t1
        FROM history t1
        INNER JOIN
          (
           SELECT x1.TIMESTAMP,x1.DEVICE,x1.READING,x1.VALUE
             FROM (SELECT
                     max(TIMESTAMP) AS TIMESTAMP,
                     date(TIMESTAMP) AS DATE,
                     DEVICE,
                     READING,
                     max(cast(VALUE AS DECIMAL(6,2))) AS VALUE
                   FROM history
                   WHERE DEVICE    =  @device
                     AND READING   IN ('Statistic_EnergyHomeBat_Day','Statistic_EnergyHomeGrid_Day','Statistic_EnergyHomePvSum_Day','Statistic_EnergyHome_Day','Statistic_TotalConsumption_Day')
                     AND TIMESTAMP > @startdate
                     AND TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY)
                   GROUP BY READING,DATE
                  ) x1
          ) x2
        ON    x2.TIMESTAMP != t1.TIMESTAMP
          AND x2.DEVICE     = t1.DEVICE
          AND x2.READING    = t1.READING
        WHERE
              t1.DEVICE    = @device
          AND t1.READING   = x2.READING
          AND t1.TIMESTAMP > @startdate
          AND t1.TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY)
        ;

===================
Und zum Schluss nochmal nachschauen...

           SELECT x1.TIMESTAMP,x1.DEVICE,x1.READING,x1.VALUE
             FROM (SELECT                      max(TIMESTAMP) AS TIMESTAMP,
                     date(TIMESTAMP) AS DATE,
                     DEVICE,
                     READING,
                     max(cast(VALUE AS DECIMAL(6,2))) AS VALUE
                   FROM history
                   WHERE DEVICE    =  @device
                     AND READING   IN ('Statistic_EnergyHomeBat_Day','Statistic_EnergyHomeGrid_Day','Statistic_EnergyHomePvSum_Day','Statistic_EnergyHome_Day','Statistic_TotalConsumption_Day')
                     AND TIMESTAMP > @startdate
                     AND TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY)
                   GROUP BY READING,DATE
                  ) x1;


===================
Oder auch gerne so...

                 SELECT TIMESTAMP,DEVICE,READING,VALUE
                   FROM history
                   WHERE DEVICE    =  @device
                     AND READING   IN ('Statistic_EnergyHomeBat_Day','Statistic_EnergyHomeGrid_Day','Statistic_EnergyHomePvSum_Day','Statistic_EnergyHome_Day','Statistic_TotalConsumption_Day')
                     AND TIMESTAMP > @startdate
                     AND TIMESTAMP < DATE_ADD(@startdate,INTERVAL @days DAY);


Wenn das getestet ist, bau ich es noch ins DbRep ein.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 17 Mai 2021, 13:21:25
Hallo Heiko
Sorry, dass hier nochmal auf mein Problem und den schon erstellten Beitrag zu spechen komme.
https://forum.fhem.de/index.php/topic,121043.0.html (https://forum.fhem.de/index.php/topic,121043.0.html)

Sowohl bei DbLog als auch bei DbRep führt das Resulat (bei mir) aus "reduceLogNbl <no> average=day" bzw. "reduceLog <no> average=day" nicht zu einem finalen Tageswert.

  • In DbLog hat der jüngste bearbeitete Tag nur stündliche Werte hh:30 (die älteren haben wie erwartet einen einzigen Wert um 12:00)
  • Bei DbRep hat kein Tag des bearbeiteten Zeitraums einen Tageswert (nur stündliche)
  • Mit "average" aufgerufen ist das Ergebnis wie erwartet mit einem Mittelwert um hh:30

Ich habe bisher keine Beiträge mit so einem Problem gefunden.


P.S.
Ich finde beide Module klasse dokumentiert (Commandref und Wiki)  :)

Habe kürzlich MariaDB aufgesetzt und schreibe dort einige wenige Messwerte rein.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Mai 2021, 16:25:05
Hallo Ralf,

ich hatte deine Meldung schon gesehen und auf meine Checkliste gelegt.
Bin nur noch nicht dazu gekommen weil ich gerade an einem neuen Modul arbeite und noch eine Sache bei SSCam einschieben will.

Grundsätzlich sollten die Routinen in DbLog und DbRep dasselbe Ergebnis liefern. Im DbRep hat man erweiterte Einstellmöglichkeiten.
Du könntest zum Vergleich den Setter ohne <no> verwenden und Zeitabgrenzung über time.* Attribute vornehmen.
Schau mal ob das Ergebnis dann ein anderes ist.

Hilfreich sind dann auch verbose 4/5 Logauszüge.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 17 Mai 2021, 19:39:16
Ok wollte nicht drängeln....   ???

Bleiben wir hier im Beitrag?

Ich lege mir mal ne Spieldatenbank an wo nur das Reading für average=day drinsteht.
Die Unterschiede sind eine Sache aber beide zeigen den Effekt, dass Tage dabei sind die nicht gemittelt werden.

Melde mich mit den Testergebnissen.

==> trenne die Tests in zwei Anworten

  • reducelogNBL mit dem set-Kommando der Logging-DB
  • reducelog über ein DBRep-Device auf die Logging-DB
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 17 Mai 2021, 23:49:28
Weiterhin reduceLog auf Device "DBRep_Tst" vom Type "DbRep" (list Device ist verzichtbar denke ich)

Vorab gleich:
das gleiche "fehlerhafte" Ergebnis wie im Test#3 DbLog ==> keine Daily Mittelwerte
sowohl ohne Attribute mit no:nn als auch mit time.* Attributen

Test#4 Daten vom 30.03 bis 17.05 (Spritpreise)
DBRep_Tst  reduceLog 18:48 average=day INCLUDE=Jet:E10 (ohne gesetzte Attribute)
Status        reduceLog finished. Rows processed: 998, deleted: 277, updated: 245
Ursprung 1614 Zeilen - Ergebnis 1337 Zeilen = 277 gelöscht ==> ok

Logfile:  exemplarisch der 31.03 & 29.04  (gegenüber DBlog um einen Tag verschoben)
==> keine daily Mittelwerte

2021.05.17 22:56:25.795 3: DbRep DBRep_Tst - ################################################################
2021.05.17 22:56:25.796 3: DbRep DBRep_Tst - ###                    new reduceLog run                     ###
2021.05.17 22:56:25.797 3: DbRep DBRep_Tst - ################################################################
2021.05.17 22:56:25.802 4: DbRep DBRep_Tst - -------- New selection ---------
2021.05.17 22:56:25.803 4: DbRep DBRep_Tst - Command: reduceLog
2021.05.17 22:56:25.806 4: DbRep DBRep_Tst - timeDiffToNow - year: , day: 48, hour: , min: , sec:
2021.05.17 22:56:25.807 4: DbRep DBRep_Tst - startMonth: 2 endMonth: 4 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:1
2021.05.17 22:56:25.807 4: DbRep DBRep_Tst - timeOlderThan - year: 0, day: 18, hour: 0, min: 0, sec: 0
2021.05.17 22:56:25.808 4: DbRep DBRep_Tst - startMonth: 2 endMonth: 3 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:1
2021.05.17 22:56:25.809 4: DbRep DBRep_Tst - FullDay option: 0
2021.05.17 22:56:25.810 4: DbRep DBRep_Tst - Time difference to current time for calculating Timestamp begin: 4147201 sec
2021.05.17 22:56:25.810 5: DbRep DBRep_Tst - Timestamp begin epocheseconds: 1617137784.8102
2021.05.17 22:56:25.811 4: DbRep DBRep_Tst - Timestamp begin human readable: 2021-03-30 22:56:24
2021.05.17 22:56:25.811 5: DbRep DBRep_Tst - Timestamp end epocheseconds: 1619729784.8117
2021.05.17 22:56:25.812 4: DbRep DBRep_Tst - Timestamp end human readable: 2021-04-29 22:56:24
2021.05.17 22:56:25.813 5: DbRep DBRep_Tst - weekday start for selection: Di  ->  wdadd: 518400
2021.05.17 22:56:25.980 5: DbRep DBRep_Tst -> Start DbLog_reduceLog
2021.05.17 22:56:25.999 5: DbRep DBRep_Tst - Devices for operation -
included (1): %
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 22:56:26.000 5: DbRep DBRep_Tst - Readings for operation -
included (1): %
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 22:56:26.001 5: DbRep DBRep_Tst - IsTimeSet: 1, IsAggrSet: 0
2021.05.17 22:56:26.002 4: DbRep DBRep_Tst - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history WHERE DEVICE like 'Jet' AND READING like 'E10' AND TIMESTAMP <= '2021-04-29 22:56:24' AND TIMESTAMP >= '2021-03-30 22:56:24' ORDER BY TIMESTAMP ASC
2021.05.17 22:56:26.002 3: DbRep DBRep_Tst - reduce data older than: 2021-04-29 22:56:24, newer than: 2021-03-30 22:56:24
2021.05.17 22:56:26.002 3: DbRep DBRep_Tst - reduceLog requested with options: AVERAGE=DAY, INCLUDE=Jet:E10
2021.05.17 22:56:26.038 3: DbRep DBRep_Tst - reduceLog deleting 11 records of day: 2021-03-31
2021.05.17 22:56:26.040 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 06:52:10) AND (VALUE=151.9)
2021.05.17 22:56:26.042 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 08:37:10) AND (VALUE=146.9)
2021.05.17 22:56:26.044 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 09:28:10) AND (VALUE=147.9)
2021.05.17 22:56:26.046 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 10:39:12) AND (VALUE=145.9)
2021.05.17 22:56:26.048 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 12:29:13) AND (VALUE=148.9)
2021.05.17 22:56:26.050 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:13:13) AND (VALUE=144.9)
2021.05.17 22:56:26.052 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:19:13) AND (VALUE=143.9)
2021.05.17 22:56:26.054 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 15:29:14) AND (VALUE=147.9)
2021.05.17 22:56:26.056 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:44:14) AND (VALUE=145.9)
2021.05.17 22:56:26.058 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:53:14) AND (VALUE=143.9)
2021.05.17 22:56:26.060 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 19:27:14) AND (VALUE=146.9)
2021.05.17 22:56:26.068 3: DbRep DBRep_Tst - reduceLog (hourly-average) updating 9 records of day: 2021-03-31
2021.05.17 22:56:26.069 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 06:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 06:01:09 AND VALUE=146.9
2021.05.17 22:56:26.073 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 08:30:00, EVENT='rl_av_h', VALUE=147.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 08:25:10 AND VALUE=147.9
2021.05.17 22:56:26.075 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 09:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 09:08:10 AND VALUE=143.9
2021.05.17 22:56:26.078 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 10:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 10:28:12 AND VALUE=147.9
2021.05.17 22:56:26.081 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 12:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 12:13:13 AND VALUE=144.9
2021.05.17 22:56:26.084 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 14:30:00, EVENT='rl_av_h', VALUE=145.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 14:03:13 AND VALUE=146.9
2021.05.17 22:56:26.087 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 15:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 15:19:14 AND VALUE=143.9
2021.05.17 22:56:26.089 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 16:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 16:29:14 AND VALUE=147.9
2021.05.17 22:56:26.092 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 19:30:00, EVENT='rl_av_h', VALUE=145.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 19:20:14 AND VALUE=143.9
...
2021.05.17 22:56:27.815 3: DbRep DBRep_Tst - reduceLog deleting 13 records of day: 2021-04-29
2021.05.17 22:56:27.817 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 06:52:26) AND (VALUE=151.9)
2021.05.17 22:56:27.819 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 08:24:27) AND (VALUE=144.9)
2021.05.17 22:56:27.821 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 09:27:28) AND (VALUE=149.9)
2021.05.17 22:56:27.823 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 10:39:29) AND (VALUE=148.9)
2021.05.17 22:56:27.826 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 11:20:29) AND (VALUE=144.9)
2021.05.17 22:56:27.828 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 12:28:30) AND (VALUE=148.9)
2021.05.17 22:56:27.830 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 13:40:31) AND (VALUE=147.9)
2021.05.17 22:56:27.832 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 14:10:31) AND (VALUE=143.9)
2021.05.17 22:56:27.834 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 15:28:32) AND (VALUE=147.9)
2021.05.17 22:56:27.836 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 16:53:33) AND (VALUE=145.9)
2021.05.17 22:56:27.838 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 17:28:33) AND (VALUE=145.9)
2021.05.17 22:56:27.840 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 18:34:34) AND (VALUE=140.9)
2021.05.17 22:56:27.842 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-29 18:49:34) AND (VALUE=139.9)
2021.05.17 22:56:27.850 3: DbRep DBRep_Tst - reduceLog (hourly-average) updating 12 records of day: 2021-04-29
2021.05.17 22:56:27.851 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 06:30:00, EVENT='rl_av_h', VALUE=150.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 06:18:25 AND VALUE=148.9
2021.05.17 22:56:27.854 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 08:30:00, EVENT='rl_av_h', VALUE=147.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 08:10:27 AND VALUE=149.9
2021.05.17 22:56:27.857 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 09:30:00, EVENT='rl_av_h', VALUE=147.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 09:24:28 AND VALUE=144.9
2021.05.17 22:56:27.859 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 10:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 10:27:28 AND VALUE=149.9
2021.05.17 22:56:27.862 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 11:30:00, EVENT='rl_av_h', VALUE=146.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 11:17:29 AND VALUE=147.9
2021.05.17 22:56:27.865 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 12:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 12:20:30 AND VALUE=144.9
2021.05.17 22:56:27.868 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 13:30:00, EVENT='rl_av_h', VALUE=148.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 13:28:31 AND VALUE=148.9
2021.05.17 22:56:27.871 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 14:30:00, EVENT='rl_av_h', VALUE=144.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 14:04:31 AND VALUE=145.9
2021.05.17 22:56:27.874 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 15:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 15:10:32 AND VALUE=143.9
2021.05.17 22:56:27.876 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 16:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 16:28:32 AND VALUE=147.9
2021.05.17 22:56:27.879 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 17:30:00, EVENT='rl_av_h', VALUE=144.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 17:04:33 AND VALUE=143.9
2021.05.17 22:56:27.882 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-04-29 18:30:00, EVENT='rl_av_h', VALUE=140.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-29 18:19:34 AND VALUE=141.9
2021.05.17 22:56:27.891 3: DbRep DBRep_Tst - reduceLog finished. Rows processed: 998, deleted: 277, updated: 245
2021.05.17 22:56:27.892 5: DbRep DBRep_Tst -> DbRep_reduceLogNbl finished



Test#5/6 Daten vom 30.03 bis 17.05 (Spritpreise)
DBRep_Tst   reduceLog average=day

Attribute
timeDiffToNow d:48
timeOlderThan d:18
device  Jet
reading E10
reduceLog finished. Rows processed: 998, deleted: 277, updated: 245

Logfile im Prinzip wie Test#4

2021.05.17 23:14:33.911 3: DbRep DBRep_Tst - ################################################################
2021.05.17 23:14:33.911 3: DbRep DBRep_Tst - ###                    new reduceLog run                     ###
2021.05.17 23:14:33.912 3: DbRep DBRep_Tst - ################################################################
2021.05.17 23:14:33.916 4: DbRep DBRep_Tst - -------- New selection ---------
2021.05.17 23:14:33.916 4: DbRep DBRep_Tst - Command: reduceLog
2021.05.17 23:14:33.919 4: DbRep DBRep_Tst - timeDiffToNow - year: , day: 48, hour: , min: , sec:
2021.05.17 23:14:33.920 4: DbRep DBRep_Tst - startMonth: 2 endMonth: 4 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:1
2021.05.17 23:14:33.921 4: DbRep DBRep_Tst - timeOlderThan - year: 0, day: 18, hour: 0, min: 0, sec: 0
2021.05.17 23:14:33.922 4: DbRep DBRep_Tst - startMonth: 2 endMonth: 3 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:1
2021.05.17 23:14:33.922 4: DbRep DBRep_Tst - FullDay option: 0
2021.05.17 23:14:33.923 4: DbRep DBRep_Tst - Time difference to current time for calculating Timestamp begin: 4147201 sec
2021.05.17 23:14:33.923 5: DbRep DBRep_Tst - Timestamp begin epocheseconds: 1617138872.9233
2021.05.17 23:14:33.924 4: DbRep DBRep_Tst - Timestamp begin human readable: 2021-03-30 23:14:32
2021.05.17 23:14:33.924 4: DbRep DBRep_Tst - Time difference to current time for calculating Timestamp end: 1555201 sec
2021.05.17 23:14:33.925 5: DbRep DBRep_Tst - Timestamp end epocheseconds: 1619730872.92465
2021.05.17 23:14:33.925 4: DbRep DBRep_Tst - Timestamp end human readable: 2021-04-29 23:14:32
2021.05.17 23:14:33.926 5: DbRep DBRep_Tst - weekday start for selection: Di  ->  wdadd: 518400
2021.05.17 23:14:34.144 5: DbRep DBRep_Tst -> Start DbLog_reduceLog
2021.05.17 23:14:34.153 5: DbRep DBRep_Tst - Devices for operation -
included (1): Jet
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:14:34.154 5: DbRep DBRep_Tst - Readings for operation -
included (1): E10
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:14:34.155 5: DbRep DBRep_Tst - IsTimeSet: 1, IsAggrSet: 0
2021.05.17 23:14:34.156 5: DbRep DBRep_Tst - Devices for operation -
included (1): Jet
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:14:34.157 5: DbRep DBRep_Tst - Readings for operation -
included (1): E10
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:14:34.158 4: DbRep DBRep_Tst - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history where  ( DEVICE = 'Jet' ) AND ( READING = 'E10' ) AND TIMESTAMP >= '2021-03-30 23:14:32' AND TIMESTAMP <= '2021-04-29 23:14:32' ORDER BY TIMESTAMP ASC;
2021.05.17 23:14:34.158 3: DbRep DBRep_Tst - reduce data older than: 2021-04-29 23:14:32, newer than: 2021-03-30 23:14:32
2021.05.17 23:14:34.158 3: DbRep DBRep_Tst - reduceLog requested with options: AVERAGE=DAY INCLUDE -> Devs: Jet Readings: E10
2021.05.17 23:14:34.225 3: DbRep DBRep_Tst - reduceLog deleting 11 records of day: 2021-03-31
2021.05.17 23:14:34.227 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 06:52:10) AND (VALUE=151.9)
2021.05.17 23:14:34.229 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 08:37:10) AND (VALUE=146.9)
2021.05.17 23:14:34.232 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 09:28:10) AND (VALUE=147.9)
2021.05.17 23:14:34.234 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 10:39:12) AND (VALUE=145.9)
2021.05.17 23:14:34.236 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 12:29:13) AND (VALUE=148.9)
2021.05.17 23:14:34.238 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:13:13) AND (VALUE=144.9)
2021.05.17 23:14:34.240 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:19:13) AND (VALUE=143.9)
2021.05.17 23:14:34.242 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 15:29:14) AND (VALUE=147.9)
2021.05.17 23:14:34.244 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:44:14) AND (VALUE=145.9)
2021.05.17 23:14:34.246 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:53:14) AND (VALUE=143.9)
2021.05.17 23:14:34.248 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 19:27:14) AND (VALUE=146.9)
2021.05.17 23:14:34.259 3: DbRep DBRep_Tst - reduceLog (hourly-average) updating 9 records of day: 2021-03-31
2021.05.17 23:14:34.260 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 06:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 06:01:09 AND VALUE=146.9
2021.05.17 23:14:34.263 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 08:30:00, EVENT='rl_av_h', VALUE=147.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 08:25:10 AND VALUE=147.9
2021.05.17 23:14:34.266 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 09:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 09:08:10 AND VALUE=143.9
2021.05.17 23:14:34.269 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 10:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 10:28:12 AND VALUE=147.9
2021.05.17 23:14:34.271 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 12:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 12:13:13 AND VALUE=144.9
2021.05.17 23:14:34.274 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 14:30:00, EVENT='rl_av_h', VALUE=145.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 14:03:13 AND VALUE=146.9
2021.05.17 23:14:34.277 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 15:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 15:19:14 AND VALUE=143.9
2021.05.17 23:14:34.280 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 16:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 16:29:14 AND VALUE=147.9
2021.05.17 23:14:34.283 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 19:30:00, EVENT='rl_av_h', VALUE=145.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 19:20:14 AND VALUE=143.9
2021.05.17 23:14:34.295 3: DbRep DBRep_Tst - reduceLog deleting 6 records of day: 2021-04-01
2021.05.17 23:14:34.296 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-01 06:53:22) AND (VALUE=151.9)
2021.05.17 23:14:34.299 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-01 09:28:24) AND (VALUE=151.9)


Attribute
timestamp_begin  2021-03-30 22:00:00
timestamp_end    2021-04-28 22:00:00
device  Jet
reading E10
reduceLog finished. Rows processed: 959, deleted: 262, updated: 232

Logfile im Prinzip wie Test#4

2021.05.17 23:23:31.731 3: DbRep DBRep_Tst - ################################################################
2021.05.17 23:23:31.731 3: DbRep DBRep_Tst - ###                    new reduceLog run                     ###
2021.05.17 23:23:31.732 3: DbRep DBRep_Tst - ################################################################
2021.05.17 23:23:31.737 4: DbRep DBRep_Tst - -------- New selection ---------
2021.05.17 23:23:31.738 4: DbRep DBRep_Tst - Command: reduceLog
2021.05.17 23:23:31.741 4: DbRep DBRep_Tst - FullDay option: 0
2021.05.17 23:23:31.742 5: DbRep DBRep_Tst - Timestamp begin epocheseconds: 1617134400
2021.05.17 23:23:31.743 4: DbRep DBRep_Tst - Timestamp begin human readable: 2021-03-30 22:00:00
2021.05.17 23:23:31.743 5: DbRep DBRep_Tst - Timestamp end epocheseconds: 1619640000
2021.05.17 23:23:31.744 4: DbRep DBRep_Tst - Timestamp end human readable: 2021-04-28 22:00:00
2021.05.17 23:23:31.745 5: DbRep DBRep_Tst - weekday start for selection: Di  ->  wdadd: 518400
2021.05.17 23:23:31.822 5: DbRep DBRep_Tst -> Start DbLog_reduceLog
2021.05.17 23:23:31.833 5: DbRep DBRep_Tst - Devices for operation -
included (1): Jet
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:23:31.834 5: DbRep DBRep_Tst - Readings for operation -
included (1): E10
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:23:31.836 5: DbRep DBRep_Tst - IsTimeSet: 1, IsAggrSet: 0
2021.05.17 23:23:31.838 5: DbRep DBRep_Tst - Devices for operation -
included (1): Jet
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:23:31.838 5: DbRep DBRep_Tst - Readings for operation -
included (1): E10
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.17 23:23:31.839 4: DbRep DBRep_Tst - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history where  ( DEVICE = 'Jet' ) AND ( READING = 'E10' ) AND TIMESTAMP >= '2021-03-30 22:00:00' AND TIMESTAMP <= '2021-04-28 22:00:00' ORDER BY TIMESTAMP ASC;
2021.05.17 23:23:31.840 3: DbRep DBRep_Tst - reduce data older than: 2021-04-28 22:00:00, newer than: 2021-03-30 22:00:00
2021.05.17 23:23:31.841 3: DbRep DBRep_Tst - reduceLog requested with options: AVERAGE=DAY INCLUDE -> Devs: Jet Readings: E10
2021.05.17 23:23:31.908 3: DbRep DBRep_Tst - reduceLog deleting 11 records of day: 2021-03-31
2021.05.17 23:23:31.909 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 06:52:10) AND (VALUE=151.9)
2021.05.17 23:23:31.912 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 08:37:10) AND (VALUE=146.9)
2021.05.17 23:23:31.915 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 09:28:10) AND (VALUE=147.9)
2021.05.17 23:23:31.917 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 10:39:12) AND (VALUE=145.9)
2021.05.17 23:23:31.920 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 12:29:13) AND (VALUE=148.9)
2021.05.17 23:23:31.922 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:13:13) AND (VALUE=144.9)
2021.05.17 23:23:31.925 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:19:13) AND (VALUE=143.9)
2021.05.17 23:23:31.927 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 15:29:14) AND (VALUE=147.9)
2021.05.17 23:23:31.930 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:44:14) AND (VALUE=145.9)
2021.05.17 23:23:31.933 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:53:14) AND (VALUE=143.9)
2021.05.17 23:23:31.935 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 19:27:14) AND (VALUE=146.9)
2021.05.17 23:23:31.945 3: DbRep DBRep_Tst - reduceLog (hourly-average) updating 9 records of day: 2021-03-31
2021.05.17 23:23:31.947 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 06:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 06:01:09 AND VALUE=146.9
2021.05.17 23:23:31.950 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 08:30:00, EVENT='rl_av_h', VALUE=147.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 08:25:10 AND VALUE=147.9
2021.05.17 23:23:31.953 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 09:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 09:08:10 AND VALUE=143.9
2021.05.17 23:23:31.957 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 10:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 10:28:12 AND VALUE=147.9
2021.05.17 23:23:31.960 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 12:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 12:13:13 AND VALUE=144.9
2021.05.17 23:23:31.963 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 14:30:00, EVENT='rl_av_h', VALUE=145.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 14:03:13 AND VALUE=146.9
2021.05.17 23:23:31.966 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 15:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 15:19:14 AND VALUE=143.9
2021.05.17 23:23:31.968 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 16:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 16:29:14 AND VALUE=147.9
2021.05.17 23:23:31.972 4: DbRep DBRep_Tst - UPDATE history SET TIMESTAMP=2021-03-31 19:30:00, EVENT='rl_av_h', VALUE=145.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-31 19:20:14 AND VALUE=143.9
2021.05.17 23:23:31.984 3: DbRep DBRep_Tst - reduceLog deleting 6 records of day: 2021-04-01
2021.05.17 23:23:31.986 4: DbRep DBRep_Tst - DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-01 06:53:22) AND (VALUE=151.9)


Fazit aus meiner Sicht:
- reduceLogNBL im DbLog-Device hat mit dem Parameter average=day "nur" ein Problem mit dem jüngsten (letzten) Tag
- diskussionswürdig wäre die Frage ob mit no:nn jeweils die kompletten Tage erfasst werden sollten (für alle Parametervarianten)
- reduceLog im DbRep-Device hat mit dem Parameter average=day an allen Tagen das Problem keine Tagesmittelwerte zu erzeugen (unabhängig davon auf welche Art der Zeitraum definiert wird)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 21 Mai 2021, 01:23:26
Nochmals (meine Livedaten) reduceLog average auf Device "DBRep_reduPower" vom Type "DbRep"


Vorab:
am jüngsten Tag (11.5) wird für Daten < 21:00 und > 20:00 kein Mittelwert um 20:30 gebildet und die Daten nicht gelöscht
Anmerkung Test 40 Minuten vorher (4.05 bis 10.05):
Es standen um 20:25 (dann der 10.5) rum etwas mehr Daten zur Verfügung. Es wurde der 20:30 Mittelwert gebildet aber die Daten nicht gelöscht.


Test#7 Daten vom 05.05 bis 11.05 (power)
DBRep_reduPower  reduceLog average
Status           reduceLog finished. Rows processed: 1793, deleted: 1688, updated: 101

Atrribute
device          shelly.*
reading         power
timeDiffToNow   d:16 FullDay
timeOlderThan   d:10 FullDay


Logfile:  exemplarisch der 05.05 & 11.05  (Ausführung am 21.5) / Achtung da zuviele Daten ist der 5.05 gekürzt. Der ist aber ok
==> vom 05.05 bis 11.05 alle hh:30 Werte (außer dem letzten), in der letzten Stunde Daten nach 20:00 bis vor 20:30 NICHT gelöscht


2021.05.21 00:25:57.304 3: DbRep DBRep_reduPower - ################################################################
2021.05.21 00:25:57.305 3: DbRep DBRep_reduPower - ###                    new reduceLog run                     ###
2021.05.21 00:25:57.305 3: DbRep DBRep_reduPower - ################################################################
2021.05.21 00:25:57.310 4: DbRep DBRep_reduPower - -------- New selection ---------
2021.05.21 00:25:57.311 4: DbRep DBRep_reduPower - Command: reduceLog
2021.05.21 00:25:57.314 4: DbRep DBRep_reduPower - timeDiffToNow - year: , day: 16, hour: , min: , sec:
2021.05.21 00:25:57.315 4: DbRep DBRep_reduPower - startMonth: 4 endMonth: 4 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:1
2021.05.21 00:25:57.315 4: DbRep DBRep_reduPower - timeOlderThan - year: 0, day: 10, hour: 0, min: 0, sec: 0
2021.05.21 00:25:57.317 4: DbRep DBRep_reduPower - startMonth: 1 endMonth: 4 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:1
2021.05.21 00:25:57.317 4: DbRep DBRep_reduPower - FullDay option: 1
2021.05.21 00:25:57.318 4: DbRep DBRep_reduPower - Time difference to current time for calculating Timestamp begin: 1382401 sec
2021.05.21 00:25:57.319 5: DbRep DBRep_reduPower - Timestamp begin epocheseconds: 1620165600
2021.05.21 00:25:57.319 4: DbRep DBRep_reduPower - Timestamp begin human readable: 2021-05-05 00:00:00
2021.05.21 00:25:57.320 4: DbRep DBRep_reduPower - Time difference to current time for calculating Timestamp end: 864001 sec
2021.05.21 00:25:57.321 5: DbRep DBRep_reduPower - Timestamp end epocheseconds: 1620770399
2021.05.21 00:25:57.321 4: DbRep DBRep_reduPower - Timestamp end human readable: 2021-05-11 23:59:59
2021.05.21 00:25:57.323 5: DbRep DBRep_reduPower - weekday start for selection: Mi  ->  wdadd: 432000
2021.05.21 00:25:57.541 5: DbRep DBRep_reduPower -> Start DbLog_reduceLog
2021.05.21 00:25:57.558 5: DbRep DBRep_reduPower - Devices for operation -
included (1): shelly_plug_s_df2674
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.21 00:25:57.559 5: DbRep DBRep_reduPower - Readings for operation -
included (1): power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.21 00:25:57.560 5: DbRep DBRep_reduPower - IsTimeSet: 1, IsAggrSet: 0
2021.05.21 00:25:57.567 5: DbRep DBRep_reduPower - Devices for operation -
included (1): shelly_plug_s_df2674
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.21 00:25:57.567 5: DbRep DBRep_reduPower - Readings for operation -
included (1): power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.05.21 00:25:57.568 4: DbRep DBRep_reduPower - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history where  ( DEVICE = 'shelly_plug_s_df2674' ) AND ( READING = 'power' ) AND TIMESTAMP >= '2021-05-05 00:00:00' AND TIMESTAMP <= '2021-05-11 23:59:59' ORDER BY TIMESTAMP ASC;
2021.05.21 00:25:57.569 3: DbRep DBRep_reduPower - reduce data older than: 2021-05-11 23:59:59, newer than: 2021-05-05 00:00:00
2021.05.21 00:25:57.569 3: DbRep DBRep_reduPower - reduceLog requested with options: AVERAGE=HOUR INCLUDE -> Devs: shelly_plug_s_df2674 Readings: power
2021.05.21 00:25:57.764 3: DbRep DBRep_reduPower - reduceLog deleting 257 records of day: 2021-05-05
2021.05.21 00:25:57.766 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 06:51:24) AND (VALUE=1.12)
2021.05.21 00:25:57.768 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 06:56:24) AND (VALUE=0.98)
2021.05.21 00:25:57.771 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 07:07:25) AND (VALUE=2.68)
2021.05.21 00:25:57.773 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 07:12:25) AND (VALUE=3.16)
2021.05.21 00:25:57.775 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 07:17:01) AND (VALUE=4.14)
....
....
2021.05.21 00:25:58.314 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 20:24:33) AND (VALUE=0.74)
2021.05.21 00:25:58.316 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-05 20:29:33) AND (VALUE=0.69)
2021.05.21 00:25:58.344 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 15 records of day: 2021-05-05
2021.05.21 00:25:58.345 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 06:30:00, EVENT='rl_av_h', VALUE=0.860 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 06:48:32 AND VALUE=0.48
2021.05.21 00:25:58.370 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 07:30:00, EVENT='rl_av_h', VALUE=4.747 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 07:01:15 AND VALUE=2.13
2021.05.21 00:25:58.376 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 08:30:00, EVENT='rl_av_h', VALUE=22.860 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 08:00:09 AND VALUE=13.59
2021.05.21 00:25:58.382 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 09:30:00, EVENT='rl_av_h', VALUE=38.230 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 09:00:03 AND VALUE=3.21
2021.05.21 00:25:58.391 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 10:30:00, EVENT='rl_av_h', VALUE=68.501 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 10:01:49 AND VALUE=2.18
2021.05.21 00:25:58.394 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 11:30:00, EVENT='rl_av_h', VALUE=148.714 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 11:00:25 AND VALUE=189.43
2021.05.21 00:25:58.397 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 12:30:00, EVENT='rl_av_h', VALUE=131.599 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 12:00:51 AND VALUE=50.67
2021.05.21 00:25:58.400 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 13:30:00, EVENT='rl_av_h', VALUE=109.276 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 13:01:06 AND VALUE=186.15
2021.05.21 00:25:58.403 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 14:30:00, EVENT='rl_av_h', VALUE=71.703 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 14:00:06 AND VALUE=145.84
2021.05.21 00:25:58.406 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 15:30:00, EVENT='rl_av_h', VALUE=97.882 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 15:01:42 AND VALUE=59.22
2021.05.21 00:25:58.409 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 16:30:00, EVENT='rl_av_h', VALUE=86.004 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 16:00:37 AND VALUE=201.8
2021.05.21 00:25:58.412 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 17:30:00, EVENT='rl_av_h', VALUE=42.370 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 17:00:25 AND VALUE=23.62
2021.05.21 00:25:58.415 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 18:30:00, EVENT='rl_av_h', VALUE=26.491 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 18:01:03 AND VALUE=19.95
2021.05.21 00:25:58.417 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 19:30:00, EVENT='rl_av_h', VALUE=10.182 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 19:02:37 AND VALUE=13.67
2021.05.21 00:25:58.420 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-05 20:30:00, EVENT='rl_av_h', VALUE=1.510 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-05 20:03:09 AND VALUE=2.32
.......
.......
2021.05.21 00:26:01.697 3: DbRep DBRep_reduPower - reduceLog deleting 223 records of day: 2021-05-11
2021.05.21 00:26:01.698 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:08:11) AND (VALUE=0.49)
2021.05.21 00:26:01.701 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:11:14) AND (VALUE=1.87)
2021.05.21 00:26:01.703 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:14:23) AND (VALUE=3.92)
2021.05.21 00:26:01.706 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:19:23) AND (VALUE=4.47)
2021.05.21 00:26:01.708 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:22:36) AND (VALUE=7.48)
2021.05.21 00:26:01.710 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:27:36) AND (VALUE=8.23)
2021.05.21 00:26:01.712 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:31:18) AND (VALUE=9.62)
2021.05.21 00:26:01.714 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:37:56) AND (VALUE=8.38)
2021.05.21 00:26:01.716 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:40:14) AND (VALUE=4.29)
2021.05.21 00:26:01.718 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:46:15) AND (VALUE=3.82)
2021.05.21 00:26:01.720 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:49:36) AND (VALUE=5.5)
2021.05.21 00:26:01.723 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:52:06) AND (VALUE=8.97)
2021.05.21 00:26:01.725 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:54:56) AND (VALUE=11.25)
2021.05.21 00:26:01.727 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:57:26) AND (VALUE=17.72)
2021.05.21 00:26:01.729 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 07:59:35) AND (VALUE=21.09)
2021.05.21 00:26:01.731 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:03:44) AND (VALUE=18.87)
2021.05.21 00:26:01.733 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:07:03) AND (VALUE=20.07)
2021.05.21 00:26:01.735 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:09:41) AND (VALUE=19.05)
2021.05.21 00:26:01.737 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:12:29) AND (VALUE=14.55)
2021.05.21 00:26:01.739 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:15:23) AND (VALUE=12.35)
2021.05.21 00:26:01.741 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:18:21) AND (VALUE=8.69)
2021.05.21 00:26:01.743 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:21:45) AND (VALUE=6.59)
2021.05.21 00:26:01.746 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:26:45) AND (VALUE=6.51)
2021.05.21 00:26:01.748 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:31:45) AND (VALUE=6.31)
2021.05.21 00:26:01.750 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:33:51) AND (VALUE=7.61)
2021.05.21 00:26:01.752 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:37:47) AND (VALUE=8.58)
2021.05.21 00:26:01.754 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:42:15) AND (VALUE=6.46)
2021.05.21 00:26:01.756 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:44:17) AND (VALUE=7.59)
2021.05.21 00:26:01.758 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:49:17) AND (VALUE=8.68)
2021.05.21 00:26:01.760 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:54:17) AND (VALUE=9.57)
2021.05.21 00:26:01.762 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 08:57:14) AND (VALUE=10.82)
2021.05.21 00:26:01.765 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:02:57) AND (VALUE=16.3)
2021.05.21 00:26:01.767 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:08:00) AND (VALUE=18.44)
2021.05.21 00:26:01.769 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:13:00) AND (VALUE=18.19)
2021.05.21 00:26:01.771 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:15:42) AND (VALUE=19.54)
2021.05.21 00:26:01.773 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:18:54) AND (VALUE=23.05)
2021.05.21 00:26:01.775 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:20:57) AND (VALUE=21.63)
2021.05.21 00:26:01.777 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:22:57) AND (VALUE=17.52)
2021.05.21 00:26:01.779 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:24:57) AND (VALUE=19.23)
2021.05.21 00:26:01.781 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:28:05) AND (VALUE=19.27)
2021.05.21 00:26:01.784 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:31:20) AND (VALUE=19.42)
2021.05.21 00:26:01.786 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:33:24) AND (VALUE=16.06)
2021.05.21 00:26:01.788 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:36:05) AND (VALUE=17.19)
2021.05.21 00:26:01.790 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:38:30) AND (VALUE=18.36)
2021.05.21 00:26:01.792 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:40:33) AND (VALUE=22.23)
2021.05.21 00:26:01.794 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:42:59) AND (VALUE=25.12)
2021.05.21 00:26:01.796 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:45:00) AND (VALUE=17.41)
2021.05.21 00:26:01.798 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:47:02) AND (VALUE=21.12)
2021.05.21 00:26:01.800 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:49:24) AND (VALUE=17.33)
2021.05.21 00:26:01.803 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:52:24) AND (VALUE=14.12)
2021.05.21 00:26:01.805 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:54:59) AND (VALUE=18.61)
2021.05.21 00:26:01.807 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 09:58:32) AND (VALUE=23.14)
2021.05.21 00:26:01.809 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:03:03) AND (VALUE=38.75)
2021.05.21 00:26:01.811 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:05:44) AND (VALUE=42.9)
2021.05.21 00:26:01.813 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:07:47) AND (VALUE=31.38)
2021.05.21 00:26:01.815 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:09:47) AND (VALUE=22.6)
2021.05.21 00:26:01.817 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:12:14) AND (VALUE=20.51)
2021.05.21 00:26:01.820 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:14:23) AND (VALUE=25.84)
2021.05.21 00:26:01.822 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:16:45) AND (VALUE=30.75)
2021.05.21 00:26:01.824 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:18:48) AND (VALUE=20.89)
2021.05.21 00:26:01.826 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:21:02) AND (VALUE=16.81)
2021.05.21 00:26:01.828 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:23:11) AND (VALUE=25.51)
2021.05.21 00:26:01.830 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:25:30) AND (VALUE=29.97)
2021.05.21 00:26:01.832 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:27:47) AND (VALUE=15.87)
2021.05.21 00:26:01.834 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:29:48) AND (VALUE=18.07)
2021.05.21 00:26:01.836 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:33:20) AND (VALUE=18.96)
2021.05.21 00:26:01.838 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:35:30) AND (VALUE=19.33)
2021.05.21 00:26:01.841 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:40:00) AND (VALUE=12.9)
2021.05.21 00:26:01.843 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:47:00) AND (VALUE=14.05)
2021.05.21 00:26:01.845 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:50:17) AND (VALUE=12.9)
2021.05.21 00:26:01.847 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:54:53) AND (VALUE=11.84)
2021.05.21 00:26:01.849 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 10:59:53) AND (VALUE=11.67)
2021.05.21 00:26:01.851 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:04:11) AND (VALUE=19.26)
2021.05.21 00:26:01.853 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:06:21) AND (VALUE=17.72)
2021.05.21 00:26:01.855 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:08:38) AND (VALUE=26.35)
2021.05.21 00:26:01.858 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:10:45) AND (VALUE=41.28)
2021.05.21 00:26:01.860 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:12:47) AND (VALUE=58.08)
2021.05.21 00:26:01.862 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:15:38) AND (VALUE=90.51)
2021.05.21 00:26:01.864 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:18:41) AND (VALUE=81.43)
2021.05.21 00:26:01.866 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:20:48) AND (VALUE=82.55)
2021.05.21 00:26:01.868 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:22:53) AND (VALUE=48.66)
2021.05.21 00:26:01.870 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:27:26) AND (VALUE=44.12)
2021.05.21 00:26:01.872 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:29:42) AND (VALUE=69.52)
2021.05.21 00:26:01.875 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:31:57) AND (VALUE=66.47)
2021.05.21 00:26:01.877 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:34:03) AND (VALUE=29.09)
2021.05.21 00:26:01.879 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:36:12) AND (VALUE=35.55)
2021.05.21 00:26:01.881 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:38:26) AND (VALUE=55.21)
2021.05.21 00:26:01.883 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:40:36) AND (VALUE=45.24)
2021.05.21 00:26:01.885 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:42:42) AND (VALUE=22.95)
2021.05.21 00:26:01.887 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:45:14) AND (VALUE=21.65)
2021.05.21 00:26:01.889 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:47:41) AND (VALUE=22.98)
2021.05.21 00:26:01.892 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:50:33) AND (VALUE=22)
2021.05.21 00:26:01.894 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:52:59) AND (VALUE=27.97)
2021.05.21 00:26:01.896 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:54:59) AND (VALUE=35.16)
2021.05.21 00:26:01.898 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 11:58:00) AND (VALUE=33.31)
2021.05.21 00:26:01.900 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:02:12) AND (VALUE=25.67)
2021.05.21 00:26:01.902 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:04:15) AND (VALUE=20.6)
2021.05.21 00:26:01.904 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:06:35) AND (VALUE=20.41)
2021.05.21 00:26:01.906 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:10:32) AND (VALUE=19.37)
2021.05.21 00:26:01.909 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:12:57) AND (VALUE=22.8)
2021.05.21 00:26:01.911 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2021-05-11 is: 100
2021.05.21 00:26:01.911 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:15:15) AND (VALUE=18.46)
2021.05.21 00:26:01.914 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:17:21) AND (VALUE=19.19)
2021.05.21 00:26:01.916 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:19:36) AND (VALUE=21.57)
2021.05.21 00:26:01.918 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:22:47) AND (VALUE=24.11)
2021.05.21 00:26:01.920 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:26:56) AND (VALUE=25.46)
2021.05.21 00:26:01.923 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:29:27) AND (VALUE=29.92)
2021.05.21 00:26:01.925 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:31:30) AND (VALUE=24.1)
2021.05.21 00:26:01.927 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:33:45) AND (VALUE=17.66)
2021.05.21 00:26:01.929 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:36:27) AND (VALUE=18.71)
2021.05.21 00:26:01.932 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:38:36) AND (VALUE=25.37)
2021.05.21 00:26:01.934 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:40:54) AND (VALUE=36.35)
2021.05.21 00:26:01.936 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:42:54) AND (VALUE=40.35)
2021.05.21 00:26:01.938 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:47:14) AND (VALUE=40.63)
2021.05.21 00:26:01.940 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:49:36) AND (VALUE=45.09)
2021.05.21 00:26:01.942 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:51:42) AND (VALUE=55.54)
2021.05.21 00:26:01.945 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:54:15) AND (VALUE=55.71)
2021.05.21 00:26:01.947 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 12:59:53) AND (VALUE=56.06)
2021.05.21 00:26:01.949 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:07:33) AND (VALUE=62.28)
2021.05.21 00:26:01.951 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:13:02) AND (VALUE=66.01)
2021.05.21 00:26:01.953 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:15:18) AND (VALUE=56.85)
2021.05.21 00:26:01.955 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:17:51) AND (VALUE=44.12)
2021.05.21 00:26:01.957 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:20:05) AND (VALUE=37.47)
2021.05.21 00:26:01.959 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:22:32) AND (VALUE=25.2)
2021.05.21 00:26:01.962 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:24:39) AND (VALUE=0)
2021.05.21 00:26:01.964 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:26:41) AND (VALUE=21.56)
2021.05.21 00:26:01.966 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:29:17) AND (VALUE=18.64)
2021.05.21 00:26:01.968 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:31:57) AND (VALUE=14.57)
2021.05.21 00:26:01.971 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:37:32) AND (VALUE=12.32)
2021.05.21 00:26:01.973 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:39:41) AND (VALUE=13.34)
2021.05.21 00:26:01.975 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:42:14) AND (VALUE=14.34)
2021.05.21 00:26:01.977 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:45:11) AND (VALUE=13.31)
2021.05.21 00:26:01.979 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:48:27) AND (VALUE=11.02)
2021.05.21 00:26:01.981 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:54:32) AND (VALUE=10.49)
2021.05.21 00:26:01.983 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 13:57:14) AND (VALUE=11.97)
2021.05.21 00:26:01.985 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:03:28) AND (VALUE=8.58)
2021.05.21 00:26:01.987 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:07:16) AND (VALUE=9.61)
2021.05.21 00:26:01.990 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:12:16) AND (VALUE=9.77)
2021.05.21 00:26:01.992 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:17:16) AND (VALUE=10.47)
2021.05.21 00:26:01.994 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:19:46) AND (VALUE=14.87)
2021.05.21 00:26:01.996 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:22:35) AND (VALUE=18.33)
2021.05.21 00:26:01.998 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:24:52) AND (VALUE=20.48)
2021.05.21 00:26:02.001 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:26:55) AND (VALUE=22.98)
2021.05.21 00:26:02.004 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:29:05) AND (VALUE=18.98)
2021.05.21 00:26:02.006 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:31:07) AND (VALUE=21.3)
2021.05.21 00:26:02.009 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:36:31) AND (VALUE=21.47)
2021.05.21 00:26:02.011 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:39:41) AND (VALUE=20.41)
2021.05.21 00:26:02.014 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:43:49) AND (VALUE=18.3)
2021.05.21 00:26:02.016 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:45:52) AND (VALUE=16.12)
2021.05.21 00:26:02.019 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:47:53) AND (VALUE=17.92)
2021.05.21 00:26:02.021 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:50:37) AND (VALUE=20.41)
2021.05.21 00:26:02.024 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:52:47) AND (VALUE=20.26)
2021.05.21 00:26:02.026 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:54:50) AND (VALUE=28.26)
2021.05.21 00:26:02.029 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 14:57:13) AND (VALUE=39.98)
2021.05.21 00:26:02.031 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:05:58) AND (VALUE=42.47)
2021.05.21 00:26:02.034 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:09:44) AND (VALUE=42.85)
2021.05.21 00:26:02.036 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:12:07) AND (VALUE=42.75)
2021.05.21 00:26:02.039 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:14:55) AND (VALUE=45.29)
2021.05.21 00:26:02.041 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:17:19) AND (VALUE=42.79)
2021.05.21 00:26:02.044 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:19:22) AND (VALUE=45.07)
2021.05.21 00:26:02.046 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:21:40) AND (VALUE=50.13)
2021.05.21 00:26:02.049 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:24:41) AND (VALUE=50.03)
2021.05.21 00:26:02.051 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:27:05) AND (VALUE=42.41)
2021.05.21 00:26:02.054 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:30:41) AND (VALUE=47.47)
2021.05.21 00:26:02.056 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:33:19) AND (VALUE=40.79)
2021.05.21 00:26:02.059 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:35:23) AND (VALUE=31.16)
2021.05.21 00:26:02.061 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:37:59) AND (VALUE=31.18)
2021.05.21 00:26:02.064 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:40:10) AND (VALUE=34.92)
2021.05.21 00:26:02.066 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:42:05) AND (VALUE=34.87)
2021.05.21 00:26:02.069 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:44:28) AND (VALUE=27.98)
2021.05.21 00:26:02.072 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:46:55) AND (VALUE=20.29)
2021.05.21 00:26:02.074 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 15:49:31) AND (VALUE=21.07)
2021.05.21 00:26:02.077 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:17:17) AND (VALUE=22.35)
2021.05.21 00:26:02.079 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:19:19) AND (VALUE=20.85)
2021.05.21 00:26:02.082 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:21:20) AND (VALUE=22.46)
2021.05.21 00:26:02.084 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:23:20) AND (VALUE=22.69)
2021.05.21 00:26:02.087 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:25:23) AND (VALUE=17.52)
2021.05.21 00:26:02.089 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:27:44) AND (VALUE=20.34)
2021.05.21 00:26:02.092 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:31:08) AND (VALUE=17.25)
2021.05.21 00:26:02.094 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:33:13) AND (VALUE=16.16)
2021.05.21 00:26:02.097 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:35:28) AND (VALUE=14.03)
2021.05.21 00:26:02.099 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:39:31) AND (VALUE=11.73)
2021.05.21 00:26:02.102 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:41:49) AND (VALUE=12.76)
2021.05.21 00:26:02.104 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:44:13) AND (VALUE=13.77)
2021.05.21 00:26:02.106 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:47:55) AND (VALUE=12.7)
2021.05.21 00:26:02.108 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:51:04) AND (VALUE=10.59)
2021.05.21 00:26:02.110 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:53:11) AND (VALUE=11.76)
2021.05.21 00:26:02.113 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:55:43) AND (VALUE=14.79)
2021.05.21 00:26:02.115 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 16:58:07) AND (VALUE=15.97)
2021.05.21 00:26:02.117 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:05:46) AND (VALUE=17)
2021.05.21 00:26:02.119 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:08:34) AND (VALUE=14.84)
2021.05.21 00:26:02.122 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:11:05) AND (VALUE=12.77)
2021.05.21 00:26:02.124 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:13:35) AND (VALUE=11.6)
2021.05.21 00:26:02.126 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:18:35) AND (VALUE=11.25)
2021.05.21 00:26:02.128 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:21:19) AND (VALUE=8.65)
2021.05.21 00:26:02.130 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:25:46) AND (VALUE=7.62)
2021.05.21 00:26:02.132 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:30:46) AND (VALUE=7.42)
2021.05.21 00:26:02.134 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:35:46) AND (VALUE=6.76)
2021.05.21 00:26:02.136 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:38:29) AND (VALUE=5.49)
2021.05.21 00:26:02.138 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:41:16) AND (VALUE=4.49)
2021.05.21 00:26:02.141 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:45:50) AND (VALUE=3.45)
2021.05.21 00:26:02.143 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2021-05-11 is: 200
2021.05.21 00:26:02.143 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:50:50) AND (VALUE=3.26)
2021.05.21 00:26:02.145 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 17:55:50) AND (VALUE=3.37)
2021.05.21 00:26:02.147 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:05:50) AND (VALUE=2.94)
2021.05.21 00:26:02.149 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:09:32) AND (VALUE=2.36)
2021.05.21 00:26:02.152 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:14:32) AND (VALUE=2.68)
2021.05.21 00:26:02.154 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:19:32) AND (VALUE=2.12)
2021.05.21 00:26:02.156 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:24:32) AND (VALUE=2.21)
2021.05.21 00:26:02.158 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:29:32) AND (VALUE=2.4)
2021.05.21 00:26:02.160 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:34:32) AND (VALUE=2.99)
2021.05.21 00:26:02.162 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:41:04) AND (VALUE=2.94)
2021.05.21 00:26:02.164 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:44:28) AND (VALUE=2.37)
2021.05.21 00:26:02.166 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:49:28) AND (VALUE=2.13)
2021.05.21 00:26:02.168 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:54:28) AND (VALUE=1.84)
2021.05.21 00:26:02.170 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 18:59:28) AND (VALUE=1.77)
2021.05.21 00:26:02.173 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:11:20) AND (VALUE=1.1)
2021.05.21 00:26:02.175 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:16:20) AND (VALUE=0.99)
2021.05.21 00:26:02.177 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:21:20) AND (VALUE=0.57)
2021.05.21 00:26:02.179 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:24:30) AND (VALUE=0)
2021.05.21 00:26:02.181 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:29:30) AND (VALUE=0.55)
2021.05.21 00:26:02.183 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:34:30) AND (VALUE=0.72)
2021.05.21 00:26:02.185 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:39:30) AND (VALUE=0.45)
2021.05.21 00:26:02.187 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:44:30) AND (VALUE=0.55)
2021.05.21 00:26:02.189 4: DbRep DBRep_reduPower - DELETE FROM history WHERE (DEVICE=shelly_plug_s_df2674) AND (READING=power) AND (TIMESTAMP=2021-05-11 19:49:30) AND (VALUE=0)
2021.05.21 00:26:02.201 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 13 records of day: 2021-05-11
2021.05.21 00:26:02.202 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 07:30:00, EVENT='rl_av_h', VALUE=7.340 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 07:03:11 AND VALUE=0.34
2021.05.21 00:26:02.206 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 08:30:00, EVENT='rl_av_h', VALUE=11.101 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 08:01:42 AND VALUE=16.42
2021.05.21 00:26:02.209 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 09:30:00, EVENT='rl_av_h', VALUE=18.977 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 09:00:00 AND VALUE=14.21
2021.05.21 00:26:02.214 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 10:30:00, EVENT='rl_av_h', VALUE=22.318 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 10:00:51 AND VALUE=27.18
2021.05.21 00:26:02.218 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 11:30:00, EVENT='rl_av_h', VALUE=42.126 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 11:02:09 AND VALUE=13.97
2021.05.21 00:26:02.223 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 12:30:00, EVENT='rl_av_h', VALUE=30.138 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 12:00:12 AND VALUE=30.05
2021.05.21 00:26:02.227 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 13:30:00, EVENT='rl_av_h', VALUE=27.147 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 13:04:53 AND VALUE=55.16
2021.05.21 00:26:02.232 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 14:30:00, EVENT='rl_av_h', VALUE=18.297 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 14:00:34 AND VALUE=7.44
2021.05.21 00:26:02.236 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 15:30:00, EVENT='rl_av_h', VALUE=38.738 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 15:03:19 AND VALUE=42.51
2021.05.21 00:26:02.240 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 16:30:00, EVENT='rl_av_h', VALUE=16.607 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 16:14:08 AND VALUE=21.2
2021.05.21 00:26:02.243 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 17:30:00, EVENT='rl_av_h', VALUE=8.999 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 17:00:34 AND VALUE=17.01
2021.05.21 00:26:02.246 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 18:30:00, EVENT='rl_av_h', VALUE=2.468 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 18:00:50 AND VALUE=3.33
2021.05.21 00:26:02.249 4: DbRep DBRep_reduPower - UPDATE history SET TIMESTAMP=2021-05-11 19:30:00, EVENT='rl_av_h', VALUE=0.631 WHERE DEVICE=shelly_plug_s_df2674 AND READING=power AND TIMESTAMP=2021-05-11 19:06:20 AND VALUE=1.38
2021.05.21 00:26:02.259 3: DbRep DBRep_reduPower - reduceLog finished. Rows processed: 1793, deleted: 1688, updated: 101
2021.05.21 00:26:02.260 5: DbRep DBRep_reduPower -> DbRep_reduceLogNbl finished


letzte SQL Daten am 11.05

"TIMESTAMP"            "DEVICE"                "TYPE"    "EVENT"        "READING"  "VALUE" "UNIT"
"2021-05-11 20:14:30"  "shelly_plug_s_df2674"  "SHELLY"  "power: 0"     "power"    "0"      ""
"2021-05-11 20:09:30"  "shelly_plug_s_df2674"  "SHELLY"  "power: 0.38"  "power"    "0.38"   ""
"2021-05-11 20:04:30"  "shelly_plug_s_df2674"  "SHELLY"  "power: 0.55"  "power"    "0.55"   ""
"2021-05-11 19:30:00"  "shelly_plug_s_df2674"  "SHELLY"  "rl_av_h"      "power"    "0.631"  ""
"2021-05-11 18:30:00"  "shelly_plug_s_df2674"  "SHELLY"  "rl_av_h"      "power"    "2.468"  ""


Irgendwie werden immer am letzten Tag (hier 11.05) die Daten unvollständign bearbeitet.
...oder ich bin auf dem völlig faschen Dampfer
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Mai 2021, 08:58:09
Hallo Ralf,

danke für die vielen Infos. Ich lese immer mit, aber es wird noch einige Zeit dauern bis ich mich wieder mit DbRep/DbLog beschäftige. Habe noch einige Dinge vorher in der Pipiline.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 21 Mai 2021, 12:08:15
Alles gut - eventuell irre ich mich ja auch.
Die meisten Sachen sind nicht wirklich dramatisch - lediglich unsauber und fallen meistens vermutlich noch nicht mal wirklich negativ auf.
Das average=day im DBRep ist schon blöd , da der tägliche average einfach nicht gebildet wird (Test#5/6).

Ich bin darauf gestoßen, da ich meine Spritpreise und die power/energy der kleinen PV-Anlage mit überschaubarer Datenmenge in eine Maria-DB überführt hatte.
Parallel habe ich dann immer mit einem "SQL-Viewer" (HeidiSQL) in die Tabellen geschaut (bei Milionen Datensätzen von vielen Devices bekommt man das wohl nicht mit).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 21 Mai 2021, 15:09:09
Oh Mist....
mit dem Beitrag heute Nacht und den vielen Logdaten hat es die Ansicht immer verbaselt.
Bei meinen Korrekturversuchen habe ich versehentlich den Beitrag mit den Tests#1/2/3 auf DBlog mit reduceLog / reduveLog average / reduceLog average=day gelöscht.

==> Kann ich nochmal erstellen.

Melde dich wenn du es dir anschauen willst. Vermutlich macht es sowie Sinn schrittweise ranzugehen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 29 Mai 2021, 12:38:26
Damit der Zusammenhang erhalten bleibt hier die Test#1 bis 3 am DBLog selbst durch Aufarbeitung der Logdatei vom 17.5

Test #1 auf DBLog Device (DBTest) mit reduceLogNbl requested with DAYS=18:48, INCLUDE=Jet:E10
Testdatenbank mit Daten von 30.03 bis 17.05 / ReduceLog von 30.03 bis 28.04
am 30.03 werden jeweils ganze Tage auf stündliche Werte reduziert; nur der jüngste Tag am 28.04 wird nach 20:30 nicht mehr reduziert
==> also am Ende des Zeitraus etwas unsauber; es sollten vielleicht immer ganze Tage sein


2021.05.17 20:17:24.140 5: DbLog DBTest -> Start DbLog_reduceLogNbl
2021.05.17 20:17:24.153 3: DbLog DBTest: reduceLogNbl requested with DAYS=18:48, INCLUDE=Jet:E10
2021.05.17 20:17:24.153 4: DbLog DBTest -> AutoCommit mode: ON, Transaction mode: ON
2021.05.17 20:17:24.198 3: DbLog DBTest: reduceLogNbl deleting 8 records of day: 2021-03-30
2021.05.17 20:17:24.199 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 10:33:54) AND (VALUE=147.9)
2021.05.17 20:17:24.202 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 10:44:54) AND (VALUE=145.9)
2021.05.17 20:17:24.205 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 11:57:54) AND (VALUE=140.9)
2021.05.17 20:17:24.207 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 13:38:56) AND (VALUE=143.9)
2021.05.17 20:17:24.210 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 14:43:56) AND (VALUE=139.9)
2021.05.17 20:17:24.212 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 16:38:58) AND (VALUE=141.9)
2021.05.17 20:17:24.215 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 17:51:09) AND (VALUE=143.9)
2021.05.17 20:17:24.218 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 19:28:06) AND (VALUE=142.9)
2021.05.17 20:17:24.230 3: DbLog DBTest: reduceLogNbl deleting 11 records of day: 2021-03-31
2021.05.17 20:17:24.232 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 06:52:10) AND (VALUE=151.9)
2021.05.17 20:17:24.234 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 08:37:10) AND (VALUE=146.9)
2021.05.17 20:17:24.236 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 09:28:10) AND (VALUE=147.9)
2021.05.17 20:17:24.238 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 10:39:12) AND (VALUE=145.9)
2021.05.17 20:17:24.241 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 12:29:13) AND (VALUE=148.9)
2021.05.17 20:17:24.243 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:13:13) AND (VALUE=144.9)
2021.05.17 20:17:24.245 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 14:19:13) AND (VALUE=143.9)
2021.05.17 20:17:24.247 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 15:29:14) AND (VALUE=147.9)
2021.05.17 20:17:24.249 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:44:14) AND (VALUE=145.9)
2021.05.17 20:17:24.251 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 16:53:14) AND (VALUE=143.9)
2021.05.17 20:17:24.253 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-31 19:27:14) AND (VALUE=146.9)
.....
31.03 bis 26.04 ok und daher aus dem Log genommen
.....
2021.05.17 20:17:25.025 3: DbLog DBTest: reduceLogNbl deleting 13 records of day: 2021-04-27
2021.05.17 20:17:25.026 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 09:26:53) AND (VALUE=153.9)
2021.05.17 20:17:25.028 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 10:44:54) AND (VALUE=148.9)
2021.05.17 20:17:25.031 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 11:08:54) AND (VALUE=144.9)
2021.05.17 20:17:25.033 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 12:27:55) AND (VALUE=148.9)
2021.05.17 20:17:25.035 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 13:39:56) AND (VALUE=147.9)
2021.05.17 20:17:25.037 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 14:16:56) AND (VALUE=146.9)
2021.05.17 20:17:25.038 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 14:18:56) AND (VALUE=144.9)
2021.05.17 20:17:25.040 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 15:28:57) AND (VALUE=148.9)
2021.05.17 20:17:25.042 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 16:38:58) AND (VALUE=146.9)
2021.05.17 20:17:25.044 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 17:17:58) AND (VALUE=143.9)
2021.05.17 20:17:25.046 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 17:26:58) AND (VALUE=146.9)
2021.05.17 20:17:25.048 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 19:28:00) AND (VALUE=145.9)
2021.05.17 20:17:25.050 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 22:52:02) AND (VALUE=147.9)
2021.05.17 20:17:25.061 3: DbLog DBTest: reduceLogNbl deleting 9 records of day: 2021-04-28
2021.05.17 20:17:25.062 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 06:53:08) AND (VALUE=151.9)
2021.05.17 20:17:25.065 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 08:34:10) AND (VALUE=149.9)
2021.05.17 20:17:25.067 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 11:24:11) AND (VALUE=147.9)
2021.05.17 20:17:25.069 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 12:28:12) AND (VALUE=151.9)
2021.05.17 20:17:25.071 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 13:38:13) AND (VALUE=147.9)
2021.05.17 20:17:25.073 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 14:59:14) AND (VALUE=143.9)
2021.05.17 20:17:25.075 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 16:48:15) AND (VALUE=145.9)
2021.05.17 20:17:25.077 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 17:29:15) AND (VALUE=146.9)
2021.05.17 20:17:25.079 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 19:28:17) AND (VALUE=142.9)
2021.05.17 20:17:25.086 3: DbLog DBTest: reduceLogNbl finished. Rows processed: 992, deleted: 271, time: 0.95sec
2021.05.17 20:17:25.087 5: DbLog DBTest -> DbLog_reduceLogNbl finished
-------------------------------------------------------------------------------------------------
Daten:
"2021-04-28 23:53:20";"Jet";"HTTPMOD";"E10: 145.9  Cent";"E10";"145.9";"Cent"

"2021-04-28 22:53:19";"Jet";"HTTPMOD";"E10: 145.9  Cent";"E10";"145.9";"Cent" => nicht gelöscht nok

"2021-04-28 22:24:19";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent"
"2021-04-28 21:24:18";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent"
"2021-04-28 20:24:18";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent"
"2021-04-28 19:28:17";"Jet";"HTTPMOD";"E10: 142.9  Cent";"E10";"142.9";"Cent" => gelöscht ok
"2021-04-28 19:19:17";"Jet";"HTTPMOD";"E10: 139.9  Cent";"E10";"139.9";"Cent"
"2021-04-28 18:19:16";"Jet";"HTTPMOD";"E10: 139.9  Cent";"E10";"139.9";"Cent"
"2021-04-28 17:29:15";"Jet";"HTTPMOD";"E10: 146.9  Cent";"E10";"146.9";"Cent" => gelöscht ok
"2021-04-28 17:09:15";"Jet";"HTTPMOD";"E10: 144.9  Cent";"E10";"144.9";"Cent"



Test #2 auf DBLog Device (DBTest) mit reduceLogNbl requested with DAYS=18:48, AVERAGE=HOUR, INCLUDE=Jet:E10
Testdatenbank mit Daten von 30.03 bis 17.05 / ReduceLog Average von 30.03 bis 28.04
ab 30.03 werden jeweils ganze Tage auf stündlichen Durchschnitt um hh:30 reduziert; nur der jüngste Tag am 28.04 wird nach 20:30 nicht mehr reduziert
==> also am Ende des Zeitraus unsauber; Durchschnitt wird gebildet aber am Ende nicht alle entsprechenden Daten gelöscht; es sollten vielleicht immer ganze Tage bearbeitet werden


2021.05.17 20:38:55.034 5: DbLog DBTest -> Start DbLog_reduceLogNbl
2021.05.17 20:38:55.044 3: DbLog DBTest: reduceLogNbl requested with DAYS=18:48, AVERAGE=HOUR, INCLUDE=Jet:E10
2021.05.17 20:38:55.045 4: DbLog DBTest -> AutoCommit mode: ON, Transaction mode: ON
2021.05.17 20:38:55.088 3: DbLog DBTest: reduceLogNbl deleting 8 records of day: 2021-03-30
2021.05.17 20:38:55.090 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 10:33:54) AND (VALUE=147.9)
2021.05.17 20:38:55.093 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 10:44:54) AND (VALUE=145.9)
2021.05.17 20:38:55.095 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 11:57:54) AND (VALUE=140.9)
2021.05.17 20:38:55.098 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 13:38:56) AND (VALUE=143.9)
2021.05.17 20:38:55.101 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 14:43:56) AND (VALUE=139.9)
2021.05.17 20:38:55.103 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 16:38:58) AND (VALUE=141.9)
2021.05.17 20:38:55.105 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 17:51:09) AND (VALUE=143.9)
2021.05.17 20:38:55.107 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 19:28:06) AND (VALUE=142.9)
2021.05.17 20:38:55.117 3: DbLog DBTest: reduceLogNbl (hourly-average) updating 7 records of day: 2021-03-30
2021.05.17 20:38:55.118 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 10:30:00, EVENT='rl_av_h', VALUE=149.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 10:26:54 AND VALUE=153.9
2021.05.17 20:38:55.121 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 11:30:00, EVENT='rl_av_h', VALUE=142.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 11:17:54 AND VALUE=144.9
2021.05.17 20:38:55.124 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 13:30:00, EVENT='rl_av_h', VALUE=144.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 13:26:55 AND VALUE=144.9
2021.05.17 20:38:55.128 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 14:30:00, EVENT='rl_av_h', VALUE=141.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 14:38:56 AND VALUE=143.9
2021.05.17 20:38:55.131 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 16:30:00, EVENT='rl_av_h', VALUE=142.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 16:26:58 AND VALUE=143.9
2021.05.17 20:38:55.134 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 17:30:00, EVENT='rl_av_h', VALUE=143.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 17:27:59 AND VALUE=143.9
2021.05.17 20:38:55.138 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 19:30:00, EVENT='rl_av_h', VALUE=141.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 19:20:06 AND VALUE=139.9
....
31.03 bis 26.04 ok und daher aus dem Log genommen
....
2021.05.17 20:38:56.838 3: DbLog DBTest: reduceLogNbl deleting 13 records of day: 2021-04-27
2021.05.17 20:38:56.840 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 09:26:53) AND (VALUE=153.9)
2021.05.17 20:38:56.843 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 10:44:54) AND (VALUE=148.9)
2021.05.17 20:38:56.845 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 11:08:54) AND (VALUE=144.9)
2021.05.17 20:38:56.847 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 12:27:55) AND (VALUE=148.9)
2021.05.17 20:38:56.849 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 13:39:56) AND (VALUE=147.9)
2021.05.17 20:38:56.851 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 14:16:56) AND (VALUE=146.9)
2021.05.17 20:38:56.853 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 14:18:56) AND (VALUE=144.9)
2021.05.17 20:38:56.855 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 15:28:57) AND (VALUE=148.9)
2021.05.17 20:38:56.857 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 16:38:58) AND (VALUE=146.9)
2021.05.17 20:38:56.859 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 17:17:58) AND (VALUE=143.9)
2021.05.17 20:38:56.861 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 17:26:58) AND (VALUE=146.9)
2021.05.17 20:38:56.863 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 19:28:00) AND (VALUE=145.9)
2021.05.17 20:38:56.865 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 22:52:02) AND (VALUE=147.9)
2021.05.17 20:38:56.873 3: DbLog DBTest: reduceLogNbl (hourly-average) updating 11 records of day: 2021-04-27
2021.05.17 20:38:56.874 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 09:30:00, EVENT='rl_av_h', VALUE=151.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 09:24:53 AND VALUE=148.9
2021.05.17 20:38:56.877 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 10:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 10:18:53 AND VALUE=149.9
2021.05.17 20:38:56.880 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 11:30:00, EVENT='rl_av_h', VALUE=146.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 11:05:54 AND VALUE=147.9
2021.05.17 20:38:56.883 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 12:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 12:08:55 AND VALUE=144.9
2021.05.17 20:38:56.886 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 13:30:00, EVENT='rl_av_h', VALUE=148.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 13:27:55 AND VALUE=148.9
2021.05.17 20:38:56.888 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 14:30:00, EVENT='rl_av_h', VALUE=145.567 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 14:08:56 AND VALUE=144.9
2021.05.17 20:38:56.891 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 15:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 15:18:57 AND VALUE=144.9
2021.05.17 20:38:56.894 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 16:30:00, EVENT='rl_av_h', VALUE=147.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 16:28:57 AND VALUE=148.9
2021.05.17 20:38:56.897 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 17:30:00, EVENT='rl_av_h', VALUE=145.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 17:01:58 AND VALUE=144.9
2021.05.17 20:38:56.899 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 19:30:00, EVENT='rl_av_h', VALUE=144.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 19:18:59 AND VALUE=142.9
2021.05.17 20:38:56.902 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 22:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 22:03:02 AND VALUE=143.9
2021.05.17 20:38:56.914 3: DbLog DBTest: reduceLogNbl deleting 9 records of day: 2021-04-28
2021.05.17 20:38:56.916 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 06:53:08) AND (VALUE=151.9)
2021.05.17 20:38:56.918 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 08:34:10) AND (VALUE=149.9)
2021.05.17 20:38:56.921 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 11:24:11) AND (VALUE=147.9)
2021.05.17 20:38:56.923 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 12:28:12) AND (VALUE=151.9)
2021.05.17 20:38:56.925 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 13:38:13) AND (VALUE=147.9)
2021.05.17 20:38:56.927 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 14:59:14) AND (VALUE=143.9)
2021.05.17 20:38:56.928 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 16:48:15) AND (VALUE=145.9)
2021.05.17 20:38:56.931 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 17:29:15) AND (VALUE=146.9)
2021.05.17 20:38:56.933 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 19:28:17) AND (VALUE=142.9)
2021.05.17 20:38:56.940 3: DbLog DBTest: reduceLogNbl (hourly-average) updating 10 records of day: 2021-04-28
2021.05.17 20:38:56.941 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 06:30:00, EVENT='rl_av_h', VALUE=150.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 06:01:08 AND VALUE=149.9
2021.05.17 20:38:56.944 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 08:30:00, EVENT='rl_av_h', VALUE=150.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 08:25:09 AND VALUE=150.9
2021.05.17 20:38:56.947 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 11:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 11:19:11 AND VALUE=150.9
2021.05.17 20:38:56.950 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 12:30:00, EVENT='rl_av_h', VALUE=149.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 12:24:12 AND VALUE=147.9
2021.05.17 20:38:56.953 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 13:30:00, EVENT='rl_av_h', VALUE=148.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 13:19:13 AND VALUE=149.9
2021.05.17 20:38:56.956 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 14:30:00, EVENT='rl_av_h', VALUE=144.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 14:09:13 AND VALUE=144.9
2021.05.17 20:38:56.959 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 16:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 16:29:15 AND VALUE=147.9
2021.05.17 20:38:56.961 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 17:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 17:09:15 AND VALUE=144.9
2021.05.17 20:38:56.964 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 19:30:00, EVENT='rl_av_h', VALUE=141.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 19:19:17 AND VALUE=139.9
2021.05.17 20:38:56.967 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 22:30:00, EVENT='rl_av_h', VALUE=143.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 22:24:19 AND VALUE=141.9
2021.05.17 20:38:56.976 3: DbLog DBTest: reduceLogNbl finished. Rows processed: 992, deleted: 271, updated: 240, time: 1.94sec
2021.05.17 20:38:56.977 5: DbLog DBTest -> DbLog_reduceLogNbl finished
-------------------------------------------------------------------------------------------------
Daten:
"2021-04-28 23:53:20";"Jet";"HTTPMOD";"E10: 145.9  Cent";"E10";"145.9";"Cent"  => unverändert ok

"2021-04-28 22:53:19";"Jet";"HTTPMOD";"E10: 145.9  Cent";"E10";"145.9";"Cent" => nicht gelöscht nok

"2021-04-28 22:24:19";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent" => Update Mittelwert ok
"2021-04-28 21:24:18";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent"  => unverändert ok
"2021-04-28 20:24:18";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent" => unverändert ok
"2021-04-28 19:28:17";"Jet";"HTTPMOD";"E10: 142.9  Cent";"E10";"142.9";"Cent" => gelöscht ok
"2021-04-28 19:19:17";"Jet";"HTTPMOD";"E10: 139.9  Cent";"E10";"139.9";"Cent" => Update Mittelwert ok
"2021-04-28 18:19:16";"Jet";"HTTPMOD";"E10: 139.9  Cent";"E10";"139.9";"Cent" => unverändert ok
"2021-04-28 17:29:15";"Jet";"HTTPMOD";"E10: 146.9  Cent";"E10";"146.9";"Cent" => gelöscht ok
"2021-04-28 17:09:15";"Jet";"HTTPMOD";"E10: 144.9  Cent";"E10";"144.9";"Cent" => Update Mittelwert ok



Test #3 auf DBLog Device (DBTest) mit reduceLogNbl requested with DAYS=18:48, AVERAGE=DAY, INCLUDE=Jet:E10
Testdatenbank mit Daten von 30.03 bis 17.05 / ReduceLog Average=Day von 30.03 bis 28.04
ab 30.03 werden jeweils ganze Tage auf den stündlichen Durchschnitt und danach auf täglichen Durchschnitt reduziert; am jüngste Tag 28.4 wird direkt im Log ersichtlich kein täglicher Durchschnitt gebildet
==> also am Ende des Zeitraus unsauber; Durchschnitt wird gebildet aber am Ende nicht alle entsprechenden Daten gelöscht; es sollten vielleicht immer ganze Tage bearbeitet werden


2021.05.17 20:58:30.474 5: DbLog DBTest -> Start DbLog_reduceLogNbl
2021.05.17 20:58:30.484 3: DbLog DBTest: reduceLogNbl requested with DAYS=18:48, AVERAGE=DAY, INCLUDE=Jet:E10
2021.05.17 20:58:30.485 4: DbLog DBTest -> AutoCommit mode: ON, Transaction mode: ON
2021.05.17 20:58:30.523 3: DbLog DBTest: reduceLogNbl deleting 8 records of day: 2021-03-30
2021.05.17 20:58:30.525 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 10:33:54) AND (VALUE=147.9)
2021.05.17 20:58:30.528 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 10:44:54) AND (VALUE=145.9)
2021.05.17 20:58:30.530 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 11:57:54) AND (VALUE=140.9)
2021.05.17 20:58:30.532 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 13:38:56) AND (VALUE=143.9)
2021.05.17 20:58:30.535 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 14:43:56) AND (VALUE=139.9)
2021.05.17 20:58:30.537 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 16:38:58) AND (VALUE=141.9)
2021.05.17 20:58:30.539 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 17:51:09) AND (VALUE=143.9)
2021.05.17 20:58:30.542 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 19:28:06) AND (VALUE=142.9)
2021.05.17 20:58:30.554 3: DbLog DBTest: reduceLogNbl (hourly-average) updating 7 records of day: 2021-03-30
2021.05.17 20:58:30.556 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 10:30:00, EVENT='rl_av_h', VALUE=149.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 10:26:54 AND VALUE=153.9
2021.05.17 20:58:30.560 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 11:30:00, EVENT='rl_av_h', VALUE=142.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 11:17:54 AND VALUE=144.9
2021.05.17 20:58:30.563 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 13:30:00, EVENT='rl_av_h', VALUE=144.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 13:26:55 AND VALUE=144.9
2021.05.17 20:58:30.567 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 14:30:00, EVENT='rl_av_h', VALUE=141.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 14:38:56 AND VALUE=143.9
2021.05.17 20:58:30.570 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 16:30:00, EVENT='rl_av_h', VALUE=142.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 16:26:58 AND VALUE=143.9
2021.05.17 20:58:30.573 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 17:30:00, EVENT='rl_av_h', VALUE=143.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 17:27:59 AND VALUE=143.9
2021.05.17 20:58:30.576 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 19:30:00, EVENT='rl_av_h', VALUE=141.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-03-30 19:20:06 AND VALUE=139.9
2021.05.17 20:58:30.587 3: DbLog DBTest: reduceLogNbl (daily-average) updating 1, deleting 23 records of day: 2021-03-30
2021.05.17 20:58:30.588 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 00:26:45'
2021.05.17 20:58:30.591 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 01:26:46'
2021.05.17 20:58:30.593 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 02:26:47'
2021.05.17 20:58:30.595 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 03:26:48'
2021.05.17 20:58:30.597 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 04:26:48'
2021.05.17 20:58:30.598 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 05:26:49'
2021.05.17 20:58:30.600 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 06:26:50'
2021.05.17 20:58:30.602 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 07:26:51'
2021.05.17 20:58:30.604 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 08:26:51'
2021.05.17 20:58:30.606 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 09:26:52'
2021.05.17 20:58:30.608 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 10:30:00'
2021.05.17 20:58:30.610 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 11:30:00'
2021.05.17 20:58:30.612 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 12:26:55'
2021.05.17 20:58:30.614 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 13:30:00'
2021.05.17 20:58:30.616 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 14:30:00'
2021.05.17 20:58:30.618 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 15:26:57'
2021.05.17 20:58:30.620 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 16:30:00'
2021.05.17 20:58:30.622 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 17:30:00'
2021.05.17 20:58:30.624 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 18:20:06'
2021.05.17 20:58:30.625 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 19:30:00'
2021.05.17 20:58:30.627 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 20:24:06'
2021.05.17 20:58:30.629 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 21:24:07'
2021.05.17 20:58:30.631 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-03-30 22:24:07'
2021.05.17 20:58:30.633 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-03-30 12:00:00, EVENT='rl_av_d', VALUE=147.247 WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-03-30 23:24:07)
...
31.03 bis 26.04 ok und daher aus dem Log genommen
...
2021.05.17 20:58:34.119 3: DbLog DBTest: reduceLogNbl deleting 13 records of day: 2021-04-27
2021.05.17 20:58:34.121 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 09:26:53) AND (VALUE=153.9)
2021.05.17 20:58:34.123 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 10:44:54) AND (VALUE=148.9)
2021.05.17 20:58:34.126 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 11:08:54) AND (VALUE=144.9)
2021.05.17 20:58:34.128 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 12:27:55) AND (VALUE=148.9)
2021.05.17 20:58:34.130 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 13:39:56) AND (VALUE=147.9)
2021.05.17 20:58:34.132 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 14:16:56) AND (VALUE=146.9)
2021.05.17 20:58:34.134 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 14:18:56) AND (VALUE=144.9)
2021.05.17 20:58:34.136 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 15:28:57) AND (VALUE=148.9)
2021.05.17 20:58:34.138 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 16:38:58) AND (VALUE=146.9)
2021.05.17 20:58:34.140 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 17:17:58) AND (VALUE=143.9)
2021.05.17 20:58:34.142 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 17:26:58) AND (VALUE=146.9)
2021.05.17 20:58:34.144 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 19:28:00) AND (VALUE=145.9)
2021.05.17 20:58:34.147 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 22:52:02) AND (VALUE=147.9)
2021.05.17 20:58:34.158 3: DbLog DBTest: reduceLogNbl (hourly-average) updating 11 records of day: 2021-04-27
2021.05.17 20:58:34.160 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 09:30:00, EVENT='rl_av_h', VALUE=151.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 09:24:53 AND VALUE=148.9
2021.05.17 20:58:34.163 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 10:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 10:18:53 AND VALUE=149.9
2021.05.17 20:58:34.166 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 11:30:00, EVENT='rl_av_h', VALUE=146.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 11:05:54 AND VALUE=147.9
2021.05.17 20:58:34.169 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 12:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 12:08:55 AND VALUE=144.9
2021.05.17 20:58:34.172 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 13:30:00, EVENT='rl_av_h', VALUE=148.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 13:27:55 AND VALUE=148.9
2021.05.17 20:58:34.176 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 14:30:00, EVENT='rl_av_h', VALUE=145.567 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 14:08:56 AND VALUE=144.9
2021.05.17 20:58:34.179 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 15:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 15:18:57 AND VALUE=144.9
2021.05.17 20:58:34.182 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 16:30:00, EVENT='rl_av_h', VALUE=147.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 16:28:57 AND VALUE=148.9
2021.05.17 20:58:34.185 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 17:30:00, EVENT='rl_av_h', VALUE=145.233 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 17:01:58 AND VALUE=144.9
2021.05.17 20:58:34.189 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 19:30:00, EVENT='rl_av_h', VALUE=144.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 19:18:59 AND VALUE=142.9
2021.05.17 20:58:34.192 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 22:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-27 22:03:02 AND VALUE=143.9
2021.05.17 20:58:34.203 3: DbLog DBTest: reduceLogNbl (daily-average) updating 1, deleting 23 records of day: 2021-04-27
2021.05.17 20:58:34.204 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 00:52:46'
2021.05.17 20:58:34.206 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 01:52:47'
2021.05.17 20:58:34.209 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 02:52:47'
2021.05.17 20:58:34.211 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 03:52:48'
2021.05.17 20:58:34.214 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 04:52:49'
2021.05.17 20:58:34.216 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 05:52:50'
2021.05.17 20:58:34.218 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 06:52:51'
2021.05.17 20:58:34.221 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 07:24:51'
2021.05.17 20:58:34.223 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 08:24:52'
2021.05.17 20:58:34.226 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 09:30:00'
2021.05.17 20:58:34.228 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 10:30:00'
2021.05.17 20:58:34.231 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 11:30:00'
2021.05.17 20:58:34.233 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 12:30:00'
2021.05.17 20:58:34.235 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 13:30:00'
2021.05.17 20:58:34.238 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 14:30:00'
2021.05.17 20:58:34.240 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 15:30:00'
2021.05.17 20:58:34.242 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 16:30:00'
2021.05.17 20:58:34.245 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 17:30:00'
2021.05.17 20:58:34.247 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 18:18:59'
2021.05.17 20:58:34.250 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 19:30:00'
2021.05.17 20:58:34.252 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 20:28:01'
2021.05.17 20:58:34.255 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 21:03:01'
2021.05.17 20:58:34.257 5: DbLog DBTest: DELETE FROM history WHERE DEVICE='Jet' AND READING='E10' AND TIMESTAMP='2021-04-27 22:30:00'
2021.05.17 20:58:34.259 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-27 12:00:00, EVENT='rl_av_d', VALUE=147.546 WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-27 23:52:03)
2021.05.17 20:58:34.273 3: DbLog DBTest: reduceLogNbl deleting 9 records of day: 2021-04-28
2021.05.17 20:58:34.276 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 06:53:08) AND (VALUE=151.9)
2021.05.17 20:58:34.280 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 08:34:10) AND (VALUE=149.9)
2021.05.17 20:58:34.282 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 11:24:11) AND (VALUE=147.9)
2021.05.17 20:58:34.285 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 12:28:12) AND (VALUE=151.9)
2021.05.17 20:58:34.287 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 13:38:13) AND (VALUE=147.9)
2021.05.17 20:58:34.289 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 14:59:14) AND (VALUE=143.9)
2021.05.17 20:58:34.292 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 16:48:15) AND (VALUE=145.9)
2021.05.17 20:58:34.294 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 17:29:15) AND (VALUE=146.9)
2021.05.17 20:58:34.296 4: DbLog DBTest: DELETE FROM history WHERE (DEVICE=Jet) AND (READING=E10) AND (TIMESTAMP=2021-04-28 19:28:17) AND (VALUE=142.9)
2021.05.17 20:58:34.307 3: DbLog DBTest: reduceLogNbl (hourly-average) updating 10 records of day: 2021-04-28
2021.05.17 20:58:34.308 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 06:30:00, EVENT='rl_av_h', VALUE=150.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 06:01:08 AND VALUE=149.9
2021.05.17 20:58:34.312 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 08:30:00, EVENT='rl_av_h', VALUE=150.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 08:25:09 AND VALUE=150.9
2021.05.17 20:58:34.315 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 11:30:00, EVENT='rl_av_h', VALUE=149.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 11:19:11 AND VALUE=150.9
2021.05.17 20:58:34.318 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 12:30:00, EVENT='rl_av_h', VALUE=149.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 12:24:12 AND VALUE=147.9
2021.05.17 20:58:34.322 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 13:30:00, EVENT='rl_av_h', VALUE=148.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 13:19:13 AND VALUE=149.9
2021.05.17 20:58:34.325 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 14:30:00, EVENT='rl_av_h', VALUE=144.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 14:09:13 AND VALUE=144.9
2021.05.17 20:58:34.328 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 16:30:00, EVENT='rl_av_h', VALUE=146.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 16:29:15 AND VALUE=147.9
2021.05.17 20:58:34.331 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 17:30:00, EVENT='rl_av_h', VALUE=145.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 17:09:15 AND VALUE=144.9
2021.05.17 20:58:34.335 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 19:30:00, EVENT='rl_av_h', VALUE=141.400 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 19:19:17 AND VALUE=139.9
2021.05.17 20:58:34.338 4: DbLog DBTest: UPDATE history SET TIMESTAMP=2021-04-28 22:30:00, EVENT='rl_av_h', VALUE=143.900 WHERE DEVICE=Jet AND READING=E10 AND TIMESTAMP=2021-04-28 22:24:19 AND VALUE=141.9
2021.05.17 20:58:34.347 3: DbLog DBTest: reduceLogNbl finished. Rows processed: 992, deleted: 938, updated: 269, time: 3.87sec
2021.05.17 20:58:34.348 5: DbLog DBTest -> DbLog_reduceLogNbl finished
-------------------------------------------------------------------------------------------------
Daten:
"2021-04-28 23:53:20";"Jet";"HTTPMOD";"E10: 145.9  Cent";"E10";"145.9";"Cent"  => unverändert ok

"2021-04-28 22:53:19";"Jet";"HTTPMOD";"E10: 145.9  Cent";"E10";"145.9";"Cent" => nicht gelöscht nok

"2021-04-28 22:24:19";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent" => Update Mittelwert ok
"2021-04-28 21:24:18";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent"  => unverändert ok
"2021-04-28 20:24:18";"Jet";"HTTPMOD";"E10: 141.9  Cent";"E10";"141.9";"Cent" => unverändert ok
"2021-04-28 19:28:17";"Jet";"HTTPMOD";"E10: 142.9  Cent";"E10";"142.9";"Cent" => gelöscht ok
"2021-04-28 19:19:17";"Jet";"HTTPMOD";"E10: 139.9  Cent";"E10";"139.9";"Cent" => Update Mittelwert ok
"2021-04-28 18:19:16";"Jet";"HTTPMOD";"E10: 139.9  Cent";"E10";"139.9";"Cent" => unverändert ok
"2021-04-28 17:29:15";"Jet";"HTTPMOD";"E10: 146.9  Cent";"E10";"146.9";"Cent" => gelöscht ok
"2021-04-28 17:09:15";"Jet";"HTTPMOD";"E10: 144.9  Cent";"E10";"144.9";"Cent" => Update Mittelwert ok
Final kein Tagesmittelwert gebildet; es ist wie bei Test#2 unsauber bei den stündlichen Werten am Ende
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 16 Juli 2021, 10:12:22
Guten Morgen Forum,

Erst einmal vielen Dank an Heiko für diesess tolle Modul.
Ich hab es nun schon einige Zeit im Einsatz und bin nun leider auf ein Problem gestossen, dass ich magels Kenntnisse wohl nicht allein lösen kann.

Ich habe mir mehrere AT's definiert, die z.b.  MIN/MAX/AVG berechnen sollen. Hier mal ein Beispiel:
defmod at.Energy.Tag.BZRadio at *00:11:00 attr DBReporting_LaCrosse device FBDECT_fbahahttp_08761_0060122;;\
attr DBReporting_LaCrosse reading power;;\
attr DBReporting_LaCrosse aggregation day;;\
attr DBReporting_LaCrosse timestamp_begin previous_day_begin;;\
attr DBReporting_LaCrosse timestamp_end previous_day_end;;\
set DBReporting_LaCrosse averageValue writeToDBSingle\

attr at.Energy.Tag.BZRadio DbLogExclude .*
attr at.Energy.Tag.BZRadio group Berechnung
attr at.Energy.Tag.BZRadio room System

setstate at.Energy.Tag.BZRadio Next: 00:11:00
setstate at.Energy.Tag.BZRadio 2021-07-16 00:11:00 state Next: 00:11:00


Wenn ich das mache, Erschein jetzt im Log:
2021.07.15 06:39:59 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 3
2021.07.15 06:39:59 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.x.x;port=xxx with user xxx
2021.07.15 06:39:59 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.15 06:39:59 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0056 seconds


Starte ich das zweite, erscheint dann im Log:
2021.07.15 06:41:00 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:750 will be killed now to start a new operation
2021.07.15 06:41:00 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 2
2021.07.15 06:41:00 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.x.x;port=xxx with user xxx
2021.07.15 06:41:00 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.15 06:41:00 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0140 seconds


warum wird der Prozess gekillt, obwohl er doch eigentlich nach 0.0056 s abgeschlossen war
Es werden leider auch keine Werte berechnen und in die DB eingetragen...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Juli 2021, 12:29:31
Zitat
warum wird der Prozess gekillt, obwohl er doch eigentlich nach 0.0056 s abgeschlossen war
Es werden leider auch keine Werte berechnen und in die DB eingetragen...
Es ist fraglich dass sich die Meldung "WARNING - running process DEAD:750 will be killed now to start a new operation" auf den vorangegangenen "get initial structure information" bezieht.

Ich vermute vielmehr du verwendest mehrere at um zeitgleich bzw. mit zu kurzen Zeitabständen ein und dasselbe DbRep-Device anzustarten um  MIN/MAX/AVG zu berechnen ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Juli 2021, 16:42:01
Zitat von: RalfRog am 29 Mai 2021, 12:38:26
Damit der Zusammenhang erhalten bleibt hier die Test#1 bis 3 am DBLog ....
Hi...
Ich häng mich hier nochmal mit der reduceLog(Nbl)-Problematik und dem/den  "Fehler/n" am Ende der ReduceLogPeriode rein.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Juli 2021, 16:53:30
Hallo Ralf,

ich habe deine Posts nicht vergessen.
Das kommt an die Reihe wenn ich mich mal wieder DbRep widme.
Zur Zeit will ich SolarForecast mal soweit abschliessen.
Zuviel Multitasking schädigt auf Dauer das Gedächtnis habe ich gerade in einem Buch von David Precht gelesen. 😉

Lg,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Juli 2021, 16:59:25
Ok
Ich halte es im Hinterkopf und checke hin und wieder die Nachrichten.
Zur Aufarbeitung kann ich dann soweit möglich zuarbeiten.

Ja verstehe ich Multitasking kann einen schon recht kirre machen  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 16 Juli 2021, 17:44:15
Zitat von: DS_Starter am 16 Juli 2021, 12:29:31
Ich vermute vielmehr du verwendest mehrere at um zeitgleich bzw. mit zu kurzen Zeitabständen ein und dasselbe DbRep-Device anzustarten um  MIN/MAX/AVG zu berechnen ?

Hallo Heiko,
das hatte ich auch vermutet. Jedoch hatte ich die beiden geposteten Aufrufe mit dem Logfile Eintrag händisch aufgerufen (morgens 6:41). Der nächste Aufruf ist dann aber erst am nächsten Tag um 0:01 Uhr usw.
2021.07.16 00:01:00 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:795 will be killed now to start a new operation
2021.07.16 00:01:00 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 1
2021.07.16 00:01:00 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.16 00:01:00 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.16 00:01:00 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0053 seconds
2021.07.16 00:02:00 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:23144 will be killed now to start a new operation
2021.07.16 00:02:00 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 0
2021.07.16 00:03:00 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:23144 will be killed now to start a new operation
2021.07.16 00:03:00 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 3
2021.07.16 00:03:00 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.16 00:03:00 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.16 00:03:00 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0051 seconds
2021.07.16 00:04:04 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:23179 will be killed now to start a new operation
2021.07.16 00:04:04 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 2
2021.07.16 00:04:04 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.16 00:04:04 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.16 00:04:04 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0043 seconds


auch wenn ich das DbRep jetzt nur einmalig ausführe, kommt besagte Fehlermeldung:
2021.07.16 17:37:19 3: DbRep DBReporting_LaCrosse - WARNING - running process  will be killed now to start a new operation
2021.07.16 17:37:19 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 3
2021.07.16 17:37:19 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.16 17:37:19 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.16 17:37:19 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0070 seconds
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Juli 2021, 18:38:32
Ich sehe jetzt dass deine Nebenprozesse wohl immer sterben, siehe

DEAD:23144

Stell doch mal versose 4 oder 5 in dem device an.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 07:40:42
Hier mal das Log mit Verbose 5

2021.07.17 07:36:06 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:53461 will be killed now to start a new operation
2021.07.17 07:36:06 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 3
2021.07.17 07:36:06 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.17 07:36:06 4: DbRep DBReporting_LaCrosse - database user for operation: xxx
2021.07.17 07:36:06 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.17 07:36:06 4: DbRep DBReporting_LaCrosse - all grants: SHOW VIEW,DROP,SELECT,EVENT,LOCK TABLES,CREATE VIEW,UPDATE,EXECUTE,ALTER ROUTINE,CREATE ROUTINE,CREATE,REFERENCES,INSERT,ALTER,DELETE,INDEX,USAGE,CREATE TEMPORARY TABLES,TRIGGER
2021.07.17 07:36:06 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0123 seconds

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 07:53:12
Und danach kommt nichts mehr ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 08:27:28
Also ein normaler Ablauf mit verbose 5 sieht so aus:


2021.07.17 08:17:15.187 4: DbRep Rep.CPU - database user for operation: fhemtest
2021.07.17 08:17:15.190 3: DbRep Rep.CPU - Index Report_Idx exists. Check ok
2021.07.17 08:17:15.192 4: DbRep Rep.CPU - all grants: DELETE,FILE,INDEX,INSERT,PROCESS,SELECT,UPDATE
2021.07.17 08:17:15.192 3: DbRep Rep.CPU - Initial data information retrieved successfully - total time used: 0.0075 seconds
2021.07.17 08:17:15.236 3: DbRep Rep.CPU - Connectiontest to db mysql:database=fhemtest;host=192.168.2.44;port=3306 successful
2021.07.17 08:17:15.248 4: DbRep Rep.CPU - -------- New selection ---------
2021.07.17 08:17:15.249 4: DbRep Rep.CPU - Command: countEntries history
2021.07.17 08:17:15.249 4: DbRep Rep.CPU - Timestamp begin human readable: not set
2021.07.17 08:17:15.250 4: DbRep Rep.CPU - Timestamp end human readable: not set
2021.07.17 08:17:15.250 4: DbRep Rep.CPU - Aggregation: no
2021.07.17 08:17:15.272 5: DbRep Rep.CPU - IsTimeSet: 0, IsAggrSet: 0
2021.07.17 08:17:15.274 5: DbRep Rep.CPU - Timestamp-Array:
....


Die initialen Daten werden nur beim ersten Start ermittelt. Wichtig ist dabei die Meldung "Connectiontest to db mysql:database=fhemtest;host=192.168.2.44;port=3306 successful".
Sie zeigt an dass der nebenläufige Prozess auch fertig geworden ist. Bei dir scheint das nicht der Fall zu sein. Das heißt der Nebenprozess kommt nicht zurück, was auch zu den DEAD Meldungen passt.
Fraglich ist wieso es bei dir so ist ... mal nach Linuxprozesse DEAD googeln...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 09:36:01
In meinem contrib liegt eine neue Version. Sie bringt am Anfang etwas mehr Infos welcher Prozess gestartet wird:

2021.07.17 09:27:09.747 3: DbRep Rep.Import - Connectiontest to database mysql:database=fhemtest;host=192.168.2.44;port=3306 with user fhemtest
2021.07.17 09:27:09.758 5: DbRep Rep.Import - start getInitData with PID "3599"
2021.07.17 09:27:09.808 4: DbRep Rep.Import - database user for operation: fhemtest
2021.07.17 09:27:09.811 3: DbRep Rep.Import - Index Report_Idx exists. Check ok
2021.07.17 09:27:09.813 4: DbRep Rep.Import - all grants: INSERT,PROCESS,SELECT,UPDATE,DELETE,FILE,INDEX
2021.07.17 09:27:09.814 3: DbRep Rep.Import - Initial data information retrieved successfully - total time used: 0.0086 seconds
2021.07.17 09:27:09.829 5: DbRep Rep.Import - getInitData finished PID "3599"
2021.07.17 09:27:09.875 3: DbRep Rep.Import - Connectiontest to db mysql:database=fhemtest;host=192.168.2.44;port=3306 successful
2021.07.17 09:27:09.888 4: DbRep Rep.Import - -------- New selection ---------
2021.07.17 09:27:09.889 4: DbRep Rep.Import - Command: countEntries history
....

Wenn der Prozess nicht beendet wird, kann man gezielt nach dieser PID im Linux suchen.
Ich checke die Version noch ein, aber kannst damit schonmal arbeiten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 10:48:18
Hallo Heiko,

hier mal das neue Log...
2021.07.17 10:40:32 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:1127 will be killed now to start a new operation
2021.07.17 10:40:32 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 3
2021.07.17 10:40:32 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.17 10:40:32 5: DbRep DBReporting_LaCrosse - start getInitData with PID "1153"
2021.07.17 10:40:32 4: DbRep DBReporting_LaCrosse - database user for operation: xxx
2021.07.17 10:40:32 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.17 10:40:32 4: DbRep DBReporting_LaCrosse - all grants: REFERENCES,CREATE,ALTER ROUTINE,EVENT,DROP,SELECT,LOCK TABLES,EXECUTE,DELETE,CREATE ROUTINE,INSERT,INDEX,SHOW VIEW,CREATE VIEW,USAGE,TRIGGER,CREATE TEMPORARY TABLES,UPDATE,ALTER
2021.07.17 10:40:32 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0042 seconds
2021.07.17 10:41:05 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:1153 will be killed now to start a new operation
2021.07.17 10:41:05 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 2
2021.07.17 10:41:05 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.17 10:41:05 5: DbRep DBReporting_LaCrosse - start getInitData with PID "1167"
2021.07.17 10:41:05 4: DbRep DBReporting_LaCrosse - database user for operation: xxx
2021.07.17 10:41:05 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.17 10:41:05 4: DbRep DBReporting_LaCrosse - all grants: REFERENCES,CREATE,EVENT,DROP,ALTER ROUTINE,SELECT,LOCK TABLES,EXECUTE,CREATE ROUTINE,DELETE,INSERT,INDEX,SHOW VIEW,CREATE VIEW,USAGE,CREATE TEMPORARY TABLES,TRIGGER,UPDATE,ALTER
2021.07.17 10:41:05 3: DbRep DBReporting_LaCrosse - Initial data information retrieved successfully - total time used: 0.0044 seconds


laut HTOP werden diese Prozesse (hier der PID 1153 und aktuell der PID 1167) jedoch sofort wieder beendet und werden trotzdem beim nächsten Start mit "...will be Killed..." angezeigt. Teilweise werden die so schnell aufgerufen und beendet, dass sie in HTOP gar nicht erst auftauchen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 11:45:28
Zitat
laut HTOP werden diese Prozesse (hier der PID 1153 und aktuell der PID 1167) jedoch sofort wieder beendet und werden trotzdem beim nächsten Start mit "...will be Killed..." angezeigt.
Ja, das ist normal in diesem Fall. Für FHEM/das Modul läuft der Prozess ja noch weil er sich bisher nicht zurück gemeldet hatte.

Die zentrale Frage ist wodurch diese Prozesse bei dir einfach sterben. Sie kommen ja nichtmal mit einem Fehler zurück der angezeigt werden würde.
Ich wette du findest im DbRep mit "get <> blockinginfo" einige DEAD Prozesse.
Du kannst im FHEMWEB in der Kommandozeile auch BlockingInfo ausführen.

Eine Vermutung die ich habe liegt im Umfeld von Telnet. Es muß ein verfügbares Device vom Type "telnet" bei dir geben.
Die oben angegebenen Kommandos sollten weiteren Aufschluß geben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 12:09:25
BlockingInfo liefert folgendes:

Pid:3012 Fn:PRESENCE_DoLocalPingScan Arg:Klaus_WLAN_Device_2|192.168.2.162|0|4 Timeout:60 ConnectedVia:telnetPort_127.0.0.1_56316
Pid:3014 Fn:PRESENCE_DoLocalPingScan Arg:Baerbel_WLAN_Device_2|192.168.2.168|0|4 Timeout:60 ConnectedVia:telnetPort_127.0.0.1_56322


aber ich stecke da echt nicht so tief drin, dass ich das in Verbindung bringen könnte ::)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 12:16:19
Was zeigt ein list TYPE=telnet ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 12:20:59
Zitat von: supergrobi am 17 Juli 2021, 12:09:25
BlockingInfo liefert folgendes:

Pid:3012 Fn:PRESENCE_DoLocalPingScan Arg:Klaus_WLAN_Device_2|192.168.2.162|0|4 Timeout:60 ConnectedVia:telnetPort_127.0.0.1_56316
Pid:3014 Fn:PRESENCE_DoLocalPingScan Arg:Baerbel_WLAN_Device_2|192.168.2.168|0|4 Timeout:60 ConnectedVia:telnetPort_127.0.0.1_56322


aber ich stecke da echt nicht so tief drin, dass ich das in Verbindung bringen könnte ::)

ich hab die beiden mal von LAN-Ping auf Abfrage der MAC umgestellt...

list Type=telnet zeigt:

Internals:
   CONNECTS   844
   DEF        7072 global
   FD         5
   FUUID      5e2be9c4-f33f-2f94-3190-22b543cce14dcacc
   NAME       telnetPort
   NR         4
   PORT       7072
   STATE      Initialized
   TYPE       telnet
   .attraggr:
   .attrminint:
   READINGS:
     2021-07-17 10:30:15   state           Initialized
Attributes:
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 12:33:24
Jetzt sehe ich leider die Attribute nicht, aber das telnet Device darf das Attr allowfrom nicht gesetzt haben oder aber muß "127.0.0.1" beinhalten.
Außerdem darf das Telnet Device nicht durch Paßwort geschützt sein.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 12:50:23
Ich glaube das Telnet hatte ich vor zig Jahren mal wegen der Fritzbox eingerichtet.
Die läuft ja nun auch schon seit vielen Jahren auf fbahahttp ... brauche ich dann das Telnet noch?
Die beiden WLAN Devices habe ich gerad noch auf die Mac Funktion umgestellt...

Edit: BlockingInfo liefert jetzt nix mehr
telnet hat kein Attribut, aber auch nix mit 127.0.0.1
jedoch hatten die WLAN Ping abfragen die 127.0.0.1 - jetzt jedoch nicht mehr.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 13:00:04
Kein Attribut ist auch ok, 127.0.0.1 wird dann als default verwendet. Alle Module die BlockingCall intern verwenden brauchen noch ein Telnet Device. Allerdings war ich der Meinung dass FHEM intern ein telnet Device für die Verwendung durch BlockingCall erzeugt.
Kann mich da aber auch täuschen.
Jedefalls darf das Telnet nicht durch Paßwort gesichert sein. Stichwort ist hier  allowed-Device.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 13:09:02
Wenn ich den Code richtig deute darf auch SSL im Telnet Device nicht gesetzt sein.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 13:13:48
hier mal die RAW Definition vom Telnet Device:

defmod telnetPort telnet 7072 global

setstate telnetPort 2021-07-17 10:30:15 state Initialized



ich würde behaupten da ist kein SSL und kein allowed definiert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 13:24:54
SSL stimmt. Aber ob telnet ein PW verlangt siehst du in deinem allowed Device sofern vorhanden. Dort würde dann im Attribut validFor dein telnet-Device mit drinstehen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 13:34:18
danke, ich glaube jetzt hab ichs kapiert :)

ein list TYPE=allowed gibt mir
allowed_WEB
allowed_WEBphone
allowed_WEBtablet

die drei devices, von denen ist bei keinem telnet(port) aktiviert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 13:42:55
Hmm, schade ... das war jetzt meine Hoffnung.  ;)

Ich habe inzwischen auch die Stelle gefunden wo ein temporäres telnet Device erzeugt werden würde wenn kein passendes vorhanden wäre. Also das war jetzt nicht der Punkt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 13:56:24
Was zeigt denn ein "get <> blockinginfo" im DbRep ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 14:00:12
leider auch nichts...
state   done - No BlockingCall processes running   2021-07-17 13:58:52
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 14:11:19
Wie ist denn dein global Attribut blockingCallMax gesetzt ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 14:18:44
blockingCallMax ist bei mir nicht gesetzt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 14:21:56
Wie groß ist dein RAM ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 14:23:41
3GB - es läuft auf eine Proxmox VM
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 14:44:32
Dann stell doch mal blockingCallMax testweise auf 6.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 17 Juli 2021, 15:51:11
leider keine Änderung auch keine aussagekräftigeren Logs
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Juli 2021, 17:12:25
Ich muß gestehen keine wirkliche Idee mehr zu haben.
Hast du noch mehr DbRep Devices laufen und ist das Problem erst seit einem bestimmten Datum oder Aktion aufgetreten ?

Ich habe verbose 5 Log nochmal erweitert in der Hoffnung etwas zu entdecken falls es am Rückgabewert in DbRep liegen sollte.
Version ist wieder im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2021, 11:05:38
Guten Morgen Heiko,

vielen Dank fur deine Mühe.

hier mal das neue log...
2021.07.18 11:02:23 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:27233 will be killed now to start a new operation
2021.07.18 11:02:23 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 2
2021.07.18 11:02:23 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.18 11:02:23 5: DbRep DBReporting_LaCrosse - start BlockingCall with PID "27244"
2021.07.18 11:02:23 4: DbRep DBReporting_LaCrosse - database user for operation: xxx
2021.07.18 11:02:23 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.18 11:02:23 4: DbRep DBReporting_LaCrosse - all grants: LOCK TABLES,UPDATE,SHOW VIEW,TRIGGER,EXECUTE,DROP,CREATE ROUTINE,INSERT,ALTER ROUTINE,REFERENCES,CREATE VIEW,EVENT,CREATE,ALTER,USAGE,SELECT,CREATE TEMPORARY TABLES,DELETE,INDEX
2021.07.18 11:02:23 5: DbRep DBReporting_LaCrosse - minimum timestamp found in database: 2017-07-14 21:30:00
2021.07.18 11:02:23 5: DbRep DBReporting_LaCrosse - return summary string: DBReporting_LaCrosse|MjAxNy0wNy0xNCAyMTozMDowMA==|0.002449,0.005128|0|minValue|writeToDB
|DbRep_Main|SW5kZXggUmVwb3J0X0lkeCBleGlzdHM=|TE9DSyBUQUJMRVMsVVBEQVRFLFNIT1cgVklFVyxUUklHR0VSLEVYRUNVVEUsRFJPUCxDUkVBVEUgUk9VVElORSxJTlNFUlQsQUxURVIgUk9VVElORSxSRUZFUkVOQ0VTLENSRUFURSBWSUVXLEVWRU5ULENSRUFURSxBTFRFUixVU0FHRSxTRUxFQ1QsQ1JFQVRFIFRFTVBPUkFSWSBUQUJMRVMsREVMRVRFLElOREVY
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2021, 12:09:29
Moin,

eine Frage zu dem Log. Bricht die Zeile im Original auch nach writeToDB um oder ist das nur bei der Anzeige im Forum so ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2021, 12:26:26
Zitat von: DS_Starter am 18 Juli 2021, 12:09:29
Moin,

eine Frage zu dem Log. Bricht die Zeile im Original auch nach writeToDB um oder ist das nur bei der Anzeige im Forum so ?

im Log ist das auch so
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2021, 12:29:07
Heiße Spur ... dann weiß ich wahrscheinlich um die Ursache. Werde später ein Testversion bereitstellen.
Gehe jetzt erstmal in die Sonne.  :D
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2021, 12:30:16
in der Definition ist da ne leere Zeile dahinter:
1 *00:01:00 attr DBReporting_LaCrosse device LaCrosse_3E;
2 attr DBReporting_LaCrosse reading temperature;
3 attr DBReporting_LaCrosse aggregation day;
4 attr DBReporting_LaCrosse timestamp_begin previous_day_begin;
5 attr DBReporting_LaCrosse timestamp_end previous_day_end;
6 set DBReporting_LaCrosse minValue writeToDB
7
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2021, 12:31:56
Zitat von: DS_Starter am 18 Juli 2021, 12:29:07
Heiße Spur ... dann weiß ich wahrscheinlich um die Ursache. Werde später ein Testversion bereitstellen.
Gehe jetzt erstmal in die Sonne.  :D

das macht Hoffnung :)
danke und viel Spaß, hier regnets.. :(
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2021, 12:34:21
Hast vlt. Ein Enter eingefügt ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2021, 12:46:52
Zitat von: DS_Starter am 18 Juli 2021, 12:34:21
Hast vlt. Ein Enter eingefügt ?

ja, da dachte ich mir nix bei :)
LogAusgabe neu, ohne ENTER:

2021.07.18 12:42:19 3: DbRep DBReporting_LaCrosse - WARNING - running process DEAD:27244 will be killed now to start a new operation
2021.07.18 12:42:19 3: DbRep DBReporting_LaCrosse - get initial structure information of database "fhem", remaining attempts: 1
2021.07.18 12:42:19 3: DbRep DBReporting_LaCrosse - Connectiontest to database mysql:database=fhem;host=192.168.xxx.xxx;port=xxx with user xxx
2021.07.18 12:42:19 5: DbRep DBReporting_LaCrosse - start BlockingCall with PID "29185"
2021.07.18 12:42:19 4: DbRep DBReporting_LaCrosse - database user for operation: xxx
2021.07.18 12:42:19 3: DbRep DBReporting_LaCrosse - Index Report_Idx exists. Check ok
2021.07.18 12:42:19 4: DbRep DBReporting_LaCrosse - all grants: INSERT,ALTER ROUTINE,LOCK TABLES,UPDATE,SHOW VIEW,TRIGGER,EXECUTE,CREATE ROUTINE,DROP,DELETE,CREATE TEMPORARY TABLES,INDEX,CREATE,EVENT,CREATE VIEW,REFERENCES,USAGE,ALTER,SELECT
2021.07.18 12:42:19 5: DbRep DBReporting_LaCrosse - minimum timestamp found in database: 2017-07-14 21:30:00
2021.07.18 12:42:19 5: DbRep DBReporting_LaCrosse - return summary string: DBReporting_LaCrosse|MjAxNy0wNy0xNCAyMTozMDowMA==|0.002151,0.005018|0|minValue|writeToDB|DbRep_Main|SW5kZXggUmVwb3J0X0lkeCBleGlzdHM=|SU5TRVJULEFMVEVSIFJPVVRJTkUsTE9DSyBUQUJMRVMsVVBEQVRFLFNIT1cgVklFVyxUUklHR0VSLEVYRUNVVEUsQ1JFQVRFIFJPVVRJTkUsRFJPUCxERUxFVEUsQ1JFQVRFIFRFTVBPUkFSWSBUQUJMRVMsSU5ERVgsQ1JFQVRFLEVWRU5ULENSRUFURSBWSUVXLFJFRkVSRU5DRVMsVVNBR0UsQUxURVIsU0VMRUNU
2021.07.18 12:42:20 3: DbRep DBReporting_LaCrosse - Initial data information retrieved - total time used: 0.0050 seconds
2021.07.18 12:42:20 3: DbRep DBReporting_LaCrosse - Connectiontest to db mysql:database=fhem;host=192.168.xxx.xxx;port=xxx successful
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - getInitData finished PID "29185"
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - -------- New selection ---------
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - Command: minValue writeToDB
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - FullDay option: 0
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Timestamp begin epocheseconds: 1626472800
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - Timestamp begin human readable: 2021-07-17 00:00:00
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Timestamp end epocheseconds: 1626559199
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - Timestamp end human readable: 2021-07-17 23:59:59
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - weekday start for selection: Sa  ->  wdadd: 172800
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Daylight savings changed: 0 (on Sun Jul 18 00:00:00 2021)
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - runtime_string: 2021-07-17, runtime_string_first: 2021-07-17 00:00:00, runtime_string_next: 2021-07-17 23:59:59
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - Aggregation: day
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - start BlockingCall with PID "29186"
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - IsTimeSet: 1, IsAggrSet: 1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Timestamp-Array:
2021-07-17#2021-07-17 00:00:00#2021-07-17 23:59:59
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Devices for operation -
included (1): LaCrosse_3E
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Readings for operation -
included (1): temperature
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.07.18 12:42:20 4: DbRep DBReporting_LaCrosse - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'LaCrosse_3E' ) AND ( READING = 'temperature' ) AND TIMESTAMP >= '2021-07-17 00:00:00' AND TIMESTAMP <= '2021-07-17 23:59:59' ORDER BY TIMESTAMP;
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse -> raw data of row_array result:
MjAyMS0wNy0xNw== 17.9 2021-07-17 00:00:03!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.8 2021-07-17 00:05:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.8 2021-07-17 00:10:07!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.8 2021-07-17 00:15:14!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 00:20:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.8 2021-07-17 00:25:17!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 00:30:19!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 00:35:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 00:40:27!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 00:45:29!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 00:50:30!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 00:55:32!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:00:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:05:36!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:10:42!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:15:53!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:20:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:26:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:31:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:36:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.5 2021-07-17 01:41:23!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:49:43!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 01:54:50!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 01:59:50!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 02:04:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 02:09:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 02:14:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 02:19:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 02:25:09!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 02:30:10!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 02:35:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 02:40:18!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 02:45:24!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 02:50:26!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 02:55:32!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 03:00:38!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 03:05:44!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 03:10:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:15:56!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:20:57!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:26:07!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:31:07!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:39:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:44:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:49:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 03:54:55!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:00:11!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:05:13!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:10:14!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:15:21!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:20:27!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:25:33!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:30:39!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:35:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:40:47!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:45:49!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:51:01!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 04:56:12!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:01:12!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:06:13!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:11:29!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:16:29!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:24:49!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:29:57!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:34:57!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:39:57!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:44:58!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:50:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 05:55:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:00:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:05:22!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:10:28!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:15:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:20:40!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:25:46!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:30:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:35:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:40:55!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 06:46:03!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 06:51:03!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 06:56:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:01:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:06:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:14:53!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:20:00!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:25:18!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:30:19!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:35:24!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:40:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:45:27!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:50:33!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 07:55:39!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:00:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:05:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:10:59!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:16:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:21:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:26:18!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:31:19!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:36:35!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:44:56!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:50:04!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 08:55:21!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:00:22!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:05:30!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:10:36!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:15:42!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:20:43!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:25:49!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 09:30:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:35:57!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:41:03!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:46:08!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 09:51:19!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.1 2021-07-17 09:56:20!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 10:00:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 10:05:31!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 10:10:35!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 10:15:47!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 10:20:47!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 10:25:50!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 10:30:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 10:35:55!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.2 2021-07-17 10:41:04!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 10:46:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.3 2021-07-17 10:51:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 10:56:31!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 11:01:32!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.5 2021-07-17 11:06:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.5 2021-07-17 11:11:35!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 11:16:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 11:21:59!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.4 2021-07-17 11:27:01!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.5 2021-07-17 11:32:03!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.5 2021-07-17 11:37:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 11:42:07!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 11:47:12!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.6 2021-07-17 11:52:14!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 11:57:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 12:02:18!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 12:07:24!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.7 2021-07-17 12:12:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.8 2021-07-17 12:17:27!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 12:22:29!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 12:27:31!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 12:32:40!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 12:37:43!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 12:42:49!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 12:47:50!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 12:52:56!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 12:58:02!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 13:03:04!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 13:08:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 13:13:08!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 13:18:09!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 13:23:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 13:28:21!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.2 2021-07-17 13:33:27!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 13:38:29!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 13:43:35!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 13:48:37!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 13:53:39!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 13:58:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:03:46!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:08:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.3 2021-07-17 14:13:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.3 2021-07-17 14:19:00!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.3 2021-07-17 14:24:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:29:08!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:34:14!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:39:28!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:44:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:49:35!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:54:38!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 14:59:44!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 15:04:50!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 15:09:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 15:14:53!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:19:59!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:25:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:30:11!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:35:17!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:40:19!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:45:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 15:50:31!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 15:55:37!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:00:43!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:05:45!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:10:47!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:15:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:20:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:26:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:31:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 16:36:08!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.6 2021-07-17 16:41:13!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:46:20!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.5 2021-07-17 16:51:43!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 16:57:00!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:02:08!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:07:10!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:12:12!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:17:13!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:22:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:27:21!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:32:23!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:37:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.4 2021-07-17 17:42:31!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.3 2021-07-17 17:47:32!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.3 2021-07-17 17:52:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.2 2021-07-17 17:57:36!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.2 2021-07-17 18:02:42!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.2 2021-07-17 18:07:48!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.2 2021-07-17 18:12:48!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:17:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:22:53!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:27:59!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:33:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:38:07!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:43:09!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:48:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 18:53:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 18:58:22!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:03:28!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:08:36!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:13:40!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:18:46!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:23:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:28:58!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:34:00!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18.1 2021-07-17 19:39:02!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:44:04!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:49:05!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:54:07!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 19:59:13!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:04:15!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:09:21!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:14:27!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:19:33!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:24:35!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:29:41!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:34:47!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:39:53!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:44:59!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:50:00!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 20:55:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:00:08!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:05:10!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:10:17!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:15:22!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:20:28!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:25:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:30:40!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:35:46!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:40:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:45:58!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:51:04!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 21:56:16!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:01:17!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:06:22!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:11:28!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:16:34!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:21:51!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:26:52!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:31:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:36:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:42:12!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:47:14!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:52:20!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 18 2021-07-17 22:57:26!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:02:28!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:07:30!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:12:36!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:17:42!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:22:48!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:27:54!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:33:00!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:38:06!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:43:12!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:48:13!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:53:19!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59 MjAyMS0wNy0xNw== 17.9 2021-07-17 23:58:25!_ESC_!2021-07-17 00:00:00|2021-07-17 23:59:59
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-00-03, VALUE: 17.9
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-05-06, VALUE: 17.8
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-10-07, VALUE: 17.8
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-15-14, VALUE: 17.8
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-20-16, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-25-17, VALUE: 17.8
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-30-19, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-35-25, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-40-27, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-45-29, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-50-30, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_00-55-32, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-00-34, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-05-36, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-10-42, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-15-53, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-20-54, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-26-05, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-31-05, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-36-06, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-41-23, VALUE: 17.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-49-43, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-54-50, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_01-59-50, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-04-51, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-09-51, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-14-51, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-19-51, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-25-09, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-30-10, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-35-16, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-40-18, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-45-24, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-50-26, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_02-55-32, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-00-38, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-05-44, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-10-52, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-15-56, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-20-57, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-26-07, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-31-07, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-39-45, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-44-45, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-49-52, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_03-54-55, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-00-11, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-05-13, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-10-14, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-15-21, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-20-27, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-25-33, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-30-39, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-35-45, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-40-47, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-45-49, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-51-01, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_04-56-12, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-01-12, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-06-13, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-11-29, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-16-29, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-24-49, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-29-57, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-34-57, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-39-57, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-44-58, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-50-15, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_05-55-15, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-00-16, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-05-22, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-10-28, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-15-34, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-20-40, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-25-46, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-30-52, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-35-54, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-40-55, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-46-03, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-51-03, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_06-56-05, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-01-15, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-06-15, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-14-53, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-20-00, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-25-18, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-30-19, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-35-24, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-40-25, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-45-27, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-50-33, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_07-55-39, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-00-45, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-05-51, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-10-59, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-16-05, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-21-15, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-26-18, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-31-19, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-36-35, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-44-56, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-50-04, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_08-55-21, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-00-22, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-05-30, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-10-36, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-15-42, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-20-43, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-25-49, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-30-51, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-35-57, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-41-03, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-46-08, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-51-19, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_09-56-20, VALUE: 17.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-00-25, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-05-31, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-10-35, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-15-47, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-20-47, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-25-50, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-30-45, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-35-55, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-41-04, VALUE: 17.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-46-05, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-51-15, VALUE: 17.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_10-56-31, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-01-32, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-06-34, VALUE: 17.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-11-35, VALUE: 17.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-16-52, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-21-59, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-27-01, VALUE: 17.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-32-03, VALUE: 17.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-37-05, VALUE: 17.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-42-07, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-47-12, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-52-14, VALUE: 17.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_11-57-16, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-02-18, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-07-24, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-12-25, VALUE: 17.7
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-17-27, VALUE: 17.8
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-22-29, VALUE: 17.9
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-27-31, VALUE: 17.9
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-32-40, VALUE: 17.9
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-37-43, VALUE: 17.9
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-42-49, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-47-50, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-52-56, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_12-58-02, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-03-04, VALUE: 17.9
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-08-06, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-13-08, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-18-09, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-23-16, VALUE: 18
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-28-21, VALUE: 18.1
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-33-27, VALUE: 18.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-38-29, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-43-35, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-48-37, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-53-39, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_13-58-45, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-03-46, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-08-52, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-13-54, VALUE: 18.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-19-00, VALUE: 18.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-24-06, VALUE: 18.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-29-08, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-34-14, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-39-28, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-44-34, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-49-35, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-54-38, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_14-59-44, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-04-50, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-09-52, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-14-53, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-19-59, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-25-05, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-30-11, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-35-17, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-40-19, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-45-25, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-50-31, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_15-55-37, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-00-43, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-05-45, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-10-47, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-15-54, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-20-54, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-26-05, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-31-06, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-36-08, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-41-13, VALUE: 18.6
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-46-20, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-51-43, VALUE: 18.5
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_16-57-00, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-02-08, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-07-10, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-12-12, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-17-13, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-22-15, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-27-21, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-32-23, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-37-25, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-42-31, VALUE: 18.4
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-47-32, VALUE: 18.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-52-34, VALUE: 18.3
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_17-57-36, VALUE: 18.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_18-02-42, VALUE: 18.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_18-07-48, VALUE: 18.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, READING: temperature, TIMESTAMP: 2021-07-17_18-12-48, VALUE: 18.2
2021.07.18 12:42:20 5: DbRep DBReporting_LaCrosse - Runtimestring: 2021-07-17, DEVICE: LaCrosse_3E, R
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2021, 12:51:42
Läuft.  :) Aber das muss ich abfangen, kann ja immer wieder passieren. Später ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 18 Juli 2021, 13:07:51
Vielen Dank für die Hilfe!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Juli 2021, 16:18:36
So, jetzt sollte auch ein Carriage Return an der Stelle nichts mehr tun und das Modul resistent dagegen sein.
Kannst du ja nochmal aus meinem contrib testen wenn du magst.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: supergrobi am 20 Juli 2021, 06:45:32
Ich hab die AT's alle angepassst und die Leerzeile entfernt.
Werde das aber demnächst mla ausprobieren, vielen Dank!

Gruß
Thomas
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: tom2966 am 05 September 2021, 21:38:46
Einen schönen guten Abend,

ich habe im Bereich "Sonstiges" eine Frage zum diesem Modul gestellt- "Sonstiges" weil dort ein ähnliches Thema schon mal ne Rolle gespielt hat. Ich würde den Link dazu gern auch hier noch mal einstellen. Vielleicht kann mir jemand helfen.

https://forum.fhem.de/index.php/topic,122791.0.html (https://forum.fhem.de/index.php/topic,122791.0.html)

Danke und viele Grüße

Tom
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Muenzi am 06 September 2021, 23:33:08
Hi, möglicherweise hätte ich länger suchen sollen, daher sorry wenn das Thema schon einmal beantwortet wurde.

Im letzten Jahr füllten sich meine LogDb und DbRep Instanzen recht stark mit Klima-Daten, die ich in recht hoher Auflösung an verschiedenen Stellen aufnahm. Die DB wuchs schnell auf einige Gigabyte an und wurde zunehmend langsam im Zusammenspiel mit Charts in FHEM.

Daher hatte ich überlegt ob man nicht zum Beispiel mit LogDb oder DbRep Partition Pruning nutzen könne um Queries gegen Zeitreihen performant zu halten. Wird sowas bereits intern genutzt oder wäre das hier unsinnig? Was sind eure Erfahrungen?

Außerdem vermisse ich eine Möglichkeit zur Normalisierung der DB-Tabellen, zum Beispiel per Star-Schema (der Performance wegen) um Speicher zu sparen. Gleiche Frage, gibt es da schon Lösungen oder ist das für den normalen FHEM-User overengineered?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 September 2021, 09:41:29
Hallo Muenzi,

grundsätzlich ist es so, dass das Standard Datenmodell sehr einfach ist und nur aus einer Tabelle besteht (history).
Dieses Modell besteht m.M. nach seit über 10 Jahren und müßte tatsächlich mal überarbeitet werden.

Es gibt dazu auch schon Ansätze:
https://forum.fhem.de/index.php/topic,111567.0.html

(Da kannst du gern etwas dazu schreiben)

Um den Bestand nicht zu gefährden, sollte es aber eine vollkommen neue Implementierung mit einem neuen DbLog-Modul geben, welches auf einer neuen DB Struktur arbeitet. Man muß natürlich dabei sicherstellen, dass alle DB Typen (MariaDB, SQLite, PostgreSQL) unterstützt werden.

Eigentlich hatte ich mir es mal vorgenommen, aber ich glaube nicht dass ich dazu noch kommen werde, andere Dinge sind meist wichtiger und meine Zeit mit den laufenden Projekten sowie Support aufgebraucht.  ;)

Allerdings könnte man mit MariaDB m.M. nach die Partitionierung durchaus mit den bestehenden Modulen nutzen. Wenn ich es richtig überblicke würde es keine SQL Anpassungen notwendig werden lassen.
Das kannst du bei mir ja mal ausprobieren.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 07 September 2021, 09:54:47
Hallo zusammen,

ich denke für die Zwischenzeit wäre eine Auslagerung in eine Archiv Datenbank mit all den aktuellen Funktionalitäten sicher ein gangbarer Weg.
Auch das Ausdünnen der Daten ist immer wieder, gleich auch zu Anfang, ein wichtiger Punkt.
Bei den historischen Wetter- oder auch z.B. PV Daten ist es nach ein bis zwei Jahren sicherlich nicht mehr wichtig alles im Minuten Takt zu haben.

VG
   Christian

Hier mal meine DB Größe mit 2 Jahren PV Daten im Minuten Takt.
Das läuft auf einem RPI4 mit SSD im Docker Container. Die Auswertung erfolgt im Grafana auch im Docker.
Das PV Dashboard aktualisiert sich auch jede Minute. Hierbei war es jedoch wichtig nicht jedes SQL SELECT einzeln abzurufen, sondern lieber mit einem langen
SQL Statement mit vielen JOIN alle Daten innerhalb der Datenbank aufzubereiten.

MySQL [fhem]> SELECT table_schema "DB Name",
    ->        Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
    ->   FROM  information_schema.tables
    ->   GROUP BY table_schema;
+--------------------+---------------+
| DB Name            | DB Size in MB |
+--------------------+---------------+
| fhem               |        4385.0 |
| information_schema |           0.0 |
+--------------------+---------------+
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Muenzi am 07 September 2021, 15:55:59
Sehr coole Übersicht ch.eick.

Und klar, da hast du Recht - ausdünnen der Daten ist sicher sinnvoller als Daten-Messi spielen. Habe mir bisher auch mit einer Archiv-Datenbank beholfen, ist nur etwas mehr Aufwand. Daher war auch die Frage ob solche Ansätze eventuell overengineered sind. Ich bin selbst Data Engineer mit Datentöpfen jenseits der 50 GB und max. Zugriffszeiten im Bereich < 10 Sekunden) und habe so vielleicht einen etwas zu ambitionierten Blick auf das Thema.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Muenzi am 07 September 2021, 15:59:59
Danke für den Link DS_Starter. Ich schau mal rein und vielleicht kann ich beitragen.

Bin selbst aber eher wenig in SQL und Co unterwegs - dafür der Performance wegen mehr in Delta Tables. Aber let's see.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 September 2021, 17:13:07
Hallo Heiko,
ich hatte ja schon länger kein SQL mehr gebaut :-)

Das SELECT holt die Jahres Statistiken vom Vorjahr, allerdings musste ich beim reading etwas filtern, was ich gerne noch "sauberer" hätte.

###################################################
## Jahres Statistik vom Wechselrichter für das Finanzamt Formular
##
SELECT * FROM
  (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE
    FROM history
    WHERE DEVICE = 'WR_1_API'
       AND READING          LIKE 'Statistic_%Year'
       AND READING NOT LIKE '%Autarky%'
       AND READING NOT LIKE '%Rate%'
       AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d')
       AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE())  ,'-01-01'),'%Y-%m-%d')
    ORDER BY TIMESTAMP DESC
  ) AS x1 GROUP BY x1.READING ;
+---------------------+---------------------------------+-------+
| TIMESTAMP           | READING                         | VALUE |
+---------------------+---------------------------------+-------+
| 2020-12-31 14:57:03 | Statistic_EnergyFeedInGrid_Year |  5200 |
| 2020-12-31 14:57:03 | Statistic_EnergyHomeBat_Year    |  1435 |
| 2020-12-31 14:57:03 | Statistic_EnergyHomeGrid_Year   |  2386 |
| 2020-12-31 14:57:03 | Statistic_EnergyHomePvSum_Year  |  4765 |
| 2020-12-31 14:57:03 | Statistic_EnergyHomePv_Year     |  3330 |
| 2020-12-31 14:57:03 | Statistic_EnergyHome_Year       |  7149 |
| 2020-12-31 14:57:03 | Statistic_TotalConsumption_Year |  7152 |
| 2020-12-31 14:57:03 | Statistic_Yield_NoBat_Year      |  8530 |
| 2020-12-31 14:57:03 | Statistic_Yield_Year            |  9965 |
+---------------------+---------------------------------+-------+


Die readings sehen dann jetzt so aus.
Den TIMESTAMP kann man ja noch weg lassen.

SqlResultRow_1 TIMESTAMP|READING|VALUE
SqlResultRow_2  2020-12-31 14:57:03|Statistic_EnergyFeedInGrid_Year|5200
SqlResultRow_3  2020-12-31 14:57:03|Statistic_EnergyHomeBat_Year|1435
SqlResultRow_4  2020-12-31 14:57:03|Statistic_EnergyHomeGrid_Year|2386
SqlResultRow_5  2020-12-31 14:57:03|Statistic_EnergyHomePvSum_Year|4765
SqlResultRow_6  2020-12-31 14:57:03|Statistic_EnergyHomePv_Year|3330
SqlResultRow_7  2020-12-31 14:57:03|Statistic_EnergyHome_Year|7149
SqlResultRow_8  2020-12-31 14:57:03|Statistic_TotalConsumption_Year|7152
SqlResultRow_9  2020-12-31 14:57:03|Statistic_Yield_NoBat_Year|8530
SqlResultRow_10 2020-12-31 14:57:03|Statistic_Yield_Year|9965


1) Ich glaube ich hatte auch schon mal gefragt, ob man bei zweispaltigem Output nicht direkt die erste Spalte als reading Namen und die Zweite als Wert im Device setzen kann.
2) Hättest Du eventuell Code, mit dem ich das hin bekomme?

3) Kann ich aus dem sqlCmd direkt auf die interne Variablen Steuerung verweisen?
   Als die Attribute, die man für Zeitsteuerung oder sogar "device" und "reading" zugreifen?

Wenn es eine andere Lösung gibt, wäre ich natürlich auch interessiert.

VG
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 September 2021, 17:34:17
Hallo Christian,

ZitatIch glaube ich hatte auch schon mal gefragt, ob man bei zweispaltigem Output nicht direkt die erste Spalte als reading Namen und die Zweite als Wert im Device setzen kann.
Das habe ich nicht vorgesehen. Grund ist vor allem dass mann mit SQL allerhand "Spielchen" treiben kann, so zum Beispiel im Ergebnis das Reading umbennenn. Dadurch wäre es nicht mehr FHEM konform und würde wieder eine Fehlerbehandlung nach sich ziehen. Denk du weißt was ich meine.

Zitat
Hättest Du eventuell Code, mit dem ich das hin bekomme?
Du könnest mit dem Attr userExitFn die Ergebnisse in eine eigene Funktion umleiten, aufspalten und eigene Readings im DbRep Device oder Dummy etc. setzen wie du es willst. Beispiel für userExitFn habe ich m.W. im Wiki.

ZitatKann ich aus dem sqlCmd direkt auf die interne Variablen Steuerung verweisen?
Auf die Zeitsteuerung ja (steht in ComRef).
Auf reading/device nicht weil die Attribute zB. auch so gesetzt werden können:


attr <name> reading eto%,Einspeisung EXCLUDE=etoday
attr <name> reading etotal,etoday,Ein% EXCLUDE=%Wirkleistung
attr <name> device TYPE=SSCam EXCLUDE=SDS1_SVS
attr <name> device TYPE=SSCam,TYPE=ESPEasy EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=TYPE=SSCam


Um diese Methoden in ein beliebig aussehendes SQL zu übernehmen muß man wieder viel prüfen bzw. einschränken.
Oder einfach den User auf Fehler laufen lassen, dann könnte man es einfach zulassen.  ;)

Grüße,
Heiko

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 September 2021, 17:39:42
Zitat von: DS_Starter am 22 September 2021, 17:34:17
Du könnest mit dem Attr userExitFn die Ergebnisse in eine eigene Funktion umleiten, aufspalten und eigene Readings im DbRep Device oder Dummy etc. setzen wie du es willst. Beispiel für userExitFn habe ich m.W. im Wiki.
Auf die Zeitsteuerung ja (steht in ComRef).
Auf reading/device nicht weil die Attribute zB. auch so gesetzt werden können:


attr <name> reading eto%,Einspeisung EXCLUDE=etoday
attr <name> reading etotal,etoday,Ein% EXCLUDE=%Wirkleistung
attr <name> device TYPE=SSCam EXCLUDE=SDS1_SVS
attr <name> device TYPE=SSCam,TYPE=ESPEasy EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=SDS1_SVS
attr <name> device EXCLUDE=TYPE=SSCam


Um diese Methoden in ein beliebig aussehendes SQL zu übernehmen muß man wieder viel prüfen bzw. einschränken.
Oder einfach den User auf Fehler laufen lassen, dann könnte man es einfach zulassen.  ;)
Das mit reading und device hatte ich gesehen und gehofft dort einfach meine Filter rein zu bekommen.

Die userExitFn wollte ich vermeiden, Du weißt ja, dass ich gerne die Möglichkeiten der Module bis zum Bersten ausschöpfe, damit ich nicht soviele Funktionen schreiben muss ;-) und mehr Unterstützung in Anspruch nehmen kann.

VG
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 September 2021, 17:46:51
Naja wie gesagt, ich könnte einfach reading bzw. device als Platzhalter im SQL vorsehen und blind 1:1 übernehmen was im Attr steht. Wenn der User das Attr nicht passend zu seinen SQL definiert läuft das Ding eben auf Error.
Eigentlich auch nicht sooo schlimm wenn ich darüber nachdenke.

Könnte ich eigentlich recht schnell einbauen mal so leichtsinnig dahin gesagt  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 22 September 2021, 17:57:25
Zitat von: DS_Starter am 22 September 2021, 17:46:51
Naja wie gesagt, ich könnte einfach reading bzw. device als Platzhalter im SQL vorsehen und blind 1:1 übernehmen was im Attr steht. Wenn der User das Attr nicht passend zu seinen SQL definiert läuft das Ding eben auf Error.
Eigentlich auch nicht sooo schlimm wenn ich darüber nachdenke.

Könnte ich eigentlich recht schnell einbauen mal so leichtsinnig dahin gesagt  ;)
Man sollte als user ja auch sein SQL durchaus mal testen. Ich bekomme ja auch so SQL Fehler, wenn ich im sqlCmd was falsches rein schreibe.
Ich finde, das würde es etwas lesbarer machen, wenn man variable Teile so auslagern kann. Geh mal in Dich und wäge es ab.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 September 2021, 20:58:02
Ich habe eine Testversion in mein contrib gestellt.
Wenn im sqlCmd die Platzhalter §device§ bzw. §reading§ vorhanden sind, werden an dieser Stelle die Attributwerte von device, reading eingesetzt.
Probiers mal aus.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 23 September 2021, 08:00:02
Zitat von: DS_Starter am 22 September 2021, 20:58:02
Ich habe eine Testversion in mein contrib gestellt.
Wenn im sqlCmd die Platzhalter §device§ bzw. §reading§ vorhanden sind, werden an dieser Stelle die Attributwerte von device, reading eingesetzt.
Moin Heiko,
ich habe es ausprobiert und es hat bei der ersten Ausführung funktioniert.

Danach wurde jedoch im sqlCmd das zuletzt ausgeführte SQL angezeigt, also das mit der Ersetzung und das Original mit den Variablen wurde überschrieben.
Damit würde jedoch beim nächsten Aufruf ein geändertes §reading§ nicht wieder ersetzt werden.

Hier das List nach der Ausführung und die original Zeile vorher:

SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=§device§ AND §reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING ;


Internals:
   CFGFN     
   DATABASE   fhem
   DEF        LogDB
   FUUID      614b0a08-f33f-61a8-f1e8-10ef59dfe90ba545
   FVERSION   93_DbRep.pm:v8.42.9-s24929/2021-09-06
   LASTCMD    sqlCmd SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE='WR_1_API' AND READING LIKE 'Statistic_%Year' AND READING NOT LIKE '%Autarky%' AND READING NOT LIKE '%Rate%' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING ;
   MODEL      Client
   NAME       LogDBRep_Statistic_previous_Year
   NOTIFYDEV  global,LogDBRep_Statistic_previous_Year
   NR         77178
   NTFY_ORDER 50-LogDBRep_Statistic_previous_Year
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     USAGE,ALL PRIVILEGES
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST   
     VERSION    8.42.9
     CV:
       aggregation no
       aggsec     1
       destr      2020-12-31
       dsstr      2019-04-03
       epoch_seconds_end 1609455599
       mestr      12
       msstr      04
       testr      23:59:59
       tsstr      00:23:42
       wdadd      432000
       yestr      2020
       ysstr      2019
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1632307720.54312
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2021-09-23 07:49:23   SqlResultRow_1  TIMESTAMP|READING|VALUE
     2021-09-23 07:49:23   SqlResultRow_10 2020-12-31 14:57:03|Statistic_Yield_Year|9965
     2021-09-23 07:49:23   SqlResultRow_2  2020-12-31 14:57:03|Statistic_EnergyFeedInGrid_Year|5200
     2021-09-23 07:49:23   SqlResultRow_3  2020-12-31 14:57:03|Statistic_EnergyHomeBat_Year|1435
     2021-09-23 07:49:23   SqlResultRow_4  2020-12-31 14:57:03|Statistic_EnergyHomeGrid_Year|2386
     2021-09-23 07:49:23   SqlResultRow_5  2020-12-31 14:57:03|Statistic_EnergyHomePvSum_Year|4765
     2021-09-23 07:49:23   SqlResultRow_6  2020-12-31 14:57:03|Statistic_EnergyHomePv_Year|3330
     2021-09-23 07:49:23   SqlResultRow_7  2020-12-31 14:57:03|Statistic_EnergyHome_Year|7149
     2021-09-23 07:49:23   SqlResultRow_8  2020-12-31 14:57:03|Statistic_TotalConsumption_Year|7152
     2021-09-23 07:49:23   SqlResultRow_9  2020-12-31 14:57:03|Statistic_Yield_NoBat_Year|8530
     2021-09-23 07:49:23   sqlCmd          SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE='WR_1_API' AND READING LIKE 'Statistic_%Year' AND READING NOT LIKE '%Autarky%' AND READING NOT LIKE '%Rate%' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING ;
     2021-09-23 07:49:23   sqlResultNumRows 9
     2021-09-23 07:49:23   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 0
   comment    Version 2021.09.23 07:48
   device     WR_1_API
   reading    Statistic_%Year  EXCLUDE=%Autarky%,%Rate%
   room       Strom->Energie,System
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 September 2021, 08:09:14
Moin,

Works as designed.
Die variablen werden natürlich ersetzt. Das sqlCmd muss man einfach neu reinkopieren. Bei Skripten ist das eh kein Problem.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 23 September 2021, 09:05:24
Zitat von: DS_Starter am 23 September 2021, 08:09:14
Die variablen werden natürlich ersetzt. Das sqlCmd muss man einfach neu reinkopieren. Bei Skripten ist das eh kein Problem.
Okay, dann kommt das mit in mein Scheduling Device :-)

Vielen Dank für die schnelle Unterstützung
      Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 23 September 2021, 14:57:13
Hallo Heiko,
sorry für meine verwirrte Rückmeldung.

Jetzt geht es mit dem §device§ und §reading§ irgendwie nicht mehr.

Ich hatte bei meinem Test etwas durcheinander mit dem reload.

Getestet hatte ich FVERSION   93_DbRep.pm:v8.42.9-s24929/2021-09-06 und da ging es soweit.
Jetzt habe ich allerdings FVERSION 93_DbRep.pm:v8.43.0-s24929/2021-09-06 und da geht es wieder nicht :-(

Leider hatte ich zwei Sachen gleichzeitig gemacht und das mit den readings und userExitFn getestet.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 23 September 2021, 17:54:33
Hallo Christian,

Bin zur zeit unterwegs und schaue mir am we nochmal an.

Grüsse,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 September 2021, 23:09:57
Hallo Christian,

hast im Statement den gekennzeichneten Teil vergessen:

SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=§device§ AND READING=§reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING;

Damit läuft es es.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 September 2021, 10:37:51
Zitat von: DS_Starter am 24 September 2021, 23:09:57
Hallo Christian,

hast im Statement den gekennzeichneten Teil vergessen:

SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=§device§ AND READING=§reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING;

Damit läuft es.
Leider nein


Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      614b0a08-f33f-61a8-f1e8-10ef59dfe90ba545
   FVERSION   93_DbRep.pm:v8.43.0-s24929/2021-09-06
   LASTCMD    sqlCmd SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=§device§ AND READING=§reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING
   MODEL      Client
   NAME       LogDBRep_Statistic_previous_Year
   NOTIFYDEV  global,LogDBRep_Statistic_previous_Year
   NR         541
   NTFY_ORDER 50-LogDBRep_Statistic_previous_Year
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     USAGE,ALL PRIVILEGES
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST   
     UEFN_REGEXP .*:.*
     USEREXITFN splitReading
     VERSION    8.43.0
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2021-09-25 10:33:55   SqlResultRow_1  TIMESTAMP|READING|VALUE
     2021-09-25 10:33:55   sqlCmd          SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=§device§ AND READING=§reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING
     2021-09-25 10:33:55   sqlResultNumRows 0
     2021-09-25 10:33:55   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 0
   comment    Version 2021.09.23 15:00
   device     WR_1_API
   reading    Statistic_%Year  EXCLUDE=%Autarky%,%Rate%
   room       System
   userExitFn splitReading .*:.*
   verbose    3
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 September 2021, 10:43:34
Doch:


2021.09.25 10:42:32.913 4: DbRep Rep.LogDB - -------- New selection ---------
2021.09.25 10:42:32.914 4: DbRep Rep.LogDB - Command: sqlCmd SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=§device§ AND READING=§reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING;
2021.09.25 10:42:32.917 4: DbRep Rep.LogDB - FullDay option: 0
2021.09.25 10:42:32.917 4: DbRep Rep.LogDB - Timestamp begin human readable: 2021-01-01 00:00:00
2021.09.25 10:42:32.918 4: DbRep Rep.LogDB - Timestamp end human readable: 2021-09-24 23:59:59
2021.09.25 10:42:32.935 4: DbRep Rep.LogDB - adminCredentials successfully read from file
2021.09.25 10:42:32.939 4: DbRep Rep.LogDB - database user for operation: root
2021.09.25 10:42:32.940 4: DbRep Rep.LogDB - SQL execute: SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE='MyWetter' AND READING='temperature' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING;
2021.09.25 10:42:32.979 4: DbRep Rep.LogDB - SQL result: 2020-12-31 00:02:59 temperature 0


Naja, dein Attribut reading passt natürlich nicht, wird ja 1:1 übernommen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 September 2021, 10:50:53
Hmm, ????

2021.09.25 10:45:15.062 4: DbRep LogDBRep_Statistic_previous_Year - -------- New selection ---------
2021.09.25 10:45:15.062 4: DbRep LogDBRep_Statistic_previous_Year - Command: sqlCmd SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE=\u00a7device\u00a7 AND READING=\u00a7reading\u00a7 AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING
2021.09.25 10:45:15.062 4: DbRep LogDBRep_Statistic_previous_Year - Timestamp begin human readable: not set
2021.09.25 10:45:15.062 4: DbRep LogDBRep_Statistic_previous_Year - Timestamp end human readable: not set
2021.09.25 10:45:15.085 5: DbRep LogDBRep_Statistic_previous_Year - start BlockingCall with PID "17956"
2021.09.25 10:45:15.140 4: DbRep LogDBRep_Statistic_previous_Year - database user for operation: fhemuser
2021.09.25 10:45:15.141 4: DbRep LogDBRep_Statistic_previous_Year - SQL execute: SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE DEVICE='WR_1_API' AND READING='Statistic_%Year  EXCLUDE=%Autarky%,%Rate%' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING;
2021.09.25 10:45:15.164 5: DbRep LogDBRep_Statistic_previous_Year - BlockingCall finished PID "17956"
2021.09.25 10:45:15.164 5: DbRep LogDBRep_Statistic_previous_Year - SQL result decoded: TIMESTAMP|READING|VALUE


Bei meinem ersten Test wurde aber der SQL Syntax vom §reading§ auch noch korrekt aufgelöst, was jetzt nicht mehr der Fall ist und somit natürlich nichts aus der Tabelle ausgewählt wird.

EDIT:
Da lief es bereits richtig (https://forum.fhem.de/index.php/topic,53584.msg1176065.html#msg1176065)
...WHERE DEVICE=§device§ AND §reading§ AND...

...WHERE DEVICE='WR_1_API' AND READING LIKE 'Statistic_%Year' AND READING NOT LIKE '%Autarky%' AND READING NOT LIKE '%Rate%' AND...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 September 2021, 11:22:23
Dein reading-Attr:


Statistic_%Year  EXCLUDE=%Autarky%,%Rate%


kann in dem Kontext nicht klappen weil reading mit §reading§ im sqlCmd 1:1 übernommen wird.

In festgelegten sql Commands löse ich EXCLUDE= im Modul entsprechend auf um die SQL zu gestalten. Aber in der freien sqlCmd geht das nicht. Hier hat der user die Gewalt über das was er ausführen möchte und muß die SQL entsprechend bauen.
Die Platzhalter können hier nur eine kleine Hilfe zur Verallgemeinerung sein.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 September 2021, 11:27:00
Zitat von: DS_Starter am 25 September 2021, 11:22:23
Dein reading-Attr:


Statistic_%Year  EXCLUDE=%Autarky%,%Rate%


kann in dem Kontext nicht klappen weil reading mit §reading§ im sqlCmd 1:1 übernommen wird.

In festgelegten sql Commands löse ich EXCLUDE= im Modul entsprechend auf um die SQL zu gestalten. Aber in der freien sqlCmd geht das nicht. Hier hat der user die Gewalt über das was er ausführen möchte und muß die SQL entsprechend bauen.
Die Platzhalter können hier nur eine kleine Hilfe zur Verallgemeinerung sein.
Was mich jedoch wundert ist, dass es bereits in FVERSION   93_DbRep.pm:v8.42.9-s24929/2021-09-06 funktioniert hat.
Ansonsten hatte ich dann noch eine Meldung zur Feldlänge von §reading§ , die wohl auf 64 Zeichen begrenzt ist.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 September 2021, 12:07:47
ZitatWas mich jedoch wundert ist, dass es bereits in FVERSION   93_DbRep.pm:v8.42.9-s24929/2021-09-06 funktioniert hat.
Schwer vorstellbar weil es bei der V noch keine Platzhalter/Ersetzungen von §device§, §reading§ gab.
Who knows ... Magie ....  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 September 2021, 13:31:58
Zitat von: DS_Starter am 25 September 2021, 12:07:47
Schwer vorstellbar weil es bei der V noch keine Platzhalter/Ersetzungen von §device§, §reading§ gab.
Who knows ... Magie ....  ;)
Sehr merkwürdig, da ich das list Device ja geposted hatte.

Da §reading§ von der Länge limitiert ist kann ich es dann so leider nicht verwenden. Ich wollte es natürlich dem Syntax vom Attribut reading angepasst nutzen.
Es ja dann auch ohne, also mit voll ausgeschriebenem SQL SELECT.

Ich habe mal in den Code geschaut, wäre es denkbar die Funktion DbRep_createCommonSql() zu verwenden, om den §reading§ Syntax zu übertragen?
Leider kann ich noch nicht genug Perl :-(

EDIT: Ich habe mal Jugend forscht gemacht und die Funktion DbRep_createCommonSql() aufgerufen.
Leider bin ich mit dem $selspec nicht so klar gekommen ;-)

  # Allow inplace replacement of keywords for timings (use time attribute syntax), device, reading
  $sql =~ s/§timestamp_begin§/'$runtime_string_first'/g;
  $sql =~ s/§timestamp_end§/'$runtime_string_next'/g;

## ch.eick patch ########################################
#  $sql =~ s/§device§/'$device'/xg   if ($device);
#  $sql =~ s/§reading§/'$reading'/xg if ($reading);

  if ($reading) {
    $reading = DbRep_createCommonSql($hash,undef,undef,$reading,undef,undef,undef);
    $reading =~ s/AND 1 \;//ig;
    $sql =~ s/§reading§/$reading/ig;
  }
  if ($device) {
    $device  = DbRep_createCommonSql($hash,undef,$device,undef,undef,undef,undef);
    $device  =~ s/AND 1 \;//ig;
    $sql =~ s/§device§/$device§/ig;
  }

#########################################################

Das kann man so natürlich noch nicht einbauen, es soll nur ein erste Ansatz sein.


So würde es dann jetzt mit meinem Patch aussehen.

2021.09.25 14:43:38.946 4: DbRep LogDBRep_Statistic_previous_Year - -------- New selection ---------
2021.09.25 14:43:38.946 4: DbRep LogDBRep_Statistic_previous_Year - Command: sqlCmd SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE \u00a7device\u00a7 AND \u00a7reading\u00a7 AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING
2021.09.25 14:43:38.946 4: DbRep LogDBRep_Statistic_previous_Year - Timestamp begin human readable: not set
2021.09.25 14:43:38.946 4: DbRep LogDBRep_Statistic_previous_Year - Timestamp end human readable: not set
2021.09.25 14:43:38.968 5: DbRep LogDBRep_Statistic_previous_Year - start BlockingCall with PID "32497"
2021.09.25 14:43:39.015 4: DbRep LogDBRep_Statistic_previous_Year - database user for operation: fhemuser
2021.09.25 14:43:39.019 1: PERL WARNING: Use of uninitialized value $device in pattern match (m//) at ./FHEM/93_DbRep.pm line 9870.
2021.09.25 14:43:39.020 1: PERL WARNING: Use of uninitialized value $idevice in split at ./FHEM/93_DbRep.pm line 9896.
2021.09.25 14:43:39.020 5: DbRep LogDBRep_Statistic_previous_Year - Devices for operation -
included (0): 
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.09.25 14:43:39.023 5: DbRep LogDBRep_Statistic_previous_Year - Readings for operation -
included (0): 
included with wildcard: Statistic_%Year
excluded (0): 
excluded with wildcard: %Autarky%,%Rate%
2021.09.25 14:43:39.024 1: PERL WARNING: Use of uninitialized value $selspec in concatenation (.) or string at ./FHEM/93_DbRep.pm line 9561.
2021.09.25 14:43:39.025 1: PERL WARNING: Use of uninitialized value $addon in concatenation (.) or string at ./FHEM/93_DbRep.pm line 9636.
2021.09.25 14:43:39.026 5: DbRep LogDBRep_Statistic_previous_Year - Devices for operation -
included (1): WR_1_API
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.09.25 14:43:39.026 1: PERL WARNING: Use of uninitialized value $reading in substitution (s///) at ./FHEM/93_DbRep.pm line 9973.
2021.09.25 14:43:39.027 1: PERL WARNING: Use of uninitialized value $reading in pattern match (m//) at ./FHEM/93_DbRep.pm line 9975.
2021.09.25 14:43:39.027 1: PERL WARNING: Use of uninitialized value $ireading in split at ./FHEM/93_DbRep.pm line 9996.
2021.09.25 14:43:39.028 5: DbRep LogDBRep_Statistic_previous_Year - Readings for operation -
included (0): 
included with wildcard: 
excluded (0): 
excluded with wildcard:
2021.09.25 14:43:39.029 4: DbRep LogDBRep_Statistic_previous_Year - SQL execute: SELECT * FROM (SELECT TIMESTAMP,READING,cast(VALUE/1000 AS decimal(6)) AS VALUE FROM history WHERE  ( DEVICE = 'WR_1_API' )  AND  ( READING LIKE 'Statistic_%Year' ) AND READING NOT LIKE '%Autarky%' AND READING NOT LIKE '%Rate%'  AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') ORDER BY TIMESTAMP DESC ) AS x1 GROUP BY x1.READING;
2021.09.25 14:43:39.081 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_EnergyFeedInGrid_Year 5200
2021.09.25 14:43:39.081 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_EnergyHomeBat_Year 1435
2021.09.25 14:43:39.082 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_EnergyHomeGrid_Year 2386
2021.09.25 14:43:39.082 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_EnergyHomePvSum_Year 4765
2021.09.25 14:43:39.082 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_EnergyHomePv_Year 3330
2021.09.25 14:43:39.082 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_EnergyHome_Year 7149
2021.09.25 14:43:39.082 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_TotalConsumption_Year 7152
2021.09.25 14:43:39.082 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_Yield_NoBat_Year 8530
2021.09.25 14:43:39.083 4: DbRep LogDBRep_Statistic_previous_Year - SQL result: 2020-12-31 14:57:03 Statistic_Yield_Year 9965
2021.09.25 14:43:39.097 5: DbRep LogDBRep_Statistic_previous_Year - BlockingCall finished PID "32497"
2021.09.25 14:43:39.098 5: DbRep LogDBRep_Statistic_previous_Year - SQL result decoded: TIMESTAMP|READING|VALUE\u00a72020-12-31 14:57:03|Statistic_EnergyFeedInGrid_Year|5200\u00a72020-12-31 14:57:03|Statistic_EnergyHomeBat_Year|1435\u00a72020-12-31 14:57:03|Statistic_EnergyHomeGrid_Year|2386\u00a72020-12-31 14:57:03|Statistic_EnergyHomePvSum_Year|4765\u00a72020-12-31 14:57:03|Statistic_EnergyHomePv_Year|3330\u00a72020-12-31 14:57:03|Statistic_EnergyHome_Year|7149\u00a72020-12-31 14:57:03|Statistic_TotalConsumption_Year|7152\u00a72020-12-31 14:57:03|Statistic_Yield_NoBat_Year|8530\u00a72020-12-31 14:57:03|Statistic_Yield_Year|9965
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 September 2021, 20:13:12
ZitatIch habe mal in den Code geschaut, wäre es denkbar die Funktion DbRep_createCommonSql() zu verwenden, om den §reading§ Syntax zu übertragen?
Ja, wäre evtl. möglich. Muß ich aber noch überlegen ob man sich damit keine Baustelle aufmacht.

Zitat
Da §reading§ von der Länge limitiert ist kann ich es dann so leider nicht verwenden. Ich wollte es natürlich dem Syntax vom Attribut reading angepasst nutzen.
Ich habe die Bescnränkung der Zeichenanzahl entfernt. Das stammte noch aus der Zeit als man in device, reading nur einen einzigen Wert eintragen konnte. Hat sich inzwischen überlebt.
Ist ins contrib geladen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 25 September 2021, 22:47:22
Zitat von: DS_Starter am 25 September 2021, 20:13:12
Ja, wäre evtl. möglich. Muß ich aber noch überlegen ob man sich damit keine Baustelle aufmacht.
Ich habe die Bescnränkung der Zeichenanzahl entfernt. Das stammte noch aus der Zeit als man in device, reading nur einen einzigen Wert eintragen konnte. Hat sich inzwischen überlebt.
Ist ins contrib geladen.
Okay,
die Grundlagenstudie habe ich jetzt bei mir lokal eingebaut und es läuft soweit. Lass Dir ruhig Zeit darüber nachzudenken, ich bin nächste Woche mal kurz weg :-)

Vielen Dank, das Du für meine Ideen immer ein offenes Ohr hast
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 04 Oktober 2021, 13:18:48
Hallo ch.eick & Muenzi

Da ihr euch aktuell mit der Datenbank und auch Datenreduzierung beschäftigt habt, mal ne Frage:
Habt ihr schonmal festgstellt, dass die Datenreduzierung am Ende des angegebenen Zeitintervalls nicht ganz sauber arbeitet (oder bin ich allein bzw. mache ich was falsch).
z.B.
reduceLogNbl 90 average=day include=<device>:<reading>

aufgeworfen hier https://forum.fhem.de/index.php/topic,121043.0.html (https://forum.fhem.de/index.php/topic,121043.0.html)
und https://forum.fhem.de/index.php/topic,53584.1425.html (https://forum.fhem.de/index.php/topic,53584.1425.html)

Betrifft bei mit sowohl das Kommando "reducelogNBL" im DB-Device als auch "reducelog" über ein DBRep-Device


Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 04 Oktober 2021, 13:38:20
Hallo Ralf,
das nutze ich nicht. Ich schreib mir meist selber schnell ein SQL und sammle nir sehr sparsam Daten.
VG
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Oktober 2021, 13:39:14
Das steht schon bzw. Noch auf meiner ToDo. Mache grad erwas Urlaub. Aber im Herbst und Winter hab ich wieder mehr Zeit für FHEM.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Oktober 2021, 17:44:25
Ich schau regelmäßig nach und bin echt gespannt....  :)

Ich wäre halt mal interessiert ob Andere dies auch beobachten.
Ich muss aber tatsächlich zugeben, dass bei automatisierter Reduzierung und größeren Datenbestände es nicht mehr auffällt  - es sein denn man schaut sich zufälling die Daten des entsprechenden Tages an.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 05 Oktober 2021, 18:16:26
Ich habe mal die Tage angefangen Min- und Maxwert der Temperatur vom Vortag abzufragen.
Nun bin ich überrascht, dass die Werte nicht einfach durchgereicht werden:

aus
setstate KS300 2021-10-05 18:12:16 temperature 14.8

wird
setstate KS300 2021-10-05 00:10:00 MAXTemp 15.3000
setstate KS300 2021-10-05 00:10:01 MINTemp 11.7000


wo kommen die Stellen hinter dem Komma her?

Muss/kann ich hier noch etwas konfigurieren?
defmod MinMaxTemp DbRep logdb
attr MinMaxTemp allowDeletion 1
attr MinMaxTemp autoForward {\
  ".*MAX.*" => "KS300 => MAXTemp",  \
  ".*MIN.*" => "KS300 => MINTemp",\
}
attr MinMaxTemp device KS300
attr MinMaxTemp fastStart 1
attr MinMaxTemp limit 300
attr MinMaxTemp reading temperature
attr MinMaxTemp room System->DbLog
attr MinMaxTemp showproctime 1
attr MinMaxTemp timestamp_begin previous_day_begin
attr MinMaxTemp timestamp_end previous_day_end
attr MinMaxTemp verbose 1


Danke und Grüße
Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Oktober 2021, 19:18:15
Hallo Bernd,

numerische Ergebnisse werden in DbRep aktuell immer auf 4 Stellen nach dem Komme genau ausgegeben bzw. in deinem Fall mit dieser Genauigkeit übertragen.
Stört es dich oder war es nur eine Frage weil es dir aufgefallen ist ?

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 05 Oktober 2021, 19:34:50
Hallo Heiko,

aktuell stört es mich nicht.
Es hat mich eher verwirrt, da ja kein neuer Wert berechnet wird.

Änderst du das irgendwann? Wenn man die Daten weiterverarbeitet, ist es evtl. unschön.

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Oktober 2021, 19:42:40
Ich hatte eine Änderung jetzt nicht direkt auf dem Schirm, aber nach meinem Urlaub will ich mir die Erweiterung bezüglich Platzhalter/Ersetzungen von §device§, §reading§ (im Thread bisschen weiter oben) nochmal vornehmen. In dem Zusammenhang könnte ich auch ein Attribut für die Anpassung der Nachkommagenauigkeit einführen.

Die Version würde ich zum Testen erstmal im contrib bereitstellen sobald ich dazu gekommen bin.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 05 Oktober 2021, 20:09:42
Das Attribut würde ich begrüßen, aber wie gesagt, ich habe keine Eile.

Danke schon einmal für deinen Support.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 31 Oktober 2021, 09:29:59
Hallo,
darf ich mich hier mit dranhängen:
Problem mit dem Dbrep-Modul:
Einfache CountEntries-Abfrage mit device: TYPE=AMADDEVICE ergibt hier die komplette Anzahl der Datensätze der DB, obwohl mein SQL-Manager nur ca. 10% davon zählt, dieses Problem gibt es auch bei anderen TYPEs. Es sind Abweichung von manchmal mehr als das Doppelte.
Stellt sich jetzt die Frage, wenn man Datensätze löschen will nach TYPE. Werden dann vielleicht alle gelöscht???? Das wäre fatal.

Vielleicht könntest Du Dir das mal anschauen.
Danke schön.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Oktober 2021, 09:57:10
Moin,

ich weiß jetzt nicht wie du mit SQL-Manager diese Abfrage mit TYPE=AMADDEVICE aufbaust.
Aber DbRep löst zunächst die relevanten Devices aus TYPE über FHEM auf und erstellt daraus eine Liste der Device-Selekts in der DB.
Du siehst das resultierende Statement wenn du verbose 4 im Device einstellst und den Befehl ausführst:

Zitat
2021.10.31 09:43:56.874 4: DbRep Rep.SSCam - -------- New selection ---------
2021.10.31 09:43:56.874 4: DbRep Rep.SSCam - Command: countEntries history
2021.10.31 09:43:56.875 4: DbRep Rep.SSCam - timeDiffToNow - year: , day: 10, hour: , min: , sec:
2021.10.31 09:43:56.875 4: DbRep Rep.SSCam - startMonth: 9 endMonth: 9 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:0
2021.10.31 09:43:56.876 4: DbRep Rep.SSCam - FullDay option: 0
2021.10.31 09:43:56.876 4: DbRep Rep.SSCam - Time difference to current time for calculating Timestamp begin: 867601 sec
2021.10.31 09:43:56.877 4: DbRep Rep.SSCam - Timestamp begin human readable: 2021-10-21 09:43:55
2021.10.31 09:43:56.877 4: DbRep Rep.SSCam - Timestamp end human readable: 2021-10-31 09:43:56
2021.10.31 09:43:56.878 4: DbRep Rep.SSCam - Aggregation: no
2021.10.31 09:43:56.952 4: DbRep Rep.SSCam - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE = 'SMA_Energymeter' ) AND TIMESTAMP >= '2021-10-21 09:43:55' AND TIMESTAMP <= '2021-10-31 09:43:56' ;

In dem Beispiel ist TYPE=SMAEM eingestellt und es wird daraus das device SMA_Energymeter ermittelt was im SQL verwendet wird.
Deswegen schaue erstmal wie das SQL bei dir aussieht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 02 November 2021, 17:56:10
Hallo DS_Starter,
hier bitte das Log:
2021.11.02 17:48:24 4: DbRep dbdel_Handy - -------- New selection ---------
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Command: countEntries history
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Timestamp begin human readable: not set
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Timestamp end human readable: not set
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Aggregation: no
2021.11.02 17:48:25 4: DbRep dbdel_Handy - SQL execute: SELECT COUNT(*) FROM history where 1 ;


hier bitte der Screenshot im Anhang,

und hier bitte auch die SQL-Abfrage, aber im Log sieht man ja schon den Fehler:

SELECT * FROM fhem.history where type like "%AMADDEVICE%";

Danke für die Mühen.

Nachtrag:

Ich sehe gerade, das per Definition der Type so geschrieben wird: AMADDevice, jetzt funktioniert es, das habe ich übersehen. In der DB steht es in Großbuchstaben drin, da habe ich nicht aufgepasst und die Abfrage so gebaut.
Aber warum ist dann die select-Abfrage so ... where = 1 ? Weil das Device nicht gefunden wird? so muss es natürlich alle Datensätze anzeigen.
Könnte man das noch abfangen?

Naja.... ich habe die falsche Brille aufgehabt :=)) ....

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 November 2021, 18:43:51
Hallo oldscout,

Zitat
Aber warum ist dann die select-Abfrage so ... where = 1 ? Weil das Device nicht gefunden wird? so muss es natürlich alle Datensätze anzeigen.
Könnte man das noch abfangen?
Weil das ein Fehler ist und der Logik geschuldet ist was FHEM zurückgibt wenn es den in TYPE= angegebenen devspec nicht gibt.
Ich konnte es bei mir nachstellen und das muß ich natürlich beheben.
Werde einen fix einbauen und hier Bescheid geben.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 November 2021, 21:23:19
Habe das Problem gefixt und wird morgen früh mit dem update verteilt.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oldscout am 04 November 2021, 18:26:07
Sehr schön, danke. Funktioniert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 November 2021, 13:24:50
Hallo Bernd, @all,

ich habe deinen Request umgesetzt und ein neues Attr zur Einstellung der Nachkommastellen eingebaut:

numDecimalPlaces- Legt die Anzahl der Nachkommastellen bei Readings mit numerischen Ergebnissen fest.
Ausgenommen sind Ergebnisse aus userspezifischen Abfragen (sqlCmd).
(default: 4)

Ist morgen früh im Update enthalten.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 24 November 2021, 17:07:34
Zitat von: DS_Starter am 21 November 2021, 13:24:50
Hallo Bernd, @all,

ich habe deinen Request umgesetzt und ein neues Attr zur Einstellung der Nachkommastellen eingebaut:

numDecimalPlaces- Legt die Anzahl der Nachkommastellen bei Readings mit numerischen Ergebnissen fest.
Ausgenommen sind Ergebnisse aus userspezifischen Abfragen (sqlCmd).
(default: 4)

Hallo Heiko,

super, danke dir. :)
Funktioniert wie erwartet und sieht im Reading wesentlich besser aus. ;)

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Dezember 2021, 22:54:01
Hallo zusammen,

ich habe eine neue DbRep-Version eingecheckt.
Die Funktion diffValue kann nun unterscheiden nun ob keine Werte zur Auswertung vorhanden sind oder die Differenz 0 ist.
Im ersten Fall wird wie bisher "-" ausgegeben, im zweiten Fall entsprechend Differenz "0".

Ist morgen früh im update enthalten.

VG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sailor am 03 Dezember 2021, 16:01:17
Ein herzerfrischendes "Moin" vom achtern Diek vorweg!

Das Tool DbRep ist inzwischen so mächtig geworden, dass ich mich frage ob dort inzwischen auch folgende Problematik gelöst werden kann:

Ich möchte einmal am Tag einen Befehl absetzen, bei dem
a) Alle Werte die jünger als 30d sind, auf einen stündlichen Mittelwert um xx:30 Uhr reduzieren.
b) Alle Werte die älter sind als 180d auf einen täglichen Mittelwert um 12:00 Uhr reduzieren.
c) Alle Werte die älter sind als 365d löschen.

Wobei es Ausnahmen geben muss, da gewisse Readings (monatlicher Gasverbrauch einmal zum Ende des Monats ermittelt) nicht durch a) bis c) behandelt werden soll.

Ich hoffe ich habe mich dahingehend verständlich ausgedrückt.

Danke für Eure Hilfe

Gruß
    Sailor
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Dezember 2021, 22:31:10
Hallo Sailor,

ja, das sollte machbar sein.
Übliche Praxis ist für jede Aufgabe ein separates DbRep zu erstellen, zu parametrisieren und regelmäßig ausführen lassen.
Ich nehme immer ein bereits existierendes Devices, kopiere es und passe es dann an.

Zitatc) Alle Werte die älter sind als 365d löschen.

Die leichteste Aufgabe. Du setzt die Attr

allowDeletion = 1
timeOlderThan = d:365


Mit dem Befehl "set ... delEntries" werden alle Daten älter als 365 Tage gelöscht.


Zitatb) Alle Werte die älter sind als 180d auf einen täglichen Mittelwert um 12:00 Uhr reduzieren.

Mit reduceLog kannst du arbeiten. Du setzt die Attribute

allowDeletion = 1
timeOlderThan = d:180
(timeDiffToNow = d:365  - optional)


Mit dem Befehl "set ... reduceLog average=day"  werden die Daten älter als 180 Tage auf einen Tagesmittelwert reduziert.
Wenn du das optionale timeDiffToNow ebenfalls setzt, werden Daten älter als 180 und nicht älter als 365 Tage bearbeitet.

Sollen Device/Readings ausgeklammert werden, ergänzt du den Befehl mit "EXCLUDE=device1:reading1,device2:reading2,...".


Zitata) Alle Werte die jünger als 30d sind, auf einen stündlichen Mittelwert um xx:30 Uhr reduzieren.

Auch hier nimmst du reduceLog und setzt die Attribute

allowDeletion = 1
timeDiffToNow = d:30


Der Befehl wäre dann "set ... reduceLog average". Device/Readings excluden wie oben angegeben.

Es gibt noch die Möglichkeit durch direkte Eingabe beim Befehl bestimmte Dinge mitzugeben.
Ich bevorzuge aber die fixe Einstellung über die Attribute.
Hoffe ich habe nichts vergessen. :) In der Hilfe findest du noch Infos zu möglichen Attributen in diesem Kontext.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sailor am 04 Dezember 2021, 13:30:50
Hallo Heiko

Zitat von: DS_Starter am 03 Dezember 2021, 22:31:10
ja, das sollte machbar sein.
Übliche Praxis ist für jede Aufgabe ein separates DbRep zu erstellen, zu parametrisieren und regelmäßig ausführen lassen.
Ich nehme immer ein bereits existierendes Devices, kopiere es und passe es dann an.

Cool, ich bereite mal was vor und poste den Erfolg...

Gruß und Danke
    Sailor
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Dezember 2021, 14:12:52
Hallo zusammen,

ich habe die Möglichkeiten des Attr userExitFn überarbeitet. Es ist nun möglich eigenen Code direkt im Attr zu hinterlegen.
Die Version liegt zunächst in meinem contrib zum Testen.

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"



Grüße,
Heiko

-------------------------------------------------------------------------------

userExitFn - stellt eine Schnittstelle zur Ausführung eigenen Usercodes zur Verfügung.
Grundsätzlich arbeitet die Schnittstelle ohne Eventgenerierung bzw. benötigt zur Funktion keinen Event. Die Schnittstelle kann mit folgenden Varianten verwendet werden.

    1. Aufruf einer Subroutine, z.B. in 99_myUtils.pm

    Die aufzurufende Subroutine wird in 99_myUtils.pm nach folgendem Muster erstellt:

    sub UserFunction {
      my $name    = shift;             # der Name des DbRep-Devices
      my $reading = shift;             # der Namen des erstellen Readings
      my $value   = shift;             # der Wert des Readings
      my $hash    = $defs{$name};
      ...
      # z.B. übergebene Daten loggen
      Log3 $name, 1, "UserExitFn $name called - transfer parameter are Reading: $reading, Value: $value " ;
      ...
    return;
    }

    Im im Attribut wird die Subroutine und optional ein Reading:Value Regex als Argument angegeben werden. Ohne diese Angabe werden alle Wertekombinationen als "wahr" gewertet und an die Subroutine übergeben (entspricht .*:.*).

        Beispiel:
        attr userExitFn UserFunction .*:.*
        # "UserFunction" ist die Subroutine in 99_myUtils.pm.
    Die Regexprüfung nach der Erstellung jedes Readings. Ist die Prüfung wahr, wird die angegebene Funktion aufgerufen.

    2. direkte Einngabe von eigenem Code

    Der eigene Code wird in geschweifte Klammern eingeschlossen. Der Aufruf des Codes erfolgt nach der Erstellung jedes Readings. Im Code stehen folgende Variablen für eine Auswertung zur Verfügung:

        $NAME - der Name des DbRep-Devices
        $READING - der Namen des erstellen Readings
        $VALUE - der Wert des Readings


        Beispiel:

        {
          if ($READING =~ /PrEnergySumHwc1_0_value__DIFF/) {
            my $mpk  = AttrVal($NAME, 'Multiplikator', '0');
            my $tarf = AttrVal($NAME, 'Tarif', '0');                                   # Kosten €/kWh           
            my $m3   = sprintf "%.3f", $VALUE/10000 * $mpk;                            # verbrauchte m3
            my $kwh  = sprintf "%.3f", $m3 * AttrVal($NAME, 'Brennwert_kWh/m3', '0');  # Umrechnung m3 -> kWh
            my $cost = sprintf "%.2f", $kwh * $tarf;
           
            my $hash = $defs{$NAME};
           
            readingsBulkUpdate ($hash, 'gas_consumption_m3',   $m3);
            readingsBulkUpdate ($hash, 'gas_consumption_kwh', $kwh);
            readingsBulkUpdate ($hash, 'gas_costs_euro',     $cost);
          }   
        }

        # Es werden die Readings gas_consumption_m3, gas_consumption_kwh und gas_costs_euro berechnet und im DbRep-Device erzeugt.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Dezember 2021, 17:04:40
Hallo Ralf, @all,

ich habe mich mal deiner Meldung in #1513 zugewendet und die reduceLog Funktion überarbeitet.
Einen wesentlichen Fehler mit average=day konnte ich beseitigen.
Offen ist noch, dass bei average die letzte Stunde nicht auf den Halbstundenwert reduziert wird und bei average=day der letzte
Tag nicht auf den 12:00 Wert reduziert wird. Aber da bin ich dran.

Die Version liegt im contrib, download siehe eine Meldung zuvor.

@sailor, die gefixte Version dürfte für deine Aufgabenstellung wichtig sein !

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Dezember 2021, 21:12:32
Zitat
Offen ist noch, dass bei average die letzte Stunde nicht auf den Halbstundenwert reduziert wird und bei average=day der letzte
Tag nicht auf den 12:00 Wert reduziert wird. Aber da bin ich dran.

Ist nun auch erledigt und die Version ins contrib geladen.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sailor am 06 Dezember 2021, 16:34:18
Hallo Heiko

Zitat von: DS_Starter am 03 Dezember 2021, 22:31:10
Mit dem Befehl "set ... reduceLog average=day"  werden die Daten älter als 180 Tage auf einen Tagesmittelwert reduziert.
Wenn du das optionale timeDiffToNow ebenfalls setzt, werden Daten älter als 180 und nicht älter als 365 Tage bearbeitet.
Sollen Device/Readings ausgeklammert werden, ergänzt du den Befehl mit "EXCLUDE=device1:reading1,device2:reading2,...".

Frage: Mit dem Befehl - Zusatz EXCLUDE und INCLUDE
kann ich davon ausgehen, dass bei folgendem Befehl


EXCLUDE=Device:Reading1, Device:Reading2 INCLUDE=Device:.*


Alle Readings des Device gemittelt bzw. gelöscht werden, bis auf die unter EXCLUDE aufgeführt?

Gruss
   Sailor
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Dezember 2021, 18:38:04
Nabend Sailor,

naja nicht ganz. Momentan zieht immer die ganz hinten stehende Option, also entweder das INCLUDE oder das EXCLUDE.
Das beide Optionen ziehen, daran arbeite ich noch.

Aber wenn du die Attribute mit verwendest, kannst du es umsetzen. Du setzt:


attr ... device Device


und rufst dann auf


set ... reduceLog average=day EXCLUDE=Device:Reading1,Device:Reading2


Dadurch werden im select alle Datensätze mit "DEVICE" aus der DB innerhalb der Zeitgrenzen gelesen.
In der nachfolgenden Verarbeitung werden wiederum die im EXCLUDE angegebenen Kombinationen ausgeschlossen.

Achtung: innerhalb des EXCLUDE keine Leerzeichen verwenden. Außerdem kann man dort keine Wildcards angeben. in den device/reading Attributen schon.

Es geht auch nur die Attr zu verwenden:


attr ... device Device
attr ... reading EXCLUDE=Reading1,Reading2


Dann führst du nur aus:


set ... reduceLog average=day


LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2021, 00:14:25
Nun werden auch direkt bei der Kommandozeilenangabe von reduceLog gleichzeitig angegebene EXCLUDE / INCLUDE Optionen berücksichtigt:

Beispiel:

    set <name> reduceLog 174:180 average EXCLUDE=SMA_Energymeter:Bezug_Wirkleistung INCLUDE=SMA_Energymeter:%
    # Datensätze älter als 174 und jünger als 180 Tage werden auf den Durchschnitt pro Stunde reduziert.
    # Es werden alle Readings vom Device "SMA_Energymeter" außer "Bezug_Wirkleistung" berücksichtigt. reduziert. 

So ist der Aufruf ebenfalls möglich um alle Device/Reading Kombinationen außer SMA_Energymeter:Bezug_Wirkleistung und DumDev:Energy zu bearbeiten:


set <name> reduceLog 174:180 average EXCLUDE=SMA_Energymeter:Bezug_Wirkleistung,DumDev:Energy INCLUDE=%:%


Liegt im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sailor am 07 Dezember 2021, 12:22:27
Hallo Heiko

Zitat von: DS_Starter am 07 Dezember 2021, 00:14:25
Nun werden auch direkt bei der Kommandozeilenangabe von reduceLog gleichzeitig angegebene EXCLUDE / INCLUDE Optionen berücksichtigt:
So ist der Aufruf ebenfalls möglich um alle Device/Reading Kombinationen außer SMA_Energymeter:Bezug_Wirkleistung und DumDev:Energy zu bearbeiten:

set <name> reduceLog 174:180 average EXCLUDE=SMA_Energymeter:Bezug_Wirkleistung,DumDev:Energy INCLUDE=%:%


Danke fuer deinen Einsatz.

Verstehe ich das richtig, das "%" ersetzt das ".*" an beliebiger Stelle?
BR_RadiatorL
BR_RadiatorR
GR_Radiator
KT_Radiator
TR_RadiatorL
TR_RadiatorR
CR_Radiator

werden mit
EXCLUDE=%_Radiato%:%
abgefangen?

Gruß
    Sailor
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 07 Dezember 2021, 12:31:38
Zitat von: Sailor am 07 Dezember 2021, 12:22:27
Verstehe ich das richtig, das "%" ersetzt das ".*" an beliebiger Stelle?
BR_RadiatorL
BR_RadiatorR
GR_Radiator
KT_Radiator
TR_RadiatorL
TR_RadiatorR
CR_Radiator

werden mit
EXCLUDE=%_Radiato%:%
abgefangen?
Hallo Sailer,

ja, das % ist für ein beliebiges Zeichen bei der SQL Abfrage in einer Datenbank.

VG
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sailor am 07 Dezember 2021, 12:43:51
Hallo Christian

Zitat von: ch.eick am 07 Dezember 2021, 12:31:38
ja, das % ist für ein beliebiges Zeichen bei der SQL Abfrage in einer Datenbank.

Das war das Stichwort!

http://www.w3bai.com/de/sql/sql_wildcards.html (http://www.w3bai.com/de/sql/sql_wildcards.html)

Danke
   Gruß
      Sailor
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2021, 12:50:51
Ich ergänze es mal noch in der Hilfe. Die Verwendung von "%" ist nicht an jeder Stelle in DbRep gleichermaßen gültig und kommt auf den Kontext der jweiligen Funktion an.
Aber hier in reduceLog konnte ich es so bauen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2021, 13:29:52
Habe die Hilfe ergänzt. Liegt im contrib:

Arbeitsweise mit Optionsangabe

....

Die Zusätze "EXCLUDE" bzw. "INCLUDE" können ergänzt werden um device/reading Kombinationen in reduceLog auszuschließen bzw. einzuschließen und überschreiben die Einstellung der Attribute "device" und "reading", die in diesem Fall nicht beachtet werden.
Diese Angabe in "EXCLUDE" wird als Regex ausgewertet. Innerhalb von "INCLUDE" können SQL-Wildcards verwendet werden (weitere Informationen zu SQL-Wildcards siehe mit get <name> versionNotes 6).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2021, 23:48:05
Nach weiteren intensiven Testen habe ich die neue Version soeben eingecheckt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2021, 23:16:34
Hallo,

ich habe noch ein bisschen weitergemacht und nun gibt es für SQLite Nutzer die Möglichkeit über sqlCmd PRAGMA Werte abzufragen. Bisher konnte man PRAGMA zwar setzen, aber eine Abfrage funktionierte nicht.

Außerdem wird die Encoding Einstellung der DB bei der initialen Verbindung direkt von der DB gelesen und davon die Einstellung von UTF8 (Internal) abgeleitet.

Es gibt auch einen neuen getter initData mit dem die initialen DB Internas als Readings angezeigt werden, z.B. die effektiven Userrechte auf die DB bei MariaDB.


   READINGS:
     2021-12-08 23:14:58   background_processing_time 0.0858
     2021-12-08 23:14:58   dbEncoding      UTF8
     2021-12-08 23:14:58   indexState      Index Report_Idx exists
     2021-12-08 23:14:58   sql_processing_time 0.0815
     2021-12-08 23:14:58   state           done
     2021-12-08 23:14:58   timestamp_oldest_dataset 2017-06-02 15:30:00
     2021-12-08 23:14:58   userRights      INSERT,SELECT,UPDATE,FILE,SHOW VIEW,INDEX,DELETE,PROCESS


Liegt wieder im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Sailor am 09 Dezember 2021, 15:21:51
Hallo Heiko

Zitat von: DS_Starter am 03 Dezember 2021, 22:31:10
ja, das sollte machbar sein.
Übliche Praxis ist für jede Aufgabe ein separates DbRep zu erstellen, zu parametrisieren und regelmäßig ausführen lassen.

Bevor ich mir meine DbLog zerschieße anbei mein tägliches at um 01:00 Uhr
Ich hoffe, das jetzt so richtig nach deiner Anleitung programmiert zu haben

Ich verstehe nicht, ob die 3 Instanzen sich nicht ins Gehege kommen, wenn diese parallel ausgeführt werden.

Danke fürs drüber schauen!

Gruß
    Sailor



*01:00:00 {

my $FileSize = int((-s "/home/fhem/fhemDb/fhem.db")/(1024*1024));
fhem("setreading myDbLog DbFileSize " . $FileSize);

### Delete all values older than 365 days
fhem("set DbRepArchive_365d delEntries EXCLUDE=CH_GasCalculator:CH_GasCounter_counters.A_EnergyMonthLast,CH_GasCalculator:CH_GasCounter_counters.A_EnergyMeter,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMonthLast,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMeter,myDbLog:DbFileSize");

### Create daily average value for all values older than 180 days
fhem("set DbRepArchive_180d reduceLog average=day EXCLUDE=CH_GasCalculator:CH_GasCounter_counters.A_EnergyMonthLast,CH_GasCalculator:CH_GasCounter_counters.A_EnergyMeter,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMonthLast,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMeter INCLUDE=%_Thermosta%:%,%_Radiato%:%,CH_Pressure%:%,CH_Speedtest:download,CH_Speedtest:upload,CH_Speedtest:ping,sysmon:%,myKm200:%,CH_GasCalculator:%,CH_WaterCalculator:%,CH_ElectricityCalculator:%");

### Create hourly average value for all values older than 30 days
fhem("set DbRepArchive_030d reduceLog average EXCLUDE=CH_GasCalculator:CH_GasCounter_counters.A_EnergyMonthLast,CH_GasCalculator:CH_GasCounter_counters.A_EnergyMeter,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMonthLast,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMeter INCLUDE=%_Thermosta%:%,%_Radiato%:%,CH_Pressure%:%,CH_Speedtest:download,CH_Speedtest:upload,CH_Speedtest:ping,sysmon:%,myKm200:%,CH_GasCalculator:%,CH_WaterCalculator:%,CH_ElectricityCalculator:%");

### Shrink database
fhem("set DbRepBasic Vaccuum");

my $FileSize = int((-s "/home/fhem/fhemDb/fhem.db")/(1024*1024));
fhem("setreading myDbLog DbFileSize " . $FileSize);
}


Mit dem

DbRepArchive_030d

Internals:
   DATABASE   /home/fhem/fhemDb/fhem.db
   DEF        myDbLog
   FUUID      61ae23b0-f33f-02bc-d155-41d99a832a462b73
   FVERSION   93_DbRep.pm:v8.46.1-s25321/2021-12-07
   LASTCMD     
   MODEL      Client
   NAME       DbRepArchive_030d
   NOTIFYDEV  global,DbRepArchive_030d
   NR         3489
   NTFY_ORDER 50-DbRepArchive_030d
   ROLE       Client
   STATE      connected » ProcTime: 0.0020 sec
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE myDbLog
     IDRETRIES  3
     MINTS      2021-12-06 15:55:13
     PACKAGE    main
     SQLHIST   
     VERSION    8.46.1
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2021-12-08 15:15:37   background_processing_time 0.0044
     2021-12-08 15:15:37   index_state     Index Report_Idx exists
     2021-12-08 15:15:37   sql_processing_time 0.0020
     2021-12-08 15:15:37   state           connected
Attributes:
   DbLogExclude .*
   allowDeletion 1
   devStateIcon connected.*:10px-kreis-gelb disconnect.*:10px-kreis-rot done.*:10px-kreis-gruen connected:10px-kreis-gruen
   fastStart  0
   group      DbLog
   role       Client
   room       System
   showproctime 1
   stateFormat {ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeDiffToNow d:30
   timeout    86400


DbRepArchive_180d

Internals:
   DATABASE   /home/fhem/fhemDb/fhem.db
   DEF        myDbLog
   FUUID      61ae247f-f33f-02bc-fd78-8f2cb9f61fd91343
   FVERSION   93_DbRep.pm:v8.46.1-s25321/2021-12-07
   LASTCMD     
   MODEL      Client
   NAME       DbRepArchive_180d
   NOTIFYDEV  global,DbRepArchive_180d
   NR         3490
   NTFY_ORDER 50-DbRepArchive_180d
   ROLE       Client
   STATE      connected » ProcTime: 0.0024 sec
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE myDbLog
     IDRETRIES  3
     MINTS      2021-12-06 15:55:13
     PACKAGE    main
     SQLHIST   
     VERSION    8.46.1
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2021-12-08 15:15:36   background_processing_time 0.0048
     2021-12-08 15:15:36   index_state     Index Report_Idx exists
     2021-12-08 15:15:36   sql_processing_time 0.0024
     2021-12-08 15:15:36   state           connected
Attributes:
   DbLogExclude .*
   allowDeletion 1
   devStateIcon connected.*:10px-kreis-gelb disconnect.*:10px-kreis-rot done.*:10px-kreis-gruen connected:10px-kreis-gruen
   fastStart  0
   group      DbLog
   role       Client
   room       System
   showproctime 1
   stateFormat {ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeDiffToNow d:365  - 180
   timeOlderThan 180
   timeout    86400


DbRepArchive_365d

Internals:
   DATABASE   /home/fhem/fhemDb/fhem.db
   DEF        myDbLog
   FUUID      61ae252e-f33f-02bc-f22a-d79e2ad17ab37d95
   FVERSION   93_DbRep.pm:v8.46.1-s25321/2021-12-07
   LASTCMD     
   MODEL      Client
   NAME       DbRepArchive_365d
   NOTIFYDEV  global,DbRepArchive_365d
   NR         3491
   NTFY_ORDER 50-DbRepArchive_365d
   ROLE       Client
   STATE      connected » ProcTime: 0.0044 sec
   TYPE       DbRep
   UTF8       0
   HELPER:
     DBLOGDEVICE myDbLog
     IDRETRIES  3
     MINTS      2021-12-06 15:55:13
     PACKAGE    main
     SQLHIST   
     VERSION    8.46.1
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2021-12-06 16:09:28   /--/----DELETED_ROWS_HISTORY-- 7143447
     2021-12-08 15:15:54   background_processing_time 0.0087
     2021-12-08 15:15:54   index_state     Index Report_Idx exists
     2021-12-08 15:15:54   sql_processing_time 0.0044
     2021-12-08 15:15:54   state           connected
Attributes:
   DbLogExclude .*
   allowDeletion 1
   devStateIcon connected.*:10px-kreis-gelb disconnect.*:10px-kreis-rot done.*:10px-kreis-gruen connected:10px-kreis-gruen
   fastStart  0
   group      DbLog
   role       Client
   room       System
   showproctime 1
   stateFormat {ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeOlderThan 365
   timeout    86400


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2021, 16:06:35
Moin Sailor,

ich schaue es mir morgen an. Möchte nicht nur kurz drüberfliegen und habe heute keine Zeit.
Aber moderne SQLite sollten mit parallenen Lese- und Schreibvorgängen kein Problem haben sofern WAL eingeschaltet ist.
WAL ist Standard im DbLog, siehe attr SQLiteJournalMode.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Dezember 2021, 17:45:17
Hallo Sailor,

ich habe ein paar Hinweise zusammengestellt und Korrekturen mit rot gekennzeichnet.
Ungeachtet einer möglichen Parallelität würde ich die Aktionen sequentiell ablaufen lassen. Zwei reduceLog gleichzeitig ist
kontraproduktiv und "Vacuum" würde ich generell nicht parallel laufen lassen. Vacuum sperrt dir auch die history, weshalb asynchroner Betrieb von DbLog in dem Fall Pflicht ist, aber das hast du denke ich.

Es gibt in DbRep bereits die Mechanismen für eine squentielle Abarbeitung eingebaut, Stichwort sind die Attr executeBeforeProc  und executeAfterProc.

Die Änderungen im Einzelnen:

DbRepArchive_365d
Zitat
Internals:
   DATABASE   /home/fhem/fhemDb/fhem.db
   DEF        myDbLog
   FUUID      61ae252e-f33f-02bc-f22a-d79e2ad17ab37d95
   FVERSION   93_DbRep.pm:v8.46.1-s25321/2021-12-07
   LASTCMD     
   MODEL      Client
   NAME       DbRepArchive_365d
   NOTIFYDEV  global,DbRepArchive_365d
   NR         3491
   NTFY_ORDER 50-DbRepArchive_365d
   ROLE       Client
   STATE      connected » ProcTime: 0.0044 sec
   TYPE       DbRep
   UTF8       0
Attributes:
   DbLogExclude .*
   allowDeletion 1
   devStateIcon connected.*:10px-kreis-gelb disconnect.*:10px-kreis-rot done.*:10px-kreis-gruen connected:10px-kreis-gruen
   fastStart  0
   group      DbLog
   role       Client
   room       System
   showproctime 1
   stateFormat {ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeOlderThan d:365
   timeout    86400
  executeAfterProc  set DbRepArchive_180d reduceLog average=day EXCLUDE=CH_GasCalculator:CH_GasCounter_counters.A_EnergyMonthLast,CH_GasCalculator:CH_GasCounter_counters.A_EnergyMeter,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMonthLast,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMeter
device EXCLUDE=CH_GasCalculator,CH_GasCalculator,CH_ElectricityCalculator,CH_ElectricityCalculator,myDbLog
readings: EXCLUDE=CH_GasCounter_counters.A_EnergyMonthLast,CH_GasCounter_counters.A_EnergyMeter,CH_ElectricityCounter_IEC_01_energyCalc_EnergyMonthLast,CH_ElectricityCounter_IEC_01_energyCalc_EnergyMeter,DbFileSize


Erläuterung: Wenn DbRepArchive_365d ausgeführt ist, startet das Device im Anschluß gleich DbRepArchive_180d.
Den reduceLog Befehl habe ich geändert und nur EXCLUDE belassen. INCLUDE kann nur eine Device/Reading -Kombination in der Befehlszeile angeben (siehe Hilfe).
Der delEntries-Befehl erlaubt zur Zeit keine EXCLUDE/INCLUDE Angaben in der Befehlszeile, sondern nur in den Attributen (siehe Hilfe)

DbRepArchive_180d:
Zitat
Internals:
   DATABASE   /home/fhem/fhemDb/fhem.db
   DEF        myDbLog
   FUUID      61ae247f-f33f-02bc-fd78-8f2cb9f61fd91343
   FVERSION   93_DbRep.pm:v8.46.1-s25321/2021-12-07
   LASTCMD     
   MODEL      Client
   NAME       DbRepArchive_180d
   NOTIFYDEV  global,DbRepArchive_180d
   NR         3490
   NTFY_ORDER 50-DbRepArchive_180d
   ROLE       Client
   STATE      connected » ProcTime: 0.0024 sec
   TYPE       DbRep
   UTF8       0
Attributes:
   DbLogExclude .*
   allowDeletion 1
   devStateIcon connected.*:10px-kreis-gelb disconnect.*:10px-kreis-rot done.*:10px-kreis-gruen connected:10px-kreis-gruen
   fastStart  0
   group      DbLog
   role       Client
   room       System
   showproctime 1
   stateFormat {ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeDiffToNow d:365
   timeOlderThan d:180
   timeout    86400
    executeAfterProc  set DbRepArchive_030d reduceLog average EXCLUDE=CH_GasCalculator:CH_GasCounter_counters.A_EnergyMonthLast,CH_GasCalculator:CH_GasCounter_counters.A_EnergyMeter,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMonthLast,CH_ElectricityCalculator:CH_ElectricityCounter_IEC_01_energyCalc_EnergyMeter
   device %_Thermosta,%_Radiato%,CH_Pressure%,CH_Speedtest,sysmon,myKm200,CH_GasCalculator,CH_WaterCalculator,CH_ElectricityCalculator


Erläuterung: timeDiffToNow / timeOlderThan waren syntaktisch falsch angegeben. executeAfterProc  startet wieder das nächste Device wenn fertig nur mit dem EXCLUDE, (das INCLUDE erfolgt im attr device des nachfolgenden DbRep). Das Attr device includiert die zu behandelnden Devices.

DbRepArchive_030d:

Zitat
Internals:
   DATABASE   /home/fhem/fhemDb/fhem.db
   DEF        myDbLog
   FUUID      61ae23b0-f33f-02bc-d155-41d99a832a462b73
   FVERSION   93_DbRep.pm:v8.46.1-s25321/2021-12-07
   LASTCMD     
   MODEL      Client
   NAME       DbRepArchive_030d
   NOTIFYDEV  global,DbRepArchive_030d
   NR         3489
   NTFY_ORDER 50-DbRepArchive_030d
   ROLE       Client
   STATE      connected » ProcTime: 0.0020 sec
   TYPE       DbRep
   UTF8       0
Attributes:
   DbLogExclude .*
   allowDeletion 1
   devStateIcon connected.*:10px-kreis-gelb disconnect.*:10px-kreis-rot done.*:10px-kreis-gruen connected:10px-kreis-gruen
   fastStart  0
   group      DbLog
   role       Client
   room       System
   showproctime 1
   stateFormat {ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
   timeDiffToNow d:30
   timeout    86400
   executeAfterProc  set DbRepBasic Vaccuum
   device %_Thermosta%,%_Radiato%,CH_Pressure,CH_Speedtest,sysmon,myKm200,CH_GasCalculator,CH_WaterCalculator,CH_ElectricityCalculator


Erläuterung: executeAfterProc startet Vaccuum wenn fertig.
Das Attr device inkludiert wieder die relevanten Devices.

Im DbRepBasic musst du noch setzen:
executeAfterProc  {my $FileSize = int((-s "/home/fhem/fhemDb/fhem.db")/(1024*1024));
fhem("setreading myDbLog DbFileSize " . $FileSize);}

Es startet die Size Ermittlung nach dem Vacuum. In einem at kannst du es so nicht verwenden, da Vacuum im Hintergrund noch laufen würde so wie du es im at hinterlegt hattest.

Um die gesamte Kette zu starten brauchst du jetzt nur noch so ein at:


*01:00:00 {

my $FileSize = int((-s "/home/fhem/fhemDb/fhem.db")/(1024*1024));
fhem("setreading myDbLog DbFileSize " . $FileSize);

### Delete all values older than 365 days
fhem("set DbRepArchive_365d delEntries");
}


Dann läuft alles nach und nach durch wenn wir keinen Fehler gemacht haben.
Vor dem ersten Versuch sollte man eine aktuellen Datenbanksicherung haben was eigentlich immer der Standard sein sollte.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Dezember 2021, 15:52:23
@DS_STARTER
zur Korrektur reduceLog --> https://forum.fhem.de/index.php/topic,53584.msg1191355.html#msg1191355

Klasse funktioniert :)  Danke!
Im set reduceLog der DbLog selber steckt der Fehler aber noch drin?

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Dezember 2021, 16:29:16
Hallo Ralf,

ZitatIm set reduceLog der DbLog selber steckt der Fehler aber noch drin?
Ja. Ich bin mir auch unsicher ob/wie ihn dort mit vertretbaren Aufwand bereinigen kann.
Im DbRep habe ich durch die Modularchitektur einfach mehr Möglichkeiten.

Eigentlich möchte ich am Liebsten alle Auswertungs- und Pflegefunktionen aus dem DbLog entfernen. DbLog soll sich nur um
das Logging kümmern. Auswerten und die Datenbank pflegen erledigt man mit DbRep. Aber historisch bedingt gibt es dort eben auch ein paar Funktionen die nichts mit dem eigentlichen Logging zu tun haben.

Also alles wie count(Nbl), deleteOldDays(Nbl), reduceLog(Nbl), userCommand erledigt man besser mit den entsprechenden Kommandos in DbRep.
Muß mal schauen wie ich es letztlich löse im DbLog. Vielleicht schreibe ich eine "deprecated Meldung" ins FHEM Log damit die User dadurch langsam für solche Aktionen auf DbRep umschwenken wenn noch nicht passiert.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 12 Dezember 2021, 17:18:08
Hmmm...    Vermutlich ne passable Idee. Das "Gleiche" an zwei Stellen zu pflegen ist ja eher blöd insbesondere wenn man es nicht einfach übernehmen kann.

Haben nicht andere Maintainer ihr Modul quasi mit neuem Namen und entsprechend passendem Funktionsumfang "neu" erstellt.
Das alte Modul kann dann ohne weitere Pflege bestehen bleiben und der User kann nach eigenem Gusto und Bedarf umsteigen wenns nötig wird.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Dezember 2021, 17:28:27
Ja, da hast du durchaus recht. Allerdings gibt es tiefere Verzahnungen zum Beispiel mit dem SVG Modul, sodass auch dort Erweiterungen notwendig wären bevor ein neues DbLog online gehen könnte.
Will damit andeuten, dass im Falle von DbLog die Dinge nicht ganz so trivial sind. Es greift schon recht tief in den FHEM Mechanismus ein.
Wenn ich ein neues DbLog erstelle, will ich gleich das Datenmodell überarbeiten. Das zieht dann wieder mehr hinterher ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Januar 2022, 19:36:53
Hallo Heiko,
es stehen mal wieder die Statistiken an und ich habe mich wieder in SQL ausgetobt :-)
Weil das SQL recht umfangreich ist habe ich es wegen der Lesbarkeit entfernt.
Das Ergebnis wird im DbRep auch bereits korrekt angezeigt, jedoch funktioniert die Aufteilung in brauchbare readings nicht vollständig.

Die fehlenden readings habe ich mit "<<<<<<<<<<<" markiert. Den Unterstrich am Ende des Namens hatte ich auch schon durch einen Buchstaber ersetzt, was nicht gereicht hat.

VG
    Christian

Hier mal das List

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        LogDB
   FUUID      61d43f05-f33f-61a8-ae1e-d125add1076a72f1
   FVERSION   93_DbRep.pm:v8.43.0-s24929/2021-09-06
   LASTCMD    sqlCmd SELECT * FROM ( SELECT  TIMESTAMP,  CONCAT('Q',CAST(MONTH(TIMESTAMP)/3 AS DECIMAL(1)),'_',REPLACE(READING,'_Year','')) AS READING,  VALUE FROM (  SELECT 
< snip >

   MODEL      Client
   NAME       LogDBRep_Statistic_previous_Quarter
   NOTIFYDEV  global,LogDBRep_Statistic_previous_Quarter
   NR         27404
   NTFY_ORDER 50-LogDBRep_Statistic_previous_Quarter
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     USAGE,ALL PRIVILEGES
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST   
     UEFN_REGEXP .*:.*
     USEREXITFN splitReading
     VERSION    8.43.0
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1641299717.09238
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2021-06-30 23:59:00   Q2_Statistic_EnergyHomeBat 676
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHome 1623
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHomeFeedInGrid 4797
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHomeGrid 16
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHomePv 1186
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyHomePvSum 1607
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyPv1 2019
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyPv2 1614
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyPv4 1260
     2021-09-30 23:59:00   Q3_SW_Statistic_EnergyPv5 1797
     2021-09-30 23:59:00   Q3_SW_Statistic_TotalConsumption 1623
     2021-09-30 23:59:00   Q3_SW_Statistic_Yield 6404
     2021-09-30 23:59:00   Q3_SW_Statistic_Yield_NoBat 5983
     2021-09-30 23:59:00   Q3_Statistic_EnergyHomeBat 421
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHome 2583
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHomeFeedInGrid 511
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHomeGrid 1378
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHomePv 875
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyHomePvSum 1205
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyPv1 510
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyPv2 422
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyPv4 330
     2021-12-31 23:59:00   Q4_SW_Statistic_EnergyPv5 551
     2021-12-31 23:59:00   Q4_SW_Statistic_TotalConsumption 2583
     2021-12-31 23:59:00   Q4_SW_Statistic_Yield 1716
     2021-12-31 23:59:00   Q4_SW_Statistic_Yield_NoBat 1386
     2021-12-31 23:59:00   Q4_Statistic_EnergyHomeBat 330
     2022-01-05 19:24:23   SqlResultRow_01 TIMESTAMP|READING|VALUE
     2022-01-05 19:24:23   SqlResultRow_02 2021-12-31 23:59:00|Q4_|previous                    <<<<<<<<<<<<<  das fehlt
     2022-01-05 19:24:23   SqlResultRow_03 2021-12-31 23:59:00|Q4_Statistic_EnergyHomeBat|330
     2022-01-05 19:24:23   SqlResultRow_04 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyHome|2583
     2022-01-05 19:24:23   SqlResultRow_05 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyHomeFeedInGrid|511
     2022-01-05 19:24:23   SqlResultRow_06 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyHomeGrid|1378
     2022-01-05 19:24:23   SqlResultRow_07 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyHomePv|875
     2022-01-05 19:24:23   SqlResultRow_08 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyHomePvSum|1205
     2022-01-05 19:24:23   SqlResultRow_09 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyPv1|510
     2022-01-05 19:24:23   SqlResultRow_10 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyPv2|422
     2022-01-05 19:24:23   SqlResultRow_11 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyPv4|330
     2022-01-05 19:24:23   SqlResultRow_12 2021-12-31 23:59:00|Q4_SW_Statistic_EnergyPv5|551
     2022-01-05 19:24:23   SqlResultRow_13 2021-12-31 23:59:00|Q4_SW_Statistic_TotalConsumption|2583
     2022-01-05 19:24:23   SqlResultRow_14 2021-12-31 23:59:00|Q4_SW_Statistic_Yield_NoBat|1386
     2022-01-05 19:24:23   SqlResultRow_15 2021-12-31 23:59:00|Q4_SW_Statistic_Yield|1716
     2022-01-05 19:24:23   SqlResultRow_16 2021-09-30 23:59:00|Q3_|                             <<<<<<<<<<<<<
     2022-01-05 19:24:23   SqlResultRow_17 2021-09-30 23:59:00|Q3_Statistic_EnergyHomeBat|421
     2022-01-05 19:24:23   SqlResultRow_18 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyHome|1623
     2022-01-05 19:24:23   SqlResultRow_19 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyHomeFeedInGrid|4797
     2022-01-05 19:24:23   SqlResultRow_20 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyHomeGrid|16
     2022-01-05 19:24:23   SqlResultRow_21 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyHomePv|1186
     2022-01-05 19:24:23   SqlResultRow_22 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyHomePvSum|1607
     2022-01-05 19:24:23   SqlResultRow_23 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyPv1|2019
     2022-01-05 19:24:23   SqlResultRow_24 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyPv2|1614
     2022-01-05 19:24:23   SqlResultRow_25 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyPv4|1260
     2022-01-05 19:24:23   SqlResultRow_26 2021-09-30 23:59:00|Q3_SW_Statistic_EnergyPv5|1797
     2022-01-05 19:24:23   SqlResultRow_27 2021-09-30 23:59:00|Q3_SW_Statistic_TotalConsumption|1623
     2022-01-05 19:24:23   SqlResultRow_28 2021-09-30 23:59:00|Q3_SW_Statistic_Yield_NoBat|5983
     2022-01-05 19:24:23   SqlResultRow_29 2021-09-30 23:59:00|Q3_SW_Statistic_Yield|6404
     2022-01-05 19:24:23   SqlResultRow_30 2021-06-30 23:59:00|Q2_|                             <<<<<<<<<<<<<
     2022-01-05 19:24:23   SqlResultRow_31 2021-06-30 23:59:00|Q2_Statistic_EnergyHomeBat|393                            Die doppelten sind noch ein Fehler in der Datenbank
     2022-01-05 19:24:23   SqlResultRow_32 2021-06-30 23:59:00|Q2_Statistic_EnergyHomeBat|676
     2022-01-05 19:24:23   SqlResultRow_33 2021-03-31 23:59:00|Q1_|                             <<<<<<<<<<<<<
     2022-01-05 19:24:23   SqlResultRow_34 2021-03-31 23:59:00|Q1_Statistic_EnergyHomeBat|-1152        <<<<<<<<<<<<<
     2022-01-05 19:24:23   SqlResultRow_35 2021-03-31 23:59:00|Q1_Statistic_EnergyHomeBat|-1435        <<<<<<<<<<<<<

     2022-01-05 19:24:23   sqlCmd          SELECT * FROM ( SELECT  TIMESTAMP,  CONCAT('Q',CAST(MONTH(TIMESTAMP)/3 AS DECIMAL(1)),'_',REPLACE(READING,'_Year','')) AS READING,  VALUE < snip >

     2022-01-05 19:24:23   sqlResultNumRows 34
     2022-01-05 19:24:23   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 0
   comment    Version 2022.01.04 14:00
   room       System
   sqlCmdVars SET @offset:=  (   CASE WHEN MONTH(CURRENT_DATE) IN (1,4,7,10) THEN @offset:=0          WHEN MONTH(CURRENT_DATE) IN (2,5,8,11) THEN @offset:=1       ELSE @offset:=2   END  );
   userExitFn splitReading .*:.*
   verbose    0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2022, 20:51:24
Hallo Christian,

mir ist nicht klar wie ich dir jetzt helfen könnte ?

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Januar 2022, 22:41:32
EDIT: Ich glaube ich bin auf der Spur, die Funktion splitReading hatte ich einfach übernommen und da ist der RegEx Filter falsch.
    Trotzdem erstmal Danke

Zitat von: DS_Starter am 05 Januar 2022, 20:51:24
mir ist nicht klar wie ich dir jetzt helfen könnte ?
Ich vermute es ist etwas mit " userExitFn splitReading .*:.* " nicht okay.
Warum werden alle anderen reading Namen erkannt und umgesetzt, aber die anderen wiederum nicht?


Das wird erkannt und als reading angelegt
2022-01-05 19:24:23   SqlResultRow_03 2021-12-31 23:59:00|Q4_Statistic_EnergyHomeBat|330

Und diese werden nicht als reading angelegt
2022-01-05 19:24:23   SqlResultRow_02 2021-12-31 23:59:00|Q4_|previous
2022-01-05 19:24:23   SqlResultRow_16 2021-09-30 23:59:00|Q3_|
2022-01-05 19:24:23   SqlResultRow_30 2021-06-30 23:59:00|Q2_|
2022-01-05 19:24:23   SqlResultRow_33 2021-03-31 23:59:00|Q1_| 
2022-01-05 19:24:23   SqlResultRow_35 2021-03-31 23:59:00|Q1_Statistic_EnergyHomeBat|-1435
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2022, 22:43:52
Zitat
Ich vermute es ist etwas mit " userExitFn splitReading .*:.* " nicht okay.

Wie sieht denn deine Funktion splitReading aus ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Januar 2022, 22:47:19
Zitat von: DS_Starter am 05 Januar 2022, 22:43:52
Wie sieht denn deine Funktion splitReading aus ?
Ich hatte gerade den Post vorher noch editiert.
Danke erstmal.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Januar 2022, 17:05:17
Hallo Heiko,
ich hatte vor einiger Zeit mal angefragt, ob Du einen Patch inds DRep mit aufnehmen würdest.
Der erste teil war da ersetzten von §device§ und §reading§ für sqlcmd , was Du ja schon teilweise eingebaut hattest.

Der Patch mit wunsch zur Aufnahme wäre folgendes

< snip >

## ch.eick patch ########################################
#  $sql =~ s/§device§/'$device'/xg   if ($device);                                                                      ## das hattest Du bereits rein genommen
#  $sql =~ s/§reading§/'$reading'/xg if ($reading);

  if ($reading) {
    $reading = DbRep_createCommonSql($hash,undef,undef,$reading,undef,undef,undef);
    $reading =~ s/AND 1 \;//ig;
    $sql =~ s/§reading§/$reading/ig;
  }
  if ($device) {
    $device  = DbRep_createCommonSql($hash,undef,$device,undef,undef,undef,undef);
    $device  =~ s/AND 1 \;//ig;
    $sql =~ s/§device§/$device/ig;
  }

###################################################

< snip >


Durch den Patch würden z.B. auch solche einsetzungen möglich sein, was ich jetzt jedes mal wieder einbaue.

device WR_1_API
reading Statistic_%Year EXCLUDE=%Autarky%,%Rate%


Leider kommen noch diese warnings :-)

2022.01.08 17:04:17.353 1: PERL WARNING: Use of uninitialized value $device in pattern match (m//) at ./FHEM/93_DbRep.pm line 9861.
2022.01.08 17:04:17.354 1: PERL WARNING: Use of uninitialized value $idevice in split at ./FHEM/93_DbRep.pm line 9887.
2022.01.08 17:04:17.355 1: PERL WARNING: Use of uninitialized value $selspec in concatenation (.) or string at ./FHEM/93_DbRep.pm line 9552.
2022.01.08 17:04:17.356 1: PERL WARNING: Use of uninitialized value $addon in concatenation (.) or string at ./FHEM/93_DbRep.pm line 9627.
2022.01.08 17:04:17.356 1: PERL WARNING: Use of uninitialized value $reading in substitution (s///) at ./FHEM/93_DbRep.pm line 9964.
2022.01.08 17:04:17.357 1: PERL WARNING: Use of uninitialized value $reading in pattern match (m//) at ./FHEM/93_DbRep.pm line 9966.
2022.01.08 17:04:17.357 1: PERL WARNING: Use of uninitialized value $ireading in split at ./FHEM/93_DbRep.pm line 9987.


VG
    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Januar 2022, 17:15:07
Hallo Christian,

ja schaue ich mir gerne mit an.
Bin momentan sowieso dabei den Code in DbRep zu überarbeiten. Wer FHEM regelmäßig updated, hat es vllt. schon bemerkt dass DbRep oft im Update mit dabei ist. Es ist aber nur refactoring, weswegen es für den User keine Änderungen gibt.
Es sei denn ich baue mal Mist.  ;)

Vllt. morgen schon ....

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Januar 2022, 17:18:09
Zitat von: DS_Starter am 08 Januar 2022, 17:15:07
Hallo Christian,

ja schaue ich mir gerne mit an.
Bin momentan sowieso dabei den Code in DbRep zu überarbeiten. Wer FHEM regelmäßig updated, hat es vllt. schon bemerkt dass DbRep oft im Update mit dabei ist. Es ist aber nur refactoring, weswegen es für den User keine Änderungen gibt.
Es sei denn ich baue mal Mist.  ;)

Vllt. morgen schon ....
Super, das würde mich freuen, dann könnte ich den SQL Code etwas portabler bezüglich der Device und Reading Namen gestalten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Januar 2022, 15:05:49
Hallo Christian,

ich habe die Erweiterung eingearbeitet.
Die Version habe ich zum Test in mein contrib geladen.

Durch diese Änderung wird die Verwendung der Platzhalter §device§ und §reading§ etwas modifiziert.
Die Auflösung erfolgt komplex, d.h. man verwendet nicht mehr DEVICE=§device§, sondern nur §device§.

An dem Beispiel wird es deutlich:


select DEVICE, READING, count(*) from history where §device§ AND §reading§ AND TIMESTAMP >= §timestamp_begin§ group by DEVICE, READING


Teste die Version bitte. Es wäre sicherlich hilfreich wenn die Version ggf. auch von deinen Mitstreitern im Projekt bzw. auch mit
komplexen SQL außerhalb deines WR-Projektes getestet wird. Du hast ja immer viele SQL's auf Lager.

Wenn alles klappen sollte (ich habe keine Fehler bei mir festgestellt) finalisiere ich die Version und passe auch noch die cref für
sqlCmd an.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 09 Januar 2022, 15:26:42
Zitat von: DS_Starter am 09 Januar 2022, 15:05:49
Hallo Christian,

ich habe die Erweiterung eingearbeitet.
Die Version habe ich zum Test in mein contrib geladen.

Durch diese Änderung wird die Verwendung der Platzhalter §device§ und §reading§ etwas modifiziert.
Die Auflösung erfolgt komplex, d.h. man verwendet nicht mehr DEVICE=§device§, sondern nur §device§.

An dem Beispiel wird es deutlich:


select DEVICE, READING, count(*) from history where §device§ AND §reading§ AND TIMESTAMP >= §timestamp_begin§ group by DEVICE, READING


Teste die Version bitte. Es wäre sicherlich hilfreich wenn die Version ggf. auch von deinen Mitstreitern im Projekt bzw. auch mit
komplexen SQL außerhalb deines WR-Projektes getestet wird. Du hast ja immer viele SQL's auf Lager.

Wenn alles klaapen sollte (ich habe keine Fehler bei mir festgestellt) finalisiere ich die Version und passe auch noch die cref für
sqlCmd an.

LG,
Heiko
Okay, ich teste das dann morgen mal.
Genau so verwende ich es momentan eh schon und meine Mitstreiter verlassen sich eher auf meine SQL Künste :-)
Kannst Du mir das wget bitte nochmal posten?

LG Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Januar 2022, 15:28:42
Klar:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


PS: Habe noch eine Warnung zu doppelter "my" Deklaration beseitigt. Einfach nochmal ziehen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 Januar 2022, 10:14:06
Zitat von: DS_Starter am 09 Januar 2022, 15:28:42

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


PS: Habe noch eine Warnung zu doppelter "my" Deklaration beseitigt. Einfach nochmal ziehen.
Hallo Heiko,

ich habe es gerade geladen und meine SQLs ausgeführt.
Bisher konnte ich keine Fehler feststellen.

FVERSION 93_DbRep.pm:v1.1.1-s25411/2022-01-02

Gruß
     Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Januar 2022, 10:42:27
Danke für die Rückmeldung Christian.
Ich nehme mir noch ein paar weitere Überarbeitungen vor. Wenn von deiner Seite (oder deiner Mitstreiter im Projekt) keine weiteren Infos kommen werde ich die Version im Laufe der Woche einchecken.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 Januar 2022, 10:50:08
Zitat von: DS_Starter am 10 Januar 2022, 10:42:27
Danke für die Rückmeldung Christian.
Ich nehme mir noch ein paar weitere Überarbeitungen vor. Wenn von deiner Seite (oder deiner Mitstreiter im Projekt) keine weiteren Infos kommen werde ich die Version im Laufe der Woche einchecken.
Ich denke nicht, dass von den Mitstreiter etwas kommen wird ;-)
Momentan müsste ich dann noch warten, bis eine verwendbare DbRep Version in der Verteilung liegt, damit ich den anderen die SQLs bereitstellen kann. Da herscht leider gerade etwas chaos.
Könntest Du da docht eventuell erst eine bereit stellen und dann die anderen Änderungen einbauen?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Januar 2022, 10:52:42
Ja kann ich machen. Werde die comref für sqlCmd anpassen und dann hast du/ihr morgen früh ein offizielles update vorliegen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 Januar 2022, 10:56:01
Zitat von: DS_Starter am 10 Januar 2022, 10:52:42
Ja kann ich machen. Werde die comref für sqlCmd anpassen und dann hast du/ihr morgen früh ein offizielles update vorliegen.
Heiko, Du bist super :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Januar 2022, 19:44:36
eingecheckt  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Januar 2022, 10:48:31
Moin Heiko,
erstmal die Rückmeldung, ich konnte bisher keine probleme erkannen. Das Ersetzen der Variablen beim sqlcmp funktioniert somit.

Nun noch zwei Fragen:
- Kann man beim sqlcmd Aufruf das letzte Kommand aus der Kommandowiederholung auch als "Pointer" angeben?
  Wenn man es ansonsten zyklisch wiederholt muss es ja immer komplett wieder übergeben werden. Das SELECT hat formatiert rund 280 Zeilen ;-)
- Wenn DbRep ein SELCT ausgeführt hat wird es als Bandwurm abgelegt, könnte man das auch formatiert belassen, damit man es im Eingabe Editor besser lesen kann?

VG
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Januar 2022, 13:10:45
Hi Christian,

ja, habe dein Monster im anderen Thread schon gesehen.

Zitat
Kann man beim sqlcmd Aufruf das letzte Kommand aus der Kommandowiederholung auch als "Pointer" angeben?
Momentan nicht. Könnte mir vorstellen die Technik an dieser Stelle neu zu schreiben um z.B. in einem Programm so auf ein SQL zugreifen zu können:  SQL = $sqlhist->{<Nummer>}.  Wenn es das ist was du meinst.

Zitat
Wenn DbRep ein SELCT ausgeführt hat wird es als Bandwurm abgelegt, könnte man das auch formatiert belassen, damit man es im Eingabe Editor besser lesen kann?
Ich denke das geht nicht, weil es im FHEMWEB nicht vorgesehen ist Argumente von set/get Kommandos direkt formatiert anzuzeigen. Geht nur indirekt mit den FHEM Widgets, aber nicht aus einer set-Liste.
Glaube auch dass ich es schon mal probiert hatte und daran gescheitert bin.

Grüße,
Heiko


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Januar 2022, 13:26:20
Zitat von: DS_Starter am 14 Januar 2022, 13:10:45
Hi Christian,

ja, habe dein Monster im anderen Thread schon gesehen.
Momentan nicht. Könnte mir vorstellen die Technik an dieser Stelle neu zu schreiben um z.B. in einem Programm so auf ein SQL zugreifen zu können:  SQL = $sqlhist->{<Nummer>}.  Wenn es das ist was du meinst.
Hallo Heiko,
genau das meinte ich.
Monster leben länger :-) Du liest also einfach wo anders mit :-) :-)

Und das mit dem formatierten SQL hast Du einfach überlesen, was ich gut verstehn kann.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Januar 2022, 13:28:28
Zitat
Und das mit dem formatierten SQL hast Du einfach überlesen, was ich gut verstehn kann.
Hab ich nicht ... nur blöd formatiert gehabt.  :)
Habs oben geändert
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Januar 2022, 14:02:41
Zitat von: DS_Starter am 14 Januar 2022, 13:28:28
Hab ich nicht ... nur blöd formatiert gehabt.  :)
Habs oben geändert
Super danke für die Info, also wäre es ne menge unnötiger Mehraufwand.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: adrian am 16 Januar 2022, 09:43:05
Hallo zusammen,
mein DbRep Device wird einmal die Woche ausgeführt um einen dumpMySQL auszuführen.
In dem Attribut "executeAfterProc" habe ich den Fhembefehl "backup" eingetragen.
Das lief auch alles tadellos.
Seit dem letzten Update von DbLog ist der Befehl "reducelogNBL" nun nicht mehr über DDbLog auszuführen, sondern über DbRep.
Hab das auch unmittelbar angepasst, aber nicht bedacht, dass nun in DbRep das Atttibut "backup" gesetzt ist.
Das heisst nun, dass nicht nur am Wochenende nach dem dumpSQL das backup ausgeführt wird, nein auch täglich nach jedem reducelog.

Gibt es eine Möglichkeit den set-Befehlen unterschiedliche executeAfterProc mitzugeben?
Oder wie würdet ihr das machen?

Danke und einen schönen Sonntag
Adrian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2022, 09:51:47
Hallo Adrian,

für die Aufgaben dumpMySQL  bzw. reducelog benutzt du zwei unterschiedliche DbRep Devices.
Du kopierst dir dein bestehendes Device einfach und in dem kopierten Device löscht du das Attribut executeAfterProc.

Man kann sich eine beliebige Anzahl DbReps für die unterschiedlichsten Aufgaben anlegen und entsprechend parametrisieren.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2022, 16:58:50
Hallo Christian, @all,

ich habe die Arbeitsweise des Setter sqlCmdHistory angefangen umzubauen.
Für den User ergibt sich folgende Feature.
Im Setter sqlCmdHistory gibt es nun einen neuen Punkt "___list_sqlhistory___".

Mit Auswahl dieses Eintrags werden die Einträge des SQL History mit einem Key und der ursprünglichen Formatierung
angezeigt, z.B.


4 => SET @TS = DATE_FORMAT(NOW(),'_%Y_%m_%d');

SET @FOLDER = '/sds1/backup/';
SET @PREFIX = 'export';
SET @EXT = '.csv';

SET @CMD = CONCAT(" SELECT *
FROM `fhemtest`.`history`
WHERE `DEVICE`='SMA_Energymeter' AND TIMESTAMP > DATE_SUB(CURRENT_DATE(),INTERVAL 1 DAY)
INTO OUTFILE '",@FOLDER,@PREFIX,@TS,@EXT,"'
FIELDS ENCLOSED BY '\"'
TERMINATED BY ';;'
ESCAPED BY '\"'","
LINES TERMINATED BY '\r\n';;
");

PREPARE statement FROM @CMD;

EXECUTE statement;
3 => select DEVICE,count(*) from history where TIMESTAMP >= §timestamp_begin§ group by DEVICE;
2 => SET @TS = DATE_FORMAT(NOW(),'_%Y_%m_%d'); SET @FOLDER = '/sds1/backup/'; SET @PREFIX = 'export'; SET @EXT = '.csv'; SET @CMD = CONCAT(" SELECT * FROM `fhemtest`.`history` WHERE `DEVICE`='SMA_Energymeter' AND TIMESTAMP > DATE_SUB(CURRENT_DATE(),INTERVAL 1 DAY) INTO OUTFILE '",@FOLDER,@PREFIX,@TS,@EXT,"' FIELDS ENCLOSED BY '\"' TERMINATED BY ';;' ESCAPED BY '\"'"," LINES TERMINATED BY '\r\n';; "); PREPARE statement FROM @CMD; EXECUTE statement;
1 => select count(*) from current;


Nun kann man das Statement mit dem Key "4" auch ausführen indem man sqlCmd folgendes aufruft:


set ... sqlCmd ckey:4


Zur Zeit ist es noch so, dass bei einem Restart die Zuordung Key-> Statement nicht erhalten bleibt.
Daran arbeite ich noch.

Die Version liegt zum Test in meinem contrib.

Grüße,
Heiko 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2022, 20:38:37
Nun bleibt die Zuordung Key-> Statement auch bei einem Restart erhalten.
Damit zeigt die Adressierung mit

    set ... sqlCmd ckey:X

immer auf das gleiche Statement. Zumindest solange die History nicht gepurged wird oder wegen Überschreitung von sqlCmdHistoryLength aus dem Cache rausgeschoben wird.

-> contrib
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 16 Januar 2022, 21:30:51
Zitat von: DS_Starter am 16 Januar 2022, 20:38:37
Nun bleibt die Zuordung Key-> Statement auch bei einem Restart erhalten.
Damit zeigt die Adressierung mit

    set ... sqlCmd ckey:X

immer auf das gleiche Statement. Zumindest solange die History nicht gepurged wird oder wegen Überschreitung von sqlCmdHistoryLength aus dem Cache rausgeschoben wird.

-> contrib
Bei dem Rausschieben würde ich jetzt aber auch interpretieren, dass sich die Nummerierung bei einem zusätzlichen sqlcmd auch verschiebt.
Liege ich da jetzt richtig oder falsch?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2022, 21:46:07
Sobald ein Statement in die History aufgenommen wird, bekommt es einen Key.
Den behält es solange es sich in der History befindet, auch beim restart und einlesen des Cachefile.
Neue Statements bekommen einen nächst höheren Key. Wenn sqlCmdHistoryLength überschritten wird, wird das älteste Statement (mit dem niedrigsten Key) aus der Historie gelöscht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Januar 2022, 17:39:58
Jetzt bleibt die Formatierung des SQL im Cache auch nach einem Restart von FHEM erhalten.

Das Attr sqlCmdHistoryLength ist nun ein Schieberegler von 0 ... 200.
Sollte ausreichen.

-> contrib
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Januar 2022, 23:29:59
Neue Version ist eingecheckt und morgen früh im Regelupdate enthalten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2022, 14:38:48
Für das Kommando sqlCmdHistory ist nun folgende Funktionalität hinzugekommen:

___purge_sqlhistory___    : löscht den History Cache
___list_sqlhistory___    : zeigt die aktuell im Cache vorhandenen SQL-Statements incl. ihrem Cache Key (ckey)
___restore_sqlhistory___    : macht ein zuvor ausgeführtes "___purge_sqlhistory___" rückgängig

sqlCmdHistory wird angezeigt sobald das Attr sqlCmdHistoryLength (ungleich 0) gesetzt ist.
Dadurch sind die oben angegebenen Aktivitäten sofort verfügbar auch wenn der SQL Cache leer ist.

-> contrib
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2022, 16:43:23
Nochmal eine Erweiterung/Änderung...

...
Der SQL Cache wird beim Beenden von FHEM automatisch gesichert und beim Start des Systems wiederhergestellt. Mit den nachfolgenden Einträgen werden spezielle Funktionen ausgeführt:

    ___purge_sqlhistory___    : löscht den History Cache
    ___list_sqlhistory___    : zeigt die aktuell im Cache vorhandenen SQL-Statements incl. ihrem Cache Key (ckey)
    ___save_sqlhistory___    : sichert den History Cache manuell
    ___restore_sqlhistory___    : stellt die letzte Sicherung des History Cache wieder her
...

Das History File wird nicht bei jeder Änderung gespeichert was für Nutzer der configDB von Vorteil ist.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 18 Januar 2022, 17:26:13
Na jetzt überschlagen sich ja die Änderungen für meinen Wunsch :-)
Zum Glück hatte ich noch keine Zeit zum Testen... Das nimmt ja Zustände an wie bei mir, wenn ich mal einen Lauf habe :-) :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2022, 17:36:31
Ja manchmal läufts einfach und es kommen Ideen beim Testen und Durchdenken.  ;)
Passt aber weil ich grad den Code im Modul straffe/modernisiere.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 27 Januar 2022, 20:07:40
Hi Heiko,
ich bekomme seit dem letzten DbRep update eine Division durch null, die ich mir nicht erklären kann.

Das ist das innere SELECT, was ein richtiges Ergebnis liefert und ohne Fehler läuft.

Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      5f3a5796-f33f-61a8-e1ac-2438b1322f15e59a
   FVERSION   93_DbRep.pm:v8.46.12-s25411/2022-01-02
   LASTCMD    sqlCmd SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0;
   MODEL      Client
   NAME       LogDBRep_PV_Forecast_SQL
   NOTIFYDEV  global,LogDBRep_PV_Forecast_SQL
   NR         432
   NTFY_ORDER 50-LogDBRep_PV_Forecast_SQL
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     USAGE,ALL PRIVILEGES
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST    SELECT&nbsp;TIMESTAMP,DEVICE,READING,VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;DATE_ADD(CURDATE(),INTERVAL&nbsp;t2.HOUR&nbsp;HOUR)&nbsp;AS&nbsp;TIMESTAMP,t2.DEVICE,@readingname&nbsp;AS&nbsp;READING,cast(if(avg(t2.FACTOR)&nbsp;>&nbsp;1.6,1.6,avg(t2.FACTOR)&nbsp;)&nbsp;AS&nbsp;DECIMAL(2,1))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;t1.TIMESTAMP,t1.HOUR,t1.DEVICE,t1.READING,t1.VALUE,if(@diff&nbsp;=&nbsp;0,NULL,@temp:=cast((t1.VALUE-@diff)&nbsp;AS&nbsp;DECIMAL(6,2)))&nbsp;AS&nbsp;DIFF,cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr)&nbsp;AS&nbsp;DECIMAL(4,1))&nbsp;AS&nbsp;FACTOR,@diff:=t1.VALUE&nbsp;AS&nbsp;curr_V&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;h.TIMESTAMP,date(h.TIMESTAMP)&nbsp;AS&nbsp;DATE,hour(h.TIMESTAMP)&nbsp;AS&nbsp;HOUR,h.DEVICE,h.READING,h.VALUE&nbsp;FROM&nbsp;history&nbsp;AS&nbsp;h&nbsp;WHERE&nbsp;h.DEVICE&nbsp;=&nbsp;@device&nbsp;AND&nbsp;(h.READING&nbsp;=&nbsp;@reading1&nbsp;OR&nbsp;h.READING&nbsp;=&nbsp;@reading2)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;>=&nbsp;DATE_SUB(DATE(now()),INTERVAL&nbsp;@days&nbsp;DAY)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;<=&nbsp;CURDATE()&nbsp;AND&nbsp;MINUTE(h.TIMESTAMP)&nbsp;=&nbsp;0&nbsp;AND&nbsp;h.VALUE&nbsp;>=&nbsp;0&nbsp;GROUP&nbsp;BY&nbsp;DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP&nbsp;)t1&nbsp;)tx&nbsp;WHERE&nbsp;READING&nbsp;!=&nbsp;@reading2&nbsp;AND&nbsp;HOUR&nbsp;>&nbsp;6&nbsp;)t2&nbsp;GROUP&nbsp;BY&nbsp;t2.HOUR,t2.DEVICE&nbsp;)t3&nbsp;WHERE&nbsp;t3.VALUE&nbsp;!=&nbsp;0&nbsp;order&nbsp;by&nbsp;TIMESTAMP;,SELECT&nbsp;TIMESTAMP,DEVICE,READING,VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;DATE_ADD(CURDATE(),INTERVAL&nbsp;t2.HOUR&nbsp;HOUR)&nbsp;AS&nbsp;TIMESTAMP,t2.DEVICE,@readingname&nbsp;AS&nbsp;READING,cast(if(avg(t2.FACTOR)&nbsp;>&nbsp;1.6,1.6,avg(t2.FACTOR)&nbsp;)&nbsp;AS&nbsp;DECIMAL(2,1))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;t1.TIMESTAMP,t1.HOUR,t1.DEVICE,t1.READING,t1.VALUE,if(@diff&nbsp;=&nbsp;0,NULL,@temp:=cast((t1.VALUE-@diff)&nbsp;AS&nbsp;DECIMAL(6,2)))&nbsp;AS&nbsp;DIFF,cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr)&nbsp;AS&nbsp;DECIMAL(4,1))&nbsp;AS&nbsp;FACTOR,@diff:=t1.VALUE&nbsp;AS&nbsp;curr_V&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;h.TIMESTAMP,date(h.TIMESTAMP)&nbsp;AS&nbsp;DATE,hour(h.TIMESTAMP)&nbsp;AS&nbsp;HOUR,h.DEVICE,h.READING,h.VALUE&nbsp;FROM&nbsp;history&nbsp;AS&nbsp;h&nbsp;WHERE&nbsp;h.DEVICE&nbsp;=&nbsp;@device&nbsp;AND&nbsp;(h.READING&nbsp;=&nbsp;@reading1&nbsp;OR&nbsp;h.READING&nbsp;=&nbsp;@reading2)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;>=&nbsp;DATE_SUB(DATE(now()),INTERVAL&nbsp;@days&nbsp;DAY)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;<=&nbsp;CURDATE()&nbsp;AND&nbsp;MINUTE(h.TIMESTAMP)&nbsp;=&nbsp;0&nbsp;AND&nbsp;h.VALUE&nbsp;>=&nbsp;0&nbsp;GROUP&nbsp;BY&nbsp;DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP&nbsp;)t1&nbsp;)tx&nbsp;WHERE&nbsp;READING&nbsp;!=&nbsp;@reading2&nbsp;AND&nbsp;HOUR&nbsp;>&nbsp;6&nbsp;)t2&nbsp;GROUP&nbsp;BY&nbsp;t2.HOUR,t2.DEVICE&nbsp;)t3&nbsp;WHERE&nbsp;t3.VALUE&nbsp;!=&nbsp;0;,SELECT&nbsp;TIMESTAMP,DEVICE,READING,VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;DATE_ADD(CURDATE(),INTERVAL&nbsp;t2.HOUR&nbsp;HOUR)&nbsp;AS&nbsp;TIMESTAMP,t2.DEVICE,@readingname&nbsp;AS&nbsp;READING,cast(if(avg(t2.FACTOR)&nbsp;>&nbsp;1.6,1.6,avg(t2.FACTOR)&nbsp;)&nbsp;AS&nbsp;DECIMAL(2,1))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;t1.TIMESTAMP,t1.HOUR,t1.DEVICE,t1.READING,t1.VALUE,if(@diff&nbsp;=&nbsp;0,NULL,@temp:=cast((t1.VALUE-@diff)&nbsp;AS&nbsp;DECIMAL(6,2)))&nbsp;AS&nbsp;DIFF,cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr)&nbsp;AS&nbsp;DECIMAL(4,1))&nbsp;AS&nbsp;FACTOR,@diff:=t1.VALUE&nbsp;AS&nbsp;curr_V&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;h.TIMESTAMP,date(h.TIMESTAMP)&nbsp;AS&nbsp;DATE,hour(h.TIMESTAMP)&nbsp;AS&nbsp;HOUR,h.DEVICE,h.READING,h.VALUE&nbsp;FROM&nbsp;history&nbsp;AS&nbsp;h&nbsp;WHERE&nbsp;h.DEVICE&nbsp;=&nbsp;@device&nbsp;AND&nbsp;(h.READING&nbsp;=&nbsp;@reading1&nbsp;OR&nbsp;h.READING&nbsp;=&nbsp;@reading2)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;>=&nbsp;DATE_SUB(DATE(now()),INTERVAL&nbsp;@days&nbsp;DAY)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;<=&nbsp;CURDATE()&nbsp;AND&nbsp;MINUTE(h.TIMESTAMP)&nbsp;=&nbsp;0&nbsp;AND&nbsp;h.VALUE&nbsp;>=&nbsp;0&nbsp;GROUP&nbsp;BY&nbsp;DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP&nbsp;)t1&nbsp;)tx&nbsp;WHERE&nbsp;READING&nbsp;!=&nbsp;@reading2&nbsp;AND&nbsp;HOUR&nbsp;>&nbsp;6&nbsp;)t2&nbsp;GROUP&nbsp;BY&nbsp;t2.HOUR,t2.DEVICE&nbsp;)t3&nbsp;WHERE&nbsp;t3.VALUE&nbsp;!=&nbsp;0&nbsp;;,select&nbsp;*&nbsp;FROM&nbsp;(SELECT&nbsp;TIMESTAMP,READING,cast(VALUE/1000&nbsp;AS&nbsp;decimal(6))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;history&nbsp;WHERE&nbsp;DEVICE=@device&nbsp;AND&nbsp;READING&nbsp;LIKE&nbsp;'Statistic_%Year'&nbsp;AND&nbsp;READING&nbsp;NOT&nbsp;LIKE&nbsp;'%Autarky%'&nbsp;and&nbsp;READING&nbsp;NOT&nbsp;LIKE&nbsp;'%Rate%'&nbsp;AND&nbsp;TIMESTAMP>STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d')&nbsp;AND&nbsp;TIMESTAMP<STR_TO_DATE(CONCAT(YEAR(CURDATE()),'-01-01'),'%Y-%m-%d')&nbsp;order&nbsp;by&nbsp;TIMESTAMP&nbsp;desc&nbsp;limit&nbsp;15&nbsp;)&nbsp;AS&nbsp;x1&nbsp;GROUP&nbsp;BY&nbsp;x1.READING&nbsp;;,DELETE&nbsp;FROM&nbsp;history&nbsp;WHERE&nbsp;DEVICE='PV_1'&nbsp;AND&nbsp;READING='Solar_Calculation_fc0'&nbsp;AND&nbsp;TIMESTAMP>='2021-02-28&nbsp;07:00:00'
     VERSION    8.46.12
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2022-01-27 20:01:59   SqlResultRow_01 TIMESTAMP|DEVICE|READING|VALUE
     2022-01-27 20:01:59   SqlResultRow_02 2022-01-27 09:00:00|WR_1|Solar_Correction_Faktor_auto|1.6
     2022-01-27 20:01:59   SqlResultRow_03 2022-01-27 10:00:00|WR_1|Solar_Correction_Faktor_auto|1.6
     2022-01-27 20:01:59   SqlResultRow_04 2022-01-27 11:00:00|WR_1|Solar_Correction_Faktor_auto|1.4
     2022-01-27 20:01:59   SqlResultRow_05 2022-01-27 12:00:00|WR_1|Solar_Correction_Faktor_auto|0.9
     2022-01-27 20:01:59   SqlResultRow_06 2022-01-27 13:00:00|WR_1|Solar_Correction_Faktor_auto|0.8
     2022-01-27 20:01:59   SqlResultRow_07 2022-01-27 14:00:00|WR_1|Solar_Correction_Faktor_auto|0.7
     2022-01-27 20:01:59   SqlResultRow_08 2022-01-27 15:00:00|WR_1|Solar_Correction_Faktor_auto|0.6
     2022-01-27 20:01:59   SqlResultRow_09 2022-01-27 16:00:00|WR_1|Solar_Correction_Faktor_auto|0.3
     2022-01-27 20:01:59   SqlResultRow_10 2022-01-27 17:00:00|WR_1|Solar_Correction_Faktor_auto|0.1
     2022-01-27 20:01:59   SqlResultRow_11 2022-01-27 08:00:00|WR_1|Solar_Correction_Faktor_auto|0.2
     2022-01-27 20:01:59   sqlCmd          SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0;
     2022-01-27 20:01:59   sqlResultNumRows 10
     2022-01-27 20:01:59   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 1
   room       System
   sqlCmdHistoryLength 5
   sqlCmdVars SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;


Jetzt kommt noch ein INSERT drum herum und der Fehler tritt auf.

Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      5f3a5796-f33f-61a8-e1ac-2438b1322f15e59a
   FVERSION   93_DbRep.pm:v8.46.12-s25411/2022-01-02
   LASTCMD    sqlCmd INSERT INTO history  (TIMESTAMP,DEVICE,READING,VALUE)  SELECT  TIMESTAMP,DEVICE,READING,VALUE  FROM (  SELECT  DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,  t2.DEVICE,  @readingname AS READING,  cast(if(avg(t2.FACTOR) > 1.6, 1.6,  avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE  FROM (  SELECT * FROM (  SELECT  t1.TIMESTAMP,  t1.HOUR,  t1.DEVICE,  t1.READING,  t1.VALUE,  if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,  cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR,  @diff:=t1.VALUE AS curr_V  FROM (  SELECT  h.TIMESTAMP,  date(h.TIMESTAMP) AS DATE,  hour(h.TIMESTAMP) AS HOUR,  h.DEVICE,  h.READING,  h.VALUE  FROM history AS h  WHERE h.DEVICE = @device  AND (h.READING = @reading1 OR h.READING = @reading2)  AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY)  AND h.TIMESTAMP <= CURDATE()  AND MINUTE(h.TIMESTAMP) = 0  AND h.VALUE >= 0  GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP  )t1  )tx  WHERE READING != @reading2  AND HOUR > 6  )t2  GROUP BY t2.HOUR,t2.DEVICE  )t3  WHERE  t3.VALUE != 0 ON DUPLICATE KEY UPDATE  VALUE=t3.VALUE;
   MODEL      Client
   NAME       LogDBRep_PV_Forecast_SQL
   NOTIFYDEV  global,LogDBRep_PV_Forecast_SQL
   NR         432
   NTFY_ORDER 50-LogDBRep_PV_Forecast_SQL
   ROLE       Client
   STATE      error
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     USAGE,ALL PRIVILEGES
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     SQLHIST    SELECT&nbsp;TIMESTAMP,DEVICE,READING,VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;DATE_ADD(CURDATE(),INTERVAL&nbsp;t2.HOUR&nbsp;HOUR)&nbsp;AS&nbsp;TIMESTAMP,t2.DEVICE,@readingname&nbsp;AS&nbsp;READING,cast(if(avg(t2.FACTOR)&nbsp;>&nbsp;1.6,1.6,avg(t2.FACTOR)&nbsp;)&nbsp;AS&nbsp;DECIMAL(2,1))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;t1.TIMESTAMP,t1.HOUR,t1.DEVICE,t1.READING,t1.VALUE,if(@diff&nbsp;=&nbsp;0,NULL,@temp:=cast((t1.VALUE-@diff)&nbsp;AS&nbsp;DECIMAL(6,2)))&nbsp;AS&nbsp;DIFF,cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr)&nbsp;AS&nbsp;DECIMAL(4,1))&nbsp;AS&nbsp;FACTOR,@diff:=t1.VALUE&nbsp;AS&nbsp;curr_V&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;h.TIMESTAMP,date(h.TIMESTAMP)&nbsp;AS&nbsp;DATE,hour(h.TIMESTAMP)&nbsp;AS&nbsp;HOUR,h.DEVICE,h.READING,h.VALUE&nbsp;FROM&nbsp;history&nbsp;AS&nbsp;h&nbsp;WHERE&nbsp;h.DEVICE&nbsp;=&nbsp;@device&nbsp;AND&nbsp;(h.READING&nbsp;=&nbsp;@reading1&nbsp;OR&nbsp;h.READING&nbsp;=&nbsp;@reading2)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;>=&nbsp;DATE_SUB(DATE(now()),INTERVAL&nbsp;@days&nbsp;DAY)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;<=&nbsp;CURDATE()&nbsp;AND&nbsp;MINUTE(h.TIMESTAMP)&nbsp;=&nbsp;0&nbsp;AND&nbsp;h.VALUE&nbsp;>=&nbsp;0&nbsp;GROUP&nbsp;BY&nbsp;DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP&nbsp;)t1&nbsp;)tx&nbsp;WHERE&nbsp;READING&nbsp;!=&nbsp;@reading2&nbsp;AND&nbsp;HOUR&nbsp;>&nbsp;6&nbsp;)t2&nbsp;GROUP&nbsp;BY&nbsp;t2.HOUR,t2.DEVICE&nbsp;)t3&nbsp;WHERE&nbsp;t3.VALUE&nbsp;!=&nbsp;0&nbsp;order&nbsp;by&nbsp;TIMESTAMP;,SELECT&nbsp;TIMESTAMP,DEVICE,READING,VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;DATE_ADD(CURDATE(),INTERVAL&nbsp;t2.HOUR&nbsp;HOUR)&nbsp;AS&nbsp;TIMESTAMP,t2.DEVICE,@readingname&nbsp;AS&nbsp;READING,cast(if(avg(t2.FACTOR)&nbsp;>&nbsp;1.6,1.6,avg(t2.FACTOR)&nbsp;)&nbsp;AS&nbsp;DECIMAL(2,1))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;t1.TIMESTAMP,t1.HOUR,t1.DEVICE,t1.READING,t1.VALUE,if(@diff&nbsp;=&nbsp;0,NULL,@temp:=cast((t1.VALUE-@diff)&nbsp;AS&nbsp;DECIMAL(6,2)))&nbsp;AS&nbsp;DIFF,cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr)&nbsp;AS&nbsp;DECIMAL(4,1))&nbsp;AS&nbsp;FACTOR,@diff:=t1.VALUE&nbsp;AS&nbsp;curr_V&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;h.TIMESTAMP,date(h.TIMESTAMP)&nbsp;AS&nbsp;DATE,hour(h.TIMESTAMP)&nbsp;AS&nbsp;HOUR,h.DEVICE,h.READING,h.VALUE&nbsp;FROM&nbsp;history&nbsp;AS&nbsp;h&nbsp;WHERE&nbsp;h.DEVICE&nbsp;=&nbsp;@device&nbsp;AND&nbsp;(h.READING&nbsp;=&nbsp;@reading1&nbsp;OR&nbsp;h.READING&nbsp;=&nbsp;@reading2)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;>=&nbsp;DATE_SUB(DATE(now()),INTERVAL&nbsp;@days&nbsp;DAY)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;<=&nbsp;CURDATE()&nbsp;AND&nbsp;MINUTE(h.TIMESTAMP)&nbsp;=&nbsp;0&nbsp;AND&nbsp;h.VALUE&nbsp;>=&nbsp;0&nbsp;GROUP&nbsp;BY&nbsp;DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP&nbsp;)t1&nbsp;)tx&nbsp;WHERE&nbsp;READING&nbsp;!=&nbsp;@reading2&nbsp;AND&nbsp;HOUR&nbsp;>&nbsp;6&nbsp;)t2&nbsp;GROUP&nbsp;BY&nbsp;t2.HOUR,t2.DEVICE&nbsp;)t3&nbsp;WHERE&nbsp;t3.VALUE&nbsp;!=&nbsp;0;,SELECT&nbsp;TIMESTAMP,DEVICE,READING,VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;DATE_ADD(CURDATE(),INTERVAL&nbsp;t2.HOUR&nbsp;HOUR)&nbsp;AS&nbsp;TIMESTAMP,t2.DEVICE,@readingname&nbsp;AS&nbsp;READING,cast(if(avg(t2.FACTOR)&nbsp;>&nbsp;1.6,1.6,avg(t2.FACTOR)&nbsp;)&nbsp;AS&nbsp;DECIMAL(2,1))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;t1.TIMESTAMP,t1.HOUR,t1.DEVICE,t1.READING,t1.VALUE,if(@diff&nbsp;=&nbsp;0,NULL,@temp:=cast((t1.VALUE-@diff)&nbsp;AS&nbsp;DECIMAL(6,2)))&nbsp;AS&nbsp;DIFF,cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr)&nbsp;AS&nbsp;DECIMAL(4,1))&nbsp;AS&nbsp;FACTOR,@diff:=t1.VALUE&nbsp;AS&nbsp;curr_V&nbsp;FROM&nbsp;(&nbsp;SELECT&nbsp;h.TIMESTAMP,date(h.TIMESTAMP)&nbsp;AS&nbsp;DATE,hour(h.TIMESTAMP)&nbsp;AS&nbsp;HOUR,h.DEVICE,h.READING,h.VALUE&nbsp;FROM&nbsp;history&nbsp;AS&nbsp;h&nbsp;WHERE&nbsp;h.DEVICE&nbsp;=&nbsp;@device&nbsp;AND&nbsp;(h.READING&nbsp;=&nbsp;@reading1&nbsp;OR&nbsp;h.READING&nbsp;=&nbsp;@reading2)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;>=&nbsp;DATE_SUB(DATE(now()),INTERVAL&nbsp;@days&nbsp;DAY)&nbsp;AND&nbsp;h.TIMESTAMP&nbsp;<=&nbsp;CURDATE()&nbsp;AND&nbsp;MINUTE(h.TIMESTAMP)&nbsp;=&nbsp;0&nbsp;AND&nbsp;h.VALUE&nbsp;>=&nbsp;0&nbsp;GROUP&nbsp;BY&nbsp;DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP&nbsp;)t1&nbsp;)tx&nbsp;WHERE&nbsp;READING&nbsp;!=&nbsp;@reading2&nbsp;AND&nbsp;HOUR&nbsp;>&nbsp;6&nbsp;)t2&nbsp;GROUP&nbsp;BY&nbsp;t2.HOUR,t2.DEVICE&nbsp;)t3&nbsp;WHERE&nbsp;t3.VALUE&nbsp;!=&nbsp;0&nbsp;;,select&nbsp;*&nbsp;FROM&nbsp;(SELECT&nbsp;TIMESTAMP,READING,cast(VALUE/1000&nbsp;AS&nbsp;decimal(6))&nbsp;AS&nbsp;VALUE&nbsp;FROM&nbsp;history&nbsp;WHERE&nbsp;DEVICE=@device&nbsp;AND&nbsp;READING&nbsp;LIKE&nbsp;'Statistic_%Year'&nbsp;AND&nbsp;READING&nbsp;NOT&nbsp;LIKE&nbsp;'%Autarky%'&nbsp;and&nbsp;READING&nbsp;NOT&nbsp;LIKE&nbsp;'%Rate%'&nbsp;AND&nbsp;TIMESTAMP>STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d')&nbsp;AND&nbsp;TIMESTAMP<STR_TO_DATE(CONCAT(YEAR(CURDATE()),'-01-01'),'%Y-%m-%d')&nbsp;order&nbsp;by&nbsp;TIMESTAMP&nbsp;desc&nbsp;limit&nbsp;15&nbsp;)&nbsp;AS&nbsp;x1&nbsp;GROUP&nbsp;BY&nbsp;x1.READING&nbsp;;,DELETE&nbsp;FROM&nbsp;history&nbsp;WHERE&nbsp;DEVICE='PV_1'&nbsp;AND&nbsp;READING='Solar_Calculation_fc0'&nbsp;AND&nbsp;TIMESTAMP>='2021-02-28&nbsp;07:00:00'
     VERSION    8.46.12
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2022-01-27 20:06:24   errortext       DBD::mysql::st execute failed: Division by 0 at ./FHEM/93_DbRep.pm line 10576.

     2022-01-27 20:06:24   state           error
Attributes:
   DbLogExclude .*
   allowDeletion 1
   room       System
   sqlCmdHistoryLength 5
   sqlCmdVars SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;


Kann das mit dem Aufräumen zu tun haben?

VG
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Januar 2022, 20:17:37
Hallo Christian,

ich habe beide SQLs jetzt mal rauskopiert und bei mir ausgeführt.
Laufen fehlerfrei durch. Zwar ohne Wert, aber syntaktisch ok.


2022.01.27 20:13:18.101 4: DbRep Rep.LogDB - -------- New selection ---------
2022.01.27 20:13:18.102 4: DbRep Rep.LogDB - Command: sqlCmd INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.01.27 20:13:18.103 4: DbRep Rep.LogDB - FullDay option: 0
2022.01.27 20:13:18.103 4: DbRep Rep.LogDB - Timestamp begin human readable: 2022-01-01 00:00:00
2022.01.27 20:13:18.104 4: DbRep Rep.LogDB - Timestamp end human readable: 2022-01-26 23:59:59
2022.01.27 20:13:18.308 4: DbRep Rep.LogDB - adminCredentials successfully read from file
2022.01.27 20:13:18.310 4: DbRep Rep.LogDB - Database connect - user: root, UTF-8 option set: yes
2022.01.27 20:13:18.312 4: DbRep Rep.LogDB - SQL execute: INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.01.27 20:13:18.316 4: DbRep Rep.LogDB - data autocommitted
2022.01.27 20:13:18.317 3: DbRep Rep.LogDB - Number of entries processed in db fhemtest: 0 by INSERT


Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 27 Januar 2022, 20:31:23
Zitat von: DS_Starter am 27 Januar 2022, 20:17:37
Hallo Christian,

ich habe beide SQLs jetzt mal rauskopiert und bei mir ausgeführt.
Laufen fehlerfrei durch. Zwar ohne Wert, aber syntaktisch ok.


2022.01.27 20:13:18.101 4: DbRep Rep.LogDB - -------- New selection ---------
2022.01.27 20:13:18.102 4: DbRep Rep.LogDB - Command: sqlCmd INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.01.27 20:13:18.103 4: DbRep Rep.LogDB - FullDay option: 0
2022.01.27 20:13:18.103 4: DbRep Rep.LogDB - Timestamp begin human readable: 2022-01-01 00:00:00
2022.01.27 20:13:18.104 4: DbRep Rep.LogDB - Timestamp end human readable: 2022-01-26 23:59:59
2022.01.27 20:13:18.308 4: DbRep Rep.LogDB - adminCredentials successfully read from file
2022.01.27 20:13:18.310 4: DbRep Rep.LogDB - Database connect - user: root, UTF-8 option set: yes
2022.01.27 20:13:18.312 4: DbRep Rep.LogDB - SQL execute: INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.01.27 20:13:18.316 4: DbRep Rep.LogDB - data autocommitted
2022.01.27 20:13:18.317 3: DbRep Rep.LogDB - Number of entries processed in db fhemtest: 0 by INSERT


Grüße,
Heiko
Okay, danke,
dann muss es doch etwas mit den Daten zu tun haben.
Aber warum geht der SELECT, mit der Berechnung? Der liefert ein Korrektes Ergebnis.
Dann mit dem INSERT, bei dem nichts mehr zusätzlich gerechnet wird kommt die Meldung.

Besten Dank
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 Januar 2022, 20:45:01
Aktuell sind wir schon bei dieser eingecheckten Version:

93_DbRep.pm:v8.47.0-s25492/2022-01-17
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 Januar 2022, 09:22:35
Zitat von: DS_Starter am 27 Januar 2022, 20:45:01
Aktuell sind wir schon bei dieser eingecheckten Version:

93_DbRep.pm:v8.47.0-s25492/2022-01-17
Bin wieder on Track :-)

Das Problem waren letztlich die Daten. Ich habe jetzt expliziet die Division durch Null abgefangen und schon geht es.
Warum das SELECT das nicht als Fehler gemeldet hat, aber das Umklammernde INSERT kann ich nicht verstehen. => böser Woodoo Zauber :-)

VG
  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: t1me2die am 28 Januar 2022, 10:16:52
Moin zusammen, ich wollte hier einmal mein Problem in Verbindung mit dem DbRep, MariaDB und OptimizeTable verlinken:

https://forum.fhem.de/index.php/topic,125762.0.html (https://forum.fhem.de/index.php/topic,125762.0.html)

Falls jemand einen hilfreichen Tipp für mich hat, oder ob ich irgendwas falsch konfiguriert hat wäre ich sehr hilfreich.

Gruß
Mathze
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 10:56:41
Hallo seit dem letzten Update funktioniert bei mir "dumpmysql" nicht mehr. Es scheint das noch die current-Tabelle gesichert wird dann tut sich aber nichts mehr.
Mit der Version "93_DbRep.pm:v8.46.11-s25414/2022-01-03" läuft noch alles und das Dumpfile mit gut 1.1 GB ist nach ca 3 Minuten geschrieben.

Fhem läuft auf einem Rasberry 4, der Dump wird clientside ausgeführt

Woran kann das liegen?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 13:07:13
Schalte bitte verbose 4 im Device ein und wiederhole bitte den dump.
Dann bitte noch ein List vom Device.
Bei mir läuft alles wie gewohnt.  Allerdings sind wir inzwischen offiziell bereits bei der Version V8.47.0.
Mach bitte vorher noch ein update.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 13:58:51
Noch besser wäre es die aktuellste Entwicklungsversion zu benutzen. Die habe ich im Einsatz und steht kurz vor dem Check In.

Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 14:01:55
Hallo DS_Starter,

ich habe es schon mehrfach probiert aber das Problem tritt bei mir seit der Version "93_DbRep.pm:v8.46.11-s25414/2022-01-03" jedes mal auf. Jetzt habe ich noch mal auf die aktuelle Version upgedatet und einen Logauszug und  ein List vom Device an gehangen. Es scheint was abgearbeitet zu werden aber es wird nichts in den Speicher geschrieben. Die Dateigröße bleibt bei 39KB stehen.
Logauszug:
2022.01.30 13:17:24 3: DbRep repdb - ################################################################
2022.01.30 13:17:24 3: DbRep repdb - ###             New database clientSide dump                 ###
2022.01.30 13:17:24 3: DbRep repdb - ################################################################
2022.01.30 13:17:24 3: DbRep repdb - Starting dump of database 'fhem'
2022.01.30 13:17:24 4: DbRep repdb - Database connect - user: fhem, UTF-8 option set: yes
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SELECT VERSION()
2022.01.30 13:17:24 3: DbRep repdb - Characterset of collection and backup file set to utf8.
2022.01.30 13:17:24 3: DbRep repdb - Searching for tables inside database fhem....
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SHOW TABLE STATUS FROM `fhem`
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SELECT count(*) FROM `current`
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SELECT count(*) FROM `history`
2022.01.30 13:17:33 3: DbRep repdb - Found 2 tables with 6401083 records.
2022.01.30 13:17:33 3: DbRep repdb - Dumping table current (Type InnoDB):
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW CREATE TABLE `current`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW FIELDS FROM `current`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `current` LIMIT 0,5000;
2022.01.30 13:17:33 3: DbRep repdb - 212 records inserted (size of backupfile: 38.10 KB)
2022.01.30 13:17:33 3: DbRep repdb - Dumping table history (Type InnoDB):
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW CREATE TABLE `history`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW FIELDS FROM `history`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 0,5000;
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 5000,5000;
2022.01.30 13:18:15 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 10000,5000;
2022.01.30 13:19:31 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 15000,5000;
2022.01.30 13:21:17 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 20000,5000;
2022.01.30 13:23:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 25000,5000;
2022.01.30 13:26:19 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 30000,5000;
2022.01.30 13:29:36 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 35000,5000;
2022.01.30 13:33:22 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 40000,5000;
2022.01.30 13:37:39 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 45000,5000;
2022.01.30 13:42:25 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 50000,5000;
2022.01.30 13:47:42 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 55000,5000;
2022.01.30 13:53:29 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 60000,5000;

Device:
Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      5c52f431-f33f-e11d-c0b2-f1dc4dfa79b37156
   FVERSION   93_DbRep.pm:v8.47.0-s25492/2022-01-17
   LASTCMD    dumpMySQL clientSide
   MODEL      Client
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         436
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      clientSide Dump is running - be patient and see Logfile !
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.47.0
     RUNNING_BACKUP_CLIENT:
       abortFn    DbRep_DumpAborted
       bc_pid     150
       finishFn   DbRep_DumpDone
       fn         DbRep_mysql_DumpClientSide
       loglevel   5
       pid        5340
       telnet     telnetForBlockingFn_1643544554_127.0.0.1_56806
       timeout    86400
       abortArg:
       arg:
         name       repdb
         table      history
         hash:
   OLDREADINGS:
   READINGS:
     2022-01-30 13:17:24   state           clientSide Dump is running - be patient and see Logfile !
Attributes:
   DbLogExclude .*
   DbLogInclude DumpRowsHistory
   aggregation hour
   allowDeletion 1
   dumpDirLocal backup
   dumpMemlimit 500000000
   dumpSpeed  5000
   event-on-update-reading state,DumpRowsHistory
   group      DbLog
   room       Technik->Funktionen
   seqDoubletsVariance 0.15
   showTableInfo %history%,%current%
   timeDiffToNow d:70
   timeOlderThan d:62
   verbose    4
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 14:05:07
Sieht doch gut aus. Die SQL zeigen den Fortschritt:


2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 0,5000;
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 5000,5000;
2022.01.30 13:18:15 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 10000,5000;
2022.01.30 13:19:31 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 15000,5000;
2022.01.30 13:21:17 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 20000,5000;
2022.01.30 13:23:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 25000,5000;
2022.01.30 13:26:19 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 30000,5000;
2022.01.30 13:29:36 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 35000,5000;
2022.01.30 13:33:22 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 40000,5000;
2022.01.30 13:37:39 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 45000,5000;
2022.01.30 13:42:25 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 50000,5000;
2022.01.30 13:47:42 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 55000,5000;
2022.01.30 13:53:29 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 60000,5000;


Das Ausgabefile sollte auch entsprechend wachsen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 14:06:04
nein leider wächst das File nicht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 14:08:20
Hmm, komisch. Bei mir läufts grad parallel astrein.

Lass es erstmal laufen. Ich schau mal ob ich etwas bei der Optimierung übersehen habe.

Achso, zieh dir mal die aktuellste Entwicklungsversion wie gerade oben geschrieben. Und starte damit nochmal den Dump.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 15:52:19
Hallo Heiko,

mit der Version 93_DbRep.pm:v8.47.0-s25492/2022-01-17 habe ich leider das gleiche Problem.
Ich habe mal mit ein paar Einstellungen experimentiert, wenn ich dumpMemlimit ud dumpSpeed drastisch reduziere wird zwar das Ausgabefile geschrieben aber die Performance ist unterirdisch.
Nach 30 Minuten noch nicht mal die Hälfte der zu erwartende Größe.
Ich habe auch die Beobachtung gemacht, das die Abstände der SQL Aufrufe

SQL execute: SELECT * FROM `history` LIMIT 0,50000;

immer länger werden, von anfänglich Sekunden bis zu mehreren Minuten.

Vielleicht hilft dir das ja bei der Fehlersuche.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 15:59:21
Und wie sieht es mit der aktuellen Entwicklungsversion aus ? Wäre mir noch wichtig zu wissen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 16:05:22
Ich dachte die 93_DbRep.pm:v8.47.0-s25492/2022-01-17 wäre die aktuellen Entwicklungsversion.
Ich hatte

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

schon mal ausgeführt, scheint nicht geklappt zu haben. Werde es noch mal versuchen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 16:07:09
Ist diese:

FVERSION 93_DbRep.pm:v8.48.0-s25492/2022-01-17
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 16:29:54
jetzt läuft die Sicherung mit aktuellen Version und den folgenden Einstellungen ca 15 Minuten ohne das das Ausgabefile sich verändert hätte. Die Größe ist immer noch 39KB, die Größe der current Tabelle.

Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      5c52f431-f33f-e11d-c0b2-f1dc4dfa79b37156
   FVERSION   93_DbRep.pm:v8.48.0-s25492/2022-01-17
   LASTCMD    dumpMySQL clientSide
   MODEL      Client
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         436
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      clientSide Dump is running - be patient and see Logfile !
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.48.0
     RUNNING_BACKUP_CLIENT:
       abortFn    DbRep_DumpAborted
       bc_pid     131
       finishFn   DbRep_DumpDone
       fn         DbRep_mysql_DumpClientSide
       loglevel   5
       pid        17168
       telnet     telnetForBlockingFn_1643555196_127.0.0.1_58616
       timeout    86400
       abortArg:
       arg:
         name       repdb
         table      history
         hash:
   READINGS:
     2022-01-30 16:12:56   state           clientSide Dump is running - be patient and see Logfile !
Attributes:
   DbLogExclude .*
   DbLogInclude DumpRowsHistory
   aggregation hour
   allowDeletion 1
   dumpDirLocal backup
   dumpMemlimit 50000000
   dumpSpeed  50000
   event-on-update-reading state,DumpRowsHistory
   group      DbLog
   room       Technik->Funktionen
   seqDoubletsVariance 0.15
   showTableInfo %history%,%current%
   timeDiffToNow d:70
   timeOlderThan d:62
   verbose    4
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 16:31:55
Ich schaue mir das heute Abend mal an. Irgendwas muß ich wohl übersehen/falsch gemacht haben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 30 Januar 2022, 16:34:13
Keine Eile, die alter Version funktioniert ja gut.
Sag Bescheid wenn ich dich noch irgendwie unterstützen kann.

Gruß
Didi
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 Januar 2022, 21:46:52
Hallo Didi, @all,

ich konnte das Problem identifizieren und beseitigen.
Die weiterentwickelte Version ist eingecheckt und morgen früh im Update.
Es enthält auch weitere Changes, wie das verbesserte optizeTable.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 31 Januar 2022, 22:31:47
Morgen früh gibt es noch ein Update mit eingen kleinen Fixes bzgl. Umlauten im Backup / Restore.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Didi am 01 Februar 2022, 15:37:07
Hallo Heiko,

saubere und schnelle Arbeit. Bei mir läuft in der neue Version

93_DbRep.pm:v8.48.1-s25603/2022-01-31

der Dump wieder wie gewohnt.
Danke
Didi
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oelkanne am 05 Februar 2022, 11:44:36
Hallo,

Habe gerade begonnen mich mit DbRep zu beschäftigen, um meine Datenbank etwas zu schrumpfen.

Sachen wie:
set mylogdb_service reduceLogNbl 7:9 average INCLUDE=%:AM2301_%
set mylogdb_service reduceLogNbl 7:9 average INCLUDE=%:F_%
set mylogdb_service reduceLogNbl 7:9 average INCLUDE=%:temperature
...
funktionieren. Um die Datenbank mit einen Befehl zu shrinken wollte ich nun EXCLUDE nutzen.

set mylogdb_service reduceLogNbl 7:9 average EXCLUDE=%:desiredTemperature,%:POWER%,%:Shutter%,Shelly%:relay%,Shelly%:light%,Handy_%:pres_true,D1_mini_1:Power_Power_curr

Hier werden jedoch Readings desiredTemperature, Shutter1Position, .. nicht excludiert.
Sind bei EXCLUDE evtl. nur Wildcards im Device erlaubt und nicht im Reading?






Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Februar 2022, 11:48:38
Zitat von: oelkanne am 05 Februar 2022, 11:44:36
Hallo,

Habe gerade begonnen mich mit DbRep zu beschäftigen, um meine Datenbank etwas zu schrumpfen.

Sachen wie:
set mylogdb_service reduceLogNbl 7:9 average INCLUDE=%:AM2301_%
set mylogdb_service reduceLogNbl 7:9 average INCLUDE=%:F_%
set mylogdb_service reduceLogNbl 7:9 average INCLUDE=%:temperature
...
funktionieren. Um die Datenbank mit einen Befehl zu shrinken wollte ich nun EXCLUDE nutzen.

set mylogdb_service reduceLogNbl 7:9 average EXCLUDE=%:desiredTemperature,%:POWER%,%:Shutter%,Shelly%:relay%,Shelly%:light%,Handy_%:pres_true,D1_mini_1:Power_Power_curr

Hier werden jedoch Readings desiredTemperature, Shutter1Position, .. nicht excludiert.
Sind bei EXCLUDE evtl. nur Wildcards im Device erlaubt und nicht im Reading?
Hey,

haben die readings in der Datenbank wirklich einen ":" im Namen???

Gruß
   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oelkanne am 05 Februar 2022, 11:52:19
Hallo Christian,

Der Syntax ist doch:
reduceLog [<no>[:<nn>]] [average[=day]] [EXCLUDE=device1:reading1,device2:reading2,...] [INCLUDE=device:reading]

..also ein Doppelpunkt zwischen Device und Reading


Oder kommt evtl. DbRep nicht mit dem Unterstrich in Device und reading klar?
Device:                       Reading
MiniTiger4gang_1b    Shutter2_Position
BadEG_Steller        desiredTemperature

Gruß
Oelkanne
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Februar 2022, 12:29:28
Hallo zusammen,

Zitat
Sind bei EXCLUDE evtl. nur Wildcards im Device erlaubt und nicht im Reading?
Das ist korrekt. Im EXCLUDE sind keine Wildcards erlaubt.


Oder kommt evtl. DbRep nicht mit dem Unterstrich in Device und reading klar?

Unterstriche sind kein Problem.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oelkanne am 05 Februar 2022, 13:49:14
Hmm,
Klappt immer noch nicht.

set mylogdb_service reduceLogNbl 4:5 average EXCLUDE=%:desiredTemperature,%:Shutter1_Position,%:Shutter2_Position,D1_mini_1:Power_Power_curr

Excludiert die mit Wildcard im Device aufgeführten Readings immer noch nicht. (D1_mini_1:Power_Power_curr
passt)

Datenbankauszug von obigen:





TIMESTAMP          DEVICE                TYPE      EVENT  1      READING      VALUE   UNIT
2022-01-30 02:30:00   Karin_Thermostat         MAX      rl_av_h   desiredTemperature   19.000   \xB0C   
2022-01-30 02:30:00   Ruheraum_Thermostat      MAX      rl_av_h   desiredTemperature   14.750   \xB0C   
2022-01-30 07:30:00   Waschkueche_Steller         MAX      rl_av_h   desiredTemperature   16.000   \xB0C   
2022-01-30 07:30:00   Waschkueche_Wandthermostat   MAX      rl_av_h   desiredTemperature   16.000   \xB0C   

TIMESTAMP          DEVICE            TYPE      EVENT       READING     VALUE   UNIT
2022-01-30 07:30:00   MiniTiger4gang_1b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   52.684      
2022-01-30 07:30:00   MiniTiger4gang_2b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   53.250      
2022-01-30 10:30:00   MiniTiger4gang_3b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   52.842      
2022-01-30 17:30:00   MiniTiger4gang_1b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   46.900      
2022-01-30 17:30:00   MiniTiger4gang_2b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   48.750      
2022-01-30 17:30:00   MiniTiger4gang_3b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   45.600      
2022-01-31 07:30:00   MiniTiger4gang_1b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   54.250      
2022-01-31 07:30:00   MiniTiger4gang_2b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   54.400      
2022-01-31 10:30:00   MiniTiger4gang_3b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   54.200      
2022-01-31 18:30:00   MiniTiger4gang_1b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   45.600      
2022-01-31 18:30:00   MiniTiger4gang_2b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   46.850      
2022-01-31 18:30:00   MiniTiger4gang_3b   MQTT2_DEVICE   rl_av_h   Shutter2_Position   46.000      
2022-01-30 07:30:00   Tuya_CS02_2   MQTT2_DEVICE   rl_av_h   Shutter1_Position   51.300      
2022-01-30 07:30:00   Teepao_1   MQTT2_DEVICE   rl_av_h   Shutter1_Position   51.220      
2022-01-30 07:30:00   MiniTiger4gang_1a   MQTT2_DEVICE   rl_av_h   Shutter1_Position   52.417      
2022-01-30 07:30:00   MiniTiger4gang_3a   MQTT2_DEVICE   rl_av_h   Shutter1_Position   53.700      
2022-01-30 07:30:00   MiniTiger4gang_2a   MQTT2_DEVICE   rl_av_h   Shutter1_Position   53.750      
2022-01-30 07:30:00   Teepao_2   MQTT2_DEVICE   rl_av_h   Shutter1_Position   28.462      
2022-01-30 17:30:00   MiniTiger4gang_1a   MQTT2_DEVICE   rl_av_h   Shutter1_Position   47.280      


Wo habe ich den Gedankenfehler?

Gruß
Oelkanne
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Februar 2022, 14:07:40
Ich muß mich korrigieren.

Als erstes ist wichtig, dass wir hier mit DbRep arbeiten, nicht mit dem reduceLogNbl in DbLog !!

Wenn du reduceLog mit den Optionen in der Kommandozeile aufruft, also:


reduceLog [<no>[:<nn>]] [average[=day]] [EXCLUDE=device1:reading1,device2:reading2,...] [INCLUDE=device:reading]


dann kannst du SQL-Wildcards nur im "INCLUDE" verwenden, nicht im EXCLUDE. (steht auch so in der Hilfe zur Funktion)

Arbeitest du aber ohne diese Angaben in der Kommandozeile, also nur mit:


reduceLog [<no>[:<nn>]] [average[=day]]


und stellst die zu bearbeitenden Device/Readings über die Attribute device/reading ein, kannst du die Spezifikation entsprechend der Hilfe zu diesen Attributen verwenden.
Das hat etwas mit dem unterschiedlichen Aufbau der abgeleiten SQL-Statements zu tun.

Aber beachte, reduceLogNbl im DbLog ist zwar von der Bedienung ähnlich, aber die Funktion im DbRep bietet mehr Einstellungsmöglichkeiten. reduceLogNbl im DbLog war der Vorgänger, wird aber dort nicht mehr weiterentwickelt.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: oelkanne am 06 Februar 2022, 12:56:46
Vielen Dank für die Erklärungen. Hab' die Regeln nun soweit verstanden.

Eine "Positivliste", um festzulegen welche Daten includiert werden sollen, wie sie sich das mit dem Attr Reading realisieren lässt, gefällt mir sehr gut.

Funktioniert jetzt alles!

Viele Grüße

Oelkanne
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Februar 2022, 13:37:34
Hallo zusammen,
ich bekomme mal wieder eine meldung, wo ich nicht weiß, wo sie her kommt.
Das SQL läuft ohne Fehlermeldung direkt in der MySQL Datenbank.


2022.02.14 13:32:36.034 2: DbRep LogDBRep_PV_Forecast_SQL - DBD::mysql::st execute failed: Out of range value for column '(null)' at row 1 at ./FHEM/93_DbRep.pm line 12969.

Ich habe natürlich jetzt bereits aktualisiert, aber die Meldung bleibt.

Die Ausgabe des SQLs sieht wie folgt aus und würde dann noch mit einem INSERT in die Datenbank geschrieben.

+---------------------+--------+------------------------------+-------+
| TIMESTAMP           | DEVICE | READING                      | VALUE |
+---------------------+--------+------------------------------+-------+
| 2022-02-14 08:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.6 |
| 2022-02-14 09:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.6 |
| 2022-02-14 10:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.6 |
| 2022-02-14 11:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.2 |
| 2022-02-14 12:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.0 |
| 2022-02-14 13:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.9 |
| 2022-02-14 14:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.7 |
| 2022-02-14 15:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.6 |
| 2022-02-14 16:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.6 |
| 2022-02-14 17:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.2 |
+---------------------+--------+------------------------------+-------+
10 rows in set, 3 warnings (0.15 sec)

VG Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Februar 2022, 13:45:49
Hi CHristian,

wie sieht denn das SQL aus ?

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Februar 2022, 14:00:40
Zitat von: DS_Starter am 14 Februar 2022, 13:45:49
wie sieht denn das SQL aus ?


SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;

               INSERT INTO history
                 (TIMESTAMP,DEVICE,READING,VALUE)
                  SELECT
                    TIMESTAMP,DEVICE,READING,VALUE
                  FROM (
                    SELECT
                      DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,
                      t2.DEVICE,
                      @readingname                             AS READING,
                      cast(if(avg(t2.FACTOR) > 1.6, 1.6,
                              avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE
                    FROM (
                      SELECT * FROM (
                        SELECT
                          t1.TIMESTAMP,
                          t1.HOUR,
                          t1.DEVICE,
                          t1.READING,
                          t1.VALUE,
                          if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2)))                                    AS DIFF,
                          if(((t1.VALUE+(-1*@temp))*@corr)=0,0, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1))) AS FACTOR,
                          @diff:=t1.VALUE                                                                                        AS curr_V
                        FROM (
                          SELECT
                            h.TIMESTAMP,
                            date(h.TIMESTAMP) AS DATE,
                            hour(h.TIMESTAMP) AS HOUR,
                            h.DEVICE,
                            h.READING,
                            h.VALUE
                          FROM history AS h
                          WHERE h.DEVICE    =  @device
                            AND (h.READING  =  @reading1 OR h.READING = @reading2)
                            AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY)
                            AND h.TIMESTAMP <= CURDATE()
                            AND MINUTE(h.TIMESTAMP) = 0
                            AND h.VALUE >= 0
                          GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP
                         )t1
                       )tx
                        WHERE READING != @reading2
                          AND HOUR > 6
                     )t2
                      GROUP BY t2.HOUR,t2.DEVICE
                   )t3
                    WHERE
                      t3.VALUE != 0
                    ON DUPLICATE KEY UPDATE
                      VALUE=t3.VALUE;
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Februar 2022, 14:09:03
... Monster  ;)

Habs bei mir getestet, ohne Befund:


2022.02.14 14:03:06.594 4: DbRep Report - -------- New selection ---------
2022.02.14 14:03:06.595 4: DbRep Report - Command: sqlCmd SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;   INSERT INTO history  (TIMESTAMP,DEVICE,READING,VALUE)  SELECT  TIMESTAMP,DEVICE,READING,VALUE  FROM (  SELECT  DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,  t2.DEVICE,  @readingname AS READING,  cast(if(avg(t2.FACTOR) > 1.6, 1.6,  avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE  FROM (  SELECT * FROM (  SELECT  t1.TIMESTAMP,  t1.HOUR,  t1.DEVICE,  t1.READING,  t1.VALUE,  if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,  if(((t1.VALUE+(-1*@temp))*@corr)=0,0, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1))) AS FACTOR,  @diff:=t1.VALUE AS curr_V  FROM (  SELECT  h.TIMESTAMP,  date(h.TIMESTAMP) AS DATE,  hour(h.TIMESTAMP) AS HOUR,  h.DEVICE,  h.READING,  h.VALUE  FROM history AS h  WHERE h.DEVICE = @device  AND (h.READING = @reading1 OR h.READING = @reading2)  AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY)  AND h.TIMESTAMP <= CURDATE()  AND MINUTE(h.TIMESTAMP) = 0  AND h.VALUE >= 0  GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP  )t1  )tx  WHERE READING != @reading2  AND HOUR > 6  )t2  GROUP BY t2.HOUR,t2.DEVICE  )t3  WHERE  t3.VALUE != 0  ON DUPLICATE KEY UPDATE  VALUE=t3.VALUE;
2022.02.14 14:03:06.596 4: DbRep Report - timeDiffToNow - year: , day: 2, hour: , min: , sec:
2022.02.14 14:03:06.596 4: DbRep Report - startMonth: 1 endMonth: 1 lastleapyear: 0 baseYear: 2022 diffdaylight:0 isdaylight:0
2022.02.14 14:03:06.597 4: DbRep Report - FullDay option: 0
2022.02.14 14:03:06.597 4: DbRep Report - Time difference to current time for calculating Timestamp begin: 172801 sec
2022.02.14 14:03:06.597 4: DbRep Report - Timestamp begin human readable: 2022-02-12 14:03:05
2022.02.14 14:03:06.598 4: DbRep Report - Timestamp end human readable: 2022-02-14 14:03:06
2022.02.14 14:03:06.625 4: DbRep Report - adminCredentials successfully read from file
2022.02.14 14:03:06.627 4: DbRep Report - Database connect - user: root, UTF-8 option set: yes
2022.02.14 14:03:06.629 4: DbRep Report - Set SQL session variable: SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;
2022.02.14 14:03:06.632 4: DbRep Report - SQL execute:    INSERT INTO history  (TIMESTAMP,DEVICE,READING,VALUE)  SELECT  TIMESTAMP,DEVICE,READING,VALUE  FROM (  SELECT  DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP,  t2.DEVICE,  @readingname AS READING,  cast(if(avg(t2.FACTOR) > 1.6, 1.6,  avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE  FROM (  SELECT * FROM (  SELECT  t1.TIMESTAMP,  t1.HOUR,  t1.DEVICE,  t1.READING,  t1.VALUE,  if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF,  if(((t1.VALUE+(-1*@temp))*@corr)=0,0, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1))) AS FACTOR,  @diff:=t1.VALUE AS curr_V  FROM (  SELECT  h.TIMESTAMP,  date(h.TIMESTAMP) AS DATE,  hour(h.TIMESTAMP) AS HOUR,  h.DEVICE,  h.READING,  h.VALUE  FROM history AS h  WHERE h.DEVICE = @device  AND (h.READING = @reading1 OR h.READING = @reading2)  AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY)  AND h.TIMESTAMP <= CURDATE()  AND MINUTE(h.TIMESTAMP) = 0  AND h.VALUE >= 0  GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP  )t1  )tx  WHERE READING != @reading2  AND HOUR > 6  )t2  GROUP BY t2.HOUR,t2.DEVICE  )t3  WHERE  t3.VALUE != 0  ON DUPLICATE KEY UPDATE  VALUE=t3.VALUE;
2022.02.14 14:03:06.642 4: DbRep Report - data autocommitted
2022.02.14 14:03:06.643 3: DbRep Report - Number of entries processed in db fhemtest: 0 by INSERT
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Februar 2022, 14:49:57
Zitat von: DS_Starter am 14 Februar 2022, 14:09:03
... Monster  ;)
Wer? Ich? :-)
Ist ja mein reden, nur wo kommt die Meldung dann her?
Das läuft ja auch schon über ein Jahr so, abgesehen von der letzten Division durch Null, die ich dann abgefangen habe.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Februar 2022, 14:54:02
 :)
Gute Frage ...
Aber die Stelle ./FHEM/93_DbRep.pm line 12969 deutet darauf hin dass du sqlCmdBlocking benutzt und nicht sqlCmd. Kann das sein ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Februar 2022, 15:12:45
Zitat von: DS_Starter am 14 Februar 2022, 14:54:02
:)
Gute Frage ...
Aber die Stelle ./FHEM/93_DbRep.pm line 12969 deutet darauf hin dass du sqlCmdBlocking benutzt und nicht sqlCmd. Kann das sein ?
Ja, denn der weitere Programm Ablauf greift auf die frisch eingetragenen Daten zu.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Februar 2022, 15:22:04
Auch das hab ich gerade gestestet, auch ohne Befund. Hmm ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Februar 2022, 15:31:57
Zitat von: DS_Starter am 14 Februar 2022, 15:22:04
Auch das hab ich gerade gestestet, auch ohne Befund. Hmm ...
Hmm, wenn keine SQL Meldung kommt sehe ich auch nicht wo es harkt.
Eine Spalte (NULL) erzeuge ich zumindest nicht wissendlich.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Februar 2022, 15:40:22
Nö, kommt nichts. Hier nochmal das Log:


2022.02.14 15:21:12.949 4: DbRep Report - -------- New selection ---------
2022.02.14 15:21:12.950 4: DbRep Report - Command: sqlCmdBlocking
2022.02.14 15:21:12.950 4: DbRep Report - SQL execute: SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ; INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, if(((t1.VALUE+(-1*@temp))*@corr)=0,0, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1))) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.02.14 15:21:12.951 4: DbRep Report - Set SQL session variables: SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;
2022.02.14 15:21:12.958 4: DbRep Report - Number of entries processed in db fhemtest: 0 by INSERT


Das ist kein SQL Fehler oder sonst etwas was angemeckert wird.
Aber vielleicht ist es das Insert "INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE)". Wenn z.B. das Feld TIMESTAMP evtl. leer gesetzt werden soll, käme m.M. nach so ein Fehler oder aber du willst einen Wert setzen in einem nicht definierten Feld, also z.B. "INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) .... (2022-02-14 00:00:00,bla,blubb,40,irgendwas)"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 14 Februar 2022, 19:19:40
Zitat von: DS_Starter am 14 Februar 2022, 15:40:22
Nö, kommt nichts. Hier nochmal das Log:


2022.02.14 15:21:12.949 4: DbRep Report - -------- New selection ---------
2022.02.14 15:21:12.950 4: DbRep Report - Command: sqlCmdBlocking
2022.02.14 15:21:12.950 4: DbRep Report - SQL execute: SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ; INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, if(((t1.VALUE+(-1*@temp))*@corr)=0,0, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1))) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.02.14 15:21:12.951 4: DbRep Report - Set SQL session variables: SET @days:=30, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;
2022.02.14 15:21:12.958 4: DbRep Report - Number of entries processed in db fhemtest: 0 by INSERT


Das ist kein SQL Fehler oder sonst etwas was angemeckert wird.
Aber vielleicht ist es das Insert "INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE)". Wenn z.B. das Feld TIMESTAMP evtl. leer gesetzt werden soll, käme m.M. nach so ein Fehler oder aber du willst einen Wert setzen in einem nicht definierten Feld, also z.B. "INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) .... (2022-02-14 00:00:00,bla,blubb,40,irgendwas)"

Die Tabelle, die ins INSERT geht ist absolut sauber

+---------------------+--------+------------------------------+-------+
| TIMESTAMP           | DEVICE | READING                      | VALUE |
+---------------------+--------+------------------------------+-------+
| 2022-02-14 08:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.6 |
| 2022-02-14 09:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.6 |
| 2022-02-14 10:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.6 |
| 2022-02-14 11:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.2 |
| 2022-02-14 12:00:00 | WR_1   | Solar_Correction_Faktor_auto |   1.0 |
| 2022-02-14 13:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.9 |
| 2022-02-14 14:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.7 |
| 2022-02-14 15:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.6 |
| 2022-02-14 16:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.6 |
| 2022-02-14 17:00:00 | WR_1   | Solar_Correction_Faktor_auto |   0.2 |
+---------------------+--------+------------------------------+-------+
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Februar 2022, 09:35:50
Schau mal, ich habe hier etwas dazu gefunden: https://stackoverflow.com/questions/19121106/out-of-range-value-for-column-null-at-row-1

Sieht mir ähnlich zu deinem Fall aus.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Februar 2022, 09:42:49
Zitat von: DS_Starter am 15 Februar 2022, 09:35:50
Schau mal, ich habe hier etwas dazu gefunden: https://stackoverflow.com/questions/19121106/out-of-range-value-for-column-null-at-row-1

Sieht mir ähnlich zu deinem Fall aus.
Vielen Dank, da bin auch bereits dran.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Februar 2022, 10:49:37
Hallo Heiko,
es scheint definitiv am INSERT zu liegen, aber warum verstehe ich noch nicht.
Zum Test habe ich stufenweise die SELECTs mit DbRep sqlCmdBlocking ausgeführt und mir die Ausgaben angeschaut.
Das lief alles Fehlerfrei und auch im FHEM Log kam keine Meldung.
Erst beim INSERT kommt die Meldung im DbRep.

Noch verstehe ich es einfach nicht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Februar 2022, 10:53:18
Wir setzen in Perl/dem Modul natürlich noch die entsprechenden Perl Bibliotheken DBI/DBD für den Datenbankzugriff ein. Möglicherweise ergeben sich daraus bestimmte Abweichungen von einer Ausführung in einem normalen SQL-Client. 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 15 Februar 2022, 18:35:36
Zitat von: DS_Starter am 15 Februar 2022, 10:53:18
Wir setzen in Perl/dem Modul natürlich noch die entsprechenden Perl Bibliotheken DBI/DBD für den Datenbankzugriff ein. Möglicherweise ergeben sich daraus bestimmte Abweichungen von einer Ausführung in einem normalen SQL-Client.
Ich bin dem ganzen nun auf der Spur, auch in der Datenbank kommt diese Meldung ;-(
Da ich auf der aktuellsten MySQL Version 8.0.28 bin scheint da etwas beim INSERT rein gekommen zu sein, was ich noch nicht anders umsetzen kann.
Mal schauen, ob es bei der nächsten Version wieder weg sein wird, mit Docker ist ein Update ja sehr einfach.

Wenn ich Zeit finde kann ich auch mal einen Downgrade der DB machen, mal schauen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Adimarantis am 08 April 2022, 10:55:13
Ich bekomme bei "reduceLog" mit DBRep (und auch mit DBLog aber natürlich in einer anderen Zeile) immer folgende Fehlermeldung:
PERL WARNING: Use of uninitialized value $ku in multiplication (*) at ./FHEM/93_DbRep.pm line 9400.

Nach einem Blick in den Code vermute ich folgendes Problem:
my ($kd,$ku) = 1;
Die Intention ist wahrscheinlich dass beide Variablen auf 1 gesetzt werden. Das ist aber nicht der Fall - $ku bleibt leer.
Nach dem ersten $ku++ steht es dann auf 1, daher kommt die Warnung nur 1x pro Lauf.
Soweit ich sehe beinflusst das potentiell nur die Logausgabe und nicht die Funktion und kommt wahrscheinlich nur wenn global->stacktrace=1 gesetzt ist. Trotzdem wäre es schön wenn ich die Warnung loskriegen würde :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 April 2022, 11:12:42
Kleiner Code-Bug.
Wollte wohl


my ($kd,$ku) = (1,1);


schreiben.
Kannst du bei dir ja schonmal ändern.
Ich ziehe es bei Gelegenheit mal gerade.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Adimarantis am 11 April 2022, 08:18:06
Danke für das update. Das Problem scheint weg zu sein.
Beim Rumprobieren mit delSeqDoublets ist mir noch eine Warning aufgefallen:
PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at ./FHEM/93_DbRep.pm line 6008.
Passiert nur, wenn man eine Variance setzt. Anscheinend wird auch für nicht-numerische Werte ein Delta ermittelt. Geflaggt werden sie aber trotzdem (wahrscheinich wird vorher zusätzlich auf Gleichheit geprüft?).
Außerdem ist mir aufgefallen, dass man keine Variance von "0" setzen kann (was wahrscheinlich sinnfrei ist, weil das ja quasi der Default ist, richtig?) - sehr wohl aber eine von 0.0

Ich habe gestern auch mal ein delDoublets laufen lassen.   Erst advice, dann delete
2022.04.10 21:26:37.317 3: DbRep logdb_rep - number records identified to delete by "delDoublets adviceDelete": 1305480
2022.04.11 02:13:35.327 2: DbRep logdb_rep - DBD::mysql::st execute failed: Lost connection to MySQL server during query at ./FHEM/93_DbRep.pm line 5841.

Er hat aber wohl trotzdem einige Einträge gelöscht, da ein erneutes Advice heute morgen nur noch 488172 Einträge lieferte (dazwischen lief aber auch noch ein reduceLog).
Wobei, mir kommt gerade: Meine mySQL Database ist auf einem externen Server - evtl. war das die Zwangstrennung vom Internet. Zu dem Thema übrigens grosses Lob für dein Caching: Meine externe Datenbank war mal für mehrere Stunden ausgefallen - ich hab dabei aber keine Daten verloren.

Zuletzt noch eine Frage zu DbLog selbst: Dort kann man ja Devices und Types ausschliessen. Interessant wäre jetzt noch ein ROOM= - dann könnte ich z.B. meinen AUTOCREATE room ausschliessen in dem sich Dank rfxtrx433 massig Sensoren von Nachbarn tummeln.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 April 2022, 12:52:12
Zitat
Außerdem ist mir aufgefallen, dass man keine Variance von "0" setzen kann (was wahrscheinlich sinnfrei ist, weil das ja quasi der Default ist, richtig?) - sehr wohl aber eine von 0.0
Variance 0 ist der Standard. Deswegen macht es wenig Sinn 0 zu setzen. 0.0 geht durch weil ich die Perl Standard sub "looks_like_number" zur Prüfung verwende und die Routine 0 offensichtlich nicht als Ziffer akzeptiert. Vllt. setze ich die Eigabe 0 einfach nach 0.0 um, aber wie gesagt eigentlich Unsinn.

Zitat
DBD::mysql::st execute failed: Lost connection to MySQL server during query
Da kann das Modul nix für.  ;)

Zitat
Zuletzt noch eine Frage zu DbLog selbst: Dort kann man ja Devices und Types ausschliessen. Interessant wäre jetzt noch ein ROOM= - dann könnte ich z.B. meinen AUTOCREATE room ausschliessen in dem sich Dank rfxtrx433 massig Sensoren von Nachbarn tummeln.
Das prüfe ich mal bei Gelegenheit.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 April 2022, 17:09:15
Zitat
Zuletzt noch eine Frage zu DbLog selbst: Dort kann man ja Devices und Types ausschliessen. Interessant wäre jetzt noch ein ROOM= - dann könnte ich z.B. meinen AUTOCREATE room ausschliessen
Also das funktioniert bereits jetzt im DbLog. Das Attr excludeDevs können Devspec (http://fhemtest.myds.me:8083/fhem/docs/commandref_DE.html#devspec) angegeben werden.
Um Devices eines Raumes auszuschließen, ergänzt man das Attr zum Beispiel so:


room=Energie


room ist klein geschrieben weil es ja das Attr "room" darstellt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 06 Mai 2022, 15:55:36
Hinweis: $Id: 93_DbRep.pm 25731 2022-02-22 20:58:50Z DS_Starter $

Ich bekomme im DBRep bei manchen per "at" ausgeführten set <name> insert <Datum>,<Zeit>,<Wert> unvollstädige Einträge in der Datenbank.
Im Log (Verbose 3) steht dann Folgendes:

2022.05.05 21:31:00.007 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 966.
2022.05.05 21:31:00.007 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.05 21:31:00.008 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 967.
2022.05.05 21:31:00.008 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.05 21:31:00.009 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 968.
2022.05.05 21:31:00.009 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.05 21:31:00.009 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 969.
2022.05.05 21:31:00.010 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.05 21:31:00.011 3: DbRep DBRepPow - get initial structure information of database "fhem", remaining attempts: 3
2022.05.05 21:31:00.012 3: DbRep DBRepPow - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2022.05.05 21:31:00.106 3: DbRep DBRepPow - Index Report_Idx exists. Check ok
2022.05.05 21:31:00.122 3: DbRep DBRepPow - Initial data information retrieved - total time used: 0.0278 seconds
2022.05.05 21:31:00.140 3: DbRep DBRepPow - Connectiontest to db mysql:database=fhem;host=localhost;port=3306 successful


Das Ergebnis in der Datenbank sind leere Werte für Device, Reading, Value - nur für die Ausführung um 21:31 (05:29 ist ok und ohne Fehler)

TIMESTAMP;DEVICE;TYPE;EVENT;READING;VALUE;UNIT
2022-05-05 21:31:00;;manual;manual;;;

Korrekt kommt
TIMESTAMP;DEVICE;TYPE;EVENT;READING;VALUE;UNIT
2022-05-06 05:29:00;shelly_plug_s_df2674;manual;manual;power;0;


Ein "at" wurde erzeugt und das andere mit FHEM kopiert- die defs sehen so aus:

1)  *05:29:00 { fhem("set DBRepPow insert $today,05:29:00,0") }
2)  *21:31:00 { fhem("set DBRepPow insert $today,21:31:00,0") }


Das "at" um 05:29 führt zu korrekten Einträgen, das "at" um 21:31 zu dem Fehlern im Log und den fehlerhaften Einträgen.
Wird jedoch das "at" manuell per "set <at-name> execNow" ausgeführt landen korrekte Werte in der Datenbank.

Hat jemand eine Idee was die Ursache sein kann? Eigentlich müsste das Perlproblem doch jedesmal oder nie auftauchen!

Hier noch ein List des DBRep (Attribute Device und Reading sind gesetzt, das Reading enthält übrigens den manuellen Versuch per execNow)

Internals:
   DATABASE   fhem
   DEF        DBLogging
   FUUID      624f1c2e-f33f-a8ec-b32f-384b60f40596616e
   FVERSION   93_DbRep.pm:v8.48.2-s25731/2022-02-22
   LASTCMD    insert 2022-05-06,21:31:00,0
   MODEL      Client
   NAME       DBRepPow
   NOTIFYDEV  global,DBRepPow
   NR         492
   NTFY_ORDER 50-DBRepPow
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     DELETE,FILE,SELECT,INSERT,UPDATE
     IDRETRIES  2
     MINTS      2019-02-17 12:00:00
     PACKAGE    main
     VERSION    8.48.2
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2022-05-06 15:10:20   data_inserted   2022-05-06 21:31:00, shelly_plug_s_df2674, manual, manual, power, 0,
     2022-05-06 15:10:20   number_lines_inserted 1
     2022-05-06 15:10:20   state           done
Attributes:
   comment    set DBRep1 reduceLog average=day
   device     shelly_plug_s_df2674
   reading    power
   room       Dbase
   useAdminCredentials 0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2022, 16:49:01
Prinzipiell ist erstmal kein Fehler zu sehen und mir fehlt die Phantasie warum es nur um eine bestimmte Uhrzeit solche Probleme gibt.

Die Meldungen


2022.05.05 21:31:00.007 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 966.
2022.05.05 21:31:00.007 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.05 21:31:00.008 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 967.
2022.05.05 21:31:00.008 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.05 21:31:00.009 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 968.


deuten darauf hin dass keine Werte <Datum>,<Zeit>,<Wert> übergeben wurden, warum auch immer.

Teste doch bitte mal diese Form:


1)  *05:29:00 { CommandSet(undef, "DBRepPow insert $today,05:29:00,0") }
2)  *21:31:00 { CommandSet(undef, "DBRepPow insert $today,21:31:00,0") }

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 06 Mai 2022, 17:03:54
Ja ist nicht wirklich logisch.
Das Kommando CommandSet übernehm ich jetzt unbekannterweise einfach.

Kann man aus "eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }" ablesen, dass zumindest die Übergabe vom "at" an DBRep geklappt aht?

Ich werde mal nur das "at" um 21:31 umdefinieren.
Mal sehen was heute Abend passiert  ;D

Addon
Ich hatte es schon am 1. Mai eingebracht (https://forum.fhem.de/index.php/topic,127503.msg1220139.html#msg1220139 (https://forum.fhem.de/index.php/topic,127503.msg1220139.html#msg1220139)). Es hat komischerweise am 2. und 3. funktioniert ab 4. dann nicht mehr. Wenn ich mich recht entsinne hatte ich auch nichts mehr am FHEM angefasst.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Mai 2022, 17:14:42
Ja, sehr merkwürdig wenn es mal problemlos geht und ein anderes mal nicht.
Na schauen wir mal auf den Test...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 07 Mai 2022, 00:05:22
Zunächst mal das Fazit von heute Abend. Es hat funktioniert (alte und neue Funktion).

  • *21:31:00 { CommandSet(undef, "DBRepPow insert $today,21:31:00,0") }
  • *21:33:00 { fhem("set DBRepPow insert $today,21:33:00,0") }

Ich lass das jetzt mal ein paar Tage so laufen und beobachte die Eintagungen am Morgen und die beiden am Abend.

Doings:

6. Mai 17:10 Uhr
Änderung des "at" auf --> *21:31:00 { CommandSet(undef, "DBRepPow insert $today,21:31:00,0") }
execNow auf das geänderte "at" führt zum korrekten Ergebnis (wie die andere Definition auch)  ;)

6. Mai 17:16 Uhr
Kopie vom "at" erzeugt und die alte Definition nochmal 2 Minuten später
*21:33:00 { fhem("set DBRepPow insert $today,21:33:00,0") }
verbose 5 auf DBRep

6. Mai 23:50
Check: Datenbank korrekt befüllt
TIMESTAMP;DEVICE;TYPE;EVENT;READING;VALUE;UNIT
2022-05-06 21:33:00;shelly_plug_s_df2674;manual;manual;power;0;
2022-05-06 21:31:00;shelly_plug_s_df2674;manual;manual;power;0;

8. Mai
bisher Datenbank korrekt befüllt, keine PERL-Warnings

10. & 11. Mai
weiterhin Datenbank korrekt befüllt, keine PERL-Warnings
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Mai 2022, 10:25:47
Fazit: Problem bisher nicht wieder aufgetreten.

Alle 3 AT's liefen seit 6. Mai sauber in die Datenbank.

define SolarPower_0     at *05:29:00 { fhem("set DBRepPow insert $today,05:29:00,0") }
define SolarPower_0W    at *21:31:00 { CommandSet(undef, "DBRepPow insert $today,21:31:00,0") }
define SolarPower_0Wneu at *21:33:00 { fhem("set DBRepPow insert $today,21:33:00,0") }


Fazit: merkwürdiges Verhaten, dass es mal zu:
      PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm
kommt und mal nicht

Deutet der Log-Eintrag
      eval: my $SELF= $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }   
nicht eigentlich darauf hin, dass im Modul der Text korrekt an eval übergeben wurde?

Ich werde den Ursprungszustand wieder herstellen und beim "DBRepPow" verbose 5 stehen lassen. Wenn es wiederkommt kann man vielleicht mehr sehen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Mai 2022, 10:49:42
Zitat
Deutet der Log-Eintrag
      eval: my $SELF= $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }   
nicht eigentlich darauf hin, dass im Modul der Text korrekt an eval übergeben wurde?

Ja, das könnte man daraus ableiten. Die Warnings resultieren aus diesen Codezeilen:


          $i_device  = substr($i_device,  0, $hash->{HELPER}{DBREPCOL}{DEVICE});
          $i_reading = substr($i_reading, 0, $hash->{HELPER}{DBREPCOL}{READING});
          $i_value   = substr($i_value,   0, $hash->{HELPER}{DBREPCOL}{VALUE});
          $i_unit    = substr($i_unit,    0, $hash->{HELPER}{DBREPCOL}{UNIT});


$i_device und $i_reading werden aus den gesetzten Attributen des Devices extrahiert, $i_value und $i_unit übergeben.
Wenn unit nicht übergeben wird, wird es im Modul substituiert.
Aus irgendwelchen Gründen klappt diese Ermittlung/Übergabe bei dir in einer bestimmten Situation nicht und der Code erzeugt die Warnungen.
Mir fehlt aber nach wie vor eine Idee unter welchen Umständen es dazu kommen kann wenn im Normalfall alles so funktioniert wie vorgesehen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Mai 2022, 12:17:13
Danke Dir für das Anschauen.
Die Codezeilen hatte ich mir auch schon angesehen (leider viel zu wenig Kenntnisse in PERL) -- aber wie es dann weitergeht verstehe ich nicht wirklich.

Oder im "at" (um 21:31) waren "unsichtbare Zeichen", die sich auswirken wenn es automatisch getriggert wird und nicht bei manueller Ausführung mit "execNow".

Ich lass das jetzt mit verbose 5 mitlaufen (sind nur um die 20 Zeilen Log, 2xtäglich). Vielleicht gibt es Erkenntnisse.....

Update 12.5
FHEM Update durchgeführt... und jetzt abwarten  ;D

21:31 Uhr
na super wieder die PERL Warning - ich halte es hier schon mal fest Zusammenfassung später in einer Antwort
Die Logeinträge geben eher nichts her

2022.05.12 21:31:00.013 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 967.
2022.05.12 21:31:00.014 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ [b]fhem("set DBRepPow insert $today,21:31:00,0")[/b] }
2022.05.12 21:31:00.015 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 968.
2022.05.12 21:31:00.016 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.12 21:31:00.017 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 969.
2022.05.12 21:31:00.018 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.12 21:31:00.019 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 970.
2022.05.12 21:31:00.020 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }
2022.05.12 21:31:00.021 3: DbRep DBRepPow - get initial structure information of database "fhem", remaining attempts: 3
2022.05.12 21:31:00.023 3: DbRep DBRepPow - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2022.05.12 21:31:00.066 5: DbRep DBRepPow - start BlockingCall with PID "20285"
2022.05.12 21:31:00.114 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.12 21:31:00.127 4: DbRep DBRepPow - Oldest timestamp determined: 2019-02-17 12:00:00
2022.05.12 21:31:00.137 4: DbRep DBRepPow - Encoding of database determined: utf8
2022.05.12 21:31:00.141 3: DbRep DBRepPow - Index Report_Idx exists. Check ok
2022.05.12 21:31:00.144 4: DbRep DBRepPow - Grants determined: INSERT,SELECT,DELETE,FILE,UPDATE
2022.05.12 21:31:00.155 5: DbRep DBRepPow - getInitData finished PID "20285"
2022.05.12 21:31:00.156 3: DbRep DBRepPow - Initial data information retrieved - total time used: 0.0322 seconds
2022.05.12 21:31:00.174 3: DbRep DBRepPow - Connectiontest to db mysql:database=fhem;host=localhost;port=3306 successful
2022.05.12 21:31:00.184 4: DbRep DBRepPow - -------- New selection ---------
2022.05.12 21:31:00.185 4: DbRep DBRepPow - Command: insert 2022-05-12 21:31:00,,,,
2022.05.12 21:31:00.205 5: DbRep DBRepPow - BlockingCall with PID "20287" started
2022.05.12 21:31:00.245 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.12 21:31:00.313 5: DbRep DBRepPow -> Primary Key used in fhem.history: 1 (TIMESTAMP,DEVICE,READING)
2022.05.12 21:31:00.314 5: DbRep DBRepPow -> Primary Key used in fhem.current: 1 (DEVICE,READING)
2022.05.12 21:31:00.315 5: DbRep DBRepPow -> data to insert Timestamp: 2022-05-12 21:31:00, Device: , Type: manual, Event: manual, Reading: , Value: , Unit:
2022.05.12 21:31:00.315 4: DbRep DBRepPow - SQL prepare: INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.05.12 21:31:00.317 4: DbRep DBRepPow - begin transaction
2022.05.12 21:31:00.328 4: DbRep DBRepPow - transaction committed
2022.05.12 21:31:00.330 4: DbRep DBRepPow - Inserted into fhem.history: 2022-05-12 21:31:00, , manual, manual, , ,
2022.05.12 21:31:00.343 5: DbRep DBRepPow - BlockingCall PID "20287" finished


22:35
Ausführen "set SolarPower_0W execNow" kein Fehler   :-\

2022.05.12 22:35:05.793 4: DbRep DBRepPow - -------- New selection ---------
2022.05.12 22:35:05.794 4: DbRep DBRepPow - Command: insert 2022-05-12 21:31:00,shelly_plug_s_df2674,power,0,
2022.05.12 22:35:05.814 5: DbRep DBRepPow - BlockingCall with PID "23724" started
2022.05.12 22:35:05.855 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.12 22:35:05.929 5: DbRep DBRepPow -> Primary Key used in fhem.history: 1 (TIMESTAMP,DEVICE,READING)
2022.05.12 22:35:05.930 5: DbRep DBRepPow -> Primary Key used in fhem.current: 1 (DEVICE,READING)
2022.05.12 22:35:05.931 5: DbRep DBRepPow -> data to insert Timestamp: 2022-05-12 21:31:00, Device: shelly_plug_s_df2674, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.05.12 22:35:05.932 4: DbRep DBRepPow - SQL prepare: INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.05.12 22:35:05.934 4: DbRep DBRepPow - begin transaction
2022.05.12 22:35:05.944 4: DbRep DBRepPow - transaction committed
2022.05.12 22:35:05.945 4: DbRep DBRepPow - Inserted into fhem.history: 2022-05-12 21:31:00, shelly_plug_s_df2674, manual, manual, power, 0,
2022.05.12 22:35:05.960 5: DbRep DBRepPow - BlockingCall PID "23724" finished
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 12 Mai 2022, 16:34:47
Hallo Heiko,

bestände die Möglichkeit, das insert optional um Device/Reading zu erweitern?

Ich habe das Problem, dass meine Aktoren nur beim Schalten ein Event ausgeben. D.h. da diese nur alle paar Tage schalten habe ich dann nur ein "ON" im Plot und sehe einen Balken für den ganzen Tag, bis den Aktor wieder ausschaltet.

Ich würde gerne zeitgleich zum "ON", mit dem gleichen Timestamp ein "OFF" in die Datenbank schreiben (evtl. 1s früher).

Da es mehrere Devices betrifft, brauche ich genauso viele DbReps oder ich muss vor dem Insert die 2 Attr setzen. Dann kommt aber auch das "save config" zum tragen.

Bsp: nicht getestet:
Zitatdefine Test notify MYSENSOR_(2|3):(status(1|2|3|4)|status):on {my $t = {ReadingsTimestamp("$NAME","EVTPART0",'undef')}, my @T = split(/ /, $t), fhem("attr insertDB Device $NAME; attr insertDB Reading $EVTPART0; set insertDB insert $T[0],$T[1],off"}

Eleganter wäre so etwas:
Zitatdefine Test notify MYSENSOR_(2|3):(status(1|2|3|4)|status):on {my $t = {ReadingsTimestamp("$NAME","EVTPART0",'undef')}, my @T = split(/ /, $t), fhem("set insertDB insert $T[0],$T[1],off,$NAME,$EVTPART0"}

oder hast du noch eine andere Idee?

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Mai 2022, 20:55:26
Hallo Bernd,

ja das kann ich machen und sollte kein Problem sein.
Allerdings muss man dann als User noch ein ",," einschieben wenn man keine Einheit mitgibt.

set insertDB insert $T[0],$T[1],off,<Unit>,$NAME,$EVTPART0

also so:

set insertDB insert $T[0],$T[1],off,,$NAME,$EVTPART0

Aber das sollte kein Problem sein. Man muss dann nur daran denken.
Die Reihenfolge von dem String ist dann zwar ein bisschen komisch, aber muss halt sein um die
kompatibel zum aktuellen Statement zu sein.
Melde mich wenn ich es implementiert habe.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 12 Mai 2022, 21:21:09
Super, danke Heiko.
Hat keine Eile.

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 12 Mai 2022, 22:52:30
Zitat von: RalfRog am 11 Mai 2022, 12:17:13
......
21:31 Uhr
na super wieder die PERL Warning - ich halte es hier schon mal fest Zusammenfassung später in einer Antwort
.....

Siehe auch Antwort #1646

Nach dem FHEM Update und einem Reboot ist die Warning heute wieder aufgetreten. Bei einem execNow auf das "at" eine Stunde später nicht.  :-[
Nun habe ich einen korrekten und einen fehlerhaften (weil weitgehend leer) DB-Eintrag.
Dieser "Fehler" ist sowas von komisch.

Wenn Du eine Idee hast füge ich im Code (z.B. im Umfeld der relevaten Zeilen) gern ein paar Kommandos ein um z.B. den Inhalt von Variablen ins Log zu schreiben. Mir fehlt da dann doch Wissen.
.....und warum war das die letzen Tage weg...   :o
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Mai 2022, 23:05:51
Hallo Ralf,

schreibe in die Zeile 965:

Log3 ($name, 5, "DbRep $name - all: $prop, dev: $i_device, reading: $i_reading, value: $i_value");

(reload 93_DbRep in der Kommandozeile ausführen. Das bringt evtl. Tippfehler gleich raus.)

Mit verbose 5 wird das ausgeschrieben.
Vllt sehen wir dann mehr.

Komische Sachen machst du ...  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 14 Mai 2022, 11:27:14
Codezeile seit gestern drin und Reload gemacht.
Code im Modul Zeile 965:

964       $hash->{LASTCMD} = $prop ? "$opt $prop" : "$opt";
965 Log3 ($name, 5, "DbRep $name - all: $prop, dev: $i_device, reading: $i_reading, value: $i_value"); # Zeile zum Debuggen da einige DB Eintraege verkorkst
966       if ($dbmodel ne 'SQLITE') {                          # Daten auf maximale Länge (entsprechend der Feldlänge in DbLog) beschneiden wenn nicht SQLite
967           $i_device  = substr($i_device,  0, $hash->{HELPER}{DBREPCOL}{DEVICE});
968           $i_reading = substr($i_reading, 0, $hash->{HELPER}{DBREPCOL}{READING});
969           $i_value   = substr($i_value,   0, $hash->{HELPER}{DBREPCOL}{VALUE});
970           $i_unit    = substr($i_unit,    0, $hash->{HELPER}{DBREPCOL}{UNIT});
971       }


Ergebnis (Codezeile liefert gewünschte Ausgabe):

2022.05.13 21:31:00.010 5: DbRep DBRepPow - all: 2022-05-13,21:31:00,0, dev: shelly_plug_s_df2674, reading: power, value: 0
2022.05.13 21:31:00.024 4: DbRep DBRepPow - -------- New selection ---------
2022.05.13 21:31:00.024 4: DbRep DBRepPow - Command: insert 2022-05-13 21:31:00,shelly_plug_s_df2674,power,0,
2022.05.13 21:31:00.051 5: DbRep DBRepPow - BlockingCall with PID "12729" started
2022.05.13 21:31:00.097 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.13 21:31:00.171 5: DbRep DBRepPow -> Primary Key used in fhem.history: 1 (TIMESTAMP,DEVICE,READING)
2022.05.13 21:31:00.171 5: DbRep DBRepPow -> Primary Key used in fhem.current: 1 (DEVICE,READING)
2022.05.13 21:31:00.172 5: DbRep DBRepPow -> data to insert Timestamp: 2022-05-13 21:31:00, Device: shelly_plug_s_df2674, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.05.13 21:31:00.172 4: DbRep DBRepPow - SQL prepare: INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.05.13 21:31:00.174 4: DbRep DBRepPow - begin transaction
2022.05.13 21:31:00.180 4: DbRep DBRepPow - transaction committed
2022.05.13 21:31:00.181 4: DbRep DBRepPow - Inserted into fhem.history: 2022-05-13 21:31:00, shelly_plug_s_df2674, manual, manual, power, 0,
2022.05.13 21:31:00.191 5: DbRep DBRepPow - BlockingCall PID "12729" finished


...wie immer erstmal wieder kein PERL Error  :-X

Ich beobachte...   provoziere nochmal mit Restart FHEM und auch kompletter Reboot    ...mal sehen

Die Frage ist, ob ich gleich auf deinen Vorschlag " CommandSet(undef, "DBRepPow insert $today,05:29:00,0") " umsteige in der Hoffnung, dass die PERL Warning wegbleibt.
Andererseits ist ein soches Problem besonders in komplexeren Szenarien doof, wenn man die Datenbankeinträge ohne Inhalt zu spät bemerkt. Insofern ist es interessant die Ursache zu finden/erkennen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 15 Mai 2022, 22:46:05
Nach einem versehentlichen Shutdown gestern Abend ist es heute morgen wieder zum dem Effekt mit "leeren" Datenbankeinträgen gekommen. Heute Abend war es allerdings wieder ok.
Hier das Logfile:

2022.05.15 05:29:00.014 5: DbRep DBRepPow - all: 2022-05-15,05:29:00,0, dev: shelly_plug_s_df2674, reading: power, value: 0
2022.05.15 05:29:00.016 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 967.
2022.05.15 05:29:00.016 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,05:29:00,0") }
2022.05.15 05:29:00.017 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 968.
2022.05.15 05:29:00.018 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,05:29:00,0") }
2022.05.15 05:29:00.018 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 969.
2022.05.15 05:29:00.019 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,05:29:00,0") }
2022.05.15 05:29:00.019 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/93_DbRep.pm line 970.
2022.05.15 05:29:00.020 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,05:29:00,0") }
2022.05.15 05:29:00.021 3: DbRep DBRepPow - get initial structure information of database "fhem", remaining attempts: 3
2022.05.15 05:29:00.023 3: DbRep DBRepPow - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2022.05.15 05:29:00.059 5: DbRep DBRepPow - start BlockingCall with PID "3384"
2022.05.15 05:29:00.105 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.15 05:29:00.119 4: DbRep DBRepPow - Oldest timestamp determined: 2019-02-17 12:00:00
2022.05.15 05:29:00.131 4: DbRep DBRepPow - Encoding of database determined: utf8
2022.05.15 05:29:00.135 3: DbRep DBRepPow - Index Report_Idx exists. Check ok
2022.05.15 05:29:00.139 4: DbRep DBRepPow - Grants determined: SELECT,FILE,DELETE,INSERT,UPDATE
2022.05.15 05:29:00.152 5: DbRep DBRepPow - getInitData finished PID "3384"
2022.05.15 05:29:00.153 3: DbRep DBRepPow - Initial data information retrieved - total time used: 0.0364 seconds
2022.05.15 05:29:00.170 3: DbRep DBRepPow - Connectiontest to db mysql:database=fhem;host=localhost;port=3306 successful
2022.05.15 05:29:00.179 4: DbRep DBRepPow - -------- New selection ---------
2022.05.15 05:29:00.180 4: DbRep DBRepPow - Command: insert 2022-05-15 05:29:00,,,,
2022.05.15 05:29:00.198 5: DbRep DBRepPow - BlockingCall with PID "3386" started
2022.05.15 05:29:00.234 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.15 05:29:00.296 5: DbRep DBRepPow -> Primary Key used in fhem.history: 1 (TIMESTAMP,DEVICE,READING)
2022.05.15 05:29:00.297 5: DbRep DBRepPow -> Primary Key used in fhem.current: 1 (DEVICE,READING)
2022.05.15 05:29:00.297 5: DbRep DBRepPow -> data to insert Timestamp: 2022-05-15 05:29:00, Device: , Type: manual, Event: manual, Reading: , Value: , Unit:
2022.05.15 05:29:00.298 4: DbRep DBRepPow - SQL prepare: INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.05.15 05:29:00.299 4: DbRep DBRepPow - begin transaction
2022.05.15 05:29:00.305 4: DbRep DBRepPow - transaction committed
2022.05.15 05:29:00.307 4: DbRep DBRepPow - Inserted into fhem.history: 2022-05-15 05:29:00, , manual, manual, , ,
2022.05.15 05:29:00.318 5: DbRep DBRepPow - BlockingCall PID "3386" finished


Ich lese im ersten Logeintrag um "05:29:00.014", dass die Variablen ($prop, $i_device, $i_reading, $i_value) Werte haben die gut aussehen  ::)
Aber was geht dann in Zeile 967ff und eval schief...   und auch nur manchmal... 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Mai 2022, 23:02:43
Zitat
Ich lese im ersten Logeintrag um "05:29:00.014", dass die Variablen ($prop, $i_device, $i_reading, $i_value) Werte haben die gut aussehen  ::)
Da hast völlig Recht. Aber ich habe vllt. eine Idee. Möglicherweise sind bestimmte Hash-Werte nicht gesetzt die aus DbLog übernommen werden. Das passiert beim ersten DB-Connect. Jetzt kann es sein, dass du das Device auch für andere Operationen verwendest. Dabei werden die Hash-Werte initial übernommen. Das würde die Unregelmäßigkeit des Fehlers erklären.

Um meine Vermutung zu verifizieren ändere doch bitte mal die Logzeile in:


Log3 ($name, 5, "DbRep $name - all: $prop, dev_colsize: $hash->{HELPER}{DBREPCOL}{DEVICE}), reading_colsize: $hash->{HELPER}{DBREPCOL}{READING}, value_colsize: $hash->{HELPER}{DBREPCOL}{VALUE}");


Falls ich richtig liege weiß ich wo ich ansetzen kann um das Problem zu fixen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Mai 2022, 13:05:38
Hallo
Habe die Codezeile zusätzlich eingefügt und die vorherige noch davor stehen lassen.

964       $hash->{LASTCMD} = $prop ? "$opt $prop" : "$opt";
965 Log3 ($name, 5, "DbRep $name - all: $prop, dev: $i_device, reading: $i_reading, value: $i_value"); # 2 Zeilen zum Debuggen da einige DB Eintraege verkorkst
966 Log3 ($name, 5, "DbRep $name - all: $prop, dev_colsize: $hash->{HELPER}{DBREPCOL}{DEVICE}), reading_colsize: $hash->{HELPER}{DBREPCOL}{READING}, value_colsize: $hash->{HELPER}{DBREPCOL}{VALUE}");
967       if ($dbmodel ne 'SQLITE') {                                                                               # Daten auf maximale Länge (entsprechend der Feldl$
968           $i_device  = substr($i_device,  0, $hash->{HELPER}{DBREPCOL}{DEVICE});
969           $i_reading = substr($i_reading, 0, $hash->{HELPER}{DBREPCOL}{READING});
970           $i_value   = substr($i_value,   0, $hash->{HELPER}{DBREPCOL}{VALUE});
971           $i_unit    = substr($i_unit,    0, $hash->{HELPER}{DBREPCOL}{UNIT});
972       }


dann "reload 93_DbRep" und Test des AT über execNow. Ergebnis im Log sieht gut aus und ist parat für den Problemfall:

2022.05.16 12:40:01.212 5: DbRep DBRepPow - all: 2022-05-16,21:31:00,0, dev: shelly_plug_s_df2674, reading: power, value: 0
2022.05.16 12:40:01.213 5: DbRep DBRepPow - all: 2022-05-16,21:31:00,0, dev_colsize: 64), reading_colsize: 64, value_colsize: 128
2022.05.16 12:40:01.227 4: DbRep DBRepPow - -------- New selection ---------
2022.05.16 12:40:01.228 4: DbRep DBRepPow - Command: insert 2022-05-16 21:31:00,shelly_plug_s_df2674,power,0,
2022.05.16 12:40:01.250 5: DbRep DBRepPow - BlockingCall with PID "14960" started
2022.05.16 12:40:01.519 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.16 12:40:01.587 5: DbRep DBRepPow -> Primary Key used in fhem.history: 1 (TIMESTAMP,DEVICE,READING)
2022.05.16 12:40:01.588 5: DbRep DBRepPow -> Primary Key used in fhem.current: 1 (DEVICE,READING)
2022.05.16 12:40:01.589 5: DbRep DBRepPow -> data to insert Timestamp: 2022-05-16 21:31:00, Device: shelly_plug_s_df2674, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.05.16 12:40:01.589 4: DbRep DBRepPow - SQL prepare: INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.05.16 12:40:01.592 4: DbRep DBRepPow - begin transaction
2022.05.16 12:40:01.604 4: DbRep DBRepPow - transaction committed
2022.05.16 12:40:01.607 4: DbRep DBRepPow - Inserted into fhem.history: 2022-05-16 21:31:00, shelly_plug_s_df2674, manual, manual, power, 0,
2022.05.16 12:40:01.665 5: DbRep DBRepPow - BlockingCall PID "14960" finished


Werde jetzt einen Restart von  FHEM veranlassen um die Warning heute Abend zu provozieren.

Hinweis:
Das Device Anfang Mai für die beiden AT um 5:29 und 21:31 Uhr verwendet um per insert die "0" in die Datenbank zu schreiben.
Letzte Woche lief es ja morgens sauber und bis ich es gemerkt habe dreimal in Folge Abends falsch (zwischendurch kein Restart FHEM oder Reboot).

Habe mal die FHEM-Logs von diesem Jahr durch gegrept. Keine PERL Warnings mit "93_DbLog.pm"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Mai 2022, 15:40:22
Hallo Ralf, @all,

ich habe das insert Kommando intern umgebaut um die identifizierte potentielle Fehlerquelle zu beseitigen.
Mit der neuen Version dürfte nach meinem Ermessen dein Problemfall nicht mehr auftreten.

Weiterhin habe ich den insert Setter erweitert (siehe den Request von Bernd in #1647).
Es ist nun möglich im insert Kommando das Device, Reading direkt mitzugeben. Eventuell per Attribut device, reading gesetzte Werte werden in diesem Fall übersteuert.

insert <Datum>,<Zeit>,<Value>,[<Unit>],[<Device>],[<Reading>]
Manuelles Einfügen eines Datensatzes in die Tabelle "history". Obligatorisch sind Eingabewerte für Datum, Zeit und Value. Die Werte für die DB-Felder TYPE bzw. EVENT werden mit "manual" gefüllt.
Werden Device, Reading nicht gesetzt, werden diese Werte aus den entsprechenden Attributen device bzw. reading genommen.

Hinweis:
Nicht belegte Felder innerhalb des insert Kommandos müssen innerhalb des Strings in "," eingeschlossen werden.

    Beispiel:
    set <name> insert 2016-08-01,23:00:09,12.03,kW
    set <name> insert 2021-02-02,10:50:00,value with space
    set <name> insert 2022-05-16,10:55:00,1800,,SMA_Wechselrichter,etotal
    set <name> insert 2022-05-16,10:55:00,1800,,,etotal


Die neue Version legt zunächst in meinem contrib zum Test.
Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


LG


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Mai 2022, 22:49:04
Zitat von: DS_Starter am 16 Mai 2022, 15:40:22
.....
ich habe das insert Kommando intern umgebaut um die identifizierte potentielle Fehlerquelle zu beseitigen.

Super ich werde es ausprobieren.
Dein Vorschlag für die neue Logzeile ging leider schief. Problem Value in Concatenation. Der erste zusätzliche Logentrag läuft natürlich noch richtig.

2022.05.16 21:31:00.012 5: DbRep DBRepPow - all: 2022-05-16,21:31:00,0, dev: shelly_plug_s_df2674, reading: power, value: 0
2022.05.16 21:31:00.013 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 966.
2022.05.16 21:31:00.014 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem("set DBRepPow insert $today,21:31:00,0") }


Spielt aber keine Rolle. Neue Version wird getestet :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Mai 2022, 23:01:04
Zitat
Dein Vorschlag für die neue Logzeile ging leider schief.....
Eigentlich nicht.  ;) Da der "uninitialized value" Fehler nun bei dem Log3 Befehl auftritt bedeutet es dass die Hash Values tatsächlich nicht gesetzt sind. Wir können nun optimistisch sein dass die neue Version das Problem behebt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 17 Mai 2022, 08:57:31
Zitat von: DS_Starter am 16 Mai 2022, 23:01:04
Eigentlich nicht.  ;) Da der "uninitialized value" Fehler nun bei dem Log3 Befehl auftritt...
Auch wieder wahr  ;D

Der erste Aufruf heute morgen war sauber. Datenbank korrekt befüllt (lasse Verbose 5 weiter mitlaufen).

Mal sehen was Bernd zu berichten hat wenn er den "insert" verwendet.

Danke tolle Arbeit.

Der Vollständigkeit halber hie noch der Log:

2022.05.17 05:29:00.012 3: DbRep DBRepPow - get initial structure information of database "fhem", remaining attempts: 3
2022.05.17 05:29:00.014 3: DbRep DBRepPow - Connectiontest to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2022.05.17 05:29:00.055 5: DbRep DBRepPow - start BlockingCall with PID "11671"
2022.05.17 05:29:00.098 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.17 05:29:00.112 4: DbRep DBRepPow - Oldest timestamp determined: 2019-02-17 12:00:00
2022.05.17 05:29:00.122 4: DbRep DBRepPow - Encoding of database determined: utf8
2022.05.17 05:29:00.126 3: DbRep DBRepPow - Index Report_Idx exists. Check ok
2022.05.17 05:29:00.131 4: DbRep DBRepPow - Grants determined: DELETE,UPDATE,INSERT,SELECT,FILE
2022.05.17 05:29:00.143 5: DbRep DBRepPow - getInitData finished PID "11671"
2022.05.17 05:29:00.144 3: DbRep DBRepPow - Initial data information retrieved - total time used: 0.0343 seconds
2022.05.17 05:29:00.164 3: DbRep DBRepPow - Connectiontest to db mysql:database=fhem;host=localhost;port=3306 successful
2022.05.17 05:29:00.173 4: DbRep DBRepPow - -------- New selection ---------
2022.05.17 05:29:00.174 4: DbRep DBRepPow - Command: insert 2022-05-17 05:29:00,shelly_plug_s_df2674,power,0,
2022.05.17 05:29:00.194 5: DbRep DBRepPow - BlockingCall with PID "11673" started
2022.05.17 05:29:00.228 4: DbRep DBRepPow - Database connect - user: fhemuser, UTF-8 option set: yes
2022.05.17 05:29:00.286 5: DbRep DBRepPow -> Primary Key used in fhem.history: 1 (TIMESTAMP,DEVICE,READING)
2022.05.17 05:29:00.286 5: DbRep DBRepPow -> Primary Key used in fhem.current: 1 (DEVICE,READING)
2022.05.17 05:29:00.287 5: DbRep DBRepPow -> data to insert Timestamp: 2022-05-17 05:29:00, Device: shelly_plug_s_df2674, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.05.17 05:29:00.288 4: DbRep DBRepPow - SQL prepare: INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.05.17 05:29:00.289 4: DbRep DBRepPow - begin transaction
2022.05.17 05:29:00.296 4: DbRep DBRepPow - transaction committed
2022.05.17 05:29:00.297 4: DbRep DBRepPow - Inserted into fhem.history: 2022-05-17 05:29:00, shelly_plug_s_df2674, manual, manual, power, 0,
2022.05.17 05:29:00.308 5: DbRep DBRepPow - BlockingCall PID "11673" finished
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Mai 2022, 09:39:56
Danke Ralf für die Info. Sieht ja schon gut aus  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 17 Mai 2022, 12:22:08
Zitat von: RalfRog am 17 Mai 2022, 08:57:31

Mal sehen was Bernd zu berichten hat wenn er den "insert" verwendet.

Ich habe momentan wenig Zeit. Mal schauen ob ich diese Woche wenigstens alles einrichten kann...

@Heiko danke für die schnelle Umsetzung  :)

Melde mich wenn ich erste Ergebnisse habe...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Mai 2022, 12:50:36
@Bernd, solltest du bis Donnerstag Abend Ergebnisse haben, kann ich die neue Modulversion noch vor meinem Urlaub einchecken und per Update zur Verfügung stellen.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 17 Mai 2022, 17:14:16
Zitat von: DS_Starter am 17 Mai 2022, 12:50:36
@Bernd, solltest du bis Donnerstag Abend Ergebnisse haben, kann ich die neue Modulversion noch vor meinem Urlaub einchecken und per Update zur Verfügung stellen.

LG

Da du mich so lieb darum gebeten hast, habe ich gleich getestet.  ;)
Spaß, bin ungeplant früher nach Hause gekommen...

Funktioniert wie erwartet...ich musste nur mein Notify etwas überarbeiten -> $EVTPART letztes Zeichen entfernen (status:)

Erste Zeile stammt von insert.
setstate fetchROWs 2022-05-17 16:46:00 2022-05-17_16-43-47__1__MYSENSOR_3__status4 off
setstate fetchROWs 2022-05-17 16:46:00 2022-05-17_16-43-47__1__MYSENSOR_3__status4_1 on




Zur Vollständigkeit (mit Debugausgabe):
defmod n_MYSENSOR_Plot notify MYSENSOR_(2|3):(status(1|2|3|4)|status):.on {my $e = chop($EVTPART0);; my $t = ReadingsTimestamp($NAME,$EVTPART0,'undef');; my @T = split(/ /, $t);; Log3 ('n_MYSENSOR_Plot', 1, "$NAME, $EVTPART0, $e, $t, $T[0], $T[1]");; fhem("set insertDB insert $T[0],$T[1],off,,$NAME,$EVTPART0")}


und die insertDB:
defmod insertDB DbRep logdb
attr insertDB allowDeletion 1
attr insertDB fastStart 1
attr insertDB room System->DbLog
attr insertDB showproctime 1
attr insertDB verbose 1



PS: Fhem upgedatet, also direkt nach einem Neustart getestet...

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Mai 2022, 20:34:39
Prima Bernd.  :D

Ich habe die neue Version eingescheckt und ist ab morgen früh im Update enthalten.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 18 Mai 2022, 19:41:39
Nochmal als Rückmeldung:
Heute 2x geschaltet, funktioniert einwandfrei.

Danke Heiko, für deinen super Support.

LG
Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 23 Mai 2022, 15:48:25
Zitat von: DS_Starter am 17 Mai 2022, 09:39:56
Danke Ralf für die Info. Sieht ja schon gut aus  :)

Bisher immer noch alles (insert) sauber :)

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 26 Mai 2022, 16:07:58
Hallo Heiko,

gibt es eigentlich eine Möglichkeit Werte aus der DB in ein Reading zu schreiben?
Hintergrund ist mein Problem mit dem Statistics Device, dieses hat irgendwie Probeme mit "temperature", da ich aber die Höchsttemperatur und Durchschnittstemperatur für meine Bewässerung benötige, wäre die Frage ob ich diese Werte (die in der DB eh jeden Tag erzeugt werden) für die Bewässerung heranziehen kann.

Gruß
Alex
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 26 Mai 2022, 17:02:17
Ja, z.B. mit maxValue, minValue oder averageValue.

Ein
set dbrep minValue display reicht.

Dann mit Attribut autoForward das Ziel definieren und den Zeitraum für die Datenermittlung eingrenzen.
z.B. {
  ".*MAX.*" => "KS300 => MAXTemp", 
  ".*MIN.*" => "KS300 => MINTemp",
}


Ansonsten einfach Mal die Comref lesen...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Nighthawk am 26 Mai 2022, 20:11:50
Hammer, genau was ich brauche, danke!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 03 Juni 2022, 10:15:47
Funktion Attribut userExitFn

Hallo Heiko
Irgendwann nach einem Update so Anfang März hat meine userExitFn-Funtion"db_File_Cleanup" nicht mehr funktioniert  :-[ (scheint nicht mehr aufgerufen zu werden)
Hat sich seit Ende letzten Jahres/Anfang diesen Jahres hier etwas beim Aufruf geändert?

Lt. Commandref muss jetzt der RegEx matchen.

  • Heisst das, dass "userExitFn db_File_Cleanup state:done" nur exakt dannn aufgerufen wird wenn im DBRep der "state = state:done" ist?
=> Somit könnte ich den Aufruf per "userExitFn db_File_Cleanup state:.*" erzwingen und das Reading in der Funktion (Variablen $reading, $value) auswerten. Wie in der Hilfe auch beschrieben:

sub UserFunction {
  my $name    = shift;             # der Name des DbRep-Devices
  my $reading = shift;             # der Namen des erstellen Readings
  my $value   = shift;             # der Wert des Readings
  my $hash    = $defs{$name};


Was das "my $hash = $defs{$name}" macht muss ich in der Hash-Variablen bei Perl nochmal nachlesen  ::) - ist aber vermutlich im Detail nur dann wichtig wenn man die Werte verwenden will.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Juni 2022, 10:35:32
Hallo Ralf,

Zitat
Hat sich seit Ende letzten Jahres/Anfang diesen Jahres hier etwas beim Aufruf geändert?
Seit Dezember letzten Jahres man direkt Code zur Ausführung bringen indem er in {..} eingeschlossen wird wie im Fall 2 der ComRef beschrieben.

Zitat
Lt. Commandref muss jetzt der RegEx matchen.

    Heisst das, dass "userExitFn db_File_Cleanup state:done" nur exakt dannn aufgerufen wird wenn im DBRep der "state = state:done" ist?
Das war schon immer so, sofern man etwas angibt. D.h. mit

userExitFn db_File_Cleanup    (wäre identisch mit "db_File_Cleanup .*:.*")

wird db_File_Cleanup für jeden Einzelwert aufgerufen/durchlaufen, wogegen mit

userExitFn db_File_Cleanup state:done

db_File_Cleanup nur aufgerufen für das Reading "state" sofern dessen Wert "done" ist.

Zitat
Was das "my $hash = $defs{$name}" macht muss ich in der Hash-Variablen bei Perl nochmal nachlesen  ::) - ist aber vermutlich im Detail nur dann wichtig wenn man die Werte verwenden will.
Das ist richtig. Brauchst du nur wenn wenn man auf den $hash des DbRep-Devices ($name) zugreifen will/muss.

Um zu prüfen ob deine sub aufgerufen wird kannst du dir einfach ein Log einbauen:

Log3 $name, 1, "UserExitFn $name called - transfer parameter are Reading: $reading, Value: $value " ;

Zitat
Somit könnte ich den Aufruf per "userExitFn db_File_Cleanup state:.*" erzwingen ...
"erzwingen" ist hier das falsche Wort ! Erzwingen kannst du nichts, nur filtern sozusagen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 03 Juni 2022, 13:41:35
Danke für die Erläuterung.  :)

Zitat
Zitat
    Lt. Commandref muss jetzt der RegEx matchen.
    Heisst das, dass "userExitFn db_File_Cleanup state:done" nur exakt dannn aufgerufen wird wenn im DBRep der "state = state:done" ist?

Das war schon immer so, sofern man etwas angibt. D.h. mit


Möglicherweise habe ich den Aufruf selbst (vermeintliche Codeoptimierung) geändert und der Nichtaufruf ist mir zu spät aufgefallen - und die Änderung zwischenzeitlich vergessen.

P.S.
bisher läuft das Thema "set <name> insert" ohne Auffälligkeiten. Auch dafür vielen Dank.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 03 Juni 2022, 13:56:25
Oh muss doch noch mal nachhaken. Wird die in "userExitFn" definierte Routine während des Abarbeitung der DBRep mehrfach aufgeufen. In meinem Fall nun bei den beiden Statusänderungen running und done?

Attribut in der DBRep:  userExitFn   db_File_Cleanup state:.*

Log mit zweimaligem Aufruf (für den Test lasse ich nur ins Log schreiben und tue nix, also direkt ein return im Code nach dem Logeintrag):

2022.06.03 13:44:23.233 1: UserExitFn DBRep_BackupWoche called - mit transfer-Parameter Reading: state, Value: running
2022.06.03 13:44:23.234 3: Aufruf checken, wenns klappt weiter an der Funktion sub db_File_Cleanup arbeiten
2022.06.03 13:44:24.047 3: DbRep DBRep_BackupWoche - Number of exported datasets from fhem to file /opt/fhem/backup/db_back/week/fhem_history_since-prev-week_2022-22_5.csv: 4325
2022.06.03 13:44:24.061 1: UserExitFn DBRep_BackupWoche called - mit transfer-Parameter Reading: state, Value: done
2022.06.03 13:44:24.061 3: Aufruf checken, wenns klappt weiter an der Funktion sub db_File_Cleanup arbeiten


Das Verhalten sieht natürlich unzweifelhaft so aus  ;D. Den Mehrfachaufruf also ggfs. auch 5mal fangs ich dann ab.
Ich hatte es so verstanden das UserExitFn einmal am Ende aufgerufen wird.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Juni 2022, 14:06:22
Zitat
Wird die in "userExitFn" definierte Routine während des Abarbeitung der DBRep mehrfach aufgeufen. In meinem Fall nun bei den beiden Statusänderungen running und done?
Es wird für jedes erstellte/aktualisierte Reading das Argument im Attribut userExitFn aufgerufen bzw. vorher geprüft ob eine angegebene Regex-Bedingung erfüllt ist.
Wenn ja, wird die Routine aufgerufen.

Wird ein Aktion gestartet, aktualisiert sich i.A. nur das "state" und wird an die sub weitergreicht. Ist der DbRep-Lauf fertig wird der Vorgang für jedes erstellte Reading/Value-Paar durchgeführt und man kann als User entsprechend auswerten.

Hast also richtig beobachtet.  8)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 03 Juni 2022, 23:26:39
Danke für die Unterstützung.
Scheint zu klappen - zumindest per execNow im at.
Heute Nacht läuft das reguläre Backup somit vermutlich auch  ;) - für das Monatsbackup muss ich dann noch bis Ultimo warten...

Da sieht man wie leicht man sich selber auf den Holzweg befördert  ::)

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: juniormajor am 08 Juni 2022, 12:19:38
Hi in die Runde,

in meiner Testumgebung versuche ich gerade der Funktion "reduceLog" einen Filter mitzugeben.
Lt. Doku sollte auch TYPE= ein valider Filter sein, jedoch schaffe ich es nicht, dass dieser auch berücksichtigt wird.

Config der DbRep:
Internals:
   DATABASE   sensors
   DEF        logdb
   FUUID      619363ed-f33f-22db-c36e-9f029177fb49c324
   FVERSION   93_DbRep.pm:v8.49.0-s26054/2022-05-17
   LASTCMD    initial database connect stopped due to attribute 'fastStart'
   MODEL      Client
   NAME       logdbRep
   NOTIFYDEV  global,logdbRep
   NR         15
   NTFY_ORDER 50-logdbRep
   ROLE       Client
   STATE      initialized
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.49.0
   OLDREADINGS:
   READINGS:
     2022-06-08 11:59:31   background_processing_time 0.00
     2022-06-08 11:59:31   reduceLogState  reduceLog finished. Rows processed: 0, deleted: 0, updated: 0
     2022-06-08 12:05:27   state           initialized
Attributes:
   device     TYPE=SSCam
   timeOlderThan d:120
   verbose    5


Hier das Log wo nirgends in der WHERE Klausel der TYPE auftaucht:
2022.06.08 12:01:13 4: DbRep logdbRep - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history where  ( DEVICE = '^^' ) AND TIMESTAMP >= '2021-11-15 00:00:00' AND TIMESTAMP <= '2022-02-09 00:59:59' ORDER BY TIMESTAMP ASC;


Hat jemand eine Idee wo mein Fehler liegen kann?

Danke
Grüße Bernhard
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Juni 2022, 13:27:36
Hallo Bernhard,

Zitat
Hier das Log wo nirgends in der WHERE Klausel der TYPE auftaucht:
Wird auch nicht auftauchen weil TYPE ein FHEM Schlüssel ist mit dem die DB nichts anfangen kann.
TYPE ist ein FHEM devspec (http://fhem.de/commandref_DE.html#devspec) und wird durch FHEM aufgelöst bzw. übergibt die identifizierten Devices an die Datenbank.

Wenn TYPE aufgelöst werden kann, würde im Statement auftauchen ".... where  ( DEVICE in  <devs> ) .." wobei <devs> die durch FHEM aufgelösten devices sind.

Was ist denn die Ausgabe von


list TYPE=SSCam


in der Browser Kommandozeile ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: juniormajor am 08 Juni 2022, 18:29:51
Hallo Heiko,

danke für Info - da bin ich dann auf dem Holzweg unterwegs gewesen. Damit erübrigt sich aber auch meine weitere Frage,
da es mir auch darum ging, dass DbRep im Zuge eines reduceLogs auch "fremde" (also nicht in FHEM bekannte) Geräte bzw. deren Datensätze berücksichtigt.

lG,
Bernhard
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Juni 2022, 18:46:19
Zitat
Damit erübrigt sich aber auch meine weitere Frage,
da es mir auch darum ging, dass DbRep im Zuge eines reduceLogs auch "fremde" (also nicht in FHEM bekannte) Geräte bzw. deren Datensätze berücksichtigt.
Das geht schon, nur mußt du dann diese Geräte im Attr devices explizit benennen weil FHEM sie nicht ausflösen kann.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 22 Juni 2022, 15:09:22
Link zum Beitrag: https://forum.fhem.de/index.php/topic,53584.msg1191355.html#msg1191355 (https://forum.fhem.de/index.php/topic,53584.msg1191355.html#msg1191355)

Zitat von: DS_Starter am 05 Dezember 2021, 21:12:32
Beitrag #1535

Offen ist noch, dass bei average die letzte Stunde nicht auf den Halbstundenwert reduziert wird und bei average=day der letzte
Tag nicht auf den 12:00 Wert reduziert wird. Aber da bin ich dran
--------------------------------------------------------------------
Beitrag #1536

Ist nun auch erledigt und die Version ins contrib geladen.

LG

Ich weiss nicht mehr wie intensiv ich mir das damals angeschaut habe....  mir ist jetzt bei der Suche nach einem Eintag aufgefallen, dass die letzte Stunde nicht stimmt.
Ich schau am Freutag nochmal rein (bin zwar in Holland müsste aber klappen).
Aktuell hier das Ergebnis des Laufs vom vergangenen Freitag - es sieht aus als würde der average berechnet und nur die Einträge nicht gelöscht.


TIMESTAMP             DEVICE       TYPE    EVENT         READING VALUE  UNIT
2022-06-07  20:30:00  shelly_plug  SHELLY  rl_av_h       power   0.890
2022-06-07  20:26:22  shelly_plug  SHELLY  power: 0      power   0
2022-06-07  20:21:22  shelly_plug  SHELLY  power: 0.34   power   0.34
2022-06-07  20:17:09  shelly_plug  SHELLY  power: 0.55   power   0.55
2022-06-07  20:12:09  shelly_plug  SHELLY  power: 0.63   power   0.63
2022-06-07  20:07:04  shelly_plug  SHELLY  power: 1.47   power   1.47
2022-06-07  19:30:00  shelly_plug  SHELLY  rl_av_h       power  12.223
2022-06-07  18:30:00  shelly_plug  SHELLY  rl_av_h       power  13.427


Da ich wöchentlich mit einem Tag Uberlappung arbeite, wird es beim neuen Lauf korrigiert. Der mögliche Berechnungsfehler spielt bei mir auch keine Rolle, da es historisch nur um die Größenordnung geht.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 25 Juni 2022, 19:58:10
Heute Nacht wurde bei der Bereinigung die letzte Stunde nicht auf den Halbstundenwert reduziert und die regulären Datenbankeinträge sind noch da.


2022-06-14 21:31:00 shelly_plug_s_df2674 manual manual power 0
2022-06-14 21:14:31 shelly_plug_s_df2674 SHELLY power: 0 power 0
2022-06-14 21:12:15 shelly_plug_s_df2674 SHELLY power: 0.5 power 0.5
2022-06-14 21:07:15 shelly_plug_s_df2674 SHELLY power: 0.91 power 0.91
2022-06-14 21:04:23 shelly_plug_s_df2674 SHELLY power: 1.08 power 1.08
2022-06-14 21:02:15 shelly_plug_s_df2674 SHELLY power: 1.04 power 1.04
2022-06-14 20:30:00 shelly_plug_s_df2674 SHELLY rl_av_h power 2.816
2022-06-14 19:30:00 shelly_plug_s_df2674 SHELLY rl_av_h power 5.472


Es liegt doch nicht an dem "manual" Eintrag, den ich 21.31 und 5.31 Uhr setze um die Kurve auf Null zu bringen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2022, 12:30:38
Kannst du nochmal genau schreiben wie du den Befehl (mit / ohne Optionen im Befehl) aufrufst ?
Und am Besten ein List vom Device noch dazu. Ich muß versuchen es bei mir nachzustellen. Vllt. habe ich dann noch eine Idee.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 02 Juli 2022, 21:09:58
Zunächst das fragliche Rep-Device (DBRep_reduPower):

Internals:
   DATABASE   fhem
   DEF        DBLogging
   FUUID      60a6d173-f33f-a8ec-3be0-2e7e866eb54ed451
   FVERSION   93_DbRep.pm:v8.49.0-s25939/2022-04-09
   LASTCMD    reduceLog average
   MODEL      Client
   NAME       DBRep_reduPower
   NOTIFYDEV  global,DBRep_reduPower
   NR         486
   NTFY_ORDER 50-DBRep_reduPower
   ROLE       Client
   STATE      reduceLog of fhem finished
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     UPDATE,FILE,DELETE,INSERT,SELECT
     IDRETRIES  2
     MINTS      2019-02-17 12:00:00
     PACKAGE    main
     VERSION    8.49.0
     CV:
       aggregation no
       aggsec     1
       destr      2022-06-21
       dsstr      2022-06-14
       epoch_seconds_end 1655848799
       mestr      06
       msstr      06
       testr      23:59:59
       tsstr      00:00:00
       wdadd      518400
       yestr      2022
       ysstr      2022
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2022-07-01 23:45:03   background_processing_time 3.40
     2022-07-01 23:45:03   reduceLogState  reduceLog finished. Rows processed: 1807, deleted: 1664, updated: 115
     2022-07-01 23:45:03   state           reduceLog of fhem finished
Attributes:
   device     shelly.*
   executeAfterProc msg push -1 [DBRep_reduPower:state] fuer shelly:power
   executeBeforeProc set DBLogging reopen 300
   reading    power
   room       Dbase
   timeDiffToNow d:17 FullDay
   timeOlderThan d:10 FullDay
   useAdminCredentials 0


Der Aufruf geschieht über ein AT am Freitag (das AT startet zusätzlich am Donnerstag ein ReduceLog mit DBRep_reduEnergy, hier nicht betrachtet)

Internals:
   COMMAND    { fhem ("msg push -1 Start reduceDBlog") ;
   if ($wday == 5) { fhem ("set DBRep_reduPower reduceLog average") }
elsif ($wday == 4) { fhem ("set DBRep_reduEnergy reduceLog") } }
   DEF        *23:45 { fhem ("msg push -1 Start reduceDBlog") ;
   if ($wday == 5) { fhem ("set DBRep_reduPower reduceLog average") }
elsif ($wday == 4) { fhem ("set DBRep_reduEnergy reduceLog") } }
   FUUID      60a6f4e0-f33f-a8ec-dc2e-bc1116a48f93ad37
   FVERSION   90_at.pm:0.252480/2021-11-21
   NAME       ReduceDB_weekly
   NR         488
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 23:45:00
   TIMESPEC   23:45
   TRIGGERTIME 1656798300
   TRIGGERTIME_FMT 2022-07-02 23:45:00
   TYPE       at
   READINGS:
     2022-07-01 23:45:00   state           Next: 23:45:00
Attributes:
   comment    Donnerstag und Freitag Datenbank für Shelly um 23:45 reduzieren (mit Device DBRep_reduEnergy und DBRep_reduPower)
   room       Dbase


Das Ergebnis in der Datenbank gestern - alles gut bis auf die letzte Stunde. Hier mal mit etwas mehr Daten um den Zeitpunkt herum.
Was zusätzlich auffällt ist, dass diesmal wieder um 20:30 eine Average Wert dabei  ist ohne die anderen Einträge zu löschen. Nicht immer ist dieser Wert da. Wovon das abhängt ist mir nicht ersichtlich. Vermutlich aber ein sekundäres (oder Folge-) Problem.

TIMESTAMP;DEVICE;TYPE;EVENT;READING;VALUE;UNIT
2022-06-22 06:19:00;shelly_plug_s_df2674; SHELLY; power: 3.53; power; 3.53;
2022-06-22 06:14:00;shelly_plug_s_df2674; SHELLY; power: 3.44; power; 3.44;
2022-06-22 06:09:00;shelly_plug_s_df2674; SHELLY; power: 3.51; power; 3.51;
2022-06-22 06:04:00;shelly_plug_s_df2674; SHELLY; power: 3.2;  power; 3.2;
2022-06-22 06:00:45;shelly_plug_s_df2674; SHELLY; power: 2.59; power; 2.59;
2022-06-22 05:55:44;shelly_plug_s_df2674; SHELLY; power: 1.87; power; 1.87;
2022-06-22 05:50:44;shelly_plug_s_df2674; SHELLY; power: 1.43; power; 1.43;
2022-06-22 05:45:44;shelly_plug_s_df2674; SHELLY; power: 1.03; power; 1.03;
2022-06-22 05:43:37;shelly_plug_s_df2674; SHELLY; power: 0.87; power; 0.87;
2022-06-22 05:39:55;shelly_plug_s_df2674; SHELLY; power: 0.57; power; 0.57;
2022-06-22 05:29:00;shelly_plug_s_df2674; manual; manual;      power; 0;
2022-06-21 21:31:00;shelly_plug_s_df2674; manual; manual;      power; 0;
2022-06-21 20:49:07;shelly_plug_s_df2674; SHELLY; power: 0;    power; 0;
2022-06-21 20:44:58;shelly_plug_s_df2674; SHELLY; power: 1.2;  power; 1.2;
2022-06-21 20:39:58;shelly_plug_s_df2674; SHELLY; power: 2.57; power; 2.57;
2022-06-21 20:34:58;shelly_plug_s_df2674; SHELLY; power: 2.49; power; 2.49;
2022-06-21 20:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 1.605;
2022-06-21 20:29:58;shelly_plug_s_df2674; SHELLY; power: 2.12; power; 2.12;
2022-06-21 20:26:20;shelly_plug_s_df2674; SHELLY; power: 1.48; power; 1.48;
2022-06-21 20:21:20;shelly_plug_s_df2674; SHELLY; power: 1.41; power; 1.41;
2022-06-21 20:16:20;shelly_plug_s_df2674; SHELLY; power: 0.97; power; 0.97;
2022-06-21 20:09:40;shelly_plug_s_df2674; SHELLY; power: 1.68; power; 1.68;
2022-06-21 19:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 8.699;
2022-06-21 18:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 22.230;
2022-06-21 17:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 40.975;
2022-06-21 16:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 81.578;
2022-06-21 15:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 109.965;
2022-06-21 14:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 171.117;
2022-06-21 13:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 133.009;


Sowie der entsprechenden Bereich aus dem Logfile. Leider nur Verbose 3.
Am 14. sieht man schön, dass die 5 verbaselten Einträge von letzter Woche bereinigt wurden (damit ist die Vorwoche dann glatt).

2022.07.01 23:45:00.106 3: DbRep DBRep_reduPower - ################################################################
2022.07.01 23:45:00.107 3: DbRep DBRep_reduPower - ###                    new reduceLog run                     ###
2022.07.01 23:45:00.107 3: DbRep DBRep_reduPower - ################################################################
2022.07.01 23:45:00.139 3: DbRep DBRep_reduPower - execute command before reduceLog: 'set DBLogging reopen 300'
2022.07.01 23:45:00.145 2: DbLog DBLogging: Connection closed until 23:50:00 (300 seconds).
2022.07.01 23:45:00.289 3: DbRep DBRep_reduPower - reduce data older than: 2022-06-22 00:59:59 (logical corrected), newer than: 2022-06-14 00:00:00
2022.07.01 23:45:00.290 3: DbRep DBRep_reduPower - reduceLog requested with options:
AVERAGE=HOUR
INCLUDE -> Devs: shelly_plug_s_df2674 Readings: power
2022.07.01 23:45:00.460 3: DbRep DBRep_reduPower - reduceLog deleting 5 records of day: 2022-06-14
2022.07.01 23:45:00.476 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 1 records of day: 2022-06-14
2022.07.01 23:45:00.517 3: DbRep DBRep_reduPower - reduceLog deleting 190 records of day: 2022-06-15
2022.07.01 23:45:00.679 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-15 is: 100
2022.07.01 23:45:00.814 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 17 records of day: 2022-06-15
2022.07.01 23:45:00.892 3: DbRep DBRep_reduPower - reduceLog deleting 193 records of day: 2022-06-16
2022.07.01 23:45:01.042 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-16 is: 100
2022.07.01 23:45:01.178 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 17 records of day: 2022-06-16
2022.07.01 23:45:01.277 3: DbRep DBRep_reduPower - reduceLog deleting 265 records of day: 2022-06-17
2022.07.01 23:45:01.409 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-17 is: 100
2022.07.01 23:45:01.587 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-17 is: 200
2022.07.01 23:45:01.694 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 17 records of day: 2022-06-17
2022.07.01 23:45:01.774 3: DbRep DBRep_reduPower - reduceLog deleting 169 records of day: 2022-06-18
2022.07.01 23:45:01.934 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-18 is: 100
2022.07.01 23:45:02.041 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 16 records of day: 2022-06-18
2022.07.01 23:45:02.131 3: DbRep DBRep_reduPower - reduceLog deleting 297 records of day: 2022-06-19
2022.07.01 23:45:02.274 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-19 is: 100
2022.07.01 23:45:02.416 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-19 is: 200
2022.07.01 23:45:02.581 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 16 records of day: 2022-06-19
2022.07.01 23:45:02.681 3: DbRep DBRep_reduPower - reduceLog deleting 264 records of day: 2022-06-20
2022.07.01 23:45:02.823 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-20 is: 100
2022.07.01 23:45:02.967 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-20 is: 200
2022.07.01 23:45:03.071 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 15 records of day: 2022-06-20
2022.07.01 23:45:03.161 3: DbRep DBRep_reduPower - reduceLog deleting 281 records of day: 2022-06-21
2022.07.01 23:45:03.303 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-21 is: 100
2022.07.01 23:45:03.439 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-21 is: 200
2022.07.01 23:45:03.564 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 16 records of day: 2022-06-21
2022.07.01 23:45:03.628 3: DbRep DBRep_reduPower - reduceLog finished. Rows processed: 1807, deleted: 1664, updated: 115
2022.07.01 23:45:03.698 3: msg globalMsg: ID=1656711903.6422.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='reduceLog database is running - be patient and see Logfile ! fuer shelly:power'


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 August 2022, 09:53:50
Hallo Ralf, @all,

ich habe die reduceLog Funktion komplett überarbeitet und dabei deine Kritikpunkte berücksichtigt und auch beseitigt.
Die Überarbeitung habe ich auch unter dem Aspekt einer kommenden Funktionserweiterung von reduceLog vorgenommen, die in diesem Thread (https://forum.fhem.de/index.php/topic,128605.0.html) andiskutiert wurde.

In der neuen Version wird auch das Attr numDecimalPlaces zur Festlegung der Nachkommastellen der average-Ergebnisse berücksichtigt.
Die neue Version liegt zunächst im contrib zum Test bereit.Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 August 2022, 16:27:36
Oh, danke.

Werde mir den Thread mal zu Gemüte führen und dann updaten.
Dauert nur ne Weile bis ich die Ergebnisse dann auch in der DB sehe.
Ich berichte!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 August 2022, 17:37:19
Ich habe jetzt noch die Möglichkeit eingebaut reduceLog mit den Optionen
   
    max

bzw.

   max=day

aufzurufen.

Die Commandref habe ich im Deutschen schon angepasst:

reduceLog [<no>[:<nn>]] [mode] [EXCLUDE=device1:reading1,device2:reading2,...] [INCLUDE=device:reading]
Reduziert historische Datensätze.


Arbeitsweise ohne Angabe von Befehlszeilenoperatoren

Es werden die Daten innerhalb der durch die time.*-Attribute bestimmten Zeitgrenzen bereinigt. Es muss mindestens eines der time.*-Attribute gesetzt sein (siehe Tabelle unten). Die jeweils fehlende Zeitabgrenzung wird in diesem Fall durch das Modul ermittelt.
Der Arbeitsmodus wird durch die optionale Angabe von mode bestimmt:

    ohne Angabe von mode : die Daten werden auf den ersten Eintrag pro Stunde je Device & Reading reduziert
    average                        : numerische Werte werden auf einen Mittelwert pro Stunde je Device & Reading reduziert
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)
    average=day                : numerische Werte werden auf einen Mittelwert pro Tag je Device & Reading reduziert
                                          Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)
    max                            : numerische Werte werden auf den Maximalwert pro Stunde je Device & Reading reduziert
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)
    max=day                    : numerische Werte werden auf den Maximalwert pro Tag je Device & Reading reduziert
                                         Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)

...


Liegt im contrib zum Test.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 August 2022, 21:03:06
Ich habe soeben noch ein update bzgl. reduceLog in mein contrib geladen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 August 2022, 21:41:13
Ich habe reduceLog noch um min und min=day erweitert.


...
min : numerische Werte werden auf den Minimalwert pro Stunde je Device & Reading reduziert, sonst wie ohne mode
min=day : numerische Werte werden auf den Minimalwert pro Tag je Device & Reading reduziert, sonst wie ohne mode
  Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.
...


V liegt im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 August 2022, 15:26:56
Und last but not least ist im reduceLog noch umgesetzt:


sum : numerische Werte werden auf die Summe pro Stunde je Device & Reading reduziert, sonst wie ohne mode
sum=day : numerische Werte werden auf die Summe pro Tag je Device & Reading reduziert, sonst wie ohne mode
  Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.


Liegt im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 August 2022, 22:05:10
Neue Version mit überarbeiteten reduceLog ist eingecheckt und morgen früh im Update.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 26 August 2022, 01:23:44
Zitat von: RalfRog am 25 Juni 2022, 19:58:10
Heute Nacht wurde bei der Bereinigung die letzte Stunde nicht auf den Halbstundenwert reduziert und die regulären Datenbankeinträge sind noch da.
......


Zitat von: DS_Starter am 22 August 2022, 22:05:10
Neue Version mit überarbeiteten reduceLog ist eingecheckt und morgen früh im Update.
LG

Hat leider länger gedauert mit der Rückmeldung (dafür kam die Version über das reguläre Update  ;)) und die neuen Möglichkeiten habe ich auch nicht getestet.

Aber das Problem mit den unvollständigen Averages am Ende des jüngsten Tags ist weg.
Alle Stundenwerte zu x:30 werden korrekt geschrieben :) und es bleiben keine Datenbankeinräge stehen.


TIMESTAMP;          DEVICE;              TYPE;  EVENT;      READING;VALUE;UNIT
2022-08-17 07:26:14;shelly_plug_s_df2674;SHELLY;power: 3.3; power;3.3;
2022-08-17 07:21:14;shelly_plug_s_df2674;SHELLY;power: 2.82;power;2.82;
2022-08-17 07:16:16;shelly_plug_s_df2674;SHELLY;power: 1.62;power;1.62;
2022-08-17 07:13:45;shelly_plug_s_df2674;SHELLY;power: 1.04;power;1.04;
2022-08-17 07:08:45;shelly_plug_s_df2674;SHELLY;power: 0.75;power;0.75;
2022-08-17 05:29:00;shelly_plug_s_df2674;manual;manual;     power;0;
2022-08-16 21:31:00;shelly_plug_s_df2674;manual;manual;     power;0;
2022-08-16 20:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;0.2300;
2022-08-16 19:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;3.6157;
2022-08-16 18:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;12.2937;
2022-08-16 17:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;28.8400;
2022-08-16 16:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;91.1250;
2022-08-16 15:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;139.9095;
2022-08-16 14:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;121.1065;
2022-08-16 13:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;159.1086;


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 August 2022, 09:05:29
Morgen Ralf,

danke für die Rückmeldung. Vllt. hast du ja für die neuen Möglichkeiten auch eine Verwendung.
Feedback ist auch dafür gerne willkommen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 03 September 2022, 17:41:33
Hallo Heiko,

ich habe ein weiteres Notify mit insert angelegt, leider bekomme ich einen BlockingCall Timeout im Log und das Insert wird nicht geschrieben. Hast du eine Idee, wo ich suchen soll?

ZitatFVERSION  93_DbRep.pm:v8.49.0-s25939/2022-04-09
Fhem bringe ich noch auf den aktuellen Stand, denke aber nicht, dass das hilft, da meine erstes Insert-Notify einwandfrei funktioniert.

Notify:
defmod n_Zisterne_Plot notify Zisternenpumpe:power:.* {if ($EVTPART1 > 50 && ReadingsVal('Zisternenpumpe','plot',0) == 0) {my $e = $EVTPART0;; chop $e;; my $t = ReadingsTimestamp($NAME,$e,'undef');; my @T = split(/ /, $t);; Debug("$T[0],$T[1],$NAME,$e");; return fhem("setreading Zisternenpumpe plot 1;; set insertDB insert $T[0],$T[1],0,,$NAME,$e");;} elsif ($EVTPART1 < 50 && ReadingsVal('Zisternenpumpe','plot',1) == 1) {return fhem 'setreading Zisternenpumpe plot 0';;}}


Verbose 1:
2022.09.03 17:00:13 1: DEBUG>2022-09-03,17:00:13,Zisternenpumpe,power
2022.09.03 17:00:13 1: DbRep insertDB -> BlockingCall DbRep_insert pid:6878 Timeout: process terminated
2022.09.03 17:00:13 1: DbRep insertDB -> BlockingCall DbRep_insert pid:6879 Timeout: process terminated
2022.09.03 17:03:14 1: DbRep insertDB -> BlockingCall DbRep_insert pid:6964 Timeout: process terminated
2022.09.03 17:06:15 1: DbRep insertDB -> BlockingCall DbRep_insert pid:7058 Timeout: process terminated


Verbose 5 bringt auch nicht mehr:
2022.09.03 10:34:12 5: Triggering n_Zisterne_Plot
2022.09.03 10:34:12 4: n_Zisterne_Plot exec {if ($EVTPART1 > 50 && ReadingsVal('Zisternenpumpe','plot',0) == 0) {my $e = $EVTPART0;; chop $e;; my $t = ReadingsTimestamp($NAME,$e,'undef');; my @T = split(/ /, $t);; Debug("$T[0],$T[1],$NAME,$e");; return fhem("setreading Zisternenpumpe plot 1;; set insertDB insert $T[0],$T[1],0,,$NAME,$e");;} elsif ($EVTPART1 < 50 && ReadingsVal('Zisternenpumpe','plot',1) == 1) {return fhem 'setreading Zisternenpumpe plot 0';;}}
2022.09.03 10:34:12 1: DEBUG>2022-09-03,10:34:12,Zisternenpumpe,power
2022.09.03 10:34:12 1: DbRep insertDB -> BlockingCall DbRep_insert pid:27242 Timeout: process terminated
2022.09.03 10:34:12 1: DbRep insertDB -> BlockingCall DbRep_insert pid:27243 Timeout: process terminated




Wenn ich ein trigger Zisternenpumpe power: 60 absetze, funktioniert es.

Plot:
Zitat2022-09-03_17:34:23 0
2022-09-03_17:34:55 60

Log:
Zitat2022.09.03 17:34:55 1: DEBUG>2022-09-03,17:34:23,Zisternenpumpe,power




Danke und Grüße
Bernd

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 September 2022, 17:59:16
Hallo Bernd,

Bin unterwegs ... gucken wir uns morgen mal an.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2022, 09:42:59
Moin Bernd,

es ist also so dass dein notify funktioniert wie es soll wenn du den event per trigger auslöst, richtig ?
Und du setzt eigentlich immer nur "0" in der DB, auch richtig ?

In deinen Logangaben vermisse ich grundsätzlich den Start der Aktion mit "-------- New selection ---------" Ausgabe mit verbose 4.
Gibt es den nicht ?

Was ist der Unterschied zwischen dem Trigger und dem normalen Event ?
Du kannst in deinem Debug mal den kompletten Event mit $EVENT aufnehmen und ausdrucken lassen.

Es müsste mit verbose 5 auch die Meldung


DbRep <name> - BlockingCall with PID "..." started


erscheinen. Sehe ich auch nicht in deinem Auszug.
Checke das bitte nochmal.

Grüße,
Heiko


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 04 September 2022, 10:10:00
Zitat von: DS_Starter am 04 September 2022, 09:42:59
Moin Bernd,

es ist also so dass dein notify funktioniert wie es soll wenn du den event per trigger auslöst, richtig ?
Und du setzt eigentlich immer nur "0" in der DB, auch richtig ?

Hallo Heiko, ja beides ist so.

Zitat
In deinen Logangaben vermisse ich grundsätzlich den Start der Aktion mit "-------- New selection ---------" Ausgabe mit verbose 4.
Gibt es den nicht

Das hat mich auch verwundert, ich habe verbose 5 benutzt, um erstmal selbst die Fehler zu finden. Mehr, wie gepostet, kommt nicht.

Zitat
Was ist der Unterschied zwischen dem Trigger und dem normalen Event ?
Eigentlich nur, dass Power eher bei 300 (296.4 o.ä.) ist.

Zitat
Du kannst in deinem Debug mal den kompletten Event mit $EVENT aufnehmen und ausdrucken lassen.
Mache ich aber erst heute Mittag...

Zitat
Es müsste mit verbose 5 auch die Meldung


DbRep <name> - BlockingCall with PID "..." started


erscheinen. Sehe ich auch nicht in deinem Auszug.
Checke das bitte nochmal.

Ich schaue heute Mittag nochmal.
Verbose von DbRep ist doch von Global verbose unabhängig, bzw. wird bevorzugt, richtig?

Grüße Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2022, 10:16:26

Verbose von DbRep ist doch von Global verbose unabhängig, bzw. wird bevorzugt, richtig?

Das verbose Verhalten unterscheidet sich nicht von anderen Modulen.
Um ein Problem in DbRep zu suchen ist es sinnvoll das globale verbose auf 3 (default) zu belassen und nur das betroffene DbRep Device auf 4 / 5 zu setzen. Das erhöht die Übersichtlichkeit enorm. Sonst hast du einen Wald vor Augen.  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 04 September 2022, 10:25:31
Ich habe alles auf verbose 1 und setze nur bei Bedarf auf 4 oder 5.

OK, mein Fehler...verbose 5 war nur im notify gesetzt. 8)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2022, 10:46:35
Ok. Dann kannst du im Dbrep erhöhen auf 2, 3, 4 oder 5. Sonst nimmt DbRep auch den global eingestellten Wert (1 bei dir).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 04 September 2022, 15:23:30
Zitat von: DS_Starter am 04 September 2022, 10:46:35
Ok. Dann kannst du im Dbrep erhöhen auf 2, 3, 4 oder 5. Sonst nimmt DbRep auch den global eingestellten Wert (1 bei dir).

Ich habe heute Morgen noch auf verbose 5 gestellt und die notify Bedingung auf >0.3.
Wenn die Pumpe steht, streut die Messung zw. 0 und 0.4 W.

Das hat dann funktiniert  :o
Zitat2022-09-04_11:35:53 0.3
2022-09-04_12:07:01 0.3
2022-09-04_12:37:13 0.3
2022-09-04_13:08:22 0
2022-09-04_13:08:22 0.4
2022-09-04_13:38:32 0
2022-09-04_14:09:42 0.3

Eben habe ich den Schwimmerschalter ausgelöst (Tauchpumpe) und das hat auch funktioniert  :o
Zitat
2022-09-04_14:52:56 0.3
2022-09-04_14:54:56 0
2022-09-04_14:54:56 299.3
2022-09-04_14:55:56 0

Lag es doch an der älteren Version von DbRep?? Fhem ist seit gestern aktuell. Oder Fhem hat einfach einen Neustart benötigt!?

Zitat2022.09.04 13:08:22 1: DEBUG>2022-09-04,13:08:22,Zisternenpumpe,power,event = power: 0.4
2022.09.04 13:08:22 3: DbRep insertDB - get initial structure information of database "fhem", remaining attempts: 3
2022.09.04 13:08:22 3: DbRep insertDB - Connectiontest to database mysql:database=fhem;host=localhost;port=xxxx with user xxx
2022.09.04 13:08:22 5: DbRep insertDB - start BlockingCall with PID "12705"
2022.09.04 13:08:22 4: DbRep insertDB - Database connect - user: xxx, UTF-8 option set: yes
2022.09.04 13:08:22 4: DbRep insertDB - Oldest timestamp determined: 2018-03-31 22:56:30
2022.09.04 13:08:22 4: DbRep insertDB - Encoding of database determined: utf8
2022.09.04 13:08:22 3: DbRep insertDB - Index Report_Idx exists. Check ok
2022.09.04 13:08:22 4: DbRep insertDB - Grants determined: USAGE
2022.09.04 13:08:22 5: DbRep insertDB - getInitData finished PID "12705"
2022.09.04 13:08:22 3: DbRep insertDB - Initial data information retrieved - total time used: 0.0144 seconds
2022.09.04 13:08:22 3: DbRep insertDB - Connectiontest to db mysql:database=fhem;host=localhost;port=3306 successful
2022.09.04 13:08:22 4: DbRep insertDB - -------- New selection ---------
2022.09.04 13:08:22 4: DbRep insertDB - Command: insert 2022-09-04 13:08:22,Zisternenpumpe,power,0,
2022.09.04 13:08:23 5: DbRep insertDB - BlockingCall with PID "12706" started
2022.09.04 13:08:23 4: DbRep insertDB - Database connect - user: xxx, UTF-8 option set: yes
2022.09.04 13:08:23 5: DbRep insertDB -> Primary Key used in fhem.history: 0 (none)
2022.09.04 13:08:23 5: DbRep insertDB -> Primary Key used in fhem.current: 0 (none)
2022.09.04 13:08:23 5: DbRep insertDB -> data to insert Timestamp: 2022-09-04 13:08:22, Device: Zisternenpumpe, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.09.04 13:08:23 4: DbRep insertDB - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.09.04 13:08:23 4: DbRep insertDB - begin transaction
2022.09.04 13:08:23 4: DbRep insertDB - transaction committed
2022.09.04 13:08:23 4: DbRep insertDB - Inserted into fhem.history: 2022-09-04 13:08:22, Zisternenpumpe, manual, manual, power, 0,
2022.09.04 13:08:23 5: DbRep insertDB - BlockingCall PID "12706" finished
2022.09.04 14:54:56 1: DEBUG>2022-09-04,14:54:56,Zisternenpumpe,power,event = power: 299.3
2022.09.04 14:54:56 4: DbRep insertDB - -------- New selection ---------
2022.09.04 14:54:56 4: DbRep insertDB - Command: insert 2022-09-04 14:54:56,Zisternenpumpe,power,0,
2022.09.04 14:54:56 5: DbRep insertDB - BlockingCall with PID "16068" started
2022.09.04 14:54:56 4: DbRep insertDB - Database connect - user: xxx, UTF-8 option set: yes
2022.09.04 14:54:56 5: DbRep insertDB -> Primary Key used in fhem.history: 0 (none)
2022.09.04 14:54:56 5: DbRep insertDB -> Primary Key used in fhem.current: 0 (none)
2022.09.04 14:54:56 5: DbRep insertDB -> data to insert Timestamp: 2022-09-04 14:54:56, Device: Zisternenpumpe, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.09.04 14:54:56 4: DbRep insertDB - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.09.04 14:54:56 4: DbRep insertDB - begin transaction
2022.09.04 14:54:56 4: DbRep insertDB - transaction committed
2022.09.04 14:54:56 4: DbRep insertDB - Inserted into fhem.history: 2022-09-04 14:54:56, Zisternenpumpe, manual, manual, power, 0,
2022.09.04 14:54:56 5: DbRep insertDB - BlockingCall PID "16068" finished

Nun muss ich erstmal warten, bis es wieder regnet...

Danke nochmal.

Grüße und schönen Restsonntag
Bernd

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 September 2022, 17:35:34
Zitat
Lag es doch an der älteren Version von DbRep?? Fhem ist seit gestern aktuell. Oder Fhem hat einfach einen Neustart benötigt!?
Eher unwahrscheinlich. Das ist m.M. nach eine grundsätzliche Problematik.

Folgender Zusammenhang ist wichtig zu verstehen.
Wenn ein Vorgang im DbRep gestartet wird, erstellt das Modul einen parallelen Prozess um die DB-Aktion auszuführen.
Mit verbose 5 sieht man das im Log:


2022.09.04 13:08:23 5: DbRep insertDB - BlockingCall with PID "12706" started


Durch diesen Mechanismus kann FHEM weiter werkeln und muß nicht auf das Ergebnis der DB warten, deswegen ist DbRep (und auch andere Module) über diesen Mechanismus non-blocking. Es werden aber Ressourcen im RAM allokiert.
Nun gibt es die Design-Vorgabe, dass ein Device nur einen ! BlockingCall aktiv haben darf.
Wenn du jetzt im selben DbRep-Device über dein notify ein neues insert antriggerst und der vorherige insert noch nicht abgeschlossen ist, wird der vorherige (noch laufende) BlockingCall abgebrochen.

Im Log erscheint dann zunächst eine WARNING dass der Prozess abgebrochen wird (verbose 3) und dann gibt es als Reaktion auf diesem Abbruch den Timeout:


2022.09.03 17:00:13 1: DbRep insertDB -> BlockingCall DbRep_insert pid:12706 Timeout: process terminated


In beiden Fällen wird dir die PID angezeigt und du kannst darüber erkennen welcher Prozess abgebrochen wurde.

Es hängt also ganz stark davon ab wie schnell deine DB den insert verarbeitet in Bezug zu dem Triggerintervall über dein notify.
Um dieses Problem zu verhindern umgehen könntest du das DbRep kopieren und den beiden notify jeweils ein DbRep exklusiv zuordnen falls es nötig wird.

Grüße und auch einen schönen Restsonntag.
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 04 September 2022, 18:09:17
Danke für die Erläuterung.

Das könnte passen, da das andere notify (Mysensors) beim Start der Pumpe ( unter bestimmten Bedingungen) parallel auch  anspricht (spülen des Filtersiebs der Zisterne).

Dann lege ich eine Kopie vom DbRep an. :)

Mir war nicht klar, das hier nur ein nonblocking erlaubt ist.

Danke nochmals.
Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: thomasg am 14 September 2022, 12:58:32
Hallo zusammen,

ich logge u.a. Messwerte von meinem Stromzähler und Wärmemengenzähler der Wärmepumpe. Das sind immer Summenwerte, die alle 15 Minuten protojolliert werden ins dblog mit sqllite hinten dran.

Nun habe ich den Wunsch, auf der fhem-Weboberfläche übersichtlich die abgegrenzten Monatsverbräuche/Wärmeerzeugung darzustellen. Vielleicht in einem Balkendiagramm auf der Y-Achse KwH und der X-Achse Monat.

Nun bin auf dieses Modul aufmerksam geworden. Meint Ihr, damit kann ich die Messwerte entsprechend aufbereiten?

Ich würde mir das So vorstellen: ein mal am Tag soll der abgerenzte Monatswert für den aktuellen Monat ermittelt/aktualisiert werden - dann in eine temporäre variable ... und wenn der monat voll ist kann die variable in die sqllite dtenbank geschrieben werden.

Vielen Dank & beste Grüße

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: frober am 14 September 2022, 20:27:55
Zitat von: frober am 04 September 2022, 18:09:17

Das könnte passen, da das andere notify (Mysensors) beim Start der Pumpe ( unter bestimmten Bedingungen) parallel auch  anspricht (spülen des Filtersiebs der Zisterne).

Dann lege ich eine Kopie vom DbRep an. :)

Mit der Kopie funktioniert es nun.
Danke nochmals.

LG
Bernd
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 September 2022, 20:43:50
Guten Abend,

@Bernd,  freut mich.  :)

@thomasg
ich könnte mir vorstellen, dass


set .... diffValue writeToDB


ein Weg für dich wäre. Mit dem Attr aggregation = month wird jeweils Differenz zwischen einem Montsanfangswert und Monatsendwert in den eingestellten Zeitgrenzen (time.* -Attribute) berechnet und mit einem neuen Readingsnamen in die DB geschrieben.
Dieses Reading kannst du dann im SVG anzeigen lassen.

diffValue  ist anwendbar für den Fall dass der Wert sich immer erhöht. Es wäre bei gegeben wenn ich deine Beschreibung richtig verstanden habe. Es würde in dem Beispiel reichen einmal im Monat für den Vormonat diese Berechnung auszuführen.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: thomasg am 24 September 2022, 14:36:22
Danke für den Tipp. Musste erst mein System neu aufsetzten und die sqlite Datenbank reparieren. Deswegen die Späte Rückmeldung.

Das funktioniert wunderbar. Ich habe ein neues Device "WP.Verbrauch.Mon" angelegt:


defmod WP.Verbrauch.Mon DbRep thomasDbLog
attr WP.Verbrauch.Mon aggregation month
attr WP.Verbrauch.Mon comment Abgegrenzter Stromverbrauch Wärmepumpe
attr WP.Verbrauch.Mon device HAR.Counter
attr WP.Verbrauch.Mon reading consumption
attr WP.Verbrauch.Mon room Sensoren


Wenn ich dann in der Weboberfläche bei set diffValue und display auswähle rechnet er die abgegrenzen Werte einmalig aus und zeigt sie als Reading an.
Kannst Du mir jetzt noch einen Hinweis geben, wie ich das automatisieren kann? Also einmal am tag soll er die Werte ermitteln und in die Datenbank schreiben.

ein  attr WP.Verbrauch.Mon diffValue writeToDB führt leider zu einer Fehlermeldung.

Gibt es auch eine Möglichkeit fürs Reinschreiben in die Datenbank als Alternative zu den generierten Readingbezeichnungen:

2022-02-28_23-56-48__HAR.Counter__consumption__DIFF__2022-02
2022-03-31_23-48-49__HAR.Counter__consumption__DIFF__2022-03
2022-04-30_23-56-00__HAR.Counter__consumption__DIFF__2022-04

ein konsistenten Readingnamen zu haben.

Also bspw. einfach nur WP.Verbrauch.Mon ohne Zeitstempel im Namen?



Lieben Dank
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 September 2022, 20:32:51
Regelmässige Ausführungen machst du einfach über die Definition eines at Devices.

Diese führt dann ein set ... diffValue writeToDB aus.

Um das geschriebene neue Reading umzubenennen kannst du das Attr readingNameMap benutzen.
Aber schau mal ob dir der generisch gebildete Namen nicht ausreicht. Ist in der Commandref zu diffValue weiteToDB beschrieben.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: thomasg am 25 September 2022, 08:55:38
Du hast recht .. der generische Name ist nachvollziehbarer und passt dann zu den anderen attributen in der datenbank.
Habe es jetzt hinbekommen. Super Sache. Das Ergebnischart mal im Anhang dargestellt. Wenn ich mit der Maus über die Legende des Charts gehe, wird Min, Max, Lastals Mouseover angezeigt. Hast Du vielleicht noch einen Tipp, wie ich da stattdessen die Summe des Monats anzeiegn lassen kann? Oder gerne auch dauerhaft einblenden im Diagramm. Ich habe auch einmal einen Screenshot meiner DBrep devices gemacht. Ist das so ok, wenn ich zwei Werte ermitteln möchte zwei Devices anzulegen, oder wäre es gecshickter diese beiden Werte (Verbrauch, Erzeugung) in ein DBREP Device zusammenzufassen. Würde dann auch nur in ein AT Device resultieren. Wäre dann alles etwas übersichtlicher/einfacher. Danke & schönes Restwochenende
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 September 2022, 14:46:28
Zitat
Hast Du vielleicht noch einen Tipp, wie ich da stattdessen die Summe des Monats anzeiegn lassen kann? Oder gerne auch dauerhaft einblenden im Diagramm.
Schau doch dafür mal im SVG Forum vorbei. Ich will nicht sagen es ginge nicht, habe aber addhoc keinen Vorschlag.
Und weil ich aktuell auch bisschen Urlaub mache, will ich jetzt auch nicht danach schauen ...  ;)

Zitat
Ist das so ok, wenn ich zwei Werte ermitteln möchte zwei Devices anzulegen, oder wäre es gecshickter diese beiden Werte (Verbrauch, Erzeugung) in ein DBREP Device zusammenzufassen.
Zwei Devices ist absolut ok und war von mir vom Design her auch so gedacht. Wenn man beide Funktionen (Verbrauch, Erzeugung) vom selben DbRep erzeugen lassen will geht das zwar auch, man muß sich aber genau überlegen wie man das zeitlich steuert. Durch die asynchrone Arbeitsweise dürfen sich beide Aufgaben zeitlich nicht überschneiden usw.
Ich habe bei mir über 100 DbRep's für die unterschiedlichsten Aufgaben definiert.
Welche Strukturierung man als übersichtlicher erachtet ist dann letztlich Ansichtssache.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 12 Oktober 2022, 12:37:14
Hallo zusammen,
ich habe seit längerem meine Datenbank mal wieder aufgeräumt und viel löschen können, danach wurde ein optimizeTables durchgeführt.
Woran kann ich eventuell erkennen, ob es etwas gebracht hat?

Die Datenbank ist eine Oracle MySQL 8.0.28 in 64 Bit auf nem RPI4
Momentane Größe 8,9 Gb

2022.10.12 10:28:42.894 3: DbRep LogDBRep - ################################################################
2022.10.12 10:28:42.895 3: DbRep LogDBRep - ###          New optimize table / vacuum execution           ###
2022.10.12 10:28:42.895 3: DbRep LogDBRep - ################################################################
2022.10.12 10:28:43.022 3: DbRep LogDBRep - Estimate of fhem before optimize (MB): Data size: 2537, Index size: 6402.92, Space free: 9, Overhead: 150.59
2022.10.12 10:28:43.022 3: DbRep LogDBRep - Optimizing tables
2022.10.12 10:28:43.022 3: DbRep LogDBRep - Optimizing table `current` (INNODB). It may take a while ...
2022.10.12 10:28:43.434 3: DbRep LogDBRep - Table 1 `current` optimized successfully.
2022.10.12 10:28:43.434 3: DbRep LogDBRep - Optimizing table `history` (INNODB). It may take a while ...
2022.10.12 12:21:45.724 3: DbRep LogDBRep - Table 2 `history` optimized successfully.
2022.10.12 12:21:45.724 3: DbRep LogDBRep - 2 tables have been optimized.
2022.10.12 12:21:45.827 3: DbRep LogDBRep - Estimate of fhem after optimize (MB): Data size: 2537, Index size: 6402.92, Space free: 9, Overhead: 150.59
2022.10.12 12:21:45.828 3: DbRep LogDBRep - Optimize tables of fhem finished - total time (hh:mm:ss): 01:53:02
2022.10.12 12:21:45.842 3: DbRep LogDBRep - Optimize tables finished successfully.

VG Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Oktober 2022, 15:10:10
Halo Christian,

die Ergebnisse zu Anfang und Endgröße stehen doch im Log. Hier einer meiner Test MySQL:


2022.10.12 14:16:25.524 3: DbRep Rep.LogMariaVM.Test - ################################################################
2022.10.12 14:16:25.524 3: DbRep Rep.LogMariaVM.Test - ###          New optimize table / vacuum execution           ###
2022.10.12 14:16:25.525 3: DbRep Rep.LogMariaVM.Test - ################################################################
2022.10.12 14:16:25.566 4: DbRep Rep.LogMariaVM.Test - Database connect - user: fhemtest, UTF-8 option set: yes
2022.10.12 14:16:25.586 3: DbRep Rep.LogMariaVM.Test - Estimate of fhemtest before optimize (MB): Data size: 3070.75, Index size: 2951.36, Space free: 7, Overhead: 150.59
....
2022.10.12 14:43:59.122 3: DbRep Rep.LogMariaVM.Test - Estimate of fhemtest after optimize (MB): Data size: 2787.05, Index size: 2654, Space free: 0, Overhead: 150.59


Und außerdem noch als Readings:


   READINGS:
     2022-10-12 14:43:59   SizeDbBegin_MB  Data size: 3070.75, Index size: 2951.36, Space free: 7, Overhead: 150.59
     2022-10-12 14:43:59   SizeDbEnd_MB    Data size: 2787.05, Index size: 2654, Space free: 0, Overhead: 150.59
     2022-10-12 14:43:59   background_processing_time 1653.5576
     2022-10-12 14:43:59   state           optimize tables finished


LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 12 Oktober 2022, 15:53:30
Zitat von: DS_Starter am 12 Oktober 2022, 15:10:10
die Ergebnisse zu Anfang und Endgröße stehen doch im Log. Hier einer meiner Test MySQL:
Okay, dem nach war bei mir nichts zu optimieren :-)

2022.10.12 10:28:43.022 3: DbRep LogDBRep - Estimate of fhem before optimize (MB): Data size: 2537, Index size: 6402.92, Space free: 9, Overhead: 150.59
2022.10.12 12:21:45.827 3: DbRep LogDBRep - Estimate of fhem after  optimize (MB): Data size: 2537, Index size: 6402.92, Space free: 9, Overhead: 150.59
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Univega06 am 29 Oktober 2022, 12:22:29
Hallo Zusammen,
ich bin gerade dabei mein SQLite Datenbank deutlich zu reduzieren.
Die Reduktion auf eine Stunde mit Dbrep reduceLog average ist mir jedoch für einige Devices etwas zu viel. Besteht die Möglichkeit entweder eine individuelle Reduktion oder einen weiteren Intervall von z.B. 5 min zu implementieren?

Vielen Dank und Grüße
Kai
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Oktober 2022, 12:40:15
Hallo Kai,

ich will nicht behaupten dass 5 Minuten nicht ginge.
Allerdings ist es nicht so leicht zu implementieren weil sich die Zeitgrenzen von "Zwischenwerten" im Zeitstempel der DB-Datensätze nicht so einfach abgrenzen lassen wie 1 Minute oder 1 Stunde oder 1 Tag.

Wird auf jeden Fall einige Zeit dauern bis die Möglichkeit evtl. zur Verfügung stehen könnte.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Univega06 am 29 Oktober 2022, 14:09:21
Hallo Heiko,
aktuell geht 1 Stunde oder 1 Tag wenn ich es richtig verstanden habe?

Wäre die Implementierung von 1 Min einfacher umsetzbar?


Danke und Grüße
Kai
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Oktober 2022, 14:11:24
Zitat
aktuell geht 1 Stunde oder 1 Tag wenn ich es richtig verstanden habe?
Ja das stimmt.

Zitat
Wäre die Implementierung von 1 Min einfacher umsetzbar?
Sag mal ja ohne es vorher genau gecheckt zu haben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: h0nIg am 07 Dezember 2022, 00:24:21
Hi,

ich versuche gerade den Zählerwert meines Stromzählers auszuwerten. Ich verwende dafür diffValue und scheinbar gehen die Kommastellen verloren.

Wenn ich das RAW SQL statement anschaue, kriege ich

| 2022-12-04 23:54:36 | 17705.911 |  0.013999999999214197 | 17705.911   | 0    |
| 2022-12-04 23:55:37 | 17705.923 |  0.011999999998806743 | 17705.923   | 0    |
| 2022-12-04 23:56:37 | 17705.935 |  0.012000000002444722 | 17705.935   | 0    |
| 2022-12-04 23:57:36 | 17705.946 |  0.010999999998603016 | 17705.946   | 0    |
| 2022-12-04 23:58:37 | 17705.958 |  0.011999999998806743 | 17705.958   | 0    |
| 2022-12-04 23:59:37 | 17705.970 |  0.012000000002444722 | 17705.970   | 0    |


wenn ich mir das array anschaue welches von MariaDB zurückkommt:

MjAyMi0xMi0wNA== 2022-12-04 23:53:36 17705.897 0
MjAyMi0xMi0wNA== 2022-12-04 23:54:36 17705.911 0
MjAyMi0xMi0wNA== 2022-12-04 23:55:37 17705.923 0
MjAyMi0xMi0wNA== 2022-12-04 23:56:37 17705.935 0
MjAyMi0xMi0wNA== 2022-12-04 23:57:36 17705.946 0
MjAyMi0xMi0wNA== 2022-12-04 23:58:37 17705.958 0
MjAyMi0xMi0wNA== 2022-12-04 23:59:37 17705.970 0



Jemand eine Idee was hier nicht stimmen könnte?

Grüße
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2022, 09:25:35
Moin,

wir hatten unlängst einen ähnlichen Fall mit MariaDB.
Kannst du bitte die Version aus meinem contrib (siehe Fußtext) herunterladen, FHEM neu starten und testen ?

Du hast aber nicht das Attr numDecimalPlaces = 0 gesetzt, oder ?

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: h0nIg am 07 Dezember 2022, 13:20:57
Hi,

jup, ist gefixxt, numDecimalPlaces ist bei mir nicht gesetzt gewesen.

MariaDB Version ist bei mir 10.9.3-MariaDB-1:10.9.3+maria~ubu2204

Grüße
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2022, 13:48:54
Ah, danke für die Rückmeldung.
Das deckt sich mit dem angedeuteten Fall.

Meine V ist MariaDB 10.1.48-MariaDB-0+deb9u2.

Ich checke die gefixte DbRep ein, ist dann morgen früh im Update.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: h0nIg am 07 Dezember 2022, 20:35:31
Hi,

ich versuche gerade das Current aggregation Beispiel bei mir zum laufen zu kriegen. Jedoch finde ich im Code keinen Hinweis was falsch sein könnte:

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#4._Erstellung_des_Plots

der Prefix sollte hier herkommen: https://github.com/fhem/fhem-mirror/blob/master/fhem/FHEM/93_DbRep.pm#L3575, wo hier ein doppeltes "_" hinzugefügt wird: https://github.com/fhem/fhem-mirror/blob/master/fhem/FHEM/93_DbRep.pm#L3566

Jedoch kommt kein doppeltes "_" in den Beispielen vor, ist die Dokumentation hier noch uptodate oder habe ich Tomaten auf den Augen?

Grüße


define logdb.aggregation DbLog ./modified/db.conf logdb.*
attr logdb.aggregation DbLogType Current/History
attr logdb.aggregation asyncMode 1
attr logdb.aggregation bulkInsert 1
attr logdb.aggregation cacheEvents 2
attr logdb.aggregation dbSchema fhem_aggregation

define logdb.weekly.Strom.Haus DbRep logdb.aggregation
attr logdb.weekly.Strom.Haus aggregation day
attr logdb.weekly.Strom.Haus allowDeletion 1
attr logdb.weekly.Strom.Haus device MQTT2_Z_HAUS
attr logdb.weekly.Strom.Haus reading MT681_Total_in
attr logdb.weekly.Strom.Haus showproctime 1
attr logdb.weekly.Strom.Haus timestamp_begin previous_week_begin
attr logdb.weekly.Strom.Haus timestamp_end previous_week_end

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Dezember 2022, 21:14:22
Ich verstehe dein Problem nicht wirklich.
Mit dem Attribut "DbLogType = Current..." im DbLog-Device wird lediglich bewirkt, dass du im dem SVG-Editor im FHEMWEB eine Drop-Down Liste bekommst um dein gewünschtes Device und das gewünschte Reading zur Anzeige im SVG auswählen zu können.

Die Readings im DbRep werden noch immer mit den doppelten __ erzeugt.
Wenn du ein List des DbRep Devices postest, ist das für potentielle Helfer einfacher und etwas besser beschreibst was du eigentlich erreichen möchtest.  ;)
Ein List kannst du einfach mit dem "Copy for forum.fhem.de" Link in der Detailanzeige des DbRep Devices erstellen hier als Code posten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Dezember 2022, 12:42:20
Hallo zusammen,
hier gibt es mal wieder ein SELECT Beispiel, falls Ihr mal wissen möchtet, wieviel der PV-Leistungs Anteil bei einer Wärmepumpe sein kann. (https://forum.fhem.de/index.php/topic,114849.msg1249971.html#msg1249971)

EDIT: Ich habe es jetzt auch hier im Wiki abgelegt: Wieviel PV-Leistung wird von einem Starkverbraucher verwendet (MySQL) (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Wieviel_PV-Leistung_wird_von_einem_Starkverbraucher_verwendet_.28MySQL.29)

VG    Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2022, 12:58:28
Deine SQLs sind immer eine Freude .... wie Weihnachten.  :D

Mache doch einen Eintrag im DbRep Wiki. Ich habe eine Abschnitt für hilfreiche SQL angefangen.
Dann geht das Know How nicht verloren und wer Anregungen sucht ....

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Dezember 2022, 13:02:40
Zitat von: DS_Starter am 08 Dezember 2022, 12:58:28
Deine SQLs sind immer eine Freude .... wie Weihnachten.  :D

Mache doch einen Eintrag im DbRep Wiki. Ich habe eine Abschnitt für hilfreiche SQL angefangen.
Dann geht das Know How nicht verloren und wer Anregungen sucht ....
Ach Du schmeichelst mir jetzt aber wieder :-) :-)
Ich schau mal, ob ich es noch generischer hin bekomme und setze es dann rein.

EDIT: Ich habe es jetzt auch hier im Wiki abgelegt: Wieviel PV-Leistung wird von einem Starkverbraucher verwendet (MySQL) (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Wieviel_PV-Leistung_wird_von_einem_Starkverbraucher_verwendet_.28MySQL.29)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Dezember 2022, 13:28:26
Ich hätte da auch noch eine Auswertung für Wechselrichter mit den Jahres Statistiken, oder sogar Quartals Statistiken, das wäre aber sehr speziel und das SELECT geht über 284 Zeilen :-)

Das ist auch der Grund, warum ich beim DbRep nach einer Formatierten Speicherung des sqlCmd gefragt hatte.

Hier mal ein List vom Jahres Report, der noch ziemlich kurz ist.

Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      614b0a08-f33f-61a8-f1e8-10ef59dfe90ba545
   FVERSION   93_DbRep.pm:v8.49.0-s26054/2022-05-17
   LASTCMD    initial database connect stopped due to attribute 'fastStart'
   MODEL      Client
   NAME       LogDBRep_Statistic_previous_Year
   NOTIFYDEV  global,LogDBRep_Statistic_previous_Year
   NR         424
   NTFY_ORDER 50-LogDBRep_Statistic_previous_Year
   ROLE       Client
   STATE      initialized
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE LogDB
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.49.0
   READINGS:
     2021-12-31 23:57:03   SW_Statistic_Autarky_Year 68
     2021-12-31 23:57:03   SW_Statistic_EnergyHomeFeedInGrid_Year 11294
     2021-12-31 23:57:03   SW_Statistic_EnergyHomeGrid_Year 2616
     2021-12-31 23:57:03   SW_Statistic_EnergyHomePvSum_Year 5598
     2021-12-31 23:57:03   SW_Statistic_EnergyHomePv_Year 4171
     2021-12-31 23:57:03   SW_Statistic_EnergyHome_Year 8214
     2021-12-31 23:57:03   SW_Statistic_OwnConsumptionRate_Year 33
     2021-12-31 23:57:03   SW_Statistic_TotalConsumption_Year 8214
     2021-12-31 23:57:03   SW_Statistic_Yield_Year 16892
     2022-01-11 15:19:26   SqlResultRow_01 TIMESTAMP|READING|VALUE
     2022-01-11 15:19:26   SqlResultRow_02 2021-12-31 23:57:03|Statistic_EnergyHomeBat_Year|1427
     2022-01-11 15:19:26   SqlResultRow_03 2021-12-31 23:57:03|SW_Statistic_Autarky_Year|68
     2022-01-11 15:19:26   SqlResultRow_04 2021-12-31 23:57:03|SW_Statistic_EnergyHome_Year|8214
     2022-01-11 15:19:26   SqlResultRow_05 2021-12-31 23:57:03|SW_Statistic_EnergyHomeFeedInGrid_Year|11294
     2022-01-11 15:19:26   SqlResultRow_06 2021-12-31 23:57:03|SW_Statistic_EnergyHomeGrid_Year|2616
     2022-01-11 15:19:26   SqlResultRow_07 2021-12-31 23:57:03|SW_Statistic_EnergyHomePv_Year|4171
     2022-01-11 15:19:26   SqlResultRow_08 2021-12-31 23:57:03|SW_Statistic_EnergyHomePvSum_Year|5598
     2022-01-11 15:19:26   SqlResultRow_09 2021-12-31 23:57:03|SW_Statistic_OwnConsumptionRate_Year|33
     2022-01-11 15:19:26   SqlResultRow_10 2021-12-31 23:57:03|SW_Statistic_TotalConsumption_Year|8214
     2022-01-11 15:19:26   SqlResultRow_11 2021-12-31 23:57:03|SW_Statistic_Yield_Year|16892
     2022-01-11 15:19:26   SqlResultRow_12 2021-12-29 14:35:50|lp_1_kWhCounter_Year|466
     2021-12-31 23:57:03   Statistic_EnergyHomeBat_Year 1427
     2021-12-29 14:35:50   lp_1_kWhCounter_Year 466
     2022-01-11 15:19:26   sqlCmd          SELECT * FROM ( SELECT h.TIMESTAMP, h.READING, IF (h.READING LIKE '%Rate%' OR h.READING LIKE '%Autarky%',h.VALUE ,cast(h.VALUE/1000 AS decimal(6)) ) AS VALUE FROM history h INNER JOIN ( SELECT max(TIMESTAMP) AS TIMESTAMP,READING FROM history WHERE §device§ AND §reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-31'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') GROUP BY READING ) x1 ON h.TIMESTAMP = x1.TIMESTAMP AND h.READING = x1.READING ) x2 UNION ALL SELECT h.TIMESTAMP, h.READING, h.VALUE FROM history h INNER JOIN ( SELECT max(TIMESTAMP) AS TIMESTAMP,READING FROM history WHERE DEVICE = 'WB_1' AND READING LIKE 'lp_%_kWhCounter_Year' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1,'-12-01'),'%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()) ,'-01-01'),'%Y-%m-%d') GROUP BY READING ) x2 ON h.TIMESTAMP = x2.TIMESTAMP AND h.READING = x2.READING ;
     2022-01-11 15:19:26   sqlResultNumRows 11
     2022-11-06 17:27:08   state           initialized
Attributes:
   DbLogExclude .*
   allowDeletion 0
   comment    Version 2022.01.11 11:00
   device     WR_1_API
   reading    SW_Statistic%_Year,Statistic_EnergyHomeBat_Year EXCLUDE=%NoBat%,%EnergyPv%
   room       System
   userExitFn splitReading .*:.*
   verbose    0

Mit dem splitReading erzeuge ich die formatierten reading Namen, die ich dann in einem DOIF uitable im Perl Modus als Statistik Tabelle anzeige.
Das sieht dann so aus wie im Anhang.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2022, 13:33:25
Na ich kenne dich ja schon ein bisschen ... ;)

Auch das wäre sicher eine hilfreiche Anregung für Nachnutzer.
Da bietet sich an eine extra Wiki Seite zu erstellen und im DbRep Abschnitt für die SQLs einen Link dorthin zu setzen.
Wieder etwas Mehrwert für DB User ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 08 Dezember 2022, 13:36:39
Zitat von: DS_Starter am 08 Dezember 2022, 13:33:25
Na ich kenne dich ja schon ein bisschen ... ;)

Auch das wäre sicher eine hilfreiche Anregung für Nachnutzer.
Da bietet sich an eine extra Wiki Seite zu erstellen und im DbRep Abschnitt für die SQLs einen Link dorthin zu setzen.
Wieder etwas Mehrwert für DB User ...
Na da haste mal wieder schön die formatierte Anzeige von sqlCmd umdribbelt :-) :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 Dezember 2022, 12:31:54
Hallo nochmal,

ich habe hier etwas für das Formatieren von SQL Statements gefunden, das sogar eine API hat :-)

Online (https://sqlformat.org/)
github (https://github.com/andialbrecht/sqlparse)
Und hier könnte etwas offline für Perl sein ;-) (https://metacpan.org/pod/SQL::Parser)

Hier mal ein Beispiel mit einer meiner Zauber SQLs
Input für die Web Page

SELECT X.HOUR, cast(X.generator_P AS decimal(7,2)) AS generator_P, cast(X.Home_Consumption AS decimal(7,2)) AS Home_Consumption, cast(X.PV_after_Home_Consumtion AS decimal(7,2)) AS PV_after_Home_Consumtion, cast(X.consumer_P AS decimal(7,2)) AS consumer_P, if(consumer_P+PV_after_Home_Consumtion <= 0,cast(round(abs(consumer_P+PV_after_Home_Consumtion),2) AS decimal(7,2)),0) AS from_Grid, if(round(consumer_P+PV_after_Home_Consumtion,2) <= 0,round(abs(PV_after_Home_Consumtion*100/consumer_P),0),100) AS Percent FROM ( SELECT X1.HOUR, generator_P, round(Home_Consumtion_P+consumer_P,2) AS Home_Consumption, if(Home_Consumtion_P+consumer_P-generator_P < 0,round(abs(Home_Consumtion_P+consumer_P-generator_P),2),0) AS PV_after_Home_Consumtion, consumer_P FROM ( SELECT hour(TIMESTAMP) AS HOUR, round(avg(value),2) AS consumer_P FROM history WHERE TIMESTAMP > §timestamp_begin§ and TIMESTAMP < DATE_ADD(§timestamp_begin§,INTERVAL 1 DAY) AND §device§ AND §reading§ GROUP BY 1 ) X1 JOIN ( SELECT hour(TIMESTAMP) AS HOUR, round(avg(value),2) AS generator_P FROM history WHERE TIMESTAMP > §timestamp_begin§ AND TIMESTAMP < DATE_ADD(§timestamp_begin§,INTERVAL 1 DAY) AND DEVICE = @generator AND READING = @generator_P AND VALUE > 10 GROUP BY 1 ) X2 JOIN ( SELECT hour(TIMESTAMP) AS HOUR, round(avg(value),2) AS Home_Consumtion_P FROM history WHERE TIMESTAMP > §timestamp_begin§ and TIMESTAMP < DATE_ADD(§timestamp_begin§,INTERVAL 1 DAY) AND DEVICE = @generator AND READING = @Home_Consumtion_P AND VALUE > 10 GROUP BY 1 ) X3 ON X1.HOUR = X2.HOUR AND X1.HOUR = X3.HOUR ) X;

Und so sieht es dann hinterher wieder aus

SELECT X.HOUR,
       cast(X.generator_P AS decimal(7, 2)) AS generator_P,
       cast(X.Home_Consumption AS decimal(7, 2)) AS Home_Consumption,
       cast(X.PV_after_Home_Consumtion AS decimal(7, 2)) AS PV_after_Home_Consumtion,
       cast(X.consumer_P AS decimal(7, 2)) AS consumer_P,
       if(consumer_P+PV_after_Home_Consumtion <= 0, cast(round(abs(consumer_P+PV_after_Home_Consumtion), 2) AS decimal(7, 2)), 0) AS from_Grid,
       if(round(consumer_P+PV_after_Home_Consumtion, 2) <= 0, round(abs(PV_after_Home_Consumtion*100/consumer_P), 0), 100) AS Percent
FROM
  (SELECT X1.HOUR,
          generator_P,
          round(Home_Consumtion_P+consumer_P, 2) AS Home_Consumption,
          if(Home_Consumtion_P+consumer_P-generator_P < 0, round(abs(Home_Consumtion_P+consumer_P-generator_P), 2), 0) AS PV_after_Home_Consumtion,
          consumer_P
   FROM
     (SELECT hour(TIMESTAMP) AS HOUR,
             round(avg(value), 2) AS consumer_P
      FROM history
      WHERE TIMESTAMP > §timestamp_begin§
        AND TIMESTAMP < DATE_ADD(§timestamp_begin§,INTERVAL 1 DAY)
        AND §device§
        AND §reading§
      GROUP BY 1) X1
   JOIN
     (SELECT hour(TIMESTAMP) AS HOUR,
             round(avg(value), 2) AS generator_P
      FROM history
      WHERE TIMESTAMP > §timestamp_begin§
        AND TIMESTAMP < DATE_ADD(§timestamp_begin§,INTERVAL 1 DAY)
        AND DEVICE = @generator
        AND READING = @generator_P
        AND VALUE > 10
      GROUP BY 1) X2
   JOIN
     (SELECT hour(TIMESTAMP) AS HOUR,
             round(avg(value), 2) AS Home_Consumtion_P
      FROM history
      WHERE TIMESTAMP > §timestamp_begin§
        AND TIMESTAMP < DATE_ADD(§timestamp_begin§,INTERVAL 1 DAY)
        AND DEVICE = @generator
        AND READING = @Home_Consumtion_P
        AND VALUE > 10
      GROUP BY 1) X3 ON X1.HOUR = X2.HOUR
   AND X1.HOUR = X3.HOUR) X;

Hierbei wurden sogar die DbRep Variablen sehr schön akzeptiert und das ganze nicht als Syntaxerror beendet.

Ich versuche das mal mit HTTPMOD ins FHEM einzubinden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 10 Dezember 2022, 12:48:02
Ich habe dann auch mal das SELECT für die Verwendung der PV-Leistung ans DbRep Device angepasst.
Hier mal das RAW

defmod LogDBRep_Statistic_Heating_PV_usage DbRep LogDB
attr LogDBRep_Statistic_Heating_PV_usage DbLogExclude .*
attr LogDBRep_Statistic_Heating_PV_usage allowDeletion 0
attr LogDBRep_Statistic_Heating_PV_usage comment Version 2022.12.10 12:00
attr LogDBRep_Statistic_Heating_PV_usage device StromZaehler_Heizung
attr LogDBRep_Statistic_Heating_PV_usage reading SMAEM1901401955_Saldo_Wirkleistung
attr LogDBRep_Statistic_Heating_PV_usage room System
attr LogDBRep_Statistic_Heating_PV_usage sqlCmdVars SET @generator:='WR_1', @generator_P:='SW_Total_AC_Active_P', @Home_Consumtion_P:='SW_Home_own_consumption';;
attr LogDBRep_Statistic_Heating_PV_usage timestamp_begin current_day_begin
attr LogDBRep_Statistic_Heating_PV_usage verbose 0


Das sqlCmd entspricht dem vorherigen Post ;-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RobertSch am 14 Dezember 2022, 08:19:49
Hallo Zusammen!

Ich habe ein Problem mit meinem fhem. Ich kann aus welchem Grund auch immer das DbRep-Modul nicht hinzufügen.

Cannot load module DbRep

wird ausgegeben, nachdem ich mit

define DBLogging_DbRep DbRep DBLogging

versucht habe dies hinzu zu fügen.

Ein Blick ins Log ergab dann folgendes:

2022.12.14 08:11:38 0: Time::HiRes::ualarm(): unimplemented in this platform at ./FHEM/93_DbRep.pm line 45.
BEGIN failed--compilation aborted at ./FHEM/93_DbRep.pm line 45.


Woran liegt das? Wenn ich die Meldung richtig deute, dann ist es irgendwas mit Time Modul von Perl?

Ich nutze fhem unter Windows auf einer VM. Liegt es an Windows?

Ich bin mit meinem Latein am Ende und würde gerne weiter kommen. Kann mir jemand helfen?

Vielen lieben Dank im Voraus!

LG
Robert


EDIT: Log Ausschnitt mit "verbose 5" Einstellung:
2022.12.14 08:21:13 4: WEB_127.0.0.1_54382 POST /fhem&fw_id=885&room=Server&fwcsrf=csrf_476589676604730&cmd=define+DBLogging_DbRep+DbRep+DBLogging; BUFLEN:0
2022.12.14 08:21:13 5: Cmd: >define DBLogging_DbRep DbRep DBLogging<
2022.12.14 08:21:13 5: Loading ./FHEM/93_DbRep.pm
2022.12.14 08:21:13 1: reload: Error:Modul 93_DbRep deactivated:
Time::HiRes::ualarm(): unimplemented in this platform at ./FHEM/93_DbRep.pm line 45.
BEGIN failed--compilation aborted at ./FHEM/93_DbRep.pm line 45.

2022.12.14 08:21:13 0: Time::HiRes::ualarm(): unimplemented in this platform at ./FHEM/93_DbRep.pm line 45.
BEGIN failed--compilation aborted at ./FHEM/93_DbRep.pm line 45.

2022.12.14 08:21:13 4: WEB: /fhem&fw_id=885&room=Server&fwcsrf=csrf_476589676604730&cmd=define+DBLogging_DbRep+DbRep+DBLogging / RL:1721 / text/html; charset=UTF-8 / Content-Encoding: gzip

/ Cache-Control: no-cache, no-store, must-revalidate
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Dezember 2022, 08:56:27
Guten Morgen Robert,

Du hast recht, es liegt am Time Modul bzw. eher daran dass du Windows benutzt. Ich habe dazu gefunden:


....
The fact that ualarm() isn't supported has nothing to do with the precision
but more with the fact that alarm() doesn't really work on Windows.  It
doesn't interrupt C code or system calls but waits until Perl polls
a messageloop to see if a timer has expired.


Das ist jetzt kein Beinbruch. Ich brauche ualarm nicht (mehr) und habe es aus dem Modul rausgenommen.
Ich checke es noch ein, aber du kannst es schon aus meinem contrib (Fußtext) laden und FHEM restarten.
Dann sollte es klappen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RobertSch am 14 Dezember 2022, 10:06:26
Hallo Heiko!

Danke für die schnelle Problemlösung. Ich konnte das DbRep Modul nun anlegen.

LG
Robert
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 Dezember 2022, 16:21:26
Hallo Heiko,
konnte man jetzt eigentlich in einem DbRep Aufruf mehrere SQL Kommandos zusammen absetzen?
z.B. ein INSERT und anschließend noch mehrere UPDATE
Falls es nicht gehen würde, wie könnte man das dann anderweitig lösen?

EDIT: Es scheint nicht zu gehen.
  Mir schwebt da eine Art RAW Modus vor, bei dem einfach alles durchgereicht wird, wie so eine Art SQL Script :-)

VG  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Dezember 2022, 20:21:16
Hallo Christian,

das "Problem" bei solchen Batchverarbeitungen ist, dass das Modul keine Ahnung hat was denn nun eigentlich das Ergebnis ist woraus Readings gebildet werden sollen. Die Rückgabe des Selects, bei mehreren ... welches Select ? oder vllt. doch nur die Anzahl der upgedateteten Datensätze oder was sonst ?

Deswegen ist so etwas nicht umgesetzt.

Man könnte versuchen ein Splitting über die keywords select, update, etc. vorzunehmen und die entstandenen SQL's der Reihe nach abzuarbeiten. Ohne Ergebnisse oder Readings zurückzugeben.

Das wäre eine neue Implementierung die es noch nicht gibt.

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 08:22:35
Hallo Heiko,
danke für die Geduld mit mir ;-)
Zitat von: DS_Starter am 20 Dezember 2022, 20:21:16
das "Problem" bei solchen Batchverarbeitungen ist, dass das Modul keine Ahnung hat was denn nun eigentlich das Ergebnis ist woraus Readings gebildet werden sollen. Die Rückgabe des Selects, bei mehreren ... welches Select ? oder vllt. doch nur die Anzahl der upgedateteten Datensätze oder was sonst ?
Okay, das kann ich verstehen :-(
Ich denke jetzt mal ins unreine:
- Wer soetwas macht, der sollte sich bewust sein, dass es um komplexere Datenbank Veränderungen geht
- Ich hätte jetzt gar nicht damit gerechnet eine Auswertung der vielen SQL Statements zu bekommen
- Dabei sollte maximal am Ende eventuell ein SELECT als finaler Status ausgewertet werden,
  was als Einschränkung im Wiki, mit einem Beispiel, dokumentiert werden sollte.

- Es sollte ein Attribut zur Aktivierung vorhanden sein
- Dadurch wird die Eingabe von "sqlCmd" ohne Prüfung in einer Session an die Datenbank gesendet.
  Okay, wenn Deine §device§ und §reading§ ersetzt werden wäre das ein Zugewinn :-)
- Die Rückmeldung der Datenbank könnte in einem reading erscheinen, ähnlich wie es beim HTTPMOD mit dem httpbody geschieht
- Über userExitFn könnte dann jeder selber die Rückmeldung verifizieren und eventuell mit regex nach Fehlern suchen
Zitat
Deswegen ist so etwas nicht umgesetzt.

Man könnte versuchen ein Splitting über die keywords select, update, etc. vorzunehmen und die entstandenen SQL's der Reihe nach abzuarbeiten. Ohne Ergebnisse oder Readings zurückzugeben.

Das wäre eine neue Implementierung die es noch nicht gibt.
Damit würde DbRep schon fast zu einer SQL Terminal Session erweitert werden. Eine Auslagerung als "DbTerm" um den Modul Code zu verschlanken wäre ja auch denkbar,
dafür reichen aber meine Programmierkenntnisse nicht aus.

1) Was ich noch nicht probiert habe wäre eine SQL Procedur aufzurufen. Würde das im sqlCmd gehen?

2) Komme ich durch die usrExitFn irgendwie an das sqlCmd, um es durch die weiter vorne beschriebene sqlformat.org wieder zu reformatieren?

VG  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Dezember 2022, 08:59:54
Moin Christian,

eine grundlegende Schwierigkeit ist, dass wir nach den Vorgaben des DBI Interface Moduls implemetieren und dort keine solche Batchverarbeitung vorgesehen ist, zumindest habe ich keine gefunden.
D.h. alles muß als Einzelstatements den entsprechenden DBI Konstrukten übergeben werden.
Wenn du Spaß daran hast, kannst du dir über die Feiertage ja mal die Doku reinziehen-> https://metacpan.org/pod/DBI
Vllt. findest du ja etwas.

Es gibt noch diverse DBI Erweiterungen über Module wo sich solche Möglichkeiten verstecken könnten. Ein Übersicht findet man hier: https://metacpan.org/search?q=DBIx

Interessant könnte z.B. das sein: https://metacpan.org/pod/DBIx::DWIW
- Robust and simple DBI wrapper to Do What I Want (DWIW)

Zitat
1) Was ich noch nicht probiert habe wäre eine SQL Procedur aufzurufen. Würde das im sqlCmd gehen?
Glaube ich aktuell nicht. Wäre aber implementierbar wenn ich weiß wie man per DBI an eine Prozedur rankommt.
Evtl. über eines der oben verlinkten Zusatzmodule.

Zitat
2) Komme ich durch die usrExitFn irgendwie an das sqlCmd, um es durch die weiter vorne beschriebene sqlformat.org wieder zu reformatieren?
Aktuell nicht. Aber ich glaube das könnte ich implementieren.
Es gibt intern bereits ein (in Ansätzen  ;) ) formatiertes Hash welches bereits ausgeführte SQL's speichert sofern man die SQL-Historie eingeschaltet hat.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 11:49:31
Zitat von: DS_Starter am 21 Dezember 2022, 08:59:54
Zitat
    1) Was ich noch nicht probiert habe wäre eine SQL Procedur aufzurufen. Würde das im sqlCmd gehen?
Glaube ich aktuell nicht. Wäre aber implementierbar wenn ich weiß wie man per DBI an eine Prozedur rankommt.
Evtl. über eines der oben verlinkten Zusatzmodule.
Hallo Heiko,

ein Proceduraufruf funktioniert und liefert die Anzahl Zeilen des ersten SELECT zurück.

defmod LogDBRep_PV_prognose DbRep LogDB
attr LogDBRep_PV_prognose DbLogExclude .*
attr LogDBRep_PV_prognose allowDeletion 0
attr LogDBRep_PV_prognose comment Version 2022.12.21 11:00
attr LogDBRep_PV_prognose room System
attr LogDBRep_PV_prognose verbose 0

setstate LogDBRep_PV_prognose done
setstate LogDBRep_PV_prognose 2022-12-21 11:45:55 SqlResultRow_1 5839
setstate LogDBRep_PV_prognose 2022-12-21 11:45:55 sqlCmd call dwd_load(12);;
setstate LogDBRep_PV_prognose 2022-12-21 11:45:55 sqlResultNumRows 5839
setstate LogDBRep_PV_prognose 2022-12-21 11:45:55 state done

Damit könnte ich jetzt erstmal als work around leben, wobei ein Scannen des call Aufrufs als SELECT noch etwas schöner wäre.

VG   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Dezember 2022, 12:03:25
Es gibt ein Modul DBIx::ProcedureCall -> https://metacpan.org/pod/DBIx::ProcedureCall

Kann den Use Case jetzt nicht übersehen, aber in der Erläuterung zum Modul steht:

Zitat
Dieses Modul bietet eine bequeme Möglichkeit, Stored Procedures von Perl aus aufzurufen, indem es Wrapper-Subroutinen erstellt, die die erforderlichen SQL-Anweisungen erzeugen, Parameter binden und die Abfrage ausführen.

Obwohl die Schnittstelle dieses Moduls datenbankunabhängig ist, werden derzeit nur Oracle und PostgreSQL unterstützt.
....
Das Modul soll eine extrem einfache Schnittstelle zu den gängigsten Formen von gespeicherten Prozeduren bieten. Es wird nicht in der Lage sein, sehr komplexe Fälle zu behandeln. Das ist nicht das Ziel, wenn es 90% der handgeschriebenen SQL- und Bind-Aufrufe eliminieren kann, bin ich zufrieden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 12:37:10
Zitat von: DS_Starter am 21 Dezember 2022, 12:03:25
Es gibt ein Modul DBIx::ProcedureCall -> https://metacpan.org/pod/DBIx::ProcedureCall

Kann den Use Case jetzt nicht übersehen, aber in der Erläuterung zum Modul steht:
Wie gesagt, ein call einer Procedur geht auch jetzt schon, nur die Rückmeldung wird nicht in einem reading geliefert.
Ich sehe aber "SqlResultRow_1 5839" was ja auch schon mal was ist :-)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Dezember 2022, 12:50:45
Probiere mal die V 8.50.8 aus meinem contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 13:25:30
Zitat von: DS_Starter am 21 Dezember 2022, 12:50:45
Probiere mal die V 8.50.8 aus meinem contrib.
Puh,
zum Glück hatte ich schon das Datenaufkommen reduziert :-) :-)


Internals:
   CFGFN     
   DATABASE   fhem
   DEF        LogDB
   FUUID      63a1d5db-f33f-61a8-a5da-bba48bb7336b3fec
   FVERSION   93_DbRep.pm:v1.1.1-s26865/2022-12-21
   LASTCMD    sqlCmd call dwd_load(curdate());
   MODEL      Client
   NAME       LogDBRep_PV_prognose
   NOTIFYDEV  global,LogDBRep_PV_prognose
   NR         741431
   NTFY_ORDER 50-LogDBRep_PV_prognose
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   eventCount 24
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     ALL PRIVILEGES,USAGE
     IDRETRIES  2
     MINTS      2019-04-03 00:23:42
     PACKAGE    main
     VERSION    8.50.5
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1671550427.75645
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2022-12-21 13:23:08   SqlResultRow_0001 MYDATETIME|MYTIMESTAMP|YEAR|MONTH|DAY|HOUR|TTT|DD|VV|N|NEFF|R101|RRS1C|SUND|RAD1H|SUND1|SUNAZ|SUNALT|YIELD|FORECAST|FORECAST1|FORECAST2|FORECAST3|FORECAST4|FORECAST5
     2022-12-21 13:23:08   SqlResultRow_0002 2021-11-21 06:00:00|1637474400|2021|11|21|6|0|0|0|0|0|0|0|0|0|0|101.7|-16.3|0|0|0|0|0|0|0
     2022-12-21 13:23:08   SqlResultRow_0003 2021-11-21 07:00:00|1637478000|2021|11|21|7|0|0|0|0|0|0|0|0|0|0|112.6|-7.1|0|0|0|0|0|0|0
< snip >
     2022-12-21 13:23:08   SqlResultRow_1449 2022-12-21 13:00:00|1671627600|2022|12|21|13|9.2|204|10400|92|92|204|0|0|270|60|190.4|16.1|45|0|0|0|0|0|0
     2022-12-21 13:23:08   sqlCmd          call dwd_load(curdate());
     2022-12-21 13:23:08   sqlResultNumRows 1448
     2022-12-21 13:23:08   state           done
Attributes:
   DbLogExclude .*
   allowDeletion 0
   comment    Version 2022.12.21 12:00
   room       System
   verbose    0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Dezember 2022, 13:26:36
 :D ... sonst wären es eben 5839 Zeilen

brauchbar ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 13:29:31
Zitat von: DS_Starter am 21 Dezember 2022, 13:26:36
:D ... sonst wären es eben 5839 Zeilen
Musst Du eigentlich nicht arbeiten, weil Du meistens so schnell bist?  :-)
Das würde für mich so passen, es führen ja viele Wege nach Rom...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Dezember 2022, 13:31:49
Mittagspause ... und es war nur eine kleine Änderung.
Manchmal geht das  ;)

Probiere noch ein bisschen. Heute Abend würde ich die V ins Repo laden wenn es soweit passt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 13:37:50
Zitat von: DS_Starter am 21 Dezember 2022, 13:31:49
Mittagspause ... und es war nur eine kleine Änderung.
Manchmal geht das  ;)

Probiere noch ein bisschen. Heute Abend würde ich die V ins Repo laden wenn es soweit passt.
Ich habe noch auf die Schnelle eine Bremse für das Anzeigen eingebaut [show|none] als Parameter

call dwd_load(curdate(),'none');

In der Procedure kann man ja auch im SQL mit IF THEN ELSE arbeiten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Dezember 2022, 13:42:39
Ich glaube ich muß mich mal wieder mit DbRep befassen wenn ich mit der DbLog V 5 durch bin (verfolgst du wahrscheinlich auch).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Dezember 2022, 13:45:55
Zitat von: DS_Starter am 21 Dezember 2022, 13:42:39
Ich glaube ich muß mich mal wieder mit DbRep befassen wenn ich mit der DbLog V 5 durch bin (verfolgst du wahrscheinlich auch).
Na klar, ab jetzt (https://forum.fhem.de/index.php/topic,130588.0.html)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Dezember 2022, 16:47:12
Ich habe im Wiki (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Ermittlung_des_monatlichen_und_durchschnittlichen_Gasverbrauches_mit_Vaillant_und_eBusd_MQTT) ein Beispiel zur Ermittlung des monatlichen und durchschnittlichen Gasverbrauches mit Vaillant und eBusd MQTT mit einem einzelnen DbRep eingestellt. Interessant für User ist vllt. in diesem Beispiel die Verwendung der Attribute userExitFn und stateFormat.

Schöne Feiertage @all.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 28 Dezember 2022, 18:45:40
Hier ist ja in letzter Zeit einiges an recht komplexen SQL queries veröffentlicht worden. Da traue ich mich, obwohl immer noch im SQL-Anfänger-Zustand, auch mal etwas beizutragen.

Hintergrund: Im fronthem/SmartVISU Unterforum wurde kürzlich  (https://forum.fhem.de/index.php/topic,118668.msg1252219.html#msg1252219) diskutiert, wie am besten gewichtete Mittelwerte von Zeitreihen in das fronthem Interface 99_fronthemUtils.pm integriert werden können. Bisher war dort die Funktion 'get ... webchart ...' aus dem DbLog Modul verwendet worden, die aber nur ungewichtet mittelt. Ein gewichtetes Mitteln bietet zwar das DbRep Modul, aber ich habe keine Ahnung, wie die (non-Blocking) Funktion 'set ... averageValue...' in z.B. 99_fronthemUtils.pm eingebunden werden kann.
Außerdem fiel mir auf, dass diese Funktion so implementiert ist, dass bei einer Einteilung eines längeren Daten-Zeitraums in einzelne Mittelungsintervalle die jeweils letzten Datenpunkte eines Mittelungsintervalls verworfen werden (was kein großes Problem bei vielen Daten pro Intervall ist, aber bei geringer Datendichte doch auffallen könnte).

Aus diesen Gründen bin ich dann bei einer anderen Lösung gelandet, bei der das Mitteln ausschließlich in SQL stattfindet und die mit 'sqlCmdBlocking' ausgeführt wird. Es kann über Minuten, Viertelstunden, Stunden, Vierteltage, Tage, Wochen, Monate, Vierteljahre oder Jahre gemittelt werden:
--### Mittelwertbildung, Variante 3
--### Bei dieser Variante wird beim gewichteten Mitteln der Wert am Ende des Mittelungsintervalls auf beide Intervall verteilt.
--### Der Wert wird gemäß dem zeitlichen Anteil an den beiden Intervallen aufgeteilt.
--### Mögliche Werte für @sortformat: minute, qhour, hour, qday, day, week, month, qyear, year
SET @sortformat="hour", @weighted="yes", @device = "E_Zaehler", @reading = "power", @start = "2022-10-29 00:00:00", @end = "2022-10-29 05:00:00";
SELECT
   avgtim,
   CASE @weighted
      WHEN "yes" THEN CAST((SUM(val * weight)/SUM(weight)) AS DECIMAL(12,4))
      ELSE CAST(sum(val) / count(val) AS DECIMAL(12,4))
   END AS avrg
FROM (
   SELECT 
      tim,
      avgtim,
      CASE @sortformat WHEN "week"
         THEN date_format(tim, "%Y-%u 00:00:00")
         ELSE avgtim
      END AS grouptim,
      CASE
         WHEN avgtim!=preavgtim THEN to_seconds(nexttim)-to_seconds(avgtim)
         WHEN avgtim!=nextavgtim THEN to_seconds(nextavgtim)-to_seconds(tim)
         ELSE to_seconds(nexttim)-to_seconds(tim)
      END AS weight,   
      CASE
         WHEN avgtim!=preavgtim THEN
            CASE @weighted WHEN "yes"
               THEN CASE WHEN avgtim!=nextavgtim
                     THEN (preval*(to_seconds(tim)-to_seconds(avgtim)) + val*(to_seconds(nextavgtim)-to_seconds(tim)))/(to_seconds(nextavgtim)-to_seconds(avgtim))
                     ELSE (preval*(to_seconds(tim)-to_seconds(avgtim)) + val*(to_seconds(nexttim)-to_seconds(tim)))/(to_seconds(nexttim)-to_seconds(avgtim))
                  END
               ELSE val
            END
         ELSE val
      END AS val
   FROM (
      SELECT
         tim,
         nexttim,
         val,
         preval,
         avgtim,
         LAG(avgtim) OVER (ORDER BY tim) AS preavgtim,
         LEAD(avgtim) OVER (ORDER BY tim) AS nextavgtim
      FROM (
         SELECT
            timestamp AS tim,
            LEAD(timestamp) OVER (ORDER BY timestamp) AS nexttim,
            value AS val,
            LAG(value) OVER (ORDER BY timestamp) AS preval,
         CASE @sortformat
            WHEN "minute" THEN date_format(timestamp, "%Y-%m-%d %H:%i:00")
            WHEN "qhour"  THEN concat(date_format(timestamp, "%Y-%m-%d %H:"),LPAD(15*(date_format(timestamp,"%i") div 15),2,"0"),":00")
            WHEN "hour"   THEN date_format(timestamp, "%Y-%m-%d %H:00:00")
            WHEN "qday"   THEN concat(date_format(timestamp, "%Y-%m-%d "),LPAD(6*(date_format(timestamp, "%H") div 6),2,"0"),":00:00")
            WHEN "day"    THEN date_format(timestamp, "%Y-%m-%d 00:00:00")
            WHEN "week"   THEN date_format(timestamp, "%Y-%m-%d 00:00:00")
            WHEN "month"  THEN date_format(timestamp, "%Y-%m-01 00:00:00")
            WHEN "qyear"  THEN concat(date_format(timestamp, "%Y-"),LPAD(3*(date_format(timestamp, "%m") div 3),2,"0"),"-01 00:00:00")
         ELSE date_format(timestamp, "%Y-01-01 00:00:00")
         END AS avgtim         
         FROM
            history WHERE TIMESTAMP BETWEEN @start AND @end AND DEVICE LIKE @device AND READING LIKE @reading ORDER BY timestamp
      ) select3
   ) select2
) select1 GROUP BY grouptim


Vielleicht ist dieses SQL-Script ja für den einen oder anderen von Nutzen.

Oder auch dieses (Aufteilung eines Gesamtzeitraums in 'count' Intervalle ohne Rücksicht auf bestimmte Zeitgrenzen):
--#########################
--###
--### Mittelwertbildung bei Unterteilung des Zeitraums @start...@end in '@count' Teilintervalle:
--###
--#########################
SET @weighted="yes", @device = "E_Zaehler", @reading = "power", @start = "2022-10-29 00:00:00", @end = "2022-10-29 05:00:00", @count = 5;
SELECT
   tim,
   CASE
      WHEN @weighted="yes" THEN
         CAST(sum(val * (to_seconds(nexttim)-to_seconds(tim))) / sum((to_seconds(nexttim)-to_seconds(tim))) AS DECIMAL(12,4))
      ELSE CAST(sum(val) / count(val) AS DECIMAL(12,4))
   END AS avrg
FROM (
   SELECT
      timestamp as tim,
      value as val,
      LEAD(timestamp) over (order by timestamp) nexttim,
      truncate(@count * (to_seconds(timestamp)-to_seconds(@start)) / (to_seconds(@end)-to_seconds(@start)),0)/@count as avgtim
   FROM
      history WHERE TIMESTAMP BETWEEN @start AND @end AND DEVICE LIKE @device AND READING LIKE @reading
) select1 group by avgtim



-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Dezember 2022, 21:28:56
Hallo Franz,

ich finde deinen Beitrag äußerst hilfreich als Anregung und Nachnutzung.
Es ist immer schade wenn dieses Wissen im Forum Universum versiegt.

Könntest du einen Beitrag in diesem Wiki-Artikel (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#gewichtete_Mittelwerte_von_Zeitreihen_.28MySQL.29) hinterlegen ?
Das wäre super, ich habe ihn gerade dafür angelegt.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 31 Dezember 2022, 15:54:50
Zitat von: DS_Starter am 28 Dezember 2022, 21:28:56
Könntest du einen Beitrag in diesem Wiki-Artikel (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#gewichtete_Mittelwerte_von_Zeitreihen_.28MySQL.29) hinterlegen ?
Ist geschehen, siehe hier (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Gewichtete_Mittelwerte_von_Zeitreihen_.28MySQL.29)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 02 Januar 2023, 12:26:54
Hallo zusammen,
ich arbeite gerade an der Reformatierung von SQL Statements und hätte da mal was für Euch zum ausprobieren.

Hier ist das verwendete HTTPMOD im RAW

defmod SQL_Format HTTPMOD none 0
attr SQL_Format DbLogExclude .*
attr SQL_Format comment Version 2023.01.02 12:00
attr SQL_Format enableCookies 1
attr SQL_Format room System
attr SQL_Format set01Data reindent=1&sql=$val
attr SQL_Format set01ExtractAllJSON 1
attr SQL_Format set01Method POST
attr SQL_Format set01Name 01_SQL_Format
attr SQL_Format set01ParseResponse 1
attr SQL_Format set01TextArg 1
attr SQL_Format set01URL https://sqlformat.org/api/v1/format
attr SQL_Format showBody 0
attr SQL_Format showError 1
attr SQL_Format verbose 0

Aufruf in der FHEM Kommandozeile mit einem Beispiel, oder mit dem SQL Kommando innerhalb des Devices in der set Zeile.

set SQL_Format 01_SQL_Format SELECT * FROM (SELECT h.TIMESTAMP, h.READING, IF (h.READING LIKE '%Rate%' OR h.READING LIKE '%Autarky%', h.VALUE, cast(h.VALUE/1000 AS decimal(6))) AS VALUE FROM history h INNER JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE §device§ AND §reading§ AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1, '-12-31'), '%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()), '-01-01'), '%Y-%m-%d') GROUP BY READING) x1 USING(TIMESTAMP,READING)) WR_1_API UNION ALL SELECT h.TIMESTAMP, concat('WB_0_', h.READING) AS READING, h.VALUE FROM history h INNER JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING LIKE 'lp_%_kWhCounter_Year' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1, '-12-01'), '%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()), '-01-01'), '%Y-%m-%d') GROUP BY READING) WB_1 USING(TIMESTAMP,READING) UNION ALL SELECT h.TIMESTAMP, concat('WB_1_', h.READING) AS READING, h.VALUE FROM history h INNER JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_1' AND READING LIKE 'lp_%_kWhCounter_Year' AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1, '-12-01'), '%Y-%m-%d') AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()), '-01-01'), '%Y-%m-%d') GROUP BY READING) WB_1 USING(TIMESTAMP,READING)

Das Ergebnis sieht dann so aus

SELECT *
FROM
  (SELECT h.TIMESTAMP,
          h.READING,
          IF (h.READING LIKE '%Rate%'
              OR h.READING LIKE '%Autarky%',
                 h.VALUE,
                 cast(h.VALUE/1000 AS decimal(6))) AS VALUE
   FROM history h
   INNER JOIN
     (SELECT max(TIMESTAMP) AS TIMESTAMP,
             READING
      FROM history
      WHERE §device§
        AND §reading§
        AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1, '-12-31'), '%Y-%m-%d')
        AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()), '-01-01'), '%Y-%m-%d')
      GROUP BY READING) x1 USING(TIMESTAMP,READING)) WR_1_API
UNION ALL
SELECT h.TIMESTAMP,
       concat('WB_0_', h.READING) AS READING,
       h.VALUE
FROM history h
INNER JOIN
  (SELECT max(TIMESTAMP) AS TIMESTAMP,
          READING
   FROM history
   WHERE DEVICE = 'WB_0'
     AND READING LIKE 'lp_%_kWhCounter_Year'
     AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1, '-12-01'), '%Y-%m-%d')
     AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()), '-01-01'), '%Y-%m-%d')
   GROUP BY READING) WB_1 USING(TIMESTAMP,READING)
UNION ALL
SELECT h.TIMESTAMP,
       concat('WB_1_', h.READING) AS READING,
       h.VALUE
FROM history h
INNER JOIN
  (SELECT max(TIMESTAMP) AS TIMESTAMP,
          READING
   FROM history
   WHERE DEVICE = 'WB_1'
     AND READING LIKE 'lp_%_kWhCounter_Year'
     AND TIMESTAMP > STR_TO_DATE(CONCAT(YEAR(CURDATE())-1, '-12-01'), '%Y-%m-%d')
     AND TIMESTAMP < STR_TO_DATE(CONCAT(YEAR(CURDATE()), '-01-01'), '%Y-%m-%d')
   GROUP BY READING) WB_1 USING(TIMESTAMP,READING)


VG  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Januar 2023, 12:41:11
Funktioniert  8)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 02 Januar 2023, 13:09:09
Zitat von: DS_Starter am 02 Januar 2023, 12:41:11
Funktioniert  8)
Ich denke, wir sind ein tolles team ;-)
Frohes neues Jahr Euch allen.

EDIT: Das klappt noch nicht, da es asyncron ist :-( und somit das vorherige Ergebnis geholt wird.
   Eventuell könnte da noch jemand helfen.

Und hir noch eine Integration ins DbRep Device, wodurch das formatierte SQL Kommando als userReading "SQL_Format" im DbRep Device erscheint.

attr LogDBRep_Statistic_previous_Year userReadings SQL_Format:sqlCmd.* { CommandSet(undef, "SQL_Format 01_SQL_Format ".ReadingsVal('$NAME','sqlCmd','null')); ReadingsVal('SQL_Format','result','null')}


VG  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Januar 2023, 14:15:31
Zitat
EDIT: Das klappt noch nicht, da es asyncron ist :-( und somit das vorherige Ergebnis geholt wird.
   Eventuell könnte da noch jemand helfen.

userExitFn benutzen:

{
  if ($READING eq "sqlCmd") {
      CommandSet(undef, "SQL_Format 01_SQL_Format ".ReadingsVal($NAME, $READING, 'null'));
      my $ret  = ReadingsVal('SQL_Format', 'result', 'null');
      my $hash = $defs{$NAME};
      readingsBulkUpdate ($hash, 'SQL_Format', $ret);
  }
}
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 02 Januar 2023, 14:25:13
Zitat von: DS_Starter am 02 Januar 2023, 14:15:31
userExitFn benutzen:

{
  if ($READING eq "sqlCmd") {
      CommandSet(undef, "SQL_Format 01_SQL_Format ".ReadingsVal($NAME, $READING, 'null'));
      my $ret  = ReadingsVal('SQL_Format', 'result', 'null');
      my $hash = $defs{$NAME};
      readingsBulkUpdate ($hash, 'SQL_Format', $ret);
  }
}


Da das SQL_Format ja auch von mehreren DbRep aufgerufen werden kann habe ich mir überlegt, dass man mehrere HTTPMOD set einbauen könnte.
Mit diesem userReadings würde das Formatieren gestartet

attr LogDBRep_Statistic_previous_Year userReadings SQL_Format:sqlCmd.* { CommandSet(undef, "SQL_Format ".$NAME." ".ReadingsVal("$NAME","sqlCmd","null"));"waiting on SQL_Format"}


Und im SQL_Format sähe es dann so aus

defmod SQL_Format HTTPMOD none 0
attr SQL_Format DbLogExclude .*
attr SQL_Format comment Version 2023.01.02 14:00
attr SQL_Format enableCookies 1
attr SQL_Format room System
attr SQL_Format set01Data reindent=1&sql=$val
attr SQL_Format set01ExtractAllJSON 1
attr SQL_Format set01Method POST
attr SQL_Format set01Name LogDBRep_Statistic_previous_Year
attr SQL_Format set01OExpr CommandSetReading(undef, "LogDBRep_Statistic_previous_Year SQL_Format ".$val);;$val
attr SQL_Format set01ParseResponse 1
attr SQL_Format set01TextArg 1
attr SQL_Format set01URL https://sqlformat.org/api/v1/format
attr SQL_Format showBody 0
attr SQL_Format showError 1
attr SQL_Format verbose 0

Durch das set01OExpr wird das Formatierte Ergebnis zurück ins entsprechende aufrufende Device geschrieben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Januar 2023, 22:55:22
Hallo Christian,

ich habe eine V ins contrib gestellt welche die Online Formatierung der SQL's automatisch intern macht.
Das klappt gut, aber noch nicht für mehrere SQLs in einem Satz, z.B.
                       SET \@diff=0;
                       SET \@delta=NULL;
                       SELECT t1.TIM....


Da bin ich noch dran. Wenn das alles klappt, führe ich noch ein Attr ein damit man die Online Formatierung einschalten kann wenn man es möchte.

Kannst du mal testen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 10:55:04
Jetzt klappt die Online Formatierung auch mit komplexen, zusammengesetzten Statements.
Liegt in contrib zum Test.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Januar 2023, 11:09:37
Zitat von: DS_Starter am 03 Januar 2023, 10:55:04
Jetzt klappt die Online Formatierung auch mit komplexen, zusammengesetzten Statements.
Liegt in contrib zum Test.
Hallo Heiko,

die set Statements hatten wir doch ins

sqlCmdVars SET @days:=7, @corr:=0.7, @diff:=0, @temp:=0, @device:='WR_1', @reading1:='SW_Total_DC_P_sumOfAllPVInputs', @reading2:='Solar_Calculation_fc0', @readingname:='Solar_Correction_Faktor_auto' ;

gepackt. Ich war bisher immer davon ausgegangen, dass man ein SQL Statement ins sqlCmd packen kann.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 11:12:53
Zitat
Ich war bisher immer davon ausgegangen, dass man ein SQL Stement ins sqlCmd packen kann.
Ja, ist auch richtig so bzw. du hast recht.

Aber soetwas geht schon über sqlCmd:


SET @diff=0;
SET @delta=NULL;
SELECT t1.TIMESTAMP,
       t1.READING,
       t1.VALUE,
       t1.DIFF,
       t1.TIME_DELTA
FROM
  (SELECT TIMESTAMP,READING,
                    VALUE,
                    cast((VALUE-@diff) AS DECIMAL(12, 4)) AS DIFF, @diff:=VALUE AS curr_V, TIMESTAMPDIFF(MINUTE, @delta,TIMESTAMP) AS TIME_DELTA, @delta:=TIMESTAMP AS curr_T
   FROM history
   WHERE §device§
     AND §reading§
     AND TIMESTAMP >= §timestamp_begin§
     AND TIMESTAMP <= §timestamp_end§
   ORDER BY TIMESTAMP) t1;


Meine Antwort "Jetzt klappt die Online Formatierung auch mit komplexen, zusammengesetzten Statements." bezog sich lediglich auf die Online Formatierung mit dem Formatter-Dienst.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Januar 2023, 11:14:40
Zitat von: DS_Starter am 03 Januar 2023, 10:55:04
Jetzt klappt die Online Formatierung auch mit komplexen, zusammengesetzten Statements.
Liegt in contrib zum Test.
Da habe ich Dich jetzt aber ganz schön angeschoben :-) :-) Ist schon schön, wenn es lesbarer wird.
Hast Du es dann jetzt intern direkt bevor das Statement wieder ins sqlCmd geschrieben wird formatiert?

Ich bin noch nicht zum Testen gekommen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Januar 2023, 11:16:46
Zitat von: DS_Starter am 03 Januar 2023, 11:12:53
Ja, ist auch richtig so bzw. du hast recht.

Aber soetwas geht schon über sqlCmd:

< snip >

Meine Antwort "Jetzt klappt die Online Formatierung auch mit komplexen, zusammengesetzten Statements." bezog sich lediglich auf die Online Formatierung mit dem Formatter-Dienst.
Da gibt es wohl auch noch eine split Funktion, ich hatte mir nur den quick win angeschaut und war sehr begeistert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 11:17:41
Zitat
Hast Du es dann jetzt intern direkt bevor das Statement wieder ins sqlCmd geschrieben wird formatiert?
Ja, im Prinzip. Intern passiert im Detail ein bisschen mehr. Betrifft auch sqlCmdHistory und sqlSpecial.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 11:19:28
Zitat
Da gibt es wohl auch noch eine split Funktion
Gibt es, aber die nehme ich nicht. Die bringt keine so schöne Formatierung zurück wie "format".
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Januar 2023, 11:25:41
Übrigens scheint das mit den "set @variable" in zukünftigen Oracle MySQL Versionen irgend wann raus genommen zu werden.
Das scheint dann so gelöst zu werden

SELECT concat(x1.DATE, " ", LPAD(x1.HOUR, 2, 0), ":00:00") AS TIMESTAMP,
                  x1.DATE,
                  x1.HOUR AS HOUR,
              h.READING,
                  h.VALUE,
      @diff:=0,@delta:=NULL                     <<<< also als zusätzliche Spalte in einer Tabelle
           FROM history h
< snip >
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 15:02:16
Das Attr sqlFormatService ist nun eingefügt um den Formatdienst aktivieren zu können.
-> contrib
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 03 Januar 2023, 16:14:47
Moin, und ein nachträgliches Happy New Year.

Es ist ja toll, was hier alles an SQL-Feuerwerk abgebrannt wird. Obwohl ich selbst lieber mit dem Syntax-highlighting von notepad++ arbeite und zu FHEM mit CTRL-C und -V hin- und her springe.
Ich habe aber noch ein anderes Problem: Da ich keine Ahnung habe, wie ich auf das Resultat des nonBlocking sqlCmd in einem externen Modul (konkret: 99_fronthemUtils.pm) zugreifen kann, benutze ich sqlCmdBlocking.
Und das kann nur Queries mit einem ";"
Das geht also z.B.: SET @a=1, @b=2; SELECT * FROM current
Und das geht nicht: "SET @a=1; SET @b=2; SELECT * FROM current"
In sqlCmd geht beides

Gruß
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 03 Januar 2023, 16:38:23
Hallo Franz
Zitat von: alkazaa am 03 Januar 2023, 16:14:47
Moin, und ein nachträgliches Happy New Year.

Es ist ja toll, was hier alles an SQL-Feuerwerk abgebrannt wird. Obwohl ich selbst lieber mit dem Syntax-highlighting von notepad++ arbeite und zu FHEM mit CTRL-C und -V hin- und her springe.
Ich habe aber noch ein anderes Problem: Da ich keine Ahnung habe, wie ich auf das Resultat des nonBlocking sqlCmd in einem externen Modul (konkret: 99_fronthemUtils.pm) zugreifen kann, benutze ich sqlCmdBlocking.
Und das kann nur Queries mit einem ";"
Das geht also z.B.: SET @a=1, @b=2; SELECT * FROM current
Und das geht nicht: "SET @a=1; SET @b=2; SELECT * FROM current"
In sqlCmd geht beides
Das machen wir eigentlich genau so, wenn man aber mal einen Überblich im DbRep haben möchte ist das SQL Statement halt schlecht zu lesen.

Eigentlich sollte es aber wie hier angesprochen funktionieren. (https://forum.fhem.de/index.php/topic,53584.msg1255248.html#msg1255248) Ich habe gerne die Variablen separat im Device.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 03 Januar 2023, 18:15:29
Hallo Christian,
Zitat von: ch.eick am 03 Januar 2023, 16:38:23
Eigentlich sollte es aber wie hier angesprochen funktionieren. (https://forum.fhem.de/index.php/topic,53584.msg1255248.html#msg1255248)
Ja, es funktioniert. (Hab erst jetzt die Contrib Version geladen)
Beim Rumspielen mit meinem 1. Query aus dem Wiki (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Gewichtete_Mittelwerte_von_Zeitreihen_.28MySQL.29) bekomme ich aber eine Fehlermeldung, wenn sqlFormatService= https://sqlformat.org gesetzt ist:
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'val*(to_seconds(nextavgtim)-to_seconds(tim)))/ (to_seconds(nextavgtim)-to_sec...' at line 1 at ./FHEM/93_DbRep.pm line 10880.
Mit sqlFormatService=none läuft es korrekt.

Wenn ich das gesamte Query vorher 'manuell' auf sqlformat.org formatieren lasse und dann in FHEM einsetze und ausführe, läuft es witzigerweise auch korrekt. Ist also kein 'kaputt-formatieren' auf sqlformat.org (Die SET statements waren dabei immer in sqlCmdVars untergebracht).

Ist wohl eher was für Heiko?

Gruß
Franz

EDIT:
Ich glaub, ich hab's gefunden:
Mit verbose5 kriegt man das SQL, das bei der automatischen Formatierung genutzt wird, hier ein Auszug:
          CASE
              WHEN avgtim!=preavgtim THEN CASE @weighted
                                              WHEN "yes" THEN CASE
                                                                  WHEN avgtim!=nextavgtim THEN (preval*(to_seconds(tim)-to_seconds(avgtim)) val*(to_seconds(nextavgtim)-to_seconds(tim)))/ (to_seconds(nextavgtim)-to_seconds(avgtim))
                                                                  ELSE (preval*(to_seconds(tim)-to_seconds(avgtim)) val*(to_seconds(nexttim)-to_seconds(tim)))/ (to_seconds(nexttim)-to_seconds(avgtim))
                                                              END
                                              ELSE val
                                          END
              ELSE val
          END AS val

Die 'manuelle' Formatierung auf sqlformat.org liefert an dieser Stelle das korrekte Ergebnis ohne die + Zeichen vor val  zu verschlucken:
          CASE
              WHEN avgtim!=preavgtim THEN CASE @weighted
                                              WHEN "yes" THEN CASE
                                                                  WHEN avgtim!=nextavgtim THEN (preval*(to_seconds(tim)-to_seconds(avgtim)) + val*(to_seconds(nextavgtim)-to_seconds(tim)))/ (to_seconds(nextavgtim)-to_seconds(avgtim))
                                                                  ELSE (preval*(to_seconds(tim)-to_seconds(avgtim)) + val*(to_seconds(nexttim)-to_seconds(tim)))/ (to_seconds(nexttim)-to_seconds(avgtim))
                                                              END
                                              ELSE val
                                          END
              ELSE val
          END AS val
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 20:48:47
Zitat
Die 'manuelle' Formatierung auf sqlformat.org liefert an dieser Stelle das korrekte Ergebnis ohne die + Zeichen vor val  zu verschlucken:

Das war mein Fehler. Hatte die Daten nicht urlEncoded/Decoded.
Sollte jetzt passen. (contrib)


Zitat
Ich habe aber noch ein anderes Problem: Da ich keine Ahnung habe, wie ich auf das Resultat des nonBlocking sqlCmd in einem externen Modul (konkret: 99_fronthemUtils.pm) zugreifen kann, benutze ich sqlCmdBlocking.
Und das kann nur Queries mit einem ";"
....
Ich habe sqlCmdBlocking wohl etwas vernachlässigt.
Werde mir das anschauen und auf das Level von sqlCmd heben.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 Januar 2023, 23:06:21
Habe sqlCmdBlocking ausgebaut und verarbeitet jetzt MySQL Session Variablen, PRAGMA wie sqlCmd.
-> contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 04 Januar 2023, 02:47:27
Ich muss mal in die Niederungen der SQL Novizen absteigen.

Ich wollte mit DBRep und set <name> changeValue old="<alter String>" new="<neuer String>" Änderungen im Feld UNIT vornehmen.
Dabei fiel mir auf, dass die CommandRef und Modul-Hilfe einen kleinen Fehler in den Beispielen enthalten.

In den Beispielen fehlt überall old= und new=  ::) (ohne sieht zwar schöner aus, klappt aber nicht).
Ein per Copy-Paste testhalber verwendetes set <name> changeValue "OL","12 OL" endet mit einer (aussagekräftigen) Fehlermeldung:
           Both entries old="old string" new="new string" are needed

Bei Gelegenheit.....

ZitatchangeValue - ändert den gespeicherten Wert eines Readings. Ist die Selektion auf bestimmte Device/Reading-Kombinationen durch die Attribute device bzw. reading beschränkt, werden sie genauso berücksichtigt wie gesetzte Zeitgrenzen (Attribute time.*).
Fehlen diese Beschränkungen, wird die gesamte Datenbank durchsucht und der angegebene Wert geändert.

    Syntax:
    set <name> changeValue old="<alter String>" new="<neuer String>"

    "String" kann sein:
    <alter String> :    
    ein einfacher String mit/ohne Leerzeichen, z.B. "OL 12"
    ein String mit Verwendung von SQL-Wildcard, z.B. "%OL%"
       
    <neuer String> :    
    ein einfacher String mit/ohne Leerzeichen, z.B. "12 kWh"
    Perl Code eingeschlossen in {"..."} inkl. Quotes, z.B. {"($VALUE,$UNIT) = split(" ",$VALUE)"}
       Dem Perl-Ausdruck werden die Variablen $VALUE und $UNIT übergeben. Sie können innerhalb
       des Perl-Code geändert werden. Der zurückgebene Wert von $VALUE und $UNIT wird in dem Feld
       VALUE bzw. UNIT des Datensatzes gespeichert.


    Beispiele:
    set <name> changeValue "OL","12 OL"
    # der alte Feldwert "OL" wird in "12 OL" geändert.

    set <name> changeValue "%OL%","12 OL"
    # enthält das Feld VALUE den Teilstring "OL", wird es in "12 OL" geändert.

....usw.
   
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Januar 2023, 08:38:14
Moin,

danke Ralf.
Bin ja gerade am bauen ... erledige ich gleich mit.

EDIT: ist drin -> contrib

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 18:11:57
Noch was..     zum FVERSION 93_DbRep.pm:v8.50.4-s26650/2022-11-04

Ich will Daten reduzieren und Mittelwerte bilden. "set RepDevice reduceLog average" bildet ja nur ein arith. Mittel.

Daher habe ich mir mal zum Test mit "set RepDevice averageValue display" die Sache angesehen (Auswahl für einen Tag).
(mit aggregation=hour und averageCalcForm=avgArithmeticMean / avgTimeWeightMean)

"avgArithmeticMean" liefert in den Readings ein Ergebnis. "avgTimeWeightMean" einfach nur "done".

Log vom "avgTimeWeightMean"
2023.01.05 17:59:21.438 4: DbRep DBRep2_MT - -------- New selection ---------
2023.01.05 17:59:21.439 4: DbRep DBRep2_MT - Command: averageValue display
2023.01.05 17:59:21.441 4: DbRep DBRep2_MT - FullDay option: 0
2023.01.05 17:59:21.442 4: DbRep DBRep2_MT - Timestamp begin human readable: 2022-06-16 00:00:00
2023.01.05 17:59:21.443 4: DbRep DBRep2_MT - Timestamp end human readable: 2022-06-16 23:59:59
2023.01.05 17:59:21.456 4: DbRep DBRep2_MT - Aggregation: hour
2023.01.05 17:59:21.704 4: DbRep DBRep2_MT - Database connect - user: fhemuser, UTF-8 option set: yes
2023.01.05 17:59:21.712 4: DbRep DBRep2_MT - averageValue calculation sceme: avgTimeWeightMean
2023.01.05 17:59:21.722 2: DbRep DBRep2_MT -


Log vom "avgArithmeticMean" sieht gut aus
2023.01.05 17:58:13.976 4: DbRep DBRep2_MT - -------- New selection ---------
2023.01.05 17:58:13.977 4: DbRep DBRep2_MT - Command: averageValue display
2023.01.05 17:58:13.979 4: DbRep DBRep2_MT - FullDay option: 0
2023.01.05 17:58:13.980 4: DbRep DBRep2_MT - Timestamp begin human readable: 2022-06-16 00:00:00
2023.01.05 17:58:13.981 4: DbRep DBRep2_MT - Timestamp end human readable: 2022-06-16 23:59:59
2023.01.05 17:58:13.993 4: DbRep DBRep2_MT - Aggregation: hour
2023.01.05 17:58:14.215 4: DbRep DBRep2_MT - Database connect - user: fhemuser, UTF-8 option set: yes
2023.01.05 17:58:14.224 4: DbRep DBRep2_MT - averageValue calculation sceme: avgArithmeticMean
2023.01.05 17:58:14.227 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 00:00:00' AND TIMESTAMP < '2022-06-16 01' ;
2023.01.05 17:58:14.233 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 01' AND TIMESTAMP < '2022-06-16 02' ;
2023.01.05 17:58:14.239 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 02' AND TIMESTAMP < '2022-06-16 03' ;
2023.01.05 17:58:14.245 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 03' AND TIMESTAMP < '2022-06-16 04' ;
2023.01.05 17:58:14.251 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 04' AND TIMESTAMP < '2022-06-16 05' ;
2023.01.05 17:58:14.257 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 05' AND TIMESTAMP < '2022-06-16 06' ;
2023.01.05 17:58:14.263 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 06' AND TIMESTAMP < '2022-06-16 07' ;
2023.01.05 17:58:14.269 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 07' AND TIMESTAMP < '2022-06-16 08' ;
2023.01.05 17:58:14.275 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 08' AND TIMESTAMP < '2022-06-16 09' ;
2023.01.05 17:58:14.280 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 09' AND TIMESTAMP < '2022-06-16 10' ;
2023.01.05 17:58:14.285 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 10' AND TIMESTAMP < '2022-06-16 11' ;
2023.01.05 17:58:14.291 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 11' AND TIMESTAMP < '2022-06-16 12' ;
2023.01.05 17:58:14.295 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 12' AND TIMESTAMP < '2022-06-16 13' ;
2023.01.05 17:58:14.301 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 13' AND TIMESTAMP < '2022-06-16 14' ;
2023.01.05 17:58:14.306 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 14' AND TIMESTAMP < '2022-06-16 15' ;
2023.01.05 17:58:14.310 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 15' AND TIMESTAMP < '2022-06-16 16' ;
2023.01.05 17:58:14.315 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 16' AND TIMESTAMP < '2022-06-16 17' ;
2023.01.05 17:58:14.320 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 17' AND TIMESTAMP < '2022-06-16 18' ;
2023.01.05 17:58:14.325 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 18' AND TIMESTAMP < '2022-06-16 19' ;
2023.01.05 17:58:14.330 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 19' AND TIMESTAMP < '2022-06-16 20' ;
2023.01.05 17:58:14.335 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 20' AND TIMESTAMP < '2022-06-16 21' ;
2023.01.05 17:58:14.339 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 21' AND TIMESTAMP < '2022-06-16 22' ;
2023.01.05 17:58:14.344 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 22' AND TIMESTAMP < '2022-06-16 23' ;
2023.01.05 17:58:14.349 4: DbRep DBRep2_MT - SQL execute: SELECT AVG(VALUE) FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 23' AND TIMESTAMP <= '2022-06-16 23:59:59' ;
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2023, 18:27:34
"avgTimeWeightMean" benötigt pro aggregation-Periode (also pro Stunde bei dir) mindestens zwei Messpunkte.
Ist das gegeben ?

verbose = 5 zeigt die die Details wie ein Beispiel von mir:

2023.01.05 18:23:41.452 4: DbRep Rep.CPU - -------- New selection ---------
2023.01.05 18:23:41.452 4: DbRep Rep.CPU - Command: averageValue display
2023.01.05 18:23:41.453 4: DbRep Rep.CPU - timeDiffToNow - year: , day: , hour: 4, min: , sec:
2023.01.05 18:23:41.453 4: DbRep Rep.CPU - startMonth: 0 endMonth: 0 lastleapyear: 0 baseYear: 2023 diffdaylight:0 isdaylight:0
2023.01.05 18:23:41.454 4: DbRep Rep.CPU - FullDay option: 0
2023.01.05 18:23:41.454 4: DbRep Rep.CPU - Time difference to current time for calculating Timestamp begin: 14401 sec
2023.01.05 18:23:41.455 5: DbRep Rep.CPU - Timestamp begin epocheseconds: 1672925020.45493
2023.01.05 18:23:41.455 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-01-05 14:23:40
2023.01.05 18:23:41.456 5: DbRep Rep.CPU - Timestamp end epocheseconds: 1672939421
2023.01.05 18:23:41.456 4: DbRep Rep.CPU - Timestamp end human readable: 2023-01-05 18:23:41
...........
2023.01.05 18:23:41.460 4: DbRep Rep.CPU - Aggregation: hour
2023.01.05 18:23:41.470 5: DbRep Rep.CPU - BlockingCall with PID "13694" started
2023.01.05 18:23:41.479 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.05 18:23:41.482 4: DbRep Rep.CPU - averageValue calculation sceme: avgTimeWeightMean
............
............
............
2023.01.05 18:23:41.490 4: DbRep Rep.CPU - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 14:23:40' AND TIMESTAMP < '2023-01-05 15' ORDER BY TIMESTAMP ASC;
2023.01.05 18:23:41.492 5: DbRep Rep.CPU - data element: 2023-01-05 14:25:12_ESC_0.0
2023.01.05 18:23:41.493 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.493 5: DbRep Rep.CPU - data element: 2023-01-05 14:26:13_ESC_0.0
2023.01.05 18:23:41.494 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.494 5: DbRep Rep.CPU - data element: 2023-01-05 14:27:14_ESC_0.0
2023.01.05 18:23:41.494 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.495 5: DbRep Rep.CPU - data element: 2023-01-05 14:28:15_ESC_0.0
2023.01.05 18:23:41.495 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.496 5: DbRep Rep.CPU - data element: 2023-01-05 14:29:16_ESC_0.0
2023.01.05 18:23:41.496 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.496 5: DbRep Rep.CPU - data element: 2023-01-05 14:30:17_ESC_0.0
2023.01.05 18:23:41.497 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.497 5: DbRep Rep.CPU - data element: 2023-01-05 14:31:18_ESC_0.0
2023.01.05 18:23:41.497 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.498 5: DbRep Rep.CPU - data element: 2023-01-05 14:32:19_ESC_0.0
2023.01.05 18:23:41.498 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.499 5: DbRep Rep.CPU - data element: 2023-01-05 14:33:20_ESC_0.0
2023.01.05 18:23:41.499 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.499 5: DbRep Rep.CPU - data element: 2023-01-05 14:34:21_ESC_0.0
2023.01.05 18:23:41.500 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.500 5: DbRep Rep.CPU - data element: 2023-01-05 14:35:22_ESC_0.0
2023.01.05 18:23:41.501 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 0.0, twm: 0
2023.01.05 18:23:41.501 5: DbRep Rep.CPU - data element: 2023-01-05 14:36:23_ESC_1920.2
2023.01.05 18:23:41.501 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1920.2, twm: 54.9142991092358
2023.01.05 18:23:41.502 5: DbRep Rep.CPU - data element: 2023-01-05 14:37:24_ESC_331.8
2023.01.05 18:23:41.502 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 331.8, twm: 9.48888888888889
2023.01.05 18:23:41.503 5: DbRep Rep.CPU - data element: 2023-01-05 14:38:25_ESC_1885.3
2023.01.05 18:23:41.503 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1885.3, twm: 53.9162212845757
2023.01.05 18:23:41.503 5: DbRep Rep.CPU - data element: 2023-01-05 14:39:26_ESC_1849.5
2023.01.05 18:23:41.504 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1849.5, twm: 52.8924050632911
2023.01.05 18:23:41.504 5: DbRep Rep.CPU - data element: 2023-01-05 14:40:27_ESC_1833.4
2023.01.05 18:23:41.505 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1833.4, twm: 52.4319737458978
2023.01.05 18:23:41.505 5: DbRep Rep.CPU - data element: 2023-01-05 14:41:28_ESC_1550.3
2023.01.05 18:23:41.505 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1550.3, twm: 44.3358180965776
2023.01.05 18:23:41.506 5: DbRep Rep.CPU - data element: 2023-01-05 14:42:29_ESC_1880.8
2023.01.05 18:23:41.506 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1880.8, twm: 53.7875293014534
2023.01.05 18:23:41.507 5: DbRep Rep.CPU - data element: 2023-01-05 14:43:30_ESC_1809.1
2023.01.05 18:23:41.507 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1809.1, twm: 51.737037037037
2023.01.05 18:23:41.507 5: DbRep Rep.CPU - data element: 2023-01-05 14:44:30_ESC_1061.8
2023.01.05 18:23:41.508 5: DbRep Rep.CPU - time sum: 2133, delta time: 60, value: 1061.8, twm: 29.8677918424754
2023.01.05 18:23:41.508 5: DbRep Rep.CPU - data element: 2023-01-05 14:45:31_ESC_1612.3
2023.01.05 18:23:41.509 5: DbRep Rep.CPU - time sum: 2133, delta time: 61, value: 1612.3, twm: 46.108907641819
.........


Ich ergänze die Hilfe zu dem Attribut.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 19:14:52
Das check ich mal.
Wenn nur ein Teil der Intervalle zwei oder mehr Messpunkte hat, läuft das dann korrekt durch (nur für die Intervalle mit weniger MPs nicht)?

Gruß Ralf

Edit ja sind genug Werte da:

2022-06-16_00__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_00 - 2023-01-05 17:46:12 0 Werte
2022-06-16_01__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_01 82 2023-01-05 17:46:12 4 Werte
2022-06-16_02__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_02 83 2023-01-05 17:46:12 8 Werte
2022-06-16_03__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_03 83 2023-01-05 17:46:12 6 Werte
2022-06-16_04__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_04 83 2023-01-05 17:46:12 8 Werte
2022-06-16_05__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_05 83 2023-01-05 17:46:12 ....
2022-06-16_06__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_06 83 2023-01-05 17:46:12
2022-06-16_07__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_07 83 2023-01-05 17:46:12
2022-06-16_08__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_08 82 2023-01-05 17:46:12
2022-06-16_09__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_09 80 2023-01-05 17:46:12
2022-06-16_10__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_10 67 2023-01-05 17:46:12
2022-06-16_11__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_11 - 2023-01-05 17:46:12
2022-06-16_12__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_12 54 2023-01-05 17:46:12
2022-06-16_13__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_13 - 2023-01-05 17:46:12
2022-06-16_14__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_14 - 2023-01-05 17:46:12
2022-06-16_15__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_15 - 2023-01-05 17:46:12
2022-06-16_16__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_16 - 2023-01-05 17:46:12
2022-06-16_17__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_17 - 2023-01-05 17:46:12
2022-06-16_18__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_18 677 2023-01-05 17:46:12
2022-06-16_19__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_19 - 2023-01-05 17:46:12
2022-06-16_20__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_20 - 2023-01-05 17:46:12
2022-06-16_21__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_21 - 2023-01-05 17:46:12
2022-06-16_22__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_22 - 2023-01-05 17:46:12
2022-06-16_23__MQTT2_ESP_2__MT691_power__AVGAM__2022-06-16_23 - 2023-01-05 17:46:12
state done

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2023, 19:16:42
Zitat
Wenn nur ein Teil der Intervalle zwei oder mehr Messpunkte hat, läuft das dann korrekt durch (nur für die Intervalle mit weniger MPs nicht)?
Ja, genau.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 19:19:27
siehe oben
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2023, 19:21:58
Lass doch mal mit verbose 5 laufen wie in meinem Beispiel.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 19:22:23
Ein Versuch um 1:10 Uhr zu starten (also ein Intervall mit 4 Werten) bringt keine Änderung.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 05 Januar 2023, 19:25:08
Mir ist als vermutlicher bug schon früher aufgefallen (Sorry, dass ich's noch nicht gemeldet hatte, schlicht und einfach vergessen):
Wenn bei aggragation period = hour der timestamp_end auf volle Stunde gesetzt ist, passiert nix.

Setz mal auf hh:59:59 statt hh:00:00

-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 19:33:53
Der Einwand von Franz triff m.M. nicht zu.

Hier mein Ergebnis

=> erster Versuch 1:10 Uhr bis 23:59 Uhr, kein Ergebnis, ich hoffe der Log ist nicht zu lang
=> zweiter Versuch 1:10 Uhr bis 04:59 Uhr, mit Ergebnis, alle da Intervalle mit Daten

2. Versuch

2023.01.05 19:26:34.176 4: DbRep DBRep2_MT - -------- New selection ---------
2023.01.05 19:26:34.177 4: DbRep DBRep2_MT - Command: averageValue display
2023.01.05 19:26:34.179 4: DbRep DBRep2_MT - FullDay option: 0
2023.01.05 19:26:34.180 5: DbRep DBRep2_MT - Timestamp begin epocheseconds: 1655334300
2023.01.05 19:26:34.180 4: DbRep DBRep2_MT - Timestamp begin human readable: 2022-06-16 01:05:00
2023.01.05 19:26:34.181 5: DbRep DBRep2_MT - Timestamp end epocheseconds: 1655348340
2023.01.05 19:26:34.181 4: DbRep DBRep2_MT - Timestamp end human readable: 2022-06-16 04:59:00
2023.01.05 19:26:34.182 5: DbRep DBRep2_MT - weekday start for selection: Do  ->  wdadd: 345600
2023.01.05 19:26:34.183 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 01:05:00 2022" to "Thu Jun 16 02:05:00 2022")
2023.01.05 19:26:34.184 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 02:05:00 2022" to "Thu Jun 16 03:05:00 2022")
2023.01.05 19:26:34.185 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 03:05:00 2022" to "Thu Jun 16 04:05:00 2022")
2023.01.05 19:26:34.186 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 04:05:00 2022" to "Thu Jun 16 05:05:00 2022")
2023.01.05 19:26:34.187 4: DbRep DBRep2_MT - Aggregation: hour
2023.01.05 19:26:34.213 5: DbRep DBRep2_MT - BlockingCall with PID "1755" started
2023.01.05 19:26:34.420 4: DbRep DBRep2_MT - Database connect - user: fhemuser, UTF-8 option set: yes
2023.01.05 19:26:34.428 4: DbRep DBRep2_MT - averageValue calculation sceme: avgTimeWeightMean
2023.01.05 19:26:34.429 5: DbRep DBRep2_MT - IsTimeSet: 1, IsAggrSet: 1
2023.01.05 19:26:34.430 5: DbRep DBRep2_MT - Timestamp-Array:
2022-06-16_01#2022-06-16 01:05:00#2022-06-16 02 2022-06-16_02#2022-06-16 02#2022-06-16 03 2022-06-16_03#2022-06-16 03#2022-06-16 04 2022-06-16_04#2022-06-16 04#2022-06-16 04:59:00
2023.01.05 19:26:34.431 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.432 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.433 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.434 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.444 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.445 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.446 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 01:05:00' AND TIMESTAMP < '2022-06-16 02' ORDER BY TIMESTAMP ASC;
2023.01.05 19:26:34.451 5: DbRep DBRep2_MT - data element: 2022-06-16 01:44:05_ESC_83
2023.01.05 19:26:34.451 5: DbRep DBRep2_MT - time sum: 1200, delta time: 600, value: 83, twm: 41.5
2023.01.05 19:26:34.452 5: DbRep DBRep2_MT - data element: 2022-06-16 01:49:05_ESC_82
2023.01.05 19:26:34.452 5: DbRep DBRep2_MT - time sum: 1200, delta time: 300, value: 82, twm: 20.5
2023.01.05 19:26:34.453 5: DbRep DBRep2_MT - data element: 2022-06-16 01:54:05_ESC_83
2023.01.05 19:26:34.453 5: DbRep DBRep2_MT - time sum: 1200, delta time: 300, value: 83, twm: 20.75
2023.01.05 19:26:34.455 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.455 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.456 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.457 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.465 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.466 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.466 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 02' AND TIMESTAMP < '2022-06-16 03' ORDER BY TIMESTAMP ASC;
2023.01.05 19:26:34.471 5: DbRep DBRep2_MT - data element: 2022-06-16 02:24:05_ESC_83
2023.01.05 19:26:34.472 5: DbRep DBRep2_MT - time sum: 3300, delta time: 1200, value: 83, twm: 30.1818181818182
2023.01.05 19:26:34.472 5: DbRep DBRep2_MT - data element: 2022-06-16 02:29:05_ESC_82
2023.01.05 19:26:34.473 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:26:34.473 5: DbRep DBRep2_MT - data element: 2022-06-16 02:34:05_ESC_83
2023.01.05 19:26:34.474 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:26:34.475 5: DbRep DBRep2_MT - data element: 2022-06-16 02:39:05_ESC_82
2023.01.05 19:26:34.475 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:26:34.476 5: DbRep DBRep2_MT - data element: 2022-06-16 02:44:05_ESC_83
2023.01.05 19:26:34.476 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:26:34.477 5: DbRep DBRep2_MT - data element: 2022-06-16 02:54:05_ESC_82
2023.01.05 19:26:34.477 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 82, twm: 14.9090909090909
2023.01.05 19:26:34.478 5: DbRep DBRep2_MT - data element: 2022-06-16 02:59:05_ESC_84
2023.01.05 19:26:34.478 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 84, twm: 7.63636363636364
2023.01.05 19:26:34.479 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.480 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.480 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.481 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.489 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.490 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.490 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 03' AND TIMESTAMP < '2022-06-16 04' ORDER BY TIMESTAMP ASC;
2023.01.05 19:26:34.495 5: DbRep DBRep2_MT - data element: 2022-06-16 03:24:05_ESC_82
2023.01.05 19:26:34.496 5: DbRep DBRep2_MT - time sum: 3300, delta time: 1200, value: 82, twm: 29.8181818181818
2023.01.05 19:26:34.496 5: DbRep DBRep2_MT - data element: 2022-06-16 03:29:05_ESC_83
2023.01.05 19:26:34.497 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:26:34.497 5: DbRep DBRep2_MT - data element: 2022-06-16 03:34:05_ESC_82
2023.01.05 19:26:34.498 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:26:34.498 5: DbRep DBRep2_MT - data element: 2022-06-16 03:44:05_ESC_83
2023.01.05 19:26:34.499 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 83, twm: 15.0909090909091
2023.01.05 19:26:34.499 5: DbRep DBRep2_MT - data element: 2022-06-16 03:59:05_ESC_84
2023.01.05 19:26:34.500 5: DbRep DBRep2_MT - time sum: 3300, delta time: 900, value: 84, twm: 22.9090909090909
2023.01.05 19:26:34.501 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.501 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.502 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.503 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.512 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.513 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:26:34.514 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 04' AND TIMESTAMP <= '2022-06-16 04:59:00' ORDER BY TIMESTAMP ASC;
2023.01.05 19:26:34.520 5: DbRep DBRep2_MT - data element: 2022-06-16 04:24:05_ESC_82
2023.01.05 19:26:34.521 5: DbRep DBRep2_MT - time sum: 2701, delta time: 900, value: 82, twm: 27.3232136245835
2023.01.05 19:26:34.522 5: DbRep DBRep2_MT - data element: 2022-06-16 04:29:05_ESC_84
2023.01.05 19:26:34.522 5: DbRep DBRep2_MT - time sum: 2701, delta time: 300, value: 84, twm: 9.32987782302851
2023.01.05 19:26:34.523 5: DbRep DBRep2_MT - data element: 2022-06-16 04:39:06_ESC_83
2023.01.05 19:26:34.523 5: DbRep DBRep2_MT - time sum: 2701, delta time: 601, value: 83, twm: 18.4683450573862
2023.01.05 19:26:34.524 5: DbRep DBRep2_MT - data element: 2022-06-16 04:44:06_ESC_84
2023.01.05 19:26:34.525 5: DbRep DBRep2_MT - time sum: 2701, delta time: 300, value: 84, twm: 9.32987782302851
2023.01.05 19:26:34.526 5: DbRep DBRep2_MT - data element: 2022-06-16 04:49:06_ESC_82
2023.01.05 19:26:34.526 5: DbRep DBRep2_MT - time sum: 2701, delta time: 300, value: 82, twm: 9.10773787486116
2023.01.05 19:26:34.527 5: DbRep DBRep2_MT - data element: 2022-06-16 04:54:06_ESC_85
2023.01.05 19:26:34.527 5: DbRep DBRep2_MT - time sum: 2701, delta time: 300, value: 85, twm: 9.44094779711218
2023.01.05 19:26:34.551 5: DbRep DBRep2_MT - BlockingCall PID "1755" finished



1. Versuch

2023.01.05 19:23:34.035 4: DbRep DBRep2_MT - -------- New selection ---------
2023.01.05 19:23:34.036 4: DbRep DBRep2_MT - Command: averageValue display
2023.01.05 19:23:34.038 4: DbRep DBRep2_MT - FullDay option: 0
2023.01.05 19:23:34.039 5: DbRep DBRep2_MT - Timestamp begin epocheseconds: 1655334600
2023.01.05 19:23:34.039 4: DbRep DBRep2_MT - Timestamp begin human readable: 2022-06-16 01:10:00
2023.01.05 19:23:34.040 5: DbRep DBRep2_MT - Timestamp end epocheseconds: 1655416799
2023.01.05 19:23:34.040 4: DbRep DBRep2_MT - Timestamp end human readable: 2022-06-16 23:59:59
2023.01.05 19:23:34.041 5: DbRep DBRep2_MT - weekday start for selection: Do  ->  wdadd: 345600
2023.01.05 19:23:34.042 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 01:10:00 2022" to "Thu Jun 16 02:10:00 2022")
2023.01.05 19:23:34.043 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 02:10:00 2022" to "Thu Jun 16 03:10:00 2022")
2023.01.05 19:23:34.043 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 03:10:00 2022" to "Thu Jun 16 04:10:00 2022")
2023.01.05 19:23:34.044 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 04:10:00 2022" to "Thu Jun 16 05:10:00 2022")
2023.01.05 19:23:34.045 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 05:10:00 2022" to "Thu Jun 16 06:10:00 2022")
2023.01.05 19:23:34.046 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 06:10:00 2022" to "Thu Jun 16 07:10:00 2022")
2023.01.05 19:23:34.047 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 07:10:00 2022" to "Thu Jun 16 08:10:00 2022")
2023.01.05 19:23:34.047 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 08:10:00 2022" to "Thu Jun 16 09:10:00 2022")
2023.01.05 19:23:34.048 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 09:10:00 2022" to "Thu Jun 16 10:10:00 2022")
2023.01.05 19:23:34.049 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 10:10:00 2022" to "Thu Jun 16 11:10:00 2022")
2023.01.05 19:23:34.050 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 11:10:00 2022" to "Thu Jun 16 12:10:00 2022")
2023.01.05 19:23:34.050 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 12:10:00 2022" to "Thu Jun 16 13:10:00 2022")
2023.01.05 19:23:34.051 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 13:10:00 2022" to "Thu Jun 16 14:10:00 2022")
2023.01.05 19:23:34.052 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 14:10:00 2022" to "Thu Jun 16 15:10:00 2022")
2023.01.05 19:23:34.053 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 15:10:00 2022" to "Thu Jun 16 16:10:00 2022")
2023.01.05 19:23:34.053 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 16:10:00 2022" to "Thu Jun 16 17:10:00 2022")
2023.01.05 19:23:34.054 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 17:10:00 2022" to "Thu Jun 16 18:10:00 2022")
2023.01.05 19:23:34.055 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 18:10:00 2022" to "Thu Jun 16 19:10:00 2022")
2023.01.05 19:23:34.056 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 19:10:00 2022" to "Thu Jun 16 20:10:00 2022")
2023.01.05 19:23:34.057 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 20:10:00 2022" to "Thu Jun 16 21:10:00 2022")
2023.01.05 19:23:34.058 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 21:10:00 2022" to "Thu Jun 16 22:10:00 2022")
2023.01.05 19:23:34.058 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 22:10:00 2022" to "Thu Jun 16 23:10:00 2022")
2023.01.05 19:23:34.059 5: DbRep DBRep2_MT - Daylight savings changed: 0 (from "Thu Jun 16 23:10:00 2022" to "Fri Jun 17 00:10:00 2022")
2023.01.05 19:23:34.060 4: DbRep DBRep2_MT - Aggregation: hour
2023.01.05 19:23:34.087 5: DbRep DBRep2_MT - BlockingCall with PID "1640" started
2023.01.05 19:23:34.294 4: DbRep DBRep2_MT - Database connect - user: fhemuser, UTF-8 option set: yes
2023.01.05 19:23:34.304 4: DbRep DBRep2_MT - averageValue calculation sceme: avgTimeWeightMean
2023.01.05 19:23:34.305 5: DbRep DBRep2_MT - IsTimeSet: 1, IsAggrSet: 1
2023.01.05 19:23:34.307 5: DbRep DBRep2_MT - Timestamp-Array:
2022-06-16_01#2022-06-16 01:10:00#2022-06-16 02 2022-06-16_02#2022-06-16 02#2022-06-16 03 2022-06-16_03#2022-06-16 03#2022-06-16 04 2022-06-16_04#2022-06-16 04#2022-06-16 05 2022-06-16_05#2022-06-16 05#2022-06-16 06 2022-06-16_06#2022-06-16 06#2022-06-16 07 2022-06-16_07#2022-06-16 07#2022-06-16 08 2022-06-16_08#2022-06-16 08#2022-06-16 09 2022-06-16_09#2022-06-16 09#2022-06-16 10 2022-06-16_10#2022-06-16 10#2022-06-16 11 2022-06-16_11#2022-06-16 11#2022-06-16 12 2022-06-16_12#2022-06-16 12#2022-06-16 13 2022-06-16_13#2022-06-16 13#2022-06-16 14 2022-06-16_14#2022-06-16 14#2022-06-16 15 2022-06-16_15#2022-06-16 15#2022-06-16 16 2022-06-16_16#2022-06-16 16#2022-06-16 17 2022-06-16_17#2022-06-16 17#2022-06-16 18 2022-06-16_18#2022-06-16 18#2022-06-16 19 2022-06-16_19#2022-06-16 19#2022-06-16 20 2022-06-16_20#2022-06-16 20#2022-06-16 21 2022-06-16_21#2022-06-16 21#2022-06-16 22 2022-06-16_22#2022-06-16 22#2022-06-16 23 2022-06-16_23#2022-06-16 23#2022-06-16 23:59:59
2023.01.05 19:23:34.308 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.309 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.310 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.310 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.320 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.321 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.322 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 01:10:00' AND TIMESTAMP < '2022-06-16 02' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.327 5: DbRep DBRep2_MT - data element: 2022-06-16 01:44:05_ESC_83
2023.01.05 19:23:34.327 5: DbRep DBRep2_MT - time sum: 1200, delta time: 600, value: 83, twm: 41.5
2023.01.05 19:23:34.328 5: DbRep DBRep2_MT - data element: 2022-06-16 01:49:05_ESC_82
2023.01.05 19:23:34.328 5: DbRep DBRep2_MT - time sum: 1200, delta time: 300, value: 82, twm: 20.5
2023.01.05 19:23:34.329 5: DbRep DBRep2_MT - data element: 2022-06-16 01:54:05_ESC_83
2023.01.05 19:23:34.329 5: DbRep DBRep2_MT - time sum: 1200, delta time: 300, value: 83, twm: 20.75
2023.01.05 19:23:34.330 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.331 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.332 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.332 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.340 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.341 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.342 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 02' AND TIMESTAMP < '2022-06-16 03' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.347 5: DbRep DBRep2_MT - data element: 2022-06-16 02:24:05_ESC_83
2023.01.05 19:23:34.347 5: DbRep DBRep2_MT - time sum: 3300, delta time: 1200, value: 83, twm: 30.1818181818182
2023.01.05 19:23:34.348 5: DbRep DBRep2_MT - data element: 2022-06-16 02:29:05_ESC_82
2023.01.05 19:23:34.348 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.349 5: DbRep DBRep2_MT - data element: 2022-06-16 02:34:05_ESC_83
2023.01.05 19:23:34.349 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.350 5: DbRep DBRep2_MT - data element: 2022-06-16 02:39:05_ESC_82
2023.01.05 19:23:34.350 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.351 5: DbRep DBRep2_MT - data element: 2022-06-16 02:44:05_ESC_83
2023.01.05 19:23:34.351 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.352 5: DbRep DBRep2_MT - data element: 2022-06-16 02:54:05_ESC_82
2023.01.05 19:23:34.352 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 82, twm: 14.9090909090909
2023.01.05 19:23:34.353 5: DbRep DBRep2_MT - data element: 2022-06-16 02:59:05_ESC_84
2023.01.05 19:23:34.353 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 84, twm: 7.63636363636364
2023.01.05 19:23:34.354 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.355 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.355 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.356 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.364 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.365 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.365 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 03' AND TIMESTAMP < '2022-06-16 04' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.370 5: DbRep DBRep2_MT - data element: 2022-06-16 03:24:05_ESC_82
2023.01.05 19:23:34.371 5: DbRep DBRep2_MT - time sum: 3300, delta time: 1200, value: 82, twm: 29.8181818181818
2023.01.05 19:23:34.372 5: DbRep DBRep2_MT - data element: 2022-06-16 03:29:05_ESC_83
2023.01.05 19:23:34.372 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.373 5: DbRep DBRep2_MT - data element: 2022-06-16 03:34:05_ESC_82
2023.01.05 19:23:34.374 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.375 5: DbRep DBRep2_MT - data element: 2022-06-16 03:44:05_ESC_83
2023.01.05 19:23:34.375 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 83, twm: 15.0909090909091
2023.01.05 19:23:34.376 5: DbRep DBRep2_MT - data element: 2022-06-16 03:59:05_ESC_84
2023.01.05 19:23:34.377 5: DbRep DBRep2_MT - time sum: 3300, delta time: 900, value: 84, twm: 22.9090909090909
2023.01.05 19:23:34.378 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.379 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.380 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.380 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.389 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.390 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.391 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 04' AND TIMESTAMP < '2022-06-16 05' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.396 5: DbRep DBRep2_MT - data element: 2022-06-16 04:24:05_ESC_82
2023.01.05 19:23:34.396 5: DbRep DBRep2_MT - time sum: 3001, delta time: 900, value: 82, twm: 24.5918027324225
2023.01.05 19:23:34.397 5: DbRep DBRep2_MT - data element: 2022-06-16 04:29:05_ESC_84
2023.01.05 19:23:34.398 5: DbRep DBRep2_MT - time sum: 3001, delta time: 300, value: 84, twm: 8.39720093302233
2023.01.05 19:23:34.398 5: DbRep DBRep2_MT - data element: 2022-06-16 04:39:06_ESC_83
2023.01.05 19:23:34.399 5: DbRep DBRep2_MT - time sum: 3001, delta time: 601, value: 83, twm: 16.622125958014
2023.01.05 19:23:34.400 5: DbRep DBRep2_MT - data element: 2022-06-16 04:44:06_ESC_84
2023.01.05 19:23:34.400 5: DbRep DBRep2_MT - time sum: 3001, delta time: 300, value: 84, twm: 8.39720093302233
2023.01.05 19:23:34.401 5: DbRep DBRep2_MT - data element: 2022-06-16 04:49:06_ESC_82
2023.01.05 19:23:34.402 5: DbRep DBRep2_MT - time sum: 3001, delta time: 300, value: 82, twm: 8.19726757747418
2023.01.05 19:23:34.402 5: DbRep DBRep2_MT - data element: 2022-06-16 04:54:06_ESC_85
2023.01.05 19:23:34.403 5: DbRep DBRep2_MT - time sum: 3001, delta time: 300, value: 85, twm: 8.4971676107964
2023.01.05 19:23:34.404 5: DbRep DBRep2_MT - data element: 2022-06-16 04:59:06_ESC_83
2023.01.05 19:23:34.404 5: DbRep DBRep2_MT - time sum: 3001, delta time: 300, value: 83, twm: 8.29723425524825
2023.01.05 19:23:34.405 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.406 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.407 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.407 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.416 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.417 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.418 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 05' AND TIMESTAMP < '2022-06-16 06' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.423 5: DbRep DBRep2_MT - data element: 2022-06-16 05:14:06_ESC_83
2023.01.05 19:23:34.423 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 83, twm: 15.0909090909091
2023.01.05 19:23:34.425 5: DbRep DBRep2_MT - data element: 2022-06-16 05:19:06_ESC_84
2023.01.05 19:23:34.425 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 84, twm: 7.63636363636364
2023.01.05 19:23:34.426 5: DbRep DBRep2_MT - data element: 2022-06-16 05:29:06_ESC_85
2023.01.05 19:23:34.426 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 85, twm: 15.4545454545455
2023.01.05 19:23:34.427 5: DbRep DBRep2_MT - data element: 2022-06-16 05:34:06_ESC_83
2023.01.05 19:23:34.427 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.428 5: DbRep DBRep2_MT - data element: 2022-06-16 05:39:06_ESC_82
2023.01.05 19:23:34.428 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.429 5: DbRep DBRep2_MT - data element: 2022-06-16 05:44:06_ESC_83
2023.01.05 19:23:34.429 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.430 5: DbRep DBRep2_MT - data element: 2022-06-16 05:54:06_ESC_84
2023.01.05 19:23:34.430 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 84, twm: 15.2727272727273
2023.01.05 19:23:34.430 5: DbRep DBRep2_MT - data element: 2022-06-16 05:59:06_ESC_82
2023.01.05 19:23:34.431 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.432 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.432 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.433 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.434 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.441 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.442 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.443 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 06' AND TIMESTAMP < '2022-06-16 07' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.447 5: DbRep DBRep2_MT - data element: 2022-06-16 06:09:06_ESC_84
2023.01.05 19:23:34.448 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 84, twm: 8.4
2023.01.05 19:23:34.449 5: DbRep DBRep2_MT - data element: 2022-06-16 06:14:06_ESC_81
2023.01.05 19:23:34.449 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 81, twm: 8.1
2023.01.05 19:23:34.450 5: DbRep DBRep2_MT - data element: 2022-06-16 06:19:06_ESC_82
2023.01.05 19:23:34.450 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 82, twm: 8.2
2023.01.05 19:23:34.451 5: DbRep DBRep2_MT - data element: 2022-06-16 06:24:06_ESC_86
2023.01.05 19:23:34.451 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 86, twm: 8.6
2023.01.05 19:23:34.452 5: DbRep DBRep2_MT - data element: 2022-06-16 06:29:06_ESC_84
2023.01.05 19:23:34.452 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 84, twm: 8.4
2023.01.05 19:23:34.453 5: DbRep DBRep2_MT - data element: 2022-06-16 06:34:06_ESC_83
2023.01.05 19:23:34.453 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 83, twm: 8.3
2023.01.05 19:23:34.454 5: DbRep DBRep2_MT - data element: 2022-06-16 06:49:06_ESC_84
2023.01.05 19:23:34.454 5: DbRep DBRep2_MT - time sum: 3000, delta time: 900, value: 84, twm: 25.2
2023.01.05 19:23:34.455 5: DbRep DBRep2_MT - data element: 2022-06-16 06:54:06_ESC_83
2023.01.05 19:23:34.455 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 83, twm: 8.3
2023.01.05 19:23:34.456 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.457 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.458 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.458 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.466 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.467 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.467 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 07' AND TIMESTAMP < '2022-06-16 08' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.472 5: DbRep DBRep2_MT - data element: 2022-06-16 07:09:06_ESC_85
2023.01.05 19:23:34.473 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 85, twm: 7.72727272727273
2023.01.05 19:23:34.473 5: DbRep DBRep2_MT - data element: 2022-06-16 07:14:06_ESC_82
2023.01.05 19:23:34.474 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.475 5: DbRep DBRep2_MT - data element: 2022-06-16 07:19:06_ESC_83
2023.01.05 19:23:34.475 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.476 5: DbRep DBRep2_MT - data element: 2022-06-16 07:34:06_ESC_84
2023.01.05 19:23:34.477 5: DbRep DBRep2_MT - time sum: 3300, delta time: 900, value: 84, twm: 22.9090909090909
2023.01.05 19:23:34.478 5: DbRep DBRep2_MT - data element: 2022-06-16 07:39:06_ESC_83
2023.01.05 19:23:34.478 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 83, twm: 7.54545454545455
2023.01.05 19:23:34.479 5: DbRep DBRep2_MT - data element: 2022-06-16 07:44:06_ESC_82
2023.01.05 19:23:34.480 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 82, twm: 7.45454545454546
2023.01.05 19:23:34.481 5: DbRep DBRep2_MT - data element: 2022-06-16 07:54:06_ESC_84
2023.01.05 19:23:34.482 5: DbRep DBRep2_MT - time sum: 3300, delta time: 600, value: 84, twm: 15.2727272727273
2023.01.05 19:23:34.483 5: DbRep DBRep2_MT - data element: 2022-06-16 07:59:06_ESC_81
2023.01.05 19:23:34.484 5: DbRep DBRep2_MT - time sum: 3300, delta time: 300, value: 81, twm: 7.36363636363636
2023.01.05 19:23:34.486 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.487 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.488 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.488 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.497 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.498 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.498 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 08' AND TIMESTAMP < '2022-06-16 09' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.503 5: DbRep DBRep2_MT - data element: 2022-06-16 08:09:06_ESC_82
2023.01.05 19:23:34.503 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 82, twm: 8.2
2023.01.05 19:23:34.504 5: DbRep DBRep2_MT - data element: 2022-06-16 08:19:06_ESC_81
2023.01.05 19:23:34.505 5: DbRep DBRep2_MT - time sum: 3000, delta time: 600, value: 81, twm: 16.2
2023.01.05 19:23:34.505 5: DbRep DBRep2_MT - data element: 2022-06-16 08:24:06_ESC_82
2023.01.05 19:23:34.506 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 82, twm: 8.2
2023.01.05 19:23:34.506 5: DbRep DBRep2_MT - data element: 2022-06-16 08:49:06_ESC_81
2023.01.05 19:23:34.507 5: DbRep DBRep2_MT - time sum: 3000, delta time: 1500, value: 81, twm: 40.5
2023.01.05 19:23:34.507 5: DbRep DBRep2_MT - data element: 2022-06-16 08:54:06_ESC_82
2023.01.05 19:23:34.508 5: DbRep DBRep2_MT - time sum: 3000, delta time: 300, value: 82, twm: 8.2
2023.01.05 19:23:34.508 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.509 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.510 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.510 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.518 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.519 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.520 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 09' AND TIMESTAMP < '2022-06-16 10' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.524 5: DbRep DBRep2_MT - data element: 2022-06-16 09:24:06_ESC_82
2023.01.05 19:23:34.525 5: DbRep DBRep2_MT - time sum: 2700, delta time: 600, value: 82, twm: 18.2222222222222
2023.01.05 19:23:34.526 5: DbRep DBRep2_MT - data element: 2022-06-16 09:29:06_ESC_79
2023.01.05 19:23:34.526 5: DbRep DBRep2_MT - time sum: 2700, delta time: 300, value: 79, twm: 8.77777777777778
2023.01.05 19:23:34.527 5: DbRep DBRep2_MT - data element: 2022-06-16 09:34:06_ESC_82
2023.01.05 19:23:34.527 5: DbRep DBRep2_MT - time sum: 2700, delta time: 300, value: 82, twm: 9.11111111111111
2023.01.05 19:23:34.528 5: DbRep DBRep2_MT - data element: 2022-06-16 09:39:06_ESC_79
2023.01.05 19:23:34.528 5: DbRep DBRep2_MT - time sum: 2700, delta time: 300, value: 79, twm: 8.77777777777778
2023.01.05 19:23:34.528 5: DbRep DBRep2_MT - data element: 2022-06-16 09:44:06_ESC_80
2023.01.05 19:23:34.529 5: DbRep DBRep2_MT - time sum: 2700, delta time: 300, value: 80, twm: 8.88888888888889
2023.01.05 19:23:34.529 5: DbRep DBRep2_MT - data element: 2022-06-16 09:49:06_ESC_81
2023.01.05 19:23:34.530 5: DbRep DBRep2_MT - time sum: 2700, delta time: 300, value: 81, twm: 9
2023.01.05 19:23:34.530 5: DbRep DBRep2_MT - data element: 2022-06-16 09:59:06_ESC_80
2023.01.05 19:23:34.531 5: DbRep DBRep2_MT - time sum: 2700, delta time: 600, value: 80, twm: 17.7777777777778
2023.01.05 19:23:34.532 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.532 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.533 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.534 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.542 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.542 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.543 4: DbRep DBRep2_MT - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'MQTT2_ESP_2' ) AND ( READING = 'MT691_power' ) AND TIMESTAMP >= '2022-06-16 10' AND TIMESTAMP < '2022-06-16 11' ORDER BY TIMESTAMP ASC;
2023.01.05 19:23:34.548 5: DbRep DBRep2_MT - data element: 2022-06-16 10:09:06_ESC_82
2023.01.05 19:23:34.548 5: DbRep DBRep2_MT - time sum: 1500, delta time: 300, value: 82, twm: 16.4
2023.01.05 19:23:34.549 5: DbRep DBRep2_MT - data element: 2022-06-16 10:14:06_ESC_80
2023.01.05 19:23:34.549 5: DbRep DBRep2_MT - time sum: 1500, delta time: 300, value: 80, twm: 16
2023.01.05 19:23:34.550 5: DbRep DBRep2_MT - data element: 2022-06-16 10:19:06_ESC_81
2023.01.05 19:23:34.550 5: DbRep DBRep2_MT - time sum: 1500, delta time: 300, value: 81, twm: 16.2
2023.01.05 19:23:34.551 5: DbRep DBRep2_MT - data element: 2022-06-16 10:24:06_ESC_80
2023.01.05 19:23:34.551 5: DbRep DBRep2_MT - time sum: 1500, delta time: 300, value: 80, twm: 16
2023.01.05 19:23:34.552 5: DbRep DBRep2_MT - data element: 2022-06-16 10:29:06_ESC_0
2023.01.05 19:23:34.552 5: DbRep DBRep2_MT - time sum: 1500, delta time: 300, value: 0, twm: 0
2023.01.05 19:23:34.553 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.554 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.554 5: DbRep DBRep2_MT - Devices for operation -
included (1): MQTT2_ESP_2
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.555 5: DbRep DBRep2_MT - Readings for operation -
included (1): MT691_power
included with wildcard: 
excluded (0): 
excluded with wildcard:
2023.01.05 19:23:34.561 2: DbRep DBRep2_MT -
2023.01.05 19:23:34.569 5: DbRep DBRep2_MT - BlockingCall PID "1640" finished

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2023, 19:42:22
Den Hinweis von Franz konnte ich bei mir nachvollziehen.
Das werde ich erstmal fixen. Dann schauen wir nochmal.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2023, 21:44:32
Das Problem von Franz konnte ich fixen. Ganz kleiner Fehler mit großer Wirkung.
Testet mal bitte -> contrib
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 23:08:43
Kann ich das auf mein Livesystem loslassen  ::)
Auf dem Testsystem muss ich das ganze Logging noch einrichten...

hmm... ich zieh nen SQL Export

Gruß
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Januar 2023, 23:13:00
Nur Mut  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 05 Januar 2023, 23:57:34
ok hat mir keine Ruhe gelassen....

timestamp_begin 2022-06-16 01:05:00
timestamp_end   2022-06-16 04:59:00
==> hatte funktioniert funktioniert noch

timestamp_begin 2022-06-16 01:05:00
timestamp_end   2022-06-16 23:59:00
==> hatte nicht funktioniert ==> liefert ein Ergebnis

Soweit zumindest eine positive Veränderung  :D

Jetzt kann ich ja mal die beiden Methoden im Rechenergebnis vergleichen, um zu sehen ob der einfache "average" besser mit der zeitgewichteten Methode ersetzt wird.


Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2023, 00:00:18
Jetzt sind schon viele Verbesserungen und Fixes ins Modul geflossen.
Ich warte mal noch bis morgen Abend, dann würde ich den Stand ins Repo bringen.

Gute Nacht @all,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 06 Januar 2023, 00:15:30
Macht Sinn, vielleicht gibts ja noch ne Meldung.

Ich glaube der gewichtete Mittelwert hat deutliche Vorteile, da die Null-Werte bzw. starke kurze Leistungsspitzen nicht so stark durchschlagen.

@Schluss für heute
Ralf


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 06 Januar 2023, 07:31:16
Zitat von: DS_Starter am 06 Januar 2023, 00:00:18
Ich warte mal noch bis morgen Abend, dann würde ich den Stand ins Repo bringen.
Moin Heiko,
vielleicht kannst Du noch warten:
Mir fiel bei der Beschäftigung mit dem gerichteten Mitteln nämlich auf, dass der jeweils letzte Datenpunkt am Ende eines Teilintervalls nicht berücksichtigt wird. Liegt, wenn ich den Perl-Code richtig verstanden hab, daran dass die Datenpakete pro Teilintervall separat mit SQL eingelesen und verarbeitet werden.
Ich hab bei der Methode mit reinem SQL die  Beiträge eines Teilintervall-übergreifenden Datenpunkts dagegen mitgenommen und anteilig gewichtet beiden Intervallen zugeordnet.

Vielleicht lässt sich die ,,nur-SQL" Methode ja in das Modul integrieren. Die Korrektheit der Berechnung habe ich jedenfalls mit ner Gegenrechnung in Excel überprüft.

Ich versuche mal im Laufe des Tages, das obige im Wiki etwas detaillierter zu erläutern.

Gruß
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2023, 08:00:27
Moin Franz,

ja gerne.

Das Problem ist, dass der Code sowohl für MySQL/MariaDB, SQLite und PostgreSQL funktionieren muss.
Es geht ja schon bei den Variablen los:


SET @sortformat="hour",
  @weighted="yes",
  @device = "E_Zaehler",
  @reading = "power",
  @start = "2022-10-29 00:00:00",
  @end = "2022-10-29 05:00:00";


SQLite kann es so nicht. Habe diverse Varianten mit temporären Tabellen im Netz eruiert.
Meine MariaDB kann auch den Code aus dem Wiki nicht verarbeiten. Es kommt der Fehler:


DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '( ORDER BY tim) AS preavgtim, LEAD(avgtim) OVER ( ORDER BY tim) AS nextavgtim FR' at line 1 at ./FHEM/93_DbRep.pm line 11100.


Passt für meine MariaDB 10.1.48 noch nicht. Hatte auch noch keine Zeit den Grund genauer zu analysieren.
Da gibt es (wie schon öfter festgestellt) Unterschiede in den DB-Systemen und DB Versionen wenn es um komplexe SQL geht.
Es gibt mittlerweile auch ein DBD::MariaDB (https://metacpan.org/pod/DBD::MariaDB). Das hat den letzten Stand vom April 22, also recht aktuell. Werde ich mal bei Gelegenheit auch installieren, probieren und schauen ob ich es für DbLog/DbRep als DB-Typ integriere.

Kurzum, wenn wir für alle unterstützten DB's einen validen Code erarbeiten können, dann kann der gerne in die Funktion.
Ansonsten kann man nur über sqlCmd gehen mit Wiki Unterstützung.

LG

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 06 Januar 2023, 09:24:47
Klar, macht Sinn. Die Vielfalt der SQL-Dialekte hatte ich nicht auf dem Schirm
-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2023, 09:50:57
Ich habe noch einen kleinen Fehler korrigiert.
Weiterhin wird nun bei sqlCmd.../Blocking der formatierte SQL Code im Reading sqlCmd ausgegeben wenn das Statement fehlerhaft war.
Das erleichtert das Editieren und neu ausführen des Codes.
-> contrib

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 06 Januar 2023, 09:56:52
Zitat von: alkazaa am 06 Januar 2023, 09:24:47
Klar, macht Sinn. Die Vielfalt der SQL-Dialekte hatte ich nicht auf dem Schirm
-Franz
Ich verwende direkt das Oracle MySQL im Docker Container, das ist teilweise noch restriktiver, dafür aber immer aktueller.
Gerade bei den Variablen wird sich etwas ändern und auch für GROUP BY ist es schon jetzt anders gehandhabt.

VG  Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 06 Januar 2023, 11:21:07
Zitat von: DS_Starter am 06 Januar 2023, 08:00:27
...
SQLite kann es so nicht. Habe diverse Varianten mit temporären Tabellen im Netz eruiert.
Meine MariaDB kann auch den Code aus dem Wiki nicht verarbeiten. Es kommt der Fehler:


DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '( ORDER BY tim) AS preavgtim, LEAD(avgtim) OVER ( ORDER BY tim) AS nextavgtim FR' at line 1 at ./FHEM/93_DbRep.pm line 11100.


Deswegen bin ich dankbar, wenn das Modul solche Sachen kann.
Bei den SQL-Statements (wie im Wiki) wäre ich völlig verloren (geht schon beim ausführen per CMD oder so im Modul los).

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 06 Januar 2023, 12:55:14
Zitat von: RalfRog am 06 Januar 2023, 11:21:07
Bei den SQL-Statements (wie im Wiki) wäre ich völlig verloren (geht schon beim ausführen per CMD oder so im Modul los).
Moin Ralf,
falls Du Dich auf das erste der Mittelungsqueries beziehst: einfach das gesamte Query ins Eingabefenster von sqlCmd (oder sqlCmdBlocking) kopieren und ausführen sollte gehen.
Inzwischen gibt es auch das Attribut sqlCmdVars, dorthin könnte (und sollte) man den Anfangsteil mit den SET @... auslagern und danach das Statement ab SELECT... im sqlCmd Fenster ausführen, also zuerst:
attr <dein DbRep-device> sqlCmdVars SET @sortformat="hour", @weighted="yes", @device="E_Zaehler", @reading="power", @start = "2022-10-29 00:00:00", @end = "2022-10-29 05:00:00";
Dann das statement ab SELECT... als sqlCmd Befehl.

Falls das gesamte (von SET ... bis ... GROUP by grouptim) Statement über die FHEM Commandozeile laufen soll (also mit set <dein DbRep-device> sqlCmd SET... ... GROUP by avgtim), musst das Semikolon vor SELECT verdoppelt werden.

Das das ganze ja auch noch vom SQL-"Dialekt" abhängt (s.o.): bei mir läuft es auf einer MariaDB 10.3er Version

Aber Du willst ja auch die reduzierten Werte zurückschreiben in die DB, brauchst also sowieso die Gesamt-Funktionalität innerhalb des Moduls umgesetzt. Das in ein statement zu packen trau ich mich nicht (wenn's überhaupt geht)

Gruß
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 06 Januar 2023, 13:19:36
Danke für die Erläuterung.
Was wo reinkommt wäre im Wiki hilfreich (das war mir nicht so recht klar).

Für die zeitlich gewerteten Mittelwerte (per Modul) muss ich noch etwas Gehirnschmalz verwenden.
Die berechneten Werte werden mit neuem (angelehnten) Namen zusätzlich in die DB geschrieben.
So weit so schön - im zweiten (oder auch dritten) Schritt müssen dann noch die Originaleinträge rediziert werden sowie (je nach Parameter) noch einer der beiden berechneten Werte am Anfang/Ende des Intervalls reduziert und zusätzlich ggfs. auch noch die neuen Namen in den Readings angepasst werden.

Dann ist (wenn es reicht, dass die Werte ungefähr den Trend zeigen) eventuell ein einfaches "reduceLog average" einfacher (auch hinsichtlich der Wartbarkeit des Konstrukts).

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 06 Januar 2023, 16:39:35
Habe die Erläuterungen im Wiki überarbeitet. Der Code wurde so umgeschrieben, dass jetzt die üblichen DbRep-Attribute für device, reading, Zeitraum genutzt werden (in der Form §device§ etc.)
-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 07 Januar 2023, 00:04:05
Zitat von: DS_Starter am 06 Januar 2023, 09:50:57
Ich habe noch einen kleinen Fehler korrigiert.
Weiterhin wird nun bei sqlCmd.../Blocking der formatierte SQL Code im Reading sqlCmd ausgegeben wenn das Statement fehlerhaft war.
Das erleichtert das Editieren und neu ausführen des Codes.
-> contrib
LG

Wart mal mit dem einchecken. Eventuell hatte die Änderung vongestern Nebenwirkungen.

Habe heute Nachmittag versucht ein set dbrep changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"kWh")"} zu machen.
Ergebnis ==> 2023.01.06 14:13:11.844 3: DbRep DBRep2_MT - WARNING - old value "%" not found in database "fhem"

Gestern vor der Verwendung der contrib-Version hat das noch geklappt  ::)
==> 2023.01.05 16:50:06.491 3: DbRep DBRep2_MT - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"kWh")", number: 15
==> 2023.01.05 16:55:04.446 3: DbRep DBRep2_MT - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"kWh")", number: 3119

Ich  habe es gerade nochmal ohne Wildcard im reading mit gleichem fehlerhaftem Ergebnis versucht
==> 2023.01.06 23:55:08.031 3: DbRep DBRep2_MT - WARNING - old value "%" not found in database "fhem"

hmm...



Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 07 Januar 2023, 00:12:16
Ja doof... Problem sitzt vor der Tastatur

Das ist keine Fehlermeldung sondern der Hinweis, dass im gewählten Teitraum keine Daten zu Anpassen da sind.
Kaum wählt man den passenden zeitraum schon geht es - oh Mann  :-X

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Januar 2023, 00:14:00
Hallo Ralf,

alles gut. Hatte heute Abend eh keine Zeit für Rep weil ich an anderer Stelle beschäftigt war.
Aber morgen dann .. jetzt erstmal gute Nacht.  :)

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 07 Januar 2023, 16:59:55
Zitat von: RalfRog am 06 Januar 2023, 13:19:36
....
So weit so schön - im zweiten (oder auch dritten) Schritt müssen dann noch die Originaleinträge reduziert werden sowie (je nach Parameter) noch einer der beiden berechneten Werte am Anfang/Ende des Intervalls reduziert und zusätzlich ggfs. auch noch die neuen Namen in den Readings angepasst werden.

Dann ist (wenn es reicht, dass die Werte ungefähr den Trend zeigen) eventuell ein einfaches "reduceLog average" einfacher (auch hinsichtlich der Wartbarkeit des Konstrukts).
...

Nur mal eine Idee ... ;)

Bei den Funktionen maxValue und minValue gibt es neben dem einfachen writeToDB auch deleteOther.
An sich wäre das doch eine schöne Möglichkeit für averageValue (bei gewichtetem Mitttelwert) nur den erechneten Wert zu behalten und auf die anderen Werte zu verzichten.
Kommt einem reduceLog average nahe aber je nach Anwnedungsfall mit "besseren" Mittelwerten.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Januar 2023, 18:59:37
Hallo Ralf,

das ist nicht ganz so einfach weil  je nach Methode nicht immer die Datensätze einzeln selected und verarbeitet werden und
Die SQL AVG-Funktion genutzt wird.
Somit stehen die Datensätze nicht zur Verfügung um sie "in einem Rutsch" gleich mit löschen zu können.
Deswegen gibt es bei dem Setter diese Option nicht.  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Januar 2023, 19:22:49
@all,
der aktuelle Entwicklungsstand ist eingecheckt und morgen früh im Update enthalten.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 17:36:26
Zitat von: DS_Starter am 07 Januar 2023, 19:22:49
@all,
der aktuelle Entwicklungsstand ist eingecheckt und morgen früh im Update enthalten.

LG

Ok zu naiv gedacht  ;)

Der set averageValue erzeugt ja neue zusätzliche Readings. Dabei wird der Type nicht 1:1 übernommen. Z.B. aus SHELLY wird Shelly.
Keine Ahnung ob so was an anderen Stellen (außerhalb der DB) wegen Unterscheidung von Groß-/Kleinschreibung zu Problemem führen kann.

Ich hoffe ich wärme hier jetzt keine alten Hüte auf. Hab aber auch nicht wirklich was gefunden.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 17:44:20
Hallo Relf,

bei dem neuen Readingsnamen wird nicht der TYPE verwendet, sondern (aus ComRef):


Der neue Readingname wird aus einem Präfix und dem originalen Readingnamen gebildet, wobei der originale Readingname durch das Attribut "readingNameMap" ersetzt werden kann. Der Präfix setzt sich aus der Bildungsfunktion und der Aggregation zusammen.


Diesen Namen findest du auch nur in der DB, sonst nirgendwo.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 18:08:53
Hallo
Das hatte ich in der CommandRef gelesen.
Ich hatte es so verstanden (passiert ja auch so), dass für das Feld 'READING' aus dem Readingnamen "power" standardmäßig (aggregation hour) "avgtwm_hour_power" gebildet und eingetragen wird ('EVENT' wird "calculated" und 'UNIT' (Null)).

Zum Feld 'TYPE' wird doch eigentlich nichts gesagt?

"TIMESTAMP"                   "DEVICE"                      "TYPE"       "EVENT"      "READING"                   "VALUE"  "UNIT"
"2023-01-08 16:59:59"   "shelly_plug_s_df2674"   "Shelly"   "calculated"   "avgtwm_hour_power"   "1"   \N
"2023-01-08 16:17:02"   "shelly_plug_s_df2674"   "SHELLY"   "power: 0"   "power"                       "0"  "W"


Gruß
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 18:12:16
Achso, jetzt verstehe ich was du meinst. Da muss ich mal in den Code schauen ....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 18:20:18
Also .... DbRep macht das richtig. Aber ... DbLog schreibt den Device TYPE generell in Großbuchstaben in die DB.
Jetzt bin ich mit mir am hadern ob ich DbRep an DbLog anpasse oder DbLog ändere.

Ich tendiere zu ersterem. Die Auswirkungen das Verhalten von DbLog zu ändern kann ich nicht abschätzen. Vllt. haben sich User Auswertungen über den TYPE gebaut etc.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 18:24:44
oh sorry hättte direkt etwas präziser sein können.

Ne Frage am Rande.
Wenn man regelmäßig (z.B. täglich) die DB etwas aufbereiten will (z.B. mit Average und Max o.ä.) dafür jeweils mehrere einzelne DBRep's braucht.

Wie verkettet man die denn am geschicktesten (Blocking, non_Blocking), dass die schön nacheinander abgearbeiet werden.
Dafür noch jeweils ein AT zu kreiern führt ja durchaus auch zu Unübersichtlichkeit.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 18:30:22
Mit einer Chain. Das hatte ich letztens hier beschrieben:

https://forum.fhem.de/index.php/topic,114815.msg1255834.html#msg1255834

(Wollte ich noch ins Wiki packen ... komme einfach zu nix  :o )
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 18:35:29
Zitat von: DS_Starter am 11 Januar 2023, 18:20:18
Also .... DbRep macht das richtig. Aber ... DbLog schreibt den Device TYPE generell in Großbuchstaben in die DB.
Jetzt bin ich mit mir am hadern ob ich DbRep an DbLog anpasse oder DbLog ändere.

Ich tendiere zu ersterem. Die Auswirkungen das Verhalten von DbLog zu ändern kann ich nicht abschätzen. Vllt. haben sich User Auswertungen über den TYPE gebaut etc.

Stimmt. Hatte ich noch gar nicht gesehen. Der Type im Modul ist "Shelly".

Ich habe zwar das Problem mit der Groß-/Kleinschreibung noch nicht aber das genau war der Hintergrund die Frage aufzuwerfen.

DBLog gibts ja schon länger....   Gefühlt denke ich auch, dass die User eher auf die "Eigenheitheiten" von DBLog bei den Auswertungen Rücksicht genommen haben und sich daher auf Großschreibung des Moduls eingestellt haben.
Kann man bisher ja nur über SQLbeeinflussen (Ich hatte zunächst analog zu readingRename nach typeRename  ;D geschaut).
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 18:36:42
Zitat von: DS_Starter am 11 Januar 2023, 18:30:22
Mit einer Chain. Das hatte ich letztens hier beschrieben:

https://forum.fhem.de/index.php/topic,114815.msg1255834.html#msg1255834

(Wollte ich noch ins Wiki packen ... komme einfach zu nix  :o )

Danke
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 18:38:30
Zitat
Ich hatte zunächst analog zu readingRename nach typeRename  ;D geschaut

:D ... werde DbRep anpassen. Wahrscheinlich ist die Änderung morgen früh mit dabei.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 21:44:54
Zitat
Wollte ich noch ins Wiki packen ...

erledigt:

https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#DbRep_Chain_-_die_Kommandokette
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 22:16:55
Cool... Super

Ich habe aber beim averageValue noch einen Fehler, der nicht wirklich mit dem Auslassen des letzten Wertes im Intervall zu tun hat.
Ich sehe momentan (muss dir noch ein Log mit verbose 5 machen), dass die gewichtet-gemittelte Stunde von x:00 bis x:59 um x-1:59 in die Datenbank geschrieben wird.

Gruß Ralf

Edit: x=0  und x-1 ist der Vortag 23 Uhr
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 22:32:29
Hier die Egebnisse. Es wurden 24 Werte geschrieben.
Als Zeitgrenzen habe ich gewählt:
timestamp_begin     previous_day_begin
timestamp_end        previous_day_end

Soweit ich das interpretieren kann, passen die Zeitstempel der 24 Selects.
Nur am Ende das Update/Insert History ist daneben. Der Zeitstempelspringt von 2023-01-10 22:59:59 auf 2023-01-09 23:59:59.

das Log:

2023.01.11 22:22:53.001 4: DbRep DBRep_avgtim_total_power - -------- New selection ---------
2023.01.11 22:22:53.002 4: DbRep DBRep_avgtim_total_power - Command: averageValue writeToDBSingle
2023.01.11 22:22:53.005 4: DbRep DBRep_avgtim_total_power - FullDay option: 0
2023.01.11 22:22:53.006 4: DbRep DBRep_avgtim_total_power - Timestamp begin human readable: 2023-01-10 00:00:00
2023.01.11 22:22:53.007 4: DbRep DBRep_avgtim_total_power - Timestamp end human readable: 2023-01-10 23:59:59
2023.01.11 22:22:53.019 4: DbRep DBRep_avgtim_total_power - Aggregation: hour
2023.01.11 22:22:53.259 4: DbRep DBRep_avgtim_total_power - Database connect - user: fhemuser, UTF-8 option set: yes
2023.01.11 22:22:53.267 4: DbRep DBRep_avgtim_total_power - averageValue calculation sceme: avgTimeWeightMean
2023.01.11 22:22:53.281 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 00:00:00' AND TIMESTAMP < '2023-01-10 01' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.307 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 01' AND TIMESTAMP < '2023-01-10 02' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.332 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 02' AND TIMESTAMP < '2023-01-10 03' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.357 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 03' AND TIMESTAMP < '2023-01-10 04' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.386 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 04' AND TIMESTAMP < '2023-01-10 05' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.415 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 05' AND TIMESTAMP < '2023-01-10 06' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.441 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 06' AND TIMESTAMP < '2023-01-10 07' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.466 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 07' AND TIMESTAMP < '2023-01-10 08' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.497 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 08' AND TIMESTAMP < '2023-01-10 09' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.523 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 09' AND TIMESTAMP < '2023-01-10 10' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.548 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 10' AND TIMESTAMP < '2023-01-10 11' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.573 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 11' AND TIMESTAMP < '2023-01-10 12' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.598 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 12' AND TIMESTAMP < '2023-01-10 13' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.623 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 13' AND TIMESTAMP < '2023-01-10 14' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.647 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 14' AND TIMESTAMP < '2023-01-10 15' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.671 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 15' AND TIMESTAMP < '2023-01-10 16' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.696 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 16' AND TIMESTAMP < '2023-01-10 17' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.720 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 17' AND TIMESTAMP < '2023-01-10 18' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.745 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 18' AND TIMESTAMP < '2023-01-10 19' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.770 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 19' AND TIMESTAMP < '2023-01-10 20' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.793 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 20' AND TIMESTAMP < '2023-01-10 21' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.816 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 21' AND TIMESTAMP < '2023-01-10 22' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.839 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 22' AND TIMESTAMP < '2023-01-10 23' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.862 4: DbRep DBRep_avgtim_total_power - SQL execute: SELECT TIMESTAMP,VALUE FROM history where ( DEVICE = 'shelly_3em_haus' ) AND ( READING = 'total_power' ) AND TIMESTAMP >= '2023-01-10 23' AND TIMESTAMP <= '2023-01-10 23:59:59' ORDER BY TIMESTAMP ASC;
2023.01.11 22:22:53.942 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 00:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|222|, RESULT: 0E0
2023.01.11 22:22:53.945 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 00:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|222|, RESULT: 1
2023.01.11 22:22:53.957 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 01:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|124|, RESULT: 0E0
2023.01.11 22:22:53.992 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 01:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|124|, RESULT: 1
2023.01.11 22:22:54.011 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 02:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|89|, RESULT: 0E0
2023.01.11 22:22:54.021 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 02:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|89|, RESULT: 1
2023.01.11 22:22:54.029 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 03:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|111|, RESULT: 0E0
2023.01.11 22:22:54.031 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 03:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|111|, RESULT: 1
2023.01.11 22:22:54.035 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 04:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|102|, RESULT: 0E0
2023.01.11 22:22:54.037 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 04:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|102|, RESULT: 1
2023.01.11 22:22:54.040 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 05:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|101|, RESULT: 0E0
2023.01.11 22:22:54.042 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 05:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|101|, RESULT: 1
2023.01.11 22:22:54.046 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 06:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|123|, RESULT: 0E0
2023.01.11 22:22:54.048 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 06:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|123|, RESULT: 1
2023.01.11 22:22:54.052 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 07:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|403|, RESULT: 0E0
2023.01.11 22:22:54.054 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 07:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|403|, RESULT: 1
2023.01.11 22:22:54.058 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 08:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|608|, RESULT: 0E0
2023.01.11 22:22:54.060 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 08:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|608|, RESULT: 1
2023.01.11 22:22:54.063 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 09:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|74|, RESULT: 0E0
2023.01.11 22:22:54.065 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 09:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|74|, RESULT: 1
2023.01.11 22:22:54.069 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 10:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|95|, RESULT: 0E0
2023.01.11 22:22:54.071 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 10:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|95|, RESULT: 1
2023.01.11 22:22:54.075 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 11:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|71|, RESULT: 0E0
2023.01.11 22:22:54.077 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 11:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|71|, RESULT: 1
2023.01.11 22:22:54.080 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 12:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|121|, RESULT: 0E0
2023.01.11 22:22:54.082 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 12:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|121|, RESULT: 1
2023.01.11 22:22:54.086 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 13:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|74|, RESULT: 0E0
2023.01.11 22:22:54.088 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 13:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|74|, RESULT: 1
2023.01.11 22:22:54.092 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 14:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|239|, RESULT: 0E0
2023.01.11 22:22:54.094 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 14:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|239|, RESULT: 1
2023.01.11 22:22:54.098 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 15:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|164|, RESULT: 0E0
2023.01.11 22:22:54.100 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 15:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|164|, RESULT: 1
2023.01.11 22:22:54.104 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 16:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|321|, RESULT: 0E0
2023.01.11 22:22:54.106 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 16:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|321|, RESULT: 1
2023.01.11 22:22:54.109 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 17:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|297|, RESULT: 0E0
2023.01.11 22:22:54.111 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 17:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|297|, RESULT: 1
2023.01.11 22:22:54.115 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 18:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|262|, RESULT: 0E0
2023.01.11 22:22:54.117 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 18:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|262|, RESULT: 1
2023.01.11 22:22:54.121 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 19:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|220|, RESULT: 0E0
2023.01.11 22:22:54.123 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 19:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|220|, RESULT: 1
2023.01.11 22:22:54.127 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 20:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|414|, RESULT: 0E0
2023.01.11 22:22:54.129 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 20:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|414|, RESULT: 1
2023.01.11 22:22:54.132 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 21:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|262|, RESULT: 0E0
2023.01.11 22:22:54.134 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 21:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|262|, RESULT: 1
2023.01.11 22:22:54.139 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-10 22:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|260|, RESULT: 0E0
2023.01.11 22:22:54.141 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-10 22:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|260|, RESULT: 1
2023.01.11 22:22:54.144 4: DbRep DBRep_avgtim_total_power - UPDATE history: 2023-01-09 23:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|202|, RESULT: 0E0
2023.01.11 22:22:54.146 4: DbRep DBRep_avgtim_total_power - INSERT history: 2023-01-09 23:59:59|shelly_3em_haus|Shelly|calculated|avgtwm_hour_total_power|202|, RESULT: 1
2023.01.11 22:22:54.154 3: DbRep DBRep_avgtim_total_power - number of lines updated in "DBLogging": 0
2023.01.11 22:22:54.155 3: DbRep DBRep_avgtim_total_power - number of lines inserted into "DBLogging": 24
2023.01.11 22:22:54.172 4: DbRep DBRep_avgtim_total_power - execute command after averageValue: 'msg push -1 [DBRep_avgtim_total_power:state] taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:total_power MT691_power'
2023.01.11 22:22:54.372 3: msg globalMsg: ID=1673472174.17602.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='running taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:total_power MT691_power'


Die Daten als Anhang.


Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 22:48:04
Welche Readings bekommst du wenn du die gleiche Selektion mit der "display" Option ausführst ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 22:54:11
Ich hoffe das ist so ok, quaisi eine Stunde verschoben aber die gleichen Werte:


2023-01-10_00__shelly_3em_haus__total_power__AVGTWM__2023-01-10_00 222 2023-01-11 22:49:52
2023-01-10_01__shelly_3em_haus__total_power__AVGTWM__2023-01-10_01 124 2023-01-11 22:49:52
2023-01-10_02__shelly_3em_haus__total_power__AVGTWM__2023-01-10_02 89 2023-01-11 22:49:52
2023-01-10_03__shelly_3em_haus__total_power__AVGTWM__2023-01-10_03 111 2023-01-11 22:49:52
2023-01-10_04__shelly_3em_haus__total_power__AVGTWM__2023-01-10_04 102 2023-01-11 22:49:52
2023-01-10_05__shelly_3em_haus__total_power__AVGTWM__2023-01-10_05 101 2023-01-11 22:49:52
2023-01-10_06__shelly_3em_haus__total_power__AVGTWM__2023-01-10_06 123 2023-01-11 22:49:52
2023-01-10_07__shelly_3em_haus__total_power__AVGTWM__2023-01-10_07 403 2023-01-11 22:49:52
2023-01-10_08__shelly_3em_haus__total_power__AVGTWM__2023-01-10_08 608 2023-01-11 22:49:52
2023-01-10_09__shelly_3em_haus__total_power__AVGTWM__2023-01-10_09 74 2023-01-11 22:49:52
2023-01-10_10__shelly_3em_haus__total_power__AVGTWM__2023-01-10_10 95 2023-01-11 22:49:52
2023-01-10_11__shelly_3em_haus__total_power__AVGTWM__2023-01-10_11 71 2023-01-11 22:49:52
2023-01-10_12__shelly_3em_haus__total_power__AVGTWM__2023-01-10_12 121 2023-01-11 22:49:52
2023-01-10_13__shelly_3em_haus__total_power__AVGTWM__2023-01-10_13 74 2023-01-11 22:49:52
2023-01-10_14__shelly_3em_haus__total_power__AVGTWM__2023-01-10_14 239 2023-01-11 22:49:52
2023-01-10_15__shelly_3em_haus__total_power__AVGTWM__2023-01-10_15 164 2023-01-11 22:49:52
2023-01-10_16__shelly_3em_haus__total_power__AVGTWM__2023-01-10_16 321 2023-01-11 22:49:52
2023-01-10_17__shelly_3em_haus__total_power__AVGTWM__2023-01-10_17 297 2023-01-11 22:49:52
2023-01-10_18__shelly_3em_haus__total_power__AVGTWM__2023-01-10_18 262 2023-01-11 22:49:52
2023-01-10_19__shelly_3em_haus__total_power__AVGTWM__2023-01-10_19 220 2023-01-11 22:49:52
2023-01-10_20__shelly_3em_haus__total_power__AVGTWM__2023-01-10_20 414 2023-01-11 22:49:52
2023-01-10_21__shelly_3em_haus__total_power__AVGTWM__2023-01-10_21 262 2023-01-11 22:49:52
2023-01-10_22__shelly_3em_haus__total_power__AVGTWM__2023-01-10_22 260 2023-01-11 22:49:52
2023-01-10_23__shelly_3em_haus__total_power__AVGTWM__2023-01-10_23 202 2023-01-11 22:49:52
state done 2023-01-11 22:49:52
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 22:57:14
Stop Reihenfolge anders
Moment
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 23:09:31
So jetzt gleich sortiert


Datenbank                                                     Display
2023-01-09 23:59:59;avgtwm_hour_total_power;202;             
2023-01-10 00:59:59;avgtwm_hour_total_power;222;              total_power__AVGTWM__2023-01-10_00 222
2023-01-10 01:59:59;avgtwm_hour_total_power;124;              total_power__AVGTWM__2023-01-10_01 124
2023-01-10 02:59:59;avgtwm_hour_total_power;89;\              total_power__AVGTWM__2023-01-10_02 89
2023-01-10 03:59:59;avgtwm_hour_total_power;111;              total_power__AVGTWM__2023-01-10_03 111
2023-01-10 04:59:59;avgtwm_hour_total_power;102;              total_power__AVGTWM__2023-01-10_04 102
2023-01-10 05:59:59;avgtwm_hour_total_power;101;              total_power__AVGTWM__2023-01-10_05 101
2023-01-10 06:59:59;avgtwm_hour_total_power;123;              total_power__AVGTWM__2023-01-10_06 123
2023-01-10 07:59:59;avgtwm_hour_total_power;403;              total_power__AVGTWM__2023-01-10_07 403
2023-01-10 08:59:59;avgtwm_hour_total_power;608;              total_power__AVGTWM__2023-01-10_08 608
2023-01-10 09:59:59;avgtwm_hour_total_power;74;\              total_power__AVGTWM__2023-01-10_09 74
2023-01-10 10:59:59;avgtwm_hour_total_power;95;\              total_power__AVGTWM__2023-01-10_10 95
2023-01-10 11:59:59;avgtwm_hour_total_power;71;\              total_power__AVGTWM__2023-01-10_11 71
2023-01-10 12:59:59;avgtwm_hour_total_power;121;              total_power__AVGTWM__2023-01-10_12 121
2023-01-10 13:59:59;avgtwm_hour_total_power;74;\              total_power__AVGTWM__2023-01-10_13 74
2023-01-10 14:59:59;avgtwm_hour_total_power;239;              total_power__AVGTWM__2023-01-10_14 239
2023-01-10 15:59:59;avgtwm_hour_total_power;164;              total_power__AVGTWM__2023-01-10_15 164
2023-01-10 16:59:59;avgtwm_hour_total_power;321;              total_power__AVGTWM__2023-01-10_16 321
2023-01-10 17:59:59;avgtwm_hour_total_power;297;              total_power__AVGTWM__2023-01-10_17 297
2023-01-10 18:59:59;avgtwm_hour_total_power;262;              total_power__AVGTWM__2023-01-10_18 262
2023-01-10 19:59:59;avgtwm_hour_total_power;220;              total_power__AVGTWM__2023-01-10_19 220
2023-01-10 20:59:59;avgtwm_hour_total_power;414;              total_power__AVGTWM__2023-01-10_20 414
2023-01-10 21:59:59;avgtwm_hour_total_power;262;              total_power__AVGTWM__2023-01-10_21 262
2023-01-10 22:59:59;avgtwm_hour_total_power;260;              total_power__AVGTWM__2023-01-10_22 260
                                                            total_power__AVGTWM__2023-01-10_23 202
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 23:11:37
Schaue ich mir an, aber heute nicht mehr  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 23:12:28
Wenn ich die zugrunde liegenden Werte betrachte gehört der Wert in der Datenbank am 9.1 um 23:59 Uhr eigentlich zum 10.1 23:59 Uhr

Alles klar.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Januar 2023, 23:14:53
Ja, ich habe eine Idee ... In der Rückschreibroutine gefunden. Aber es ist zu kompliziert für diese Uhrzeit.
Das stelle ich besser zurück.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 11 Januar 2023, 23:27:04
Immer gemach und mit der nötigen Ruhe. Verschlimmbessern ist auch doof.

Das Problem an den Datenbankgeschichten ist, dass es nur beim Ausprobieren auffällt.
Wenn das mal im Regelbetrieb und damit permanent läuft, fällt die Verschiebung nicht mehr auf. Es sind ja alle Zeitstempel bedient und wenn dann die Datenbank noch reduziert ist kann man auch nicht "nachrechnen".

Beim Verbrauch mit dem Shelly_3EM gemessen fällt es etwas leichter auf, da zu allen Uhrzeiten ohne Lücken permanent Strom fließt und damit Leistung ansteht.

Gruß Ralf und gutes Gelingen mit der Idee
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 12 Januar 2023, 13:44:07
Moin allerseits!

Ich möcht auch noch mal mein bisschen Senf dazu geben. Und zwar bezüglich des gewichteten Mittelns, bei dem ja Datenpunkte, deren "Gültigkeitszeitraum" die Grenzen der Mittelungsintervalle überschneiden, nicht berücksichtigt werden.

Ich habe die entsprechende Routine in 93_DbRep.pm so angepasst, dass diese Datenpunkte anteilig dem jeweiligen Mittelungsintervall zugerechnet werden. Ein Nebeneffekt: auch Intervalle mit nur einem Datenpunkt sind nun möglich.

Hier mal das Ergebnis für den extremen Fall, dass nur etwa jedes 2. Intervall einen Datenpunkt enthält:
Die Originaldaten:
TIMESTAMP         VALUE
2023-01-08 00:11:01 0.289
2023-01-08 00:12:36 0.284
2023-01-08 00:14:12 0.336
2023-01-08 00:15:45 0.479
2023-01-08 00:17:22 0.272
2023-01-08 00:20:32 0.503
2023-01-08 00:22:04 0.496
2023-01-08 00:25:15 0.488

Ergebnis  mit der alten Mittelung:
Readings
2023-01-08_00-09__E_Zaehler__power__AVGTWM__2023-01-08_00_09 - 2023-01-12 13:18:18
2023-01-08_00-10__E_Zaehler__power__AVGTWM__2023-01-08_00_10 - 2023-01-12 13:18:18
2023-01-08_00-11__E_Zaehler__power__AVGTWM__2023-01-08_00_11 0.0000 2023-01-12 13:18:18
2023-01-08_00-12__E_Zaehler__power__AVGTWM__2023-01-08_00_12 0.0000 2023-01-12 13:18:18
2023-01-08_00-13__E_Zaehler__power__AVGTWM__2023-01-08_00_13 - 2023-01-12 13:18:18
2023-01-08_00-14__E_Zaehler__power__AVGTWM__2023-01-08_00_14 0.0000 2023-01-12 13:18:18
2023-01-08_00-15__E_Zaehler__power__AVGTWM__2023-01-08_00_15 0.0000 2023-01-12 13:18:18
2023-01-08_00-16__E_Zaehler__power__AVGTWM__2023-01-08_00_16 - 2023-01-12 13:18:18
2023-01-08_00-17__E_Zaehler__power__AVGTWM__2023-01-08_00_17 0.0000 2023-01-12 13:18:18
2023-01-08_00-18__E_Zaehler__power__AVGTWM__2023-01-08_00_18 - 2023-01-12 13:18:18
2023-01-08_00-19__E_Zaehler__power__AVGTWM__2023-01-08_00_19 - 2023-01-12 13:18:18
2023-01-08_00-20__E_Zaehler__power__AVGTWM__2023-01-08_00_20 0.0000 2023-01-12 13:18:18
2023-01-08_00-21__E_Zaehler__power__AVGTWM__2023-01-08_00_21 - 2023-01-12 13:18:18
2023-01-08_00-22__E_Zaehler__power__AVGTWM__2023-01-08_00_22 0.0000 2023-01-12 13:18:18
2023-01-08_00-23__E_Zaehler__power__AVGTWM__2023-01-08_00_23 - 2023-01-12 13:18:18
2023-01-08_00-24__E_Zaehler__power__AVGTWM__2023-01-08_00_24 - 2023-01-12 13:18:18
2023-01-08_00-25__E_Zaehler__power__AVGTWM__2023-01-08_00_25 0.0000 2023-01-12 13:18:18
2023-01-08_00-26__E_Zaehler__power__AVGTWM__2023-01-08_00_26 - 2023-01-12 13:18:18
2023-01-08_00-27__E_Zaehler__power__AVGTWM__2023-01-08_00_27 - 2023-01-12 13:18:18
2023-01-08_00-28__E_Zaehler__power__AVGTWM__2023-01-08_00_28 - 2023-01-12 13:18:18
2023-01-08_00-29__E_Zaehler__power__AVGTWM__2023-01-08_00_29 - 2023-01-12 13:18:18
2023-01-08_00-30__E_Zaehler__power__AVGTWM__2023-01-08_00_30 - 2023-01-12 13:18:18
background_processing_time 0.1199 2023-01-12 13:18:18
sql_processing_time 0.1091 2023-01-12 13:18:18
state done 2023-01-12 13:18:18

Ergebnis  mit der neuen Mittelung:
Readings
2023-01-08_00-09__E_Zaehler__power__AVGTWM__2023-01-08_00_09 - 2023-01-12 13:11:33
2023-01-08_00-10__E_Zaehler__power__AVGTWM__2023-01-08_00_10 - 2023-01-12 13:11:33
2023-01-08_00-11__E_Zaehler__power__AVGTWM__2023-01-08_00_11 0.2890 2023-01-12 13:11:33
2023-01-08_00-12__E_Zaehler__power__AVGTWM__2023-01-08_00_12 0.2870 2023-01-12 13:11:33
2023-01-08_00-13__E_Zaehler__power__AVGTWM__2023-01-08_00_13 0.2840 2023-01-12 13:11:33
2023-01-08_00-14__E_Zaehler__power__AVGTWM__2023-01-08_00_14 0.3256 2023-01-12 13:11:33
2023-01-08_00-15__E_Zaehler__power__AVGTWM__2023-01-08_00_15 0.3718 2023-01-12 13:11:33
2023-01-08_00-16__E_Zaehler__power__AVGTWM__2023-01-08_00_16 0.4790 2023-01-12 13:11:33
2023-01-08_00-17__E_Zaehler__power__AVGTWM__2023-01-08_00_17 0.3479 2023-01-12 13:11:33
2023-01-08_00-18__E_Zaehler__power__AVGTWM__2023-01-08_00_18 0.2720 2023-01-12 13:11:33
2023-01-08_00-19__E_Zaehler__power__AVGTWM__2023-01-08_00_19 0.2720 2023-01-12 13:11:33
2023-01-08_00-20__E_Zaehler__power__AVGTWM__2023-01-08_00_20 0.3798 2023-01-12 13:11:33
2023-01-08_00-21__E_Zaehler__power__AVGTWM__2023-01-08_00_21 0.5030 2023-01-12 13:11:33
2023-01-08_00-22__E_Zaehler__power__AVGTWM__2023-01-08_00_22 0.4965 2023-01-12 13:11:33
2023-01-08_00-23__E_Zaehler__power__AVGTWM__2023-01-08_00_23 0.4960 2023-01-12 13:11:33
2023-01-08_00-24__E_Zaehler__power__AVGTWM__2023-01-08_00_24 0.4960 2023-01-12 13:11:33
2023-01-08_00-25__E_Zaehler__power__AVGTWM__2023-01-08_00_25 0.4900 2023-01-12 13:11:33
2023-01-08_00-26__E_Zaehler__power__AVGTWM__2023-01-08_00_26 0.4880 2023-01-12 13:11:33
2023-01-08_00-27__E_Zaehler__power__AVGTWM__2023-01-08_00_27 0.4880 2023-01-12 13:11:33
2023-01-08_00-28__E_Zaehler__power__AVGTWM__2023-01-08_00_28 0.4880 2023-01-12 13:11:33
2023-01-08_00-29__E_Zaehler__power__AVGTWM__2023-01-08_00_29 0.4880 2023-01-12 13:11:33
2023-01-08_00-30__E_Zaehler__power__AVGTWM__2023-01-08_00_30 0.0000 2023-01-12 13:11:33
background_processing_time 0.1567 2023-01-12 13:11:33
sql_processing_time 0.1446 2023-01-12 13:11:33
state done 2023-01-12 13:11:3


Der (kommentierte) Code ist im Anhang. Änderungen wurden nur in der "sub DbRep_averval" vorgenommen. Alle Änderungen sind mit 'alkazaa' markiert.
(Disclaimer: ich bin immer noch ziemlicher Perl-Anfänger, also auf Risiken und Nebenwirkungen achten)

Beste Grüße
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Januar 2023, 13:50:56
Moin Franz,

danke. Nehme ich gerne entgegen und versuche deinen Patch einzubauen und gegenzuchecken.
Melde mich wenn ich eine Testversion fertig habe.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 12 Januar 2023, 17:06:49
Zitat von: alkazaa am 12 Januar 2023, 13:44:07
....
Hier mal das Ergebnis für den extremen Fall, dass nur etwa jedes 2. Intervall einen Datenpunkt enthält:
Die Originaldaten:
TIMESTAMP         VALUE
2023-01-08 00:11:01 0.289
2023-01-08 00:12:36 0.284
............

Ergebnis  mit der alten Mittelung:
Readings
2023-01-08_00-09__E_Zaehler__power__AVGTWM__2023-01-08_00_09 - 2023-01-12 13:18:18
2023-01-08_00-10__E_Zaehler__power__AVGTWM__2023-01-08_00_10 - 2023-01-12 13:18:18
............

Ergebnis  mit der neuen Mittelung:
Readings
2023-01-08_00-09__E_Zaehler__power__AVGTWM__2023-01-08_00_09 - 2023-01-12 13:11:33
2023-01-08_00-10__E_Zaehler__power__AVGTWM__2023-01-08_00_10 - 2023-01-12 13:11:33
.........

....

Hallo Franz
Upps das ist höhere Mathematik  ::)

Das mit der alten Mittelung in den  Minuten 11,12,14,15,17,20,22,25 nur Null herauskommt ist natürlich unschön.

Die neue Mittelung verstehe ich auch nicht so ganz (liegt vermutlich am Fehlverständnis von Datenpunkt, Mittelungsintervall & zeitliche Grenzen (BIN)) bzw. es entsteht nicht das, was ich erwarten würde (wenn das Intervall eine Miunte ist). Am Anfang / Mitte komme ich glaube ich soweit mit.

Z.B. die Minuten 26-29 sind ohne Werte - trotzdem ist das AVG-Ergebnis der Wert von Minute 25. Müsste das nicht zumindest kleiner werden - bzw. ab wann gilt denn 0?
Müsste ja ab der kompletten Minute 30 sein - also nach 29 (ist ja noch 0,488)
   ::) Oh je


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 12 Januar 2023, 19:06:27
Zitat von: RalfRog am 12 Januar 2023, 17:06:49
Die neue Mittelung verstehe ich auch nicht so ganz (liegt vermutlich am Fehlverständnis von Datenpunkt, Mittelungsintervall & zeitliche Grenzen (BIN)) bzw. es entsteht nicht das, was ich erwarten würde (wenn das Intervall eine Miunte ist). Am Anfang / Mitte komme ich glaube ich soweit mit.
Z.B. die Minuten 26-29 sind ohne Werte - trotzdem ist das AVG-Ergebnis der Wert von Minute 25. Müsste das nicht zumindest kleiner werden - bzw. ab wann gilt denn 0?

OK, das mit Minute 30 ist in der Tat noch ein Fehler, denn da sollte gar kein Wert sein (timestamp_begin und _end war auf 00:00:00 und 00:30:00 gesetzt, dh. in Minute 30 sollte gar kein Wert auftauchen, aber nicht 0).

Dann muss man bedenken, dass der Mittelwert eines Teilintervalls (im engl. bin) dem Zeitstempel des Intervallanfangs zugeordnet wird (das war schon immer der Fall in DbRep).

Des weiteren: die gemessenen Originalwerte in FHEM gelten ja immer so lange, bis eine neue Messung neue Information liefert. Entweder weil man nicht oft genug misst, oder weil sich der Messwert innerhalb der Auflösung des Messgeräts nicht ändert. Fairerweise müsste man also im Plot eine Stufengraphik wählen: der Messwert bleibt in der graphischen Darstellung so lange konstant, bis eine neue Messung vorliegt (mit dem gleichen oder anderen Messwert als vorher). Ich logge in FHEM aber in der Regel mit 'event-on-change-reading'.

In graphischer Darstellung wird's vielleicht klarer: die roten Punkte sind die Oiginaldaten, verbunden mit der roten Linie als Stufengraphik. Die schwarzen Punkte sind die errechneten, sie liegen jeweils zur vollen Minute auf den senkrechten Linien, mit denen die minütlichen Intervallgrenzen markiert sind. Auch diese Punkte sind als Stufengraphik dargestellt. Am Beispiel des Wertes für Minute 17 kann man sich klar machen, wie gerechnet wird: 22 sec lang galt noch der letzte Wert 0,479, dann ab Minute 17:22 der Wert 0,272 für die restlichen 38 sec. Also 0,3479=(22*0,479+38*0,272)/60. Ab Minute 26 kam kein neuer Wert, daher 0,488 bis zum Ende. Und vor Minute 11 gab es noch keine Werte im Gesamtzeitraum [00:00 bis 30:00]. Und wenn man [00:00 bis 29:59] wählt, taucht auch die irritierende 0 am Ende nicht mehr auf.

Und natürlich ist das ganze Beispiel hier zwar anwendungsfremd, aber es lässt sich halt "zu Fuss" rechnerisch überprüfen (ohne höhere Mathematik, nur mit Grundrechenarten ;) ).

Eine gründliche Überprüfung an realen Beispielen steht noch aus. Man sollte dabei aber praktisch keine Unterschiede zwischen der alten und der neuen Methode sehen, wenn die Zahl der zu mittelnden Daten einigermaßen groß ist. 

Beste Grüße
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Januar 2023, 21:02:29
Hallo,

ich habe den Zeitstempelfehler bein Rückschreiben in die DB gefixt (zumindest lt. meinen Tests).
Testet es mal bitte dagegen.

Den Code von Franz habe ich noch nicht integriert. Ich wollte erstmal das eine Prob erledigen.
Kommt als nächstes dran wenn der Fix klar ist.

Liegt im contrib als 8.51.2
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 12 Januar 2023, 22:47:53
Zitat von: DS_Starter am 12 Januar 2023, 21:02:29
...
Testet es mal bitte dagegen.
...

Ich probier es aus. Muss mir nur morgen ne Datenlücke suchen, da ich gestern relativ viel zu Fuß gemacht und 23:45 meine Chain zum ersten Mal läuft  ;D

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 12 Januar 2023, 22:57:06
Zitat von: alkazaa am 12 Januar 2023, 19:06:27
...
Des weiteren: die gemessenen Originalwerte in FHEM gelten ja immer so lange, bis eine neue Messung neue Information liefert. Entweder weil man nicht oft genug misst, oder weil sich  man [00:00 bis 29:59] wählt, taucht auch die irritierende 0 am Ende nicht mehr auf.

Und natürlich ist das ganze Beispiel hier zwar anwendungsfremd, aber es lässt sich halt "zu Fuss" rechnerisch überprüfen (ohne höhere Mathematik, nur mit Grundrechenarten ;) ).
...

Super danke für die ausführliche Erläuterung. Die Idee sich das mit der Grafik zu veranschaulichen ist echt gut.
Nach dem Schnelldurchgang muss ich noch mal intensiver ran
- und tatsächlich mal meine Datenreihe vom PV Balkon-Modul anschauen ob ich am Ende der Sonnenscheindauer sauber aufhöre.
Wegen des Plots schreibe ich abends und morgens schon händisch ne 0 in die DB rein weil sonst öfter mal schiefe Linien entstehen. Irgend ein Umstand lässt öfter mal als ersten Wert um 10W erscheinen und dann geht es gemächlichab 0,5W aufwärts.

Im Grunde hat mich das Ende verwirrt in der Mitte konnte ich folgen - eben wie im Zitat:
"0,3479=(22*0,479+38*0,272)/60. Ab Minute 26 kam kein neuer Wert, daher 0,488 bis zum Ende."
Der letzte Wert muss einfach in Gedanken ala "event-on-change" gehalten werden.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 12 Januar 2023, 23:57:13
Zitat von: RalfRog am 12 Januar 2023, 22:47:53
Ich probier es aus. Muss mir nur morgen ne Datenlücke suchen, da ich gestern relativ viel zu Fuß gemacht und 23:45 meine Chain zum ersten Mal läuft  ;D

Habe dummerweise doch noch schnell vor dem Chain-Lauf probieren wollen. Leider Error. Konnte das alte DBRep noch pünktlich reloaden.

Also, habe die Datei aus dem Contrib nach ~/FHEM geladen und ein "reload reload 93_DbRep.pm" gemacht.

Attribute gesetzt
aggregation       day   (versehentlich, hätte hour sein sollen)
averageCalcForm   avgTimeWeightMean
timestamp_begin   2023-01-11 00:00:00
timestamp_end   2023-01-11 23:59:59

Kommando
LASTCMD    averageValue writeToDBSingle

Log

2023.01.12 23:32:03.067 3: WARNING: DBLogging attribute bulkInsert was renamed to insertMode
2023.01.12 23:32:03.070 1: PERL WARNING: Use of uninitialized value $cm in split at ./FHEM/93_DbLog.pm line 6931.
2023.01.12 23:32:03.072 1: PERL WARNING: Use of uninitialized value $ac in pattern match (m//) at ./FHEM/93_DbLog.pm line 6933.
2023.01.12 23:32:03.073 1: PERL WARNING: Use of uninitialized value $ta in pattern match (m//) at ./FHEM/93_DbLog.pm line 6937.
2023.01.12 23:32:03.084 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7065.
2023.01.12 23:32:03.086 1: PERL WARNING: Use of uninitialized value $history in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7065.
2023.01.12 23:32:03.087 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7066.
2023.01.12 23:32:03.088 1: PERL WARNING: Use of uninitialized value $current in concatenation (.) or string at ./FHEM/93_DbLog.pm line 7066.

2023.01.12 23:32:13.936 2: DbRep DBRep2_MT - ERROR - DBD::mysql::st execute failed: called with 6 bind variables when 7 are needed at ./FHEM/93_DbRep.pm line 11221.


Achtung merke ich gerade erst:
Habe heute Nachmittag  17:14 Uhr ein "offizielles" Update 93_DbLog.pm & 93_DbRep.pm jeweils mit Reload der Module gemacht (kein Restart FHEM).
Seit dem (17:16:09) kommen alle 2 Minuten die 7-Log-Einträge zur DBLog.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 Januar 2023, 00:21:40
Habe jetzt doch noch einen Fhem-Restart gemacht.

Die DBLog-Meldungen alle 2 Minuten sind weg und ich sehe im Log, dass sie schon weg waren nachdem um 23:45 mein reduceLog (nicht mehr Contrib-Version) gelaufen ist.
Hmmmm.....

Zumindest hier noch die Log Daten zum DB* beim Hochlauf:

2023.01.13 00:06:32.031 2: DbLog DBLogging - Subprocess >22099< initialized ... ready for non-blocking operation
2023.01.13 00:06:32.047 3: WARNING: DBLogging attribute bulkInsert was renamed to insertMode
2023.01.13 00:06:34.589 2: DbLog DBTest - Subprocess >22100< initialized ... ready for non-blocking operation
2023.01.13 00:07:47.442 3: DbLog DBLogging - DB connection parameters are initialized in the SubProcess
2023.01.13 00:07:47.479 3: DbLog DBTest - DB connection parameters are initialized in the SubProcess
2023.01.13 00:07:47.524 3: DbLog DBTest - DB connection parameters are stored in SubProcess
2023.01.13 00:07:47.675 3: DbLog DBLogging - DB connection parameters are stored in SubProcess
2023.01.13 00:08:17.548 3: DbLog DBLogging - SubProcess connected to fhem


Vom DBRep im Contrib lass ich nach dem Error jetzt aber die Finger bis zur Rückmeldung.
Generell:  Reicht der Reload?

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Januar 2023, 08:25:02
Moin Ralf,

die Meldungen von DbLog sind die Standardmeldungen der aktuellen Version. Im letzten Update wurde das Attr bulkInsert automatisiert umbenannt. Stand ja auch in den Update-Notes.

Zitat
2023.01.12 23:32:13.936 2: DbRep DBRep2_MT - ERROR - DBD::mysql::st execute failed: called with 6 bind variables when 7 are needed at ./FHEM/93_DbRep.pm line 11221.
Da ist eines der Felder für die DB "undefined". Vermutlich ist bei dir eines der Felder ausgeblendet (Attr col... im DbLog) oder aber beim Rückschreiben "undef". Aber egal, dass muss ich abfangen und die Schreibfunktion nochmal ändern. Mache ich nachher gleich.

Zitat
Generell:  Reicht der Reload?
Klare Antwort ... es kommt darauf an.
Bei "einfachen" Modulen reicht ein reload meistens. ABER ... komplexere Module lagern Funktionen in andere Library-Module aus, haben subProzesse (wie DbLog) und andere Architekturen. Dann führt der eine reload u.U. zu unpassenden Codes.
Der Normal-User kann das nicht überblicken.
Deswegen ganz klare Empfehlung ... bei Updates IMMER einen Restart machen es sei denn man weiß genau dass ein reload reicht weil man sich z.B. genauer mit dem Modul befasst hat.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 Januar 2023, 10:35:24
Im DBLog habe ich kein Attribut Col... gesetzt.

In den Spalten UNIT hatte ich letzte Woche mit changeValue Einheiten nachpflegt.
Vorher waren sie leer "". Die Funktionen averageValue (min, max) setzen ja (NULL) - also ohne Wert. .
Undef und (NULL) sind aber vermutlich 2 verschiedene Paar Schuhe. 

Bei normalen Updates ist ein Restart zwar gelebte Praxis aber für die beiden Module wollte ich mein Livesystem nicht rund fahren.
Mach dann zukünftig bei DBLog/Rep auf jeden Fall mit Restart.

Vielen Dank für deine Arbeit  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Januar 2023, 10:54:27
So, neue DbRep liegt im contrib. Es reicht ein reload  ;)

Naja, es kann theoretisch immer passieren dass ein errechnetes Feld undef / NULL ist. Deswegen darf kein Fehler kommen.
Sollte nun nicht mehr in der Rewrite Routine passieren.

<OT> Bei Update DbLog wegen des Subprozesses auf jeden Fall restarten </OT>

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 Januar 2023, 15:30:27
So habe die Version aus dem Contrib probiert.

Für ein Reading am 12.1  00:00:00 bis 23:59:59 mit "averageValue writeToDBSingle" und "aggregation = hour" wurde der gewichtete Mittelwert berechnet.

TYPE ist Uppercase und die Daten sind mit korrekten Zeitstempeln von 00:59:59 bis 23:59:59 eingetragen  :)

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Januar 2023, 16:06:53
Wieder ein Fortschritt.  :)
Wahrscheinlich werde ich die Version heute einchecken und mich morgen dann mal an den Patch von Franz heranmachen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 13 Januar 2023, 17:14:31
Zitat von: DS_Starter am 13 Januar 2023, 16:06:53
Wahrscheinlich werde ich die Version heute einchecken und mich morgen dann mal an den Patch von Franz heranmachen.

Hab gerade meinen Patch in Deine neueste Version integriert und dabei gemerkt, dass ich an einer Stelle meine Änderung nicht kenntlich gemacht hatte. Daher hier jetzt der korrekt markierte patch...

Gruß
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 13 Januar 2023, 19:53:33
Hallo!
Ich ging bisher immer davon aus, dass die gemittelten Werte als timestamp den Beginn des Mittelungsintervalls zugeordnet bekommen, siehe die Diskussion in  meinem obigen (https://forum.fhem.de/index.php/topic,53584.msg1257453.html#msg1257453) Beitrag. Ich habe jetzt erstmals auch die gemittelten Daten abgespeichert und bemerkt, dass aber das Ende des Mittelungsintervalls zum timestamp des gemittelten Wertes wird.

Ich halte den Beginn des Mittelungsintervalls aber für die bessere Wahl, und möchte das mit den Bildern hier begründen. Dargestellt sind die gleichen Daten wir im erwähnten Beitrag, aber
a) für die Originaldaten ohne Verbindungen der Messpunkte
b) für die berechneten Daten mit direkter Verbindung der Punkte (wie es bei Liniengraphiken üblicherweise gewählt wird)

Im oberen Plot sind die avg Daten dem Intervallende zugeordnet (wie es z.Zt. in DbRep gemacht wird).
Im unteren sind sie dem Intervallanfang zugeordnet.

Ich hoffe, man erkennt warum ich das untere vorziehen würde.

-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 Januar 2023, 20:10:32
Sieht insbesondere in dieser "minutenauflösung" nachvollziehbar und logisch aus.

Bei mir persönlich ist es egal, da ich zur Zeit nur Energie als DayLast-Werte über das Statistik-Modul plotte.
Durchschnittswerte halte ich quasi nur als historischen Trend im Stunden-/Tagestakt fest um ältere Originaldaten der Zähler/Shellies deutlich zu reduzieren.

Aber ich kann mir vorstellen, dass es Fälle gibt wo es in der von dir gezeigten Weise auf jeden Fall besser passt.

Das soll jetzt aber keine Arbeitsbeschaffungsmaßnahme für Heiko sein  8) gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Januar 2023, 20:44:15
Es gibt ja verschiedene Schreibvarianten:

    writeToDB    : schreibt jeweils einen Wert mit den Zeitstempeln XX:XX:01 und XX:XX:59 innerhalb der jeweiligen Auswertungsperiode
    writeToDBSingle    : schreibt nur einen Wert mit dem Zeitstempel XX:XX:59 am Ende einer Auswertungsperiode
    writeToDBInTime    : schreibt jeweils einen Wert am Anfang und am Ende der Zeitgrenzen einer Auswertungsperiode

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 Januar 2023, 21:50:06
Unabhängig von alkazaa's Anmerkung hatte ich das schon mal ausprobiert writeToDB <> writeToDBInTime

Bei "aggregation = hour" kommt da meiner Ansicht nach kein großer Unterschied raus. Zeitbegrenzung 15:00:00 bis 20:59:59
Hab mal ein Beispiel angehängt.
Der erste Wert hat in meinem Beispiel (Screenshot) den Zeitstempel 15:00:00 statt 15:00:01.
Abgesehen von der ausreichenden Anzahl an Datenpunkten würde selbst ein stündlicher Aufruf letztlich auch nur die Zeiten von xx:00:01 auf xx:00:00 verschieben.
War das so gedacht?

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 13 Januar 2023, 21:50:47
mea culpa: hatte RTFM geschwänzt ...
-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 Januar 2023, 22:07:47
Habe noch folgende Option für averageValue ergänzt:

writeToDBSingleStart    : schreibt nur einen Wert mit dem Zeitstempel XX:XX:01 am Beginn einer Auswertungsperiode

Zitat
Bei "aggregation = hour" kommt da meiner Ansicht nach kein großer Unterschied raus. Zeitbegrenzung 15:00:00 bis 20:59:59
Hab mal ein neues Beispiel angehängt.
Der erste Wert hat in meinem Beispiel (Screenshot) den Zeitstempel 15:00:00 statt 15:00:01.
War das so gedacht?
Ja. Es beachtet die Grenzen der Selektion. D.h. wenn du 11:12:08 bis 23:21:16  selektierst, beachten der erste und letzte (neu geschriebene) Datensatz genau diese Zeitgrenzen und gehen mit XX:XX:01 nicht darunter oder mit XX:59:59 darüber.

Die ergänzte Version ist eingecheckt und liegt auch im contrib wenn ihr sie schon benutzen möchtet.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 Januar 2023, 22:29:36
Ok...

Dann kann man Attribute geschickt gesetzt natürlich so etwas hinbekommen und ist weg von der 01 bzw. 59:

2023-01-13 15:50:59;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;227;
2023-01-13 15:00:00;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;227;

2023-01-13 13:50:59;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;668;
2023-01-13 13:05:00;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;668;
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 15 Januar 2023, 14:25:14
Zitat von: DS_Starter am 13 Januar 2023, 16:06:53
Wahrscheinlich werde ich die Version heute einchecken und mich morgen dann mal an den Patch von Franz heranmachen.

Ich hoffe, Du hast noch nicht angefangen: Habe noch weiter "gepatcht" und jetzt wird auch der Anteil des letzten Wertes VOR dem allerersten Mittelungs-bin anteilig berücksichtigt.

Hier nochmal kurz zusammengefasst, was eigentlich gemacht wird:

       
  • der letzte Wert eines bins wird anteilig beim aktuellen bin mit gewertet
  • er wird als zusätzlicher Wert am Anfang des nächsten bins gesetzt und dadurch auch dort am Anfang anteilig mit gewertet
  • beim allerersten bin wird duch ein "peek-back-in-time" der letzte gemessene Wert vor Beginn des ersten Intervalls an den Beginn des ersten Intervalls gesetzt. Dazu wird natürlcih ein extra SQL-query nötig, und ich hoffe, ich habe das richtig gemacht.
So, jetzt hör ich auch auf, versprochen   ;)

Beste Grüße
Franz

EDIT: Anhang korrigiert (am Ende von Zeile 3480 fehlte ein ; )
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 Januar 2023, 14:42:46
Zitat
Ich hoffe, Du hast noch nicht angefangen
Nein, ich wußte dass noch etwas kommt.  :D

... nee, hatte noch keine Zeit/Lust. Eine andere Sache hatte meine Aufmerksamkeit.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Januar 2023, 22:24:53
Zitat von: DS_Starter am 13 Januar 2023, 22:07:47
...
writeToDBSingleStart    : schreibt nur einen Wert mit dem Zeitstempel XX:XX:01 am Beginn einer Auswertungsperiode
...
Schönes Feature habs mal dank "alkazaa" zum Kurven vergleichen ausprobiert.

Dabei ist mir folgendes  aufgefallen: 

CommandRef:
maxValue [display | writeToDB | deleteOther] - berechnet den Maximalwert des Datenbankfelds "VALUE" in den Zeitgrenzen .....
Die Auswertung enthält den Zeitstempel des ermittelten Maximumwertes innerhalb der Aggregation bzw. Zeitgrenzen. Im Reading wird der Zeitstempel des letzten Auftretens vom Maximalwert ausgegeben, falls dieser Wert im Intervall mehrfach erreicht wird


"Im Reading wird der Zeitstempel des letzten Auftretens..."
Tatsächlich wird (auch bei MIN) immer xx:xx:59 eingetragen. Ich weiss natürlich nicht was der Grund dafür ist - aber aus meiner Sicht wünschenswert ist tatsächlich, dass der Zeitstempel des Max/Min-Wertes erhalten bleibt.

Gruß Ralf

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2023, 22:45:59
Hallo Ralf,

habe min/max gerade mit aggregation hour und day getestet.
Geschrieben wird der richtige Timestamp:


2023.01.16 22:38:56.720 4: DbRep Rep.CPU - -------- New selection ---------
2023.01.16 22:38:56.721 4: DbRep Rep.CPU - Command: maxValue writeToDB
2023.01.16 22:38:56.722 4: DbRep Rep.CPU - FullDay option: 0
2023.01.16 22:38:56.722 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-01-05 11:12:08
2023.01.16 22:38:56.722 4: DbRep Rep.CPU - Timestamp end human readable: 2023-01-05 23:21:16
2023.01.16 22:38:56.723 4: DbRep Rep.CPU - Aggregation: hour
2023.01.16 22:38:56.745 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:38:56.756 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 11:12:08' AND TIMESTAMP < '2023-01-05 12' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.769 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 12' AND TIMESTAMP < '2023-01-05 13' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.771 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 13' AND TIMESTAMP < '2023-01-05 14' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.776 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 14' AND TIMESTAMP < '2023-01-05 15' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.779 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 15' AND TIMESTAMP < '2023-01-05 16' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.781 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 16' AND TIMESTAMP < '2023-01-05 17' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.785 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 17' AND TIMESTAMP < '2023-01-05 18' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.787 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 18' AND TIMESTAMP < '2023-01-05 19' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.790 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 19' AND TIMESTAMP < '2023-01-05 20' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.792 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 20' AND TIMESTAMP < '2023-01-05 21' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.794 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 21' AND TIMESTAMP < '2023-01-05 22' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.797 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 22' AND TIMESTAMP < '2023-01-05 23' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.799 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 23' AND TIMESTAMP <= '2023-01-05 23:21:16' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.805 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:38:56.816 4: DbRep Rep.CPU - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:38:56.817 4: DbRep Rep.CPU - SQL prepare: UPDATE history SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:38:56.818 4: DbRep Rep.CPU - SQL prepare: INSERT IGNORE INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:38:56.819 4: DbRep Rep.CPU - SQL prepare: UPDATE current SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:38:56.820 4: DbRep Rep.CPU - begin transaction
2023.01.16 22:38:56.830 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 11:35:31|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3492.1000|, RESULT: 0
2023.01.16 22:38:56.832 4: DbRep Rep.CPU - INSERT history: 2023-01-05 11:35:31|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3492.1000|, RESULT: 1
2023.01.16 22:38:56.833 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 12:05:00|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1507.3000|, RESULT: 0
2023.01.16 22:38:56.835 4: DbRep Rep.CPU - INSERT history: 2023-01-05 12:05:00|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1507.3000|, RESULT: 1
2023.01.16 22:38:56.836 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 13:13:02|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3297.1000|, RESULT: 0
2023.01.16 22:38:56.837 4: DbRep Rep.CPU - INSERT history: 2023-01-05 13:13:02|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3297.1000|, RESULT: 1
2023.01.16 22:38:56.839 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 14:36:23|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1920.2000|, RESULT: 0
2023.01.16 22:38:56.840 4: DbRep Rep.CPU - INSERT history: 2023-01-05 14:36:23|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1920.2000|, RESULT: 1
2023.01.16 22:38:56.841 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 15:07:52|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1399.2000|, RESULT: 0
2023.01.16 22:38:56.842 4: DbRep Rep.CPU - INSERT history: 2023-01-05 15:07:52|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1399.2000|, RESULT: 1
2023.01.16 22:38:56.843 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 16:59:34|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.844 4: DbRep Rep.CPU - INSERT history: 2023-01-05 16:59:34|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.845 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 17:59:28|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.846 4: DbRep Rep.CPU - INSERT history: 2023-01-05 17:59:28|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.847 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 18:59:26|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.848 4: DbRep Rep.CPU - INSERT history: 2023-01-05 18:59:26|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.873 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 19:59:22|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.875 4: DbRep Rep.CPU - INSERT history: 2023-01-05 19:59:22|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.876 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 20:59:15|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.877 4: DbRep Rep.CPU - INSERT history: 2023-01-05 20:59:15|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.878 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 21:58:08|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.879 4: DbRep Rep.CPU - INSERT history: 2023-01-05 21:58:08|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.880 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 22:59:14|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.881 4: DbRep Rep.CPU - INSERT history: 2023-01-05 22:59:14|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.883 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 23:20:33|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.884 4: DbRep Rep.CPU - INSERT history: 2023-01-05 23:20:33|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.886 4: DbRep Rep.CPU - transaction committed
2023.01.16 22:38:56.887 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 0
2023.01.16 22:38:56.887 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 13


und


2023.01.16 22:40:54.607 4: DbRep Rep.CPU - -------- New selection ---------
2023.01.16 22:40:54.610 4: DbRep Rep.CPU - Command: minValue writeToDB
2023.01.16 22:40:54.611 4: DbRep Rep.CPU - FullDay option: 0
2023.01.16 22:40:54.611 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-01-05 11:12:08
2023.01.16 22:40:54.612 4: DbRep Rep.CPU - Timestamp end human readable: 2023-01-05 23:21:16
2023.01.16 22:40:54.613 4: DbRep Rep.CPU - Aggregation: day
2023.01.16 22:40:54.632 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:40:54.637 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 11:12:08' AND TIMESTAMP <= '2023-01-05 23:21:16' ORDER BY TIMESTAMP;
2023.01.16 22:40:54.651 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:40:54.660 4: DbRep Rep.CPU - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:40:54.660 4: DbRep Rep.CPU - SQL prepare: UPDATE history SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:40:54.661 4: DbRep Rep.CPU - SQL prepare: INSERT IGNORE INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:40:54.662 4: DbRep Rep.CPU - SQL prepare: UPDATE current SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:40:54.662 4: DbRep Rep.CPU - begin transaction
2023.01.16 22:40:54.663 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 11:12:13|SMA_Energymeter|SMAEM||min_day_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:40:54.664 4: DbRep Rep.CPU - INSERT history: 2023-01-05 11:12:13|SMA_Energymeter|SMAEM||min_day_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:40:54.666 4: DbRep Rep.CPU - transaction committed
2023.01.16 22:40:54.667 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 0
2023.01.16 22:40:54.667 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 1


Welche Aggregation hast du verwendet ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Januar 2023, 22:56:42
Zitat von: DS_Starter am 16 Januar 2023, 22:45:59
...
Welche Aggregation hast du verwendet ?

Oh Mist...
Sehe gerade, dass die Werte die ich geprüft habe vom vom "reduceLog max" stammen und nicht vom maxValue  :-[
Sorry!

War meine Vorgehensweise um auf der einen Seite per averageValue writeToDBSingle Mittelwerte (timeWeighted) zu haben und trotzdem "recht einfach" die DB mit einem interessanten Wert zu reduzieren.
Aber mir würde auch der echte Zeitstempel gefallen. "reduceLog average" auf xx:xx:30 ist (für mich) logisch und gut.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2023, 23:10:49
Zitat
Aber mir würde auch der echte Zeitstempel gefallen.
Das wäre ein zu großer Umbau. Die Zeitstempel bei reduceLog sind ein Kompromiss und werde je nach Verfahren vorbelegt:

                'average' -> '30:00'
                'max'      -> '59:59'
                'min'      ->  '00:01'
                'sum'     ->  '00:00'

Dadurch soll sichergestellt werden, dass Ergebnsisse verschiedener reduceLog Verfahren sich nicht (zufällig) überdecken.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 Januar 2023, 23:25:45
Ja klar.

Sorry manchmal schaut man in die DB und stolpert... und hat dann die unterschiedlichen Methoden "reduclog Parameter" gegenüber "average|min|maxValue" nicht so direkt auf dem Schirm.

Die Stolperei hört jetzt vermutlich auf, da der Shelly3EM und das Logging & LangzeitLogging der gewünschten Werte eingestellt sind.

Und nochmal vielen Dank für DBLog & DBRep.
Wenn man sich getraut hat umzustellen (beim Einarbeiten hat HeidiSQL sehr geholfen) sind viele Sachen deutlich einfacher. Allein die ganzen Datenmanipulationen mit DBRep in den  letzten 10 Tagen  :)

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 Januar 2023, 23:32:44
Mein Job als Maintainer ist es unter anderem die Gesamtheit im Auge zu behalten.
Gelingt mal besser mal schlechter.  ;)

Aber Spaß macht es immer (naja meistens)  :)

(Und danke für deine/eure Ideen/Mitarbeit !!)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 18 Januar 2023, 09:27:33
Ich habe nach einem Update folgende Meldung im Log
Error:Modul 93_DbRep deactivated:
"evalDecodeJSON" is not exported by the FHEM::SynoModules::SMUtils module

Weiß jemand, was ich tun muss?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2023, 09:56:25
Hast du ein relativ aktuelles FHEM, d.h. das Modul  ../lib/FHEM/SynoModules/SMUtils.pm aktualisiert ?
Ich hatte vor vllt. 14 Tagen (?) die Datei SMUtils.pm ergänzt und ausgeliefert.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 18 Januar 2023, 10:37:47
Danke. Komischerweise wurde das bei mir nicht aktualisiert.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2023, 10:41:18
Hast du es jetzt ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: andies am 18 Januar 2023, 10:51:21
ja, von github.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 Januar 2023, 11:04:35
Komisch ... ist ganz normal eingecheckt.
Falls sich noch jemand deswegen melden sollte checke ich es einfach nochmal ein.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 Januar 2023, 22:57:37
Hallo,

ich habe die Zuarbeit von Franz leicht verändert eingearbeitet (Nutzung localtime, timelocal) und getestet.

@Franz ....


              if ($aval eq 'hour' || $aval eq 'minute') {
                  $time -= 3600;                                              # um 1 Stunde zurückblicken
              }
              elsif ($aval eq 'day') {
                  $time -= 24 * 3600;                                         # peek back by 1 day
              }
              elsif ($aval eq 'week') {
                  $time -= 3 * 24 * 3600;                                     # peek back by 3 days
              }
              elsif ($aval eq 'month') {
                  $time -= 7 * 24 * 3600;                                     # peek back by 1 week
              }
              else {
                  $time -= 30 * 24 * 3600;                                    # peek back by 1 month
              };


Die "Rückblicke" verstehe ich nicht ganz.
Warum gehst du bei "week" (nur) 3 Tage zurück, bei "month" (nur) 1 Woche und sonst einen Monat, wobei die Länge des Monats darauf ankommt von welchem Monat man ausgeht ?
Oder ist es eher eine empirische Wahl um einen Anfangswert mit einer gewissen Wahrscheinlichkeit zu ermitteln ?

Liegt als V 8.51.3 im contrib zum Gegentesten.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 20 Januar 2023, 14:07:36
Zitat von: DS_Starter am 19 Januar 2023, 22:57:37
ich habe die Zuarbeit von Franz leicht verändert eingearbeitet (Nutzung localtime, timelocal) und getestet.
Super, Vielen Dank!
Zitat von: DS_Starter am 19 Januar 2023, 22:57:37
Die "Rückblicke" verstehe ich nicht ganz.
Warum gehst du bei "week" (nur) 3 Tage zurück, bei "month" (nur) 1 Woche und sonst einen Monat, wobei die Länge des Monats darauf ankommt von welchem Monat man ausgeht ?
Oder ist es eher eine empirische Wahl um einen Anfangswert mit einer gewissen Wahrscheinlichkeit zu ermitteln ?
Genau, "gefühlte Empirie". Hab's aber geändert, sodass es weniger rätselhaft aussieht.

Ich habe noch 1 bug rausgeschissen, und auch Kommentare, die mir nicht mehr verständlich erschienen. Außerdem das ganze dann für Grenzfälle (kein Messwert im Rückblick-Zeitraum, oder überhaupt keine Werte im betrachteten Zeitraum) getestet und angepasst. Nicht ermittelbare Mittelwerte (z.B. kein Rückschau-Wert und keine Werte in den Anfangs-Bins, oder Ende des betrachteten Zeitraums genau auf Mittelungsperiode) werden jetzt auch mit '-' gekennzeichnet statt mit dem Wert 0.000.

-Franz

EDIT:
"Nicht ermittelbare Mittelwerte (z.B. kein Rückschau-Wert und keine Werte in den Anfangs-Bins, oder Ende des betrachteten Zeitraums genau auf Mittelungsperiode) werden jetzt auch mit '-' gekennzeichnet statt mit dem Wert 0.000."
Das war natürlicg Blödsinn, denn so wie ich's gemacht habe, werden auch "echte" 0.000 gelöscht. Muss mir das anders überlegen...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Januar 2023, 14:13:24
Danke Franz.
Schaue ich mir nachher gleich an.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Januar 2023, 11:27:25
Hallo,

@Franz, ich habe dein Update eingearbeitet.
Weil die DbRep_averval Sub inzwischen sehr unübersichtlich geworden ist und auch meinem aktuellen Stil nicht mehr entspricht, habe ich begonnen diese Funktion neu zu strukturieren und dadurch übersichtlicher zu gestalten.

Bin damit noch nicht ganz fertig, aber ihr könnt den Stand mit dem aktuellen Patch von Franz schon benutzen und testen.

V 8.51.3 im contrib.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Januar 2023, 14:48:51
Jetzt bin ich mir der Restrukturierung der averageValue Funk durch. Liegt wieder im contrib.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: der-Lolo am 22 Januar 2023, 09:31:06
Hallo Heiko,
ich beobachte derzeit Einträge im Logfile die offensichtlich durch meine ReduceLogChain hervorgerufen werden...

2023.01.21 23:45:19 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 9626.
2023.01.21 23:45:19 3: eval: {DbRep_getInitDataDone('Rep.Reduce.Older7Davg||MjAyMi0wNi0xMCAyMjowMzozNQ==|0.690913,0.693636|reduceLog||DbRep_Main|SW5kZXggUmVwb3J0X0lkeCBkb2Vzbid0IGV4aXN0XXXXbGVhc2UgY3JlYXRlIHRoZSBpbmRleCBieSAic2V0IFJlcC5SZWR1Y2UuT2xkZXI3RGF2ZyBpbmRleCByZWNyZWF0ZV9SZXBvcnRfSWR4IiBjb21tYW5kICE=|VVBEQVRFLERFTEVURSxTRUxFQ1QsVVNBR0UsSU5TRVJU|dXRmOA==|dXRmOA==')}


Kannst Du mir sagen was hier nicht wie geplant funktioniert?

Dank!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Januar 2023, 12:02:03
So richtig weiß ich es noch nicht. Mit welcher DbRep Version arbeitest du ?

Oder mach einfach mal ein list von dem DbRep-Device. Dann sehe ich alles was interessant sein könnte.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: der-Lolo am 22 Januar 2023, 12:39:41
Hallo Heiko,
hier das gewünschte list:
Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      63427754-f33f-4532-a08a-4cfd3fb05edc3e9e
   FVERSION   93_DbRep.pm:v8.51.2-s27047/2023-01-13
   LASTCMD    reduceLog average=hour
   MODEL      Client
   NAME       Rep.Reduce.Older7Davg
   NOTIFYDEV  global,Rep.Reduce.Older7Davg
   NR         675
   NTFY_ORDER 50-Rep.Reduce.Older7Davg
   ROLE       Client
   STATE      reduceLog of fhem finished
   TYPE       DbRep
   UTF8       1
   eventCount 5
   HELPER:
     DBLOGDEVICE logdb
     GRANTS     UPDATE,DELETE,SELECT,USAGE,INSERT
     IDRETRIES  2
     MINTS      2022-06-10 22:03:35
     PACKAGE    main
     VERSION    8.51.2
     CV:
       aggregation no
       aggsec     1
       destr      2023-01-14
       dsstr      2022-06-10
       epoch_seconds_end 1673736313.61569
       mestr      01
       msstr      06
       testr      23:45:13
       tsstr      22:03:35
       wdadd      259200
       yestr      2023
       ysstr      2022
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      0
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       background_processing_time:
         logdb:
           TIME       1674341137.17217
           VALUE      20.94
       connectionEncoding:
         logdb:
           TIME       1674341114.59061
           VALUE      utf8
       dbEncoding:
         logdb:
           TIME       1674341114.59061
           VALUE      utf8
       indexState:
         logdb:
           TIME       1674341114.59061
           VALUE      Index Report_Idx doesn't exist. Please create the index by "set Rep.Reduce.Older7Davg index recreate_Report_Idx" command !
       reduceLogState:
         logdb:
           TIME       1674341137.17217
           VALUE      reduceLog finished. Rows processed: 480587, deleted: 47338
       state:
         logdb:
           TIME       1674341137.17217
           VALUE      reduceLog of fhem finished
       timestamp_oldest_dataset:
         logdb:
           TIME       1674341114.59061
           VALUE      2022-06-10 22:03:35
       userRights:
         logdb:
           TIME       1674341114.59061
           VALUE      UPDATE,DELETE,SELECT,USAGE,INSERT
   OLDREADINGS:
   READINGS:
     2023-01-21 23:45:37   background_processing_time 20.94
     2023-01-21 23:45:37   reduceLogState  reduceLog finished. Rows processed: 480587, deleted: 47338
     2023-01-21 23:45:37   state           reduceLog of fhem finished
Attributes:
   allowDeletion 0
   devStateIcon devStateIcon connected|initialized:10px-kreis-gelb .*disconnect:10px-kreis-rot .*finished:10px-kreis-gruen
   executeAfterProc get Rep.Fhem.Size tableinfo
   room       90 - System -> 96 - Server -> MariaDBLog
   timeOlderThan d:7
   verbose    1


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Januar 2023, 14:34:03
Das war jetzt ein recht interessanter Fall.
Dieses Problem trat auf wenn das Feld VALUE den Wert NULL hatte, also nicht '<leer>' sondern undefiniert.

Habe es gelöst und die Version 8.51.3 in meinem contrib upgedated.
Kannst du die Version bitte bei dir laden, FHEM restarten und testen ?

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: der-Lolo am 22 Januar 2023, 15:13:24
Hallo Heiko,

sorry - mein Log sagt da passt noch was nicht.

2023.01.22 15:11:48 1: reload: Error:Modul 93_DbRep deactivated:
Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 0: Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 1: reload: Error:Modul 93_DbRep deactivated:
Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 0: Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 1: reload: Error:Modul 93_DbRep deactivated:
Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 0: Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 1: reload: Error:Modul 93_DbRep deactivated:
Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.

2023.01.22 15:11:48 0: Can't modify numeric lt (<) in scalar assignment at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
syntax error at ./FHEM/93_DbRep.pm line 9, near "93_DbRep"
Unknown regexp modifier "/D" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/_" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/S" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/r" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/t" at ./FHEM/93_DbRep.pm line 9, at end of line
Unknown regexp modifier "/e" at ./FHEM/93_DbRep.pm line 9, at end of line
./FHEM/93_DbRep.pm has too many errors.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Januar 2023, 15:18:02
Da hast du im contrib nicht den Download-Button benutzt. Siehe Anhang.

Oder zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: der-Lolo am 22 Januar 2023, 15:26:15
Ok - sorry, hatte den link kopiert und via ssh ein wget abgesetzt...
Keine Ahnung warum das nicht funktionierte - Deine Variante geht offensichtlich.

2023.01.22 15:24:38 3: DbRep Rep.Fhem.Size - get initial structure information of database "fhem", remaining attempts: 3
2023.01.22 15:24:38 3: DbRep Rep.Fhem.Size - Connectiontest to database mysql:database=fhem;host=192.168.1.99;port=3306 with user fhemuser
2023.01.22 15:24:39 3: DbRep Rep.Fhem.Size - WARNING - Index Report_Idx doesn't exist. Please create the index by "set Rep.Fhem.Size index recreate_Report_Idx" command !
2023.01.22 15:24:39 3: DbRep Rep.Fhem.Size - Initial data information retrieved - total time used: 0.6704 seconds
2023.01.22 15:24:39 3: DbRep Rep.Fhem.Size - Connectiontest to db mysql:database=fhem;host=192.168.1.99;port=3306 successful

jump to the top


Danke Dir..!
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Januar 2023, 15:27:25
Hast du reducelog laufen lassen ?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: der-Lolo am 22 Januar 2023, 15:33:33
Jepp - Size ist der letzte in der Kette.
Keine Meldungen von den vorherigen DbReps - es gab auch nicht viel zu tun für die DbReps da ich ein paar minuten vorher auch schon ausgeführt hatte.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 Januar 2023, 15:34:55
Prima. Ich checke die Version ein. Ist dann morgen früh im Update drin.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 24 Januar 2023, 19:33:26
Was ist eigentlich die Idee hinter dem Attribut readingNameMap?

Die kurze Beschreibung "A part of the created reading name will be replaced by the specified string" erschließt sich mir noch nicht wirklich.
Vor allem nicht, welcher Teil da warum ersetzt wird.

Aus 2023-01-24_19-18-00__<device>__<reading>__MAX__no_aggregation
wird 2023-01-24_19-21-00__bla__no_aggregation

wenn ich das Attribut auf "bla" setze und set ... maxValue display ausführe.

Kann ich den readingName komplett selbstbestimmen?
Oder welche eine einfache Möglichkeit gibt es, den Wert direkt (ohne Umweg über ein reading) einer Variablen zuzuweisen?
Irgendwie vermisse ich dafür ein "set ... maxValue raw"  :)

Wobei ich ehrlich gesagt nicht verstehe, warum das überhaupt mit "set" gemacht wird anstatt mit "get".
Aber das lasse ich mal als "künstlerische Freiheit des Entwicklers" durchgehen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2023, 20:56:56
Zitat
Was ist eigentlich die Idee hinter dem Attribut readingNameMap?
Das readingNameMap soll dem User die Möglichkeit geben die entstehen Readingnamen bei Bedarf zu vereinheitlichen und ihnen einen sprechenden Namen bezüglich ihres Inhaltes zu geben.

Zum Beispiel:


READINGS:
     2023-01-24 20:20:22   2023-01-01_15-52-49__Tageserzeugung_kWh__2023-01-01 4.5430
     2023-01-24 20:20:22   2023-01-02_15-52-19__Tageserzeugung_kWh__2023-01-02 5.9120
     2023-01-24 20:20:22   2023-01-03_16-13-32__Tageserzeugung_kWh__2023-01-03 17.0710
     2023-01-24 20:20:22   2023-01-04_15-44-28__Tageserzeugung_kWh__2023-01-04 0.8900
     2023-01-24 20:20:22   2023-01-05_15-54-51__Tageserzeugung_kWh__2023-01-05 4.8030
     2023-01-24 20:20:22   2023-01-06_16-09-47__Tageserzeugung_kWh__2023-01-06 4.0190
     2023-01-24 20:20:22   2023-01-07_15-43-26__Tageserzeugung_kWh__2023-01-07 3.9460
     2023-01-24 20:20:22   2023-01-08_16-13-42__Tageserzeugung_kWh__2023-01-08 1.5690
     2023-01-24 20:20:22   2023-01-09_16-53-22__Tageserzeugung_kWh__2023-01-09 5.4100
     2023-01-24 20:20:22   2023-01-10_16-28-00__Tageserzeugung_kWh__2023-01-10 2.4710
     2023-01-24 20:20:22   2023-01-11_15-45-08__Tageserzeugung_kWh__2023-01-11 1.1600
     2023-01-24 20:20:22   2023-01-12_15-43-45__Tageserzeugung_kWh__2023-01-12 1.5890
     2023-01-24 20:20:22   2023-01-13_16-21-24__Tageserzeugung_kWh__2023-01-13 11.4810
     2023-01-24 20:20:22   2023-01-14_15-57-56__Tageserzeugung_kWh__2023-01-14 6.0470
     2023-01-24 20:20:22   2023-01-15_16-29-23__Tageserzeugung_kWh__2023-01-15 4.2050
     2023-01-24 20:20:22   2023-01-16_16-01-51__Tageserzeugung_kWh__2023-01-16 12.9730
     2023-01-24 20:20:22   2023-01-17_16-26-21__Tageserzeugung_kWh__2023-01-17 6.5970
     2023-01-24 20:20:22   2023-01-18_16-16-11__Tageserzeugung_kWh__2023-01-18 1.5610
     2023-01-24 20:20:22   2023-01-19_15-46-29__Tageserzeugung_kWh__2023-01-19 17.2280
     2023-01-24 20:20:22   2023-01-20_16-33-34__Tageserzeugung_kWh__2023-01-20 12.9760
     2023-01-24 20:20:22   2023-01-21_16-07-10__Tageserzeugung_kWh__2023-01-21 2.1700
     2023-01-24 20:20:22   2023-01-22_16-52-37__Tageserzeugung_kWh__2023-01-22 0.7180
     2023-01-24 20:20:22   2023-01-23_16-12-44__Tageserzeugung_kWh__2023-01-23 1.1810
     2023-01-24 20:20:22   2023-01-24_16-00-02__Tageserzeugung_kWh__2023-01-24 0.9950
     2023-01-24 20:20:22   background_processing_time 0.2217
     2023-01-24 20:20:22   sql_processing_time 0.1152
     2023-01-24 20:20:22   state           done


Es wird nur ein Teil des Namens ersetzt damit der zeitliche Kontext erhalten bleibt und sich die Readings nicht "überschreiben", d.h. wenn der Namen komplett gleich wäre, würde im obigen Beispiel nur ein einziges Reading im Frontend sichtbar sein.
Die Beschreibung werde ich mal etwas ausbauen damit es griffiger wird.

Zitat
Kann ich den readingName komplett selbstbestimmen?
Über readingNameMap wegen den oben dargestellten Zusammenhängen nicht, aber über das Attr userExitFn  kannst du dir die entstandenen Readings nach Belieben auswerten, neue Readings erstellen und im Prinzip auch auch die vom Device automatisch erstellten Readings löschen.

Hier ein Beispiel.


{
  if ($READING =~ /1_Brenner_Energy_Summe__DIFF/ && $VALUE ne '-') {
    my $date = (split '__', $READING)[0];
    my $cdd  = "VaillantControlDummy";                             # Steuerungsdummy Device
    my $mpk  = AttrVal($cdd, 'Multiplikator',    '0');
    my $zz   = AttrVal($cdd, 'Zustandszahl',     '0');
    my $bw   = AttrVal($cdd, 'Brennwert_kWh/m3', '0');
    my $tarf = AttrVal($cdd, 'Tarif', '0');                        # Kosten €/kWh           
    my $m3   = sprintf "%.3f", $VALUE/10000 * $mpk;                # verbrauchte m3
    my $kwh  = sprintf "%.3f", $m3 * $zz * $bw;                    # Umrechnung m3 -> kWh
    my $cost = sprintf "%.2f", $kwh * $tarf;
   
    my $hash = $defs{$NAME};
   
    readingsBulkUpdate ($hash, 'gas_consumption_m3',   $m3);
    readingsBulkUpdate ($hash, 'gas_consumption_kwh', $kwh);
    readingsBulkUpdate ($hash, 'gas_costs_euro',     $cost);
  }   
}



ZitatOder welche eine einfache Möglichkeit gibt es, den Wert direkt (ohne Umweg über ein reading) einer Variablen zuzuweisen?
Irgendwie vermisse ich dafür ein "set ... maxValue raw"  :)

Die ganzen "set" führen die Funktionen non-blocking, also asynchron aus. Deswegen klappt die direkte Zuweisung in eine Var nicht weil die FHEM-Schleife ja nicht wartet ... ;).

Momentan gibt es das blockierende "get ... sqlCmdBlocking" um das Ergebnis eines SQL's einer Variablen oder Array (man kann mehrzeilige Ergebnisse verarbeiten) zuzuweisen.

Es gibt auch noch ein bereitgestelltes FHEM Kommando bzw. eine Perl Funktion .... (Auszug aus Kommandref):


Sobald ein DbRep-Device definiert ist, wird sowohl die Perl Funktion DbReadingsVal als auch das FHEM Kommando dbReadingsVal zur Verfügung gestellt. Mit dieser Funktion läßt sich, ähnlich dem allgemeinen ReadingsVal, der Wert eines Readings aus der Datenbank abrufen.
Die Funktionsausführung erfolgt blockierend mit einem Standardtimeout von 10 Sekunden um eine dauerhafte Blockierung von FHEM zu verhindern. Der Timeout ist mit dem Attribut timeout anpassbar.

    Die Befehlssyntax für die Perl Funktion ist:

    DbReadingsVal("<name>","<device:reading>","<timestamp>","<default>")

    Beispiel:

      $ret = DbReadingsVal("Rep.LogDB1","MyWetter:temperature","2018-01-13_08:00:00","");
      attr <name> userReadings oldtemp {DbReadingsVal("Rep.LogDB1","MyWetter:temperature","2018-04-13_08:00:00","")}
      attr <name> userReadings todayPowerIn
        {
           my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime(gettimeofday());
           $month++;
           $year+=1900;
           my $today = sprintf('%04d-%02d-%02d', $year,$month,$mday);
           DbReadingsVal("Rep.LogDB1","SMA_Energymeter:Bezug_Wirkleistung_Zaehler",$today."_00:00:00",0)
        }
     

    Die Befehlssyntax als FHEM Kommando ist:

    dbReadingsVal <name> <device:reading> <timestamp> <default>

    Beispiel:
    dbReadingsVal Rep.LogDB1 MyWetter:temperature 2018-01-13_08:00:00 0

    <name> : Name des abzufragenden DbRep-Device
    <device:reading> : Device:Reading dessen Wert geliefert werden soll
    <timestamp> : Zeitpunkt des zu liefernden Readingwertes (*) im Format "YYYY-MM-DD_hh:mm:ss"
    <default> : Defaultwert falls kein Readingwert ermittelt werden konnte


(*) Es wird der zeitlich zu <timestamp> passendste Readingwert zurück geliefert, falls kein Wert exakt zu dem angegebenen Zeitpunkt geloggt wurde.


Die get-Kommandos habe ich dem Abruf von internen Datenbankinformationen zugeordnet bzw. stelle dem User bei Bedarf blockierende Funktionen im Get bereit.
Also wenn es Bedarf an einem "get ... maxValue" welches blockierend arbeitet um die Ausgabe direkt einer Variable zuordnen zu können, kann ich die Getter gerne erweitern.  :)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 24 Januar 2023, 21:09:52
Zitat von: DS_Starter am 24 Januar 2023, 20:56:56
Die Beschreibung werde ich mal etwas ausbauen damit es griffiger wird.
Über readingNameMap wegen den oben dargestellten Zusammenhängen nicht,

Schade, meine Hoffnung war, dass ich dort einfach eine regex angeben könnte und damit die komplette Kontrolle über den Namen habe. Auch damit könnte ich den zeitlichen Kontext beibehalten...

Alles andere, was Du beschrieben hast, ist nett, aber totaler Overkill für das, was ich eigentlich haben möchten: den Maximalwert eines bestimmten readings in eine Variable schreiben. Es ist eigentlich alles dafür da - nur ein einfacher Rückgabeweg für das Ergebnis existiert nicht.

Alternative Idee:

In DbLog.pm gibt es ja "get ... ReadingsVal ...".
Ein Blick in den Code zeigt mir, dass man da vermutlich ohne großen Aufwand auch "get ... ReadingsMaxVal ..." einbauen könnte  8)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 Januar 2023, 21:27:57
Zitat
Schade, meine Hoffnung war, dass ich dort einfach eine regex angeben könnte und damit die komplette Kontrolle über den Namen habe. Auch damit könnte ich den zeitlichen Kontext beibehalten...
Du kannst das, das weiß ich.  :)
Bisher hatte ich es vermieden dem User die volle Kontrolle darüber zu geben.
Aber inzwischen ist schon viel Know How im Umgang mit dem Modul vorhanden, dass ich es mir vllt. keinen Stress macht die Möglichkeiten zu erweitern, mal schauen.

Zitat
In DbLog.pm gibt es ja "get ... ReadingsVal ...".
Ein Blick in den Code zeigt mir, dass man da vermutlich ohne großen Aufwand auch "get ... ReadingsMaxVal ..." einbauen könnte  8)
Ja, kommt auf die Liste.  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Januar 2023, 21:55:33
Zitat
In DbLog.pm gibt es ja "get ... ReadingsVal ...".
Ein Blick in den Code zeigt mir, dass man da vermutlich ohne großen Aufwand auch "get ... ReadingsMaxVal ..." einbauen könnte  8)

Schau mal hier: https://forum.fhem.de/index.php/topic,130588.msg1260124.html#msg1260124
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 01 Februar 2023, 19:39:19
Hallo Heiko,

mir ist (leider) erst jetzt aufgefallen das ich immer wieder Fehlermeldungen im Log vom DbRep erhalte.
Leider hab ich längere Zeit dort nicht genau genug nachgesehen.....


2023.02.01 17:55:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 17:55:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:00:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:00:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:05:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:05:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:10:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:10:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:15:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:15:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:20:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:20:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:25:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:25:37 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:30:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:30:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:35:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:35:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:40:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:40:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:45:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:45:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:50:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:50:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:55:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 18:55:37 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:00:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:00:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:05:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:05:37 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:10:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:10:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:15:19 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.
2023.02.01 19:15:38 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/93_DbRep.pm line 4525.



Ich habe / nutze die FVERSION : 93_DbRep.pm:v8.51.3-s27102/2023-01-22

Ist da schon irgendwo etwas bekannt?
Da es immer im 2fach im 5 Minuten Abstand müsste ich ansonsten mal tiefer (woanders) in den schon 4 Jahre laufenden Energy-Routinabfragen suchen wenns unbekannt ist. Dort hab ich sicher solche Routinen im 5 Minuten-Abstand laufen.

Gruß
300P
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Februar 2023, 19:57:44
Du hast einen oder mehrere Datensätze deren Wert leer ("") ist. Dadurch wird bei der Substraktion in diifValue dieser Fehler provoziert.
Ich könnte die Routine erweitern und nichtnumerische Werte überspringen.
Bin mir aber unsicher ob es nicht besser wäre in dem Fall Logausgaben mit dem betreffenden Datensatz zu erstellen damit der User diesen löschen kann und hat dadurch gleich eine Datenpflege seiner DB vorgenommen.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Februar 2023, 20:45:06
@300P, ich habe dir eine Version in mein contrib geladen.
Sie bringt bei diffValue in deinem Fall eine solche Meldung:


2023.02.01 20:27:52.599 2: DbRep Rep.CPU - WARNING - dataset has no numeric value >bla< and is ignored, >2023-01-05 23:02:17<, device >SMA_Energymeter<, reading >Einspeisung_Wirkleistung<.
2023.02.01 20:27:52.599 2: DbRep Rep.CPU - WARNING - dataset has no numeric value >bla< and is ignored, >2023-01-05 23:03:17<, device >SMA_Energymeter<, reading >Einspeisung_Wirkleistung<.


Probiers mal aus.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 01 Februar 2023, 21:28:20
Ich glaube es kam aus dem Modul SMAInverter (seit Jahren) bis Ende letzten Jahres:
Immer wenn es dort bei "etotal" einen 0 Wert gab ("abnullen"), gab es auf jeden Fall bei dem Eintrag eines Wertes am Morgen von 0 in VALUE ein "".

Probiere auch gleich mal die Test-Version, vielleicht kommen ja noch mehr als die von mir bereits gelöschten "leeren" Werte in anderen Modulen bei 0.

Gruß
300P
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Februar 2023, 21:32:11
Ich habe das Log auf verbose 3 gesetzt, ist ja nur eine Warnung.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 01 Februar 2023, 21:59:08
Danke:
Die Routine findet schon mal mehr als ich auf den ersten Blick per SQLDatenbankzugriff gefunden und gelöscht habe habe.
Ich habe mir das Log im Code mal auf 2 gesetzt, sonst muss ich sicherlich in alle diversen DiffValue-Aufrufe rein  ;)
Als Hilfe ist das sicherlich richtig so, ich beobachte mal was alles kommt.



2023.02.01 21:45:51 1: Including ./log/fhem.save
2023.02.01 21:45:53 2: netatmo: missing app refresh token!
2023.02.01 21:45:54 0: Featurelevel: 6.2
2023.02.01 21:45:54 0: Server started with 255 defined entities (fhem.pl:27110/2023-01-23 perl:5.032001 os:linux user:fhem pid:546702)
2023.02.01 21:45:56 2: AttrTemplates: got 258 entries
2023.02.01 21:48:11 2: DbRep Rep.SMAEM.Einspeisung.Gesamt - WARNING - dataset has no numeric value >< and is ignored
timestamp >2018-09-04 11:53:07<, device >SMA_Energymeter<, reading >Einspeisung_Wirkleistung_Zaehler<
2023.02.01 21:48:34 2: DbRep Rep.SMAEM.Bezug.Gesamt - WARNING - dataset has no numeric value >< and is ignored
timestamp >2018-09-04 11:53:07<, device >SMA_Energymeter<, reading >Bezug_Wirkleistung_Zaehler<
2023.02.01 21:49:09 2: DbRep Rep.SBS25_2.Entladung.Gesamt - WARNING - dataset has no numeric value >< and is ignored
timestamp >2021-04-17 20:08:56<, device >SBS25_2<, reading >bat_loadtotal<
2023.02.01 21:50:57 2: VCONTROL300: Error while sending command for parameter 5527 (Status 0x15) : Retry 0!!!
2023.02.01 21:50:57 2: VCONTROL300: Error while sending command for parameter 5527 (Status 0x15) : Retry 1!!!
2023.02.01 21:50:58 2: DbRep Rep.SMAEM.Einspeisung.Gesamt - WARNING - dataset has no numeric value >< and is ignored
timestamp >2018-09-04 11:53:07<, device >SMA_Energymeter<, reading >Einspeisung_Wirkleistung_Zaehler<
2023.02.01 21:51:20 2: DbRep Rep.SMAEM.Bezug.Gesamt - WARNING - dataset has no numeric value >< and is ignored
timestamp >2018-09-04 11:53:07<, device >SMA_Energymeter<, reading >Bezug_Wirkleistung_Zaehler<
2023.02.01 21:51:56 2: DbRep Rep.SBS25_2.Entladung.Gesamt - WARNING - dataset has no numeric value >< and is ignored
timestamp >2021-04-17 20:08:56<, device >SBS25_2<, reading >bat_loadtotal<



Gruß
300P
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 Februar 2023, 22:07:36
Ich packe die V ins Repo. Passt so.
Wie gesagt, wird produktiv dann als verbose 3 gemeldet, sonst nervt es zu sehr wenn man nicht gleich dazu kommt die DB zu pflegen.  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 01 Februar 2023, 22:19:07
merci
:)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 02 Februar 2023, 19:57:06
Hab inzwischen meine SQL bereinigt.
??? :o da haben sich in 5 Jahren fast 15.000 Datensätze mit EMPTY-VALUE-Werten aus verschiedensten Modulen angesammelt die jetzt durch eine Bereinigungsaktion bei mir weg sind....

DELETE FROM `fhem`.`history`
WHERE `VALUE` = ''
AND `EVENT` LIKE '%: 0';

Werde mir eine monatliche Routine schreiben damit es nicht wieder so viele bei mir werden.

Gruß
300P


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Februar 2023, 20:13:22
Könnte sein:


define At.Del.Rep at +*XX:XX:XX set <DbRep> sqlCmd DELETE FROM `fhem`.`history` WHERE `VALUE` = '' AND `EVENT` LIKE '%: 0';


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 04 Februar 2023, 07:31:00
Hallo Heiko,

ich habe täglich folgende Warnung in meinem Log:

Warnung
2023.02.04 01:17:00.042 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3397.

Log komplett mit Warnung
2023.02.04 00:05:00.006 3: DbRep Rep.SQLite.Backup - ################################################################
2023.02.04 00:05:00.010 3: DbRep Rep.SQLite.Backup - ###                    New SQLite dump                       ###
2023.02.04 00:05:00.010 3: DbRep Rep.SQLite.Backup - ################################################################
2023.02.04 00:05:00.010 3: DbRep Rep.SQLite.Backup - execute command before dump: 'set logdb reopen 3600'
2023.02.04 00:05:00.015 2: DbLog logdb - Connection closed until 01:05:00 (3600 seconds).
2023.02.04 00:05:00.065 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem.db before optimize (MB): 11901.48 MB
2023.02.04 00:05:00.065 3: DbRep Rep.SQLite.Backup - VACUUM database /opt/fhem.db....
2023.02.04 00:05:00.182 3: DbLog logdb - Database disconnected by request.
2023.02.04 00:17:23.601 3: DbRep Rep.SQLite.Backup - Size of database /opt/fhem.db after optimize (MB): 11900.46 MB
2023.02.04 00:17:23.601 3: DbRep Rep.SQLite.Backup - Starting dump of database 'fhem.db'
2023.02.04 00:19:20.513 3: DbRep Rep.SQLite.Backup - Size of backupfile: 11900.46 MB
2023.02.04 00:19:20.515 3: DbRep Rep.SQLite.Backup - Deleting old dumpfile 'fhem_2023_02_01_00_17.sqlitebkp'
2023.02.04 00:19:20.536 3: DbRep Rep.SQLite.Backup - Finished backup of database fhem - total time used (hh:mm:ss): 00:14:20
2023.02.04 00:19:20.549 3: DbLog logdb - Reopen requested
2023.02.04 00:19:20.565 2: DbRep Rep.SQLite.Backup - command message after dump: "Reopen executed."
2023.02.04 00:19:20.569 3: DbRep Rep.SQLite.Backup - Database dump finished successfully.
2023.02.04 00:19:20.707 3: DbLog logdb - Database disconnected by request.
2023.02.04 00:19:43.749 3: DbLog logdb - SubProcess connected to /opt/fhem.db
2023.02.04 01:15:00.148 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 3
2023.02.04 01:15:00.151 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 1
2023.02.04 01:16:00.129 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 3
2023.02.04 01:16:00.129 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 1
2023.02.04 01:17:00.042 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3397.
2023.02.04 01:17:00.065 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 6
2023.02.04 01:17:00.065 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 0


DbLog Device
COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:.*
   FD         7
   FUUID      5eb961f7-f33f-cd72-b3f6-f6ca8383a8350f4c
   FVERSION   93_DbLog.pm:v5.8.0-s27165/2023-02-01
   MODE       asynchronous
   MODEL      SQLITE
   NAME       logdb
   NR         2
   NTFY_ORDER 50-logdb
   PID        30366
   REGEXP     .*:.*
   SBP_PID    30368
   SBP_STATE  running
   STATE      connected
   TYPE       DbLog
   dbconn     SQLite:dbname=/opt/fhem.db
   dbuser     
   eventCount 1802
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    5.8.0
   OLDREADINGS:
   READINGS:
     2023-02-04 07:18:55   CacheOverflowLastNum 0
     2023-02-04 00:19:50   CacheOverflowLastState normal
     2023-02-04 07:18:56   CacheUsage      7
     2023-02-04 07:18:55   NextSync        2023-02-04 07:19:25 or when CacheUsage 500 is reached
     2023-02-04 07:18:55   state           connected
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Exclude/Include
   DbLogType  Current/History
   asyncMode  1
   insertMode 1
   valueFn    {
   if ($DEVICE eq "SMA_Wechselrichter") {
     if( ($READING eq "etoday" || $READING eq "etotal") && $VALUE > 4000000 ) {
       Log3 ($DEVICE, 1, "Reading: $READING with Value: $VALUE was ignored and not logged. ");
       $IGNORE = 1;
     }
   }
}
   verbose    3


DbRep Device nach dem die Warung kommt
  DATABASE   /opt/fhem.db
   DEF        logdb
   FUUID      5ec9522c-f33f-cd72-2c67-4a017ef05f4c2b3f
   FVERSION   93_DbRep.pm:v8.51.4-s27164/2023-02-01
   LASTCMD    averageValue writeToDB
   MODEL      Client
   NAME       Rep.total_pac
   NOTIFYDEV  global,Rep.total_pac
   NR         416
   NTFY_ORDER 50-Rep.total_pac
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   eventCount 14
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  2
     MINTS      2020-04-13 21:54:39
     PACKAGE    main
     VERSION    8.51.4
     CV:
       aggregation day
       aggsec     86400
       destr      2023-02-04
       dsstr      2023-02-01
       epoch_seconds_end 1675469820
       mestr      02
       msstr      02
       testr      01:17:00
       tsstr      00:00:00
       wdadd      432000
       yestr      2023
       ysstr      2023
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2023-02-04 01:17:00   2023-02-01__SMA_Wechselrichter__total_pac__AVGAM__2023-02-01 0.5815
     2023-02-04 01:17:00   2023-02-02__SMA_Wechselrichter__total_pac__AVGAM__2023-02-02 0.3833
     2023-02-04 01:17:00   2023-02-03__SMA_Wechselrichter__total_pac__AVGAM__2023-02-03 0.5685
     2023-02-04 01:17:00   2023-02-04__SMA_Wechselrichter__total_pac__AVGAM__2023-02-04 -
     2023-02-04 01:17:00   background_processing_time 0.0421
     2023-02-04 01:17:00   db_lines_processed 6
     2023-02-04 01:17:00   sql_processing_time 0.0222
     2023-02-04 01:17:00   state           done
Attributes:
   DbLogExclude .*
   aggregation day
   allowDeletion 1
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     SMA_Wechselrichter
   event-on-update-reading state
   reading    total_pac
   room       Photovoltaik
   showproctime 1
   timestamp_begin current_month_begin
   verbose    3


Kannst du mir hier weiter helfen?

Danke und ein schönes Wochenende.
VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Februar 2023, 09:01:12
Morgen Dieter,

es fehlt ein Wert im Write Back. Unklar ist momentan welcher genau.
Deswegen habe ich dir eine Testversion in mein contrib gestellt.
Damit kommen mit verbose 3 solche Meldungen im Log:


2023.02.04 08:53:50.438 3: DbRep Rep.CPU - Write Back String: 2023-01-05#163.18804664723#2023-01-05_11:12:08#2023-01-05_23:21:16|
2023.02.04 08:53:50.456 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 2
2023.02.04 08:53:50.456 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 0


Im "Write Back String" sollte dann der fehlende Wert erkennbar sein.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 04 Februar 2023, 09:35:54
Danke für die schnelle Unterstützung.

Hier das Ergebnis, mit dem ich allerdings nicht viel anfangen kann  ???
2023.02.04 09:32:59.903 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 3
2023.02.04 09:32:59.903 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 1
2023.02.04 09:33:18.864 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 4
2023.02.04 09:33:18.864 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 0
2023.02.04 09:33:27.700 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3400.
2023.02.04 09:33:27.700 3: DbRep Rep.total_pac - Write Back String: 2023-02-01#0.581517816527674#2023-02-01_00:00:00#2023-02-02_|
2023.02.04 09:33:27.700 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3402.
2023.02.04 09:33:27.703 3: DbRep Rep.total_pac - Write Back String: 2023-02-02#0.383271541686074#2023-02-02_#2023-02-03_|
2023.02.04 09:33:27.707 3: DbRep Rep.total_pac - Write Back String: 2023-02-03#0.568531518624643#2023-02-03_#2023-02-04_|
2023.02.04 09:33:27.707 3: DbRep Rep.total_pac - Write Back String: 2023-02-04#0.399760162601626#2023-02-04_#2023-02-04_09:33:27|
2023.02.04 09:33:27.721 3: DbRep Rep.total_pac - number of lines updated in >logdb<: 8
2023.02.04 09:33:27.721 3: DbRep Rep.total_pac - number of lines inserted into >logdb<: 0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 Februar 2023, 09:47:08
Danke Dieter. Ich sehe es.
Es fehlt teilweise ein Stringteil 2023-02-03_....

Konnte es bei mir jetzt nachstellen und melde mich wieder mit einer Lösung.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 Februar 2023, 20:49:15
Hallo Dieter, @all,

ich habe das von dir gemeldete Problem gelöst, getestet und eingecheckt.
Neue V ist morgen früh im Update enthalten.

LG,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 06 Februar 2023, 08:07:07
Guten Morgen Heiko,

Meldung taucht nicht mehr auf.

Wie immer, toller support.
Vielen Dank und eine schöne Woche.

VG Dieter
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: h0nIg am 07 Februar 2023, 12:30:22
Hallo zusammen,

ich aggregiere aktuell mit diffValue und erhalte komischerweise falsche StartDaten für die Wochenaggregation.

2022-05-01_00:00:15 0.0000
2022-05-07_20:03:36 30.3000
2022-05-14_20:04:30 21.4120
2022-05-21_20:04:25 21.1900
2022-05-28_20:03:20 19.0250


Wobei ich für andere readings des gleichen phyischen Devices die richtige Wochen-Startzeit kriege:

2022-04-18_23:59:58 0.0000
2022-05-01_23:57:14 9.1330
2022-05-08_23:57:35 21.5490
2022-05-15_23:59:29 10.8130
2022-05-22_23:57:24 7.3580
2022-05-29_23:58:19 11.6910


Woran wird es den festgemacht, welche Startzeit genommen wird? Für beide Readings beginnen die Daten zur gleichen Zeit?

Die Konfiguration sieht gleich aus:

define logdb.weekly.Strom.WP.HT DbRep logdb
attr logdb.weekly.Strom.WP.HT aggregation week
attr logdb.weekly.Strom.WP.HT device MQTT2_Z_WP
attr logdb.weekly.Strom.WP.HT reading MT681_Total_in_HT
attr logdb.weekly.Strom.WP.HT showproctime 1
attr logdb.weekly.Strom.WP.HT timestamp_begin previous_year_begin
attr logdb.weekly.Strom.WP.HT timestamp_end previous_week_end
attr logdb.weekly.Strom.WP.HT readingNameMap agg_HT

define logdb.weekly.Strom.WP.NT DbRep logdb
attr logdb.weekly.Strom.WP.NT aggregation week
attr logdb.weekly.Strom.WP.NT device MQTT2_Z_WP
attr logdb.weekly.Strom.WP.NT reading MT681_Total_in_NT
attr logdb.weekly.Strom.WP.NT showproctime 1
attr logdb.weekly.Strom.WP.NT timestamp_begin previous_year_begin
attr logdb.weekly.Strom.WP.NT timestamp_end previous_week_end
attr logdb.weekly.Strom.WP.NT readingNameMap agg_NT


Grüße
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: sinemeter am 07 Februar 2023, 14:15:59
Hallo zusammen,

ich habe mal eine Frage zur Dauer des DbRep Dumps:

Raspberry Pi4 mit 4 GB RAM:
sandisc extreme pro SD Karte: 64 GB 
DB Größe: ca. 2,4 GB (Log läuft seit 2018)
Größe der SQL Datei nach dem Dump ca. 1,3 GB
Fhem und MariaDB laufen in separaten Docker Containern

Der Dump läuft beri mir gute 4 Stunden was mir trotz der Größe ziemlich langsam vorkommt.
Attribut Dumpspeed habe ich noch nicht verändert.

Ist der Wert realistisch oder meint ihr das da mehr rauszuholen wäre? Die SD Karte ist ansonsten beim kopieren von Dateien ja recht flott.
Hier mein Top des Hosts während der Dump läuft:


top - 13:54:51 up 11 days, 23:30,  3 users,  load average: 1,17, 1,30, 1,46
Tasks: 307 total,   2 running, 303 sleeping,   0 stopped,   2 zombie
%CPU0  : 11,0 us,  7,6 sy,  0,0 ni, 54,5 id, 26,6 wa,  0,0 hi,  0,3 si,  0,0 st
%CPU1  :  7,6 us,  1,3 sy,  0,0 ni, 89,0 id,  2,0 wa,  0,0 hi,  0,0 si,  0,0 st
%CPU2  :  7,7 us,  5,4 sy,  0,0 ni, 65,7 id, 21,2 wa,  0,0 hi,  0,0 si,  0,0 st
%CPU3  :  5,3 us,  5,6 sy,  0,0 ni, 72,5 id, 16,6 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   3794,4 total,    625,8 free,   2005,9 used,   1162,6 buff/cache
MiB Swap:    100,0 total,     45,2 free,     54,8 used.   1623,4 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
   2099 999       20   0 2350468 409700   7464 S  27,5  10,5 332:20.75 mariadbd
2563985 6061      20   0  293792 214308  14536 R   5,6   5,5  96:11.22 perl
4001830 root       0 -20       0      0      0 I   4,3   0,0   0:38.01 kworker/0:2+
   2275 pi        20   0 1595912  56132  18032 S   3,6   1,4 572:36.74 deCONZ
4021557 pi        20   0   10572   3628   2856 R   1,3   0,1   0:00.19 top
2559176 root      20   0   14532   4108   3072 S   1,0   0,1  12:42.80 entry.sh
3987435 root       0 -20       0      0      0 I   1,0   0,0   0:18.37 kworker/2:1+
3988948 root       0 -20       0      0      0 I   1,0   0,0   0:15.40 kworker/3:1+
     14 root      20   0       0      0      0 S   0,7   0,0   6:53.52 ksoftirqd/0
   1997 root      20   0  711676   3964   1752 S   0,7   0,1   1:38.66 containerd-+
     15 root      20   0       0      0      0 I   0,3   0,0  18:08.49 rcu_preempt
   1662 root      20   0 1443640   3452   1752 S   0,3   0,1   5:39.14 docker-proxy
   1834 root      20   0  712188   4632   2276 S   0,3   0,1   1:54.80 containerd-+
   5493 _rpc      20   0    7380   1276    516 S   0,3   0,0  26:39.94 avahi-daemon



Ich frage mich ob ich hier noch mehr Geschwindigkeit rauszuholen ist, oder erwarte ich zuviel?

Hier meine Devices:

defmod DBLogging DbLog /opt/fhem/db.conf .*:.*
attr DBLogging DbLogSelectionMode Include
attr DBLogging alias Datenbank Logging
attr DBLogging asyncMode 1
attr DBLogging group Logging
attr DBLogging icon audio_playlist
attr DBLogging insertMode 1
attr DBLogging room Log



defmod DBLogging_DbRep DbRep DBLogging
attr DBLogging_DbRep DbLogExclude .*
attr DBLogging_DbRep DbLogInclude state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time
attr DBLogging_DbRep alias Datenbank Logging DbRep
attr DBLogging_DbRep comment x\
{backupSqlFiles("DBLogging_DbRep")}\

attr DBLogging_DbRep dumpFilesKeep 1
attr DBLogging_DbRep event-on-change-reading state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time,DumpFileCreated
attr DBLogging_DbRep executeAfterProc set Pibot _msg Dunp beendet
attr DBLogging_DbRep executeBeforeProc set Pibot _msg SQL Dump beginnt
attr DBLogging_DbRep group Logging
attr DBLogging_DbRep icon file_pod
attr DBLogging_DbRep optimizeTablesBeforeDump 1
attr DBLogging_DbRep room Log


P.S.: Das Kommando {backupSqlFiles("DBLogging_DbRep")} nach M. Kleines Anleitung zur Kopie aufs Nas ist hier nur als Kommentar hinterlegt da ich damit noch experimentiere.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2023, 15:01:51
@sinemeter,

ich denke du könntest die Geschwindigkeit erhöhen wenn du die Attr wie folgt setzt:


dumpMemlimit 1000000
dumpSpeed     100000


Du kannst sicherlich weiter erhöhen sofern der RAM ausreicht und dein Server nicht in den Swap läuft.
Das musst du ein bisschen beobachten.
Wichtig ist auch auch dass die Datenbank indiziert ist (DbLog configCheck ausführen).

Zum Vergleich ... bei mir läuft der dumpMySQL clientSide einer 3,5 GB MariaDB rund 1500 Sekunden, also knapp 0,5 h.
Allerdings als VM auf einem NUC.

Deutlich schneller ist dumpMySQL serverSide der gleichen Datenbank. Er braucht nur 80 Sekunden.

Die beiden Verfahren haben als Ergebnis aber unterschiedliche Daten (SQL vs. CSV) und arbeiten verschieden.
Das ist aber in der Commandref beschrieben denke ich. 
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Februar 2023, 16:54:41
@h0nIg,

die Startzeit für die Datenselektion erfolgt immer (in deinem Setup!) durch die Festlegung im Attr timestamp_begin.
Das sieht man deutlich im Log mit verbose 4.

Die Ergebnisreadings sind davon abhängig, wann im Zeitraum bzw. der Aggregation der erste auswertbare Wert in der DB gefunden wird.

Vergleiche die Commandref:

Zitat
....
Wird in einer auszuwertenden Zeit- bzw. Aggregationsperiode nur ein Datensatz gefunden, kann die Differenz in Verbindung mit dem Differenzübertrag der Vorperiode berechnet werden. in diesem Fall kann es zu einer logischen Ungenauigkeit in der Zuordnung der Differenz zu der Aggregationsperiode kommen. Deswegen wird eine Warnung im "state" und das Reading "less_data_in_period" mit einer Liste der betroffenen Perioden wird erzeugt.

    Hinweis:
    Im Auswertungs- bzw. Aggregationszeitraum (Tag, Woche, Monat, etc.) sollten dem Modul pro Periode mindestens ein Datensatz zu Beginn und ein Datensatz gegen Ende des Aggregationszeitraumes zur Verfügung stehen um eine möglichst genaue Auswertung der Differenzwerte vornehmen zu können.

Nähere Informationen zum Ablauf sieht man ebenfalls mir verbose 4 im Log.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: sinemeter am 08 Februar 2023, 11:04:56
Zitat von: DS_Starter am 07 Februar 2023, 15:01:51
@sinemeter,

ich denke du könntest die Geschwindigkeit erhöhen wenn du die Attr wie folgt setzt:


dumpMemlimit 1000000
dumpSpeed     100000



Vielen Dank!! Hat gewirkt. Zeit jetzt <45 Min.

Leider noch eine Frage:

Das

attr DBLogging_DbRep executeAfterProc {backupSqlFiles("DBLogging_DbRep")}


führt er garnicht aus.

Dagegen das fhem Kommando zum Telegram Note was ich vorher drin hatte führt er aber normal aus.
Device:

defmod DBLogging_DbRep DbRep DBLogging
attr DBLogging_DbRep DbLogExclude .*
attr DBLogging_DbRep DbLogInclude state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time
attr DBLogging_DbRep alias Datenbank Logging DbRep
attr DBLogging_DbRep dumpFilesKeep 1
attr DBLogging_DbRep dumpMemlimit 1000000
attr DBLogging_DbRep dumpSpeed 100000
attr DBLogging_DbRep event-on-change-reading state,DumpFileCreatedSize,DumpRowsHistory,background_processing_time,DumpFileCreated
attr DBLogging_DbRep executeAfterProc {backupSqlFiles("DBLogging_DbRep")}
attr DBLogging_DbRep executeBeforeProc set Pibot _msg SQL Dump beginnt
attr DBLogging_DbRep group Logging
attr DBLogging_DbRep icon file_pod
attr DBLogging_DbRep optimizeTablesBeforeDump 1
attr DBLogging_DbRep room Log

setstate DBLogging_DbRep Database backup finished
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpFileCreated ./log/fhem_2023_02_08_09_40.sql
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpFileCreatedSize 1376.80 MB
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpFilesDeleted fhem_2023_02_08_01_00.sql
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpRowsCurrent 0
setstate DBLogging_DbRep 2023-02-08 10:26:41 DumpRowsHistory 6415032
setstate DBLogging_DbRep 2023-02-08 10:26:41 background_processing_time 2786.7522
setstate DBLogging_DbRep 2023-02-08 10:26:41 state Database backup finished


Führe ich
{backupSqlFiles("DBLogging_DbRep")}
über die Befehlszeile aus läuft das Kommando durch und returned 1.
In 99_myUtils.pm habe ich sonst nix drin:


##############################################
# $Id: myUtilsTemplate.pm 21509 2020-03-25 11:20:51Z 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.
sub backupSqlFiles($) {
my ($devspec) = @_;

my $file = ReadingsVal($devspec, "DumpFileCreated", "");
if ($file ne "") {
system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

return 1;
}

return 0;
}




1;


Hat jemand eine Idee?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2023, 11:41:01
Schalte dir mal verbose 4 im Device ein.
Im Log siehst du dann was ausgeführt werden soll(te):

2023.02.08 11:39:31.074 4: DbRep Rep.CPU - execute command after averageValue: '{afterdump ('Rep.CPU')}'
2023.02.08 11:39:31.074 3: DbRep Rep.CPU -> Dump beendet

In meiner 99_myUtils.pm steht zum Test:


######################################################
########    Nach Dump 
######################################################
sub afterdump {
my ($name) = @_;
my $hash = $defs{$name};

  Log3($name, 3, "DbRep $name -> Dump beendet");

return;
}
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: sinemeter am 08 Februar 2023, 14:05:06
Hi, hier das Log des Fhem Containers um 13:47 nach Finish.


2023.02.08 13:47:25.819 3: [echo] [echodevice_NPMLoginRefresh] alexa-cookie modul not found
2023.02.08 13:47:35.665 3: DbRep DBLogging_DbRep - 6425118 records inserted (size of backupfile: 1379.23 MB)
2023.02.08 13:47:35.667 3: DbRep DBLogging_DbRep - Deleting old dumpfile 'fhem_2023_02_08_09_40.sql'
2023.02.08 13:47:35.756 3: DbRep DBLogging_DbRep - Finished backup of database fhem - total time used (hh:mm:ss): 00:39:10
2023.02.08 13:47:35.759 4: DbRep DBLogging_DbRep - execute command after dump: '{backupSqlFiles("DBLogging_DbRep")}'
2023.02.08 13:47:35.772 3: DbRep DBLogging_DbRep - Database dump finished successfully.
2023.02.08 13:48:25.822 3: [echo] [echodevice_LoginStart] Alter COOKIE=2827040/6000 Refresh Cookie!
2023.02.08 13:48:25.822 3: [echo] [echodevice_NPMLoginRefresh] alexa-cookie modul not found


Ich kann damit aber leider nicht ersehen das was schief gelaufen ist.
Das Kommando wurde ausgeführt aber es wurde weder die Telegram Nachricht verschickt noch das File kopiert
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2023, 15:45:13
Jetzt ist mir der Grund klar geworden.
executeAfterProc  führt das Script aus wenn die Funktion erledigt ist, aber noch bevor die Readings angelegt werden.
Hinterlege dein Script in dem Attr userExitFn leicht abgewandelt in dieser Form:


############################################################################################################
########       Aktion nach einem Backup     
############################################################################################################
sub doafterdump {
my ($name,$reading,$value) = @_;
my $hash   = $defs{$name};
my $dbname = $hash->{DATABASE};

   return if($reading ne "state" || ($reading eq "state" && ReadingsVal($name,"state",'') =~ /Dump is running/));
   
   if ($reading  = "state" && ReadingsVal($name,"state",'') !~ m/Database.*backup.*(finished|timed.*)/) {

my $file = ReadingsVal($devspec, "DumpFileCreated", "");
if ($file ne "") {
system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

return 1;
}

return 0;
   }

return;
}


Ich werde prüfen ob ich executeAfterProc  nebenwirkungsfrei auch nach der Readingserstellung ausführen kann. Aber es gab sicherlich einen Grund es so zu machen wie es jetzt ist. Muß ich schauen ...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 08 Februar 2023, 18:01:14
Würde ich auch drauf reinfallen. Würde vermutlich jedem passieren der nicht so tief drinsteckt.

Das Problem ist als "Anwender" vermutlich auch schwierig zu erkennen - man (ich) geht davon aus, dass executeAfterProc gestartet wird wenn DBRep fertig ist.
Vielleicht könnte man es über diverse LOG temporär zum Debuggen in 99_myutil fangen.

So hatte ich mich ja auch mal über die mehrfache Ausführung der Kommandos in userExitFn gewundert - bis du mir erklärt hast, das es mehrfach getriggert werden kann.

...insofern fänd ich eine solche Änderung begrüßenswert

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Februar 2023, 22:40:38
Ja, verstehe ich Ralf.
Ich schaue es mir an. Betrifft im Prinzip alle "done" Routinen.
Aber ich muß in mich gehen, meistens gab es einen bestimmten Grund es so und nicht anders zu machen.
Manchmal habe ich aber auch nur den Tunnelblick.  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: sinemeter am 09 Februar 2023, 02:58:42
Hi zusammen,


Vielen lieben Dank schonmal für die tolle Unterstützung!

Wenn ich Deinen Code speichere bekomme ich
beim Save in MyUtils den Fehler:

ERROR:
Global symbol "$devspec" requires explicit package name (did you forget to declare "my $devspec"?) at ./FHEM/99_myUtils.pm line 44.

Zeile 44:
s. Screenshot.

Da ich Perl noch zu wenig verstehe:
Wie genau muss das Attrib in UserExitFn aussehen um Deine Funktion aufzurufen?
Muss ich Argumente übergeben?
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Februar 2023, 18:07:01
Hi,

naja, war von mir nur schnell "zusammengklöppelt".
Das geht auch einfacher:


sub doafterdump {
 my ($name, $reading, $value) = @_;
 my $hash   = $defs{$name};
   
   if ($reading  eq "DumpFileCreated")  {
my $file = $value;
if ($file ne "") {
system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

return 1;
}
   }
 
return 0;
}


Die Angabe im Attribut erfolgt mindestens mit dem Namen der Routine und optional mit einem Regex. Das ist in der Commandref genau beschrieben. Variablen übergibst du nicht, das passiert intern und ist auch in der Comref beschrieben.
Bei dir würde ich raten es so zu definieren:

attr userExitFn doafterdump DumpFileCreated:.*

Dadurch wird nur das Reading "DumpFileCreated" an die sub doafterdump übergeben. Theoretisch könnte man dadurch die äußere if-Bedingung noch weglassen, also die sub z.B. so definieren:


sub doafterdump {
  my $name    = shift;
  my $reading = shift;
  my $file       = shift;

  if ($file ne "") {
      system("scp $file fhem\@qnas.fritz.box:/share/homes/fhem/backups/ &");
      fhem("set Pibot _msg 'mySQL' 'Der Dump wurde erfolgreich erstellt ($file)'");

      return 1;
  }
 
return 0;
}


Es gibt also wie immer verschiedene Möglichkeiten.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 Februar 2023, 13:07:18
@all,

in meinem contrib liegt eine neue V 8.51.6.
Nun wird executeAfterProc erst nach der Readinggenerierung ausgeführt.
Der Umbau war nicht ganz trivial, da eventuelle Error-State, die sich aus einem Funktionsproblem heraus ergeben nicht durch Fehler im executeAfterProc überschrieben werden sollen. Das war auch der Grund für die bis dato eingebaute Funktionsweise.

Deswegen erstmal im contrib für Tests über das WE.

LG,
Heiko
Titel: 50mostFreqLogsLast2days - funktioniert nicht richtig !?!
Beitrag von: m.zielinski am 11 Februar 2023, 10:11:47
Nutzt hier jemand das SQLSpecial 50mostFreqLogsLast2days ?
Irgendwas stimmt da mit dem timestamp nicht - ich bekomme statt der letzten 2 tage die gesamtanzahl in meiner DB...

Auch wenn ich die DB runterlade und mit DB Browser die SQL ausführen bekomme ich viel zu hohe Trefferzahlen:  select Device, reading, count(0) AS `countA` from history where ( TIMESTAMP > ('now' - '2 days')) group by DEVICE, READING order by countA desc, DEVICE limit 50

Nur wenn ich die Timestamp-Berechnung manuell mache bekomme ich plausible werte:  select Device, reading, count(0) AS `countA` from history where ( TIMESTAMP > '2023-02-09 00:00:00') group by DEVICE, READING order by countA desc, DEVICE limit 150

ALternativ scheint auch zu funktionieren: datetime('now' ,'-2 days')

Mit diese Funktion gucke ich, ob manche Geräte viel zu geschwätzig sind...
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 Februar 2023, 11:35:37
Ich habe das SQL für MySQL angepasst und ins contrib geladen zum Test.
Ausgerollt wird es mit dem kommenden check in.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 12 Februar 2023, 20:40:31
Neue V ist eingecheckt und morgen früh im Update enthalten.

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: m.zielinski am 17 Februar 2023, 14:50:09
Zitat von: DS_Starter am 12 Februar 2023, 20:40:31
Neue V ist eingecheckt und morgen früh im Update enthalten.


Hi - falls sich deine Antwort auf mein Problem mit dem 50mostFreqLogsLast2days-sql bezog - ich nutze SQLite Und eben nach updatefhem ist der Fehler noch immer da.

Hast du das evtl bei den recentReadingsOfDevice geändert ?
Lg
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Februar 2023, 14:59:03
Zitat
Hi - falls sich deine Antwort auf mein Problem mit dem 50mostFreqLogsLast2days-sql bezog - ich nutze SQLite ...
Ah ok.
Nein, hatte es tatsächlich für MySQL geändert. Da war es mir jetzt auch aufgefallen.
Ich ändere es auch für SQLite und checke eine neue V wahrscheinlich schon heute Abend ein.

Es kommt mit dieser Version auch ein neuer Setter "migrateCollation" hinzu um den Zeichensatz einer MySQL/MariaDB nebst Tabellen umzustellen.
Gilt nicht für SQLite.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Februar 2023, 23:30:48
Morgen früh wird eine neue DbRep Version ausgeliefert.
Neben kleineren Fixes ist der Support für den Zeichensatz utf8mb4 eingebaut, um die neue DbLog Version entsprechend zu unterstützen.

Um eine bestehende MySQL/MariaDB-Datenbank einfach nach utf8mb4 zu migrieren, kann jetzt der neue Setter "migrateCollation" genutzt werden.
Die Hintergründe bzgl. utf8mb4 könnt ihr in diesem Thread lesen:
https://forum.fhem.de/index.php/topic,132163.0.html

LG
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 20 Februar 2023, 17:56:13
Moin,
beim executeAfterProc ist die Hilfe durcheinander.
VG   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 20 Februar 2023, 18:09:17
Hmm, bei mir nicht.....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Februar 2023, 09:17:16
Zitat von: DS_Starter am 20 Februar 2023, 18:09:17
Hmm, bei mir nicht.....
Sorry, ich hatte ne ältere version
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Februar 2023, 09:56:18
Moin,
ich habe das executeAfterProc jetzt auch mal ausprobiert und es läuft prima. Bei Fehlermeldungen kommt auch eine Rückmeldung, jedoch nicht beim Erfolg.
Wäre es eventuell möglich Meldungen vom Skript oder zumindest einen Return Code als reading zu liefern?

Bei den Beispielen könnte man auch noch eins für z.B. Python mit aufnehmen.
"/opt/fhem/python/Prognose_KI/PV-KI-21_batch.py"

In meinem Test konnte ich so für meine KI Leistungsprognose eine MySQL Procedur im Anschluss mit einem Python Skript koppeln.
Ich bin immer wieder begeistert, was man mit FHEM so alles machen kann.

Einige Fragen wären da dann noch:
1) Läuft das executeAfterProc dann blocking, oder asyncron im Hintergrund?
2) Werden im auszuführenden Kommando auch noch Variablen ersetzt, z.B. $NAME, bevor es ausgeführt wird?

EDIT:
Für die Überwachung des Skriptes habe ich zu Beginn ein setreading mit "running" in das DbRep gemacht, am Ende wird das dann mit "done" erneut gesetzt. Bisher läuft das jetzt ohne Probleme.

VG   Christian
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Februar 2023, 18:45:02
Hallo Christian,

Zitat
Wäre es eventuell möglich Meldungen vom Skript oder zumindest einen Return Code als reading zu liefern?
Das ist schon so.
Es wird das Reading after_<Funktion>_message geschrieben. Zum Beispiel ist bei mir gesetzt:

    executeAfterProc = set LogDB reopen

Nach einem tableCurrentFillup wird der Befehl ausgeführt und das Reading mit der Rückmeldung des ausgeführten Befehls geschrieben:

  after_tableCurrentFillup_message = Reopen executed.

(Der ausgeführte Befehl oder die sub muss natürlich eine Rückmeldung zurückgeben.)

Zitat
1) Läuft das executeAfterProc dann blocking, oder asyncron im Hintergrund?
Nein, zumindest nicht durch DbRep gesteuert.
Aber der Nutzer kann natürlich eine Perl-Routine hinterlegen, die ihrerseits non-Blocking (z.B. mit BlockingCall) arbeitet.

Zitat
2) Werden im auszuführenden Kommando auch noch Variablen ersetzt, z.B. $NAME, bevor es ausgeführt wird?
Ersetzt nicht, aber der User kann seiner Routine die Struktur "$hash" mitgeben und daraus $hash->{NAME} herausziehen und selbst Ersetzungen vornehmen und vieles mehr.

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Februar 2023, 18:54:41
Zitat von: DS_Starter am 21 Februar 2023, 18:45:02
Es wird das Reading after_<Funktion>_message geschrieben. Zum Beispiel ist bei mir gesetzt:

    executeAfterProc = set LogDB reopen

Nach einem tableCurrentFillup wird der Befehl ausgeführt und das Reading mit der Rückmeldung des ausgeführten Befehls geschrieben:

  after_tableCurrentFillup_message = Reopen executed.

(Der ausgeführte Befehl oder die sub muss natürlich eine Rückmeldung zurückgeben.)
Nein, zumindest nicht durch DbRep gesteuert.
Aber der Nutzer kann natürlich eine Perl-Routine hinterlegen, die ihrerseits non-Blocking (z.B. mit BlockingCall) arbeitet.
Ersetzt nicht, aber der User kann seiner Routine die Struktur "$hash" mitgeben und daraus $hash->{NAME} herausziehen und selbst Ersetzungen vornehmen und vieles mehr.
Hallo Heiko,
Du überforderst mich wieder :-)
Geht das mit dem $hash auch zu Python? Hättest Du da ein Beispiel?

Wenn ich aus dem Python mit print() eine Meldung schreibe ist die nicht sichtbar. Ich versuche es dann mal mit einen return Code.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 Februar 2023, 19:01:01
Zitat
Geht das mit dem $hash auch zu Python? Hättest Du da ein Beispiel?
Wahrscheinlich nicht, aber sicherlich kann man Python (habe aber noch nie etwas damit gemacht!) Variablen übergeben.
Wie zum Beispiel

my $name = $hash->{NAME};

$name dann an Python übergeben. In $hash steckt ja z.B. alles drin was das aufrufende DbRep-Device enthält.
Es gibt ja auch ein FHEM-Modul für Python (oder umgedreht). Wahrscheinlich bekommst du in diesem Unterforum fundiertere Informationen.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 21 Februar 2023, 19:27:35
Das ist ja lustig, wenn ich im Python Skript ein print() mache wird das dann direkt ins FHEM Log geschrieben.
Mit dem Fhem Modul im Python schreibe ich direkt in das Fhem Device, damit bekomme ich es jetzt erstmal synchronisiert und kann auf den Event reagieren.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 März 2023, 14:49:11
Hallo DS_Starter

Mach schon seit ein paar Wochen nächtllich eine Mittelwertbildung mit dem Modul per avgtim.
=> Ein FHEM Update lief am 7.3 und seit 9.3 treten "plötzlich" PERL-Warnings auf.

Update erfolgte am 7.3 ca. 13 Uhr
pi@raspi-2:~/log$ grep shutdown fhem-2023-10.log
2023.03.06 17:02:12.499 0: Server shutdown
2023.03.07 12:58:23.380 1: [b]update finished[/b], "shutdown restart" is needed to activate the changes.
2023.03.07 13:00:00.983 0: Server shutdown
2023.03.07 18:34:27.558 0: Server shutdown



Warnings erstmaling am 9.3 bei der Mittelwertbildung   
Im Editor fiel es erst gar nicht so auf. Bei einem grep bin ich dann über die mehrzeilige Info hinter eval gestolpert.

2023.03.09 03:30:00.048 3: msg globalMsg: ID=1678329000.00468.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='Start Mittelwerte in DB schreiben'
2023.03.09 03:30:00.581 3: DbRep DBRep_avgtim_MT691_power - number of lines updated in >DBLogging<: 0
2023.03.09 03:30:00.583 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 15
2023.03.09 03:30:00.625 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'
2023.03.09 03:30:00.781 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.09 03:30:00.784 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtM................$
2023.03.09 03:30:00.790 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.09 03:30:00.792 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtMDhfMDB8MjAyMy0wMy0wOF8wMSM................$
2023.03.09 03:30:01.214 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
2023.03.09 03:30:01.215 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 9
2023.03.09 03:30:01.259 3: DbRep DBRep_avgtim_power - execute command after averageValue: 'set DBRep_avgtim_total_power averageValue writeToDBSingleStart'
2023.03.09 03:30:01.995 3: DbRep DBRep_avgtim_total_power - number of lines updated in >DBLogging<: 0
2023.03.09 03:30:01.997 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
2023.03.09 03:30:02.048 3: DbRep DBRep_avgtim_total_power - execute command after averageValue: 'set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}'
2023.03.09 03:30:02.388 3: DbRep DBRep_avgtim_unit - execute command after changeval: 'msg push -1 [DBRep_avgtim_total_power:state] taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:tot$
2023.03.09 03:30:02.442 3: msg globalMsg: ID=1678329002.39269.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='done taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:t$
2023.03.09 03:30:02.459 3: DbRep DBRep_avgtim_unit - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"W")", number: 48


Ob die Werte in der Datenbank in Ordnung sind habe ich nicht geprüft. Der DBRep_avgtim_MT691_power macht Probleme die beiden DBRep_avgtim_power & DBRep_avgtim_total_power laufen durch.

Die beiden eval-Zeilen in voller Länge:

2023.03.09 03:30:00.784 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtMDhfMDB8MjAyMy0wMy0wOF8wMSMxNjc5NC4wNiMyMDIzLTAzLTA4XzAxfDIwMjMtMDMtMDhfMDIjMTQ4OTYuNTk2NjY2NjY2NyMyMDIzLTAzLTA4XzAyfDIwMjMtMDMtMDhfMDMjNjkwMC4xMDMzMzMzMzMzMyMyMDIzLTAzLTA4XzAzfDIwMjMtMDMtMDhfMDQjMTg1NC42NTQ0NDQ0NDQ0NCMyMDIzLTAzLTA4XzA0fDIwMjMtMDMtMDhfMDUjMTg1OC41OTc3Nzc3Nzc3OCMyMDIzLTAzLTA4XzA1fDIwMjMtMDMtMDhfMDYjMzguNTcjMjAyMy0wMy0wOF8wNnwyMDIzLTAzLTA4XzA3I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wN3wyMDIzLTAzLTA4XzA4I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wOHwyMDIzLTAzLTA4XzA5IzkuMTY2NjY2NjY2NjY2NjcjMjAyMy0wMy0wOF8wOXwyMDIzLTAzLTA4XzEwI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMHwyMDIzLTAzLTA4XzExI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMXwyMDIzLTAzLTA4XzEyI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMnwyMDIzLTAzLTA4XzEzI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xM3wyMDIzLTAzLTA4XzE0I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNHwyMDIzLTAzLTA4XzE1I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNXwyMDIzLTAzLTA4XzE2I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNnwyMDIzLTAzLTA4XzE3IzguMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xN3wyMDIzLTAzLTA4XzE4IzYuNDA0MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOHwyMDIzLTAzLTA4XzE5IzcuMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOXwyMDIzLTAzLTA4XzIwIzEuNDkxMzg4ODg4ODg4ODkjMjAyMy0wMy0wOF8yMHwyMDIzLTAzLTA4XzIxIzAuOTI1IzIwMjMtMDMtMDhfMjF8MjAyMy0wMy0wOF8yMiMxMi4xMDUjMjAyMy0wMy0wOF8yMnwyMDIzLTAzLTA4XzIzIzcuNTU1NDMyMDY0NDYyMzUjMjAyMy0wMy0wOF8yM3w=|TVFUVDJfRVNQXzI=|MT691_power|0.295909,0.395488|15||')}
2023.03.09 03:30:00.792 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtMDhfMDB8MjAyMy0wMy0wOF8wMSMxNjc5NC4wNiMyMDIzLTAzLTA4XzAxfDIwMjMtMDMtMDhfMDIjMTQ4OTYuNTk2NjY2NjY2NyMyMDIzLTAzLTA4XzAyfDIwMjMtMDMtMDhfMDMjNjkwMC4xMDMzMzMzMzMzMyMyMDIzLTAzLTA4XzAzfDIwMjMtMDMtMDhfMDQjMTg1NC42NTQ0NDQ0NDQ0NCMyMDIzLTAzLTA4XzA0fDIwMjMtMDMtMDhfMDUjMTg1OC41OTc3Nzc3Nzc3OCMyMDIzLTAzLTA4XzA1fDIwMjMtMDMtMDhfMDYjMzguNTcjMjAyMy0wMy0wOF8wNnwyMDIzLTAzLTA4XzA3I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wN3wyMDIzLTAzLTA4XzA4I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wOHwyMDIzLTAzLTA4XzA5IzkuMTY2NjY2NjY2NjY2NjcjMjAyMy0wMy0wOF8wOXwyMDIzLTAzLTA4XzEwI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMHwyMDIzLTAzLTA4XzExI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMXwyMDIzLTAzLTA4XzEyI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMnwyMDIzLTAzLTA4XzEzI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xM3wyMDIzLTAzLTA4XzE0I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNHwyMDIzLTAzLTA4XzE1I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNXwyMDIzLTAzLTA4XzE2I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNnwyMDIzLTAzLTA4XzE3IzguMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xN3wyMDIzLTAzLTA4XzE4IzYuNDA0MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOHwyMDIzLTAzLTA4XzE5IzcuMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOXwyMDIzLTAzLTA4XzIwIzEuNDkxMzg4ODg4ODg4ODkjMjAyMy0wMy0wOF8yMHwyMDIzLTAzLTA4XzIxIzAuOTI1IzIwMjMtMDMtMDhfMjF8MjAyMy0wMy0wOF8yMiMxMi4xMDUjMjAyMy0wMy0wOF8yMnwyMDIzLTAzLTA4XzIzIzcuNTU1NDMyMDY0NDYyMzUjMjAyMy0wMy0wOF8yM3w=|TVFUVDJfRVNQXzI=|MT691_power|0.295909,0.395488|15||')}


Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 13 März 2023, 18:56:17
Moin Ralf,
die perl warning
Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694
hängt offensichtlich mit der von mir 'verbrochenen' Änderung des gewichteten Mittelwertalgorithmus zusammen (s. ab Beitrag #1849). Dort wird durch ein 'peek-back-in-time' versucht, den letzten Messwert VOR Begin des eigentlichen Mittelwert-Zeitraums zu ermitteln. Beim schnellen Blick über den Code fiel mir jetzt auf, dass $to undefiniert bleibt, wenn kein voriger Wert gefunden wird. Die for-Schleife ab Zeile 3670 (in der $to erstmals definiert wird) wird dann gar nicht durchlaufen. Alles weitere sind dann evtl. Folgefehler.

Ich versuche mal, das zu simulieren (und den bug zu korrigieren). Aber DS_Starter wird vermutlich schneller sein.

Gruss
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 13 März 2023, 22:19:52
Ok dazu passt vermutlich, dass am 10. kein Fehler kam um dann am 11. wieder aufzutreten.

Muss gleich nochmal schauen, ob das identisch war oder etwas anderes angemeckert.

Gruß Ralf

Edit 14.3 9.20 Uhr

Ne ist das gleiche wie oben ($to in subtraction und $val1 in concatenation):
2023.03.11 03:30:00.609 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'
2023.03.11 03:30:00.755 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.11 03:30:00.758 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0xMF8wMCMxNS40MjI1MzUyMTEyNjc2IzIwMjMtMDMtMTBfMDB8MjAyMy0wMy0xMF8wMSMxMC4zNTA1NTU1NTU1NTU2IzIwMjMtMDMtMTBfMDF8MjAyMy0wMy0xMF8wMiMzLjU4MzMzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDJ8MjAyMy0wMy0xMF8wMyMxNDg5My45NDY2NjY2NjY3IzIwMjMtMDMtMTBfMDN8MjAyMy0wMy0xMF8wNCMxNDM1MS4zOTY2NjY2NjY3IzIwMjMtMDMtMTBfMDR8MjAyMy0wMy0xMF8wNSM2MjM1LjgxMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDV8MjAyMy0wMy0xMF8wNiM0MS40MjY2NjY2NjY2NjY3IzIwMjMtMDMtMTBfMDZ8MjAyMy0wMy0xMF8wNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDd8MjAyMy0wMy0xMF8wOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDh8MjAyMy0wMy0xMF8wOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDl8MjAyMy0wMy0xMF8xMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTB8MjAyMy0wMy0xMF8xMSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTF8MjAyMy0wMy0xMF8xMiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTJ8MjAyMy0wMy0xMF8xMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTN8MjAyMy0wMy0xMF8xNCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTR8MjAyMy0wMy0xMF8xNSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTV8MjAyMy0wMy0xMF8xNiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTZ8MjAyMy0wMy0xMF8xNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTd8MjAyMy0wMy0xMF8xOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTh8MjAyMy0wMy0xMF8xOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTl8MjAyMy0wMy0xMF8yMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjB8MjAyMy0wMy0xMF8yMSMxMS42NDU4MzMzMzMzMzMzIzIwMjMtMDMtMTBfMjF8MjAyMy0wMy0xMF8yMiM2LjI3MDgzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMjJ8MjAyMy0wMy0xMF8yMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjN8|TVFUVDJfRVNQXzI=|MT691_power|0.244824,0.342877|9||')}
2023.03.11 03:30:00.764 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.11 03:30:00.766 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0xMF8wMCMxNS40MjI1MzUyMTEyNjc2IzIwMjMtMDMtMTBfMDB8MjAyMy0wMy0xMF8wMSMxMC4zNTA1NTU1NTU1NTU2IzIwMjMtMDMtMTBfMDF8MjAyMy0wMy0xMF8wMiMzLjU4MzMzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDJ8MjAyMy0wMy0xMF8wMyMxNDg5My45NDY2NjY2NjY3IzIwMjMtMDMtMTBfMDN8MjAyMy0wMy0xMF8wNCMxNDM1MS4zOTY2NjY2NjY3IzIwMjMtMDMtMTBfMDR8MjAyMy0wMy0xMF8wNSM2MjM1LjgxMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDV8MjAyMy0wMy0xMF8wNiM0MS40MjY2NjY2NjY2NjY3IzIwMjMtMDMtMTBfMDZ8MjAyMy0wMy0xMF8wNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDd8MjAyMy0wMy0xMF8wOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDh8MjAyMy0wMy0xMF8wOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDl8MjAyMy0wMy0xMF8xMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTB8MjAyMy0wMy0xMF8xMSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTF8MjAyMy0wMy0xMF8xMiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTJ8MjAyMy0wMy0xMF8xMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTN8MjAyMy0wMy0xMF8xNCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTR8MjAyMy0wMy0xMF8xNSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTV8MjAyMy0wMy0xMF8xNiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTZ8MjAyMy0wMy0xMF8xNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTd8MjAyMy0wMy0xMF8xOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTh8MjAyMy0wMy0xMF8xOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTl8MjAyMy0wMy0xMF8yMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjB8MjAyMy0wMy0xMF8yMSMxMS42NDU4MzMzMzMzMzMzIzIwMjMtMDMtMTBfMjF8MjAyMy0wMy0xMF8yMiM2LjI3MDgzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMjJ8MjAyMy0wMy0xMF8yMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjN8|TVFUVDJfRVNQXzI=|MT691_power|0.244824,0.342877|9||')}
2023.03.11 03:30:01.108 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 14 März 2023, 10:36:05
Das allein
Zitat von: alkazaa am 13 März 2023, 18:56:17
Beim schnellen Blick über den Code fiel mir jetzt auf, dass $to undefiniert bleibt, wenn kein voriger Wert gefunden wird. Die for-Schleife ab Zeile 3670 (in der $to erstmals definiert wird) wird dann gar nicht durchlaufen.
war's nicht.

Aber wenn ich weder im gesamten Mittelungszeitraum, noch in dem 'peek-back' Zeitraum irgendwelche Daten habe, kann ich die zwei perl-warnings reproduzieren.

Gruß Franz





Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2023, 11:19:44
Hallo zusammen,

ich schaue heute oder morgen mal danach.
War bei mir auch schon aufgefallen, hatte aber bisher noch keine Zeit.
Hatte mich intensiv mit dem Einbau Solarbatterie befasst.  :)

Grüße,
Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 14 März 2023, 12:39:54
Hi
Weiss nicht ob es Sinn macht... oder zufällig in den letzten paar Wochen vor dem 8.3 geklappt hat.

Der Fehler ist erstmalig am 8.3 aufgetreten (lt. den Logs seit Januar 2023). Hab das Archiv mal gerade durchgegrept. Und diese Mittelwertchain läuft seit 14. Januar.
FHEM Updates am 7.3 & 12.1 (nur DBRep/DBLog Update mit spätem Restart 6 Stunden später) & 14.1 (vermutlich die Version mit dem neuen Mittelwertcode).


pi@raspi-2:/opt/fhem/log $ grep "subtraction" fhem-2023-*
fhem-2023-10.log:2023.03.08 03:30:01.044 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.09 03:30:00.781 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.10 03:30:01.106 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.11 03:30:00.755 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.12 03:30:00.266 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.12 03:30:00.861 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-11.log:2023.03.13 03:30:00.764 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-11.log:2023.03.14 03:30:00.268 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-11.log:2023.03.14 03:30:00.734 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.


Muss mich hinsichtlich der Aussage oben korrigieren. Liegt eventuell ja an den Daten die da gemittelt werden und manchmal nicht zum Fehler führen.
=> die Meldung kommt z.B. für die Variable $to ab 8.3
=> es sind alle drei  avgtim betroffen mit den Readings "DBRep_avgtim_MT691_power" & "DBRep_avgtim_power" & "DBRep_avgtim_total_power".
=> das geloggte "eval" ist beim "DBRep_avgtim_MT691_power" besonders lang und daher auffällig.

Klingt aus meiner naiven Sicht danach, dass es Codeteile nach dem 14.1 sind.


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 14 März 2023, 15:20:32
Von den Daten her passt es: Am 22.1. ist die neue Routine "sub _DbRep_avgTimeWeightMean" im SVN vom contrib Verzeichnis in das FHEM Verzeichnis übernommen worden. Seit Deinem update vom 7.3. benutzt Du sie dann bei Dir.

Aber wie gesagt: ich kann die beiden perl-warnings (mit meinen Daten)  bei mir nur provozieren, wenn ich erwinge, dass im betrachteten Zeitraum KEINE Daten vorliegen. Allerdings musste ich dazu aggregation=minute und das Zeitfenster (timestamp_begin und timestamp_end) sehr kurz wählen und auch im code die peek-back Zeit auf wenige Sekunden einstellen.

Wie ist den bei Dir aggregation eingestellt, und wieviele Daten liegen zwischen timestamp_begin und timestamp_end?

-Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 14 März 2023, 20:19:38
Hi ich lass mal im ersten Step Lists etc. weg.

Zu den Fragen, das ist bei allen drei gleich:
=> "aggregation  hour"
=> "timestamp_begin  previous_day_begin"    "timestamp_end  previous_day_end"
       dazwischen am 13.3:
       40 Werte für 1)  / 230 Werte für 2) / 740 Werte für 3)


Daten der readings

  • HitchiLesekopf am Zähler (Nachtstromheizung) per ESP mit TASMOTA und MQTT, Daten schickt der ESP alle 300 Sekunden sowie ein einschränkendes "DbLogInclude MT691_power:120
    Werte kommen wenn der Stromversorger per Rundsteuerempfänger nachts einschaltet alle 300 Sekunden . Sowie tagsüber ggfs. durch kleine Leistungen der Steuerelektronik, können dann aber ggfs. nur 2 Werte in der Stunde sein, oder auch keine.
  • Shelly PlugS am Balkonkraftwerk mit dem Reading "power"; Daten über Shelly_Monitor 2 bis etwa 6 Minuten
    nachts keine Daten (max. alle 120 Sekunden per DbLogInclude  power:120)
  • Shelly 3EM am Zähler mit dem Reading "total_power";  Daten im 2 Minutenraster auch nachts (aufgrund attribut interval 120)

Edit:
Ich häng als Textdatei mal die relevanten Daten an: Log und 3) mit avgtwm_hour_MT691_power   vom 13.  ;)

Edit2:
Irgendwie sieht es so aus, dass die Mittelwertberechnung durch ist und die Zeilen in der Datenbank eingefügt sind.
Die Warnings und der eval-Eintrag kommt erst wenn es um das nächste Kommando der Chain geht "execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'"
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 15 März 2023, 10:13:46
Zitat von: RalfRog am 14 März 2023, 20:19:38
Irgendwie sieht es so aus, dass die Mittelwertberechnung durch ist und die Zeilen in der Datenbank eingefügt sind.
Die Warnings und der eval-Eintrag kommt erst wenn es um das nächste Kommando der Chain geht "execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'"

Das sieht für mich danach aus, dass beim zweiten 'averageValue' der chain die Datenbank noch mit dem Rückschreiben der Ergebnisse des ersten Teils beschäftigt ist. Bei den ganzen DB Aktivitäten in 93_DbRep und 93_DbLog wurde zuletzt einiges geändert (z.B. asynchrone Prozesse eingeführt), was der Grund dafür sein könnte dass Du den Effekt erst jetzt beobachtest. DS_Starter kann das sicher im Detail erklären, falls meine Vermutung stimmt.

Als pragmatiche Lösung würde ich mal testen, die chain zeitlich zu entzerren, z.B. mit  "execute command after averageValue: 'define chain_delay at +00:05:00 set DBRep_avgtim_power averageValue writeToDBSingleStart'"

Statt der hier gewählten 5 Minuten als delay würde vermutlich auch schon 1 Minute reichen.

Gruss
Franz


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 15 März 2023, 10:40:35
Hi
Ja schauen wir mal was DS_STARTER sagt. Ich meine mich zu erinnern, dass er auch mal was von einer Chain bei sich erzählt hat und jetzt das "Problem" beobachtet.

Danke für den Vorschlag zur Entzerrung.
Dafür sprechen könnte (noch nicht fertig abgespeichert), dass mit dem ersten Aufruf tatsächlich ja die Readings verarbeitet werden die den größten Anteil haben 700-800 den Tag.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 15 März 2023, 14:09:54
Mist hab mir aus irgendeinem Grund den Beitrag kaputt geschrieben  :-\

Hier ging es um den Vorschlag den 2. Aufruf in der Chain mit Verzögerung zu starten
"define chain_delay at +00:01:00 set DBRep_avgtim_power averageValue writeToDBSingleStart"

Das ist der Rest:
Ok verstanden. Versuch macht kluch... klappt als Attribut. Du hattest den Text des Logfiles verwendet  :D
Habe es gerade mal durchlaufen lassen. Alle calculated Werte wieder neu erzeugt (hatte die vorher aus der DB gelöscht).
Ende Rest:

HAb ich dann gemacht. Siehe Antwort #1946  => Fazit keine Änderung

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 15 März 2023, 15:16:16
Hi das ist heute Nacht passiert - LOG  (Meldung eval: my $SELF... erstmalig am 12.3  ::) )


2023.03.15 03:30:00.074 3: msg globalMsg: ID=1678847400.00598.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='Start Mittelwerte in DB schreiben'

2023.03.15 03:30:00.274 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.15 03:30:00.276 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }

2023.03.15 03:30:00.282 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.15 03:30:00.283 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }

2023.03.15 03:30:00.571 3: DbRep DBRep_avgtim_MT691_power - number of lines updated in >DBLogging<: 0
2023.03.15 03:30:00.574 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 10
2023.03.15 03:30:00.627 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'

2023.03.15 03:30:00.772 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.15 03:30:00.775 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0xNF8wMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTRfMDB8MjAyMy0wMy0xNF8wMSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTRfMDF8MjAyMy0wMy0$

2023.03.15 03:30:00.780 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.15 03:30:00.782 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0xNF8wMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTRfMDB8MjAyMy0wMy0xNF8wMSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTRfMDF8MjAyMy0wMy0$

2023.03.15 03:30:01.141 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
2023.03.15 03:30:01.142 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 12
2023.03.15 03:30:01.189 3: DbRep DBRep_avgtim_power - execute command after averageValue: 'set DBRep_avgtim_total_power averageValue writeToDBSingleStart'
2023.03.15 03:30:02.004 3: DbRep DBRep_avgtim_total_power - number of lines updated in >DBLogging<: 0
2023.03.15 03:30:02.006 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
2023.03.15 03:30:02.058 3: DbRep DBRep_avgtim_total_power - execute command after averageValue: 'set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}'
2023.03.15 03:30:02.388 3: DbRep DBRep_avgtim_unit - execute command after changeval: 'msg push -1 [DBRep_avgtim_total_power:state] taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:total_power MT691_power'

2023.03.15 03:30:02.446 3: msg globalMsg: ID=1678847402.39299.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='done taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:total_power MT691_power'

2023.03.15 03:30:02.468 3: DbRep DBRep_avgtim_unit - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"W")", number: 46


Die Chain wird um 3.30 Uhr per AT gestartet:
=>  "*03:30 { fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }"
       Perl-Mode, da wusste ich wie zwei fhem Kommandos hintereinander ausgeführt werden

Was mich nun wundert ist, dass in der dritten Zeile nach der Perl-Warning der eval geloggt wird. Das ist ja der Inhalt des AT (vermute mal, dass so die Kommandos von Modul zu Modul weitergegeben werden um sie per eval auszuführen).
Aber da sind wir doch noch gar nicht beim berechnen und schreiben in die Datenbank, was dann noch nicht fertig sein könne. Hmmmm....
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 15 März 2023, 16:37:57
Jetzt bin ich auch verwirrt über die zeitliche Reihenfolge der log-Meldungen.

Was mit aber auffiel: in beiden von Dir genannten Fällen (in Beitrag #1926 und #1937) tauchen diese drei Log-Meldungen auf:

2023.03.09 03:30:00.583 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 15
2023.03.09 03:30:01.215 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 9
2023.03.09 03:30:01.997 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
(Beitrag #1926)


2023.03.15 03:30:00.574 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 10
2023.03.15 03:30:01.142 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 12
2023.03.15 03:30:02.006 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
(Beitrag #1937)

Also wurde jedesmal für die readings MT691_power, power und total_power etwas in die Datenbank zurückgeschrieben. Aber nur beim letzten reading (total_power) waren es 24 Werte, wie man beim stundenweise Mitteln erwarten würde. Irgendwas hat die beiden ersten Läufe also abgewürgt.

Teste doch mal, was sich beim händischen Mitteln der einzelnen readings jeweils ergibt. Ob die auch abwürgen, oder sauber durchlaufen.


EDIT:
Alles ist gut...
... außer das ich mich geirrt habe mit der Aussage, dass ein fehlender Datensatz im 'peek-back' Zeitraum allein nicht die perl-warning auslöst, sondern die Warnung nur kommt, wenn überhaupt keine Daten vorliegen.       

In Wirklichkeit löst die Kombination "keine Daten im peek-back intervall UND keine Daten in der ersten Periode" die Warnung aus. Im Ergebnis spielt es aber keine Rolle, weil dann sowieso keine Daten für die erste Mittelungsperiode geliefert werden.

Ich schau mal, wie man diese Warning am besten unterdrückt (bzw. so verhindert, dass nichts falsches berechnet wird)


Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 15 März 2023, 17:46:23
Zitat von: alkazaa am 15 März 2023, 16:37:57
...
Also wurde jedesmal für die readings MT691_power, power und total_power etwas in die Datenbank zurückgeschrieben. Aber nur beim letzten reading (total_power) waren es 24 Werte, wie man beim stundenweise Mitteln erwarten würde. Irgendwas hat die beiden ersten Läufe also abgewürgt.
...

Nur kurz der Vollständigkeit halber. Lediglich das Reading  total_power hat Daten von 24 Stunden. Die beiden andern nur während Sonnenschein oder der Nacht. Daher passen 10 oder 12 Werte schon  ;)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 15 März 2023, 18:04:39
Ja, hab's gesehen, siehe das EDIT meines vorigen Beitrags...
Sorry für das Hin und Her

Gruß
Franz
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 15 März 2023, 18:52:52
OK, hier die beiden Änderungen in 93_DbRep.pm, mit denen die perl-warnings verhindert werden:
Zeile 3657      if ($bin_end) {    wird zu                                     
Zeile 3657      if ($bin_end && $val1) {     

und     
Zeile 3694      $dt    = timelocal($secf, $minf, $hhf, $ddf, $mmf-1, $yyyyf-1900) - $to;                   
Zeile 3695         
wird zu   
Zeile 3694      $dt    = timelocal($secf, $minf, $hhf, $ddf, $mmf-1, $yyyyf-1900);                   
Zeile 3695      $dt   -= $to if ($to);
       

Vielleicht kann Heiko [DS_Starter] das bei nächster Gelegenheit übernehmen?                 

Beste Grüße
Franz                     
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 März 2023, 21:48:18
Mach ich ... bin noch bisschen mit meiner PV Battrie befasst  ;)
Melde mich ...

Danke für die Analyse !

Heiko
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 15 März 2023, 22:55:04
Bin unterwegs,
kann es morgen nachmittag probieren.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: alkazaa am 16 März 2023, 10:21:13
Was ich mich jetzt noch frage: Wo kommen bei Dir die "eval: "-Meldungen her? Die hatte ich nie, selbst mit verbose=5 nicht.
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 März 2023, 12:31:30
Ja ich frage ich mich auch...

Dachte irgenwie (wg. fast gleichem Zeitstempel), dass das mit der PERL-Warning davor zusammenhängt, da ja der Text der Meldung mit dem was davor war im Zusammenhang steht:
"eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue
writeToDBSingleStart") }"

Wo wird im DBRep die eval Funktion aufgefufen? Die $evalSpecials stecken doch in der fhem.pl. I'm lost  ::)

Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 März 2023, 13:10:34
Zitat
Ok verstanden. Versuch macht kluch... klappt als Attribut. Du hattest den Text des Logfiles verwendet  :D
Habe es gerade mal durchlaufen lassen. Alle calculated Werte wieder neu erzeugt (hatte die vorher aus der DB gelöscht).

Hatte mich zu dem Versuch mit der Verzögerung nicht geäußert.
Problem blieb bestehen:

2023.03.15 14:55:14.286 3: msg globalMsg: ID=1678888514.24051.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='Start Mittelwerte in DB schreiben'

2023.03.15 14:55:14.619 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.15 14:55:14.621 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }

2023.03.15 14:55:14.627 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.15 14:55:14.628 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }

2023.03.15 14:55:14.908 3: DbRep DBRep_avgtim_MT691_power - number of lines updated in >DBLogging<: 0
2023.03.15 14:55:14.910 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 10
==> mit delay aufgerufen
2023.03.15 14:55:15.085 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'define chain_delay at +00:01:00 set DBRep_avgtim_power averageValue writeToDBSingleStart'

2023.03.15 14:56:15.256 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.15 14:56:15.264 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.

2023.03.15 14:56:15.629 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
2023.03.15 14:56:15.631 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 12
2023.03.15 14:56:15.682 3: DbRep DBRep_avgtim_power - execute command after averageValue: 'set DBRep_avgtim_total_power averageValue writeToDBSingleStart'
==> hier die Warteminute
2023.03.15 14:56:16.466 3: DbRep DBRep_avgtim_total_power - number of lines updated in >DBLogging<: 0
2023.03.15 14:56:16.468 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
.... rest schenk ich mir


heute Nacht dann analog dazu:

2023.03.16 03:30:00.070 3: msg globalMsg: ID=1678933800.00793.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='Start Mittelwerte in DB schreiben'
2023.03.16 03:30:00.252 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.16 03:30:00.254 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }
2023.03.16 03:30:00.261 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.16 03:30:00.262 3: eval: my $SELF=   $evalSpecials->{'%SELF'};{ fhem ("msg push -1 Start Mittelwerte in DB schreiben") ; fhem ("set DBRep_avgtim_MT691_power averageValue writeToDBSingleStart") }
2023.03.16 03:30:00.539 3: DbRep DBRep_avgtim_MT691_power - number of lines updated in >DBLogging<: 0
2023.03.16 03:30:00.539 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 7
2023.03.16 03:30:00.582 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'define chain_delay at +00:01:00 set DBRep_avgtim_power averageValue writeToDBSingleStart'
2023.03.16 03:31:00.724 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.16 03:31:00.731 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.16 03:31:01.144 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
.... rest schenk ich mir



so jetzt geh ich die Codeänderung an
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 16 März 2023, 13:30:58
Sooo
1) Codeänderung
2) reload 93_DbRep.pm

Chain wird abgearbeitet (immer noch mit Pause zwischen 1. und 2. Schritt, ohne Pause 3. Schritt)


2023.03.16 13:22:25.550 3: msg globalMsg: ID=1678969345.50395.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='Start Mittelwerte in DB schreiben'
2023.03.16 13:22:26.164 3: DbRep DBRep_avgtim_MT691_power - number of lines updated in >DBLogging<: 0
2023.03.16 13:22:26.167 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 7
2023.03.16 13:22:26.357 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'define chain_delay at +00:01:00 set DBRep_avgtim_power averageValue writeToDBSingleStart'
2023.03.16 13:23:26.905 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
2023.03.16 13:23:26.907 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 15
2023.03.16 13:23:26.961 3: DbRep DBRep_avgtim_power - execute command after averageValue: 'set DBRep_avgtim_total_power averageValue writeToDBSingleStart'
2023.03.16 13:23:27.727 3: DbRep DBRep_avgtim_total_power - number of lines updated in >DBLogging<: 0
2023.03.16 13:23:27.729 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
2023.03.16 13:23:27.786 3: DbRep DBRep_avgtim_total_power - execute command after averageValue: 'set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}'
2023.03.16 13:23:28.120 3: DbRep DBRep_avgtim_unit - execute command after changeval: 'msg push -1 [DBRep_avgtim_total_power:state] taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:total_power MT691_power'
2023.03.16 13:23:28.177 3: msg globalMsg: ID=1678969408.12622.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='done taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:total_power MT691_power'
2023.03.16 13:23:28.197 3: DbRep DBRep_avgtim_unit - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"W")", number: 46


Sieht auf den ersten Blick gut aus und alle 46 gelöschten Werte wieder neu geschrieben  :)
Die Pause bzw. keine Pause scheint nicht der Knackpunkt zu sein.

Bleibt die Frage warum bei PERL Warning auch die Einträge mit eval?

Edit: Inhalt EventMonitor angehängt (Events Db.* und LOG)
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 17 März 2023, 11:33:06
Mit der Änderung der drei Zeilen code auch weiterhin diese Nacht (um 3:30 Uhr) keine Warnings zu "uninitialized value" mehr.

Gruß Ralf
Titel: Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 19 März 2023, 08:51:08
Moin,

habe die Änderungen übernommen und eingecheckt. Wird somit morgen früh im Update verteilt.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 30 März 2023, 13:43:24
In meinem contrib liegt eine neue V von DbRep.
Ich habe die Funktionalität von diffValue erweitert.

Man kann nun einstellen dass sowohl postive (wie bisher) als auch negative Differenzen berechnet werden.
UseCase war die Berechnung von Ladeleistungen (+) als auch Entladeleistungen (-) einer PV-Batterie pro Tag mit eine Stundenaggregation.

Dazu ist das Attr diffAccept erweitert:

diffAccept [+-]<Schwellenwert>

diffAccept legt für die Funktion diffValue fest, bis zu welchem <Schwellenwert> eine Werte-Differenz zwischen zwei unmittelbar aufeinander folgenden Datensätzen akzeptiert werden.
Wird dem Schwellenwert +- (optional) vorangestellt, werden sowohl positive als auch negative Differenzen ausgewertet.

(default: 20, nur positve Differenzen zwischen Vorgänger und Nachfolger)

    Beispiel:
    attr diffAccept +-10000


Bei Schwellenwertüberschreitungen wird das Reading diff_overrun_limit_<Schwellenwert> erstellt.
Es enthält eine Liste der relevanten Wertepaare. Mit verbose 3 werden diese Datensätze ebenfalls im Logfile protokolliert.

(Upgedatet)

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 02 April 2023, 14:23:27
Hallo, ich habe mir mit diffValue die Tageswerte aus der db gezogen und würde diese gerne in einem barchart svg Tageweise darstellen. Die Werte selbst sind wieder in die db geschrieben, aber wie muss ich das svg konfigurieren?


Berechnete Readings:2023-03-02_17-50-27__Qcells__SolarEngeryTotal__DIFF__2023-03-02
58.2000
2023-04-02 14:06:02
2023-03-03_17-47-58__Qcells__SolarEngeryTotal__DIFF__2023-03-03
45.1000
2023-04-02 14:06:02
2023-03-04_17-29-16__Qcells__SolarEngeryTotal__DIFF__2023-03-04
10.1000
2023-04-02 14:06:02
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 April 2023, 21:03:32
Ehrlich gesagt verstehe ich die Frage noch nicht ganz.
Du hast ja nach writeToDB Readings in der DB die so heißen sollten:

diff_day_SolarEngeryTotal

Die kannst du doch nun wie gewöhnlich im SVG darstellen bzw. wo genau ist dein Problem ?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 02 April 2023, 22:07:08
Die SVG nimmt den timestamp von dem db Eintrag für die x Achse. Hier steht aber der Zeitpunkt an dem die Berechnung ausgeführt wurde, nicht der Tag für den die Werte sind.

Ich müsste entweder den Zeitstempel anpassen oder dem Plot beibringen das es den Zeitpunkt aus dem Reading extrahiert...
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 April 2023, 22:45:36
ZitatHier steht aber der Zeitpunkt an dem die Berechnung ausgeführt wurde, nicht der Tag für den die Werte sind.
Der Timestamp sollte allerdings der Zeitstempel des Datensatzes sein.
Das schaue ich mir morgen genauer an und melde mich wieder.

Hast du das Attr aggregation auf "day" stehen ?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 April 2023, 22:54:48
Ich habe gerade ein diffValue eines Wertes ausgeführt (verbose 5):

2023.04.02 22:50:28.278 4: DbRep Rep.CPU - begin transaction
2023.04.02 22:50:28.287 4: DbRep Rep.CPU - UPDATE history: 2023-04-02 20:08:02|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.0080|, RESULT: 0
2023.04.02 22:50:28.288 4: DbRep Rep.CPU - INSERT history: 2023-04-02 20:08:02|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.0080|, RESULT: 1
2023.04.02 22:50:28.290 4: DbRep Rep.CPU - transaction committed
2023.04.02 22:50:28.291 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 0
2023.04.02 22:50:28.291 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 1

Man sieht dass der Insert Timestamp in die history der Timestamp des Wertes ist und nicht die Zeit der Ausführung (2023.04.02 22:50:28).
Poste mal bitte noch ein List deines Devices damit ich es evtl. nachstellen kann.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 03 April 2023, 06:10:05
Merkwürdig, ich dachte das wäre so gewollt das der timestamp der Berechnung hier hinterlegt wird.

Mein device sieht so aus:
defmod Rep.Pv.lm.daily DbRep myDbLog
attr Rep.Pv.lm.daily aggregation day
attr Rep.Pv.lm.daily device Qcells
attr Rep.Pv.lm.daily event-on-change-reading .*
attr Rep.Pv.lm.daily fastStart 1
attr Rep.Pv.lm.daily reading SolarEngeryTotal
attr Rep.Pv.lm.daily readingNameMap Daily_Production
attr Rep.Pv.lm.daily room PV->Reporting
attr Rep.Pv.lm.daily showproctime 1
attr Rep.Pv.lm.daily timestamp_begin previous_month_begin
attr Rep.Pv.lm.daily timestamp_end previous_month_end
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: FHEM-User22 am 03 April 2023, 09:45:08
Guten Morgen,
ich habe mir mal das RAW von Tomk gestiebitzt.

define Rep.Pv.lm.hour DbRep LogDBHome
attr Rep.Pv.lm.hour aggregation no
attr Rep.Pv.lm.hour alias PV letzte Stunde
attr Rep.Pv.lm.hour comment https://forum.fhem.de/index.php?msg=1270728
attr Rep.Pv.lm.hour device FRW_Einspeisung
attr Rep.Pv.lm.hour event-on-change-reading .*
attr Rep.Pv.lm.hour fastStart 1
attr Rep.Pv.lm.hour reading switch_aenergy_total
attr Rep.Pv.lm.hour readingNameMap Daily_Production
attr Rep.Pv.lm.hour room Strom,Strom Einspeisung
attr Rep.Pv.lm.hour showproctime 1
attr Rep.Pv.lm.hour timestamp_begin previous_hour_begin
attr Rep.Pv.lm.hour timestamp_end previous_hour_end
#   DATABASE   fhem
#   DEF        LogDBHome
#   FUUID      642a60c7-f33f-bd9c-c200-48a40829fd3d4947
#   FVERSION   93_DbRep.pm:v8.52.1-s27340/2023-03-19
#   LASTCMD    initial database connect stopped due to attribute 'fastStart'
#   MODEL      Client
#   NAME       Rep.Pv.lm.hour
#   NOTIFYDEV  global,Rep.Pv.lm.hour
#   NR         499
#   NTFY_ORDER 50-Rep.Pv.lm.hour
#   ROLE       Client
#   STATE      initialized
#   TYPE       DbRep
#   UTF8       1
#   HELPER:
#     DBLOGDEVICE LogDBHome
#     IDRETRIES  3
#     PACKAGE    main
#     VERSION    8.52.1
#   READINGS:
#     2023-04-03 07:58:34   state           initialized
#
setstate Rep.Pv.lm.hour initialized
setstate Rep.Pv.lm.hour 2023-04-03 07:58:34 .associatedWith FRW_Einspeisung
setstate Rep.Pv.lm.hour 2023-04-03 07:58:34 state initialized


Bin ich total falsch, ich finde keine Ergebisse. Wo schreibt dbrep die neu erzeugten Readings hin? Oder habe ich einen Denkfehler.

Dankeschön
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2023, 09:58:28
Guten Morgen nach Grimma  :)

Bin ich total falsch, ich finde keine Ergebisse. Wo schreibt dbrep die neu erzeugten Readings hin?

Zumindest in die history Tabelle. Du musst aber ein:

 set ... <Kommando> writeToDB

ausführen.

LG,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2023, 10:05:19
@Tomk,

ich habe dein Setup bei mir nachgestellt.
Wie schon geschrieben werden Diffs des Monats mit den Werte-Timestamp in die DB geschrieben:

Zitat2023.04.03 09:46:59.910 4: DbRep Rep.CPU - UPDATE history: 2023-03-15 23:54:22|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|8.1357|, RESULT: 1
2023.04.03 09:46:59.913 4: DbRep Rep.CPU - UPDATE history: 2023-03-16 23:48:46|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|24.2794|, RESULT: 1
2023.04.03 09:46:59.915 4: DbRep Rep.CPU - UPDATE history: 2023-03-17 23:56:04|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|9.7738|, RESULT: 1
2023.04.03 09:46:59.917 4: DbRep Rep.CPU - UPDATE history: 2023-03-18 23:49:48|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|9.3645|, RESULT: 1
2023.04.03 09:46:59.932 4: DbRep Rep.CPU - UPDATE history: 2023-03-19 23:08:32|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.5659|, RESULT: 1
2023.04.03 09:46:59.935 4: DbRep Rep.CPU - UPDATE history: 2023-03-20 19:47:01|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.0331|, RESULT: 1
2023.04.03 09:46:59.938 4: DbRep Rep.CPU - UPDATE history: 2023-03-21 23:24:33|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|4.8647|, RESULT: 1
2023.04.03 09:46:59.940 4: DbRep Rep.CPU - UPDATE history: 2023-03-22 23:52:13|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|9.8353|, RESULT: 1
2023.04.03 09:46:59.943 4: DbRep Rep.CPU - UPDATE history: 2023-03-23 19:52:52|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.1750|, RESULT: 1
2023.04.03 09:46:59.945 4: DbRep Rep.CPU - UPDATE history: 2023-03-24 23:58:47|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|1.0459|, RESULT: 1
2023.04.03 09:46:59.948 4: DbRep Rep.CPU - UPDATE history: 2023-03-25 22:17:31|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|3.2759|, RESULT: 1
2023.04.03 09:46:59.950 4: DbRep Rep.CPU - UPDATE history: 2023-03-26 23:59:44|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.7821|, RESULT: 1
2023.04.03 09:46:59.953 4: DbRep Rep.CPU - UPDATE history: 2023-03-27 23:53:45|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|9.5597|, RESULT: 1
2023.04.03 09:46:59.955 4: DbRep Rep.CPU - UPDATE history: 2023-03-28 23:36:28|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|5.8637|, RESULT: 1
2023.04.03 09:46:59.958 4: DbRep Rep.CPU - UPDATE history: 2023-03-29 23:52:56|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.9543|, RESULT: 1
2023.04.03 09:46:59.960 4: DbRep Rep.CPU - UPDATE history: 2023-03-30 23:42:17|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|1.3963|, RESULT: 1
2023.04.03 09:46:59.962 4: DbRep Rep.CPU - UPDATE history: 2023-03-31 23:35:46|SMA_Energymeter|SMAEM||diff_day_Einspeisung_Wirkleistung_Zaehler|0.2493|, RESULT: 1

Das resultierende SVG habe ich testweise erstellt wie im Anhang.

Hole dir bitte die DbRep Version aus meinem contrib.
Die Version ist noch nicht eingecheckt. Ich hatte wie weiter vorn schon geschrieben die Funktionalität von diffValue erweitert. Möglicherweise habe ich "nebenbei" mit der V einen Bug gefixt (glaube ich allerdings nicht  ;)  )

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: FHEM-User22 am 03 April 2023, 10:07:46
Hallo Heiko,

Zitat von: DS_Starter am 03 April 2023, 09:58:28set ... <Kommando> writeToDB

welches Kommando genau? Und nur einmal?

Grüße aus Grimma
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2023, 10:16:25
Zitatwelches Kommando genau? Und nur einmal?

Es gibt einige Kommandos wie maxValue, minValue, diffValue die die Option "writeToDB" anbieten.
Diese Option kannst du immer angeben wenn du es möchtest.
Gibt es noch keine Ergebniswerte in der DB wird ein Insert ausgeführt, anderenfalls erfolgt ein Update auf den existierenden Datensatz. Dadurch wird der Wert in der DB aktualisiert.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 03 April 2023, 21:48:40
Zitat von: DS_Starter am 03 April 2023, 10:05:19@Tomk,

ich habe dein Setup bei mir nachgestellt.
Wie schon geschrieben werden Diffs des Monats mit den Werte-Timestamp in die DB geschrieben:
...

Das resultierende SVG habe ich testweise erstellt wie im Anhang.

Hole dir bitte die DbRep Version aus meinem contrib.
Die Version ist noch nicht eingecheckt. Ich hatte wie weiter vorn schon geschrieben die Funktionalität von diffValue erweitert. Möglicherweise habe ich "nebenbei" mit der V einen Bug gefixt (glaube ich allerdings nicht  ;)  )

LG

vielleicht bin ich auch echt nur zu blöd... ich habe nochmal die Version aus dem Contrib aktualisiert. Aber ich denke das macht kein Unterschied. der Timestamp ist immernoch der gleiche (siehe Foto).
Aber wie hast du das SVG erzeugt... vielleicht mache ich hier einfach was falsch?

Bild_2023-04-03_214905374.png
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2023, 22:07:35
Ach ich glaube jetzt sehe ich es.
Du hast dir direkt die Readings des DbRep-Devices geloggt und versuchst die im SVG wiederzugeben.
Das ist nicht der Weg.

Zunächst setzt du

event-on-update-reading state
Das reicht, die Readings von DbRep muss man üblicherweise nicht loggen oder daraus Events erzeugen, es sei denn man macht es bewusst für die weitere Verarbeitung.

Dann führst du diffValue mit der Option writeToDB aus.

Es entstehen neue Readings in der Datenbank des ausgewerteten Devices, wie in meinem Beispiel:

Device: SMA_Energymeter , neues Reading: diff_day_Einspeisung_Wirkleistung_Zaehler

Diese Readings holst du dir in dein SVG-Device und kannst sie anzeigen.

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2023, 22:53:20
Ich habe soeben die neue DbRep Version eingecheckt.
diffValue kann mit diffAccept so eingestellt werden dass positive und negative Differenzen verarbeitet werden.

Weiterhin kann sqlCmd (sqlCmdBlocking) das Statement 'describe' verarbeiten.

LG,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 03 April 2023, 22:57:45
Zitat von: DS_Starter am 03 April 2023, 22:07:35Zunächst setzt du

event-on-update-reading state
Das reicht, die Readings von DbRep muss man üblicherweise nicht loggen oder daraus Events erzeugen, es sei denn man macht es bewusst für die weitere Verarbeitung.

Dann führst du diffValue mit der Option writeToDB aus.

Es entstehen neue Readings in der Datenbank des ausgewerteten Devices, wie in meinem Beispiel:

Device: SMA_Energymeter , neues Reading: diff_day_Einspeisung_Wirkleistung_Zaehler

Diese Readings holst du dir in dein SVG-Device und kannst sie anzeigen.



Ich hab's jetzt kapiert und hinbekommen... das ist ja noch genialer aus ich gedacht habe  :o

Vielen Dank, echt klasse das Modul!
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 03 April 2023, 23:10:28
Eine Frage doch noch: wenn ich die diff Werte für den aktuellen Monat berechnen lasse wird für die Tage in der Zukunft der letzte wert von heute übernommen. Soll das so sein?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 April 2023, 23:16:32
Nein, das soll so nicht sein.
Danke für den Hinweis. Dann kann ich gleich morgen einen Fix erstellen.
Bei "nur Anzeige" funktioniert es wie beabsichtigt.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 April 2023, 21:34:48
ZitatDanke für den Hinweis. Dann kann ich gleich morgen einen Fix erstellen.
Bei "nur Anzeige" funktioniert es wie beabsichtigt.

Habe es gefixt und eingecheckt.
Dadurch endet jetzt die Anzeige von diffValue-Ergebnissen auch am Endetimestamp.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 05 April 2023, 14:38:39
Hallo Heiko,

nach dem letzten aktuellen Update bekomme ich nach Update/Restart leider folgende "neue" LOG-Einträge:

93_DbRep.pm:v8.52.3-s27393/2023-04-04


2023.04.05 14:25:23 1: Including ./log/fhem.save
2023.04.05 14:25:25 2: netatmo: missing app refresh token!
2023.04.05 14:25:25 0: Featurelevel: 6.2
2023.04.05 14:25:25 0: Server started with 259 defined entities (fhem.pl:27302/2023-03-05 perl:5.032001 os:linux user:fhem pid:1455389)
2023.04.05 14:26:02 2: DbLog myDbLog - WARNING - "countNbl" is outdated. Please consider use of DbRep "set <Name> countEntries" instead.
2023.04.05 14:26:18 2: AttrTemplates: got 259 entries
2023.04.05 14:26:18 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.
2023.04.05 14:27:19 1: DbRep Rep.SB25.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10.4850000000006|2023-04-05_14:26:50';

2023.04.05 14:27:19 1: DbRep Rep.SMAEM.Einspeisung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.08279999999991|2023-04-05_14:26:49';

2023.04.05 14:27:20 1: DbRep Rep.SMAEM.Bezug.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|0.0515999999997803|2023-04-05_13:48:51';

2023.04.05 14:27:20 1: DbRep Rep.SBS25.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|1.73600000000005|2023-04-05_13:49:07';

2023.04.05 14:27:21 1: DbRep Rep.SBS25_2.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.27099999999973|2023-04-05_09:23:18';

2023.04.05 14:27:21 1: DbRep Rep.SBS25.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|8.54100000000017|2023-04-05_14:01:47';

2023.04.05 14:27:21 1: DbRep Rep.SBS25_2.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|5.36299999999983|2023-04-05_13:03:30';

2023.04.05 14:27:22 1: DbRep Rep.SB30.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|3.16100000000006|2023-04-05_14:26:50';

2023.04.05 14:27:22 1: DbRep Rep.SB40.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|6.98599999999999|2023-04-05_14:26:50';

2023.04.05 14:27:22 1: DbRep Rep.FCU.Erzeugung.heute - rh:
2023.04.05 14:29:19 1: DbRep Rep.SB25.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10.5|2023-04-05_14:28:51';

2023.04.05 14:29:19 1: DbRep Rep.SMAEM.Einspeisung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.17529999999988|2023-04-05_14:28:51';

2023.04.05 14:29:19 1: DbRep Rep.SMAEM.Bezug.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|0.0515999999997803|2023-04-05_13:48:51';

2023.04.05 14:29:20 1: DbRep Rep.SBS25.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|1.73600000000005|2023-04-05_13:49:07';

2023.04.05 14:29:20 1: DbRep Rep.SBS25_2.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.27099999999973|2023-04-05_09:23:18';

2023.04.05 14:29:20 1: DbRep Rep.SBS25.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|8.54100000000017|2023-04-05_14:01:47';

2023.04.05 14:29:20 1: DbRep Rep.SBS25_2.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|5.36299999999983|2023-04-05_13:03:30';

2023.04.05 14:29:20 1: DbRep Rep.SB30.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|3.20500000000038|2023-04-05_14:28:52';

2023.04.05 14:29:21 1: DbRep Rep.SB40.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|7.04500000000007|2023-04-05_14:28:52';

2023.04.05 14:29:21 1: DbRep Rep.FCU.Erzeugung.heute - rh:
2023.04.05 14:29:42 1: DbRep Rep.SB25.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10.5030000000006|2023-04-05_14:29:22';

2023.04.05 14:29:43 1: DbRep Rep.SMAEM.Einspeisung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.19859999999994|2023-04-05_14:29:21';

2023.04.05 14:29:43 1: DbRep Rep.SMAEM.Bezug.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|0.0515999999997803|2023-04-05_13:48:51';

2023.04.05 14:29:43 1: DbRep Rep.SBS25.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|1.73600000000005|2023-04-05_13:49:07';

2023.04.05 14:29:43 1: DbRep Rep.SBS25_2.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.27099999999973|2023-04-05_09:23:18';

2023.04.05 14:29:44 1: DbRep Rep.SBS25.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|8.54100000000017|2023-04-05_14:01:47';

2023.04.05 14:29:44 1: DbRep Rep.SBS25_2.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|5.36299999999983|2023-04-05_13:03:30';

2023.04.05 14:29:44 1: DbRep Rep.SB30.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|3.2170000000001|2023-04-05_14:29:22';

2023.04.05 14:29:44 1: DbRep Rep.SB40.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|7.06000000000006|2023-04-05_14:29:22';

2023.04.05 14:29:44 1: DbRep Rep.FCU.Erzeugung.heute - rh:
2023.04.05 14:30:26 1: DbRep Rep.SB25.Erzeugung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|318.116999999998|2023-04-05_14:29:52';

2023.04.05 14:30:27 1: DbRep Rep.SB25.Erzeugung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10470.471|2023-04-05_14:29:52';

2023.04.05 14:30:48 1: DbRep Rep.SMAEM.Einspeisung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|182.1125|2023-04-05_14:29:52';

2023.04.05 14:30:55 1: DbRep Rep.SMAEM.Einspeisung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|6881.72790001501|2023-04-05_14:30:22';

2023.04.05 14:31:11 1: DbRep Rep.SMAEM.Bezug.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|102.8576|2023-04-05_13:48:51';

2023.04.05 14:31:17 1: DbRep Rep.SBS25.Ladung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|306.058999999999|2023-04-05_13:49:07';

2023.04.05 14:31:18 1: DbRep Rep.SMAEM.Bezug.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10568.2338999784|2023-04-05_13:48:51';

2023.04.05 14:31:19 1: DbRep Rep.SB25.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10.5159999999996|2023-04-05_14:30:53';

2023.04.05 14:31:19 1: DbRep Rep.SMAEM.Einspeisung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.26829999999995|2023-04-05_14:30:52';

2023.04.05 14:31:20 1: DbRep Rep.SMAEM.Bezug.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|0.0515999999997803|2023-04-05_13:48:51';

2023.04.05 14:31:20 1: DbRep Rep.SBS25.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|1.73600000000005|2023-04-05_13:49:07';

2023.04.05 14:31:20 1: DbRep Rep.SBS25_2.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.27099999999973|2023-04-05_09:23:18';

2023.04.05 14:31:20 1: DbRep Rep.SBS25.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|8.54100000000017|2023-04-05_14:01:47';

2023.04.05 14:31:21 1: DbRep Rep.SBS25_2.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|5.36299999999983|2023-04-05_13:03:30';

2023.04.05 14:31:21 1: DbRep Rep.SB30.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|3.25|2023-04-05_14:30:53';

2023.04.05 14:31:21 1: DbRep Rep.SB40.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|7.10500000000002|2023-04-05_14:30:53';

2023.04.05 14:31:21 1: DbRep Rep.FCU.Erzeugung.heute - rh:
2023.04.05 14:31:24 1: DbRep Rep.SBS25_2.Ladung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|318.758|2023-04-05_09:23:18';

2023.04.05 14:31:26 1: DbRep Rep.SBS25.Ladung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4274.5320000085|2023-04-05_13:49:07';

2023.04.05 14:31:32 1: DbRep Rep.SBS25_2.Ladung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|2222.594|2023-04-05_09:23:18';

2023.04.05 14:31:34 1: DbRep Rep.SBS25.Entladung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|443.462|2023-04-05_14:01:47';

2023.04.05 14:31:43 1: DbRep Rep.SBS25.Entladung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|6017.462|2023-04-05_14:01:47';

2023.04.05 14:31:45 1: DbRep Rep.SBS25_2.Entladung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|467.712|2023-04-05_13:03:30';

2023.04.05 14:31:52 1: DbRep Rep.SB30.Erzeugung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|238.442|2023-04-05_14:31:24';

2023.04.05 14:31:55 1: DbRep Rep.SBS25_2.Entladung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|3199.752|2023-04-05_13:03:30';

2023.04.05 14:31:59 1: DbRep Rep.SB40.Erzeugung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|450.263|2023-04-05_14:31:24';

2023.04.05 14:32:00 1: DbRep Rep.FCU.Erzeugung.Jahr - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|1090|2023-04-01_10:00:34';

2023.04.05 14:32:00 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/93_DbRep.pm line 4784.
2023.04.05 14:32:02 1: DbRep Rep.SB30.Erzeugung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|2730.938|2023-04-05_14:31:24';

2023.04.05 14:32:09 1: DbRep Rep.SB40.Erzeugung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|550.892|2023-04-05_14:31:54';

2023.04.05 14:32:10 1: DbRep Rep.FCU.Erzeugung.Gesamt - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|23663|2023-04-01_10:00:34';

2023.04.05 14:33:19 1: DbRep Rep.SB25.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|10.5320000000011|2023-04-05_14:32:54';

2023.04.05 14:33:19 1: DbRep Rep.SMAEM.Einspeisung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.36099999999988|2023-04-05_14:32:54';

2023.04.05 14:33:20 1: DbRep Rep.SMAEM.Bezug.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|0.0515999999997803|2023-04-05_13:48:51';

2023.04.05 14:33:20 1: DbRep Rep.SBS25.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|1.73600000000005|2023-04-05_13:49:07';

2023.04.05 14:33:20 1: DbRep Rep.SBS25_2.Ladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|4.27099999999973|2023-04-05_09:23:18';

2023.04.05 14:33:20 1: DbRep Rep.SBS25.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|8.54100000000017|2023-04-05_14:01:47';

2023.04.05 14:33:20 1: DbRep Rep.SBS25_2.Entladung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|5.36299999999983|2023-04-05_13:03:30';

2023.04.05 14:33:21 1: DbRep Rep.SB30.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|3.29200000000037|2023-04-05_14:32:55';

2023.04.05 14:33:21 1: DbRep Rep.SB40.Erzeugung.heute - rh: $VAR1 = 'no_aggregation';
$VAR2 = 'no_aggregation|7.16800000000001|2023-04-05_14:32:55';

2023.04.05 14:33:21 1: DbRep Rep.FCU.Erzeugung.heute - rh:




etc. usw



Gruß
300P
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 05 April 2023, 15:00:12
Hi,

ja, sorry.
Da habe ich gestern eine "Entwicklungsversion" eingecheckt. (Man, man ...  :o )
DbRep habe ich schon geradegezogen und eingecheckt. Du kannst aber vorab diese V aus meinem contrib ziehen damit der Log-Terror aufhört.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 05 April 2023, 15:15:54
Danke fürs schnelle reagieren.....
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 09 April 2023, 06:13:49
Moin und frohe Ostern zusammen.

Ich versuche die Funktion diffValue täglich mittels "at" in die db schrieben zu lassen.

Der befehl wird ausgeführt aber nur das Reading aktualisiert, nicht der db Eintrag. Das "writeToDB" funktioniert so scheinbar nicht. Was mache ich falsch?

defmod CalcDailyPvProd at *04:00:00 set Rep.Pv.lm.daily diffValue wirteToDB
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: HeikoGr am 09 April 2023, 08:16:57
defmod CalcDailyPvProd at *04:00:00 set Rep.Pv.lm.daily diffValue wirteToDB

Du hast einen Buchstabendreher
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Tomk am 09 April 2023, 17:23:50
Och nö... vielen Dank! Und sorry für die Frage...
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 10 April 2023, 17:01:32
Hallo Heiko,

irgendwie hab ich seit dem letzten Update einen Wurm in meinen diversen REP.<gerät>.<art>.<zeitraum> -Abfragen, die schon mehrere Jahre anstandslos funktionierten.
(Betrifft hier die diffValue Funktion - egal ob mit oder ohne Nutzung <writeToDB>)

Mein Problem:
Wenn es keinen Anfangs- und keinen Endwert gibt, bekam ich bislang "0" als Ergebnis statt einer x-beliebigen Zahl und alles war okay..... :)

Kein Werte kann aber leider schon vorkommen, da manche Daten zu dem Zeitpunkt gar nicht da sein können oder evtl. keine Wertveränderung in dem Zeitraum anfiel....oder ...weil neues Gerät oder Gerät nicht mehr vorhanden (weitere PV-Anlage erst ab ab oder nur bis JJJJ/MM/TT)  o. ä.  :o

Nun bekommen ich "" (wahrscheinlich leer / garnix) neuerdings als Antwort und das weitere Reporting der Statistiken wird in Folge daher irgendwie ab diesem Punkt abgebrochen weil kein Wert geschrieben wird.

Ich hab aber noch nicht gefunden warum und wieso das seit dem Update  so ist. :o
Die alten vorhergehenden Werte in meinen Statistiken bleiben einfach weiter bestehen.
Könnte es evtl. jetzt eine "andere" Reaktion beim UserExit hervorrufen oder was damit zu tuen haben ??

Internals:
   DATABASE   fhem
   DEF        myDbLog
   FUUID      621a8eb7-f33f-1da7-ce39-7d94f330866ad63d
   FVERSION   93_DbRep.pm:v8.52.3-s27396/2023-04-05
   LASTCMD    diffValue writeToDB
   MODEL      Client
   NAME       Rep.FCU.Erzeugung.heute
   NOTIFYDEV  global,Rep.FCU.Erzeugung.heute
   NR         316
   NTFY_ORDER 50-Rep.FCU.Erzeugung.heute
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   eventCount 358
   HELPER:
     DBLOGDEVICE myDbLog
     GRANTS     ALL PRIVILEGES
     IDRETRIES  2
     MINTS      1996-03-08 17:23:29
     PACKAGE    main
     VERSION    8.52.3
     CV:
       aggregation no
       aggsec     1
       destr      2023-04-10
       dsstr      2023-04-10
       epoch_seconds_end 1681163999
       mestr      04
       msstr      04
       testr      23:59:59
       tsstr      00:00:00
       wdadd      604800
       yestr      2023
       ysstr      2023
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1681137712.95432
           VALUE      done
   OLDREADINGS:
   READINGS:
     2023-04-10 16:41:52   background_processing_time 0.0150
     2023-04-10 16:41:52   db_lines_processed 0
     2023-04-10 16:41:52   sql_processing_time 0.0025
     2023-04-10 16:41:52   state           done
Attributes:
   aggregation no
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     FCU
   diffAccept 20
   disable    0
   event-on-update-reading state
   group      Energy Meter Auswertung
   reading    FCU_Erzeugung_akt_Zaehlerstand
   room       Energie
   showproctime 1
   timeout    180
   timestamp_begin current_day_begin
   timestamp_end current_day_end
   userExitFn setDumEnergy .*:.*
   verbose    2


Hier die letzten Einträge des Gerätes in der Datenbank
(DB-Einträge erfolgen nur wenn eine Veränderung des Wertes erfolgt)


2023-04-07 19:42:17    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23679    FCU_Erzeugung_akt_Zaehlerstand    23679    NULL
2023-04-07 18:22:12    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23678    FCU_Erzeugung_akt_Zaehlerstand    23678    NULL
2023-04-07 17:02:14    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23677    FCU_Erzeugung_akt_Zaehlerstand    23677    NULL
2023-04-07 15:47:13    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23676    FCU_Erzeugung_akt_Zaehlerstand    23676    NULL
2023-04-07 14:27:15    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23675    FCU_Erzeugung_akt_Zaehlerstand    23675    NULL
2023-04-07 13:12:13    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23674    FCU_Erzeugung_akt_Zaehlerstand    23674    NULL
2023-04-07 11:52:14    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23673    FCU_Erzeugung_akt_Zaehlerstand    23673    NULL
2023-04-07 10:37:10    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23672    FCU_Erzeugung_akt_Zaehlerstand    23672    NULL
2023-04-07 07:14:41    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23671    FCU_Erzeugung_akt_Zaehlerstand    23671    NULL
2023-04-07 05:54:38    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23670    FCU_Erzeugung_akt_Zaehlerstand    23670    NULL
2023-04-07 04:34:39    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23669    FCU_Erzeugung_akt_Zaehlerstand    23669    NULL
2023-04-07 03:19:38    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23668    FCU_Erzeugung_akt_Zaehlerstand    23668    NULL
2023-04-07 01:59:41    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23667    FCU_Erzeugung_akt_Zaehlerstand    23667    NULL
2023-04-07 00:44:40    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23666    FCU_Erzeugung_akt_Zaehlerstand    23666    NULL
2023-04-06 23:24:39    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23665    FCU_Erzeugung_akt_Zaehlerstand    23665    NULL
2023-04-01 10:00:34    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23664    FCU_Erzeugung_akt_Zaehlerstand    23664    NULL
2023-04-01 08:44:44    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23663    FCU_Erzeugung_akt_Zaehlerstand    23663    NULL
2023-04-01 07:24:44    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23662    FCU_Erzeugung_akt_Zaehlerstand    23662    NULL
2023-04-01 06:09:43    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23661    FCU_Erzeugung_akt_Zaehlerstand    23661    NULL
2023-04-01 04:54:46    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23660    FCU_Erzeugung_akt_Zaehlerstand    23660    NULL
2023-04-01 03:34:43    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23659    FCU_Erzeugung_akt_Zaehlerstand    23659    NULL
2023-04-01 02:14:46    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23658    FCU_Erzeugung_akt_Zaehlerstand    23658    NULL
2023-04-01 00:59:42    FCU    VCONTROL300    FCU_Erzeugung_akt_Zaehlerstand: 23657    FCU_Erzeugung_akt_Zaehlerstand    23657    NULL



Gruß
300P


EDIT: DB-Einträge und Text ergänzt
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 April 2023, 18:16:08
Ja das stimmt. Man bekommt nichts zurück wenn in dem betreffenden Auswertungszeitraum keine (auswertbaren) Werte vorhanden sind.
Darauf kann man wahrscheinlich in der Funktion setDumEnergy reagieren.
Wie sieht die bei dir aus ?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 10 April 2023, 18:55:00
A:

Hab nochmals eine alte Version aus Februar installiert.
Dann ist alles i.o. bei gleichen REP.xxxxx - Aufrufen.
Als zusätzliches Reading gibt es da das alte bekannte:


2023-04-10__FCU__FCU_Erzeugung_akt_Zaehlerstand__DIFF__no_aggregation     -     2023-04-10 18:45:30



B:
Zitat von: DS_Starter am 10 April 2023, 18:16:08Ja das stimmt. Man bekommt nichts zurück wenn in dem betreffenden Auswertungszeitraum keine (auswertbaren) Werte vorhanden sind.
Darauf kann man wahrscheinlich in der Funktion setDumEnergy reagieren.
Wie sieht die bei dir aus ?


und so in der 99_myUtils.pm:



 if ($name =~ m/Rep.*heute/) {
    # Werte aktueller Tag
    if ($reading =~ m/SB25__etotal__DIFF/) {
      # Erzeugung aktueller Tag
      CommandSetReading(undef, "Dum.Energy PVDay ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report Einspeisung aktueller Tag
      CommandSet(undef,"Rep.SMAEM.Einspeisung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 1 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF/) {
      # Einspeisung aktueller Tag
      CommandSetReading(undef, "Dum.Energy GridFeedInDay ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report Bezug aktueller Tag
      CommandSet(undef,"Rep.SMAEM.Bezug.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 2 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SMA_Energymeter__Bezug_Wirkleistung_Zaehler__DIFF/) {
      # Bezug aktueller Tag
      CommandSetReading(undef, "Dum.Energy GridConsumptionDay ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report Ladung aktueller Tag
      CommandSet(undef,"Rep.SBS25.Ladung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 3 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SBS25__etotal__DIFF/) {
      # Ladung aktueller Tag
      CommandSetReading(undef, "Dum.Energy BattLoadInDay ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report SBS25_2Entladung aus Batterie Tag
      CommandSet(undef,"Rep.SBS25_2.Ladung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 4 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SBS25_2__etotal__DIFF/) {
      # Ladung aktueller Tag
      CommandSetReading(undef, "Dum.Energy BattLoadInDay_2 ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report SBS25Entladung aus Batterie Tag
      CommandSet(undef,"Rep.SBS25.Entladung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 5 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SBS25__bat_loadtotal__DIFF/) {
      # Entladung aktuelles Tag
      CommandSetReading(undef, "Dum.Energy BattLoadOutDay ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report SBS25_2Entladung aus Batterie Tag
      CommandSet(undef,"Rep.SBS25_2.Entladung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 6 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SBS25_2__bat_loadtotal__DIFF/) {
      # Entladung aktuelles Tag
      CommandSetReading(undef, "Dum.Energy BattLoadOutDay_2 ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report FCUErzeugung heute
      CommandSet(undef,"Rep.SB30.Erzeugung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 7 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SB30__etotal__DIFF/) {
      # Erzeugung aktueller Tag
      CommandSetReading(undef, "Dum.Energy PVDay_2 ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report Einspeisung aktueller Tag
      CommandSet(undef,"Rep.SB40.Erzeugung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 8 Dum.Energy heute = $value";
   }
   if ($reading =~ m/SB40__etotal__DIFF/) {
      # Erzeugung aktueller Tag
      CommandSetReading(undef, "Dum.Energy PVDay_40 ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));
      # starten Report Einspeisung aktueller Tag
      CommandSet(undef,"Rep.FCU.Erzeugung.heute diffValue writeToDB");
      Log3 $name, 1, "$name - 9 Dum.Energy heute = $value";

   }

   if ($reading =~ m/FCU_Erzeugung_akt_Zaehlerstand__DIFF/) {
     # Erzeugung FCU aktueller Tag
      Log3 $name, 1, "$name - 10 Dum.Energy FCUDay = $value";
      CommandSetReading(undef, "Dum.Energy FCUDay ".(looks_like_number($value)?sprintf('%.1f',$value):0.0));

# Eigenverbrauchsquote aktueller Tag / Vortag
     my $pvday     = ReadingsVal("Dum.Energy", "PVDay", 0);
     my $pvday_2   = ReadingsVal("Dum.Energy", "PVDay_2", 0);
     my $pvday_40  = ReadingsVal("Dum.Energy", "PVDay_40", 0);
     my $fcuday    = ReadingsVal("Dum.Energy", "FCUDay", 0);
     my $feedinday = ReadingsVal("Dum.Energy", "GridFeedInDay", 0);
     my $sqday     = ($fcuday + $pvday + $pvday_2 + $pvday_40 - $feedinday) / ($fcuday + $pvday + $pvday_2 + $pvday_40) * 100 if(($fcuday + $pvday + $pvday_2 + $pvday_40) > 0);
     CommandSetReading(undef, "Dum.Energy SelfConsumptionQuoteDay ".sprintf('%.0f',$sqday)) if($sqday);

     # Autarkiequote aktueller Tag / Vortag
     my $consumday = ReadingsVal("Dum.Energy", "GridConsumptionDay", 0);
     my $aqday     = ($fcuday + $pvday + $pvday_2 + $pvday_40 - $feedinday) / ($fcuday + $pvday + $pvday_2 + $pvday_40 - $feedinday + $consumday) * 100 if(($fcuday + $pvday + $pvday_2 + $pvday_40 ) > 0);
     CommandSetReading(undef, "Dum.Energy AutarkyQuoteDay ".sprintf('%.0f',$aqday)) if ($aqday);

# Verbrauch aktueller Tag / Vortag
my $tcday = $fcuday + $pvday + $pvday_2 + $pvday_40 - $feedinday + $consumday;
CommandSetReading(undef, "Dum.Energy TotalConsumptionDay ".sprintf('%.1f',$tcday)) if ($tcday);
     
   }
 }

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 April 2023, 21:12:33
@300P,

ich habe dir eine Version zum Test in mein contrib geladen.
Die V sollte sowohl die Vorteile des letzten Change von diffValue bewahren als auch dein Problem beheben.
Teste sie mal bitte. Auch mit writeToDB.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 10 April 2023, 21:27:16
Habs "mal eben eingespielt" und getestet......

DANKE! 8)

Das Reading mit dem "-" wird wieder wie vorher bei den Aufrufen zurückgegeben bzw. erzeugt.

2023-04-10__FCU__FCU_Erzeugung_akt_Zaehlerstand__DIFF__2023-04-10             -  2023-04-10 21:22:38
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 10 April 2023, 21:32:54
Danke  :)
Habe die V eingecheckt. Morgen früh im Update.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 10 April 2023, 22:31:27
Zitat von: DS_Starter am 10 April 2023, 21:12:33@300P,

ich habe dir eine Version zum Test in mein contrib geladen.
Die V sollte sowohl die Vorteile des letzten Change von diffValue bewahren als auch dein Problem beheben.
Teste sie mal bitte. Auch mit writeToDB.

LG

Nachsatz:
Es klappt auch ohne die Option "writeToDB"

Nachsatz II:
M.E. kann man ab jetzt am Reading erkennen ob Datensätze vorhanden sind oder nicht

Datensätze sind GARNICHT vorhanden.
(Datum wird am Readingnamenende eingefügt und ein "-" wird als Ergebnis gezeigt)

2023-04-11__FCU__FCU_Erzeugung_akt_Zaehlerstand__DIFF__2023-04-11       -      2023-04-11 09:10:22
oder
2017-06-13__SB40__etotal__DIFF__2017-06-13       -           2023-04-11 00:15:02

Datensätze sind genügend VORHANDEN
(alles okay)

2018-09-03_23-59-59__FCU__FCU_Erzeugung_akt_Zaehlerstand__DIFF__no_aggregation   4915.0000       2023-04-11 00:15:02



Gruß
300P
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Christian83 am 16 April 2023, 08:35:40
Hallo,

bei mir ist nun das Problem, dass bei nur einem vorhandenem Wert (Zählerstand hat sich im Zeitraum nicht verändert) die Warnung "less_data..." im State steht. Da ich auf State "done" prüfe geht nichts mehr weiter.
Das war bisher nicht so. Da gab es die Fehlermeldung nicht und das Ergebnis war einfach 0.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: 300P am 16 April 2023, 10:07:12
Hallo Christian83,

um welche Zeiträume ohne Werte geht es denn ?

Eventuell hilft dir da schon der Einsatz / Nutzung des Attributes "event-min-interval" im zugehörigen Zähler-Device
->>>  z.B. "attr <Devicename> event-min-interval <Zählerstandname>:300" für spätestens 5 Minuten nach dem letzten Wert den aktuellen Wert wieder schreiben.

Aber der Zeitraum muss je nach deiner Auswertungshäufigkeit gewählt werden. Ansonsten kann es ja bis unendlich dauern ehe von dort ein neuer Wert kommt. ;)

Gruß
GW
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 April 2023, 10:17:30
Hallo,

Zitatbei mir ist nun das Problem, dass bei nur einem vorhandenem Wert (Zählerstand hat sich im Zeitraum nicht verändert) die Warnung "less_data..." im State steht. Da ich auf State "done" prüfe geht nichts mehr weiter.

Das ist ein einigen Fällen bei mir nun auch so. Ich habe dafür die state-Prüfung erweitert, dann klappt es wieder wie es soll:

if ($READING eq 'state' && $VALUE =~ /done|WARNING/xs) {
}
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Christian83 am 18 April 2023, 08:15:23
Zitat von: 300P am 16 April 2023, 10:07:12Hallo Christian83,

um welche Zeiträume ohne Werte geht es denn ?

Eventuell hilft dir da schon der Einsatz / Nutzung des Attributes "event-min-interval" im zugehörigen Zähler-Device
->>>  z.B. "attr <Devicename> event-min-interval <Zählerstandname>:300" für spätestens 5 Minuten nach dem letzten Wert den aktuellen Wert wieder schreiben.

Aber der Zeitraum muss je nach deiner Auswertungshäufigkeit gewählt werden. Ansonsten kann es ja bis unendlich dauern ehe von dort ein neuer Wert kommt. ;)

Gruß
GW

Es geht um den Stromzählerstand der eingespeisten Menge. Die ist ja bis zum nächsten Einspeisen, was irgendwann am Nachmittag sein kann 0 bzw. keine Änderung. Da jetzt aller 5 Minuten einen Wert in die DB zu schreiben ist für die Datenmenge nicht förderlich.
Zumal es ja vorher ging.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Christian83 am 18 April 2023, 08:18:56
Zitat von: DS_Starter am 16 April 2023, 10:17:30Hallo,

Das ist ein einigen Fällen bei mir nun auch so. Ich habe dafür die state-Prüfung erweitert, dann klappt es wieder wie es soll:

if ($READING eq 'state' && $VALUE =~ /done|WARNING/xs) {
}

Super danke. Jetzt geht es wieder.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dk3572 am 24 April 2023, 06:36:47
Hallo Heiko,

ich erhalte morgens von Rep.STP5000.Erzeugung.heute folgende Warnung:

WARNING - see readings 'less_data_in_period' or 'diff_overrun_limit_XX'
     2023-04-24 06:13:18   2023-04-24_00-00-04__SMA_Wechselrichter__etoday__DIFF__no_aggregation 0.0000
     2023-04-24 06:13:18   background_processing_time 0.0084
     2023-04-24 06:13:18   less_data_in_period no_aggregation ||
     2023-04-24 06:13:18   sql_processing_time 0.0018
     2023-04-24 06:13:18   state           WARNING - see readings 'less_data_in_period' or 'diff_overrun_limit_XX'

Hast du eine Idee wie ich die los werde?

Danke und VG
Dieter
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 April 2023, 10:27:53
Morgen Dieter,

entweder die Auswertung in einen Zeitraum verschieben in dem genügend Daten zu erwarten sind oder die Warnung im state ignorieren.
Ist ja nur eine Warnung bzw. Information über den festgestellten Sachverhalt dass keine Daten zur Auswertung.

Auszug aus der Commandref:

ZitatIm Auswertungs- bzw. Aggregationszeitraum (Tag, Woche, Monat, etc.) sollten dem Modul pro Periode mindestens ein
       Datensatz zu Beginn und ein Datensatz gegen Ende des Aggregationszeitraumes zur Verfügung stehen um eine möglichst
       genaue Auswertung der Differenzwerte vornehmen zu können. <br>
       
       Wird in einer auszuwertenden Zeit- bzw. Aggregationsperiode nur ein Datensatz gefunden, kann die Differenz in
       Verbindung mit dem Differenzübertrag der Vorperiode berechnet werden. in diesem Fall kann es zu einer logischen
       Ungenauigkeit in der Zuordnung der Differenz zu der Aggregationsperiode kommen. In diesem Fall wird eine Warnung
       im state ausgegeben und das Reading <b>less_data_in_period</b> mit einer Liste der betroffenen Perioden erzeugt.

LG,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Christian83 am 24 April 2023, 10:37:45
Zitat von: DS_Starter am 24 April 2023, 10:27:53Morgen Dieter,

entweder die Auswertung in einen Zeitraum verschieben in dem genügend Daten zu erwarten sind oder die Warnung im state ignorieren.
Ist ja nur eine Warnung bzw. Information über den festgestellten Sachverhalt dass keine Daten zur Auswertung.

Auszug aus der Commandref:

ZitatIm Auswertungs- bzw. Aggregationszeitraum (Tag, Woche, Monat, etc.) sollten dem Modul pro Periode mindestens ein
       Datensatz zu Beginn und ein Datensatz gegen Ende des Aggregationszeitraumes zur Verfügung stehen um eine möglichst
       genaue Auswertung der Differenzwerte vornehmen zu können. <br>
       
       Wird in einer auszuwertenden Zeit- bzw. Aggregationsperiode nur ein Datensatz gefunden, kann die Differenz in
       Verbindung mit dem Differenzübertrag der Vorperiode berechnet werden. in diesem Fall kann es zu einer logischen
       Ungenauigkeit in der Zuordnung der Differenz zu der Aggregationsperiode kommen. In diesem Fall wird eine Warnung
       im state ausgegeben und das Reading <b>less_data_in_period</b> mit einer Liste der betroffenen Perioden erzeugt.

LG,
Heiko

Hallo,

ist das neu? Das war bis vor einiger Zeit nämlich kein Problem bzw. gab es da kein WARNING im state.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 April 2023, 22:00:41
Nein, das ist nicht neu. Aber es ist durchaus möglich, dass im Zuge von Bugfixing ein Fehler beseitigt wurde der die Anzeige dieser Warnung bisher verhindert hat obwohl die Warnung hätte angezeigt werden müssen.
Ich hoffe das war jetzt nicht verwirrend  ;)
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 April 2023, 12:10:08
Hallo zusammen,

ich suche noch immer eine Möglichkeit das DbRep mit sqlCmd zyklisch auszuführen.
Das Problem ist z.B. dass meine SQL Aufrufe sehr lang sind und dies aus einem DOIF ziemlich unübersichtlich ist.
Weiterhin habe ich ein SQL Kommando, das über das Device mit "set <Device> sqlCmd aus dem FHEMWeb problemlos startet, jedoch über den aufruf einen SQL Error bringt.

Im DOIF FHEM Modus wird folgendes Aufgerufen, was im DbRep genau so läuft und auch in der FHEMWEB Kommandozeile.
(set LogDBRep_Statistic_previous_Month sqlCmd SELECT * FROM (SELECT h.TIMESTAMP, CONCAT('WB_0_', h.READING) AS READING, h.VALUE FROM history h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING = 'Kia_eNiro_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x1 USING(TIMESTAMP,READING)) x UNION ALL SELECT h.TIMESTAMP, CONCAT('WB_0_', h.READING) AS READING, h.VALUE FROM history AS h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING = 'Gast_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x2 USING(TIMESTAMP,READING) UNION ALL SELECT h.TIMESTAMP, CONCAT('WB_1_', h.READING) AS READING, h.VALUE FROM history h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_1' AND READING LIKE 'lp_%_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x3 USING(TIMESTAMP,READING) UNION ALL SELECT max(TIMESTAMP) AS TIMESTAMP, 'EVU_Tibber_Pulse_nodes_consumption_Month' AS READING, cast(sum(VALUE) AS DECIMAL(10,0)) AS VALUE FROM history WHERE DEVICE='EVU_Tibber_Pulse' AND READING='nodes_consumption' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') ;)

Als Meldung kommt dann
SQL_Format Normal! 2023-04-28 12:06:00
errortext DBD::mysql::st execute failed: Unknown table 'h' in field list at ./FHEM/93_DbRep.pm line 11623. 2023-04-28 12:05:49

sqlCmd
SELECT * FROM (SELECT h.TIMESTAMP, CONCAT('WB_0_', h.READING) AS READING, h.VALUE FROM history h JOIN (SELECT max(TIMESTAMP) AS TIMESTAMP, READING FROM history WHERE DEVICE = 'WB_0' AND READING = 'Kia_eNiro_kWhCounter_Month' AND TIMESTAMP > DATE_FORMAT(NOW() - INTERVAL 1 MONTH, '%Y-%m-01 00:00:00') AND TIMESTAMP < DATE_FORMAT(LAST_DAY(NOW() - INTERVAL 1 MONTH), '%Y-%m-%d 23:59:59') GROUP BY READING) x1 USING(TIMESTAMP,READING)) x UNION ALL SELECT h.TIMESTAMP;
2023-04-28 12:05:49

state error 2023-04-28 12:05:49

VG  Christian
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 April 2023, 14:55:37
Hallo Christian,

die Frage bzgl. dem DOIF kann ich  dir nicht beantworten, setze DOIF nicht ein.

Aber du könntest dir dein langes Statement in der sqlcmd History speichern (Attr sqlCmdHistoryLength).
Wenn es dort gespeichert wurde, kannst du es immer wieder mit einem Index-Key neu ausführen lassen,
z.B.

   set ... sqlCmd ckey:1

Das ist in der Hilfe zu sqlCmd beschrieben.
Vllt. hilft dir das ?

Edit: mit verbose 4 müsstest du das SQL-Kommando im Log sehen welches vom DOIF übergeben wird kurz bevor der Error im Log steht.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 28 April 2023, 16:32:31
Zitat von: DS_Starter am 28 April 2023, 14:55:37Aber du könntest dir dein langes Statement in der sqlcmd History speichern (Attr sqlCmdHistoryLength).
Wenn es dort gespeichert wurde, kannst du es immer wieder mit einem Index-Key neu ausführen lassen,
z.B.
   set ... sqlCmd ckey:1

Das ist in der Hilfe zu sqlCmd beschrieben.
Vllt. hilft dir das ?
Okay, genau das hatte ich gesucht.

EDIT:
Die sqlCmdHistory wurde bei mir nur gesetzt, wenn man es mit "set <Device> sqlCmd SELECT...." auf der FHEM Kommandozeile aufgerufen hat.
Die Zählung hat jedoch nicht bei ckey:1 begonnen, sondern bei einem Device bei 2 und bei einem anderen bei 5.
Nach einem ___purge_sqlhistory___ und erneutem set ging es dann bei 1 los.
Mit dem set <Device> sqlCmd aus dem Device heraus wurde nichts in der sqlCmdHistory gespeichert.

ZitatEdit: mit verbose 4 müsstest du das SQL-Kommando im Log sehen welches vom DOIF übergeben wird kurz bevor der Error im Log steht.
Das schau ich mir dann auch noch an.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 April 2023, 22:43:55
ZitatDie Zählung hat jedoch nicht bei ckey:1 begonnen, sondern bei einem Device bei 2 und bei einem anderen bei 5.
Nach einem ___purge_sqlhistory___ und erneutem set ging es dann bei 1 los.
Das ist normal.


ZitatMit dem set <Device> sqlCmd aus dem Device heraus wurde nichts in der sqlCmdHistory gespeichert.
Kann ich nicht glauben.  ;)
Funktioniert bei mir tadellos.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: ch.eick am 05 Mai 2023, 14:12:11
Zitat von: DS_Starter am 28 April 2023, 22:43:55
ZitatDie Zählung hat jedoch nicht bei ckey:1 begonnen, sondern bei einem Device bei 2 und bei einem anderen bei 5.
Nach einem ___purge_sqlhistory___ und erneutem set ging es dann bei 1 los.
Das ist normal.
Ich hatte damit gerechnet, wenn das Attribut neu definiert wird, dass es auch bei 0 oder 1 mit der Zählung beginnt.
Zitat
ZitatMit dem set <Device> sqlCmd aus dem Device heraus wurde nichts in der sqlCmdHistory gespeichert.
Kann ich nicht glauben.  ;)
Funktioniert bei mir tadellos.
Ich schau mir das beim nächsten DbRep nochmal genauer an, jetzt bin ich erstmal froh, dass es läuft und das rufende Device nicht mehr seitenweise MySQL beinhaltet.
Du kennst ja meine optimierten Abfragen :-) :-)
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 28 Juni 2023, 17:19:25
Hallo
Nach dem Update von Sonntag (mit DBLog und DBRep) ist bei einem DBRep-Device ein Attribut beim/nach dem Hochlauf gelöscht worden
=> "attr DBRep_avgtim_total_power executeAfterProc set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}"
Im Restore-Dir ist es noch enthalten  ???

Beim neu Anlegen erhalte ich die Fehlermeldung:
=> "syntax error at (eval 163764) line 1, near ""%" new""

Diese Meldung (PERL-Warning) ist auch im Log des Hochlaufs enthalten, war aber leider nicht direkt zuzuordnen:
2023.06.25 00:35:41.220 1: PERL WARNING: Bareword found where operator expected at (eval 256) line 1, near ""%" new"
2023.06.25 00:35:41.221 1: PERL WARNING: (Missing operator before new?)
2023.06.25 00:35:41.223 1: PERL WARNING: String found where operator expected at (eval 256) line 1, near "W")""
2023.06.25 00:35:41.223 3: syntax error at (eval 256) line 1, near ""%" new"

2023.06.25 00:35:41.898 1: Including ./log/fhem.save
2023.06.25 00:35:43.077 1: Messages collected while initializing FHEM:configfile: syntax error at (eval 256) line 1, near ""%" new"

1) ich überlege was an der Syntax falsch ist um das Attribut erneut zu konfigurieren
2) welches Modul -> DBRep selber oder fhem.pl? löscht die Zeile aus der fhem.cfg. Ein Hinweis im Log wäre hilfreich.

Gruß Ralf
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2023, 18:05:18
Hallo Ralf,

seit der letzte Version kann executeAfterProc Perl code ausführen.
Die Syntax prüfe ich im Modul.
Leider hat die Prüfung bei deinem Konstrukt ein "false positiv" gebracht.

Ich habe die Prüfung gefixt und die V 8.52.8 vorerst in mein contrib geladen damit du es schnell bei dir implementieren und testen kannst.
Wird dann noch zügig eingecheckt wenn ok.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 28 Juni 2023, 18:33:53
Danke ich hole es mir gleich und gebe eine Rückmeldung.

Das heisst, dass das Modul die Zeile aus der CFG löscht. Ist es möglich dafür auch bei niedrigem verbose-Level eine Log-Meldung zu bekommen?

Gruß Ralf
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2023, 18:42:07
Naja, das war etwas unglücklich.
Wenn du das gefixte Modul aktiv hast, wird dir direkt bei der Eingabe der Syntaxfehler angezeigt und das Attr
nicht gesetzt.
Andererseits wäre dir mit dem gefixten Modul kein Fehler gemeldet worden und das Attr auch nicht entfernt worden.

Das Löschen macht nicht das Modul. Das Attr konnte beim Restart wegen des "false positiv" durch FHEM nicht aktiviert werden und fiel so aus der cfg. Zumindest sofern man nach dem Restart "save" gedrückt hat, sonst nicht.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 28 Juni 2023, 19:01:16
Zitat von: DS_Starter am 28 Juni 2023, 18:42:07...
Das Löschen macht nicht das Modul. Das Attr konnte beim Restart wegen des "false positiv" durch FHEM nicht aktiviert werden und fiel so aus der cfg. Zumindest sofern man nach dem Restart "save" gedrückt hat, sonst nicht.
War mir nicht klar (kann ich mir hoffentlich merken  ::) )
Weiss leider nicht mehr ob ich ein save ausgeführt habe. Da aber in "/opt/fhem/restoreDir/save/2023-06-25" um 0:38 Uhr eine CFG liegt werde ich es wohl getan haben.
Da fällt man ggfs. allerdings schnell drauf rein, dass etwas beim Hochlauf nicht gesetzt wird und man "leichtfertig" eine save absetzt.



Habe die Datei in ./FHEM abgelegt und per "reload 93_DbRep.pm" neu geladen.
Das Attribut ist wieder gesetzt!  :)
"attr DBRep_avgtim_total_power executeAfterProc set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}"

Werde nachher noch ein Restart durchführen - ist sauberer und heute Nacht sehen ob die chain durchläuft.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 28 Juni 2023, 19:29:50
Wenn beim Start Fehler passieren schreibt FHEM zur Info für den User auf der Startseite ein "Autosave deactivated" oder ähnliches aus um mitzuteilen dass die Konfiguration wegen eines/des Fehlers nicht gesichert wurde.
Siehe das globale Attr autosave.

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 28 Juni 2023, 19:32:44
ja so:
You can disable this message with attr global motd none
Autosave deactivated
2023.06.25 00:35:43.158 3: Opening UartRpi device /dev/ttyAMA0
Danke für den Hinweis. Konnte ich nicht einordnen.

Edit:
Stimmt.
Attribut "autosave = 0". Ist aber offensichtlich (lt. Backups) schon länger so...  vielleicht hab ich es sogar selber so gesetzt um bewusst zu entscheiden ob etwas in die CFG kommt.

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 01 Juli 2023, 19:33:41
Zitat von: RalfRog am 28 Juni 2023, 19:01:16Werde nachher noch ein Restart durchführen - ist sauberer und heute Nacht sehen ob die chain durchläuft.

Alles gut.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 Juli 2023, 11:01:37
Danke für die Info Ralf ... ist eingecheckt.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 08 September 2023, 11:53:09
Hallo zusammen,

ich tue mir grad irgendwie schwer einen Ansatz zu schaffen und bräuchte mal einen Schubs in die richtige Richtung:

Ich habe seit diesem Jahr eine Balkonanlage wo ich mit den Werten immer mal wieder ein wenig rumgespielt habe. Was ist allerdings nicht beachtet habe: Meine aktuelle Auswertung zeigt mir gewisse Werte an die ich mir als einzelne Tage super anschauen kann. Der Gesamtwert wird zusammengerechnet und diesen sehe ich. Was mir fehlt ist eine Übersicht von Tageserträgen, Wochen / Monatzusammenfassung usw. Ich habe von der Anlage einzelne (steigende) Werte wieviel die Anlage zum jeweiligen Tageszeitpunkt gemacht hat, die in der DB gespeichert sind.

Gibt es eine "einfache" Möglichkeit, aus den vorhandenen Werten jeweils den Tageshöchstwert zu ermitteln (alles andere kann ja gelöscht werden) und daraus dann wiederum neue Readings zu generieren die dann Summ7days Summ30days heißen könnten oder oder? Oder denke ich hier zu kompliziert und es gibt einen anderen Weg?

Für zukünftige Tage könnte ich es lösen, indem ich jeweils an dem Tag / Sonntags und am 1 eines Monats die Erfassung machen würde, aber für die vergangenen Monate interessiert es mich.

Vielen dank im Voraus
VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: RalfRog am 08 September 2023, 13:53:07
Als Schubs fallen mir die set-Funktionen maxValue, diffValue und sumValue mit entsprechendem Aggregationszeitraum ein.

Damit hat es soweit ich erinnere schon Umsetzungen gegeben.

Ausserhalb der Datenbank wäre das statistics-Modul eine Möglichkeit.
Das Modul bereitet Stunden-, Tages-, Monats und Jahres-Summen auf.

Gruß Ralf


Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 September 2023, 21:30:57
ZitatGibt es eine "einfache" Möglichkeit, aus den vorhandenen Werten jeweils den Tageshöchstwert zu ermitteln (alles andere kann ja gelöscht werden) und daraus dann wiederum neue Readings zu generieren die dann Summ7days Summ30days heißen könnten oder oder? Oder denke ich hier zu kompliziert und es gibt einen anderen Weg?
Ich weiß nicht inwieweit du schon die richtigen Hinweise von Ralf verfolgt hast.
Ergänzend dazu gibt es im DbRep Befehle wie "maxValue writeToDB" welcher genau das macht was du oben beschreibst (aggregation=day).

Weiterhin habe ich mal vor langer Zeit im Wiki Auswertungsszenarios beschrieben: https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung

Vllt. hilft dir das weiter.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 18 September 2023, 09:40:29
Hey Ihr zwei,

@RalfRog: sorry, ich hab irgendwie eine Antwort an Dich geschrieben gehabt und sie scheinbar nicht abgeschickt. Dachte dann "OK da kommt erstmal nichts mehr" und dabei war ich das Problem .. sorry nochmal. War keine Absicht....

@DS_Starter: Ich hab es (für die jetzt kommenden Werte) genauso gelöst.  maxValue deleteOther löst das Ganze ab jetzt
SELECT `TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `UNIT`, MAX(CAST(`VALUE` AS UNSIGNED)) AS 'VALUE'
FROM `history`
WHERE `DEVICE` = 'Flummy_DTU' AND `READING` = 'YieldDay'
GROUP BY date( `TIMESTAMP` ) 
ORDER BY `history`.`TIMESTAMP`  DESC
als SQL Befehl hat es für die Vergangenheit gelöst. Die MaxWerte habe ich übernommen, alles andere gelöscht und somit passt es  :)

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Jewe am 14 Oktober 2023, 10:36:37
Moin,

habe versucht die SQLiteDB mit DBrep und exporttofile in eine csv datei zu exportieren. Diese möchte ich dann in Influx wieder einlesen. Die DB´s sind recht groß 14,2Mio Datensätze (5,2GB) und 5,2 Mio Datensätze (2,7GB).
DBRep startet und legt auch die CSV-Files an, dann stürzt Fhem ab startet neu. Die erstellte CSV-Dateien sind ca. 1,1 und 1,4GB groß.

Bin mir nicht sicher ob dieser Weg ein guter ist. Vmtl. geht das auch anders?
define Rep.impDbLog DbRep impDbLog
attr Rep.impDbLog DbLogExclude .*
attr Rep.impDbLog aggregation month
attr Rep.impDbLog devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.impDbLog dumpDirLocal ./log
attr Rep.impDbLog dumpFilesKeep 0
attr Rep.impDbLog event-on-update-reading state
attr Rep.impDbLog executeAfterProc set impDbLog reopen
attr Rep.impDbLog executeBeforeProc set impDbLog reopen 3600
attr Rep.impDbLog expimpfile /opt/fhem/expimpDbLog_%Y-%m-%d.csv
attr Rep.impDbLog optimizeTablesBeforeDump 1
attr Rep.impDbLog room DbLog
attr Rep.impDbLog showproctime 1
attr Rep.impDbLog verbose 3
#   DATABASE   /opt/fhem/important.db
#   DEF        impDbLog
#   FUUID      5c4cce27-f33f-9f49-19f3-51254aae6d47c978
#   FVERSION   93_DbRep.pm:v8.52.11-s27975/2023-09-17
#   LASTCMD    initial database connect stopped due to attribute 'fastStart'
#   MODEL      Client
#   NAME       Rep.impDbLog
#   NOTIFYDEV  global,Rep.impDbLog
#   NR         383
#   NTFY_ORDER 50-Rep.impDbLog
#   ROLE       Client
#   STATE      initialized
#   TYPE       DbRep
#   UTF8       0
#   HELPER:
#     DBLOGDEVICE impDbLog
#     IDRETRIES  3
#     PACKAGE    main
#     VERSION    8.52.11
#   READINGS:
#     2023-10-14 02:19:17   after_command_message Reopen executed.
#     2023-10-14 07:32:13   state           initialized
#
setstate Rep.impDbLog initialized
setstate Rep.impDbLog 2023-10-14 02:19:17 after_command_message Reopen executed.
setstate Rep.impDbLog 2023-10-14 07:32:13 state initialized


LOGFILE:
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - get initial structure information of database "/opt/fhem/important.db", remaining attempts: 3
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Connectiontest to database SQLite:dbname=/opt/fhem/important.db with user
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Index Report_Idx exists. Check ok
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Initial data information retrieved - total time used: 0.0102 seconds
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Connectiontest to db SQLite:dbname=/opt/fhem/important.db successful
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - execute command before exportToFile: 'set impDbLog reopen 3600'
2023.10.14 02:13:07 2: impDbLog - Connection closed until 03:13:07 (3600 seconds).
2023.10.14 02:13:08 3: impDbLog - Database disconnected by request.
2023.10.14 02:19:09 1: Server shutdown delayed due to myDbLog,alexa for max 10 sec
2023.10.14 02:19:15 1: [Freezemon] freezemon: possible freeze starting at 02:17:28, delay is 107.342 possibly caused by: tmr-CODE(0x55fcfa6d2bb8)(ResponseTimeout) tmr-CODE(0x55fcfa62c3c8)(ProcessRequestQueue) tmr-HM485_LAN_KeepAlive(HM485_LAN) tmr-DOIF_SleepTrigger(Heizung_HK2_Solltemperatur)
2023.10.14 02:19:16 3: alexa: stopped
2023.10.14 02:19:17 1: DbRep Rep.impDbLog -> BlockingCall DbRep_expfile pid:DEAD:84022 Process died prematurely
2023.10.14 02:19:17 3: DbRep Rep.impDbLog - execute command after command: 'set impDbLog reopen'
2023.10.14 02:19:17 3: impDbLog - Reopen requested
2023.10.14 02:19:17 2: DbRep Rep.impDbLog - command message after command: >Reopen executed.<
2023.10.14 02:19:17 2: DbRep Rep.impDbLog - Database command aborted: "Process died prematurely"
2023.10.14 02:19:17 0: Server shutdown


2023.10.14 07:27:18 3: DbRep Rep.myDbLog - get initial structure information of database "/opt/fhem/fhem.db", remaining attempts: 3
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Connectiontest to database SQLite:dbname=/opt/fhem/fhem.db with user
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Index Report_Idx exists. Check ok
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Initial data information retrieved - total time used: 0.0096 seconds
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - execute command before exportToFile: 'set myDbLog reopen 3600'
2023.10.14 07:32:02 2: impDbLog - Wait for last database cycle due to shutdown ...
2023.10.14 07:32:02 1: Server shutdown delayed due to alexa,impDbLog for max 10 sec
2023.10.14 07:32:03 2: impDbLog - Last database write cycle done
2023.10.14 07:32:03 1: DbRep Rep.myDbLog -> BlockingCall DbRep_expfile pid:DEAD:88816 Process died prematurely
2023.10.14 07:32:03 3: DbRep Rep.myDbLog - execute command after command: 'set myDbLog reopen'
2023.10.14 07:32:03 2: DbRep Rep.myDbLog - command message after command: >Reopen executed.<
2023.10.14 07:32:03 2: DbRep Rep.myDbLog - Database command aborted: "Process died prematurely"
2023.10.14 07:32:05 0: Server shutdown
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Oktober 2023, 11:10:03
Moin,

Fhem stürzt nicht ab soweit ich das sehe sondern wird regulär heruntergefahren:

Server shutdown delayed due ...
Wodurch kann ich nicht sehen.
Allerdings stirbt der parallel laufende DbRep Export. Ich bin mir unsicher ob es die Folgr von zb. zu wenig RAM ist oder die Folge des initiierten Shutdowns. Ich vermute aber letzteres.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Jewe am 14 Oktober 2023, 11:36:45
Danke, habe mich korrigiert.

2023.10.14 07:32:02 2: impDbLog - Wait for last database cycle due to shutdown ...
2023.10.14 07:32:02 1: Server shutdown delayed due to alexa,impDbLog for max 10 sec
2023.10.14 07:32:03 2: impDbLog - Last database write cycle done

Hier sieht es aber schon so auf, als ob es dblog kommt. Fhem läuft bei mir in einer Proxmox VM mit 6GB RAM, 4 Kerne, SSD hat genügend Platz.

Kann ich das auch anders machen ?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: wowogiengen am 14 Oktober 2023, 12:01:19
Zitat von: Jewe am 14 Oktober 2023, 10:36:37Moin,

habe versucht die SQLiteDB mit DBrep und exporttofile in eine csv datei zu exportieren. Diese möchte ich dann in Influx wieder einlesen. Die DB´s sind recht groß 14,2Mio Datensätze (5,2GB) und 5,2 Mio Datensätze (2,7GB).
DBRep startet und legt auch die CSV-Files an, dann stürzt Fhem ab startet neu. Die erstellte CSV-Dateien sind ca. 1,1 und 1,4GB groß.

Bin mir nicht sicher ob dieser Weg ein guter ist. Vmtl. geht das auch anders?
define Rep.impDbLog DbRep impDbLog
attr Rep.impDbLog DbLogExclude .*
attr Rep.impDbLog aggregation month
attr Rep.impDbLog devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.impDbLog dumpDirLocal ./log
attr Rep.impDbLog dumpFilesKeep 0
attr Rep.impDbLog event-on-update-reading state
attr Rep.impDbLog executeAfterProc set impDbLog reopen
attr Rep.impDbLog executeBeforeProc set impDbLog reopen 3600
attr Rep.impDbLog expimpfile /opt/fhem/expimpDbLog_%Y-%m-%d.csv
attr Rep.impDbLog optimizeTablesBeforeDump 1
attr Rep.impDbLog room DbLog
attr Rep.impDbLog showproctime 1
attr Rep.impDbLog verbose 3
#   DATABASE   /opt/fhem/important.db
#   DEF        impDbLog
#   FUUID      5c4cce27-f33f-9f49-19f3-51254aae6d47c978
#   FVERSION   93_DbRep.pm:v8.52.11-s27975/2023-09-17
#   LASTCMD    initial database connect stopped due to attribute 'fastStart'
#   MODEL      Client
#   NAME       Rep.impDbLog
#   NOTIFYDEV  global,Rep.impDbLog
#   NR         383
#   NTFY_ORDER 50-Rep.impDbLog
#   ROLE       Client
#   STATE      initialized
#   TYPE       DbRep
#   UTF8       0
#   HELPER:
#     DBLOGDEVICE impDbLog
#     IDRETRIES  3
#     PACKAGE    main
#     VERSION    8.52.11
#   READINGS:
#     2023-10-14 02:19:17   after_command_message Reopen executed.
#     2023-10-14 07:32:13   state           initialized
#
setstate Rep.impDbLog initialized
setstate Rep.impDbLog 2023-10-14 02:19:17 after_command_message Reopen executed.
setstate Rep.impDbLog 2023-10-14 07:32:13 state initialized


LOGFILE:
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - get initial structure information of database "/opt/fhem/important.db", remaining attempts: 3
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Connectiontest to database SQLite:dbname=/opt/fhem/important.db with user
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Index Report_Idx exists. Check ok
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Initial data information retrieved - total time used: 0.0102 seconds
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Connectiontest to db SQLite:dbname=/opt/fhem/important.db successful
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - execute command before exportToFile: 'set impDbLog reopen 3600'
2023.10.14 02:13:07 2: impDbLog - Connection closed until 03:13:07 (3600 seconds).
2023.10.14 02:13:08 3: impDbLog - Database disconnected by request.
2023.10.14 02:19:09 1: Server shutdown delayed due to myDbLog,alexa for max 10 sec
2023.10.14 02:19:15 1: [Freezemon] freezemon: possible freeze starting at 02:17:28, delay is 107.342 possibly caused by: tmr-CODE(0x55fcfa6d2bb8)(ResponseTimeout) tmr-CODE(0x55fcfa62c3c8)(ProcessRequestQueue) tmr-HM485_LAN_KeepAlive(HM485_LAN) tmr-DOIF_SleepTrigger(Heizung_HK2_Solltemperatur)
2023.10.14 02:19:16 3: alexa: stopped
2023.10.14 02:19:17 1: DbRep Rep.impDbLog -> BlockingCall DbRep_expfile pid:DEAD:84022 Process died prematurely
2023.10.14 02:19:17 3: DbRep Rep.impDbLog - execute command after command: 'set impDbLog reopen'
2023.10.14 02:19:17 3: impDbLog - Reopen requested
2023.10.14 02:19:17 2: DbRep Rep.impDbLog - command message after command: >Reopen executed.<
2023.10.14 02:19:17 2: DbRep Rep.impDbLog - Database command aborted: "Process died prematurely"
2023.10.14 02:19:17 0: Server shutdown


2023.10.14 07:27:18 3: DbRep Rep.myDbLog - get initial structure information of database "/opt/fhem/fhem.db", remaining attempts: 3
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Connectiontest to database SQLite:dbname=/opt/fhem/fhem.db with user
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Index Report_Idx exists. Check ok
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Initial data information retrieved - total time used: 0.0096 seconds
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - execute command before exportToFile: 'set myDbLog reopen 3600'
2023.10.14 07:32:02 2: impDbLog - Wait for last database cycle due to shutdown ...
2023.10.14 07:32:02 1: Server shutdown delayed due to alexa,impDbLog for max 10 sec
2023.10.14 07:32:03 2: impDbLog - Last database write cycle done
2023.10.14 07:32:03 1: DbRep Rep.myDbLog -> BlockingCall DbRep_expfile pid:DEAD:88816 Process died prematurely
2023.10.14 07:32:03 3: DbRep Rep.myDbLog - execute command after command: 'set myDbLog reopen'
2023.10.14 07:32:03 2: DbRep Rep.myDbLog - command message after command: >Reopen executed.<
2023.10.14 07:32:03 2: DbRep Rep.myDbLog - Database command aborted: "Process died prematurely"
2023.10.14 07:32:05 0: Server shutdown


Hallo Jewe,
wie wärs denn damit... zunächst mal FHEM geregelt herunterfahren, und dann die DB-Datei von SQLite kopieren. Mit einem Datenbanktool kannst du dann auf die "offline"-DB zugreifen und sie damit exportierern. Ich habe für mich unter Windows den DBeaver Community entdeckt, damit kann man sich auf viele Datenbanken verbinden...

Viele Grüße
Wolfgang
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 Oktober 2023, 12:21:34
Die dblog Meldung ist auch nur eine Reaktion auf den shutdown.
Du kannst es noch mit aggregation=day probieren.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 14 Oktober 2023, 15:45:34
Moin,

gerade bin ich mit einem Serverumzug einer zentralen FHEM Instanz beschäftigt.
Für DbLog habe ich mittels DbRep dumpfiles erzeugt.

Dabei sind mir zwei Dinge aufgefallen:

  • set ... dumpMySql schreibt nur die Tabellen ins dumpfile, nicht aber die Datenbank selbst
  • die Rechte des dumpfiles mit 0777 festzulegen, finde ich überdenkenswert

Zu 1:
Es ist an sich nicht schlimm, wenn man es weiß. Dann legt man halt die Datenbank manuell an.

ABER: das dumpfile lässt sich dann von der Kommandozeile aus trotzdem nicht einfach einspielen, weil im dumpfile keine Datenbank ausgewählt wird. Deshalb musste ich im dumpfile manuell ein "use fhem;" einfügen, danach hat das Einspielen funktioniert.

Beide oben genannten Punkte sind nicht wirklich dramatisch.
Vielleicht lässt sich an der Stelle aber trotzdem irgendwas optimieren.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Oktober 2023, 09:21:30
Hallo betateilchen,

danke für die Hinweise.
Schaue ich mir demnächst mal an.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 07 November 2023, 21:42:08
Hallo Heiko,

danke fürs Umsetzen.

--
-- Create database
--
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `fhem` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin */;
USE `fhem`;

Darf ich mir bei Gelegenheit noch was wünschen?

2023.11.07 21:37:50 5: DbRep logRep - New dump file ./log/fhem_2023_11_07_21_37.sql was created
Spricht etwas dagegen, diese Meldung im Loglevel 3 auszugeben?
Die würde doch an der markierten Stelle perfekt passen:

2023.11.07 21:31:02 3: DbRep logRep - ################################################################
2023.11.07 21:31:02 3: DbRep logRep - ###             New database clientSide dump                 ###
2023.11.07 21:31:02 3: DbRep logRep - ################################################################
2023.11.07 21:31:02 3: DbRep logRep - Starting dump of database 'fhem'
2023.11.07 21:31:02 3: DbRep logRep - Characterset of collection set to utf8mb4.
2023.11.07 21:31:02 3: DbRep logRep - Searching for tables inside database fhem....
2023.11.07 21:31:02 3: DbRep logRep - Found 2 tables with 64586 records.
>>> 2023.11.07 hh:mm:ss 3: DbRep logRep - New dump file ./log/fhem_2023_11_07_21_37.sql was created
2023.11.07 21:31:02 3: DbRep logRep - Dumping table current (Type InnoDB):
2023.11.07 21:31:02 3: DbRep logRep - 0 records inserted (size of backupfile: 1.15 KB)
2023.11.07 21:31:02 3: DbRep logRep - Dumping table history (Type InnoDB):
2023.11.07 21:31:03 3: DbRep logRep - 64586 records inserted (size of backupfile: 12.09 MB)
2023.11.07 21:31:03 3: DbRep logRep - Finished backup of database fhem - total time used (hh:mm:ss): 00:00:00
2023.11.07 21:31:03 3: DbRep logRep - Database dump finished successfully.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 November 2023, 22:08:32
Hallo Udo,

da warst du aber schnell ... die Version kommt doch erst morgen.  ;)

Ja, den Loglevel setze ich gerne so um.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 November 2023, 22:19:26
Ist drin:

2023.11.07 22:12:16.294 3: DbRep Rep.fhemtest.Dump - ################################################################
2023.11.07 22:12:16.295 3: DbRep Rep.fhemtest.Dump - ###             New database clientSide dump                 ###
2023.11.07 22:12:16.296 3: DbRep Rep.fhemtest.Dump - ################################################################
2023.11.07 22:12:16.442 3: DbRep Rep.fhemtest.Dump - Starting dump of database 'fhemtest'
2023.11.07 22:12:16.536 3: DbRep Rep.fhemtest.Dump - Characterset of collection set to utf8mb4.
2023.11.07 22:12:16.537 3: DbRep Rep.fhemtest.Dump - Searching for tables inside database fhemtest....
2023.11.07 22:12:30.894 3: DbRep Rep.fhemtest.Dump - Found 2 tables with 15307590 records.
2023.11.07 22:12:30.898 3: DbRep Rep.fhemtest.Dump - New dump file /sds1/backup/dumps_FHEM/fhemtest_2023_11_07_22_12.sql was created
2023.11.07 22:12:30.902 3: DbRep Rep.fhemtest.Dump - Dumping table current (Type InnoDB):
2023.11.07 22:12:31.224 3: DbRep Rep.fhemtest.Dump - 16457 records inserted (size of backupfile: 3.28 MB)
2023.11.07 22:12:31.224 3: DbRep Rep.fhemtest.Dump - Dumping table history (Type InnoDB):
2023.11.07 22:16:02.945 3: DbRep Rep.fhemtest.Dump - 15291133 records inserted (size of backupfile: 2615.80 MB)
2023.11.07 22:16:02.950 3: DbRep Rep.fhemtest.Dump - Deleting old dumpfile 'fhemtest_2023_11_07_20_28.sql'
2023.11.07 22:16:03.788 3: DbRep Rep.fhemtest.Dump - Finished backup of database fhemtest - total time used (hh:mm:ss): 00:03:47
2023.11.07 22:16:03.826 3: DbRep Rep.fhemtest.Dump - Database dump finished successfully.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 07 November 2023, 22:25:18
super, dankeschön!
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 06 Dezember 2023, 00:16:38
Hallo,
bei meiner FHEM-Konfiguration mit 93_DbRep.pm:v8.52.14-s28140/2023-11-08 sind im Perl-Code hinter executeAfterProc globale Variablen wie bspw. $mday nicht mehr definiert. Ist das beabsichtigt?
Viele Grüße,
Thome
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Dezember 2023, 09:01:54
Moin,

nein. Und es wurde auch diesbezüglich nichts geändert bzw. keine diesbezüglichen Einschränkungen (bewusst) vorgenommen.
Wie äußert sich denn dein Problem?

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 07 Dezember 2023, 23:39:08
Hallo Heiko,
bis zu letzten Update hatte folgendes Konstrukt funktioniert:
attr test_rep executeAfterProc {if($mday==1) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }

Jetzt erhalte ich beim Anlegen dieses Attributs:
Global symbol "$mday" requires explicit package name (did you forget to declare "my $mday"?) at (eval 960707) line 1.
Viele Grüße,
Thome
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2023, 00:00:29
Nabend Thome,

ich habe dein Attr mal eben bei mir gegengecheckt und kann deinen Issue bestätigen.
Allerdings kann ich versichern diesbezüglich nichts geändert zu haben. Auch der Attributcheck (beim Anlegen) ist unverändert zur Vorversion.
Möglicherweise hat sich an zentraler Stelle etwas geändert was Auswirkungen hat.
Aber das muß ich erstmal prüfen und mir anschauen.

Meld mich wieder.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 08 Dezember 2023, 12:50:33
Schwer vorstellbar, dass das schon funktioniert haben soll.
$mday ist, genau wie $hms innerhalb von fhem.pl nicht als globale Variable definiert.
Diese Werte stehen immer nur temporär zur Verfügung, man kann sie beispielsweise auch nicht in der 99_myUtils.pm verwenden.
Dieses Verhalten ist nicht neu.

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2023, 15:54:42
Da habe ich auch lange darüber sinniert und die fhem.pl aber auch die 99_Utils.pm abgesucht. Inzwischen kann ich mir auch vorstellen, weshalb es doch funktioniert haben könnte.

In den besagten Attributen war dokumentiert FHEM Befehle und seit vergangenen Mai (V8.52.7) auch Perl Code zur Ausführung bringen zu können. Im Zuge der Erweiterung hatte ich damals auch eine Syntaxprüfung im Attr eingebaut was vorher nicht der Fall war.
Später wird dieser Code dann mit AnalyzeCommandChain bzw. Perl in der Sub AnalyzePerlCommand ausgeführt (war vor V8.52.7 auch so).
Die Sub stellt intern $mday,$month,$we usw. zur Verfügung. Dadurch klappt es dann bei der Ausführung.

Blöderweise hatte ich aber im Check beim Setzen des Attr nur ein einfaches eval verwendet. Da fehlen die Variablen.

@Thome, wenn du bestätigen könntest DbRep schon ziemlich lange (konkret seit Mai 2023) nicht upgedated zu haben und nun mit dem letzten Update auf diesen Fehler gelaufen bist, hätten wir eine schlüssige Erklärung für das Phänomen. ;)

Ungeachtet dessen schaue ich mal den Check entsprechend anzupassen.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 08 Dezember 2023, 16:49:03
Zitat von: DS_Starter am 08 Dezember 2023, 15:54:42Später wird dieser Code dann mit AnalyzeCommandChain bzw. Perl in der Sub AnalyzePerlCommand ausgeführt (war vor V8.52.7 auch so).
Die Sub stellt intern $mday,$month,$we usw. zur Verfügung. Dadurch klappt es dann bei der Ausführung.

Das ist genau das, was ich mit "stehen immer nur temporär zur Verfügung" meinte: immer dann wenn die fhem-internen Analyze...() Funktionen im Spiel sind, deshalb funktioniert es z.B. auch in der FHEM Befehlszeile.

Ok, das mit Deiner zusätzlichen Syntaxprüfung hatte ich nicht berücksichtigt. Aber wenn "nur" das das Problem ist, sollte ein Umbau ohne großen Aufwand möglich sein.



geht 8)

2023.12.08 17:23:39 3: DbRep dbRep_ub - Entries of /opt/fhem/sqldb/fhemlog.db.history deleted: ub4--w3_/--0
2023.12.08 17:23:39 3: DbRep dbRep_ub - execute command after delEntries: '{Debug $hms}'
2023.12.08 17:23:39 1: DEBUG>17:23:39

Grundsätzlich habe ich dafür lediglich an zwei Stellen (beim Setzen des Attributes und in _DbRep_procCode) das eval durch AnalyzePerlCommand ersetzt. Wobei an der zweiten Stelle ja sogar schon ein AnalyzeCommandChain vorgesehen ist, wenn ... (?)
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2023, 17:50:26
Bin grad nicht am Rechner ... führt AnalyzePerlCommand das Kommando nicht gleich aus? Beim Attr prüfen sollte nur die Syntax gecheckt aber nicht ausgeführt werden. War vermutlich der Grundd weshalb ich AnalyzePerlCommand nicht im Attr verwendet hatte? Muss ich später mal schauen welche Hirnwindungen ich damals aktiviert hatte.  ;)
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 08 Dezember 2023, 18:02:32
Zitat von: DS_Starter am 08 Dezember 2023, 17:50:26führt AnalyzePerlCommand das Kommando nicht gleich aus?

Ja, aber ich wollte auch nicht sagen, dass mein Ansatz die tatsächliche Lösung ist. Es sollte nur der Beleg dafür sein, dass Deine Vermutung zur Ursache stimmt.

Eigentlich bin ich mir gar nicht sicher, ob Du die Attributbehandlung überhaupt selbst machen musst. Es könnte sein, dass CommandAttr() in fhem.pl das schon für Dich übernimmt und perlSyntaxCheck() aufruft. In diesem Fall würde sogar ggf. das globale Attribut zum Abschalten dieser Prüfung greifen. Aber das habe ich jetzt nicht geprüft.

Schau es Dir einfach in Ruhe an.



Noch ein bisschen rumgetestet:

perlSyntaxCheck("Debug $hmms")
liefert:

Global symbol "$hmms" requires explicit package name (did you forget to declare "my $hmms"?) at (eval 5196) line 1.
perlSyntaxCheck("Debug $hms")
liefert nichts, auch keinen Eintrag im Log, wird also nicht ausgeführt, sondern nur geprüft.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 Dezember 2023, 23:14:17
Habe eine Lösung implementiert und eingecheckt.
perlSyntaxCheck hat den Check abgedeckt. Allerdings kamen bei der Übergabe von $name, $hash wiederum Fehler und dadurch wäre die lt. commandref beschriebene Syntax nicht mehr gegeben. Deswegen habe ich eine etwas andere Lösung gewählt.
Wahrscheinlich werde ich die Variablenübergabe nochmal ändern und dafür %evalspecials einsetzen, muß ich testen ob das in dem Kontext klappt.
Möglicherweise schon am WE, mal schauen.

@Thome, morgen früh ist das Update verfügbar. Damit sollte dein use case wieder funktionieren.

Grüße,
Heiko

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 09 Dezember 2023, 13:08:54
Hallo Heiko,
vielen Dank für die schnelle Reaktion: Die globalen Variablen funktionieren wieder! Das spart Code im Perl-Konstrukt.
Übrigens: Der Syntax-Check hatte dafür gesorgt, dass das betreffende Attribut komplett gelöscht wurde. Genial, ansatzweise selbstheilender Code bzw. Konfiguration 8)
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 09 Dezember 2023, 13:37:00
 :)
schönes WE.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 09 Dezember 2023, 15:22:26
Zitat von: Thowe am 09 Dezember 2023, 13:08:54Übrigens: Der Syntax-Check hatte dafür gesorgt, dass das betreffende Attribut komplett gelöscht wurde.

Nein, er hatte dafür gesorgt, dass das Attribut erst gar nicht angelegt wurde...
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 14 Dezember 2023, 22:17:31
Das ist eine Sichtweise. Die andere ist, dass das Attribut mit $mday bereits jahrelang funktioniert hatte, bis es weg war. Auskommentieren in fhem.cfg hätte auch gereicht.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 15 Dezember 2023, 11:38:29
Zitat von: Thowe am 14 Dezember 2023, 22:17:31Auskommentieren in fhem.cfg hätte auch gereicht.

Nein.

Dazu muss man wissen und verstanden haben, wie das Speichern einer Konfiguration in FHEM funktioniert.

Vereinfacht gesagt: es wird nicht die bestehende Konfigurationsdatei verändert, sondern immer eine neue Konfigurationsdatei aus dem gerade laufenden FHEM erzeugt. Dabei werden nur die aktuell definierten devices mit ihrem "define" und allen zugehörigen "attr" (der vorhandenen (!) Attribute) gespeichert.

Es wird beim Speichern der Konfiguration nichts gelöscht. Das Attribut war zum Zeitpunkt des Speicherns einfach nicht (mehr) vorhanden, weil es beim letzten FHEM Start nicht angelegt wurde.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 Dezember 2023, 10:15:08
Danke für die Erläuterung.
Ich möchte auf noch ein Problem hinweisen:
Im Konstrukt lt. FHEM-Editor
attr test_rep executeAfterProc {if($mday==1) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }
wird der Befehl
set test2 2nicht mehr ausgeführt. In fhem.cfg stehen als Befehlstrenner ;;;;. Wie soll das Escapen funktionieren?
Nach einem Rollback 93_DbRep.pm auf einen Versionsstand vom 17.02.23 funktioniert es.
Viele Grüße, Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2023, 10:47:21
Danke für den Hinweis.
Schaue ich mir an. Wollte ohnehin wegen des letzten Themas die Ausführungsroutine noch einmal in Ruhe überprüfen.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 17 Dezember 2023, 10:53:04
Bei mir funktioniert das problemlos.

attr logRep executeAfterProc { if($mday==17) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }

liefert im Log:

2023.12.17 10:49:50 3: DbRep logRep - execute command after dump: '{ if($mday==17) {fhem("set test1 1;set test2 2")} else {fhem("set test3 3")} }'
2023.12.17 10:49:50 3: set test1 1;set test2 2 : Please define test1 first
Please define test2 first

Dass dabei zwei Fehlermeldungen kommen, ist logisch, da es bei mir weder test1 noch test2 gibt.
Aber ausgeführt werden beide set Befehle.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 17 Dezember 2023, 11:11:51
Zitat von: Thowe am 17 Dezember 2023, 10:15:08In fhem.cfg stehen als Befehlstrenner ;;;;. Wie soll das Escapen funktionieren?

In meiner Konfiguration stehen nur zwei Semikolon.

search result for device: logRep in version: 1
--------------------------------------------------------------------------------
define logRep DbRep logMetallDb
attr logRep executeAfterProc { if($mday==17) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 Dezember 2023, 11:32:50
Hallo ihr Sonntagsarbeiter, das ist der feine Unterschied, auf den ich hinweisen wollte. Früher waren für Perl-Inline-FHEM-Kommandos zwei ,,escapete" Semikolons notwendig. Oder muss ich schreiben: Sie wurden korrekt verarbeitet. Mit dem Syntax-Check ist dem offensichtlich nicht mehr so.
Danke für die Analyse.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 17 Dezember 2023, 11:42:04
Ich weiß ja nicht, wie Du solche Dinge in die Konfiguration bringst, aber wenn man dafür den integrierten Attribut-Editor benutzt, muss man über die Anzahl der Semikolon selten nachdenken, das macht FHEM dann normalerweise selbst "richtig".
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 Dezember 2023, 12:40:36
Gut gemeinte Worte. In der Praxis hätte ich Devices inkl. Attribute von über 200 sequenziell ablaufenden DbRep-Kommandos im FHEM-Editor eingeben müssen. Dafür habe ich die Alternative genutzt, um einigermaßen den Überblick behalten zu können.
Vor jedem DbRep-Update stelle ich eine Kerze ins Fenster. Diesmal hat es nicht geholfen.
Ich wünsche Euch schöne Feiertage
und sage vielen Dank für Euer Engagement,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 17 Dezember 2023, 13:33:26
//offtopic

Es kann natürlich jeder tun und lassen, was und wie er möchte.

Hätte ich 200 DbRep Kommandos nacheinander abzuarbeiten, würde ich das nicht direkt in der Konfiguration hinterlegen, sondern ein 99_dbrepUtils.pm erstellen.
Darin würde ich die Parameter für jeden Aufruf in einem array of hashes ablegen und dann das array abarbeiten.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 Dezember 2023, 19:18:30
Interessanter Ansatz, weil übersichtlicher, aber praktikabel? Wie meinst Du das konkret, wenn von Aufruf zu Aufruf einige dbrep-Attribute anzupassen sind, z.B. timestamp_begin, timestamp_end, device, reading, executeAfterProc und bspw. §timestamp_begin§ in einem sqlCmd benutzt werden muss?
Falls das zur Abarbeitung jeder Array-Zeile ein defmod notwendig macht, halte ich das laufzeittechnisch für ungeschickt.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 17 Dezember 2023, 20:14:17
Warum sollte dafür ein defmod notwendig werden? Ein DbRep device muss doch einfach nur vorhanden sein, um beliebige Dinge damit tun zu können.

Alles andere wird per Attributen festgelegt und dann mit "set ... irgendwas" ausgeführt.

Zitat von: Thowe am 17 Dezember 2023, 19:18:30Wie meinst Du das konkret, wenn von Aufruf zu Aufruf einige dbrep-Attribute anzupassen sind, z.B. timestamp_begin, timestamp_end, device, reading, executeAfterProc und bspw. §timestamp_begin§ in einem sqlCmd benutzt werden muss?

wie ich schon geschrieben hatte:

Zitat von: betateilchen am 17 Dezember 2023, 13:33:26die Parameter für jeden Aufruf in einem array of hashes ablegen

Jeder hash im array enthält alle Werte für die Attribute, den auszuführenden Befehl und ggf. Befehlsparameter jeder einzelnen Aktion.

my @dbrep = (
{ timestamp_begin => "2023-12-17 00:00:00", timestamp_end => "2023-12-17 01:00:00", device => "device1", reading => "reading1", cmd => "delEntries" },
{ timestamp_begin => "2023-12-15 11:00:00", timestamp_end => "2023-12-15 12:00:00", device => "device2", reading => "reading2", cmd => "delEntries" },
);

und dann in einer Schleife über das array die Attribute setzen und den angegebenen Befehl ausführen.
Das kann man theoretisch beliebig granular aufdröseln.



//offtopic:
Mega-cool wäre natürlich, wenn man so einen vorbereiteten hash direkt an ein DbRep device übergeben könnte.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 Dezember 2023, 23:37:02
Dankeschön für die Unterstützung. Wenn DbRep jetzt noch eine XML-Struktur mit SQL-Statements verarbeiten könnte...
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 Dezember 2023, 23:45:55
Habe eure Diskussion verfolgt ...

Zitat//offtopic:
Mega-cool wäre natürlich, wenn man so einen vorbereiteten hash direkt an ein DbRep device übergeben könnte.

ZitatWenn DbRep jetzt noch eine XML-Struktur mit SQL-Statements verarbeiten könnte...

Mal schauen ...
Wünsche euch guten Start in die Vorweihnachtswoche!
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 17 Dezember 2023, 23:49:29
Bitte nicht xml, xml ist gruslig und finsterstes Mittelalter.
json macht viel mehr Spaß und ist viel flexibler.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 18 Dezember 2023, 00:45:44
Im Ernst, ich bezweifele, dass eine SQL-Skriptmaschine für ein Hausautomationssystem erwartet wird.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 29 Dezember 2023, 14:37:58
Hallo Heiko,
ist der Ansatz von betateilchen z.Zt. überhaupt umsetzbar? Wie kann ich die strenge Abarbeitungssequenz der DbPrep-Audrufe sicherstellen?
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 29 Dezember 2023, 17:45:43
Hallo Thowe,

das kann man svhon machen. wegen der asynchronen Arbeitsweise muss man sich in ein bisschen Steuerungslogik überlegen. man kann im executeBeforeProc einen Status in einem Reading setzen und mit executeAfterProc wieder löschen. den fragt man in seiner Schleife ab und startet dann den nächsten Befehl usw.

Nur als Beispiel.

Aber das

ZitatMega-cool wäre natürlich, wenn man so einen vorbereiteten hash direkt an ein DbRep device übergeben könnte

will ich mir auf jeden Fall noch zu Gemüte führen. Halte ich für viele Einsätze sehr praktisch. Dbrep ist gerade nicht so im Scope, aber kommt wieder mal dran.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 Januar 2024, 14:29:55
Hallo zusammen,

in meinem contrib habe ich die V 8.53.0 hochgeladen.

Es gibt in der V einen Setter multiCmd mit dem man dem Device einen Befehls-Hash übergeben und abarbeiten lassen kann.
Die genaue Syntax/Verwendung könnt ihr der Kommando-Hilfe entnehmen.
Der Befehlshash kann auch über eine Variable übergeben werden.
Als Demo hier ein Beispiel mit einem at-Device:

define Rep.multi at +*01:00:00 {
   my $cmdhash =
   "{
      1  => { timestamp_begin => '2023-12-17 00:00:00',
              timestamp_end   => '2023-12-17 01:00:00',
              device          => 'SMA_Energymeter',
              reading         => 'Einspeisung_Wirkleistung_Zaehler',
              cmd             => 'countEntries history'
            },
      2  => { timestamp_begin => '2023-12-15 11:00:00',
              timestamp_end   => 'previous_day_end',
              device          => 'SMA_Energymeter',
              reading         => 'Einspeisung_Wirkleistung_Zaehler',
              cmd             => 'countEntries'
            },
      3  => { timeDiffToNow   => 'd:2',
              device          => 'SMA_%,MySTP.*',
              reading         => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
              cmd             => 'countEntries history'
            },
      4  => { cmd             => 'sqlCmd select count(*) from current'
            },
    }";
   
    fhem ("set Rep.CPU multiCmd $cmdhash");
}


Mit verbose 4 seht ihr die Abarbeitung der "Queue" im Log:

Zitat2024.01.06 14:17:42.240 4: DbRep Rep.CPU - Start multiCmd index >1<
2024.01.06 14:17:42.418 4: DbRep Rep.CPU - -------- New selection ---------
2024.01.06 14:17:42.419 4: DbRep Rep.CPU - Command: countEntries history
2024.01.06 14:17:42.420 4: DbRep Rep.CPU - FullDay option: 0
2024.01.06 14:17:42.420 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-12-17 00:00:00
2024.01.06 14:17:42.421 4: DbRep Rep.CPU - Timestamp end human readable: 2023-12-17 01:00:00
2024.01.06 14:17:42.421 4: DbRep Rep.CPU - Aggregation: no
2024.01.06 14:17:42.452 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.01.06 14:17:42.456 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.01.06 14:17:42.458 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.01.06 14:17:42.459 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.01.06 14:17:42.460 4: DbRep Rep.CPU - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung_Zaehler' ) AND TIMESTAMP >= '2023-12-17 00:00:00' AND TIMESTAMP <= '2023-12-17 01:00:00' ;
2024.01.06 14:17:42.586 4: DbRep Rep.CPU - Start multiCmd index >2<
2024.01.06 14:17:42.596 4: DbRep Rep.CPU - -------- New selection ---------
2024.01.06 14:17:42.597 4: DbRep Rep.CPU - Command: countEntries history
2024.01.06 14:17:42.597 4: DbRep Rep.CPU - FullDay option: 0
2024.01.06 14:17:42.598 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-12-15 11:00:00
2024.01.06 14:17:42.598 4: DbRep Rep.CPU - Timestamp end human readable: 2024-01-05 23:59:59
2024.01.06 14:17:42.599 4: DbRep Rep.CPU - Aggregation: no
2024.01.06 14:17:42.644 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.01.06 14:17:42.648 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.01.06 14:17:42.650 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.01.06 14:17:42.650 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.01.06 14:17:42.651 4: DbRep Rep.CPU - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung_Zaehler' ) AND TIMESTAMP >= '2023-12-15 11:00:00' AND TIMESTAMP <= '2024-01-05 23:59:59' ;
2024.01.06 14:17:42.860 4: DbRep Rep.CPU - Start multiCmd index >3<
2024.01.06 14:17:42.872 4: DbRep Rep.CPU - -------- New selection ---------
2024.01.06 14:17:42.872 4: DbRep Rep.CPU - Command: countEntries history
2024.01.06 14:17:42.873 4: DbRep Rep.CPU - timeDiffToNow - year: , day: 2, hour: , min: , sec:
2024.01.06 14:17:42.874 4: DbRep Rep.CPU - Year 2024 is leap year
2024.01.06 14:17:42.874 4: DbRep Rep.CPU - startMonth: 0 endMonth: 0 lastleapyear: 2024 baseYear: 2024 diffdaylight:0 isdaylight:0
2024.01.06 14:17:42.875 4: DbRep Rep.CPU - FullDay option: 0
2024.01.06 14:17:42.875 4: DbRep Rep.CPU - Time difference to current time for calculating Timestamp begin: 172801 sec
2024.01.06 14:17:42.876 4: DbRep Rep.CPU - Timestamp begin human readable: 2024-01-04 14:17:41
2024.01.06 14:17:42.876 4: DbRep Rep.CPU - Timestamp end human readable: 2024-01-06 14:17:42
2024.01.06 14:17:42.877 4: DbRep Rep.CPU - Aggregation: no
2024.01.06 14:17:42.916 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.01.06 14:17:42.920 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.01.06 14:17:42.921 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.01.06 14:17:42.922 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.01.06 14:17:42.927 4: DbRep Rep.CPU - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE IN ('SMA_Energymeter','MySTP_5000') ) AND ( READING LIKE 'Ein%' OR READING IN ('etotal','etoday') ) AND READING NOT LIKE '%Wirkleistung' AND TIMESTAMP >= '2024-01-04 14:17:41' AND TIMESTAMP <= '2024-01-06 14:17:42' ;
2024.01.06 14:17:44.359 4: DbRep Rep.CPU - Start multiCmd index >4<
2024.01.06 14:17:44.504 4: DbRep Rep.CPU - SQL online formatted: select count(*)
from current;
2024.01.06 14:17:44.519 4: DbRep Rep.CPU - -------- New selection ---------
2024.01.06 14:17:44.520 4: DbRep Rep.CPU - Command: sqlCmd select count(*) from current;
2024.01.06 14:17:44.521 4: DbRep Rep.CPU - Timestamp begin human readable: not set
2024.01.06 14:17:44.522 4: DbRep Rep.CPU - Timestamp end human readable: not set
2024.01.06 14:17:44.548 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.01.06 14:17:44.552 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.01.06 14:17:44.554 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.01.06 14:17:44.555 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.01.06 14:17:44.556 4: DbRep Rep.CPU - SQL execute: select count(*) from current;
2024.01.06 14:17:44.581 4: DbRep Rep.CPU - SQL result: 21515

Ich habe bei mir schon recht viel getestet, würde mich dennoch freuen wenn der eine oder andere die Möglichkieten in seinem System ausprobiert. Möglicherweise gibt es Situationen die ich noch nicht beachtet habe.

EDIT: habe die die Lösung noch gehärtet, sodass irrtümlich falsch geschriebene Befehle ignoriert werden und dies im Log protokolliert wird.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 Januar 2024, 22:29:09
Ich habe noch weitere Attributschlüssel verfügbar gemacht.
Damit kann man sich die Ergebnisse zum Beipiel über autoForward automatisch in, u.U. verschiedene, Zieldevices konsolidieren lassen.

Das Demo at-Device kann dann z.B. so aussehen:

define Rep.multi at +*01:00:00 {
   my $cmdhash =
   qq/{   
      1  => { timestamp_begin => '2023-12-17 00:00:00',
              timestamp_end   => '2023-12-17 01:00:00',
              device          => 'SMA_Energymeter',
              reading         => 'Einspeisung_Wirkleistung_Zaehler',
              cmd             => 'countEntries history'
            },
      2  => { timestamp_begin => '2023-12-15 11:00:00',
              timestamp_end   => 'previous_day_end',
              device          => 'SMA_Energymeter',
              reading         => 'Einspeisung_Wirkleistung_Zaehler',
              cmd             => 'countEntries'
            },
      3  => { timeDiffToNow   => 'd:2',
              readingNameMap  => 'COUNT',
              autoForward     => '{ ".*COUNT.*" => "Dum.Rep.All" }',
              device          => 'SMA_%,MySTP.*',
              reading         => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
              cmd             => 'countEntries history'
            },
      4  => { timeDiffToNow   => 'd:2',
              readingNameMap  => 'SUM',
              autoForward     => '{ ".*SUM.*" => "Dum.Rep.All" }',
              device          => 'SMA_%,MySTP.*',
              reading         => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
              cmd             => 'sumValue'
            },
      5  => { cmd             => 'sqlCmd select count(*) from current'
            },
    }/;

    fhem ("set Rep.CPU multiCmd $cmdhash");
}

Update liegt in meinem contrib.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 25 Januar 2024, 12:06:17
Hallo zusammen,

ich hab seit einiger Zeit (ca 1-2 Wochen) immer mal wieder ne Meldung im Log von zwei DbRep Devices, bei den ich mir noch nicht erklären kann, woher die Meldung kommt. Die Devices wird alle 15 Min aufgerufen (mit Hilfe von executeAfterProc) und mal kommt ein Fehler mal nicht. Z.B. Heute Nacht 5x davor im Laufe des Nachmittags 4x .... total verwunderlich  ???

Da ich absolut keine Idee hab, eben auch weil es nur ab und zu mal kommt. Hoffe ich dass jemand einen Tipp hat, wie ich mich dem Ganzen mal nähern kann:

Fehler:
2024.01.25 02:55:12.191 2: DbRep DBrep_Wetter_wind_speed - ERROR - DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction at ./FHEM/93_DbRep.pm line 11956.

Betroffenes Device:
define DBrep_Wetter_wind_speed DbRep DBLogging
attr DBrep_Wetter_wind_speed DbLogExclude .*
attr DBrep_Wetter_wind_speed alias 03 Schnitt Wind_speed errechnen
attr DBrep_Wetter_wind_speed allowDeletion 1
attr DBrep_Wetter_wind_speed device Wetterstation
attr DBrep_Wetter_wind_speed event-on-change-reading .*
attr DBrep_Wetter_wind_speed executeAfterProc set DBrep_Wetter_humidity averageValue writeToDBInTime
attr DBrep_Wetter_wind_speed group Automatische DB Bereinigung
attr DBrep_Wetter_wind_speed icon own-log@darkgrey
attr DBrep_Wetter_wind_speed reading wind_speed
attr DBrep_Wetter_wind_speed room System->Datenbank
attr DBrep_Wetter_wind_speed sortby 13
attr DBrep_Wetter_wind_speed timeDiffToNow m:15
attr DBrep_Wetter_wind_speed timeOlderThan m:0
attr DBrep_Wetter_wind_speed verbose 2
#   DATABASE   fhem_DB_LIVE
#   DEF        DBLogging
#   FUUID      649cad18-f33f-6adc-f2c3-76163c3dfee6ef9a
#   FVERSION   93_DbRep.pm:v8.53.0-s28370/2024-01-10
#   LASTCMD    averageValue writeToDBInTime
#   MODEL      Client
#   NAME       DBrep_Wetter_wind_speed
#   NOTIFYDEV  global,DBrep_Wetter_wind_speed
#   NR         326
#   NTFY_ORDER 50-DBrep_Wetter_wind_speed
#   ROLE       Client
#   STATE      done
#   TYPE       DbRep
#   UTF8       1
#   eventCount 1685
#   HELPER:
#     DBLOGDEVICE DBLogging
#     GRANTS     DROP,RELOAD,SHOW VIEW,CREATE VIEW,CREATE USER,INSERT,TRIGGER,REPLICATION SLAVE,SHUTDOWN,LOCK TABLES,ALTER,FILE,REFERENCES,REPLICATION CLIENT,CREATE TEMPORARY TABLES,INDEX,DELETE,ALTER ROUTINE,PROCESS,CREATE ROUTINE,EXECUTE,SELECT,SHOW DATABASES,UPDATE,EVENT,CREATE
#     IDRETRIES  2
#     MINTS      2022-07-01 00:00:22
#     PACKAGE    main
#     VERSION    8.53.0
#     CV:
#       aggregation no
#       aggsec     1
#       destr      2024-01-25
#       dsstr      2024-01-25
#       epoch_seconds_end 1706180108.03797
#       mestr      01
#       msstr      01
#       testr      11:55:08
#       tsstr      11:40:08
#       wdadd      345600
#       yestr      2024
#       ysstr      2024
#     DBREPCOL:
#       COLSET     1
#       DEVICE     64
#       EVENT      512
#       READING    64
#       TYPE       64
#       UNIT       32
#       VALUE      128
#   OLDREADINGS:
#   READINGS:
#     2024-01-25 11:55:10   2024-01-25__Wetterstation__wind_speed__AVGAM__no_aggregation 1.0000
#     2024-01-25 11:55:10   db_lines_processed 2
#     2024-01-25 11:55:11   state           done
#
setstate DBrep_Wetter_wind_speed done
setstate DBrep_Wetter_wind_speed 2024-01-23 22:31:21 .associatedWith Wetterstation
setstate DBrep_Wetter_wind_speed 2024-01-25 11:55:10 2024-01-25__Wetterstation__wind_speed__AVGAM__no_aggregation 1.0000
setstate DBrep_Wetter_wind_speed 2024-01-25 11:55:10 db_lines_processed 2
setstate DBrep_Wetter_wind_speed 2024-01-25 11:55:11 state done


Vielen Dank im Voraus
VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 25 Januar 2024, 17:55:19
Zitat von: DS_Starter am 06 Januar 2024, 14:29:55Es gibt in der V einen Setter multiCmd mit dem man dem Device einen Befehls-Hash übergeben und abarbeiten lassen kann.
Die genaue Syntax/Verwendung könnt ihr der Kommando-Hilfe entnehmen.
Der Befehlshash kann auch über eine Variable übergeben werden.

Das sieht gut aus, aber ich habe den Beitrag erst heute entdeckt.
Diese und nächste Woche komme ich wahrscheinlich nicht zum Testen, aber ich werde das auf jeden Fall ausprobieren.

Vorab schonmal Danke für Umsetzen der Idee.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 Januar 2024, 18:10:14
Hallo Andreas,

das ist ein Datenbankmechanismus der recht gut hier erklärt ist: https://karbachinsky.medium.com/deadlock-found-when-trying-to-get-lock-try-restarting-transaction-54a3ed118068

Führe mal bitte im DbRep aus:

set ... sqlCmd SHOW ENGINE INNODB STATUS;

Es kommt eine größere Ausgabe. Interessant ist dieser Block

Zitat------------------------
LATEST DETECTED DEADLOCK
------------------------
2023-12-20 09:14:22 7f9d830cf700
*** (1) TRANSACTION:
TRANSACTION 243789459, ACTIVE 149 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 7266603, OS thread handle 0x7f9d0a32d700, query id 639594931 fhem.myds.me 192.168.2.46 fhemshort update
REPLACE INTO current (TIMESTAMP, TYPE, EVENT, VALUE, UNIT, DEVICE, READING) VALUES ('2023-12-20 09:11:27','FULLY','','1',NULL,'googlenexus.fully','powerstate')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 547 page no 8 n bits 240 index `PRIMARY` of table `fhemshort`.`current` trx table locks 1 total table locks 3  trx id 243789459 lock_mode X locks rec but not gap waiting lock hold time 47 wait time before grant 0
*** (2) TRANSACTION:
TRANSACTION 243789414, ACTIVE 168 sec inserting
mysql tables in use 2, locked 2
114855 lock struct(s), heap size 14759464, 21983074 row lock(s), undo log entries 834
MySQL thread id 7270446, OS thread handle 0x7f9d830cf700, query id 639592831 fhem.myds.me 192.168.2.46 fhemshort Sending data
INSERT IGNORE INTO current (TIMESTAMP,DEVICE,READING) SELECT timestamp,device,reading FROM history where 1 group by timestamp,device,reading
*** (2) HOLDS THE LOCK(S)

Vllt. erkennen wir anhand der Statements die beteiligten Prozesse. Könnte auch ein paralleler DbLog Schreibvorgang beteiligt sein.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 25 Januar 2024, 23:15:03
Hallo Heiko,

vielen Dank für die Antwort. Ich bin grad erst von der Arbeit rein und hab das mal ausgeführt. (Verbose 5 Log aus der Aufführung ist ebenfalls vorhanden). Leider verstehe ich aber aus der Ausgabe gar nichts. Vielleicht ja Du ;)

(Inhalt als Txt Anhang, weil es zu einem Fehlermeldung der Forumssoftware führt, wenn ich versuche das zu posten ;) )
log.txt (https://forum.fhem.de/index.php?action=dlattach;attach=175927;type=preview;file)

Zitat von: DS_Starter am 25 Januar 2024, 18:10:14Vllt. erkennen wir anhand der Statements die beteiligten Prozesse. Könnte auch ein paralleler DbLog Schreibvorgang beteiligt sein.
In Anbetracht dessen was ich in dem oben erwähntem Link bisher gelesen habe und Deinem Hinweis mit dem entsprechendem Schreibvorgang, könntest es natürlich sehrwohl genau das Problem sein. Die Betroffenen Devices erhalten sehr sehr viele Infos von der Wetterstation - Dafür eben auch der Vorgang alle 15 Min um die Daten nochmehr zu schrumpfen als anhand von event Beschränkungen innerhabl von Fhem. Beispiel:

define DBrep_Wetter_humidity DbRep DBLogging
attr DBrep_Wetter_humidity DbLogExclude .*
attr DBrep_Wetter_humidity alias 04 Schnitt Luftfeuchte errechnen
attr DBrep_Wetter_humidity allowDeletion 1
attr DBrep_Wetter_humidity device Wetterstation
attr DBrep_Wetter_humidity event-on-change-reading .*
attr DBrep_Wetter_humidity executeAfterProc set DBrep_Wetter_temperature averageValue writeToDBInTime
attr DBrep_Wetter_humidity group Automatische DB Bereinigung
attr DBrep_Wetter_humidity icon own-log@darkgrey
attr DBrep_Wetter_humidity reading humidity
attr DBrep_Wetter_humidity room System->Datenbank
attr DBrep_Wetter_humidity sortby 14
attr DBrep_Wetter_humidity timeDiffToNow m:15
attr DBrep_Wetter_humidity timeOlderThan m:0
attr DBrep_Wetter_humidity verbose 2
#   DATABASE   fhem_DB_LIVE
#   DEF        DBLogging
#   FUUID      649cad56-f33f-6adc-6608-1d3b22cbba8a36f0
#   FVERSION   93_DbRep.pm:v8.53.0-s28370/2024-01-10
#   LASTCMD    averageValue writeToDBInTime
#   MODEL      Client
#   NAME       DBrep_Wetter_humidity
#   NOTIFYDEV  global,DBrep_Wetter_humidity
#   NR         327
#   NTFY_ORDER 50-DBrep_Wetter_humidity
#   ROLE       Client
#   STATE      done
#   TYPE       DbRep
#   UTF8       1
#   eventCount 1817
#   HELPER:
#     DBLOGDEVICE DBLogging
#     GRANTS     SHOW DATABASES,SELECT,EXECUTE,CREATE ROUTINE,PROCESS,ALTER ROUTINE,DELETE,CREATE,EVENT,UPDATE,REPLICATION SLAVE,SHUTDOWN,TRIGGER,INSERT,CREATE USER,SHOW VIEW,CREATE VIEW,DROP,RELOAD,INDEX,CREATE TEMPORARY TABLES,REPLICATION CLIENT,REFERENCES,LOCK TABLES,FILE,ALTER
#     IDRETRIES  2
#     MINTS      2022-07-01 00:00:22
#     PACKAGE    main
#     VERSION    8.53.0
#     CV:
#       aggregation no
#       aggsec     1
#       destr      2024-01-25
#       dsstr      2024-01-25
#       epoch_seconds_end 1706219705.23661
#       mestr      01
#       msstr      01
#       testr      22:55:05
#       tsstr      22:40:05
#       wdadd      345600
#       yestr      2024
#       ysstr      2024
#     DBREPCOL:
#       COLSET     1
#       DEVICE     64
#       EVENT      512
#       READING    64
#       TYPE       64
#       UNIT       32
#       VALUE      128
#   OLDREADINGS:
#   READINGS:
#     2024-01-25 22:55:06   2024-01-25__Wetterstation__humidity__AVGAM__no_aggregation -
#     2024-01-25 22:55:06   db_lines_processed 0
#     2024-01-25 22:55:06   state           done
#
setstate DBrep_Wetter_humidity done
setstate DBrep_Wetter_humidity 2024-01-23 22:31:21 .associatedWith Wetterstation
setstate DBrep_Wetter_humidity 2024-01-25 22:55:06 2024-01-25__Wetterstation__humidity__AVGAM__no_aggregation -
setstate DBrep_Wetter_humidity 2024-01-25 22:55:06 db_lines_processed 0
setstate DBrep_Wetter_humidity 2024-01-25 22:55:06 state done


Dieses Device reduziert bsw. die Einträge von humidity - genau wie die anderen Einträge ist es aber auf 0:15 Min beschränkt:
timeDiffToNow  m:15
timeOlderThan m:0

Kann es sein, dass eben genau diese 0 BIS 15 Min zu meinem Problem führen könnte? Was auf dieser Grafik verdeutlicht wurde:
https://miro.medium.com/v2/resize:fit:4800/format:webp/1*fSJWI00jPKHdmj7XqG-m1A.png
 

Mein Ansatz wäre als erstes mal die Devices auf
timeDiffToNow  m:30
timeOlderThan m:15
zu ändern und die Daten erst später zu löschen -könnte das vielleicht schon helfen? (Ich würd gern Deine Meinung dazu hören, bevor ich die ganzen notifys / Devices etc ändere  ;)  ;D 

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Januar 2024, 09:18:04
Moin,

soweit ich sehen kann, hält wahrscheinlich DbLog einen Lock (INSERT IGNORE INTO history...):

*** (2) TRANSACTION: TRANSACTION 15412754, ACTIVE 1 sec inserting mysql tables in use 1, locked 1 729 lock struct(s),
heap size 90232, 121823 row lock(s), undo log entries 2 MySQL thread id 10195,
OS thread handle 139778776536832, query id 390546 192.168.0.24 fhempi_user
Update INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES ('2024-01-25 18:10:07','Hauptzaehler','ELECTRICITYCALCULATOR','calculated','avgam_no_wemos_current_lang','13.7727',NULL)
*** (2) HOLDS THE LOCK(S):

Die Attribute

timeDiffToNow  m:30
timeOlderThan m:15

sind vermutlich tatsächlich besser.
Unterstützend kannst du im DbRep das DbLog Device temporär von der DB trennen:

attr ... executeBeforeProc set DBLogging reopen 60
Die Zeit (60 Sekunden) sollten halt länger sein wie DbRep für seine Aktion benötigt.
DbLog speichert die Event-Daten zwischen und vergisst nichts.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 26 Januar 2024, 12:29:08
Moinsen,

vielen herzlichen Dank für deinen schnellen Lösungsvorschlag. Hab allerdings noch ein paar kleine Fragen dazu:

Zitat von: DS_Starter am 26 Januar 2024, 09:18:04soweit ich sehen kann, hält wahrscheinlich DbLog einen Lock (INSERT IGNORE INTO history...):

1. Zeiten anpassen: Ich habs befürchtet, aber dann weiss ich was ich jetzt zu tun hab  ;) Hat es einen Grund warum diese Zeiten dann noch besser sind oder einfach wie mein "einfacher" Gedanke war um damit außerhalb der aktuellen Zeit und Tabellenbereich zu sein?

2. Unterstützend...: Ich habe einige devices, die eine solche Aufgabe erfüllen, wenn ich das im ersten Ausführe, und sobald die Zeit für die nachfolgendenn Ausführungen reich, wird es auch ausgeführt?

3. Ergänzend dazu noch: Ich habe wie gesagt mehrere solche Devices. Es ist natürlich ultraclever alle zur gleichen Zeit ausführen zu lassen. Da ich aber an sowas nicht gedacht hab und die Sachen nach und nach gewachsen sind..... Lange Rede kurzer Sinn:

at_DBrep_3DDrucker_POWER_15Min              Next: 12:25:03
at_DBrep_Wetter_wind_lumi_15Min             Next: 12:25:01
at_DBrep_dev_GH_solar_15Min                 Next: 12:25:06
at_DBrep_zaehler_wemos_current_lang_15Min   Next: 12:25:08

+*00:15 set DBrep_3Ddrucker_ENERGY_Power averageValue writeToDBInTime

Das sind die at-devices die jeweils die Bearbeitung auslösen. Alle nach dem Muster definiert. Gibt es einen Trick / Möglichkeit sie verzögert ausführen zu lassen, oder werden sie es eh automatisch (die Zeiten unterscheiden sich ja bereits um je 1-2 sek)

Alternativ bliebe mir lediglich das Ganze so umzubauen, dass es nur noch ein Einziges at device gibt, das dann das erste auslöst und alle anderen werden mit "executeafterproc" eingebunden. Das wollte ich gern vermeiden, weil ich jetzt "Gruppen" habe. Am oberen Beispiel (3D Drucker):

at löst aus -> 50 Schnitt 3D Drucker ENERGY_Power -> executeAfterProc -> 51 Schnitt 3D Drucker ENERGY_Current -> executeAfterProc -> 52 Schnitt 3D Drucker Power5min -> executeAfterProc ->  53 Schnitt 3D Drucker alte Werte löschen -> done.
Würde diese Ordnung "ungern" verlieren - Gibt es Performance die dagegen sprechen, dann natürlich sofort.

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Januar 2024, 13:03:28
ZitatHat es einen Grund warum diese Zeiten dann noch besser sind oder einfach wie mein "einfacher" Gedanke war um damit außerhalb der aktuellen Zeit und Tabellenbereich zu sein?
Bei diesen Zeitabgrenzungen werden die aktuellsten Datensätze nicht berüchsichtigt und können mit DbLog nicht in Konflikt geraten, so die Überlegung.

Zitat2. Unterstützend...: Ich habe einige devices, die eine solche Aufgabe erfüllen, wenn ich das im ersten Ausführe, und sobald die Zeit für die nachfolgendenn Ausführungen reich, wird es auch ausgeführt?
Es reicht die DbLog "Sperre" im ersten Device zu veranlassen. Das reopen passiert dann nach Ablauf der angegebenen Sekunden.

ZitatDas sind die at-devices die jeweils die Bearbeitung auslösen. Alle nach dem Muster definiert. Gibt es einen Trick / Möglichkeit sie verzögert ausführen zu lassen, oder werden sie es eh automatisch (die Zeiten unterscheiden sich ja bereits um je 1-2 sek)
Der Zeitversatz ist damit schon gegeben.
Bei so wenig Zeitversatz kann aber schon passieren dass einige Dinge parallel laufen, auch im Hinblick auf BlockingCall. Ich würde das mehr auseinanderziehen. Vllt. gefällt dir auch das neue Kommando "multiCmd". Schau es dir mal an.

Zitatat löst aus -> 50 Schnitt 3D Drucker ENERGY_Power -> executeAfterProc -> 51 Schnitt 3D Drucker ENERGY_Current -> executeAfterProc -> 52 Schnitt 3D Drucker Power5min -> executeAfterProc ->  53 Schnitt 3D Drucker alte Werte löschen -> done.
Würde diese Ordnung "ungern" verlieren - Gibt es Performance die dagegen sprechen, dann natürlich sofort.
Auch unter diesem Gesichtspunkt ist "multiCmd" wahrscheinlich hilfreich.

Alles in Allem muß meine Analyse nicht in jedem Falle zutreffen. Bevor du große Umbauten vornimmst, gehe langsam voran, starte z.B. mit dem executeBeforeProc und beobachte den Erfolg.
Danach Stück für Stück wie beschrieben.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 26 Januar 2024, 13:14:00
Zitat von: DS_Starter am 26 Januar 2024, 13:03:28Auch unter diesem Gesichtspunkt ist "multiCmd" wahrscheinlich hilfreich.
Alles in Allem muß meine Analyse nicht in jedem Falle zutreffen. Bevor du große Umbauten vornimmst, gehe langsam voran, starte z.B. mit dem executeBeforeProc und beobachte den Erfolg.
Danach Stück für Stück wie beschrieben.

Perfekt - ich danke Dir vielmals für die Aufklärung. Ich stell mal in das set DBLogging reopen 60 in das erste Device und schau mal wie sich die Log Einträge verändern. In der Zwischenzeit werde ich mir das multiCmd mal anschauen - auch mit der Beführchtung es nicht zu verstehen :-\  :))
Edit muss mal nachwerfen: So schwer scheint es gar nicht zu verstehen zu sein :D Ich glaube das ist ein sehr sehr mächtiger Befehl - gerade für solche / meine Zwecke ;)

Ich werde in jedem Fall berichten, was wo zu welchem Erfolg geführt hat (dauert aber ggf ein paar Tage) falls ich mehr umbauen muss, oder die "Analyse" länger dauert.

Vielen Dank nochmal
und VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: jnewton957 am 26 Januar 2024, 20:09:13
Hallo,
ich habe eine Frage zum Anhängen von Datenbankwerten an eine bestehende Datenbank (sqlite3 gem. wiki)

Nach unendlicher Arbeit ist es mir gelungen eine defekte fhem.db quasi wieder zum Leben zu erwecken. Zwischenzeitlich habe ich mit Start 11/2022 eine neue fhem.db.

ich habe mit DB Browser nun verschiedene sql per device erstellt bzw. könnte sicherlich auch eine sql exportieren.

Wie kann ich nun disjunkte historische Werte 2019-2022 in diese DB für einzelne devices nachtragen. Insbesondere Stromstatistikwerte wären für mich interessant.

Da ich nicht (erneut) Fehler mit der fhem.db machen möchte (eigenes try & error), bitte ich um Hilfe für dieses todo

Danke
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 26 Januar 2024, 20:35:55
Das Wichtigste bei allen Manipulationen ist immer! ein vorhandenes gültiges Backup der Datenbank!
Für SQLite hat Dbrep dafür den Befehl:

set <DbRep> dumpSQLite

Man kann natürlich auch FHEM stoppen und das File fhem.db mit Betriebssystem Werkzeugen sichern.
Weiterhin ist es ratsam DbLog für die Zeit des Importes zu pausieren. Dafür hat DbLog den Befehl:

set <DbLog> reopen xxxxxx

Du könntest also so vorgehen:

1. set <DbLog> reopen xxxxxx um die DB für die Zeit xxxxx zu isolieren
2. erstelle ein Backup mit set <DbRep> dumpSQLite
3. importiere deine Daten (mit DbRep oder separaten SQL's)

Wenn alles funktioniert hat, öffne DbLog wieder mit einem simplen "set <DbLog> reopen".
Bei Problemen restore die DB wieder mit "set <DbRep> restoreSQLite" und öffne danach DbLog wieder.

Mit dieser Prozedur solltest du auf der sicheren Seite sein.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: rolizer am 01 März 2024, 13:32:36
Hallo,
ich hab eine Frage zum Fehlerhandling von multiCmd. Erstmal vielen Dank Heiko für den immensen Aufwand und Zeit die du in das Tool steckst. Unglaublich, was mittlerweile alles möglich ist.

Ich hab ein multiCmd zum testen auf einer neuen FHEM gebaut, um nicht wieder mit einer 7GB großen Datenbank voller Datenschrott zu enden. Dabei fällt mir auf, wenn ein Step im cmdHash zum Fehler führt, werden die nächsten nicht weiter ausgeführt. Ist das gewollt?
{\
my $cmdhash = "{\
      1  => { cmd            => 'sqlCmd select count(*) from history'\
            },\
      2  => { timeOlderThan  => 'd:5',\
                timeDiffToNow  => 'd:7',\
                cmd              => 'reduceLog average'\
            },\
      3  => { timeOlderThan  => 'd:90',\
                timeDiffToNow  => 'd:91',\
                cmd              => 'reduceLog average=day'\
            },\
      4  => { timeOlderThan  => 'd:360',\
              device          => 'sysmon%,global',\
              cmd            => 'delEntries'\
            },\
      5  => { cmd            => 'sqlCmd select count(*) from history'\
            },\
    }";;\
fhem ("set DBRep.multiCmd.reduceLog multiCmd $cmdhash");;\
}
führt zu (letzte 3 Zeilen):

2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - get initial structure information of database "fhem", remaining attempts: 3
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Connectiontest to database mysql:database=fhem;host=localhost;port=3308 with user fhemuser
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Index Report_Idx exists. Check ok
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Initial data information retrieved - total time used: 0.0186 seconds
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - Connectiontest to db mysql:database=fhem;host=localhost;port=3308 successful
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - execute command before sqlCmd: 'set LogDB reopen 3600'
2024.03.01 01:00:00 2: LogDB - Connection closed until 02:00:00 (3600 seconds).
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - execute command after sqlCmd: 'set LogDB reopen'
2024.03.01 01:00:00 3: LogDB - Reopen requested
2024.03.01 01:00:00 2: DbRep DBRep.multiCmd.reduceLog - command message after sqlCmd: >Reopen executed.<
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - ###                    new reduceLog run                    ###
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - execute command before reduceLog: 'set LogDB reopen 3600'
2024.03.01 01:00:00 2: LogDB - Connection closed until 02:00:00 (3600 seconds).
2024.03.01 01:00:00 3: LogDB - Database disconnected by request.
2024.03.01 01:00:00 3: LogDB - Database disconnected by request.
2024.03.01 01:00:00 3: LogDB - SubProcess connected to fhem
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - reduce data older than: 2024-02-25 00:59:59, newer than: 2024-02-23 00:59:59
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - reduceLog requested with options:
average
INCLUDE -> Devs: % Readings: %
2024.03.01 01:00:00 3: LogDB - Database disconnected by request.
2024.03.01 01:00:00 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deleting 5606 records of day: 2024-02-24
2024.03.01 01:00:01 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 1000
2024.03.01 01:00:02 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 2000
2024.03.01 01:00:03 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 3000
2024.03.01 01:00:03 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 4000
2024.03.01 01:00:04 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-24 is: 5000
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating 131 records of day: 2024-02-24
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating progress of day: 2024-02-24 is: 100
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deleting 244 records of day: 2024-02-25
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-25 is: 100
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deletion progress of day: 2024-02-25 is: 200
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating 5 records of day: 2024-02-25
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - reduceLog finished. Rows processed: 6264, deleted: 5850, updated: 136
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - execute command after reduceLog: 'set LogDB reopen'
2024.03.01 01:00:05 3: LogDB - Reopen requested
2024.03.01 01:00:05 2: DbRep DBRep.multiCmd.reduceLog - command message after reduceLog: >Reopen executed.<
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - ###                    new reduceLog run                    ###
2024.03.01 01:00:05 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.01 01:00:05 2: DbRep DBRep.multiCmd.reduceLog - ERROR - The Timestamp of the oldest dataset (1706029700) is newer than specified end time (1701471599)
2024.03.01 01:00:06 3: LogDB - Database disconnected by request.
2024.03.01 01:00:06 3: LogDB - SubProcess connected to fhem

Step 4 bricht ab, weil er keine älteren Daten findet, aber der Step 5 wird nicht mehr ausgeführt.
Vielen Dank
Oli
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 01 März 2024, 13:57:16
Hallo Oli,

also explizit gewollt/eingebaut ist das nicht. Möglicherweise habe ich einen Rücksprung bei Abbruch übersehen.
Ich schaue mir das vllt. am WE schonmal an und melde mich wieder.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 02 März 2024, 21:45:47
Hallo Oli,

ich habe das Problem gefunden und gefixt.
Die version liegt zunächst in meinem contrib (siehe Fußtext). Du kannst die Version herunterladen, dein FHEM restarten und die Funktion testen.

LG,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 03 März 2024, 16:33:41
Hey Heiko,

ich hab mir die Funktion multicmd auch angeschaut und finde sie total cool (hat mir viele einzelne Devices entfernt).

Allerdings bekomme ich seit der Umstellung gelegentlich mal diese Meldung:

2024.03.02 03:23:37.596 2: DbRep SQL_DBrep_Device - ERROR - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 11966
oder
2024.03.02 13:41:00.129 1: DbRep SQL_DBrep_Device -> BlockingCall DbRep_averval pid:171276 Timeout: process terminated

Zeitlich würde ich dafür dieses Device vermuten ohne bisher weiter ins Detail zu gehen. (Verbose hatte ich zur Fehlersuche erhöht, es aber biser nicht provizieren können)

Internals:
   COMMAND    set SQL_DBrep_Device multiCmd {
        {
          1  => { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_gust',
                  cmd             => 'averageValue writeToDBInTime'
                },
        2  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'luminosity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          3  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_speed',
                  cmd             => 'averageValue writeToDBInTime'
                },
          4  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          5  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          6  =>  { timeDiffToNow  => 'd:3',
                  timeOlderThan   => 'd:2',
                  device          => 'Wetterstation',
                  reading         => 'luminosity,wind_gust,wind_speed,humidity,temperature',
                  cmd             => 'delEntries'
                },
          7  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          8  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          9  =>  { timeDiffToNow  => 'm:15',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'averageValue writeToDBInTime'
                },
          10  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'delEntries'
                },
          11  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity,temperature',
                  cmd             => 'delEntries'
                },

}
}
   DEF        +*00:15  set SQL_DBrep_Device multiCmd {
        {
          1  => { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_gust',
                  cmd             => 'averageValue writeToDBInTime'
                },
        2  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'luminosity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          3  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'wind_speed',
                  cmd             => 'averageValue writeToDBInTime'
                },
          4  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          5  =>  { timeDiffToNow  => 'm:15',
                  device          => 'Wetterstation',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          6  =>  { timeDiffToNow  => 'd:3',
                  timeOlderThan   => 'd:2',
                  device          => 'Wetterstation',
                  reading         => 'luminosity,wind_gust,wind_speed,humidity,temperature',
                  cmd             => 'delEntries'
                },
          7  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity',
                  cmd             => 'averageValue writeToDBInTime'
                },
          8  =>  { timeDiffToNow  => 'm:15',
                  device          => '     dev_EG_WZ_innen_temperatur',
                  reading         => 'temperature',
                  cmd             => 'averageValue writeToDBInTime'
                },
          9  =>  { timeDiffToNow  => 'm:15',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'averageValue writeToDBInTime'
                },
          10  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_LUX_innen',
                  reading         => 'illuminance',
                  cmd             => 'delEntries'
                },
          11  =>  { timeDiffToNow  => 'd:4',
                  timeOlderThan   => 'd:2',
                  device          => 'dev_EG_WZ_innen_temperatur',
                  reading         => 'humidity,temperature',
                  cmd             => 'delEntries'
                },

}
}
   FUUID      5e80a069-f33f-8d79-a867-e1060514c503b7ec
   FVERSION   90_at.pm:0.284400/2024-01-28
   NAME       at_DBrep_15Min_Werte
   NR         151
   NTM        16:37:30
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 16:37:30
   TIMESPEC   00:15
   TRIGGERTIME 1709480250
   TRIGGERTIME_FMT 2024-03-03 16:37:30
   TYPE       at
   eventCount 181
   READINGS:
     2024-03-03 16:22:30   state           Next: 16:37:30
Attributes:
   DbLogExclude .*
   alignTime  01:07:30
   group      Auslösungen < 1x Tag
   room       System->Datenbank
   verbose    5

Kann es der gleiche Bug sein, der oben gefixt wurde?

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 16:58:52
Hallo Andreas,

ZitatKann es der gleiche Bug sein, der oben gefixt wurde?
Nein. Da hatte ich aus einer Fehlerbehandlung einfach einen Rücksprung vergessen.

In deinem Fall vermute ich eher einen "Konflikt" mit DbLog. Für bestimmt Operationen muß die Anwendung die Tabelle sperren (Lock Table). Wenn du eine lange Kommandokette hast, kommt DbLog nicht zum Zug und wartet auf eine Gelegenheit reinzuspringen. Wenn es mal gelingt, und es sind viele Daten im Cache aufgelaufen, krallt sich DbLog die DB. DbRep muß nun warten um seinerseits die history zu sperren. Wenn das zu lange dauert, kommt mit "Lock wait timeout exceeded" der Timeout. Soweit meine Theorie.

Du kannst es überprüfen indem du vor dem Start von multiCmd im DbLog ein "set ... reopen 3600" ausführst.
Das sperrt DbLog für eine Stunde und DbRep hat die DB für sich. Wenn multiCmd durch ist, öffnest du DbLog wieder mit "set ... reopen".

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: rolizer am 03 März 2024, 20:30:40
sorry for confusion - hatte die falsche Datei geladen.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 20:50:03
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm

Oder du brauchst eigentlich nur auf den Link im Fußtext gehen und das Modul auswählen und mit dem Downloadbutton im Originalformat speichern (Windows Client).
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: rolizer am 03 März 2024, 21:14:16
Hallo,
sorry, Anfänger  :-[
Allerdings funktioniert das noch  immer nicht: mit verbose 4 und gleichem Multicmd kommt nach wie vor die folgende Meldung:
2024.03.03 21:04:35 2: DbRep DBRep.multiCmd.reduceLog - ERROR - The Timestamp of the oldest dataset (1706029700) is newer than specified end time (1701644399)
2024.03.03 21:04:35 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >4< start
2024.03.03 21:04:35 3: LogDB - Database disconnected by request.
2024.03.03 21:04:35 3: LogDB - Database disconnected by request.
2024.03.03 21:04:35 3: LogDB - SubProcess connected to fhem
Ein multiCmd index 5 taucht nicht auf.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 21:15:48
Die Meldung muß kommen, das ist klar.
Hast du auch restarted?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: rolizer am 03 März 2024, 21:20:15
via "shutdown restart", ja.
2024.03.03 21:02:38 0: Server started with 224 defined entities (fhem.pl:28484/2024-02-06 perl:5.036000 os:linux user:fhem pid:127418)sollte ich via systemctl?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 21:28:16
Nein, das reicht schon.
Hmmm, komisch.
Kannst du bitte den gesamten Kommandohash und den gesamten Logausdruck vom Lauf posten. Da muß ich mirgen nochmal suchen.

EDIt: Und bitte noch ein List von dem Device nach der Ausführung vom multiCmd.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 21:35:52
Ach lass mal, ich glaube ich weiß schon woran es noch hapert.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 21:40:46
Nein ... Sorry ich brauche die Infos doch. War gerade ein Holzweg.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: rolizer am 03 März 2024, 21:45:20
Hier zuerst das AT, das DbRep und das Log (verbose 4)

Internals:
   COMMAND    {\
my $cmdhash = "{\
      1  => { cmd             => 'sqlCmd select count(*) from history'\
            },\
      2  => { timeOlderThan   => 'd:5',\
                timeDiffToNow   => 'd:7',\
                cmd              => 'reduceLog average'\
            },\
      3  => { timeOlderThan   => 'd:90',\
                timeDiffToNow   => 'd:91',\
                cmd              => 'reduceLog average=day'\
            },\
      4  => { timeOlderThan   => 'd:360',\
              device          => 'sysmon%,global',\
              cmd             => 'delEntries'\
            },\
      5  => { cmd             => 'sqlCmd select count(*) from history'\
            },\
    }";;\
fhem ("set DBRep.multiCmd.reduceLog multiCmd $cmdhash");;\
}
   DEF        *01:00:00 {\
my $cmdhash = "{\
      1  => { cmd             => 'sqlCmd select count(*) from history'\
            },\
      2  => { timeOlderThan   => 'd:5',\
                timeDiffToNow   => 'd:7',\
                cmd              => 'reduceLog average'\
            },\
      3  => { timeOlderThan   => 'd:90',\
                timeDiffToNow   => 'd:91',\
                cmd              => 'reduceLog average=day'\
            },\
      4  => { timeOlderThan   => 'd:360',\
              device          => 'sysmon%,global',\
              cmd             => 'delEntries'\
            },\
      5  => { cmd             => 'sqlCmd select count(*) from history'\
            },\
    }";;\
fhem ("set DBRep.multiCmd.reduceLog multiCmd $cmdhash");;\
}
   FUUID      65ca34d8-f33f-fd93-bf66-ee965ab4cacd3dc0
   NAME       at.MultiCmd.DBaufraeumen
   NR         61
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 01:00:00
   TIMESPEC   01:00:00
   TRIGGERTIME 1709510400
   TRIGGERTIME_FMT 2024-03-04 01:00:00
   TYPE       at
   eventCount 2
   READINGS:
     2024-03-03 21:20:44   state           Next: 01:00:00
Attributes:
   DbLogExclude .*
   room       System->DB

Internals:
   DATABASE   fhem
   DEF        LogDB
   FUUID      65c9ff92-f33f-fd93-d13c-23c6751017ed43f9
   FVERSION   93_DbRep.pm:v8.53.2-s28525/2024-02-16
   LASTCMD    reduceLog average=day
   MODEL      Client
   NAME       DBRep.multiCmd.reduceLog
   NOTIFYDEV  global,DBRep.multiCmd.reduceLog
   NR         60
   NTFY_ORDER 50-DBRep.multiCmd.reduceLog
   ROLE       Client
   STATE      The Timestamp of the oldest dataset is newer than the specified time range
   TYPE       DbRep
   UTF8       1
   eventCount 18
   HELPER:
     DBLOGDEVICE LogDB
     GRANTS     DELETE,UPDATE,INSERT,SELECT,FILE
     IDRETRIES  2
     MINTS      2024-01-23 18:08:20
     PACKAGE    main
     VERSION    8.53.2
     CV:
       aggregation no
       aggsec     1
       destr      2023-12-03
       dsstr      2023-12-02
       epoch_seconds_end 1701644399
       mestr      12
       msstr      12
       testr      23:59:59
       tsstr      00:00:00
       wdadd      172800
       yestr      2023
       ysstr      2023
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2024-03-03 21:39:13   state           The Timestamp of the oldest dataset is newer than the specified time range
Attributes:
   DbLogExclude .*
   allowDeletion 0
   comment    <<<ganz viel Text>>>
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
   device     sysmon%,global
   event-on-update-reading state
   executeAfterProc set LogDB reopen
   executeBeforeProc set LogDB reopen 3600
   room       System->DB
   showproctime 1
   timeOlderThan d:360
   timeout    3600
   verbose    4

2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >1< start
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - -------- New selection ---------
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Command: sqlCmd select count(*) from history;
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Timestamp begin human readable: not set
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Timestamp end human readable: not set
2024.03.03 21:39:12 3: DbRep DBRep.multiCmd.reduceLog - execute command before sqlCmd: 'set LogDB reopen 3600'
2024.03.03 21:39:12 2: LogDB - Connection closed until 22:39:12 (3600 seconds).
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Database connect - user: fhemuser, UTF-8 option set: yes
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Database Character set is >utf8mb4_bin<
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - SQL execute: select count(*) from history;
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - SQL result: 19980
2024.03.03 21:39:12 3: DbRep DBRep.multiCmd.reduceLog - execute command after sqlCmd: 'set LogDB reopen'
2024.03.03 21:39:12 3: LogDB - Reopen requested
2024.03.03 21:39:12 2: DbRep DBRep.multiCmd.reduceLog - command message after sqlCmd: >Reopen executed.<
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >2< start
2024.03.03 21:39:12 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.03 21:39:12 3: DbRep DBRep.multiCmd.reduceLog - ###                    new reduceLog run                     ###
2024.03.03 21:39:12 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - -------- New selection ---------
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Command: reduceLog average
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - timeDiffToNow - year: , day: 7, hour: , min: , sec:
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Year 2024 is leap year
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - startMonth: 1 endMonth: 2 lastleapyear:  baseYear: 2024 diffdaylight:0 isdaylight:0
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - timeOlderThan - year: 0, day: 5, hour: 0, min: 0, sec: 0
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Year 2024 is leap year
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - startMonth: 0 endMonth: 1 lastleapyear: 2024 baseYear: 2024 diffdaylight:0 isdaylight:0
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - FullDay option: 0
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Time difference to current time for calculating Timestamp begin: 604801 sec
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Timestamp begin human readable: 2024-02-25 21:39:11
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Time difference to current time for calculating Timestamp end: 432001 sec
2024.03.03 21:39:12 4: DbRep DBRep.multiCmd.reduceLog - Timestamp end human readable: 2024-02-27 21:39:11
2024.03.03 21:39:12 3: DbRep DBRep.multiCmd.reduceLog - execute command before reduceLog: 'set LogDB reopen 3600'
2024.03.03 21:39:12 2: LogDB - Connection closed until 22:39:12 (3600 seconds).
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Database connect - user: fhemuser, UTF-8 option set: yes
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Database Character set is >utf8mb4_bin<
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - reduce data older than: 2024-02-27 21:39:11, newer than: 2024-02-25 21:39:11
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - reduceLog requested with options:
average
INCLUDE -> Devs: % Readings: %
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL prepare: DELETE FROM history WHERE (DEVICE=?) AND (READING=?) AND (TIMESTAMP=?) AND (VALUE=?)
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL prepare: DELETE FROM history WHERE (DEVICE=?) AND (READING=?) AND (TIMESTAMP=?) AND VALUE IS NULL
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL prepare: UPDATE history SET TIMESTAMP=?, EVENT=?, VALUE=? WHERE (DEVICE=?) AND (READING=?) AND (TIMESTAMP=?) AND (VALUE=?)
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL prepare: DELETE FROM history WHERE (DEVICE=?) AND (READING=?) AND (TIMESTAMP=?)
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL prepare: UPDATE history SET TIMESTAMP=?, EVENT=?, VALUE=? WHERE (DEVICE=?) AND (READING=?) AND (TIMESTAMP=?)
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - SQL execute: SELECT TIMESTAMP,DEVICE,'',READING,VALUE FROM history where  TIMESTAMP >= '2024-02-25 21:39:11' AND TIMESTAMP <= '2024-02-27 21:39:11' ORDER BY TIMESTAMP ASC;
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - reduceLog deleting 35 records of day: 2024-02-27
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - begin transaction
2024.03.03 21:39:13 3: LogDB - Database disconnected by request.
2024.03.03 21:39:13 3: LogDB - Database disconnected by request.
2024.03.03 21:39:13 3: LogDB - SubProcess connected to fhem
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - transaction committed
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - reduceLog (hourly-average) updating 4 records of day: 2024-02-27
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - begin transaction
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - UPDATE history SET TIMESTAMP=2024-02-27 21:30:00, EVENT=rl_av_h, VALUE=55.4206 WHERE DEVICE=sysmon_pi2 AND READING=cpu_temp AND TIMESTAMP=2024-02-27 21:27:21 AND VALUE=54.77
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - UPDATE history SET TIMESTAMP=2024-02-27 21:30:00, EVENT=rl_av_h, VALUE=955.5556 WHERE DEVICE=sysmon_pi2 AND READING=cpu_freq AND TIMESTAMP=2024-02-27 21:29:20 AND VALUE=1400
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - UPDATE history SET TIMESTAMP=2024-02-27 21:30:00, EVENT=rl_av_h, VALUE=0.0000 WHERE DEVICE=LogDB AND READING=CacheOverflowLastNum AND TIMESTAMP=2024-02-27 21:27:22 AND VALUE=0
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - UPDATE history SET TIMESTAMP=2024-02-27 21:30:00, EVENT=rl_av_h, VALUE=55.5525 WHERE DEVICE=sysmon_pi2 AND READING=cpu_temp_avg AND TIMESTAMP=2024-02-27 21:27:21 AND VALUE=55.5
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - transaction committed
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - reduceLog finished. Rows processed: 442, deleted: 35, updated: 4
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - execute command after reduceLog: 'set LogDB reopen'
2024.03.03 21:39:13 3: LogDB - Reopen requested
2024.03.03 21:39:13 2: DbRep DBRep.multiCmd.reduceLog - command message after reduceLog: >Reopen executed.<
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >3< start
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - ###                    new reduceLog run                     ###
2024.03.03 21:39:13 3: DbRep DBRep.multiCmd.reduceLog - ################################################################
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - -------- New selection ---------
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Command: reduceLog average=day
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - timeDiffToNow - year: , day: 91, hour: , min: , sec:
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Year 2024 is leap year
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - startMonth: 11 endMonth: 2 lastleapyear: 2024 baseYear: 2023 diffdaylight:0 isdaylight:0
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - timeOlderThan - year: 0, day: 90, hour: 0, min: 0, sec: 0
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Year 2024 is leap year
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - startMonth: 0 endMonth: 11 lastleapyear: 2024 baseYear: 2023 diffdaylight:0 isdaylight:0
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - FullDay option: 1
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Time difference to current time for calculating Timestamp begin: 7948801 sec
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Timestamp begin human readable: 2023-12-02 00:00:00
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Time difference to current time for calculating Timestamp end: 7862401 sec
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - Timestamp end human readable: 2023-12-03 23:59:59
2024.03.03 21:39:13 2: DbRep DBRep.multiCmd.reduceLog - ERROR - The Timestamp of the oldest dataset (1706029700) is newer than specified end time (1701644399)
2024.03.03 21:39:13 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >4< start
2024.03.03 21:39:13 3: LogDB - Database disconnected by request.
2024.03.03 21:39:13 3: LogDB - Database disconnected by request.
2024.03.03 21:39:13 3: LogDB - SubProcess connected to fhem
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 21:59:37
Danke.
Das Kommando 4 (delEntries) wird schon nicht ausgeführt.
In dem Device ist das Attr allowDeletion nicht gesetzt. Setze es mal auf 1.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: rolizer am 03 März 2024, 22:08:26
Danke! Das wars wohl:
2024.03.03 22:05:05 2: DbRep DBRep.multiCmd.reduceLog - ERROR - The Timestamp of the oldest dataset (1706029700) is newer than specified end time (1701644399)
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >4< start
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - -------- New selection ---------
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Command: delEntries
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - timeOlderThan - year: , day: 360, hour: , min: , sec:
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Year 2024 is leap year
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - startMonth: 0 endMonth: 2 lastleapyear: 2024 baseYear: 2023 diffdaylight:0 isdaylight:0
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - FullDay option: 0
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Timestamp begin human readable: 2024-01-23 18:08:20
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Time difference to current time for calculating Timestamp end: 31190401 sec
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Timestamp end human readable: 2023-03-08 22:05:04
2024.03.03 22:05:05 2: DbRep DBRep.multiCmd.reduceLog - ERROR - The Timestamp of the oldest dataset (1706029700) is newer than specified end time (1678309504)
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - multiCmd index >5< start
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - -------- New selection ---------
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Command: sqlCmd select count(*) from history;
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Timestamp begin human readable: not set
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Timestamp end human readable: not set
2024.03.03 22:05:05 3: DbRep DBRep.multiCmd.reduceLog - execute command before sqlCmd: 'set LogDB reopen 3600'
2024.03.03 22:05:05 2: LogDB - Connection closed until 23:05:05 (3600 seconds).
2024.03.03 22:05:05 3: LogDB - Database disconnected by request.
2024.03.03 22:05:05 3: LogDB - SubProcess connected to fhem
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Database connect - user: fhemuser, UTF-8 option set: yes
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - Database Character set is >utf8mb4_bin<
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.03 22:05:05 4: DbRep DBRep.multiCmd.reduceLog - SQL execute: select count(*) from history;
2024.03.03 22:05:06 4: DbRep DBRep.multiCmd.reduceLog - SQL result: 19984
2024.03.03 22:05:06 3: DbRep DBRep.multiCmd.reduceLog - execute command after sqlCmd: 'set LogDB reopen'
2024.03.03 22:05:06 3: LogDB - Reopen requested
2024.03.03 22:05:06 2: DbRep DBRep.multiCmd.reduceLog - command message after sqlCmd: >Reopen executed.<
2024.03.03 22:05:06 3: LogDB - Database disconnected by request.
2024.03.03 22:05:06 3: LogDB - Database disconnected by request.
2024.03.03 22:05:06 3: LogDB - SubProcess connected to fhem
2024.03.03 22:05:06 3: LogDB - Database disconnected by request.
2024.03.03 22:05:06 3: LogDB - Database disconnected by request.
2024.03.03 22:05:06 3: LogDB - SubProcess connected to fhem
Ich wusste nicht, dass verdichten funktioniert ohne allowDeletion, löschen aber nicht. Wieder was gelernt.
Das scheint es gewesen zu sein. Top!
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 03 März 2024, 22:12:48
Stimmt. Eigentlich müßte ich allowDeletion auch bei reduceLog verpflichtend definieren.
Aber das muß ich mal separat machen. Viele User würden jetzt plötzlich mit ihren Definitionen auf Fehler laufen wenn ich das "mal so nebenbei" ändere.

Ich checke die Version ein. Ist dann morgen früh im Update.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 04 März 2024, 09:24:23
Ey, mal ehrlich. Das Attribut "allowDeletion" ist genau so unnötig wie ein goldenes Fußkettchen.

Wenn ich als User ein "reduceLog" Task definiere, dann bin ich mir durchaus bewusst, dass dadurch Zeilen in der Datenbank gelösche werde, und ich gebe sogar selbst die Kriterien dafür an.

Da muss ich doch nicht noch extra ein Attribut setzen, um meinen Geisteszustand zu bestätigen.
Du kannst Dir nicht vorstellen, was mich dieser Mist schon an Nerven und Zeit gekostet hat.

Schaff das Attribut endlich ab!
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 04 März 2024, 11:37:21
Guten Morgen,

vielen Dank für den schnellen Lösungsvorschlag:

Zitat von: DS_Starter am 03 März 2024, 16:58:52Du kannst es überprüfen indem du vor dem Start von multiCmd im DbLog ein "set ... reopen 3600" ausführst.
Das sperrt DbLog für eine Stunde und DbRep hat die DB für sich. Wenn multiCmd durch ist, öffnest du DbLog wieder mit "set ... reopen".

Jetzt hab ich mal eine Frage kosmetischer Natur: Wenn ich o.g. ausführe, scheinen alle anderen Fehler weg zu sein. Allerdings wir mein Log voll gespamt mit:
2024.03.04 11:26:00.875 2: DbRep SQL_DBrep_Device - command message after averageValue: >Reopen executed.<
und
2024.03.04 11:26:02.004 2: DbRep SQL_DBrep_Device - command message after delEntries: >Reopen executed.<

Ich hab das entsprechende Device bereits aus Verbose 2 (damit eben wichtiger Fehler durchkommen. Für mich ist das ein Hinweis, dass die DB gesperrt wurde und geöffnet wurde - Kann man das irgendwie von Log 3 auf 2 "erzwingen" oder könntest Du direkt im Modul?

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2024, 12:41:54
ZitatSchaff das Attribut endlich ab!
Durchaus eine Variante. Fasse ich ins Auge.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2024, 12:51:14
ZitatJetzt hab ich mal eine Frage kosmetischer Natur: Wenn ich o.g. ausführe, scheinen alle anderen Fehler weg zu sein. Allerdings wir mein Log voll gespamt mit:
Als erste Variante kannst du im relevanten DbRep das verbose=1 setzen.
Weiterhin könntest du aber auf das Setzen der exec-Attribute im Device verzichten und das Schließen der DB für DbLog als Befehl im at hinterlegen.
Für das Öffnen bietet sich eventuell ein Notify an welches auf eine Ende-Meldung des 'sqlCmd select count(*) from history' reagiert. Muß man schauen ob ein brauchbares Event generiert wird.
Die 2. Variante würde ich bevorzugen als die DB ständig für DbLog zu schließen/öffnen.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 04 März 2024, 14:37:49
Zitat von: DS_Starter am 04 März 2024, 12:51:14Die 2. Variante würde ich bevorzugen als die DB ständig für DbLog zu schließen/öffnen.

Das hab ich nicht so ganz verstanden  ::)  ich muss die DB ja eh ständig zu und auf machen, damit der obere Fehler weg bleibt. Ob ich das nun mit der execute before / aufter oder einem notify mache, ist ja dann egal? 🤔

Vg
Andreas

P. S. Tippfehler sind der Autokorrektur am Handy zuzuschreiben ;)
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 04 März 2024, 14:53:57
Zitatich muss die DB ja eh ständig zu und auf machen...
Nein.
Was ich meine, du schließt DbLog mit dem "set ... reopen xxx" Kommando bevor du die ganze Kommandokette startest und lässt den close auch solange bis DbRep mit seinen ganzen Aktionen durch ist.
DbLog cached seine Daten in der Zwischenzeit.
Ist DbRep dann mit dem Summs fertig, wird DbLog mit "set ... reopen" Befehl wieder mit der DB verbunden.
Für den letzten Schritt braucht man einen passenden Trigger/Event um mit einem Notify zu reagieren oder man macht zeitgesteuert, wie auch immer.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 März 2024, 09:34:45
Guten Morgen,

in meinem contrib liegt eine neue DbRep Version zunächst zum Test.
Folgende Punkte sind umgesetzt:

- das Attribut allowDeletion ist obsolet
- die Beschränkung für DbRep Kommandos bei gesetzten DbLog "set ... reopen xxx" ist aufgehoben
- im multiCmd Kommandohash können die Attribute executeBeforeProc, executeAfterProc verwendet werden

@flummy1978, die letzen beiden Punkte können für deinen Case sehr hifreich sein. Damit kann die Kommandochain zum Beipiel folgendermaßen aufgebaut werden um zu Beginn und zum Ende das DbLog Management mit zu integrieren:

{
  1  => { executeBeforeProc => 'set LogDB reopen 900',
          timestamp_begin   => '2023-12-17 00:00:00',
  timestamp_end     => '2023-12-17 01:00:00',
  device            => 'SMA_Energymeter',
  reading           => 'Einspeisung_Wirkleistung_Zaehler',
  cmd               => 'countEntries history'
},
  2  => { timestamp_begin   => '2023-12-15 11:00:00',
  timestamp_end     => 'previous_day_end',
  device            => 'SMA_Energymeter',
  reading           => 'Einspeisung_Wirkleistung_Zaehler',
  cmd               => 'countEntries'
},
  3  => { timeDiffToNow     => 'd:2',
  readingNameMap    => 'COUNT',
  autoForward       => '{ ".*COUNT.*" => "Dum.Rep.All" }',
  device            => 'SMA_%,MySTP.*',
  reading           => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
  cmd               => 'countEntries history'
},
  4  => { timeDiffToNow     => 'd:2',
  readingNameMap    => 'SUM',
  autoForward       => '{ ".*SUM.*" => "Dum.Rep.All" }',
  device            => 'SMA_%,MySTP.*',
  reading           => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
  cmd               => 'sumValue'
},
  5  => { executeAfterProc => 'set LogDB reopen',
  cmd              => 'sqlCmd select count(*) from current'
},
}

!HINWEIS!  Beim Start kommen Meldungen der Art
"Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon. Please press "save config" when FHEM start is finished.

Ursache ist die Entfernung des allowDeletion Attributs sofern es gesetzt war.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 06 März 2024, 15:11:49
Hey Heiko,

vielen dank für die neue Version, wird grad getestet. Ich hab den vorherigen Teil noch nicht so verstanden gehabt und war noch in der Bearbeitungsphase ... mit exec before / after im multiCmd macht es die Sache natürlich NOCH einfacher - Das wird gleich getestet.

Zitat von: DS_Starter am 06 März 2024, 09:34:45Guten Morgen,

in meinem contrib liegt eine neue DbRep Version zunächst zum Test.
....
@flummy1978, die letzen beiden Punkte können für deinen Case sehr hifreich sein. Damit kann die Kommandochain zum Beipiel folgendermaßen aufgebaut werden um zu Beginn und zum Ende das DbLog Management mit zu integrieren:

!HINWEIS!  Beim Start kommen Meldungen der Art
"Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon. Please press "save config" when FHEM start is finished.

Ursache ist die Entfernung des allowDeletion Attributs sofern es gesetzt war.


Meldung taucht im Log auf - man bekommt außerhalb vom Log aber keinen Hinweis, dass was geändert wurde (daher auch nicht direkt ersichtlich - vielleicht für den normal Sterblichen den Fragezeichen Hinweis einbauen, wenn das nicht zu viel Umstand macht)

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 06 März 2024, 17:02:35
Zitatman bekommt außerhalb vom Log aber keinen Hinweis, dass was geändert wurde

Sagt doch  ... Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon ..
Wüßte nichts was ich da noch ergänzen könnte.

Das betrifft natürlich nur das entfernte Attribut.
Die Ergänzungen bzgl. multiCmd findet man natürlich in der Hilfe und es kommmt auch ein Verweis in die Update.Txt damit man den Hinweis im regulären Update auch sieht.

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: uwirt am 07 März 2024, 10:39:32
Ich bekomme immer wieder dieselbe Fehlermeldung im Zusammenhang mit fastSTart Attribut:

LASTCMD    initial database connect stopped due to attribute 'fastStart'

define repdb DbRep logdb
attr repdb averageCalcForm avgDailyMeanGWSwithGTS
attr repdb devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr repdb device Mean_Temp_outside
attr repdb executeAfterProc set logdb reopen
attr repdb executeBeforeProc set logdb reopen 86400
attr repdb fastStart 1
attr repdb reading state
attr repdb room DBLog
attr repdb showproctime 1
attr repdb timestamp_begin current_year_begin
attr repdb timestamp_end previous_day_end
attr repdb userExitFn saveGTS
#   DATABASE   fhem
#   DEF        logdb
#   FUUID      65e841ba-f33f-c144-4162-bc12999b8dae2a68
#   FVERSION   93_DbRep.pm:v8.53.2-s28590/2024-03-03
#   LASTCMD    initial database connect stopped due to attribute 'fastStart'
#   MODEL      Client
#   NAME       repdb
#   NOTIFYDEV  global,repdb
#   NR         147
#   NTFY_ORDER 50-repdb
#   ROLE       Client
#   STATE      initialized
#   TYPE       DbRep
#   UTF8       0
#   HELPER:
#     DBLOGDEVICE logdb
#     IDRETRIES  3
#     PACKAGE    main
#     VERSION    8.53.2
#   READINGS:
#     2024-03-07 10:33:11   state           initialized
#
setstate repdb initialized
setstate repdb 2024-03-07 10:33:11 .associatedWith Mean_Temp_outside
setstate repdb 2024-03-07 10:33:11 state initialized


Habe ich da was vergessen?

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 07 März 2024, 10:46:14
Das ist keine Fehlermeldung sondern die Info dass beim Start zunächst keine DB Verbindung aufgebaut wurde. Ist auch nicht neu. fastStart 1 ist schon lange Standard, du kannst das Attr löschen und nur auf explizit 0 setzen wenn du eine sofortige Verbindung haben willst.

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 08 März 2024, 15:44:09
@all,

Morgen früh ist die neue DbRep Version im Update enthalten.
Folgende Punkte sind umgesetzt:

- das Attribut allowDeletion ist obsolet
- die Beschränkung für DbRep Kommandos bei gesetzten DbLog "set ... reopen xxx" ist aufgehoben
- im multiCmd Kommandohash können die Attribute executeBeforeProc, executeAfterProc verwendet werden
- DbRep ist für die Verwendung von MariaDB Perl-Treibern (DBD::MariaDB) vorbereitet und kann damit arbeiten sobald DbLog sie (in Kürze) unterstützt

Noch einmal der HINWEIS:
Die Meldungen

"Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon. Please press "save config" when FHEM start is finished."
sind kein Fehler, sondern ein Hinweis und eine Aufforderung das zu tun was geschrieben steht, nämlich die Konfiguration sichern wenn der Restart beendet ist.
Diese Meldungen kommen dann auch nicht wieder.

LG


Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 11 März 2024, 00:35:36
Hallo Heiko,
vielen Dank für Deinen Mut zur Umsetzung der Hash-Steuerung.
Jetzt kommen natürlich die Fragen zur skripttypischen Beeinflussung des Ablaufs (Bedingungen, Sprünge, Einsprung an einer Hash-Element-Nr., Aussprung bei einem Hash-Element, ... ). In meinem Ablauf werden datumsabhängig unterschiedliche SQL-Befehls-Sequenzen durchlaufen.
Wie kann in einem cmd ein sqlCmd mit where der Spaltennamen in Hochkomma angeschrieben werden, z.B. für select value from history where device = 'beispiel' Könnte dafür ein Sonderzeichen gesetzt werden, das intern im SQL-Befehl wieder in ein Hochkomma umgewandelt wird?
Viele Grüße,
Thome
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 März 2024, 20:02:27
Hallo Thome,

hier zwei Syntax Varianten wie du sqlCmd schreiben könntest:

{
  1  => { cmd => 'sqlCmd select count(*) from current where device = "SMA_Energymeter"'
        },
  2  => { cmd => qq{sqlCmd select count(*) from current where device = 'SMA_Energymeter'}
        },
}

Bezüglich einer Script (ähnlichen) Steuerung hätte ich evtl. eine vage Vorstellung einer Umsetzbarkeit.
Könntest du mir ein praktisches Beipiel eine Use Cases posten?

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 11 März 2024, 20:43:28
@all,
ich verschiebe dieses Thema jetzt nach "Automatisierung" um das Modul im gleichen Forum wie DbLog zu supporten.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 12 März 2024, 23:10:33
Hallo Heiko,
ich starte einen Hash-gestützten Ablauf täglich nach Mitternacht, ca. 200 DB-Operationen verarbeiten Daten des Tages (Wetter, Hausstatus, Kraftstoffpreise, Energie-Verbrauchswerte und deren Kosten, etc.). Nach dem Monatswechsel wäre der Ablauf nahezu gleich, jedoch kommen ein paar DB-Operationen zusätzlich für die Monatswerte hinzu.
Als Lösung müsste ich einen zusätzlichen Ablauf mit teilweise identischen DB-Operationen vom täglichen Ablauf aufrufen.
Oder der Ablauf erlaubt das Überspringen einiger Hash-Elemente, dann ließe sich ein einziger Ablauf pflegen.
BTW: im Hash sqlCmd wird bei §timestamp_end§ das § als Fehler angezeigt.
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 März 2024, 10:19:38
Hallo Thowe,

danke für die Info. Meinst du das unten dargestellte Problem oder etwas anderes in Bezug auf "Fehler bei §timestamp_end§"?

2024.03.13 10:16:23.195 4: DbRep Rep.LogDB1 - multiCmd index >1< start
2024.03.13 10:16:23.206 4: DbRep Rep.LogDB1 - -------- New selection ---------
2024.03.13 10:16:23.206 4: DbRep Rep.LogDB1 - Command: sqlCmd select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP < "§timestamp_end§";
2024.03.13 10:16:23.207 4: DbRep Rep.LogDB1 - Timestamp begin human readable: not set
2024.03.13 10:16:23.207 4: DbRep Rep.LogDB1 - Timestamp end human readable: not set
2024.03.13 10:16:23.275 4: DbRep Rep.LogDB1 - adminCredentials successfully read from file
2024.03.13 10:16:23.276 4: DbRep Rep.LogDB1 - Database Model: MYSQL
2024.03.13 10:16:23.277 4: DbRep Rep.LogDB1 - Database connect - user: root, UTF-8 option set: yes
2024.03.13 10:16:23.280 4: DbRep Rep.LogDB1 - Communication between Client and Server will be compressed
2024.03.13 10:16:23.281 4: DbRep Rep.LogDB1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.13 10:16:23.283 4: DbRep Rep.LogDB1 - Database Character set is >utf8mb4_bin<
2024.03.13 10:16:23.283 4: DbRep Rep.LogDB1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.13 10:16:23.284 1: PERL WARNING: Use of uninitialized value $rsn in concatenation (.) or string at ./FHEM/93_DbRep.pm line 7310.
2024.03.13 10:16:23.285 4: DbRep Rep.LogDB1 - SQL execute: select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP < "''";
2024.03.13 10:16:26.749 4: DbRep Rep.LogDB1 - SQL result: 0

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 13 März 2024, 18:52:25
Hallo Heiko,
die Fehlermeldung tritt folgender Definition von at im DEF-Editor auf:
+*00:01:00 {
  my $cmdhash =
  "{
      1  => { timestamp_end  => 'previous_day_end',
              device          => 'Stromkosten.HH_kWh',
              reading        => 'state',
              autoForward    => '{ ".*" => "Stromkosten.HH_kWh" }',
              cmd            => 'sqlCmd select value from history where device = "Stromkosten.HH_kWh" and timestamp <= §timestamp_end§ order by timestamp desc limit 1'
            },
    }";
    fhem ("set Rep_test_dev multiCmd $cmdhash");
    }
Die Fehlermeldung weist an die Position vom §:
Unrecognized character \xC2; marked by <-- HERE after estamp <= <-- HERE near column 364 at (eval 2424) line 8.
Ich vermute ein Codierproblem, neu schreiben hat keine Verbesserung gebracht. Hast Du einen Tipp?

Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 13 März 2024, 19:13:46
autoForward    => '{ ".*" => "Stromkosten.HH_kWh" }',
Das ".*" als hash key sieht irgendwie komisch aus.
Hast Du mal versucht, den . und den * zu escapen?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 13 März 2024, 20:52:35
Hallo betateilchen und Heiko,
ich teste gerne ;D
Zusammenfassung der Ergebnisse:
- in autoForward und cmd darf kein Device-Name mit . enthalten sein
- im cmd mit '....' dürfen keine Anführungszeichen bei der where-clause "" stehen. Mit qq{   ... where device = 'name'  ...} funktioniert es, auch mit dem §Platzhalter§.
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 März 2024, 21:30:27
Hallo Thowe,
Zitat- in autoForward und cmd darf kein Device-Name mit . enthalten sein
- im cmd mit '....' dürfen keine Anführungszeichen bei der where-clause "" stehen. Mit qq{   ... where device = 'name'  ...} funktioniert es, auch mit dem §Platzhalter§.
hmm, ich habe diese Dinge mit folgendem Hash getestet:
{
  1  => {
          timestamp_begin => "2024-03-01 12:00:00",
          autoForward     => '{ ".*ResultRow.*" => "Dum.Rep.All" }',
          cmd             => 'sqlCmd select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP > "§timestamp_begin§"'
        },
}

Funktioniert einwandfrei und die generierten Readings werden per autoforeward auch verteilt:

2024.03.13 21:24:36.976 4: DbRep Rep.CPU - multiCmd index >1< start
2024.03.13 21:24:37.119 4: DbRep Rep.CPU - SQL online formatted: select count(*)
from history
where device = "SMA_Energymeter"
  and TIMESTAMP > "§timestamp_begin§";
2024.03.13 21:24:37.136 4: DbRep Rep.CPU - -------- New selection ---------
2024.03.13 21:24:37.138 4: DbRep Rep.CPU - Command: sqlCmd select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP > "§timestamp_begin§";
2024.03.13 21:24:37.140 4: DbRep Rep.CPU - FullDay option: 0
2024.03.13 21:24:37.141 4: DbRep Rep.CPU - Timestamp begin human readable: 2024-03-01 12:00:00
2024.03.13 21:24:37.142 4: DbRep Rep.CPU - Timestamp end human readable: 2024-03-13 21:24:37
2024.03.13 21:24:37.227 4: DbRep Rep.CPU - Database Model: MYSQL
2024.03.13 21:24:37.230 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.03.13 21:24:37.235 4: DbRep Rep.CPU - Communication between Client and Server will be compressed
2024.03.13 21:24:37.236 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.13 21:24:37.238 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.03.13 21:24:37.239 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.13 21:24:37.240 4: DbRep Rep.CPU - SQL execute: select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP > "'2024-03-01 12:00:00'";
2024.03.13 21:24:40.519 4: DbRep Rep.CPU - SQL result: 3893576
2024.03.13 21:24:40.524 4: Rep.CPU - Forward reading "SqlResultRow_1" to "Dum.Rep.All:SqlResultRow_1"
2024.03.13 21:24:40.537 4: Rep.CPU - Forward reading "SqlResultRow_2" to "Dum.Rep.All:SqlResultRow_2"

Aktuellste DbRep Version 93_DbRep.pm:v8.53.5-s28638/2024-03-11.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 März 2024, 21:38:54
Auch diese Variante:

{
  1  => {
          timestamp_begin => '2024-03-01 12:00:00',
          autoForward     => '{ ".*ResultRow.*" => "Dum.Rep.All" }',
          cmd             => 'sqlCmd select count(*) from history where device = "Dum.Energy" and TIMESTAMP > §timestamp_begin§'
        },
}

läuft einwandfrei:

2024.03.13 21:36:18.466 4: DbRep Rep.CPU - multiCmd index >1< start
2024.03.13 21:36:18.595 4: DbRep Rep.CPU - SQL online formatted: select count(*)
from history
where device = "Dum.Energy"
  and TIMESTAMP > §timestamp_begin§;
2024.03.13 21:36:18.614 4: DbRep Rep.CPU - -------- New selection ---------
2024.03.13 21:36:18.614 4: DbRep Rep.CPU - Command: sqlCmd select count(*) from history where device = "Dum.Energy" and TIMESTAMP > §timestamp_begin§;
2024.03.13 21:36:18.615 4: DbRep Rep.CPU - FullDay option: 0
2024.03.13 21:36:18.616 4: DbRep Rep.CPU - Timestamp begin human readable: 2024-03-01 12:00:00
2024.03.13 21:36:18.616 4: DbRep Rep.CPU - Timestamp end human readable: 2024-03-13 21:36:18
2024.03.13 21:36:18.688 4: DbRep Rep.CPU - Database Model: MYSQL
2024.03.13 21:36:18.690 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.03.13 21:36:18.693 4: DbRep Rep.CPU - Communication between Client and Server will be compressed
2024.03.13 21:36:18.693 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.13 21:36:18.695 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.03.13 21:36:18.696 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.13 21:36:18.696 4: DbRep Rep.CPU - SQL execute: select count(*) from history where device = "Dum.Energy" and TIMESTAMP > '2024-03-01 12:00:00';
2024.03.13 21:36:20.686 4: DbRep Rep.CPU - SQL result: 123887
2024.03.13 21:36:20.691 4: Rep.CPU - Forward reading "SqlResultRow_1" to "Dum.Rep.All:SqlResultRow_1"
2024.03.13 21:36:20.700 4: Rep.CPU - Forward reading "SqlResultRow_2" to "Dum.Rep.All:SqlResultRow_2"
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 13 März 2024, 21:48:09
Und jetzt auch noch diese Variante:

{
  1  => {
          timestamp_begin => '2024-03-01 12:00:00',
          autoForward     => '{ ".*" => "Dum.Rep.All" }',
          cmd             => 'sqlCmd select count(*) from history where device = "Dum.Energy" and TIMESTAMP > §timestamp_begin§'
        },
}

Problemlos ...

2024.03.13 21:46:54.695 4: DbRep Rep.CPU - multiCmd index >1< start
2024.03.13 21:46:54.841 4: DbRep Rep.CPU - SQL online formatted: select count(*)
from history
where device = "Dum.Energy"
  and TIMESTAMP > §timestamp_begin§;
2024.03.13 21:46:54.855 4: Rep.CPU - Forward reading "state" to "Dum.Rep.All:state"
2024.03.13 21:46:54.868 4: DbRep Rep.CPU - -------- New selection ---------
2024.03.13 21:46:54.869 4: DbRep Rep.CPU - Command: sqlCmd select count(*) from history where device = "Dum.Energy" and TIMESTAMP > §timestamp_begin§;
2024.03.13 21:46:54.870 4: DbRep Rep.CPU - FullDay option: 0
2024.03.13 21:46:54.871 4: DbRep Rep.CPU - Timestamp begin human readable: 2024-03-01 12:00:00
2024.03.13 21:46:54.872 4: DbRep Rep.CPU - Timestamp end human readable: 2024-03-13 21:46:54
2024.03.13 21:46:54.950 4: DbRep Rep.CPU - Database Model: MYSQL
2024.03.13 21:46:54.952 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2024.03.13 21:46:54.957 4: DbRep Rep.CPU - Communication between Client and Server will be compressed
2024.03.13 21:46:54.958 4: DbRep Rep.CPU - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.13 21:46:54.960 4: DbRep Rep.CPU - Database Character set is >utf8mb4_bin<
2024.03.13 21:46:54.962 4: DbRep Rep.CPU - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.13 21:46:54.963 4: DbRep Rep.CPU - SQL execute: select count(*) from history where device = "Dum.Energy" and TIMESTAMP > '2024-03-01 12:00:00';
2024.03.13 21:46:58.547 4: DbRep Rep.CPU - SQL result: 123948
2024.03.13 21:46:58.550 4: Rep.CPU - Forward reading "sqlCmd" to "Dum.Rep.All:sqlCmd"
2024.03.13 21:46:58.560 4: Rep.CPU - Forward reading "sqlResultNumRows" to "Dum.Rep.All:sqlResultNumRows"
2024.03.13 21:46:58.572 4: Rep.CPU - Forward reading "SqlResultRow_1" to "Dum.Rep.All:SqlResultRow_1"
2024.03.13 21:46:58.584 4: Rep.CPU - Forward reading "SqlResultRow_2" to "Dum.Rep.All:SqlResultRow_2"
2024.03.13 21:46:58.634 4: Rep.CPU - Forward reading "state" to "Dum.Rep.All:state"
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 14 März 2024, 00:00:06
Hallo Heiko,
Danke für die Verifizierungen, die mir nicht gelingen wollen.
Im DEF-Editor steht bei mir
+*00:01:00 {
   my $cmdhash =
   "{
      1   => {    timestamp_end   => 'previous_day_end',
              device          => 'Stromkosten.HH_kWh',
                        reading         => 'state',
                        autoForward     => '{ ".*SqlResultRow_2.*" => "Stromkosten.HH_kWh" }',
            cmd              => 'sqlCmd select value from history where device = "Stromkosten.HH_kWh" and timestamp <= "§timestamp_end§" order by timestamp desc limit 1'
             }
    }";
    fhem ("set Rep_test_dev multiCmd $cmdhash");
}

und erhalte ich als FehlermeldungCan't find string terminator "'" anywhere before EOF at (eval 35383) line 8.

Entferne ich im o.g. Hash die Anführungsstriche im SQL-Platzhalter "§timestamp_end§", erhalte ich als Fehlermeldung
Unrecognized character \xC2; marked by <-- HERE after estamp <= <-- HERE near column 382 at (eval 35754) line

Wie können zwei FHEM-Installationen so unterschiedliche Eigenschaften haben?
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 14 März 2024, 00:08:34
Einen Fehler sehe ich.
Entferne erstmal die Anführungsstriche die den Hash (eigentlich ist eine Hashreferenz) umfassen:

  my $cmdhash =
  "{
      ....
    }"

Und dann update auf die aktuellste Version falls noch nicht geschehen.

Als weiteren Test führe den Hash direkt im DbRep multiCmd aus. Einfach dort reinkopieren:

{
  1 => { timestamp_end   => 'previous_day_end',
         device          => 'Stromkosten.HH_kWh',
         reading         => 'state',
         autoForward     => '{ ".*SqlResultRow_2.*" => "Stromkosten.HH_kWh" }',
         cmd              => 'sqlCmd select value from history where device = "Stromkosten_HH.kWh" and timestamp <= "§timestamp_end§" order by timestamp desc limit 1'
       }
}
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 14 März 2024, 12:49:56
Hallo Heiko,
Danke für die Unterstützung!
Die Problemlösung: Mit dem Umweg über eine String-Variable müssen die Anführungszeichen in der Hash-Struktur escaped werden. Beispiel:
+*00:01:00 {
   my $cmdhash =
   "{
      1   => {    timestamp_end   => 'previous_day_end',
                  device          => 'Stromkosten.HH_kWh',
                 reading         => 'state',
                autoForward     => '{\".*SqlResultRow_2.*\" => \"Stromkosten.HH_kWh => state\"}',
                 cmd             => 'sqlCmd select value from history where device = \"Stromkosten.HH_kWh\" and timestamp <= §timestamp_end§ order by timestamp desc limit 1'
             },
    }";
    fhem ("set Rep_test_dev multiCmd $cmdhash");
}

Zur Sicherheit noch die Fragen: Gewährleistet der Ablauf, dass bei einem autoForward das Device den neuen Wert hat, bevor die nächste DbRep-Anweisung im multiCmd ausgeführt wird? Gilt gleiches auch für executeAfterProc?
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 15 März 2024, 07:46:09
Hallo Heiko,
nur ein Gedanke:
Der hash-definierte Ablauf kann als zusammenhängender gerichteter Graph aufgefasst werden. Knoten sind Hash-Elemente 1,2,...,n. Mit den Kanten kann bestimmt werden, über welche Knoten der Weg läuft. Soll ein Teilgraph übersprungen werden, haben wir eine Splitsituation. Zur Entscheidung, welcher Weg genommen wird, muss eine Bedingung geprüft werden. Im einfachsten Fall ist der Weg eine ,,Knotenumgehung" zum nächsten Knoten. Falls der einzelne Knoten Träger einer Kantenbedingung wäre, würden von einem Startknoten mehrere Wege kaskadiert entlang der Knotennummern zu prüfen sein.
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 März 2024, 08:25:28
Morgen Thowe,

ZitatDie Problemlösung: Mit dem Umweg über eine String-Variable müssen die Anführungszeichen in der Hash-Struktur escaped werden.
Würdest du die äußeren Anführungszeichen ( my $cmdhash =  "{ .... }" ) weglassen, bräuchtest du das escapen nicht.  ;)

Zitatnur ein Gedanke:
Der hash-definierte Ablauf kann als zusammenhängender gerichteter Graph aufgefasst werden. Knoten sind Hash-Elemente 1,2,...,n.
Ja, diesen Gedanken würde ich verfolgen.
Es ist zu beachten dass ein ausgeführter Knoten aus dem Hash entfernt wird (geschieht auch jetzt). Damit ist gewährleistet sich keine Endlosschleifen zu erstellen.
Ich versuche mich an einem ersten Testentwurf sobald ich dazu komme.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 15 März 2024, 12:27:45
Hallo Heiko,
ich hatte mit weggelassenen Quotes getestet, muss wohl noch einen Fehler gemacht haben.
Zur Sicherheit noch die Fragen: Gewährleistet der Ablauf, dass bei einem autoForward das Device den neuen Wert hat, bevor die nächste DbRep-Anweisung im multiCmd ausgeführt wird? Gilt gleiches auch für executeAfterProc?
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 15 März 2024, 12:38:09
Hallöchen,

irgendwie bin ich aktuell mit der Änderung nach der Umstellung und einer nahezu leeren DB noch nicht so ganz glücklich.... (liegt aber zu 99,99999999999999% an mir)

Sperre ich die DB mit "reopen ...." werde ich alle 15 Min mit

DbRep SQL_DBrep_Device - command message after averageValue: >Reopen executed.<im Log zugespamt. Das Verbose für das Device auf <2 möchte ich nicht unbedingt setzen, weil ich sonst solche "Fehler" (und wie den folgenden) nicht erkennen würde. Ja es läuft, aber ich würde es gern ohne Fehler haben und nicht nur "läuft irgedwie"

Nachdem ich das reopen wieder rausgenommen habe und das Device lediglich mit
set SQL_DBrep_Device multiCmd {...}läuft, kommt ständig (unregelmäßig) die Meldung:
2024.03.15 12:08:53.831 2: DbRep SQL_DBrep_Device - ERROR - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 11932.
Hast Du nen Tipp für mich, wie ich mich der Fehlerursache nähern kann? Für das Grundverständnis:

In meinem Aufbau ist es so, dass einige Strom, (verbrauch), Temperatur, Helligkeit Infos usw. geloggt. Die allermeisten davon bleiben nur für 3-5 Tage in der Masse der Daten der Rest wird gelöscht. Alle 15 min wird ein Schnitt von einigen Daten erstellt, die dann für länger beibehalten werden. Ich gehe davon aus, dass die o.g. Fehlermeldung zu 99% von dem 15 min at kommt, das mit multiCmd arbeitet und alle Befehle nacheinander probiert.(Wenn ich oben die Sperre mit Reopen einbaue, kommt nämlich die zweite Meldung deutlich seltener aber eben auch ab und zu mal)

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 März 2024, 13:14:16
@Thowe,
bin noch eine Antwort schuldig

Zitatgewährleistet der Ablauf, dass bei einem autoForward das Device den neuen Wert hat, bevor die nächste DbRep-Anweisung im multiCmd ausgeführt wird? Gilt gleiches auch für executeAfterProc?
Ja das ist gewährleistet sofern alles richtig eingestellt ist.

@flummy1978,
ZitatSperre ich die DB mit "reopen ...." werde ich alle 15 Min mit

Code Auswählen
DbRep SQL_DBrep_Device - command message after averageValue: >Reopen executed.<
im Log zugespamt. Das Verbose für das Device auf <2 möchte ich nicht unbedingt setzen, weil ich sonst solche "Fehler" (und wie den folgenden) nicht erkennen würde. Ja es läuft, aber ich würde es gern ohne Fehler haben und nicht nur "läuft irgedwie"
Nach kurzer Überlegung halte ich es für angebracht die aus den execafter/before resultierenden Meldungen auf verbose 3 setze. So essntiell sind sie im Normalfall nicht und du kannst das DbRep mit verbose 2 betreiben ohne wichtige Meldungen zu verpassen.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 15 März 2024, 20:35:36
Hallo Heiko,
das DbLogInclude beim autoForward in ein Dummy wird erst mit Verspätung ausgeführt (ich vermute: DbLog-Commit nach DbRep-Beendigung, s. reopen-Thema). Dadurch entfallen wohl auch Lösungen weg wie
executeAfterProc = {fhem("set Rep_dummy sqlCmd insert into history values (§timestamp_end§,'Dummydev','DUMMY','calculated','state','".(ReadingsVal("Dummydev","state",0)."','')")}Siehst Du eine Möglichkeit, in einem Hash-Ablauf ein Device-Reading in die DB zu schreiben, das vom nächsten Ablaufschritt verarbeitet werden kann? Commit  erzwingen mit executeBeforeAfter?
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 15 März 2024, 21:03:13
Hallo Thowe,

das geht so nicht weil ein "set Rep_dummy sqlCmd ..." nichblockierend asynchron arbeitet.
Wenn du sowas machen möchtest, musst du das blockierende "get ... sqlCmdBlocking ..." verwenden.
Lass dich durch das get nicht irritieren, ist nur damit der User nicht "zufällig" den falschen Setter benutzt.
Denk daran dass sqlCmdBlocking synchron arbeitet, die DB Zeit also dein FHEM beeinflusst.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 16 März 2024, 12:37:17
Hallo Heiko,

es gab vor einiger Zeit schonmal die Diskussion, dass beim Setzen von DbRep-Attributen der im Attribut angegeben perl Code im eval sofort ausgeführt wird. Damals war das Thema "Syntaxprüfung bei der Angabe von perl Code in Attributwerten".

Nun weiß ich nicht mehr, wie bzw. ob die Geschichte damals gelöst wurde.

Heute habe ich eine ganze Weile gebraucht, um herauszufinden, woher in meinem FHEM-Log eine Debug Meldung immer beim FHEM Start kommt, die mir die Uhrzeit ins Log schreibt. Am Ende bin darauf gekommen, dass das beim Setzen eines Attributwertes execute(After|Before)Proc passiert. Dort hatte ich "{Debug $hms}" eingetragen.

2024.03.16 10:11:33 0: Server shutdown
2024.03.16 10:11:37 1: stacktrace:
2024.03.16 10:11:37 1:     main::Debug                         called by ./FHEM/93_DbRep.pm (1616)
2024.03.16 10:11:37 1:     main::DbRep_Attr                    called by fhem.pl (3985)
2024.03.16 10:11:37 1:     main::CallFn                        called by fhem.pl (3205)
2024.03.16 10:11:37 1:     main::CommandAttr                   called by fhem.pl (1282)
2024.03.16 10:11:37 1: DEBUG>{Debug $hms}
2024.03.16 10:11:37 1: stacktrace:
2024.03.16 10:11:37 1:     main::Debug                         called by (eval 260) (1)
2024.03.16 10:11:37 1:     (eval)                              called by ./FHEM/93_DbRep.pm (1617)
2024.03.16 10:11:37 1:     main::DbRep_Attr                    called by fhem.pl (3985)
2024.03.16 10:11:37 1:     main::CallFn                        called by fhem.pl (3205)
2024.03.16 10:11:37 1:     main::CommandAttr                   called by fhem.pl (1282)
2024.03.16 10:11:37 1: DEBUG>10:11:37
2024.03.16 10:11:38 0: Featurelevel: 6.3

Ist das wirklich so gewollt?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2024, 12:49:07
Hallo Udo,

ZitatAm Ende bin darauf gekommen, dass das beim Setzen eines Attributwertes execute(After|Before)Proc passiert. Dort hatte ich "{Debug $hms}" eingetragen.
Du hast damals mit geholfen zu ergründen ob/wieso die Variable $hms in execute(After|Before)Proc durch einen User nicht verwendet werden konnte. Das war der Kontext.

Es ist natürlich ein berechtigter Hinweis/Einwand dass der Ausdruck bei Start von FHEM (respektive dem Setzen des Attr beim Start) nicht ausgeführt werden sollte.
Habe schon eine Idee die ich mir anschaue und eine Korrektur einbaue.

Danke für den Hinweis.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 16 März 2024, 12:52:15
Hallo Heiko,
Danke für den Tipp und Deine Geduld. Mittlerweile ist die Migration ins Hash sehr komplex geworden. Ich fange mal mit dem Basis-Problem an: 
Ich versuche vergeblich Deinen Tipp, die umfassenden Anführungszeichen sowie die Escapes wegzulassen, umzusetzen. Bei mir erzeugt folgender Eintrag im DEF-Editor des at-Devices
+*00:01:00 {
   my $cmdhash =
   {
      1  => { timestamp_begin => 'current_day_begin',
              timestamp_end   => 'current_day_end',
              device          => 'HH_Tagesenergie',
              reading         => 'state',
              autoForward     => '{".*HH_Tagesenergie__state__MAX.*" => "Tagesgesamtenergie_HH => state"}',
              cmd             => 'maxValue'
            },
     
    };
    fhem ("set Rep_test_dev multiCmd $cmdhash");
}
bei verbose 5 nur folgende Fehlermeldung
2024.03.16 12:32:37 3: set Rep_test_dev multiCmd HASH(0x75b10a0) : The syntax of 'multiCmd' is wrong. See command reference.
2024.03.16 12:32:37 3: Rep_Kettenprozess: The syntax of 'multiCmd' is wrong. See command reference.
Das/der Hash in Rep_test_dev als multiCmd ausgeführt funktioniert. Wo kann der Fehler liegen?
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2024, 14:49:57
Hallo Thowe,

jetzt mußte ich selbst ein wenig knobeln. ;)
Man muß $cmdhash als normale Stringvariable definieren. Im Set des DbRep wird daraus der Hash geformt.
Im Set-Kommando wird die Eingabe zunächst auch als String übertragen, das war der (auch mein!) Denkfehler.
So gesehen waren die umfassenden "{  ]" gar nicht verkehrt, nur sehr ungünstig wegen des dann notwendigen escapen in der Variable.

So funktioniert es im at Device. Du definierst die Variable als my $cmdhash = qq/{....}/:

+*00:01:00 {
   my $cmdhash =
   qq/{
      1  => { timestamp_begin => 'current_day_begin',
              timestamp_end   => 'current_day_end',
              device          => 'HH_Tagesenergie',
              reading         => 'state',
              autoForward     => '{".*HH_Tagesenergie__state__MAX.*" => "Tagesgesamtenergie_HH => state"}',
              cmd             => 'maxValue'
            },
     
    }/;
    fhem ("set Rep.fhemtest1 multiCmd $cmdhash");
}

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 16 März 2024, 20:15:14
Hallo Heiko,
das hat funktioniert, vielen Dank. Das hoffentlich letzte Problem ist folgendes: Wie können in den Hash-Definitionen die Platzhalter eingetragen werden. Folgende Definition
+*00:01:00 {
   my $cmdhash =
   qq/{
      1  => { timestamp_begin => 'current_day_begin',
              timestamp_end   => 'current_day_end',
              device          => 'HH_Tagesenergie',
              reading         => 'state',
              autoForward     => '{".*HH_Tagesenergie__state__MAX.*" => "Tagesgesamtenergie_HH => state"}',
              cmd             => 'maxValue',
              executeAfterProc => qq({fhem("get Rep_Daten_aus_DB_ermitteln sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','".(ReadingsVal("Tagesgesamtenergie_HH","state",0))."','')")})
            },
     
    }/;
    fhem ("set Rep_test_dev multiCmd $cmdhash");
}
führt zu folgender Fehlermeldung:
2024.03.16 19:44:39 3: DbRep Rep_test_dev - execute command after maxValue: '{fhem("get Rep_Daten_aus_DB_ermitteln sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','".(ReadingsVal("Tagesgesamtenergie_HH","state",0))."','')")}'
2024.03.16 19:44:39 2: DbRep Rep_Daten_aus_DB_ermitteln - DBD::mysql::st execute failed: Unknown column '§timestamp_end§' in 'field list' at ./FHEM/93_DbRep.pm line 7071.
Ich hoffe, Du hast eine Idee.
Viele Grüße,
Thomas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 16 März 2024, 21:50:30
Hallo Thowe,

Problem ist, dass ich die Keyword Auflösung (Platzhalter) noch nicht in sqlCmdBlocking integregriert habe.
Gerade gecheckt.
Heute ist es zu spät geworden, aber morgen baue ich die Keyword Auflösung ein.
Dann funktioniert es damit auch.  ;)

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2024, 11:08:51
Moin Thowe,

in meinem contrib liegt die Version 8.53.8.
Die Keyword Auflösung ist in sqlCmdBlocking integregriert.

Du kannst bitte die V aus meinem contrib laden, restarten und testen ob alles so arbeitet wie du es erwartest.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 März 2024, 11:49:51
Hallo Heiko,
vielen Dank dem Sonntagsarbeiter!
Mit 8.53.8 getestet scheint das Keyword noch leer zu sein:
2024.03.17 11:38:59 3: DbRep Rep_test_dev - execute command after maxValue: '{fhem("get Rep_Daten_aus_DB_ermitteln sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','".(ReadingsVal("Tagesgesamtenergie_HH","state",0))."','')")}'
2024.03.17 11:38:59 2: DbRep Rep_Daten_aus_DB_ermitteln - DBD::mysql::st execute failed: Incorrect datetime value: '' for column `fhem`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 7100.

2024.03.17 11:38:59 2: DbRep Rep_Daten_aus_DB_ermitteln - ERROR - DBD::mysql::st execute failed: Incorrect datetime value: '' for column `fhem`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 7100.

2024.03.17 11:38:59 3: get Rep_Daten_aus_DB_ermitteln sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','3.1510','') : DBD::mysql::st execute failed: Incorrect datetime value: '' for column `fhem`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 7100.
Aber das Positive: Der Inline-Aufruf der Perl-Funktion ReadingsVal funktioniert - mit dem vorher in autoForward eingetragenen Wert! Nur noch ein kleiner Schritt...
Viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2024, 13:39:58
Hmm ...
Ich habe ein at-Device nach deinem Muster erstellt (Namen an meine Installation angepasst):

+*00:00:30 {
   my $cmdhash =
   qq/{
      1  => { timestamp_begin => 'current_day_begin',
              timestamp_end   => 'current_day_end',
              device          => 'HH_Tagesenergie',
              reading         => 'state',
              autoForward     => '{".*HH_Tagesenergie__state__MAX.*" => "Dum.Rep.All => state"}',
              cmd             => 'maxValue',
              executeAfterProc => qq({fhem("get Rep.fhemtest1 sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','".ReadingsVal("Tagesgesamtenergie_HH","state",0)."','')")})
            },
     
    }/;
    fhem ("set Rep.fhemtest1 multiCmd $cmdhash");
}

... und ausgeführt.
Dabei habe ich keinen Fehler bekommen, sondern eine einwandfreie Ausführung. Hier der verbose 4 Output des Log:

2024.03.17 13:31:48.501 4: DbRep Rep.fhemtest1 - multiCmd index >1< start
2024.03.17 13:31:48.516 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.17 13:31:48.518 4: DbRep Rep.fhemtest1 - Command: maxValue
2024.03.17 13:31:48.519 4: DbRep Rep.fhemtest1 - FullDay option: 0
2024.03.17 13:31:48.519 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: 2024-03-17 00:00:00
2024.03.17 13:31:48.520 4: DbRep Rep.fhemtest1 - Timestamp end human readable: 2024-03-17 23:59:59
2024.03.17 13:31:48.521 4: DbRep Rep.fhemtest1 - Aggregation: no
2024.03.17 13:31:48.592 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.17 13:31:48.594 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.17 13:31:48.596 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.17 13:31:48.598 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.17 13:31:48.600 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.17 13:31:48.604 4: DbRep Rep.fhemtest1 - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'HH_Tagesenergie' ) AND ( READING = 'state' ) AND TIMESTAMP >= '2024-03-17 00:00:00' AND TIMESTAMP <= '2024-03-17 23:59:59' ORDER BY TIMESTAMP;
2024.03.17 13:31:48.642 4: Rep.fhemtest1 - Forward reading "2024-03-17__HH_Tagesenergie__state__MAX__no_aggregation" to "Dum.Rep.All:state"
2024.03.17 13:31:48.659 3: DbRep Rep.fhemtest1 - execute command after maxValue: '{fhem("get Rep.fhemtest1 sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','".ReadingsVal("Tagesgesamtenergie_HH","state",0)."','')")}'
2024.03.17 13:31:48.681 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.17 13:31:48.682 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.17 13:31:48.684 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.17 13:31:48.688 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.17 13:31:48.689 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.17 13:31:48.691 4: DbRep Rep.fhemtest1 - FullDay option: 0
2024.03.17 13:31:48.692 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: 2024-03-17 00:00:00
2024.03.17 13:31:48.693 4: DbRep Rep.fhemtest1 - Timestamp end human readable: 2024-03-17 23:59:59
2024.03.17 13:31:48.694 4: DbRep Rep.fhemtest1 - Aggregation: no
2024.03.17 13:31:48.695 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.17 13:31:48.695 4: DbRep Rep.fhemtest1 - sqlCmdBlocking Command:
insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','0','');
2024.03.17 13:31:48.698 4: DbRep Rep.fhemtest1 - data autocommitted
2024.03.17 13:31:48.699 4: DbRep Rep.fhemtest1 - Number of entries processed in db fhemtest1: 1
2024.03.17 13:31:48.718 3: get Rep.fhemtest1 sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','0','') : 1

Lege auch mal ein verbose 4 Log an zum Vergleich. Momentan habe ich keinen Ansatz was bei dir anders sein sollte als bei mir.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 März 2024, 14:45:15
Hallo Heiko,
da hatte ich Pech beim Denken. Im get Rep_Daten_aus_DB_ermitteln sqlCmdBlocking insert into history values (§timestamp_end§,... wird der timestamp_end der Rep_Daten_aus_DB_ermitteln verwendet. Wie komme ich an den timestamp_end des Hash-Elements heran? Hab's mit
executeAfterProc => qq({fhem("attr Rep_Daten_aus_DB_ermitteln timestamp_end §timestamp_end§; get Rep_Daten_aus_DB_ermitteln sqlCmdBlocking insert into history values (§timestamp_end§,'Tagesgesamtenergie_HH','DUMMY','calculated','state','".(ReadingsVal("Tagesgesamtenergie_HH","state",0))."','')")}) vergeblich versucht.
Viele Grüße,
Thomas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2024, 15:47:46
ZitatWie komme ich an den timestamp_end des Hash-Elements heran?
In jedem Step (hier "1") werden die Attr timestamp_begin, timestamp_end im DbRep Device entsprechend der Schlüssel-Angabe im Commandhash gesetzt vor Ausführung des cmd bzw. executeAfterProc (d.h. alle angegebenen Attribute werden vor der Abarbeitung von Kommandos definiert).
D.h. zur Laufzeit wird ein §timestamp_end§ mit dem Attr timestamp_end Wert des DbRep Device ersetzt  und ist auch gleich dem Schlüssel timestamp_end im Commandhash, weil der die 'Quelle' für die Setzungen darstellt. Natürlich wird z.B. current_day_end noch mit der absoluten Zeitangabe ersetzt die die DB verarbeiten kann.

Vor diesem Hintergrund verstehe ich deine Frage nicht wirklich.


Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 17 März 2024, 16:40:49
Will sagen: Man sollte im execAfterProc sqlCmd(Blocking) das selbe Rep-Device wie fürs multiCmd nutzen!
Ansonsten besteht die Frage, wie kommt das Keyword vom Commandhash in das andere Rep-Device im execAfterProc.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2024, 17:12:39
Ja, genau. Der Kommandohash bezieht sich auf das DbRep Device in dem er ausgeführt wird.
Wenn du im execAfterProc die Daten/Attribute eines anderen (DbRep)Devices verarbeiten willst, kannst du die execAfterProc-Routine natürlich aufwändiger gestalten und diese Daten mit AttrVal, ReadingsVal vom anderen Device vorher in deine execAfterProc-Routine als Variable holen.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 17 März 2024, 19:36:37
@Thowe, habe die V 8.53.8 eingecheckt und ist morgen früh im Regelupdate enthalten.

LG
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 März 2024, 22:45:14
@Thowe, in meinem contrib habe die Version 8.53.9 bereitgestellt.

Ich habe eine Scriptsteuerung implementiert. Dafür ist jetzt auch das Attribut "userExitFn" im multiCmd setzbar und zur Steuerung kann man in Perl Bedingungen (if, else, ...) den Befehl "nextHop (x)" einbauen.
Dabei ist "x" der nächste Index der abgearbeitet werden soll oder "quit" für ein direktes Verlassen von multiCmd.

"nextHop (x)" kann auch in executeBefore/After/Proc verwendet werden.

Zu beachten ist, dass nur höhrere Index angesprungen werden können. Übersprungene Index sind nicht mehr (als Rücksprung) erreichbar.
Zur Demo hier ein längeres Hash mit einer Sprungbedingung im Index "3":

        {
          1  => { executeBeforeProc => 'set LogDB1 reopen 900',
                  timestamp_begin   => '2023-12-17 00:00:00',
                  timestamp_end     => '2023-12-17 01:00:00',
                  device            => 'SMA_Energymeter',
                  reading           => 'Einspeisung_Wirkleistung_Zaehler',
                  cmd               => 'countEntries history'
                },
          2  => { timestamp_begin   => '2023-12-15 11:00:00',
                  timestamp_end     => 'previous_day_end',
                  device            => 'SMA_Energymeter',
                  reading           => 'Einspeisung_Wirkleistung_Zaehler',
                  cmd               => 'countEntries'
                },
          3  => { userExitFn        => '{ if ($READING =~ /SqlResultRow_2/ && $VALUE > 0) {nextHop (5)} }',
                  cmd               => 'sqlCmd select count(*) from current'
                },
          4  => { timeDiffToNow     => 'd:2',
                  readingNameMap    => 'COUNT',
                  autoForward       => '{ ".*COUNT.*" => "Dum.Rep.All" }',
                  device            => 'SMA_%,MySTP.*',
                  reading           => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
                  cmd               => 'countEntries history'
                },
          5  => { timeDiffToNow     => 'd:2',
                  readingNameMap    => 'SUM',
                  autoForward       => '{ ".*SUM.*" => "Dum.Rep.All" }',
                  device            => 'SMA_%,MySTP.*',
                  reading           => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
                  cmd               => 'sumValue'
                },
          6  => { executeAfterProc  => 'set LogDB1 reopen',
                  cmd               => 'sqlCmd select count(*) from current'
                },
        }

Im Log mit verbose 4 sieht es dann so aus:

2024.03.18 22:25:53.550 4: DbRep Rep.fhemtest1 - multiCmd index >1< start
2024.03.18 22:25:53.561 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.18 22:25:53.561 4: DbRep Rep.fhemtest1 - Command: countEntries history
2024.03.18 22:25:53.562 4: DbRep Rep.fhemtest1 - FullDay option: 0
2024.03.18 22:25:53.563 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: 2023-12-17 00:00:00
2024.03.18 22:25:53.563 4: DbRep Rep.fhemtest1 - Timestamp end human readable: 2023-12-17 01:00:00
2024.03.18 22:25:53.564 4: DbRep Rep.fhemtest1 - Aggregation: no
2024.03.18 22:25:53.564 3: DbRep Rep.fhemtest1 - execute command before countEntries: 'set LogDB1 reopen 900'
2024.03.18 22:25:53.566 2: LogDB1 - Connection closed until 22:40:53 (900 seconds).
2024.03.18 22:25:53.631 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.18 22:25:53.632 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.18 22:25:53.635 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.18 22:25:53.637 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.18 22:25:53.638 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.18 22:25:53.639 4: DbRep Rep.fhemtest1 - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung_Zaehler' ) AND TIMESTAMP >= '2023-12-17 00:00:00' AND TIMESTAMP <= '2023-12-17 01:00:00' ;
2024.03.18 22:25:53.779 4: DbRep Rep.fhemtest1 - multiCmd index >2< start
2024.03.18 22:25:53.789 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.18 22:25:53.790 4: DbRep Rep.fhemtest1 - Command: countEntries history
2024.03.18 22:25:53.791 4: DbRep Rep.fhemtest1 - FullDay option: 0
2024.03.18 22:25:53.791 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: 2023-12-15 11:00:00
2024.03.18 22:25:53.792 4: DbRep Rep.fhemtest1 - Timestamp end human readable: 2024-03-17 23:59:59
2024.03.18 22:25:53.792 4: DbRep Rep.fhemtest1 - Aggregation: no
2024.03.18 22:25:53.859 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.18 22:25:53.861 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.18 22:25:53.864 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.18 22:25:53.866 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.18 22:25:53.867 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.18 22:25:53.868 4: DbRep Rep.fhemtest1 - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung_Zaehler' ) AND TIMESTAMP >= '2023-12-15 11:00:00' AND TIMESTAMP <= '2024-03-17 23:59:59' ;
2024.03.18 22:25:53.930 4: DbRep Rep.fhemtest1 - multiCmd index >3< start
2024.03.18 22:25:53.940 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.18 22:25:53.941 4: DbRep Rep.fhemtest1 - Command: sqlCmd select count(*) from current;
2024.03.18 22:25:53.941 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: not set
2024.03.18 22:25:53.942 4: DbRep Rep.fhemtest1 - Timestamp end human readable: not set
2024.03.18 22:25:53.979 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.18 22:25:53.981 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.18 22:25:53.984 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.18 22:25:53.986 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.18 22:25:53.987 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.18 22:25:53.988 4: DbRep Rep.fhemtest1 - SQL execute: select count(*) from current;
2024.03.18 22:25:53.989 4: DbRep Rep.fhemtest1 - SQL result: 1356
2024.03.18 22:25:53.993 4: DbRep Rep.fhemtest1 - multiCmd nextHop was set by previous function: 5
2024.03.18 22:25:54.014 4: DbRep Rep.fhemtest1 - nexthop is set to >5< -> multiCmd index >4< skipped
2024.03.18 22:25:54.071 4: DbRep Rep.fhemtest1 - multiCmd index >5< start
2024.03.18 22:25:54.083 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.18 22:25:54.084 4: DbRep Rep.fhemtest1 - Command: sumValue
2024.03.18 22:25:54.084 4: DbRep Rep.fhemtest1 - timeDiffToNow - year: , day: 2, hour: , min: , sec:
2024.03.18 22:25:54.085 4: DbRep Rep.fhemtest1 - Year 2024 is leap year
2024.03.18 22:25:54.085 4: DbRep Rep.fhemtest1 - startMonth: 2 endMonth: 2 lastleapyear:  baseYear: 2024 diffdaylight:0 isdaylight:0
2024.03.18 22:25:54.086 4: DbRep Rep.fhemtest1 - FullDay option: 0
2024.03.18 22:25:54.087 4: DbRep Rep.fhemtest1 - Time difference to current time for calculating Timestamp begin: 172801 sec
2024.03.18 22:25:54.087 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: 2024-03-16 22:25:53
2024.03.18 22:25:54.088 4: DbRep Rep.fhemtest1 - Timestamp end human readable: 2024-03-18 22:25:54
2024.03.18 22:25:54.088 4: DbRep Rep.fhemtest1 - Aggregation: no
2024.03.18 22:25:54.139 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.18 22:25:54.140 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.18 22:25:54.145 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.18 22:25:54.146 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.18 22:25:54.146 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.18 22:25:54.151 4: DbRep Rep.fhemtest1 - SQL execute: SELECT SUM(VALUE) FROM history where ( DEVICE IN ('SMA_Energymeter','MySTP_5000') ) AND ( READING LIKE 'Ein%' OR READING IN ('etotal','etoday') ) AND READING NOT LIKE '%Wirkleistung' AND TIMESTAMP >= '2024-03-16 22:25:53' AND TIMESTAMP <= '2024-03-18 22:25:54' ;
2024.03.18 22:25:54.273 4: DbRep Rep.fhemtest1 - Forward reading "2024-03-16__SUM__no_aggregation" to "Dum.Rep.All:2024-03-16__SUM__no_aggregation"
2024.03.18 22:25:54.398 4: DbRep Rep.fhemtest1 - multiCmd index >6< start
2024.03.18 22:25:54.414 4: DbRep Rep.fhemtest1 - -------- New selection ---------
2024.03.18 22:25:54.415 4: DbRep Rep.fhemtest1 - Command: sqlCmd select count(*) from current;
2024.03.18 22:25:54.416 4: DbRep Rep.fhemtest1 - Timestamp begin human readable: not set
2024.03.18 22:25:54.417 4: DbRep Rep.fhemtest1 - Timestamp end human readable: not set
2024.03.18 22:25:54.471 4: DbRep Rep.fhemtest1 - Database Model: MYSQL
2024.03.18 22:25:54.472 4: DbRep Rep.fhemtest1 - Database connect - user: fhemtest1, UTF-8 option set: yes
2024.03.18 22:25:54.475 4: DbRep Rep.fhemtest1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.18 22:25:54.477 4: DbRep Rep.fhemtest1 - Database Character set is >utf8mb4_bin<
2024.03.18 22:25:54.477 4: DbRep Rep.fhemtest1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.18 22:25:54.478 4: DbRep Rep.fhemtest1 - SQL execute: select count(*) from current;
2024.03.18 22:25:54.479 4: DbRep Rep.fhemtest1 - SQL result: 1356
2024.03.18 22:25:54.483 3: DbRep Rep.fhemtest1 - execute command after sqlCmd: 'set LogDB1 reopen'
2024.03.18 22:25:54.512 3: DbRep Rep.fhemtest1 - command message after sqlCmd: >Reopen executed.<

Beachte die Ausgabe im Step 3 mit dem Hinweis dass der Index 4 übersprungen wird.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 18 März 2024, 23:11:25
Da haben wir ja was angerichtet mit der Einführung der hash-gesteuerten Ausführung von Befehlen. Es entwickelt sich zum unbeherrschbaren Moloch...
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 18 März 2024, 23:38:16
Ja ist nicht ganz einfach.
Bis jetzt ist es noch strukturiert machbar, aber die Grenze ist in Reichweite ...
Für heute ist sie auf jeden Fall überschritten ...  ;)
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 19 März 2024, 02:18:50
Hallo Heiko,
noch gewinne ich mit der Hash-gesteuerten Ausführung an Übersichtlichkeit und damit Wartbarkeit. Der Wettbewerb zwischen fhem.cfg und 99_myUtils.pm hat wieder mehr Gewicht auf die Konfigurationsseite gebracht. Vielen Dank und
viele Grüße,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 19 März 2024, 09:13:45
Ich würde solche "Romane" niemals in ein Attribut schreiben.
Nicht alles, was technisch möglich ist, ist automatisch auch sinnvoll.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 19 März 2024, 09:25:55
Hallo betateilchen,
Zitat von: betateilchen am 19 März 2024, 09:13:45Ich würde solche "Romane" niemals in ein Attribut schreiben.
Nicht alles, was technisch möglich ist, ist automatisch auch sinnvoll.
ist zu pauschal gehalten. Auf welches Attribut bezieht sich Deine Aussage? Was wäre die sinnvolle Alternative?
VG Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 19 März 2024, 10:19:26
Sorry, Attribut war falsch, der Roman steht ja im DEF eines at.
Aber auch da würde ich sowas nicht hinschreiben.
Sowas ist in der 99_myUtils.pm einfach besser aufgehoben und leichter wartbar.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dennisk am 20 März 2024, 06:53:04
Guten Morgen zusammen,

ich nutze DbRep noch nicht sehr intensiv, aber seit ich es instantiiert habe, habe ich im Log, auch über viele Updates hinweg, sporadisch diese Fehlermeldungen:
2024.03.19 17:39:39 1: PERL WARNING: readdir() attempted on invalid dirhandle DIR at /usr/share/fhem/FHEM/93_DbRep.pm line 552.
2024.03.19 17:39:39 1: PERL WARNING: closedir() attempted on invalid dirhandle DIR at /usr/share/fhem/FHEM/93_DbRep.pm line 557.

Der betreffende Code scheint immer dieser hier zu sein, nach einem Update von DbRep dann mit mglw. anderen Zeilennummern:
  while (my $file = readdir(DIR)) {
      next unless (-f "$dir/$file");
      next unless ($file =~ /^$sd/);
      push @bkps,$file;
  }
  closedir(DIR);

Fehlt mir hier irgendein Attribut, oder habe ich etwas falsch konfiguriert?

Hier mal mein DEF des DbRep Gerätes:
defmod globalDbLog_DbRep DbRep globalDbLog
attr globalDbLog_DbRep dumpDirLocal /var/lib/fhem/dblog/

setstate globalDbLog_DbRep initialized
setstate globalDbLog_DbRep 2024-03-15 17:45:47 state initialized

Das Verzeichnis dumpDirLocal ist les- und schreibbar durch den User, unter dem fhem läuft. Oder hat es mit dumpDirLocal gar nichts zu tun? Hat jemand eine Idee, was die Warnung auslösen und wie ich das beheben könnte?

Vielen Dank schon mal!
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: betateilchen am 20 März 2024, 16:54:46
Vermutlich kommt die Meldung im Log immer dann, wenn Du das DbRep device im Frontend anzeigen lässt?

Meines Erachtens wäre es sinnvoll, im opendir() ein paar Zeilen vorher eine Fehlerbehandlung einzubauen, damit DbRep_Set() erst gar nicht bis zu der Stelle kommt, an der ein Zugriff erfolgt.

Aber warum die Fehlermeldung verursacht wird, ist damit noch nicht klar.

Zitat von: dennisk am 20 März 2024, 06:53:04Das Verzeichnis dumpDirLocal ist les- und schreibbar durch den User, unter dem fhem läuft.

Ohne Dir zu nahe treten zu wollen: sowas haben schon viele behauptet :)

Nimm doch mal testweise das Attribut komplett raus, dann wird das Standardverzeichnis verwendet, auf das FHEM sicher Zugriff hat.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dennisk am 20 März 2024, 22:49:42
Zitat von: betateilchen am 20 März 2024, 16:54:46Vermutlich kommt die Meldung im Log immer dann, wenn Du das DbRep device im Frontend anzeigen lässt?

Das könnte in der Tat sein, ist aber schwer nachzuvollziehen, da das Ganze nur sehr sporadisch auftaucht. Aber ich werde versuchen, darauf zu achten.

Zitat von: betateilchen am 20 März 2024, 16:54:46Meines Erachtens wäre es sinnvoll, im opendir() ein paar Zeilen vorher eine Fehlerbehandlung einzubauen, damit DbRep_Set() erst gar nicht bis zu der Stelle kommt, an der ein Zugriff erfolgt.

Aber warum die Fehlermeldung verursacht wird, ist damit noch nicht klar.

Hast Du da eine konkrete Idee, was ich wo einbauen sollte?

Zitat von: dennisk am 20 März 2024, 06:53:04Das Verzeichnis dumpDirLocal ist les- und schreibbar durch den User, unter dem fhem läuft.

Zitat von: betateilchen am 20 März 2024, 16:54:46Ohne Dir zu nahe treten zu wollen: sowas haben schon viele behauptet :)

Nimm doch mal testweise das Attribut komplett raus, dann wird das Standardverzeichnis verwendet, auf das FHEM sicher Zugriff hat.

Das Attribut hatte ich ursprünglich mal gesetzt, weil der Fehler schon ohne das Attribut auftrat. Ich habe soeben aber in fhem als Kommando folgendes eingegeben und ausgeführt: {qx(echo "test" > /var/lib/fhem/dblog/testfile)}
Die vorher nicht existente Datei wurde im Verzeichnis erfolgreich angelegt und der String auch erfolgreich in die Datei geschrieben. Dann sollte doch auch DbRep schreiben können, oder?

Vielen Dank in jedem Fall für Deinen Input
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2024, 00:05:08
Es werden bestimmte Files im Verzeichnis "$attr{global}{modpath}/log/" gesucht.
D.h. du müsstest überprüfen was bei dir im global Device Attr "modpath" steht (üblicherweise '.') und ob es dieses Verzeichnis bei dir gibt (was Standard wäre).
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dennisk am 21 März 2024, 07:09:02
Zitat von: DS_Starter am 21 März 2024, 00:05:08Es werden bestimmte Files im Verzeichnis "$attr{global}{modpath}/log/" gesucht.
D.h. du müsstest überprüfen was bei dir im global Device Attr "modpath" steht (üblicherweise '.') und ob es dieses Verzeichnis bei dir gibt (was Standard wäre).

Vielen Dank für den Hinweis. Bei mir steht in $attr{global}{modpath} /usr/share/fhem Ist eine Installation, die ich damals über das Paket fhem aus dem Arch User Repository unter Arch Linux installiert habe, siehe auch https://wiki.archlinux.org/title/FHEM (https://wiki.archlinux.org/title/FHEM) Und in diesem Verzeichnis existierte kein Verzeichnis log Dieses habe ich jetzt mal hinzugefügt. Reicht das schon? Oder such DbRep etwas bestimmtes darunter?
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2024, 18:01:25
ZitatDieses habe ich jetzt mal hinzugefügt. Reicht das schon? Oder such DbRep etwas bestimmtes darunter?
Das reicht.
Ist dumpDirLocal nicht gesetzt, werden Dump-Files mit "dumpMySQL clientSide" oder "dumpSQLite" in dieses Verzeichnis per default abgelegt bzw. wird aus (evtl.) gefundenen Files in dem Verzeichnis eine Drop-Down Liste für die Restore Set-Befehle erstellt.
Die Hilfe zum Attr dumpDirLocal  erklärt den Zusammenhang ebenfalls.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: dennisk am 21 März 2024, 18:40:28
Zitat von: DS_Starter am 21 März 2024, 18:01:25
ZitatDieses habe ich jetzt mal hinzugefügt. Reicht das schon? Oder such DbRep etwas bestimmtes darunter?
Das reicht.
Ist dumpDirLocal nicht gesetzt, werden Dump-Files mit "dumpMySQL clientSide" oder "dumpSQLite" in dieses Verzeichnis per default abgelegt bzw. wird aus (evtl.) gefundenen Files in dem Verzeichnis eine Drop-Down Liste für die Restore Set-Befehle erstellt.
Die Hilfe zum Attr dumpDirLocal  erklärt den Zusammenhang ebenfalls.


Danke. Aber dumpDirLocal ist doch gesetzt. Siehe das DEF in meinem Post weiter oben.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 21 März 2024, 23:30:17
ZitatAber dumpDirLocal ist doch gesetzt.
Wenn es gesetzt ist, wird das angegebene Verzeichnis benutzt.
Wenn die Fehlerausschrift in diesem Fall auftritt, kann das angegebene Verzeichnis nicht gelesen werden.
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 22 März 2024, 19:05:35
Tagchen,

ich versuche immernoch den o.g. Fehler hinterher zu kommen:
2024.03.22 14:38:20.511 2: DbRep SQL_DBrep_Device - ERROR - DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./FHEM/93_DbRep.pm line 11994Dieser kommt seit der Umstellung 10-30 mal pro Tag von einem der Device das aktuell alle 15 Min ausgeführt wird.

Die betreffende Zeile 11994 ist mit
Zitat#    führt ein sth execute prepared Insert aus
#    return ERROR oder die Anzahl der betroffenen Zeilen
kommentiert. Leider kann ich mit dem Hinweis so erstmal nichts anfangen.... Kannst Du mir einen Tipp geben, woher das kommt, wodurch diese Fehlermeldung kommt? Eigentlich sollte die DB (bzw das DBRep) weniger zu tun haben, als früher, weil alles der Reihe nach erfüllt wird und nicht teilweise 4 Aufrufe für ein Device nötig sind.....

Zitat von: DS_Starter am 15 März 2024, 13:14:16@flummy1978,
Nach kurzer Überlegung halte ich es für angebracht die aus den execafter/before resultierenden Meldungen auf verbose 3 setze. So essntiell sind sie im Normalfall nicht und du kannst das DbRep mit verbose 2 betreiben ohne wichtige Meldungen zu verpassen.
Wenn ich es richtig verstanden habe, hast Du das bereits in der aktuellen Ausführung umgestellt? Ich bekomme noch die Meldung:
2024.03.22 18:52:30.481 2: DBLogging - Connection closed until 19:52:30 (3600 seconds).
Die allerdings erst sichtbar geworden ist, nachdem ich das entsprechende DBRep Device auf verbose 2 umgestellt habe.

VG
Andreas

Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 März 2024, 22:58:20
Hallo Andreas,

ZitatWenn ich es richtig verstanden habe, hast Du das bereits in der aktuellen Ausführung umgestellt? Ich bekomme noch die Meldung:
Diese Meldung kommt aber nicht aus DbRep, sondern DbLog als Reaktion auf das Schließen der Verbindung.

Die Datenbank Meldung:
ZitatDBD::mysql::st execute failed: Lock wait timeout exceeded
Ist im Prinzip kein technischer Fehler im eigentlichen Sinn, sondern ist eine Reaktion darauf dass
die Situation "Lock wait timeout exceeded" auftritt, wenn eine Transaktion auf eine Sperre wartet, die von einer anderen erworben wurde.

Du könntest den Server Parameter innodb_lock_wait_timeout (https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_lock_wait_timeout) versuchen zu trimmen.
Eine weitere Möglichkeit wäre im DbLog das Attr commitMode = basic_ta:off setzen.

Möglicherweise arbeitet deine Datenbank sehr langsam. Das erkennst du evtl. mit den DbLog Attr showproctime = 1.

EDIT: Im DbRep sqlCmd kannst du den Befehl "SHOW ENGINE INNODB STATUS;" ausführen. Es zeigt ein Ergebnis welches u.U. hilfreich sein kann den Verursacher des Lock wait zu finden.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 22 März 2024, 23:48:52
@Thowe,
bist du mit der aktuellen Testversion von DbRep soweit zufrieden dass du deine Cases umsetzen kannst?
Wenn es soweit passt, würde ich die V auch mal einchecken.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: flummy1978 am 24 März 2024, 13:20:19
Hallo Heiko,

Zitat von: DS_Starter am 22 März 2024, 22:58:20Du könntest

vielen herzlichen Dank für alle Vorschläge. Ich würde sie nacheinander umsetzen und versuchen herauszufinden, was dort passiert.

Nur zur Erklärung:
Ich habe mein DS endlich auf DSM 7 upgedatet und in diesem Zuge natürlich alles andere auch aktualisiert. Seitdem (und auch der Umstellung auf multiCmd) habe ich den log recht voll mit diesen oder vorher den anderen Meldungen. Daher ist es für mich eben auch etwas schwerer festzustellen woher der jeweilige "Fehler" (der wie du sagst, keiner ist) bzw Meldung kommt. Die Verbindung und Geschwindigkeit der DB sollte sich maximal nach oben verandert haben, aber noch nicht schlechter geworden sein, weil die DS seitdem gefühlt schneller / bssser läuft.

Eine Frage vorab zu showproctime = 1. Ich habe das Attribut schon länger gesetzt (erinnere mich an eine frühere Fehlersuche) aber das genannte Reading ist dort nicht zu finden. Kann ich das irgendwie erzwingen?

Vielen Dank nochmal für Deine Geduld und Hilfe und ich werde weiter berichten

VG
Andreas
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 24 März 2024, 16:35:15
Hallo Andreas,

es ist davon ausgezugehen dass die DB auf der Synology mit den Default-Einstellungen des Synology-Paketes nicht optimal eingestellt ist. Synology gibt m.W. auch Einstellungstemplates mit um die Serverparameter entsprechend der Syno (RAM) anpassen zu können (low, medium, high).
Wichtig ist zu wissen, dass man dieses Einstellungen in einem User-Konfigfile vornimmt und nicht in  von Syno ausgelieferten Konfig-Files. Die werden bei einem DSM-Update überschrieben!

Diesbezüglich würde ich dir empfehlen den Austausch hier im Synology Thread (https://forum.fhem.de/index.php?board=30.0) vorzunehmen.

Zum Reading...
Wenn du das Attr showproctime = 1 setzt, wird das Reading sql_processing_time automatisch angelegt und zeigt die Abarbeitungszeit von SQL-Statements. Sollte das Reading nicht da sein, wäre es schon ein sehr merkwürdiger Zustand und ein Achtungszeichen mal genauer deine DB anzuschauen.

Viel bekommt man schon mit den Möglichkeiten von DbLog heraus. Wäre aber ein anderer/neuer Thread.
Auch das Tool MySQLTuner (https://github.com/major/MySQLTuner-perl) kann hilfreich sein um herauszubekommen an welchen Schrauben es sich lohnen würde zu drehen.
Wie gesagt, das Reading sql_processing_time gibt schonmal einen groben Überblick über die Performance.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: Thowe am 25 März 2024, 10:15:00
Hallo Heiko,
die Sprünge funktionieren. Das Fehlen war in meinem Fall das letzte Umsetzungshindernis. Von meiner Seite aus kann die Version eingecheckt werden.
Bei der Migration auf den Hash-Ablauf habe ich Dank der übersichtlichen Hash-Struktur im alten Ablauf sogar einen Fehler entdeckt - genau bei den Sonderhandlungen zum Monatsende.
Ich bin gespannt auf den ersten Volldurchlauf. Falls ich auf ein Problem stoße, könntest Du involviert werden.
Vielen Dank für dieses geniale Modul und Deinen Support,
Thowe
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 25 März 2024, 16:32:22
Hallo Thowe,
danke für deine Rückmeldung  :) 
Die neue V ist morgen früh im Update enthalten.

LG,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maa1 am 26 März 2024, 19:48:04
Hallo Heiko,

möchte meine DB-Reorganisation auf multiCmd umstellen. Es fehlt mir aber noch das Attribut seqDoubletsVariance für delSeqDoublets. Falls möglich bitte ergänzen.

Noch eine Frage: Warum werden die Attribute bei Ausführung von multiCmd im DBRep-Device gespeichert? Dies hätte ich so nicht erwartet bzw. müsste darauf hingewiesen werden.

Danke.

LG Fredi
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 März 2024, 00:01:56
Hallo Fredi,

bzgl. des Attr seqDoubletsVariance schau ich mir das an.

ZitatWarum werden die Attribute bei Ausführung von multiCmd im DBRep-Device gespeichert? Dies hätte ich so nicht erwartet bzw. müsste darauf hingewiesen werden.
multiCmd ist im Prinzip eine Verkettung von Befehlen mit einem dynamisch konfigurierten DbRep Device.
Würdest du die Befehle manuelle ausführen ohne multiCmd, müsstest/würdest du vorab das Device ebenfalls entsprechend einstellen müssen. Daraus erklärt sich das speichern der Attribute.

Ich kann den Umstand aber gern in der Hilfe vermerken, kein Thema.

LG,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: DS_Starter am 27 März 2024, 22:41:45
@Fredi,
habe das Attr dem multiCmd hinzugefügt, die CommandRef ergänzt und eingecheckt.
Morgen früh ist die V im Update enthalten.

Grüße,
Heiko
Titel: Aw: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
Beitrag von: maa1 am 28 März 2024, 13:50:05
Hallo Heiko,

vielen Dank für die rasche Umsetzung.

Bin übrigens auch ein Forecast-Fan.

lG Fredi