HMLAN Adapter wechselt permanent zwischen disconnected / connected

[Ma_Bo]

Also bei mir ist die Version 11645, wo gibt es denn die 11666 ?

[Ma_Bo]

Habe den Fix jetzt mal auf die Version 11645 angewendet, aber ich hatte bis jetzt schon 1x reboot bei meinem HMLAN1 und 2x reboot bei meinem HMLAN2. Sonst hate ich höchstens 1x einen reboot bei einem der beiden. komischerweise läuft der HMLAN3 ohne Probleme bisher.

Es sind tatsächlich Reboots, sieht man ja anhand der uptime.

###### EDIT

Jetzt gerade hat sich der HMLAN3 auch rebootet. Ich spiel die alte Datei wieder ein.

[rx]

Bei mir waren die Reboots ja in dem Senden von bestimmten Paketen begründet. Das konnte ich herausfinden, da der nur empfangene HMLAN sich nie rebootet hat.
Ich hatte dann so lange beobachtet bis ich gesehen habe, dass ein Delay zwischen dem Bestätigen des Bewegungsmelders und dem Senden an das Licht das Problem löst. Das konnte ich dann vorwärts und rückwärts nachvollziehen, d.h. Delay raus -> Regelmäßige Reboots und Delay von mindestens 750ms rein -> keine Reboots mehr.

Alternativ habe ich dann den Keepalive-Fix versucht, da ich auch schon die Beobachtung mit dem zeitnahen Senden der Keepalives und dem daraus resultierenden Reboot gemacht habe. Der Fix hat für mich den gleichen positiven Effekt, d.h. auch mit diesem Fix treten keine Reboots mehr auf. Das Delay habe ich ebenfalls wieder entfernt. D.h. der Fix scheint den gleichen Effekt wie das Delay zu haben.

Ich würde mir wünschen, dass das mit dem Keepalive dauerhaft in fhem eingebaut wird - vielleicht über eine Option aktivierbar. Dass es nicht für alle die Lösung ist, wird auch allen klar sein - dafür sind die Gründe für die Reboots zu unterschiedlich...

Grüße

[M_I_B]

... darf ich mich dranhängen?!
Seit (gefühlt) vorgestern erhalte ich nach einem Reboot oder ReloadCFG ohne Ende "unreachable" durchgehend bei allen Devices. Das sieht dann auf den Dashboard so aus, das alle nacheinander auf "unreachable" wechseln und, wenn ich Glück habe, nach und nach alle wieder zurück kommen; Lauflicht in unschön. Das Phänomen hatte ich vergangene Woche definitiv nicht.
Habe eben gerade noch mal ein Update gemacht in der Hoffnung, das irgendwo beim letzen Update (etwa 14 Tage her) was klemmte... nö...
Dann habe ich abschließend den SCC aus der Config geschmissen und hardwaretechnisch entfernt, aber auch das hat nichts geändert.
Was noch auffällig ist, ist die enorme Zeit, die nun Befehle benötigen vom Auslösen bis zur Aktion. Ich habe u.a. zwei 8CH Platinen-Aktoren (HM-MOD-Re-8), welche ich als optische Rückmeldung für allerlei Dinge benutze. Dazu gibt es einen Dummy, mit dem ich alle 2x8 Kanäle gemeinsam schalten kann. Das dauerte vorher vielleicht 3 Sekunden, bis alle Kanäle den Zustand auch physikalisch geändert haben, nunmehr vergehen da schon mal etliche Minuten, wenn es überhaupt erfolgreich durchläuft. Da tauchen dann im Log solche Dinge auf:

Code Auswählen Erweitern

