[Gelöst] Endlosschleife in ElectricityCalculator wegen Zeitumstellung?

[KyleK]

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?

[isy]

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.

[Beta-User]

Falls ihr einen patch vorschlagen wollt, wäre in https://forum.fhem.de/index.php/topic,123847.msg1184061.html#msg1184061 ggf. Material zu finden.

[rob]

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:

Code Auswählen Erweitern


...
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

[isy]

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.

[rob]

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

[rob]

Hab mal doch das Testsystem angeworfen und mit WaterCalc begonnen. Ja, blockt reproduzierbar.
Freezemon sagt

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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

[isy]

Guter Fund!
Ich komme heute erst am Abend zum Testen. Evtl. kann Sailor heute Abend auch mal schauen.

[rob]

Der GasCalc blockt leider auch.

Code Auswählen Erweitern


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

[isy]

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

Code Auswählen Erweitern

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

[rob]

Danke Dir.

Ja, blockt ebenfalls:

Code Auswählen Erweitern


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 
In allen drei Fällen also der MidnightTimer.

Viele Grüße
rob

[Nestor]

Code Auswählen Erweitern

        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.

[Nestor]

@rob Can you test this patch?

Code Auswählen Erweitern

--- - 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


Code Auswählen Erweitern


# 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?

[rob]

...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:

Code Auswählen Erweitern


        ### 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 
I also set the time to 23:59 what made no difference - just to keep my test procedure.

Freezemon tells me:

Code Auswählen Erweitern


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

[Sailor]

Dear Nestor, dear Rob

@rob Can you test this patch?

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 

Thanks a lot for your suggestions!!! 

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

[Sailor]

Hi rob

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.

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!

Well, the next clock change gives us a delay of almost 6 months - maybe not that urgent 

Exactly! 

Regards
    Sailor

[rob]

Moinssen.

That's excellent my dear 

Thank you very much for your quick response and great work.

Kind regards
rob

[isy]

Mni thanks to all!

[Sailor]

Moin zusammen

Eingepflegt. Sollte morgen im Update dabei sein.

@KyleK : Bitte Thread als "Gelöst" markieden

Gruß
    Sailor

[KyleK]

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?

[Nestor]

@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.

Code Auswählen Erweitern

/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:

The 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).

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:00

This is my fourth year as a FHEM user and the 3rd module with a DST bug.
I guess next year history will repeat itself.

Look at all the modules using 86400
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

[Sailor]

Hi Nestor

@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

[KyleK]

@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.

[Sailor]

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:

Code Auswählen Erweitern


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

[Sailor]

Dear All

New versions for all 3 Calculators checked in.

Regards
    Sailor

[Beta-User]

Look at all the modules using 86400

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...

[Nestor]

@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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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?

If 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()

[Nestor]

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  . Perfect handling of DST, Timezones and date/time arithmetic.
https://metacpan.org/pod/DateTime

[Beta-User]

DateTime module was released in 2003  . Perfect handling of DST, Timezones and date/time arithmetic.
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)...

[Sailor]

Well

My research confirms your suggestion, that DateTime seems to be the only solution.

The Code would look like

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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

[Nestor]

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

2022-11-08T00:00:00
2022-11-09T00:00:00

[Sailor]

Hi Nestor

You don't need localtime and can simplify a bit with object chaining.

Ok, fair enough. I used you shorter version

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

Code Auswählen Erweitern

my $TimeZone = DateTime::TimeZone->new( name => 'local' )->name();

I am testing the modules over night and then I will check them in.

Regards
    Sailor

[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:

Code Auswählen Erweitern

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

[Beta-User]

Doch... nocheck!

[Nestor]

Code Auswählen Erweitern

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).

Code Auswählen Erweitern

my $dt = DateTime->now()->set_time_zone('local');
say $dt->time_zone;


Result:

Code Auswählen Erweitern


DateTime::TimeZone::Europe::Brussels=HASH(0x5628649f3a00)

[Beta-User]

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?

