****GELÖST*****plötzlich alle HMLAN disconnect ????

[Otto123]

Ist so einfach!
Steht alles im Wiki! IODev musst Du nicht ändern wird ignoriert. IOgrp musst Du einrichten, steht auch im Wiki.

Bloß weil Du ein Problem mit HMLAN hast, ist es nicht unbedingt für die Tonne. Ich habe seit Jahren null Probleme mit HMLAN.

Gruß Otto

[Nobby1805]

Ich weise mal wieder darauf hin, dass man unterscheiden muss ob es Disconnects sind die z.B. durch Timeouts im Fhem entstehen oder ob der HMLAN gebootet hat (das kann man sehr schnell an der Uptime des HMLAN sehen) was dann in der Folge zu dem Disconnect führt.

Gründe für den Reboot gibt es wohl einige ... eQ3 hatte aufgrund von LAN-Sniffs bei mir (mindestens) einen Fehler gefunden ... jetzt warten wir aber schon ewig auf die Veröffentlichung der neuen Version

[bugster_de]

Hi,

Status: heute Nacht gab es keine disconnects mehr. Logfile war clean heute morgen. Die disconnects haben gegen 23:30h aufgehört. Ich habe gegen 0:30h meinen PC runter gefahren, sprich ich war noch bei uns im Haus im LAN aktiv.

VCCU: habe mir das Wiki noch min 5 mal durch gelesen und dann das umgesetzt, was ich davon glaubte verstanden zu haben. Sprich bei jedem HM Device habe ich die IOGrp und das IODev auf die VCCU umgestellt. Dauert dann pro device ca 1 Min, bis es wieder reagiert, aber dann geht es. Danke für eure Geduld ! Ich glaube ich habe das jetzt so alles richtig auf VCCU umgestellt.

Ist so einfach!

Stimmt. Und es beweist sich mal wieder: kaum macht man's richtig tut's auch schon

Ich weise mal wieder darauf hin, dass man unterscheiden muss ob es Disconnects sind die z.B. durch Timeouts im Fhem entstehen oder ob der HMLAN gebootet hat (das kann man sehr schnell an der Uptime des HMLAN sehen) was dann in der Folge zu dem Disconnect führt.

Stimmt. Ich mache mir heute abend mal ein FileLog, der die Uptime loggt, denn weder apptime noch der Eventmonitor haben Hinweise auf einen Timeout auf FHEM Seiten geliefert.
Weiterer Grund kann natürlich auch am Netzwerk liegen (Auslastung / Überlastung), oder?

Mülltonne: da habe ich mehrere Anmerkungen / Gründe dafür
- mein Homematic scheint so eine Art telepathische Angewohnheit zu haben: immer wenn es am besten einfach funktionieren sollte (weil z.B. Weihnachten ist und wir die ganze Familie im Haus haben) oder ich z.B. wegen Geschäftsreise nicht zu Hause bin, dann tritt der Effekt mit den disconnects auf. Der WAF sinkt dadurch erheblich
- wie programmiert man eine Firmware, die bei Empfangen von neuen Funk-Messages (HM Ip) sich resettet? Ein Feature wird das wohl eher nicht sein, oder? Mein Bauchgefühl zur Qualität der HM Firmware sagt mir da nix Gutes. Und wie soll Otto-Normalanwender als Käufer von Homematic Geräten denn auf sowas kommen? Wir hier im Forum sind mit FHEM ja durch die Natur der Sache näher an der Technik aber Lieschen Müller wäre bei so einem Effekt doch komplett verloren. Und ohne eure Hilfe würde ich mir ebenfalls den Wolf suchen.
- die Qualität mancher HM Geräte ist doch "schwankend". Ich habe nun z.B. den zweiten, defekten Aussentemp Sensor (HM-WDS30-TO). Der erste war nach einem Jahr (!) innen drin komplett vergammelt, da es keinerlei Entlüftung gibt und sich somit Kondenswasser bildet und die Antenne einfach abrostet. Den zweiten habe ich dann mit einer kleinen Neopren Entlüftung versehen und mit Gussmasse verfüllt. der ist letzte Woche einfach so gestorben und lässt sich nicht mehr zum Leben erwecken. Ich habe nun bereits drei Rolladne-Unterputz Aktoren neu gekauft, da die bestehenden Geräte nach ca. 9 Monaten dauernd nicht mehr erreichbar waren. Neue gekauft gut ist. Andere Geräte laufen seit Jahren mit immer noch dem ersten Satz Batterien einwandfrei.
- last but not least werde ich bei HM immer den Eindruck nicht los, dass das von Ingenieuren für Ingenieure ist (bin selber einer) und wir Ing. haben ja oftmals die unschöne Angewohnheit dass wir einen Fachbegriff mit einem anderen Fachbegriff erklären. Eigentlich will ich ja nur meine Rolläden hoch und runter fahren und, Achtung Ironie, nicht auf dem Thema "HM Systemarchitektur" promovieren

