HMLAN Adapter wechselt permanent zwischen disconnected / connected

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

Vorheriges Thema - Nächstes Thema

rx

Also bei mir kommen sie nicht von FHEM, sondern von HM-Komponenten. Ich habe Bewegungsmelder im Verdacht - wenn sie gleichzeitig senden (bei mehr als einem in einem Raum).
Server started with 1333 defined entities (fhem.pl:27302/2023-03-05 perl:5.028001 os:linux user:root pid:29591)

martinp876

Das waere traurig. Hm sollte sich korrekt verhalten. Fhem muss ein paar einstellungen am hmlan durchfuehren. Bei devices zu denen ni ht gesendet wird sollte es kein problem geben. Nun ja.

Rampler

Ist irgendwie traurig die Story...
Habe unter anderem meine Alarmanlage damit  realisiert. Bei mir bootet der HMLAN Adapter (Murphys Gesetz) immer dann, wenn die Alarmanlage angeschlagen hat. Dann ist es natürlich blöde, wenn sich die Sirene nicht abschalten lässt, weil der Adapter gerade bootet.
Bin etwas stinkig auf EQ-3, immerhin habe ich mind. 2000 Euro in Homematic investiert...
Ich weiß, dass gejammer bringt nichts, musste aber trotzdem mal raus ...
Umso besser finde ich das Forum und die FHEM Entwickler !!!
3 HMUART (2 via ESP8266), 1 DUOFERN, 12 ESP8266, SolvisBen, GoodWE WR, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

StefanD

Habe meinen HMLAN gestern auch aktualisiert. Nach 15-20 vergeblichen Versuchen über das WLAN/LAN habe ich ihn direkt an den LAN Port gehängt, dann ging es auf Anhieb. Seither sind meine disconnect/connect Probleme weg.

Mein HMLAN hängt an einer FritzBox 7490 mit aktueller Labor-FW und der Port ist auf 1Gbit/s eingestellt. Die Einstellung auf 100Mbit/s hatten in der Vergangenheit keine Verbesserung gebracht.

VG
Stefan
HW: Intel NUC8i5 mit ESXi7 mit Ubuntu Server 18.04 LTS und FHEM als DockerContainer

rx

Ich geb ja nicht auf. Bei meinen letzten Tests hatte ich AES beim Türkontakt in Verdacht und habe es daraufhin disabled. HMLAN-Reboots sind natürlich immer noch da. Jetzt schaue ich mir immer nach einem Reboot die letzten Aktionen an. Heute morgen dann Reboot nachdem jemand in die Küche gekommen ist (Bewegungsmelder meldet an fhem und fhem schaltet Licht an). Letzte Meldung im Log vor Reboot:


2016.04.11 07:01:57.140 5: HMLAN_Send:  HMLAN1 S:S03B29B67 stat:  00 t:00000000 d:01 r:03B29B67 m:98 A011 1EA04F 24EB56 0201C800009601
2016.04.11 07:01:57.141 5: HMLAN_Send:  HMLAN1 I:K


Das Kommando ist nicht beim Licht angekommen.

Frage 1: Kann man daraus irgendwas erkennen?

Frage 2: Könnte man ein zweites HMLAN zum Sniffen-only nehmen? Ich habe ja bei meinen Tests ein Zweites erworben...
Server started with 1333 defined entities (fhem.pl:27302/2023-03-05 perl:5.028001 os:linux user:root pid:29591)

Newbie

Hallo,

ich hab ja auch seit Anfang Februar Probleme gehabt. Na jedensfalls kommen bei mir die Disconnect´s wohl vom Netzwerk bzw. der FritzBox.
HMLan muss alleine am Lan-Port(gedrosselt auf 100MB) angeschlossen sein, jede andere Konfiruration führt bei mir zu mehr oder weniger Fehlern.
Eventuell ist auch die Firmware der Fritte fehlerhaft, bis zum Februar gab es ja keine Probleme.


vg Jens
fhem-6.1 (configDB+DbLog)  auf ODROID-XU4

rx

Ich nehme jetzt mein 2. HMLAN als Sniffer mit einer minimalen FHEM-Installation auf einem Raspberry. Mal schauen ob es beide HMLAN gleichzeitig zerreisst... ich bleib dran :)
Server started with 1333 defined entities (fhem.pl:27302/2023-03-05 perl:5.028001 os:linux user:root pid:29591)

Nobby1805

Zitat von: rx am 12 April 2016, 22:09:35
Ich nehme jetzt mein 2. HMLAN als Sniffer mit einer minimalen FHEM-Installation auf einem Raspberry. Mal schauen ob es beide HMLAN gleichzeitig zerreisst... ich bleib dran :)
Da bin ich mal gespannt ... ich habe in einer ähnlichen Konfiguration getestet bevor ich vor fast 1 Jahr den  Servicecall bei eq-3 über ELV erzielt hatte .. der führte dann zu der Firmware 0.965 die aber leider das Problem nicht löst

Bei mir waren übrigens die Reboots der beiden HMLAN nie gleichzeitig
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)

rx

Ok, heute den ganzen Tag ruhig. Dann gegen 15:30 Uhr ein Reboot vom ersten HMLAN - kein Reboot beim zweiten HMLAN. Ob man dadurch aber einfach die "Empfangsseite" ausklammern kann, wage ich zu bezweifeln. Stochern im Nebel :)
Server started with 1333 defined entities (fhem.pl:27302/2023-03-05 perl:5.028001 os:linux user:root pid:29591)

Rampler

