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

[Beta-User]

Hmm, evtl. auch mal in global nach der dns-Auflösung sehen?

Falls da eine Fritzbox im Hintergrund die Adressvergabe macht, kann es auch an der liegen...

[Wernieman]

Also scheinbar an der Netzwerkhardware liegt es nicht. Die Error vor dem Reset währen interessant gewesen.

War nur so eine Idee ...

[flummy1978]

Hallo,

Hmm, evtl. auch mal in global nach der dns-Auflösung sehen?
Falls da eine Fritzbox im Hintergrund die Adressvergabe macht, kann es auch an der liegen...

mhm ich dachte eher, wenn die Frithbox die Adressvergabe NICHT macht, führt es oft zu lags, wenn man DNS in global nicht eingetragen hat und zwischendurch das Internet weg ist ?
Ich hab bei mir DNS in global eingetragen (Fritzbox) zu 99,99 (Ein Radio und TV die nicht in FHEM sind) haben sonst alle geräte eine feste IP. D.h. Die Fritte vergibt k(aum) bzw keine Adressen, außer im separaten Gastnetzwerk.

War nur so eine Idee ...

Die Tabelle sieht jetzt allerdings nach 2 Tagen Betrieb (und unzähligen "Hängern") - immernoch genauso aus. :
Port   Empfangene Bytes   Gesendete Bytes   Pakete mit CRC-Fehlern
1   146709663   4408459808   0
2   32968127731   5312678454   0

Alle CRC Fehler, Felder sind leer.... 
Ich bin um jeden NOCH so kleinen Tipp dankbar, denn das führt einfach dazu, dass ich dort wieder was suchen kann. Ich bin der Meinung mich ansich ganz gut auszukennen, aber so langsam aber sicher fast schon am Ende mit meinem Latein 

Was mich allerdings zu meiner aktuellen Vermutung führt:
Halten es die Netzwerkspezies für möglich dass der Fehler aus der Fritzbox kommt, obwohl sie (eigentlich) läuft und keine Fehler anzeigt ?

Mich wundert einfach, dass ich aus keinem Gerät speziell den Fehler reproduzierbar verhindern kann... D.h.: (Alle Geräte sind im Netzwerk und zumeist auch in Fhem) Ich mache einen Unifi AccessPoint aus - Fehler weg. Ich mach Enigma2 Receiver an => Fehler da. Engima2 aus, Hotspot aus anderen Hotspot aus / an, Mehr Traffic verursachen -> Fehler da (zumindest verschwindet der Drucker dann) und vor allem appropos Drucker:
Dieser wird sofort als "Offline" angezeigt, sobald der Fehler mal durch Freezmon angezeigt wurde bzw da war. Der Drucker ist aber sowohl Ping als auch Webaufruf erreichbar. Nach der Win Problembehandlung ist dieser wieder da und geht beim nächsten Fehler wieder Offline.....   

Meine Idee für diesen Fall (weil die Fritte beim ISP als eigener Router eingetragen ist ):
Mit einer Ersatz Fritte das Netzwerk herstellen (mit gleichen IPs etc) und die Fritzbox, die das Internet zur Verfüfung stellt, NUR dafür zu konfigurieren und dann mal sehen ob die Ersatzfritzbox den gleichen Fehler macht - Ist aber ein sehr großer Config Aufwand, meine Frauch brauch beruflich Inet an diesem WE und ich hab die Ersatz Fritzbox erst gestern bekommen. Das sind die Günde warum ich es bisher noch nicht getestet hab.

Bin weiterhin um jeden Tipp / Idee Möglichkeit und Antwort sehr dankbar.
Vielen Dank  und Viele Grüße
Andreas

[Wernieman]

Verwedest Du die Fritte auch als Switch?

[flummy1978]

Verwedest Du die Fritte auch als Switch?

Ja: Es ist ein Switch angeschlossen, und an LAN2 und LAN3 jeweils nochmal einzelne Geräte... Meinst Du es könnte damit was zu tun haben ? (Was schon immer lief ?)

Tante Edith ergänzt noch aktuellen Stand:
Über Nacht habe ich Fhem runter gefahren. Heute morgen Rechner an - Drucker online. Dann ca 1 Std unterwegs gewesen, als ich wiedergekommen bin, war der Drucker wieder offline.  Ergo ist zu 99,9999% n Bock allgemein im Netzwerk

