HM-LAN Disconnect

[bugster_de]

Hi Leute,

ich weiß, das Thema hatten wir schon ein paar mal hier, jetzt will ich auch mal

Seit ca. 2 Wochen macht der HM-LAN mucken. Er disconnected sich dauernd und nach ca. 1 Minute ist er wieder da. Siehe Logfile

Code Auswählen Erweitern


2013.11.12 14:42:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 14:43:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 14:44:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 14:45:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 14:46:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 14:47:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 14:54:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 14:55:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:02:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:03:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:04:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:05:13 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:06:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:07:13 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:20:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:21:13 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:22:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:23:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:30:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:31:13 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:32:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:33:12 1: 192.168.2.50:1000 reappeared (OG_HMLAN)
2013.11.12 15:34:11 1: 192.168.2.50:1000 disconnected, waiting to reappear
2013.11.12 15:35:13 1: 192.168.2.50:1000 reappeared (OG_HMLAN)

Das System ist aktuell (gerade heute morgen noch ein Update gemacht
ich habe keine PRESENCE oder WOL Devices drin
alles andere im Netzwerk ist ausgeschaltet (NAS etc.)

Und das beste: wenn ich attr global verbose 5 setze, dann habe ich keine disconnects (zumindest nichts mehr im Logfile)?

Ich blick nicht mehr, was ich sonst noch so probieren könnte

[MarkusN]

Hallo FHEM-Gemeinschaft!

Seit zwei Wochen betreibe ich eine minimale HM-Konfiguration, die derzeit lediglich aus einem HMLAN und einem Temperatur-/Luftfeuchtesensor HM-WDS10-TH-O besteht. Die Inbetriebnahme (zu dem Zeitpunkt lief bei mir noch FHEM 5.4) lief reibungslos, auch die restlichen Devices die ich momentan noch nicht nutze funktionieren wunderbar, auch die BidCos-Kommunikation läuft. Jedoch habe ich recht früh bemerkt dass FHEM mehr oder weniger regelmäßig die Verbindung zum HMLAN-Adapter verliert, das sah in der Logfile dann so aus:

Code Auswählen Erweitern

[...]
2013.11.06 08:25:04 1: hmlan:1000 reappeared (hmlan)
2013.11.06 08:24:59 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 08:11:02 1: hmlan:1000 reappeared (hmlan)
2013.11.06 08:10:57 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 07:59:04 1: hmlan:1000 reappeared (hmlan)
2013.11.06 07:58:54 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 07:45:05 1: hmlan:1000 reappeared (hmlan)
2013.11.06 07:45:00 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 06:29:02 1: hmlan:1000 reappeared (hmlan)
2013.11.06 06:28:57 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 06:17:03 1: hmlan:1000 reappeared (hmlan)
2013.11.06 06:16:58 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 05:55:05 1: hmlan:1000 reappeared (hmlan)
2013.11.06 05:55:00 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 05:41:03 1: hmlan:1000 reappeared (hmlan)
2013.11.06 05:40:58 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 05:37:04 1: hmlan:1000 reappeared (hmlan)
2013.11.06 05:36:59 1: hmlan:1000 disconnected, waiting to reappear
2013.11.06 04:09:50 1: hmlan:1000 reappeared (hmlan)
2013.11.06 04:09:45 1: hmlan:1000 disconnected, waiting to reappear
[...]

Kommt relativ häufig vor, meistens mind. 1x pro Stunde.  Man sieht jedoch deutlich dass der HMLAN nach wenigen Sekunden wieder da ist.
Mutig wie ich bin habe ich vor drei Tagen ein FHEM-Update angestoßen, in der Hoffnung dass meine restliche Installation (hauptsächlich 1-Wire und Max!) darunter nicht leidet. Glücklicherweise funktioniert auch noch alles, das HMLAN-Problem hat sich jedoch nicht verbessert, ganz im Gegenteil:

Code Auswählen Erweitern

[...]
2013.11.12 15:26:48 1: hmlan:1000 reappeared (hmlan)
2013.11.12 15:25:47 1: hmlan:1000 disconnected, waiting to reappear
2013.11.12 15:19:43 1: hmlan:1000 reappeared (hmlan)
2013.11.12 15:18:43 2: HMLAN_Parse: hmlan new condition disconnected
2013.11.12 15:18:43 1: hmlan:1000 disconnected, waiting to reappear
2013.11.12 15:07:47 2: HMLAN_Parse: hmlan new condition ok
2013.11.12 15:07:47 2: HMLAN_Parse: hmlan new condition init
2013.11.12 15:07:47 1: hmlan:1000 reappeared (hmlan)
2013.11.12 15:06:43 2: HMLAN_Parse: hmlan new condition disconnected
2013.11.12 15:06:43 1: hmlan:1000 disconnected, waiting to reappear
2013.11.12 14:16:44 2: HMLAN_Parse: hmlan new condition ok
2013.11.12 14:16:44 2: HMLAN_Parse: hmlan new condition init
2013.11.12 14:16:44 1: hmlan:1000 reappeared (hmlan)
2013.11.12 14:15:43 2: HMLAN_Parse: hmlan new condition disconnected
2013.11.12 14:15:43 1: hmlan:1000 disconnected, waiting to reappear
2013.11.12 13:56:45 2: HMLAN_Parse: hmlan new condition ok
2013.11.12 13:56:44 2: HMLAN_Parse: hmlan new condition init
2013.11.12 13:56:44 1: hmlan:1000 reappeared (hmlan)
2013.11.12 13:55:43 2: HMLAN_Parse: hmlan new condition disconnected
2013.11.12 13:55:43 1: hmlan:1000 disconnected, waiting to reappear
2013.11.12 13:38:46 2: HMLAN_Parse: hmlan new condition ok
2013.11.12 13:38:46 2: HMLAN_Parse: hmlan new condition init
2013.11.12 13:38:46 1: hmlan:1000 reappeared (hmlan)
2013.11.12 13:37:43 2: HMLAN_Parse: hmlan new condition disconnected
2013.11.12 13:37:43 1: hmlan:1000 disconnected, waiting to reappear
2013.11.12 13:36:47 2: HMLAN_Parse: hmlan new condition ok
2013.11.12 13:36:47 2: HMLAN_Parse: hmlan new condition init
2013.11.12 13:36:47 1: hmlan:1000 reappeared (hmlan)
2013.11.12 13:35:43 2: HMLAN_Parse: hmlan new condition disconnected
2013.11.12 13:35:43 1: hmlan:1000 disconnected, waiting to reappear
[...]

Die Disconnects sind im Schnitt gleich viele, allerdings ist die Zeit in der der HMLAN weg ist länger geworden, nämlich ca. eine Minute. Und das ist für eine vernünftige Installation nicht mehr tragbar.

FHEM läuft mittlerweile seit über einem Jahr auf einem RaspberryPi mit 256MB Ram und hat seinen Dienst immer problemlos verrichtet, die Sache mit dem HMLAN verärgert mich jedoch sehr.  Der HMLAN hat die aktuelle Firmware (0.961), eine feste IP-Adresse und die AES-Encrypted LAN Communication ist deaktiviert. Eine saubere LAN-Verbindung besteht auch, zwischen dem RaspberryPi und dem HMLAN liegen zwei Gbit-Switche.

Diskussionen wie diese sind leider im Sand verlaufen, ohne dass sich der OP wieder gemeldet hat.

Wie bekomme ich das in den Griff?

Grüße,

Markus

[MarkusN]

Mist, da bist du mir ja zuvor gekommen

Habe quasi einen identischen Post geschrieben. Gut dass ich damit aktuell nicht alleine bin.

[bugster_de]

was mich wundert: momentan tauchen alle meine Probleme (siehe andere Posts) auch bei mehreren Usern auf.

[bugster_de]

das war dann wohl ein doppel-Post. Ich habe das gleiche Problem auch gerade eingestellt.

[martinp876]

hi,

das ist ja ein interessanter testfall (schade für dich... sorry)
kannst du mitloggen mit
attr global verbose 1
attr global mseclog 1
attr OG_HMLAN loglevel 1

danke
Martin

p.s. habe die Themen zusammengefasst. Bitte um die Logs.

[MarkusN]

Hallo Martin,

habe quasi das gleiche Problem (siehe anderer Thread von mir) und habe mir mal erlaubt deinen Vorschlag umzusetzen. Anbei ein Auszug der Logfile als der HMLAN sich mal wieder verabschiedet hat:

Code Auswählen Erweitern


[...]
2013.11.13 08:48:26.840 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32AD5945 IDcnt:0000
2013.11.13 08:48:26.112 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:48:01.111 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32ACF4C0 IDcnt:0000
2013.11.13 08:48:01.105 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:47:53.723 1: HMLAN_Parse: hmlan R:E20DB0B   stat:0000 t:32ACD081 d:FF r:FFCF     m:F4 8670 20DB0B 000000 00AE3B
2013.11.13 08:47:36.103 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32AC930D IDcnt:0000
2013.11.13 08:47:36.097 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:47:11.098 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32AC315B IDcnt:0000
2013.11.13 08:47:11.091 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:46:47.914 1: HMLAN_Parse: hmlan new condition ok
2013.11.13 08:46:47.913 1: HMLAN_Parse: hmlan R:R506D4007 stat:0002 t:00000000 d:FF r:7FFF     m:99 8112 737BB2 000001
2013.11.13 08:46:47.910 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32ABCF62 IDcnt:0000
2013.11.13 08:46:46.086 1: HMLAN_Send:  hmlan S:S506D4007 stat:  00 t:00000000 d:01 r:506D4007 m:99 8112 737BB2 000001
2013.11.13 08:46:46.031 1: HMLAN_Parse: hmlan new condition init
2013.11.13 08:46:46.030 1: HMLAN_Send:  hmlan I:T1A15DCD6,04,00,00000000
2013.11.13 08:46:46.028 1: HMLAN_Send:  hmlan I:Y03,00,
2013.11.13 08:46:46.026 1: HMLAN_Send:  hmlan I:Y02,00,
2013.11.13 08:46:46.025 1: HMLAN_Send:  hmlan I:Y01,00,
2013.11.13 08:46:46.023 1: HMLAN_Send:  hmlan I:C
2013.11.13 08:46:46.022 1: HMLAN_Send:  hmlan I:A737BB2
2013.11.13 08:46:46.014 1: hmlan:1000 reappeared (hmlan)
2013.11.13 08:45:44.648 1: HMLAN_Parse: hmlan new condition disconnected
2013.11.13 08:45:44.607 1: hmlan:1000 disconnected, waiting to reappear
2013.11.13 08:45:44.601 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:45:12.693 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32AA62C7 IDcnt:0000
2013.11.13 08:45:12.687 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:45:01.166 1: HMLAN_Parse: hmlan R:E20DB0B   stat:0000 t:32AA26C2 d:FF r:FFCF     m:F3 8670 20DB0B 000000 00AF3C
2013.11.13 08:44:47.679 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32AA010D IDcnt:0000
2013.11.13 08:44:47.673 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:44:22.667 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32A99F56 IDcnt:0000
2013.11.13 08:44:22.661 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:43:57.661 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32A93DA4 IDcnt:0000
2013.11.13 08:43:57.654 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:43:31.326 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32A8D6C0 IDcnt:0000
2013.11.13 08:43:31.318 1: HMLAN_Send:  hmlan I:K
2013.11.13 08:43:06.143 1: HMLAN_Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32A8745F IDcnt:0000
2013.11.13 08:43:06.137 1: HMLAN_Send:  hmlan I:K
[...]

Was mir sofort auffällt:

Code Auswählen Erweitern

2013.11.13 08:46:46.014 1: hmlan:1000 reappeared (hmlan)
2013.11.13 08:45:44.648 1: HMLAN_Parse: hmlan new condition disconnected
2013.11.13 08:45:44.607 1: hmlan:1000 disconnected, waiting to reappear
2013.11.13 08:45:44.601 1: HMLAN_Send:  hmlan I:K

FHEM scheint nach dem Senden des K garnicht lange zu warten, sondern sagt direkt dass der HMLAN disconnected ist.

[martinp876]

Hallo Markus,

das ist ein klarer keep-alive Verstoss.

08:45:44.648 Parse: hmlan new condition disconnected
08:45:44.607 1000 disconnected, waiting to reappear
08:45:44.601 Send:  hmlan I:K
*** 32  sec delay ***
08:45:12.693 Parse: hmlan V:03C1 sNo:JEQ0707502 d:1E9CFB O:737BB2 t:32AA62C7 IDcnt:0000
08:45:12.687 Send:  hmlan I:K

die 32sec sind zu lang. HMLAN mache einen autonomen disconnect. 00_HMLAN kann garnicht warten, der disconnect wird - korrekter weise - von IODev gemeldet, weil die TCP connection zusammengebrochen ist. Das ist von HMLAN beabsichtingt und hat soweit alles seine Richtigkeit.
Wir haben es in diesem Fall mit einem "einfachen" timeout zu tun.

Was ist zu tun
1) erkennen des Problems
in der neusten Version von FHEM solltest du bei HMLAN einen Parameter sehen
msgKeepAlive dlyMax:0.01 bufferMin:4

