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

[DS_Starter]

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:

Müssen die Daten / Readings nochmal geloggt werden?

Vermutlich ja, da ich nicht annehme dass SVG mathematische Funktionen wie Diffvalue oder sumValue beherrscht.
Das Loggen kann für die Ploterstellung wahlweise in einem Filelog oder DbLog erfolgen.

Und wie funktioniert es, dass im Plot jeweils in Ballken pro Monat ausgegeben wird

Balken kannst du im Ploteditor mit dem Style "bars" erstellen. (siehe Screenshot)

Wenn jetzt ein weiteres Readings für Februar dazukommt, wie erkennt der Plot dann, dass es sich um einen neuen Monat handelt?

Plot erkennt den Zeitpunkt des Readings anhand dessen Erstellungsdatums in der Datenbank bzw. dem Filelog. Meiner Meinung nach müßte man demnach z.B. für jeden Monat ein eigenes DbRep-Device erstellen um mit diesem nur das jeweilige Reading für den jeweiligen Monat wie von dir beschrieben:

2017-01-29_11-06-29__Strom__Verbraucht__DIFF__2017-01 243.0000 2017-01-29 14:02:27

zu erstellen.
In dem jeweiligen DbRep-Device darf die Readingerstellung regelmäßig ab Montasanfang, aber jeweils nur maximal bis zum Ende des jweiligen Monats (also Ende Januar beim DbRep.Januar-Device erfolgen) damit der Timestamp im Log dann stimmt und vom SVG ordentlich ausgewertet werden kann.
Kann z.B. mit einem AT realisiert werden.

Kann ich auch parallel Tages-., Monats und Jahresplots generieren wenn ich über aggregation day, month, year jeweils einmal die Nacht die entsprechenden Werte von DbRep genieren lassen?

Ja das geht . Aber Aggregation "year" gibt es zumindest bis jetzt noch nicht.

Grüße
Heiko

[abc2006]

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

Code Auswählen Erweitern

diff-overrun_limit-20

Das wird dann natürlich bei  (.*-20) entsprechend eingefügt.

Also hab ich versucht, meine Readings umzuformatieren:

Code Auswählen Erweitern

attr REP_test readingNameMap Gaszaehler(kWh)

Ist leider fehlgeschlagen, da die Klammern () wohl nicht als Reading-Name erlaubt sind.

also hab ichs mit

Code Auswählen Erweitern

attr REP_test readingNameMap Gaszaehler
versucht.

Dann heissen meine Readings jetzt zb

Code Auswählen Erweitern

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

[abc2006]

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:

Code Auswählen Erweitern


   timestamp_begin 2017-01-01 00:00:00
   timestamp_end 2017-01-31 23:59:59


Trotzdem erstellt DbRep ein Reading

Code Auswählen Erweitern


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

Code Auswählen Erweitern

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

[DS_Starter]

Hallo Stephan,

Könntest du das limit-reading umbenennen?

Ja, ich schaue mal wie das besser wäre. Das ist wirklich unschön wenn man in dem speziellen Fall so "rumopern" muß.

Die andere Sache schaue ich mir auch mal in Ruhe an.

Grüße
Heiko

[abc2006]

Habe ein bisschen mit dem Modul rumgebastelt, und es sind mir tausend Ideen eingefallen 
Aber ich teil das mal in kleine Häppchen auf, nachdem ich jeweils nochmal drüber nachgedacht habe ;P

current_year_begin, current_year_end sowie previous_year_begin und previous_year_end

Wäre es ebenfalls möglich, diese für
- month
- week
- day
- und wenn man es vollständig haben will, hour

zu implementieren?

Wobei die current_*_end ja immer in der Zukunft liegen werden...

Der Vollständigkeit halber (und Einfachheit des Benutzens) wäre hier vielleicht auch eine Dropdown-liste sinnvoll:

Code Auswählen Erweitern

attr calcTimeBetween (chour,cday,cweek,cmonth,cyear;lhour,lday,lweek,lmonth,lyear)

Edit: dazu wäre es natürlich sinnvoll, ein Reading namens

Code Auswählen Erweitern

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

[DS_Starter]

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

Habe ein bisschen mit dem Modul rumgebastelt, und es sind mir tausend Ideen eingefallen 

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 

Grüße
Heiko

[Hauswart]

Ist dieses Modul auch in der Lage Migrationen sqlite <=> MySQL durchzuführen?

[DS_Starter]

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

[Hauswart]

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.

[abc2006]

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

[DS_Starter]

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.

Dass ich 30 Tage sehen kann, ist ja ganz nett, aber irgendwie interessiert mich der aktuelle/kürzliche Verbrauch mehr ...

Welche 30 Tage ?  Naja, für den aktuellen Verbrauch brauchst du keine DB-Auswertungen 
Ursprünglich waren die DbRep-Auswertungen gedacht für tabellarische Darstellungen/Gegenüberstellungen (z.B. mit Readingsgroup) verschiedener definierter Auswertungsscenarien.

Konnte nicht DBLog oder DBRep beliebige MySQL-Statements absetzen?

Ja , in DbLog kannst du mit "set .. userCommand" deine SQL's ausführen.

Grüße
Heiko

[abc2006]

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

Grüße und Danke

Stephan

[abc2006]

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

[DS_Starter]

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

[abc2006]

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?

Code Auswählen Erweitern

ReadingsVal("meinRep",".*DIFF.*",0);
funktioniert leider nicht...