Grundsätzliche Codingfragen / Performance

[Zrrronggg!]

Naja die Nebenwirkungen von eocr .* lassen sich z.B. durch eour: event-on-update-reading Reading1,Reading2 usw. wieder "zurückstellen".
Es gibt auch andere Mechanismen wie mininterval...

Am besten mal lesen...
https://wiki.fhem.de/wiki/Event-on-change-reading
https://wiki.fhem.de/wiki/Event-on-update-reading
https://wiki.fhem.de/wiki/Event-min-interval

Ja, danke, aber das habe ich schon alles gelesen und auch kapiert. Damit arbeite ich schon.
Konkret habe ich allerdings den tieferen Sinn von "Event-on-update-reading" nicht verstanden.
Ich verstehe glaube ich zwar was es macht, mir ist noch nicht klar, wozu man das verwenden sollte, also welches Problem das löst. Ich hab das Gefühl durch richtige Nutzung von Event-on-change-reading ist Event-on-update-reading eigentlich überflüssig. Oder?

So oder so könnten die Wikiartikel noch etwas Feinschliff verkraften, sobald ich da etwas sicherer bin, gehe ich das mal an.

"Event" und das, was man im Event-Monitor sieht, sind betreffend der Systemlast nicht ganz dasselbe. Werden mehrere Readings "auf einen Rutsch" aktualisiert (bulk-update), ist das bzgl. der Info an Eventhandler EIN Durchlauf, der dann nur etwas länger dauert, weil der "Eventstapel" eben größer ist und nicht nur ein Reading enthält.

Okay. War mir nur halb klar.

Doku ist sicher eine gute Idee, und notifyRegexpCheck() als Funktion ist auch noch nicht besonders alt (es ist afaik eine Reaktion auf "Optimierer" wie mich, die ihre regexp (ehemals) gerne optimierten, um möglichst viele Buchstaben zu sparen ). Das ganze Thema ist auch erst jüngst v.a. deswegen zum Thema geworden, weil manche Devices unglaublich viele unnötige Events produzieren, und wenn man "ein paar" davon hat, dann summiert sich das halt.

Ja, für das eine oder ander ist meine Inst auch zu alt, ich habe schon länger keine Update mehr gemacht  (Update zeigt bei mir immer an, alle Module seien aktuell, ich kapier nicht warum, das ist aber ein anderes Thema und stört an sich nur wenig.) notifyRegexpCheck() geht bei mit z.b. nicht. Lustigerweise schien ich bei vielen Fällen auch ohne Kenntnis des NOTIVYDEF Themas ganz bauchbare notify Regexp verwendet zu haben, bei mir immer getrieben vom Wunsch möglichst sicher zu wissen, warum genau ausgelöst wurde. Sowas wie nur Gerät ohne möglichst eng passendes Event hab ich immer versucht zu vermeiden.

Es wird auch immer noch ein Freiwilliger gesucht, der mal "anfängerfreundlich" erklärt, wie die Attribute event-on-change-reading, ... und timestamp-on-change-reading (@MadMax-FHEM: Danke für den Beleg, dass man sich da gerne was vergisst, wenn man es nicht einmal gründlich macht...) denn sinnvoll zu setzen wären - mein Vorschlag für ein Demo-Device wäre ein shelly-plug (mit Leistungsmessung)@MQTT2, aber wen den Job übernimmt, darf gerne auch was anderes nehmen. ("Wechselwirkungen" ist m.E. nur verständlich, wenn man es verstanden hat...).

Ich mach das an sich gerne, also ein für mich kryptisches Thema im Wiki beschreiben, sobald ich es kapiert habe. Der Vorteil ist dann, dass ich in dem Moment genau weiss, was mit zum Verständnis geholfen hätte. Aber der "Kapierlevel" ist noch zu niedrig, besonders was den Einsatz von Event-on-update-reading betrifft. (Und Shelly-plugs habe ich nicht)

Weiter hoffe ich, dass angekommen ist, dass ich nicht grundsätzlich der Ansicht bin, dass "event-on-change-reading .*" falsch ist. Es ist nur oft zu kurz gegriffen (oder .* kommt an der falschen Stelle/zu früh in der Kette).

Selbstverständlich. Für mich ist es aber aktuell der einfachste Weg. Die Nebenwirkungen glaube ich zu verstehen und beherrschen zu können.

Und da Wiederholung scheinbar manchmal hilft:

