Gelöst - User Reading mehrfach in Logs angezeigt

tfriedrich85 · 28 Mai 2020, 11:42:33

Hallo zusammen,
ich habe einen Lichtsensor in der Küche der seine Werte alle 5 Minute an Fhem sendet. Da hin und wieder komische Werte dabei sind möchte ich den Median der letzten 15 Minuten (der letzten 3 Werte) verwenden um das Licht in der Wohnung zu steuern.
Das klappt auch soweit ganz gut. Allerdings wird der Mittelwert sehr oft im Log erfasst und ich weiß nicht wesshalb das passiert:

Hier das Logfile:

Definition: /opt/fhem/log/ESP_Easy_Kueche_Licht-%Y-%m.log ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht:Lux:.*|ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht:Mittelwert:.*|ESPEasy_ESPEasy_WZ_Licht_WZ_Licht:Lux:.*

Logfile:

Code Auswählen


2020-05-28_11:30:02 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 368
2020-05-28_11:30:02 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 343
2020-05-28_11:25:37 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 343
2020-05-28_11:25:37 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 343
2020-05-28_11:25:37 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Lux: 368
2020-05-28_11:25:05 ESPEasy_ESPEasy_WZ_Licht_WZ_Licht Lux: 546
2020-05-28_11:25:01 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 343
2020-05-28_11:25:01 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 249
2020-05-28_11:20:37 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 249
2020-05-28_11:20:37 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Mittelwert: 249
2020-05-28_11:20:37 ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht Lux: 343
2020-05-28_11:20:05 ESPEasy_ESPEasy_WZ_Licht_WZ_Licht Lux: 530

Hier das List von dem Sensor:

Internals:
CFGFN
DEF 192.168.178.66 80 ESPBridge ESP_Easy_Kueche_Licht_Kueche_Licht
ESPBridge_MSGCNT 61
ESPBridge_TIME 2020-05-28 11:35:37
ESP_BUILD 20103
ESP_BUILD_GIT mega-20190630
ESP_BUILD_NOTES - Mega
ESP_NODE_TYPE_ID ESP Easy Mega
ESP_SLEEP 0
ESP_UNIT 0
ESP_VERSION 2
FUUID 5ecf7799-f33f-aed9-0fd9-53d64bc5126500aa
HOST 192.168.178.66
IDENT ESP_Easy_Kueche_Licht_Kueche_Licht
INTERVAL 300
IODev ESPBridge
LASTInputDev ESPBridge
MAX_CMD_DURATION 1
MSGCNT 61
NAME ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht
NOTIFYDEV global
NR 58505
NTFY_ORDER 50-ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht
PORT 80
STATE Bro: 161 Inf: 78 Lux: 586
SUBTYPE device
TYPE ESPEasy
VERSION 2.18
OLDREADINGS:
READINGS:
2020-05-28 11:35:37 Broadband 161
2020-05-28 11:35:37 Infrared 78
2020-05-28 11:35:37 Lux 586
2020-05-28 11:40:08 Mittelwert 586
2020-05-28 11:40:08 presence present
2020-05-28 11:40:08 state Bro: 161 Inf: 78 Lux: 586
helper:
fpc 1590654873
pm:
Encode 1
JSON 1
received:
Broadband 1590658537
Infrared 1590658537
Lux 1590658537
sec:
admpwd
Attributes:
IODev ESPBridge
Interval 300
alias Küche_Licht
event-aggregator Mittelwert::none:median:900
group ESPEasy Device
presenceCheck 1
readingSwitchText 1
room System
setState 3
userReadings Mittelwert {ReadingsVal("ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht","Lux",0)}

Wisst ihr woarn das liegt?

Beta-User · 28 Mai 2020, 12:20:03

...wie wäre es mit einem sauberen "trigger" für das userReadings-Ding...?

Code Auswählen

userReadings Mittelwert:Lux.* {ReadingsVal("ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht","Lux",0)}
(Es gibt auch Möglichkeiten, wirklich einen Mittelwert zu bilden, aber das reflektiert dein Code derzeit nicht...?).

MadMax-FHEM · 28 Mai 2020, 12:24:29

Trigger ist bei userReadings immer der "saubere" Weg...
...wenn dich "nur" die mehrfach GLEICHEN Einträge "stören" (und das hilft dann "generell" bei Readings): event-on-change-reading

Gruß, Joachim

tfriedrich85 · 28 Mai 2020, 13:47:34

Hallo Joachim,

danke für den Tipp, habe ich sofort mit:

Code Auswählen

event-on-change-reading .*

bzw.

Code Auswählen

event-on-change-reading Mittelwert

umgesetzt. Der Fehler tritt immer noch auf.

MadMax-FHEM · 28 Mai 2020, 15:07:42

Tja dann kann es nat. sein, dass das Modul (manche machen das) die Readings löscht und dann aktualisiert.
Dann ist das für den "event-on-change-reading"-Mechanismus ja eine Änderung, ergo wirkt das nicht...

Aber nur eine Vermutung, nutze espEasy nicht...

Würde aber behaupten, wenn das Modul das so macht, dass es so nicht gehört...
...bzw. ich es so nicht haben wollte...

EDIT: ansonsten ja noch die Möglichkeit von Beta-User. D.h. dein userReadings wird bei JEDER Änderung IRGENDEINES Readings "getriggert" und "berechet" -> Event. Wenn du es mittels Triggerangabe (Beispiel von Beta-User) umsetzt (oder einen anderen/passenderen Trigger kennst, dann den nehmen), dann wird das userReadings NUR "getriggert" und "berechnet", wenn genau der triggernde Event kommt...