das sagt dir, dass das der keep-Alive trigger maximales  10ms später kam, als ich programmiert hatte (also quasi pünktlich). Ich hatte noch 4 sec Puffer bis zum voraussichtlichen HMLAN disconnect. Ich habe 25 sec Periode eingestellt, bei 30sec erwarte ich ein disconnect - ich runde nach Integer - also 4sec ist ok.
==> mein System hat im beobachteten Zeitraum kein Problem
??> wie sieht es bei dir aus?

2) Symptom beheben
Mit dem Attribut wdTimer kannst du den Timer von 25sec reduzieren und somit dem Puffer (jetzt 5 sec) vergrössern. Damit lassen sich delays deines systems ausgleichen.

3) Ursachen des Problems
die eigentliche Ursache für den Delay ist (noch bin ich überzeugt) nicht der HM-part von FHEM. Du hat voraussichtlich einen Prozess laufen, der länger als 5sec FHEM blockiert. Noch hat FHEM (leider) keine Überwachung und Auswertung, welcher Prozess wie lange braucht - und somit wie lange alles andere blockiert.

Gruss Martin

[MarkusN]

Hallo Martin,

danke für diese ausführliche Antwort. Ich habe auch bereits einen ersten Verdacht. Nachdem du erwähnt hast dass FHEM vermutlich zu lange blockiert wird ist mir eingefallen dass mein Nagios einige meiner Temperatursensoren über fhem.pl abfragt. Das habe ich jetzt mal deaktivert, ggf werde ich es so umbauen dass Nagios die Daten nicht über fhem.pl sondern via owserver abfragt. Bis jetzt gibt es jedenfalls seit über einer Stunde keinen Disconnect mehr.