[Wernieman]

Wie misst Du "Offline"?

[frank]

welche fritzbox?
ich würde mal so viele funktionen wie möglich in der fritzbox abschalten und anschliessend neu booten. zb: wlan, dect, fon, ab, fax, ....
usb3 stick angeschlossen?


und mal mit apptime modul in fhem schauen:
1. apptime zb 30 min laufen lassen, wenn keine störungen existieren. dann "apptime max" aufrufen und ausgabe speichern.
2. dann ein paar minuten im störungsfall.
vorher alte daten mit "apptime clear" löschen.

[flummy1978]

Wie misst Du "Offline"? : Der Drucker wird mir in der Win - Drucker - Umgebung als Offline angezeigt (läuft seit ca 5 Jahren und war sonst nie "nicht" erreichbar)

welche fritzbox?: 6490. Die von Dir aufgelisteten Funktionen sind komplett aus. Telefon über den ISDN Anschluss. Wlan geht über die Unifis, Dect AB und Telefonbuch ist auch komplett aus. USB Stick war da glaube ich noch nie einer dran USB3 schon gar nicht.

Zu apptime...
Störungen (in Fhem) tauchen ja eigentlich auf, im Sinne von Freezes. Diese zeigen sich aber immer nach dem gleichen Muster auf, nämlich zuerst zeigt er die S7 (SPS) Verbindung als Fehler:
S7_GetUpdate

1.12 possibly caused by: tmr-S7_GetUpdate(dev_KG_S7_SPS)
(zig Male)
also lösche ich alle Verbindungen die mit der SPS zu tun haben als nächstes kommt dann:
1.417 possibly caused by: tmr-at_Exec(Sprengercountdown) Dieses Gerät ist aber INAKTIV 
Also lösche ich das at Sprengercountdown... dann kommt irgendwann:
1.076 possibly caused by: no bad guy found
oder
1.206 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(brok_MQTT2) tmr-HttpUtils_Err(N/A)

Natürlich werden die Fehler danach immer seltener und immer weniger, weil weniger Netzwerktraffitc besteht und weil die SPS bsw. alle 0.5 Sek nach dem aktuellen Zustand abgefragt wird (Das läuft aber auch schon seitdem ich FHEM hab, weil es das  erste Gerät war, dass ich aktiviert habe - Allerdings auch ohne Freezmon)

Das Vorher / Nachher mit apptime teste ich auf jeden Fall auch noch zusätzlich.

Vielen herlichen Dank bis hierhin schon für Eure Mühe und Willen mir helfen zu wollen

VG
Andreas

[Wernieman]

Dann hättest Du noch testen können, ob der Drucker "pingbar" war. ist er eigentlich pr "namen" oder per IP eingetragen?

Ich tippe immer weiter auf Netzwerkprobleme.

Btw: Du verwendest IPs .. oder doch Namen?

[flummy1978]

Dann hättest Du noch testen können, ob der Drucker "pingbar" war. ist er eigentlich pr "namen" oder per IP eingetragen?

Ich tippe immer weiter auf Netzwerkprobleme.

Genau .. ich auch. Nur zuordnen, kann ich diese irgendwie noch gar nicht 
Deine Frage ob der Drucker dann pingbar / erreichbar ist, hatte ich 4 Beiträge zuvor bereits beantwortet. Macht aber nichts, weil man bei der Menge an Infos sicher schnell was übersehen kann 
Daher:

appropos Drucker:
Dieser wird sofort als "Offline" angezeigt, sobald der Fehler mal durch Freezmon angezeigt wurde bzw da war. Der Drucker ist aber sowohl Ping als auch Webaufruf erreichbar. Nach der Win Problembehandlung ist dieser wieder da und geht beim nächsten Fehler wieder Offline.....   

Der Drucker selbst ist (wie alle geräte die irgendwie eine Kommunikation innerhalb des Netzwerkes selbst brauchen), per IP eingebunden. Die DNS Seite der Fritte zeigt hier und dort mal einen Namen an, den ich aber kaum verwende. Lediglich die Diskstation, die Enigma2 Receiver und FHEM werden mit dem Namen aufgerufen. Allerdings nur vom PC aus (d.h. in keiner Config) und es funktioneren identisch auch alle IP Aufrufe für diese Geräte.

