Hallo, besteht die Möglichkeit, die Inhalte in event_Readings irgendwie zu verzögern?
Ich habe Sensoren, die zu schnell pollen und ich will mit event_Readings einen Median und einen größeren Abstand zwischen den Events erzeugen.
Danke.
Zitat von: FunkOdyssey am 30 Juli 2020, 16:11:34
Hallo, besteht die Möglichkeit, die Inhalte in event_Readings irgendwie zu verzögern?
Ich habe Sensoren, die zu schnell pollen und ich will mit event_Readings einen Median und einen größeren Abstand zwischen den Events erzeugen.
Danke.
Dann nimm Median von 5 oder 10, dann hast du automatisch eine Verzögerung.
Danke. Das hat nur leider den Nachteil, dass der Wert irgendwann stehenbleibt, da auf 5-10 weitere Events gewartet wird.
Geht das nicht mit event-min-interval?
Ja und nein.
Zwar wird dann dadurch der Wert als Event verschickt.
Aber der Median wurde nicht neu berechnet. Somit bleibt dad Reading unverändert.
Mir ist nicht klar welche Events zu verzögern willst. Das vom Sensor, oder das vom event_Readings? Je nach dem meinte ich entspr. das event-min-interval zu setzen.
Zitat von: amenomade am 22 August 2020, 12:09:14
Mir ist nicht klar welche Events zu verzögern willst. Das vom Sensor, oder das vom event_Readings? Je nach dem meinte ich entspr. das event-min-interval zu setzen.
Also, wenn ein Sensor z. B. alle 30 Sekunden etwas sendet, dann wird mit einer Verzögerung bei med5 nach 5*30=150 Sekunden der entsprechende bereinigte Wert geliefert. Die Häufigkeit des Triggerns bleibt aber die Gleiche.
Wenn das Modul nicht getriggert wird, dann liegt es ggf. an einem gesetzten event-on-change-Attribut beim Sensor, dann sollte event-min-interval beim Sensor helfen, damit gleiche Events durchkommen.
Mir ist das eigentlich egal, wo verzögert wird. Ich habe einfach zu viele Events und würde die ansonsten einfach zum DOIF durchlassen und dort irgendwie drosseln.
Edit: Es tut mir leid, ich habe wieder den falschen Knopf gedrückt, statt Zitat, Änderung, ich kann es leider nicht mehr rückgängig machen.
Nachtrag von FunkOdyssey: Die Änderung kam nicht von mir. :D
Zitat von: Damian am 22 August 2020, 12:20:08
Also, wenn ein Sensor z. B. alle 30 Sekunden etwas sendet, dann wird mit einer Verzögerung bei med5 nach 5*30=150 Sekunden der entsprechende bereinigte Wert geliefert. Die Häufigkeit des Triggerns bleibt aber die Gleiche.
Wenn das Modul nicht getriggert wird, dann liegt es ggf. an einem gesetzten event-on-change-Attribut beim Sensor, dann sollte event-min-interval beim Sensor helfen, damit gleiche Events durchkommen.
Ich probiere es noch einmal.
Dann könnte ich auch evtl. den Code dazu hier posten.
Also ich kann machen was ich will.
Aber auch mit Median10 kommen die Events zu häufig.
Die Sensoren triggern alle 5 Sekunden.
Dort habe ich folgendes gesetzt:
event-min-interval lux:300,lightlevel:300
event-on-change-reading .*
Das DOIF sieht so aus:
defmod di_light DOIF ##
attr di_light do always
attr di_light event-min-interval lux:300,lightlevel:300
attr di_light event-on-change-reading .*
attr di_light event_Readings lux:round([sensor:lux:med10],0),\
lightlevel:round([sensor:lightlevel:med10],0)
attr di_light readingList lux,lightlevel
attr di_light setList lux\
lightlevel
Trotzdem kommen fast alle 5s neue Werte im DOIF-FileLog an.
Zitat von: FunkOdyssey am 22 August 2020, 12:42:09
Also ich kann machen was ich will.
Aber auch mit Median10 kommen die Events zu häufig.
Die Sensoren triggern alle 5 Sekunden.
Dort habe ich folgendes gesetzt:
event-min-interval lux:300,lightlevel:300
event-on-change-reading .*
Das DOIF sieht so aus:
defmod di_light DOIF ##
attr di_light do always
attr di_light event-min-interval lux:300,lightlevel:300
attr di_light event-on-change-reading .*
attr di_light event_Readings lux:round([sensor:lux:med10],0),\
lightlevel:round([sensor:lightlevel:med10],0)
attr di_light readingList lux,lightlevel
attr di_light setList lux\
lightlevel
Trotzdem kommen fast alle 5s neue Werte im DOIF-FileLog an.
Die Attribute event-min-interval und event-on-change-reading .* gehören zum Sensor.
Sonst beim DOIF cmdpause Attribut setzen.
Zitat von: Damian am 22 August 2020, 12:52:09
Die Attribute event-min-interval und event-on-change-reading .* gehören zum Sensor.
Ja. Eigentlich wohl. Die richten im DOIF aber doch keinen Schaden an. Aber auch ohne gibt es keinen Unterschied.
Zitat
Sonst beim DOIF cmdpause Attribut setzen.
Ausprobiert. Ohne Erfolg. Kein Unterschied zu zuvor.
Zitat von: FunkOdyssey am 22 August 2020, 12:56:28
Ja. Eigentlich wohl. Die richten im DOIF aber doch keinen Schaden an. Aber auch ohne gibt es keinen Unterschied.
Ausprobiert. Ohne Erfolg. Kein Unterschied zu zuvor.
OK, ich sehe, dass du das DOIF nur für die berechneten Readings lux, lightlevel benutzt, da nützt cmdpause natürlich nichts.
Es steht und fallt alles mit den berechneten Readings.
Wenn die Readings nach jeder Berechnung einen unterschiedlichen Wert haben, dann nützt auch event-on-change-reading natürlich nichts.
Mit dem Attribut event-aggregator im Ursprungsgerät kann ein Median berechnet werden und die Eventrate gedrosselt werden, https://commandref.fhem.de/commandref_DE.html#readingFnAttributes
@Ellert: Danke. Ich kenne nicht eine Installation, in dem event-aggregator richtig funktioniert. Die Events kommen trotzdem in 5s-Intervallen.
Merkwürdig ist das Verhalten von event-aggregator nach Änderung daran. Man muss das Attribut jedesmal löschen und neu anlegen.
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).
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
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:
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.
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:
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.
@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.
Natürlich. Hier das Log:
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
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:
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
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!
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.
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.
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"
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.
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.
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).
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
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
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.
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.