Integralwertberechnung + Median über Zeitraum

[jensb]

Hallo Boris,

freut mich sehr, dass es keine (offensichtlichen) Nebenwirkungen bei deinem Test gibt.

Habe momentan keinen weiteren Änderungsbedarf, weil ich in meinem Analysis-Modul im Kern den Ablauf des statistics-Modul übernommen habe, um erst einmal ohne spezielle Infrastruktur für die Persistenz der Messwert-Historie und der Update-Benachrichtigung mit den Daten real arbeiten zu können. Insofern könnte der zuletzt gepostete Stand des TimeSeries-Moduls auch eingecheckt werden.

Über das Device-Change-Notify werden neue Samples hinzugefügt und die Ergebnisse aus TimeSeries in den Quell-Devices als Readings gespeichert. Die Samples selbst werden in CSV-Form im Analysis-Modul als Hidden Readings gehalten. 130 Samples benötigen ca. 2 kB. Wäre die Datenrate höher, wird das aber irgendwann zum Bottleneck.

Momentan wandle ich im Analysis-Modul festcodierte Parameter, die an TimeSeries übergeben werden müssen, schrittweise in Modul-Attribute um, damit das Modul flexibler wird. Außerdem prüfe ich gerade, ob es mehr als nur Integral und Differenz unterstützen sollte. Faktisch handelt es sich ja um Funktionen, die prinzipiell auch schon von anderen Modulen zur Verfügung gestellt werden. Die anderen Module verzichten dabei meist nur auf die Zeitgewichtung. Habe auch schon überlegt, hier austauschkompatibel vorzugehen. Alternativ könnte man das Ganze aber auch in die bestehenden Module integrieren, was aber wiederum einiges an Umbauarbeiten nach sich ziehen würden. Anbei einfach mal der Zwischenstand meines Moduls, in dem man auch sehen kann, wie das TimeSeries-Modul zu Einsatz kommt.

Bitte beschreibe mir, wie du das mit dem event-aggregator meinst, damit habe ich mich bisher nicht beschäftigt. Wenn es besser Wege gibt, an die Daten heranzukommen, würde ich mir das gern ansehen.

LG, Jens

[Dr. Boris Neubert]

Hallo Jens,

ist eingecheckt.

Zum event-aggregator siehe bitte auch Commandref.

Man kann damit bestimmen, dass ein neuer Wert nicht unmittelbar das Reading aktualisiert sondern erst in die Zeitreihe gesteckt wird. Ich nutze das, um die alle zwei bis drei Sekunden kommenden Messwerte eines Leistungsmessgeräts über eine Periode von 5 Minuten zu mitteln.

Ich weiß nicht genau, was Dein Analysis-Modul und das statistics-Modul tun, aber ich habe den Eindruck, dass der event-aggregator eine ähnliche Funktion bietet.

Viele Grüße
Boris

[jensb]

Hallo Boris,

danke fürs Einchecken und für den Hinweis auf "event-aggregator". Die Erweiterung von TimeSeries könnte man hier vielleicht aufnehmen, was u.U. mein Analysis-Modul überflüssig macht. Werde mir das im Detail ansehen und ein paar Tests machen.

LG, Jens

[jensb]

Hallo Boris,

die Verarbeitung des "event-aggregators" in fhem.pl habe ich in der Methode "readingsBulkUpdate" gefunden.

Um die zusätzlichen Funktionen zentral nutzbar zu machen, hier ein paar Ideen:

• Neue event-aggregator Funktion "integral - the sum or time-weighted integral of all values"
  
• Erweiterte event-aggregator Attribut-Syntax "reading:interval:method:function[:mode]" mit folgenden Möglichkeiten für mode: 
  
   
  • block - block operation for specified interval, default, may be omitted
  • moving - moving operation for specified interval, note: does not throttle update rate, once the interval of samples has been collected
• Optional: Neue TimeSeries Eigenschaft "delta - the difference between the last and the first value" und Bereitstellung als event-aggregator Funktion.
  

