ccu3 webui nach update nicht mehr erreichbar

[ibein]

Das Problem scheint weit verbreitet zu sein; ich habe hier in den letzten Wochen viele Threads mit diesem Fehler gelesen... bei mir ist dieser Fehler mit dem Aufkommen der neuen Sicherheits-Einstellungen/Firewall-Einstellungen seitens EQ-3 das erste Mal aufgetreten, so dass ich nicht mehr auf die WebUI komme! Seitdem immer wieder mal... es macht mich wahnsinnig, weil es mich viel Zeit kostet, das Problem wieder einzufangen!

Frage: habt ihr eine Fritz-Box?

Grund: im EG habe ich meine Raspberrymatic direct mit LAN-Kabel an der Fritz-Box. Hier komme ich gar nicht auf die WebUI; auf dem DB habe ich einen Buffallo-Router und einen Fritz-Repeater dazwischen. Hier komme ich auf die WebUI... zudem konnte ich beoabachten, dass beim Booten die Zentrale bis zu einem gewissen Punkt regulär hochfährt, d.h. rega, rfd, homeserver... alles startet scheinbar korrekt (mit angeschlossenem HDMI-Monitor). Sobald ich das erste Mal die IP der Zentrale aufrufe, fängt sie an zu blinken.

Meine Daten: feste IP in der Zentrale und auch in der Fritz-Box fix zugewiesen!

[jmaus]

Also das alles hier hört sich eher für mich nach generellen Netzwerkproblemen im LAN/WLAN an alsdass dies momentan auf ein Problem in RaspberryMatic selber hinweist.

Als erstes Mittel der Wahl sollte hier immer als erstes ein normaler "ping" versucht werden, und zwar von einem Gerät das mit einem LAN Anschluss am gleichen Netzwerksegment wie die RaspberryMatic/CCU angeschlossen ist. D.h. also einen Laptop mit LAN Kabel (NICHT WLAN!) an den selben Switch wie RaspberryMatic stecken. Wenn da ein Ping schon nicht funktioniert stimmt etwas mit den Netzwerkeinstellungen in der CCU nicht. Geht der Ping und kommt man dann über einen Webbrowser+IP Adresse auf die Zentrale stimmt alles in RaspberryMatic und man sollte dann in einem nächsten Schritt den Laptop mal an den WLAN Access Point stecken (wenn dieser mehr als ein LAN Kabel zulässt, wie z.B. eine fritzbox) und von dort aus via LAN Kabel probieren. Kommt man von dort dann komischerweise nicht mehr auf sein RaspberryMatic ist der Fehler hier zu suchen. Geht es jedoch mit einem LAN Kabel auch von dort kann man den Laptop mal ins WLAN nehmen und wenn es von dort nicht geht dann ist das Problem wohl auf der WLAN<>LAN Strecke zu suchen. Was man auch noch probieren könnte ist ob die FritzBox (wenn das der WLAN Router ist) selbst RaspberryMatic anpingen kann (da gibt es ein Webinterface für ein netzwerkping) und wenn ja dann stimmt auch die Verbindung prinzipiell. Alles in allem muss/sollte man da wirklich sehr systematisch und akribisch vorgehen um solche allgemeinen Netzwerkprobleme zu finden und aufzudecken. Auch ist es nicht selten das hier ggf. aus irgendwelchen gründe IPs fälschlicherweise doppelt vergeben worden und zwar auf einem switch die Verbindung geht aber dann switch übergreifend nicht weil dann eben das zweite gerät mit der selben IP-Adresse dazwischenfunkt.

[ibein]

Also vielen Dank für die Unterstützung, mit meinem Rechner (verdongeltes Firmen-Notebook) kam ich heute nicht weiter. Bringe morgen mein freies Projekt-Notebook mit, dann komme ich hoffentlich weiter. Für mein (einziger Rechner im Haus) privates MacBook Pro muss ich mir einen LAN-Adapter besorgen... alles suboptimal!

Der oben beschriebene Workaround mit Abziehen nach Booten hat bei mir nicht funktioniert, muss also weitersuchen!

[Sven_A]

Hm... hatte heute morgen festgestellt das die CCU (allerdings noch mit der Januar FW) im Netzwerk nichtmehr richtig erreichbar war. Ping ok, SSH und HTTP keine Antwort. Muss irgendwann gestern abend aufgetreten sein, nächtliche Statusübertragungen der Heizung, Mailversand,... lief nach 23 Uhr nicht mehr...
Funk, sowohl klassisch als auch IP, lief und Programme wurden ausgeführt (Rolläden hoch bei Fenster auf, WLAN an, Zirklationspumpe...).

Hatte aber keine Zeit heute morgen, ich hab dann neu gestartet (Stromlos). Ob das auch nur annähernd hiermit was zu tun hatte... keine Ahnung. Ist halt IT.

[dtp]

Frage: habt ihr eine Fritz-Box?

Ja, habe ich. Eine 6490 Cable. Die CCU3 läuft damit seit ihrem Kauf kurz nach Release einwandfrei und ist stets erreichbar.

Ich empfehle zusätzlich das aufmerksame Studieren dieses Threads.

[ibein]

Ich habe mein Problem gefunden: es war ein Konflikt zwischen Fritz-Box und der Zentrale! In beiden habe ich eine feste IP (jeweils identisch, mehrfach geprüft!) hinterlegt, beim Booten bekam sie trotzdem eine andere IP zugewiesen als eingetragen. Die Fritz-Box war aber laut Netzwerk-Übersicht fest der Meinung, dass die eingetragene, feste IP trotzdem die richtige ist. Auch im Netzwerk-Scan, den ich ausgeführt habe, tauchte die korrekte IP nicht auf, was mich im Nachhinein sehr wundert! Also habe ich zum Testen in der Zentrale die IP-Einstellungen auf DHCP eingestellt (also feste IP deaktiviert) und beim Neustart hatte sie plötzlich die .34 anstelle der in der Fritz-Box festgelegten .37... merkwürdig! Auch kann ich die Fritz-Box nicht überreden, die .37 zu übernehmen! Also ändere ich nun überall die IP der Zentrale auf .34... ärgerlich aber wenigstens läuft es nun korrekt!

[Loredo]

Ich habe ein ähnliches Phänomen. Folgendes konnte ich in Erfahrung bringen:

1. SSH ist ganz normal erreichbar, ich kann mich einloggen.
2. Der lighttpd Reverse Proxy bekommt wohl keine Verbindung zum ReGaHss Dienst.
3. Nach einem manuellen Neustart des lighttpd Prozesses via "/etc/init.d/S50lighttpd restart" läuft alles wie erwartet.

Meine Vermutung ist, dass die Startreihenfolge von ReGaHss und lighttpd nicht optimal ist. Derzeit wird lighttpd zuerst gestartet und wenn dieser eine Anfrage in Richtung ReGaHss weiterleitet bevor dieser gestartet ist, wird die Nichterreichbarkeit zwischengespeichert. Offenbar versucht es lighttpd jedoch nicht erneut, so dass nur ein Neustart des Prozesses Abhilfe schafft.