Ergänzung zum aktuellen Stand:
Ich habe nochmal die Config der Fritte kontrolliert und bis auf ein paar ungenutzte Portfreigaben, die deaktiviert waren und ich gelöscht habe, nichts geändert. Ich hab allerdings auch die SPS aus der Fritzbox gezogen und sie mit an den 16 Port Switch gehangen. Nu hab ich zwar seid 3 Std das Drucker offline Problem nicht mehr, aber stattdessen sie die Abfragelags innerhalb vom Apptime bei Fhem wieder größer geworden (Zufall?)

VG
Andreas

[Wernieman]

Verwende mal die Fitte nur als Router, d.h. 1 Netzwerkkabel, sonst nichts.

Hast Du das Routing der fritte geändert? Also spezielle Netzwerkrouten eingetragen?

Kenne viele FritzBox Probleme, aber so etwas ist mir unbekannt ....

[flummy1978]

Verwende mal die Fitte nur als Router, d.h. 1 Netzwerkkabel, sonst nichts.

Jupp genau das war das was ich probiert hab:

Ich hab allerdings auch die SPS aus der Fritzbox gezogen und sie mit an den 16 Port Switch gehangen. Nu hab ich zwar seid 3 Std das Drucker offline Problem nicht mehr.....

Es steckt also jetzt nur noch ein LAN Kabel zum 16Port Switch.

Eine Route ist auf einen Raspberry aktiv auf dem OpenVPN läuft (VPN Config, die eben auch an einem DS Lite Anschluss funktioniert (hat) hab ja jetzt einen FULL Dual Stack Anschluss, an dem die gleiche VPN weiterhin läuft)

Jetzt stellt sich die Frage ob nicht vielleicht doch Fhem ein Problem damit hat .... Eben, weil dort so viele "Meldungen" meckern in Apptime:

Code Auswählen Erweitern


name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call

tmr-SunSetShuttersAfterTimerFn           HASH_unnamed                           265       10    1082.21   108.22   266.99    72.74 02.11. 19:00:02 HASH(0x48db398)
tmr-at_Exec                              HASH(0x3dc7cf0)                        199       16    2289.58   143.10   513.57   106.28 02.11. 16:57:40 HASH(at_BUE_Temperatur)
tmr-CUL_HM_valvePosUpdt                  valvePos                               166      284   28832.14   101.52  2100.46   194.20 02.11. 16:15:52 valvePos:00800101
tmr-S7_GetUpdate                         HASH(0x145a330)                        160    12305  452486.94    36.77  2261.32   139.43 02.11. 17:33:48 HASH(dev_KG_S7_SPS)
tmr-ROLLO_Timer                          HASH(0x4601298)                        151        1     151.57   151.57  2037.16  2037.16 02.11. 18:30:09 HASH(Rollo_OG_SZ_01)
tmr-CUL_HM_valvePosUpdt                  valvePos                               166      284   28832.14   101.52  2100.46   194.20 02.11. 16:15:52 valvePos:00800101


Das sind so die höchsten delays im groben Überblick in der Laufzeit von 16 Uhr bis jetzt in etwa... komischerweise gibt es da so ziemlich alle Möglichkeiten der Devices. Wlan, Lan aber eben auch Homematik Funkteile. Sollte ich bis morgen keine Aussetzer beim Drucker haben, wäre meine Idee morgen die aktuelle Config (nochmal) von einem anderen Raspberry aus laufen lassen und testen....

So langsam frisst mich der Fehler echt auf ... bis zur dieser Fehlersuche war ich der Meinung ich kenne mich da aus 

Grüße
Andreas

[Wernieman]

Tja ... warum brauchst Du auch so ein Kompliziertes Netzwerk .... ;o)

[frank]

die funktion tmr-S7_GetUpdate wurde in dieser zeit über 12000 mal aufgerufen.
muss das sein?
ich dachte s7 ist "schlau" und arbeitet "autark".

[flummy1978]

Tja ... warum brauchst Du auch so ein Kompliziertes Netzwerk .... ;o)

Könnte es kaum besser beschreiben 
Mal ehrlich ... WENN alles läuft, ist es ja wirklich genial - und bei alldem was ich hier laufen habe (inklusive vieler Sicherheitsfallstricke), läuft es schon sehr sehr lange stabil und jetzt wirklich zum ersten mal ein sehr komplizierter Fehler....

die funktion tmr-S7_GetUpdate wurde in dieser zeit über 12000 mal aufgerufen.

