Lan adapter disconnected andauernd

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

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1 2 3 ... 6 Alle
Benutzer-Aktionen

Markus

22 Februar 2013, 13:06:30
mein log ist Voll von dieser Fehlermeldung :-(
Ich habe bis vor kurzem einen cuno verwendet aber seit ich auf hm-lan umgestiegen bin ist meine Haupt logdatei voll von dieser Meldung.
Kann mir jemand sagen warum das so ist und wo ich nach dem Fehler suchen soll..
.cfg
define HMLAN1 HMLAN 192.158.176.150:1000
attr HMLAN1 hmId F10000

Gruß Markus

Code Auswählen

2013.02.22 05:55:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 05:55:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 05:59:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 05:59:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:05:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:05:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:08:23 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:08:28 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:18:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:18:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:19:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:19:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:24:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:24:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:28:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:28:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:33:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:33:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:52:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:52:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:57:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:57:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 06:59:28 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 06:59:33 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.22 07:04:21 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.22 07:04:26 1: 192.168.1.10:1000 reappeared (HMLAN1)
Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

martinp876

#1
22 Februar 2013, 19:46:07
kannst du einen log ziehen - mit

attr global mseclog 1
attr global verbose 1
attr <hmlan> hmProtocolEvents 1
attr <hmlan> loglevel 1

ein paar disconnects aufnehmen


Markus

#2
23 Februar 2013, 15:02:17
Hallo Martin
Hier der Ausschnitt aus der logdatei
ich hab auch die ganze Datei unverändert angehängt da ich nicht recht weiß was du wirklich noch alles brauchen kannst.
es sind mehrere disconects drauf

Code Auswählen
2013.02.23 14:28:39.796 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:059C3C2E IDcnt:0000
2013.02.23 14:29:09.742 1: 192.168.1.10:1000 disconnected, waiting to reappear
2013.02.23 14:29:14.906 1: 192.168.1.10:1000 reappeared (HMLAN1)
2013.02.23 14:29:14.909 1: HMLAN_Send:  AF10000
2013.02.23 14:29:14.911 1: HMLAN_Send:  C
2013.02.23 14:29:14.913 1: HMLAN_Send:  Y01,01,
2013.02.23 14:29:14.914 1: HMLAN_Send:  Y02,00,
2013.02.23 14:29:14.917 1: HMLAN_Send:  Y03,00,
2013.02.23 14:29:14.919 1: HMLAN_Send:  Y03,00,
2013.02.23 14:29:14.921 1: HMLAN_Send:  T18BB729A,04,00,00000000
2013.02.23 14:29:15.076 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,059CC55F,0000
E19E0D7,0000,059CC513,FF,FFB1,E9867019E0D700000000C931
I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00

Danke!

Gruß Markus
Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

Markus

#3
01 März 2013, 21:28:10
das Problem habe ich immer noch :-(
@ Martin sagt dir das logfile etwas?

Gruß Markus
Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

martinp876

#4
03 März 2013, 09:41:10
Hallo Markus

der keep-alive in deinem Aufbau ist exterm instabil. Es schwankt um 5-10 sec, wenn es abstürzt um noch mehr.

Die Ursache der Verzögerung kann veilfältig sein... innerhalb oder ausserhalb von fhem.

Bekanntes Problem ist WOL. hast du dieses Modul am laufen?
anderes Problem kann ein sleep sein. benutzt du sleep oder irgendwelchen anderen warte-methoden?

und die 'unscharfe' frage: ist deine HW mit unter ausgelastet? oder an der Grenze?

Das Problem ist in deinem aufbau eigentlich immer da

Gruss
Martin

Markus

#5
03 März 2013, 11:41:29
Hallo Markus
Hallo Martin

der keep-alive in deinem Aufbau ist exterm instabil. Es schwankt um 5-10 sec, wenn es abstürzt um noch mehr.

Die Ursache der Verzögerung kann vielfältig sein... innerhalb oder ausserhalb von fhem.
Ich würde auf fhem tippen da die fritzbox sonst nicht viel zu tun hat :-)

Bekanntes Problem ist WOL. hast du dieses Modul am laufen?
Ja hab ich! :-( Anwesenheitserkennung möchte ich unbedingt nutzen kannst du eine andere Möglichkeit empfehlen?
anderes Problem kann ein sleep sein. benutzt du sleep oder irgendwelchen anderen warte-methoden?
Ich benutze auch sleep aber ich hab gelesen das fhem dann weiter läuft und rudi hat sleep sogar empfohlen..
Code Auswählen
meine .cfg
define Musik_Ein notify Musik.* {if (Value("Aktiv") eq "on" \
&& Value("Musik") eq "on") \
{fhem "set HauptRadio on;;sleep 5;;set Onko on"} \
else \
{fhem "set Onko off;;sleep 5;;set HauptRadio off"} \
}[/color]
und die 'unscharfe' frage: ist deine HW mit unter ausgelastet? oder an der Grenze?
Eigentlich nicht, fhem läuft auf der fritzbox 7390 cpu Auslastung um 10% aber nie über 45% ram nie über 80%

Das Problem ist in deinem aufbau eigentlich immer da

Gruß Markus
Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

Markus Bloch

#6
03 März 2013, 12:32:01
ZitatBekanntes Problem ist WOL. hast du dieses Modul am laufen?
Ja hab ich! :-( Anwesenheitserkennung möchte ich unbedingt nutzen kannst du eine andere Möglichkeit empfehlen?

Dafür gibt es extra das Modul PRESENCE. Mit dem kannst du unter anderem eine ANwesenheitserkennung mit Ping durchführen.

Zitatdefine Handy PRESENCE lan-ping 192.168.0.XX

Dieses verhindert auch die Verzögerung von FHEM

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)

martinp876

#7
03 März 2013, 16:44:27
ok - bei WOL ist die einfach - das hatten wir schon durch.

Probleme gibt es bei nicht antwortenden devices, das dauert sehr lange.

Wenn du devices im eigenen netz pingen willst sollte 1 sec reichen. Also die Zeile in 98_WOL.pm

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

resetzen. Ping wird nach 1sec abgebrochen. nicht optimal aber fuer HMLAN erheblich besser

Billy

#8
04 März 2013, 19:31:55
Bei mir kommt

2013.03.04 05:50:18 1: 192.168.138.10:1000 disconnected, waiting to reappear
regelmässig jeden Tag, wenn die Nachtabschaltung des WLAN durch die Fritzbox zuende ist.
d.h. das WLAN wieder aktiviert wird. FHEM läuft bei mir aber nicht auf der FB.

Vielleicht hilft das dem einen oder anderen.

Gruss Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Markus

#9
06 März 2013, 18:46:49
Ich hab jetzt auf das Modul PRESENCE umgestellt und es scheint jetzt besser zu Funktionieren! jetzt disconnected der lan Adapter nur mehr alle zwei Stunden. Das ist jetzt zwar nicht perfekt aber damit kann ich Leben.
Ich Danke euch!

Code Auswählen
define Handy PRESENCE lan-ping 192.168.0.XX 30 120
Gruß Markus
Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

Markus

#10
07 März 2013, 08:23:58
so schaut mein log jetzt aus leider immer noch ziemlich viele disconnect

Code Auswählen

2013.03.07 00:59:35.148 1: HMLAN_Parse: HMLAN1 S:E19DA38   stat:0000 t:0C47D14B d:FF r:FFB6 m:56820219DA3819E0D7010100002D
2013.03.07 00:59:35.165 1: RCV L:0E N:56 F:82 CMD:02 SRC:Heizkorper_Bad DST:ThermostatBad 010100002D (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x2D) (,WAKEMEUP,RPTEN)
2013.03.07 00:59:39.796 1: HMLAN_Send:  K
2013.03.07 00:59:39.801 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0C47E5FF,0007

2013.03.07 00:59:39.803 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0C47E5FF IDcnt:0007
2013.03.07 01:00:14.088 1: 192.168.167.150:1000 disconnected, waiting to reappear
2013.03.07 01:00:19.250 1: 192.168.167.150:1000 reappeared (HMLAN1)
2013.03.07 01:00:19.252 1: HMLAN_Send:  AF10000
2013.03.07 01:00:19.254 1: HMLAN_Send:  C
2013.03.07 01:00:19.256 1: HMLAN_Send:  Y01,01,
2013.03.07 01:00:19.258 1: HMLAN_Send:  Y02,00,
2013.03.07 01:00:19.260 1: HMLAN_Send:  Y03,00,
2013.03.07 01:00:19.262 1: HMLAN_Send:  Y03,00,
2013.03.07 01:00:19.264 1: HMLAN_Send:  T18CA8703,04,00,00000000
2013.03.07 01:00:19.445 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0C488023,0007
I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00

2013.03.07 01:00:19.447 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0C488023 IDcnt:0007
2013.03.07 01:00:37.288 1: HMLAN/RAW: /E19E0DB,0000,0C48C68F,FF,FFC3,A6867019E0DB00000000D837

2013.03.07 01:00:37.290 1: HMLAN_Parse: HMLAN1 S:E19E0DB   stat:0000 t:0C48C68F d:FF r:FFC3 m:A6867019E0DB00000000D837
2013.03.07 01:00:37.308 1: RCV L:0C N:A6 F:86 CMD:70 SRC:Thermostat_Vorraum DST:broadcast 00D837 (WeatherEvent TEMP:0x00D8 HUM:0x37) (,WAKEMEUP,CFG,RPTEN)
2013.03.07 01:00:39.751 1: HMLAN/RAW: /E19E0D5,0000,0C48D02E,FF,FFCA,73867019E0D500000000D13A

Code Auswählen

2013.03.07 02:20:17.495 1: HMLAN_Parse: HMLAN1 S:E19DA38   stat:0000 t:0C91B877 d:FF r:FFB5 m:76820219DA3819E0D7010100002D
2013.03.07 02:20:17.513 1: RCV L:0E N:76 F:82 CMD:02 SRC:Heizkorper_Bad DST:ThermostatBad 010100002D (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x2D) (,WAKEMEUP,RPTEN)
2013.03.07 02:20:34.968 1: HMLAN_Send:  K
2013.03.07 02:20:34.975 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0C91FE51,0002

2013.03.07 02:20:34.978 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0C91FE51 IDcnt:0002
2013.03.07 02:20:59.980 1: HMLAN_Send:  K
2013.03.07 02:20:59.985 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0C926009,0002

2013.03.07 02:20:59.986 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0C926009 IDcnt:0002
2013.03.07 02:21:33.038 1: 192.168.167.150:1000 disconnected, waiting to reappear
2013.03.07 02:21:38.208 1: 192.168.167.150:1000 reappeared (HMLAN1)
2013.03.07 02:21:38.211 1: HMLAN_Send:  AF10000
2013.03.07 02:21:38.213 1: HMLAN_Send:  C
2013.03.07 02:21:38.215 1: HMLAN_Send:  Y01,01,
2013.03.07 02:21:38.217 1: HMLAN_Send:  Y02,00,
2013.03.07 02:21:38.219 1: HMLAN_Send:  Y03,00,
2013.03.07 02:21:38.221 1: HMLAN_Send:  Y03,00,
2013.03.07 02:21:38.224 1: HMLAN_Send:  T18CA9A12,04,00,00000000
2013.03.07 02:21:39.197 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0C92F563,0002
E19E0DB,0000,0C92F351,FF,FFC2,C6867019E0DB00000000D635
I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00
E19E0D5,0000,0C92F7D7,FF,FFC9,93867019E0D500000000D03A

2013.03.07 02:21:39.199 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0C92F563 IDcnt:0002
2013.03.07 02:21:39.201 1: HMLAN_Parse: HMLAN1 S:E19E0DB   stat:0000 t:0C92F351 d:FF r:FFC2 m:C6867019E0DB00000000D635
2013.03.07 02:21:39.220 1: RCV L:0C N:C6 F:86 CMD:70 SRC:Thermostat_Vorraum DST:broadcast 00D635 (WeatherEvent TEMP:0x00D6 HUM:0x35) (,WAKEMEUP,CFG,RPTEN)

Code Auswählen

2013.03.07 02:51:25.684 1: RCV L:0E N:9F F:82 CMD:02 SRC:Heizkorper_Kuche DST:Thermostat_Wohnzimmer 010100003C (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0x00 DOWN:0x00 LOWBAT:0x00 RSSI:0x3C) (,WAKEMEUP,RPTEN)
2013.03.07 02:51:29.730 1: HMLAN_Send:  K
2013.03.07 02:51:29.735 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0CAE4C8E,0000

2013.03.07 02:51:29.736 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0CAE4C8E IDcnt:0000
2013.03.07 02:52:03.089 1: 192.168.167.150:1000 disconnected, waiting to reappear
2013.03.07 02:52:08.260 1: 192.168.167.150:1000 reappeared (HMLAN1)
2013.03.07 02:52:08.262 1: HMLAN_Send:  AF10000
2013.03.07 02:52:08.264 1: HMLAN_Send:  C
2013.03.07 02:52:08.266 1: HMLAN_Send:  Y01,01,
2013.03.07 02:52:08.268 1: HMLAN_Send:  Y02,00,
2013.03.07 02:52:08.270 1: HMLAN_Send:  Y03,00,
2013.03.07 02:52:08.272 1: HMLAN_Send:  Y03,00,
2013.03.07 02:52:08.274 1: HMLAN_Send:  T18CAA138,04,00,00000000
2013.03.07 02:52:09.310 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314853,1C68FE,F10000,0CAEE316,0000
E19E0AA,0000,0CAEDE9A,FF,FFB7,0C867019E0AA00000000D43D
I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00

2013.03.07 02:52:09.312 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314853 d:1C68FE O:F10000 m:0CAEE316 IDcnt:0000
2013.03.07 02:52:09.314 1: HMLAN_Parse: HMLAN1 S:E19E0AA   stat:0000 t:0CAEDE9A d:FF r:FFB7 m:0C867019E0AA00000000D43D
2013.03.07 02:52:09.332 1: RCV L:0C N:0C F:86 CMD:70 SRC:ThermostatSchlaf DST:broadcast 00D43D (WeatherEvent TEMP:0x00D4 HUM:0x3D) (,WAKEMEUP,CFG,RPTEN)


Gruß Markus
Raspberry Pi2 als FHEM-Plattform
HM, FS20, 1-Wire, PanStamp,LW12,Intertechno,ESPEasy,Alexa

martinp876

#11
07 März 2013, 10:18:06
Hallo Markus,

was du selbst pruefen kannst:
die keep-alive werden alle 25sec von FEHM getriggert. Sollte der Abstand groesser 25sec sein gab es bereits einen delay - egal woher.

die Antwort muss innerhalb 1sec kommen.

Der LAN Adaper disconnected wenn er nicht alle ~30-35 sec ein keepalive bekommt. Da ist meines Wissens auc nichts einstellbar (aber vom LAN adapter haben wir keine Internas...)
Das keep-alive darf also 5sec bis max 10sec Variation haben.

Alle deine Disconnects sind auf eine Ueberschreitung der keep-alive Zeiten zurueckzufuehren, das sagen die Logs.
Das Problem liegt nicht in HMLAN oder CUL_HM, da passiert gerade garnichts. Es kann aus FHEM kommen (oder davon getriggert werden) - aber auch von sonstigen aktionen auf dem Rechner.

2 Dinge solltest du pruefen
a) wann treten disconnects auf? Kann man ein Muster erkennen? Korrelation zu andern Prozessen?
b) kommen die send: K immer im Abstand von 25 sec? Wenn es hier auch schon variiert dann besteht das Problem permanent.

