Auslastung / Kontrolle - Netzwerkfehler ?

[flummy1978]

Hallo zusammen,

nachdem ich nun seit ca einem Jahr sehr intensiv mit FHEM und allem drum herum spiele, ist einiges an meiner Installation passiert. Das führt natürlich auch dazu, dass die ein oder andere Leiche übrig geblieben sein dürfte (auch wenn ich ansich sehr penibel drauf achte, dass es eben nicht zu viele sind). Nun hab ich das Gefühl, dass das System ansich ein wenig träge geworden ist. Es ist nich so, dass es wer weiß wie extrem spürbar ist, aber gefühlt würde ich sagen reagiert das Licht über den Bewegungsmelder vielleicht eben doch verzögerter als früher oder der Knopfdruck für den Rolladen ist nicht so direkt ansprechend wie es (gefühlt) mal war.

Nun würde ich ein wenig schauen, wie der allgemeine Ablauf ist. Was wäre dazu eine empfehlenswerte Vorgansweise ?

Für mich wäre z.B. wichtig mal herauszufinden ob / wo es Verzögerungen gibt. D.h. wie kann ich die DB anbindung am besten testen und was sind hierfür akzeptable Werte ? Genauso die Prozesslaufzeit des FHEM Prozesses, Auslastung vom Arbeitsspeicher usw usf.

Mir ist durchaus bewusst, dass es Dinge wie Freezmon, oder ähnliches gibt, aber zum einen kann ich mit den Ausgaben kaum etwas anfangen wo ich nicht weiß, worauf ich achten muss und zum anderen habe ich ja keine wirklichen Freezes, sondern das System ansich ist gefühlt träge.

Vielleicht ha ja jemand den einen oder anderen Tipp für mich, wie ich am besten vorgehen könnte
Vielen Dank im Voraus
Viele Grüße
Andreas

[MadMax-FHEM]

Mir ist durchaus bewusst, dass es Dinge wie Freezmon, oder ähnliches gibt, aber zum einen kann ich mit den Ausgaben kaum etwas anfangen wo ich nicht weiß, worauf ich achten muss und zum anderen habe ich ja keine wirklichen Freezes, sondern das System ansich ist gefühlt träge.

Das ist schon mal "Quatsch"!

Also fhem ist "single Threaded" (außer ein Modul nutzt non-Blocking).
D.h. wenn fhem "freezed" und du einen Schalter drückst, dann kann fhem erst reagieren, wenn der Freeze vorbei ist (und alles was während dem Freeze sonst noch aufgelaufen ist) reagieren...

Fühlt sich träge an.

Und freezemon ist sehr einfach, zumindest erst mal, um zu sehen sind "schlimme Freezes" da.

Wenn nichts im Log steht, dann sind erst mal keine wirklich schlimmen Freezes vorhanden...
...wenn doch: Detailanalyse...

Das andere sind unnötige Events, die durch's System huschen: event-on-...Attribute helfen hier.

Bei DOIF-Tools besteht die Möglichkeit Events "zählen" zu lassen (pro Modul/pro Zeit)...

Und dann noch notify die "auf alles mögliche" reagieren und dann "intern" (durch if/else etc.) erst "schauen", ob sie "gemeint waren"...
...also notify-RegEx verbessern...

Das sind doch schon mal so einige Dinge...

Speicher etc. kann man auch noch. Dazu gibt es mind. 2 ausführliche Threads...

Gruß, Joachim

[flummy1978]

Hallo Joachim,

zu allererst vielen Dank für Deine ausführliche Antwort und bitte entschuldige dass ich jetzt erst drauf reagiere. Ich habe die Antwort spät gelesen und bis in die Nacht + Gestern den ganzen Tag nach der Ursache gesucht..... Bisher leider mit mäßigem Erfolg....

Zu Freezmon: Bei meinem ursprünglichen Test mit Freezmon stand bei mir immer (schon länger her) "delay is 1.171 possibly caused by: no bad guy found " ... das bedeutet, hier kann ich natürlich nichts mit der Ausgabe anfangen. Hab allerdings erst jetzt (beim erneuten Test nach Deiner Antwort), dass man das Ganze schön separat loggen kann und es nicht im normalen Log landet. Allerdings wie oben geschrieben ist die Auswertung für mich auch eher ein lustiges Raten, weil dort einfach so viele Geräte und Informationen stehen, dass ich keine Idee hab womit ich anfangen soll.

Was ich aber mit Hilfe des Freezmon hoffe herausgefunden zu haben: Wenn ich den MQTT Broker deaktiviere ist (war zumindest über ne Std etwa) kein Freeze zu erkennen. Das muss ich noch mal reprodzieren, wenn ich den nächsten Test mit einem bestimmten AccessPoint durch hab.
Oder hast Du (oder jemand anderes) eine Idee, wie ich einem NetzwerkLag auf die Schliche kommen kann ? Ich gehe davon aus, dass sich eines der MQTT(Netzwerk) Geräte "verschluckt" und dadurch immerwieder zu einer Überlastung im Netzwerk führt.