Tja ... das ist eine gute Frage... Je länger ich mich mit diesem Fehler befasse umso öfter komme ich in den Genuss zu sagen: Ja die SPS ist so schlau. Aber die Anbindung in Fhem wohl nicht so .... Laut Config fragt er alle nach festgelegtem Intervall die Informationen ab (damit diese in Fhem immer aktuell sind) in meinem Fall alle 0,5 sek was natürlich zu sehr vielen Anfragen führt. Grundsätzlich ist so eine Anfrage wahrscheinlich nicht länger als ca 20 ms. D.h. eigentlich sind es 480 ms nichtstun und 20 ms Abfragen......
Wenn es NUR die S7 wäre, die diese Fehler ausspuckt, wäre diese schon längst rausgeflogen. Aber es sind eben auch mal hier und da andere Geräte die Fehler ausspucken.

Kann mir jemand sagen wofür die Funktion:  tmr-__ANON__ oder  prio-__ANON__(N/A) steht ?
Die hab ich auch das ein odere andere mal im Freeze Log. Das kommt mir komisch vor.

Sowas wundert mich auch total:
tmr-at_Exec                              HASH(0x49383a0)                          8     4753    7901.34     1.66  2269.60   162.69 02.11. 18:01:39 HASH(Sprengercountdown)
Sprengercountdown ist ein at das deaktiviert ist... Wie kann des 8 x aufgerufen werden und ein Delay haben / verursachen?

Ich werde jetzt mal Zähler, und S7 deaktivieren, das sind dann die größten Reccourcenfresser... dann mal schauen.

[frank]

Wenn es NUR die S7 wäre, die diese Fehler ausspuckt, wäre diese schon längst rausgeflogen. Aber es sind eben auch mal hier und da andere Geräte die Fehler ausspucken.

das umstecken der s7 an den externen switch hat ja schon gezeigt, dass die fritzbox "entlastet" wurde, da der drucker nun wieder richtig angezeigt wird.
zu den 12000 anfragen gibt es ja auch mindestens so viele antworten, die über das netzwerk rauschen.

auf fhem seite wird ja sicherlich nicht nur die funktion aufgerufen. die antworten müssen ja auch verarbeitet und weitergereicht werden.
wieviele events werden denn dabei erzeugt? die belasten fhem ja noch zusätzlich.
kannst du noch alle events auf dem eventmonitor in ruhe lesen?


sortier mal apptime nach count.

[flummy1978]

Hallo Frank,

vielen Dank auch Dir noch mal für Deine Zeit und Mühe mir helfen zu wollen. Bin Dir (und wernieman und allen anderen die bisher geantwortet haben) da wirklich sehr sehr sehr dankbar weil man in solchen Fällen sicherlich schnell aufgeben könnte, wenn es einen selbst nicht betrifft   

On Topic ... alle Fragen / Bemerkungen der Reihe nach:

Umstecken der S7: Sicherlich richtig, dass es jetzt (bis jetzt) funktioniert. Was mich dabei einfach total wundert, ist dass es ja schon immer funktioniert hat..... und ich bin ja nun schon sehr lange am Suchen, was dazu geführt hat, dass ich auch sehr sehr oft in mich hinein gehorcht hab um mich zu erinnern, ob ich was bestimmtes geändert habe. Die Frage war dann doch immerwieder - Nein 

12 Anfragen Bin mir nicht sicher ob ich das richtig zuordne, aber 12000 Kommunikationen innerhalb von ca 3 Std, bei denen jeweils genau 1 BIT abgefragt wird sind grob gesehen pro sekunde eine Abfrage. Ich würde jetzt schätzen (wirklich geschätzt) dass bei einem Stream oder ähnlichem mehr übers Netzwerk geht , oder ? Aus den oberen 12000 Anfragen wurden zu dem Zeitpunkt insg. 0 Events erzeugt, weil sich nichts geändert hatte. Er hat ja nur den aktuellen Zustand abgefragt und dieser war gleich.
Unabhängig davon habe ich jetzt mal testweise die Abfragezeit von 0,5 auf 4 Sek gesetzt. Bedienung VON Fhem ist die gleiche Anzeige ZU Fhem kann sich um bis zu 4 Sek verzögern. Das ist mir momentan aber erstmal egal.