Generell kann man das Problem nicht loesen. Es hatte sich jemand gelendet, der disconnects hatte immer wen seine Box irgendwelche anderen Services bedient hat. Wenn es in FHEM liegt (moeglich) dann musst du die Services untersuchen/listen die du betreibst.

Code Auswählen
define Handy PRESENCE lan-ping 192.168.0.XX 30 120
Evtl. liegt es am PRESENCE. Das benutzt, wie WOL, einen ping - und nimmt sich heraus auch noch auf 4 Antworten zu warten, anstatt nur auf eine.

Du solltest den ping modifizieren...
$temp = qx(ping -c 4 $device);
aendern nach
$temp = qx(ping -c 1 -w 1  $device);
ohne gewaehr, untested.

Und dich an den Entwickler des Moduls wenden.

Gruss
Martin

Steffen

#12
07 März 2013, 18:11:15
Zitat von: martinp876 schrieb am Do, 07 März 2013 10:18Hallo Markus,

was du selbst pruefen kannst:
die keep-alive werden alle 25sec von FEHM getriggert. Sollte der Abstand groesser 25sec sein gab es bereits einen delay - egal woher.

die Antwort muss innerhalb 1sec kommen.

Der LAN Adaper disconnected wenn er nicht alle ~30-35 sec ein keepalive bekommt. Da ist meines Wissens auc nichts einstellbar (aber vom LAN adapter haben wir keine Internas...)
Das keep-alive darf also 5sec bis max 10sec Variation haben.

