HMLAN Adapter wechselt permanent zwischen disconnected / connected

[Nobby1805]

Bei mir hat 0.965 die sporadischen Reboots des HMLAN NICHT behoben  würde mich mal sehr interessieren welchen Fehler eQ3 dort angeblich gefunden hat 

[Newbie]

Hallo,

also bei mir hat das Update des Lan-Adapters auch nichts gebracht. Hatte zwischenzeitlich FHEM-Module im verdacht, hat sich aber nicht bestätigt.
Kurios ist nur, das bei mir die Disconnect´s immer dann auftretten, wenn im Netzwerk sonst nichts los ist (also nur FHEM läuft).

vg jens

[bart0190]

Hi,
Hab nun das logging aufgedreht, wie von Nobby1805 vorgeschlagen, danke nochmal.
Davor hab ich wieder den wdtimer auf 25 gesetzt (womit ich wieder alle 29s ein disconnect bekomme). Das passiert mit oder ohne zusätzliche HM-Module.
Logging im Anhang. Leider sagt mir das Logging nicht viel.

Zusätzlich muss ich sagen, dass wenn ich den wdtimer auf 5 setze, sind die disconnects nicht vollkommen weg und kommen unregelmäßig (min bis einige Stunden) wieder.

Versteht jemand die Loggings?

lg
bart

[martinp876]

Da schaue ich einmal nicht ins Log sondern sage dir, dass du einen Timeout hast. Der hmlan wird nicht alle 30sgetriggert. Wenn du ihm auf 5 setzt und immer noch Disconnects hast ist es ein Task ausserhalb von culhm, evtl ausserhalb von fhem.
Ich würde mit apptime suchen.
Dass es Probleme gibt, wenn du alle Logs einschaltest ist bekannt, muss ich nicht ansehen. Die konsumieren erhabli h Zeit.

[bart0190]

Hallo,
danke für den Hinweis. Anbei der Output vom apptime.
Heißt das, dass alle keepAlives ankommen? Oder wie kann man das interpretieren?

lg
bart

[martinp876]

apptime hat ein paar optionen. in dem aufgenommenen Zeitraum hat HMLAN einmal 3sec am Stück gebraucht. Das war sicher ein Disconnect - FHEM wartet dann 3 sec ob er nicht doch noch kommt. Nachdem es 500 mal aufgerufen wurde hast du wohl so 200min geloggt...

Du siehst nur die top-verbraucher sortiert nach laufzeit. Das ist eine gute Aussage über FHEM intern.

interessant ist jetzt

Code Auswählen Erweitern


apptime maxDly all
zeigt die Verzögerung - die auch von extern hervorgerufen werden kann.
die Parameter maxDly,... steuern nur die Anzeigesortierung. Aufgezeihnete Werte bleiben erhalten bis "clear" gesendet wird.

[bart0190]

Hi,
Danke für die Info.
Ich hab nun versucht meinen Raspberry Pi mit Rasbian - Wheezy (vorher hatte ich Jessie) aufzusetzen, FHEM drauf und FHEM update gemacht. Gleiche Fehler. 

Hab nun
apptime maxDly all
ausgeführt und das erhalten:

Code Auswählen Erweitern


                                name             function    max  count    total  average maxDly
                 tmr-HMLAN_KeepAlive     keepAlive:HM_LAN      0     10        0     0.00     25
         tmr-FW_closeInactiveClients                           0      9        0     0.00     14
            tmr-HMLAN_KeepAliveCheck   keepAliveCk:HM_LAN     17     22       53     2.41      1 keepAliveCk:HM_LAN
                              HM_LAN         HMLAN_Notify      1     39        5     0.13      0 HASH(HM_LAN); HASH(HM_LAN)
                              HM_LAN           HMLAN_Read     11     21       68     3.24      0 HASH(HM_LAN)
                              HM_LAN          HMLAN_Ready   3005    107    13087   122.31      0 HASH(HM_LAN)
                             Logfile          FileLog_Log      0     39        0     0.00      0
                                 WEB            FW_Notify      0     39        0     0.00      0
                                 WEB              FW_Read      1      6        5     0.83      0 HASH(WEB)
                  WEB_10.0.0.5_52069              FW_Read      0      1        0     0.00      0
                            WEBphone            FW_Notify      0     39        0     0.00      0
                           WEBtablet            FW_Notify      0     39        0     0.00      0
                          eventTypes    eventTypes_Notify      1     39        2     0.05      0 HASH(eventTypes); HASH(HM_LAN)


