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.

[justme1968]

gehört eigentlich in ein Attribut "event-on-threshold"

was weniger schlank und weniger gut zu erklären ist wenn man noch den vorrang der attribute untereinander berücksichtigt und an zwei stellen nachsehen muss um 'etwas was mit der änderung zu tun hat zu' konfigurieren.

wenn man genau an der stelle an der man konfiguriert ob eine änderung ein event auslöst auch konfigurieren kann wie gross diese änderung sein muss ist es nicht unsauber und schon gar nicht extrem unsauber.

und es jedem einsteiger leicht zu vermitteln.

[herrmannj]

eine gewisse Emotionalität läßt sich in solchen threads wohl nie vermeiden 

Daher nochmal zurück auf Start. Der Punkt ist: ich stelle über die Zeit (der versionen) eine messbare performance Verschlechterung (bei gleichen Bedingungen: cfg, Hardware) fest.

Das lässt sich mit der Anzahl der notifys und at messen die nicht innerhalb von 1000ms erfüllt werden und sagt erst mal nichts über die Ursache(n) aus. Ist so. Gleichzeitig ist es auch ein (Natur) Gesetz das die Anforderungen an die Rechenzeit eben mit den Features steigt die ich mit gleicher Technik umsetze. Das die Sicht Schwarz/Weiß ist weiß ich selber - trotzdem ist sie grundsätzlich gültig.

Da schließt dann eben schon der Kreis zu diesem Patch und ich frag mich: wie relevant ist das jetzt. Ich hab genau eine Anwendung wo das zum tragen käme (Sprachausgabe Temperatur,  wenn alle Jubeljahre mal die Temperatur genau um einen .0° schwankt). Nun kann es aber auch gut sein hier gleich 500 User um die Ecke springen weilsie auf genau dieses Feature gewartet haben - darum gehts aber nicht.

Wofür ich werben und sensibilisieren möchte: manchmal ist weniger mehr! Selten genutzte Features sollten optional geladen werden (müssen)!

Mag sein das genau dieses Feature dann bei wenigen usern "etwas" weniger performant läuft, bei allen anderen usern läuft fhem eben "etwas" performanter. In der Folge hoffentlich auch noch stabiler.

Dahin mein opening, es mag da ja auch völlig andere Standpunkte und Argumente geben.

vg
Jörg

[hexenmeister]

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.

Einverstanden. Das wäre (dem Namen nach) logischer. Andereseits denke ich nicht, das man hier von 'extrem unsauber' sprechen kann. Es ist eine kleine bis mittlere Sünde bezüglich der Namensgebung (und des Single Responsibility Prinzip)

Wenn man die Grenzen für jede Reading einzeln setzen können soll (müsste schon sein), müsste man bei einer 'event-on-threshold' alle readings wieder auflisten, plus die Grenzwerte. Womit wir wieder bei der jetzigen Situation wären. Auch wenn mit einem besseren Namen.

Irgendwie stecken wir in einer Sackgasse

[justme1968]

gerade wenn du die performance im auge hast ist es wichtig events so weit wie nur möglich zu verhindern.

ich denke dieser patch kann das für die vermutlich am verbreitetste art der sensoren die mit fhem im einsatz sind.

in vermutlich 95% aller fälle ist es bei den temperatur readings sinnvoll das 0.1 grad geflattert zu unterbinden. und in den meisten fällen ist sogar das auslösen von events erst bei 0.5 grad änderung ausreichend.

es gibt sicher sensoren die hier besser sind als andere aber es betrifft ganz sicher mehr als einem anwender und ein device. alleine von den LaCrosse sensoren sind ein paar 100 im
einsatz die davon profitieren. die s300ht gehen in die mehrere 1000.

das gleiche gilt für die vielen verbrauchs sensoren die inzwischen mit fhem nutzbar sind. ich behaupte niemand hat einen nutzen wenn für jedes 10tel watt ein event erzeugt wird.

