Lan adapter disconnected andauernd

[cyberdwarf]

Hallo zusammen,

seit 3 Tagen habe ich bei mir einen HM Lan Adapter zu Testzwecken in Betrieb. Leider disconnected er bei mir auch andauernd.

Hardware ist ein RPi. Den Switch habe ich schon ausgetauscht. Der LAN Apdater bekommt eine reservierte IP Adresse vom DHCP Server.
Firmware vom LAN Adpater ist die 0.961.

Zuerst dachte ich an eine hohe Auslastung von FHEM, aber mittlerweile denke ich das es etwas anderes sein muss.
Er disconnected auch in der Nacht, wenn überhaupt nichts los ist.

Am ersten Tag lief der LAN Adapter noch auf meinem Test RPi. Selbst dort sehe ich die Disconnects im FHEM Log.

WOL und PRESECE sind nicht in Betrieb.

Ein Dauerping läuft von einem anderen System aus ohne Ausreißer durch.

Gruß
Torsten  

[martinp876]

Hallo,

leider hast du die roh-messages zum Adapter nicht aufgezeichnet.
attr global verbose 1
attr global mseclog 1
attr HMLAN1 loglevel 1

Gruss
Martin

[cyberdwarf]

Hallo Martin,

ich habe es jetzt so eingestellt und auf ein Disconnect gewartet.

Gruß
Torsten

[martinp876]

Hi Torsten,

es handelt sich also (bei diesem) um eine fehlende Antwort. Genauer gesagt:
FHEM sendet den keep-alive und hat nach 2 sec noch keine Antwort.

es sieht also nicht um die Probleme aus WOL, die wir schon hatten. FHEM kommt nach 2 sec dran aber die LAN-dose hat nicht geantwortet.

wie weiter machen.... schön waere ein ethernet-mitschnitt (wireshark, AVM capture interface,...) - zusammen mit einem Trace wie eben.

Mögliche Fehler sind, dass das kommando zu langsam gesendet wird, zu langsam verarbeitet wird oder du echte LAN probleme und delays hast.
Normal ist die Antwort in 7ms da, also allgemein funktioniert es bei dir.

Falls du den traffic aufzeichnen willst (kommst du mit ethernet loggern zurecht?) kann ich einmal reinsehen. Aber wenn du unfiltered loggst ist alles drin, was du gemacht hast... ggf auch passwörter.

Evtl findest du aber auch selbst ein mögliche Problemquelle experimentell...

du kannst die Wartezeit aber auch verlaengern: 00_HMLAN.pm line 485
  InternalTimer(gettimeofday()+1, "HMLAN_KeepAliveCheck", "keepAliveCk:".$name, 1);

beispielsweise auf 5 oder 10 setzen.

Beachte aber dass irgend etwas in deinem Netzwert verzögert arbeitet


Gruss
Martin

[Willi]

du kannst die Wartezeit aber auch verlaengern: 00_HMLAN.pm line 485
  InternalTimer(gettimeofday()+1, "HMLAN_KeepAliveCheck", "keepAliveCk:".$name, 1);

beispielsweise auf 5 oder 10 setzen.

Hallo Martin,

danke für den Tipp.
Ich habe bei mir jetzt auf 2 Sekunden geändert
485c485
<   InternalTimer(gettimeofday()+1, "HMLAN_KeepAliveCheck", "keepAliveCk:".$name, 2);
---
>   InternalTimer(gettimeofday()+1, "HMLAN_KeepAliveCheck", "keepAliveCk:".$name, 1);

Bei mir kam die Meldung mit dem Disconnect zwar nicht ständig aber trotzdem mehrfach pro Tag zu unterschiedlichen Zeiten. Netzwerkprobleme kenne ich eigentlich nicht. Es mag natürlich sein, dass bei meiner Konfiguration mit vielen Geräten (CUL per FHEM2FHEM-raw, RFXtrx433 per FHEM2FHEM-raw, USWDE1, ECMD) FHEM nicht gerade echtzeitfähig ist......

Gibt es einen Grund den Timeout so klein (1 Sekunde) als default zu setzen?

MfG Willi

[Reinerlein]

Hi Willi,

das liest sich jetzt eher lustig...

Der Parameter den du angepasst hast, legt fest, ob der Timer zurückgestellt werden soll, bis der Startvorgang beendet ist (muss zu true evaluieren, heisst: ungleich 0 sein).
Im späteren Betrieb ist er eher funktionslos, und auf jeden Fall ist es kein Unterschied, ob dort 1 oder 2 steht :-)

Du solltest die Zahl anpassen, die zu gettimeofday addiert wird. Das sind die Sekunden, die der Aufruf verlagert wird. Genauer gesagt gibt man für den internen Timer den nächsten Ausführungszeitpunkt an...

Grüße Reinerlein

[Willi]

Schön, wenn Du Deinen Spass hast....
Dann ändere ich das.
Dann war es eher Zufall, dass kein Disconnect mehr kam.

