seltsames Verhalten nach FHEM-Neustart

[aga]

Mein Fhem wollte nach shutdown restart nicht mehr, also habe ich mein beaglebone durchgestartet.
Dann ging für ca. 15 minuten das Licht an und aus, Rolladen runter und wieder hoch, grosses Kino.

Im Event Monitor ist alles mögliche durchgerauscht, man konnte nicht mitlesen, so schnell.
Z. B. mein at für die Danfoss Thermostate war da ununterbrochen für Minuten zu sehen.

So als ob der alles abspult, was er je gemacht hat.
Das hatte ich schon einmal, hatte mich aber nicht weiter dran gestört, weil hinterher ging alles wieder.

Aber wenn das öfter passiert, dann ist das schlecht, ich würde gern wissen, was da läuft.

Mein Event Monitor rattert immer noch, das hier steht im Log von einem meiner Danfoss:

Code Auswählen Erweitern

2015-11-07_16:51:24 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_16:51:24 WZ_THERMOSTAT_Sued_id14 setpointTemp: setpoint 17 °
2015-11-07_16:51:24 WZ_THERMOSTAT_Sued_id14 ccsOverride: no, unused
2015-11-07_16:51:24 WZ_THERMOSTAT_Sued_id14 wakeup: notification
2015-11-07_16:51:24 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_16:51:25 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_16:51:25 WZ_THERMOSTAT_Sued_id14 battery: 87 %
.
.
.
2015-11-07_17:53:40 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_17:53:48 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_17:53:49 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_17:53:54 WZ_THERMOSTAT_Sued_id14 battery: 87 %
2015-11-07_17:53:55 WZ_THERMOSTAT_Sued_id14 battery: 87 %


Man beachte die Zeiten, das geht jetzt schon eine Stunde!

Ich trau mich nicht, noch einmal neu zu starten, dann geht der Zirkus womöglich von vorne los.

Hat einer eine Idee oder das Gleiche auch schon erlebt?

Gruß
Andreas

[aga]

Nachtrag
Ich habe die Geduld verloren und Fhem beendet und neu gestartet. Jetzt ist alles wieder normal.

Noch als Info, ich hatte ein update gemacht und anschliessend shutdown restart.
Lange gewartet, zumindest das Webinterface kam nicht wieder. Vielleicht lief ja doch was und das habe ich mit dem reboot abgeschossen.

Egal wie, das was ich oben beschrieben habe, sollte nicht passieren.
Wenn der BB oder Pi etc. mal unverhofft, warum auch immer, neu startet, dann sollte das nach dem Neustart wieder bedienbar sein.
In meinem Fall konnte man zwar alles bedienen, nur ging z. B. das Licht wieder aus, wenn man es angeschaltet hatte. Das musste man halt aussitzen, bis der Spuk vorbei war.

Vielleicht hat ja jemand eine Ahnung bzw. Erklärung, wie sowas zustande kommen kann.

Schönen Abend
Andreas

[aga]

Heute morgen war meine Batterie von besagtem Thermostat von 87 auf 79% runter, also war das wohl auch gut beschäftigt mit Ventil auf und zu.
D. h. die events waren nicht nur einfach im Monitor zu sehen, sondern da ist tatsächlich was passiert.

Wie kann nach einem Neustart so etwas passieren?
Ich habe oben schon geschrieben, das at für die Thermostate lief im Event Monitor gefühlt ewig durch.

Hat fhem eine history, woraus evtl. die Kommandos wiederholt werden könnten?

Was mir auffällt, die Sache mit den Thermostaten, das Licht und der Rolladen, die an/auf und aus/runter gegangen sind, sind alles at Befehle.

Was kann passieren, wenn der Rechner beim Neustart eine andere Zeit (nicht korrekte Zeit) hat?
Die Zeit wird auf jeden Fall über ntp aktualisiert, weiß nur nicht wie schnell das nach dem reboot passiert.
Vielleicht ist das ja eine Idee.

Mein Fhem läuft jetzt ca. 3 Monate und nach dem Start war ca.15 Minuten wildes Geschalte. Wie lange wird das dauern, wenn mein fhem 1 Jahr läuft??

Hat nicht doch jemand eine Erklärung?

Gruß
Andreas

[aga]

Weil das Problem bei meiner Installation weiter bestand, musste ich der Sache auf den Grund gehen.
Und habe herausgefunden, warum das das so war. Vielleicht hilft es ja jemandem, der mal solche Symptome hat.

Irgendwann hatte ich NTP konfiguriert, um die aktuelle Zeit von einem Zeitserver zu beziehen. Kann kein Fehler sein, dachte ich.
Die Probleme hatte ich damit nicht in Verbindung gebracht, weil so oft starte ich meinen Beaglebone nicht, deswegen war das nicht sofort danach aufgefallen.

Es ist so, dass fhem bei einem Neustart relativ früh gestartet wird, das eth0 interface ist aber erst ca. 30 Sekunden später "up", kann also erst dann die korrekte Zeit ermitteln.
Vor dem Aktualisieren der Uhrzeit stand das Datum bei mir auf 04.05.2014 glaube ich. Nachdem Datum und Uhrzeit aktualisiert war, ging das Spektakel los.
Ich kann nur mutmassen, dass fhem beim Start die Zeiten der at's berechnet und wenn sich dann das Datum ändert, holt fhem das auf, heisst z. B. wenn ich zwei at's habe , die morgends bzw. abends den Rolladen bei Sonnenauf-/untergang  hoch/runter fahren, dann wird das für jeden Tag der fast 2 Jahre einer nach dem anderen berechnet und ausgeführt, bis das aktuelle Datum erreicht ist. Meine at's sind relativ, also wäre das ja durchaus korrektes Verhalten, immer vom aktuellen Zeitpunkt ausgehend die nächste Zeit zu berechnen.
Aber in so einem Fall ist das ja eigentlich nicht gewollt und auch unnötig.

Weil ich erstmal keine bessere Lösung gefunden habe, habe ich das Startscript 30 Sekunden warten lassen, bevor fhem gestartet wird.

[viegener]

Meinem Verständnis nach ist ein weiteres Problem, dass ntp die Systemzeit nicht sprunghaft, sondern langsam anpasst. Vielleicht ist das die Erklärung für die vielen Aktionen?

Es gäbe die Möglichkeit, über die "fake hw-clock" dafür zu sorgen, dass der Rechner mit der Zeit wieder aufwacht, zu der er zuletzt aktiv war.

Ausserdem kann man per ntpdate dafür sorgen eine Erstsynchronisation beim boot stattfindet, allerdings dürfte das mit Deiner Netzwerkkonfiguration nicht passen, wenn das Netzwerk beim reboot nicht frühzeitig verfügbar ist.

Bei mir war nach dem Restart die Uhrzeit auf 1.1.1970, das findet zwar Linux nicht so toll, aber FHEM verzögert den Start dann bis eine Uhrzeit vorliegt.