LAN-Funk Gateway HM-LGW-O-TW-W-EU verliert CCU2 Verbindung

[rhuebner]

Hallo,

im changelog hatte ich auch gelesen, dass es gefixt sein sollte.
Bei mir besteht das Problem aber weiterhin.

Aktuell am laufen ist die aktuellste Version 2.9.12, es sind statische IPs eingegeben, allerdings existiert das Problem auch ohne diese.

Als Switch kommt ein Netgear GS724T zum Einsatz.

[flo01]

Hallo Zusammen,

ich habe vermutlich das selbe Problem:
Sobald das Netzwerk zwischen CCU2 und Lan Gateway abreißt, findet die CCU2 das Gateway nicht mehr - schlimmer noch, die CCU2 verschickt/empfängt selbst über die integrierte Antenne keine Befehle mehr (vermutlich stürzt der RF Layer ab?).

Ich habe es für mich dadurch gelöst, dass ein Script das Log prüft und und bei einer spezifischen Meldung die Zentrale restartet.
Mein Netzwerk läuft relativ stabil, obwohl das Gateway auch über DLAN angeschlossen ist. Es geht mir hauptsächlich darum, ein unvorhergesehenes Ereignes abzudecken (Router restart, Stromausfall, etc.)


Wenn das Netzwerk getrennt wird, erscheint im Log (/var/log/messages) unverzüglich die Meldung:
Sep 5 09:51:26 homematic-ccu2 user.err rfd: LGWPortWrapper::keepAliveThreadFunction(): Did not receive reply on keepalive.
Es scheint also eine Art keepalive eingebaut zu sein.

Kurz darauf kommt folgende Meldung:
Sep 5 09:51:48 homematic-ccu2 user.err : Error setting rf-lgw info led

Sie erscheint zuverlässig wenn das LAN Gateway nicht erreicht werden kann.

Wird die Meldung gefunden fängt das Script an, die IP der Antenne zu pingen und macht einen Eintrag im Log. Sobald die Antenne wieder erreichbar ist, wird rebootet und ein entsprechender Eintrag im Log vermerkt.

Als minütlicher Cronjob eingeplant bekommt man über die Logeinträge auch eine ungefähre Idee, wie lange das Netzwerk zwischen CCU und Gateway gestört war.
Es erfolgt also keine unverzügliche Reaktion auf den Netzwerkausfall. Ich sehe es aber auch nicht zeitkritisch, da der Restart sowieso ein paar Minuten dauert.

Anbei das Script (es geht bestimmt eleganter... aber so etwas sollte ja auch vom Hersteller gelöst werden!)

#######################################
#!/bin/sh -e


adresse=192.168.1.128 #muss angepasst werden


file=/var/log/messages
date=`date +%Y-%m-%d:%H:%M:%S`

if [ -f $file ]
then

error=`grep "Error setting rf-lgw info led" $file`
result=$?

if [[ $result -eq 0 ]]; then

echo Fehlerzustand erkannt $date >> /usr/local/messages_error

UNREACHEABLE=1;
while [ $UNREACHEABLE -ne "0" ];
do ping -q -c 1 $adresse &> /dev/null; UNREACHEABLE=$?; sleep 1;
done

if [[ $UNREACHEABLE -eq 0 ]]; then
echo Going down for reboot in 30sec >> /usr/local/messages_error
reboot -d 30
fi
fi
fi
#######################################


Das Log sieht dann so aus:
#######################################
Fehlerzustand erkannt 2014-09-05:09:52:01
Fehlerzustand erkannt 2014-09-05:09:53:01
Going down for reboot in 30sec
#######################################

Natürlich ohne Gewähr.
Prüft vorher erstmal das Log auf o.g. Meldung, falls sie bei Euch öfter vorkommt kann das in einer Bootschleife enden.
Eventuell ist die Fehler-Meldung für das Wired Gateway eine andere.

Grüße
Flo

[Hulstenaar]

Ich bin verzweifelt. Habe das gleiche Problem. Jemand eine Idee? (sehe Logfile).

[inidona]

Hab ich auch, läuft deine ccu danach noch oder musst du die auch neu starten ? Bitte an elv melden weil die das bei mir als Einzelfall sehen

[Hulstenaar]

Ich muss also auch neu starten da nichts mehr geht.

[anli]

