Lan adapter disconnected andauernd

[martinp876]

Hi,

die beiden aufgezeichneten Disconnects kommen aufgrund eine Zeitueberschreitung.
HMLAN will min alle 30sec gestreichelt werden. FHEM hat einen 2sec Puffer, streichelt also alle 25 sec.
Bei beiden Disconnects kommen die Streicheeinheiten nicht in/time. also nach 30sec.
=> es besteht keine generelle ueberlast
=> irgendwer erzwingt eine FHEM-Pause von min 5sec. Wenn diese genau vor dem "streicheln" beginnt wird das streicheln um (unzulaessige) 5sec verzoegnert und HMLAN faehrt einen disconnect/reconnect.

WOL hat ein Problem wenn devices, die nicht am LAN sind geprueft werden. WOL wartet bis zu 10 sec auf eine Antwort, blockierend.

Allerdings haben die Disconnects erwartungsgemäß wieder aufgehört, als mein Computer mittels WOL gestartet wurde. Wenn WOL das Problem wäre, dann müssten doch die Disconntects da erst anfangen?

Eben nicht. WOL hat (s.o.) ein Problem wenn das gesuchte Device NICHT vorhanden ist oder nicht antwortet.

in 98_WOL gibt es eine Zeile

Code Auswählen Erweitern

 if (`ping -c 1 $ip` =~ m/100/)
hier kannst du die Pingzeit auf 1 oder 2 sec begrenzen:

if (`ping -c 1 -w 1 $ip` =~ m/100/)

das ist ein workaround. Final sollte das Ping in einen eigenen Prozess ausgelagert werden, dann kann es warten so lange es will.  

Gruss
Martin

[Willi]

die beiden aufgezeichneten Disconnects kommen aufgrund eine Zeitueberschreitung.
HMLAN will min alle 30sec gestreichelt werden. FHEM hat einen 2sec Puffer, streichelt also alle 25 sec.
Bei beiden Disconnects kommen die Streicheeinheiten nicht in/time. also nach 30sec.
=> es besteht keine generelle ueberlast
=> irgendwer erzwingt eine FHEM-Pause von min 5sec. Wenn diese genau vor dem "streicheln" beginnt wird das streicheln um (unzulaessige) 5sec verzoegnert und HMLAN faehrt einen disconnect/reconnect.

Schöne Erklärung. Dann ist es wohl kein Wunder, dass bei mir auch die Disconnects kommen. Ich habe viele Devices (FHEM2FHEM, RFXtrx, CUL, USB-WDE1, etc.). Da können in Summe schnell mal 5 Sekunden zusammenkommen.
Solange FHEM kein richtiges multitasking kann, wird das kaum zu vermeiden sein.

Gelten diese 5 Sekunden auch bei Nutzung der Weboberfläche?

Diese 25 Sec Interval. Ist das die Zeile 470 in 00_HMLAN.pm?

Code Auswählen Erweitern

InternalTimer(gettimeofday()+25, "HMLAN_KeepAlive", "keepAlive:".$name, 0);
sowie Zeite 484

Code Auswählen Erweitern

 InternalTimer(gettimeofday()+25 ,"HMLAN_KeepAlive", "keepAlive:".$name, 1);
Dann würde ich mal probieren diese zu verändern, z.B. auf alle 15 Sekunden.
Oder spricht da grundsätzlich etwas dagegen?

-- Willi

[martinp876]

Hallo Willi,

die 30sec sind von HM, die 25 sec sind in FHEM definiert, wie du korrekt gefunden hast. Du kannst sie veraendern, kein Problem. Dann duerfen die Pausen/Funktionen nicht laenger als 15sec sein. Bei 2 Pings am stueck kann es dich immer noch treffen.

FHEM kann schon ein bisschen multitasking. WOL ist ein Kandikat bei dem man es auch einbauen sollte.
Uebrigens koennen alle User das System mit sleep anhalten - ein Unix sleep legt den Prozess lahm. Gleicher Effekt.  

Eigentlich sind 5sec schon eine lange Zeit. FHEM sollte alles aktive Warten ueber 100-200ms vermeiden.

Gruss
Martin

[Wolle02]

Hallo Martin,