Der gleitende Modus widerspricht aber der Datenminimierung und damit der Grundidee des Attributs event-aggregator. Insofern ist zu überlegen, ob man statt des oben erwähnten Parameters "mode" besser einen neuen Attribute-Namen vergibt (z.B. event-collector), der die gleichen Funktionen wie event-aggregator anbietet.

Außerdem stellt sich für mich die Frage nach der Persistenz der Daten in TimeSeries bei der Verwendung über event-aggregator. Ist sie schon dadurch realisiert, dass die TimeSeries Instanz als weitere Eigenschaft mit dem Reading gespeichert wird oder speichert das nur die TimeSeries-Referenz? Wenn letzteres, könnte man die TimeSeries Daten z.B. in einem Hidden Reading halten. Allerdings bräuchte man dann auch noch eine Funktion, um die Daten in diesen Hidden Readings automatisch bei Delete des Quell-Readings und bei Bedarf auch manuell zu löschen, da es sich ja je nach Updaterate um relevante Datenmengen handeln kann, auf die man als User sonst keinen direkten Zugriff hätte.

LG, Jens

[Dr. Boris Neubert]

Hallo Jens,

Um die zusätzlichen Funktionen zentral nutzbar zu machen, hier ein paar Ideen:

• Neue event-aggregator Funktion "integral - the sum or time-weighted integral of all values"
  
• Erweiterte event-aggregator Attribut-Syntax "reading:interval:method:function[:mode]" mit folgenden Möglichkeiten für mode: 
  
   
  • block - block operation for specified interval, default, may be omitted
  • moving - moving operation for specified interval, note: does not throttle update rate, once the interval of samples has been collected
• Optional: Neue TimeSeries Eigenschaft "delta - the difference between the last and the first value" und Bereitstellung als event-aggregator Funktion.
  

Ich unterstütze inhaltlich Deinen Vorschlag voll und ganz.

Der gleitende Modus widerspricht aber der Datenminimierung und damit der Grundidee des Attributs event-aggregator. Insofern ist zu überlegen, ob man statt des oben erwähnten Parameters "mode" besser einen neuen Attribute-Namen vergibt (z.B. event-collector), der die gleichen Funktionen wie event-aggregator anbietet.

Ich habe mir den Kode dazu angesehen und auch ein über die Benennung nachgedacht. Ein neues Attribut event-collector würde dazu führen, dass der Kode in fhem.pl, Zeilen 3906 bis 3934 dupliziert werden müsste. Außerdem hat man ein grep mehr, das bei jedem Readings-Update ausgeführt wird. Ich würde daher das Attribut wiederverwenden mit der von Dir o.a. Syntax. Ein gleitendes Fenster ist m.E. auch eine Aggregation, so dass man den Namen auch rechtfertigen kann.

Außerdem stellt sich für mich die Frage nach der Persistenz der Daten in TimeSeries bei der Verwendung über event-aggregator. Ist sie schon dadurch realisiert, dass die TimeSeries Instanz als weitere Eigenschaft mit dem Reading gespeichert wird oder speichert das nur die TimeSeries-Referenz? Wenn letzteres, könnte man die TimeSeries Daten z.B. in einem Hidden Reading halten. Allerdings bräuchte man dann auch noch eine Funktion, um die Daten in diesen Hidden Readings automatisch bei Delete des Quell-Readings und bei Bedarf auch manuell zu löschen, da es sich ja je nach Updaterate um relevante Datenmengen handeln kann, auf die man als User sonst keinen direkten Zugriff hätte.

Je Reading mit event-aggregator-Verarbeitung wird ein Exemplar der TimeSeries-Klasse erzeugt und am Reading als verstecktes Hash-Element gespeichert. Löschen halte ich für nicht so wichtig, weil der von Dir oben beschriebene Anwendungsfall m.E. sehr selten ist. Gelöscht wird die Zeitreihe, wenn das event-aggregator-Attribut nicht mehr für das Reading gesetzt ist, sobald das Reading beim nächsten Mal aktualisiert wird.

