Event-Aggregator aktualisiert readings während des Intervals

Begonnen von KernSani, 07 Juni 2017, 00:00:30

Vorheriges Thema - Nächstes Thema

KernSani

Hi Rudi,

Aufgrund dieses Posts habe ich das Verhalten von event-aggregator analysiert und m.E. ist das nicht ganz korrekt.

Im Grunde macht das Attribut, was es soll: Es aggregiert die Events... Allerdings werden zwischendrin auch Readings aktualisiert was - z.B. wenn man mit ReadingsVal ausliest m.E. zu falschen Ergebnissen führt.

folgender Testaufbau. Ein Dummy:
Internals:
   CFGFN
   NAME       eaDummy
   NR         21580
   STATE      48
   TYPE       dummy
   Readings:
     2017-06-06 23:22:20   myAggregator    42
     2017-06-06 23:22:20   state           48
Attributes:
   event-aggregator myAggregator:30:none:min
   userReadings myAggregator {ReadingsVal($name,"state",0)}



ein at:
Internals:
   CFGFN
   COMMAND    {fhem("set eaDummy ".(ReadingsNum("eaDummy","state",0)+1))}
   DEF        +*00:00:05 {fhem("set eaDummy ".(ReadingsNum("eaDummy","state",0)+1))}
   NAME       eaAt
   NR         21659
   NTM        23:23:25
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 23:23:25
   TIMESPEC   00:00:05
   TRIGGERTIME 1496784205.81392
   TRIGGERTIME_FMT 2017-06-06 23:23:25
   TYPE       at
   Readings:
     2017-06-06 23:23:20   state           Next: 23:23:25
Attributes:



Das AT aktualisiert alle 5 Sekunden den Dummy, das userreading wird ebenfalls alle 5 Sekunden aktualisiert (und zwar mit dem aktuellen Wert von state), ein Event wird aber nur alle 30 Sekunden erzeugt (und dann jeweils mit dem was zu erwarten wäre, nämlich dem Minimum der vorangegangenen 30 Sekunden).

die relevanten Zeilen aus dem Event-Monitor:
2017-06-06 23:31:30 dummy eaDummy 158
2017-06-06 23:31:30 dummy eaDummy myAggregator: 153
2017-06-06 23:31:35 dummy eaDummy 159
2017-06-06 23:31:40 dummy eaDummy 160
2017-06-06 23:31:45 dummy eaDummy 161
2017-06-06 23:31:50 dummy eaDummy 162
2017-06-06 23:31:55 dummy eaDummy 163
2017-06-06 23:32:00 dummy eaDummy 164
2017-06-06 23:32:00 dummy eaDummy myAggregator: 158



Ein zweites (identisches)  Userreading mit event-aggregator diesmal mit holdTime verhält sich, wie erwartet und aktualisiert sich, nachdem 30 Sekunden gesammelt wurde alle 5 Sekunden:
2017-06-06 23:42:25 dummy eaDummy 57
2017-06-06 23:42:25 dummy eaDummy myAggregator2: 50
2017-06-06 23:42:30 dummy eaDummy 58
2017-06-06 23:42:30 dummy eaDummy myAggregator2: 51
2017-06-06 23:42:35 dummy eaDummy 59
2017-06-06 23:42:35 dummy eaDummy myAggregator2: 52
2017-06-06 23:42:40 dummy eaDummy 60
2017-06-06 23:42:40 dummy eaDummy myAggregator2: 53
2017-06-06 23:42:45 dummy eaDummy 61
2017-06-06 23:42:45 dummy eaDummy myAggregator: 56
2017-06-06 23:42:45 dummy eaDummy myAggregator2: 54



Eine Änderung des event-aggregator Attributes hatte übrigens bei mir keine Änderung des Verhaltens zur Folge, nur löschen und neu anlegen hat geholfen.

Zum einfacheren nachstellen noch die raw definition:
defmod eaDummy dummy
attr eaDummy event-aggregator myAggregator:30:none:min,myAggregator2:30:none:min:30
attr eaDummy userReadings myAggregator {ReadingsVal($name,"state",0)},myAggregator2 {ReadingsVal($name,"state",0)},myTest {ReadingsVal($name,"myAggregator",0)}

defmod eaAt at +*00:00:05 {fhem("set eaDummy ".(ReadingsNum("eaDummy","state",0)+1))}

(im myTest reading kann man schön sehen, wie myAggregator alle 5 Sekunden identisch zum state hochgezählt wird...und dann plötzlich auf das Minimum geht.

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

rudolfkoenig

event-aggregator ist von Boris, ich habe es uebernommen, aber nicht in der Tiefe durchgelesen, geschweige denn verstanden.
Falls Boris keine Zeit dafuer hat, dann muesste ich das wohl uebernehmen, aber ich schlage vor, wir warten noch eine Weile auf ihn :)

KernSani

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

chq

So einfach wie möglich, so kompliziert wie nötig