Kann man event_Readings verzögern?

FunkOdyssey · 22 August 2020, 17:27:51

Ich habe das jetzt so gelöst. Das DOIF läuft nun zyklisch.
Ich dachte eigentlich, dass ich im Ausführungsteil die Readings noch setzen muss, um ein Event zu bekommen. Aber eine leere Klammer hat die Readings aus dem DOiF_readings als Event generiert.

Warum? Weiß ich nicht.

Mit dem setreading wurde doppelt ins Log geschrieben (ohne event-on-change natürlich).

Code Auswählen


defmod di_light DOIF ([+00:01])\
(\
##setreading $SELF lux [?$SELF:lux],\
## setreading $SELF lightlevel [?$SELF:lightlevel]\
)
attr di_light DOIF_Readings lux:round([sensor:lux:med10],0),\
lightlevel:round([sensor:lightlevel:med10],0)
attr di_light do always
attr di_light event-on-change-reading lux,lightlevel
attr di_light readingList lux,lightlevel
attr di_light setList lux\
lightlevel

Damian · 23 August 2020, 10:39:58

Zitat von: FunkOdyssey am 22 August 2020, 17:27:51
Ich habe das jetzt so gelöst. Das DOIF läuft nun zyklisch.
Ich dachte eigentlich, dass ich im Ausführungsteil die Readings noch setzen muss, um ein Event zu bekommen. Aber eine leere Klammer hat die Readings aus dem DOiF_readings als Event generiert.

Warum? Weiß ich nicht.

Mit dem setreading wurde doppelt ins Log geschrieben (ohne event-on-change natürlich).

Das Problem ist, dass FHEM eigenständig, obwohl lux ohne Event-Flag geschrieben wurde, es zu den vom DOIF später durch den Zeittrigger produzierten Events (state, cmd...) zuordnet und im Eventmonitor anzeigt.

Ich würde es im DOIF-Perlmodus realisieren, dann hast du auch nur die Events, die du haben willst:

z. B. für ein Reading reicht dieses:

Code Auswählen

defmod Reading_test DOIF {set_Reading("lux",[sensor:lux:med])}\
{[+00:01];;set_Reading("lux",[?$SELF:lux],1)}\

Im ersten Block wird das Reading Lux berechnet und ohne Trigger gesetzt.
Im zweiten Block wird entkoppelt das eigene Reading mit Trigger überschrieben.

Besser wäre natürlich die Events des Sensors beim Sensor selbst zu reduzieren, denn die belasten in der hohen Häufigkeit dein System dennoch.

FunkOdyssey · 23 August 2020, 14:45:13

Zitat von: Damian am 23 August 2020, 10:39:58
Das Problem ist, dass FHEM eigenständig, obwohl lux ohne Event-Flag geschrieben wurde, es zu den vom DOIF später durch den Zeittrigger produzierten Events (state, cmd...) zuordnet und im Eventmonitor anzeigt.

Ich würde es im DOIF-Perlmodus realisieren, dann hast du auch nur die Events, die du haben willst:

z. B. für ein Reading reicht dieses:

Code Auswählen Erweitern
defmod Reading_test DOIF {set_Reading("lux",[sensor:lux:med])}\ {[+00:01];;set_Reading("lux",[?$SELF:lux],1)}\

Im ersten Block wird das Reading Lux berechnet und ohne Trigger gesetzt.
Im zweiten Block wird entkoppelt das eigene Reading mit Trigger überschrieben.

Ich bin dir sehr dankbar. Diese Lösung finde ich auch sauberer.

Zitat von: Damian am 23 August 2020, 10:39:58
Besser wäre natürlich die Events des Sensors beim Sensor selbst zu reduzieren, denn die belasten in der hohen Häufigkeit dein System dennoch.

Das sind Xiaomi Lichtsensoren (lumi.sen_ill.mgl01 / ZHALightLevel). Ich habe schon alles versucht, aber scheinbar kann man das Intervall nicht verändern.
Ich bin auch nicht wirklich begeistert, dass fünf dieser Sensoren mein System fluten.

Sany · 24 August 2020, 09:25:09

@FunkOdyssey

