00_HMLAN.pm und disconnects

[bugster_de]

Hallo Leute und vorallem Hallo an den Maintainer des 00_HMLAN.pm Moduls,

das Thema disconnects taucht ja am heutigen Tage mehrfach hier im Forum auf. Auch bei mir spackt die Installation rum. Ich habe mir deshalb mal den code der 00_HMLAN.pm angesehen, und stelle mir eine einfache Frage:
warum wird die Antwort des HM-LAN auf die Message K eigentlich jedesmal geprüft?

Zur Lebenserhaltung des HM-LAN wird ja alle 25 Sekunden (so ungefähr) der Buchstabe K gesendet. Dies passiert in der Routine HMLAN_KeepAlive, welche am Ende dann zwei InternalTimer startet. Einen um sich selbst wieder aufzurufen (in 25 Sek.) und einen um die Antwort des HM-LAN zu checken (die Routine HMLAN_KeepAlive). Hier wird dann geprüft, ob die Antwort des HM-LAN kam.
Aber warum eigentlich? Sprich warum prüft man jedesmal ob die Antwort kam?

Hintergrund: der einzig negative Effekt des disconnect bei mir ist ein voll gemülltes Logfile. Sonst geht ja alles so wie es soll. Sogar die MISSING ACK einzelner Empfänger sind zu großen Teilen verschwunden.

Sprich aus meiner Sicht müsste man nicht jedesmal die Antwort so detailliert checken, wie das Modul das macht. Alle 15 Minuten oder so würde eigentlich auch reichen. Zumal in der Antwort Überprüfung ein paar if-the-else drin sind.

Desweiteren eine Nebenbemerkung:
in der Routine HMLAN_SimpleWrite wird auf etwaige Antworten des HM-LAN gewartet aber dann doch irgendwann gesendet. Kann es sein, dass dies manchmal schief geht? Um ehrlich zu sein, habe ich den Sinn des Codes ab Zeile 631 nicht verstanden, da ja unabhängig was im if oder else Zweig passiert, am Ende dann doch sysWrite ausgeführt wird.

Wäre klasse, wenn sich das hier mal jemand ansieht.

[martinp876]

Hallo Bugster,

das prüfender Antwort auf ein keep-alive sorgt in einigen Fällen für eine schnellere recovery des HMLAN. Ein Aufhängen des HMLAN wird nicht immer erkannt.
Im Übrigen ist es in einem ordentlichen System das handshake-getrieben ist quasi Pflicht, die Antwort zu prüfen - das ist ja eben der Sinn eines solchen.
Der Zustang des HMLAN wird entsprechend geändert und CUL_HM kann entsprechende Aktionen ergreifen (timeouts verlängern)

Nach deinen Logs ist dies aber nicht der Grund der disconnects - es müssten sonst "timeout" events gepostet werden.

Was willst du alle 15min prüfen? Den Sinn verstehen ich nicht - das ist viel zu lange für ein System
Was für ein Problem hast du mit condition-abfragen? hast du angst vor der Performance deines systems und denkst, das es hier zu Problemen kommt? Es wird im gut-Fall genau ein if hier abgefragt. Timing-probleme habe wir an anderen Stellen.

Im Übrigen hast du geschrieben,dass das Problem weg ist, wenn du verbose auf 5 setzt - das ist genau das gegenteil - wenn dein System langsamer ist scheint es zu funktionieren.

Um ehrlich zu sein, habe ich den Sinn des Codes ab Zeile 631 nicht verstanden

ok - den Rest vom Code hast du aber verstanden?
ja, ich habe es mir angesehen - ist korrekt so.

da ja unabhängig was im if oder else Zweig passiert, am Ende dann doch sysWrite ausgeführt wird.

richtig - und da sind viele If-Then-Else bevor es zum syswrite kommt.

Wirklich klar ist mir nicht, worauf du hinaus willst.
Gruss Martin

[bugster_de]

Wirklich klar ist mir nicht, worauf du hinaus willst.

Auf ein funktionierendes HM-LAN Device

Offensichtlich geht das HM-LAN Modul ja so nicht, da es bei jedem Update andere Probleme gibt. Ich verstehe durchaus, dass in der Basis, vorallem bei einem Hand-Shake Protokoll, Echtzeit Charakteristica der Software gefragt sind. Und genau deshalb habe ich mir den Code mal angesehen ...

hast du angst vor der Performance deines systems und denkst, das es hier zu Problemen kommt?

nein. Aber die Abfrage alle 30 Sekunden geht ja nachweislich schief. Aber ausser einem lästigen Eintrag im Logfile passiert ja nichts.
Somit also die Frage nach einer pragmatischen Lösung: warum die Antwort JEDESMAL so GENAU zu prüfen? Wie gesagt, Effekte hat es ja erstmal nicht. Alle Rolläden fahren, alle Sensorwerte kommen an.
Und wenn der HM-LAN wirklich tot ist, dann reicht auch ein deutlich längeres Abfrage Intervall um Massnahmen zu ergreifen.

[martinp876]

Hallo Bugster_de

ich kann nicht wirklich sehen, dass das HMLAN nach jeden update andere Probleme hat. Es gab und wird immer wieder Probleme geben, wenn FHEM durch andere ausgebremst wird. Das kann jeder User einfach fabrizieren - und dass machen gelegentlich auch andere Module/Entwickler aus FHEM.

der HMLAN ist nicht immer tot. Es gibt die verschiedensten Fälle. Die Abfrage erhöht bisher NICHT die Anzahl der disconnects. Das könnte man einfach an den Parametern sehen, wird ja mitgeschrieben. Das interval von 30sec steht sowieso. Die anderen Zeiten kann sich der User einstellen, wenn er es anpassen will.

Gruss Martin