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

DS_Starter · 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" ?

DerFrickler · 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"

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

DerFrickler · 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?

DS_Starter · 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

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

DS_Starter · 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ß.

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

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

DS_Starter · 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

DS_Starter · 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

DS_Starter · 15 August 2016, 08:25:50

Habe noch einen Fehler in der V.3.4.4 festgestellt und korrigiert im Eingangsthread hinterlegt.

VG

DerFrickler · 15 August 2016, 10:56:31

ich hatte bisher noch keine Zeit zum Testen, mal sehen ob es im Laufe der Woche klappt.

DerFrickler · 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

DS_Starter · 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:

Code Auswählen


# 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