ich bin ganz sicher deiner meinung wenn es darum
geht resourcen schonend zu sein wenn es möglich ist und so viel wie möglich modular und optional umzusetzen. aber genau dieser patch ist ein schlechtes beispiel für ein aufgeblähtes monolithisches system weil er sehr zentral und sparsam eine optimierung ermöglicht die an keiner nachgelagerten stelle mehr möglich ist.

dieser patch kann bei vielen Installationen viele viele events verhindern.

[herrmannj]

es gibt sicher sensoren die hier besser sind als andere aber es betrifft ganz sicher mehr als einem anwender und ein device. alleine von den LaCrosse sensoren sind ein paar 100 im einsatz die davon profitieren. die s300ht gehen in die mehrere 1000.

Die Dinger senden doch sowieso nur alle xxx Sekunden. Außerdem geh ich 'ne Wette um einen Kasten Bier ein das bei weniger als 10% davon über ein on-change .. gesetzt ist. Dagegen wird ab bald weltweit (r)  jedes  fhem event erstmal durch die Weiche "hast Du da was eingestellt" geschickt.

Und hexenmeister hat das ja auch konsequent zum "event-on-threshold" (gedanklich) weiterentwickelt und die warnings bei den strings unterdrücken - so kommt der code am ende dann eben zustande 

nachtrag:
Hier hab ich noch einen schweren Einwand:

gerade wenn du die performance im auge hast ist es wichtig events so weit wie nur möglich zu verhindern.

SO muss sich das lesen:
gerade wenn du die performance im auge hast ist es wichtig events so weit wie nur möglich zu verhindern. so schnell wie möglich zu verarbeiten.

vg
jörg

[hexenmeister]

Und hexenmeister hat das ja auch konsequent zum "event-on-threshold" (gedanklich) weiterentwickelt

Danke für die Blümen, aber das war beteteilchens Idee. *blümenstrausweiterreich*

[justme1968]

die lacrosse sensoren senden alle 4 sekunden. da kommt ganz schön was an events zusammen wenn man mehrere davon hat. erst recht weil sie das +- 0.1 grad flattern haben. das einfache event-on-change nützt als gar nichts. und mit event-min-intervall werden entweder schnelle änderungen verzögert oder viel optimierungspotential verschenkt.

das ganze auf zwei attribute aufzuteilen macht es nicht einfacher zu konfigurieren und nicht resourcen schonender.

durch dir vorrang frage schaft man sogar noch zusätzliche probleme und stolperfallen.

wirklich bedauerliche finde ich das soviel energie in diese diskussion bei einem patch mit der möglichkeit tatsächlich resourcen zu schonen gesteckt wird statt die gleiche energie in das finden von echten performance fressern zu stecken und diese zu optimieren.

gruss
  andre

[hexenmeister]

wirklich bedauerliche finde ich das soviel energie in diese diskussion bei einem patch mit der möglichkeit tatsächlich resourcen zu schonen gesteckt wird statt die gleiche energie in das finden von echten performance fressern zu stecken und diese zu optimieren.

Ich glaube, das siehst Du falsch.
Die neue Funktionalität finden wohl alle gut, es gibt nur mehrere Meinungen bezüglich der optimalen Umsetzung. Ein wenig Diskussion schadet schon nicht

[herrmannj]

statt die gleiche energie in das finden von echten performance fressern zu stecken

Na, Na ! Das ist nicht mehr als Deine Vermutung !

Ein wenig Diskussion schadet schon nicht

Genau so ist das 

Die neue Funktionalität finden wohl alle gut, es gibt nur mehrere Meinungen bezüglich der optimalen Umsetzung

Richtig ! 

