Fehler in der Berechnung des nächsten Schaltzeitpunktes

Begonnen von FHEm2005, 15 September 2021, 11:33:19

Vorheriges Thema - Nächstes Thema

FHEm2005

Meine Fensterbeleuchtung soll mit Sonnenuntergang eingeschaltet werden (cmd_1) und nach 23.30 Uhr innerhalb der nächsten 60 Minuten zufallsgesteuert ausgehen (cmd_2). Der cmd_1 wird immer pünktlich abgearbeitet. Wenn der aktuelle Zeitschaltpunkt von cmd_2 in der Zeit von 0:00 und 0:30 liegt, wird dieser zwar noch richtig abgearbeitet, aber die Berechnung des darauffolgenden cmd_2 - Zeitpunktes ist falsch. Dadurch wird die Fensterbeleuchtung am folgenden Tag nicht mehr ausgeschaltet.

Doch zunächst das Listing:
defmod Fensterfront.di DOIF ([({sunset("HORIZON=-0.1",250,0,"22:00")})])\
(set Fensterfront.du on)\
DOELSEIF ([([23:30]+int(rand(3600)))])\
(set Fensterfront.du off)
attr Fensterfront.di userattr alleLichter alleLichter_map structexclude
attr Fensterfront.di comment Steuerung der Fensterfront
attr Fensterfront.di devStateIcon nodevice
attr Fensterfront.di disable 0
attr Fensterfront.di event-min-interval 3600
attr Fensterfront.di group Fensterfront
attr Fensterfront.di room System->Funktionen
attr Fensterfront.di stateFormat state
attr Fensterfront.di userReadings sunrise { \
my $date = time();;\
sunrise_abs_dat($date,"HORIZON=-0.1");;}, \
sunset {\
my $date = time();;\
sunset_abs_dat($date,"HORIZON=-0.75");;},\
Frontstatus { \
my $command1 = ReadingsVal("Fensterfront.di","timer_01_c01",'');;   \
my $command2 = ReadingsVal("Fensterfront.di","timer_02_c02",'');; \
return("Ein:".$command1." | Aus:".$command2);;}
attr Fensterfront.di verbose 5
attr Fensterfront.di webCmd cmd_1:cmd_2

setstate Fensterfront.di cmd_2
setstate Fensterfront.di 2021-09-15 00:07:16 Frontstatus Ein:15.09.2021 19:49:03 | Aus:16.09.2021 23:50:56
setstate Fensterfront.di 2021-09-15 00:07:16 cmd 2
setstate Fensterfront.di 2021-09-15 00:07:16 cmd_event timer_2
setstate Fensterfront.di 2021-09-15 00:07:16 cmd_nr 2
setstate Fensterfront.di 2021-09-13 08:53:22 mode enabled
setstate Fensterfront.di 2021-09-15 00:07:16 state cmd_2
setstate Fensterfront.di 2021-09-15 00:07:16 sunrise 07:13:38
setstate Fensterfront.di 2021-09-15 00:07:16 sunset 19:49:03
setstate Fensterfront.di 2021-09-14 19:51:20 timer_01_c01 15.09.2021 19:49:03
setstate Fensterfront.di 2021-09-15 00:07:16 timer_02_c02 16.09.2021 23:50:56


Die letzte Zeile offenbart den Fehler. Richtig wäre gewesen, wenn das Datum 15.09.2021 gewesen wäre und nicht der 16.09.2021. Läge der auslösende cmd_2 nicht um 00:07:16 sondern vor 24:00, wäre die Berechnung fehlerfrei gewesen. So wird die Fensterbeleuchtung aber am darauffolgenden Tag nicht ausgeschaltet.

Mein Fhem läuft auf einem Raspi4 (ich weiß nicht, ob das wichtig ist).

Nun meine Frage: Wo liegt mein Denk- /Programmierfehler?

Gruß Eberhard

Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

Otto123

Hallo Eberhard,

Du verwendest am falschen Tag die Berechnung eines Timers um den Tageswechsel! Was erwartest Du da? Wenn (zufällig) heute/morgen ein Timer für (zufällig) morgen/übermorgen berechnet wird!

Nimm doch einfach ein wait! https://fhem.de/commandref_DE.html#DOIF_timerWithWait

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEm2005

Hallo Otto,

danke für die schnelle Antwort. Ich erwarte, dass am Tag X eine Uhrzeit Y für Y+rand(60) berechnet wird. Wenn die am Tag X+1 berechnete Uhrzeit am Tag X+1 durchführbar ist, erwarte ich auch eine Berechnung und Abarbeitung für den Tag X+1 und nicht X+2. Das muss DOIF doch hergeben. Oder?

Genau diese Definition lief auf einem Raspi 3 immer ohne Probleme. Nach Umzug+Update dieses Problem.

Blockiert wait denn das system?

Gruß Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

Otto123