msgKeepAlive sagt bei mir jedenfalls: "dlyMax:12.498 bufferMin:-7"

Ich hoffe dass ich mein Problem damit gefunden habe.

[martinp876]

Hallo Markus,

zumindest eines, das ist sicher.
schön zu sehen, dass die delay-berechnung funktioniert
Ich werden noch eine Beschreibung basteln um die Info verständlich zu machen.

Gruss Martin

[MarkusN]

Hallo Martin,

meine Nagios-Abfrage über fhem.pl scheint nicht alleiniger Auslöser für meine Probleme zu sein. Mein msgKeepAlive beträgt mittlerweile "dlyMax:8.107 bufferMin:6", also immer noch weit von optimalen Werten entfernt. Die Disconnects sind in etwa gleich häufig vorgekommen. Ich habe jetzt wdTimer auf 15 gesetzt und habe seit 3 Stunden Ruhe vor Disconnects.

Die Zahlen habe ich noch nicht wirklich verstanden. Das HMLAN-Modul sendet regelmäßig Pakete (das "K"?) an den HMLAN-Adapter, welcher daraufhin eine Art Ack schickt. Dieser Ack muss innerhalb einer bestimmten Zeit geschickt werden, ansonsten denkt FHEM der HMLAN ist nicht mehr erreichbar. Ist das so weit richtig? Meinst du mit Keep-Alive Trigger die Antwort des HMLAN-Adapters? Und warum ist bufferMin bei mir manchmal negativ? Fragen über Fragen. Und jetzt die wichtigste: Habe ich mir durch die Erhöhung des wdTimer eine mögliche Verzögerung bei der Befehlsausführung erkauft?

