"event-aggregator" vs "event-on-change-reading"

[fron]

Ich dachte schon einen Fehler gefunden zu haben - konfiguriert ist:

Um alle Readings eines Gerätes nur bei Änderungen zu protokollieren, sollte das Attribut folgendermaßen gesetzt werden:
   

Code Auswählen Erweitern

attr <device> event-on-change-reading .*
    attr <device> event-aggregator power::none:median:110

und im Log landet z.B.

Code Auswählen Erweitern

power: 27.4
power: 27.5
power: 27.5
power: 27.6
power: 27.7
power: 27.7
power: 27.4


Man fragt sich, was hat die Funktion "on-change-reading" an der Folge "27.7 27.7" als Änderung bemerkt?

Nach dem Studium des Handbuchs - eine Antwort, aber keine Lösung - ich zitiere:

"The event aggregator only takes into consideration those updates that remain after preprocessing according to the event-on-update-reading and event-on-change-reading directives."

In welcher Situation macht es denn Sinn,
* zuerst: per "on-change" Events zu unterdrücken
* danach: per "event-aggregator" Statistikfunktionen wie Mittelwert oder Median zu berechnen
?

Beispiel:

Wenn meine Heizung in einer Minute 6x alle 10 Sekunden meldet:
* 10 Grad
dann ist der Mittelwert 10 Grad.

Wenn meine Heizung in einer Minute im 10 Sekunden-Intervall meldet
* 10, 10, 10, 10, 10, 20 - dann ist bei "on-change-reading .*" der Mittelwert "15"!!! - da beim event-aggregator "10, 20" ankommt
Wenn die Reihenfogle dagegen
* 10,  10, 10, 20, 10, 10 wäre - käme man auf einen Mittelwert von 13 - da beim event-aggregator dank on-change-reading "10, 20, 10" ankäme

Wollen wir wirklich eine Mittelwertsberechnung haben, die abhängig von der Reihenfolge der Eingangsdaten andere Werte berechnet???

Der korrekte Mittelwert wäre übrigens "70/6" - den berechnet der event-aggregator in Kombination mit einem verfälschenden on-change-Filter niemals...

Die Median-Berechnung fährt analog gegen die Wand, die muss auch jeden Eingangswert sehen.

"Ist das ein Bug oder ein Feature?", möchte man ketzerisch rufen...

Vielleicht stehe ich auch auf dem Schlauch, aber ich würde als intuitives Default-Setting erwarten:
* immer zuerst der "event-aggregator"
* dann "event-on-change-reading etc"

Lange Rede, Kurzer Sinn:
* Hat jemand eine Idee, wie man die Abarbeitungsreihenfolge ändern kann?

Dies wählbar zu machen, hielte ich für "over-engineered", da die Option "zuerst event-on-update-reading, dann event-aggregator" nie Sinn macht, falls ich mich mal am ersten Advent ganz weit aus dem Fenster lehnen darf

[LuckyDay]

 du könntest es noch mit "event-min-interval" beeinflussen.
um dich noch etwas zu verwirren.


Edit:
attr <device> event-on-change-reading .*

.* ist der joker für alles.
du kannst doch auch alle Readings die du als event-on-change haben willst einzeln dort eintragen,
und dein temperaturReading von der Heizung nur im event-aggregator.

[OdfFhem]

@fron

Die erste Ebene entscheidet, ob die Wertänderung zu einem Event führt.
Die zweite Ebene legt fest, was mit dem generierten Event passieren soll.

Laut Wiki gilt für event-aggregator:

Das Reading selbst muss seine Werte aus einer Aktion oder einem Event in FHEM erhalten

Die Umkehrung der Abarbeitungsreihenfolge macht damit wohl keinen Sinn.

Vielleicht erreicht man schon mit einer anderen Angabe als none einen besser errechneten Wert ...

[fron]

@OdfFhem

dh. die jetzige Iimplementierungl vom "event-aggregator" wurde in der jetzigen Form vorgenommen, da es nicht besser ging, und nicht in einer Form, wie es korrekt wäre?

Ich meine, die jetzige Implementierung führt dazu, dass eine Kombination von "event-on-change-reading" und "event-aggr" immer zu falschen Werten des "event-aggr" führt...

"immer" mag übertrieben sein, aber den Mittelwert und Median kann man knicken.
...daher... macht imho die jetzige Implentierung keinen Sinn...

Und - ich sehe im Zitat "Das Reading selbst muss seine Werte aus einer Aktion oder einem Event in FHEM erhalten." keine Einschränkung

ob die Reihenfolge wäre:
(1) Thermometer misst und löst zyklisch einen Event aus
(2) event-on-change unterdrückt Werte, wenn es nicht unterdrückt, löst es einen Event aus
(3) event-aggregator reagiert auf den Event von "event-on-change-reading" und berechnet einen unbrauchbaren Mittelwert/Median

oder die Reihenfolge wäre:
(1) Thermometer misst und löst zyklisch einen Event aus
(2) event-aggregator berechnet einen korrekten Mittelwert oder Median und löst einen Event aus
(3) event-on-change-reading unterdrückt uninteressante Mittelwerte/Medianwerte

Ich interessiere mich im Wesentlichen für LaCrosse-Sensoren, da gibt es bereits "doAverage" - im Notfall vergesse ich den event-aggregator wieder und implementiere ein "doMedian" direkt dort, falls das Eventsystem im Fhem anderweitig keine saubere Implementierung zulässt - was ich mir eigentlich überhaupt nicht vorstellen kann, ich denke das giinge durchaus und wir wissen nur nichts davon...

[fron]

@fhem-hm-knecht

ja, das ist mein augenblicklicher Workaround um das Schlamassel zu umgehen:
* ich lasse den event-aggregator nur auf "temperature", "humidity" etc. los
* ich lasse event-on-change... nur auf "state" los - beim LaCrosse-Sensor wird dieser aus Temperatur/Humidity/AbsHumidity/Taupunkt gebildet, fasst also 4 durch den event-aggregator berechnete Werte zusammen.

Das funktioniert und ich habe soweit korrekte Werte im Log.

Und da mir FHEM sehr gut gefällt, würde ich gerne ein bisschen zur Verbesserung beitragen, und wenn es evtl. unqualifiziertes Genörgel über kaputte Mittelwerte ist, um jemand Kompetenteren zu triggern, dass hoffentlich gar nicht so viel geändert werden muß um eine "richtig gute" Implementierungsvariante zu finden die zu noch mehr zufriedenen Usern führt

[OdfFhem]

@fron

Ich habe für einen kleinen Test mean statt median verwendet ...

Wenn die Reihenfogle dagegen 10,  10, 10, 20, 10, 10 wäre

Variante #1:

Code Auswählen Erweitern


  attr <device> event-on-change-reading .*
  attr <device> event-aggregator power::none:mean:110

Es ergibt sich für event-aggregator dank on-change-reading "10, 20, 10" ... der "Mittelwert" entspricht ungefähr 13,33 ...

Vielleicht erreicht man schon mit einer anderen Angabe als none einen besser errechneten Wert ...

Variante #2:

Code Auswählen Erweitern


  attr <device> event-on-change-reading .*
  attr <device> event-aggregator power::const:mean:110

Es ergibt sich für event-aggregator dank on-change-reading immer noch "10, 20, 10" ... der "Mittelwert" entspricht aber ungefähr 11,67 ...