[PATCH] fhem.pl: event-min-interval in Verbindung mit event-on-...-reading

[Dr. Boris Neubert]

Hallo,

die aktuelle Behandlung von event-min-interval funktioniert nicht in Verbindung mit event-on-...-reading und ist auch noch nicht optimal. Anbei ein Patch, der ändert.

Viele Grüße
Boris

[rudolfkoenig]

Falls event-on-change-reading und event-min-interval gesetzt sind, dann wird. z.Zt. ein event ENTWEDER bei Aenderung, ODER nach X Sekunden erzeugt.
Deine Variante: ein Event wird NUR bei Aenderung UND hoechstens alle X Sekunden erzeugt.

Ob die beiden Attribute mit UND und nicht wie jetzt, mit ODER zu verknuepfen besser ist, ist mAn subjektiv. Deine Variante ist intuitiver, die aktuelle wurde als erstes "bestellt". Vermutlich sollte man konfigurabel beide anbieten, um alle zufrieden zu stellen.

[Dr. Boris Neubert]

Hallo,

kurz nachgedacht: warum braucht man ein Event bei Änderung aber mindestens alle X Sekunden? Weil man für Plots und Auswertungen alle verschiedenen Messwerte haben will und zusätzlich höchstens Lücken der Länge X Sekunden in der Zeitreihe. M.E. müsste das Attribut dafür event-max-interval heißen. Mich stört, dass sich event-min-interval in Kombination mit  event-on-change-reading anders verhält als ohne.

Die Doku

Code Auswählen Erweitern

Events will only be generated, if at least minInterval seconds elapsed since the last reading of the matched type. suggeriert, dass das Attribut mein Bedürfnis erfüllt:

Wenn es ein Event gibt (unter Beachtung von event-on-change-reading, event-on-update-reading) geben sollte, wird es nur ausgeworfen, wenn mindestens X Sekunden (Karenzzeit) vergangen sind.

Was ich wirklich brauche: das Event, das am Ende der Karenzzeit erzeugt wird, liefert als Wert den zeitlich gewichteten Mittelwert der während der Karenzzeit aufgelaufenen Werte.

Ich fasse meinen Vorschlag zusammen:

• event-min-interval <X>: so lassen und anders dokumentieren oder abschaffen oder den Requester dazu befragen
• event-period (average|stddev|min|max|first|last) <X> : für eine Zeit von mindestens X Sekunden seit dem letzten Event werden alle gleichnamigen Events gesammelt und nicht ausgeworfen. Beim Eintreffen des ersten Events bei oder nach Ablauf von X Sekunden wird zu diesem Zeitpunkt ein Event generiert und ausgeworfen, welches als Wert den zeitlich gewichteten Durchschnitt der gesammelten Werte/ die Standardabweichung der zeitlich gewichteten gesammelten Werte/ das Maximum der gesammelten Werte/ das Minimum der gesammelten Werte/ den ersten gesammelten Wert/ den letzten gesammelten Wert enthält. In die Betrachtung gehen a priori nur diejenigen Events ein, die unter Beachtung von event-on-change-reading, event-on-update-reading übrig bleiben.

Das mit der Standardabweichung ist kein Gag. In der Implementierung bekommt man das geschenkt. Man braucht zur Berechnung von Durchschnitt und Standardabweichung nicht die ganze Zeitreihe aufzuheben sondern nur zwei laufende Summen mitzuführen - Details liefere ich nach, falls mein Vorschlag auf Gegenliebe stößt.

Viele Grüße
Boris

[rudolfkoenig]

Das aktuelle Attribut sollten wir so lassen, wie es ist, und die Doku erweitern. Gegen ein event-period Patch habe ich nichts einzuwenden, andere Meinungen dazu wuerden mich aber interessieren. Mein Wunsch: die Funktionalitaet als separate Funktion, damit eine nachtraegliche Bearbeitung von protokollierten Werten moeglich wird.

[justme1968]

min kommt daher das es die untere schranke vorgibt nach der ein event das erste mal kommen kann. es kann ja auch länger sein.
max wäre die obere schranke nach der ein event auf jeden fall gekommen sein muss. die macht aber gar keinen sinn.

der satz aus der doku trifft ja auch zu. er muss nur um die beschreibung der verknüpfung ergänzt werden. bei event-on-update-reading/event-on-change-reading ist es ja auch beschrieben.

die statistik funktionen direkt in die event behandlung einzubauen finde ich eine sehr gute idee. das wäre dann modul übergreifend einheitlich. ich würde aber vorschlagen ein solches attribut nicht event-period  sondern event-statistics nennen. vielleicht sogar mit einer möglichkeit benutzerdefinierte funktionen zu verwenden. vielleicht ist ja auch der median interessant oder es sollen oben und unten offensichtliche ausreißer entfernt werden.

wenn die unterscheidung ob event-on-change-reading und event-min-interval und oder oder verknüpft sind noch gebraucht wird würde ich einen [:modifer] hinter den werten hinter event-min-interval vorschlagen. attr <device> event-min-interval reading1:AND reading2:OR und den default bei OR belassen.

[Dr. Boris Neubert]

Hallo Rudi,