#309
Von seitens EQ3 ist wohl nicht mehr mit einer Korrektur zu rechnen, guckst Du:

ZitatHallo Nobody****,

wir können uns an dieser Stelle lediglich wiederholen.

Laut Hersteller eQ-3 ist das Verhalten behoben. Es sind dabei umfangreiche Tests mit verschiedenen Geräten durchgeführt worden.

Die Ursache für das Verhalten bei Ihnen beiden (nobody*** und Nobby1805) können wir so nicht feststellen. Zumal keine weiteren Rückmeldungen diesbezüglich vorliegen.

Wir würden Sie daher bitten, eine eMail-Anfrage hierzu einzureichen. Geben Sie dabei bitte genau an, welche Netzwerk-Komponenten verwendet werden und wie die Netzwerkstruktur aufgebaut ist. Zudem geben Sie bitte auch die ELV-Kundennummer mit an.

Ob sich was ändert, wenn jeder hier eine EMAIL-Anfrage einreicht ?

Hier ist der Link:
http://www.elv.de/topic/hm-lan-reboots.html
3 HMUART (2 via ESP8266), 1 DUOFERN, 12 ESP8266, SolvisBen, GoodWE WR, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

Nobby1805

Ich hatte wie gewünscht die eMail-Anfrage direkt am 23. März an ELV geschickt und es wurde mir auch eine Support-Nummer von eQ-3 mitgeteilt ... ich fände es sehr zielführend wenn sich alle mit diesem Problem bei ELV melden würden  ;)
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)

Deudi

Vielleicht sollte man mal das Problem von Wuppi68 schildern (2 Fensterkontakte gleichzeitig führen zum Reboot). Das ist doch ein schöner Testfall.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

Rampler

Zitat von: Nobby1805 am 14 April 2016, 17:09:18
Ich hatte wie gewünscht die eMail-Anfrage direkt am 23. März an ELV geschickt und es wurde mir auch eine Support-Nummer von eQ-3 mitgeteilt ... ich fände es sehr zielführend wenn sich alle mit diesem Problem bei ELV melden würden  ;)

Vielleicht kannst Du Deine Support Anfrage ja mal hier posten...
Dann können wir alle mit leichten Abwandlungen den gleichen Fehler melden, um dem so etwas mehr Nachdruck zu verleihen...
3 HMUART (2 via ESP8266), 1 DUOFERN, 12 ESP8266, SolvisBen, GoodWE WR, RPI2 (Bullseye), ZWAVE, HM-Classic, und hoch zufrieden ...
Danke an alle, die was dazu beigetragen haben !!

Nobby1805

Leider habe ich das direkt in die Supportmaske von ELV eingetragen ... mit der Hoffnung in der Bestätigungsmail oder im ELV-Forum den Text zu sehen ... aber dann kam zuerst nur der Hinweis doch die 0.965 zu installieren  >:( als ich dann darauf hingewiesen hatte, dass das Problem sowohl vor als auch nach 0.965 aufgetreten ist und daraus ja die Bitte von ELV geäußert wurde einen erneuten Call auf zu machen kam dann am 24.3.
Zitatvielen Dank für Ihre Anfrage in der technischen Kundenbetreuung und das damit verbundene Interesse an unseren Produkten. Wir haben Ihre Frage aufgrund der Komplexität an den Hersteller der Produkte eQ-3 AG weitergeleitet. Hier wird der Vorgang unter der Bearbeitungsnummer

EQ3_SUPPORT-409

geführt. Sobald wir weiterführende Informationen vom Hersteller erhalten, setzen wir uns mit Ihnen erneut in Verbindung. Bis dahin bitten wir Sie um etwas Geduld.

Sollten Sie weitere Fragen haben, stehen wir Ihnen montags bis freitags von 9 Uhr bis 19 Uhr unter nachfolgenden Kontaktdaten zur Verfügung.

   Deutschland   Österreich   Schweiz
Telefon   0491/6008-245   0662/627-310    061/8310-100
E-Mail   technik@elv.de   technik@elv.at   technik@elv.ch

Mit freundlichen Grüßen

ELV Elektronik AG
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)

rx

Ich teste immer noch eifrig und möchte kurz den Zwischenstand darstellen.

Ich habe den HMLAN-Adapter via Ethernet-Adapter USB an den Cubietruck gehängt. Dazu verwende ich das folgende Modell von Xiaomi:
http://www.gearbest.com/cables-connectors/pp_259718.html

Dadurch erreiche ich, dass das HMLAN-Interface direkt am Rechner hängt und kein Switch oder ähnliches dazwischen geschaltet ist.

Ein zweites HMLAN habe ich ja mittlerweile ich Einsatz, welches parallel an einem Raspberry PI hängt und nur lauscht. Bei diesem HMLAN habe ich keinen einzigen Reboot gehabt und mittlerweile eine Uptime von über 5 Tagen. Das lässt mich zu dem Schluss kommen, dass ein Reboot nicht an einem Paket hängt welches vom HMLAN empfangen wird, sondern eher an der anderen Richtung.

Das wird auch durch die Beobachtung gestärkt, dass das jeweils letzte Paket vor dem Reboot vom HMLAN ein "HMLAN_Send" ist.

Btw. habe ich natürlich auch das neue HMLAN-Interface im Echtbetrieb gehabt und dort die gleichen Reboots wie beim alten Interace, d.h. ein Hardware-Problem beim HMLAN ist auszuschließen.

Weitere Erkenntnisse folgen hoffentlich...

Server started with 1333 defined entities (fhem.pl:27302/2023-03-05 perl:5.028001 os:linux user:root pid:29591)