Völlig korrekt formuliert was mich betrifft (da SCHEINBAR nämlich bedeutet: Sieht so aus, ist aber nicht so, im Gegensatz zu ANSCHEINEND: Sieht so aus, ist aber nicht sicher) Kurzum: Bei mir hilft das höchstens zum Schein aber nicht echt.
In so einem Thread wie diesem hier ist es nämlich so, dass viele Puzzelstückchen von mir zwar gesehen werden, ich aber noch nicht weiss wo sie hin gehören. Diese Puzzelstücke öfters zu präsentieren hilft bei mir nicht, ich muss warten, bis sich ein Gesamtbild ergibt und ich auf einmal sehe  was es mit dem Puzzelstück auf sich hat. Es mag sein, dass das für Manche so aussieht, als hätte ich die Beiträge nicht wahrgenommen und als müsse man sie nochmal präsentieren. Inhaltiche Wiederholung in anderer Formulierung mag sogar helfen. Eine andere Formulierung kann machmal den Groschen fallen lassen. Blosse Eigenzitate hingegegen ...

Zum konkreten Fall:

Bitte immer erst checken, was man bereits von extern abfangen kann

Ich wüsste nicht,  wie ich das machen sollte. Wenn eine Heizungsventil alle x Sekunden meldet, dass es geschlossen ist, dann meldet es dass.
Meine Thermometer melden alle 2 Minuten oder so die Temperatur, auch wenn sie sich nicht ändert. Die Fenstersensoren melden alle 2 Minuten das das Fenster immer noch zu ist. Alle melden dauernd, die Batterien sind noch okay... und was eben sonst noch an Kram rüber kommt.
Ich wüsste nicht wie ich das ändern könnte. Gut, doch, bei manchen Devices kann man etwas konfigurieren, aber das ist ja eher die Ausnahme.

(und "notfalls" mal auf den Hersteller/Anbieter/github-Repo-Inhaber zugehen!)

Naja, die Erfolgsaussichten bei Herstellern schätze ich als gegen Null gehen ein. Bei github-Repo-Inhabern gäbe es ein anderes Problem: Ich bin mir meist nicht sicher, ob meine Ansicht über Dinge überhaupt sinnvoll ist, bzw ich das überhaupt komplett verstanden habe. Ich komme idr. Regel ganz gut zu recht und mein FHEM Installation macht seit Jahren was ich will. Aber im Grunde habe ich keine Ahnung. Ich bin Laie. Ich bin auf einem ganz anderen Niveau unterwegs als du oder Rudi oder Otto123 und  viel andere hier . Ich fühle mich echt nicht in der Lage, Modulentwicklern zu sagen, was sie da vielleicht besser machen könnten.
Und da kommt mir event-on-change-reading .* gerade recht. Welche logischen Implikationen das haben kann und das sich deswegen das Verhalten meiner Alarmanlage verändert, kann ich verstehen und beherrschen. Und das ich mal ein Auge auf Graphen haben muss und man da mit Event-min-interval gegensteuern kann ist auch klar.

Aber Anmerkungen wie Deine dazu sind trotzdem wichtig für mich, schon weil sie das Bild erweitern und ich wieder ein kleines Puzzelstück bekomme, das zum Bild beiträgt.

Sowas ist eben schwer, ihr wisst nicht welchen Kenntnisstand ich habe, und könnt nicht bei Adam und Eva anfangen. Ich will auch nicht nerfen oder eure Zeit klauen.

[MadMax-FHEM]

Konkret habe ich allerdings den tieferen Sinn von "Event-on-update-reading" nicht verstanden.
Ich verstehe glaube ich zwar was es macht, mir ist noch nicht klar, wozu man das verwenden sollte, also welches Problem das löst. Ich hab das Gefühl durch richtige Nutzung von Event-on-change-reading ist Event-on-update-reading eigentlich überflüssig. Oder?

event-on-change-reading .* -> alle Events nur bei einer Änderung

Das ist halt manchmal "doof", z.B. für Logs oder wichtiger für "Automatismen", die auch laufen sollen, auch wenn sich nichts ändert (fällt mir aber grad nix ein   )...

Dann kannst du entweder:

event-on-change-reading statt mit .* eben mit den einzelnen Readings "füllen", für die das gelten soll. Bei Devices mit wenig Readings kann man das so machen. Hat ein Device (keine Ahnung) mahr als 10 oder 20 Readings und du willst aber 2 davon "raus" nehmen, dann wird die Liste halt lang:

Code Auswählen Erweitern


event-on-change-reading Reading1,Reading3,Reading4,Reading5,Reading6,Reading7,Reading8

d.h. für Reading2 "gültet" das nicht

Oder eben:

Code Auswählen Erweitern


event-on-change-reading .*

und dann:

Code Auswählen Erweitern


event-on-update-reading Reading2


Jetzt kommst du: was ist "schöner", "schneller", ...

Klar man kann auch (wo es geht) "RegExen"

Und es gibt ja auch andere Möglichkeiten...

Und wenn man nicht jede Änderung will/braucht, sondern alle 5min oder 10min reicht, dann eben event-min-interval