Könntest Du mal den Eventmonitor für einen Sensor ein paar Minuten mitlaufen lassen und hier zeigen?
Bitte beim Sensor alle attr event-on-change/event-on-update/event-min-interval löschen.
Und beschreiben, was mit den Werten dann gemacht werden soll.
Vielleicht läßt sich ja doch was finden, damit nicht jeder event zur Auswertung kommt.

Danke.

FunkOdyssey · 24 August 2020, 14:05:21

Natürlich. Hier das Log:

Code Auswählen

2020-08-24 14:01:45 HUEDevice sensor daylight: 1
2020-08-24 14:01:45 HUEDevice sensor lux: 13253
2020-08-24 14:01:45 HUEDevice sensor lightlevel: 41224
2020-08-24 14:01:45 HUEDevice sensor dark: 0
2020-08-24 14:01:50 HUEDevice sensor daylight: 1
2020-08-24 14:01:50 HUEDevice sensor dark: 0
2020-08-24 14:01:50 HUEDevice sensor lightlevel: 41116
2020-08-24 14:01:50 HUEDevice sensor lux: 12927
2020-08-24 14:01:55 HUEDevice sensor dark: 0
2020-08-24 14:01:55 HUEDevice sensor lightlevel: 41011
2020-08-24 14:01:55 HUEDevice sensor lux: 12618
2020-08-24 14:01:55 HUEDevice sensor daylight: 1
2020-08-24 14:02:00 HUEDevice sensor daylight: 1
2020-08-24 14:02:00 HUEDevice sensor lux: 13518
2020-08-24 14:02:00 HUEDevice sensor lightlevel: 41310
2020-08-24 14:02:00 HUEDevice sensor dark: 0
2020-08-24 14:02:05 HUEDevice sensor daylight: 1
2020-08-24 14:02:05 HUEDevice sensor dark: 0
2020-08-24 14:02:05 HUEDevice sensor lightlevel: 41271
2020-08-24 14:02:05 HUEDevice sensor lux: 13397
2020-08-24 14:02:10 HUEDevice sensor dark: 0
2020-08-24 14:02:10 HUEDevice sensor lightlevel: 41195
2020-08-24 14:02:10 HUEDevice sensor lux: 13164
2020-08-24 14:02:10 HUEDevice sensor daylight: 1
2020-08-24 14:02:15 HUEDevice sensor dark: 0
2020-08-24 14:02:15 HUEDevice sensor lightlevel: 41122
2020-08-24 14:02:15 HUEDevice sensor lux: 12945
2020-08-24 14:02:15 HUEDevice sensor daylight: 1
2020-08-24 14:02:20 HUEDevice sensor daylight: 1
2020-08-24 14:02:20 HUEDevice sensor dark: 0
2020-08-24 14:02:20 HUEDevice sensor lightlevel: 41049
2020-08-24 14:02:20 HUEDevice sensor lux: 12729
2020-08-24 14:02:25 HUEDevice sensor lux: 12529
2020-08-24 14:02:25 HUEDevice sensor lightlevel: 40980
2020-08-24 14:02:25 HUEDevice sensor dark: 0
2020-08-24 14:02:25 HUEDevice sensor daylight: 1
2020-08-24 14:02:29 HUEDevice sensor daylight: 1
2020-08-24 14:02:29 HUEDevice sensor dark: 0
2020-08-24 14:02:29 HUEDevice sensor lightlevel: 40920
2020-08-24 14:02:29 HUEDevice sensor lux: 12357
2020-08-24 14:02:34 HUEDevice sensor daylight: 1
2020-08-24 14:02:34 HUEDevice sensor lux: 12181
2020-08-24 14:02:34 HUEDevice sensor lightlevel: 40858
2020-08-24 14:02:34 HUEDevice sensor dark: 0
2020-08-24 14:02:39 HUEDevice sensor lux: 12023
2020-08-24 14:02:39 HUEDevice sensor lightlevel: 40801
2020-08-24 14:02:39 HUEDevice sensor dark: 0
2020-08-24 14:02:39 HUEDevice sensor daylight: 1
2020-08-24 14:02:44 HUEDevice sensor lux: 11871
2020-08-24 14:02:44 HUEDevice sensor lightlevel: 40746
2020-08-24 14:02:44 HUEDevice sensor dark: 0
2020-08-24 14:02:44 HUEDevice sensor daylight: 1
2020-08-24 14:02:49 HUEDevice sensor daylight: 1
2020-08-24 14:02:49 HUEDevice sensor dark: 0
2020-08-24 14:02:49 HUEDevice sensor lightlevel: 40700
2020-08-24 14:02:49 HUEDevice sensor lux: 11746
2020-08-24 14:02:54 HUEDevice sensor lux: 11623
2020-08-24 14:02:54 HUEDevice sensor lightlevel: 40654
2020-08-24 14:02:54 HUEDevice sensor dark: 0
2020-08-24 14:02:54 HUEDevice sensor daylight: 1
2020-08-24 14:02:59 HUEDevice sensor lux: 11521
2020-08-24 14:02:59 HUEDevice sensor lightlevel: 40616
2020-08-24 14:02:59 HUEDevice sensor dark: 0
2020-08-24 14:02:59 HUEDevice sensor daylight: 1
2020-08-24 14:03:04 HUEDevice sensor daylight: 1
2020-08-24 14:03:04 HUEDevice sensor lux: 11437
2020-08-24 14:03:04 HUEDevice sensor lightlevel: 40584
2020-08-24 14:03:04 HUEDevice sensor dark: 0
2020-08-24 14:03:09 HUEDevice sensor lux: 11358
2020-08-24 14:03:09 HUEDevice sensor lightlevel: 40554
2020-08-24 14:03:09 HUEDevice sensor dark: 0
2020-08-24 14:03:09 HUEDevice sensor daylight: 1
2020-08-24 14:03:14 HUEDevice sensor daylight: 1
2020-08-24 14:03:14 HUEDevice sensor dark: 0
2020-08-24 14:03:14 HUEDevice sensor lightlevel: 40525
2020-08-24 14:03:14 HUEDevice sensor lux: 11282
2020-08-24 14:03:19 HUEDevice sensor lux: 11231
2020-08-24 14:03:19 HUEDevice sensor lightlevel: 40505
2020-08-24 14:03:19 HUEDevice sensor dark: 0
2020-08-24 14:03:19 HUEDevice sensor daylight: 1