Das andere sind unnötige Events, die durch's System huschen: event-on-...Attribute helfen hier.
Bei DOIF-Tools besteht die Möglichkeit Events "zählen" zu lassen (pro Modul/pro Zeit)...

DOIFs habe ich so gut wie gar nicht im Einsatz (komme einfach irgendwie bei der Syntax durcheinander) und Events werden in jedem Fall eingeschränkt: Ich führe bei jedem Device immer erstmal ein event-on-change .* ein und DANN schränke ich diese beim Einrichten je nach Bedarf ein. Das bedeutet nicht, dass ich auch ein paar total unsinnige Events drin hab. Aber es wird ganz sicher nicht von jedem Gerät alles mit verfolgt.

Das andere mit den Notifiys ist (wenn auch für dieses Problem) definitiv eine Sache für die ToDo Liste, weil ich zu 95 % notifys nutze die dann auf Perl Eben ausgesondert werden und natürlich oft mit if else. Allerdings hab ich auch hier versucht drauf zu achten, dass sie nicht auf zu viel reagieren. - Ist aber sicher verbesserungsfähig und landet deshalb auf der ToDo.

Würde mich über weitere Ideen, Tipps und Vorschläge sehr freuen und such derweil mal weiter im Netzwerk - Hier vermute ich das Problem

Viele Grüße
Andreas

[Beta-User]

Vielleicht noch eine Anmerkung zu den notifyRegexen: Das ist keine normale Regex-Sprache, und wie "trennscharf" die Regexe sind, kann man eigentlich auch auf der Detailseite jedes notify sehen.

Es gibt btw. auch eine spezielle Funktion, mit der man die "Trennschärfe" testen kann:

Code Auswählen Erweitern

{ notifyRegexpCheck('<notify-Rgex-hier rein<') }

Zu MQTT noch:
- MQTT2_SERVER oder externer Broker?
- IO dann MQTT2_CLIENT oder MQTT?
- Ist eine MQTT_GENERIC_BRIDGE im Spiel und gibt es ggf. ein "globalPublish"?

Falls (!) es (auch) ein Problem mit MQTT2-IO's zu sein scheint: Bitte separaten Thread aufmachen und ggf. hierher verlinken (kann dann direkt geschlossen werden), sonst kann es sehr gut sein, dass Rudi das hier nicht sieht.

[MadMax-FHEM]

Vielleicht noch eine Anmerkung zu den notifyRegexen: Das ist keine normale Regex-Sprache, und wie "trennscharf" die Regexe sind, kann man eigentlich auch auf der Detailseite jedes notify sehen.

Es gibt btw. auch eine spezielle Funktion, mit der man die "Trennschärfe" testen kann:

Code Auswählen Erweitern

{ notifyRegexpCheck('<notify-Rgex-hier rein<') }

Das ist interessant, danke!

Ich hab mal ein wenig "rumgespielt"...
...aber: was soll da rauskommen bzw. was "sagt" mir das dann?

Beispiel:

{ notifyRegexpCheck('.*:battery.*') }

->

.*:battery.*: no match (ignored)

heißt was?

no match stimmt nicht, weil damit bekomme/prüfe ich meine Batteriestände...
...und das tut...

oder

{ notifyRegexpCheck('ECHO_.*:currentArtist:.*') }

->

ECHO_.*:currentArtist:.*: devspec ECHO_709405XXXX,ECHO_G070L8XXXX,ECHO_G070L81XXXXX,ECHO_G070XXXX,ECHO_G090L90XXXXX,ECHO_G090LXXXX, usw. (OK)

ok, das verstehe ich noch (denke ich   )...


Gruß, Joachim

[Beta-User]

...es geht auch nicht darum, ob es "tut", sondern, ob es unter "Verteilungsgesichtspunkten" optimal ist:

Ob also fhem.pl beim "dispatchen" der Events direkt weiß, bei welchen Devices es die NotifyFn aufrufen muß, oder ob
(EDIT mit klarerer Formulierung)
ein Eventhandler eben "alle Events" erhält und  "alle Events" dann intern prüfen, eb etwas mit der Info anzustellen ist,
(/EDIT)
was entsprechend ineffizient ist (so jedenfalls mein bisheriges Verständnis).

[flummy1978]

Holla,

Es gibt btw. auch eine spezielle Funktion, mit der man die "Trennschärfe" testen kann:

Code Auswählen Erweitern

{ notifyRegexpCheck('<notify-Rgex-hier rein<') }