Danke und Grüße,

Markus

[martinp876]

Hallo Markus,

an einer erweiterten Doku arbeite ich  noch...
dlyMax:8.107 bufferMin:6

Das keepalive kam maximal 8sec "verspätet", also spater als über dem timer eingestellt. Somit gibt es einen "Task" oder auch eine Gruppe von tasks die 8sec das abarbeiten des timers verhindern. Das kann jedem timer in FHEM so gehen. 8sec sind aus meiner sicht kritisch - und sollte es ein einzelner "task" sein eigentlich nicht hinnehmbar in einem "echtzeitsystem". Müsste man suchen gehen.
Du hattest seit der letzten Änderung des wdTimer mindestens 6 sec Puffer zwischen keep-alive message und erwartetem HMLAN disconnect.

Wenn du jetzt 15 eingestellt hast wird das keep-alive ("k") alle 15 sec gesendet. Es gab aber (s.o.) manchmal 8 sec delay, also trigger nach 23sec. Du hattest also <7sec puffer (entspricht "6" wen man "int" macht)
Die Berechnungen stimmen als. Keep-Alive-mässig bist du also im grünen Bereich.

Die Berechnung von bufferMin ist einfach:  30 - "zeit-zwische-2-keep-alive". Wenn die Zahl negativ ist kam der trigger zu spät. Bei 0 oder negativ ist damit zu rechnen, dass der HMLAN einen disconnect gemacht hat.

