HMLAN Adapter wechselt permanent zwischen disconnected / connected

Begonnen von bdombrowsky, 26 Februar 2014, 19:41:00

Vorheriges Thema - Nächstes Thema

Nobby1805

Zitat von: frank am 05 August 2016, 12:30:30
nachdem der hmlan ausgemustert wurde, erwarte ich kein update mehr.
Die Nachricht, die ich von ELV erhalten hatte hieß: der Update kommt, aber es dauert etwas ... ich hake da jetzt noch einmal nach
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

MarkusN

Ich hatte bis vor kurzem massive Probleme mit disconnects/reconnects vom HMLAN, hat am Tag teilweise hunderte Zeilen in meine log geworfen. Habe dann per Zufall rausgefunden dass offenbar der logitech media server für die Probleme verantwortlich ist. Nachdem ich den aufgrund einer Änderung in meinem Netzwerk in ein anderes VLAN geschoben habe waren die Probleme plötzlich verschwunden. Heute habe ich den LMS wieder in das gleiche VLAN wie den HMLAN geworfen und die Probleme gingen wieder von vorne los.

Habe jetzt nicht weiter recherchiert, aber der LMS wird vermutlich eine Art Broadcast raushauen um die Radios wissen zu lassen dass er da ist. Vielleicht kommt der kleine HMLAN mit so einem "Sturm" nicht klar und steigt irgendwann aus.

Vielleicht ist ein ähnlicher Dienst (bspw. DLNA oder AirPlay) bei euch für die Probleme verantwortlich.

Grüße,

Markus

dev0

Zitat von: MarkusN am 09 August 2016, 11:38:41
vermutlich eine Art Broadcast raushauen
Multicast, nicht Broadcast. Das ist bekannt und tritt eigentlich auch nur auf, wenn ein (dummer) Switch das nicht filtern kann.

Nobby1805

Zitat von: dev0 am 09 August 2016, 14:06:06
... und tritt eigentlich auch nur auf, wenn ein (dummer) Switch das nicht filtern kann.
weil dann der ganz dumme HMLAN damit gar nicht zurecht kommt und abschmiert :(
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

sledge

Wenn jetzt Dienste rund um Airplay / DLNA als potentielle Übeltäter in Frage kommen, müsste dieses Problem doch "jeden" treffen, oder bin ich hier auf dem Holzweg.

Nahezu jeder Drucker verwendet heutzutage Bonjour (als Implementierung von Airplay), ebenso Kodi / Openelec, um die Konfiguration zu vereinfachen. Auch so manches NAS preist doch seine Verfügbarkeit über diese Mechanismen im heimischen Netz an.

Interessanterweise war ich in den letzten anderthalb Wochen nicht daheim - Kodi somit aus, gedruckt wurde auch nicht, niemand hat (außer des FHEM-Rechners) das NAS angetriggert. Lediglich das NAS und der Drucker liefen durch - dennoch wimmelt es im Log nur so von disconnects, aber eben unregelmäßig - mal 20 Minuten Ruhe, dann nach zwei Minuten Hektik, dann mal drei Stunden Ruhe. Unabhängig von Tag- oder Nachtzeit - über einen Zeitraum von 10 Tagen immerhin 514 disconnects.

Im Zeitraum von 7 Tagen vor dem Urlaub waren es 134 disconnects. Rein statistisch traten in der Zeit, während Kodi häufiger lief, gedruckt wurde usw. (und vermutlicherweise auch mehr Bonjour / Airplay-Requests durchs Netz gejagt wurden) weniger disconnects auf als in meiner Abwesenheit.

Daher die Frage: Sind "wir" mit den Multicasts als Übeltäter auf dem richtigen Weg?

Helfe sehr gerne mit bei der Suche / Anamnese, wenn mich jemand mit in die richtige Richtung schiebt ;-)

Gruß,

Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

chriz