Gruß, Joachim

Beta-User · 28 Mai 2020, 15:11:16

Ist denn jetzt der Trigger eingeschränkt?

tfriedrich85 · 28 Mai 2020, 15:17:19

Hallo,

der Mittelwert wird doch immer dann neu berechnet wenn ein neuer Wert vom Sensor kommt, deshalb ging ich davon aus, dass das event-on-change reading als trigger dient? Ist das falsch?
Wie kann ich den den Trigger noch einstellen?

Beta-User · 28 Mai 2020, 15:30:50

no comment

. Warum testest du nicht einfach, ob der vorgeschlagene Code das macht, was du willst, liest dann die Doku, warum das ggf. was ändert und stellst dann weitere Fragen?

Außerdem berechnet das userReading "Mittelwert" derzeit nichts, sondern kopiert einfach einen Wert (scheinbar mehrfach!) in das Reading.

MadMax-FHEM · 28 Mai 2020, 15:40:36

Zitat von: tfriedrich85 am 28 Mai 2020, 15:17:19
Hallo,

der Mittelwert wird doch immer dann neu berechnet wenn ein neuer Wert vom Sensor kommt, deshalb ging ich davon aus, dass das event-on-change reading als trigger dient? Ist das falsch?
Wie kann ich den den Trigger noch einstellen?

So wie ich geschrieben habe: IMMER EGAL WELCHER EVENT/WERT kommt! Daher ja: mehrfach!

Was event-on-change-reading macht (steht in der Doku

): wenn ein Reading (das aufgeführt ist / .* -> alle) einen neuen Wert erhält (weil z.B. das physische Gerät halt was schickt), dann wird NUR ein Event erzeugt, wenn sich der Wert geändert hat.

Aber auch NUR, wenn das Device es "richtig" macht

Wenn das Device/Modul/programmierter Code/you name it

aber beispielsweise das Reading löscht und danach eben den neuen Wert (der aber der selbe ist) schreibt, dann ist das ja trotzdem für event-on-change-reading ein neuer Wert: alter Wert -> kein Wert -> neuer/alter Wert...

Und der Trigger bei DEINEM userReadings FEHLT KOMPLETT.
Daher wird es (wie schon 1000mal geschrieben / und jetzt dann nicht mehr

) bei JEDEM EVENT der kommt "berechnet"...

Wobei nat. Beta-User recht hat: es wird nur der Lux-Wert kopiert...

Hast du dir das Statistics-Modul mal angesehen!?
Vielleicht macht das ja was du willst...

Gruß, Joachim

tfriedrich85 · 28 Mai 2020, 15:42:35

Zitat von: Beta-User am 28 Mai 2020, 15:30:50
no comment . Warum testest du nicht einfach, ob der vorgeschlagene Code das macht, was du willst, liest dann die Doku, warum das ggf. was ändert und stellst dann weitere Fragen?

Außerdem berechnet das userReading "Mittelwert" derzeit nichts, sondern kopiert einfach einen Wert (scheinbar mehrfach!) in das Reading.

Sorry, deinen Vorschlag hat sich beim ersten hinsehen gar nicht von meinem Original unterschieden....
Ich probier deinen Vorschlag mal aus! Sorry nochmal

Beta-User · 28 Mai 2020, 15:52:33

und dann bitte hier weiter: https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen

(ist nur ein nicht näher geprüfter Link, den ich mir für solche Gelegenheiten gemerkt habe, muß also nicht funktionieren/passen).

tfriedrich85 · 28 Mai 2020, 16:36:07

Zitat von: Beta-User am 28 Mai 2020, 12:20:03
...wie wäre es mit einem sauberen "trigger" für das userReadings-Ding...?
Code Auswählen Erweitern
userReadings Mittelwert:Lux.* {ReadingsVal("ESPEasy_ESP_Easy_Kueche_Licht_Kueche_Licht","Lux",0)}
(Es gibt auch Möglichkeiten, wirklich einen Mittelwert zu bilden, aber das reflektiert dein Code derzeit nicht...?).

Das funktioniert super! Damit habe ich ein neues Reading und mit dem

Code Auswählen

event-aggregator Mittelwert::none:median:900
erzeuge ich einen "Mittelwert".

Beta-User · 28 Mai 2020, 17:34:27

...und warum machst du das dann nicht gleich mit dem Ausgangsreading "Lux"?

Wegen (commandref)?

ZitatWhen more than one function should be calculated for the same reading, the original reading must be multiplied (e.g. by using a notify) before applying the event-aggregator to the derived readings.

(Das mit dem event-aggregator Mittelwert::none:median:900 muß ich mir auch mal näher ansehen, damit habe ich bisher auch nicht gearbeitet, scheint interessant zu sein

...).

tfriedrich85 · 29 Mai 2020, 10:16:18

Zitat von: Beta-User am 28 Mai 2020, 17:34:27
...und warum machst du das dann nicht gleich mit dem Ausgangsreading "Lux"?

Wegen (commandref)?(Das mit dem event-aggregator Mittelwert::none:median:900 muß ich mir auch mal näher ansehen, damit habe ich bisher auch nicht gearbeitet, scheint interessant zu sein ...).

Hallo,

ich möchte den Original Lux - Wert behalten, deshalb das neue Reading.