Hallo zusammen,
ich schaue mir immer mal wieder meine bestehenden Konstrukte an, ob nicht - schon immer oder durch die Weiterentwicklung von FHEM - Optimierungen möglich sind hinsichtlich Vereinfachung und/oder Laufzeit.
Da bin ich neulich über https://forum.fhem.de/index.php?topic=115414.0 (https://forum.fhem.de/index.php?topic=115414.0) gestolpert und las später https://forum.fhem.de/index.php/topic,19019.msg127173.html#msg127173 (https://forum.fhem.de/index.php/topic,19019.msg127173.html#msg127173).
Da habe ich mir meine notifies vorgenommen und festgestellt, dass bei knapp 40% kein NOTIFYDEV gesetzt war. Zum Glück fand ich auch https://forum.fhem.de/index.php/topic,64449.msg556908.html#msg556908 (https://forum.fhem.de/index.php/topic,64449.msg556908.html#msg556908). Damit konnte ich die meisten meiner ca. 450 notifies so umstellen, dass NOTIFYDEV gesetzt wurde. Aktuell sind noch sieben notifies nicht umgestellt, aber die mittlere Systemlast ist um ca. 3-4% gegenüber vorher gesunken. Auch sind die Reaktionszeiten spürbar kürzer.
Jetzt frage ich mich, ob es Sinn macht, die letzten sieben auch noch umzustellen. Denn diese sind so weit gefasst, dass ich entweder mehrere notifies brauche, um ein vorhandenes zu ersetzen oder mir irgendwelche anderen Konstrukte überlegen muss. Das sind notifies wie
.*:[Bb]attery:.* oder
(AA|.G)_.*_(Tuer.|PIR.|Fenster.):(open|closed|motion|on-old-for-timer.*)
Gibt es eine Möglichkeit, so etwas abzuschätzen oder gar zu messen? Gibt es einen "FHEM-Benchmark"?
Grüße
Auch hier gab es letztens eine Diskussion: https://forum.fhem.de/index.php/topic,125381.0.html dazu, ich habe für mein Modul eine Messung durchgeführt, die Ergebnisse und deren Bedeutung kannst du in weiteren Posts des Threads lesen.
Du kannst Dir auch deine watchdogs und sequence anschauen.
count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
list TYPE=watchdog:FILTER=NOTIFYDEV!~.+ DEF
list TYPE=sequence:FILTER=NOTIFYDEV!~.+ DEF
.*:[Bb]attery:.* und ähnliches hatte ich auch - Ich habe mir dann überlegt, ob und wann ein event + notify wirklich notwendig ist.
Events + notify habe ich nur noch für die Sachen die ich entweder loggen will, oder wo sofort die Information über die Statusänderung gebraucht wird (Schalter/Bewegungsmelder/Alarm/Fensterstatus/presence etc).
Den Rest habe ich durch ein 'at' ersetzt. Also ein ''at'', was alle 10 minuten triggered, und dann werden nur noch 1 mal alle 10 minuten die Informationen geupdatet die nicht Zeitkritisch sind wie Innenraumtemperatur, Aussentemperatur, Lichtstärke, Co2-Luftqualität, Lampenstatus bei Abwesenheit, Verbrauch bei Abwesenheit, etc. Die entsprechenden Events werden dann durch entsprechendes ändern des event-on-change-reading (eocr) also auch nicht mehr generiert. Mal in den Eventmonitor schauen, und den mal eine Stunde laufen lassen - benötigt man die ganzen Events wirklich?
Batterien frage ich rundum für alle Batteriebetriebenen Devices 1 x Mittags ab, und lasse mich dann 1 x am Tag informieren - das notify fällt damit weg.
(AA|.G)_.*_(Tuer.|PIR.|Fenster.):(open|closed|motion|on-old-for-timer.*) - sowas habe ich dann in der Tat komplett ausgeschrieben . . .
PS: was ist 'on-old-for-timer' ?
ZitatGibt es eine Möglichkeit, so etwas abzuschätzen oder gar zu messen?
Man kann die "problematischen" notifies temporaer entfernen, und die Systemauslastung messen.
ZitatGibt es einen "FHEM-Benchmark"?
Mir ist sowas nicht bekannt, und wie es in diesem Fall helfen koennte, auch nicht.
NOTIFYDEV zu "optimieren" (d.h. den Regexp solange umzubauen, bis NOTIFYDEV gesetzt wird) lohnt sich dann, wenn FHEM subjektiv zaeh ist oder deswegen Probleme wie Verbindungsabbrueche auftauchen, man eine Menge von notifies/FileLogs/etc hat (d.h. 100+), und performantere Hardware keine Option ist.
Die 4% durchschnittliche Systemlast Ersparnis ist irrefuehrend: in Peaks (d.h. wenn Nachrichten gehaeuft erzeugt werden) kann die Optimierung durchaus einen groesseren Unterschied ausmachen.
Ich selbst wuerde die letzten 7 notifies aber nicht mehr optimieren, NOTIFYDEV ist nur bei der Menge relevant.
Zitat von: Damian am 30 Januar 2022, 11:30:09
Auch hier gab es letztens eine Diskussion: https://forum.fhem.de/index.php/topic,125381.0.html dazu, ich habe für mein Modul eine Messung durchgeführt, die Ergebnisse und deren Bedeutung kannst du in weiteren Posts des Threads lesen.
Den hatte ich noch nicht gefunden. Danke!
Zitat von: Jamo am 30 Januar 2022, 11:52:28
.*:[Bb]attery:.* und ähnliches hatte ich auch - Ich habe mir dann überlegt, ob und wann ein event + notify wirklich notwendig ist.
[...]
Den Rest habe ich durch ein 'at' ersetzt. Also ein ''at'', was alle 10 minuten triggered, und dann werden nur noch 1 mal alle 10 minuten die Informationen geupdatet [...]
Ich fürchte, dass einige Sachen, die bei mir derzeit noch events generieren, umgebaut auf ein AT *+00:10:00 das System dann alle 10 Minuten zu sehr bremsen würden.
ZitatMal in den Eventmonitor schauen, und den mal eine Stunde laufen lassen - benötigt man die ganzen Events wirklich?
Das ist schon ziemlich optimiert dort. Es ist halt die Masse aus gut 200 physikalische Geräten, ca. 450 notifies...
Zitat
PS: was ist 'on-old-for-timer' ?
Die kommen von ein paar FS20PIRI und -PIRA, die ich noch nicht in Rente geschickt habe. :o
Zitat von: rudolfkoenig am 30 Januar 2022, 12:11:28
Man kann die "problematischen" notifies temporaer entfernen, und die Systemauslastung messen.
Problematisch sind die alle nicht oder nicht gewesen. Frei nach dem Motto "Wehret den Anfängen!" möchte ich es gar nicht erst zu Problemen kommen lassen.
Zitat
NOTIFYDEV zu "optimieren" (d.h. den Regexp solange umzubauen, bis NOTIFYDEV gesetzt wird) lohnt sich dann, wenn FHEM subjektiv zaeh ist oder deswegen Probleme wie Verbindungsabbrueche auftauchen, man eine Menge von notifies/FileLogs/etc hat (d.h. 100+), und performantere Hardware keine Option ist.
Wie gesagt: da bin ich noch nicht, dass es zäh wird. Allerdings möchte ich für FHEM auch nicht mehr als den Odroid XU4 laufen lassen. Der lief vorher bei knapp 90% idle und jetzt etwas über 93% idle. Da ich aus Gründen der Flexibilität und des Komforts auch weiterhin die Steuerung von z.B. Beleuchtung nicht durch Peering statt wie jetzt durch FHEM machen möchte, versuche ich halt, dass die Gedenksekunden nach dem Betätigen eines Schalters nicht mehr sondern eher weniger werden.
Zitat
Die 4% durchschnittliche Systemlast Ersparnis ist irrefuehrend: in Peaks (d.h. wenn Nachrichten gehaeuft erzeugt werden) kann die Optimierung durchaus einen groesseren Unterschied ausmachen.
Und genau den Effekt merke ich durch das Optimieren der regex, so dass NOTIFYDEV gesetzt werden kann. Einzelne Peaks kann ich im SystemMonitor eher nicht erkennen, deren Summe anhand der mittleren Auslastung schon.
Zitat
Ich selbst wuerde die letzten 7 notifies aber nicht mehr optimieren, NOTIFYDEV ist nur bei der Menge relevant.
Danke für diesen Hinweis!
Grüße
Wenn du wirklich Performance sparen willst, dann würde ich dir empfehlen mehr Energie in die Vermeidung von unnötigen Events zu investieren.
Man mag es nicht glauben, aber man braucht in seltensten Fällen Events von irgendetwas, was sich nicht ändert.
Ich habe bei mir ganz mutig attr .* event-on-change-reading .* für alle Devices gesetzt (Sicherung der Konfiguration kann davor nicht schaden!) und musste es zunächst nur bei einem Device rückgängig machen. Das hat bereits eine Menge unnötiger Events eliminiert.
Dann habe ich mir den Event-Monitor angeschaut und konnte noch regelmäßige Events sehen, die ich überhaupt nicht brauchte. Und selbst die, habe ich per event-on-update-reading eliminieren können.
Im optimalen Fall sollten nur noch Events zu sehen sein, die man tatsächlich in seinem System irgendwo auswertet. Und das sage ich, obwohl mein Modul inzwischen immer mit einem gesetzten NOTIFYDEV-Filter arbeitet: https://forum.fhem.de/index.php/topic,103401.msg1204449.html#msg1204449
Das kann man dann auch noch für neue Devices automatisieren:
defmod nyEocrNewDef notify global:DEFINED.* attr $EVTPART1 event-on-change-reading .*
Geht sicher auch mit DOIF ;)
gb#
Und hier noch mal paar Zahlen:
Ein Event, auf das kein Device im System reagiert verbraucht bereits 25 bis 30 mal mehr Performance, als wenn man das Event unterdrückt.
Das kannst du bei dir ausprobieren:
defmod di_t123 DOIF {\
my ($seconds, $microseconds) = ::gettimeofday();;\
for (my $i=0;;$i<1000;;$i++){\
set_Reading("q123","qwert",1);;\
}\
my ($seconds2, $microseconds2) = ::gettimeofday();;\
set_State($seconds2+$microseconds2/1000000-($seconds+$microseconds/1000000));;\
}
attr di_t123 event-on-update-reading state
paar mal laufen lassen mit:
set di_t123 block_01
die Laufzeiten im Status notieren.
dann das Attribut event-on-update-reading löschen und dann den set Befehl mit Abstand paar mal ausführen.
Die kürzeste Laufzeit aus dem Status kannst du ins Verhältnis setzen mit der kürzesten Laufzeit mit dem gesetzten Attribut, dann weißt du Bescheid ;)
Zitat von: alanblack am 29 Januar 2022, 21:02:32
Du kannst auch mal mit apptime count schauen, wer sich wieviel Fhemsekunden gönnt .
da sieht man z.b. dass readingsGroup_Notify sich jedes Event anschaut
usw.
name function max count total average maxDly avgDly TS Max call param Max call
banane FHEM2FHEM_Ready 15 3008914 103532.07 0.03 0.00 0.00 22.01. 20:10:03 HASH(banane)
AB readingsGroup_Notify 23 1712629 200065.65 0.12 0.00 0.00 27.01. 02:44:55 HASH(AB); HASH(Mqtt_create_reading_localhost)
CORONA readingsGroup_Notify 22 1712629 151204.20 0.09 0.00 0.00 25.01. 02:05:48 HASH(CORONA); HASH(FHEM_HZ)
Tel readingsGroup_Notify 22 1712629 144231.37 0.08 0.00 0.00 27.01. 15:45:52 HASH(Tel); HASH(FHEM_HZ)
Tel_g readingsGroup_Notify 20 1712629 143592.01 0.08 0.00 0.00 23.01. 18:11:46 HASH(Tel_g); HASH(FHEM_HZ)
WEB FW_Notify 4 1712629 21864.56 0.01 0.00 0.00 29.01. 16:51:24 HASH(WEB); HASH(WZ_t)
Wetter readingsGroup_Notify 16 1712629 146139.36 0.09 0.00 0.00 25.01. 04:35:37 HASH(Wetter); HASH(FHEM_HC)
mqttPublishList readingsGroup_Notify 25 1712629 137890.45 0.08 0.00 0.00 22.01. 08:03:44 HASH(mqttPublishList); HASH(FHEM_HM)
perlsize FileLog_Log 24 1712629 201951.74 0.12 0.00 0.00 20.01. 19:28:03 HASH(perlsize); HASH(Mqtt_create_reading_localhost)
rg_dead readingsGroup_Notify 16 1712629 135920.93 0.08 0.00 0.00 26.01. 10:15:17 HASH(rg_dead); HASH(WS1080)
system notify_Exec 24 1712629 271329.06 0.16 0.00 0.00 21.01. 05:43:07 HASH(system); HASH(HC1live_at)
tmr-perfmon_ProcessTimer HASH_unnamed 2 872881 78320.76 0.09 283.96 1.49 29.01. 16:50:05 HASH(0xd93128)
mqttclient_localhost MQTT2_CLIENT_Read 38 700788 2312766.05 3.30 0.00 0.00 29.01. 02:40:08 HASH(mqttclient_localhost)
tmr-__ANON__ HASH(0x1aa8840) 57 544021 3475064.24 6.39 0.00 0.00 29.01. 06:58:31 HASH(mqttclient_localhost)
rain_stat statistics_Notify 50 293521 2524274.13 8.60 0.00 0.00 26.01. 18:11:19 HASH(rain_stat); HASH(WS1080)
tmr-MQTT2_CLIENT_keepalive HASH(0x1aa8840) 5 87277 23906.90 0.27 247.46 1.00 28.01. 05:08:55 HASH(mqttclient_localhost)
WS1080 MQTT2_DEVICE_Set 14 56138 3999.29 0.07 0.00 0.00 20.01. 17:01:39 HASH(WS1080); WS1080; ?
Heizung MQTT2_DEVICE_Set 0 40365 3602.74 0.09 0.00 0.00 23.01. 21:24:38 HASH(Heizung); Heizung; ?
FHEM_HC1_live dummy_Set 23 29129 175558.82 6.03 0.00 0.00 27.01. 07:01:07 HASH(FHEM_HC1_live); FHEM_HC1_live; on
mqttclient_localhost MQTT2_CLIENT_Set 2 29119 16144.33 0.55 0.00 0.00 29.01. 04:19:07 HASH(mqttclient_localhost); mqttclient_localhost; publish; haus/HC1/Fhem_HC1_live/state; on
n_publish_mqtt_localhost notify_Exec 20 29097 107116.06 3.68 0.00 0.00 27.01. 07:01:07 HASH(n_publish_mqtt_localhost); HASH(FHEM_HC1_live)
Zitat von: Damian am 30 Januar 2022, 18:03:40
Wenn du wirklich Performance sparen willst, dann würde ich dir empfehlen mehr Energie in die Vermeidung von unnötigen Events zu investieren.
Das ist schon klar. Nochmal ausdrücklich: Ich habe kein Problem mit der Performance. Ich versuche nur, mehr und mehr zu verstehen, um möglichst viel zu automatisieren und dabei zu optimieren.
Ich kontrolliere ab und an händisch mit
list TYPE=.*:FILTER=event-on-change-reading!~.+ ob mir irgendetwas durch die Lappen gegangen ist.
Bei vielen Devices steht eher etwas selektiveres im eocr wie
actuator,battery,day-temp,measured-temp:0.2,control-mode,mode,night-temp,temperature:0.2,humidity,dewpoint,absFeuchte,desired-temp,controlMode,state,STATEZitat
Im optimalen Fall sollten nur noch Events zu sehen sein, die man tatsächlich in seinem System irgendwo auswertet. Und das sage ich, obwohl mein Modul inzwischen immer mit einem gesetzten NOTIFYDEV-Filter arbeitet: https://forum.fhem.de/index.php/topic,103401.msg1204449.html#msg1204449
Daher habe ich eocr auf Dinge reduziert, wozu es ein notify/watchdog... oder FileLog gibt.
Zitat von: Benni am 30 Januar 2022, 18:58:30
Das kann man dann auch noch für neue Devices automatisieren:
defmod nyEocrNewDef notify global:DEFINED.* attr $EVTPART1 event-on-change-reading .*
Die Idee an sich ist gut, aber mich würden die Fehlermeldungen stören, wenn ich bspw. einen watchdog anlege; der hat kein eocr.
Zitat von: Damian am 30 Januar 2022, 19:17:09
Und hier noch mal paar Zahlen:
Ein Event, auf das kein Device im System reagiert verbraucht bereits 25 bis 30 mal mehr Performance, als wenn man das Event unterdrückt.
[...]
Ich glaube Dir das auch, ohne es ausprobiert zu haben.
Aber dieses DOIF kann ich vielleicht mal als Benchmark benutzen. Nettes Konstrukt!
Zitat von: fhem-hm-knecht am 30 Januar 2022, 19:19:32
Du kannst auch mal mit apptime count schauen, wer sich wieviel Fhemsekunden gönnt .
da sieht man z.b. dass readingsGroup_Notify sich jedes Event anschaut
Einer der Gründe, weswegen ich keine ReadingsGroup mehr habe.
Grüße
Zitat von: alanblack am 30 Januar 2022, 21:17:41
Die Idee an sich ist gut, aber mich würden die Fehlermeldungen stören, wenn ich bspw. einen watchdog anlege; der hat kein eocr.
Das kann man aber auch verhindern, wenn's stört! ;)
defmod nyEocrNewDef notify global:DEFINED.* {\
fhem("attr $EVTPART1 event-on-change-reading .*") if(fhem_devSupportsAttr($EVTPART1,'event-on-change-reading'));;\
}
gb#
Zitat von: alanblack am 30 Januar 2022, 21:17:41
Das ist schon klar. Nochmal ausdrücklich: Ich habe kein Problem mit der Performance. Ich versuche nur, mehr und mehr zu verstehen, um möglichst viel zu automatisieren und dabei zu optimieren.
Die Optimierungsvorschläge sollte man beherzingen, bevor man Probleme bekommt und nicht erst, wenn es zu spät ist. Und wie optimiert man wohl: Indem man Rechenzeit spart :)
Zitat von: Damian am 31 Januar 2022, 12:33:11
Die Optimierungsvorschläge sollte man beherzingen, bevor man Probleme bekommt und nicht erst, wenn es zu spät ist. Und wie optimiert man wohl: Indem man Rechenzeit spart :)
...mich wundert auch immer wieder, wie wenig das tendenziell wichtige Thema bei einer großen Zahl von Usern präsent zu sein scheint...
(Und wie wenige den Unterschied zwischen Event und Event-Loop kennen wird)
Allerdings hätte ich in meiner eigenen Installation mit der pauschalen (nachträglichen) ".*"-Lösung gleich zwei Probleme verursacht:
- zum einen würde das meine vorhandenen und teils ähnlich langen Einstellungen wie von alanblack gezeigten überschreiben (und damit zu mehr (!) Events führen) und
- zum Teil würden manche Eventhandler damit (manchmal!) nicht funktionieren, z.B. (mehr oder weniger) alles, was mit (mehrfach-) Tastern zu tun hat.
Ich würde daher eher empfehlen, sich jeden "Typ" mal intensiver anzusehen, dafür "gute" Einstellungen zu erarbeiten (das kann auch heißen, überhaupt nur einen Teil der Readings triggern zu lassen), und diese dann zu übertragen (attrTemplate oder v.a. auch archetype (https://fhem.de/commandref_modular_DE.html#archetype), wenn ich das richtig verstanden habe).
Zitat von: Beta-User am 31 Januar 2022, 13:07:50
...mich wundert auch immer wieder, wie wenig das tendenziell wichtige Thema bei einer großen Zahl von Usern präsent zu sein scheint...
Na ja, es ist halt manchmal einfacher, mit dem Hammer zu schrauben ;)
Will meinen, wenn das System träge wird, einfach mal mit einem leistungsfähigeren drauf hauen, sprich durch ein solches ersetzen. (Pi3 -> Pi4 -> NUC -> ...)
Zitat
Allerdings hätte ich in meiner eigenen Installation mit der pauschalen (nachträglichen) ".*"-Lösung gleich zwei Probleme verursacht:
- zum einen würde das meine vorhandenen und teils ähnlich langen Einstellungen wie von alanblack gezeigten überschreiben (und damit zu mehr (!) Events führen) und
Das könnte man aber mit dem devspec, das alanblack für das Aufspüren der ungesetzten Devices verwendet hat, relativ einfach umgehen:
attr .*:FILTER=event-on-change-reading!~.+ event-on-change-reading .*
Wobei man das .* am Anfang ggf. weiter eingrenzen kann.
(Ggf. auftretende Log-Meldungen, wg. nicht unterstütztem eocr sind dabei allerdings zu ignorieren ;) )
Ansonsten sehe ich das auch so: Am besten nur die Events zuzulassen, die man auch wirklich braucht! Und das muss auch immer mal wieder reviewed werden :)
Gruß Benni
Zitat von: Benni am 31 Januar 2022, 13:30:50
Na ja, es ist halt manchmal einfacher, mit dem Hammer zu schrauben ;)
...schönes Bild...
Das Problem ist nur: Wenn hier "ständig alle" mit der großen Keule schwingen, glaubt recht schnell ein nicht unerheblicher Teil der community, das sei sowas wie ein "Universalwerkzeug". Ich empfinde das daher eher als grenzwertig.
Zitat
Will meinen, wenn das System träge wird, einfach mal mit einem leistungsfähigeren drauf hauen, sprich durch ein solches ersetzen. (Pi3 -> Pi4 -> NUC -> ...)
:) Meine Empfehlung für Anfänger wäre eigentlich immer, eher eine Nummer kleiner zu nehmen, dann merkt man es auch gleich, wenn man einen Bock geschossen hat. Ein Pi 2 war eigentlich unter diesem Gesichtspunkt "ideal" ;D .
Zitat
Das könnte man aber mit dem devspec, das alanblack für das Aufspüren der ungesetzten Devices verwendet hat, relativ einfach umgehen:
Mir ist das klar, aber das würde trotzdem bedeuten, dass praktisch alle Event-Handler nicht mehr (richtig) funktionieren, die Taster-Devices auswerten.
Und letztlich ist eine gewisse "Grundlast" an Events auch kein wirkliches Problem. Man muss halt die Gesamtsituation im Auge behalten...
Werde mir jetzt aber trotzdem mal "archetype" näher ansehen. Bisher habe ich eher über den "devspec-Weg" (also eher zu Fuß denn vollautomatisiert) passende Gesamteinstellungen an "gleichartige" Geräte verteilt, aber das ist nur solange "gut", wie man weiß, warum und für welche Geräte man das gemacht hat...
Das Hauptproblem liegt hauptsächlich darin, dass der Modulentwickler oft alle seine Readings mit Event setzt. Er kann ja argumentieren, wenn der User sie nicht haben willst, dann kann er sie mit event-on-update-readings eliminieren. Wenn er aber Readings ohne Event schreibt, dann kann der User das Event nicht nachträglich aktivieren.
Der "Normal"-User wiederum achtet zunächst bei einer Definition eines neuen Devices nicht darauf, welche Events dazu kommen und vor allem in welcher Häufigkeit.
Selbst mir geht es so, dass ich alle paar Monate erschreckend feststelle, was da an Events dazugekommen ist und fange wieder an auszumisten - das dürften aber die wenigsten tun.
Besser für die Gesamtperformance wäre, wenn die Events eines neuen Devices zunächst ausbleiben würden (default z.B.: event-on-update-readings state) und der User sie nach Bedarf bewusst erst einschalten müsste, wenn er sie bräuchte - das wäre aber für den User weniger komfortabel. Und solange man immer leistungsfähigere Hardware kaufen kann ...
Zitat von: Damian am 31 Januar 2022, 14:29:49
Das Hauptproblem liegt hauptsächlich darin, dass der Modulentwickler oft alle seine Readings mit Event setzt. Er kann ja argumentieren, wenn der User sie nicht haben willst, dann kann er sie mit event-on-update-readings eliminieren. Wenn er aber Readings ohne Event schreibt, dann kann der User das Event nicht nachträglich aktivieren.
doch, das kann man dank rudi mittlerweile "aushebeln".
sehr tricky und gut "versteckt", funktioniert aber hervorragend. 8)
https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583 (https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583)
@frank: Ich glaube nicht, dass es für die überwiegende Zahl der User hilfreich ist, wenn man das "bewirbt" (oder gar unter Verweis auf diese Option die Maintainer motivieren will, weniger Events zu zeigen)...
Es ist und bleibt m.E. so, dass es sinnvoll ist, den Usern den sinnvollen Einsatz _aller_ eocr-Optionen zu erläutern und ggf. die (vorhandenen) Hilfsmittel so darzustellen, dass man sie relativ einfach anwenden kann.
Zitat von: Damian am 31 Januar 2022, 12:33:11
Die Optimierungsvorschläge sollte man beherzingen, bevor man Probleme bekommt und nicht erst, wenn es zu spät ist. Und wie optimiert man wohl: Indem man Rechenzeit spart :)
Das möchte ich so nicht stehen lassen. Wenn ich meinem FHEM-Computer soviel Rechenzeit abverlange, dass der Kühlkörper anfängt zu glühen und Leuchten erst nach sechs statt nach 0,5 Sekunden angehen, dann nehme ich dieses Mehr gerne in Kauf, wenn ich dafür nur noch die Hälfte an Strom- und Heizkosten hätte. Ist für mich eine Optimierung des Systems hin zur Kostenreduktion. Eine Optimierung verlangt mMn immer (mindestens) ein Optimierungsziel.
Zitat von: Beta-User am 31 Januar 2022, 13:07:50
Allerdings hätte ich in meiner eigenen Installation mit der pauschalen (nachträglichen) ".*"-Lösung gleich zwei Probleme verursacht:
[...]- zum Teil würden manche Eventhandler damit (manchmal!) nicht funktionieren, z.B. (mehr oder weniger) alles, was mit (mehrfach-) Tastern zu tun hat.
So nicht ganz vollständig: setze ich bei diesen Devices noch ein eo
ur (event-on-
update-reading)z.B. ein state, funktionieren diese 1a.
Zitat von: Beta-User am 31 Januar 2022, 13:44:11
Mir ist das klar, aber das würde trotzdem bedeuten, dass praktisch alle Event-Handler nicht mehr (richtig) funktionieren, die Taster-Devices auswerten.
Wie gerade geschrieben: es gibt auch event-on-update-reading.
Zitat von: Beta-User am 31 Januar 2022, 15:07:44
@frank: Ich glaube nicht, dass es für die überwiegende Zahl der User hilfreich ist, wenn man das "bewirbt" (oder gar unter Verweis auf diese Option die Maintainer motivieren will, weniger Events zu zeigen)...
Jepp!
ZitatEs ist und bleibt m.E. so, dass es sinnvoll ist, den Usern den sinnvollen Einsatz _aller_ eocr-Optionen zu erläutern und ggf. die (vorhandenen) Hilfsmittel so darzustellen, dass man sie relativ einfach anwenden kann.
Ja, aller eocr (event-on-change-reading) aber auch aller eour (event-on-update-reading) Optionen.
Grüße
Nachtrag (leicht offtopic):
Zitat von: Benni am 31 Januar 2022, 13:30:50
attr .*:FILTER=event-on-change-reading!~.+ event-on-change-reading .*
[...]
(Ggf. auftretende Log-Meldungen, wg. nicht unterstütztem eocr sind dabei allerdings zu ignorieren ;) )
Beim Aufruf über die Commandozeile gibt es keine Einträge im Log. 8)
Zitat von: alanblack am 31 Januar 2022, 22:21:40
Das möchte ich so nicht stehen lassen. Wenn ich meinem FHEM-Computer soviel Rechenzeit abverlange, dass der Kühlkörper anfängt zu glühen und Leuchten erst nach sechs statt nach 0,5 Sekunden angehen, dann nehme ich dieses Mehr gerne in Kauf, wenn ich dafür nur noch die Hälfte an Strom- und Heizkosten hätte. Ist für mich eine Optimierung des Systems hin zur Kostenreduktion. Eine Optimierung verlangt mMn immer (mindestens) ein Optimierungsziel.
Jetzt wird's aber OT! ;)
Optimierungsziel dieses Threads war bisher doch die Eventlast, bzw. die Verarbeitungslast der auftretenden Events zu reduzieren.
Das hat per se erst mal nix mit Strom und Heizkosten zu tun.
gb#
Zitat von: alanblack am 31 Januar 2022, 22:21:40
Wie gerade geschrieben: es gibt auch event-on-update-reading.
[...]
Ja, aller eocr (event-on-change-reading) aber auch aller eour (event-on-update-reading) Optionen.
Unvollständig.
Mit "_aller_ eocr-Optionen" in
Zitat von: Beta-User am 31 Januar 2022, 15:07:44
Es ist und bleibt m.E. so, dass es sinnvoll ist, den Usern den sinnvollen Einsatz _aller_ eocr-Optionen zu erläutern und ggf. die (vorhandenen) Hilfsmittel so darzustellen, dass man sie relativ einfach anwenden kann.
waren noch weitere Attribute gemeint, die in den Gesamtkontext auch noch reingehören:
event-min-interval, timestamp-on-change-reading und event-aggregator.
U.A. auch deswegen ist der pauschale Hinweis auf das Setzen nur eines Attributs aus der Familie zwar wichtig, aber eben nicht vollständig.
Zitat von: Benni am 01 Februar 2022, 05:54:07
Jetzt wird's aber OT! ;)
Optimierungsziel dieses Threads war bisher doch die Eventlast, bzw. die Verarbeitungslast der auftretenden Events zu reduzieren.
Das hat per se erst mal nix mit Strom und Heizkosten zu tun.
Hey, das ist doch ein normaler Verlauf in einem Forum:
Optimierung von NOTIFYDEV (notifies/watchdogs/...) => Vermeidung von Events (eocr/eour/emi/...) => Optimierung allgemein => ... => wann wird der nicht optimale Einsatz von FHEM besteuert? [IronieOff]
[ ] Meine Beiträge sind immer on-topic, vollständig und fehlerfrei :o
Ich weiß nicht, aber wenn hier nicht noch Hinweise zu NOTIFYDEV (!) kommen, sollte ich den Thread schließen, oder?
Grüße