Sagt mir das etwas Genaueres über mein Problem, oder die Bestätigung, dass das keepAlive Signal nicht immer (oder nie) angkommt?
Was kann ich noch probieren, um das Problem zu lösen?

Mittlerweile kann ich ausschließen, dass die HMLAN HW was hat, da sie bei einem Freund richtig funktioniert (ohne disconnects).

lg
bart

[martinp876]

Sieht gut aus. Das waren 10 keepalive, also 5 Minuten. Wieviele Disconnects waren in diesem Zeitraum?
Was sagen eigentlich die internals des hmlan? Da stehen performance Daten bereit.

[uwemicro]

Hallo,
ich beschäftige mich seit kurzem mit FHEM und wollte mal über meine Erfahrungen berichten. Bei mir läuft FHEM auf einem Raspberry Pi 2. Ich habe auch ständig Disconnects mit dem HM-CFG-LAN Adapter. Nach Einspielen der neuen Softwareversion 0.965 hat sich bei mir leider nichts geändert. Ich habe dann verschiedenes ausprobiert (was hier auch stellenweise beschrieben wurde), zwei verschiedene 10/100 Mbps Switchs oder auch direkt an der FritzBox (Port auf 100Mbps gestellt), nichts hat geholfen. Auch wenn nur ein PC, der Raspberry und der HM-CFG-LAN über einen Switch verbunden waren (Switch isoliert, keine Verbindung zum restlichen Netzwerk) gab es Disconnects. Dann habe mir von der Firma wo ich arbeite einen alten 10Mbps Hub mitgebracht, um mal mt Wireshark die Telegramme mitzuschneiden - seit der HM-CFG-LAN am Hub hing gab es keine Disconnects mehr. Also habe ich mir zwei Hubs bei EBAY besorgt. Ich habe zum Test jetzt nochmal einen Switch hinter den Hub geschaltet und den HM-CFG-LAN an den Switch gehängt - keine Disconnects. Das ist mir jetzt etwas unklar, der Hub lässt ja alles durch, der einzige Unterschied zwischen Hub dann Switch und nur Switch ist ja die geringere Geschwindigkeit von 10Mbps durch den zwischengeschalteten Hub.
Jedenfalls bin ich froh, des es mit Hub keine Disconnects mehr gibt.

Viele Grüße
Uwe

[martinp876]

Das Netzwerk kann immer ein Problem sein. Wireshark sollte auch auf Pi laufen. Fhem kümmert sich nicht um dein LAN.
Wenn dein Netzwerk Probleme mit 100 mbit hat kann es Probleme bereiten. Du kannst natürlich auch dein LAN interface auf 10 drosseln. Sollte den Treiber ersetzen.
Bei mir läuft es an der FB ohne Probleme. Auch mit pi2 als Server. Direkt verbinden mache ich nicht, ist ja im netzwerk

[bart0190]

Disconnects gibt es bei mir immer gleich viele wie keepAlives, also damals 10 disconnects.
Ich hab jetzt ein wenig länger laufen gehabt, hier dazu die internals

Code Auswählen Erweitern


DEF 10.0.0.98:1000
DeviceName 10.0.0.98:1000
FD 5
HM_LAN_MSGCNT 124
HM_LAN_TIME 2016-03-20 12:49:50
IFmodel LAN
NAME HM_LAN
NR 20
NTFY_ORDER 50-HM_LAN
PARTIAL
RAWMSG E4589F3,0000,008FBDBB,FF,FFC0,E484704589F300000000FE27
RSSI -64
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 0
msgKeepAlive dlyMax:0.816 bufferMin:4
msgLoadCurrent 3
msgLoadHistory 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
owner xxxxxx
uptime 000 02:38:03.620