Gruß, Joachim

[Beta-User]

..und wieder hält doppelt genäht eventuell besser...

Ja, danke, aber das habe ich schon alles gelesen und auch kapiert. Damit arbeite ich schon.
Konkret habe ich allerdings den tieferen Sinn von "Event-on-update-reading" nicht verstanden.

Ging mir auch lange so, bis ich irgendwann mal dachte, es sei an der Zeit, das an einem Device mal konkret durchzuspielen...

Im Wiki findet sich (ohne Hervorhebung):

Sind bei einem Device weder event-on-change-reading noch event-on-update-reading spezifiziert, werden für alle Readings sowohl bei Änderung als auch bei der Aktualisierung (mit dem gleichen Wert) Events erzeugt. Sobald jedoch eines der beiden Attribute gesetzt ist, müssen alle Readings, die protokolliert werden sollen bei (mindestens) einem der Attribute berücksichtigt sein.

Das Device, mit dem ich das durchgespielt habe, war ein shelly1pm, die Attribute sind u.A. in diesem Beitrag zu finden:
https://forum.fhem.de/index.php/topic,116162.msg1104833.html#msg1104833

Da gibt es bei eocr dann _kein .*_ , alles, was ich haben will, steht _entweder im einen oder im anderen Attribut_.

So oder so könnten die Wikiartikel noch etwas Feinschliff verkraften, sobald ich da etwas sicherer bin, gehe ich das mal an.
[...]
Ich wüsste nicht,  wie ich das machen sollte. [...]

Wie geschrieben: das Thema ist relativ neu, und wenn man eine "klassische" CUL_HM-lastige Installation hat, kann man da wenig machen - abgesehen vom sauberen Arbeiten beim Anlegen der Eventhandler, das du ja "intuitiv" auch passend gemacht hast.

Mir sind nur eben (v.a.) in der MQTT-Welt in der jüngeren Vergangenheit einige Beispiele "über den Weg" gelaufen, bei denen die Autoren von "2mqtt"-Anwendungen über Rückmeldungen zu ihren Ideen in der Regel über Anregungen sehr dankbar waren, weil sie in der Regel die "Zielhardware" deutlich besser kannten als MQTT-Basisfunktionalitäten und -Konzepte ("LWT?!? watndat?!?"). Die "Boten" haben übrigens dann in der Regel die betroffenen User gemacht .
Und bei den Shelly kann man eben über das Web-Interface das Meldeverhalten direkt einstellen (vermutlich auch für HTTP-POST). Man muss es nur wissen/danach suchen...

Falls du also Interesse hast, auf einem Test-Pi ein aktuelles FHEM auszuprobieren, sende ich dir gerne meinen Ersatz-Shelly1pm zu, dann werden Theorie und Praxis hoffentlich klarer .

[Zrrronggg!]

Im Wiki findet sich (ohne Hervorhebung):
Zitat
Sind bei einem Device weder event-on-change-reading noch event-on-update-reading spezifiziert, werden für alle Readings sowohl bei Änderung als auch bei der Aktualisierung (mit dem gleichen Wert) Events erzeugt. Sobald jedoch eines der beiden Attribute gesetzt ist, müssen alle Readings, die protokolliert werden sollen bei (mindestens) einem der Attribute berücksichtigt sein.

Ja, gesehen. Mir fehlte da nur die Phantasie mir einen Fall vorzustellen, der mit event-on-change-reading und event-min-interval nicht praktisch lösbar wäre.

Code Auswählen Erweitern

event-on-change-reading Reading1,Reading3,Reading4,Reading5,Reading6,Reading7,Reading8
d.h. für Reading2 "gültet" das nicht

Oder eben:

Code Auswählen Erweitern

event-on-change-reading .*
und dann:

Code Auswählen Erweitern

event-on-update-reading Reading2

Hm. Das geht im ersten Teil meiner Meinung nach sowieso nicht.

Code Auswählen Erweitern

event-on-change-reading  Reading1,Reading3,Reading4,Reading5,Reading6,Reading7,Reading8

bedeutet ja nicht, dass Reading2 noch normal geloggt wird, sondern gar nicht mehr, auch nicht bei Werteänderung.
Wenn ich nun Reading2 auch ohne Werteänderung haben will, würde ich jetzt zusätzlich

Code Auswählen Erweitern

attr <device> event-min-interval Reading2 wählen und mir überlegen, wie oft das reading  ganz ohne event-on-* kommen würde, oder besser noch wie oft ich das Reading BRAUCHE und dann den Interval wählen.

D.H.

Code Auswählen Erweitern

event-on-change-reading .*
und

Code Auswählen Erweitern

event-on-update-reading Reading2

ist aus meiner Sicht nur eine schlechtere Variante von

