gleitender Mittelwert

[Joachim]

Moin @ all,

Ich wollte mal fragen, ob Interesse an gleitenden Mittelwerten besteht.
Dabei meine ich
- den gleitenden Arithmetischen Mittelwert
- den gleitenden Median
da ich für mich beide benötige, habe ich zum testen cloneDummy erweitert.
Ich bin allerdings der Meinung, das die Berechnung dort nicht hingehört.
Sinnvoller wäre es, das in die fhem.pl zu integrieren, z.B. beim event-aggregator, der es als rudimentären Ansatz ja schon hat.
Hier mal ein Bild indem der Mittelwert über 9 Werte gebildet wird.
(http://forum.fhem.de/index.php?action=dlattach;topic=46978.0;attach=43784;image)
Eventuell gibt es ja noch weitere Anregungen von Euch.
Als Anhang der cloneDummy um mit eigenen Werten zu experimentieren. (bitte nicht in Produktivumgebungen testen!)

gruß Joachim

[rudolfkoenig]

Ich bin der Meinung, dass sowas in einem separaten Modul gehoert, wie statistics oder average.

[Joachim]

@rudolf,
Danke ersteinmal für Deine Antwort.

Von der Reihenfolge her würde die Berechnung meiner Meinung nach
a) in die Module gehören, dagegen spricht aber die unnötige Codevervielfachung.
b1) in die fhem.pl, wo prinzipiell mit dem event-aggregator die Grundlagen mit mean geschaffen sind.
b2) in die fhem.pl,wo mit userreadings und dem modifer ebenfalls die Grundlagen vorhanden sind.
c) in einem seperaten Modul, egal ob "cloneDummy","statistics","average", hier kollidiert man allerdings mit event-on-change aus der fhem.pl

ich habe alle 3 Varianten bei mir ausprobiert, und mein Favorit wäre die fhem.pl.
mal sehen was die anderen Entwickler dazu sagen.
Wenn ich mit meiner Idee alleine bleibe, und der Bedarf nicht vorhanden ist, dann wird es der cloneDummy, da bei mir sowiso fast alle Readings über ihn laufen.
Egal, welcher Weg genommen wird, ich bin bereit, einen Patch dafür zu schreiben.

gruß Joachim

[rudolfkoenig]

Ich versuche fhem.pl minimal zu halten, damit es kein Engpass in der Entwicklung ist, lieber baue ich fuer Erweiterungen Schnittstellen, siehe Authentifizierung/Authorisierung. Ein gleitender Mittelwert ist mAn prinzipiell gleich wie ein Durchschnitt, man kann ihn also gut in externe Module verfrachten.

[Joachim]

Ich versuche fhem.pl minimal zu halten

Das verstehe ich sehr gut.
Ich brauche dann allerdings mal einen Schubser in die richtige Richtung.
für den gleitenden Mittelwert, egal ob Median oder Arithmetischer Mittelwert benötigt man jedes Reading und jeden Trigger vom Device, egal ob event-on-change gesetzt ist oder nicht.
Wo bekomme ich den Trigger her, wenn event-on-change gesetzt ist, und der Wert sich nicht verändert hat?

Beispiel:

Code Auswählen Erweitern


2016-01-01_00:00:26 Hz_00_FW_VL temperature: 24.9375
2016-01-01_00:00:33 Hz_00_FW_VL temperature: 24.875
2016-01-01_00:00:40 Hz_00_FW_VL temperature: 24.875 -----> wird durch event-on-change gefiltert
2016-01-01_00:00:47 Hz_00_FW_VL temperature: 24.875 -----> wird durch event-on-change gefiltert
2016-01-01_00:00:54 Hz_00_FW_VL temperature: 24.875 -----> wird durch event-on-change gefiltert
2016-01-01_00:01:01 Hz_00_FW_VL temperature: 24.8125
2016-01-01_00:01:08 Hz_00_FW_VL temperature: 24.8125 -----> wird durch event-on-change gefiltert
2016-01-01_00:01:15 Hz_00_FW_VL temperature: 24.8125 -----> wird durch event-on-change gefiltert

[rudolfkoenig]

1. Gar nicht. Wer Mittelwert haben will, soll keine event-on-change setzen
2. Der Mittlewert wird mit einem Timer berechnet, das funktioniert auch beim Ausbleiben von Nachrichten.