Sany · 24 August 2020, 14:46:57

Hallo FunkOdyssey,

der Sensor ist ja ziemlich gesprächig. Aber man kann das ganz gut eindämmen. Den Werten nach scheint lux ein logarithmischer Wert zu sein (ok, ist ein wenig Glaskugel, da alle Werte recht ähnlich sind, aber verglichen mit meinem Lichtsensor und lux-werten um 13000 entspricht das einem recht hellen Tageslicht. Ich kenne den Sensor nicht, er wird aber lux von ~0 bis ~80000/100000 liefern.
Ich habe das bei mir so gelöst: per userReading wird der logarithmische Lux-wert in einen linearen Wert umgerechnet:

Code Auswählen

LuxLin:lux.* {sprintf("%d",(log(ReadingsVal($name,"lux",0)+1)/log(10)*20))}
die Formel liefert bei Eingangswerten von 0...100000 als Ergebnis 0..100, sagen wir mal %
Die entstehenden Werte sollten sich schon mal deutlich weniger ändern, als der lux-Wert. Wenn es immer noch zu viel ist, dann kann man das beim event-on-change noch mit einer Schwelle lösen.
Bei Dir sollte also im Sensor! das userReading sein, zusätzlich noch

Code Auswählen

event-on-change-reading lux,LuxLin,(was auch immer noch triggern soll, z.B. battery etc)
event-min-Inteval LuxLin:900

Der min-interval liefert mindestens alle 15min einen Wert, wenn dieser sich nicht geändert hat (z.B. Nachts ist und bleibt er ja 0, evtl. als Activity-check)

Die Umrechnung in den linearen Wert habe ich eigentlich nur, um den lux-wert besser interpretieren zu können und um bei Vergleich mit einer Hysterese diese immer gleich zu haben, auch wenn der Bereich verschoben wird, damit es besser passt. Z.B. LuxLin > 80 dann Lampen aus, LuxLin < 75 Lampen an.

Damit sendet zwar der Sender immer noch wie vorher, aber fhem generiet wesentlich weniger events.

Viel Erfolg!

FunkOdyssey · 24 August 2020, 15:01:36

Vielen Dank für deine Mühe.
Ich kenne den Weg eigentlich umgekehrt. Bei gewissen Steuerungen lasse ich mir den Lux-Wert in einen logarithmischen Lightlevel-Wert umrechnen.
Ich verstehe deine Vorgehensweise.
Nur würde FHEM weiterhin mit den Events attackiert werden. An dieser Stelle sehe ich keine Entlastung.
Ich habe mich schon daran gewöhnt, einen minütlichen Timer laufen zu lassen. Damit kann ich auch endlich das ASC-Modul im Debug-Modus laufen lassen und das Log einsehbar machen. Vorher wurde zu viel protokolliert und man kam nicht noch über SSH an das Log.

Übrigens brauche ich Lux wie auch Lightlevel.
Die Beschattung läuft bei mir über Lux, da ich dann die Sonnenintensität aussagekräftig zurückgeliefert bekommen.
Lampenschaltungen berücksichtigen die sichtbare Helligkeit und daher nutze ich dort Lightlevel.

Damian · 24 August 2020, 23:03:03

Zitat von: FunkOdyssey am 24 August 2020, 15:01:36
Vielen Dank für deine Mühe.
Ich kenne den Weg eigentlich umgekehrt. Bei gewissen Steuerungen lasse ich mir den Lux-Wert in einen logarithmischen Lightlevel-Wert umrechnen.
Ich verstehe deine Vorgehensweise.
Nur würde FHEM weiterhin mit den Events attackiert werden. An dieser Stelle sehe ich keine Entlastung.
Ich habe mich schon daran gewöhnt, einen minütlichen Timer laufen zu lassen. Damit kann ich auch endlich das ASC-Modul im Debug-Modus laufen lassen und das Log einsehbar machen. Vorher wurde zu viel protokolliert und man kam nicht noch über SSH an das Log.

Übrigens brauche ich Lux wie auch Lightlevel.
Die Beschattung läuft bei mir über Lux, da ich dann die Sonnenintensität aussagekräftig zurückgeliefert bekommen.
Lampenschaltungen berücksichtigen die sichtbare Helligkeit und daher nutze ich dort Lightlevel.

naja, wenn ich mir die geposteten lux-Werte anschaue und in die vorgeschlagene log-Funktion einsetze, dann würde sich Anzahl der Events bei event-on-change deutlich reduzieren - möglicherweise auf ein Zehntel. Eine Auflösung von 1% sollte eigentlich ausreichend sein.

Sany · 25 August 2020, 13:00:38

Also ich kenne den Sensor nicht, habe lediglich die Info gefunden, dass er 0..83000 lux messen kann (war auf einem chinesischen Flyer von dem mijia Light sensor). Mich würde mal interessieren, was lux und lightlevel unterscheidet. Die gezeigten Werte waren ja leider fast gleich, interessanter wäre im dunkeln, in einem normal beleuchteten Raum und draussen zu messen, um da mehr Aussagekraft hineinzubekommen.

ZitatÜbrigens brauche ich Lux wie auch Lightlevel.
Die Beschattung ....

Ich habe mit BH1750, OPT3001 und MAX44009 Lichtsensoren gebaut, die chips liefern aber alle nur EINEN Wert, lux. Da Dein Lichtsensor 0..83k-lux liefert tippe ich mal stark auf den OPT3001, der misst nämlich 0,01..83000 lux.
Was XIAOMI da wohl macht, um lux und lightlevel auszugeben?

zum eigentlich Problem zurück:

ZitatNur würde FHEM weiterhin mit den Events attackiert werden. An dieser Stelle sehe ich keine Entlastung.

(Glaskugel) der Sensor sendet ZigBee und ist per Phoscon und HUEbridge an fhem gekoppelt. Somit "produziert" das Device die Events. Hier kannst Du reduzieren, indem Du alle Readings, die nicht gebraucht werden ausschließt bzw. per event-on-change-reading und event-min-interval auf das nötigste reduzierst.
Durch die Umrechnung in 0..100 gibt es keine events, wenn sich lux z.B. von 11183 auf 11187 ändert. Ohne Umrechnung schon. Das Originalreading "lux" solltest Du nirgends zum triggern nehmen, dann wird es auch nicht weiter beachtet. Kann das Reading jedoch etwas triggern/auslösen, so muss das jedesmal ausgewertet werden und "belastet" fhem.
Deine Lösung im Moment triggert alle 5sec das DOIF, welches beim abarbeiten wiederum events erzeugt. Also insgesamt deutlich mehr für fhem zu tun.
(Man möge mich korrigieren, falls ich das mit den events nicht korrekt wiedergegeben habe. Das ist bisher mein Verständnis, wie fhem "tickt"

Damian · 25 August 2020, 14:02:46

Meine Messungen in einem anderen Zusammenhang haben ergeben, dass das Setzen eines Reading ohne Event 100 mal weniger Performance benötig, als wenn man ein Event dabei erzeugt. Das Event wird nämlich erst mal an alle Devices weitergegeben, die im System definiert sind, bei denen nicht explizit programmiert wurde, welche Events sie bekommen sollen - das dürften die meisten Module in FHEM sein.

Die beste Performancesteigerung in FHEM ist die Reduzierung von Events.

frank · 25 August 2020, 14:11:18

ich sags mal so:

das original reading lux erzeugt events.
die werden mit event-on-change reduziert.

mit dem zusätzlichen userreading luxlin generierst du aber nun erst einmal zusätzliche events.
auch wenn sie mit event-on-change reduziert sind.
mit dem userreading hast du in jedem fall immer in summe mehr events als ohne.

nützlich wird es erst, wenn in einem weiteren modul (zb notify, doif) auf events reagiert werden soll.

Sany · 25 August 2020, 15:16:26

Zitatdas original reading lux erzeugt events.
die werden mit event-on-change reduziert.

das erste läßt sich nicht vermeiden, das zweite spielt eigentlich erst bei 0 lux eine Rolle, d.h. es findet keine change statt ergo gibts keinen event.
Wichtig: der Sender sendet alle 5 sec! ich schätze, im 1-2 stelligen Bereich der Werte könnte es sein. dass mal 2 gleiche hintereinander kommen, aber bei größeren Werten ist das eher ausgeschlossen. Man bekommt also alle 5 sec einen event, der dann ein notify/Doif triggert. Wenn es jetzt nur darum geht, z.B. eine Lichtschwelle abzufragen dann sind das viele, viele events, die ein notify/DOIF triggern, aber eigentlich nichts machen (ausser der Schwelle)
Das userReading wird bei jedem event vom Sender ausgeführt, löst aber nur ein event aus, wenn sich der Wert ändert (event-on-change-reading auch hier). Beispielhaft von 4240 - 4754 lux ergibt sich der Wert 73 LuxLin (um bei meinem Beispiel zu bleiben). Bei kleinen lux-Werten gibts mehr Änderungen, bei größeren entsprechend weniger. Wenn also der output des userReadings die nachgelagerten notify/DOIFs triggert sind das wesentlich weniger Ereignisse als direkt.
Mittels Schwelle beim event-on-change-reading könnte man auch arbeiten, allerdings macht das bei logarithmischen Werten keinen Sinn, da die Schwelle fix ist.

ZitatDas Event wird nämlich erst mal an alle Devices weitergegeben, die im System definiert sind, bei denen nicht explizit programmiert wurde, welche Events sie bekommen sollen - das dürften die meisten Module in FHEM sein.

hast Du da Beispiele? Oder wie muss ich mir das vorstellen, dass ein Modul so programmiert ist, das es auf bestimmte Events reagiert und andere nicht? Oder ist das schon der Fall, dass wenn ich ein DOIF anlege und einen "Sender" als trigger definiere, dass dieses DOIF dann nicht auf andere events "hört"?

ZitatDie beste Performancesteigerung in FHEM ist die Reduzierung von Events.

Da kann ich ein langes Lied von singen... Mein fhem hatte alle Nase lang Hänger von ~0.5 bis 2 sec (100%CPU-Last, sonst 40-80%). Nach dem ich alle Definitionen (hoffe ich) abgesucht habe auf events, die nicht nötig sind, läuft es reibungslos (fast immer unter 10% Load, ab und an mal kurz ~30).

Damian · 25 August 2020, 15:19:16

ja, ich habe es bei mir ausprobiert. Es ist wohl so, dass man mit userReadings nicht mehr das ursprüngliche Event beeinflussen kann. Es werden weitere Events generiert. Im schlimmsten Fallen entsteht sogar eine Rekursion, weil das userReading auf seine eigene Änderung getriggert wird. Diese wird dann im weiteren Durchlauf von FHEM unterbunden.

Beispiel:

mit

Code Auswählen

attr ESPEasy_ESP_Temp_Keller_Vorlauf userReadings Temperature {ReadingsVal($name,"Temperature",0)/2}

passiert Folgendes:

2020-08-25 15:14:38.153 ESPEasy ESPEasy_ESP_Temp_Keller_Vorlauf Temperature: 23.00
2020-08-25 15:14:38.153 ESPEasy ESPEasy_ESP_Temp_Keller_Vorlauf Temperature: 11.5
2020-08-25 15:14:38.163 ESPEasy ESPEasy_ESP_Temp_Keller_Vorlauf Temperature: 5.75

Damian · 25 August 2020, 15:26:25

Zitat von: Sany am 25 August 2020, 15:16:26
das erste läßt sich nicht vermeiden, das zweite spielt eigentlich erst bei 0 lux eine Rolle, d.h. es findet keine change statt ergo gibts keinen event.
Wichtig: der Sender sendet alle 5 sec! ich schätze, im 1-2 stelligen Bereich der Werte könnte es sein. dass mal 2 gleiche hintereinander kommen, aber bei größeren Werten ist das eher ausgeschlossen. Man bekommt also alle 5 sec einen event, der dann ein notify/Doif triggert. Wenn es jetzt nur darum geht, z.B. eine Lichtschwelle abzufragen dann sind das viele, viele events, die ein notify/DOIF triggern, aber eigentlich nichts machen (ausser der Schwelle)
Das userReading wird bei jedem event vom Sender ausgeführt, löst aber nur ein event aus, wenn sich der Wert ändert (event-on-change-reading auch hier). Beispielhaft von 4240 - 4754 lux ergibt sich der Wert 73 LuxLin (um bei meinem Beispiel zu bleiben). Bei kleinen lux-Werten gibts mehr Änderungen, bei größeren entsprechend weniger. Wenn also der output des userReadings die nachgelagerten notify/DOIFs triggert sind das wesentlich weniger Ereignisse als direkt.
Mittels Schwelle beim event-on-change-reading könnte man auch arbeiten, allerdings macht das bei logarithmischen Werten keinen Sinn, da die Schwelle fix ist.

hast Du da Beispiele? Oder wie muss ich mir das vorstellen, dass ein Modul so programmiert ist, das es auf bestimmte Events reagiert und andere nicht? Oder ist das schon der Fall, dass wenn ich ein DOIF anlege und einen "Sender" als trigger definiere, dass dieses DOIF dann nicht auf andere events "hört"?
Da kann ich ein langes Lied von singen... Mein fhem hatte alle Nase lang Hänger von ~0.5 bis 2 sec (100%CPU-Last, sonst 40-80%). Nach dem ich alle Definitionen (hoffe ich) abgesucht habe auf events, die nicht nötig sind, läuft es reibungslos (fast immer unter 10% Load, ab und an mal kurz ~30).

ja, man generiert insg. mehr Events, allerdings muss ein DOIF oder notify ggf. weniger rechnen, weil es dann weniger oft getriggert wird. Es hängt natürlich davon ab, wie rechenintensiv die Bearbeitung des Events im jeweiligen Modul ist.

Per · 03 März 2021, 16:33:01

Ich hatte damals in mein Modul eine prozentuale Abhängigkeit des Stromverbrauches einprogrammiert, weil es keine logarithmische Funktion davon gibt, ansonsten wäre das eine gute Idee.
Aber vllt. könnte man event-on-change-reading so erweitern, dass es auch auf "10%" reagiert? Das wird ja nicht das einzige Modul und die einzige Anwenung sein, wo das praktisch wäre, wenn auch hier besonders dringend, um das System zu entlasten.
Ich habe es mal in "Vorschläge" eingestellt.