Lan adapter disconnected andauernd

Begonnen von Markus, 22 Februar 2013, 13:06:30

Vorheriges Thema - Nächstes Thema

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.

ZitatAllerdings 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
 if (`ping -c 1 $ip` =~ m/100/)
hier kannst du die Pingzeit auf 1 oder 2 sec begrenzen:
Zitatif (`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

Zitat von: martinp876 schrieb am Fr, 03 Mai 2013 10:35die 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?
InternalTimer(gettimeofday()+25, "HMLAN_KeepAlive", "keepAlive:".$name, 0);
sowie Zeite 484
 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
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

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
Zitatif (`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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

justme1968

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

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dietmar63

ist das der Aufruf von Blockincall?


(siehe Anhang / see attachement)
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

justme1968

ja. der aufruf geht per BlockigCall.

hier Link stehen ein paar  anmerkungen von rudi.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dietmar63

aha - Danke!
mit der Erklärung ist das bestimmt machbar.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

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

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


Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

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
Hardware FHEM:
Neue Fritzbox 7390 keine Labor von AVM
Konfigurationsadapter Lan
Funk-Schließerkontaktschnittstellen
Funk-Fenster/Türkontakt
Funk-Schaltaktoren UP ein und zweifach
Funk-Jalousieaktoren
Funk-Rauchmelder


AK-868

Ich habs, es ist der Yamaha gewesen der nicht an war. Nur wie bekomm ich das jetzt in den Griff?
Hardware FHEM:
Neue Fritzbox 7390 keine Labor von AVM
Konfigurationsadapter Lan
Funk-Schließerkontaktschnittstellen
Funk-Fenster/Türkontakt
Funk-Schaltaktoren UP ein und zweifach
Funk-Jalousieaktoren
Funk-Rauchmelder


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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Markus Bloch

Zitat von: Dietmar63 schrieb am Do, 09 Mai 2013 15:43Vermutlich 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
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

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!

Hardware FHEM:
Neue Fritzbox 7390 keine Labor von AVM
Konfigurationsadapter Lan
Funk-Schließerkontaktschnittstellen
Funk-Fenster/Türkontakt
Funk-Schaltaktoren UP ein und zweifach
Funk-Jalousieaktoren
Funk-Rauchmelder