DOIF mit Twilight --> ss_astro nach 00:00 -> Problem

Begonnen von Frank_Huber, 24 Mai 2017, 11:34:59

Vorheriges Thema - Nächstes Thema

Frank_Huber

Mahlzeit,

Ich nutze Twilight mit einem DOIF zum herunterfahren meiner Rollos.
([{twilight("Sonnenstand","ss_astro","20:00","23:30")}]) (set ....)

also zum Sunset Astro herunterfahren, aber nicht vor 20:00 und nicht nach 23:30.

Soooo, ss_astro ist jetzt nach 00:00 und die Rollos fahren um 20:00 runter, sollen aber um 23:30.
Das Twilight Modul macht ja alles richtig, aber wie kann ich das Problem umgehen?

Ich sehe 2 Möglichkeiten:
1. So was wie: Wenn ss nach 00:00 nimm 23:59 als ss
2. ss_astro minus x Minuten. Bei normalen Zeitangaben geht das ja, bei der Funktion von Twilight müsste ich dannaber alle Zeitwerte anpasen.

Möglichkeit 1 wäre mir lieber, weis nur nicht wie...
Gibt es vielleicht gar noch andere Lösungsansätze?

Danke & Grüße
Frank

moonsorrox

Zitat von: Frank_Huber am 24 Mai 2017, 11:34:59
([{twilight("Sonnenstand","ss_astro","20:00","23:30")}]) (set ....)

also zum Sunset Astro herunterfahren, aber nicht vor 20:00 und nicht nach 23:30.

Evtl. hat es etwas damit zutun
da ja der Wert "ss_astro" von der Yahoo! Wetter-ID kommt, kann es damit ein Problem geben/sein...!
Wenn ich momentan in mein twilight schaue habe ich 3 Werte die ein "undefined" zeigen schau mal nach.
Diese sind es: sr_astro, sr_twilight, ss_astro
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Frank_Huber

Die Werte passen.
Problem ist dass ss_astro nach Null Uhr ist und somit am nächsten Tag.
ss_astro 00:05:04 2017-05-24 00:00:09

sr 05:39:55 2017-05-24 00:00:09
sr_astro 02:44:03 2017-05-24 00:00:09
sr_civil 04:54:04 2017-05-24 00:00:09
sr_indoor 05:47:06 2017-05-24 00:00:09
sr_naut 04:00:20 2017-05-24 00:00:09
sr_weather 06:09:27 2017-05-24 05:09:34
ss 21:06:57 2017-05-24 00:00:09
ss_astro 00:05:04 2017-05-24 00:00:09
ss_civil 21:53:01 2017-05-24 00:00:09
ss_indoor 20:59:44 2017-05-24 00:00:09
ss_naut 22:47:10 2017-05-24 00:00:09
ss_weather 20:37:18 2017-05-24 05:09:34


Frank_Huber

Habs jetzt mal auf den nautischen SS + 60min gesetzt.
Mal sehen ob das so geht wie ich es mir denke.
müsste dann ja heute Abend um 23:30 runterfahren.
([{twilight("Sonnenstand","ss_naut","19:00","22:30")}]+01:00)

Falls es bessere Lösungen gibt wäre ich dankbar. ;)

Damian

Zitat von: Frank_Huber am 24 Mai 2017, 13:18:43
Habs jetzt mal auf den nautischen SS + 60min gesetzt.
Mal sehen ob das so geht wie ich es mir denke.
müsste dann ja heute Abend um 23:30 runterfahren.
([{twilight("Sonnenstand","ss_naut","19:00","22:30")}]+01:00)

Falls es bessere Lösungen gibt wäre ich dankbar. ;)

[{max("20:00",min("[Sonnenstand:ss_astro]","23:30"))}]

Das dürfte besser funktionieren, denn DOIF reagiert bei dieser Definition auf Änderungen von [Sonnenstand:ss_astro] und passt automatisch die aktuelle Zeit an.

min und max sind Perlfunktionen, mit diesen lässt sich das Zeitintervall einschränken.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Frank_Huber

Zitat von: Damian am 24 Mai 2017, 13:35:18
[{max("20:00",min("[Sonnenstand:ss_astro]","23:30"))}]

Das dürfte besser funktionieren, denn DOIF reagiert bei dieser Definition auf Änderungen von [Sonnenstand:ss_astro] und passt automatisch die aktuelle Zeit an.

min und max sind Perlfunktionen, mit diesen lässt sich das Zeitintervall einschränken.

Danke Damian,
Aber würde er da nicht auch um 20:00 schon abfeuern wenn ss_astro um 00:05 ist z.B.?
Wie definieren sich die Elemente in deinem Code? Gerade dieses verdrehte min/max verwirrt mich gerade etwas. :-)

Damian

#6
Zitat von: Frank_Huber am 24 Mai 2017, 13:38:54
Danke Damian,
Aber würde er da nicht auch um 20:00 schon abfeuern wenn ss_astro um 00:05 ist z.B.?
Wie definieren sich die Elemente in deinem Code? Gerade dieses verdrehte min/max verwirrt mich gerade etwas. :-)

{max("20:00",min(meinezeit(),"23:30"))}

Das ist reines Perl. Hier ist das Ergebnis von min der Übergabeparameter von max. meinezeit ist z. B. eine Funktion die Zeit im Format HH:MM liefert.

Und genauso funktioniert das im DOIF, dort entspricht meinezeit() "[Sonnenstand:ss_astro]"

Edit: Und jetzt kannst du mal überlegen was liefert dann:

{max("20:00",min("00:05","23:30"))}
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Frank_Huber

Zitat von: Damian am 24 Mai 2017, 13:43:51
{max("20:00",min(meinezeit(),"23:30"))}