[martinp876]

@ Reinerlein: korrekt soweit

@Willi
so sollte es aussehen
InternalTimer(gettimeofday()+2, "HMLAN_KeepAliveCheck", "keepAliveCk:".$name, 1);

Grund fuer den Timer ist schnellstmoeglich zu recovern. Normal ist die Antwort in einigen ms wieder da. Sollte FHEM beschaefftigt sein ist es kein Problem, da dann auch die Abfrage verzoegert wird. Wenns mal wieder laenger dauert muss jemand auf der Bremse stehen.

Gruss
Martin

[cyberdwarf]

Hallo Martin,

auch ich danke Dir für den Tipp. Ich habe den Wert jetzt auf 4 gesetzt. Muss dann jetzt nur bei Updates aufpassen.
Sniffen kann ich hier mit meinem Switch leider nicht, mal sehen wie ich das hin bekomme. Ein alter Hub sollte ja gehen!
Mittlerweile habe ich den HMLAN mit einem HM-LC-Sw1PBU-FM produktiv im Einsatz. Funktioniert gut!

Gruß
Torsten

[martinp876]

Hallo Thorsten,

wenn die 1 sec des öfteren zu Problemen führen, bei mehr Usern, werde ich die Zeit verlaengern.
Oder besser mache ich es einstellbar - werden ein Attribut definieren.

Der Ausfall sollte aber zu denken geben. Den default werde ich auf 1sec belassen.

Gruss,
Martin

[Markus]

Meiner Meinung nach kannst du dir die Arbeit sparen
das löst das Problem nicht sondern zeigt nur den log Eintrag nicht mehr an oder irre ich mich jetzt? Der log Eintrag ist mir aber egal nur wen fhem Funksignale nicht mitbekommt stört mich das.

Was ich aber nicht verstehe, bevor ich mir denn lan Adapter gekauft habe hatte ich den cuno in Verwendung und hatte nie ein disconect im log stehen.

Gruß Markus

[martinp876]

Hi Markus,

cuno habe ich nicht, nur CUL. Fuer CUL -  und ich denke auch CUNO - gilt:
- kein keep-alive notwendig. HMLAN ueberwacht die Verbindung und resetet ggf.
- keine alive-ueberwachung von FHEM
- kein "schnelles" wiederholen von messages bei fehlendem ACK
- kein Automatischen senden von ACKs
- kein HM protokoll zwischen CUL/CUNO und FHEM
- kein AES
- keine burst-mode unterstuetzung

So einmal meine Zusammenfassung.
der erste Punkt macht die keep-alive lebensnotwendig bei HMLAN
Den 2. werde ich noch einmal probieren - bei USB sollte FHEM merken, dass die CUL gezogen wurde. Einen SW-fehler kann FHEM nicht erkennen (ist auch kaum notwendig). Wie es bei einer CUNO funtioniert ist mir unklar - wenn man ein device von ethernet nimmt gibt es keine benachrichtigung. Man merkt es wohl erst beim senden einer weiteren Nachricht.

Langer Rede kurzer Sinn: Die Ueberwachung selbst erzeugt disconnects u.a. durch Unzulaenglichkeiten des FHEM timings. Da HMLAN erheblich mehr Funktionen bereit stellt hat eine Ueberwachung eine ganz andere Bedeutung, u.a. fuer das Protokoll.

Zur Aenderung des Timers: Der kann schon einen Sinn machen.
a) HMLAN will alle 30sec einen trigger
b) FHEM ueberwacht, ob HMLAN noch reagiert (aktuell 1 sec).
Level b) stellt sicher, dass FHEM reagiert wenn sich HMLAN nicht meldet und startet einen re-connect. Das erlaubt eine schnellere recovery, solche Fehler hatte ich schon einige.

Eingestellt habe ich, dass der HMLAN in 1sec antworten muss, sonst wird re-connected. Das klappt bei mit 100%. Hat man nun ein schlechtes Netz oder eine ueberlasteten Processor,... kann die Zeit ueberschritten werden. Dann lag es nicht am HMLAN, der waere dann noch putzmunter.
Wenn jemand mit solchen Systemen arbeitet, bei denen eine schlechte Reaktionszeit an der Tagesordnung ist kann er die Zeit einstellen (habe ich schon fertig, kommt in der naechsten Version...). Generell koennte sen System aber Probleme mit der Kommunikation bekommen: reaktionszeiten bei wakeup devices....
Gruss
Martin

[Markus]

Danke für die ausführliche Beschreibung man lernt halt nie aus.

Gruß Markus

[martinp876]

der timer kann jetzt eingestellt werden... mit attributen.

Gruss
Martin

[cyberdwarf]

Hallo Martin,

respTime funktioniert gut!
Bei Gelegenheit werde ich versuchen so einen Disconnect bei mir zu sniffen. Ich muss mir nur noch die passende Hardware besorgen.

Danke und Gruß
Torsten