Eigentlich(TM) braucht man ein event-on-change, was nur fuer manche Empfaenger gilt (wie FileLog/notify/etc), aber nicht fuer alle.


Nachtrag: Ich meine es ist nicht richtig Mittelwert mit einer Methode zu rechnen, was man spaeter nicht mehr nachvollziehen kann.
D.h. wenn jemand einen beliebigen Filter setzt, dann akzeptiert er implizit, dass man ein Mittelwert der gefilterten Werte bekommt.

[herrmannj]

Ich war da nie ein Freund von. Wegen <siehe hier>

mMn sollten nicht die events am sender beschnitten werden sondern der Empfänger sollte sich darum kümmern. Das dürften mMn in ersten Linie LOG und evtl notify sein.

Ich plädiere dafür den log device (db, file) das beizubringen (log nur einen Wert pro 5min, nur wenn sich was ändert etc). Vlt noch dem notify...

vg
joerg

[Dr. Boris Neubert]

Hallo Joachim,

Ich wollte mal fragen, ob Interesse an gleitenden Mittelwerten besteht.

das gehört ins Modul TimeSeries.pm. Ein anderer Benutzer hat das bereits für sich implementiert. Ich finde nur gerade die Kommunikation dazu nicht, weiß nicht mehr, ob das im Forum oder per PM war. Der Benutzer wollte das mir zum Einchecken zur Verfügung stellen, ist aber nicht passiert.

Bitte suche selbst mal nach entsprechenden Stichworten im Forum.

Viele Grüße
Boris

[Dr. Boris Neubert]

Hier ist es: http://forum.fhem.de/index.php/topic,38479.0.html

[Joachim]

@ rudi,
ich glaube, wir reden ananeinder vorbei, nur wie drücke ich aus, was ich will?
Mir geht es darum,das Flattern eines Sensors zu glätten. Mir bekannt sind dafür 2 Methoden, die man in der Grafik im ersten Post sehen, und vergleichen kann.
Beides sind Mittelwerte, allerdings nicht um den Wert zu verfälschen, sondern um die Meßwerte zu beruhigen, damit sie sinnvoll weiterverarbeitet werden können. Mehrere flatternde Meßwerte miteinander kombiniert ergeben unschöne Sprünge (z.B. bei der Feuchteberechnung oder beim D-Anteil eines PID-Reglers).

@ joerg,

Ich war da nie ein Freund von. Wegen <siehe hier>

Dein Link ist nicht zu sehen, und auch hier, es geht nicht darum events des Devices zu beschneiden, sondern
a) Fehlmessungen zu filtern
b) Systematische Fehler an der Auflösungsgrenze des Sensors zu beseitigen

@ Boris,
Danke für das finden des Beitrages, den muß ich jetzt ersteinmal durchackern und verstehen.
Ich bin durchaus der Meinung, dass mein Wunsch im event-aggregator richtig aufgehoben ist.

gruß Joachim

[Dr. Boris Neubert]

Ich bin durchaus der Meinung, dass mein Wunsch im event-aggregator richtig aufgehoben ist.

Natürlich. Und event-aggregator verwendet TimeSeries, um das zu bewerkstelligen, was es tut. fhem.pl braucht nicht angefasst zu werden. Das entspricht Rudis Leitlinie.

Grüße
Boris

[jensb]

Hallo,

das erinnert mich daran, dass ich die Doku nachpflegen sollte. Hier die Kurzfassung:

readingFnAttribute - event-aggregator

function   description

integral    the arithmetic sum (if not time weighted) or integral area (if time weighted) of all values

Eine Patch für die Doku werde ich kurzfristig nachliefern.

Ich kann die Motivation für die verschiedenen Standpunkte gut nachvollziehen. Deshalb hatte ich mir zusätzlich noch ein Analysis-Modul auf Basis von TimeSeries geschrieben, mit dem man Integrale bzw. Differenzen von Readings über variable Zeiträume berechnen kann. Dieses Modul kann auch für das gleiche Reading unterschiedliche Berechnungen durchführen, was aber meist nur dann sinnvoll ist, wenn man für diese Readings keinen event-aggregator verwendet. Es ist noch etwas krude, funktioniert aber zuverlässig und bietet außerdem Persistenz für die Messwerte im zu berechnenden Zeitraum.

Grüße,
Jens