Hallo,
seit eben hab ich eine Endlosschleife in FHEM, was zu 100% Auslastung führt und das WEB-Interface nicht mehr erreichbar macht.
Ich glaube der Grund ist das Modul ElectricityCalculator.
Im Define des Moduls wird ein ElectricityCalculator_MidnightTimer angelegt, und dieser scheint in einer Endlosschleife zu laufen.
Das Modul hat Level5 Logausgaben, "time", "timelocal" und "nextMidnight".
Im Fall der Endlosschleife waren diese 3 Werte 1667170365.18888, 1667170365 und 1667080801.
Hier sieht man, dass "nextMidnight" vor "timeLocal" liegt.
Inzwischen ist es nach 00:00 Uhr, und FHEM läuft wieder fehlerfrei.
Das Problem scheint also nur zwischen 23 und 0 Uhr zu bestehen?
Ich hatte um 23.00 ebenso einen Fhem Ausfall:
- Keine Web Oberfläche
- Perl auf 100% CPU
Bislang ungeklärt, um 00.00 lief das System wieder.
Falls ihr einen patch vorschlagen wollt, wäre in https://forum.fhem.de/index.php/topic,123847.msg1184061.html#msg1184061 ggf. Material zu finden.
Mich hats auch erwischt. Allerdings habe ich keinen ElectricityCalculator im Einsatz. Dafür WaterCalculator und GasCalculator. Da kann ich jetzt schlecht Unterstellungen betreiben ohne mehr zu wissen.
Leider hatte ich kein Verbose=5 und auch sonst keinen Watcher in FHEM aktiv.
Zumindest kann ich sagen, dass es nach Neustart mit dem Laden nach dieser Nachricht im LOG sofort auf 100% hochging:
...
2022.10.30 23:17:57 0: Featurelevel: 6.1
2022.10.30 23:17:57 0: Server started with 458 defined entities (fhem.pl:26379/2022-09-03 perl:5.032001 os:linux user:messagebus pid:8258)
...
Exakt mit 00:00:01Uhr war lt. htop der Spuk vorbei. Welch Déjà-vu ;)
Hat jmd. von Euch mehr Details/ Infos?
VG
rob
Bei mir laufen Gas und Electricity Calculator.
Ich kann nicht sagen, wo die Ursache liegen könnte.
By the way - heute morgen zeigt der Electricity Calculator negative Werte an, Gas sieht OK aus.
Hier muss wohl der Modulautor mal den Code prüfen. Siehe Hinweis Beta-User.
Mit meinem Testsystem kann ich evtl. unterstützen (Module einrichten und einen entsprechenden Counter finden oder definieren) , insofern das möglich ist.
Gute Idee. Ich könnte ebenfalls testen, falls nötig. Könnte sein, dass man wieder die Systemzeit zurückdrehen müsste, um zu simulieren. Im worst case könnten alle drei Calculatoren betroffen sein.
Mein GasCounter hat zwei negative Werte: EnergyCostDayLast und EnergyDayLast. Hab ihn noch nicht lange genug, um das zu bewerten.
Der WaterCounter hat nix negatives.
VG
rob
Hab mal doch das Testsystem angeworfen und mit WaterCalc begonnen. Ja, blockt reproduzierbar.
Freezemon sagt
1 - 2022-10-30: s:22:26:43 e:22:59:25 f:1962.433 d:no bad guy found :-(
1 - 2022-10-30: s:23:00:02 e:00:00:00 f:3598 d:tmr-WaterCalculator_MidnightTimer(myWaterCalculator)
Log
2022.10.31 00:00:00.000 1: [Freezemon] myfreezer: possible freeze starting at 23:00:02, delay is 3598 possibly caused by: tmr-WaterCalculator_MidnightTimer(myWaterCalculator)
Passt jetzt halt nicht zur Fred-Überschrift ;)
Den GasCalc schau ich mir auch an.
VG
rob
Guter Fund!
Ich komme heute erst am Abend zum Testen. Evtl. kann Sailor heute Abend auch mal schauen.
Der GasCalc blockt leider auch.
1 - 2022-10-30: s:22:07:56 e:22:59:49 f:3113.022 d:no bad guy found :-(
1 - 2022-10-30: s:23:00:02 e:00:00:00 f:3598 d:tmr-GasCalculator_MidnightTimer(Gaszaehler)
Mein Vorgehen:
- Docker FHEM taufrisch mit nix drin starten
- Counter + Calc anlegen
- FHEM updaten + restart
- Sys-Zeit setzen auf 30.10. 22:00Uhr
- ein setreading am Counter machen, im Calc wird reagiert
- Sys-Zeit setzen auf 30.10. 22:59Uhr
→ FHEM nicht erreichbar, sobald es 23:00Uhr ist
- Sys-Zeit setzen auf 30.10. 23:59Uhr
→ FHEM wieder erreichbar, sobald es 31.10. 00:00Uhr ist
Wenn Du mir für den EleCalc + dessen Counter eine Defi geben magst, kann ich den auch testen.
VG
rob
Hallo rob,
das sieht bei mir so aus:
"SolarView:BKDY" ist der aktuelle Strombezug am 2-Wege-Zähler.
BKDY bekommt jede Minute einen aktuellen Wert.
VG Helmut
define ke_StromVerbrauch ElectricityCalculator SolarView:BKDY.*
attr ke_StromVerbrauch BasicPricePerAnnum 60
attr ke_StromVerbrauch Currency €
attr ke_StromVerbrauch DecimalPlace 3
attr ke_StromVerbrauch ElectricityCounterOffset 0
attr ke_StromVerbrauch ElectricityKwhPerCounts 1
attr ke_StromVerbrauch ElectricityPricePerKWh 0.2088
attr ke_StromVerbrauch MonthOfAnnualReading 1
attr ke_StromVerbrauch MonthlyPayment 10
attr ke_StromVerbrauch ReadingDestination CalculatorDevice
attr ke_StromVerbrauch SiPrefixPower W
attr ke_StromVerbrauch alias StromVerbrauch (Bezug)
attr ke_StromVerbrauch event-on-change-reading .*
attr ke_StromVerbrauch room Keller
attr ke_StromVerbrauch stateFormat SolarView_BKDY_EnergyDay kWh, SolarView_BKDY_EnergyCostDay € heute
define ke_StromVerbrauchFileLog_1 FileLog ./log/ke_StromVerbrauchFileLog_1-%Y-%m.log ke_StromVerbrauch:SolarView_BKDY_EnergyCostDay:.*
attr ke_StromVerbrauchFileLog_1 addLog ke_StromVerbrauch:SolarView_BKDY_EnergyCostDay:300
attr ke_StromVerbrauchFileLog_1 room System
Danke Dir.
Ja, blockt ebenfalls:
1 - 2022-10-30: s:22:16:39 e:22:59:30 f:2571.672 d:no bad guy found :-(
1 - 2022-10-30: s:23:00:02 e:00:00:00 f:3598 d:tmr-ElectricityCalculator_MidnightTimer(ke_StromVerbrauch)
Heißt, beim Raten mit welchem Modul ich starte, hatte ich 0% Risiko daneben zu liegen ;D
In allen drei Fällen also der MidnightTimer.
Viele Grüße
rob
my $EpochNextMidnight = timelocal(1, 0, 0, $mday, $mon, $year+1900) + 86400;
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/73_ElectricityCalculator.pm#L605
The code expects the same number of seconds in every day (86400) which you can't assume with daylight saving.
Yet another DST bug in Fhem because every module keeps manually calculating time differences. ;D
@rob Can you test this patch?
--- - 2022-10-31 17:22:58.750295332 +0100
+++ /srv/fhem/FHEM/73_ElectricityCalculator.pm 2022-10-31 17:22:08.191859193 +0100
@@ -602,7 +599,7 @@
### Start timer for execution around midnight
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
- my $EpochNextMidnight = timelocal(1, 0, 0, $mday, $mon, $year+1900) + 86400;
+ my $EpochNextMidnight = Time::Local::timelocal_nocheck(1, 0, 0, $mday+1, $mon, $year+1900);
InternalTimer($EpochNextMidnight, "ElectricityCalculator_MidnightTimer", $ElectricityCalcDev, 0);
### For debugging purpose only
# 1667080801 = Sun Oct 30 2022 00:00:01 GMT+0200 (CES)
fhem> { my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(1667080801);; FmtDateTime(timelocal(1, 0, 0, $mday, $mon, $year+1900) + 86400) }
2022-10-30 23:00:01
fhem> { my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(1667080801);; FmtDateTime(Time::Local::timelocal_nocheck(1, 0, 0, $mday+1, $mon, $year+1900)) }
2022-10-31 00:00:01
The sane way would be to use DateTime module....
https://perldoc.perl.org/5.30.3/perlfaq4#How-do-I-find-yesterday's-date?
Zitat von: Nestor am 31 Oktober 2022, 17:34:34
...Can you test this patch?...
Sure :) Thank you very much for your support.
I just patched "73_ElectricityCalculator.pm" inside my test instance in its last state, which is already up to date and has an EleCalc-device running. I edited line #156 so the block looks like that:
### Start timer for execution around midnight
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
#my $EpochNextMidnight = timelocal(1, 0, 0, $mday, $mon, $year+1900) + 86400;
my $EpochNextMidnight = Time::Local::timelocal_nocheck(1, 0, 0, $mday+1, $mon, $year+1900);
InternalTimer($EpochNextMidnight, "ElectricityCalculator_MidnightTimer", $hash, 0);
After setting the sys-time back to 30.11. 22:20, I restarted FHEM and set the time to 22:59. No freeze happend as the time reached 23:00 :D :D 8)
I also set the time to 23:59 what made no difference - just to keep my test procedure.
Freezemon tells me:
1 - 2022-10-30: s:22:16:39 e:22:59:30 f:2571.672 d:no bad guy found :-(
1 - 2022-10-30: s:23:00:02 e:00:00:00 f:3598 d:tmr-ElectricityCalculator_MidnightTimer(ke_StromVerbrauch)
1 - 2022-10-30: s:22:22:30 e:22:59:17 f:2207.463 d:no bad guy found :-(
1 - 2022-10-30: s:23:01:11 e:23:59:05 f:3474.089 d:no bad guy found :-(
The first two lines come from my testing before the patch. Looks promising, doesn't it?
The other two modules WaterCalc and GasCalc do have the same code line inside. So I guess they even should work well with that patch.
Do you think my spot testing of that particular case will be enough? Or are there some more special cases we should check by further tests?
It would would be excellent if all concerned modules could be patched officially (at least those three ones). But I'm not sure who feels actually responsible for that and when it could be done (are the module authors still on board and have the time to implement it?).
Well, the next clock change gives us a delay of almost 6 months - maybe not that urgent ;)
Best regards
rob
Dear Nestor, dear Rob
Zitat von: Nestor am 31 Oktober 2022, 17:34:34
@rob Can you test this patch?
Zitat von: rob am 01 November 2022, 12:57:26
After setting the sys-time back to 30.11. 22:20, I restarted FHEM and set the time to 22:59. No freeze happend as the time reached 23:00 :D :D 8)
Thanks a lot for your suggestions!!! ;D
I am going to implement this patch as soon as I have the possibility.
Latest for Friday.
Still time enough till the next daylight saving ;)
Regards
Sailor
Hi rob
Zitat von: rob am 01 November 2022, 12:57:26
The other two modules WaterCalc and GasCalc do have the same code line inside. So I guess they even should work well with that patch.
Correct. All 3 modules are based on the same structure. Most of the code can be found exactly at the same line.
Zitat von: rob am 01 November 2022, 12:57:26
It would would be excellent if all concerned modules could be patched officially (at least those three ones). But I'm not sure who feels actually responsible for that and when it could be done (are the module
I am the author and current maintainer and I will do it as soon as possible. Friday latest!
Thanks a lot for your help! Open Source at its best!
Zitat von: rob am 01 November 2022, 12:57:26
Well, the next clock change gives us a delay of almost 6 months - maybe not that urgent ;)
Exactly! ;)
Regards
Sailor
Moinssen.
That's excellent my dear ;D ;D
Thank you very much for your quick response and great work.
Kind regards
rob
Mni thanks to all!
:) :) :)
Moin zusammen
Eingepflegt. Sollte morgen im Update dabei sein.
@KyleK : Bitte Thread als "Gelöst" markieden
Gruß
Sailor
Thanks everyone for the quick patch.
I do remember some DST issues last year or the year before, which begs the question: why does every module do this on its own? Is there a standard way to do this in Perl, and if so, can't fhem.pl provide such a common solution?
@Sailor; You still have some work to do...
There are still 2 incorrect timers in Gas en WaterCalc and 86400 comparison will not be correct on the 2 DST switch days.
/srv/fhem$ grep 86400 FHEM/*Calculator.pm
FHEM/73_ElectricityCalculator.pm: if ( $DeltaTimeSinceLastUpdate >= 86400) {
FHEM/73_ElectricityCalculator.pm: if (($ElectricityCountReadingTimestampCurrentHour < $ElectricityCountReadingTimestampPreviousHour) || ($ElectricityCountReadingLastChangeDelta > 86400))
FHEM/73_GasCalculator.pm: if ( $DeltaTimeSinceLastUpdate >= 86400) {
FHEM/73_GasCalculator.pm: my $EpochNextMidnight = timelocal(1, 0, 0, $mday, $mon, $year+1900) + 86400;
FHEM/73_GasCalculator.pm: if (($GasCountReadingTimestampCurrentHour < $GasCountReadingTimestampPreviousHour) || ($GasCountReadingLastChangeDelta > 86400))
FHEM/73_WaterCalculator.pm: if ( $DeltaTimeSinceLastUpdate >= 86400) {
FHEM/73_WaterCalculator.pm: my $EpochNextMidnight = timelocal(1, 0, 0, $mday, $mon, $year+1900) + 86400;
FHEM/73_WaterCalculator.pm: if (($WaterCountReadingTimestampCurrentHour < $WaterCountReadingTimestampPreviousHour) || ($WaterCountReadingLastChangeDelta > 86400))
@KyleK I posted a link to a good solution (DateTime module) instead of counting seconds manually.
From the Perl FAQ:
ZitatThe DateTime module makes it simple, and give you the same time of day, only the day before, despite daylight saving time changes. Most people try to use the time rather than the calendar to figure out dates, but that assumes that days are twenty-four hours each. For most people, there are two days a year when they aren't: the switch to and from summer time throws this off.
This automatically takes into account DST days (with 23 and 25 hours).
use 5.030;
use strict;
use warnings;
use DateTime;
use Time::Local;
sub timelocal_add {
my $epoch = shift;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($epoch);
return Time::Local::timelocal(0, 0, 0, $mday, $mon, $year+1900) + 86400;
}
say "Summertime 2023";
my $dt = DateTime->new(year => 2023, month => 03, day => 26, time_zone => 'Europe/Brussels');
say $dt;
say "Datetime +1day";
say $dt->add(days => 1);
say "Fhem +1day (WRONG)";
say DateTime->from_epoch(epoch => timelocal_add($dt->epoch));
say "\nWintertime 2023";
my $dt2 = DateTime->new(year => 2023, month => 10, day => 29, time_zone => 'Europe/Brussels');
say $dt2;
say "Datetime +1day";
say $dt2->add(days => 1);
say "Fhem +1day (WRONG)";
say DateTime->from_epoch(epoch => timelocal_add($dt2->epoch));
Result:
Summertime 2023
2023-03-26T00:00:00
Datetime +1day
2023-03-27T00:00:00
Fhem +1day (WRONG)
2023-03-27T22:00:00
Wintertime 2023
2023-10-29T00:00:00
Datetime +1day
2023-10-30T00:00:00
Fhem +1day (WRONG)
2023-10-30T23:00:00This is my fourth year as a FHEM user and the 3rd module with a DST bug.
I guess next year history will repeat itself. ;D
Look at all the modules using 86400 :P
grep -r --count 86400 FHEM | grep -v :0
FHEM/73_ElectricityCalculator.pm:2
FHEM/98_rain.pm:2
FHEM/00_CUL.pm:1
FHEM/96_allowed.pm:1
FHEM/00_TCM.pm:2
FHEM/73_WaterCalculator.pm:3
FHEM/38_netatmo.pm:1
FHEM/98_HourCounter.pm:2
FHEM/60_allergy.pm:2
FHEM/42_SMARTMON.pm:2
FHEM/00_KM271.pm:2
FHEM/10_EnOcean.pm:6
FHEM/90_at.pm:3
FHEM/01_FHEMWEB.pm:1
FHEM/lib/AttrTemplate/mqtt2.template:3
FHEM/lib/AttrTemplate/httpmod.template:7
FHEM/57_CALVIEW.pm:3
FHEM/13_KS300.pm:2
FHEM/95_Astro.pm:7
FHEM/98_GoogleAuth.pm:1
FHEM/10_SchellenbergHandle.pm:2
FHEM/51_MOBILEALERTS.pm:1
FHEM/98_alarmclock.pm:4
FHEM/00_SIGNALduino.pm:1
FHEM/93_DbLog.pm:6
FHEM/21_N4HMODULE.pm:3
FHEM/98_statistics.pm:3
FHEM/92_FileLog.pm:7
FHEM/89_HEATRONIC.pm:4
FHEM/89_FULLY.pm:3
FHEM/74_HusqvarnaAutomower.pm:1
FHEM/98_uptime.pm:1
FHEM/44_S7.pm:2
FHEM/72_FB_CALLLIST.pm:4
FHEM/98_JsonMod.pm:1
FHEM/98_TRAFFIC.pm:2
FHEM/98_DOIF.pm:2
FHEM/23_LUXTRONIK2.pm:3
FHEM/10_FBDECT.pm:2
FHEM/50_SSFile.pm:2
FHEM/00_THZ.pm:25
FHEM/73_GasCalculator.pm:3
FHEM/94_PWM.pm:2
FHEM/10_ZWave.pm:1
FHEM/47_OBIS.pm:3
FHEM/95_holiday.pm:3
FHEM/95_PostMe.pm:1
FHEM/42_SYSMON.pm:4
FHEM/21_OWCOUNT.pm:1
FHEM/88_HMCCU.pm:1
FHEM/98_rssFeed.pm:2
FHEM/RESIDENTStk.pm:10
FHEM/26_KM273.pm:1
FHEM/97_TrashCal.pm:1
FHEM/99_Utils.pm:1
FHEM/74_Nmap.pm:2
FHEM/55_DWD_OpenData.pm:5
FHEM/95_YAAHM.pm:25
FHEM/98_SVG.pm:14
FHEM/98_DOIFtools.pm:3
FHEM/98_average.pm:2
FHEM/99_SUNRISE_EL.pm:5
FHEM/96_Snapcast.pm:1
FHEM/00_HMLAN.pm:1
FHEM/57_Calendar.pm:11
FHEM/74_XiaomiBTLESens.pm:1
FHEM/10_GFPROBT.pm:1
FHEM/93_DbRep.pm:42
FHEM/57_SSCal.pm:10
Hi Nestor
Zitat von: Nestor am 03 November 2022, 18:11:50
@Sailor; You still have some work to do...
There are still 2 incorrect timers in Gas en WaterCalc and 86400 comparison will not be correct on the 2 DST switch days.
I fixed it on all 3. Will test it over midnight and check it in as long ther are no errors tonight.
Regards
Sailor
@Nestor I'm afraid I'm not a developer, the maintainer of each module would have to fix the issue.
I do wonder though, why such functionality is not provided by the FHEM basecode, apparently lots of modules could (and should) use the same code.
Zitat von: KyleK am 05 November 2022, 19:20:07
I do wonder though, why such functionality is not provided by the FHEM basecode, apparently lots of modules could (and should) use the same code.
As a matter of fact, its just 4 lines of code:
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
my $EpochThisMidnight = timelocal(0,0,0,$mday ,$mon,$year);
my $EpochNextMidnight = timelocal(0,0,0,$mday+1,$mon,$year);
my $SecondsToday = $EpochNextMidnight - $EpochThisMidnight;
I do not see a reason, why this code cannot be implemented by each module author directly.
Best reards
Sailor
Dear All
New versions for all 3 Calculators checked in.
Regards
Sailor
Zitat von: Nestor am 03 November 2022, 18:11:50
Look at all the modules using 86400 :P
I'm quite sure, that's not the complete picture, as some might use DAYSECONDS constant for the same purpose...
On the other hand, I'm also pretty sure, there's some false positives on the resulting list for both of the grep variants... (especially the code of statistics should be ok, and in other cases, it's just some checks or actions (the .template-things), if they happen once every day or every 24 hours...
@Sailor,
Unfortunately in your last commit you changed
timelocal_nocheck(0,0,0,$mday+1,$mon,$year) to
timelocal(0,0,0,$mday+1,$mon,$year) but this does not work on the last day of the month.
my $ts=1669836392; # Wed Nov 30 2022 19:26:32 GMT+0000
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($ts);
say Time::Local::timelocal(0,0,0,$mday+1,$mon,$year)Result:
Day '31' out of range 1..30 at test.pl line 9.
Removed cmd 1572: perl test.pl
You have to use
timelocal_nocheck as suggested by Beta-User in the 2nd post in this topic.
The Perl docs have the following to say, about
timelocal_nocheck so I believe it is more like a hack but it works?
ZitatIf you supply data which is not valid (month 27, second 1,000) the results will be unpredictable (so don't do that).
https://perldoc.perl.org/Time::Local#timelocal_nocheck()-and-timegm_nocheck()
Zitat von: Beta-User am 06 November 2022, 10:44:14
On the other hand, I'm also pretty sure, there's some false positives on the resulting list for both of the grep variants... (especially the code of statistics should be ok, and in other cases, it's just some checks or actions (the .template-things), if they happen once every day or every 24 hours...
Look over here, wow, somebody already investigated this and warned about using ONE_DAY constants and timelocal() with DST timezones. Incredible!
https://perldoc.perl.org/perlfaq4#How-do-I-find-yesterday's-date?
DateTime module was released in 2003 ;D. Perfect handling of DST, Timezones and date/time arithmetic.
https://metacpan.org/pod/DateTime
Zitat von: Nestor am 07 November 2022, 21:52:01
DateTime module was released in 2003 ;D . Perfect handling of DST, Timezones and date/time arithmetic.
https://metacpan.org/pod/DateTime (https://metacpan.org/pod/DateTime)
Afaik, DateTime is not yet part of the Core Modules, so this would require some additional actions from user side....
Apart from that, "good" usage of (real Perl) Modules is not very common in FHEM. As soon as packaging FHEM-modules would be more common, one really could think about some more standardisation wrt. this subject.
As "good" workarounds are (relatively) well known, I'd stick with the recommendation to use one of the code snipplets I already tried to point to (and make sure, they are used in a save way)...
Well
My research confirms your suggestion, that DateTime seems to be the only solution.
The Code would look like
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
my $ObjectNow = DateTime->new(
year => $year+1900,
month => $mon+1,
day => $mday,
hour => 0,
minute => 0,
second => 0,
time_zone => 'Europe/Berlin',
);
my $EpochNow = $ObjectNow->epoch();
my $ObjectTomm = $ObjectNow->add(days => 1);
my $EpochTomm = $ObjectTomm->epoch();
my $EpochDiff = $EpochTomm - $EpochNow;
If you like to double check it, than I am going to implement it in the Counter!
My tests
26.03.2023
2022.11.08 18:02:44.048 1: myIonosApi - GetHostByName _______________________________________________________________________________
2022.11.08 18:02:44.048 1: myIonosApi - GetHostByName - EpochNow : 1679785200
2022.11.08 18:02:44.048 1: myIonosApi - GetHostByName - EpochTomm : 1679868000
2022.11.08 18:02:44.048 1: myIonosApi - GetHostByName - EpochDiff : 82800
29.10.2023
2022.11.08 18:04:08.521 1: myIonosApi - GetHostByName _______________________________________________________________________________
2022.11.08 18:04:08.522 1: myIonosApi - GetHostByName - EpochNow : 1698530400
2022.11.08 18:04:08.525 1: myIonosApi - GetHostByName - EpochTomm : 1698620400
2022.11.08 18:04:08.525 1: myIonosApi - GetHostByName - EpochDiff : 90000
31.10.2023
2022.11.08 18:04:53.634 1: myIonosApi - GetHostByName _______________________________________________________________________________
2022.11.08 18:04:53.634 1: myIonosApi - GetHostByName - EpochNow : 1698706800
2022.11.08 18:04:53.634 1: myIonosApi - GetHostByName - EpochTomm : 1698793200
2022.11.08 18:04:53.634 1: myIonosApi - GetHostByName - EpochDiff : 86400
Thanks a lot!
Regards
Sailor
You don't need localtime and can simplify a bit with object chaining.
Maybe implement the timezone as a device attr, since it can be different for users. There is no global timezone support in Fhem I believe.
use 5.030;
use strict;
use warnings;
use DateTime;
my $tz = 'Europe/Brussels'; # implement as device attribute ?
my $dt = DateTime->now()->set_time_zone($tz)->set_hour(0)->set_minute(0)->set_second(0);
say $dt;
say $dt->add(days => 1);
Result:
2022-11-08T00:00:00
2022-11-09T00:00:00
Hi Nestor
Zitat von: Nestor am 08 November 2022, 18:23:06
You don't need localtime and can simplify a bit with object chaining.
Ok, fair enough. I used you shorter version
Zitat von: Nestor am 08 November 2022, 18:23:06
Maybe implement the timezone as a device attr, since it can be different for users. There is no global timezone support in Fhem I believe.
I am obtaining the timzone from the system by
my $TimeZone = DateTime::TimeZone->new( name => 'local' )->name();I am testing the modules over night and then I will check them in.
Regards
Sailor
Ein herzerfrischendes "Moin" vom Achtern Diek vorweg!
Aufgrund eines Bugs in den
73_ElectricityCalculator
73_GasCalculator
73_WaterCalculator
mit den Anzahl der Sekunden pro Tag während der Zeitumstellung sowie dem Start der Mitternachtsroutine, bin ich gezwungen die Bibliothek "DateTime" zu verwenden.
Daher bitte unbedingt vor dem Update im linux shell die Bibliohek DateTime nachinstallieren:
sudo cpan install DateTime
ausfuehren!
Ansonsten schmiert Euch euer fhem ab und legt sich in eine Dauer-Startschleife.
Sorry für die Unannehmlichkeiten, aber es ging leider nicht anders.
Gruß
Sailor
Doch... nocheck!
Zitat von: Sailor am 08 November 2022, 20:31:32
my $TimeZone = DateTime::TimeZone->new( name => 'local' )->name();
You can use the string "local" directly (instead of creating a TimeZone object and converting to string).
my $dt = DateTime->now()->set_time_zone('local');
say $dt->time_zone;
Result:
DateTime::TimeZone::Europe::Brussels=HASH(0x5628649f3a00)
Können wir bitte in Ruhe nochmal checken, welche Lösung ggf. Sinn macht, ohne für die kommenden Monate einen unabsehbaren support-Aufwand zu generieren?
Zitat von: Sailor am 08 November 2022, 20:38:17
Ansonsten schmiert Euch euer fhem ab und legt sich in eine Dauer-Startschleife.
Sorry für die Unannehmlichkeiten, aber es ging leider nicht anders.
Sorry Herr Nachbar, aber das ist Quatsch. Du kannst doch einfach prüfen, ob das benötigte Modul geladen werden kann und wenn das nicht der Fall ist, eine Logmeldung ausgeben und die Verarbeitung beenden.
Da muss man doch keine Dauerschleife für das gesamte System provozieren.
ZitatKönnen wir bitte in Ruhe nochmal checken, welche Lösung ggf. Sinn macht, ohne für die kommenden Monate einen unabsehbaren support-Aufwand zu generieren?
Sehe ich ähnlich. Nach Nestors Analyse nutzen ja eine Menge Module einen "Tageswechselcheck" per 86.400s. Dann sollte aber auch eine allgemeine Lösung(zentrale Funktion) gefunden und mit den anderen maintainern diskutiert werden. Dauert zwar länger, aber eine Hals-über-Kopf-Lösung ist doch gar nicht notwendig. Das "Problem" kommt doch frühestens Ende März wieder. :-\
Zitat von: Sailor am 08 November 2022, 20:38:17
Ein herzerfrischendes "Moin" vom Achtern Diek vorweg!
Aufgrund eines Bugs in den
73_ElectricityCalculator
73_GasCalculator
73_WaterCalculator
mit den Anzahl der Sekunden pro Tag während der Zeitumstellung sowie dem Start der Mitternachtsroutine, bin ich gezwungen die Bibliothek "DateTime" zu verwenden.
Daher bitte unbedingt vor dem Update im linux shell die Bibliohek DateTime nachinstallieren:
sudo cpan install DateTime
ausfuehren!
Ansonsten schmiert Euch euer fhem ab und legt sich in eine Dauer-Startschleife.
Sorry für die Unannehmlichkeiten, aber es ging leider nicht anders.
Gruß
Sailor
Viele sind wenig bedarft im Umgang mit dem OS. Und viele fahren mit Debian und nutzen apt zur "Systempflege". DateTime ist wohl in libdatetime-perl enthalten und dann braucht es kein cpan zur Installation.
Grüße Markus
Hi BetaUser
Zitat von: Beta-User am 08 November 2022, 20:45:46
Doch... nocheck!
Habe sie noch nicht eingecheckt.
Ich will da noch ein wenig Zeit in Land streichen lassen...
Es gibt hier noch interessante Verbesserungsvorschläge von betateilchen und Nestor die ich wohl erst mit einarbeiten will.
Gruß
Sailor
Hallo betateilchen
Zitat von: betateilchen am 08 November 2022, 22:10:16
Sorry Herr Nachbar, aber das ist Quatsch. Du kannst doch einfach prüfen, ob das benötigte Modul geladen werden kann und wenn das nicht der Fall ist, eine Logmeldung ausgeben und die Verarbeitung beenden.
Da muss man doch keine Dauerschleife für das gesamte System provozieren.
Seit 2 Jahren suche ich mir im fhem - Developer Board nach genau dieser Möglichkeit einen Wolf.
Das ist generell genau ein Problem mit allen Modulen und mich hat es ohnehin gewundert, warum das nicht auf übergeordneter Ebene bereits abgefangen wird.
Dort könnte man dann auch gleich die entsprechenden Module automatisch nachinstallieren.
Wenn du mir ein Code-Schnipsel nennen oder auch nur einen Hinweis zum Lesen geben kannst wie man dieses Problem löst, dann hast du bei mir einen Whiskey gut. ;)
Gruss
Sailor
Hi Markus
Zitat von: KölnSolar am 09 November 2022, 06:53:30
Sehe ich ähnlich. Nach Nestors Analyse nutzen ja eine Menge Module einen "Tageswechselcheck" per 86.400s. Dann sollte aber auch eine allgemeine Lösung(zentrale Funktion) gefunden und mit den anderen maintainern diskutiert werden. Dauert zwar länger, aber eine Hals-über-Kopf-Lösung ist doch gar nicht notwendig. Das "Problem" kommt doch frühestens Ende März wieder. :-\
Viele sind wenig bedarft im Umgang mit dem OS. Und viele fahren mit Debian und nutzen apt zur "Systempflege". DateTime ist wohl in libdatetime-perl enthalten und dann braucht es kein cpan zur Installation.
Da gebe ich dir vollkommen Recht!
Aus meiner Sicht sollte es in der fhem.pl einige nützliche Funktionen mehr geben.
Zum Beispiel die besagte "
getSecondsOfDay()" mit der Aufruf-Option
getSecondsOfDay(0) -> heute
getSecondsOfDay(+1) -> Morgen
getSecondsOfDay("2023-03-26") -> Vom 26. März 2023
Damit wären die 86400 endgültig Mausetot!
Anderes Beispiel zum Starten von Mitternachtsroutinen ein "
getEpochOfMidnight()"
Diese werden beim InternalTimer benötigt.
Gruß
Sailor
Hi Sailor,
bin zwar zu weit weg für den Whisky(den kannst Du ja Udo rüber bringen), aber so mach ich es
eval {require Time::HiRes; 1;}
or do {
return "......Module Time:HiRes not installed. Check perl libraries'";
};
ZitatDa gebe ich dir vollkommen Recht!
Schön. Machst Du dann einen neuen Faden im Development Bereich ?
Grüße Markus
Hi Markus
Zitat von: KölnSolar am 09 November 2022, 12:01:37
Hi Sailor,
bin zwar zu weit weg für den Whisky(den kannst Du ja Udo rüber bringen)
Der wird sich sicher freuen!
Zitat von: KölnSolar am 09 November 2022, 12:01:37
so mach ich es
eval {require Time::HiRes; 1;}
or do {
return "......Module Time:HiRes not installed. Check perl libraries'";
};
OK, hatte immer wieder mit dem Standard Modul
ExtUtils::Installed eingelesen.
Aber die Frage die sich bei beiden Lösungen stellt ist die, ob ich das Ganze am geschicktesten
über oder
in die Subfunktion "
X_Initialize()" stelle...
Zitat von: KölnSolar am 09 November 2022, 12:01:37
Schön. Machst Du dann einen neuen Faden im Development Bereich ?
Sobald ich dieses Problem gelöst habe, mache ich mich ran...
Die derzeitig eingecheckten Module werden wohl am 30.11. Schwierigkeiten bereiten weil sie versuchen den 31.11. zu berechnen.
Ein saudummer Fehler meinerseits im letzten Update.
Bis dahin habe ich noch 21 Tage Zeit...
Gruß
Sailor
ZitatAber die Frage die sich bei beiden Lösungen stellt ist die, ob ich das Ganze am geschicktesten über oder in die Subfunktion "X_Initialize()" stelle...
Initialize, Define... lasse ich durchlaufen. Dann hat der Anwender wenigstens sein device anlegen können(schlimmstenfalls ja ein altes device, welches dann nach einem update/restart "plötzlich" verschwunden ist. Und man merkt es erst einmal nicht.
Erst wenn ich das Modul bei einer Interaktion benötige, prüfe ich und der User sieht die Meldung ggfs. hoffentlich online.
Ist bei Dir natürlich anders, da es ja keine Interaktion gibt. Ich würde das Log fluten.....
Grüße Markus
Zitat von: Sailor am 09 November 2022, 07:22:24
Hi BetaUser
Habe sie noch nicht eingecheckt.
So war es nicht gemeint, das bezog sich auf die "nocheck"-Variante von timelocal...
Für die Kommandozeile:
{ my $ts=1669836392;; my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($ts);; return localtime(Time::Local::timelocal_nocheck(0,0,0,$mday+1,$mon,$year)) }
Zitat von: Beta-User am 08 November 2022, 21:54:31
ohne für die kommenden Monate einen unabsehbaren support-Aufwand zu generieren?
Ergänzend: ...ein Ladung irritierter User wie in https://forum.fhem.de/index.php/topic,47909.msg1244457.html#msg1244457 (https://forum.fhem.de/index.php/topic,47909.msg1244457.html#msg1244457) und dem folgenden Beitrag zu generieren, obwohl diese vermeintlich dringende Notfallmaßnahme jetzt doch erst mal noch gar nicht sein muss (und wenn, dann ggf. schneller über das OS-Paket zu lösen wäre!).
Konkreter Vorschlag: Streiche die betreffenden Beiträge durch und mach einen Vermerk drunter, dass weitere News dann bei Gelegenheit folgen werden...
Zitat von: Sailor am 09 November 2022, 07:25:16
Wenn du mir ein Code-Schnipsel nennen oder auch nur einen Hinweis zum Lesen geben kannst wie man dieses Problem löst
Das wird doch in einigen Modulen bereits gemacht, zum Beispiel in 55_InfoPanel.pm zur Prüfung, ob bestimmte Funktionen verwendet werden können oder nicht.
sub InfoPanel_Initialize {
my ($hash) = @_;
## no critic
eval "use MIME::Base64" ;
$useImgTools = 0 if($@);
Log3(undef,4,"InfoPanel: MIME::Base64 missing.") unless $useImgTools;
eval "use Image::Info qw(image_info dim)";
$useImgTools = 0 if($@);
Log3(undef,4,"InfoPanel: Image::Info missing.") unless $useImgTools;
--
Zitat von: KölnSolar am 09 November 2022, 06:53:30
DateTime ist wohl in libdatetime-perl enthalten und dann braucht es kein cpan zur Installation.
Via apt zu installieren wäre auch mein präferierter Weg. Das wäre dann dieses Paket?
https://packages.debian.org/bullseye/libdatetime-perl (https://packages.debian.org/bullseye/libdatetime-perl)
https://packages.debian.org/buster/libdatetime-perl (https://packages.debian.org/buster/libdatetime-perl)
Cpan Installation ist tw. schwierig. Beim nativ installierten FHEM wohl weniger ein Problem - wird nur einmalig durchgeführt. Wer aber FHEM im Docker einsetzt, muss wg. preinstall per cpan relativ lange Startzeiten in Kauf nehmen - und zwar jedes Mal wenn der Container aktualisiert wird oder aus anderen Gründen ein Neustart vom Container fällig wurde (geänderte Parameter usw.). Kann der Container nix für - cpan ist braucht halt Zeit.
Preinstall via apt geht ratzfatz. Natürlich starte ich den Container nicht dauernd neu, also kein Riesenthema.
Wenn ich es richtig verstehe, ist das Paket bereits on board:
root@1bee5d8d8f05:/opt/fhem# apt list --installed | grep libdate
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libdatetime-format-builder-perl/stable,now 0.8300-1 all [installed,automatic]
libdatetime-format-iso8601-perl/stable,now 0.16-1 all [installed,automatic]
libdatetime-format-strptime-perl/stable,now 1.7800-1 all [installed]
libdatetime-locale-perl/stable,now 1:1.31-1 all [installed,automatic]
libdatetime-perl/stable,now 2:1.54-1 armhf [installed]
libdatetime-timezone-perl/stable-updates,now 1:2.47-1+2022e all [installed,automatic]
Hi rob
Zitat von: rob am 10 November 2022, 10:08:47
Wenn ich es richtig verstehe, ist das Paket bereits on board:
Also bei mir war das definitiv nicht der Fall! :-\
Gruß
Sailor
Habe mir jetzt mal folgenden Check ueberlegt.
Sobald der Bullshit gecheckt wird, wird init abgebrochen aber fhem stürzt nicht ab.
Und man kann die gewünschten Module schön untereinander auflisten.
##START###### Initialize module ##############################################################################START####
sub IONOSAPI_Initialize($) {
my ($hash) = @_;
### Checking whether all required perl libaries are installed. ###
my $listUseLibaries = "
JSON
JSON::Parse
HttpUtils
Net::DNS
NetAddr::IP
Big::Bullshit
DateTime
DateTime::TimeZone
";
# Transform Tabs in spaces, remove exessive blanks, leading blanks and split into array
$listUseLibaries =~ s/(.*?)\t/$1 /g;
$listUseLibaries =~ s/[\h\v]+/ /g;
$listUseLibaries =~ s/^\s+//;
my @UseLibaries = split (/ /, $listUseLibaries);
# Check each wanna be used libary for unavailability
foreach my $Libary (@UseLibaries) {
eval "use " . $Libary;
if (length($@) == 0) {
Log3 undef, 1, "IONOSAPI - Successfully Installed Perl Module : " . $Libary
}
else {
Log3 undef, 1, "IONOSAPI - Cannot find " . $Libary . " in \@INC. Please install the Perl libary first. Initialization of IONOSAPI aborted";
return
}
}
Bei meinem Test-Modul klappt das sehr gut.
2022.11.10 22:08:18.485 1: IONOSAPI - Successfully Installed Perl Module : JSON
2022.11.10 22:08:18.488 1: IONOSAPI - Successfully Installed Perl Module : JSON::Parse
2022.11.10 22:08:18.489 1: IONOSAPI - Successfully Installed Perl Module : HttpUtils
2022.11.10 22:08:18.603 1: IONOSAPI - Successfully Installed Perl Module : Net::DNS
2022.11.10 22:08:18.635 1: IONOSAPI - Successfully Installed Perl Module : NetAddr::IP
2022.11.10 22:08:18.636 1: IONOSAPI - Cannot find Big::Bullshit in @INC. Please install the Perl libary first. Initialization of IONOSAPI aborted
Gruß
Sailor
Zitat von: Sailor am 10 November 2022, 22:10:16
...Also bei mir war das definitiv nicht der Fall! :-\ ...
Benutzt Du Docker? Bei mir ist es das offizielle latest Image. Da scheint das Modul bereits dabei zu sein.
Bei nativen Installationen dann wohl manuell einmalig nachzuinstallieren.
VG
rob
Zitat von: Sailor am 10 November 2022, 22:14:08
Habe mir jetzt mal folgenden Check ueberlegt.
a) Warum bitte hängst du weiter der Überlegung nach, dass unbedingt ein Check wegen eines Moduls erforderlich wäre? Mach den Code mit der einen geänderten Zeile sauber und du brauchst nicht alle User deiner Module dazu zu nötigen, irgendwelche Klimmzüge zu machen!
b) Vorgeschlagen war ein Block-eval. Gibt es irgend einen nachvollziehbaren Grund dafür, dass du das in ein String-eval umbauen mußt?
(Popcorn?)
Zitat von: Sailor am 10 November 2022, 22:14:08
Habe mir jetzt mal folgenden Check ueberlegt.
Dir ist hoffentlich klar, dass Du mit diesem Bullshit alles noch schlimmer machst?
Hallo Beta-User
Zitat von: Beta-User am 10 November 2022, 23:09:48
a) Warum bitte hängst du weiter der Überlegung nach, dass unbedingt ein Check wegen eines Moduls erforderlich wäre? Mach den Code mit der einen geänderten Zeile sauber und du brauchst nicht alle User deiner Module dazu zu nötigen, irgendwelche Klimmzüge zu machen!
Weil timelocal, timelocal_modern und schon dar nicht timelocal_nocheck keine DST-korrekte Addierung eines Tages vornehmen koennen.
Zumindest hat sich das mir noch nicht erschlossen. Es sei denn du zeigst mit ein Code-Schnipsel der das kann.
Zitat von: Beta-User am 10 November 2022, 23:09:48
b) Vorgeschlagen war ein Block-eval. Gibt es irgend einen nachvollziehbaren Grund dafür, dass du das in ein String-eval umbauen mußt?
beta-teilchen hat einen String eval vorgeschlagen:
Zitat von: betateilchen am 09 November 2022, 20:46:02
eval "use MIME::Base64" ;
$useImgTools = 0 if($@);
Log3(undef,4,"InfoPanel: MIME::Base64 missing.") unless $useImgTools;
Diesen habe ich nur entsprechend weiter entwickelt.
Wie dem auch sei.
Der Code
eval {
use utf8;
use JSON;
use JSON::Parse;
use HttpUtils;
use Net::DNS;
use NetAddr::IP;
use Big::Bullshit;
use DateTime;
use DateTime::TimeZone;
1;
}
or do
{
### Log Entry for debugging purposes
Log3 undef, 1, "IONOSAPI - Cannot find one of the libaries in \@INC. Please install the Perl libary first. Initialization of 73_IONOSAPI.pm aborted!";
return;
};
kommt gar nicht erst zum eval, weil er bereits vorher meckert, dass die entsprechende Libary nicht installiert hat.
Zumindest stuerzt fhem beim startup nicht ab.
2022.11.11 09:25:11.117 1: reload: Error:Modul 73_IONOSAPI deactivated:
Can't locate Big/Bullshit.pm in @INC (you may need to install the Big::Bullshit module) (@INC contains: ./FHEM/lib ./lib ./ .//lib .//FHEM . /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/aarch64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/aarch64-linux-gnu/perl-base .//FHEM/lib) at .//FHEM/73_IONOSAPI.pm line 87, <$fh> line 135.
BEGIN failed--compilation aborted at .//FHEM/73_IONOSAPI.pm line 87, <$fh> line 135.
Dann kann man sich noch die "or do" sparen.
Gruß
Sailor
Zitat von: betateilchen am 11 November 2022, 02:12:30
Dir ist hoffentlich klar, dass Du mit diesem Bullshit alles noch schlimmer machst?
Der von dir vorgeschlagene Code
Zitat von: betateilchen am 09 November 2022, 20:46:02
eval "use MIME::Base64" ;
$useImgTools = 0 if($@);
Log3(undef,4,"InfoPanel: MIME::Base64 missing.") unless $useImgTools;
bricht das Laden und define des Moduls / Device nicht ab.
Das Modul und das Device laden erst einmal normal weiter. So weit so gut.
Aber sobald also die fragliche Funktion, welche die nicht vorhandenen Libary eigentlich bereit stellen soll, aufgerufen wird, stürzt fhem ab bzw. startet neu.
Wenn diese Funktion bereits im weiteren Verlauf der e.g. X_define verwendet werden, gibt es eine undendliche Reboot-Schleife.
Gruß
Sailor
Zitat von: Beta-User am 09 November 2022, 13:20:04
So war es nicht gemeint, das bezog sich auf die "nocheck"-Variante von timelocal...
Für die Kommandozeile:
{ my $ts=1669836392;; my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($ts);; return localtime(Time::Local::timelocal_nocheck(0,0,0,$mday+1,$mon,$year)) }
Paßt man das für den Oktober an, kommt man auf:
{ my $ts=1669836392-32*DAYSECONDS;; my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($ts);; return localtime(Time::Local::timelocal_nocheck(0,0,0,$mday+1,$mon,$year)) }Dann mal die "32" ersetzen durch "31" bzw. "33".
Du kannst es gerne für den März selbst anpassen...
Dass betateilchen einen String-eval aus einem bestehenden Modul gepostet hatte, ist ja prinzipiell ok, aber der funktional gleichwertige Schnippsel von KölnSolar ist an dem Punkt schon weiter (auch wenn man über "or do" auch streiten kann, genauso wie über das "unless", das in den Modulen, die ich unter die Fittiche genommen habe immer die "komischsten" Code-Teile komplett unleserlich gemacht hat - nimm eine zweite Bedingung dazu, negiere eine und es wird zum Hirnverdreher...).
Und dass man das Modul im Fehlerfall nicht normal durchstarten kann, sondern einfach nach dem Laden "tot" stellen muss, versteht sich doch von selbst, oder? (Also keine timer anlegen, set-Befehle ausführen, usw.!)
Nachtrag: Der Block-eval war mit einer anderen Prüfung!
Mein Kommentar bezog sich nicht darauf, dass Du die Prüfung nun eingebaut hast, sondern vielmehr auf die Art und Weise, WIE Du das umgesetzt hast.
Zitat von: Sailor am 10 November 2022, 22:14:08
Und man kann die gewünschten Module schön untereinander auflisten.
Es geht doch nicht um "schön". Und Deine gesamte regex-Orgie, nur um aus "schön" dann wieder "funktional" zu machen, ist einfach haarsträubend.
my @UseLibaries = ("JSON",
"JSON::Parse",
"HttpUtils");
liefert übrigens direkt das gewünschte Array.
Noch eleganter geht es so:
my @UseLibaries = qw( JSON
JSON::Parse
HttpUtils );
Völlig egal, ob Du das in eine Zeile schreibst oder "schön untereinander - das gesamte regexen ist damit unnötig.
Davon, dass bei Dir in UseLibaries sogar noch ein r fehlt, will ich mal gar nicht reden.
Vielleicht solltest Du Dir doch mal irgendwann ein paar perl-Grundlagen aneignen, bevor Du sämtliche Dir gegebenen Ratschläge einfach ignorierst und weiter vor Dich hin wurschtelst.
Hallo Beta-User
Zitat von: Beta-User am 11 November 2022, 09:31:15
Paßt man das für den Oktober an, kommt man auf:
{ my $ts=1669836392-32*DAYSECONDS;; my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($ts);; return localtime(Time::Local::timelocal_nocheck(0,0,0,$mday+1,$mon,$year)) }
Ok, hast gewonnen!
# my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
my $mday = 29;
my $mon = 9;
my $year = 2023;
my $EpochThisMidnight = Time::Local::timelocal_nocheck(0,0,0,$mday ,$mon,$year);
my $EpochNextMidnight = Time::Local::timelocal_nocheck(0,0,0,$mday+1,$mon,$year);
my $SecondsToday = $EpochNextMidnight - $EpochThisMidnight;
### Log Entry for debugging purposes
Log3 $name, 1, $name. " - GetHostByName _______________________________________________________________________________";
Log3 $name, 1, $name. " - GetHostByName - ReadThisMidnight : " . localtime($EpochThisMidnight);
Log3 $name, 1, $name. " - GetHostByName - ReadNextMidnight : " . localtime($EpochNextMidnight);
Log3 $name, 1, $name. " - GetHostByName - EpochThisMidnight : " . $EpochThisMidnight;
Log3 $name, 1, $name. " - GetHostByName - EpochNextMidnight : " . $EpochNextMidnight;
Log3 $name, 1, $name. " - GetHostByName - SecondsToday : " . $SecondsToday;
2022.11.11 10:31:19.737 1: myIonosApi - GetHostByName _______________________________________________________________________________
2022.11.11 10:31:19.737 1: myIonosApi - GetHostByName - ReadThisMidnight : Wed Nov 30 00:00:00 2022
2022.11.11 10:31:19.737 1: myIonosApi - GetHostByName - ReadNextMidnight : Thu Dec 1 00:00:00 2022
2022.11.11 10:31:19.737 1: myIonosApi - GetHostByName - EpochThisMidnight : 1669762800
2022.11.11 10:31:19.738 1: myIonosApi - GetHostByName - EpochNextMidnight : 1669849200
2022.11.11 10:31:19.738 1: myIonosApi - GetHostByName - SecondsToday : 86400
2022.11.11 10:32:16.087 1: myIonosApi - GetHostByName _______________________________________________________________________________
2022.11.11 10:32:16.088 1: myIonosApi - GetHostByName - ReadThisMidnight : Sun Mar 26 00:00:00 2023
2022.11.11 10:32:16.088 1: myIonosApi - GetHostByName - ReadNextMidnight : Mon Mar 27 00:00:00 2023
2022.11.11 10:32:16.089 1: myIonosApi - GetHostByName - EpochThisMidnight : 1679785200
2022.11.11 10:32:16.089 1: myIonosApi - GetHostByName - EpochNextMidnight : 1679868000
2022.11.11 10:32:16.089 1: myIonosApi - GetHostByName - SecondsToday : 82800
2022.11.11 10:35:09.118 1: myIonosApi - GetHostByName _______________________________________________________________________________
2022.11.11 10:35:09.118 1: myIonosApi - GetHostByName - ReadThisMidnight : Sun Oct 29 00:00:00 2023
2022.11.11 10:35:09.124 1: myIonosApi - GetHostByName - ReadNextMidnight : Mon Oct 30 00:00:00 2023
2022.11.11 10:35:09.124 1: myIonosApi - GetHostByName - EpochThisMidnight : 1698530400
2022.11.11 10:35:09.124 1: myIonosApi - GetHostByName - EpochNextMidnight : 1698620400
2022.11.11 10:35:09.124 1: myIonosApi - GetHostByName - SecondsToday : 90000
Nehme ich dann so auf und verzichte auf DateTime.
Gruß
Sailor
Zitat von: Sailor am 11 November 2022, 10:37:49
Ok, hast gewonnen!
...es ging nicht um's gewinnen, sondern darum, eine (für die user!) möglichst unaufwändige funktionierende Lösung zu haben.
Wer bessere Alternativen kennt, darf gerne den Pott haben!
(zur Klarstellung: dieser "nocheck"-Schnippsel stammt auch nicht von mir, sondern von jemandem, der vor mir WeekdayTimer (?) maintaint hat!)
...warum eigentlich nicht mit Bordmitteln? Rudi hat das schon in 90_at.pm und 92_FileLog.pm gelöst....
eine "generalisierte" form für 99_Utils:
# calculate number of seconds for given day
# input: 'YYYY-MM-DD HH:MM:SS' (like FHEM DateTime) or unix-Timestamp
# return: Numer of seconds for given day: 86400 (normal), 82800 or 90000 on DST day!
sub secondsToday {
my $ts = shift;
$ts = int(time()) if ((! defined($ts)) || $ts eq ''); # no arg given - today
my $secToday = 0;
if ($ts =~ /^[\d]+$/ix) { # unix TS
$ts = FmtDateTime($ts); # convert unix TS into FHEM DateTime
}
my ($fy,$fm,$fd, undef) = split(/\D/,$ts,4);
my $sec = time_str2num("$fy-$fm-$fd 00:00:00");
my $secTo = time_str2num("$fy-$fm-$fd 23:59:59") +1;
$secToday = $secTo - $sec;
return $secToday;
}
geht sicher noch eleganter....
l.g. erwin
Zitat von: betateilchen am 11 November 2022, 09:32:04
Noch eleganter geht es so:
my @UseLibaries = qw( JSON
JSON::Parse
HttpUtils );
Naja, mit der Liste stoesst du dann aber an die Grenzen von qw()
Crypt::NaCl::Sodium qw( :utils )
Crypt::Argon2 qw/argon2i_raw/
File::Spec::Functions ':ALL'
Gruss
Sailor
Zitat von: erwin am 11 November 2022, 11:40:43
...warum eigentlich nicht mit Bordmitteln? Rudi hat das schon in 90_at.pm und 92_FileLog.pm gelöst....
eine "generalisierte" form für 99_Utils:
# calculate number of seconds for given day
# input: 'YYYY-MM-DD HH:MM:SS' (like FHEM DateTime) or unix-Timestamp
# return: Numer of seconds for given day: 86400 (normal), 82800 or 90000 on DST day!
sub secondsToday($) {
my $ts = shift;
my $secToday = 0;
if ($ts =~ /^[\d]+$/ix) { # unix TS
$ts = FmtDateTime($ts); # convert unix TS into FHEM DateTime
}
my ($fy,$fm,$fd, undef) = split(/\D/,$ts,4);
my $sec = time_str2num("$fy-$fm-$fd 00:00:00");
my $secTo = time_str2num("$fy-$fm-$fd 23:59:59") +1;
$secToday = $secTo - $sec;
return $secToday;
}
geht sicher noch eleganter....
l.g. erwin
Hallo Erwin
Stimmt, aber ich brauche auch den UNIX - Timestamp von der nächsten Mitternacht.
Insofern erschlage ich mit dem Code oben beides.
Trotzdem Danke für den Hinweis.
Gruß
Sailor
ZitatStimmt, aber ich brauche auch den UNIX - Timestamp von der nächsten Mitternacht.
der ist in meinem code versteckt unter $secTo.
l.g.erwin
Zitat von: Sailor am 11 November 2022, 12:23:40
Naja, mit der Liste stoesst du dann aber an die Grenzen von qw()
Ja, qw() vielleicht. Aber nicht an die Grenze einer direkten array-Definition
sub test{
use Data::Dumper;
my @UseLibraries = ( "Crypt::NaCl::Sodium qw( :utils )",
"Crypt::Argon2 qw/argon2i_raw/",
"File::Spec::Functions ':ALL'" );
return Dumper \@UseLibraries;
}
Aber: ich bin jetzt hier raus.
Du meinst immer noch, alles besser zu wissen und ignorierst deshalb die meisten gutgemeinten Tipps, die Dir hier gegeben werden (Beispiel: erwins Codeschnipsel, das Du Dir offenbar nichtmal genau angeschaut hast).
Zitat von: rob am 10 November 2022, 10:08:47
Wenn ich es richtig verstehe, ist das Paket bereits on board:
Bei mir ist die Library jedenfalls auch bereits installiert, nur eine ältere Version:
libdatetime-format-builder-perl/oldstable,now 0.8100-2 all [Installiert,automatisch]
libdatetime-format-iso8601-perl/oldstable,now 0.08-2 all [Installiert,automatisch]
libdatetime-format-strptime-perl/oldstable,now 1.7600-1 all [Installiert,automatisch]
libdatetime-locale-perl/oldstable,now 1:1.23-1 all [Installiert,automatisch]
libdatetime-perl/oldstable,now 2:1.50-1+b1 armhf [Installiert,automatisch]
libdatetime-timezone-perl/oldstable,now 1:2.23-1+2022e all [Installiert,automatisch]Die Version wird durch apt-get update / upgrade nicht erneuert, das ist aber ein anderes Thema, denke ich.
Zitat von: Beta-User am 09 November 2022, 17:34:59
Ergänzend: ...ein Ladung irritierter User wie in https://forum.fhem.de/index.php/topic,47909.msg1244457.html#msg1244457 (https://forum.fhem.de/index.php/topic,47909.msg1244457.html#msg1244457) und dem folgenden Beitrag zu generieren, obwohl diese vermeintlich dringende Notfallmaßnahme jetzt doch erst mal noch gar nicht sein muss (und wenn, dann ggf. schneller über das OS-Paket zu lösen wäre!).
Konkreter Vorschlag: Streiche die betreffenden Beiträge durch und mach einen Vermerk drunter, dass weitere News dann bei Gelegenheit folgen werden...
*aus gegebenem Anlass ein reminder*
M.E. wäre das weiter sinnvoll, diese Art "Tipp" als überholt zu markieren!