2016.06.17 16:35:23.913 3: CUL_HM set HM8NV1_1 off
2016.06.17 16:35:23.938 3: CUL_HM set HM8NV1_2 off
2016.06.17 16:35:23.958 3: CUL_HM set HM8NV1_3 off
2016.06.17 16:35:23.976 3: CUL_HM set HM8NV1_4 off
2016.06.17 16:35:23.989 3: CUL_HM set HM8NV1_5 off
2016.06.17 16:35:24.002 3: CUL_HM set HM8NV1_6 off
2016.06.17 16:35:24.014 3: CUL_HM set HM8NV1_7 off
2016.06.17 16:35:24.027 3: CUL_HM set HM8NV1_8 off
2016.06.17 16:35:24.051 3: CUL_HM set HM8NV2_1 off
2016.06.17 16:35:24.075 3: CUL_HM set HM8NV2_2 off
2016.06.17 16:35:24.099 3: CUL_HM set HM8NV2_3 off
2016.06.17 16:35:24.124 3: CUL_HM set HM8NV2_4 off
2016.06.17 16:35:24.148 3: CUL_HM set HM8NV2_5 off
2016.06.17 16:35:24.172 3: CUL_HM set HM8NV2_6 off
2016.06.17 16:35:24.197 3: CUL_HM set HM8NV2_7 off
2016.06.17 16:35:24.221 3: CUL_HM set HM8NV2_8 off
2016.06.17 16:36:39.269 1: HMLAN_Parse: UFO1 new condition timeout
2016.06.17 16:36:39.292 1: 192.168.1.198:1000 disconnected, waiting to reappear (UFO1)
2016.06.17 16:36:39.300 1: HMLAN_Parse: UFO1 new condition disconnected
2016.06.17 16:37:41.485 1: 192.168.1.198:1000 reappeared (UFO1)
2016.06.17 16:37:41.493 1: HMLAN_Parse: UFO1 new condition init
2016.06.17 16:37:43.987 1: HMLAN_Parse: UFO1 new condition ok
2016.06.17 16:38:49.429 3: CUL_HM set HM8NV1_1 on
2016.06.17 16:38:49.454 3: CUL_HM set HM8NV1_2 on
2016.06.17 16:38:49.474 3: CUL_HM set HM8NV1_3 on
2016.06.17 16:38:49.487 3: CUL_HM set HM8NV1_4 on
2016.06.17 16:38:49.499 3: CUL_HM set HM8NV1_5 on
2016.06.17 16:38:49.512 3: CUL_HM set HM8NV1_6 on
2016.06.17 16:38:49.525 3: CUL_HM set HM8NV1_7 on
2016.06.17 16:38:49.538 3: CUL_HM set HM8NV1_8 on
2016.06.17 16:38:49.563 3: CUL_HM set HM8NV2_1 on
2016.06.17 16:38:49.588 3: CUL_HM set HM8NV2_2 on
2016.06.17 16:38:49.613 3: CUL_HM set HM8NV2_3 on
2016.06.17 16:38:49.638 3: CUL_HM set HM8NV2_4 on
2016.06.17 16:38:49.664 3: CUL_HM set HM8NV2_5 on
2016.06.17 16:38:49.689 3: CUL_HM set HM8NV2_6 on
2016.06.17 16:38:49.715 3: CUL_HM set HM8NV2_7 on
2016.06.17 16:38:49.740 3: CUL_HM set HM8NV2_8 on
2016.06.17 16:39:00.015 1: HMLAN_Parse: UFO1 new condition timeout
2016.06.17 16:39:00.052 1: 192.168.1.198:1000 disconnected, waiting to reappear (UFO1)
2016.06.17 16:39:00.064 1: HMLAN_Parse: UFO1 new condition disconnected
2016.06.17 16:40:02.215 1: 192.168.1.198:1000 reappeared (UFO1)
2016.06.17 16:40:02.224 1: HMLAN_Parse: UFO1 new condition init
2016.06.17 16:40:05.761 1: HMLAN_Parse: UFO1 new condition ok
Wirklich eingeschaltet sind nach der Aktion allerdings nur 3 von 16 Kanälen... Ok, die Platinen sind nicht gerade die schnellsten, aber selbe Probleme bestehen auch mit allen anderen Aktoren, wie z.B. die 4CH Hutschinen- Teile... (Ich kann da gerne mal ein Video von machen, da ich die Platinen vor den Monitor legen kann, so das man beides sieht...)