Code Auswählen Erweitern

event-on-change-reading .*
und

Code Auswählen Erweitern

event-min-interval Reading2

Weil man im letztern Fall nicht abhängig davon ist, was das Geräte denn meint wie oft es aktualisieren will, sondern selber bestimmen kann wie oft man das gleiche Reading sehen muss.

Event-on-update-reading erscheint mir nur sinnvoll, wenn man ein Reading mit jeder normalen Aktualisierung haben will, not matter what, und das in einer Umgebung wo man mit event-on-change-reading arbeitet, aber nicht sagen kann, wie oft man das unveränderte Reading denn "braucht". Es fehlte mir die Phantasie oder der passende Installation, mir so einen Anwendungsfall vorzustellen.

Das liegt ggf auch hier dran:

wenn man eine "klassische" CUL_HM-lastige Installation hat,

Hab ich.

Falls du also Interesse hast, auf einem Test-Pi ein aktuelles FHEM auszuprobieren, sende ich dir gerne meinen Ersatz-Shelly1pm zu, dann werden Theorie und Praxis hoffentlich klarer .

Ja, in der Tat überlege ich schon lange mit einen PI hinzustellen und damit ein Testsystem aufzubauen.
Früher oder später muss ich das sowieso machen. Bestimmte Dinge gehen auf der Linkstation einfach nicht mehr, fängt schon mit der uralten perl version an.
Ggf komme ich darauf zurück 

[Beta-User]

Code Auswählen Erweitern

Event-on-update-reading erscheint mir nur sinnvoll, wenn man ein Reading mit jeder normalen Aktualisierung haben will, not matter what, und das in einer Umgebung wo man mit event-on-change-reading arbeitet, aber nicht sagen kann, wie oft man das unveränderte Reading denn "braucht". Es fehlte mir die Phantasie oder der passende Installation, mir so einen Anwendungsfall vorzustellen.

Bei dem Shelly betrifft das ganz elementar den Schaltzustand des Aktors und die Taste!
Wenn da jemand den Knopf drückt, dann braucht man beides, bekommt es aber eben nur, wenn man es angibt (und wenn man .* ans Ende von eocr macht, bekommt man uU. eine ganze Menge Müll, der niemanden interessiert...).

(vermutlich sollte ich aber mal in die firmware auf dem Ersatzgerät sehen, ob ich da das Sendeintervall nicht doch auch noch auf 0 stellen kann; bei der genannten Schnellaktion wollte ich das nicht austesten, weil ich bestimmte Werte unbedingt regelmäßig haben wollte bzw. der spezielle Aktor überhaupt nur deswegen da ist, weil er bestimmte Werte liefern soll... )

[MadMax-FHEM]

Hm. Das geht im ersten Teil meiner Meinung nach sowieso nicht.
Code: [Auswählen]

event-on-change-reading  Reading1,Reading3,Reading4,Reading5,Reading6,Reading7,Reading8

bedeutet ja nicht, dass Reading2 noch normal geloggt wird, sondern gar nicht mehr, auch nicht bei Werteänderung.
Wenn ich nun Reading2 auch ohne Werteänderung haben will, würde ich jetzt zusätzlich
Code: [Auswählen]

attr <device> event-min-interval Reading2

wählen und mir überlegen, wie oft das reading  ganz ohne event-on-* kommen würde, oder besser noch wie oft ich das Reading BRAUCHE und dann den Interval wählen.

Jep, stimmt!

Korrigiert.

Liegt daran, dass ich erst mal event-on-change-reading .* setze und dann entweder per event-on-update-reading (damit habe ich es wie ohne eocr) oder eben mit min-interval (wenn ich "steuern" will wie oft/wann dann doch auch ohne Änderung) "gegensteuere"...

Und ich habe (noch) Fälle wo ich event-on-update-reading habe, könnte (evtl. mache ich das auch) da auch auf min-interval umstellen aber ich habe eigentlich nur Geräte die ca. alle 3min mal was schicken und wenn da dann auch 10min reichen würden bringt mich das alle 3min nicht um und Grafen sehen einfach schöner aus
(ja sind Homematic   )

Die meisten anderen senden deutlich weniger, da wäre manchmal öfter besser

Gruß, Joachim

[Zrrronggg!]

Bei dem Shelly betrifft das ganz elementar den Schaltzustand des Aktors und die Taste!

Gut, ich hab so ein Dingen (noch) nicht und die verlinkten Threads mit Shelly Spezifika habe ich noch nicht durch. Daher verstehe ich die Funktionsweise der Teil noch nicht so richtig.

Die meisten anderen senden deutlich weniger, da wäre manchmal öfter besser

Eben: Ein Argument  das lieber nicht mit Event-on-update-reading zu lösen.