Integralwertberechnung + Median über Zeitraum

[jensb]

Hallo,

seit einiger Zeit gibt es die Integral-Option bei den userReadings, die auf dem Mittelwert von zwei aufeinanderfolgenden Werten aufbaut.

Für meine Bewässerungssteruerung benötige ich aber z.B. die Gesamtwassermenge innerhalb der letzten 24 Stunden, was aus mehreren Stundenmesswerten [l/(m2*h)] aufsummiert werden muss - und zwar immer wieder neu mit jedem neuen Messwert, da ja die ältesten Messwerte jeweils aus der Berechnung herausfallen sollen (wie bei einer Blockmittelwertberechnung). Die gleiche Berechnung möchte ich u.a. auch für die Differenz zwischen Taupunkt und Temperatur durchführen.

Neben dem wählbaren Zeitraum benötigt man eine Option, ob man das Integral durch Fortschreiben des letzten Wertes (für sprungfähige Messdaten wie den Niederschlag/Stunde) oder über den Mittelwert zwischen zwei Werten (für stetige Messdaten wie die Temperatur) berechnen will.

Ein Weg, den ich sehe, wäre es, über ein at oder notify das Modul readingsHistory aufzurufen, die Berechnung durchzuführen und das Ergebnis als Reading zu speichern - aber das ist schon ziemlich indirekt, vor allem wenn man das für diverse Readings so machen muss.

Kennt jemand eine Möglichkeit, eine Integralfunktion noch einfacher umzusetzten?

LG, jensb

[Dr. Boris Neubert]

Hi,

brauchst Du nur einen neuen modifier oder ein Funktionalität mit gleitendem Fenster?

Grüße
Boris

[jensb]

Hi Boris,

glaube nicht, dass es mit einem Modifier getan ist, da man ja auf einem Ringspeicher von Werten arbeiten müsste, die normalerweise nicht im Reading des Quell-Devices vorhanden sind. Die benötigten Werte sind je nach eigener Konfiguration manchmal in einem Log, aber meist ist man ja nicht bei jedem Reading an der Historie interessiert.

Habe mir die Module statistics, dewpoint und readingsHistory von innen angesehen. Sie haben eine gemeinsame Basis und verstecken die Hilfswerte in Hidden Readings. Dabei handelt es sich aber meist nur um eine Handvoll Werte. Bei einem Reading, dass sich oft ändert, kommen für einen Zeitraum von z.B. 24 Stunden schnell relevante Datenmengen zusammen. Die sollte man einerseits im RAM halten, damit die Neuberechnung schnell genug abläuft. Andererseits müsste man die Daten aber auch persistent machen. Das Modul readingsHistory verwendet dafür scheinbar Dumper.

Inzwischen habe ich mit einem Skelett für ein neues Analysis-Modul angefangen, dass diese Funktionen zur Verfügung stellen soll. Bin mir aber nach wie vor nicht schlüssig, was der sinnvollste Weg für den RAM-Cache und die Persistenz ist. Den RAM-Cache könnte man in einem Hash (ReadingName) von Arrays (Zeit + Wert) unterbringen. Für die Persistenz könnte man z.B. eigene Files erzeugen, aber mir würde es besser gefallen, wenn man auf bereits vorhandene Logs zurückgreift, damit die Daten nicht doppelt gehalten werden.

LG, Jens

[Dr. Boris Neubert]

Hallo Jens,

schau Dir bitte mal das TimeSeries-Modul an. Ich bin für Patches offen, aber Ringbuffer unterstützt es ohne größere Änderungen nicht.

Viele Grüße
Boris

[jensb]

Hallo Boris,

vielen Dank für den Hinweis. Mache ich nachher.

LG, Jens

[jensb]

Hallo Boris,

TimeSeries ist ein prima Container für zeitbezogenen Messwerte und damit steht schon mal ein RAM-Cache zur Verfügung. Allerding müsste man die Elapsed- und Reset-Funktion in Abhängigkeit von einem neuen Property (z.B. "holdTime" in Sekunden) nur die Werte löschen lassen, die älter sind als der gewünschte Zeitbereich. Damit hätte man dann den Ringspeicher und könnte das Integral abhängig von einem Modifier wahlweise wertfortschreibend oder nachbarwertmittelnd berechnen (oder gleich beides auf einmal).

Wenn ich die so erweiterten TimeSeries-Klasse in das angefangene Analysis-Modul integriere, könnte es sich im Define mit den Einträgen aus einem (oder mehreren) Logs befüllen, mit Notify auf dem aktuellen Stand halten und die berechneten Integralwerte in die Quell-Devices zurückschreiben.

