[gelöst]event-aggregator und Log, zu viele Log Zeilen

[stefanru]

Hi,

ich habe einen Abstandssensor an einem ESP für die Regenwasser Messung.
Der Sensor liefert mir den Abstand alle 2 Sekunden.
Der Abstand schwankt leicht und ich wollte für Log und den Plot den ich erstelle:
1. Den Abstand auf gleiche werte (Mittelwert nach 30 Messungen)
2. Das Logfile nicht alle 2 sekunden sondern nur jede Minute befüllen.

Dafür habe ich event-aggregator benutzt. Leider wird das Log nach wie vor alle 2 Sekunden befüllt.
Das Device hat ein Reading Abstand das alle 2 Sekunden befüllt wird.
Daraus mache ich in einem User Reading Liter:
Liter {sprintf("%.0f",10000 - 50 * (ReadingsVal("ESPEasy_esp_easy_stefan2_Abstands_Sensor","Abstand",0)-3))}

Auf dieses habe ich den event-aggregator gelegt:
event-aggregator
LiterLog::none:median:300

Das scheint auch zu gehen nur die Updates des Readings geschehen nach wie vor alle 2 Sekunden.

Was mache ich falsch?

Gruß,
Stefan

[Amenophis86]

Hilft dir vll event-min-intervall?

[stefanru]

Hi,

danke für die Antwort!
Ja das hilft.

Mich wundert das Verhalten von event-aggregator. Nach der Beschreibung hätte ich gedacht es würde genau das machen:
"The primary uses of this attribute are to calculate (time-weighted) averages of readings over time periods and to throttle the update rate of readings and thus the amount of data written to the logs."

Genau gesagt es gäbe nur alle black-out period ein update im reading:
"If set, updates for the listed readings are ignored and associated events are suppressed for a black-out period of at least interval seconds (downsampling). After the black-out period has expired, the reading is updated with a value that is calculated from the values and timestamps of the previously ignored updates within the black-out period..."

Habe ich da was falsch verstanden?

Gruß,
Stefan

[KernSani]

Wenn ich fas richtig verstehe hast du den event-aggregator auf dem userreading, bleibt aber immernoch das eigentliche reading, das bei jedem update ein event erzeugt...

[stefanru]

Ja das verstehst du richtig.
Das Logfile logged aber nur das user reading.
Ich hätte erwartet dass dieses nur alle 300 sekunden aktualisiert wird.
Wird aber leider im gleichen takt wie das "normale" Reading aktualisiert.

Irgendwie verstehe ich das wohl falsch mit dem event-aggregator....

Gruß,
Stefan

[mumpitzstuff]

If the holdTime in seconds is defined, the samples will be kept in memory allowing the calculation of floating statistics instead of blocked statistics. With holdTime defined the interval can be kept undefined so that the readings update rate is unchanged or it can be set to a value less then holdTime for downsampling as described above with a full history of the readings in memory. Note that the historic samples are not persistent and will be lost when restarting FHEM.

Du musst ein Intervall definieren und nicht nur eine hold time.

LiterLog:300:none:median:300

[stefanru]

Ja das habe ich auch gemacht.
Zur Zeit sieht es so aus.
LiterLog.*:120:none:min:120

Leider wird das reading trotzdem mit dem Abstands-reading aktualisiert.
Der min Wert funktioniert aber scheinbar wie er soll.

Noch eine Idee?

Gruß,
Stefan

[mumpitzstuff]

LiterLog.*:120:none:min

Versuch mal das.

[stefanru]

Ok habs versucht.
Ich glaube da liegt echt ein Missverständnis vor, oder ich bin zu blöd dafür.
Also wenn ich es so eingebe schreibt er die ersten 120 sekunden nicht.
Danach wieder bei jeder aktualisierung.

Denke dass heißt er sammelt Daten von 120 sekunden und dann nimmt er immer den min Wert vom aktuellen reading inkl der 120 sekunden davor.
Dann aber wieder bei jeder aktualisierung.

Ich hätte gern den min Wert von jeweils 120 sekunden so dass er auch nur alle 120 sekunden schreibt.

Gruß,
Stefan

[mumpitzstuff]

Ich hätte auch gedacht das es so funktionieren müsste wie du es beschrieben hast. Vermutlich ein Bug im Modul.

[KernSani]

Ich denke, mit der holdTime passiert genau das was zu erwarten ist:

If the holdTime in seconds is defined, the samples will be kept in memory allowing the calculation of floating statistics

Was mich irritiert ist, dass es ohne holdTime nicht funktioniert.

[stefanru]

Ich hab alle Einstellungen und Kombinationen von Intervall und HoldTime ausprobiert. Es tut bei mir nicht.
Bekomme es nur mit zusätzlichem event-min-intervall hin. Sollte aber nicht nötig sein.
Neustes Updates sind drin.

Wäre nett wenn es vieleicht noch jemand bei sich mal ausprobieren könnte um sicher zu gehen dass es auch ein Bug ist.


Gruß,
Stefan

[KernSani]

folgender Testaufbau. Ein Dummy:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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 von dir beschreiben und aktualisiert sich, nachdem 30 Sekunden gesammelt wurde alle 5 Sekunden:

Code Auswählen Erweitern


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.

Im Grunde macht das Attribut, was es soll: Es aggregiert die Events... Dass die Readings zwischendrin aktualisiert werden führt aber nicht nur zu (falschen) Log-Einträgen sondern kann - z.B. wenn man mit ReadingsVal ausliest m.E. auch zu falschen Ergebnissen führen. Ich werde das mal an Rudi melden...


Edit: hier fortgesetzt: https://forum.fhem.de/index.php/topic,72893.0.html

[stefanru]

Hi KernSani,

ich danke dir vielmals.
Muss dich aber doch kurz was fragen.
Heißt das wenn ich nun das event-aggregator attribut lösche und wieder anlege und diesmal nicht mit hold time wird ein event nur alle 30 sekunden erzeugt?
Also auch ein log an diesem userReading schreibt nur alle 30 sekunden?

Danke und Gruß,
Stefan

[KernSani]

ich hatte auch das userreading gelöscht, erst dann hat er irgendwie die Änderungen am event-aggregator "gefressen". Musst du asuprobieren, ob das bei dir hilft...