Hilft aber alles nix: die Alternativen haben alle noch mehr Nachteile (z.B. keinen Rückkanal) und Kabelgebundene Anbindung habe ich bei mir im Haus halt nicht. Sprich ich fuchse mich da halt weiter rein.

jetzt warten wir aber schon ewig auf die Veröffentlichung der neuen Version

siehe meine Anmerkung zur Qualität der Firmware

[Otto123]

Hi,

Sprich bei jedem HM Device habe ich die IOGrp und das IODev auf die VCCU umgestellt.

wie schon gesagt ->

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

Da muss man nix tun.

Der folgende Befehl macht es relativ einfach und eine 1 minütige nicht Reaktion habe ich bei mir nicht gemerkt

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCU
Man muss nur die 6 Punkte verstehen  was mir als nicht regExp(erte) nicht auf Anhieb gelang.

Jetzt wo Du eine VCCU hast kannst Du doch einfach einen zweiten IO dazu tun, das mit der Firmware wird sowieso nix mehr, der HMLAN ist "durch" und die Firmware trug nie eine 1 

Gruß Otto

[bugster_de]

Man muss nur die 6 Punkte verstehen  was mir als nicht regExp(erte) nicht auf Anhieb gelang.

die drei Punkte waren so ziemlich das Einzige, was ich in dem WIKI Artikel auf Anhieb verstanden hatte

jetzt wo Du eine VCCU hast kannst Du doch einfach einen zweiten IO dazu tun,

ist schon bestellt Great minds think alike

[Nobby1805]

Weiterer Grund kann natürlich auch am Netzwerk liegen (Auslastung / Überlastung), oder?

Ein bekanntes Problem sind Multicasts di z.B. beim IP-TV verwendet werden ... bei den von mir gesnifften Problemen war es ein Timingproblem wo der HMLAN auf dem LAN auf etwas von der Zentrale, also Fhem, wartete und dann ein anderes Paket dazwischen kam wodurch der HMLAN abstürzte

[bugster_de]

soderle
1. kein disconnetc seit 23:30h letzte Nacht. Also fast 24h !
2. Uptime zeigt bereits 27h an. Also auch kein reset

Sieht mal sehr gut aus.

Ein bekanntes Problem sind Multicasts di z.B. beim IP-TV verwendet werden

naja, dann wäre ich aber ganz vorne dabei. Wir schauen seit Jahren nur noch per IPTV (TVHeadend Server im Keller und KODIs and den TVs); da ist es nicht so selten, dass auf bis zu drei Geräten TV geschaut wird. Hatte ich bisher keine Probleme

[Nobby1805]

Wir schauen seit Jahren nur noch per IPTV (TVHeadend Server im Keller und KODIs and den TVs); da ist es nicht so selten, dass auf bis zu drei Geräten TV geschaut wird. Hatte ich bisher keine Probleme

Dann hast du vermutlich einen Switch, der Multicasts richtig handelt und IGMP richtig unterstützt ... nach Austausch eines Switches ging bei mir die Rebootrate von ca. alle 5 Minuten (aber nicht 24 h am Tag sondern nur zu bestimmten Zeiten) auf alle paar Wochen mal zurück.

[bugster_de]

ja, bei dem zentralen Switch habe ich mich nicht Lumpen lassen. Ist ein Semi-Profi, managable switch mit 16 Ports. Bringt mir ja nichts, wenn ich schon den Aufwand mache im Haus Ethernet Kabel zu verlegen und dann mit einem 10,- € Switch vom Elektronik-Discounter wieder alles zu Nichte mache. Ehrlicherweise hatte ich mich aber nicht damit beschäftigt, ob der Switch das nun alles richtig kann sondern habe mich eher auf das Prinzip "höherer Preis wird schon auch besser sein" verlassen
Interessanterweise hatte aber wohl die Fritzbox bei den Versionsnummer 5.x der FW einige Probleme mit Multicast vorallem ins WLAN. Ist aber seit den >V6.2 Versionen auch alles gut.

[bugster_de]

Hallo Leute,

ich wollte mal kurz den Stand der Dinge berichten:
- ich habe mir jetzt zwei Funk-LAN Gateways zugelegt. Einen für OG, einen für EG
- ich habe wie hier beschrieben alles auf eine VCCU umgestellt

Das Ding läuft jetzt seit Wochen wie geschnitten Brot. Keine disconnects, alles gut ! Sogar die Rollaend Aktoren, die im Laufe der Zeit immer wieder Probleme mit MISSING ACK hatten laufen einfach durch.

Danke für die Tips hier !