at-Timer laufen nach Reboot Amok

[Carsten]

Genau. Deshalb verstehe ich Dein Problem auch nicht. Bei sauberem shutdown existiert das beschriebene Problem nur nach längeren FHEM-Stillstandszeiten. Wurde FHEM vielleicht nicht ordentlich beendet(=keine aktuelle fhem.save) ?

Wie gesagt: Ich habe beim Testen ja explizit noch vorher gesaved und später sogar noch explizit ein shtutdown von FHEM vor dem Shutdown vom Host gemacht. Immer mit demselben Effekt.

Bei einem relativen Timer, sollte das Modul vom aktuellen Zeitpunkt ausgehen, um den nächsten Trigger zu berechnen.

Davon bin ich auch ausgegangen. Und bis vor ein paar Wochen ist mir dieses Verhalten auch nie aufgefallen. Das muss allerdings nicht heißen, dass es dieses Verhalten nicht gab, aber die Effekte sind schon recht auffällig, denn einer der Timer fragt alle 10 Minuten den aktuellen Zählerstand einer Z-Wave-Steckdose ab, was dazu führt, dass mehrere tausend Z-Wave-cmds in der Queue landen.

Warum dem pi (ob jetzt banana oder raspberry is egal) nicht für 1,50 inkl Versand nen RTC Chip spendieren?
Damit hast das Problem ein für alle mal los.

Wenn ich wüsste, dass das Problem damit wirklich gelöst ist...
Im Moment ist das ja nur eine Vermutung. Und wenn das Verhalten grundsätzlich so wäre, müssten doch alle mit FHEM auf Pi (und das sind imho recht viele ) das Problem haben. Die werden ja nicht alle eine RTC haben, oder?
Zumal das Problem bei Zeitanpassungen ( z.B. Sommerzeit ) ja vermutlich auch auftreten würde.

[Frank_Huber]

https://wiki.fhem.de/wiki/Raspberry_Pi
Abschnitt Echtzeituhr.

Meine FHEM Instanzen (4 produktiv, 1 Test) laufen alle super, auch wenn mal paar Tage aus.
Wobei paar Tage aus nur bei der test Instanz vorkommt.

Mit dem Handy online, daher kurz gefasst...

[Damian]

Code Auswählen Erweitern

define tmr_CheckTherme DOIF ([+00:05]) { CheckTherme() }
attr tmr_CheckTherme do always

Bevor du Geld in neue Hardware investierst, kannst du es damit versuchen. Dieses Modul geht von aktueller Zeit beim Setzen des nächsten Zeittimers aus.

[KölnSolar]

Und wenn das Verhalten grundsätzlich so wäre, müssten doch alle mit FHEM auf Pi (und das sind imho recht viele ) das Problem haben. Die werden ja nicht alle eine RTC haben, oder?

Genau. Muss man nicht haben.

Zumal das Problem bei Zeitanpassungen ( z.B. Sommerzeit ) ja vermutlich auch auftreten würde.

Bin mir nicht sicher, aber Zeitumstellung ist als Sonderfall glaub ich berücksichtigt.

sollte das Modul vom aktuellen Zeitpunkt ausgehen,

Aber der ist im Rebootfall des PI ja bis zum Inetsynchronisieren auch noch falsch und FHEM schon fleißig...

mehrere tausend Z-Wave-cmds in der Queue landen

Kann bei funktionierendem reboot/fhem.save und Zeitsynchronisierung nicht sein.
Du könntest evtl. den FHEM-Start von der Zeitsynchronisierung des Rpi abhängig machen oder mit timelag starten. Ich brauchs nicht, habs aber schon ein paar mal gelesen...

[Frank_Huber]

Klar, muss jeder selbst wissen.
Mir war es die 1,50 pro raspberry wert.
Hatte nie Probleme mit der Uhrzeit.

Mit dem Handy online, daher kurz gefasst...

[Carsten]

Ich habe es jetzt wie in diesem Thread ( aus dem Wiki-Beitrag von Frank_Huber ) versucht, aber ich bin mir zum einen nicht sicher, ob die Reihenfolge jetzt stimmt, aber davon abgesehen ist laut daemon.log auch nach dem Start von ntp noch eine Weile das Datum falsch ( 2016 ), bevor die aktuelle Zeit geladen wird.

[Frank_Huber]

bei meiner letzten Installation bin ich nach dieser Anleitung vorgegangen, lief problemlos:

There are only two edits you need to do:
1. put the below line into the /boot/config.txt file: (edit it with your favourite editor and type the line in - or copy and paste it from here )
dtoverlay=i2c-rtc,ds3231
2. edit the /lib/udev/hwclock-set file (sudo nano /lib/udev/hwclock-set) and "comment out" the following lines ("comment out" means put a # at the beginning of each of the lines, so they sudo -ibecome comments and are ignored by the system)
if [ -e /run/systemd/system ] ; then
exit 0
fi
so they become:
#if [ -e /run/systemd/system ] ; then
# exit 0
#fi
...and that's it - that's all you need to do. Shut down your system, connect the rtc module, then power up and test with the command:
sudo hwclock -r

[Carsten]

Ich glaub, das ist ein Mißverständnis.
Das sieht nach einrichten der RTC aus, oder?

Ich hab ( noch ) keine. Ich hatte versucht, FHEM erst nach NTP zu starten über

Code Auswählen Erweitern

/etc/systemd/system/fhem.service.d/fhem.conf

[Frank_Huber]

OK, dann hab ich das Missverstanden, sorry.

[Carsten]

Kein Problem. Spätestens, wenn ich den Versuch, ohne RTC auszukommen, aufgegeben habe, kann ich das brauchen.