Berechnung zeitl. gewichteter Mittelwert mit event-aggregator fehlerhaft?!

[timtom2000]

Hallo,

ich habe ein merkwürdiges, aus meiner Sicht falsches, Verhalten von event-aggregator festgestellt, konkret bei der zeitlich gewichteten Mittelwertbildung (mean mit const oder linear).

Folgendes Testdevice habe ich angelegt:

Code Auswählen Erweitern

defmod testdummy dummy
attr testdummy userReadings testreading
attr testdummy event-aggregator testreading::const:mean:86400
Danach Stimulation über mehrere aufeinanderfolgende setreadings. Nach jedem setreading wurde der akt. Wert des Readings ausgelesen; hierbei hätte ich ab dem zweiten Stimulus den zeitl. gew. Mittelwert erwartet.

Code Auswählen Erweitern

setreading testdummy testreading 1 (bzw. 2,3,etc. s. unten)
{ReadingsNum("testdummy","testreading",99)}
Ergebnis war wie folgt (In=Wert von setreading / Out=Ausgabe von ReadingsNum)

In Out 1   1 2   2 3   99 4   2 5   2,504877803 6   3,026676048

Erst ab der "5/6-Stimulation" erscheint mir der Wert plausibel (der krumme Wert kommt wg. der zeitl. Gewichtung). Insbes. aber die 99 ist doch völlig fehl am Platz! Offensichtlich ist das Reading zu diesem Zeitpunkt auf "ndef", weswegen der Default-Wert aus dem ReadingsNum verwendet wird.
Das Verhalten ist bei const und linear ähnlich (falsch). Bei none funktioniert es wie erwartet, insofern scheint es irgendwie an der zeitl. Gewichtung zu hängen...

Hat jemand eine Erklärung? Muss zusätzl. eine Art Initialisierung erfolgen? Gibt es irgendein "hidden feature" was ich nicht kenne/berücksichtige...?

[betateilchen]

Den Sinn des userReadings habe ich noch nicht verstanden.

Aber unabhängig davon, ist es auch bei mir so, dass ich nach dem dritten setreading im device gar kein reading mehr sehe. Ab dem nächsten setreading ist dann wieder ein reading vorhanden.

[Dr. Boris Neubert]

https://forum.fhem.de/index.php?topic=110375

[betateilchen]

@Boris: das ist hier nicht das Problem, bei meinem Test war das userReading nicht angelegt, weil das überhaupt keinen Sinn macht, wenn man mit setreading arbeitet.

[timtom2000]

Den Sinn des userReadings habe ich noch nicht verstanden.

Das userReading kann man auch weglassen, stimmt. Ändert aber nichts am Verhalten, dass beim 3. setreading kein Mittelwert rauskommt...

https://forum.fhem.de/index.php?topic=110375

Mit dem verlinkten Beitrag sehe ich keine Parallelen...

[Dr. Boris Neubert]

https://forum.fhem.de/index.php?topic=110375

Mit dem verlinkten Beitrag sehe ich keine Parallelen...

Ich lese daraus, dass setreading nicht für userReadings geht. Was sagt das Log?

[Dr. Boris Neubert]

@Boris: das ist hier nicht das Problem, bei meinem Test war das userReading nicht angelegt, weil das überhaupt keinen Sinn macht, wenn man mit setreading arbeitet.

Kann der OP das ganze bitte mit ReadingsSingleUpdate() testen?

(Als ich das Zeug vor x Jahren beigetragen hatte, war es durchgetestet - seitdem gab es aber auch zahlreiche Änderungen/Erweiterungen im event-aggregator.)

[betateilchen]

@Boris: nochmal, es geht nicht um das Thema userReading

Du kannst das Verhalten recht einfach selbst reproduzieren:

Code Auswählen Erweitern

defmod testdummy dummy
attr testdummy event-aggregator testreading::const:mean:86400

danach (zwischen den einzelnen Befehlen habe ich immer ein paar Sekunden Zeit gelassen)

Code Auswählen Erweitern

setreading testdummy testreading 1

setreading testdummy testreading 2

setreading testdummy testreading 3

Die ersten beiden setreading Befehle funktionieren, nach dem dritten hat das device überhaupt kein reading mehr.

Das Verhalten tritt (bei einem neu angelegten device) in gleicher Form auch mit readingsSingleUpdate() auf.

Code Auswählen Erweitern

{readingsSingleUpdate($defs{testdummy},"testreading",1,1)}
{readingsSingleUpdate($defs{testdummy},"testreading",2,1)}
{readingsSingleUpdate($defs{testdummy},"testreading",3,1)}

Die ersten beiden funktionieren und setzen testreading auf 1 bzw. 2.
Beim dritten Aufruf wird kein reading angelegt.

[timtom2000]

Danke für eure Unterstützung!
Was evtl. hilft...im Logfile steht folgende Warning, die ich bisher nicht zuordnen konnte, die zeitlich aber zum Aufruf passt.

Code Auswählen Erweitern

PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 272.Beim näheren Hinsehen habe ich gerade festgestellt, dass in TimeSeries.pm offensichtlich die Methoden für event-aggregator ablaufen.

[Dr. Boris Neubert]

Debugging am Morgen, Kummer und Sorgen...

Das Problem entsteht in readingsBulkUpdate, wenn das Reading noch nicht existiert, was bei Dummys der Fall ist, bevor das Reading mit setreading gesetzt wird. Das TimeSeries-Objekt wird erzeugt, aber nicht aufgehoben. Beim nächsten setreading wird das TimeSeries-Objekt erneut erzeugt. Nach dreimal setreading enthält das TimeSeries-Objekt zwei Werte und die statistischen Größen sind alle berechnet. Das Reading enthält aber erst den Mittelwert nach dem zweiten setreading, und der ist leer, weil ja erst ein Wert im TimeSeries-Objekt stand.

Das Problem ist eine Spezialität von dem Dummy. Bei Devices, wo die Readings bereits bei Definition feststehen, taucht es nicht auf.

Ich gebe das mal ins Developer-Board.

[timtom2000]

Ohne, zugegebenermaßen, die ganzen Zusammenhänge verstanden zu haben...besteht eine Möglichkeit das Problem zu umgehen, indem man das Reading vorab erzeugt bzw. initialisiert?
Ein schneller Test mit setreading VOR der Definition des "attr testdummy event-aggregator ..." brachte keinen Erfolg.

[Dr. Boris Neubert]

Nee, wir lösen das ganze "richtig" in fhem.pl.