WLAN Geräteschnittstelle des FHEM-Servers überwachen?

Begonnen von Dracolein, 12 März 2020, 11:15:05

Vorheriges Thema - Nächstes Thema

Dracolein

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.

Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

frank

fhem server besser per lan an den router anbinden.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

KernSani

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
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Dracolein

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.
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

marvin78

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.

Dracolein

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.  :)
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

marvin78

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.

Dracolein

#7
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.



Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

marvin78

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.

Frank_Huber

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.

frank

und loggen über wlan plus dlan auf nas muss auch nicht sein.
warum nicht ausschliesslich dlan?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html


Dracolein

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.
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

Wernieman

#13
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 ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Prof. Dr. Peter Henning

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