Du hat 2 Möglichkeiten, dem zu begegnen: schneller triggern (wdTimer runter setzen) oder den "langweiler" finden, der FHEM so lange blockiert.

Die Überwachung der keep-alive-Antwort hast du richtig erkannt. Diese führt aber nach den logs nicht zu einem Problem bei dir. Diese hat die Aufgabe zum einen das Protokol zu komplettieren, ggf ein keep-alive nachzusenden falls es verloren geganben ist und zum 2. einen schnelleren disconnect/reconnect durchzuführen sollte der HMLAN "verstorben" sein. Das kann u.U. manche message-sequence "retten". - wie gesagt, nicht bei dir aufgetreten.

Mit dem heruntersetzen des keepalive verzögerst du erst einmal nicht. Das ist nicht kritisch - und 15 ist sicher vertretbar. Du sendest jetzt doppelt so viele keep-alives  - aber das belastet das HMLAN auch nicht in seiner transmission performance.
Was mich stören würde sind die 8sec. Irgendwann - wie oft auch immer -ist ein task dran der ganz FHEM 8 sec blockiert (könnte auch eine sequenz sein...). Du kannst davon ausgehen, dass dann ganz FHEM steht. Es werden auch andere Timer auslaufen, messages werden wiederholt oder die Übertragung abgebrochen. Einfach alles, was über die Zentrale läuft.
Viele sehen das gelassen - mich stört es immens. Wenn das schule macht und es immer mehr dieser Kandidaten gibt werden sie sich akkumulieren. Aus meiner Sicht sollte ein einzelner task nach spätestens 1sec beendet sein - das ist schon lang.
Aktuell gibt es noch keine Möglichkeit (die mir bekannt ist) daß es ein User messen könnte. Evtl bastle ich einmal etwas.