vielen Dank für die tolle Erklärung. Jetzt hab ich das Problem verstanden und der Workaround funktioniert auch. Ich habe die Wartezeit auf 1 Sekunde begrenzt und es funktioniert; mein Rechner fährt nach wie vor hoch und die Disconnects kommen in meiner kurzen Testphase nicht mehr.

Vielen Dank für die Hilfe.

Gruß
Wolle

[Dietmar63]

@ Martin

ich habe eine Änderung an WOL(NAS-Control für Buffalo) in der Mache und will sie mit Boris irgendwann freischalten:
Link
Er hat nur wenig Zeit zu testen.
In dieser Version wäre der Workaround

if (`ping -c 1 -w 1 $ip` =~ m/100/)

enthalten.

Wenn du mir verrätst wie man den ping in einen eigenen Prozess auslagerst würde ich das machen.
Dann wäre hoffentlich Ruhe.

[justme1968]

schau mal im presence modul. da wird alles in einem geforkten prozess aufgerufen.

gruss
  andre

[Dietmar63]

ist das der Aufruf von Blockincall?

(siehe Anhang / see attachement)

[justme1968]

ja. der aufruf geht per BlockigCall.

hier Link stehen ein paar  anmerkungen von rudi.

gruss
  andre

[Dietmar63]

aha - Danke!
mit der Erklärung ist das bestimmt machbar.

[Dietmar63]

@ Martin,
@ Andre:

Ich habe eine Version von 98_WOL erstellt, die den ping über BlockingCall durchführt. Damit sollte das Problem mit dem disconnect von HM-LAN nicht mehr an WOL liegen.

Seid ihr beide in der Lage meine Lösung zu prüfen und zu testen.
Ich würde das Modul dann gern einchecken.

Sie enthält neben dem Aufruf von BlockingCall auch noch eine Erweiterung um ein NAS von Buffalo wach zu halten. Diese Änderung sollte nicht weiter stören, weil die alte Funktionalität erhalten geblieben ist. (die ganze Entwicklungsgeschichte - nur der Vollständigkeit halber bzw. falls Fragen sind):
Link

aktuelle Definition

Code Auswählen Erweitern


define NAS                    WOL 00:24:A5:A6:10:E0 192.168.2.196 UDP 240


[AK-868]

Ich hab genau das Problem auch, aber kein WOl definiert, glaub ich zumindest?

Wo kann ich das rausfinden?

FHEM ist fast Jungfräulich.

Nur Yamaha definiert und jetzt den Lan Adapter an FB 7390

[AK-868]

Ich habs, es ist der Yamaha gewesen der nicht an war. Nur wie bekomm ich das jetzt in den Griff?

[Dietmar63]

Vermutlich wir der Yamaha per ping angesprochen. Wenn er nicht antwortet blockiert fhem und das hmlan wird nicht wach gehalten.

Dem Autor des Yamaha Modul deinen Wunsch schicken.

Dann baut er es vielleicht bald ein.

[Markus Bloch]

Vermutlich wir der Yamaha per ping angesprochen. Wenn er nicht antwortet blockiert fhem und das hmlan wird nicht wach gehalten.

Dem Autor des Yamaha Modul deinen Wunsch schicken.

Dann baut er es vielleicht bald ein.

Hallo Dietmar,

YAMAHA_AVR verwendet keinerlei Ping-Anfragen um die erreichbarkeit eines Receivers festzustellen. Es werden lediglich HTTP Aufrufe verwendet um den Receiver anzusprechen. Falls der Receiver jedoch nicht antwortet, weil er vom Strom getrennt ist, oder Network Standby nicht aktiviert ist, wird aktuell 10 Sekunden auf die Antwort gewartet, danach läuft FHEM normal weiter. Diese Zeit kann man durchaus runterdrehen, aber ich würde sie nicht unter 5 Sekunden stellen.

Viele Grüße

Markus

[AK-868]

Hallo Markus,

vielen Dank für deine Auskunft. Dann darf der eig. nie getrennt sein. Eig. wollte ich doch Energie sparen. Dann halt Log Einträge.
Aber der Yamaha ist ein Monster was Standby angeht. Ich meine mich daran erinnern zu können das er sich 10Watt gönnt. Kann das aber gern nochmal nachmessen.

Achja und deine Anwendung funktioniert richtig gut. Vielen Dank dafür!