Alle deine Disconnects sind auf eine Ueberschreitung der keep-alive Zeiten zurueckzufuehren, das sagen die Logs.
Das Problem liegt nicht in HMLAN oder CUL_HM, da passiert gerade garnichts. Es kann aus FHEM kommen (oder davon getriggert werden) - aber auch von sonstigen aktionen auf dem Rechner.

2 Dinge solltest du pruefen
a) wann treten disconnects auf? Kann man ein Muster erkennen? Korrelation zu andern Prozessen?
b) kommen die send: K immer im Abstand von 25 sec? Wenn es hier auch schon variiert dann besteht das Problem permanent.

Generell kann man das Problem nicht loesen. Es hatte sich jemand gelendet, der disconnects hatte immer wen seine Box irgendwelche anderen Services bedient hat. Wenn es in FHEM liegt (moeglich) dann musst du die Services untersuchen/listen die du betreibst.

Code Auswählen
define Handy PRESENCE lan-ping 192.168.0.XX 30 120
Evtl. liegt es am PRESENCE. Das benutzt, wie WOL, einen ping - und nimmt sich heraus auch noch auf 4 Antworten zu warten, anstatt nur auf eine.

Du solltest den ping modifizieren...
$temp = qx(ping -c 4 $device);
aendern nach
$temp = qx(ping -c 1 -w 1  $device);
ohne gewaehr, untested.