Zitat von: FHEm2005 am 15 September 2021, 13:27:17
Genau diese Definition lief auf einem Raspi 3 immer ohne Probleme. Nach Umzug+Update dieses Problem.
Glaub ich Dir irgendwie nicht. Du siehts doch wann der Timer berechnet wird? Da hat die Version des Raspberry keinen Einfluss. Zufällig kann das bisher immer funktioniert haben, immer dann wenn der letzte Timer auf vor Mitternacht fiel. :)
setstate Fensterfront.di 2021-09-15 00:07:16 timer_02_c02 16.09.2021 23:50:56
Zitat
Blockiert wait denn das system?
Wie kommst Du darauf?  ::) Da wird doch genau ein Timer berechnet wie in deinem Konstrukt! Nur eben "richtig" ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FHEm2005

Zitat von: Otto123 am 15 September 2021, 14:09:58
Glaub ich Dir irgendwie nicht.
Kann ich durchaus nachvollziehen, wenn aber ein System über ein Jahr ohne Fehler läuft und nach Umzug Zicken macht, kann der Gedanke schon aufkommen.
ZitatDu siehts doch wann der Timer berechnet wird?
Das ist es ja! Wenn er am 15.09.  um 00:07:16 einen Timer berechnet, warum dann für den 16.09. und nicht für den 15.09.??? Obwohl der 15.09. von der Programmierung richtig und auch möglich wäre. Ich verstehe es einfach nicht.

Ich habe jetzt das DOIF in zwei Teile zerpflückt (on:off) und das Ausschalten mit einem "rand(3600)" - wait versehen. Ich werde es nun so benutzen, obwohl es für mich nur ein Workaround darstellt.

Dir, Otto, vielen Dank für Deine Unterstützung.

Gruß
Eberhard
Raspi3: FHEM, CULV3 (V1.61), EnOcean Pi 868, nanoCUL433, HUE-Bridge; Raspi4: Node-red, MQTT, Gaszähler auslesen mit ESP32-CAM

Otto123

Hallo Eberhard,

warum in zwei Teile zerpflückt? Ich hatte gedacht Du brauchts bloß den zweiten verzögern. Aber so genau kenne ich das im DOIF jetzt auch wieder nicht. Wichtig ist ja nur das zweite Attribute, damit es auch für den timer gilt.

Mit der Zeitberechnung liege ich vielleicht doch falsch? Aber wenn, hat sich sicher was am DOIF und nicht am Raspberry geändert :) Du verwendest es ja in Anlehnung an die Doku https://fhem.de/commandref_DE.html#DOIF_Zeitsteuerung_mit_Zeitberechnung - allerdings eben über den Tageswechsel hinweg. Das sehe ich immer problematisch ;)

Vielleicht findet ja Damian den Thread und löst das auf.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Damian

#6
Bei absoluten Tages-Timern addiert DOIF immer 24 Stunden dazu, weil man davon ausgeht, dass ein absoluter (Gegenteil von relativ) Timer nur einmal pro Tag schaltet. Würde man das nicht tun, dann würde ein Tagestimer ggf. mehrfach am Tag schalten.

Beispiel: um 23:30 + 10 Sekunden Zufall = 23:30:10 wird der nächste Timer berechnet 23:30+ 11 Sekunden Zufall = 23:30:11

Das Programm hätte dann im Abstand von einer Sekunde zweimal geschaltet.

In solchen Fällen sollte man am besten mit wait verzögern, weil dann die Zeitberechnung immer um die gleiche Zeit stattfindet und nur der Befehl verzögert wird, nicht aber die Zeitberechnung selbst.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

frank

wait überlebt keinen fhem restart, soweit ich weiss.
daher würde ich einen aktor, der on-for-timer kann, diesen schon zum sonnenuntergang damit entsprechend starten.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Damian

Zitat von: frank am 15 September 2021, 17:59:04
wait überlebt keinen fhem restart, soweit ich weiss.

Ein berechneter Zufall in der Bedingung auch nicht. Das dürfte hier nicht so gravierend sein, weil nach dem Neustart eine neue zufälliger Verzögerung berechnet wird, egal ob über wait oder über die Berechnung in der Bedingung.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

frank

Zitat von: Damian am 15 September 2021, 18:04:07
Ein berechneter Zufall in der Bedingung auch nicht. Das dürfte hier nicht so gravierend sein, weil nach dem Neustart eine neue zufälliger Verzögerung berechnet wird, egal ob über wait oder über die Berechnung in der Bedingung.
es ist 00:07 uhr, das licht ist noch an und der wait timer läuft, so dass 00:28 uhr das "set off" kommen würde.
nun gibt es ein fhem restart.

gibt es bis sonnenaufgang garantiert noch ein "set off"?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Damian

Zitat von: frank am 16 September 2021, 14:59:41
es ist 00:07 uhr, das licht ist noch an und der wait timer läuft, so dass 00:28 uhr das "set off" kommen würde.
nun gibt es ein fhem restart.

gibt es bis sonnenaufgang garantiert noch ein "set off"?

ja, solange der neu errechnete Zufall nicht vor dem Restart liegt, dh. wenn das System um 00:10 hochfährt und der errechnete Zufall um 00:09 ist, dann muss man ca. 24 h auf off warten.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html