HMLAN Timeout

[dancatt]

ich habe auch festgestellt, dass andfhem, über handy (gprs) auf fritzbox mit fhem, oft disconnects auslöst

Muss ich mir mal anschauen. Hab das Teil auch drauf.
Wenn dem so ist sollte man Matthias Klaas bescheid geben.

[Gunther]

Ich hatte das Problem ja auch, leider auch mit langen disconnects.
Hatte testweise einen neuen HMLAN gekauft, exakt gleich eingebunden (getauscht) und siehe da: seit einem 3/4 Jahr keine Disconnects.

[Joker]

Das klingt ja nicht gut 

Ich habe jetzt die letzten Tage immer mal wieder was geändert und weiter geforscht.
- Langläufer habe ich laut apptime keine:
apptime max (Auszug vom Anfang)

Code Auswählen Erweitern

  name             function    max  count    total  average maxDly
                              HMLAN1          HMLAN_Ready   3008    101    15991   158.33      0 HASH(HMLAN1)
                              HMLAN1           HMLAN_Read   1244  17113   420645    24.58      0 HASH(HMLAN1)
                 onTerraceDoorStatus          notify_Exec   1180      2     2122  1061.00      0 HASH(onTerraceDoorStatus); HASH(Wohnzimmer.Terrassentuer)
                             myDbLog            DbLog_Log    700   6225    77744    12.49      0 HASH(myDbLog); HASH(Wohnzimmer.Heizkoerperthermostat.Clima)
            tmr-HMLAN_KeepAliveCheck   keepAliveCk:HMLAN1    520   7462     2466     0.33    582 keepAliveCk:HMLAN1
                                  lp         logProxy_Get    222     19     3528   185.68      0 HASH(lp); lp; HISTORY; INT;

apptime maxDly:

Code Auswählen Erweitern

tmr-HMLAN_KeepAliveCheck   keepAliveCk:HMLAN1    520   7466     2466     0.33    582 keepAliveCk:HMLAN1
                 tmr-HMLAN_KeepAlive     keepAlive:HMLAN1    109   7326    15530     2.12    270 keepAlive:HMLAN1
              tmr-FW_closeOldClients                          10   3063     3104     1.01    159
                 tmr-CUL_HM_ActCheck       ActionDetector     14    306     3377    11.04     32 ActionDetector
                tmr-HMLAN_UpdtMsgCnt       UpdtMsg:HMLAN1      1   1838       74     0.04     25 UpdtMsg:HMLAN1
            tmr-CUL_HM_statCntRfresh        StatCntRfresh      0      2        0     0.00      3
                      ActionDetector           CUL_HM_Set      3      6       14     2.33      0 HASH(ActionDetector); ActionDetector; ?

Trotzdem mehrere Disconnects am Tag.
Ich habe das Filesystem des Raspberry mal gecheckt, weiterhin als erstens den Switchport von HMLAN und Pi fix auf 100Mbit eingestellt, dann als zweiten Schritt einen zweiten Switch nur für HMLAN und Pi dazugestellt: Bringt alles genau gar nix.

Hat wer eine Strategie wie ich vorgehen kann, um rauszufinden was hier schiefgehen könnte? Es scheint ja irgendwie außerhalb von FHEM zu liegen. Ich habe mir mal die Prozesse etc angeschaut aber finde da auch nix besonderes.

[martinp876]

hast du einmal apptime maxDly gemacht? das zeigt dir, wie lange ein timer ausserordentlich verzögert worden ist.
apptime registriert nur die Laufzeiten von FHEM jobs. der delay kann auch von "extern" kommen.

[nebukadnezza]

Ich hatte das exakt gleiche Problem wie Joker.

Ein ping auf den HMLAN brachte exakt alle 15 Minuten ein paar Pings (4-5) mit Antwortzeiten um die 3-4 Sekunden. Im Betrieb führte dies sehr oft zu einem timeout am HMLAN.
Diese Ping-Langläufer bekam ich auch, wenn fhem gar nicht gestartet war. Kein anderes Netzwerkdevice, welches ich gleichzeitig anpinge, hat diese Langläufer. Sieht also so aus als käme HMLAN mit irgendeiner Art Netzwerktraffic nicht klar, was für andere Devices kein Problem darstellt.

Ich habe nun HMLAN ein eigenes Netzwerkinterface am Server spendiert, auf dem fhem läuft. Interface kommt bei autoneg up mit 10 MBit und Half(!!!) Duplex. Seither kein einziges timeout mehr und alles funktioniert wunderbar

Matthias

[Hollo]

