vorschlag für average

[justme1968]

ich würde gerne die folgenden beiden vorschläge für das average modul machen:

- den timestamp für die generierten events auf kurz vor mitternacht des tages zurück zu datieren für den die werte auch berechnet wurden. zur zeit ist es jeweils der auf den aufsummierten tag folgende. d.h. der durchschnitt/min/max für tag x wird mit dem ersten notify des folgetages berechnet und bekommt als timestamp den zeitpunkt dieser berechnung, also tag x+1. eigentlich sind es aber die werte für den tag x. für den min und max wert wäre eventuell auch der tatsächliche zeiptunk interessant. aber das wäre aufwändiger und dann würde der zweite vorschlag unten zumindest damit nicht mehr funktionieren.

- die gleichen readings zwei mal schreiben. einmal mit einem timestamp kurz nach mitternacht und ein mal mit einem timestamp kurz vor mitternacht. dann könnte man geringem aufwand zumindest in der zoom stufe tag den jeweiligen durchschnitt/min/max direkt als gerade in einem plott verwenden.

gruss
  andre

[rudolfkoenig]

Gerne, am besten das getestete Patch hier posten, damit _ich_ es einspiele (hint :)
Bitte beachten, dass FileLog von einem monotonen Zeitverlauf ausgeht.

[justme1968]

ist der monotone zeitverlauf eventtyp übergreifen wichtig oder reicht es wenn es innerhalb eines event typs monoton ist?

d.h. das folgende muß ok sein. sonst ist es mit FileLog nicht möglich sondern nur mit dbLog.

Code Auswählen Erweitern

2013-04-07_18:03:45 temp temperature 50
2013-04-07_00:00:01 temp temperature_avg_day: 40
2013-04-07_00:00:01 temp temperature_max_day: 50.0
2013-04-07_00:00:01 temp temperature_min_day: 30.0
2013-04-07_23:59:59 temp temperature_avg_day: 40
2013-04-07_23:59:59 temp temperature_max_day: 50.0
2013-04-07_23:59:59 temp temperature_min_day: 30.0
2013-04-07_18:03:45 temp temperature_avg_month: 60
2013-04-07_18:03:45 temp temperature_max_month: 80.0
2013-04-07_18:03:45 temp temperature_min_month: 20.0


die zweite sehr hilfreiche voraussetzung für einen recht einfachen patch wäre das es ok ist am ende von DoTrigger in fhem.pl $hash->{CHANGETIME} genau so zu löschen wie es mit $hash->{CHANGED} auch schon passiert. nach meinem eindruck sollte es möglich sein.

[rudolfkoenig]

>  ist der monotone zeitverlauf eventtyp übergreifen wichtig oder reicht es wenn es innerhalb eines event typs monoton ist?

Es muss innerhalb einer von FileLog geschriebenen Datei monoton sein, d.h. wenn man mehrere Geraete mit einem FileLog protokolliert, dann wird man hier erstmal Probleme bekommen, bzw. man muesste FileLog anpassen (nicht ganz trivial).

DbLog sollte deutlich weniger Probleme damit haben.

[justme1968]

die monotonie bedinung macht es eigentlich unmöglich readings zurück zu datieren. sogar im einfachsten fall den durchschnitt auf den tag zuvor kurz vor mitternacht zu legen wenn nicht sichergestellt ist das das log nur für ein einzges device gilt.

meinen anwendungsfall den mittelwert (oder min und max) als linie mit zu plotten lässt sich aber auch ganz einfach mit dem regex parameter in der colum_spec im plot file lösen. das ist so einfach und noch flexibler das ich es damit gut sein lasse.

[rudolfkoenig]

Unmoeglich ist das falsche Wort, aufwendig ist besser. FileLog muss in diesem Fall die Zeile an der richtigen Stelle einfuegen, was de-facto ein Neuschreiben der letzten Zeilen bedeutet.

[justme1968]

ich gebe zu auf die idee war ich noch nicht gekommen. ich weiss aber nicht ob es daran liegt weil die idee so genial ist oder so ungewöhnlich... aber aufwändig trifft es wirklich.