Nachtrag:
Ich habe den HM-LAN jetzt mal komplett rausgeschmissen und über die VCCU nur noch den SSC dran. Jetzt ist das "Lichtorgelverhalten" zumindest weg. Leider ist das keine Dauerlösung, da der SCC bekannter Weise andere Probleme mit sich bringt. Ist also (für mich) die Frage, woran das beobachtete Verhalten nun liegt?

[Damu]

Regelmäßige Reboots und Delay von mindestens 750ms rein -> keine Reboots mehr.

Wie hast du das Umgesetzt?
DOIF mit Wait?

[Damu]

Hallo

Habe den "keepalive-fix" gestern Abend eingebaut:
Bis Heute Morgen kein Neustart von einem Lan Adapter.


HMLAN1 ist bei mir direkt an der Fritzbox
HMLAN2 über Powerline (AVM 546e an der Fritzbox, AVM 510E am Lan Adapter)
HMLAN3 über Powerline (AVM 546e an der Fritzbox, AVM 510E an einem Switch, Lan Adapter an dem Switch)

[Ma_Bo]

@Damu kannst du bitte mal deine gefixte 00_HMLAN.pm hier hochladen, möchte diese dann mal testen.
Ich hatte ja versucht den fix selber zu machen, aber mit der Datei hatte ich dann nur noch mehr reboots.
evtl geht es mit deiner, vielleicht hab ich ja was falsch gemacht.

Grüße Marcel

[Damu]

Hallo

Hier meine 00_HMLAN.pm
Perfekt ist es noch nicht, aber eben viel besse als vorher.

Habe nun mal Vebose auf 5 gestellt und werde beobachten.

[Ma_Bo]

Danke, werde ich gleich mal einspielen und testen.

[rx]

Wie hast du das Umgesetzt?
DOIF mit Wait?

Genau, ich habe in dem DOIF vor dem Einschalten der Lampen auf Grund von Bewegungsmelder-Aktivität einfach ein Sleep gesetzt. Der Keepalive-Fix scheint genau den gleichen Effekt zu haben - mittlerweile habe ich eine Uptime von 196 Stunden.

[FhemPiUser]

...die Reboots habe ich ja auch schon seit langem, aber ich hatte vorgestern das erste Mal den Fall, dass der HMLAN1 nach dem disconnect nicht wiedergekommen ist. Nach 2 Std. habe ich ihn dann vom Strom getrennt und wieder angeschlossen. Dann ging es wieder. Das gibt mir aber natürlich wenig Vertrauen in die Zuverlässigkeit des Systems.

Hatte das auch schon einmal jemand von Euch?

[michael.winkler]

ich habe heute festgestellt das in meinem Log folgendes zu sehen ist. Das läuft endlos durch. Ist das normal?

Code Auswählen Erweitern


2016.06.21 11:47:41 3: HMLAN1 device opened
2016.06.21 11:47:41 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:41 3: HMLAN1 device opened
2016.06.21 11:47:45 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:45 3: HMLAN1 device opened
2016.06.21 11:47:45 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:45 3: HMLAN1 device opened
2016.06.21 11:47:45 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:45 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:47 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:47 3: HMLAN1 device opened
2016.06.21 11:47:47 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:47 3: HMLAN1 device opened
2016.06.21 11:47:48 1: HMLAN_Parse: HMLAN1 new condition init


[Bartimaus]

Mein HMLAN trennt meistens zu einer vollen Stunde die Verbindung. Ich habe die diversen HourCounter im Verdacht, da diese immer zu einer vollen Stunde ein paar Berechnungen durchführen. Dann ist das System evtl. zu ausgelastet.

[Nobby1805]

Mein HMLAN trennt meistens zu einer vollen Stunde die Verbindung. Ich habe die diversen HourCounter im Verdacht, da diese immer zu einer vollen Stunde ein paar Berechnungen durchführen. Dann ist das System evtl. zu ausgelastet.

Dann schau doch mal mit Perfmon ob du Delays feststellen kannst

[Ma_Bo]

Danke Damu für deine gefixte Datei, bis jetzt habe ich keinen Reboot mehr. Vorher mindestens 1x innerhalb von 24 Stunden.
Grüße Marcel