Gerade habe ich die Feststellung gemacht, dass sich mein FHEM bei 100% CPU-Last aufgehängt hat. Mit globalem verbose=5 kam folgende Meldung in endloser Wiederholung im Log:
2020.10.25 00:27:57.619 5: Starting notify loop for astro, 1 event(s), first is Updated
2020.10.25 00:27:57.621 5: End notify loop for astro
Da lag der Verdacht nahe, dass es an der Zeitumstellung liegt. Der Verdacht erhärtet sich bei einem Blick in die 95_Astro.pm (http://svn.fhem.de/trac/browser/trunk/fhem/FHEM/95_Astro.pm):
2517 {
2518 if ( $comp eq 'NewDay' ) {
2519 push @next,
2520 _timelocal_modern( 0, 0, 0, (localtime($now + 86400.))[3,4], (localtime($now + 86400.))[5]+1900. );
2521 next;
2522 }
2523 my $k = ".$comp";
2524 next unless ( defined( $Astro{$k} ) && $Astro{$k} =~ /^\d+(?:\.\d+)?$/ );
2525 my $t =
2526 _timelocal_modern( 0, 0, 0, (localtime($now))[3,4], (localtime($now))[5]+1900. ) + $Astro{$k} * 3600.;
2527 $t += 86400. if ( $t < $now ); # that is for tomorrow
2528 push @next, $t;
2529 }
Wenn ich das richtig sehe, schaut Zeile 2526 welcher Tag in 24 Stunden ist und setzt einen Timer auf Mitternacht an dem gefundenen Tag. Dummerweise ist in 24 Stunden immer noch heute und nicht morgen, wenn man die Uhr eine Stunde zurückstellt und es zwischen Mitternacht und 1 Uhr ist. Damit wird scheinbar ein Timer in der Vergangenheit gesetzt und auch prompt aufgerufen, was dann zu einer Endlosschleife führt.
Erwartungsgemäß geht es jetzt nach 1 Uhr (Ortszeit hier in Estland) jetzt wieder, da in 24 Stunden morgen ist und der NewDay Trigger erst um Mitternacht wieder zuschlägt.
Kann ich bestätigen. Habe das Astro device eben mal aus der Config rausgenommen und neugestartet. Jetzt gehts wieder.
Kann ich bei mir nicht bestätigen. Ich habe 2 Astro-Devices auf 2 verschiedenen FHEM-Servern. Kann sein, dass das mit dem genauen Termin der Zeitumstellung zusammenhängt. Etwas schwer zu testen...
LG
pah
In meiner zweiten Instanz konnte ich es durch mein Monitoring gut beobachten. Port 8083 war ab 00:00 Uhr nicht mehr erreichbar und ab Punkt 01:00 lief wieder alles. Wenn man in der Zeit sowieso nicht viel von FHEM erwartet hat, bekam man es vermutlich gar nicht mit.
Aber die Zeitumstellung passiert doch um 03:00 - genau wegen solcher Effekte.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 26 Oktober 2020, 20:53:01
Aber die Zeitumstellung passiert doch um 03:00 - genau wegen solcher Effekte.
Anscheinend spielt der Zeitpunkt der Umstellung dafür keine Rolle, jedenfalls so wie Perl / POSIX die Zeit angibt:
25. 10. 2020, 0 Uhr Sommerzeit (oder kurz danach): NewDay wird getriggert. Mit localtime($now + 86400) wird der Zeitpunkt 24 Stunden später in lokaler Zeit formatiert. Dann gilt aber schon die Normalzeit - Perl liefert dann den 25. 10. 2020 um 23 Uhr zurück (oder kurz danach), also das in Normalzeit formatierte Datum. Daraus macht FHEM / Astro dann als neuen Triggerzeitpunkt den 25. 10. 2020 um Mitternacht. Das ist dann aber nicht der nächste Tag.
Hab wieder das gleiche Problem :-D
Bin hier ja nur durch Zufall gelandet...
...aber eben wollte ich mal auf mein fhem System: nix...
Dann top -> fhem 100%
Gut service fhem stop / service fhem start -> wieder 100%
Dann service fhem stop / per nano dann attr Astro disable 1 -> service fhem start -> alles wieder i.O.
Und: ab 00:00 keine Logs etc. mehr. Also scheint das so gegen 00:00 gewesen zu sein. Ja ich weiß (wurde ja schon genannt) Zeitumstellung kommt erst noch...
...aber es ist halt jetzt aufgetreten...
Wollte ich nur hier hinterlassen...
Gruß, Joachim
Zitat von: MadMax-FHEM am 31 Oktober 2021, 00:46:44
Und: ab 00:00 keine Logs etc. mehr. Also scheint das so gegen 00:00 gewesen zu sein.
Dito hier bei mir.
Fhem ab 0:00 Uhr bis 1:00 Uhr nicht ansprechbar.
Im Logffile dann
2021.10.31 01:00:03 1: [Freezemon] myFreezemon: possible freeze starting at 00:00:01, delay is 3602.073 possibly caused by: tmr-FHEM::Astro::Update(myAstro) tmr-FileLog_dailySwitch(FileLog)Norbert
Edit:
Außerdem habe ich noch festgestellt, dass die Zeiten für z.B. CivilTwilightMorning und SunRise mit dem Stand von Timesstamp 00:00:00 noch ohne die Zeitverschiebung berechnet waren. Leider habe ich ein
set myAstro update vor Sicherung des "alten" list ausgeführt und kann daher keinen Belege dafür liefern.
Bei mir ebenfalls wieder der gleiche Effekt, um 0:00 bis 1:00. Es beginnt, wenn um 0:00 NewDay ausgelöst wird und der Zeitpunkt für das nächste NewDay (fehlerhaft) berechnet wird. Und es endet, wenn NewDay wieder korrekt ist.
Zitat von: xenos1984 am 26 Oktober 2020, 21:01:29
Anscheinend spielt der Zeitpunkt der Umstellung dafür keine Rolle, jedenfalls so wie Perl / POSIX die Zeit angibt:
25. 10. 2020, 0 Uhr Sommerzeit (oder kurz danach): NewDay wird getriggert. Mit localtime($now + 86400) wird der Zeitpunkt 24 Stunden später in lokaler Zeit formatiert. Dann gilt aber schon die Normalzeit - Perl liefert dann den 25. 10. 2020 um 23 Uhr zurück (oder kurz danach), also das in Normalzeit formatierte Datum. Daraus macht FHEM / Astro dann als neuen Triggerzeitpunkt den 25. 10. 2020 um Mitternacht. Das ist dann aber nicht der nächste Tag.
Bin auch dabei, und vermutlich hat das auch DbLog blockiert, siehe:
https://forum.fhem.de/index.php/topic,123788.0.html
l.g. erwin
Hmmm, ich kanns nicht nachvollziehen...
Astro läuft in zwei meiner Systeme - allerdings nicht auf einem Raspberry Pi. Keine Blockade...
Könnte der Grund in der Hardware-Echtzeituhr liegen?
LG
pah
ZitatKönnte der Grund in der Hardware-Echtzeituhr liegen?
.. kann ich nicht sagen, jedenfalls hat der ntpd seinen job richtig gemacht, lt. meinem FHEM-log:
2021.10.31 02:56:59.125 3: Invalid response for /common/get_datetime: Can't connect to 192.168.x.y:80
2021.10.31 02:57:00.876 2: AC_Schlafzimmer HVAC_DaikinAC_Poll(): failed (HVAC_DaikinAC_Poll) - Timeout while attempting to poll 192.168.x.y (Timeout: process terminated)
2021.10.31 02:00:13.390 2: ...... (das WLAN der Klimaanlage spinnt.....)
ich hatte zufällig auch apptime am laufen, schaut so als ob alles was mit Internal timer zu tun hatte, in dieser zeit blockiert hat:
name function max count total average maxDly avgDly TS Max call param Max call
tmr-FHEM::Astro::Update HASH(0x38508c8) 134 298321 3595667.91 12.05 3600007.82 1798271.32 29.10. 18:11:11 HASH(myAstro)
tmr-perfmon_ProcessTimer HASH_unnamed 1 248456 34226.51 0.14 3599251.63 17.58 28.10. 11:46:26 HASH(0xa88ed0)
tmr-freezemon_ProcessTimer HASH(0x34ebbe8) 36 248456 111554.90 0.45 3599235.53 17.01 28.10. 11:46:26 HASH(myfreezemon)
tmr-FileLog_dailySwitch HASH_unnamed 11 3 29.04 9.68 3599228.50 1199743.56 29.10. 00:00:01 HASH(0x1244e40)
tmr-DOIFtoolsCounterReset myDOIFtools 0 3 1.56 0.52 3596819.15 1198940.48 29.10. 00:00:03 myDOIFtools
tmr-at_Exec HASH(0x2be21b8) 28 3 79.75 26.58 3595252.99 1198418.05 29.10. 00:00:05 HASH(after_midnight)
tmr-FW_closeInactiveClients 0 7 4142 9880.86 2.39 3583277.93 869.01 31.10. 01:55:00 0
tmr-HVAC_DaikinAC_StartPoll HASH(0x38ea230) 26 824 15932.03 19.33 3581804.81 4348.56 31.10. 02:11:10 HASH(AC_Schlafzimmer)
tmr-ENIGMA2_GetStatus HASH(0x2ecfcd0) 2 5521 3717.29 0.67 3573941.16 649.16 30.10. 09:46:53 HASH(myVUzero)
tmr-CustomReadings_OnTimer HASH(0x1bb90f8) 6 4141 12198.37 2.95 3568449.56 874.89 30.10. 22:44:30 HASH(mySPCMQTTCheck)
tmr-MQTT2_CLIENT_keepalive HASH(0x37f3a28) 1 4140 1785.22 0.43 3568446.65 879.09 31.10. 01:56:03 HASH(Mosquitto_CL_RPI_3)
tmr-SamsungAV_Init HASH(0x3a81bd0) 12 4141 15060.61 3.64 3568445.29 872.06 30.10. 01:57:54 HASH(newTV)
tmr-KNXIO_keepAlive HASH(0x3b96598) 16 4139 7954.26 1.92 3566199.16 868.15 31.10. 07:27:17 HASH(myKNXIO)
tmr-PRESENCE_StartLocalScan HASH(0x2acd828) 31 820 15953.21 19.46 3430449.78 4185.48 30.10. 13:26:11 HASH(VPN_PRESENCE)
tmr-HVAC_DaikinAC_StartPoll HASH(0x38f4b20) 31 827 15898.14 19.22 3348373.12 4050.44 31.10. 03:40:33 HASH(AC_Wohnzimmer)
tmr-HVAC_DaikinAC_StartPoll HASH(0x39998a8) 27 827 15938.04 19.27 3318024.39 4014.28 31.10. 07:26:05 HASH(AC_Kinderzimmer)
tmr-SYSSTAT_GetUpdate HASH(0x23ae368) 118 829 22495.93 27.14 3316862.89 4002.66 29.10. 12:04:42 HASH(mySYSSTAT)
tmr-FRITZBOX_Readout_Start myFritzbox.Readout 39 829 16098.92 19.42 3311355.59 3996.12 29.10. 17:59:48 myFritzbox.Readout
tmr-at_Exec HASH(0x384c1e8) 75 420 21546.12 51.30 3000461.64 21471.17 28.10. 22:50:00 HASH(get_ebus_updates)
tmr-at_Exec HASH(0x2def588) 153 280 26692.62 95.33 3000398.77 23581.64 30.10. 23:40:00 HASH(EnergyPoll)
tmr-KOSTALPIKO_StatusTimer myKostal.STATUS 27 69 1546.34 22.41 921706.75 13359.87 31.10. 07:00:00 myKostal.STATUS
tmr-PROPLANTA_Start HASH(0x27abab0) 29 69 1393.96 20.20 901970.85 13076.03 31.10. 08:00:00 HASH(myPROPLANTA)
tmr-statistics_PeriodChange HASH(0x2df1438) 116 70 3379.26 48.28 5838.51 133.55 29.10. 23:59:55 HASH(Stromzaehler_stats)und nach 01:00:00 läuft wieder alles!
Edit: Hardware: raspberry 3B - Linux CL-RPI-2 4.9.35-v7+ #1014
l.g. erwin
Welche Hardware?
LG
pah
Bei mir ist es ein RPi 4. Aber ich denke nicht, dass es an der Hardware-Echtzeituhr liegt, sondern an der Zeitberechnung
2518 if ( $comp eq 'NewDay' ) {
2519 push @next,
2520 _timelocal_modern( 0, 0, 0, (localtime($now + 86400.))[3,4], (localtime($now + 86400.))[5]+1900. );
2521 next;
2522 }
"Setze den nächsten Trigger an dem Tag (gemäß lokaler Uhrzeit) um 00:00, der in 86400 Sekunden ist." In 86400 Sekunden ist aber, gemessen in lokaler Zeit, immer noch der gleiche Tag, weil die Uhr ja zwischenzeitlich zurückgestellt wird. Also wird der Trigger nicht für 00:00 am nächsten, sondern am selben Tag gesetzt, und sofort ausgelöst, weil der Zeitpunkt ja bereits erreicht ist. Erst ab 01:00 fällt (jetzt + 86400 Sekunden) auf den nächsten Kalendertag.
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.
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.
ZitatVielleicht 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 ... ;D
ZitatAbhilfe 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
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?
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2021, 10:40:27
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.)
Zitat
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...
Zitat
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.
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...
ok, ich bin hier raus, da mein fhem noch sommerzeit hat. ;)
weder rtc noch internet.
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
Die Anzeichen verdichten sich, dass es die RTC macht...
So lange ich das nicht verstanden habe, werde ich jedenfalls keinen Workaround basteln.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2021, 12:41:08
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.
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.
Zitat von: Frank_Huber am 31 Oktober 2021, 12:44:34
...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
Zitat von: rob am 31 Oktober 2021, 13:29:48
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:
### 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
Zitat von: xenos1984 am 31 Oktober 2021, 10:09:39
... 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.
Also auf meinem Pi 3B+ gabs auch keine Auffälligkeiten.......
Buster, Perl 5.28.1
Zitat von: Icinger am 02 November 2021, 09:40:38
Also auf meinem Pi 3B+ gabs auch keine Auffälligkeiten.......
Buster, Perl 5.28.1
mit oder ohne RTC?
OK. Ich habe einfach mal ein Testsystem aufgesetzt.
Testszenario:
Host Intel Desktop (nicht mein prod. System ;D ). Umgebung ist FHEM Docker und darin läuft Buster
root@7ec02abd6be1:/opt/fhem# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
Perl:
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.
Kannst du mal in deinem Testsystem die Zeilen am #2518 versuchsweise tauschen:
if ( $comp eq 'NewDay' ) {
my $dch = localtime($now + 86400 + 3600*((localtime($now))[8] - (localtime($now + 86400.))[8]));
push @next,
_timelocal_modern( 0, 0, 0, ($dch)[3,4], ($dch)[5]+1900. );
next;
}
Ergänzend sollt man z.B. in #776 noch Folgendes einfügen:
return 'Astro may not be run on Windows systems' if $^O eq 'MSWin32';
Hallo Beta-User.
Habe die Änderungen hoffentlich richtig eingesetzt. Die Ergänzung #776 ist auch mit drin. Reload ausgeführt. Zeit zurückgedreht auf 23:59 und wieder abgewartet.
Beobachtung:
Mit Umschaltung 00:00 WebIF weiter verfügbar + reagiert, CPU schaut normal aus (cpan-outdated springt als einziges ab und zu auf 100%)
Habe allerdings dauernd reconnects zum WebIF. Nach Connection lost kommt dann mit F5 ein "Fehler: Verbindung fehlgeschlagen". Nach ein paar Sekunden wieder alles OK. Dann von vorne. Vielleicht habe ich die Editierung noch einen Fehler reingepastet?
Zumindest besteht bereits der Unterschied, dass es erreichbar bleibt.
VG
rob
Edit: die Reconnect liegen daran, dass Fhem dauernd neu startet. Ich fang nochmal frisch an, damit das vergleichbar bleibt.
Zitat von: rob am 02 November 2021, 11:52:37
Habe allerdings dauernd reconnects zum WebIF. Nach Connection lost kommt dann mit F5 ein "Fehler: Verbindung fehlgeschlagen". Nach ein paar Sekunden wieder alles OK. Dann von vorne. Vielleicht habe ich die Editierung noch einen Fehler reingepastet?
Glaube ich nicht; vermutlich ist FHEM einfach bei so einem Monatswechsel etwas beschäftigt, so dass longpoll nicht hinreichend schnell bedient wird.
Danke für den Test
@pah: anbei die komplette Datei. Soweit ich das im Kopf habe bevorzugst du diese Variante gg. einem patch.
Die Testumgebung lief ja noch. Wollte ausschließen, dass irgendwas im System sich daran stört, wenn ich ich Zeit einfach zurückdrehe ;D
Also neu begonnen.
- Container resettet
- Zeit auf 23:50Uhr
- Container gestartet
- Devices etc. eingerichtet[/li][/list]
→ Alles OK
Astro.pm geändert + reload
→ Alles OK
Mit Umschaltung auf 00:00 → reconnects/ restarts
Zeit vorgestellt auf 00:59 und abgewartet bis 01:00Uhr → reconnect/restarts bleiben
Astro wieder zurückgepatched + reload (bzw. wg. deuerndem restart zieht es eh von allein) → alles stabil
Irgendwas will da noch nicht so ganz. Habe ich etwas übersehen?
Ups, nicht gut... Wenn es einen Neustart gibt, sollte eigentlich was dazu im Log stehen?
Schaut so aus:
2021.10.31 00:00:00.009 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/95_Astro.pm line 2522.
Day '' out of range 1..31 at ./FHEM/95_Astro.pm line 1293.
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:10.673 1: Including fhem.cfg
2021.10.31 00:00:10.755 3: WEB: port 8083 opened
2021.10.31 00:00:10.772 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2021.10.31 00:00:10.891 3: AptToDate (fhemServerApt) - defined
2021.10.31 00:00:11.137 3: telnetPort: port 7072 opened
2021.10.31 00:00:11.226 1: Including ./log/fhem.save
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:11.234 1: Messages collected while initializing FHEM:SecurityCheck:
telnetPort is not password protected
WEB is not password protected
Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none
2021.10.31 00:00:11.933 1: usb create starting
2021.10.31 00:00:11.948 1: usb create end
2021.10.31 00:00:11.948 0: Featurelevel: 6
2021.10.31 00:00:11.948 0: Server started with 16 defined entities (fhem.pl:22522/2020-08-02 perl:5.028001 os:linux user:fhem pid:13474)
2021.10.31 00:00:16.237 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/95_Astro.pm line 2522.
Day '' out of range 1..31 at ./FHEM/95_Astro.pm line 1293.
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:26.677 1: Including fhem.cfg
2021.10.31 00:00:26.760 3: WEB: port 8083 opened
2021.10.31 00:00:26.777 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2021.10.31 00:00:26.896 3: AptToDate (fhemServerApt) - defined
2021.10.31 00:00:27.139 3: telnetPort: port 7072 opened
2021.10.31 00:00:27.204 1: Including ./log/fhem.save
2021.10.31 00:00:27.210 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:27.211 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:27.211 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:27.211 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:27.211 1: Messages collected while initializing FHEM:SecurityCheck:
WEB is not password protected
telnetPort is not password protected
...
Spannend ist wahrscheinlich nur die erste Message. Der Rest wiederholt sich eh :)
...vermutlich...
Vielleicht dann doch eher so:
if ( $comp eq 'NewDay' ) {
my @dch = localtime($now + 86400 + 3600*((localtime($now))[8] - (localtime($now + 86400.))[8]));
push @next,
_timelocal_modern( 0, 0, 0, $dch[3], $dch[4], $dch[5]+1900. );
#_timelocal_modern( 0, 0, 0, (localtime($now + 86400.))[3,4], (localtime($now + 86400.))[5]+1900. );
next;
}
Schaut gut aus 8).
Test mit frischem System wiederholt. Zeitumstellung wieder abgewartet und beobachtet.
Umstellung auf 00:00 erfolgt unauffällig: WebIF bleibt stabil, CPU-Last bleibt low
Keine Auffälligkeiten im Log.
Test im laufenden System glashart wiederholt: keine Auffälligkeiten. Sehr geschmeidig.
VG
rob
Danke für die Geduld, dann hier wieder die kommentarbereinigte Vollversion.
Ich bedanke mich und es hat mich kein bisschen Geduld gekostet ;D
Setze mir mal einen Merker für nä. Jahr :P :
define lookilooki at 2022-10-30T23:50:00 { Log 1, "... watch out for the groundhog https://www.youtube.com/watch?v=AjNE2N0SDzs" }
VG
rob
So, ich habe mal weitgehend alle Änderungswünsche von loredo, CoolTux und anderen in das "offizielle" Modul eingebaut. Das war eine Masse Zeug, irgendwer war da ziemlich fleißig - und wenigstens ungefähr musste ich es verstehen.
Wird gerade eingecheckt und dann per Update verteilt. Eventuelle Fehler gehen erst einmal auf Eure Kappe ;D
LG
pah
???
https://svn.fhem.de/trac/changeset/25198/ war doch nicht übermäßig groß? (Und der vorherige Commit lief schon "ewig" ohne, dass es Beschwerden gegeben hätte).
Zitat von: Prof. Dr. Peter Henning am 07 November 2021, 16:40:23
Eventuelle Fehler gehen erst einmal auf Eure Kappe ;D
Falls sich jemand veranlaßt sieht, Beschwerden abzuliefern, dann gerne an meine Adresse ::) .
Dank ausdrücklich an @rob für's Testen! (@rob: Falls du das Testsystem nochmal quälen wolltest... Es gibt da noch ein Vorschlag für statistics, der ebenfalls ungetestet ist: https://forum.fhem.de/index.php/topic,123815.msg1184079.html#msg1184079. Irgendwie habe ich da noch Bauchweh, was passiert, wenn jemand den dayChange um genau 2h (bzw. 3h) verschiebt, vielleicht sollte man dazu noch einen Hinweis in die commandref aufnehmen...)