Und dich an den Entwickler des Moduls wenden.

Gruss
Martin

Hallo!

Habe ich auch mal versucht aber wie schon den ganzen und die letzte Tage...

2013.03.07 16:47:05 3: Device Wz_Heizung1 added to ActionDetector with 000:10 time
2013.03.07 16:48:40 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:48:50 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:49:16 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:49:25 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:49:51 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:49:56 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:50:22 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:50:27 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:50:53 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:50:58 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:51:24 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:51:32 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:51:58 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:52:03 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:54:59 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:55:04 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:55:30 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:55:40 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 16:56:31 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 16:56:41 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:00:52 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:01:01 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:01:27 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:01:35 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:03:16 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:03:21 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:03:47 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:03:52 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:04:18 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:04:26 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:04:52 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:05:58 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:06:29 2: CUL_HM set Fl_LampeDecke press on rxt:1
2013.03.07 17:15:59 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:16:04 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.03.07 17:38:11 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.03.07 17:38:59 2: CUL_HM set Fl_LampeDecke press on rxt:1
2013.03.07 17:39:29 1: 192.168.178.60:1000 reappeared (HMLAN1)

Schon getauscht Switch,Cat-kabel, direkt verbunden usw...kein Erfolg ich gebe es auf:-(

martinp876

#13
07 März 2013, 19:18:26
nur um es richtig zu verstehen:

die Disconnects kommen auch, wenn du PRESENCE ausschaltest? War das dein Test?

Aus diesen traces ist nicht zu sehen, wenn die keep-alive gesendet werden und ob es an der Antwort oder dem 25sec timer liegt.

Wenn es am 25sec timer liegt kann es nicht am kabel liegen...
Also die messages loggen und die Zeiten der keep-alive auswerten, nach den genannten kriterien

Das ist auch nicht die Dargestellte dauer 'alle 2 stunden', da gehen eigentlich alle keepalive daneben.
In diesen Fall klaut dir jemand quasi die gesamte CPU-zeit - fuer FHEM thread jedenfalls

Markus Bloch

#14
07 März 2013, 22:47:33
Zitat von: martinp876 schrieb am Do, 07 März 2013 10:18Hallo Markus,

was du selbst pruefen kannst:
die keep-alive werden alle 25sec von FEHM getriggert. Sollte der Abstand groesser 25sec sein gab es bereits einen delay - egal woher.

die Antwort muss innerhalb 1sec kommen.

Der LAN Adaper disconnected wenn er nicht alle ~30-35 sec ein keepalive bekommt. Da ist meines Wissens auc nichts einstellbar (aber vom LAN adapter haben wir keine Internas...)
Das keep-alive darf also 5sec bis max 10sec Variation haben.

Alle deine Disconnects sind auf eine Ueberschreitung der keep-alive Zeiten zurueckzufuehren, das sagen die Logs.
Das Problem liegt nicht in HMLAN oder CUL_HM, da passiert gerade garnichts. Es kann aus FHEM kommen (oder davon getriggert werden) - aber auch von sonstigen aktionen auf dem Rechner.

2 Dinge solltest du pruefen
a) wann treten disconnects auf? Kann man ein Muster erkennen? Korrelation zu andern Prozessen?
b) kommen die send: K immer im Abstand von 25 sec? Wenn es hier auch schon variiert dann besteht das Problem permanent.

