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

Begonnen von timtom2000, 03 April 2024, 17:41:58

Vorheriges Thema - Nächstes Thema

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:
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.
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...?
LWZ 304 (BJ 2017; FW 7.09); DHH o. Keller; 100m² Wohnfläche
FHEM auf USB-Stick an FritzBox 7560 (FW 7.12)

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

timtom2000

Zitat von: betateilchen am 03 April 2024, 18:37:29Den 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...

Zitat von: Dr. Boris Neubert am 03 April 2024, 18:52:30https://forum.fhem.de/index.php?topic=110375
Mit dem verlinkten Beitrag sehe ich keine Parallelen...

LWZ 304 (BJ 2017; FW 7.09); DHH o. Keller; 100m² Wohnfläche
FHEM auf USB-Stick an FritzBox 7560 (FW 7.12)

Dr. Boris Neubert

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

Zitat von: betateilchen am 03 April 2024, 19:38:30@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.)
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

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

Du kannst das Verhalten recht einfach selbst reproduzieren:

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

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

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.

{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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
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.
LWZ 304 (BJ 2017; FW 7.09); DHH o. Keller; 100m² Wohnfläche
FHEM auf USB-Stick an FritzBox 7560 (FW 7.12)

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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.
LWZ 304 (BJ 2017; FW 7.09); DHH o. Keller; 100m² Wohnfläche
FHEM auf USB-Stick an FritzBox 7560 (FW 7.12)

Dr. Boris Neubert

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!