NOTIFYDEV - wie weit optimieren?

[alanblack]

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 gestolpert und las später 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. 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

Code Auswählen Erweitern

.*:[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

[Damian]

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.

[Jamo]

Du kannst Dir auch deine watchdogs und sequence anschauen.

Code Auswählen Erweitern

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' ?

[rudolfkoenig]

Gibt es eine Möglichkeit, so etwas abzuschätzen oder gar zu messen?

Man kann die "problematischen" notifies temporaer entfernen, und die Systemauslastung messen.

Gibt 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.

[alanblack]

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!

.*:[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.

Mal 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...

PS: was ist 'on-old-for-timer' ?

Die kommen von ein paar FS20PIRI und -PIRA, die ich noch nicht in Rente geschickt habe. 

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.

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.

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.

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

[Damian]

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

[Benni]

Das kann man dann auch noch für neue Devices automatisieren:

Code Auswählen Erweitern


defmod nyEocrNewDef notify global:DEFINED.* attr $EVTPART1 event-on-change-reading .*


Geht sicher auch mit DOIF

gb#

[Damian]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[LuckyDay]

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.

Code Auswählen Erweitern

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)

[alanblack]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

actuator,battery,day-temp,measured-temp:0.2,control-mode,mode,night-temp,temperature:0.2,humidity,dewpoint,absFeuchte,desired-temp,controlMode,state,STATE

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.

Das kann man dann auch noch für neue Devices automatisieren:

Code Auswählen Erweitern


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.

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!

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

[Benni]

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!

Code Auswählen Erweitern


defmod nyEocrNewDef notify global:DEFINED.* {\
fhem("attr $EVTPART1 event-on-change-reading .*") if(fhem_devSupportsAttr($EVTPART1,'event-on-change-reading'));;\
}


gb#

[Damian]

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

[Beta-User]

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, wenn ich das richtig verstanden habe).

[Benni]

...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 -> ...)

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:

Code Auswählen Erweitern


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

[Beta-User]

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.

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" .

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...