Hallo,
seit einiger Zeit gibt es die Integral-Option bei den userReadings, die auf dem Mittelwert von zwei aufeinanderfolgenden Werten aufbaut.
Für meine Bewässerungssteruerung benötige ich aber z.B. die Gesamtwassermenge innerhalb der letzten 24 Stunden, was aus mehreren Stundenmesswerten [l/(m2*h)] aufsummiert werden muss - und zwar immer wieder neu mit jedem neuen Messwert, da ja die ältesten Messwerte jeweils aus der Berechnung herausfallen sollen (wie bei einer Blockmittelwertberechnung). Die gleiche Berechnung möchte ich u.a. auch für die Differenz zwischen Taupunkt und Temperatur durchführen.
Neben dem wählbaren Zeitraum benötigt man eine Option, ob man das Integral durch Fortschreiben des letzten Wertes (für sprungfähige Messdaten wie den Niederschlag/Stunde) oder über den Mittelwert zwischen zwei Werten (für stetige Messdaten wie die Temperatur) berechnen will.
Ein Weg, den ich sehe, wäre es, über ein at oder notify das Modul readingsHistory aufzurufen, die Berechnung durchzuführen und das Ergebnis als Reading zu speichern - aber das ist schon ziemlich indirekt, vor allem wenn man das für diverse Readings so machen muss.
Kennt jemand eine Möglichkeit, eine Integralfunktion noch einfacher umzusetzten?
LG, jensb
Hi,
brauchst Du nur einen neuen modifier oder ein Funktionalität mit gleitendem Fenster?
Grüße
Boris
Hi Boris,
glaube nicht, dass es mit einem Modifier getan ist, da man ja auf einem Ringspeicher von Werten arbeiten müsste, die normalerweise nicht im Reading des Quell-Devices vorhanden sind. Die benötigten Werte sind je nach eigener Konfiguration manchmal in einem Log, aber meist ist man ja nicht bei jedem Reading an der Historie interessiert.
Habe mir die Module statistics, dewpoint und readingsHistory von innen angesehen. Sie haben eine gemeinsame Basis und verstecken die Hilfswerte in Hidden Readings. Dabei handelt es sich aber meist nur um eine Handvoll Werte. Bei einem Reading, dass sich oft ändert, kommen für einen Zeitraum von z.B. 24 Stunden schnell relevante Datenmengen zusammen. Die sollte man einerseits im RAM halten, damit die Neuberechnung schnell genug abläuft. Andererseits müsste man die Daten aber auch persistent machen. Das Modul readingsHistory verwendet dafür scheinbar Dumper.
Inzwischen habe ich mit einem Skelett für ein neues Analysis-Modul angefangen, dass diese Funktionen zur Verfügung stellen soll. Bin mir aber nach wie vor nicht schlüssig, was der sinnvollste Weg für den RAM-Cache und die Persistenz ist. Den RAM-Cache könnte man in einem Hash (ReadingName) von Arrays (Zeit + Wert) unterbringen. Für die Persistenz könnte man z.B. eigene Files erzeugen, aber mir würde es besser gefallen, wenn man auf bereits vorhandene Logs zurückgreift, damit die Daten nicht doppelt gehalten werden.
LG, Jens
Hallo Jens,
schau Dir bitte mal das TimeSeries-Modul an. Ich bin für Patches offen, aber Ringbuffer unterstützt es ohne größere Änderungen nicht.
Viele Grüße
Boris
Hallo Boris,
vielen Dank für den Hinweis. Mache ich nachher.
LG, Jens
Hallo Boris,
TimeSeries ist ein prima Container für zeitbezogenen Messwerte und damit steht schon mal ein RAM-Cache zur Verfügung. Allerding müsste man die Elapsed- und Reset-Funktion in Abhängigkeit von einem neuen Property (z.B. "holdTime" in Sekunden) nur die Werte löschen lassen, die älter sind als der gewünschte Zeitbereich. Damit hätte man dann den Ringspeicher und könnte das Integral abhängig von einem Modifier wahlweise wertfortschreibend oder nachbarwertmittelnd berechnen (oder gleich beides auf einmal).
Wenn ich die so erweiterten TimeSeries-Klasse in das angefangene Analysis-Modul integriere, könnte es sich im Define mit den Einträgen aus einem (oder mehreren) Logs befüllen, mit Notify auf dem aktuellen Stand halten und die berechneten Integralwerte in die Quell-Devices zurückschreiben.
Werde mit dem Patch für TimeSeries anfangen und mich wieder melden, sobald es spruchreif ist.
LG, Jens
Hallo Boris,
anbei das erweiterte TimeSeries-Modul. Es ist erst mal nur kodiert und noch komplett ungetestet. Bevor es weiter geht, hätte ich gern gewusst, ob dir die Änderungen zusagen bzw. welche Anpassungen du für sinnvoll hältst.
Bitte sieh dir vor allem die geänderte Zeile 274 an. In der alten Version stand hier für method = "none":
$self->_updatestat(1, $v);
aber die Methode _updatestat verarbeitet nur den 1. Parameter nach $self, ignoriert also das übergebene $v. Entsprechend wird dann nicht die Abweichung vom Mittelwert in _M aktualisiert, sondern _M bleibt 1 und damit auch mean - oder habe ich da was übersehen?
LG, Jens
Hallo,
wollte kurz Bescheid geben, dass ich Deinen Vorschlag gesehen habe, ihn mir aber dieses Wochenende noch nicht ansehen konnte.
Viele Grüße
Boris
Hallo Boris,
kein Problem, freue mich, dass du mich hier weiter unterstützen willst. Bin momentan unterwegs und komme nur selten ins Netz. Vor nächster Woche werde ich wohl auch nicht weiter machen können.
LG, Jens
Hallo,
habe mir das mittlerweile angesehen und bin damit einverstanden.
Ist das schon fertig, getestet und bereit zum Einchecken als TimeSeries.pm?
Viele Grüße
Boris
Hallo Boris,
das Modul ist nur codiert und nicht getestet, bitte noch nicht einchecken. Werde am Wochenende damit weiter machen und eine Testfunktion für beide Funktionsvarianten integrieren.
LG, Jens
Hallo,
habe die Erweiterungen des TimeSeries Moduls nun sowohl formal als auch praktisch getestet und bin über die Ergebnisse erfreut.
Es gibt folgende neue Funktionen:
- neue Eigenschaft "integral" enthält Integralwert der Messwerte, für "method=none" ist dies äquivalent mit der Summe der Messwerte
- Messwertspeicher: setzten der Eigenschaft "holdTime" aktiviert die Messdatenpufferung
- neue Methode "getValue" ermöglicht den Zugriff auf die gepufferte Messwerte
- ist die Eigenschaft "autoreset" nicht gesetzt, erfolgt die Messdatenpufferung für die von "holdTime" vorgegebene Dauer und statt der Block-Statistiken wird eine gleitende Statistik über die gepufferten Daten gebildet
- neue statische Methode "selftest" stellt einen einfachen Unit-Test zur Verfügung, der mit {TimeSeries::selftest} ausgeführt werden kann, ohne dass ein Testmodul erforderlich ist
Ähnlich wie bei der Klasse selbst ist auch bei der Methode "getValue" noch ein Methoden-Parameter (interpolieren, links, rechts, etc.) vorstellbar. Derzeit liefert die Methode immer den nächsten linken Wert.
Bezüglich der Abwärtskompatibilität habe ich nur einen formalen Test über die neue Methode "selftest" machen können. Es wäre sinnvoll, dass jemand, der bereits mit TimeSeries arbeitet, die neue Version ausprobiert, bevor sie eingecheckt wird.
Viel Spaß, Jens
Hallo Jens,
ich schaue mir das vermutlich nächstes Wochenende mal an und teste es auch für meinen Anwendungsfall.
Viele Grüße
Boris
Hallo Boris,
prima, bin gespannt auf dein Testergebnis.
LG, Jens
Hallo,
ich habe Deine Version jetzt ein paar Stunden am Laufen. Ich habe keine Veränderungen bei meinem Anwendungsfall festgestellt. Wenn Du auch der Meinung bist, dass die Version so in Ordnung ist, werde ich sie heute einchecken.
Ich vermute, dass Du noch Anpassungen am event-aggregator in fhem.pl brauchst. Wie willst Du dazu vorgehen? Wenn Du den Teil umprogrammierst, kann ich mir den Patch gerne ansehen und testen, bevor Du ihn an Rudi zum Einchecken schickst.
Viele Grüße
Boris
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
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
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
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
Hallo Jens,
Zitat von: jensb am 02 August 2015, 14:10:23
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.
Zitat
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.
Zitat
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
Hallo Boris,
danke für die detaillierte Rückmeldung.
Zitat... 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
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
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
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
@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
require "TimeSeries.pm";
$ts= TimeSeries->new( { method => $method, autoreset => $duration } );
fhem.pl geändert
require "TimeSeries.pm";
$ts= TimeSeries->new( { method => $method, holdTime => $duration } );
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
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
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
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
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
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 ...
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
Hallo knxhm,
du hast wahrscheinlich weiter neue Updates auf das Reading bekommen, während du die holdTime geändert hast, denn gegen Ende werden die Werte betragsmäßig größer.
TimeSeries arbeitet zeitbasiert. Die holdTime stellt keine feste Anzahl von Werten ein, sondern das Alter für das älteste zu erhaltende Sample. Je nach dem, in welchem Takt die Reading-Updates erfolgen, hat man also mal mehr oder mal weniger Samples zur Verfügung.
Der Abstand zwischen zwei "sortdev" Logs ist bei dir nicht immer gleich. Um eine ungefähr konstante Anzahl zu verarbeiten, müsste man äquidistant sampeln. Zum Filtern vereinzelter Ausreißer reicht es aber sicherlich, wenn man eine holdTime einstellt, die im Normalfall eine Mindestanzahl von 5 (oder mehr) Samples sicherstellt, denn es ist bei der Median-Bestimmung kein Nachteil, wenn es vorübergehend auch mal mehr Samples werden.
Grüße,
Jens
Hallo Jens,
der gpio4 liefert mir per default ungefähr jede Minute eine Messung und das ist mir auch recht so. Wenn es also einen neuen Messwert gibt, dann sollte der älteste alt genug sein um zu verschwinden.
Deswegen habe ich normalerweise bei Zeitintervall 600 auch 10 Werte im Puffer von denen dann der Median genommen wird. Alles ok.
Wenn ich das Zeitinterval ändere dann erzeuge ich doch wohl keine neuen Messwerte, die kommen doch immer im gleichen Takt, oder ?
Deswegen kann ich mir die Erhöhung der Anzahl nach der Zeitänderung nicht recht erklären. Aber nachdem es sich nach einer Zeit eh wieder einpendelt, ist es wohl egal.
Heute hat er mir jedenfalls eine plausible Kurve gezeichnet, ohne die Nadelspitzen die ich loswerden wollte und abgestürzt ist er auch nicht. Alles gut.
lg
knxhm
Hallo knxhm,
freut mich, dass das so schon mal grundsätzlich funktioniert.
ZitatWenn ich das Zeitinterval ändere dann erzeuge ich doch wohl keine neuen Messwerte, die kommen doch immer im gleichen Takt, oder ?
Das Zeitintervall ist nur ein Wert der TimeSeries-Klasseninstanz und wirkt sich erst aus, wenn wieder neue Messwerte hinzugefügt werden.
Wenn du herausfinden willst, was wirklich passiert, dann dopple über ein notify zuerst das Original-Reading vom Sensor ohne event-aggregator auf einen 2. Reading-Namen und setze auf diesen den event-aggregator. Wenn du jetzt im Event-Monitor zusiehst oder beide Readings in ein Logfile schreibst, kannst du herausfinden, was wirklich passiert.
Grüße,
Jens
Hallo Jens,
hab einen dummy angelegt und mit einem notify ein userreading gesetzt, was ich dabei gesehen habe ist jedoch verwirrend.
Das ADD in TimeSeries.pm wird bei jedem Event 2mal aufgerufen und ich versteh nicht warum. Wobei beim 2. Aufruf ein Element mehr in der Series steht. Kannst du dir das erklären ?
config
pi@knxdfhem /opt/fhem $ grep Aussente fhem.cfg
define Aussentemp GPIO4 28-00000656fa4e
attr Aussentemp model DS18B20
attr Aussentemp room temperatur
define FileLog_Aussentemp FileLog ./log/Aussentemp-%Y-%W.log Aussentemp:temperature.*
attr FileLog_Aussentemp logtype text
define SVG_FileLog_Aussentemp_1 SVG FileLog_Aussentemp:SVG_FileLog_Aussentemp_1:CURRENT
attr SVG_FileLog_Aussentemp_1 nrAxis 1
attr SVG_FileLog_Aussentemp_1 room svg
define duAussentemp dummy
attr duAussentemp event-aggregator temp:300:none:median
attr duAussentemp room temperatur
attr duAussentemp userReadings temp
define noAussentemp notify Aussentemp setreading duAussentemp temp {(ReadingsVal("Aussentemp","temperature",""))}
attr noAussentemp disable 0
fhem.pl Auszug:
require "TimeSeries.pm";
if($function eq "median") {
$ts= TimeSeries->new( { method => $method, holdTime => $duration } );
} else {
$ts= TimeSeries->new( { method => $method, autoreset => $duration } );
}
$readings->{".ts"}= $ts;
# access from command line:
# { $defs{"myClient"}{READINGS}{"myValue"}{".ts"}{max} }
#Debug "TimeSeries created.";
}
my $now = $hash->{".updateTime"};
my $val = $value; # save value
$changed = $ts->elapsed($now);
$value = $ts->{$function} if($changed);
Debug("$name voradd ");
$ts->add($now, $val);
TimeSeries.pm Auszug
# median
if(defined($self->{holdTime})) {
my @sortedVSeries = sort {$TimeSeries::a <=> $TimeSeries::b} @{$self->{vSeries}};
my $center = int($self->{count} / 2);
main::Debug("vSeries (@{$self->{vSeries}})"); ###
main::Debug("center ($center)"); ###
main::Debug("sortedv (@sortedVSeries)"); ###
if($self->{count} % 2 == 0) {
$self->{median} = (@sortedVSeries[$center - 1] + @sortedVSeries[$center]) / 2;
} else {
$self->{median} = @sortedVSeries[$center];
}
main::Debug("median ($self->{median})"); ###
}
} else {
# time-weighting
debuglog
2016.01.29 08:03:48 5: Notify loop for HMLAN1 loadLvl: low
2016.01.29 08:04:01 5: Triggering Aussentemp (2 changes)
2016.01.29 08:04:01 5: Notify loop for Aussentemp T: 6
2016.01.29 08:04:01 5: Triggering noAussentemp
2016.01.29 08:04:01 4: noAussentemp exec setreading duAussentemp temp {(ReadingsVal("Aussentemp","temperature",""))}
2016.01.29 08:04:01 5: Cmd: >setreading duAussentemp temp {(ReadingsVal("Aussentemp","temperature",""))}<
2016.01.29 08:04:01 1: DEBUG>duAussentemp voradd
2016.01.29 08:04:01 1: DEBUG>vSeries (6 6 6 6 6 6 6 6 6)
2016.01.29 08:04:01 1: DEBUG>center (4)
2016.01.29 08:04:01 1: DEBUG>sortedv (6 6 6 6 6 6 6 6 6)
2016.01.29 08:04:01 1: DEBUG>median (6)
2016.01.29 08:04:01 5: Triggering duAussentemp (1 changes)
2016.01.29 08:04:01 5: Notify loop for duAussentemp temp: 6
2016.01.29 08:04:01 5: Triggering noAussentemp
2016.01.29 08:04:01 4: noAussentemp exec setreading duAussentemp temp {(ReadingsVal("Aussentemp","temperature",""))}
2016.01.29 08:04:01 5: Cmd: >setreading duAussentemp temp {(ReadingsVal("Aussentemp","temperature",""))}<
2016.01.29 08:04:01 1: DEBUG>duAussentemp voradd
2016.01.29 08:04:01 1: DEBUG>vSeries (6 6 6 6 6 6 6 6 6 6)
2016.01.29 08:04:01 1: DEBUG>center (5)
2016.01.29 08:04:01 1: DEBUG>sortedv (6 6 6 6 6 6 6 6 6 6)
2016.01.29 08:04:01 1: DEBUG>median (6)
2016.01.29 08:04:13 5: HMLAN_Send: HMLAN1 I:K
lg
knxhm
Hallo knxhm,
das notify triggert ein 2. Mal, wenn der Dummy beschrieben wird:
Zitat2016.01.29 08:04:01 5: Notify loop for duAussentemp temp: 6
2016.01.29 08:04:01 5: Triggering noAussentemp
Könnte mir vorstellen, dass das notify reagiert, weil der Dummy den gleichen Teilstring enthält wie die Datenquelle, also "Aussentemp". Ändere mal den Namen vom Dummy auf "duAussenTemp", dann wird das vermutlich nicht mehr passieren.
Dass die Werte in diesem Fall mehr werden, ist nicht verwunderlich. Da ja kaum eine Sekunde vergangen ist, greift die eingestellte holdTime von 300 Sekunden nicht.
Grüße,
Jens
Hallo Knxhm,
hier mein Vorschlag für die Änderung an fhem.pl:
my (undef, $duration, $method, $function, $holdTime) = split(":", $v[0], 5);
my $ts;
if(defined($readings->{".ts"})) {
$ts= $readings->{".ts"};
} else {
require "TimeSeries.pm";
$ts= TimeSeries->new( { method => $method, autoreset => $duration, holdTime => $holdTime } );
$readings->{".ts"}= $ts;
# access from command line:
# { $defs{"myClient"}{READINGS}{"myValue"}{".ts"}{max} }
#Debug "TimeSeries created.";
}
Mit diesem Ansatz kann man alle Features von TimeSeries nutzen. Du müsstest dann aber den event-aggregator auf "temp::none:median:300" ändern.
Bitte probier das mal aus - es sollte sich dadurch nichts an deiner Auswertung ändern.
Grüße,
Jens
Hallo Knxhm,
habe mir das Zusammenspiel von TimeSeries und fhem.pl noch einmal angesehen. Derzeit würde es trotzdem zu einem Downsampling kommen, wenn man die holdTime setzt. Das ist aber nicht immer gewünscht, gerade wenn man eine gleitende Berechnung durchführen will. Anbei eine neue Version von TimeSeries mit entsprechend geänderter elapsed-Methode. Dadurch kann man das Downsampling und die Haltezeit getrennt vorgeben.
Beispiele:
- event-aggregator "temp::none:median:300" -> kein Downsampling, aber 300 Sekunden Haltezeit
- event-aggregator "temp:0:none:median:300" -> auch kein Downsampling, aber 300 Sekunden Haltezeit
- event-aggregator "temp:30:none:median:300" -> Downsampling mit Update alle 30 Sekunden und 300 Sekunden Haltezeit
Grüße,
Jens
Hallo Jens,
die letzte Vers. läuft ab jetzt im Test.
lg
knxhm
Hallo Jens,
ich hab wieder Ausreisser.
Mit den Änderungen von:
am: 29 Januar 2016, 23:38:53 »
am: 29 Januar 2016, 22:03:25 »
Die letzte Änderung war wohl nicht so gut.
Konfiguriert habe ich so:
event-aggregator temp::none:median:600
lg
knxhm
Hallo knxhm,
die beiden Aenderungen haben vor allem damit zu tun, wie die Konfigurationsparameter uebergeben werden - an der eigentlichen Mathematik fuer die Median-Berechnung aendern sie nichts. Die in TimeSeries integrierte Selbttest-Funktion zeigt, dass die Beispielberechnungen einwandfrei ausgefuehrt werden. Um das gleiche Verhalten wie vor den Updates zu erhalten, kannst du 'temp:600:none:median:600' ausprobieren, denn da wurde nur alle 600 Sekunden ein neuer Messwert generiert. Dann hast du aber keinen gleitenden Median sondern einen geblockten
Hast du z.B. zu bestimmten Zeiten mehrere Fehlmessungen dicht beieinander, schlagen die auf den Median durch. Verwendest man eine Blockberechnung, beeinflusst man die Wahrscheinlichkeit, dass man einen von solchen Ausreissern beeinflussten Median erhaelt - aber eine Garantie gegen Ausreisser ist das trotzdem nicht. Vielleicht sind bei deiner relativ geringen Datenrate auch die 600 Sekunden noch zu wenig, denn du muss sicher stellen, dass in jedem Zeitraum die Anzahl der Gutwerte ueberwiegt.
Es waere hilfreich, wenn du sowohl die Rohmesswerte als auch die berechneten Mediane in einem Log aufzeichnest. Noch besser ist ein Log, wie du es schon mal gemacht hat, wo die gepufferten Messwerte aus TimeSeries ausgegeben werden.
Gruesse,
Jens
Hallo Jens,
ja das hatte ich mir eh schon vorgenommen fürs We. Ich hatte aber im den alten logs nie mehr als einzelne falsche Werte ,da sollte der median immer gut gehen. Aber ich werde sehen. Vielleicht müssen wir nur noch etwas herumdoktern .
LG
Knxhm
Hallo Jens,
das war wohl ein Eigentor, das kommt von zuviel c&p, reading Name in der config war falsch, dann gibts kein match und auch keinen event-aggregator :-(
Lass ma's jetzt berichtigt weiterlaufen.
lg
knxhm
Hallo knxhm,
freue mich, wenn es sich so lösen lässt.
Für die erweiterte Funktionalität des event-aggregators fehlt nun noch die Anpassung der Hilfetexte. Es wird nicht ganz einfach, die vielen möglichen Konfigurationsvarianten so zu beschreiben, dass man sie ohne zusätzlichen Blick in den Perl-Code versteht. Werde erst mal einen Entwurf machen.
Grüße,
Jens
Hallo Boris,
die Median-Berechnung scheint wie gewünscht zu funktionieren. Anbei die Patches für TimeSeries, fhem und commandref für die Unterstützung der Median-Berechnung per Event-Aggregator. Wenn gewünscht, kann ich das Einchecken übernehmen, aber ich hätte vorher gerne ein OK, da auch eine Änderung von fhem.pl erforderlich ist.
Grüße,
Jens
Hallo Jens,
vielen Dank für Deine Arbeit!
Die überarbeitete Version ist abwärtskompatibel? Das heißt, dass wir keine Störungen bei laufenden Konfigurationen haben werden?
Ich bin nur autorisiert, TimeSeries.pm einzuchecken. Für die drei anderen Dateien musst Du bitte Rudi fragen. Wenn er die Patches heute bis 19 Uhr anwendet und das Ergebnis eincheckt, werde ich auch TimeSeries.pm einchecken. Sonst muss es bis zum nächsten Wochenende warten.
Viele Grüße
Boris
@Boris
TimeSeries ist abwärtskompatibel und kann sowohl vor oder nach fhem.pl eingecheckt werden. Alle bisher für den Event-Aggregator genutzten Berechnungen sind unverändert, es kommen "nur" die neuen Möglichkeiten mit der holdTime hinzu, die ja zum Teil schon länger in TimeSeries vorhanden sind, aber bisher nicht über den Event-Aggregator aktiviert werden konnten. Die in TimeSeries zurück genommenen Änderungen in elapsed() und _housekeeping() (siehe Änderungskommentar im Modul) betreffen nur Abläufe für die Kombination "holdTime > 0" + Aufruf von elapsed(), die bisher nur über eigene Module mit TimeSeries aber nicht über fhem.pl nutzbar waren. Faktisch ist diese Rücknahme ein Bugfix.
@Rudi
Bitte prüfe meinen Änderungsvorschlag für den neuen 5. Parameter "holdTime" für TimeSeries in fhem.pl. Der split sollte keine Probleme bei bestehenden Konfigurationen machen, die nur 4 Parameter haben, der 5. Wert ist dann undef. Die holdTime ist jetzt schon in TimeSeries definiert und wird per Namen an den Konstruktor von TimeSeries übergeben. TimeSeries hat kein Problem damit, wenn holdTime undef ist - das ist aus Gründen der Abwärtskompatiblität schon jetzt der Defaultwert. Die Änderungen an der commandref sollten erfolgen, wenn beide Module eingespielt sind.
Grüße,
Jens
OK. Es kann sein, dass Rudi dieses Thema nicht mitliest. Am besten weist Du ihn per PM darauf hin.
Hallo Boris,
ich kann Rudi über das Forum keine PM senden. Kannst du das bitte anstoßen?
Grüße,
Jens
Habs eingecheckt.
Ich auch (und CHANGED und MAINTAINER.txt aktualisiert).
Hallo Rudi, hallo Boris,
danke für eure Unterstützung.
Grüße,
Jens
Zitat von: jensb am 26 Juli 2015, 19:18:55
Es gibt folgende neue Funktionen:
- ...
- neue statische Methode "selftest" stellt einen einfachen Unit-Test zur Verfügung, der mit {TimeSeries::selftest} ausgeführt werden kann, ohne dass ein Testmodul erforderlich ist
Hallo Jens, diese Posts sind Jahrzehnte her und ich weiß gar nicht, ob das noch gelesen wird. Ich habe an anderer Stelle Fragen zu TimeSeries (hier zB https://forum.fhem.de/index.php/topic,129920.msg1241805.html#msg1241805 (https://forum.fhem.de/index.php/topic,129920.msg1241805.html#msg1241805)) und in diesem Zusammenhang den Selbsttest mal aufgerufen. Im Forum fand ich die Zeichenkette TimeSeries:selftest nicht, bin ich der Erste? Jedenfalls gab es Probleme:
2022.10.28 08:53:24 1: DEBUG>unweighed block add test failed: sd mismatch 0.2/0.254950975679639
2022.10.28 08:53:24 1: DEBUG>unweighed block autoreset test failed: sd mismatch 0.282842712474619/0.4
2022.10.28 08:53:24 1: DEBUG>const weighed block add test failed: sd mismatch 1.41421356237309/2
2022.10.28 08:53:24 1: DEBUG>unweighed moving add test failed: sd mismatch 0.2/0.254950975679639
2022.10.28 08:53:27 1: DEBUG>unweighed moving holdTime test failed: sd mismatch 0.2/0.254950975679639
2022.10.28 08:53:27 1: DEBUG>const weighed moving add test 1 failed: sd mismatch 1.41421356237309/2
2022.10.28 08:53:27 1: DEBUG>const weighed moving add test 2 failed: sd mismatch 1.88745860881769/2.44470090195099Vermutlich hat das aber damit zu tun: https://forum.fhem.de/index.php/topic,114954.msg1091796.html#msg1091796 (https://forum.fhem.de/index.php/topic,114954.msg1091796.html#msg1091796)? Stellt sich die Frage, ob man das unbedingt ändern muss...
Hallo andies,
Danke für den Hinweis. Auch wenn es diesbezüglich schon lange keine Nachfragen mehr gab, werde ich mir das bei nächster Gelegenheit mal ansehen.
Grüße,
Jens
Hallo andies,
habe mir den Selbsttest von TimeSeries mal genauer angesehen. Da TimeSeries diverse Betriebsarten kennt, habe ich dazu das beigefügte XLS-Dokument erstellt, um neutral nachzurechnen. Glücklicherweise hat sich herausgestellt, dass FHEM richtig rechnet und nur der Selbsttest für die Standardabweichung falsch ist. Meine Vermutung geht dahin, dass der Selbsttest zunächst auf eine falsche berechnete Standardabweichung eingestellt wurde und dann zwar der Berechnungsfehler behoben wurde, aber der Selbsttest nicht mit angepasst wurde.
Die neue Version von TimeSeries mit angepasstem Selbsttest ist eingecheckt und sollte ab morgen zur Verfügung stehen.
Grüße,
Jens