Ich habe - wie der Titel sagt - ein gewisses Verständnisproblem mit dem Attribut event-aggregator zusammen mit einem ESPEasy-Device. Konkret geht es um ein WeMos, das zusammen mit einem Ultraschall-Sensor den Füllstand einer Wassertonne ermittelt und diesen Wert einmal pro Minute an FHEM zur weiteren Verarbeitung sendet. Eigentlich benötige ich den Wert nicht wirklich jede Minute, daher setzt sich der WeMos per Rule (siehe unten) immer 5 Minuten nach der vollen Stunde für 54 Minuten in den Deep-Sleep-Modus. Das funktioniert soweit. So bekomme ich jede Stunde für etwa 5 Minuten im Minutenabstand Werte für den Füllstand der Wassertonne.
Eigentlich würde ja ein Wert genügen, aber leider gibt es da nicht selten deutliche Ausreißer. Daher mein Gedanke, das ganze auf diese Weise zu korrigieren: Ich nehme wie beschrieben die ca. 5 Werte und ermittle daraus den Median. So ist es ja auch in unterschiedlichen Threads und im Wiki zum Event-Aggregator beschrieben.
Vielleicht noch von Bedeutung: Aus dem Füllstand in cm wird als User-Reading ein Prozentwert der Höhe berechnet. Auch das funktioniert. Und zuletzt: Dieser FHEM-Teil läuft auf einem Slave-FHEM und die Ergebnisse werden dann an das Master-FHEM per RFHEM übertragen und geloggt. Auch das läuft.
Nun zum Problem. Eigentlich habe ich erwartet, dass die Definition des event-generator-Attributs der Form wie unten angegeben jeweils nur ein Wert - nämlich der Median aus den jeweils 5 intern irgendwo temporär von FHEM zwischengespeicherten Werten dieser Readings - innerhalb diesen 5-Minuten Intervalls sowohl für Hoehe als auch für Fuellstand in FHEM ausgegeben wird. Dem ist jedoch nicht so. Es werden weiterhin jeweils jede Minute ein Wert ausgegeben. Da leider die RTC der WeMos offensichtlich recht ungenau ist, sind dies auch mehr als 5 Werte, es sind hier im Beispiel meist 8 Werte im Minutenabstand.
Ich dachte, durch die Angabe des Eintrags 300 für das Intervall würden immer 5 Minuten lang keine Werte für das jeweilige Reading ausgegeben, dann erst der Median.
Raw-Definition in FHEM
defmod ESPEasy_WEMOS_2_Distanz_4 ESPEasy 192.168.178.82 80 ESP_bridge WEMOS_2_Distanz_4
attr ESPEasy_WEMOS_2_Distanz_4 IODev ESP_bridge
attr ESPEasy_WEMOS_2_Distanz_4 Interval 0
attr ESPEasy_WEMOS_2_Distanz_4 alias Wassertonne
attr ESPEasy_WEMOS_2_Distanz_4 event-aggregator Hoehe:300:none:median:300,Fuellstand:300:none:median:300
attr ESPEasy_WEMOS_2_Distanz_4 presenceCheck 1
attr ESPEasy_WEMOS_2_Distanz_4 readingSwitchText 1
attr ESPEasy_WEMOS_2_Distanz_4 setState 3
attr ESPEasy_WEMOS_2_Distanz_4 stateFormat {ReadingsVal("ESPEasy_WEMOS_2_Distanz_4","Hoehe","")}
attr ESPEasy_WEMOS_2_Distanz_4 userReadings Hoehe { int(ReadingsVal("ESPEasy_WEMOS_2_Distanz_4","Fuellstand",0)/73.4*100+0.5);;;; }
setstate ESPEasy_WEMOS_2_Distanz_4 4
setstate ESPEasy_WEMOS_2_Distanz_4 2019-03-30 23:04:52 Fuellstand 3.3
setstate ESPEasy_WEMOS_2_Distanz_4 2019-03-30 23:04:52 Hoehe 4
setstate ESPEasy_WEMOS_2_Distanz_4 2019-03-30 23:04:52 state Fue: 3.3
ESPEasy-Rule:
On System#Boot do
timerSet,8,60 //Set Timer 8 for the next event in 60 seconds
endOn
On Rules#Timer=8 do
notify 1, "WEMOS-2: System gestartet"
endOn
on Clock#Time=All,**:00 do
timerSet,6,300 //WeMos soll schlafen gehen
notify 1, "WEMOS-2: Ich gehe in 5 Minuten schlafen"
endOn
On Rules#Timer=6 do
deepsleep,3600 //54 Minuten schlafen gehen - Wert ist sehr ungenau
EndOn
also ich kapiere, glaube ich, deine frage nicht richtig. aber ich hatte mal ähnliche Schwierigkeiten mit dem aggregatoren und habe daher den Wiki-Artikel etwas umfangreicher gestaltet. Lies den mal. Mir fällt bei Dir auf, dass der Füllstand erstmal als Reading da sein muss, bevor er dann aggregiert wird (das soll er doch, oder?).
Der aggregator bezieht sich immer auf ein existierendes Reading, dass von einer anderen Quelle gespeist wird. Der aggregator beeinflusst gewissermaßen dann die Ausgabe/Anzeige des Readings.
Gesendet von iPad mit Tapatalk Pro
Besten Dank erst mal.
Naja, nachdem ich den Wiki-Eintrag gelesen hatte, dachte ich, auch die Commandref zu verstehen. Die englische Beschreibung wollte mir vorher nicht wirklich einleuchten.
Im Moment habe ich für das Reading Fuellstand praktisch keine Ausreißer und die Tonne ändert ihren Füllstand auch nicht. Daher denke ich, der event-aggregator funktioniert im Prinzip schon.
Das Reading Fuellstand wird bei mir vom WeMos per ESPEasy alle 60 Sekunden befüllt. Pro Stunde etwa 8 Werte, dann schläft der WeMos. Ich habe nun erwartet, der Wert 300 für Intervall (zweiter Wert je Reading) sorgt dafür, dass nur alle 300 Sekunden ein Wert ausgegeben wird für das jeweilige Reading. Also beispielsweise würde ich das Reading Fuellstand jeweils 5 Minuten lang nicht ändern und erst dann ein Wert, nämlich der Median der Werte innerhalb der 5 Minuten, für das Reading ausgegeben. SO habe ich die Beschreibung im Wiki interpretiert:
"interval
Updates des <readings> werden ignoriert, Events werden für mindestens <interval> Sekunden unterdrückt.
Nach der interval-periode wird das reading mit einem Wert upgedated, der sich aus den Werten und Zeitstempeln der vorher ignorierten Updates zusammensetzt."
attr ESPEasy_WEMOS_2_Distanz_4 event-aggregator Hoehe:300:none:median:300,Fuellstand:300:none:median:300
Kannst Du Deine damaligen Schwierigkeitenvielleicht kurz beschreiben, dass ich sehen kann, ob sie wirklich ähnlich waren?
Ich wollte das Maximum einer Temperatur über 24h haben. Ich hatte das Reading für diese Temperatur definiert und auch den event-aggregator eingestellt, aber es gab keinen "Mechanismus", der den ursprünglichen (also noch nicht maximalen) Temperaturwert in das reading geschrieben hätte. Ohne event-aggregator wäre das Reading gar nicht aktualisiert worden. Und dann habe ich mich gewundert, dass das Maximum nicht ausgerechnet wird.
Du musst Dir das so vorstellen: Man hat ein Reading. Das Reading wird mit Werten gefüttert. Der event-aggregator sorgt dann nur dafür, dass der angezeigte Wert im Reading gleich dem Median/Maximum/Minimum etc ist. Wenn keine Werte gefüttert werden, wird auch nichts maximiert/minimiert/gemittelt.
Wo kommt denn bei Dir der Füllstand rein? Das habe ich nicht gesehen. In dem list ist auch kein attr zu finden.
Das Reading kommt aus ESPEasy auf dem WeMos. Dort ist FHEM als Controller definiert und der Fuellstand in cm ist dort die einzige Device mit der Aktivierung eben dieses Controllers. Die Werte kommen ja auch in FHEM an, ich kann sie im Eventmonitor sehen und sie werden auch erfasst, wenn ich das Attribut event-aggregator nicht definiert habe. Einzig das User-Reading Hoehe, das die Hohe in % berechnet, wird erst in FHEM berechnet. Kann das stören? Dann sollte ich das mal testweise deaktivieren.
Zitat von: duke-f am 31 März 2019, 00:35:05
Ich dachte, durch die Angabe des Eintrags 300 für das Intervall würden immer 5 Minuten lang keine Werte für das jeweilige Reading ausgegeben, dann erst der Median.
Es wird
immer der Median der letzten 5 Minuten ausgegeben, in jedem Zeitpunkt.
Ok, genau das passiert ja bei mir. Dann ist das so gewollt. Nur verstehe ich dann nicht , wie die Erklärung zu intervall zu deuten ist (Updates des <readings> werden ignoriert, Events werden für mindestens <interval> Sekunden unterdrückt.) und wo da der Unterschied zu holdtime dann liegt.
Für meinen Fall bedeutet das dann, dass ich mir überlegen muss, wie ich selber nur den jeweils letzten Wert eines Intervalls vom Slave-FHEM zum Master übertrage. Danke nochmals.