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
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)
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
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
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
das Problem habe ich immer noch :-(
@ Martin sagt dir das logfile etwas?
Gruß Markus
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
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..
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
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
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
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
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!
define Handy PRESENCE lan-ping 192.168.0.XX 30 120
Gruß Markus
so schaut mein log jetzt aus leider immer noch ziemlich viele disconnect
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
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)
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
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.
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
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.
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:-(
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
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.
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
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
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
Hallo Martin,
ich habe es jetzt so eingestellt und auf ein Disconnect gewartet.
Gruß
Torsten
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
Zitat von: martinp876 schrieb am So, 10 März 2013 17:03du 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
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
Schön, wenn Du Deinen Spass hast....
Dann ändere ich das.
Dann war es eher Zufall, dass kein Disconnect mehr kam.
@ 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
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
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
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
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
Danke für die ausführliche Beschreibung man lernt halt nie aus.
Gruß Markus
der timer kann jetzt eingestellt werden... mit attributen.
Gruss
Martin
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
Hallo,
Danke für den Thread und die Bereitstellung von respTime. Leider bekomme ich auch mit 5 Sekunden mein Problem nicht weg. Die Log-Einträge sehen auch etwas anders aus:
2013.04.01 14:06:29.150 1: 192.168.178.15:1000 reappeared (HMLAN1)
2013.04.01 14:06:29.150 1: HMLAN_Send: A222222
2013.04.01 14:06:29.154 1: HMLAN_Send: C
2013.04.01 14:06:29.158 1: HMLAN_Send: Y01,01,
2013.04.01 14:06:29.161 1: HMLAN_Send: Y02,00,
2013.04.01 14:06:29.165 1: HMLAN_Send: Y03,00,
2013.04.01 14:06:29.169 1: HMLAN_Send: Y03,00,
2013.04.01 14:06:29.169 1: HMLAN_Send: T18EC42D5,04,00,00000000
2013.04.01 14:06:29.313 1: HMLAN/RAW: /V763B1D0E118844222C160B0502010000
2013.04.01 14:06:29.325 1: HMLAN1 Unknown msg >V763B1D0E118844222C160B0502010000<
2013.04.01 14:06:54.184 1: HMLAN_Send: K
2013.04.01 14:06:55.188 1: 192.168.178.15:1000 disconnected, waiting to reappear
2013.04.01 14:07:00.666 1: 192.168.178.15:1000 reappeared (HMLAN1)
2013.04.01 14:07:00.674 1: HMLAN_Send: A222222
2013.04.01 14:07:00.674 1: HMLAN_Send: C
2013.04.01 14:07:00.678 1: HMLAN_Send: Y01,01,
2013.04.01 14:07:00.682 1: HMLAN_Send: Y02,00,
2013.04.01 14:07:00.686 1: HMLAN_Send: Y03,00,
2013.04.01 14:07:00.686 1: HMLAN_Send: Y03,00,
2013.04.01 14:07:00.690 1: HMLAN_Send: T18EC42F4,04,00,00000000
2013.04.01 14:07:00.794 1: HMLAN/RAW: /V763B1D0E118844222D160B0502010000
2013.04.01 14:07:00.798 1: HMLAN1 Unknown msg >V763B1D0E118844222D160B0502010000<
2013.04.01 14:07:25.701 1: HMLAN_Send: K
2013.04.01 14:07:26.709 1: 192.168.178.15:1000 disconnected, waiting to reappear
2013.04.01 14:07:36.792 1: 192.168.178.15:1000 reappeared (HMLAN1)
2013.04.01 14:07:36.792 1: HMLAN_Send: A222222
2013.04.01 14:07:36.796 1: HMLAN_Send: C
2013.04.01 14:07:36.800 1: HMLAN_Send: Y01,01,
2013.04.01 14:07:36.800 1: HMLAN_Send: Y02,00,
2013.04.01 14:07:36.804 1: HMLAN_Send: Y03,00,
2013.04.01 14:07:36.808 1: HMLAN_Send: Y03,00,
2013.04.01 14:07:36.808 1: HMLAN_Send: T18EC4318,04,00,00000000
2013.04.01 14:07:36.884 1: HMLAN/RAW: /V763B1D0E118844222E170B0502010000
2013.04.01 14:07:36.888 1: HMLAN1 Unknown msg >V763B1D0E118844222E170B0502010000<
2013.04.01 14:08:01.819 1: HMLAN_Send: K
2013.04.01 14:08:02.827 1: 192.168.178.15:1000 disconnected, waiting to reappear
2013.04.01 14:08:12.910 1: 192.168.178.15:1000 reappeared (HMLAN1)
2013.04.01 14:08:12.914 1: HMLAN_Send: A222222
2013.04.01 14:08:12.918 1: HMLAN_Send: C
2013.04.01 14:08:12.918 1: HMLAN_Send: Y01,01,
2013.04.01 14:08:12.922 1: HMLAN_Send: Y02,00,
2013.04.01 14:08:12.926 1: HMLAN_Send: Y03,00,
2013.04.01 14:08:12.930 1: HMLAN_Send: Y03,00,
2013.04.01 14:08:12.934 1: HMLAN_Send: T18EC433C,04,00,00000000
2013.04.01 14:08:13.002 1: HMLAN/RAW: /V763B1D0E412010082F170B0502010000
2013.04.01 14:08:13.006 1: HMLAN1 Unknown msg >V763B1D0E412010082F170B0502010000<
Es kommt alle 30-40 Sekunden zu einem DISCONNECT und dann wieder zu einem CONNECT.
Hilfe gerne willkommen, da ich mit dem HMLAN meine HM-Sec-Key-S steuern möchte und es hinten und vorne nicht klappt. Denke, dass zu einem Teil die Instabilitäten mit der Verbindung des HMLAN dafür verantwortlich sind.
Tschuess,
hightower
Hallo!
Habe das jetzt auch schon sehr lange und am aufgeben:-(, habe schon Switch/Kabel usw. ausgewechselt dann diverse Notify ausgeklammert aber immer das Gleiche...
2013.04.01 08:59:09 3: TELNET: port 7072 opened
2013.04.01 08:59:09 3: WEB: port 8083 opened
2013.04.01 08:59:09 3: WEBphone: port 8084 opened
2013.04.01 08:59:09 3: WEBtablet: port 8085 opened
2013.04.01 08:59:09 3: Opening HMLAN1 device 192.168.178.60:1000
2013.04.01 08:59:09 3: HMLAN1 device opened
2013.04.01 08:59:10 1: Including ./var/log/fhem/fhem.save
2013.04.01 08:59:11 0: Server started with 62 defined entities (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 3003 2013-03-31 08:08:11Z rudolfkoenig $, pid 23981)
2013.04.01 08:59:15 3: Device Heizung_1OG added to ActionDetector with 000:10 time
2013.04.01 08:59:15 3: Device Heizung_OG_BA added to ActionDetector with 000:10 time
2013.04.01 08:59:15 3: Device Wz_Heizung1 added to ActionDetector with 000:10 time
2013.04.01 09:00:11 2: CUL_HM set Wz_Heizung1 tempListSun 05:00 19.0 11:00 22.0 21:00 21.0 24:00 19.0 rxt:12
2013.04.01 09:56:45 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.04.01 09:56:50 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.04.01 10:00:00 2: CUL_HM set Rollo_Wz off rxt:1
2013.04.01 10:04:11 2: CUL_HM set LuefterHeizung on rxt:1
2013.04.01 10:54:11 2: CUL_HM set LuefterHeizung off rxt:1
2013.04.01 11:07:11 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.04.01 11:07:16 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.04.01 12:00:00 2: CUL_HM set VG_GartenSprinkler on-for-timer 30 rxt:1
2013.04.01 17:28:52 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.04.01 17:29:00 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.04.01 17:34:29 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.04.01 17:34:36 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.04.01 17:36:45 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.04.01 17:36:55 1: 192.168.178.60:1000 reappeared (HMLAN1)
2013.04.01 17:39:29 1: 192.168.178.60:1000 disconnected, waiting to reappear
2013.04.01 17:39:41 1: 192.168.178.60:1000 reappeared (HMLAN1)
Hi,
bei hightower scheint der respTime nicht zu arbeiten. Welchen Wert hast du eingegeben?
Steffen, bei dir kann ich nicht sehen, was der Grund ist, da die logs nicht raw sind, also die messages fehlen. Hast du schon mi respTime getested?
Gruss
Martin
Hallo Martin,
läuft! Hatte die respTime (Wert = 5) zuerst über die Web-Oberfläche gesetzt, weiß aber nicht mehr, ob ich danach sauber FHEM restartet hatte. Habe dann den Wert in der fhem.cfg eingetragen:
define HMLAN1 HMLAN 192.XXX.XXX.XXX:1000
attr HMLAN1 hmId XXXXXX
attr HMLAN1 respTime 5
Jetzt kommen die Fehlermeldungen nicht mehr. Der anschließende Schritt, die saubere Einbindung einer HM-Sec-Key-S hat dann heute auch funktioniert - der Tag ist gerettet.
Vielen Dank für die Unterstützung und die Bereitstellung des respTime! Klopf auf die Schulter.
Tschuess,
hightower
Hallo Hightower,
nach dem Setzen des Attributs braucht es keinen Restart... seltsam.
Aber gut, dass es klappt
Gruss
Martin
Hallo!
Hatte das schon mal wo anders gefragt aber mir fällt auf beim start über Putty kommt diese Fehlermeldung:
sudo /etc/init.d/fhem start
root@NASC87667:~# 2013.04.02 18:38:10 1: Including /etc/fhem.cfg
Can't open ./var/log/fhem/fhem-2013-04.log: Datei oder Verzeichnis nicht gefunden at /usr/bin/fhem.pl line 1755, <$fh> line 2
und Fhem startet nicht, kann das vielleicht ein Grundproblem mit dem disconnected sein???
Wenn ich die punkte vor ./var... entferne kommt diese Fehlermelung:
sudo /etc/init.d/fhem start
Starting fhem...
root@NASC87667:~# Use of uninitialized value $temperature in concatenation (.) or string at /usr/share/fhem/FHEM/59_Weather.pm line 346, <$fh> line 305.
Use of uninitialized value $humidity in concatenation (.) or string at /usr/share/fhem/FHEM/59_Weather.pm line 346, <$fh> line 305.
Use of uninitialized value $wind in concatenation (.) or string at /usr/share/fhem/FHEM/59_Weather.pm line 346, <$fh> line 305.
Use of uninitialized value in string lt at /usr/bin/fhem.pl line 1966, <$fh> line 456.
Use of uninitialized value in string lt at /usr/bin/fhem.pl line 1966, <$fh> line 465.
Use of uninitialized value in string lt at /usr/bin/fhem.pl line 1966, <$fh> line 467.
aber Fhem startet habe aber keine Haupt-Logfile mehr!
Hoffe es könnte mir jemand einen Tip geben??
Mfg Steffen
Hi Steffen,
Can't open ./var/log/fhem/fhem-2013-04.log: Datei oder Verzeichnis nicht gefunden at /usr/bin/fhem.pl line 1755, <$fh> line 2
du hast ein schlechtes logfile in global angegeben.
. bedeuted "current directory"
also <current directory>/var/log/fhem/fhem-2013-04.log
wahrscheinlich willst du entweder
"/var/log/fhem/fhem-2013-04.log"
oder
"./log/fhem/fhem-2013-04.log"
zweiteres ist ein unterverzeichniss deiner FHEM installation.
Ob es zu problemen führen kann weiss ich nicht. Kommt darauf an wie FHEM mit nicht vorhandenen logfiles umgeht. Falls hier immer wieder geprüft wird kann es schon zu Problemen kommen. Jedenfalls solltest du es beheben.
Dein logfile sollte schon da sein du musst es nur suchen... absoluter oder realitver Pfad
Wenn es also ohne '.' laeuft hast du ein Problem mit weather, auch nicht meine baustelle.
lösche die Zeilen:
my $temperature= $hash->{READINGS}{temperature}{VAL};
my $humidity= $hash->{READINGS}{humidity}{VAL};
my $wind= $hash->{READINGS}{wind}{VAL};
my $val= "T: $temperature H: $humidity W: $wind";
und füge ein
my $val= "T: ".ReadingsVal($hash,"temperature","?").
" H: ".ReadingsVal($hash,"humidity" ,"?").
" W: ".ReadingsVal($hash,"wind" ,"?");
Die 3 letzten Meldungen kann ich nicht deuten, habe gerade eine andere FHEM.PL version.
Gruss
Martin
Zitat von: martinp876 schrieb am Mi, 03 April 2013 17:12Hi Steffen,
Can't open ./var/log/fhem/fhem-2013-04.log: Datei oder Verzeichnis nicht gefunden at /usr/bin/fhem.pl line 1755, <$fh> line 2
du hast ein schlechtes logfile in global angegeben.
. bedeuted "current directory"
also <current directory>/var/log/fhem/fhem-2013-04.log
wahrscheinlich willst du entweder
"/var/log/fhem/fhem-2013-04.log"
oder
"./log/fhem/fhem-2013-04.log"
zweiteres ist ein unterverzeichniss deiner FHEM installation.
Ob es zu problemen führen kann weiss ich nicht. Kommt darauf an wie FHEM mit nicht vorhandenen logfiles umgeht. Falls hier immer wieder geprüft wird kann es schon zu Problemen kommen. Jedenfalls solltest du es beheben.
Dein logfile sollte schon da sein du musst es nur suchen... absoluter oder realitver Pfad
Wenn es also ohne '.' laeuft hast du ein Problem mit weather, auch nicht meine baustelle.
lösche die Zeilen:
my $temperature= $hash->{READINGS}{temperature}{VAL};
my $humidity= $hash->{READINGS}{humidity}{VAL};
my $wind= $hash->{READINGS}{wind}{VAL};
my $val= "T: $temperature H: $humidity W: $wind";
und füge ein
my $val= "T: ".ReadingsVal($hash,"temperature","?").
" H: ".ReadingsVal($hash,"humidity" ,"?").
" W: ".ReadingsVal($hash,"wind" ,"?");
Die 3 letzten Meldungen kann ich nicht deuten, habe gerade eine andere FHEM.PL version.
Gruss
Martin
Hallo Martin,
erstmal danke für deine Hilfe...
hier mal ein Auszug von Debian:
root@NASC87667:/var/log/fhem# ls -l
insgesamt 8648
-rw-r--r-- 1 root root 13301 31. Mär 21:48 ActionDetector-2013-03.log
-rw-r--r-- 1 root root 2875 2. Apr 19:05 ActionDetector-2013-04.log
-rw-rw-rw- 1 root root 191836 31. Mär 23:00 fhem-2013-03.log
-rw-rw-rw- 1 root root 104837 3. Apr 17:30 fhem-2013-04.log
-rwxrwxrwx 1 root root 11993 3. Apr 17:30
fhem.save-rw-r--r-- 1 root root 12702 31. Mär 22:06 Fl_LampeDecke-2013-03.log
-rw-r--r-- 1 root root 7242 3. Apr 15:42 Fl_LampeDecke-2013-04.log
-rw-r--r-- 1 root root 2642135 31. Mär 23:33 Heizung_1OG-2013-03.log
-rw-r--r-- 1 root root 32065 3. Apr 17:25 Heizung_1OG-2013-04.log
-rw-r--r-- 1 root root 2750618 31. Mär 23:51 Heizung_OG_BA-2013-03.log
-rw-r--r-- 1 root root 41420 3. Apr 17:25 Heizung_OG_BA-2013-04.log
-rw-r--r-- 1 root root 37291 3. Apr 16:07 Ke_LampeDecke-2013.log
-rw-r--r-- 1 root root 14290 31. Mär 12:35 LuefterHeizung-2013-03.log
-rw-r--r-- 1 root root 756 3. Apr 11:05 LuefterHeizung-2013-04.log
-rw-r--r-- 1 root root 0 2. Jan 09:43 maximus_Wz-2013.log
-rw-r--r-- 1 root root 10910 31. Mär 23:00 Rollo_Wz-2013-03.log
-rw-r--r-- 1 root root 2708 3. Apr 10:00 Rollo_Wz-2013-04.log
-rw-r--r-- 1 root root 15674 3. Apr 12:00 VG_GartenSprinkler-2013.log
-rw-r--r-- 1 root root 198421 3. Apr 04:19 Wz_DLampeDecke-2013.log
-rw-r--r-- 1 root root 2635532 31. Mär 23:21 Wz_Heizung1-2013-03.log
-rw-r--r-- 1 root root 37810 3. Apr 17:30 Wz_Heizung1-2013-04.log
-rw-r--r-- 1 root root 21297 2. Apr 19:09 Wz_LampeDeckeUp-2013.log
also die Log-Datei liegt ja wohl da oder sehe ich das Falsch, aber wieso sieht Fhem diese Log-Datei nicht??
Zitatalso die Log-Datei liegt ja wohl da oder sehe ich das Falsch, aber wieso sieht Fhem diese Log-Datei nicht??
das ist m.E. eine Meldung beim starten. FHEM ist es wurst ob die Datei da ist oder nicht. Wenn nicht da wird sie angelegt.
Das hast du sicher mit "ohne Punkt" erreicht!?
In der Datei gibt es ja auch aktuelle Eintraege, so jedenfalls das Datum.
Kommt die Fehlermeldung zur Datei immer noch?
Das Problem mit der Logdatei und sie zu finden sollte damit doch gelöst sein. Warumglaubst du sieht FHEM die Datei nicht undwo soll sie den herkommen wenn nicht von FHEM?
Gruss
Martin
Zitat von: martinp876 schrieb am Mi, 03 April 2013 18:35Zitatalso die Log-Datei liegt ja wohl da oder sehe ich das Falsch, aber wieso sieht Fhem diese Log-Datei nicht??
das ist m.E. eine Meldung beim starten. FHEM ist es wurst ob die Datei da ist oder nicht. Wenn nicht da wird sie angelegt.
Das hast du sicher mit "ohne Punkt" erreicht!?
In der Datei gibt es ja auch aktuelle Eintraege, so jedenfalls das Datum.
Kommt die Fehlermeldung zur Datei immer noch?
Das Problem mit der Logdatei und sie zu finden sollte damit doch gelöst sein. Warumglaubst du sieht FHEM die Datei nicht undwo soll sie den herkommen wenn nicht von FHEM?
Gruss
Martin
Ok, ja habe es selber gemerkt das ich in diesem Punkt Falsch gedacht habe.
Danke Martin, dein Tip war Gold richtig...habe den punkt/punkte entfernt vor ./var/... und als sudo gespeichert und genau das war wohl vorher das Problem denn jetzt klappt es bestens ohne Fehlermeldung...
Mfg Steffen
Hallo zusammen,
ich habe auch schon seit längerer Zeit das "Problem", dass ich im Logfile sehr viele HMLan Disconnects habe. Das Problem habe ich deshalb in "" gesetzt, weil ich außer diesen Einträgen bislang eigentlich keinerlei Funktionseinbußen festgestellt habe.
Hier mal ein Auszug aus meiner Logdatei:
2013.04.25 23:54:19 2: CUL_HM set AZ_Tanja_Decke off rxt:1
2013.04.25 23:54:19 2: CUL_HM set AZ_Wolle_Decke off rxt:1
2013.04.25 23:54:19 2: CUL_HM set Flur_Decke off rxt:1
2013.04.25 23:54:19 2: CUL_HM set KU_Unterschrankbeleuchtung off rxt:1
2013.04.25 23:54:19 2: CUL_HM set SZ_Decke off rxt:1
2013.04.25 23:54:19 3: FS20 set SZ_Nachttischlampe_Tanja off
2013.04.25 23:54:19 3: FS20 set SZ_Nachttischlampe_Wolle off
2013.04.25 23:54:19 3: FS20 set SZ_Schranklicht off
2013.04.25 23:54:19 2: CUL_HM set WZ_Beistelllampe_Fenster off rxt:1
2013.04.25 23:54:19 2: CUL_HM set WZ_Media off rxt:1
2013.04.25 23:54:19 2: CUL_HM set WZ_Vitrine off rxt:1
2013.04.25 23:54:23 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:54:23 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:54:23 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:54:39 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:54:39 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:54:39 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:57:16 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:57:16 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:57:16 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:58:47 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:58:47 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:58:47 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:59:03 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:59:03 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.25 23:59:03 2: CUL_HM set WZ_Beistelllampe_Fenster on-for-timer 60 rxt:1
2013.04.26 00:23:01 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 00:23:06 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 00:33:11 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 00:33:16 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 00:43:21 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 00:43:26 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 01:03:41 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 01:03:46 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 01:24:01 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 01:24:06 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 02:04:41 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 02:04:46 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 02:25:01 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 02:25:06 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 02:35:11 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 02:35:16 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 02:55:31 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 02:55:36 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 03:15:51 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 03:15:56 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 03:26:01 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 03:26:06 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 04:06:41 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 04:06:46 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 04:16:51 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 04:16:56 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 04:37:11 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 04:37:16 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 04:57:31 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 04:57:36 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 05:07:41 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 05:07:46 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 05:48:21 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 05:48:26 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 05:58:32 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 05:58:37 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 06:18:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 06:18:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 06:29:02 3: FS20 set SZ_Nachttischlampe_Tanja dim75% 1920
2013.04.26 06:29:02 3: FS20 set SZ_Nachttischlampe_Wolle dim75% 1920
2013.04.26 06:39:12 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 06:39:17 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 07:09:02 3: FS20 set SZ_Nachttischlampe_Tanja off
2013.04.26 07:09:02 3: FS20 set SZ_Nachttischlampe_Wolle off
2013.04.26 07:09:42 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 07:09:47 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 07:15:18 3: Watchdog Abwesenheit_Wolle_w triggered
2013.04.26 07:19:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 07:19:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 07:30:02 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 07:30:07 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 07:40:12 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 07:40:17 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 07:45:23 3: Watchdog Abwesenheit_Tanja_w triggered
2013.04.26 07:45:23 2: CUL_HM set AZ_Tanja_Decke off rxt:1
2013.04.26 07:45:23 2: CUL_HM set AZ_Wolle_Decke off rxt:1
2013.04.26 07:45:23 2: CUL_HM set Flur_Decke off rxt:1
2013.04.26 07:45:23 2: CUL_HM set KU_Unterschrankbeleuchtung off rxt:1
2013.04.26 07:45:23 2: CUL_HM set SZ_Decke off rxt:1
2013.04.26 07:45:23 3: FS20 set SZ_Media off
2013.04.26 07:45:23 3: FS20 set SZ_Nachttischlampe_Tanja off
2013.04.26 07:45:23 3: FS20 set SZ_Nachttischlampe_Wolle off
2013.04.26 07:45:23 3: FS20 set SZ_Schranklicht off
2013.04.26 07:45:23 2: CUL_HM set WZ_Media off rxt:1
2013.04.26 07:45:23 2: CUL_HM set WZ_Vitrine off rxt:1
2013.04.26 07:50:22 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 07:50:27 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 08:31:02 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 08:31:07 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 09:01:32 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 09:01:37 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 09:32:02 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 09:32:07 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 10:02:32 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 10:02:37 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 10:22:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 10:22:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 10:43:12 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 10:43:17 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 11:03:32 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 11:03:37 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 11:23:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 11:23:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 11:34:02 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 11:34:07 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 11:44:12 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 11:44:17 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 12:04:32 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 12:04:37 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 12:24:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 12:24:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 12:45:12 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 12:45:17 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 12:55:22 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 12:55:27 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 13:05:32 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 13:05:37 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 13:25:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 13:25:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 13:56:22 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 13:56:27 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 14:16:42 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 14:16:47 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 14:57:22 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 14:57:27 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 16:18:42 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 16:18:47 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 16:28:52 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 16:28:57 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 16:39:02 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 16:39:07 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 16:49:12 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 16:49:17 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 16:59:22 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.04.26 16:59:27 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.04.26 17:02:12 3: Watchdog Anwesenheit_Wolle_w triggered
2013.04.26 17:02:12 3: FS20 set SZ_Media on
2013.04.26 17:02:12 2: CUL_HM set WZ_Media on rxt:1
2013.04.26 17:02:12 2: WOL set Wolle_internet on
2013.04.26 17:02:12 2: trying to wake 00:22:15:17:7B:8E
2013.04.26 17:02:12 2: trying etherwake with response:
2013.04.26 17:02:12 2: trying direct socket via UDP
2013.04.26 17:02:12 2: trying to wake 00:22:15:17:7B:8E
2013.04.26 17:02:12 2: trying etherwake with response:
2013.04.26 17:02:12 2: trying direct socket via UDP
2013.04.26 17:02:12 2: trying to wake 00:22:15:17:7B:8E
2013.04.26 17:02:12 2: trying etherwake with response:
2013.04.26 17:02:12 2: trying direct socket via UDP
2013.04.26 17:02:12 2: WOL waking Wolle_internet
Sorry für die Länge; ich wollte damit nur zeigen was mir dabei aufgefallen ist.
Ich habe nämlich festgestellt, dass die Disconnects nur ab dem Zeitpunkt auftreten, wenn ich meinen Computer herunterfahre und sie dauern exakt so lange bis mein Computer wieder gestartet wird. Dann findet der Disconnect exakt alle 10 Minuten und 5 Sekunden für die Dauer von 5 Sekunden statt.
FHEM läuft auf meiner Synology und der HM-LAN ist über das Netzwerk auch an diese angeschlossen. Mein Computer nimmt hier nur Client-Funktionen wahr und ist in keinster Weise in die Arbeitsweise von FHEM integriert.
In sofern ist es für mich absolut unverständlich, was der Online bzw. Offline Modus meines Computers für eine Rolle bei der Connektivität des HM-LAN spielt.
Wie gesagt, für mich ist das eigentlich nur ein kosmetisches Problem, weil ich bislang keinerlei Funktionseinbußen feststellen konnte, aber auch ein setzen des Attributes respTime auf 10 beim HM-LAN brachte keine Besserung.
Vielleicht hat jemand einen Tip für mich, wie ich diesem Phänomen weiter auf den Grund gehen kann? Mir fällt nämlich nichts mehr ein.
Gruß
Wolle
WOL set Wolle_internet on
:)
Jaja, mit FHEM kann der Wolle sogar das Internet ein- und ausschalten.
:-D
hast du jetzt falsch verstanden :)
Bekanntes Problem ist WOL. hast du dieses Modul am laufen?
zweites prob ist dblog, ist gerade auch ein kandidat für Fhembremse
den HmLan muss man alle 25, spatestens 30 sec streicheln, sonst mag er nicht mehr,
deswegen der hinweis auf das WOL Modul, irgendetwas bremst den Fhem.
ansonsten wie immer
attr global verbose 1
attr global mseclog 1
attr HMLAN1 loglevel 1
alles andere ist in die GlasKugel schauen, die schweigt gerade bei Dir
:)
und natürlich ein Paar Aussagen zu deinem System :)
Hallo Hary,
WOL habe ich aber erst seit kurzem eingerichtet. Die Disconnects kommen schon bestimmt einen Monat länger. Gefühlt hat das mit der Einrichtung des PRESENCE Dienstes begonnen. Das kann ich aber nicht verifizieren. Ich habe PRESENCE testweise auch mal auskommentiert und FHEM neu gestartet. Das brachte allerdings auch keine Veränderung.
Ich kann auch immer noch keinen Zusammenhang mit dem Online bzw. Offlinestatus meines Computers erkennen, der ja mit der FHEM Steuerung gar nichts zu tun hat.
Mit den Glaskugeln ist das natürlich immer so eine Sache; leider funktionieren die irgendwie nie. ;-) Da ich mich im Debuggen auch nicht auskenne und auch keinen Sticky-Post gefunden habe, welche Einstellungen getätigt werden müssen, damit bestimmte Infomationen kommen, hatte ich gehofft, dass mir da jemand auf die Sprünge hilft, was du mit
attr global verbose 1
attr global mseclog 1
attr HMLAN1 loglevel 1
ja auch dankenswerter Weise getan hast.
Da hier natürlich eine Fülle an Informationen in mein Logfile flossen, füge ich hier mal nur einen Ausschnitt zwischen zwei Disconnects ein:
2013.05.02 07:58:57.380 1: HMLAN_Parse: HMLAN1 R:E1A3833 stat:0000 t:7526AB0F d:FF r:FFBA m:09 8670 1A3833 000000 007056
2013.05.02 07:59:22.357 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 07:59:22.360 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75270CAE,0000
2013.05.02 07:59:22.360 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75270CAE IDcnt:0000
2013.05.02 07:59:47.362 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 07:59:47.365 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75276E5E,0000
2013.05.02 07:59:47.365 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75276E5E IDcnt:0000
2013.05.02 08:00:22.146 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.05.02 08:00:27.160 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.05.02 08:00:27.161 1: HMLAN_Send: HMLAN1 I:A567CDE
2013.05.02 08:00:27.161 1: HMLAN_Send: HMLAN1 I:C
2013.05.02 08:00:27.161 1: HMLAN_Send: HMLAN1 I:Y01,01,
2013.05.02 08:00:27.162 1: HMLAN_Send: HMLAN1 I:Y02,00,
2013.05.02 08:00:27.162 1: HMLAN_Send: HMLAN1 I:Y03,00,
2013.05.02 08:00:27.162 1: HMLAN_Send: HMLAN1 I:Y03,00,
2013.05.02 08:00:27.162 1: HMLAN_Send: HMLAN1 I:T1914BD7B,04,00,00000000
2013.05.02 08:00:27.225 1: HMLAN_Send: HMLAN1 I:+1B786D,00,00,
2013.05.02 08:00:27.226 1: HMLAN_Send: HMLAN1 S:S63D3D698 stat: 00 t:00000000 d:01 r:63D3D698 m:1C A011 567CDE 1B786D 0201000000
2013.05.02 08:00:27.262 1: HMLAN_Send: HMLAN1 I:+1B7659,00,00,
2013.05.02 08:00:27.262 1: HMLAN_Send: HMLAN1 S:S63D3D6BC stat: 00 t:00000000 d:01 r:63D3D6BC m:1D A011 567CDE 1B7659 0201000000
2013.05.02 08:00:27.303 1: HMLAN_Send: HMLAN1 I:+1BD486,00,00,
2013.05.02 08:00:27.304 1: HMLAN_Send: HMLAN1 S:S63D3D6E6 stat: 00 t:00000000 d:01 r:63D3D6E6 m:1E A011 567CDE 1BD486 0201000000
2013.05.02 08:00:27.357 1: HMLAN_Send: HMLAN1 I:+1B7859,00,00,
2013.05.02 08:00:27.358 1: HMLAN_Send: HMLAN1 S:S63D3D71C stat: 00 t:00000000 d:01 r:63D3D71C m:1F A011 567CDE 1B7859 0201000000
2013.05.02 08:00:27.387 1: HMLAN_Send: HMLAN1 I:+1B7325,00,00,
2013.05.02 08:00:27.388 1: HMLAN_Send: HMLAN1 S:S63D3D73A stat: 00 t:00000000 d:01 r:63D3D73A m:20 A011 567CDE 1B7325 0201000000
2013.05.02 08:00:27.624 1: HMLAN_Send: HMLAN1 I:+1ED071,00,00,
2013.05.02 08:00:27.625 1: HMLAN_Send: HMLAN1 S:S63D3D827 stat: 00 t:00000000 d:01 r:63D3D827 m:21 A011 567CDE 1ED071 0201000000
2013.05.02 08:00:27.682 1: HMLAN_Send: HMLAN1 I:+1B786C,00,00,
2013.05.02 08:00:27.683 1: HMLAN_Send: HMLAN1 S:S63D3D861 stat: 00 t:00000000 d:01 r:63D3D861 m:22 A011 567CDE 1B786C 0201000000
2013.05.02 08:00:27.691 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752809DB,0000
I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00
2013.05.02 08:00:27.692 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752809DB IDcnt:0000
2013.05.02 08:00:27.982 1: HMLAN/RAW: /R63D3D73A,0001,75280D0D,FF,FFC6,2080021B7325567CDE0101000039
2013.05.02 08:00:27.982 1: HMLAN_Parse: HMLAN1 R:R63D3D73A stat:0001 t:75280D0D d:FF r:FFC6 m:20 8002 1B7325 567CDE 0101000039
2013.05.02 08:00:28.031 1: HMLAN/RAW: /R63D3D698,0008,00000000,FF,7FFF,1CA011567CDE1B786D0201000000
R63D3D6E6,0001,75280D25,FF,FFCF,1E80021BD486567CDE010100002F
R63D3D6BC,0008,00000000,FF,7FFF,1DA011567CDE1B76590201000000
2013.05.02 08:00:28.032 1: HMLAN_Parse: HMLAN1 R:R63D3D698 stat:0008 t:00000000 d:FF r:7FFF m:1C A011 567CDE 1B786D 0201000000
2013.05.02 08:00:28.032 1: HMLAN_Parse: HMLAN1 discard
2013.05.02 08:00:28.032 1: HMLAN_Parse: HMLAN1 R:R63D3D6E6 stat:0001 t:75280D25 d:FF r:FFCF m:1E 8002 1BD486 567CDE 010100002F
2013.05.02 08:00:28.078 1: HMLAN_Parse: HMLAN1 R:R63D3D6BC stat:0008 t:00000000 d:FF r:7FFF m:1D A011 567CDE 1B7659 0201000000
2013.05.02 08:00:28.078 1: HMLAN_Parse: HMLAN1 discard
2013.05.02 08:00:28.253 1: HMLAN/RAW: /R63D3D71C,0001,75280E1D,FF,FFBB,1F80021B7859567CDE0101000043
2013.05.02 08:00:28.253 1: HMLAN_Parse: HMLAN1 R:R63D3D71C stat:0001 t:75280E1D d:FF r:FFBB m:1F 8002 1B7859 567CDE 0101000043
2013.05.02 08:00:28.294 1: HMLAN/RAW: /R63D3D827,0008,00000000,FF,7FFF,21A011567CDE1ED0710201000000
2013.05.02 08:00:28.295 1: HMLAN_Parse: HMLAN1 R:R63D3D827 stat:0008 t:00000000 d:FF r:7FFF m:21 A011 567CDE 1ED071 0201000000
2013.05.02 08:00:28.295 1: HMLAN_Parse: HMLAN1 discard
2013.05.02 08:00:28.322 1: HMLAN/RAW: /R63D3D861,0008,00000000,FF,7FFF,22A011567CDE1B786C0201000000
2013.05.02 08:00:28.323 1: HMLAN_Parse: HMLAN1 R:R63D3D861 stat:0008 t:00000000 d:FF r:7FFF m:22 A011 567CDE 1B786C 0201000000
2013.05.02 08:00:28.323 1: HMLAN_Parse: HMLAN1 discard
2013.05.02 08:00:29.230 1: HMLAN_Send: HMLAN1 S:S63D3DE6C stat: 00 t:00000000 d:01 r:63D3DE6C m:1C A011 567CDE 1B786D 0201000000
2013.05.02 08:00:29.265 1: HMLAN_Send: HMLAN1 S:S63D3DE8F stat: 00 t:00000000 d:01 r:63D3DE8F m:1D A011 567CDE 1B7659 0201000000
2013.05.02 08:00:29.385 1: HMLAN/RAW: /R63D3DE6C,0001,7528128A,FF,FFC8,1C80021B786D567CDE0101000038
2013.05.02 08:00:29.386 1: HMLAN_Parse: HMLAN1 R:R63D3DE6C stat:0001 t:7528128A d:FF r:FFC8 m:1C 8002 1B786D 567CDE 0101000038
2013.05.02 08:00:29.430 1: HMLAN/RAW: /R63D3DE8F,0001,752812AD,FF,FFC0,1D80021B7659567CDE010100003E
2013.05.02 08:00:29.430 1: HMLAN_Parse: HMLAN1 R:R63D3DE8F stat:0001 t:752812AD d:FF r:FFC0 m:1D 8002 1B7659 567CDE 010100003E
2013.05.02 08:00:29.628 1: HMLAN_Send: HMLAN1 S:S63D3DFFA stat: 00 t:00000000 d:01 r:63D3DFFA m:21 A011 567CDE 1ED071 0201000000
2013.05.02 08:00:29.685 1: HMLAN_Send: HMLAN1 S:S63D3E033 stat: 00 t:00000000 d:01 r:63D3E033 m:22 A011 567CDE 1B786C 0201000000
2013.05.02 08:00:29.784 1: HMLAN/RAW: /R63D3DFFA,0001,75281419,FF,FFBB,2180021ED071567CDE0101000044
2013.05.02 08:00:29.785 1: HMLAN_Parse: HMLAN1 R:R63D3DFFA stat:0001 t:75281419 d:FF r:FFBB m:21 8002 1ED071 567CDE 0101000044
2013.05.02 08:00:29.841 1: HMLAN/RAW: /R63D3E033,0001,75281453,FF,FFC1,2280021B786C567CDE010100003E
2013.05.02 08:00:29.841 1: HMLAN_Parse: HMLAN1 R:R63D3E033 stat:0001 t:75281453 d:FF r:FFC1 m:22 8002 1B786C 567CDE 010100003E
2013.05.02 08:00:36.064 1: HMLAN/RAW: /E1A5191,0000,75282C9C,FF,FFD2,76A6101A51911C391606014F00
2013.05.02 08:00:36.065 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:75282C9C d:FF r:FFD2 m:76 A610 1A5191 1C3916 06014F00
2013.05.02 08:00:36.494 1: HMLAN/RAW: /E1A5191,0000,75282E49,FF,FFD2,76A6101A51911C391606014F00
2013.05.02 08:00:36.494 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:75282E49 d:FF r:FFD2 m:76 A610 1A5191 1C3916 06014F00
2013.05.02 08:00:36.838 1: HMLAN/RAW: /E1A5191,0000,75282FA2,FF,FFD2,76A6101A51911C391606014F00
2013.05.02 08:00:36.839 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:75282FA2 d:FF r:FFD2 m:76 A610 1A5191 1C3916 06014F00
2013.05.02 08:00:52.174 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:00:52.177 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75286B96,0007
2013.05.02 08:00:52.177 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75286B96 IDcnt:0007
2013.05.02 08:01:17.182 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:01:17.185 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,7528CD49,0007
2013.05.02 08:01:17.186 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:7528CD49 IDcnt:0007
2013.05.02 08:01:25.482 1: HMLAN/RAW: /E1A3833,0000,7528ED53,FF,FFB8,0A86701A3833000000007056
2013.05.02 08:01:25.482 1: HMLAN_Parse: HMLAN1 R:E1A3833 stat:0000 t:7528ED53 d:FF r:FFB8 m:0A 8670 1A3833 000000 007056
2013.05.02 08:01:42.185 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:01:42.188 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75292EF7,0007
2013.05.02 08:01:42.188 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75292EF7 IDcnt:0007
2013.05.02 08:02:07.188 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:02:07.191 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752990A5,0007
2013.05.02 08:02:07.191 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752990A5 IDcnt:0007
2013.05.02 08:02:32.199 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:02:32.202 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,7529F25C,0007
2013.05.02 08:02:32.203 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:7529F25C IDcnt:0007
2013.05.02 08:02:57.205 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:02:57.208 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752A540D,0007
2013.05.02 08:02:57.208 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752A540D IDcnt:0007
2013.05.02 08:03:22.210 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:03:22.213 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752AB5BD,0007
2013.05.02 08:03:22.214 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752AB5BD IDcnt:0007
2013.05.02 08:03:38.907 1: HMLAN/RAW: /E1A3833,0000,752AF6ED,FF,FFB8,0B86701A3833000000007256
2013.05.02 08:03:38.907 1: HMLAN_Parse: HMLAN1 R:E1A3833 stat:0000 t:752AF6ED d:FF r:FFB8 m:0B 8670 1A3833 000000 007256
2013.05.02 08:03:47.217 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:03:47.220 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752B176F,0007
2013.05.02 08:03:47.220 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752B176F IDcnt:0007
2013.05.02 08:04:12.229 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:04:12.232 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752B7927,0007
2013.05.02 08:04:12.233 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752B7927 IDcnt:0007
2013.05.02 08:04:37.232 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:04:37.235 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752BDAD4,0007
2013.05.02 08:04:37.235 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752BDAD4 IDcnt:0007
2013.05.02 08:05:02.238 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:05:02.241 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752C3C86,0007
2013.05.02 08:05:02.241 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752C3C86 IDcnt:0007
2013.05.02 08:05:17.075 1: HMLAN/RAW: /E1A5191,0000,752C7671,FF,FFD2,77A6101A51911C391606014F00
2013.05.02 08:05:17.076 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:752C7671 d:FF r:FFD2 m:77 A610 1A5191 1C3916 06014F00
2013.05.02 08:05:17.307 1: HMLAN/RAW: /E1A5191,0000,752C775A,FF,FFD2,77A6101A51911C391606014F00
2013.05.02 08:05:17.307 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:752C775A d:FF r:FFD2 m:77 A610 1A5191 1C3916 06014F00
2013.05.02 08:05:17.895 1: HMLAN/RAW: /E1A5191,0000,752C79A6,FF,FFD2,77A6101A51911C391606014F00
2013.05.02 08:05:17.895 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:752C79A6 d:FF r:FFD2 m:77 A610 1A5191 1C3916 06014F00
2013.05.02 08:05:27.250 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:05:27.253 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752C9E3D,0007
2013.05.02 08:05:27.253 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752C9E3D IDcnt:0007
2013.05.02 08:05:52.254 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:05:52.257 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752CFFEC,0007
2013.05.02 08:05:52.257 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752CFFEC IDcnt:0007
2013.05.02 08:06:17.257 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:06:17.260 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752D619A,0007
2013.05.02 08:06:17.260 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752D619A IDcnt:0007
2013.05.02 08:06:42.173 1: HMLAN/RAW: /E1A3833,0000,752DC2E7,FF,FFB9,0C86701A3833000000007356
2013.05.02 08:06:42.174 1: HMLAN_Parse: HMLAN1 R:E1A3833 stat:0000 t:752DC2E7 d:FF r:FFB9 m:0C 8670 1A3833 000000 007356
2013.05.02 08:06:42.259 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:06:42.262 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752DC347,0007
2013.05.02 08:06:42.262 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752DC347 IDcnt:0007
2013.05.02 08:07:07.265 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:07:07.268 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752E24F8,0007
2013.05.02 08:07:07.268 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752E24F8 IDcnt:0007
2013.05.02 08:07:32.270 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:07:32.273 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752E86A9,0007
2013.05.02 08:07:32.273 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752E86A9 IDcnt:0007
2013.05.02 08:07:57.275 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:07:57.278 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752EE859,0007
2013.05.02 08:07:57.278 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752EE859 IDcnt:0007
2013.05.02 08:08:22.278 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:08:22.281 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752F4A07,0007
2013.05.02 08:08:22.282 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752F4A07 IDcnt:0007
2013.05.02 08:08:47.285 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:08:47.288 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,752FABB9,0007
2013.05.02 08:08:47.288 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:752FABB9 IDcnt:0007
2013.05.02 08:09:12.295 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:09:12.299 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75300D6F,0007
2013.05.02 08:09:12.299 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75300D6F IDcnt:0007
2013.05.02 08:09:29.083 1: HMLAN/RAW: /E1A5191,0000,75304EFA,FF,FFD2,78A6101A51911C391606014F00
2013.05.02 08:09:29.084 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:75304EFA d:FF r:FFD2 m:78 A610 1A5191 1C3916 06014F00
2013.05.02 08:09:29.736 1: HMLAN/RAW: /E1A5191,0000,75305187,FF,FFD2,78A6101A51911C391606014F00
2013.05.02 08:09:29.737 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:75305187 d:FF r:FFD2 m:78 A610 1A5191 1C3916 06014F00
2013.05.02 08:09:30.253 1: HMLAN/RAW: /E1A5191,0000,7530538C,FF,FFD2,78A6101A51911C391606014F00
2013.05.02 08:09:30.254 1: HMLAN_Parse: HMLAN1 R:E1A5191 stat:0000 t:7530538C d:FF r:FFD2 m:78 A610 1A5191 1C3916 06014F00
2013.05.02 08:09:30.939 1: HMLAN/RAW: /E1A3833,0000,7530563A,FF,FFBA,0D86701A3833000000007456
2013.05.02 08:09:30.939 1: HMLAN_Parse: HMLAN1 R:E1A3833 stat:0000 t:7530563A d:FF r:FFBA m:0D 8670 1A3833 000000 007456
2013.05.02 08:09:37.304 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:09:37.307 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75306F22,0007
2013.05.02 08:09:37.307 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75306F22 IDcnt:0007
2013.05.02 08:10:02.308 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:10:02.311 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,7530D0D1,0007
2013.05.02 08:10:02.311 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:7530D0D1 IDcnt:0007
2013.05.02 08:10:32.171 1: 192.168.178.23:1000 disconnected, waiting to reappear
2013.05.02 08:10:37.184 1: 192.168.178.23:1000 reappeared (HMLAN1)
2013.05.02 08:10:37.185 1: HMLAN_Send: HMLAN1 I:A567CDE
2013.05.02 08:10:37.185 1: HMLAN_Send: HMLAN1 I:C
2013.05.02 08:10:37.185 1: HMLAN_Send: HMLAN1 I:Y01,01,
2013.05.02 08:10:37.186 1: HMLAN_Send: HMLAN1 I:Y02,00,
2013.05.02 08:10:37.186 1: HMLAN_Send: HMLAN1 I:Y03,00,
2013.05.02 08:10:37.186 1: HMLAN_Send: HMLAN1 I:Y03,00,
2013.05.02 08:10:37.186 1: HMLAN_Send: HMLAN1 I:T1914BFDD,04,00,00000000
2013.05.02 08:10:37.197 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75315913,0007
2013.05.02 08:10:37.197 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:75315913 IDcnt:0007
2013.05.02 08:10:37.391 1: HMLAN/RAW: /I00,00,00,00
I00,00,00,00
I00,00,00,00
I00,00,00,00
2013.05.02 08:11:02.195 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:11:02.198 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,7531BAC8,0000
2013.05.02 08:11:02.198 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0314510 d:1C6A69 O:567CDE t:7531BAC8 IDcnt:0000
2013.05.02 08:11:27.205 1: HMLAN_Send: HMLAN1 I:K
2013.05.02 08:11:27.209 1: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0314510,1C6A69,567CDE,75321C7E,0000
Mir sagen diese ganzen Codes leider überhaupt nichts. 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?
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
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
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
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
@ Martin
ich habe eine Änderung an WOL(NAS-Control für Buffalo) in der Mache und will sie mit Boris irgendwann freischalten:
Link (http://forum.fhem.de/index.php?topic=10354.msg58332#msg58332)
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.
schau mal im presence modul. da wird alles in einem geforkten prozess aufgerufen.
gruss
andre
ist das der Aufruf von Blockincall?
(siehe Anhang / see attachement)
ja. der aufruf geht per BlockigCall.
hier Link (http://forum.fhem.de/index.php?topic=9731.msg54876#msg54876) stehen ein paar anmerkungen von rudi.
gruss
andre
aha - Danke!
mit der Erklärung ist das bestimmt machbar.
@ 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 (http://forum.fhem.de/index.php?topic=10354.msg58332#msg58332)
aktuelle Definition
define NAS WOL 00:24:A5:A6:10:E0 192.168.2.196 UDP 240
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
Ich habs, es ist der Yamaha gewesen der nicht an war. Nur wie bekomm ich das jetzt in den Griff?
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.
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
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!
Ich habe soeben ins Modul geschaut und gesehen, dass es genau so ist wie du schreibst - ping wird nicht genutzt, http Aufrufe wirken aber vielleicht ähnlich.
Kann es dann sein, dass wenn der Receiver nicht angeschaltet ist, etwas länger auf eine Antwort gewartet wird, dadurch fhem, wie hier im Thread beschrieben, blockiert und dann HMLAN nicht wach gehalten wird?
Die Beschreibung von AK-868 deutet jedenfalls darauf hin: Nachdem er den Receiver angeschaltet hat war das Problem scheibar gelöst.
Vielleicht hilft es ja auch den Status des Receivers seltener abzufragen.
Zitat von: Dietmar63 schrieb am Do, 09 Mai 2013 16:07Kann es dann sein, dass wenn der Receiver nicht angeschaltet ist, etwas länger auf eine Antwort gewartet wird, dadurch fhem, wie hier im Thread beschrieben, blockiert und dann HMLAN nicht wach gehalten wird?
Das kommt drauf an was AK-868 mit ausgeschaltet meint.
Meint er mit ausgeschaltet wirklich physikalisch den Strom zu trennen? Dann ja, da würde es zu der genannten 10 Sekunden-Verzögerung kommen, da der Receiver nicht antwortet.
Meint er mit ausgeschaltet den Receiver per Fernbedienung auszuschalten ohne aktivierten Network-Standby (keine rote Standby-Leuchte am Receiver)? Da würde es ebenfalls zu der 10 Sekunden Verzögerung kommen.
Meint er mit ausgeschaltet den Receiver per Fernbedienung auszuschalten mit aktivierten Network-Standby (rote Standby-Leuchte am Receiver leuchtet)? Dann nein. In diesem Fall antwortet der Receiver sofort und die Antwort wird sofort durch FHEM verarbeitet ohne nennenswerte Verzögerung.
Genau aus diesem Grund wird in der Commandref hingewiesen den Network Standby zu aktivieren. Was ich daher nur machen kann, ist die Wartezeit auf die HTTP Antwort runter zu setzen auf ca. 5 Sekunden. Weiter runter würde ich da nicht gehen wollen.
Viele Grüße
Markus
Natürlich kann ich auch nur 1 Sekunde auf eine HTTP Antwort warten, aber das währe in dem ein oder anderen Fall zu wenig.
Ich habe im SVN die Wartezeit jetzt auf 4 Sekunden gesetzt. im HMLAN wird aller 25 Sekunden ein KeepAlive gesendet was innerhalb von 30 Sekunden ankommen muss. Damit sollte also noch 1 Sekunde Luft bleiben.
Bitte morgen via update installieren oder direkt aus dem SVN ziehen.
Viele Grüße
Markus
Ich hab getrennt geschrieben.
Getrennt = Kein Netzwerk zugriff
Getrennt = Network Standby nicht aktiv
Getrennt = Kein Strom
Ich habe noch ganz Oldschool eine Steckdosenleiste mit Schalter daran. Das soll sich aber bald ändern mit einem EQ-767-93.
Da wird der Yamaha aber auch keinen Strom haben. Ohne Strom kein Network Standby.
Oder ich muß irgendwann wenn ich das mal kann ein Programm schreiben, das wenn ich nicht Zuhause bin der Yamaha nicht definiert ist.
Wenn ich dann hier her komme er definiert wird.
Was FEHM angeht bin ich noch gaaaanz unten.
Andre
Versuchs erstmal morgen mit dem update ;-)
Jeder hat mal klein angefangen.
Viele Grüße
Markus
OT:
Update ist schon drauf, oder gibts schon wieder was neues?
Yamaha lässt sich ja auch Steuern, alles super ;)
Lad-Adapter ist dran und zwei aktoren für Jalousien sind jetzt verbunden.
Ich such gerade rum wie ich die umbenannt bekomme. Im Wiki steht da ist nix mit umbennen... naja...
Vorallem die Fahrzeiten sind noch utopisch, ich möchte die auch ändern? FHEM How to ich google schon überdurchschnittlich viel ;)
Ab morgen wird mit eine Update eine neue Yamaha-Version verteilt, die FHEM nicht mehr so stark behindert, so das die LAN Disconnects weniger bis gar nicht mehr vorkommen sollten.
Um ein Device umzubenennen einfach in der Oberfäche oben "rename <name-alt> <name-neu>" eingeben.
Um die Fahrzeiten einzustellen einfach die Fahrzeiten messen und dann mit den Befehlen eintragen:
set <name> regSet driveUp 26.0 # Fahrtzeit nach oben
set <name> regSet driveDown 26.0 # Fahrtzeit nach unten (ist meistens identisch mit der Fahrtzeit nach oben
set <name> regSet driveTurn 0.2 # Die Zeit die gebraucht wird um die Fahrtrichtung zu wechseln
Alle angaben in Sekunden mit einer Kommastelle.
Viele Grüße
Markus
Hallo Markus, echt super das du mir da so hilfst!!
Bin dir zu Dank verpflichtet
@Markus
Ich halte alle Wartezeiten über 100ms für unschön, über 1sec für nicht akzeptabel. Immerhin hat dies Auswirkungen auf das schalten und anderes mehr.
Das Disconnect wird es wahrscheinlich beheben, es macht aber FHEM instabil und unzuverlässig.
Im presents modul ist bereits eine einfache Implementierung aktiv, die solche Wartezeiten dispatched. Es ist auf jeden Fall eine Möglichkeit, wird es auch noch einmal verbessert, so dass man einen sauberen parallel-prozess am laufen hat.
Wäre cool, wenn du das Warten aus dem main-process entfernen könntest.
Gruss
Martin
Werd ich mich demnächst mal drum kümmern.
@ Martin
@ Andre
Da habe ich ja ordentlich was losgetreten.
Ist denn niemand dabei, der das 98_WOL testen kann. Das war nämlich meine eigentliche Absicht. Auch dort ist ein
ping enthalten, der Blockieren verursachen kann, den ich ausgebaut habe. Ich würde es nicht so gern einchecken bevor nicht jemand Drittes darauf geschaut hat:
Link (http://forum.fhem.de/index.php?topic=11270.msg76795#msg76795)
Hallo Dietmar,
ich habe mir dein Modul angeschaut und würde es gerne noch überarbeiten da hier noch einige wichtige Details fehlen.
* UndefFn um einen laufenden Fork zu beenden bei einem Shutdown oder Neustart
* eine adequate AbortFn inkl. Argumenten um den InternalTimer weiterlaufen zu lassen im Falle eines Abbruchs
* verhindern von parrallelen aufrufen, die sich sonst später hochschaukeln können
Dies sind alles Randdetails die sich im Laufe der Zeit bei meinem PRESENCE-Modul offenbart haben. Ich würde das gerne noch einmal überarbeiten wollen. Was ich aber erst ab Samstag schaffen würde.
Viele Grüße
Markus
das wäre klasse!
Zitat von: Markus Bloch schrieb am Do, 09 Mai 2013 22:11Hallo Dietmar,
ich habe mir dein Modul angeschaut und würde es gerne noch überarbeiten da hier noch einige wichtige Details fehlen.
* UndefFn um einen laufenden Fork zu beenden bei einem Shutdown oder Neustart
* eine adequate AbortFn inkl. Argumenten um den InternalTimer weiterlaufen zu lassen im Falle eines Abbruchs
* verhindern von parrallelen aufrufen, die sich sonst später hochschaukeln können
Dies sind alles Randdetails die sich im Laufe der Zeit bei meinem PRESENCE-Modul offenbart haben. Ich würde das gerne noch einmal überarbeiten wollen. Was ich aber erst ab Samstag schaffen würde.
Viele Grüße
Markus
ich sehe mir deine Anmerkungen heute nochmals an. Presence ist ja ein gutes Beispiel.
Dann ist es vielleicht schon am Samstag fertig.
Hallo Dietmar,
anbei die überarbeitete Version von WOL mit BlockingCall für Ping und shutdownCmd.
Viel Spaß
Gruß
Markus
hast du alles getestet?
wie gestaltet sich die Freigabe. Ich würde es übernehmen, da Boris ziemlich busy ist.
Hallo Dietmar,
ich hab alles im Zusammenhang mit BlockingCall getestet. Währe gut, wenn du es nochmal komplett testest mit allem drum und drann, da ich kein WOL nutze.
Zur Freigabe
Da man Rudi nicht via PN anschreiben kann und du wahrscheinlich in FHEM Development nichts posten darfst, würde ich es mit einem Post in "Unterstützende Dienste" versuchen mit der Bitte zum einchecken.
Viele Grüße
Markus
Ich hatte auch den dauernden Disconnect.
Habe ihn in den Griff bekommen mit dem hier erwähnten:
attr HMLAN1 respTime 5
Seitdem nicht mehr aufgetreten.
Falls sich noch jemand mit dem Problem herumschlaegt: ich habe das Gefühl, dass es bei mir ursächlich mit der Kanalwahl des Fritz WLAN Adapters zusammenhängt. Er wählt einen Kanal, auf dem sich schon viele andere tummeln. Habe ich jetzt mal umgestellt.
Ich hatte auch diese disconnects...
Seitdem ich den HMLAN alle 15 sec "streichle" habe ich keine Meldungen mehr im Log.
Bitte korrigiert mich sollte ich falsch liegen: de Netzlast die durch die herabsetzung der Timer erzeugt wird ist in einem GigE Netz vernachlässigbar und Skalierungsprobleme sollten nur dann auftreten falls ich massenhaft HMLANs hinzufügen würde. nicht aber bei zusätzlichen Sensoren oder Aktoren.
Wäre es bitte möglich den "Streicheltimer" in die HMLAN Config einstellbar zu machen?
Hallo thunder,
ja, das ethernet selbst sollte in den wenigsten Faellen ein Problem darstellen.
wenn du bei ~15sec keine Probleme mehr hast heist dass im Rueckschluss, dass ein Task dein FHEM um 15sec ausbremst/lahmlegt. Das heist, dass ggf das einschalten deines Lichts um 15 sec verzoegert werden kann, wenn es ueber fhem kommt. Auch kann es zu protokoll-abbruechen kommen.
In meinem System wuerde ich so etwas nie akzeptieren, das hat nichts mehr mit echtzeit zu tun, besonders wenn es haeufig kommt.
Ich arbeite gerade an 'echten' HMLAN Problemen - evtl baue ich es ein... lass mich einmal nachdenken ;-) wahrscheinlich wird es also kommen.
Empfehlen kann und werde ich es niemandem - es ist eine ueble Symthpombehandlung.
Das Problem der Verzoegerung ist natuerlich nicht HM-eigen sondern betrifft alle Familien und alles, was von FHEM getriggert werden soll/muss. Faktisch ist es ein FHEM design/architektur fehler, wenn es auftritt und sollte nicht in x workarounds geloest werden sondern an der Quelle.
Gruss Martin
Hallo Thunder,
wdTimer kannst du jetzt nutzen. 5-25sec sind zugelassen.
Gruss Martin
Hallo Martin,
selbst wenn ich au 5s keepalives herunter gehe bekomme ich die disconnects. Da das System auf dem FHEM läuft ein i5 mit 6GB RAM ist und ansonsten eigentlich nur einen Asterisk beheimatet (der sich übrigens völligunauffällig verhält) würde ich fast ausschliessen, daß es auf dem Server ein bottleneck gibt.
Ich werde mich jetzt dran machen Netzwerk Traces zu ziehen. da das LAN geswitched ist: ist es besser den Trace nah am FHEM oder nah am HMLAN zu ziehen?
Nachtrag:
ich beginne gerade ich ganz zaghaft dem HMLAN zu nähern und stelle bein Anpingen ein ungewöhnliches Verhalten fest:
ping 192.168.10.7
PING 192.168.10.7 (192.168.10.7) 56(84) bytes of data.
64 bytes from 192.168.10.7: icmp_seq=1 ttl=128 time=0.484 ms
64 bytes from 192.168.10.7: icmp_seq=45 ttl=128 time=0.383 ms
64 bytes from 192.168.10.7: icmp_seq=46 ttl=128 time=0.363 ms
64 bytes from 192.168.10.7: icmp_seq=47 ttl=128 time=0.357 ms
64 bytes from 192.168.10.7: icmp_seq=48 ttl=128 time=0.396 ms
64 bytes from 192.168.10.7: icmp_seq=49 ttl=128 time=0.387 ms
64 bytes from 192.168.10.7: icmp_seq=93 ttl=128 time=0.356 ms
64 bytes from 192.168.10.7: icmp_seq=94 ttl=128 time=0.347 ms
64 bytes from 192.168.10.7: icmp_seq=95 ttl=128 time=0.358 ms
64 bytes from 192.168.10.7: icmp_seq=96 ttl=128 time=0.397 ms
64 bytes from 192.168.10.7: icmp_seq=97 ttl=128 time=0.419 ms
64 bytes from 192.168.10.7: icmp_seq=141 ttl=128 time=0.365 ms
64 bytes from 192.168.10.7: icmp_seq=142 ttl=128 time=0.345 ms
64 bytes from 192.168.10.7: icmp_seq=143 ttl=128 time=0.353 ms
64 bytes from 192.168.10.7: icmp_seq=144 ttl=128 time=0.386 ms
64 bytes from 192.168.10.7: icmp_seq=145 ttl=128 time=0.380 ms
64 bytes from 192.168.10.7: icmp_seq=189 ttl=128 time=0.395 ms
64 bytes from 192.168.10.7: icmp_seq=190 ttl=128 time=0.431 ms
64 bytes from 192.168.10.7: icmp_seq=191 ttl=128 time=0.426 ms
64 bytes from 192.168.10.7: icmp_seq=192 ttl=128 time=0.380 ms
64 bytes from 192.168.10.7: icmp_seq=193 ttl=128 time=0.373 ms
64 bytes from 192.168.10.7: icmp_seq=238 ttl=128 time=0.411 ms
64 bytes from 192.168.10.7: icmp_seq=239 ttl=128 time=0.329 ms
64 bytes from 192.168.10.7: icmp_seq=240 ttl=128 time=0.331 ms
64 bytes from 192.168.10.7: icmp_seq=241 ttl=128 time=0.369 ms
64 bytes from 192.168.10.7: icmp_seq=242 ttl=128 time=0.351 ms
64 bytes from 192.168.10.7: icmp_seq=287 ttl=128 time=0.382 ms
64 bytes from 192.168.10.7: icmp_seq=288 ttl=128 time=0.358 ms
64 bytes from 192.168.10.7: icmp_seq=289 ttl=128 time=0.374 ms
64 bytes from 192.168.10.7: icmp_seq=290 ttl=128 time=0.382 ms
64 bytes from 192.168.10.7: icmp_seq=291 ttl=128 time=0.413 ms
HMLAN antwortet auf fünf Pings und dann ist für längere Zeit Ruhen dann wieder fünf Antworten usw... In Summe 89% packet loss.
Ein Ping auf den letzten Switch vor dem HMLAN bringt 0% packet loss.
Ich gehe davon aus, daß die Pakete nicht auf dem Netz sondern im HMLAN verloren werden...
Nachtrag zum Nachtrag:
das seltsame ping-Verhalten ist auch im Betrieb mit dem Homematic Konfigurationsprogramm unter Windows zu beobachten...
hm - mein HMLAN antwortet der FB immer. Es dauert zwar doppelt so lange (0.8ms) aber ist stabil.
Ich nehme an, dass andere Devices in deinem Netz sauber pingen.
Dann hat dein HMLAN wohl Probleme. Evtl kannst du noch einmal die FW runterladen (wenn es klappt...)
Hallo Martin,
das war der richtige Tipp. FW update und die pings laufen sauber....
bis jetzt auch keine disconnects...
jetzt ist nur die Frage was den HMLAN so aus dem Tritt gebracht hat. aber ich befürchte die Frage werden wir nie mehr beantworten können ;-)
Hallo thunder,
gut zu hoeren - sollten wir uns als Option merken
spekulieren kann man viel:
- FW version war nicht die aktuelle
- HMLAN hatte einen flash-fehler und das Programm war korrupt
- ein FW-update "koennte" sonstige Einstellungen im HMLAN ruecksetzen/loeschen???
Gruss Martin
Hallo Martin,
ich halte die Möglichkeit
Zitatein FW-update "koennte" sonstige Einstellungen im HMLAN ruecksetzen/loeschen???
für die wahrscheinlichste und hoffe auf die Forschungsergebnisse zum FHEM gesteuerten reset des HMLAN
:-)