[Gelöst]: Unerwünschte Schaltvorgänge bei System-Neustart (reboot) - BBB

[nexulm]

Möglicherweise habe ich ein ähnliches Thema nur übersehen, dann freue ich mich über einen Hinweis/Link!

Bei einem "reboot" meines BeagleBone Black verhält sich FHEM bei mir unerwartet.
Einige (nicht alle) Rolläden (mit HM-LC-Bl1PBU-FM) werden angesteuert und in die entgegengesetzte Richtung gefahren. Tagsüber bedeutet dies, die Rolläden werden geschlossen und Nachts, die Rolläden werden hoch gefahren.
Bei einem "shutdown restart" im FEMweb funktioniert alles reibungslos, d.h. die Rolladenaktoren werden NICHT angesteuert und entgegengesetzt hoch-/runtergefahren (= alles wie erwartet).

Wieso verhält FHEM sich so und wie kann ich dieses "Fehlverhalten" vermeiden?
Ein vorheriges abspeichern der Zustände in der fhem.save brachte nicht den erhofften Erfolg!

Gruss
Michael

[Rince]

Ich muss raten:

Eventuell liegt es daran, dass du bei einem Neustart des BBB die aktuelle Uhrzeit verlierst, und fhem daher denkt, es wäre finstere Nacht?
Wenn du dann fhem neu startest, stimmt die Uhrzeit, weil dein System sich mittlerweile synchronisiert hat?

[nexulm]

Eventuell liegt es daran, dass du bei einem Neustart des BBB die aktuelle Uhrzeit verlierst, und fhem daher denkt, es wäre finstere Nacht?
Wenn du dann fhem neu startest, stimmt die Uhrzeit, weil dein System sich mittlerweile synchronisiert hat?

Guter Hinweis, die Zeit des BBB wird erst per ntpdate aktualisiert sobald das Netzwerkinterface aktiv ist. FHEM wird möglicherweise bereits schneller gestart, wenn die Systemzeit noch nich aktualisiert wurde.

Welche Vorgehensweise wird denn hier von den Raspi und BBB Usern genutzt?
RTC einbauen oder FHEM verzögert nach z.B. 2min starten?

[Rince]

Du könntest in das fhem Startskript noch eine Zeitabfrage (und evtl. ein kurzes wait) einbauen?

[nexulm]

Du könntest in das fhem Startskript noch eine Zeitabfrage (und evtl. ein kurzes wait) einbauen?

Ich bin bisher davon ausgegangen, dass dieses Problem alle Einplatinen-User haben, da weder der Raspi noch das BBB automatisch eine Realtime-Clock besitzen und somit beim Systemstart keine gültige (aktuelle) Uhrzeit/Datum.
Bin nicht der Freund von "Rad neu erfinden" und dacht vielmehr, dass es "die" fertige Lösung längst gibt, da andere FHEM-User das gleiche Problem haben.

Wenn dem nicht so ist, werde ich ggf. das Startskript modifizieren oder eine andere Lösung suchen!

Danke nochmal für den Denkanstoss, was die Ursache für das Problem ist!

[Wernieman]

Du konntest dem Init-Script ein "Dependenci" eben nach der Netzwerkverbindung setzen.

So sollte ntpdat vor fhem starten.

P.S. Das könntest Du veröffentlichen, damit für alle das "Problem" gelöst ist.....

[LuckyDay]

das Thema ist gar nicht so einfach

in der fhem.pl gibts einen Eintrag , wenn die Uhrzeit, Datum 1970 ist startet fhem erst nach 2 std.
beim Cubietruck fängt das Datum bei 2010 irgendwo an.

ich seh nur die Möglichkeit einer Hardwareuhr mit Batterie gibst ja beim Chinamann für ca. 5 €

Beim Stromausfall hab ich eben immer das Problem, dass der Internetrouter sehr lange braucht. und wie lange will man denn warten um Fhem zu starten?

[nexulm]

das Thema ist gar nicht so einfach

in der fhem.pl gibts einen Eintrag , wenn die Uhrzeit, Datum 1970 ist startet fhem erst nach 2 std.
beim Cubietruck fängt das Datum bei 2010 irgendwo an.

ich seh nur die Möglichkeit einer Hardwareuhr mit Batterie gibst ja beim Chinamann für ca. 5 €

Beim Stromausfall hab ich eben immer das Problem, dass der Internetrouter sehr lange braucht. und wie lange will man denn warten um Fhem zu starten?

Deshalb scheint es im Forum noch nicht so verbreitet zu sein?
Ich habe eh schon diese Module hier seit Wochen/Monaten rumliegen:
http://www.elecrow.com/wiki/index.php?title=Tiny_RTC

Die RTC hat natürlich auch den Vorteil, dass ich unabhängig vom Internet bin, denn was ist, wenn es einen Stromausfall gibt und die Internetverbindung braucht noch länger bis sie wieder aufgebaut ist oder bleibt gar ganz weg.

Werde am WE dieses RTC-Module endlich einbauen und testen. Sobald ich eine zufriedenstellende Lösung/Umsetzung habe, werde ich wieder berichten.

[nexulm]

Hallo,

die RTC habe ich seit einigen Tagen laufen. Funktioniert soweit auch ganz ordentlich, nur das Problem ist damit nicht behoben.
Als ich heute Morgen testweise einen Reboot ausgelöst habe, sind min. 6 der bereits hochgefahrenen Rolladen wieder runtergefahren. Das unverständliche ist halt, dass einige aber auch oben blieben und nicht angesteuert wurden!?!

Daraufhin habe ich mir das Init-Script angeschaut und festgestellt, dass S01fhem vor dem rc.local im Startvorgang aufgerufen wird. In der rc.local habe ich wiederum die RTC Initialisierung und den Abgleich mit der Systemzeit. Nachdem ich S01fhem auf S99fhem (also ans Ende der Aufrufreihenfolge und damit nach rc.local) gelegt habe, zeigt sich leider trotzdem das oben beschriebene Verhalten.

Nun bleibt mir nur noch ein Test mit einer Zeitverzögerung, d.h. ich lasse das fhem Init-Skript z.B. erst nach 2/3 Minuten starten.
Aber ist das wirklich die Lösung und warum sollte nur ich dieses Problem haben!

Ist der Fehler möglicherweise an einer anderen Stelle begraben und welche Tipps habt ihr noch zur Fehlersuche. Ich möchte nicht noch länger den WAF gefährden und Suche dringend nach einer Lösung.

Danke + Gruss
Michael

[nexulm]

...meine nun funktionierende Lösung sieht wie folgt aus:

Deaktivierung vom FHEM Autostart per Default init-script (Debian Wheezy)

Code Auswählen Erweitern

update-rc.d fhem remove

Aktivierung der RTC Initialisierung und des automatischen FHEM Start beim Systemstart durch folgende Einträge in der rc.local vor "exit 0".

Code Auswählen Erweitern

ntpdate -b -s -u pool.ntp.org
if [ $? -ne 0 ];then
        echo Setting system time from Tiny RTC
        hwclock --rtc /dev/rtc1 -s
        hwclock --rtc /dev/rtc0 -w
else
        echo Updating Internet time on Tiny RTC
        hwclock --rtc /dev/rtc1 -w
fi

service fhem start