HMLANCFG ständige Disconnects

[Trolli]

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:

Code Auswählen Erweitern

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

[Rohan]

Hmmm...

gelöscht wegen überflüssig...

Thomas

[chriz]

hast du schon "apptime" und "apptime maxDly" probiert?

Grüße
Chris

[Trolli]

Also mit apptime habe ich noch nichts gemacht da die langen Antwortzeiten ja auch kommen wenn FHEM gar nicht läuft.

Trolli

[chriz]

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

[Trolli]

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! 

[frank]

FHEM 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?

[Trolli]

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

[frank]

ich denke, das sollte im einplatinencomputerbereich beschrieben sein.

[juppzupp]

Was sagt denn "top" zu dem Zeitpunkt, wenn er zuckt?

[Trolli]

Ähm sorry für meine Unwissenheit  Aber was ist "top"??

Trolli

[juppzupp]

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

[Trolli]

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

[frank]

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

[LuckyDay]

DSL-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