und weiter die disconnects im log file:

Code Auswählen Erweitern



2016.03.20 12:55:23 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:55:23 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:55:23 1: HMLAN_Parse: HM_LAN new condition ok
2016.03.20 12:55:52 1: HMLAN_Parse: HM_LAN new condition timeout
2016.03.20 12:55:52 1: 10.0.0.98:1000 disconnected, waiting to reappear (HM_LAN)
2016.03.20 12:55:52 1: HMLAN_Parse: HM_LAN new condition disconnected
2016.03.20 12:55:57 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:55:57 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:55:57 1: HMLAN_Parse: HM_LAN new condition ok
2016.03.20 12:56:26 1: HMLAN_Parse: HM_LAN new condition timeout
2016.03.20 12:56:26 1: 10.0.0.98:1000 disconnected, waiting to reappear (HM_LAN)
2016.03.20 12:56:26 1: HMLAN_Parse: HM_LAN new condition disconnected
2016.03.20 12:56:31 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:56:31 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:56:31 1: HMLAN_Parse: HM_LAN new condition ok
2016.03.20 12:56:41 3: HM_LAN: Unknown code A0CE7865A4589F3000000A8F622::-71:HM_LAN, help me!
2016.03.20 12:57:00 1: HMLAN_Parse: HM_LAN new condition timeout
2016.03.20 12:57:00 1: 10.0.0.98:1000 disconnected, waiting to reappear (HM_LAN)
2016.03.20 12:57:00 1: HMLAN_Parse: HM_LAN new condition disconnected
2016.03.20 12:57:03 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:57:03 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:57:03 3: HM_LAN: Unknown code A0CE784704589F300000000F622::-69:HM_LAN, help me!


Die "help me!" bzw. Unkown code Meldungen gab es früher nicht, wobei ich dort auch noch nicht auf das neue FHEM aktualisiert hatte.

Weitere Ideen?

danke
bart

[martinp876]

msgKeepAlive      dlyMax:0.816 bufferMin:4

kenne ich so nicht. da ist noch ein Puffer von 4 sec. FHEM sendet nicht verzögert. offensichtlich kommt die msg nicht am Device an. Möglich auch, es komm an, aber die Antwort kommt nicht zurück.
Ich tippe auf dein Netzwerk, was du schon so gu wie bestätigt hast. Wie hier eine solche Verzögerung kommen kann ist mir nicht transparent. Jedenfalls ist es dein Netzwerk.

[uwemicro]

Hallo,
also mein Netzwerk besteht aus der Fritzbox und 3 Gigabit Switches. Was ich halt merkwürdig finde ist, wenn der HM-CFG-LAN an einem Switch hängt (auch testweise an einem 10/100Mbs) gibt es Disconnects, wenn ich vor den HM-CFG-LAN einen Hub schalte, nicht. Der Hub läßt ja alles durch, der einzige Unterschied ist das der Hub nur 10Mbs kann. Anscheinend scheint der HM-CFG-LAN mit der schnelleren Geschwindigkeit ein Problem zu haben

[martinp876]

Autonego ist nicht so unproblematisch wie allgemein angenommen. Setze deinen Gigabit auf 10tel Ration. Besser gleich 10MBit einstellen am hmlan Port. Auch die beste macht kein Gigabit.
Möglich sollte sein, den hmlan an der FB zu betreiben und gleich die Leistung hzu drosseln.

[Rampler]

Habe leider auch das Problem der HMLAN disconnects am LAN Port der Fritzbox (7490). Der HMLAN bootet immer wieder mal neu. Leider kann die FB nur auf 100 mbit, nicht aber auf 10mbit beschränken..
Bin am überlegen mal ein ganz altes CAT3 Kabel zu testen, dass kann nur 10 MBit