Endlosschleife in Astro bei NewDay-Trigger & Zeitumstellung

[Prof. Dr. Peter Henning]

Vielleicht könntest du zum testen ein Testsystem aufsetzen und dessen Uhrzeit auf 23:55 am Tag vor der Zeitumstellung setzen? Dann sollte das Phänomen eigentlich auftreten.

Wenn ich mal nichts Anderes zu tun habe. Sollte nach derzeitiger Schätzung etwa 2031 soweit sein ...

Abhilfe schaffen würde statt 86400 Sekunden in die Zukunft eine Stunde weiter zu projizieren. Das funktioniert dann sowohl an normalen Tagen, als auch zur Zeitumstellung.

Nene, das rückt dann pro Tag eine Stunde weiter vor. Man müsste das Datum der neuen Zeitangabe vergleichen. Oder gleich das Datum der Zeitumstellung mit einbeziehen.

Aber, wie gesagt: Bei mir gibt es außer einem Rücksprung in den Daten keinerlei negative Effekte. Auch Module, bei denen extensiv Gebrauch von InternalTimer gemacht wird, liefern schön brav ihre Daten. Anbei ein paar Screenshots von heute Nacht als Beleg

Hat denn eigentlich der RPI4 endlich eine Hardware-Uhr? Ich habe einen hier herumliegen, bin nur mangels Zei tnicht dazu gekommen, den aufzusetzen.

LG

pah

[frank]

bei mir war alles ruhig, keine auffälligkeiten im log oder sonst wo.
fhem auf pi3/buster mit astro device.

vielleicht hat die perl version einen einfluss?

[Nobbynews]

Welche Hardware?

Pi 3B
Stretch
Perl 5.24.1

[xenos1984]

Nene, das rückt dann pro Tag eine Stunde weiter vor. Man müsste das Datum der neuen Zeitangabe vergleichen. Oder gleich das Datum der Zeitumstellung mit einbeziehen.

Mit der Methode sollte das nicht passieren, siehe der von mir zitierte Code (von dem ich vermute, dass der den neuen Trigger-Zeitpunkt bestimmt). Beispiele:

• Derzeitige Methode, keine Zeitumstellung: NewDay triggert am 30. Oktober um 00:00:00. Danach wird der neue Termin bestimmt, indem 86400 Sekunden vorwärts geschaut wird (localtime + 86400). Das ist der 31. Oktober 00:00:00. Es werden aber nur Tag, Monat und Jahr ausgewertet, die Uhrzeit wird verworfen und auf 0 gesetzt. Ergebnis: 31. Oktober 00:00:00.
• Derzeitige Methode, Zeitumstellung: NewDay triggert am 31. Oktober um 00:00:00. Danach wird der neue Termin bestimmt, indem 86400 Sekunden vorwärts geschaut wird (localtime + 86400). Das ist der 31. Oktober 23:00:00. Es werden aber nur Tag, Monat und Jahr ausgewertet, die Uhrzeit wird verworfen und auf 0 gesetzt. Ergebnis: 31. Oktober 00:00:00. Der Trigger wird am gleichen Tag gesetzt.
• Von mir vorgeschlagene Methode, keine Zeitumstellung: NewDay triggert am 30. Oktober um 00:00:00. Danach wird der neue Termin bestimmt, indem 90000 Sekunden vorwärts geschaut wird (localtime + 90000). Das ist der 31. Oktober 01:00:00. Es werden aber nur Tag, Monat und Jahr ausgewertet, die Uhrzeit wird verworfen und auf 0 gesetzt. Ergebnis: 31. Oktober 00:00:00.
• Von mir vorgeschlagene Methode, Zeitumstellung: NewDay triggert am 31. Oktober um 00:00:00. Danach wird der neue Termin bestimmt, indem 90000 Sekunden vorwärts geschaut wird (localtime + 90000). Das ist der 1. November 00:00:00. Es werden aber nur Tag, Monat und Jahr ausgewertet, die Uhrzeit wird verworfen und auf 0 gesetzt. Ergebnis: 1. November 00:00:00.

(Bei der Zeitumstellung im Frühling gibt es auch kein Problem. Dann liefert (localtime + 90000) eben 02:00:00 am nächsten Tag, aber die Uhrzeit wird ohnehin "weggeworfen" und auf 0 gesetzt, weil nur die Datumskomponente benutzt wird.)

Aber, wie gesagt: Bei mir gibt es außer einem Rücksprung in den Daten keinerlei negative Effekte. Auch Module, bei denen extensiv Gebrauch von InternalTimer gemacht wird, liefern schön brav ihre Daten. Anbei ein paar Screenshots von heute Nacht als Beleg

Und recomputeAt enthält NewDay, und der Rechner benutzt die lokale / umzustellende Zeit (kein UTC o.ä.)? Das ist in der Tat eigenartig...

Hat denn eigentlich der RPI4 endlich eine Hardware-Uhr? Ich habe einen hier herumliegen, bin nur mangels Zei tnicht dazu gekommen, den aufzusetzen.

Meines Wissens nach nicht. Die gibt es als Zusatzmodul (habe ich aber nicht).

Perl ist bei mir v5.28.1 auf Raspbian Buster.

[Frank_Huber]

Moin,

Hier laufen 6 Instanzen FHEM. alle auf RasPI. (2er, 3er und 4er)
Astro ist glaube ich auf 3 oder 4 davon definiert. Keine Probleme.