Das ist reines Perl. Hier ist das Ergebnis von min der Übergabeparameter von max. meinezeit ist z. B. eine Funktion die Zeit im Format HH:MM liefert.

Und genauso funktioniert das im DOIF, dort entspricht meinezeit() "[Sonnenstand:ss_astro]"

Versteh es zwar nicht, aber ich bau es mal so ein. :-)
Danke Dir! werde berichten!

Frank_Huber

OK, eingebaut, der Timer c02 steht jetzt aber auf 20:00.

Hier der gesamte LIST:
Internals:
   DEF        ([{twilight("Sonnenstand","sr_civil","06:00","08:00")}])
(set PI_EG cmd set Rollos_EG offen ;set PI_OG cmd set Rollos_Flur_Bad_OG offen ;set PI_DG cmd set Rollos_DG open)
DOELSEIF([{max("20:00",min("[Sonnenstand:ss_astro]","23:30"))}])
(set PI_EG cmd set Rollos_EG geschlossen ;set PI_OG cmd set Rollos_OG geschlossen ;set PI_DG cmd set Rollos_DG geschlossen)
   NAME       DOIF_ROLLO_ALLGEMEIN
   NR         186
   NTFY_ORDER 50-DOIF_ROLLADEN_UP
   STATE      initialized
   TYPE       DOIF
   Helper:
     Dblog:
       Cmd:
         Logdb:
           TIME       1495626435.69729
           VALUE      0
       Cmd_event:
         Logdb:
           TIME       1495577700.02404
           VALUE      timer_2
       Cmd_nr:
         Logdb:
           TIME       1495577700.02404
           VALUE      2
       State:
         Logdb:
           TIME       1495626435.69729
           VALUE      initialized
   Readings:
     2017-05-24 13:47:15   cmd             0
     2017-05-24 13:47:15   state           initialized
     2017-05-24 13:47:15   timer_01_c01    25.05.2017 06:00:00
     2017-05-24 13:47:15   timer_02_c02    24.05.2017 20:00:00
   Condition:
     0          DOIF_time_once($hash,0,$wday)
     1          DOIF_time_once($hash,1,$wday)
   Days:
   Devices:
   Do:
     0:
       0          set PI_EG cmd set Rollos_EG offen ;set PI_OG cmd set Rollos_Flur_Bad_OG offen ;set PI_DG cmd set Rollos_DG open
     1:
       0          set PI_EG cmd set Rollos_EG geschlossen ;set PI_OG cmd set Rollos_OG geschlossen ;set PI_DG cmd set Rollos_DG geschlossen
     2:
   Helper:
     globalinit 1
     last_timer 2
     sleeptimer -1
   Itimer:
     all         Sonnenstand
   Localtime:
     0          1495684800
     1          1495648800
   Realtime:
     0          06:00:00
     1          20:00:00
   Regexp:
     All:
   State:
     State:
   Time:
     0          {twilight("Sonnenstand","sr_civil","06:00","08:00")}
     1          {max("20:00",min("[Sonnenstand:ss_astro]","23:30"))}
   Timecond:
     0          0
     1          1
   Timer:
     0          0
     1          0
   Timers:
     0           0
     1           1
   Triggertime:
     1495648800:
       localtime  1495648800
       Hash:
     1495684800:
       localtime  1495684800
       Hash:
Attributes:
   group      Rollo
   room       zentrale Funktionen

Damian

Zitat von: Frank_Huber am 24 Mai 2017, 13:46:13
Versteh es zwar nicht, aber ich bau es mal so ein. :-)
Danke Dir! werde berichten!

wenn in [Sonnenstand:ss_astro] ein Wert außerhalb von 20:00-23:30 steht, dann wird logischerweise der kleinere bzw. größere Wert genommen, aber das hast du ja wohl so gewollt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Frank_Huber

Das hat er auch vorher schon gemacht mit    
([{twilight("Sonnenstand","ss_astro","20:00","23:30")}])

Die Schwierigkeit kam gestern auf als ss_astro auf nach Null Uhr gewandert ist. Hier hat dann der früheste Zeitpunkt 20:00 gegriffen anstatt 23:30.

herrmannj

logisch. 0:05 ist vor 20:00, als um 20:00 zumachen.

Wäre es eine Idee von ss_astro auf etwas weniger restriktives (-6, -12) zu gehen ? Dann musst Du die logik nicht komplett neu schreiben. Btw, in einigen Gegenden von Deutschland findet den ganzen Sommer kein ss_astro statt. In etwa nördlich Hannover

vg
joerg


Frank_Huber

Ja klar, Die Logik arbeitet richtig.
Ich habe jetzt als Workaround sen SS_NAUT +60:00 drin.
Ist optisch nicht ganz so gut zu durchschauen da min max auch eine Stunde verschoben sind.
Aber ist wohl denke ich die einfachste Lösung.

Das ([{max("20:00",min("[Sonnenstand:ss_astro]","23:30"))}]) macht im Grunde das gleiche wie ([{twilight("Sonnenstand","ss_astro","20:00","23:30")}])

moonsorrox

Zitat von: herrmannj am 24 Mai 2017, 14:10:26
Btw, in einigen Gegenden von Deutschland findet den ganzen Sommer kein ss_astro statt. In etwa nördlich Hannover

das wäre ich dann...?? :-\  ;) :D deshalb bei mir ein "undefined"
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

herrmannj

ich bin mir nicht sicher wie genau twilight das zur Anzeige bringt. "undefined" wäre formell richtig. Was ich zum Ausdruck bringen wollte: man muss bei numerischen Vergleichen dann auch diesen Sonderfall, evtl "undefined" berücksichtigen.