Leider kann ich das Problem bei mir nicht nachvollziehen - wenn ich beispielsweise ein Firmwareupdate meines Routers mache, findet die CCU die Gateways danach selbst wieder. Damit das Problem gelöst werden kann, müssen wir mal ein bisschen strukturiert Infos sammeln, die dem Hersteller helfen, das Problem nachzuvollziehen, den nur ein Problem was nachvollzogen werden kann läss sich vernünftig lösen.

Bitte gebt mal folgende Infos:

Firmware der Zentrale
Anzahl der Gateways (ich verwende im folgenden Einzahl, benötige die Infos jedoch für alle Gateways)
Firmware des Gateways
Ip-Adresse der Zentrale (dhcp oder fest?)
Ip-Adresse des Gateways (dhcp oder fest)
Topologie (bei mir ccu2---Switch---FritzBox 7490---Switch--- Gateway 1/2, alles über Ethernet-Kabel)
Ausfallszenario (nach Zeit, bei Trennung der Netzwerkverbindung...)
Log-Datei (Beispiel siehe oben)

Danke!

[Hulstenaar]

Danke für deine Reaktion.

Firmware der Zentrale: 2.9.12
Anzahl der Gateways: 2
Firmware des Gateways: keine Ahnung wie ich die herausfinde
Ip-Adresse der Zentrale (dhcp oder fest?): 192.168.1.33 (feste Zuordnung durch “Bind IP to MAC”)
Ip-Adresse des Gateways (dhcp oder fest): 192.168.1. 25 und 192.168.1.36 (feste Zuordnung durch “Bind IP to MAC”)
Topologie: CCU2-Switch-Vigor 2130n-Switch-Gateway 1+2 (alles ueber Ethernet-Kabel)

Ausfallszenario (nach Zeit, bei Trennung der Netzwerkverbindung...): fuer mich nicht nachvollziebar. Desto mehr Geraete ueber die Gateways laufen, desto oefter friert der CCU2 ein. Gestern hatte ich an die 20 von meine 33 Geraete ueber die Gateways leiten lassen mit hmcompanion und frierte der CCU2 jede halbe Stunde ein. Gesternabend die Gateways heraus genommen und bislang keine Stoerungen mehr (ausserhalb ab und zu kontaktverlust mit einige Geraete, war ja der Grund fuer die Gateways...)
Log-Datei: habe ich nochmals hoch geladen

[leknilk0815]

@anli:
ich kann mich nur wiederholen - warum versucht nicht einer von den Unixern mal, einen NIC- Treiber für die CCU zu finden, in dem man den Autosense- Mode auf 100MBit/full duplex umstellen kann? Oder ist diese Überlegung so abwegig?

[anli]

Firmware des Gateways: keine Ahnung wie ich die herausfinde

Mit dem Netfinder, bitte einfach einmal im Download-Bereich bei eQ3 suchen: http://www.eq-3.de/downloads.html

Interessant in Deinem Szenario ist während des nächsten Ausfalls auch, ob der rfd noch läuft. Kannst Du während des Ausfalls Dich einmal per SSH auf die CCU2 verbinden und mit

Code: Alles auswählen

ps -ef|grep rfd

nachsehen, ob der rfd noch läuft - die Ausgabe sieht dann so aus:

Code: Alles auswählen

  366 root     /bin/rfd -d -f /etc/config/rfd.conf -l 5
24529 root     grep rfd

(die Zahlen vorne weichen höchstwahrscheinlich ab, das ist normal).

@toni: Deinem Gedankengang kann ich noch nicht folgen. Was soll das für einen Vorteil haben?

[leknilk0815]

@toni: Deinem Gedankengang kann ich noch nicht folgen. Was soll das für einen Vorteil haben?

Servus,
ganz einfach - wir hatten früher mal erheblichen Ärger mit Cisco- Switchen und 3Com- NIC's.
Auf "Auto- Sense" liefen die Dinger zwar irgendwie, es gab aber immer wieder Abbrüche und Performance- Probleme.
Stellte man auf 100MBit/FD um, liefen sie weit besser.
Und - auf sämtlichen Servern war, auch aus Performance- Gründen, die Standardeinstellung immer 100MBit/FD.
Es ist sicher nur ein Versuch, aber wenn jemand hier "abwegig" sagen würde - was ist dann z.B. mit min 10m Netzwerkkabel, um eine CCU am Router betreiben zu können? Oder weißt Du, woran das liegt?
Deshalb könnte man das mal probieren. Wenn die CCU mit Windows laufen würde, hätte ich das längst getan...