Täglich setreading mit at, am Monatsende ein zusätzliches setreading

Begonnen von TomLee, 15 Juni 2023, 14:15:08

Vorheriges Thema - Nächstes Thema

TomLee

Ich hab mir vorhin zufällig zeitgleich und unabängig zu/von zu diesem Thread ein at überlegt wie es gerade Betateilchen zuletzt mit zwei ats vorschlägt.

Hab die Bezeichnungen/Namen des Vorschlags mal übernommen:

defmod at_test at *23:59:00 {\
my $time = time_str2num(ReadingsTimestamp("$SELF","state","1970-01-01 00:00:00"))-1;;\
my $lm = ReadingsVal("<pv_device>","laufendermonat",0);;\
fhem("setreading <pv_device> laufendermonat <WertDesLaufendenMonats>");;\
fhem("setreading <pv_device> vormonat $lm; setreading <pv_device> laufendermonat 0") if $time == at_ultimo();;\
}


Ich weiß noch nicht ob ich das wirklich brauche.
Könnte man das so machen oder hab ich einen Denkfehler drin (ich meine nicht) ?
Könnte man es noch anders/besser lösen oder sollte man einfach zwei ats verwenden ?
Ich frag auch deshalb weil vom Zeitstempel ja eine Sekunde abgezogen werden muss wenn das at um 23:59:00 auslöst (bin mir aber nicht sicher ob das immer so ist). Bsp:
setstate at_test 2023-06-14 23:59:01 state Next: 23:59:00

frober

Prinzipiell würde ich sagen, warum sollte es nicht funktionieren.

Aber mit der einen Sekunde Abzug wäre ich vorsichtig, die kommt bestimmt von der Verarbeitungszeit (Freezes) und kann vermutlich schwanken. Daher die Uhrzeit evtl. hard vercoden und nur das Datum anfragen!?
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Das 2. at ist vermutlich effektiver, aber wenn du es mit einem Vergleich lösen willst, dann würde ich eher den Monat von time mit Monat von (time +2) nehmen. Dürfte jedenfalls effizienter sein wie diese Text-Operationen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Danke für die Rückmeldungen.

Denke werde das überhaupt nicht brauchen, eigentlich gehts mir nur darum was dazuzulernen.

Mag ja sein das zwei at effektiver sind, ein Device wär mir aber lieber wie zwei, das ist eine Prüfung pro Tag, das bringt meine gelangweilte Pi nicht um.

Zitatdann würde ich eher den Monat von time mit Monat von (time +2) nehmen

Ich verstehs nicht wie das gemeint ist (habs kurz versucht nachzuvollziehen) ::)


Genauso wie das:
ZitatDürfte jedenfalls effizienter sein wie diese Text-Operationen.



Hab mir noch eine Möglichkeit überlegt auf den letzten Tag zu prüfen, mit Zuhilfenahme einer Time::Piece Methode:
{my @a= split(' ',localtime);; return 'bla' if  localtime()->month_last_day == $a[2];;}
edit: OK, man könnte auch mit der FHEM eigenen $mday Variablen vergleichen, kam mir erst später:
{return 'bla' if  localtime()->month_last_day == $mday;;}

TomLee

Zitatdie kommt bestimmt von der Verarbeitungszeit (Freezes)

Hab mich nicht weiter beschäftigt, bist dir sicher dass das ein "Freeze" ist ?
Hab die Vermutung das die Millisekunden auf eine Sekunde aufgerundet werden im Zeitstempel ?

frober

Zitat von: TomLee am 17 Juni 2023, 22:38:37
Zitatdie kommt bestimmt von der Verarbeitungszeit (Freezes)

Hab mich nicht weiter beschäftigt, bist dir sicher dass das ein "Freeze" ist ?
Hab die Vermutung das die Millisekunden auf eine Sekunde aufgerundet werden im Zeitstempel ?

Eher eine Vermutung, da ich das auch immer wieder beobachte.
Wobei Freeze nur ein Bsp. war, bezogen Fhem = ein Prozess. Auch wenn es je nach Modul Forks gibt...
D.h. es kann immer zu kleinen Verzögerungen kommen.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Zitat von: TomLee am 17 Juni 2023, 13:56:43dann würde ich eher den Monat von time mit Monat von (time +2) nehmen

Ich verstehs nicht wie das gemeint ist (habs kurz versucht nachzuvollziehen) ::)
Gemeint war: Addiere zur aktuellen Zeit (in Sekunden) soviel Sekunden, dass in jedem Fall ein Tages- bzw. Monatswechsel dazwischen liegt (das at eine Minute vor Mitternacht => 120 Sekunden addieren) und vergleiche die Monate dieser beiden Sekundenwerte. Sind die gleich => return;. Sowas braucht keine weiteren libraries, das localtime-Array sollte ausreichen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

#7
Das Modul at.pm wurde im Januar 2021 genau deshalb um die Funktion at_ultimo() erweitert, damit man solche Krämpfe nicht mehr veranstalten muss...

https://forum.fhem.de/index.php?topic=117269.0
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

TomLee

ZitatSowas braucht keine weiteren libraries, das localtime-Array sollte ausreichen.

Liest sich für mich jetzt so das die Time::Piece Variante (versteh ich als weitere Library) weniger effizient ::) sein soll ?
Die ist in Perl seit mehr als 20 Jahren vorhanden, warum nutzt man/Ihr diese Möglichkeit nicht ?

Ihr wisst ja wer frägt, ich erwarte bitte eine mir verständliche Antwort darauf !