Generell kann man das Problem nicht loesen. Es hatte sich jemand gelendet, der disconnects hatte immer wen seine Box irgendwelche anderen Services bedient hat. Wenn es in FHEM liegt (moeglich) dann musst du die Services untersuchen/listen die du betreibst.

Code Auswählen
define Handy PRESENCE lan-ping 192.168.0.XX 30 120
Evtl. liegt es am PRESENCE. Das benutzt, wie WOL, einen ping - und nimmt sich heraus auch noch auf 4 Antworten zu warten, anstatt nur auf eine.

Du solltest den ping modifizieren...
$temp = qx(ping -c 4 $device);
aendern nach
$temp = qx(ping -c 1 -w 1  $device);
ohne gewaehr, untested.

Und dich an den Entwickler des Moduls wenden.

Gruss
Martin

Hallo Martin,

das PRESENCE Modul wurde extra aus diesem Grund so entwickelt, dass jegliches Blocken des Hauptprozesses verhindert wird. Dazu wird das Modul Blocking.pm verwendet, welches eine Funktion bereitstellt um FHEM-interne Funktionen non-Blocking zu verwenden. Dazu wird ein Child-Prozess mittels Forking (unter Windows: Threading) erzeugt, welcher diese Funktion bearbeitet und anschließend das Ergebnis an den Mutter-Prozess zurück gibt. Daher habe ich hier bei PING gerade einen Count von 4 gewählt um eben Netzwerk-Schwanker zu umgehen.

FHEM wird dadurch in keiner Weise behindert, da der Ping-Befehl vom Hauptprozess abgekoppelt ist.

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)
Drucken
Nach oben Seiten1 2 3 ... 6 Alle
Benutzer-Aktionen