HMLAN Adapter wechselt permanent zwischen disconnected / connected

[martinp876]

Hallo Billy,

das ist interessant, aber nicht wirklich hilfreich.
Da ich nicht weiss was bei dir schief geht kann ich diesen Beitrag nur ignorieren.

Falls du zur Problemlösung beitragen willst könntest du testen
1) HMConfig und HMInfo könntest du hochdrehen. die haben höchst wahrscheinlic nichts damit zu tun
2) wenn du auf die neuste Version updatest könntest du
  - apptime laufen lassen
  - die internals des HMLAN schicken - insbesondere die MSG informationen zu delays.

Alternativ kannst du dich bei Updates auch selbständig machen. Ab 2016 wird FHEM strikte Regeln zu reading namen realisieren - viel Glück.

[Billy]

Hallo Billy,
das ist interessant, aber nicht wirklich hilfreich.
Da ich nicht weiss was bei dir schief geht kann ich diesen Beitrag nur ignorieren.

Hallo Martin erstmal vielen Dank für deine auch in 2015 geleistete Arbeit und für heute einen guten Rutsch.

Das ist wirklich interessant, ich hatte auch auf Bestätigung von anderen Usern gehofft bevor es für dich lohnt tiefer einzusteigen.

Alternativ kannst du dich bei Updates auch selbständig machen. Ab 2016 wird FHEM strikte Regeln zu reading namen realisieren - viel Glück.

Ich habe nicht die Absicht mich selbständig zu machen.

Ich musste nur kurzfristig eine Lösung über die Feiertage finden um meine TC's den Feiertagsbedingungen anzupassen. Ausfälle der HCS Steuerung nicht akzeptabel.
Außerdem gibt es in dieser Zeit auch keinen Slot für mich um groß zu testen.

Die Erkenntnis, dass das Zurückdrehen auf eine alte Konfiguration auch das Thema disconnects positiv beeinflusst war eher Zufall.

Ich hoffe dass diese Erkenntnis auch von weiteren Usern bestätigt werden kann.

Ich melde mich sobald ich Zeit für detaillierte Tests habe.

Gruß Billy

[Torben]

Hallo zusammen,

ich habe gerade erst mit einem HMLAN gestartet und hatte beim alten RPI auch ständig Abbrüche (mit den neuen und den alten *.pm-Dateien von Dir). Gerade habe ich einen RPI 2 bekommen und damit läuft es tadellos (identische Installation, einfach SD-Karte im neuen RPI 2). Der alte war häufig bei 100% Systemlast, der neue ist da doch deutlich kräftiger. Daher denke ich, dass es eventuell einfach an einem zu schwachen/überlasteten Server liegen könnte, wenn die Abbrüche kommen. Was denkt ihr?

Gruß
Torben

[martinp876]

absolut!

[Torben]

Hmm, jetzt habe ich auch immer wieder Abbrüche mit dem RPI 2 

[martinp876]

die logs? apptime, msg infos in HMLAN internal?

[Ma_Bo]

So, habe jetzt mal die Dateien von Billy eingespielt, mal schauen was passiert.
Bisher hatte ich mindestens 1 Timeout bei jedem HMLan innerhalb von 24 Stunden, das extremste waren 6.

Ich werde berichten.

[cornhoulio]

@Martin

Mein HMLAN bootet alle ca. 15min.
Vielleicht kannst Du in meinen Files was sehen.
FHEM ist aktuell.

Gruß cornhoulio.

[Nobby1805]

@cornhoulio

hast du Telekom Entertain in Betrieb ? Dann solltest du einen Switch einsetzen der Multicast-Traffic besser trennt oder auf die neue Firmware 0.965 für den HMLAN warten

[Wuppi68]

@cornhoulio

hast du Telekom Entertain in Betrieb ? Dann solltest du einen Switch einsetzen der Multicast-Traffic besser trennt oder auf die neue Firmware 0.965 für den HMLAN warten

bei Entertain muss der Switch IGMP V3 können

[martinp876]

folgende Dinge kannst du raus lesen:
    msgKeepAlive dlyMax:12.77 bufferMin:-2
das keepalive ist 12sec später als geplant gekommen. Du hast wohl eingestellt, dass es alle 20sec kommen soll, somit war es 2 sec zu spät, also 32 sec anstatt die notwendigen 30sec. Das wird ein disconnect.

   HMLAN1          HMLAN_Ready   3117   3277   151882    46.35      0 HASH(HMLAN1)
   tmr-Calendar_Wakeup      HASH(0x293b108)   1045      3     2938   979.33     84 HASH(Kalender)
diese beiden dauern etwas lang. Das kannzu problemen bei der Kommunikation führen.
HMLAN hat wohl 3 sec da es disconnected ist. Das ist eine standardZeit des warten auf den Socket.
Zum disconnect wird dies nicht führen.
Auffällig sind die vielen maxDly in der Grösenordnung 3sec. Timer sind also 3sec später gekommen als geplant. Das kann nicht alles vom HMLAN Disconnect kommen.
=> Die Verzögerung ist demnach ausserhalb von FHEM

Uncool ist auch noch
tmr-Calendar_Wakeup      HASH(0x293b108)   1045      3     2938   979.33     84 HASH(Kalender)
Im Schnitt 1 sec dauer. Das ist zu lang - hier kann es zu Problemen in der kommunikation kommen

da du keine rohmessages geschickt hast kann ich  nicht sehen, wie langsam die keepalives sind. Aber dein Problem liegt wohl ausserhalb von FHEM.

[Ma_Bo]

Zwischenstatus : seit 24 Stunden keinen Disconnect, beide HMLan´s laufen stabil.
Keine Änderung am Netzwerk oder sonstigem, nur die Dateien von Billy eingespielt und neugestartet.

Getauscht habe ich folgende Dateien :

00_HMLAN.pm 7822 2015-02-01 16:28:10Z martinp876 $
10_CUL_HM.pm 8070 2015-02-22 16:10:26Z martinp876 $
HMConfig.pm 8070 2015-02-22 16:10:26Z martinp876 $

[cornhoulio]

Danke für Euere Einschätzungen.

Entertain habe ich nicht, aber Amazon TV. IGMP kann mein Switch leider nicht obwohl es ein Managed Switch von HP ist.

Dan werde ich wohl weiter suchen. FHEM läuft auf einem RPI vielleicht hat der ja ein Problem.

Gruß cornhoulio.

[rx]

Zum Verständnis: Wirkt sich denn ein Disconnect, der durch ein Timeout ausgelöst wird auf die Uptime des HMLAN aus? D.h. wird der Uptime-Zähler daraufhin auf 0 gesetzt oder passiert das nur wenn es zu einem Neustart/Reboot des HMLAN kommt?

Grüße

[Nobby1805]

Zum Verständnis: Wirkt sich denn ein Disconnect, der durch ein Timeout ausgelöst wird auf die Uptime des HMLAN aus? D.h. wird der Uptime-Zähler daraufhin auf 0 gesetzt oder passiert das nur wenn es zu einem Neustart/Reboot des HMLAN kommt?

umgekehrt ... ein Reboot hat auch ein Disconnect zur Folge, ein Disconnect weil ein Timeout zwischen dem HMLAN und Fhem stattgefunden hat bedingt keinen Reboot des HMLAN

PS die Gründe für einen Reboot des HMLAN scheinen vielfältig zu sein, u.a. scheint es auch Situationen zu geben wo durch die Kommunikation zwischen Fhem und HMALN ein Reboot ausgelöst wird