Cool ... das ist auf jeden Fall ein sehr gutes Tool, damit ich das o.g. mal durchgehen kann ... dankeschön dafür

Zu MQTT noch:
1- MQTT2_SERVER oder externer Broker?
2- IO dann MQTT2_CLIENT oder MQTT?
3- Ist eine MQTT_GENERIC_BRIDGE im Spiel und gibt es ggf. ein "globalPublish"?

Ich hoffe ich ordne die Antworten richtig zu (weil für mich MQTT2_Client = MQTT ist  )
1 MQTT2_Server

Code Auswählen Erweitern

Internals:
   CONNECTS   38
   DEF        52709 global
   FD         13
   FUUID      5cb4d159-f33f-8d79-e538-336765cb048a4d76
   NAME       brok_MQTT2
   NR         103
   PORT       52709
   STATE      Initialized
   TYPE       MQTT2_SERVER
2. Zigbee Bridge und Wlan Geräte alle als MQTT2_CLIENT eingerichtet.
3. Schon mal gelesen, aber aber kann ich so grad nicht zuordnen und finde auch nichts dergleichen in der gesamten Config. GlobalPublish höre ich grad zum ersten mal und kann mir daher nicht vorstellen, dass ich sowas eingerichtet habe *grübel*

Falls (!) es (auch) ein Problem mit MQTT2-IO's zu sein scheint: Bitte separaten Thread aufmachen und .....

