Autor Thema: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)  (Gelesen 225000 mal)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
Hab die neue Version 3.4.3 auch noch im ersten Thread eingehängt. Kannst du dann auch heute schon probieren.

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

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



ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
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"

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
Ja klar, verstanden. Ich denke, das sollte möglich sein. Sehe ich mal bei einem der nächsten Updates mit vor.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
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?

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
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.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
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ß.
   
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
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.

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
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.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
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
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
Zitat
Ich hätte da noch einen Vorschlag: wenn man timestamp_begin und timestamp_end mit Werten wie z.B. current_year_begin, current_year_end sowie previous_year_begin und previous_year_end belegen könnte.

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

VG und schönes WE
« Letzte Änderung: 12 August 2016, 17:14:59 von DS_Starter »
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
Habe noch einen Fehler in der V.3.4.4 festgestellt und korrigiert im Eingangsthread hinterlegt.

VG
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
ich hatte bisher noch keine Zeit zum Testen, mal sehen ob es im Laufe der Woche klappt.

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
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


Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7827
Hallo Karsten,

prima  :).

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

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

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

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

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

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

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

viele Grüße
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

 

decade-submarginal