Eventverarbeitung: Ich habe mir angewöhnt, alle paar Tage / Wochen je nachdem wie oft ich an Fhem was geändert habe, regelmäßg in den Eventmonitor zu schauen. D.h. eigentlich läuft der IMMER sobald ich was ändere und ich versuche schon sehr sehr drauf zu achten kaum mehr als nötige Events zu erzeugen. Das klappt sicher nicht immer........

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.

Sicherlich ist das ein oder andere unnötige Event drin, aber wenn ich Eventmonitor mit .* laufen habe ist die unterste Zeile nach (gestoppten) ca 60 Sek erst oben angekommen (je nach Zustand - Wenn Zähler und Wetter grad ein Event erzeugen, könnten es auch schon mal 15-20 sek sein - ohne beide dauert es auch schnell mal 2 min). Also um Deine Frage zu beantworten: zu 99% kann ich alle Events mitlesen.

sortier mal apptime nach count:

Code Auswählen Erweitern

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
allowedMqtt                              allowed_Authorize                        1    41467    1338.46     0.03     0.00     0.00 02.11. 23:48:52 HASH(allowedMqtt); HASH(telnetForBlockingFn_1604328169_127.0.0.1_34636); cmd; perl; (undef)
allowedTelnet                            allowed_Authorize                        1    41467     816.68     0.02     0.00     0.00 02.11. 21:03:32 HASH(allowedTelnet); HASH(telnetForBlockingFn_1604328169_127.0.0.1_55912); cmd; perl; (undef)
DBLogging                                DbLog_Log                              121    40237   80255.41     1.99     0.00     0.00 02.11. 17:54:20 HASH(DBLogging); HASH(Wetterstation)
FileLog_Logfile                          FileLog_Log                              2    40237    9996.60     0.25     0.00     0.00 03.11. 01:56:13 HASH(FileLog_Logfile); HASH(virtual_BAD_OG_Temperatur)
Freezmonitor                             freezemon_Notify                         1    40237    1960.29     0.05     0.00     0.00 02.11. 23:14:34 HASH(Freezmonitor); HASH(EG_KUE_HM_kuehl_back_Pwr)
KG_haupt_zaehler                         HourCounter_Notify                      56    40237   18662.15     0.46     0.00     0.00 02.11. 17:14:42 HASH(KG_haupt_zaehler); HASH(KG_SYS_haupt_zaehler_S0)
Nebenzaehler                             ElectricityCalculator_Notify           196    40237   57970.89     1.44     0.00     0.00 03.11. 02:13:37 HASH(Nebenzaehler); HASH(wemoszaehler_EG)
RG_test                                  readingsGroup_Notify                     5    40237    4861.00     0.12     0.00     0.00 03.11. 11:00:55 HASH(RG_test); HASH(global)
SYS_START_FB_Kalender_noty               notify_Exec                              0    40237    1175.90     0.03     0.00     0.00 02.11. 23:57:41 HASH(SYS_START_FB_Kalender_noty); HASH(Hauptzaehler)
TestWemos_LOG                            FileLog_Log                              2    40237    8502.60     0.21     0.00     0.00 02.11. 18:11:21 HASH(TestWemos_LOG); HASH(virtual_BAD_OG_Temperatur)
WEB                                      FW_Notify                                0    40237     632.42     0.02     0.00     0.00 03.11. 05:48:22 HASH(WEB); HASH(dev_Garten_shelly25)
WEB2                                     FW_Notify                                0    40237     330.84     0.01     0.00     0.00 03.11. 02:14:15 HASH(WEB2); HASH(dev_Garten_shelly25)
WEB3                                     FW_Notify                                0    40237     319.10     0.01     0.00     0.00 03.11. 07:44:26 HASH(WEB3); HASH(dev_OG_BAD_Temp_Sensor)
WEBphone                                 FW_Notify                                0    40237     317.33     0.01     0.00     0.00 03.11. 02:50:03 HASH(WEBphone); HASH(OG_SZ_SD_02Bett_LI)
WEBtablet                                FW_Notify                                1    40237     313.73     0.01     0.00     0.00 02.11. 22:26:30 HASH(WEBtablet); HASH(wemoszaehler)
WEBweatherstation                        FW_Notify                                0    40237     313.07     0.01     0.00     0.00 02.11. 16:27:54 HASH(WEBweatherstation); HASH(MQTT_wemoszaehler)
eventTypes                               eventTypes_Notify                        2    40237    7636.78     0.19     0.00     0.00 03.11. 10:41:20 HASH(eventTypes); HASH(EG_KUE_HM_kuehl_back_Pwr)
heatingInfo                              readingsGroup_Notify                    19    40237    4069.66     0.10     0.00     0.00 02.11. 16:45:31 HASH(heatingInfo); HASH(HEAT_OG_SZ_HZ_Clima)
hminfo                                   HMinfo_Notify                            0    40237     785.35     0.02     0.00     0.00 02.11. 17:19:30 HASH(hminfo); HASH(wemoszaehler)
noti_OG_SZ_conditions                    notify_Exec                            500    40237  749549.43    18.63     0.00     0.00 03.11. 10:56:55 HASH(noti_OG_SZ_conditions); HASH(MQTT2_shellydimmer_D3E457)
noti_POW_aktivity                        notify_Exec                              2    40237   12875.81     0.32     0.00     0.00 02.11. 23:41:29 HASH(noti_POW_aktivity); HASH(virtual_SZ)
noti_onfortimer                          notify_Exec                              6    40237   27752.58     0.69     0.00     0.00 02.11. 19:02:26 HASH(noti_onfortimer); HASH(Licht_EG_FL_abstell)
noti_rollotaster                         notify_Exec                              2    40237    8695.18     0.22     0.00     0.00 02.11. 18:44:50 HASH(noti_rollotaster); HASH(HEAT_OG_BAD_HZ_Clima)
rg_SYS_ALL_Licht                         readingsGroup_Notify                    10    40237    4596.11     0.11     0.00     0.00 03.11. 11:00:55 HASH(rg_SYS_ALL_Licht); HASH(global)
rg_SYS_ALL_rollo_level                   readingsGroup_Notify                    10    40237    3025.18     0.08     0.00     0.00 03.11. 11:00:55 HASH(rg_SYS_ALL_rollo_level); HASH(global)
rg_SYS_ALL_rollo_shades                  readingsGroup_Notify                    11    40237    2920.54     0.07     0.00     0.00 03.11. 11:00:55 HASH(rg_SYS_ALL_rollo_shades); HASH(global)
rg_SYS_ALL_rollo_times                   readingsGroup_Notify                    10    40237    2844.80     0.07     0.00     0.00 03.11. 11:00:55 HASH(rg_SYS_ALL_rollo_times); HASH(global)
rg_SYS_ALL_wifi_battery_status           readingsGroup_Notify                    55    40237   17473.11     0.43     0.00     0.00 02.11. 16:34:32 HASH(rg_SYS_ALL_wifi_battery_status); HASH(RESIDENT_ALL)
rg_SZ_Fenster                            readingsGroup_Notify                     1    40237    3085.63     0.08     0.00     0.00 03.11. 01:48:11 HASH(rg_SZ_Fenster); HASH(dev_Robby_Garage_taster)
rg_WZ_Fenster                            readingsGroup_Notify                     0    40237    2851.40     0.07     0.00     0.00 03.11. 00:00:19 HASH(rg_WZ_Fenster); HASH(dev_OG_BUE_decke)
testlog                                  FileLog_Log                              4    40237   13478.13     0.33     0.00     0.00 03.11. 10:56:55 HASH(testlog); HASH(MQTT2_shellydimmer_D3E457)
wemoszaehler                             HourCounter_Notify                     305    40237   96669.58     2.40     0.00     0.00 03.11. 00:00:59 HASH(wemoszaehler); HASH(MQTT_wemoszaehler)
wemoszaehler_EG                          HourCounter_Notify                     217    40237    3801.32     0.09     0.00     0.00 03.11. 02:13:37 HASH(wemoszaehler_EG); HASH(MQTT_wemoszaehler)
wemoszaehler_KG                          HourCounter_Notify                     170    40237   22097.97     0.55     0.00     0.00 03.11. 08:23:01 HASH(wemoszaehler_KG); HASH(MQTT_wemoszaehler)
wemoszaehler_OG                          HourCounter_Notify                     164    40237   12157.84     0.30     0.00     0.00 03.11. 00:01:51 HASH(wemoszaehler_OG); HASH(MQTT_wemoszaehler)
allowedMqtt                              allowed_Authenticate                     1    35405    5601.95     0.16     0.00     0.00 02.11. 19:46:46 HASH(allowedMqtt); HASH(WEBweatherstation_192.168.0.99_8488); HASH(0xffb758)
allowedTelnet                            allowed_Authenticate                     1    35364    2010.98     0.06     0.00     0.00 02.11. 22:59:22 HASH(allowedTelnet); HASH(WEBweatherstation_192.168.0.99_49987); HASH(0xffb758)
tmr-S7_GetUpdate                         HASH(0x145a330)                        160    31090 1127948.88    36.28  2261.32   114.88 02.11. 17:33:48 HASH(dev_KG_S7_SPS)
tmr-freezemon_ProcessTimer               HASH(0x4987aa8)                        137    27720  116665.59     4.21  2400.87   130.77 02.11. 21:22:17 HASH(Freezmonitor)
tmr-__ANON__                             HASH(0x4baa818)                        109    26952 1279966.44    47.49     0.00     0.00 02.11. 22:02:12
Ist allerdings der Appmonitor seit gestern Nachmittag. Hatte ihne jetzt noch nicht resettet. Das wollte ich gegen 15 Uhr machen, wenn nicht jemand von den Helfenden noch einen Einwand hat, wonach ich schauen sollte 

