patch um event-on-change-reading um einen threshold zu erweitern

[justme1968]

anbei ein kleiner patch der event-on-change-reading um die möglichkeit einen threshold anzugeben erweitert. das ist z.b. bei temperatur sensoren deren messwert um 0.1 grad 'zappelt' hilfreich.

der threshold wird optional mit : getrennt hinter den jeweiligen reading namen geschrieben:

Code Auswählen Erweitern

attr <device> event-on-change-reading temperature:0.5 humidity:5 pressure

in diesem beispiel erzeugen änderungen für die temperatur erst dann ein event wenn sich der wert seit dem letzten event um mindestens 0.5 grad geändert hat für die feuchte bei änderungen um mindestens 5% und beim druck wie bisher bei jeder änderung.

das zusammenspiel mit event-min-intervall ist unverändert.

ein event das durch min intervall erzeugt wurde beeinflusst die threshold berechnung nicht.

gruss
  andre

[rudolfkoenig]

Habs eingecheckt.

Falls die Herrschaften es nicht mit Zahl-Readings benutzen, dann regnet es perl-warnings, es soll mir aber recht sein.

[herrmannj]

Hi,

bitte das folgende als offene Frage zu verstehen:

Muss sowas wirklich in die Main-- fhem.pl ?

Zum Hintergrund: um Nebeneffekte zu vermeiden upgrade ich mein Produktivsystem nur bei Bedarf oder mit mehreren Monaten Abstand. Dort habe ich perfmon laufen und es ist wirklich messbar das mit jedem upgrade die Anzahl der freeze steigt - bei gleicher Config. Jedes einzelne der Features die dazukommen ist sicher (CPU) unkritisch - in der Summe scheint es sich dann wohl doch auszuwirken.

Deswegen möchte ich zur Diskussion stellen (und bin dafür) solche, vielleicht nicht ganz so essentielle Features, möglichst optional anzubieten. Möglicherweise als Modul was ja genauso funktionieren würde.

vg
jörg

[justme1968]

dieses feature kostet absolut keine zusätzliche cpu zeit wenn es nicht verwendet wird und ist ohne jegliche nebenwirkung rückwärts kompatibel.

diese art änderung die potentiell für jedes numerische reading anwendbar ist gehört genau in fhem.pl. weil dort der einzige ort ist wo es ohne overhead und dupliziertem code möglich ist. es ist auch die einzige stelle an der von vorn herein das triggern eines events bei minimalen änderunge unterbunden werden kann. unter anderem um ressourcen beim loggen, bei longpoll und in allen notifys zu sparen. wenn man das feature nutz um sensoren zu bändigen die sehr oft werte mit minimalen änderungen senden ist es eine möglichkeit die performance zu verbessern. nicht zu verschlechtern.

zumindest dieses feature ist also gerade genau das gegenteil von dem was du darin siehst.

gruss
  andre

[betateilchen]

Was mich an diesem Patch am meisten stört - und irgendwie die Integrität der fhem.pl verletzt - ist die Einschränkung auf numerische readings. Bisher war doch das Bestreben, alle Readings gleich zu behandeln. Ich kann nicht erkennen, warum eine Aufgabe dieses an sich sehr guten Grundsatzes jetzt wirklich notwendig war.

[herrmannj]

es ist ja auch keine Kritik an Deinem Versuch den Usern das Leben zu erleichtern - das ist ja absolut ehrenwert, absolut anerkannt!

Das Thema ist ja die gesamte Performance und natürlich braucht es CPU Zeit. Jeder Code code der per Verzweigung ausgeführt werden kann braucht minimal CPU Zeit, Speicher, Disk, etc. Es geht im übrigen ja garnicht um *diesen* Patch/Feature speziell. Der Patch für sich frisst sicher nicht viel CPU, der Punkt ist die Aufsummierung.

Man kann ja auch problemlos auf einen Raspi umziehen. Daher ja auch die offene Frage, schlankes fhem mit optionen oder viele Feature und zwangsläufig dann auch mehr Hardwareanforderungen ?

nix für ungut
vg
jörg

[herrmannj]

Was mich an diesem Patch am meisten stört - und irgendwie die Integrität der fhem.pl verletzt - ist die Einschränkung auf numerische readings. Bisher war doch das Bestreben, alle Readings gleich zu behandeln. Ich kann nicht erkennen, warum eine Aufgabe dieses an sich sehr guten Grundsatzes jetzt wirklich notwendig war.

ja, kommt dazu. Die Fehlermeldungen bei nicht Num-Readings (wird kommen, ich sag nur regex .*)  sollten eigentlich auch sauber aufgefangen werden. Ich vermute das andre, durchaus freundlich, Einsteigern das leben erleichtern möchte. Ich hätte mir da ein notify genommen, perl einzeiler mit user reading und gut ist. Das Problem was ich eben auch sehe ist das man Einsteigern vielleicht gar mit dieser Überfülle an optionen einen Bärendienst erweist

aber das sind eben auch nur meine 5cc
vg
Jörg

[justme1968]

ist die Einschränkung auf numerische readings

ein schwellwert macht nun mal nur bei numerischen readings sinn.

wenn kein schwellwert gesetz wird ist alles wie bisher und alle readings sind gleich. wenn es numerische readings gibt gibt es jetzt zusätzlich die möglichkeit events nicht nicht nach seit oder änderung zu unterdrücken sondern auch nach einem schwellwert.

der schwellwert wird nicht global oder pro device sondern pro reading gesetzt. und es wird keine reading auf kosten eines anderen benachteiligt. genau so wenig wie ein thermometer benachteiligt ist weil fhem in der regel kein on oder off kommando dafür anbietet.

entschuldige aber ich kann nicht sehen das irgendwo irgendetwas zu irgendeinem nachteil aufgegeben wurde.