was meinst Du mit

damit eine nachtraegliche Bearbeitung von protokollierten Werten moeglich wird.

?

Viele Grüße
Boris

[rudolfkoenig]

Z.Bsp. eine FileLog oder DbLog Funktion, die eine konsolidierte Version der Altdaten erstellt.

[Dr. Boris Neubert]

Du meinst, die Berechnungsmethoden in Funktionen wegkapseln, die sowohl aus der Eventbehandlung als auch auf Logs aufsetzenden Konsolidierungsfunktionen verwendet werden?

Hast Du ein Beispiel für mich, wo es eine solche auf Logs aufsetzende Konsolidierungsfunktion schon im Kode gibt?

Viele Grüße
Boris

[rudolfkoenig]

Nein, Beispiel habe ich nicht, sowas gibts mWn noch nicht.
Faende ich aber schoen, fuer Archivierungszwecke sowas haben zu koennen.

[Dr. Boris Neubert]

OK, im Prinzip braucht man eine leere Kiste, wo man Time/Value-Kombinationen reinwirft und TWA, StdDev, Min, Max, First, Last auf Anfrage herausbekommt.

Modul TimeSeries.pm

funktionale Form (vielleicht baue ich auch eine Klasse):

Code Auswählen Erweitern

%series= TimeSeries_Create();
TimeSeries_Clear(%series);
TimeSeries_Add(%series, $timestamp, $value);
$twa= TimeSeries_TWA(%series);
TimeSeries_Destroy(%series);


So was?

Grüße
Boris

[rudolfkoenig]

So kompliziert wollte ich es gar nicht haben.
Es reicht mir, wenn der Code fuer diese Statistiken aus readingsBulkUpdate in eine Funktion auswandert. readingsBeginUpdate/readingsEndUpdate kann wie bisher fuer die Initialisierung, etc verwendet werden. Oder anders: bau es ohne Funktion, ich werde es dann raustrennen.

[Dr. Boris Neubert]

Allein die zeitgewichteten Mittelwerte werden aufgrund der Fallunterscheidungen* schon so komplex, dass es das eigene Package rechtfertigt, welches ich gerade schreibe. Brauche eine kreative Pause bis nächste Woche.

Grüße
Boris


*Annahme einer Stufenfunktion vs. lineare Funktion, zwei aufeinanderfolgende Datenpunkte zeitlich enger zusammen als Zeitauflösung, Anzahl Datenpunkte ist 0 oder 1 oder größer.

[Dr. Boris Neubert]

Hallo,

bitte finde anbei einen Patch für fhem.pl, der noch einmal ein ganzes Arsenal an Möglichkeiten für alle Module eröffnet, die den readingsUpdate-Mechanismus nutzen. Der Patch greift auf das von mir heute hinzugefügte Modul TimeSeries.pm zurück.

Sofern der Patch gefällt und eingecheckt wird, baue ich noch die untenstehende Dokumentation in die commandref.html ein.

Viele Grüße
Boris

P.S.: auch wenn die Beschreibung unten vermuten lassen könnte, dass die Zeitreihe der aufgehaltenen Aktualisierungen von Readings zwischengespeichert wird: das geht auch ohne und sehr schlank.


readingFnAttributes

...

event-aggregator

The primary uses of this attribute are to calculate (time-weighted) averages of readings over time periods and to throttle the update rate of readings and thus the amount of data written to the logs.

This attribute takes a comma-separated list of reading:interval:method:function quadruples. You may use regular expressions for reading. If set, updates for the listed readings are ignored and associated events are suppressed for a black-out period of at least interval seconds.  After the black-out period has expired, the reading is updated with a value that is calculated from the values and timestamps of the previously ignored updates within the black-out period as follows:

function	description
v	the last value encountered
v0	the first value encountered
min	the smallest value encountered
max	the largest value encountered
mean	the arithmetic mean of all values
sd	the standard deviation from the mean

If method is none, then that's all there is. If method is const or linear, the time-weighted series of values is taken into account instead. The weight is the timespan between two subsequent updates. With the const method, the value is the value of the reading at the beginning of the timespan; with the linear method, the value is the arithmetic average of the values at the beginning and the end of the timespan. Rollovers of black-out periods are handled as one would expect it.

One would typically use the linear method with the mean function for quantities continuously varying over time like electric power consumption, temperature or speed. For cumulative quantities like energy consumed, rain fallen or distance covered, the none method with the v function is used. The constant method is for discrete quantities that stay constant until the corresponding reading is updated, e.g. counters, switches and the like.

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. Besides which, any update of a reading that occurs within a timespan from the preceding update that is smaller than the resolution of FHEM's time granularity is ditched.

Example:
attr myPowerMeter event-aggregator EP_POWER_METER:300:linear:mean,EP_ENERGY_METER:300:none:v

[rudolfkoenig]

Habs eingecheckt. Bitte die Doku in commandref_frame.html bzw. commandref_frame_DE.html  einfuegen.

[Dr. Boris Neubert]

Großartig! Vielen Dank.

EN-Übersetzung ist drin (auch in der deutschen commandref - werde ich demnächst übersetzen)

Viele Grüße
Boris