Nachdem ich es nun innerhalb von 24h schon 2x geschafft habe, den RasPi irgendwie aus dem WLAN zu "schmeissen" und sich das Problem wg. fehlender anderer Zugriffsmöglichkeiten nur mittels Trennen der Stromversorgung beheben liess, überlege ich einen "Reboot"-Taster per GPIO zu realisieren wie beispielsweise hier beschrieben: https://alexbloggt.com/raspberry-pi-ausschalter/ (https://alexbloggt.com/raspberry-pi-ausschalter/)
(Ich habe nach dem ersten Mal ein Shell-Skript eingerichtet, das die WLAN-Verbindung neu aufbauen sollte, aber das hat offenbar nicht funktioniert, denn als das Problem erneut aufgetreten ist, hat es sich nicht wie erwartet "selbst repariert". Da FHEM weiterhin geloggt hat, weiss ich, dass der RasPi prinzipiell gelaufen ist.)
Jetzt habe ich eine dumme Frage bzgl. der Umsetzung des "Reboot-Tasters":
Wenn ich in der Linux-Shell shutdown oder restart eingebe und der RasPi dann neu startet, wird vorher FHEM "geordnet runtergefahren" wie wenn ich es vorher selbst mittels sudo /etc/init.d/fhem stop beende oder ist es in Bezug auf FHEM genauso wie wenn ich einfach die Spannungszufuhr trenne?
Wenn jemand eine bessere Lösung für mein "WLAN-Problem" hat, nehme ich es auch gerne... leider weiss ich noch nicht wie ich es geschafft habe die Verbindung 2x zu trennen, da ich während der Zeit nie zum RasPi verbunden war, sonst könnte ich auch dort ansetzen.
Nw. wenn Du fhem als Dienst (init.d oder systemd) installiert hast, sollte das Betriebsystem fhem whärend des reboot Vorgangs ordentlich stoppen.
Hi,
nur Kabel ist wahres ;D
Ja FHEM wird als Dienst ordentlich beendet. Kannst Du im Log leicht verfolgen wenn Du den Raspberry mal neu startest.
Gruß Otto
Ein Shutdown unter Linux beendet vorher alle Dienste über die Start-/Stop-Skripte bzw. systemd. FHEM wird also ordentlich beendet.
#!/bin/bash
#
##
PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin
HOST=`hostname`
if [ $(cat /sys/class/net/wlan0/carrier) = 0 ] || [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then
if [ $(cat /sys/class/net/wlan0/carrier) = 0 ]; then
ifup wlan0
echo "wlan0 Interface on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "wlan0 on $HOST is DOWN!!!" Email@gmail.com
exit 0
elif [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then
ifup vlan60
echo "Public Network vlan60 on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "vlan60 on $HOST is DOWN!!!" Email@gmail.com
exit 0
fi
fi
exit 0
Entweder durch cron alle 10min ausführen lassen oder mittels FHEM.
Zitat von: CoolTux am 02 November 2017, 21:47:07
#!/bin/bash
#
##
PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin
HOST=`hostname`
if [ $(cat /sys/class/net/wlan0/carrier) = 0 ] || [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then
if [ $(cat /sys/class/net/wlan0/carrier) = 0 ]; then
ifup wlan0
echo "wlan0 Interface on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "wlan0 on $HOST is DOWN!!!" Email@gmail.com
exit 0
elif [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then
ifup vlan60
echo "Public Network vlan60 on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "vlan60 on $HOST is DOWN!!!" Email@gmail.com
exit 0
fi
fi
exit 0
Entweder durch cron alle 10min ausführen lassen oder mittels FHEM.
Hm...
Mein Skript müsste ähnliches tun:
#!/bin/bash
# global variables
gateway="gateway"
interface="wlan0"
# Ping gateway for network status test
ping -c4 $gateway > /dev/null
# if gateway is not reachable, restart the network interface
if [ $? != 0 ]
then
ifdown $interface
sleep 3
ifup --force $interface
fi
Wenn ich das Skript direkt starte (bzw. mit "echos" debugge) und parallel dazu den RasPi "dauerpinge", sehe ich, dass die Schleife durchlaufen wird, sobald das Gateway nicht mehr erreichbar ist, und im Ping 2x ein paar Pakete ausfallen, d.h. die Verbindung offenbar neu gestartet wird.
Ich mag ja diese würgarounds, mit denen man sich nicht mehr um die Ursache kümmern muss, weil es damit ja irgendwie bis irgendwann funktioniert. :-\
Du hast sicher mal in die Glasgoogle geguckt und die diversen Hinweise dazu kontrolliert!?
Es kann natürlich auch ganz andere Ursachen haben, aber die "bekannten Probleme" kann man ja evtl. vorab testen und ausschließen.
Hier https://forum.fhem.de/index.php/topic,55161.0.html (https://forum.fhem.de/index.php/topic,55161.0.html) gibt es einiges bzgl. Energiesparmodus des WLAN.
Hallo TheTrumpeter,
was hast Du für einen Wlan Access Point?
Gruß Otto
Zitat von: Otto123 am 03 November 2017, 10:51:37
was hast Du für einen Wlan Access Point?
Verbunden ist der RasPi per WLAN mit einem Edimax Extender "irgendwas". Der wiederum ist per WLAN mit dem Pirelli-Modem verbunden.
Der Extender hat eine separate SSID. Anfangs hatte der dieselbe SSID, damit gab's massiv Probleme, sobald sich ein 2. Gerät am Extender angemeldet hat.
Seit der eigenen SSID lief es eigentlich absolut rund.
Im Pirelli-Modem blockiere ich den RasPi, damit er sich ins starke Signal vom Extender einwählt und nicht ins schwache Signal vom Modem.
Beide Ausfälle liefen wie folgt ab:
Ich habe versucht vom Handy aus über DDNS das Webinterface zu erreichen, als ich ebenfalls am Extender verbunden war. Nach einigen Sekunden, als ich merkte, dass es mal wieder nicht funkioniert (siehe separater Thread) habe ich das andere Tab mit interner IP-Adresse vom RasPi aktiviert und dort "neu laden" gedrückt. Das Webinterface wurde aufgebaut, aber bevor die Plots des entsprechenden Raums angezeigt wurden, blieb es "stecken".
Danach konnte ich den RasPi nicht mehr erreichen, weder per VNC, noch Ping. Später habe ich sowohl den Extender als auch das Modem neu gestartet, aber der RasPi wurde nirgends als "verbunden" angezeigt.
Beim ersten Ausfall lief der RasPi sicher schon 2 Monate durch, ohne jegliche Probleme. Der 2. Ausfall war nichtmal 24 Stunden nach dem ersten.
Bei unterschiedlicher SSID erübrigt sich doch ein Blocken, wenn Du einfach am PI nur 1x Zugangsdaten abspeicherst.
Sorry, aber weißt Du wirklich was Du da so konfiguriert hast bzw. musst?
Zitat von: Hollo am 03 November 2017, 23:06:06
Bei unterschiedlicher SSID erübrigt sich doch ein Blocken, wenn Du einfach am PI nur 1x Zugangsdaten abspeicherst.
Sorry, aber weißt Du wirklich was Du da so konfiguriert hast bzw. musst?
Das kommt daher, dass ich beide Zugänge konfiguriert habe, um bei Ausfall des Extenders mit dem (schwachen) Signal vom Router verbinden kann. Dann muss ich dort nur das Blocken aufheben und es müsste funktionieren.