Ich hab aber überall eine RTC drauf.
die PIs laufen alle unter Buster und sind am Freitag mit den letzten Updates versorgt worden. OS und FHEM.

also könnte es an einer fehlenden RTC oder zu alten Versionen liegen. Oder an ganz was anderem...

[frank]

ok, ich bin hier raus, da mein fhem noch sommerzeit hat. 
weder rtc noch internet.

[MadMax-FHEM]

Dann liefere ich auch mal meine HW-/OS-Daten

PI3B+ aktuelles Buster (also bis gestern/vorgestern aktuell gibt es ja wieder ein paar Updates / das letzte Update war tzdata vor einigen Tagen).
Kein RTC aber Internet und ntp...

Perl:
This is perl 5, version 28, subversion 1 (v5.28.1) built for arm-linux-gnueabihf-thread-multi-64int

Letztes fhem update war am 18.10.2021

Gruß, Joachim

[Prof. Dr. Peter Henning]

Die Anzeichen verdichten sich, dass es die RTC macht...

So lange ich das nicht verstanden habe, werde ich jedenfalls keinen Workaround basteln.

LG

pah

[Frank_Huber]

Die Anzeichen verdichten sich, dass es die RTC macht...

Na falls sich das bestätigt wäre ja auch eine Lösung "RTC nachrüsten".

Ist ja jetzt wieder ein Jahr Zeit bis zum nächsten Vorfall dieser Art.

[rob]

Ich reihe mich mal mit ein. Laut htop FHEM bei 100% CPU. Kein Zugriff, kein LOG zw. 00:00 und 01:00Uhr. Auch ein Reboot brachte keine Verbesserung - sprang sofort auf 100% Last. Ab 01:06Uhr lief FHEM wieder, als wäre nix gewesen.
Hab mich erinnert, dass es mir letztes Jahr auch so ging, aber nicht bei der Zeitumstellung im Frühling dieses Jahr (würde es aber nicht beschwören  ).

HW: RPi3B
OS: Raspbian GNU/Linux 9 (stretch)
Perl: v5.24.1 (built for arm-linux-gnueabihf-thread-multi-64int)

Der ntpd synchronisiert bei mir je Boot + stündlich.

...Na falls sich das bestätigt wäre ja auch eine Lösung "RTC nachrüsten".

In dem Fall müsste so einer reichen, oder? https://www.reichelt.de/de/de/raspberry-pi-real-time-clock-modul-rtc-ds3231sn-rpi-rtc-clock-p224214.html?r=1

[Frank_Huber]

In dem Fall müsste so einer reichen, oder?

Ja, die stecken bei mir auf jedem PI. Einrichtung sind  zwei Schritte.
Wichtig ist dass ne Batterie drauf ist.

Einrichtung:

Code Auswählen Erweitern

###         R T C                ###
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 become 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 

[rob]

... ein Testsystem aufsetzen und dessen Uhrzeit auf 23:55 am Tag vor der Zeitumstellung setzen? Dann sollte das Phänomen eigentlich auftreten.

Hat das schon jmd. ausprobiert?
Ich könnte via Docker ja leicht ein Testsystem aufsetzen und testen. Soweit ich weiß, ist im FHEM-Docker immer alles aktuell, sodass evtl. Ursachen wie altes Stretch oder altes Perl nicht direkt zu erkennen sind (nur per Ausschluss, weil es keinen Fehler gibt - dann weiß ich aber nicht, ob das Testszenario korrekt aufgestellt ist).
Ansonsten müsste ich einen anderen Raspi nehmen und dort testweise aufsetzen: 1x Stretch u. 1x Buster. Das ganze dann nochmal mit HW-RTC vergleichen.

[Icinger]

Also auf meinem Pi 3B+ gabs auch keine Auffälligkeiten.......

Buster, Perl 5.28.1

[Frank_Huber]

Also auf meinem Pi 3B+ gabs auch keine Auffälligkeiten.......
Buster, Perl 5.28.1

mit oder ohne RTC?

[rob]

OK. Ich habe einfach mal ein Testsystem aufgesetzt.

Testszenario:
Host Intel Desktop (nicht mein prod. System  ). Umgebung ist FHEM Docker und darin läuft Buster

Code Auswählen Erweitern


root@7ec02abd6be1:/opt/fhem# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"


Perl:

Code Auswählen Erweitern


v5.28.1 (built for x86_64-linux-gnu-thread-multi)


Aktion:
Zeit vom Host zurückgedreht auf 30.10. 23:50Uhr und die Devices angelegt: twilight, Astro, 2x Dummys und 1x notify.

Beobachtung:
23:55Uhr - FHEM im Docker erreichbar.
Mit Umschaltung auf 00:00 FHEM nicht mehr erreichbar
CPU lt. top auf 100%

Aktion:
Zeit im Host vorgestellt auf 00:59 und gewartet.

Beobachtung:
Exakt bei Umschaltung auf 01:00Uhr im Host ist das WebIF wieder verfügbar und CPU-Last wieder runter.

Damit müsste man doch gut eingrenzen können oder? Zumindest scheint es nicht an Stretch vs. Buster und nicht an der Perl-Version zu liegen. Ich hätte erwartet, dass es auf dem Intel-System nicht nachvollziehbar ist. Der Intel-Krams müsste doch immer eine HW-RTC haben. Komisch.