Ich sperr mich gedanklich so ein wenig das sich dann alle events erstmal (auch duch diese die initiale Verzweigung schleusen müssen. Aber so langsam kommen wir doch näher. Andre ist doch gerade an dem jeelink / lacrosse Modul bei (oder). Und mit einem Hammer in der Hand sieht alles aus wie ein Nagel .

Also wenn ein lacrosse jetzt ständig flattert könnte man auch die Ursache (im Modul) beseitigen. Du könntest doch dort die 0.1° schon einfach verwerfen ?

vg
Jörg

[hexenmeister]

Also wenn ein lacrosse jetzt ständig flattert könnte man auch die Ursache (im Modul) beseitigen. Du könntest doch dort die 0.1° schon einfach verwerfen ?

Nee, da finde ich eine zentralle Lösung (sprich gleichartig für alle verfügbar) wesentlich besser. Es wäre falsch, das jedem einzelen Modul zu überlassen. Ich möchte dies z.B. auf ds18b20 loslassen.
Und ich teile auch nicht unbedingt die Sorge wegen einer Verzweigung. Es müssen schon sehr (sehr-sehr-sehr) viele davon sein, damit man das nicht nur (im Labor) messen kann, sondern auch (unter reelen Bedindungen) auch spüren kann.

so, jetzt aber gute Nacht an alle Nachtmenschen

[rudolfkoenig]

Ich fand den Patch von justme1968 sinnvoll an genau dieser Stelle, sonst haette ich es nicht eingecheckt. Ich trau mich inzwischen nein zu sagen (siehe den CUL-Patch von Martin, was ich 10 Minuten vorher abgelehnt habe). Ein neues Attribut finde ich nicht sinnvoller: es vergroessert die Liste der globalen Attribute (die ist eh schon zu lang), und intuitiver (d.h. ohne commandref zu bedienen) ist es auch nicht. An die Geschwindigkeitskritiker: bitte Zahlen vorlegen.

Generell stoert mich auch, dass FHEM dauernd groesser und komplizierter wird, aber ich glaube das ist der Schicksal von Software, die weiterentwickelt wird. Und mAn lieber lebendig und weiterentwickelt als einfach und tot.

Wenn es jemanden stoert, dass FHEM langsam ist, der soll besseren Hardware fuer die Zentrale besorgen: die Mehrkosten (Anschaffung/Strom) sollten im Verhaeltnis der Preis der Peripherie nicht wesentlich sein. Und wenn es dann immer noch langsam ist, und konkrete Zahlen vorliegen, denn werden wir das Problem optimieren. Uebrigens kann man nicht generell von "immer langsamer" reden: z.Bsp. werden seit Januar bei notifies und Filelogs, die nur Einzelgeraete beobachten, nur die Events zugestellt, die sie auch betreffen.

[betateilchen]

ich denke dieser patch kann das für die vermutlich am verbreitetste art der sensoren die mit fhem im einsatz sind.

Das ist eine sehr kühne Behauptung, die Du sicherlich nur aus Deiner eigenen Installation abgeleitet hast. Bei mir ist die Anzahl der Temperatursensoren bezogen auf alle definierten devices  unter 5%. Und 90% aller Devices liefern nicht-numerische Readings.

in vermutlich 95% aller fälle ist es bei den temperatur readings sinnvoll das 0.1 grad geflattert zu unterbinden.

Auch das ist eine sehr kühne und nicht belegbare Behauptung von Dir.

Grundsätzlich habe ich nichts gegen eine threshold Auswertung. Trotzdem gehört sie nicht in die fhem.pl - zumindest nicht so, wie das jetzt umgesetzt wurde, was ich sehr bedauerlich finde.

[betateilchen]

An die Geschwindigkeitskritiker: bitte Zahlen vorlegen.

Wo sind bitte die belastbaren Zahlen, die die Notwendigkeit des patches begründen?

[justme1968]

ganz ohne aus meiner installation irgendwelche rückschlüsse zu ziehen kannst du auf der fhem statistik seite die meist verwendeten sensoren sehen. und das sind mit weitem abstand heizung und wetter bzw tempertaur, druck, feuchte & co. das ganze multipliziert sich noch mit der tatsache das die meisten dieser sensoren oft und ungefragt senden. die sensoren mit nicht numerischen readings senden dagegen meist nur bei status änderungen.

wenn also jemand bestreiten würde das die mehrzahl aller readings in fhem numerische sind wäre er es der aus seiner installation falsche schlüsse zieht.


wenn du mir eine einzige sinnvolle verwendung für das 0.1 grad 'geflatter' nennst nehme ich meine behauptung zurück. aber ich meine hier nicht eine tatsächliche messgenauigkeit und reproduzierbarkeit von 0.1grad. darüber zu diskutieren macht nur noch ein bodenloses fass auf.

[herrmannj]

Hi,

einen patch (wie hier) auf den Prüfstand zu stellen ist das normalste der Welt, absolut legitim und total wertfrei.

Ich hatte Zweifel, daher hab ich (höflich) gefragt. Am Ende bin ich aber eher bestätigt:

der Patch adressiert eine Untergruppe von Sensoren (Thermometer, numerisch), davon eine Untergruppe (die flattern / Oregon zB "flattern" nicht), davon eine Untergruppe User die update-on-change darauf setzen. Das Performance-Gewinn-Versprechen hinterfrage ich: was passiert denn tatsächlich? Der Sensor sendet, wie gehabt, die Daten wandert in ein IO Device, werden geparst, gehen die gesamte chain durch (decodieren etc). Kurz vor der Ziellinie werden sie dann aussortiert. Dann nehm ich das Argument von Hexenmeister (single responsibility) genauso an wie die inkonsistente Umsetzung bzgl numerischer und nicht-numerischer readings.

again: das macht den Kohl nicht fett, aber um den Ball dann auch zurückzuspielen, da gibt es größere Baustellen.

just my 5cc
vg
jörg

[hexenmeister]

ich sehe die jetzige Lösung als ein (akzeptabler) Kompromis.
Nicht ganz sauber, wenn man aus einem Elfenbeinturm runter schaut
Aber auch sehr nützlich.
Also was wäre denn besser?
Gar nichts machen? Sicher nicht...
X-mal in jedem einzelnen Device/Modul implementieren? Das ist noch 'dreckiger'...

[betateilchen]

Ich hatte Zweifel, daher hab ich (höflich) gefragt. Am Ende bin ich aber eher bestätigt:
...
again: das macht den Kohl nicht fett, aber um den Ball dann auch zurückzuspielen, da gibt es größere Baustellen.

*unterschreib*

(und es gibt wichtigere Baustellen, bei denen sich Änderungen wirklich "lohnen" würden!)

[justme1968]

hallo rudi,

du hattest in meinen ursprünglichen patch noch ein zeile eingebaut die den value auf zahlen beschränkt:

Code Auswählen Erweitern

$value =~ s/[^\d\.\-]//g; # We expect only numbers here.dies führt in manchen per versionen dazu das $1 aus der regex davor die den threshold wert extrahiert zurück gesetzt wird und der threshold nicht greift.

der folgende kleine patch behebt das problem:

Code Auswählen Erweitern

--- fhem.pl 2014-11-03 19:32:14.000000000 +0100
+++ fhem.pl 2014-11-03 19:32:22.000000000 +0100
@@ -3653,12 +3653,13 @@
     my $threshold_reached = 1;
     if( $eocr
         && $eocrv[0] =~ m/.*:(.*)/ ) {
+      my $threshold = $1;

       $value =~ s/[^\d\.\-]//g; # We expect only numbers here.
       my $last_value = $hash->{".attreocr-threshold$reading"};
       if( !defined($last_value) ) {
         $hash->{".attreocr-threshold$reading"} = $value;
-      } elsif( abs($value-$last_value) < $1 ) {
+      } elsif( abs($value-$last_value) < $threshold ) {
         $threshold_reached = 0;
       } else {
         $hash->{".attreocr-threshold$reading"} = $value;


da würde einige anwender glücklich machen

[rudolfkoenig]

Na dann will ich mal nicht im Weg stehen: habs eingecheckt.