Ich meine, dass die Zeitreihe einen Restart von FHEM nicht überlebt. Ich glaube, dass das auch gut so ist.

Viele Grüße
Boris

[jensb]

Hallo Boris,

danke für die detaillierte Rückmeldung.

... dass die Zeitreihe einen Restart von FHEM nicht überlebt

Das ist einerseits beruhigend, aber trotzdem ein Problem für bestimmte Szenarien. Z.B. starte ich manchmal FHEM ganz bewusst neu, um auch das Startverhalten der Module bewerten zu können. Da ich aber mit der gleitenden Integralfunktion z.T. auch relativ seltene Einzelereignisse erfasse (1 bis 2 pro Tag), würde es damit die gewünschte Funktion ad absurdum führen. Das Vergessen ist nur für hochfrequente Daten akzeptabel.

Um die Persistenz doch zu ermöglichen, könnte ich mir auch einen 6. Parameter im Attribut event-aggregator vorstellen, mit dem man die Persistenz explizit aktivieren muss. Eine Schleife beim Startup und Shutdown von FHEM kopiert dann zwischen den TimeSeries-Instanzen und Hidden Readings um, oder man nutzt hierfür eine eigene History-State-Datei. In beiden Varianten entsteht keine zusätzliche Last im laufenden Betrieb.


Habe mir die Abläufe um die gleitenden Berechnungen noch einmal durch den Kopf gehen lassen. Für eine möglichst universelle Verwendung der erforderlichen Datenbasis in FHEM könnte man meiner Ansicht nach auch folgendes machen:

• Option, um gezielt für einzelne Readings einen History-Cache (TIME/VAL) aktivieren zu können, ganz unabhängig von der weiteren Verwendung, um dadurch vor allem auch doppelte Datenhaltung zu vermeiden. Der History-Cache würde an der gleichen Stelle befüllt, wo jetzt die Werte an TimeSeries übergeben werden und könnte wie TIME und VAL zum Reading-Hash hinzugefügt werden. Durch eine entsprechend erweiterte Syntax des event-aggregator Attributs könnte man dies ohne zusätzlich erforderliches grep erreichen.


• optinal FHEM-Methoden zum Zugriff auf den History-Cache von außen (scalar GetReadingValue(device, reading, timestamp), array-ref GetReadingHistoryTimestamps/Values(device, reading))


• Anwendungsfunktionen, wie die Berechnung der gleitende Statistikwerte in TimeSeries, die bei Bedarf auf den History-Cache zugreifen, aber auch auf einem Subset des History-Cache operieren können (z.B. Reading mit History-Cache von 7 Tagen als Basis zur Berechnung von Mittelwerten für 1 h, 1 Tag und 1 Woche und Integral für 6 h statt 4 getrennten Daten-Arrays mit z.T. identischen Inhalt).

Ich musste das hier kurz los werden. 


Wir können gerne bei dem ursprünglichen Plan bleiben. In diesem Fall würde ich die Patches für fhem und TimeSeries vorbereiten. Es wäre schön, wenn wir auch eine gute Lösung für die Persistenz finden.

LG, Jens

[jensb]

Hallo Boris,

anbei die Aktualisierung für die Commandref für den aktuellen Stand der Implementierung der Integralberechnung über TimeSeries. Kannst du sie bitte einchecken?

Einige der von uns bereits diskutierten Features sind noch nicht umgesetzt:

• Erweiterte event-aggregator Attribut-Syntax mit mode
• Neue TimeSeries Eigenschaft delta

Wenn du sie nach wie vor für sinnvoll hältst, mache ich gern die erforderlichen Anpassung.

Grüße,
Jens

[Dr. Boris Neubert]

Hallo Jens,

Danke für die Doku - ich habe die Patches angewendet und das Ergebnis eingecheckt.

Nach dem gleitenden Durchschnitt wurde in dem anderen Thema gefragt, wo Du auch präsent bist. Ich bin bereit, entsprechende Erweiterungen einzuchecken.

