"Anfängerfrage" ist ggf nicht ganz das richtige Unterforum, wusste aber nicht wohin damit.
Ich lasse FHEM auf einer recht betagten HW laufen. Gleichzeitig ist die config in den Jahren doch recht umfangreich geworden, was dazu führt, dass die Ausführungen machmal mit Verzögerungen einhergeht, wir reden hier von Sekunden.
Schon seit einiger Zeit beschäftigt mich der Gedanke, ob man die Anzahl der notifies und der Bedingungen darin nicht reduzieren könnte, um die Performance zu erhöhen.
Ich meine z.b. folgendes: Die Heizungsventile werden in überwiegend in Abhängigkeit von der Raumbelegung gesteuert, diese wird mit Bewegungsmelder ermittelt. Grundsätzlich werden also nur Räume geheizt, in denen jemand ist.
Das sieht in etwa so aus:
define Wohn_unten_nutzung_on notify PIRA_Wohn_unten:on.* { if(($hour < 3 || $hour >= 7) && Value("Tuer_Wohn_u") ne "Open") { fhem ("<heizung regeln>) ") } }
Wie man sehen kann, wird bei jeder Auslösung des PIRA bereits Kram getestet, hier wieviel Uhr es ist und ob nicht etwa die Eingangstür offen ist.
Das bedeutet, dass bei jeder Raumbewegung ein notify plus perl if/else mit 2 Bedingungen durchlaufen wird. Wenn man DOIF verwendet, dürfte der tatsächliche Load sogar noch höher sein, da DOIF letztlich auch perls if verwendet ,nur mir zahlreichen Komfortfeatures drumherum.
Ein andere Lösung wäre aber das define selbst zu verändern, per define im define und delete oder per defmod.
Ich könnte z.b. jeweils mit erreichen von 07:00 Uhr
define Wohn_unten_nutzung_on notify PIRA_Wohn_unten:on.* { if(Value("Tuer_Wohn_u") ne "Open") { fhem ("<heizung regeln>) ") } }
definieren, und dieses um 03:00 Uhr löschen.
Ebenso könnte ich das Event Tuer_Wohn_u Open dazu verwenden, das Define zu löschen, und wenn die Tür wieder Closed wird, das Define wieder anlegen, dann könnte das sogar auf
define Wohn_unten_nutzung_on notify PIRA_Wohn_unten:on.* <heizung regeln>
reduziert werden, also ganz ohne if abfrage,
Tatsächlich gäbe es das define nur, wenn es auch tatsächlich etwas auslösen würde, im Rest der Zeit würden Bewegungsmelder events einfach kein notify auslösen.
Die Frage ist nun folgende: Was ist in der Ausführung schneller? Die .cfg wird durch die 2te Methode garantiert deutlich grösser, da das "define Wohn_unten_nutzung_on..." ja nun mehrmals vorkommen wird. Gleichzeitig werden die if-abfragen, ja sogar die notifys selber aber deutlich reduziert.
Wenn ich das konsequent für alle events/notifis die if-abfragen auslöse umsetze , also in allen Fällen wo die events häufig aber die Werteänderung der per if abzufragenden Parameter eher selten sind, (nur am Sonntag, nur wenn das Gästezimmer belegt ist, nicht nachts, nur im Winter, nur wenn es Tag ist, es sei den die Alarmanlage ist an etc etc.) wächst meine .cfg sicher um 200% oder so an und würde sicher auch komplexer. Gleichzeitig würde die Anzahl der "aktiven" notifies von aktuell über 100 und vor allem der if-Prüfungen deutlich sinken.
Abstrakt:
was ist in der Ausführung schneller
define irgendwas notify a:on { if(b) eq on) { fhem ("<mach was>)" } }
(bzw. dessen DOIF Equivalent) oder
define erzeuge_irgendwas notify b:on define irgendwas notify blubber:on mach was
define loesche_irgendwas notify b:off delete irgendwas
für alle Anzahl Werteänderung a > Werteänderung b
(bitte Nebenbedingungen wie Werte für a oder b könnten auch andere sein als on/off ignorieren - ist nur ein vereinfachtes Beispiel)
Klar, ich könnte auch für 50€ ein RasPi kaufen, also CPU auf das Problem werfen, werde ich sicher auch bald machen. Ich finde die Frage aber trotzdem interessant.
ich hab mal vor Jahrzehnen gelernt: ne ist schneller als eq
IOs schlimmer als ein bißchen vergleichen. ==> also auch define, defmod, delete....
Und ja, notifys reduzieren dürfte immens helfen, weil je event immer ALLE notifys(Regexp) geprüft werden.
Und ich vermute die Vielzahl von events tut sein übriges(notify-Loop, Logging[IO]). Also lieber mal timer(interval) etwas höher setzen, event-on.....
ZitatWenn man DOIF verwendet, dürfte der tatsächliche Load sogar noch höher sein
sehe ich auch so.
Zitatkönnte auch für 50€ ein RasPi kaufen, also CPU auf das Problem werfen
Nö. Ist zwar einfacher, aber Optimierung halte ich für den besseren Ansatz, sonst ist schnell das nächste upsizing fällig.
Alles nur meine Meinung u. Theorie. ::)
Zitat von: KölnSolar am 26 Dezember 2020, 19:02:47
ich hab mal vor Jahrzehnen gelernt: ne ist schneller als eq
Interessant, damit kann man ja schon mal was machen. Im Grunde sogar nachvollziehbar.
ZitatIOs schlimmer als ein bißchen vergleichen. ==> also auch define, defmod, delete....
Hm. Klar, aber die Frage ist ob das ein echtes Gegenargument: Wenn ich 10x am Tag IO wegen Umschreiben habe, hauen die statistisch und speziell im dem Moment wo's passiert ordentlich rein. Aber den Rest der Zeit könnte FHEM sich schon responsiver verhalten.
Überspitzt formuliert: Was ist schlimmer: 20x am Tag 5 Sekunden Verzögerung (und auch nur dann wenn man die 100 Sekunden am Tag genau trifft) aber ansonsten nur 1 Sekunde, oder den ganzen Tag über immer 2-3 Sekunden bei allen Operationen.
ZitatUnd ja, notifys reduzieren dürfte immens helfen, weil je event immer ALLE notifys(Regexp) geprüft werden.
Eben, das war der Grundgedanke, weiss eben nur nicht, ob es da nicht noch ander Dinge zu bedenken gibt. IO ist sicher so eine "anderes" Thema.
ZitatUnd ich vermute die Vielzahl von events tut sein übriges(notify-Loop, Logging[IO]). Also lieber mal timer(interval) etwas höher setzen, event-on.....
Das mache ich sowieso, ich will nicht sagen, dass ich das alles optimal habe, aber ich habe schon ein wenig Gehirnschmalz reingesetzt, die events gering zu halten. Das fängt wo es geht schon bei den Sendeintervallen der Sensoren an. Überlege aber gerade: Loglevel bzw. vielmehr verbose könnte ich noch überall runterdrehen. Danke für die Idee.
ZitatNö. Ist zwar einfacher, aber Optimierung halte ich für den besseren Ansatz, sonst ist schnell das nächste upsizing fällig.
Ja, genau.
Danke schon mal.
Ich habe ja hier ähnlich schon auf eine ähnliche Frage geantwortet ;)
https://forum.fhem.de/index.php/topic,117062.msg1114195.html#msg1114195
Bzgl. ne: aber aufpassen, oft ist ne "DasWillIchNicht" weil oft kommt ein "DasWillIchNicht" dazu (Events ändern sich: Beispiel Homematic vor einiger Zeit) und dann kann das auch mal schnell "nach hinten losgehen" ;)
(Gut bei "DasWillIch" auch aber eher nicht so "nebenher" weil es sollte ja alles was ich "damals" wollte ich immer noch wollen ;) )
Gruß, Joachim
Hi,
die Beispiele oben sehen gut aus, aber vielleicht trotzdem mal nach "nicht optimierten " Suchmustern schauen.
https://forum.fhem.de/index.php/topic,115414.msg1096774.html#msg1096774
Schöne Weihnachten
Otto
@Zrrronggg!, ohne jetzt gleich an die notifys und andere Logik zu gehen :
Ich mache oft einfach nur den Event Monitor auf und lasse ihn eine Weile laufen, dabei achte ich auf "Vielschwätzer"
Frei nach dem Motto musste der jetzt schon wieder das und das unbedingt als Event raushauen ?
Klar event-on-change-reading ist ein gutes Schweizer Messer, aber es gibt auch Fälle wo der Modulautor nicht ganz unschuldig ist und das sollte man dann im passenden Thread auch ansprechen.
ZitatHm. Klar, aber die Frage ist ob das ein echtes Gegenargument: Wenn ich 10x am Tag IO wegen Umschreiben habe, hauen die statistisch und speziell im dem Moment wo's passiert ordentlich rein. Aber den Rest der Zeit könnte FHEM sich schon responsiver verhalten.
Überspitzt formuliert: Was ist schlimmer: 20x am Tag 5 Sekunden Verzögerung (und auch nur dann wenn man die 100 Sekunden am Tag genau trifft) aber ansonsten nur 1 Sekunde, oder den ganzen Tag über immer 2-3 Sekunden bei allen Operationen.
Das ist mir zu viel Theorie für komplexes FHEM.
Ich denke, ein paar Grundregeln beachten reicht.
Und dann mit freezemon die Bösewichte ausfiltern.
Edit: Wzut war flotter und ich kann ihm nur zustimmen. In der Regel wird für jedes readingsupdate ein event rausgehauen.
event-on-change lässt sich im Modul realisieren, wird aber seltendst(nur von mir ? :-\ ;D) genutzt.
Na ja, ob man es im Modul einbaut oder der User filtert, macht schon einen Unterschied; wenn ich das richtig verstanden habe, kann die Entscheidung eines Maintainers, trigger auf 0 zu setzen nicht vom User "overruled" werden, von daher beschränke ich das auch eher auf die ganz eindeutigen Fälle; jetzt bin ich aber sensibler für single-updates vs. bulk und versuche eher letzteres einzusetzen.
Was Optionen auf User-Seite angeht:
- bei dem MQTT-Kram kann man schauen, ob sich die "report"-Zeiten sinnvoll einschränken lassen; grade bei den Shellys kann man periodische Updates schon auf der Firmware-Ebene ganz unterdrücken, dann braucht man weniger event-on... ;)
- Bei den attrTemplate für Tasmota hatte ich auch mal versucht, das einigermaßen einzudämmen, allerdings bin ich nicht sicher, ob das noch dem aktuellen Stand der fimwares entspricht...
- devspecs anschauen ist auf alle Fälle eine gute Idee. Hilfsmittelchen:count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
- FHEMWEB-Aktionen in den Hintergrund schickten (plotfork&Co) ist sicher auch eine gute Idee (seit neuestem wohl default).
- Ganz grundsätzlich habe ich auch immer den Verdacht, dass speziell Netzwerkprozesse auch immer einen Extra-Blick wert sind. Siehe die aktuelle PRESENCE-Diskussion (sonos ist auch so ein Thema). Ggf. lohnt es sich, für "schwierige Fälle" ein separates FHEM aufzuziehen?
Zitat von: MadMax-FHEM am 26 Dezember 2020, 19:36:14
Ich habe ja hier ähnlich schon auf eine ähnliche Frage geantwortet ;)
https://forum.fhem.de/index.php/topic,117062.msg1114195.html#msg1114195
Danke, die Frage ist *ähnlich*. Zwar ist meine Frage auch allgemein performancegetrieben, aber ich habe eine konkrete Idee im Kopf, zu der ich hoffte Meinungen zu bekommen. Dein Post enthält eher andere (auch nützliche) Vorschläge, allgemeinen Perrformanceproblemen zu begegnen, werde ich mir auch alle ansehen. Die meisten Themen davon würde ich für mich aber als "hab ich schon richtig" abhaken, ausser event-on-change ...
Konkret war die Frage vor allem, ob man modulierende Zustände (es ist Tag, Wochenende, August, kälter als X) besser on notify per if abfragt oder zum Anlass nimmt, mit defmod etc die Defines die notified werden moduliert. Das letzteres IO erzeugt ist schon mal ein einschränkender Parameter, den man in Betracht ziehen muss.
ZitatBzgl. ne: aber aufpassen, oft ist ne "DasWillIchNicht" weil oft kommt ein "DasWillIchNicht" dazu (Events ändern sich: Beispiel Homematic vor einiger Zeit) und dann kann das auch mal schnell "nach hinten losgehen" ;)
Jo, das ist klar.
So oder so: Danke für eure Antworten bisher. Übrigens läuft meine Installation an sich gut, ich habe nur das Problem, dass manchmal vom Event bis zu ausgelösten Aktion 3-4 Sekunden vergehen. Ist also noch kein echtes Problem.
Was das Ändern an der config im laufenden Betrieb angeht, bin ich persönlich eher sehr vorsichtig - das wäre mir schlicht zu unübersichtlich aufzupassen, ob es "Nebenwirkungen" hat, wenn ich irgendwo anders was umbaue...
An sich sind ein paar if-Abfragen vermutlich auch nicht das Problem, und wenn "Hänger" nur sporadisch auftreten, ist das eher irgendein parallel laufendes Ding oder z.B. ein nur unter bestimmten Umständen auftretendes Funkthema.
Zitat von: Beta-User am 26 Dezember 2020, 21:31:16
Was das Ändern an der config im laufenden Betrieb angeht, bin ich persönlich eher sehr vorsichtig - das wäre mir schlicht zu unübersichtlich aufzupassen, ob es "Nebenwirkungen" hat, wenn ich irgendwo anders was umbaue...
Das sehe ich bisher auch als grösste Gefahr.
ZitatAn sich sind ein paar if-Abfragen vermutlich auch nicht das Problem, und wenn "Hänger" nur sporadisch auftreten, ist das eher irgendein parallel laufendes Ding oder z.B. ein nur unter bestimmten Umständen auftretendes Funkthema.
Nee die treten immer auf, es ist ein generelle Verzögerung, daher gehe ich davon aus, dass FHEM so ein wenig an irgendeiner Grenze läuft
Allerdings: LOAD hat die Kiste nicht echt. Und Netzproblem soweit ich das bisher gesehen habe auch nicht und HMLANs sind auf loadLvl low.
msgParseDly steht aber beibeiden HMLANs auf bis zu 6000 ms, das ist recht hoch.
Na ja, wenn es dauert, die Nachrichten erst mal an das IO zu bringen, würde ich tendenziell wohl da mal ansetzen...
Falls du noch was anderes (ZigBee, WLAN-Gedöhns...) im Einsatz hast, wäre ja die spannende Frage, ob es da ähnlich ist? Wenn nein, suchst du innerhalb des FHEM-Codes wohl an der falschen Stelle.
Load, also Belastung oder gar "Überlastung" muss nicht der Grund sein für Verzögerungen.
Auch das Warten (z.B. Netzwerk, wurde ja schon angesprochen) führt zu Verzögerungen, wenn es "blocking" implementiert ist (ohne Hintergrund-Fork)...
Da ist "load" praktisch "Null"...
Da wäre evtl. Freezemon hilfreich...
Gruß, Joachim
ZitatFalls du noch was anderes (ZigBee, WLAN-Gedöhns...) im Einsatz hast, wäre ja die spannende Frage, ob es da ähnlich ist? Wenn nein, suchst du innerhalb des FHEM-Codes wohl an der falschen Stelle.
Naja, paar CULs. für SlowRF, IT und so weiter. Da ist das Bild überall gleich.
Und die sind per USB angebunden, was gegen Netz spricht. Netz hab ich zumindest mal oberflächlich angesehen mit WireShark, da ist meist nix los.
Richtig tief hab ich da aber noch nicht gebohrt.
Und es korreliert eben mit dem Wachstum des Zoos. Die Verzögerung wächst immer weiter, je mehr Geräte und notifies ich einführe. Kann Zufall sein.
ZitatLoad, also Belastung oder gar "Überlastung" muss nicht der Grund sein für Verzögerungen.
Klar. Nur treten die Problem eben auch bei nicht mit dem Netz verbunden Schnittstellen/Geräten auf - ja ich weiss muss nix heissen.
Ich such auch an allen Fronten. Oder auch wieder nicht, denn ein echtes Problem ist es noch nicht.. Wir bewegen uns hier auch im akademischen Raum, die Installation funktioniert an sich gut - seit Jahren. Nur je mehr sie wächst desto langsamer wird sie, obwohl FHEM mit Mühe und Not mal auf 25% CPU kommt und der Rest überwiegend idl ist. Ich bin schon froh wenn FHEM mal mehr CPU zieht als TOP selbst. Eher noch ist Mem ein Problem, da werden für fhem auch mal 40% fällig. Die Kiste (Linkstation mini) ist schon recht klein und mein Verdacht ist, das IRGENDEIN RasPi das Thema sofort löst.
Egal, ich kaue jetzt erstmal auf den diversen Tips rum, speziell eine flottes event-on-change-reading .* bei den top-geschwätzigen Dingern hab ich gerade einfach mal eingefügt und dann mal sehen, ob das was ändert. ggf ist das Schreiben des Logfiles schon das Thema.
Guten Morgen.
auch mein System wurde mit der Zeit und der Größe der config immer zäher, auch geschuldet dem Umstand, dass ich eher neue Dinge eingebaut/probiert habe als mich um die (vermeintlich) laufenden Sachen zu kümmern. Teilweise uralte Definitionen aus meinen Anfangstagen mit fhem. Ich habe gefühlt das Internet durchgelesen ;) auf der Suche nach brauchbaren Informationen. Das Problem waren auch "Hänger" von ein paar Sekunden, aber durch nichts (freezwmon/apptime...) einem bestimmten Ereignis zuzuordnen.
Was bei mir geholfen hat: Ich habe sämtlich Logs überprüft und nahezu alle auf Wochenlogs umgestellt -%Y-%W.log sowie mit nrarchive auf 4 logs begrenzt. Weiterhin habe ich alle Devices auf events abgeklopft und mit event-on-change-reading und event-min-interval auf das Nötigste reduziert. Aus meiner Anfangszeit waren viele Log-Definitionen noch so, dass ich im Log per Regex angegeben habe, was gelogged werden soll. Die dazugehörigen Devices haben aber alle Events gefeuert, die sie hatten. jetzt sind diese per event-on-... reduziert und die Log-Definition zeichnet alles auf (.*).
Prima geholfen hat DOIF-Tools https://wiki.fhem.de/wiki/DOIFtools (https://wiki.fhem.de/wiki/DOIFtools). Klingt erst mal nach "nur zu brauchen wenn ich DOIF nutze", was ja bei einigen schon fast glaubensmäßig abgelehnt wird, ist aber ein prima Tool, um eine Übersicht zu bekommen, was wie viele Events erzeugt und welche Module event-on... Beschränkungen haben oder nicht. Einfach mal "set doStatistics enable" anklicken und ein paar Stunden/Tage mitlaufen lassen. Per "get statisticsReport" gibts dann ein nach TYPE sortiertes Ergebnis und diverse andere Informationen. Devices/Module die viele Events erzeugen lassen sich damit sehr schön erkennen.
Viel Erfolg!
Das Problem hierbei dürfte tatsächlich die Linkstation Mini sein. Da auch der Hersteller immer mehr Funktionalität in seine Firmware packt und die I/O-Bandbreite sehr begrenzt ist, behindern sich die diversen Lese- und Schreibvorgänge auf die Peripherie gegenseitig. Die CPU ist also weitestgehend unschuldig.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 27 Dezember 2020, 11:57:25
Das Problem hierbei dürfte tatsächlich die Linkstation Mini sein.
Ja, ich fürchte auch. Das Teil ist ja in sich selber schon recht betagt.
Zitat von: Sany am 27 Dezember 2020, 10:08:40
... Klingt erst mal nach "nur zu brauchen wenn ich DOIF nutze", was ja bei einigen schon fast glaubensmäßig abgelehnt wird ...
Zu DOIF (off Topic) : Ich lehne das nicht ab, ich benutze es nur nicht. Das hat historische Gründe, als ich anfing gab's das schlicht noch nicht.
Ich bin bisher noch an nichts vorbei gekommen, was ich machen wollte und mit "perl-if" nicht auch ging. Daher hatte ich einfach keinen Bedarf das doch recht mächtigen DOIF zu "erlernen". Und das "erlernen" könnte mühsam sein: Ich habe direkt am Anfang mal mitbekommen, dass - für mich total unintiutiv - ohne weiteres ein Event das die Bedingung erfüllt nicht mit jedem Eintritt das Ereignis auslöst sondern nur das erste mal. Ich habe verstanden, dass man das mit irgendeinem Attribut a la "always" oder so ändern kann. Aber mein Problem ist, dass meine Denke genau andersrum wäre: Wenn Bedingung erfüllt, mach es. Jedes mal. Wenn es nur 1x sein soll, dann könnte man einen Parameter einführen ... Der umgekehrte Pfad mag eine Berechtigung haben, klingt für mich aber erstmal absurd.
An sich kein Problem, lässt mich aber befürchten, dass in DOIF noch mehr so Dinge schlummern, wo DOIF sich total anders verhält als ich es erwarten würde. Daher erwarte ich eine steile Lernkurve - die ich zugegeben scheue.
Wenn ich mal was brauche, was mit DOIF super einfach zu lösen ist und ansonsten nur kompliziert oder gar nicht, sehe ich mir DOIF sicher an.
(Im Moment sehe ich hier im Forum aber eher das Gegenteil: komplexe "Lösungen" mit DOIF, für die es aber an sich viel einfachere Lösungen ohne DOIF gibt.)
Das die DOIFtools auch ohne DOIF Nutzung sinnvoll sein könnten habe ich aber kapiert ;-)
ZitatIch könnte z.b. jeweils mit erreichen von 07:00 Uhr [...] definieren, und dieses um 03:00 Uhr löschen.
Oder man setzt disabledForIntervals (https://fhem.de/commandref_modular.html#disabledForIntervals)
Das macht es nicht performanter, nur einfacher zu lesen.
Zitatwas ist in der Ausführung schneller
Haengt davon ab, wie haeufig b oder a sich aendert.
Ein define erzeugt ein zusaetzliches Event, genauso wie ein delete, also am besten meiden.
Die if Abfrage innerhalb eines perl Evals duerfte schneller sein, als zwei NotifyFns der Reihe nach aufzurufen.
Viel wichtiger in diesem Zusammenhang ist NOTIFYDEV, wie Beta-User das erwaehnt hat.
fhem.pl benachrichtigt fuer ein Event vom Geraet XXXX alle NotifyFns (d.h. notify, FileLog, sequence, watchdog, DOIF, etc), die im NOTIFYDEV XXXX aufgefuehrt haben, und alle ohne ein NOTIFYDEV.
Im Idealfall haben alle NOTIFYDEV, dann wird niemand "sinnlos" aufgerufen, im Worst-Case (bei keinem der Instanzen ist NOTIFYDEV gesetzt) werden alle Instanzen fuer alle Events aufgerufen.
Kuerzlich hatten wir ein System mit ca 1000 NotifyFns, und 100 Events/Sek: im Idealfall (s.o) hat man 100 Funktionsaufrufe/sec, im Worst-Case 100 tausend.
Das alles ist dann relevant, wenn die CPU ausgelastet ist.
Die Groesse von FileLogs ist irrelevant, es sei denn, man will Grafiken haben, die Daten aus mehreren Dateien ziehen muessen.
Die Anzahl der alten Filelogs ist nur wg. Plattenplatz relevant, nicht aber aus Performance-Gruenden.
Viele Events können schon das System recht träge machen, da lohnt der Blick in den Event-Monitor.
Im Laufe der Zeit kann sich da einiges ansammeln. Ich war erschrocken, als ich bei mir feststellen musste, dass der Event-Monitor nur so durchlief und keine Eventpausen mehr zu sehen waren.
Nach meinen Messungen belastet ein Event das System zig-mal mehr, als das Schreiben eines Readings ohne Event.
Ich habe mir daraufhin das Leben einfach gemacht und einfach mit:
attr .* event-on-change-reading .*
viele Events erstmal stillgelegt.
Das System wurde sofort reaktionsschneller.
An zwei Stellen musste ich dann noch event-min-interval setzen, damit wichtige Temperaturen nicht zu lange ausblieben.
Leider gibt es immer noch unwichtige Events, die ich nicht unterbinden kann.
Leider sind einige Module sehr gesprächig - offenbar wussten die Autoren es nicht besser und haben es zu gut gemeint.
Ich würde mir ein no-event-Attribut (für alle Module) wünschen, um Events bewusst in solchen Fällen unterbinden zu können.
Pauschale Aktionen wie "event-on-... .* " sehe ich eher skeptisch, v.a., wenn man sich irgendwo "versehentlich" doch mal Gedanken gemacht hatte, wie es "passend" ist.
Erschreckend finde ich eher, wie "stressfrei" viele User damit umgehen, dass manche Geräte (und evtl. auch Module) FHEM mit Events (und teils Logeinträgen) "fluten", ohne dass irgendein Mehrwert erkennbar wäre. V.a. im MQTT-Umfeld kann man sich manchmal nur die Frage stellen, ob irgendwer auch nur eine Sekunde nachgedacht hat, als er die Schnittstelle designed hat... (Beispiel: Wie kommt man auf die Überlegung, dass irgendwen die (unveränderte) WLAN-SSID alle 5 Sekunden interessierten könnte)?!?
Von Userseite wird das aber dann nicht hinterfragt, sowas bekommt man dann teils erst Monate später mehr oder weniger zufällig mit... Hähhh!?!?!
Sowas wird dann durch eocr .* einfach zugedeckt - eigentlich sollte man den Hersteller kontaktieren und einen Teil seines Geldes zurückverlangen oder das Ding gleich zurückschicken! Wer an der Stelle so einen Unsinn treibt, steht stark im Verdacht, (mindestens!) softwareseitig eventuell auch sonst irgendwas irdendwie hingepfriemelt zu haben...
patches (für "gesprächige" Module) könnte man ja durchaus anderen Maintainern liefern, wenn man mag. (Oder auch einfach nur erst mal Fragen zur "Informationspolitik" stellen, manchmal ist es ja in der Tat nur eine Kleinigkeit, das Meldeverhalten insgesamt umzustellen oder wenigstens von single- auf bulk-update...).
Zitat von: Damian am 28 Dezember 2020, 00:33:39
Leider gibt es immer noch unwichtige Events, die ich nicht unterbinden kann.
Leider sind einige Module sehr gesprächig - offenbar wussten die Autoren es nicht besser und haben es zu gut gemeint.
Ist mir selbst schon passiert beim Modul schreiben/testen, inzwischen "verstecke" ich diese Events/Readings hinter einem debug Attribut.
Im Problemfall zur Fehlersuche hat man sie dann schnell zur Hand aber im Normalbetrieb fehlen sie.
Zitat von: Beta-User am 28 Dezember 2020, 06:40:54
patches (für "gesprächige" Module) könnte man ja durchaus anderen Maintainern liefern,
IMHO muss es nicht unbedingt gleich ein Patch sein, man sollte einfach die betreffenden Autoren direkt darauf ansprechen.
Ich denke, ich werde mal einen Patch für ein "no-Event"-Attribut in fhem.pl vorschlagen.
ZitatIch denke, ich werde mal einen Patch für ein "no-Event"-Attribut in fhem.pl vorschlagen.
"attr xx event-on-update-reading ," oder "attr xx event-on-change-reading ," duerfte die gleiche Wirkung haben.
Zitat von: rudolfkoenig am 28 Dezember 2020, 10:33:58
"attr xx event-on-update-reading ," oder "attr xx event-on-change-reading ," duerfte die gleiche Wirkung haben.
Stimmt, beim Update muss man dann nur umdenken:
event-on-update-reading blablabla
tut's schon :)
aber nur dann wenn man nicht an ein Modul hat wo der Autor der Meinung war vor jedem Durchlauf alle Readings ins Nirwana schicken zu müssen und dann alle komplett neu zu betanken .... Ohne Frage gibt es Anwendungen wo dieses Vorgehen zum Teil sinnvoll ist (ich selbst mache das bei meinem MPD Modul bei einem Titelwechsel das alte Readings gelöscht werden, weil die Neuen zum Teil weniger Informationen haben als die Alten) aber ich hatte auch schon Module in der Hand wo über 30 Readings jedesmal im Event Monitor aufgeschlagen sind.
@Zrrronggg!
ZitatZu DOIF (off Topic) : Ich lehne das nicht ab, ich benutze es nur nicht. Das hat historische Gründe, als ich anfing gab's das schlicht noch nicht.
da warst Du gar nicht gemeint, es sollte nur "unterstützen" die DOIFtools unabhängig von DOIF als Werkzeug zu nutzen.
ZitatDas die DOIFtools auch ohne DOIF Nutzung sinnvoll sein könnten habe aber kapiert ;-)
hat ja geklappt :)
@rudolfkoenig
ZitatDie Groesse von FileLogs ist irrelevant, es sei denn, man will Grafiken haben, die Daten aus mehreren Dateien ziehen muessen.
gibt es da so etwas wie "best practice"?
Also z.B. wenn Daten von mehreren Devices in einem SVG-plot dargestellt werden sollen dann alles in einem gemeinsamen log aufzeichnen? Kann man Aussagen treffen, ab wann die Größe des Logs sich "schädlich" auswirkt, wenn man mehrere Logs in einem SVG-plot auswertet? Hat es einen Einfluss, ob im SVG-plot Daten direkt dargestellt werden (z.B. temperature Wert) oder noch "behandelt" werden ($fld[2]=~"open"?1:0)?
Ich denke, wenn es da Auswirkungen gibt, dann vermutlich auch abhängig von der gesamten Anzahl an plots. Also vermutlich gar nicht so pauschal zu beantworten, aber vielleicht gibts ja doch Größenordnungen, an denen man sich orientieren kann.
@Sany Ich werfe mal meine Erfahrung mit ein:
Es wird langsamer dargestellt wenn:
Mehr Daten pro Zeiteinheit vorhanden sind als die Auflösung überhaupt erfordert
Wenn berechnet werden muss
Wenn Daten zerpflückt oder umgewandelt werden müssen
Wenn Daten aus mehrere Dateien zusammengesucht werden
Die Darstellungsgeschwindigkeit ist abhängig von der Anzahl Plots auf einer Seite.
Interessant ist vielleicht auch, dass der Umstieg von Filelog auf eine Datenbank sich nicht positiv auf die Geschwindigkeit auswirkt (gleiche Hardware Vorrausetzungen). Es kann sich sogar negativ auswirken.
Das typische Homematic Logging T:19 H:56 spart Platz im Logfile und ist nicht langsamer in der Darstellung gegenüber dem getrennten Log obwohl die Daten aus der Zeile "geteilt" werden müssen.
Die Auswertung des Konstruktes "T:19 H:56 " aus einer Datenbank ist wesentlich langsamer als die Auswertung von getrennten Werten temperature:19 und humidity:56 .
Zitat von: Sany am 29 Dezember 2020, 09:26:01
@rudolfkoeniggibt es da so etwas wie "best practice"?
Da ich die Frage vor kurzem auch gestellt hatte, hier die dortige Antwort (soweit über den hier schon mehrfach diskutierten Aspekt: Events reduzieren hinaus relevant):
Zitat von: rudolfkoenig am 17 Dezember 2020, 20:20:09
ZitatIst es jetzt geschickter, die state-Events mitzuschneiden (und den Rest nicht), oder besser die Einzelwerte?
Etwas vereinfacht skaliert der Aufwand im FileLog mit Anzahl der vorhandenen (d.h. ungefilterten) Spalten(!) im fraglichen Bereich.
Der Aufwand im SVG skaliert mit Anzahl der anzuzeigenden Werte.
D.h. optimal ist ein separates FileLog pro Linie, was nur die Wertspalte enthaelt, zusaetzlich zum Zeitstempel und Geraet. Die naechstbeste Loesung ist alle benoetigten Werte auf einer Zeile zu haben, moeglichst ohne ueberfluessige Spalten. [...]
Nach den zahlreichen Beiträgen hier habe ich für mich meine Grundüberlegung beerdigt und bin dazu übergegangen mit attr xx event-on-change-reading zu arbeiten. Dazu brauche ich eigentlich nichtmal Tools, wenn ich info timer im Telnet aufmache rauschen bei mir auch die Events nur so vorbei und wenn man sieht das jetzt zum 4x gemeldet wird, das das Ventil im Gästezimmer noch zu ist, die Batterie noch gut, und die Luftfeuchte immer noch 60% ist ...
Inzwischen habe ich sogar schon mal 15 Sekunden, wo NIX an Meldungen kommt.
Ich habe auch nachteilige Effekte befürchtet und mach das daher recht langsam Schritt für Schritt und ergänze bei Readings für Graphen event-min-interval.
Das klappt bisher ganz gut.
Das die Grösse des Logs an sich egal ist war mir klar, nur mehr Daten im Log heisst ja auch, das die mal da rein geschrieben werden müssen, also IO.
disabledForIntervals hatte ich nicht auf dem Schirm. Wird ja letztlich auch nur ein verdecktes perl if sein, aber es würde bei mir zumindest so mache komplexere Bedingung vereinfachen, indem es Abfragen nach Zeiten quais auslagert. Also wie Rudi sagt: Einfacher zu lesen.
Das werde ich daher auch einsetzen.
Mit NOTIFYDEV werde ich mich auch mal befassen, aber soweit ich das verstanden habe, kann ich das ja nicht echt beinflussen, da das ja wohl bei der Modulerstellung gemacht werden muss, oder hab ich das falsch verstanden?
Zitat von: Zrrronggg! am 29 Dezember 2020, 22:54:09
Mit NOTIFYDEV werde ich mich auch mal befassen, aber soweit ich das verstanden habe, kann ich das ja nicht echt beinflussen, da das ja wohl bei der Modulerstellung gemacht werden muss, oder hab ich das falsch verstanden?
Hast Du mit der Wahl Deiner Suchmuster beim notify voll in der Hand.
device:(on|off) nicht optimal - kein NOTIFYDEV
device:o[nf]+ optimal - NOTIFYDEV
device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV
Zitat von: Otto123 am 29 Dezember 2020, 23:22:13
device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV
Jetzt hab ich das auch verstanden :)
Danke, Joachim
Zitatdevice:o[nf]+ optimal - NOTIFYDEV
device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV
Warum ist device:on|device:off exakter ? Woran erkennt ihr jetzt den Unterschied der beiden Definitionen, in NOTIFYDEV steht doch bei beiden "device".
o[nf]+ matched auch auf onnn onnnnnfffff onfnfnfn usw. :)
ich weiß kommt nicht vor :) nur theoretisch.
Ich würde NOTIFYDEV nicht überbewerten. Meine Untersuchungen haben gezeigt, dass man mit NOTIFYDEV ca. 30 % Systemlast (im DOIF) einspart (https://forum.fhem.de/index.php/topic,103401.msg971224.html#msg971224), ein eingespartes Event bringt dagegen ca. 99 % Einsparung und das nur beim Schreiben des Readings also ohne Folgekonsequenzen (https://forum.fhem.de/index.php/topic,113228.msg1080655.html#msg1080655)
Danke für die "Messungen"!
Drum versuche/mache ich beides...
Events hab ich schon (fast) so weit möglich auf das eingeschränkt was ich brauche (Logs/Automatismen), jetzt kommen die 30% dran... ;)
Gruß, Joachim
Gibt es einen intelligenten Filter, mit dem man die notify ohne NOTIFYDEV herausfinden kann? Das folgende funktuioniert nicht, im Wiki steht fuer Internals wird immer nur der erste Wert gefunden...
list TYPE=notify:FILTER=Internals!=NOTIFYDEV
Zitat von: Otto123 am 29 Dezember 2020, 23:22:13
Hast Du mit der Wahl Deiner Suchmuster beim notify voll in der Hand.
device:(on|off) nicht optimal - kein NOTIFYDEV
device:o[nf]+ optimal - NOTIFYDEV
device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV
Oh, okay.
Zitat von: Jamo am 30 Dezember 2020, 01:36:55
Gibt es einen intelligenten Filter, mit dem man die notify ohne NOTIFYDEV herausfinden kann?
Zitat von: Beta-User am 26 Dezember 2020, 20:47:16
Hilfsmittelchen:count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
Ergänzend sei aber nochmal erwähnt, dass auch ich voll zustimme, dass man vorrangig die Eventseite ansehen muss.
Reihenfolge:
- Externer "Verursacher" (firmware-Einstellungen)
- eocr-Attribute - aber mit Augenmaß. Wie hier auch abgerissen, ist es nur ein erster Ansatz, eines dieser Attribute auf .* zu setzen. Für Shelly@MQTT2-Module gibt es z.B. einen Vorschlag (zu finden über den "Workshop zu M2-Device"), zu dem bisher aber zu wenig Rückmeldung vorliegt, um das fest in die attrTemplate einzuarbeiten. Da werden übrigens dann manche Topic-Zweige ganz ignoriert.
Nur mal zur Info:
Falls NOTIFYDEV nicht gesetzt werden kann, wird im DOIF ein eigener Filter gesetzt, der in den ersten Zeilen der Notify-Routine angewendet wird, daher dürfte der Einspareffekt durch NOTIFYDEV inzwischen beim DOIF nur noch ein paar Prozent ausmachen.
ZitatMit NOTIFYDEV werde ich mich auch mal befassen, aber soweit ich das verstanden habe, kann ich das ja nicht echt beinflussen, da das ja wohl bei der Modulerstellung gemacht werden muss, oder hab ich das falsch verstanden?
Fuer die Module steht eine fhem.pl-Funktion bereit (notifyRegexpChanged), der aus dem (ueblicherweise vom Benutzer gesetzten) Regexp versucht abzuleiten, welche Geraete betroffen sind. Wenn das bekannt ist. dann wird NOTIFYDEV gesetzt, und das betroffene notify/FileLog/DOIF/etc fuer Events von anderen(!) Geraeten nicht aufgerufen. Leider kann diese Routine nicht immer rausfinden, was gemeint ist (siehe die Beispiele von Otto), mit { notifyRegexpCheck("myregexp") } kann man sehen, wie notifyRegexpCheck "denkt".
Zitatdaher dürfte der Einspareffekt durch NOTIFYDEV inzwischen beim DOIF nur noch ein paar Prozent ausmachen.
Bei einer Konfiguration mit vielen(!) DOIFs/FileLogs/etc machen die paar Prozente einen wesentlichen Unterschied.
Das ist kein Problem auf einem Test- oder Spielsystem, wird aber eins mit einer groessen Konfiguration.
Wir hatten kuerzlich den Fall, wo aus den ca 1000 FileLogs und notifies "nur" 2/3 ein NOTIFYDEV hatten.
Hier sind es mehr als ein paar Prozent Unterschied, wenn bei jedem Event statt eine Funktion 300 Weitere sinnlos aufgerufen werden.
Um die CPU-Last zu reduzieren sollte man die Anzahl der Events und Anzahl der Funktionsaufrufe minimieren.
Am ersten Parameter zu drehen ist einfacher, der Zweite ist aber deswegen nicht sinnlos.
Wie geschrieben, das wird relevant, wenn die CPU zu ist.
Habe inzwischen ein Menge gelesen, auch eure Kommentare alle und es lichtet sich etwas der Nebel bezüglich NOTIVYDEF.
Ich darf eventuell anmerken, das die Doku dazu etwas zu dünn und vor allem zu zerstreut ist, um Leuten auf meine Level einen einigermassen brauchbaren Einstig zu bieten. Ohne diesen Thread wäre das noch schwerer gewesen. Eventuell verfasse ich mal einen Wikiartikel - sobald ich sicher bin es auch richtig kapiert zu haben.
Ein Aspekt in meinem konkreten Fall ist, dass ich nicht mal weiss, ob CPU überhaupt das Problem ist. TOP sagt eher nein, aber da ich im Grunde nicht weiss wie der CPU% Wert bei TOP im Anzeigeintervall ermittelt wird, könnte es schon sein, das FHEM immer wieder mal auf 100% springt für sehr kurze Zeit.
Ich habe trotz der Bedenken von Beta-User jetzt erstmal recht grossflächig eocr eingesetzt, das hat aber in der Tat auch Nebenwirkungen (z.b. bei meiner "Alarmanlage"), bisher vielen die mir aber immer noch vorher ein ...
Das
ZitatHilfsmittelchen:
Code: [Auswählen]
count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
hatte ich gesehen. Ich war nur noch nicht so weit, genug von NOTIFYDEV kapiert zu haben um damit schon was anfangen zu können.
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
Um bzgl. Logging (da nehme ich ab und an ein mininterval dazu) aber v.a. "gewohnte" Automatismen wie vor eocr.* zu haben nehme ich eben über eour wieder einige "wichtige" Readings aus eocr.* "raus"...
Gruß, Joachim
Vielleicht noch ein paar Anmerkungen:
"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. Beispiel: zwei readingList-Einträge in einem MQTT2_DEVICE ergeben zwei Event-Verarbeitungsdurchläufe (wenn nicht {}), egal, ob jeweils nur ein einzelnes Klartext-Reading kommt oder auf beiden Topics je ein Mammut-JSON mit vielen Elementen ;) .
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 ;D ). 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.
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...).
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).
Und da Wiederholung scheinbar manchmal hilft: Bitte immer erst checken, was man bereits von extern abfangen kann und will (und "notfalls" mal auf den Hersteller/Anbieter/github-Repo-Inhaber zugehen!)
Zitat von: Zrrronggg! am 30 Dezember 2020, 13:40:31
Ich darf eventuell anmerken, das die Doku dazu etwas zu dünn und vor allem zu zerstreut ist, um Leuten auf meine Level einen einigermassen brauchbaren Einstig zu bieten. Ohne diesen Thread wäre das noch schwerer gewesen. Eventuell verfasse ich mal einen Wikiartikel - sobald ich sicher bin es auch richtig kapiert zu haben.
Zustimm + unterstreich + Daumen hoch :D
Dieses Thema köchelt so seit ein paar Monden in ein paar Threads - ich habe schon mal wenigsten das eine oder andere verlinkt.
Zitat von: Otto123 am 30 Dezember 2020, 14:56:49
Zustimm + unterstreich + Daumen hoch :D
Dieses Thema köchelt so seit ein paar Monden in ein paar Threads - ich habe schon mal wenigsten das eine oder andere verlinkt.
Freue mich übrigens auch, wenn hier noch ein paar Leute aufspringen und das ganze etwas mehr in die Breite bringen :) . Danke auf alle Fälle (u.a.!) an Otto, der "still und leise" an vielen Stellen dafür sorgt, dass v.a. im Wiki u.a. auch solche Dinge dann zu finden sind!
Da hier vermutlich viele interessiert mitlesen: Falls da wer dabei ist, der irgendwann mal einen Wiki-Artikel geschrieben hat, wäre es super, wenn ihr mit dem aktuellen Wissen (nicht nur zu diesen Aspekten) nochmal kritisch (v.a.) über "eure" Werke drüberschaut und ggf. auch mal checkt, ob die Welt sich nicht weiter gedreht hat (oder manches noch in euren Augen verständlicher formuliert werden kann) ;) .
Zitat von: MadMax-FHEM am 30 Dezember 2020, 13:56:43
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.
Zitat von: Beta-User am 30 Dezember 2020, 14:08:48
"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.
ZitatDoku 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 ;D ). 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.
ZitatEs 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)
ZitatWeiter 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.
ZitatUnd 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) ;D Kurzum: Bei mir hilft das höchstens zum Schein aber nicht echt. 8)
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:
ZitatBitte 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.
Zitat(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.
Zitat
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:
event-on-change-reading Reading1,Reading3,Reading4,Reading5,Reading6,Reading7,Reading8
d.h. für Reading2 "gültet" das nicht ;)
Oder eben:
event-on-change-reading .*
und dann:
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
..und wieder hält doppelt genäht eventuell besser...
Zitat von: Zrrronggg! am 30 Dezember 2020, 15:38:25
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 (https://wiki.fhem.de/wiki/Event-on-change-reading#Wechselwirkungen) findet sich (ohne Hervorhebung):
ZitatSind 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_.
Zitat
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 ;) .
ZitatIm 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.
Zitat
event-on-change-reading Reading1,Reading3,Reading4,Reading5,Reading6,Reading7,Reading8
d.h. für Reading2 "gültet" das nicht ;)
Oder eben:
event-on-change-reading .*
und dann:
event-on-update-reading Reading2
Hm. Das geht im ersten Teil meiner Meinung nach sowieso nicht.
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
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.
event-on-change-reading .*und
event-on-update-reading Reading2ist aus meiner Sicht nur eine schlechtere Variante von
event-on-change-reading .*und
event-min-interval Reading2Weil 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:
Zitatwenn man eine "klassische" CUL_HM-lastige Installation hat,
Hab ich.
ZitatFalls 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 8)
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... ::) )
Zitat
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
Zitat von: Beta-User am 30 Dezember 2020, 17:36:28Bei 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.
Zitat von: MadMax-FHEM am 30 Dezember 2020, 17:39:36Die 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. :P