[98_monitoring] - Support Thread ab 2022

[Gisbert]

Da die regexp'e analog zu notify funktionieren (zumindest steht das so in der commandref), solltest du fast richtig gelegen haben mit deinem Lösungsversuch.

Versuche es mal so:
Code Auswählen Erweitern

Code Auswählen Erweitern

defmod mymonitoring monitoring .*:Zeitstempel:.*

Das sieht auf den ersten Blick gut aus - ich beobachte weiter. Falls ich mich nicht mehr hier melde, dann ist es erfolgreich.

[Gernott]

Ich bin eher zufällig über das Monitoring-Modul gestolpert und habe mal testweise 2 Instanzen installiert, eines für Batterien und eines für den Activity-Status. Ich habe den Code für die beiden Devices aus den Beispielen der ersten Seite des Startfadens kopiert. Nach einiger Beobachtung war mir aufgefallen, daß mein Raspi teilweise träger bei Zugriffen reagiert als sonst. top zeigte mir im System eine teilweise hohe Last des FHEM-perl-Prozesses, mit regelmäßig wiederkehrenden Phasen von 100 %. Damit war das träge Verhalten beim Webzugriff zumindest mal erklärt.
Ich habe dann die beiden Module deaktiviert. Dann idelt der Raspi wieder ruhig vor sich hin. Danach zuerst das Batteriemonitoring aktiviert, ab etwa 12:30. Man sieht im Plot keine signifikante Lastzunahme, obwohl die Raspitaktfrequenz nun am oberen Limit bleibt. Nach dem Zuschalten des Activity-Monitoring geht die Last deutlich hoch (ab ca. 16:30).
Du darfst diesen Dateianhang nicht ansehen.

Hat das auch schon jemand so beobachtet?

[Beta-User]

Hat das auch schon jemand so beobachtet?

Jein*.

Meine Vermutung: Dei beiden monitoring-Instanzen haben "das Fass zum Überlaufen" gebracht. In der ".*:xy"-Fassung für die add- und remove-devspec wird kein NOTIFYDEF ermittelt, so dass diese beiden Instanzen einfach alle Events auswerten müssen, was etwas ineffizienter ist, wie wenn das besser eingegrenzt ist.
Sind es tatsächlich viele Events (v.a., wenn es keine Event-Stapel (bulk-updates) sind, kann das schon dazu führen, dass der PI besser ausgelastet ist, und -v.a.- dann anfängt zu swappen. In dem Moment ist es mehr oder weniger vorbei mit lustig...

Das hätte dann aber weniger mit "monitoring" zu tun, sondern würde genauso auftreten, wenn du ein paar "schlechte" notify dazu packen würdest oder sonst einfach das System weiter ausbaust.  (*Jein=Das hatten wir in der Vergangenheit häufiger, allerdings nicht speziell mit monitoring, siehe der weiter unten verlinkte "Performance-Problem-Thread").

Hast du denn "event-lastige" Neuzugänge im System? (Ich hatte z.B. deutlich mehr Events nach dem Umbau von deconz/HUE.* auf zigbee2mqtt wegen diverser Aktoren mit Messfunktion, die sekündlich (viele) Werte gesendet haben).
Dazu ein paar Devices, die forks erzeugen (alte PRESENCE-ping?) oä.?

Sonst müßte ich mal in den Code schauen (und die commandref "NOTIFYDEF-freundlicher" überarbeiten)...