Lan adapter disconnected andauernd

[Markus Bloch]

Hallo Dietmar,

anbei die überarbeitete Version von WOL mit BlockingCall für Ping und shutdownCmd.

Viel Spaß

Gruß
Markus

[Dietmar63]

hast du alles getestet?
wie gestaltet sich die Freigabe. Ich würde es übernehmen, da Boris ziemlich busy ist.

[Markus Bloch]

Hallo Dietmar,

ich hab alles im Zusammenhang mit BlockingCall getestet. Währe gut, wenn du es nochmal komplett testest mit allem drum und drann, da ich kein WOL nutze.

Zur Freigabe

Da man Rudi nicht via PN anschreiben kann und du wahrscheinlich in FHEM Development nichts posten darfst, würde ich es mit einem Post in "Unterstützende Dienste" versuchen mit der Bitte zum einchecken.

Viele Grüße

Markus

[integras]

Ich hatte auch den dauernden Disconnect.

Habe ihn in den Griff bekommen mit dem hier erwähnten:

attr HMLAN1 respTime 5

Seitdem nicht mehr aufgetreten.  

Falls sich noch jemand mit dem Problem herumschlaegt: ich habe das Gefühl, dass es bei mir ursächlich mit der Kanalwahl des Fritz WLAN Adapters zusammenhängt. Er wählt einen Kanal, auf dem sich schon viele andere tummeln. Habe ich jetzt mal umgestellt.

[thunder]

Ich hatte auch diese disconnects...

Seitdem ich den HMLAN alle 15 sec "streichle" habe ich keine Meldungen mehr im Log.

Bitte korrigiert mich sollte ich falsch liegen: de Netzlast die durch die herabsetzung der Timer erzeugt wird ist in einem GigE Netz vernachlässigbar und Skalierungsprobleme sollten nur dann auftreten falls ich massenhaft HMLANs hinzufügen würde. nicht aber bei zusätzlichen Sensoren oder Aktoren.

Wäre es bitte möglich den "Streicheltimer" in die HMLAN Config einstellbar zu machen?

[martinp876]

Hallo thunder,

ja, das ethernet selbst sollte in den wenigsten Faellen ein Problem darstellen.

wenn du bei ~15sec keine Probleme mehr hast heist dass im Rueckschluss, dass ein Task dein FHEM um 15sec ausbremst/lahmlegt. Das heist, dass ggf das einschalten deines Lichts um 15 sec verzoegert werden kann, wenn es ueber fhem kommt. Auch kann es zu protokoll-abbruechen kommen.

In meinem System wuerde ich so etwas nie akzeptieren, das hat nichts mehr mit echtzeit zu tun, besonders wenn es haeufig kommt.

Ich arbeite gerade an 'echten' HMLAN Problemen - evtl baue ich es ein... lass mich einmal nachdenken ;-) wahrscheinlich wird es also kommen.
Empfehlen kann und werde ich es niemandem - es ist eine ueble Symthpombehandlung.
Das Problem der Verzoegerung ist natuerlich nicht HM-eigen sondern betrifft alle Familien und alles, was von FHEM getriggert werden soll/muss. Faktisch ist es ein FHEM design/architektur fehler, wenn es auftritt und sollte nicht in x workarounds geloest werden sondern an der Quelle.

Gruss Martin

[martinp876]

Hallo Thunder,

wdTimer kannst du jetzt nutzen. 5-25sec sind zugelassen.

Gruss Martin

[thunder]

Hallo Martin,
selbst wenn ich au 5s keepalives herunter gehe bekomme ich die disconnects. Da das System auf dem FHEM läuft ein i5 mit 6GB RAM ist und ansonsten eigentlich nur einen Asterisk beheimatet (der sich übrigens völligunauffällig verhält) würde ich fast ausschliessen, daß es auf dem Server ein bottleneck gibt.

Ich werde mich jetzt dran machen Netzwerk Traces zu ziehen. da das LAN geswitched ist: ist es besser den Trace nah am FHEM oder nah am HMLAN zu ziehen?


Nachtrag:
ich beginne gerade ich ganz zaghaft dem HMLAN zu nähern und stelle bein Anpingen ein ungewöhnliches Verhalten fest:

Code Auswählen Erweitern

