Raspberry Pi 2 bootet so schnell, dass FHEM Start verzögert werden muss

[fu_zhou]

Hallo zusammen,

ich nutze das S7 Modul von charlie71, FHEM kommuniziert damit über TCP/IP mit einer Siemens Simatic S7 SPS. Mein Raspberry PI B hat schön gemütlich gebootet und man konnte auf die FHEM Web-Oberfläche zugreifen, sobald FHEM gestartet war. Die Kommunikation zur S7 wurde gleich aufgebaut.

Jetzt habe ich auf einen Pi 2 umgestellt, der bootet wesentlich schneller, wahrscheinlich trägt die Class 10 SD Karte ihren Teil dazu bei. Die Konsequenz ist, dass, obwohl die S7 per Ping erreichbar ist, die FHEM Oberfläche für ca. 3 Minuten nicht reagiert. Im Log steht dann auch, dass das S7 Modul mehrfach versuchen muss, die Kommunikation zur S7 aufzubauen, bis es endlich klappt. So lange ist FHEM über den Browser nicht erreichbar.

Wenn ich in der /etc/init.d/fhem vor dem FHEM Start ein sleep 25 (=Sekunden) einbaue, ist die Weboberfläche von FHEM sofort nach dem Start (nach der Wartezeit) erreichbar und die Kommunikation mit der S7 ist aufgebaut. Die 25 Sekunden habe ich durch probieren für mein System herausgefunden. 20 Sek waren zu kurz.

Irgendwie scheint also das (Netzwerk-) System noch nicht voll da zu sein, wenn FHEM (ohne Wartezeit) startet, obwohl Ping schon funktioniert.

Mein RasPi 2 (wie der B vorher) hängt am LAN und WLAN (2 verschiedene Netze). Mit sleep 25 werden nach dem booten dann beide dynamischen IP Adressen gezeigt, ohne sleep 25 nur eine (die vom LAN). Die S7 hängt am WLAN und ist, wie schon geschrieben, per Ping schon während der Wartezeit erreichbar. Bei einem Kaltstart nach shutdown -h 0 langen die 25 Sekunden nicht, da wird dann nach der Wartezeit auch nur eine IP Adresse angezeigt und die FHEM-Oberfläche ist nicht erreichbar. Bei einem neuen reboot (Warmstart) langen dann die 25 Sekunden.

Mit statischen IP Adressen ist das Verhalten ähnlich, sleep kann dann etwas kürzer ausfallen.

Hat jemand ähnliche Erfahrungen gemacht, mit einem anderen TCP/IP Modul?

Grüße,

fu_zhou

[betateilchen]

Das hängt mit der (technisch bedingt) langwierigen Initialisierung der WLAN Hardware auf dem Raspberry zusammen.

Du kannst ggf. über die if-up.d Skripts steuern, dass Dein fhem erst gestartet wird, wenn alle Interfaces bereit sind.

[fu_zhou]

Hallo betateilchen,

meinst du, du kannst dabei unterstützen? Was ich verstanden habe ist, dass man unter /etc/network/if-up.d scripte ablegen kann. Wie sähe jetzt so ein Script aus, dass wlan0 und eth0 erst bereit sein muss, bevor FHEM startet?

Danke vorab und Gruß!

fu_zhou

[betateilchen]

ich hab hier zwei Links für Dich, von denen ich denke, sie helfen Dir bei dem Thema weiter:

http://stackoverflow.com/questions/20478516/how-to-detect-when-networking-initialized-in-etc-init-d-script

http://superuser.com/questions/695482/script-in-if-up-d-appears-to-be-running-3-times-only-want-it-to-run-once

[fu_zhou]

Hallo betateilchen,

verstehe ich den Inhalt aus dem ersten Link richtig, dass das fhem startscript aus "/etc/init.d" nach "/etc/network/if-up.d" verschoben werden muss? Oder mache ich mir ein script in "/etc/network/if-up.d" z.b. mit dem Namen "fhemstart", dass solange das Ausführen des fhem startscripts in "/etc/init.d" verzögert, bis eth0 und wlan0 voll verfügbar sind?

Werden scripts in "/etc/network/if-up.d" immer als erstes ausgeführt, oder muss man organisieren, dass zuerst das if-up.d script und dann das init.d script ausgeführt wird?

Elegant wäre es natürlich, genau solange zu warten, bis der WLAN Adapter zur Verfügung steht, dann funktioniert das beim Kalt- und Warmstart mit der minimal möglichen Zeit.

Auf der anderen Seite funktioniert auch sleep..., da sträuben sich dem passionierten Linux-User aber wahrscheinlich die Nackenhaare!