...Ich habe nun HMLAN ein eigenes Netzwerkinterface am Server spendiert, auf dem fhem läuft. Interface kommt bei autoneg up mit 10 MBit und Half(!!!) Duplex. Seither kein einziges timeout mehr und alles funktioniert wunderbar

Habe den Switch-Port, an dem mein HMLAN hängt, jetzt auch mal fest auf 10MBit Halbduplex eingestellt. Das hat die Abbrüche nochmals vermindert.

[Nobby1805]

Ich habe diese Abbrüche auch seitdem ich Ende Januar irgendetwas neu konfiguriert habe ... nur was 

Jetzt habe ich heute mal einen Netzwerksniffer angeschlossen ... alle 25 Sekunden schickt FHEM ein Paket an den HMLAN, normalerweise kommt der Acknowledgement sofort (unterhalb der Zeitauflösung des Sniffers  )  ...
aber nicht wenn es danach zum Disconnect kommt ... dann kommt gar kein Ack
nach 0,25, 0,8, 2 und 4,4 Sekunden macht FHEM ein Retransmit des Pakete (aber auch ohne Antwort) und dann wird die Verbindung abgebrochen und neu aufgebaut.

Aus meiner Sicht zeigt das, dass es nichts mit FHEM zu tun hat sondern ein HMLAN-Problem ist ... ich schaue mal, ob ich noch mehr heraus bekomme

[martinp876]

Aus meiner Sicht zeigt das, dass es nichts mit FHEM zu tun hat

kann sein

sondern ein HMLAN-Problem ist

oder den netzwerk. wo hast du gemessen? Kann es sein, dass du die message nicht gesehen hast?
Möglich ist eben auch, dass der HMLAN aus anderem Grund rebootet.

[Nobby1805]

kann seinoder den netzwerk. wo hast du gemessen? Kann es sein, dass du die message nicht gesehen hast?
Möglich ist eben auch, dass der HMLAN aus anderem Grund rebootet.

da ich direkt im TCP-Stack des Servers den Capture-Filter eingeklinkt habe ist es recht unwahrscheinlich  das FHEM den ACK vorher noch abfängt ... den ACK zu übersehen ist unmöglich, weil das Originalpaket und der 1. Retry unmittelbar nacheinander im Log liegen

Der HMLAN und der Server hängen am selben Switch ... ich schau mal ob ich mir einen Hardware-Sniffer ausleihen kann um die Daten direkt am HMLAN zu loggen

[martinp876]

wenn es nur ein disconnect ist rebootet der HMLAN nicht. Wenn es ein reboot ist kannst du das an der Dauer erkennen. Auch meldet das Device die angemeldeten HMIds (die Anzahl). Nach einem Reboot wären die 0.
damit kannst du die Unterschiede erkennen. Leider weiss ich nicht, wann und warum ein HMLAN rebooten darf. Das müsste man ggf aus der Vorgeschichte erkennen.... können wir versuchen.
könnt aber auch schlicht an irgend einem Zähler schlecht empfangener messages liegen.... das wird schwer.

[topfi]

Ich habe jetzt einen zweiten HMLAN gekauft. Mit diesem gibt es nullkommanull disconnects, am gleichen Ort, Kabel und Netzteil. Dann habe ich den (ca. 1 Jahr) alten wieder angeschlossen, die neueste Firmware aufgespielt und siehe da: Ab und zu ein disconnect, vorrangig nachts, wenn überhaupt nichts anliegt.

Das ist also ein Hardwareproblem.

[Nobby1805]

Ich hatte gestern 2 disconnects kurz hintereinander ... und vermute, dass das Reboots des HMLAN waren weil der 2. Reconnect zu der uptime des HMLAN passt.
Interessanterweise findet man im Sniffer jeweils 2 IGMPv1 membership reports mit der Multicastadresse 255.255.255.255 ... was mich doch ehrlich gesagt etwas wundert weil IGMP doch eigentlich den Routern im Netz eine Gruppenadresse/Multicast mitteilen soll und 255.255.255.255 ist hier m.E. nicht zulässig.

Ich werde mich jetzt mal an den eQ3-Support wenden

[Nobby1805]

Da eQ-3 den direkten Support für Endkunden ablehnt  habe ich mich jetzt an den Lieferanten gewendet, schau'n wir mal  ich habe keine Lust einen Zweiten zu kaufen und dann zwei mit dem selben Verhalten rumliegen zu haben

[baeri3]

He Nobby1805,
hast du noch was erreichen können?
Grüße,
baeri3

[Nobby1805]

Schau mal hier ... http://forum.fhem.de/index.php/topic,40391.msg327053.html#msg327053
aber ich muss da jetzt noch einmal nachhaken, mein HMLAN hat gerade wieder ausgesetzt sprich. etliche Reboots durchgeführt