Hallo zusammen,
mir ist heute Nacht aus noch nicht näher bekannten Gründen die W-LAN Verbindung am Raspberry-Pi zusammengebrochen, auf dem mein FHEM Server läuft. Ich vermute als Ursache den Access-Point, mit dem sich der Raspberry normalerweise verbindet, aber hatte noch keine Zeit näher nachzuforschen.
Jedenfalls ist dadurch FHEM mehr oder weniger durcheinander gekommen (Logfiles liegen auf dem NAS, Verbindung zu Livecams verloren, Verbindung zu ESP8266 verloren etc. pp.) und heute morgen war zumindest die grafische Oberfläche samt Browser komplett abgestürzt. Das Logfile ist voller Timeout-Einträge aller möglichen Devices. Für nähere Analysen fehlte mir ebenfalls bisher die Zeit. Ich sah nur, dass um exakt 04:01 Uhr heute früh die erste Fehlermeldung erschien. Eine Verbindung zum Raspi heute morgen konnte ich nur händisch wiederherstellen, indem ich eine alternatives W-LAN ausgewählt habe.
Ebenfalls für mich als Laie fragwürdig war der Fakt, dass ich FHEMWEB lokal am Gerät mit Tastatur & Maus nicht aufrufen konnte; es wurde nicht gefunden. Erst mit einer funktionierenden W-LAN Schnittstelle und anschließendem Neustart erhielt ich wieder Zugriff.
Aus dieser Erfahrung heraus resultiert folgende Frage:
Gibt es ggf. Möglichkeiten, aus FHEM heraus die Netzwerkverbindung auf Funktion zu überprüfen, um somit z.B. bei Verbindungsverlust diverse Devices automatisiert zu deaktivieren, damit FHEM selbst arbeitsfähig bleibt?
Zur Erläuterung: die hardwareseitige Funktion meine ich gar nicht mal, sondern z.B. einen automatisierten, zyklisch wiederkehrenden Test (z.B. Ping xxx.xxx.xxx.xxx ) ob die Verbindung tatsächlich noch besteht. Hardwareseitig war die W-LAN Schnittstelle heute morgen ON und zeigte auch eine angeblich aktive Verbindung an. Tatsächlich jedoch war von keiner Seite eine Verbindung möglich.
fhem server besser per lan an den router anbinden.
Fraglich, ob es zielführend ist, dass du irgendwas anpingst (sollte dann zumindest ein kabelgebundenes Gerät sein). Dafür gibt es PRESENCE.
Lass mich raten, der AP ist ein Fritz Mesh Repeater?
Gesendet von iPhone mit Tapatalk
Zitat von: frank am 12 März 2020, 12:13:07
fhem server besser per lan an den router anbinden.
Das ist mir bewusst, ist jedoch technisch nicht umsetzbar bei mir.
Der AP ist ein DLAN-Modul aus dem Hause Devolo, was zumindest die letzten 3 Monate problemlos funktionierte, aber auch nicht meine favorisierte Lösung darstellt.
Eventuell breitest du mal etwas mehr über die technischen Probleme aus, die eine kabelgebundene Anbindung scheitern lassen. Es gibt nicht viele Gründe dafür. Deshalb kann man dir hier ggf. helfen.
Zitat von: marvin78 am 12 März 2020, 13:31:24
Eventuell breitest du mal etwas mehr über die technischen Probleme aus, die eine kabelgebundene Anbindung scheitern lassen. Es gibt nicht viele Gründe dafür. Deshalb kann man dir hier ggf. helfen.
Selbstverständlich kann ich zusätzliche Hardware kaufen und die Wände aufstämmen, um Leitungen zu legen, wenn ich das wollte. Ich bitte höflichst darum, diesen Punkt nicht weiter zu diskutieren, weil es schlicht in meiner Konfiguration mit den vorhandenen Geräten _nicht_ möglich ist aus o.g. Gründen. :)
Wo sind die Gründe denn? Ich habe keine gefunden.
Warum kann dein Pi nicht kabelgebunden neben dem Router stehen?
Ich habe nichts von Wände aufstemmen geschrieben.
Darf ich fragen, weshalb das für meine Frage im 1. Posting relevant ist, wenn ich bereits deutlichst auf die Nicht-Machbarkeit bzw. meinen Unwillen zur Hardwareänderung hingewiesen habe?
Du kannst keine Gründe finden, weil ich sie nicht genannt habe, da das Wissen darüber an meinen Fakten nichts ändert. ::)
Andere Hardware und Kabel in die Wände wird es nicht geben bei mir. Dass dies eine sub-optimale Lösung darstellt, ist mir völlig klar, aber darum geht es in diesem Thread nicht.
Ich hatte auf Hinweise gehofft, dass es für solche Ideen vielleicht schon Lösungen gibt o.ä, mehr nicht.
Dennoch bittesehr, wenn es Dir hilft:
Am Raspberry-Pi hängt ein 15" Touchdisplay, was mein FTUI Dashboard beinhaltet und ist gleichzeitig mit dem ConBee II USB Stick so positioniert, dass ZigBee Sensoren aus dem Keller, dem Garten und sogar dem 2. Obergeschoss noch eine Verbindung ermöglichen. Das Ding steht an einer Wand mitten im Haus, wo das Dashboard seinen sinnvollsten Nutzen hat und optisch gut aussieht.
edit:
siehe (altes) Foto, sagt mehr als Worte ;)
Der Mangel an defakto nicht vorhandenen LAN-Kabeln nervt mich an einigen Stellen auch abseits von FHEM. Aber das lässt sich leider nicht ohne irrsinnigen Aufwand ändern, damit habe ich mich abgefunden.
Natürlich ist das relevant. In der Regel werden nicht alle Möglichkeiten in Betracht gezogen. Dass es gewisse "Fakten" gibt, heißt nicht, dass diese nicht durch nicht bedachtes ausgehebelt werden können. Für eine Problemlösung gehört immer alles auf den Tisch. Wenn man Dinge für sich behält, erhält man nur selten die optimale Lösung des Problems. Aber da du nicht an einer effizienten Lösung interessiert ist, muss mich das nicht weiter kümmern.
Das erste wäre mal das prüfen des DNSServer Attributs in FHEM. Ist dies nicht gesetzt kann FHEM blockieren wenn kein Netz da ist.
Ein weiterer Ansatz wäre evtl eine USB-Wlan Karte mit "besserer" Antenne.
und loggen über wlan plus dlan auf nas muss auch nicht sein.
warum nicht ausschliesslich dlan?
schau dir auch mal das hier an:
https://forum-raspberrypi.de/forum/thread/45828-seit-migration-auf-buster-bei-raspi-3-deaktiviert-sich-wlan-nach-langer-nichtnut/
Erstmal danke für sachliches Feedback. :-*
Zitat von: Frank_Huber am 12 März 2020, 14:16:46
Das erste wäre mal das prüfen des DNSServer Attributs in FHEM. Ist dies nicht gesetzt kann FHEM blockieren wenn kein Netz da ist.
Interessant, habe im Wiki was gefunden ( https://wiki.fhem.de/wiki/Global#dnsServer ), werde ich ausprobieren.
Zitat von: Frank_Huber am 12 März 2020, 14:16:46
Ein weiterer Ansatz wäre evtl eine USB-Wlan Karte mit "besserer" Antenne.
Die Drahtlosqualität ist nicht das Problem, der Empfangsstärke ist hervorragend. Wie gesagt, bin ich recht sicher, dass nicht der Raspi Schuld trägt, sondern das DLAN-Modul. Ich hatte heute früh keine Zeit, die anderen Geräte zu checken, die ebenfalls diesen AP nutzen.
Zitat von: frank am 12 März 2020, 15:13:40
warum nicht ausschliesslich dlan?
a) weil das DLAN Modul ein riesiger Klotz ist und sich (siehe Bild) nicht verstecken lässt (sitzt abseits an anderer Wand im Raum)
b) weil die DLAN Sende- und Empfangsleistung an diesem Stromkreis (habs probiert) unterirdisch schlecht ist im Vergleich zu anderen Steckdosen in der Etage
Zitat von: Frank_Huber am 12 März 2020, 15:19:48
schau dir auch mal das hier an:
https://forum-raspberrypi.de/forum/thread/45828-seit-migration-auf-buster-bei-raspi-3-deaktiviert-sich-wlan-nach-langer-nichtnut/
Habs überflogen, aber da die Schnittstelle durch FHEM im 60 Sekunden Takt genutzt wird, sollte das kein Problem darstellen.
Davon ab, meine Konfiguration im Hinblick auf Netzwerkanbindung lief seit Dezember unauffällig und problemfrei.
Dein Problem ist schon, das Du einen Pi als Anzeige UND FHEM verwendest .... ich würde Dir dort dringend eine Trennung empfehlen. Also den FHEM-Server ohne GUI ....
Hier in der Firma z.B. werden die "Monitoring" PIs, welche eigentlich nur einen Browser haben, mindestens 1mal die Woche automatisch (cron) rebootet. Habe noch keinen Browser ohne Memory-Probleme im Langzeitbetrieb kennengelernt. Ein FHEM-Server (auch als Pi) sollte aber durchaus viel länger durchhalten ... ohne automatisches reboot.
Ansonsten könntest Du per script gucken, ob WLAN enabled ... ist durchaus möglich.
Btw:
Welche Pi WLAN-Schnitstelle? Die interne?
Die ist als Problematisch bekannt ...
Edit:
Obiges wurde von Dir beantwortet, aber wie schon geschrieben, die Probleme der internen WLAN Schnittelle des Pis liegen nicht an der Empfangsstärke .. da haben schon Linux-Freaks in meinem Bekanntenkreis sich erfolglos versucht ...
Erstens ist es bekannt, dass Power-LAN (vulgo DLAN) ab und zu genau diese Probleme produziert: Abbrüche, hohe Latenzen etc. Aus dem Grund habe ich immer wieder Probleme mit meiner DoorPi-Lösung.
Zweitens ist ein besserer WLAN-Adapter nicht einfach durch "mehr Power" oder "höhere Empfindlichkeit" bestimmt, sondern durch das Verbindungsmanagement. Beispiele: https://www.wlan-shop24.de/alfa-networks-awus1900-wlan-usb-adapter, https://www.amazon.de/300Mbit-WLAN-Adapter-Hochleistungs-Antennen-Dual-Band/dp/B00LLIOT34
Drittens kann man die WLAN-Schnittstelle problemlos mit dem internen Watchdog des Raspberry Pi überwachen.
LG
pah
Guten Morgen zusammen,
ich hoffe alle sind weiterhin gesund, das ist derzeit das wichtigste. :-\
Zitat von: Wernieman am 12 März 2020, 15:32:42
Dein Problem ist schon, das Du einen Pi als Anzeige UND FHEM verwendest .... ich würde Dir dort dringend eine Trennung empfehlen. Also den FHEM-Server ohne GUI ....
Den Hinweis habe ich schon oft gelesen, möchte ihn aber nicht befolgen.
Mir fällt die Bedienung über Terminaleingaben als Laie (in diesem Sektor) äusserst schwer. Weiterhin nutze ich hin und wieder die deCONZ GUI, um meine ZigBee Komponenten zu überprüfen.
Letztlich arbeite ich sogar gelegentlich per VNC Remotedesktop auf dem Ding um per Editor an den HTML-Files zu schrauben.
Ich nehme Dein Hinweis ernst, behaupte auch nicht, dass Du unrecht damit hast, aber ich persönlich kann derzeit noch keine Probleme bei mir feststellen. Zumal mein Raspi eine CPU Auslastung zwischen 10-25% hat, die nur so "hoch" ist wegen Chromium und der gleichzeitigen Darstellung zweiter Livestreams (ohne aktives Touch UI liegt die CPU Last bei <5%)
Zitat von: Wernieman am 12 März 2020, 15:32:42
Hier in der Firma z.B. werden die "Monitoring" PIs, welche eigentlich nur einen Browser haben, mindestens 1mal die Woche automatisch (cron) rebootet. Habe noch keinen Browser ohne Memory-Probleme im Langzeitbetrieb kennengelernt. Ein FHEM-Server (auch als Pi) sollte aber durchaus viel länger durchhalten ... ohne automatisches reboot.
Da ich seit Projektbeginn im Dezember immer noch hin und wieder am basteln bin, lief mein System bisher nicht länger als 4 Wochen ohne Reboot. Den Browser habe ich zwischendurch 1-3x manuell die Seite neu laden lassen.
Zitat von: Wernieman am 12 März 2020, 15:32:42
Btw:
Welche Pi WLAN-Schnitstelle? Die interne?
Die ist als Problematisch bekannt ...
Ja die interne W-LAN Schnittstelle ist in Benutzung.
Auch beim Pi 4 noch ein Problem? Ich hatte lediglich von PI2 mal mit Problemen gelesen...
Zitat von: Prof. Dr. Peter Henning am 12 März 2020, 17:58:35
Erstens ist es bekannt, dass Power-LAN (vulgo DLAN) ab und zu genau diese Probleme produziert: Abbrüche, hohe Latenzen etc. Aus dem Grund habe ich immer wieder Probleme mit meiner DoorPi-Lösung.
Ich mache mir schon länger Gedanken über die Optimierung meiner Netzwerk Infrastruktur im Haus. Aber leider gefällt mir bisher keine Lösung, da alles mit baulich aufwändigen Maßnahmen verbunden ist. Wahrscheinlich ist mein persönlicher Leidensdruck einfach noch nicht hoch genug. Ich überlege derzeit, den vorhandenen Versorgungsschacht im Haus, der durch alle Etagen verläuft, aufzubrechen und wenigstens in jede Etage ein Netzwerkkabel reinzulegen, um dort einen wireless AP zu verbauen. Dann hätte ich wenigstens die Möglichkeit, ein vernünftiges wireless Mesh Netzwerk aufzubauen und könnte den D-LAN Krempel größtenteils rauswerfen (wobei zwei Außenkameras seit Jahren draußen kabelgebunden über PowerLAN angeklemmt sind und meine Diskstation so gut wie keine Verbindungsabbrüche meldet...)
Zitat von: Prof. Dr. Peter Henning am 12 März 2020, 17:58:35
Zweitens ist ein besserer WLAN-Adapter nicht einfach durch "mehr Power" oder "höhere Empfindlichkeit" bestimmt, sondern durch das Verbindungsmanagement. Beispiele: https://www.wlan-shop24.de/alfa-networks-awus1900-wlan-usb-adapter, https://www.amazon.de/300Mbit-WLAN-Adapter-Hochleistungs-Antennen-Dual-Band/dp/B00LLIOT34
Ich glaube, die Maßnahme von Euch werde ich befolgen und zunächst die interne W-LAN Schnittstelle des Raspi durch eins der genannten externen Module ersetzen.
Erstmal ein schönes Wochenende später und auf dass wir nächste Woche noch arbeiten dürfen ::) #corona ::)
Zitat von: Dracolein am 13 März 2020, 09:35:15
Wahrscheinlich ist mein persönlicher Leidensdruck einfach noch nicht hoch genug. Ich überlege derzeit, den vorhandenen Versorgungsschacht im Haus, der durch alle Etagen verläuft, aufzubrechen und wenigstens in jede Etage ein Netzwerkkabel reinzulegen, um dort einen wireless AP zu verbauen. Dann hätte ich wenigstens die Möglichkeit, ein vernünftiges wireless Mesh Netzwerk aufzubauen und könnte
APs über Kabel am Router angeschlossen und dann Wireless Mesh Netzwerk??
Das ist für mich ein Widerspruch in sich.
Außerdem würde ich aus meiner, wenn auch nur kurzen Erfahrung mit Mesh, davon die Finger lassen. Egal von welchem Hersteller.
Ein provisorisch über Mesh angeklemmter Repeater hat mein ganzes WLan still gelegt :-<<
Ok, war von AVM, aber mir hat es gereicht.
Meiner Meinung nach ist die Fragestellung falsch. Fhem läuft auch ohne Netzwerk. Ich empfehle die Ursache des Absturz zu suchen und zu beseitigen anstelle der Bastelei an den Symptomen.
Ich hatte heute Gelegenheit etwas intensivere Nachforschungen anzustellen.
Tatsächlich war der FHEM-Server nicht abgestürzt, wie ich vorgestern zunächst dachte. Das Problem scheint tatsächlich die interne W-LAN Schnittstelle zu sein, denn andere verbundene Geräte hatten zum gleichen Zeitpunkt keine Probleme.
Heute beim "Reparieren" bekam ich erneut Schwierigkeiten mit selbiger Schnittstelle. Ich war partout nicht in der Lage, eine funktionale Verbindung zu diesem DLAN-Punkt zu ermöglichen. Zwar wurde die Verbindung als "online" angezeigt, jedoch war aus Sicht des Raspi weder von raus noch rein eine Verbindung möglich, sprich defakto nicht in Ordnung. Ein anderer AP wurde problemlos verbunden, sehr merkwürdig.
Kurzum habe ich den PowerLAN Adapter an eine andere Position gebaut, ein langes Netzwerkkabel organisiert, die eth0 Schnittstelle am Raspi konfiguriert und den Kram miteinander verbunden. Das System läuft nun erstmal wieder wie gewohnt und ich werde die nächsten Tage dessen Zuverlässigkeit beobachten. D.h. "Wireless" ist jetzt aus Sicht des Raspi gar nichts mehr, weil alles kabelgebunden zum PowerLAN Adapter läuft.
Wenn alles wie erwartet stabil läuft, kommt die Bohrmaschine dann doch zum Einsatz ::)