Ich muss erstmal herausfinden, was ich genau deaktivieren muss, bevor ich sagen kann woran es liegt. Aktuell läuft das System ohne die Zigbee Bridge (Also den zigbee2mqtt Prozess auf dem Raspi gestoppt) und bisher (45 Min) ohne Freeze, aber ich freu mich diesmal nicht zu früh (hab ich nämlich schon 3 mal gemacht 

Vielen Dank an alle Hilfewilligen
VG
Andreas

[MadMax-FHEM]

...es geht auch nicht darum, ob es "tut", sondern, ob es unter "Verteilungsgesichtspunkten" optimal ist:

Ja, war etwas "plakativ" formuliert 

Ob also fhem.pl beim "dispatchen" der Events direkt weiß, bei welchen Devices es die NotifyFn aufrufen muß, oder ob der Event eben "an alle" verteilt werden muß und "alle" dann intern prüfen, was mit der Info anzustellen ist, was entsprechend ineffizient ist (so jedenfalls mein bisheriges Verständnis).

Hmmm, ok.

Ich spiele mal noch ein wenig rum...
...wobei da wo ich nat. ein bestimmtes Device mit einer Auswahl an Readings angebe (1. Beispiel) da leuchtet mir ein, dass das nat. eher "eingegrenzt" ist als das "Battery-Beispiel"...
...aber wenn ich nicht jedes mal nachkaspern will, wenn ein neues Batterie-Gerät dazu kommt, wird das wohl so bleiben müssen

Aber schön, so kann man wenigstens mal drüber prüfen, ob es so "greift" wie gedacht (Echo-Beispiel)...

Danke, Joachim

[Beta-User]

Ich hoffe ich ordne die Antworten richtig zu (weil für mich MQTT2_Client = MQTT ist  )
1 MQTT2_Server
[...]

Ähm, kapiere ich nicht. Mal angenommen, alles läuft in demselben FHEM, brauchst du MQTT2_CLIENT NICHT. Das ist NUR erforderlich, wenn der Broker auf einem anderen Rechner läuft (oder ein 2. unter einem anderen Port).

Mach' mal

Code Auswählen Erweitern

list TYPE=MQTT2_CLIENT DEF
list TYPE=MQTT2_DEVICE IODev
IODev sollte (im Regelfall) bei allen auf den MQTT2_SERVER direkt verweisen oder eben auf einen CLIENT, der _nach außen_ zeigt.

[flummy1978]

Ähm, kapiere ich nicht. Mal angenommen, alles läuft in demselben FHEM, brauchst du MQTT2_CLIENT NICHT. Das ist NUR erforderlich, wenn der Broker auf einem anderen Rechner läuft (oder ein 2. unter einem anderen Port).

Ich habe MQTT2_Client mit _device verwechselt ... sorry:
Ich habe einen alternativen Port fürs mqtt eingerichtet. Darauf "zielen" eben auch alle Devices.

1. list TYPE=MQTT2_CLIENT DEF
2. list TYPE=MQTT2_DEVICE IODev:

1. Gibt nichts heraus (kein Device)
2. Spuckt alle meine Devices aus, die als MQTT2_DEVICE eingerichtet sind. Alle haben hinten dann den gleichen IODev:

Code Auswählen Erweitern

D1_Temp_SZ               brok_MQTT2
EG_KUE_SD_01_Radio       brok_MQTT2
EG_KUE_spuelma_tuer      brok_MQTT2
EG_WZ_SD_01_handy        brok_MQTT2
Ersatz_Xiaomi_tempsensor     brok_MQTT2
GH_garten_ventile        brok_MQTT2
Licht_EG_FL_abstell      brok_MQTT2
Licht_EG_FL_decke_garderobe     brok_MQTT2
.....tbc......

(kleine Anmerkung - 3 Std habe ich bisher noch nicht ohne Aussetzer geschafft - Immernoch Zigbee Dienst deaktiviert)
Viele Grüße
Andreas

[flummy1978]

(kleine Anmerkung - 3 Std habe ich bisher noch nicht ohne Aussetzer geschafft - Immernoch Zigbee Dienst deaktiviert)

So viel dazu ... Jetzt ist nicht nur guter Rat teuer, der ist auch noch Gold wert.

Ich denke mal (fürchte oder was auch immer) es liegt vielleicht doch nicht an Fhem sondern an irgendeinem Gerät im Netzwerk. Die o.g. Variante hat ca 3:45 Std gehalten, dann kamen die ersen Lags wieder ( somit auch Freezmon Meldungen ) - Das Ganze ist allerdings passiert, als mein Enigma2 Receiver gestartet wurde. Dieser ist auch im Netzwerk in Fhem eingebunden und löst 1 notifiy aus. Aber 1x mit den Freezes angefangen, spamt das System mir das Log zu..... Irgendwer eine Idee wie ich da rangehen könnte ? *grübel* 
Außer irgendwelche Netzwerkgeräte ständig aus dem Netz zu lassen um dann wieder festzustellen, dass es doch nicht daran lag, fällt mir grad irgendwie nicht ein 

VG
Andreas

[Wernieman]

Mal als schnelle Frage ... was sagt denn der Kernel-Treiber zum Netzwerk, bzw. sind viele Defekte Netzwerkpackete unterwegs?

Code Auswählen Erweitern

/sbin/ifconfig -a | grep error
Vor allem im Fehlerfalle mal testen.

Sollte so aussehen:

Code Auswählen Erweitern

/sbin/ifconfig -a | grep error
        RX errors 0  dropped 8155  overruns 0  frame 0
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        RX errors 0  dropped 0  overruns 0  frame 0
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[flummy1978]

Hallo,

vielen Dank für Deinen Vorschlag, Werniemann, aber scheint so leider nicht die richtige Richtung zu sein:

Mal als schnelle Frage ... was sagt denn der Kernel-Treiber zum Netzwerk, bzw. sind viele Defekte Netzwerkpackete unterwegs?

Code Auswählen Erweitern

/sbin/ifconfig -a | grep error
Vor allem im Fehlerfalle mal testen.

Ich habe grad mal Freezmon eingeschaltet, danach kamen direkt 2,3 Freeze Meldungen (Es sind alle Netzwerkgeräte aktiv, die es auch sonst auch waren) :

Code Auswählen Erweitern


pi@fhempi:~ $ /sbin/ifconfig -a | grep error
        RX errors 0  dropped 8163*  overruns 0  frame 0
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        RX errors 0  dropped 0  overruns 0  frame 0
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        RX errors 0  dropped 0  overruns 0  frame 0
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Mehrmals durchlaufen und variiert durchgend zwischen 8111 und 8169

Oder irre ich mich ?

VG
Andreas

[Wernieman]

dropped ist nicht schlimm, z.B. werden BroardCast Packete, die nicht zum Gerät passen, gedropopt.Siehe auch mein letzten Beitrag

Es war nur mal eine Idee, auf die Schnelle. Du hast als Switch bestimmt einen normalen, nicht managbaren?

[flummy1978]

Es war nur mal eine Idee, auf die Schnelle. Du hast als Switch bestimmt einen normalen, nicht managbaren?

Doch der ist Managebar (zumindest der, an dem ich "wichtige" Anschlüsse habe). Hab ihn allerdings nicht konfiguriert - Der läuft also noch als Standard Switch.  In meiner Fehlersuchewut hab ich auch diesen (vorsichtshalber) Resettet, damit ist auch die Statistik der Ports dort nur seit dem Neustart:
Port   Empfangene Bytes   Gesendete Bytes   Pakete mit CRC-Fehlern
1   3816926   6253684   0
2   1652396   4626704   0
3   0   0   0
4   6408785   8151289   0
5   9632346   19438073   0
6   97561771   16751474984   0
7   2806860   19759419   0
8   238412   3499201   0
9   0   0   0
10   0   0   0
11   16600836484   94382571   0
12   0   0   0
13   0   0   0
14   2972859   6355218   0
15   9816075   10080688   0
16   167814394   16141469   0

Dort sind also bisher auch keine Fehler erkennbar.... Oder hattest Du eine andere Idee für den Switch?

VG
Andreas