Werde mit dem Patch für TimeSeries anfangen und mich wieder melden, sobald es spruchreif ist.

LG, Jens

[jensb]

Hallo Boris,

anbei das erweiterte TimeSeries-Modul. Es ist erst mal nur kodiert und noch komplett ungetestet. Bevor es weiter geht, hätte ich gern gewusst, ob dir die Änderungen zusagen bzw. welche Anpassungen du für sinnvoll hältst.

Bitte sieh dir vor allem die geänderte Zeile 274 an. In der alten Version stand hier für method = "none":

Code Auswählen Erweitern

$self->_updatestat(1, $v);

aber die Methode _updatestat verarbeitet nur den 1. Parameter nach $self, ignoriert also das übergebene $v. Entsprechend wird dann nicht die Abweichung vom Mittelwert in _M aktualisiert, sondern _M bleibt 1 und damit auch mean - oder habe ich da was übersehen?

LG, Jens

[Dr. Boris Neubert]

Hallo,

wollte kurz Bescheid geben, dass ich Deinen Vorschlag gesehen habe, ihn mir aber dieses Wochenende noch nicht ansehen konnte.

Viele Grüße
Boris

[jensb]

Hallo Boris,

kein Problem, freue mich, dass du mich hier weiter unterstützen willst. Bin momentan unterwegs und komme nur selten ins Netz. Vor nächster Woche werde ich wohl auch nicht weiter machen können.

LG, Jens

[Dr. Boris Neubert]

Hallo,

habe mir das mittlerweile angesehen und bin damit einverstanden.

Ist das schon fertig, getestet und bereit zum Einchecken als TimeSeries.pm?

Viele Grüße
Boris

[jensb]

Hallo Boris,

das Modul ist nur codiert und nicht getestet, bitte noch nicht einchecken. Werde am Wochenende damit weiter machen und eine Testfunktion für beide Funktionsvarianten integrieren.

LG, Jens

[jensb]

Hallo,

habe die Erweiterungen des TimeSeries Moduls nun sowohl formal als auch praktisch getestet und bin über die Ergebnisse erfreut.

Es gibt folgende neue Funktionen:

• neue Eigenschaft "integral" enthält Integralwert der Messwerte, für "method=none" ist dies äquivalent mit der Summe der Messwerte
• Messwertspeicher: setzten der Eigenschaft "holdTime" aktiviert die Messdatenpufferung
• neue Methode "getValue" ermöglicht den Zugriff auf die gepufferte Messwerte
• ist die Eigenschaft "autoreset" nicht gesetzt, erfolgt die Messdatenpufferung für die von "holdTime" vorgegebene Dauer und statt der Block-Statistiken wird eine gleitende Statistik über die gepufferten Daten gebildet
• neue statische Methode "selftest" stellt einen einfachen Unit-Test zur Verfügung, der mit {TimeSeries::selftest} ausgeführt werden kann, ohne dass ein Testmodul erforderlich ist

Ähnlich wie bei der Klasse selbst ist auch bei der Methode "getValue" noch ein Methoden-Parameter (interpolieren, links, rechts, etc.) vorstellbar. Derzeit liefert die Methode immer den nächsten linken Wert.

Bezüglich der Abwärtskompatibilität habe ich nur einen formalen Test über die neue Methode "selftest" machen können. Es wäre sinnvoll, dass jemand, der bereits mit TimeSeries arbeitet, die neue Version ausprobiert, bevor sie eingecheckt wird.

Viel Spaß, Jens

[Dr. Boris Neubert]

Hallo Jens,

ich schaue mir das vermutlich nächstes Wochenende mal an und teste es auch für meinen Anwendungsfall.

Viele Grüße
Boris

[jensb]

Hallo Boris,

prima, bin gespannt auf dein Testergebnis.

LG, Jens

[Dr. Boris Neubert]

Hallo,

ich habe Deine Version jetzt ein paar Stunden am Laufen. Ich habe keine Veränderungen bei meinem Anwendungsfall festgestellt. Wenn Du auch der Meinung bist, dass die Version so in Ordnung ist, werde ich sie heute einchecken.

Ich vermute, dass Du noch Anpassungen am event-aggregator in fhem.pl brauchst. Wie willst Du dazu vorgehen? Wenn Du den Teil umprogrammierst, kann ich mir den Patch gerne ansehen und testen, bevor Du ihn an Rudi zum Einchecken schickst.

Viele Grüße
Boris