Problematisch waren bei mir nur die Telekom Entertain (IPTV) Multicasts, welche meinen HMLAN oftmals aus dem Takt brachten. Airplay, Bonjour, DLNA usw. machen hier keine Probleme. Einen hohen Netzwerktraffic kannst du auch an einem beliebigen Netzwerkswitch sehen. Seinerzeit hat Entertain alle "Lämpchen" am Switch in rage gebracht :D, wobei Airplay/Bonjour/DLNA usw. keine aussergewöhnlich hohe Netzwerklast am Switch erzeugte.

Zudem hat die modifizerte HMLAN.pm (hier im Thread gepostet) meine ab und an dennoch vorkommenden HMLAN disconnects nahzu ausgemerzt. Über mehrere Wochen habe ich nun maximal 1-2 disconnects die Woche, wenn überhaupt.

Dieser HMLAN-Fix sollte in die offzielle Version eingebaut werden, bin mir sicher das so viele disconnects vermieden werden.

Grüße
Chris
FHEM auf Intel NUC D34010WYK Core i3, SSD, Ubuntu. HomeMatic mit HMLAN (Groundplane Antenne), Fritz DECT!200, FritzBox 7490, EnerGenie EG-PMS2-LAN, Yamaha RX-V475, Netatmo, Withings, Philips hue, Osram Lightify, Flukso Energy Meter, Harmony, RooWifi, Junkers ZSB 24-4 C Heizung via Heatronic HT-BUS

sledge

Mein Switch als solcher hat schon gut zu tun - aber Netzwerküberlastung bei meinem 1GB Netzwerk habe ich noch nicht festgestellt. Die Übertragungsraten zu meinem NAS entsprechen idR den 100MB/s - viel mehr ist wohl via Samba auf 1GB-Ethernet auch nicht zu holen.

Gerade habe ich mal probeweise 100GB kopiert, um den Switch mal ein wenig anzuwärmen - dabei traten aber keinerlei HMLAN-spezifischen Probleme auf.

Bisher habe ich mit dem Einspielen des Patches gewartet - wollte hier auf das "offizielle" GO warten - werde es aber gleich mal in Betracht ziehen und mir die Datei einspielen.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

sledge

Also die Antwort auf sich selbst ;-)

Nachdem ich den ganzen Thread noch mehrfach durchgearbeitet habe (eigentlich mit der Absicht, den mehrfach erwähnten Patch einzuspielen), bin ich den Anmerkungen von Martin nochmal explizit nachgegangen.

Was waren die Hinweise:


       
  • apptime auf Unregelmäßigkeiten untersuchen, speziell apptime maxDly all.   
    Ergebnis: Viele Einträge mit hohen maxDelays
  • perfmon hinzuziehen.
    Ergebnis: Bei jeder Aktualisierung meiner MAX!--Komponenten kam es zu langen Aussetzern, ebenso beim periodischen Prüfen der XBMC-Devices. Auch die Fritzboxen (3 an der Zahl) verursachten immer wieder mal entsprechende Einträge im Logfile. In Summe hatte ich je Minute rund 3 Einträge durch perfmon... nicht schön
