Hallo zusammen,
ich betreibe FHEM auf einem Cubieboard mit einem HMLAN-Konfigurator. Es kommt in unregelmäßigen Abständen, aber wie ich finde recht oft, zu Disconnects:
2014.12.15 14:49:23 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.12.15 14:49:23 1: 192.168.1.67:1000 disconnected, waiting to reappear (HMLAN1)
2014.12.15 14:49:23 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.12.15 14:50:35 1: 192.168.1.67:1000 reappeared (HMLAN1)
2014.12.15 14:50:35 1: HMLAN_Parse: HMLAN1 new condition init
2014.12.15 14:50:35 1: HMLAN_Parse: HMLAN1 new condition ok
2014.12.15 15:05:17 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.12.15 15:05:17 1: 192.168.1.67:1000 disconnected, waiting to reappear (HMLAN1)
2014.12.15 15:05:17 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.12.15 15:05:22 1: 192.168.1.67:1000 reappeared (HMLAN1)
Wenn ich von meinem PC aus einen Dauerping auf den HMLANCFG laufen lasse sieht man, das immer zur Zeit der geloggten Disconnects die Response-Zeiten extrem lang werden (4-8 Sekunden, immer 3-5 Pakete, danach wieder Anwortzeiten im 1ms-Bereich). Mein Netzwerk besteht aus einem DSL-Router mit 2 daran angeschlossenen Switchen (100 Mbit und 1 GBit). Ich glaube ich habe nun schon alles ausprobiert was man ausprobieren kann, um die Disconnects los zu werden, im Einzelnen:
- FHEM abgeschaltet und nur HMLANCFG eingeschaltet gelassen
- Cubieboard und HMLANCFG an den gleichen Switch angeschlossen (keine weiteren Geräte am Switch, nur Uplink zum Router verbunden)
- FHEM nur mit minimaler FHEM.cfg laufen lassen
- Cubieboard und HMLANCFG an einem alten 10 MBit-Hub angeschlossen
- HMLANCFG direkt an einen Ethernetport am Router angeschlossen
- neuen Switch gekauft und Cubieboard und HMLANCFG angeschlossen
- HMLAN-Firmware auf 0.964 aktualisiert
- neuen HMLANCFG gekauft und getestet (!!) gleiches Verhalten
Alle diese Massnahmen haben keine Verbesserung gebracht. >:( Und nun gehen mir ehrlich gesagt die Ideen aus. Ich habe natürlich die Forenbeiträge zu dem Thema (scheint ja relativ viele Nutzer zu betreffen) gelesen. FHEM selbst und die Konfiguration würde ich mal ausschließen wollen, da es ja auch bei ausgeschaltetem Cubieboard zu den langen Pingzeiten bzw. Paketverlusten kommt. Meine restlichen in das Netzwerk eingebundenen Gerätschaften mache auch keine Probleme, die laufen stabil. Ach ja: FHEM natürlich per Update immer aktuell!
Hat jemand noch Ideen, was ich versuchen könnte? Mir fällt nix mehr ein. :'(
Danke
Trolli
Hmmm...
gelöscht wegen überflüssig...
Thomas
hast du schon "apptime" und "apptime maxDly" probiert?
Grüße
Chris
Also mit apptime habe ich noch nichts gemacht da die langen Antwortzeiten ja auch kommen wenn FHEM gar nicht läuft.
Trolli
hmm, in den FHEM-Forenuntiefen hab ich noch aufgeschnappt, dass ein zu kurzes LAN-Kabel ebenfalls Probleme machte. Evtl. mal ein längeres Kabel >10m probieren.
Ist alles ein bisschen Voodoo ;)
Grüße
Chris
30m langes Ethernetkabel verwendet:
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Antwort von 192.168.1.67: Bytes=32 Zeit=2320ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit=181ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.1.67: Bytes=32 Zeit<1ms TTL=128
Hilft auch nix! :( :(
ZitatFHEM abgeschaltet und nur HMLANCFG eingeschaltet gelassen
das sollte ja auch ein disconnect erzeugen. fhem muss den hmlan spätestens alle 30s ein keepalive senden.
schon mal nur am cubie angeschlossen, ohne weiteres netzwerk?
Das wär noch einen Versuch wert! Ist aber nicht so ganz ohne. Da brauche ich glaube ich ein Crossover-Kabel. Das müsste ich mir erst mal besorgen. Weiterhin muss der Cubie auch eine feste IP eingetragen bekommen, da er ja den DHCP-Server nicht mehr erreicht. Da der Cubie ja nur 1 Netzwerkinterface hat komme ich dann ja auch nicht mehr mit Putty drauf und muss also auch Tastatur und Monitor dranhängen. Oder ist es möglich zusätzlich das im Cubie integrierte WLAN zu aktivieren? Hat da jemand eine Anleitung?
Trolli
ich denke, das sollte im einplatinencomputerbereich beschrieben sein.
Was sagt denn "top" zu dem Zeitpunkt, wenn er zuckt?
Ähm sorry für meine Unwissenheit :o Aber was ist "top"??
Trolli
in einer linux shell das kommando "top" ausführen.
das könnte dir verraten ob ein prozess, ein i/o, o.ä. das system blockiert.
grüße
Ich werde nun vielleicht nochmal testen, an meinem Router ein separates VLAN für Cubietruck und HMLAN einzurichten. Vielleicht bringt das noch was.
Ansonsten werde ich dann frustriert aufgeben und die teilweise erheblichen Verzögerungen (z.B. bei den Bewegungsmeldern wenn gerade "disconnected")
hinnehmen. :'( :'( :'(
Trolli
deine vorgehensweise scheint mir insgesamt auch ein wenig überdenkenswert zu sein.
wie gesagt, benötigt der hmlan von fhem streicheleinheiten. mindestens alle 30 sec, sonst macht er automatisch einen disconnect. mit deiner ping-methode ermittelst du nun diese disconnects. die stehen aber bereits im log. in vielen fällen, in denen von disconnects berichtet wird, ist die ursache dieser disconnects aber ein freeze von fhem (oder module) selbst, da der keepalive nicht rechtzeitig zum hmlan gesendet werden kann. diese freezes lassen sich eventuell mit apptime oder dem performancemonitor lokalisieren und dann beseitigen.
eine vorläufige gegensteuerung wäre vielleicht die reduzierung des wertes wdTimer.
gruss frank
ZitatDSL-Router mit 2 daran angeschlossenen Switchen (100 Mbit und 1 GBit)
was hängt denn noch alles am Netz? irgendwelcher Windowsserver.... usw
du verschweigst doch etwas ;)
In meinem Hausnetz hängt natürlich so einiges an den genannten Switchen (TV, Satreceiver, NAS, PC usw.)
Aber auch wenn ich alle anderen Geräte vom Netzt trenne und nur HMLAN und Cubie dran habe gibt's Disconnects.
Trolli
@Frank:
FHEM würde ich mal ausschließen da ich ja auch schon mit einer Minmal Fhem.cfg getestet habe. Fhem also praktisch nix zu tun hatte. Trotzdem Disconnects. WdTimer habe ich auch erfolglos in allen Variationen getestet.
Trolli
ZitatFHEM würde ich mal ausschließen
na dann spekuliere mal weiter. 8)
schon mal einen netzwerk-log gemacht? Wenn tatsächlich wenig dran hängt einmal wireshark bemühen?
Hallo, ich habe neue Erkenntnisse:
Wenn ich meinen Router von meinem restlichen Hausnetz trenne gibt es keine Disconnects mehr! (Allerdings gibt's dann massiven
Ärger weil im ganzen Haus kein Internet mehr funktioniert ;D ;D)
@Martin: Das mit dem Wireshark ist nicht so ganz einfach weil ich nur Switches habe. Ich müßte dann erst einmal irgendwo
'nen alten Hub besorgen.
Trolli
So sieht das übrigens im Disconnect-Fall aus:
2014.12.20 16:25:52.402 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F547D60 IDcnt:0009
2014.12.20 16:26:07.403 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:26:07.408 5: HMLAN/RAW: /HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F54B800,0009,00
2014.12.20 16:26:07.409 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F54B800 IDcnt:0009
2014.12.20 16:26:22.409 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:26:22.413 5: HMLAN/RAW: /HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F54F29F,0009,00
2014.12.20 16:26:22.414 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F54F29F IDcnt:0009
2014.12.20 16:26:37.425 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:26:38.429 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:26:39.432 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:26:40.435 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:26:41.439 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.12.20 16:26:41.446 1: 192.168.1.67:1000 disconnected, waiting to reappear (HMLAN1)
2014.12.20 16:26:41.449 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.12.20 16:26:46.467 1: 192.168.1.67:1000 reappeared (HMLAN1)
2014.12.20 16:26:46.468 5: HMLAN_Send: HMLAN1 I:A123ABC
2014.12.20 16:26:46.468 5: HMLAN_Send: HMLAN1 I:C
2014.12.20 16:26:46.469 5: HMLAN_Send: HMLAN1 I:+254B18,00,01,00
2014.12.20 16:26:46.470 5: HMLAN_Send: HMLAN1 I:+2B668D,00,01,1E
2014.12.20 16:26:46.471 5: HMLAN_Send: HMLAN1 I:+1F1C68,00,01,1E
2014.12.20 16:26:46.472 5: HMLAN_Send: HMLAN1 I:+1DC4D6,00,01,00
2014.12.20 16:26:46.473 5: HMLAN_Send: HMLAN1 I:+1F083C,00,01,00
2014.12.20 16:26:46.474 5: HMLAN_Send: HMLAN1 I:+1EAC26,00,01,FE1F
2014.12.20 16:26:46.475 5: HMLAN_Send: HMLAN1 I:+1C9208,00,01,00
2014.12.20 16:26:46.476 5: HMLAN_Send: HMLAN1 I:+1F397B,00,01,1E
2014.12.20 16:26:46.476 5: HMLAN_Send: HMLAN1 I:+2D86BB,00,01,1E
2014.12.20 16:26:46.477 5: HMLAN_Send: HMLAN1 I:Y01,00,
2014.12.20 16:26:46.478 5: HMLAN_Send: HMLAN1 I:Y02,00,
2014.12.20 16:26:46.478 5: HMLAN_Send: HMLAN1 I:Y03,00,
2014.12.20 16:26:46.479 5: HMLAN_Send: HMLAN1 I:T1C2843A6,04,00,00000000
2014.12.20 16:26:46.480 1: HMLAN_Parse: HMLAN1 new condition init
2014.12.20 16:26:46.486 5: HMLAN_Send: HMLAN1 S:S684EDE1F stat: 00 t:00000000 d:01 r:684EDE1F m:99 8112 123ABC 000000
2014.12.20 16:26:46.491 5: HMLAN/RAW: /HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F55509B,0009,00
HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F553CFF,0009,00
HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F553D03,0009,00
HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F553D04,0009,00
HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F553D05,0009,00
I00,00,00,00
I00,00,00,00
I00,00,00,00
2014.12.20 16:26:46.492 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F55509B IDcnt:0009
2014.12.20 16:26:46.493 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F553CFF IDcnt:0009
2014.12.20 16:26:46.496 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F553D03 IDcnt:0009
2014.12.20 16:26:46.497 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F553D04 IDcnt:0009
2014.12.20 16:26:46.497 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:JEQ0707693 d:1E9C2D O:123ABC t:1F553D05 IDcnt:0009
2014.12.20 16:26:46.514 5: HMLAN/RAW: /R684EDE1F,0002,00000000,FF,7FFF,998112123ABC000000
2014.12.20 16:26:46.514 5: HMLAN_Parse: HMLAN1 R:R684EDE1F stat:0002 t:00000000 d:FF r:7FFF m:99 8112 123ABC 000000
2014.12.20 16:26:46.515 1: HMLAN_Parse: HMLAN1 new condition ok
2014.12.20 16:27:01.492 5: HMLAN_Send: HMLAN1 I:K
2014.12.20 16:27:01.496 5: HMLAN/RAW: /HHM-LAN-IF,03C4,JEQ0707693,1E9C2D,123ABC,1F558B4F,0009,01
Du kannst evtl einen managed switch oder einen router nutzen. Eine fb zb. Kann interfaces loggen.
In deinem fall sieht man delays. Die massages werden in einigen sec abstand gesendet. Die antworten kommen na h dem fhem reconnect. Was immer dein netzwerk da treibt - das ist aufwaendig.... dauert ewig
Ist schon komisch das nur das HMLAN betroffen ist! Alle anderen Geräte (TV, Tablets, Handys etc.) die sich im selben Netz befinden funktionieren einwandfrei. Spätestens beim STreaming von Filmen vom NAS o.ä. würde man doch merken das es zu Netzwerkunterbrechungen kommt, oder? Ich habe auch Sonos-Lautsprecher im Netz, auch da gibt es keinerlei Unterbrechungen während der Musikwiedergabe und das teilweise über den ganzen Tag. Ebenso Webradio, keinerlei Unterbrechungen. Ich bin jetzt ernsthaft am Überlegen auf eine CCU umzusteigen, da die Funktion der Bewegungsmelder bzw. der Aussenbeleuchtung eine Hauptnutzung von FHEM für mich ist. Und es nervt echt wenn das Licht draussen erst angeht wenn man schon die Haustür hinter sich geschlossen hat. >:(
Gruss
Trolli
ZitatSTreaming von Filmen vom NAS o.ä. würde man doch merken das es zu Netzwerkunterbrechungen kommt, oder?
nicht unbedingt. hängt vom puffer ab und der länge der verzögerung.
dennoch kenne ich keinen Grund für die Verzögerung.
ist das port des HMLAN am switch korrekt eingerichtet? autoConnect ist nicht immer problemlos - hatte schon einige Probleme. besser man stellt die datenrate fix ein.
kann aber auch etwas ganz anderes sein...
Hallo Martin,
ich habe keine Möglichkeit an den Switchports etwas einzustellen. Sind ungemanagte Ports. Du kannst aber definitiv sagen das die Verzögerung am Netzwerk liegt?
Gruss
Trolli
@Trolli
Das könnte ich dir auch bestätigen, hatte vor einem dreiviertel Jahr das Gleiche. Habe insgesamt 3 fhem Instanzen laufen (Cubietruck und 2 Raspi), diese sind in einem Gehäuse verbaut und im Gehäuse an einem 100er Switch zusammengefasst. Von diesem Switch geht ein Kabel direkt zum Router, dieser ist auf 100 Mbs eingestellt. Meine zwei IO Devices (HMLAN) hängen dann irgendwo mit im restlichen Netzwerk. Seitdem läuft alles absolut stabil und ohne Verzögerungen.
P.S. Oder hast du auf deinem System fowsr laufen (für USB Wetterstation)? fowsr erzeugt auf dem Host für ca. 1 min ein Freeze.
VG
Frank
Hallo zusammen, habe das gleiche Problem mit dem HMLAn. Habe nur 1GBit Switche. Der HMLAN liegt auf dem selben Switch wie mein FHEM. Dieser läuft auf einem Synology ds 110J mit SSD Speicher. Auch wenn ich jede Verbindung am Switch bis auf FHEM und HMLAN trenne tritt das Problem auf. Habe allerdings die Softwareversion 0.961 noch auf dem HMLAN. Ich kann mir nicht vorstellen, dass das an einem Switch oder Kabel liegen kann, dafür ist das Datenaufkommen viel zu klein. An Prozessen selbst habe ich nur ein Syslog und FHEM laufen mit dem HMLAN und CUL für FS20, ansonsten habe alles gestoppt und auch dann tritt züglich ein "disconnect" auf. Am HMLAN läuft bis dato nur ein HM-CC-TC. Habe aber auch noch seit dem Update gestern von fhem.pl noch weitere Probleme bekommen. Hier ist wohl das Problem, dass mit dem Update Befehl nicht die neue Version von fhem.pl geladen wurde -siehe hierzu anderen Thread-. Habe hier das Gefühl, dass mit der aktuellen fhem.pl was nicht stimmt. Bin hier aber viel zu neu, um dazu eine fundierte Aussage treffen zu können, nur soviel, dass der fhem.cfg File an vielen stellen verändert wurde und mein Dashboard nicht mehr angezeigt wird. Evtl. hängt das alles irgendwie zusammen. Ansonsten Frohe Weihnachten an alle FHEM Users.
Wenn du einen test machen kannst mit switch und nur hmlan und fhem (wusste nicht, dass fhem ein device ist ) kannst du auch den pc und hmlan direkt verbinden. Dann ist klar, ob der switch ein problem macht.
Ansonsten gibt es pingtools, die latenzen des netzes pruefen - oder einfach einen dauerping und selbst pruefen. Das gibt schon einen startpunkt, auch wenn es nicht alles aussagt