[betateilchen]

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.

[KölnSolar]

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?

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. 

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:

Code Auswählen Erweitern

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

[Sailor]

Hi BetaUser

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

[Sailor]

Hallo betateilchen

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

[Sailor]

Hi Markus

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

[KölnSolar]

Hi Sailor,
bin zwar zu weit weg für den Whisky(den kannst Du ja Udo rüber bringen), aber so mach ich es

Code Auswählen Erweitern

eval {require Time::HiRes; 1;}
or do {
return "......Module Time:HiRes not installed. Check perl libraries'";
};


Da gebe ich dir vollkommen Recht!

Schön. Machst Du dann einen neuen Faden im Development Bereich ?

Grüße Markus

[Sailor]

Hi Markus

Hi Sailor,
bin zwar zu weit weg für den Whisky(den kannst Du ja Udo rüber bringen)

Der wird sich sicher freuen!

so mach ich es

Code Auswählen Erweitern


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...

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

[KölnSolar]

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...

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

[Beta-User]

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:

Code Auswählen Erweitern

{ 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)) }

[Beta-User]

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 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...

[betateilchen]

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.

Code Auswählen Erweitern


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;



--

[rob]

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/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:

Code Auswählen Erweitern


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]


[Sailor]

Hi rob

Wenn ich es richtig verstehe, ist das Paket bereits on board:

Also bei mir war das definitiv nicht der Fall! 

Gruß
   Sailor

[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.

Code Auswählen Erweitern


##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.

Code Auswählen Erweitern


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

[rob]

...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

[Beta-User]

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?)

[betateilchen]

Habe mir jetzt mal folgenden Check ueberlegt.

Dir ist hoffentlich klar, dass Du mit diesem Bullshit alles noch schlimmer machst?

[Sailor]

Hallo Beta-User

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.

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:

Code Auswählen Erweitern


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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern


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

[Sailor]

Dir ist hoffentlich klar, dass Du mit diesem Bullshit alles noch schlimmer machst?

Der von dir vorgeschlagene Code

Code Auswählen Erweitern


    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

[Beta-User]

So war es nicht gemeint, das bezog sich auf die "nocheck"-Variante von timelocal...

Für die Kommandozeile:

Code Auswählen Erweitern

{ 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:

Code Auswählen Erweitern

{ 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!

[betateilchen]

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.

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.

Code Auswählen Erweitern


my @UseLibaries = ("JSON",
"JSON::Parse",
"HttpUtils");


liefert übrigens direkt das gewünschte Array.

Noch eleganter geht es so:

Code Auswählen Erweitern


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.

[Sailor]

Hallo Beta-User

Paßt man das für den Oktober an, kommt man auf:

Code Auswählen Erweitern

{ 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!

Code Auswählen Erweitern


# 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;


Code Auswählen Erweitern


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

[Beta-User]

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!)

[erwin]

...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:

Code Auswählen Erweitern

# 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

[Sailor]

Noch eleganter geht es so:

Code Auswählen Erweitern


my @UseLibaries = qw( JSON
JSON::Parse
HttpUtils );


Naja, mit der Liste stoesst du dann aber an die Grenzen von qw()

Code Auswählen Erweitern


Crypt::NaCl::Sodium qw( :utils )
Crypt::Argon2 qw/argon2i_raw/
File::Spec::Functions ':ALL'


Gruss
    Sailor

[Sailor]

...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:

Code Auswählen Erweitern

# 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

[erwin]

Stimmt, aber ich brauche auch den UNIX - Timestamp von der nächsten Mitternacht.

der ist in meinem code versteckt unter $secTo.
l.g.erwin

[betateilchen]

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

Code Auswählen Erweitern


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).

[isy]

Wenn ich es richtig verstehe, ist das Paket bereits on board:

Bei mir ist die Library jedenfalls auch bereits installiert, nur eine ältere Version:

Code Auswählen Erweitern

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.
       

[Beta-User]

Ergänzend: ...ein Ladung irritierter User wie in 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!