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

[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