Jeder Code code der per Verzweigung ausgeführt werden kann braucht minimal CPU Zeit

ja. das bestreitet ich nicht. es kommen in der tat auch für den fall das kein event-on-change verwendet wird eine verzweigung hinzu. das gleiche gilt für den fall das even-on-change ohne schwellwert verwendet wird. und es wird etwas speicher verbraucht.

wenn das ein problem ist dann macht es keinen sinn darüber zu diskutieren. aber ich kann dazu sagen das eine hardware bei der selbst  ein paar dutzend einfacher verzweigung probeme macht vielleicht schlicht und einfach nicht geeignet ist. die hardware wird ganz sicher schneller. code der über alle möglichen stellen verteilt und dupliziert ist wird aber nie wieder aufgeräumt.

schlankes fhem mit optionen oder viele Feature

auf jeden fall schlank mit optionen. aber wie oben schon erklärt ist dieser patch genau ein beispiel das nicht alles als modul besser ist sondern dadurch erst recht overhead erzeugt wird. schlank bedeutet manchmal auch etwas explizit zentral zu machen.

Ich hätte mir da ein notify genommen, perl einzeiler mit user reading und gut ist.

das ist aber ein absolutes no-go wenn du tatsächlich so auf die performance achtest wie oben angedeutet. du brachst weit mehr cpu resourcen und auch mehr speicher. nicht nur durch den code sondern auch durch das zusätzliche reading. davon das du plötzlich nicht mehr einfach nur temperature loggen kannst sondern einen anderen namen ganz zu schweigen. kein externer mechanismus kann den schwellwert so schlank und ohne overhead umsetzen wie ein patch in dieser art.

sollten eigentlich auch sauber aufgefangen werden

über eine bessere fehlermeldung kann man sicher diskutieren. aber ein 'Argument "xxx" isn't numeric in subtraction'  ist keine so schlechte meldung.

jemand der so weit ins system vorgedrungen ist das er versteht wie event-on-change funktioniert und die schwellwert variante probiert dem traue ich sehr wohl zu das er versteht das ein schwellwert nur bei numerischen readings sinn macht.

wenn es um die einfachheit geht gewinnt der patch aber haus hoch gegen eine lösung mit notify, user reading, anderen namen loggen, dafür sorgen das das original nicht mehr geloggt wird, plot files anpassen auf neuen namen oder sogar auf neu und alt wenn das ganze nur in manchen devices verwendet wird.

[betateilchen]

über eine bessere fehlermeldung kann man sicher diskutieren. aber ein 'Argument "xxx" isn't numeric in subtraction'  ist keine so schlechte meldung.

Du solltest inzwischen selbst wissen, dass > 95% aller fhem-User eine solche Warning nicht von einer echten Fehlermeldung unterscheiden können und ich warte schon auf die unzähligen "ich habe da eine Fehlermeldung"-Heul-Threads hier im Forum, die man mit dieser Änderung bewusst provoziert.

[justme1968]

diese ändernung provoziert keine fehlermeldung. es wird rein gar nichts passieren solange nicht jemand aktiv in die commandref schaut und das feature auch nutzt...

und einen schwellwert für ein nicht numerisches reading zu setzen ist nun mal genau so falsch wie perl und fhem kommandos zu mischen, nicht zu verstehen wie eine regex funktioniert, und und und

nichtdas davon passiert aus heiterem himmel und provoziert fehlermeldungen.

[herrmannj]

es wird rein gar nichts passieren solange nicht jemand aktiv in die commandref schaut und das feature auch nutzt...

ich dachte das wär der Soll Zustand   

[betateilchen]

es wird rein gar nichts passieren solange nicht jemand aktiv in die commandref schaut und das feature auch nutzt...

Das ist ja nun mit Abstand der größte Schwachsinn, den ich hier seit langem gelesen habe: Es wird ein Feature geschaffen und mit der Hoffnung verbunden, dass niemand es merkt...

Gehts noch?

[justme1968]

in richtung 'größter Schwachsinn' geht wohl eher so etwas:

... die man mit dieser Änderung bewusst provoziert.

und mit der Hoffnung verbunden, dass niemand es merkt...

und das absichtlich falsch verstehen kommt nicht weit dahinter.

[hexenmeister]

Ich verstehe das Problem nicht.

- Wenn einer das richtig nutzt -> keine Fehlermeldung
- Wenn einer das falsch nutzt (also mit einer ungeeigneten (=>nicht numirischen) Reading -> selber schuld und die Meldung weist ihn freundlich darauf hin
- Wenn einer das nicht nutzt -> keine Fehlermeldung.
- Wenn uns der Himmel auf den Kopf fällt -> kann man eben auch nichts dagegen machen 

Habe ich noch irgendeine Variante vergessen?

=> also, die Ändeurng ist eindeutig vorteilhaft und nicht unsauber.

[betateilchen]

=> also, die Ändeurng ist eindeutig vorteilhaft und nicht unsauber.

Nein, sie ist extrem unsauber.

Denn das Attribut, über das wir hier diskutieren, heißt "event-on-change-reading" und das bedeutet dem Namen nach "Löse einen Event aus, wenn ein Reading sich ändert" - egal wie/warum sich das Reading ändert. Diese Bedeutung ist eindeutig, verständlich und erklärbar. Von einer Möglichkeit, den auszulösenden Event nicht nur von einer Änderung an sich, sondern auch noch von zusätzlichen Bedingungen (Schwellwert) abhängig zu machen, ist aus dem Namen nichts erkennbar.

Das, was hier gebastelt wurde, gehört eigentlich in ein Attribut "event-on-threshold" - dann wäre auch das wieder dem Namen nach klar zuorden- und erklärbar.