ping 192.168.10.7
PING 192.168.10.7 (192.168.10.7) 56(84) bytes of data.
64 bytes from 192.168.10.7: icmp_seq=1 ttl=128 time=0.484 ms
64 bytes from 192.168.10.7: icmp_seq=45 ttl=128 time=0.383 ms
64 bytes from 192.168.10.7: icmp_seq=46 ttl=128 time=0.363 ms
64 bytes from 192.168.10.7: icmp_seq=47 ttl=128 time=0.357 ms
64 bytes from 192.168.10.7: icmp_seq=48 ttl=128 time=0.396 ms
64 bytes from 192.168.10.7: icmp_seq=49 ttl=128 time=0.387 ms
64 bytes from 192.168.10.7: icmp_seq=93 ttl=128 time=0.356 ms
64 bytes from 192.168.10.7: icmp_seq=94 ttl=128 time=0.347 ms
64 bytes from 192.168.10.7: icmp_seq=95 ttl=128 time=0.358 ms
64 bytes from 192.168.10.7: icmp_seq=96 ttl=128 time=0.397 ms
64 bytes from 192.168.10.7: icmp_seq=97 ttl=128 time=0.419 ms
64 bytes from 192.168.10.7: icmp_seq=141 ttl=128 time=0.365 ms
64 bytes from 192.168.10.7: icmp_seq=142 ttl=128 time=0.345 ms
64 bytes from 192.168.10.7: icmp_seq=143 ttl=128 time=0.353 ms
64 bytes from 192.168.10.7: icmp_seq=144 ttl=128 time=0.386 ms
64 bytes from 192.168.10.7: icmp_seq=145 ttl=128 time=0.380 ms
64 bytes from 192.168.10.7: icmp_seq=189 ttl=128 time=0.395 ms
64 bytes from 192.168.10.7: icmp_seq=190 ttl=128 time=0.431 ms
64 bytes from 192.168.10.7: icmp_seq=191 ttl=128 time=0.426 ms
64 bytes from 192.168.10.7: icmp_seq=192 ttl=128 time=0.380 ms
64 bytes from 192.168.10.7: icmp_seq=193 ttl=128 time=0.373 ms
64 bytes from 192.168.10.7: icmp_seq=238 ttl=128 time=0.411 ms
64 bytes from 192.168.10.7: icmp_seq=239 ttl=128 time=0.329 ms
64 bytes from 192.168.10.7: icmp_seq=240 ttl=128 time=0.331 ms
64 bytes from 192.168.10.7: icmp_seq=241 ttl=128 time=0.369 ms
64 bytes from 192.168.10.7: icmp_seq=242 ttl=128 time=0.351 ms
64 bytes from 192.168.10.7: icmp_seq=287 ttl=128 time=0.382 ms
64 bytes from 192.168.10.7: icmp_seq=288 ttl=128 time=0.358 ms
64 bytes from 192.168.10.7: icmp_seq=289 ttl=128 time=0.374 ms
64 bytes from 192.168.10.7: icmp_seq=290 ttl=128 time=0.382 ms
64 bytes from 192.168.10.7: icmp_seq=291 ttl=128 time=0.413 ms


HMLAN antwortet auf fünf Pings und dann ist für längere Zeit Ruhen dann wieder fünf Antworten usw... In Summe 89% packet loss.
Ein Ping auf den letzten Switch vor dem HMLAN bringt 0% packet loss.

Ich gehe davon aus, daß die Pakete nicht auf dem Netz sondern im HMLAN verloren werden...

Nachtrag zum Nachtrag:
das seltsame ping-Verhalten ist auch im Betrieb mit dem Homematic Konfigurationsprogramm unter Windows zu beobachten...

[martinp876]

hm - mein HMLAN antwortet der FB immer. Es dauert zwar doppelt so lange (0.8ms) aber ist stabil.
Ich nehme an, dass andere Devices in deinem Netz sauber pingen.
Dann hat dein HMLAN wohl Probleme. Evtl kannst du noch einmal die FW runterladen (wenn es klappt...)

[thunder]

Hallo Martin,
das war der richtige Tipp. FW update und die pings laufen sauber....

bis jetzt auch keine disconnects...

jetzt ist nur die Frage was den HMLAN so aus dem Tritt gebracht hat.  aber ich befürchte die Frage werden wir nie mehr beantworten können ;-)

[martinp876]

Hallo thunder,

gut zu hoeren - sollten wir uns als Option merken
spekulieren kann man viel:
- FW version war nicht die aktuelle
- HMLAN hatte einen flash-fehler und das Programm war korrupt
- ein FW-update "koennte" sonstige Einstellungen im HMLAN ruecksetzen/loeschen???

Gruss Martin

[thunder]

Hallo Martin,

ich halte die Möglichkeit

ein FW-update "koennte" sonstige Einstellungen im HMLAN ruecksetzen/loeschen???

für die wahrscheinlichste und hoffe auf die Forschungsergebnisse zum FHEM gesteuerten reset des HMLAN


:-)