Gruss Martin

[bugster_de]

Hi,

ich habe zwar den Task gestartet, aber da ja alles so geht wie es soll habe ich nicht mehr rein geschaut.

Das mit der Performance ist natürlich interessant. Ich beobachte seit geraumer Zeit dass meine FB7390 im Schnitt bei 80% CPU Load hängt. Somit kann es natürlich sein, dass irgendein Task die Ausfürhung der Rückmeldungsauswertung in HM-LAN blockiert.
Wie kann ich rausfinden, wer der Schuldige ist? Gibt es Performance Logging Tools für Perl?

-->Martinp876: im Prinzip ist das dann aber ein unglückliches Design für so ein "Echtzeitsystem". Wenn de eine "Task" den Buschstaben K sendet und dann in fester Zeit die Ausführung unr Rückmeldung geprüft werden muß, dann muss es eigentlich pre-emptive sein, sonst geht das mit Ansage schief. Ich weiß, da kannst Du nichts dafür, denn das ist halt in Perl / FHEM mal so.
Im Prinzip müsste man im Design einen Interrupt vorsehen. Der zugehörige Handler speichert dann nur die ein gegangen Antwort des HM-LAN inkl. Zeitstempel. Und sobald dein HM-LAN Modul nach Ablauf des InternalTimer wieder dran kommt wertet es den gespeicherten Zeitstempel aus.

[martinp876]

wenn die FB auf 80% hängt solltest du erst einmal den Unix-level bemühen, nachsehen ob Perl/fhem das Problem ist (oder zu welchen Anteil) und was sonst so los ist.

-->Martinp876: im Prinzip ist das dann aber ein unglückliches Design für so ein "Echtzeitsystem"

ja.
Bitte an die Entwickler der Platform wenden. FHEM hat definitiv Grenzen!

Wenn de eine "Task" den Buschstaben K sendet und dann in fester Zeit die Ausführung unr Rückmeldung geprüft werden muß, dann muss es eigentlich pre-emptive sein, sonst geht das mit Ansage schief.

nein.
Die Timer laufen in gleichen Threat und werden "symetrisch" mit verzögert. Das ist wiederum ein Vorteil des Designs.

Ich weiß, da kannst Du nichts dafür, denn das ist halt in Perl / FHEM mal so.

Nicht Perl, aber FHEM

Im Prinzip müsste man im Design einen Interrupt vorsehen. Der zugehörige Handler speichert dann nur die ein gegangen Antwort des HM-LAN inkl. Zeitstempel. Und sobald dein HM-LAN Modul nach Ablauf des InternalTimer wieder dran kommt wertet es den gespeicherten Zeitstempel aus.

Ich denke du siehst ein Problem wo keins ist. Es gibt Probleme - aber die rechtzeitige Prüfung der Antwort ist eher keines.
Das rechtzeitige senden des "k" schon häufiger.

Gruss Martin

[Jojo11]

Hallo,

auch ich habe schon seit längerem dieses Phänomen beobachtet und "HMLAN disconnected, waiting to reappear"-Einträge im log. Bislang war mir vollkommen unklar, woran es liegen könnte. Nun habe ich ein absolut reproduzierbares Szenario entdeckt. Ich habe eine Seite (einen Raum "Plots") mit 12 Temperaturplots. Wenn ich diese Seite im Browser aufrufe, dauert das so ca. 40 Sekunden. Während die Seite aufgebaut wird, disconnected der HMLAN. Ist es richtig, dass der Plot-Aufbau FHEM mehr oder weniger lahm legt, so dass die HMLAN-Lebenszeichen nicht mehr rechtzeitig empfangen werden können? Kann man das irgendwie umgehen oder z.B. den Seitenaufbau in der Priorität herabsetzen?

schöne Grüße
Jo