2016.08.19 14:29:58 1: Perfmon: possible freeze starting at 14:29:56, delay is 2.465
2016.08.19 14:30:34 1: Perfmon: possible freeze starting at 14:30:32, delay is 2.849
2016.08.19 14:31:02 1: Perfmon: possible freeze starting at 14:30:56, delay is 6.005
2016.08.19 14:31:38 1: Perfmon: possible freeze starting at 14:31:35, delay is 3.341
2016.08.19 14:32:06 1: Perfmon: possible freeze starting at 14:32:00, delay is 6.005
2016.08.19 14:32:41 1: Perfmon: possible freeze starting at 14:32:38, delay is 3.005
2016.08.19 14:33:10 1: Perfmon: possible freeze starting at 14:33:04, delay is 6.005
2016.08.19 14:33:44 1: Perfmon: possible freeze starting at 14:33:42, delay is 2.527
2016.08.19 14:34:14 1: Perfmon: possible freeze starting at 14:34:08, delay is 6.005
2016.08.19 14:34:48 1: Perfmon: possible freeze starting at 14:34:45, delay is 3.074
2016.08.19 14:35:14 1: Perfmon: possible freeze starting at 14:35:12, delay is 2.041
2016.08.19 14:35:18 1: Perfmon: possible freeze starting at 14:35:15, delay is 3.005
2016.08.19 14:35:50 1: Perfmon: possible freeze starting at 14:35:48, delay is 2.602
2016.08.19 14:36:18 1: Perfmon: possible freeze starting at 14:36:15, delay is 3.005
2016.08.19 14:36:21 1: Perfmon: possible freeze starting at 14:36:19, delay is 2.013
2016.08.19 14:36:54 1: Perfmon: possible freeze starting at 14:36:51, delay is 3.005
2016.08.19 14:37:22 1: Perfmon: possible freeze starting at 14:37:19, delay is 3.005
2016.08.19 14:37:25 1: Perfmon: possible freeze starting at 14:37:23, delay is 2.026
2016.08.19 14:37:58 1: Perfmon: possible freeze starting at 14:37:55, delay is 3.293
2016.08.19 14:38:11 1: Perfmon: possible freeze starting at 14:38:10, delay is 1.237
2016.08.19 14:38:26 1: Perfmon: possible freeze starting at 14:38:23, delay is 3.005

  • Netzwerkkonstellation rund um den HM-CFG-LAN prüfen.
    Ergebnis HM-CFG-LAN hing hinter einem (kaskadierten) Switch eines WLAN-Hotspots, der den Port mit 1GB ansteuerte


Also alles der Reihe nach angegangen:


       
  • Sämtliche XBMC-Installationen auf "fork" umgestellt. attr <device> fork enable.
    Effekt: Deutliche Reduktion der maxDly-Einträge in apptime, ebenso deutlich weniger Logeinträge durch perfmon
  • Umstellung der Plots auf plotfork via  attr WEB plotfork 1
    Effekt: Da zusammen mit der ersten Maßnahme umgestellt, mache ich beides für die Reduktion der Logeinträge durch perfmon verantwortlich - im Positiven.
2016.08.19 15:07:06 1: Perfmon: possible freeze starting at 15:07:05, delay is 1.024
2016.08.19 16:19:23 1: Perfmon: possible freeze starting at 16:19:22, delay is 1.024
2016.08.19 16:24:37 1: Perfmon: possible freeze starting at 16:24:29, delay is 8.213
2016.08.19 16:38:41 1: Perfmon: possible freeze starting at 16:38:40, delay is 1.595
2016.08.19 16:55:26 1: Perfmon: possible freeze starting at 16:55:25, delay is 1.723
2016.08.19 16:57:35 1: Perfmon: possible freeze starting at 16:57:34, delay is 1.294
2016.08.19 16:58:29 1: Perfmon: possible freeze starting at 16:58:28, delay is 1.615
2016.08.19 16:58:48 1: Perfmon: possible freeze starting at 16:58:39, delay is 9.155
2016.08.19 16:58:51 1: Perfmon: possible freeze starting at 16:58:49, delay is 2.359
2016.08.19 17:43:56 1: Perfmon: possible freeze starting at 17:43:55, delay is 1.11



  • Update-Häufigkeit der "komplexeren" Devices reduziert, zB die Fritzboxen.
    Effekt: Ab jetzt keine Einträge mehr durch perfmon im Logfile
  • HM-CFG-LAN direkt an meinen Switch gehängt und den Port auf 10MBit/s runtergeregelt.
    Effekt: Seit der Umstellung kein einziges disconnect/reconnect mehr. Reboots hatte ich ohnehin nicht. Hält jetzt seit 14:00 des Vortags... also gute 20h


