Hi Joe,
"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