Das muss gut getestet sein. Vielleicht mag Joachim aus dem anderen Thema mit Dir zusammen arbeiten?

Viele Grüße
Boris

[Joachim]

Moin Boris, Moin Jens,

Ich habe kein Problem damit, mit Jens zusammenzarbeiten.
Mein Plan ist zur Zeit so, dass ich ersteinmal meinen cloneDummy so anpasse, wie ich glaube, ihn zu brauchen.
Damit das fertig ist, bevor die Heizsaison zuende ist.
Parallel sehe ich mir timeseries.pm an.
Wenn es was zu testen oder zu helfen gibt, melde ich mich oder ihr.

Gruß Joachim

[knxhm]

@Jens und @Boris,

das ist die von mir abgeänderte Version von TimeSeries.pm. Die Änderungen dienen dazu, Messfehler bei meiner Temperaturmessung auszubügeln (aussentemp_median.png), siehe Bilder.
Ich habe 1wire Temperaturmessung am gpio4 am Raspi, das produziert sporadisch Ausreisser die die Temperaturkurve dann völlig flachlegen (aussentemp_direkt.png).

Mein Problem kann man mit dem vorhandenen Funktionen im event-aggregator nicht gut beheben, deswegen median, das eliminiert alle Ausreisser, egal ob positive oder negative.

Persistenz ist nicht nötig.

Ich habe dazu auch eine Änderung in der fhem.pl gemacht (bzw. müssen), damit TimeSeries.pm den holdTime übergeben bekommt und damit die v/tSeries gespeichert werden, statt dem autoreset.

fhem.pl alt

Code Auswählen Erweitern


        require "TimeSeries.pm";
        $ts= TimeSeries->new( { method => $method, autoreset => $duration } );


fhem.pl geändert

Code Auswählen Erweitern


       require "TimeSeries.pm";
        $ts= TimeSeries->new( { method => $method, holdTime => $duration } );


Code Auswählen Erweitern


event-aggregator
temperature:600:linear:median


Die Frage is nun, ob und wie man das alles so unterbringen kann das es vernünftig parametrierbar wird ohne etwas anderes kaputtzumachen.

Grüße
knxhm

[jensb]

Hallo knxhm,

ohne das heute noch im Detail pruefen zu koennen, wird es bei deinem Vorschlag wohl noch erforderlich sein, die Parameter fuer 'new'  in Abhaengikeit des 4. Parameters (also z.B. median mit holdTime) unterschiedlich zu setzen, damit sowohl die bestehenden als auch die neuen Funktionen so arbeiten, wie sie sollen.

Gruesse,
Jens

[knxhm]

Hallo Jens
ja ich denke es ist eine gute Möglichkeit in fhem.pl an der Stelle eine Abfrage einzubauen ob als function median gesetzt ist und wenn ja die duration als holdTime zu übergeben statt als autoreset. Wenn wir den fhem.pl maintainer überzeugen können.
Gruesse
knxhm

[jensb]

Hallo knxhm,

habe deinen Vorschlag für TimeSeries ein bisschen überarbeitet, hoffe du erkennst ihn noch wieder

Nochmal testen wäre auch eine gute Idee. Bitte beachte, dass du dazu das Attribut "event-aggregator" von "temperature:600:linear:median" auf "temperature:600:none:median" ändern musst, denn der Median ist, so wie du ihn umgesetzt hast, nicht zeitgewichtet sondern nur von der Anzahl der Stichproben abhängig und fällt damit in die Variante "method => none".

Vielleicht hast du auch noch eine Idee, wie man den Median auch für die Varianten const und/oder linear realisieren könnte.

Die Anpassungen für fhem.pl würde ich mir in den nächsten Tagen ansehen.

Grüße,
Jens

[knxhm]

Hallo Jens,
ja, ich erkenne ihn noch. Das ist Median wie er im Buche steht, so weit wollte ich es gar nicht treiben, ich wär mit dem näherungsweisen Median auch zufrieden gewesen. Aber danke fürs perfektionieren.
Ich hab das geänderte Modul installiert und neu parametriert, schaun wir mal was es die nächsten Tage macht. Sollte eigentlich gehen.