Desweiteren habe ich einfach in allen angelegten Devices nachgeschaut, ob man die Update-Zyklen hochsetzen kann - und dies bei einigen durchgeführt. In summe fluppt das System - bei einem Intel NUC hatte ich aber auch keine Probleme wg. der HW erwartet. Meine MAX!-Probleme (anderer Thread) haben sich auch erstmal "reduziert" - noch nicht ganz weg, aber deutlich besser.

Nochmal zur Info:

HM-CFG-LAN Firmware: 0.965
Original HMLAN-Modul (keinen Patch aus dem Thread)

Vielleicht hilft es ja jemandem. In jedem Fall Danke @Martin, der mit seinen (wiederholten) Hinweisen bzgl. Netzwerkkonfiguration und Analyse via Bordmittel (perfmon / apptime) in meinem Fall den Nagel auf den Kopf getroffen hat.

Gruß,

Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Gernott

#413
Hallo die Runde der Geplagten

ich will ja die Verwirrung nicht weiter steigern, nur eine Beobachtung mitteilen.
Seit 17.08. habe ich keine HMLAN disconnects mehr, davor waren es meist so zwischen 5 und 10 am Tag.

Was habe ich am 17.08. gemacht? Blöderweise zwei Dinge:
1. Update FHEM
2. Firmware Update Fritz!Wlan Repeater 1750E

Na mal sehen, ob es hält.

Update
Zu früh gefreut. da war er wieder, der erste disconnect.  :-\

Gruß
G.

frank

ZitatZu früh gefreut. da war er wieder, der erste disconnect.
trigger damit ein notify und lass licht einschalten als anwesenheits-simulation.  :)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Gernott

Zitat von: frank am 20 August 2016, 19:50:12
trigger damit ein notify und lass licht einschalten als anwesenheits-simulation.  :)
Das war jetzt aber nicht hilfreich. Bei uns ist immer einer da.

FhemPiUser

hallo zusammen,

ich hatte heute früh zum 2. mal das problem, dass der hmlan disconnected war und auch nach 1std noch nicht wieder funktionierte. normalerweise ist der ausfall ja nur wenige sekunde , aber diesmal nicht. selbst kurz vom strom trennen funktionierte nicht, erst als ich ihn mehrere minuten vom stom getrennt hatte ging er wieder.

ich hatte gestern ein fhem update gemacht und das modul dlnatenderer konfiguriert, keine ahnung ob es damit zu tun hatte.

sollte es nicht ein firmware update vom eq3 geben? wie ist denn da der stand?

ansonsten überlege ich schon auf das raspberry aufsteckmodul umzusteigen...

Deudi

Dazu noch meine 2 Cent:
Ich habe bei meinem Switch die Möglichkeit der Port-Isolation und blockiere damit für die Ports, an denen ein HM-CFG-LAN angeschlossen ist, den kompletten Traffic von allen Ports außer für den Cubietruck auf dem FHEM läuft. Hat etwa die gleiche Qualität wie ein VLAN. Damit sind die Disconnects deutlich zurückgegangen. Übrig bleibt im Schnitt ein Disconnect je HM-CFG-LAN pro Woche. Nachdem ich den Keep-Alive Patch eingespielt habe, sind die verbleibenden Disconnects weg.
Ich denke diese Änderung sollte Martin in das Modul aufnehmen.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

Nobby1805

Ich befürchte inzwischen, dass der von eQ-3 aufgrund meiner Logs gefundene Fehler zwar laut Aussage behoben ist, diese neue Version aber doch nicht mehr ausgeliefert wird :(
Auf meine diesbezügliche Anfrage kam nur auf Deutsch gesagt nur Bla-Bla zurück :(
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

FhemPiUser

#419
fürchte ich auch. ich habe bei eq3 auch nachgefragt und am telefon meinte er, er kennt das problem nicht und ich soll auf ccu2 umstellen oder nochmal per email den eq3 support fragen. letzteres habe ich dann gemacht mit der aussage, der hmlan sei defekt und ich soll mich an den händler wenden.

was für ein support... :(