Beendet Linux "reboot/shutdown" vorher FHEM "sauber"?

Begonnen von TheTrumpeter, 02 November 2017, 21:40:37

Vorheriges Thema - Nächstes Thema

TheTrumpeter

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/
(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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

amenomade

Nw. wenn Du fhem als Dienst (init.d oder systemd) installiert hast, sollte das Betriebsystem fhem whärend des reboot Vorgangs ordentlich stoppen.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

mahowi

Ein Shutdown unter Linux beendet vorher alle Dienste über die Start-/Stop-Skripte bzw. systemd. FHEM wird also ordentlich beendet.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

CoolTux


#!/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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Hollo

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 gibt es einiges bzgl. Energiesparmodus des WLAN.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Otto123

Hallo TheTrumpeter,

was hast Du für einen Wlan Access Point?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

Hollo

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?
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

TheTrumpeter

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.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110