Was die verschiedenen Methoden anbelangt, ich denke man kann bei Median gar nichts anderes machen als alles sortieren und in die Mitte greifen weil man eben nur am mittleren Wert interessiert ist ... . Ich wüsste nicht wie man da einen unterschiedlichen zeitlichen Abstand der Messwerte berücksichtigen könnte.
Mit dem Integral kann man das nicht vergleichen, das ist ganz was anderes.
lg
knxhm

[knxhm]

Hallo Jens
hab mich noch ein bischen gespielt und eine Merkwürdigkeit entdeckt. Jedesmal wenn ich den Zeitwert ändere, dann erhöht sich die Anzahl der Elemente in v/tSeries um 1, und zwar egal ob ich den Zeitwert erhöhe oder runtersetze. Ich hab mit 600 angefangen, dann ...

Code Auswählen Erweitern


600
2016.01.26 09:36:10 1: DEBUG>sortedv (10.25 10.312 10.312 10.375 10.375 10.5 10.625 10.625 10.75 10.75)
2016.01.26 09:36:10 1: DEBUG>median (10.4375)
2016.01.26 09:37:14 1: DEBUG>center (5)
2016.01.26 09:37:14 1: DEBUG>sortedv (10.25 10.312 10.375 10.375 10.5 10.625 10.625 10.75 10.75 10.75)
2016.01.26 09:37:14 1: DEBUG>median (10.5625)
2016.01.26 09:38:17 1: DEBUG>center (5)
2016.01.26 09:38:17 1: DEBUG>sortedv (10.25 10.312 10.375 10.5 10.625 10.625 10.75 10.75 10.75 10.75)
2016.01.26 09:38:17 1: DEBUG>median (10.625)
540
2016.01.26 09:38:45 1: DEBUG>center (5)
2016.01.26 09:38:45 1: DEBUG>sortedv (10.25 10.312 10.375 10.5 10.625 10.625 10.687 10.75 10.75 10.75 10.75)
2016.01.26 09:38:45 1: DEBUG>median (10.625)
2016.01.26 09:39:21 1: DEBUG>center (5)
2016.01.26 09:39:21 1: DEBUG>sortedv (10.25 10.375 10.5 10.625 10.625 10.687 10.687 10.75 10.75 10.75 10.75)
2016.01.26 09:39:21 1: DEBUG>median (10.687)
2016.01.26 09:40:24 1: DEBUG>center (5)
2016.01.26 09:40:24 1: DEBUG>sortedv (10.375 10.5 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75)
2016.01.26 09:40:24 1: DEBUG>median (10.687)
2016.01.26 09:41:28 1: DEBUG>center (5)
2016.01.26 09:41:28 1: DEBUG>sortedv (10.5 10.625 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75)
2016.01.26 09:41:28 1: DEBUG>median (10.687)
480
2016.01.26 09:41:43 1: DEBUG>center (6)
2016.01.26 09:41:43 1: DEBUG>sortedv (10.5 10.562 10.625 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75)
2016.01.26 09:41:43 1: DEBUG>median (10.687)
2016.01.26 09:42:32 1: DEBUG>center (6)
2016.01.26 09:42:32 1: DEBUG>sortedv (10.562 10.625 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75 10.812)
2016.01.26 09:42:32 1: DEBUG>median (10.687)
420
2016.01.26 09:42:49 1: DEBUG>center (6)
2016.01.26 09:42:49 1: DEBUG>sortedv (10.562 10.625 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75 10.812 10.812)
2016.01.26 09:42:49 1: DEBUG>median (10.687)
2016.01.26 09:43:35 1: DEBUG>center (6)
2016.01.26 09:43:35 1: DEBUG>sortedv (10.562 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75 10.812 10.812 10.875)
2016.01.26 09:43:35 1: DEBUG>median (10.75)
540
2016.01.26 09:43:50 1: DEBUG>center (7)
2016.01.26 09:43:50 1: DEBUG>sortedv (10.562 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75 10.812 10.812 10.875 10.875)
2016.01.26 09:43:50 1: DEBUG>median (10.75)
600
2016.01.26 09:43:59 1: DEBUG>center (7)
2016.01.26 09:43:59 1: DEBUG>sortedv (10.562 10.625 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75 10.812 10.812 10.875 10.875 10.875)
2016.01.26 09:43:59 1: DEBUG>median (10.75)
2016.01.26 09:43:59 1: DEBUG>median (10.75)
2016.01.26 09:44:39 1: DEBUG>center (7)
2016.01.26 09:44:39 1: DEBUG>sortedv (10.562 10.625 10.687 10.687 10.687 10.75 10.75 10.75 10.75 10.812 10.812 10.875 10.875 10.875 10.937)
2016.01.26 09:44:39 1: DEBUG>median (10.75)
2016.01.26 09:45:43 1: DEBUG>center (7)
2016.01.26 09:45:43 1: DEBUG>sortedv (10.562 10.625 10.687 10.687 10.687 10.75 10.75 10.812 10.812 10.875 10.875 10.875 10.937 10.937)
2016.01.26 09:45:43 1: DEBUG>median (10.781)
2016.01.26 09:46:46 1: DEBUG>center (7)
2016.01.26 09:46:46 1: DEBUG>sortedv (10.562 10.625 10.687 10.687 10.687 10.75 10.812 10.812 10.875 10.875 10.875 10.937 10.937 10.937)
2016.01.26 09:46:46 1: DEBUG>median (10.812)
2016.01.26 09:47:50 1: DEBUG>center (6)
2016.01.26 09:47:50 1: DEBUG>sortedv (10.562 10.625 10.687 10.687 10.812 10.812 10.875 10.875 10.875 10.937 10.937 10.937 11)
2016.01.26 09:47:50 1: DEBUG>median (10.875)
2016.01.26 09:48:53 1: DEBUG>center (6)
2016.01.26 09:48:53 1: DEBUG>sortedv (10.562 10.625 10.687 10.812 10.812 10.875 10.875 10.875 10.937 10.937 10.937 11 11)
2016.01.26 09:48:53 1: DEBUG>median (10.875)
2016.01.26 09:49:57 1: DEBUG>center (6)
2016.01.26 09:49:57 1: DEBUG>sortedv (10.562 10.625 10.812 10.812 10.875 10.875 10.875 10.937 10.937 10.937 10.937 11 11)
2016.01.26 09:49:57 1: DEBUG>median (10.875)
2016.01.26 09:51:01 1: DEBUG>center (6)
2016.01.26 09:51:01 1: DEBUG>sortedv (10.812 10.812 10.875 10.875 10.875 10.875 10.937 10.937 10.937 10.937 11 11)
2016.01.26 09:51:01 1: DEBUG>median (10.906)
2016.01.26 09:52:05 1: DEBUG>center (5)
2016.01.26 09:52:05 1: DEBUG>sortedv (10.812 10.875 10.875 10.875 10.875 10.937 10.937 10.937 10.937 11 11)
2016.01.26 09:52:05 1: DEBUG>median (10.937)
2016.01.26 09:53:09 1: DEBUG>center (4)
2016.01.26 09:53:09 1: DEBUG>sortedv (10.75 10.812 10.875 10.937 10.937 10.937 10.937 11 11)
2016.01.26 09:53:09 1: DEBUG>median (10.937)
2016.01.26 09:54:13 1: DEBUG>center (4)
2016.01.26 09:54:13 1: DEBUG>sortedv (10.687 10.75 10.812 10.875 10.937 10.937 10.937 11 11)
2016.01.26 09:54:13 1: DEBUG>median (10.937)



Da kommt wohl das trimToHoldTime ein bischen aus dem Takt.
Etwas später werdens dann aber doch wieder wieder weniger ohne das ich noch was gemacht habe ?
lg
knxhm