Viele Grüße
Andreas

[flummy1978]

Auch wenn es möglicherweise niemanden mehr so richtig interessiert, kleine Rückmeldung von meiner Seite:

Ich habe, nachdem ich noch ein wenig rumprobiert hab, urplötzlich von jetzt auf gleich das Fork Speicherproblem "... Cannot fork: Cannot allocate memory....." bekommen, ohne dass ich groß was geändert hab, also war klar. JETZT ist die Chance vielleicht nicht für den totale (dafür ist da doch zu viel drin um es auf einmal zu machen) aber für einen ziemlichen Kahlschlag. Also gab es:

• Buster auf den Raspi
• Neue Zigbee2MQTT Installation
• Einige alte Teile sind aus der Config geflogen, bevor sie eingefügt wurde
• die SPS hat eine 4 sek Überwachungszeit behalten


• Das Netzwerk wird jetzt von einem Unifi USG geregelt (hatte ich hier, wollte ich schon lange einsetzen, nun "musste" ich)
• Ich hab parallel vieles an der Diskstation / Docker getestet und n neues Problem entwickelt (USB Zigbee2mqtt wird nicht mehr erkannt)
• Einige Notifys / Geräte angepasst

Ich bin ehrlich: Die Fritzbox ist mittlerweile zu einem reinen Modem - Gerät degradiert und leitet eigentlich nur noch das Inet an den WAN Port des Unifi USG aber sie hängt halt immernoch mit im Netz.
Freezmon zeigt immernoch ab und zu (WESENTLICH seltener als früher, aber immernoch) nen Freeze der dann vom nem MQTT Gerät kommt, oder eben von der SPS. Daher kann ich nicht abschließend sagen, dass der Fehler endgültig weg ist, aber es läuft soweit, dass ich sagen kann SO lief es immer und ich war damit zufrieden.
Ob Freezmon früher die Freezes gezeigt hätte und ich sie nur nicht gemerkt habe, weiss ich ja nicht, weil ich Freezmon nicht immer drin hatte

Der Vorteil ist, dass ich mich jetzt endlich dazu durchraffen (MUSSTE) konnte, die gemanaged Switches richtig zu konfigurieren (noch zum Teil in Arbeit) Meine Netzwerkstruktur etwas um zu bauen. VLAN einzupflegen, das USG einzusetzen und VPN über die Diskstation bzw das USG einzurichten. Vieles davon läuft schon sehr sehr zufriedenstellend, muss aber noch zum Teil angepasst werden.

Auch wenn wir keinen direkten Einzelverursacher finden konnte, GLAUBE ich dass das Problem überwiegend gelöst ist. Endgültig werde ich das wohl erst bei einem Umzug auf andere Hardware merken und wenn die Fritzbox und SPS eben raus sind. Daher noch mal VIELEN VIELEN VIELEN DANK an alle die mich hier im Beitrag unterstützt haben und mir versucht haben mit jedem noch so kleinem Tipp weiter zu helfen.

Natürlich hab ich dabei auch wieder vieles gelernt

Viele Grüße
Andreas

[Wernieman]

Danke fürs Feedback .. auch wenn es etwas "unbefriedigend" ist ...

Aber lernen .. sollte man doch immer ;o)