Sommerzeit/Normalzeit als DOIF Objekt

[Loredo]

Ich wollte statt dst() gerne ein richtiges Reading nutzen können und habe mir dafür dieses DOIF erstellt:

Code: [Auswählen]

define DST DOIF
(
   ([02:00] or [03:00]) and
   $isdst
)

DOELSE


Folgende Attribute wurden gesetzt:

Code: [Auswählen]

alias Daylight Time
cmdState summer|normal
event-on-change-reading state
eventMap summer:Sommer normal:Normal initialized:---
group Season Details
icon time_clock
room Environment


[moonsorrox]

wenn die Anfänger das so in die Fhem Kommandozeile eingeben meckert er rum..! 

dann sollten sie diese beiden Semikolons hinter "localtime(time);" weglassen
Ansonsten ist das ein echt guter Einfall, wenn man es irgendwo brauchen kann..! 

[Loredo]

Wer das in den Editor eingibt bekommt keine Fehler.
Bei solch langen Definitionen ist es immer sinnvoll erst ein leeres DOIF anzulegen und dann zu editieren:

Code: [Auswählen]

define DST DOIF ([DST])


[moonsorrox]

OK gute Idee, hatte ich bisher auch noch nicht gemacht..! 

[cwagner]

Super-Idee so kurz vor dem nächsten Wechsel - zum Beispiel stellen die Wetterdienste die Tagesmenge Regen jeweils um 7:50 Ortszeit im Sommer und 6:50 Ortszeit im Winter fest. Die entsprechende automatische E-Mail kann ich mit Deiner Konstruktion jetzt ohne Änderung meines DOIF (anstelle eines at) umsetzen.

Christian

[Damian]

Ich wollte statt dst() gerne ein richtiges Reading nutzen können und habe mir dafür dieses DOIF erstellt:

Code: [Auswählen]

define DST DOIF

(
my ( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst ) = localtime(time);


([02:00] or [03:00]) and
$isdst
)


DOELSEIF
(
my ( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst ) = localtime(time);


([02:00] or [03:00]) and
!$isdst
)





alias      Daylight Time
cmdState   summer|normal
event-on-change-reading state
eventMap   summer:Sommer normal:Normal initialized:---
group      Season Details
icon       time_clock
room       Environment


Es ist schon erstaunlich, was so alles funktioniert - auch für mich. Auf diese Art und Weise lassen sich sogar ganze Perl-Programme in einer DOIF-Bedingung unterbringen

Allerdings ist in diesem konkreten Fall  der Aufruf von localtime überflüssig, weil ich es bereits intern in DOIF vor der Auswertung der Bedingung tue. Auch die DOELSEIF-Abfrage ist überflüssig, weil es die Negation des DO-Falls ist.

Daher reicht schon:

Code: [Auswählen]

define DST DOIF (([02:00] or [03:00]) and $isdst) DOELSE
Gruß

Damian

[cwagner]

das ist ja noch geiler! Und damit zähle ich jetzt bei mir 23 DOIF 

[tik-tak-tok]

Hallo,

ich habe nun folgendes DOIF angelegt um die Sommerzeit/Winterzeit abzufragen.

Code: [Auswählen]

define SommerzeitWinterzeit (([02:00] or [03:00]) and $isdst) DOELSE

Nun würde ich gerne, sobald festgestellt wird "Es ist Winterzeit" folgenden set Befehl "set ThermostatProfile send_to_device BadezimmerWinter [BadzimmerHeizung_Clima]" mittels separatem DOIF absenden lassen (einmalig).
Sobald dann irgendwann wieder "Es ist Sommerzeit" festgestellt wird würde ich gerne den Befehl "set ThermostatProfile send_to_device BadezimmerSommer [BadzimmerHeizung_Clima]" absenden lassen.

Wie stelle ich das an? :-)
Vermutlich muss ich, wie bei einem Türkontakt auch, den State des DOIF "SommerzeitWinterzeit" prüfen (lassen).

Wäre hier folgendes möglich?
([SommerzeitWinterzeit] eq "cmd1" (set ThermostatProfile send_to_device BadezimmerWinter [BadzimmerHeizung_Clima]" und alternativ für den Sommer ([SommerzeitWinterzeit] eq "cmd2" (set ThermostatProfile send_to_device BadezimmerSommer [BadzimmerHeizung_Clima] möglich?

Bzw. falls nein, welchen State sollte das DOIF "SommerzeitWinterzeit" denn jeweils liefern?

Muss ich beim DOIF "SommerzeitWinterzeit" irgendwelche Attribute (außer do always) setzen? :-)

Vielen Dank und fhem`ige Grüße :-P

[Damian]

Hallo,

ich habe nun folgendes DOIF angelegt um die Sommerzeit/Winterzeit abzufragen.

Code: [Auswählen]

define SommerzeitWinterzeit (([02:00] or [03:00]) and $isdst) DOELSE

Nun würde ich gerne, sobald festgestellt wird "Es ist Winterzeit" folgenden set Befehl "set ThermostatProfile send_to_device BadezimmerWinter [BadzimmerHeizung_Clima]" mittels separatem DOIF absenden lassen (einmalig).
Sobald dann irgendwann wieder "Es ist Sommerzeit" festgestellt wird würde ich gerne den Befehl "set ThermostatProfile send_to_device BadezimmerSommer [BadzimmerHeizung_Clima]" absenden lassen.

Wie stelle ich das an? :-)
Vermutlich muss ich, wie bei einem Türkontakt auch, den State des DOIF "SommerzeitWinterzeit" prüfen (lassen).

Wäre hier folgendes möglich?
([SommerzeitWinterzeit] eq "cmd1" (set ThermostatProfile send_to_device BadezimmerWinter [BadzimmerHeizung_Clima]" und alternativ für den Sommer ([SommerzeitWinterzeit] eq "cmd2" (set ThermostatProfile send_to_device BadezimmerSommer [BadzimmerHeizung_Clima] möglich?

Bzw. falls nein, welchen State sollte das DOIF "SommerzeitWinterzeit" denn jeweils liefern?

Muss ich beim DOIF "SommerzeitWinterzeit" irgendwelche Attribute (außer do always) setzen? :-)

Vielen Dank und fhem`ige Grüße :-P

Wenn du das Attribut cmdState summer|normal bei deinem SommerzeitWinterzeit-DOIF setzt, kannst du in jedem anderen Modul den Status von SommerzeitWinterzeit auf summer oder normal prüfen, bei einem DOIF-Modul z. B.

Code: [Auswählen]

DOIF ([SommerzeitWinterzeit] eq "summer") (set bla on)

[tik-tak-tok]

Dankeschön!

DOIFs entsprechend geändert :-)

Scheint zu funktionieren.
Wie könnte ich es nun gestalten das nicht mehrfach die Profile übertragen werden?
Ich sag mal, sobald Sommerzeit eingetreten ist und die Profile gesendet wurden...ist das ja schick und OK, aber dann könnte der Befehl ja "pausieren" bis "Winter bzw. normal" eintritt.

Danke & Grüße

[Damian]

Dankeschön!

DOIFs entsprechend geändert :-)

Scheint zu funktionieren.
Wie könnte ich es nun gestalten das nicht mehrfach die Profile übertragen werden?
Ich sag mal, sobald Sommerzeit eingetreten ist und die Profile gesendet wurden...ist das ja schick und OK, aber dann könnte der Befehl ja "pausieren" bis "Winter bzw. normal" eintritt.

Danke & Grüße

ja, es gibt bei dieser Lösung zwei Zeittrigger pro Tag für das SommerzeitWinterzeit-DOIF. Der Zustand ändert sich nicht, d.h. für alle anderen gibt es keine Trigger. Im Vergleich zu tausend anderen Ereignissen, ist dieser Belastung zu vernachlässigen.
 

[tik-tak-tok]

Danke für deine Antwort! :-)

Okay,...also, da sich der State ja so gesehen nicht ändert bekomme ich mit der 1% Regel beim Senden über mein Homematic Modul diesbezüglich keine Probleme?
Heißt also auch, heute wird "Sommer" erkannt, heute werden die gesetzten Sommer Befehle gesetzt,...und am nä. Tag passiert nichts, da ja zwischenzeitlich der State "Sommer" nicht anders war, richtig gedeutet?

Danke :-)

[Damian]

Danke für deine Antwort! :-)

Okay,...also, da sich der State ja so gesehen nicht ändert bekomme ich mit der 1% Regel beim Senden über mein Homematic Modul diesbezüglich keine Probleme?
Heißt also auch, heute wird "Sommer" erkannt, heute werden die gesetzten Sommer Befehle gesetzt,...und am nä. Tag passiert nichts, da ja zwischenzeitlich der State "Sommer" nicht anders war, richtig gedeutet?

Danke :-)

ja.  Aber selbst, wenn sich der Zustand ändern würde, würde das ja nur um 2:00  und 3:00 Uhr geschehen, da bist du von der 1% Regel ziemlich weit entfernt

[Xell1984]

Guten Abend,

im Bezug auf das obere habe ich eine Frage:

Da am Tag der Zeitumstellung die Jalousien noch in der alten Zeit liegen (Timer wird ja um Mitternacht gesetzt) möchte ich gern nach der Zeitumstellung die entsprechenden DOIF zurück setzen (Initialiseren) um die Timer neu zu generieren. Jeweils am Tag der Umstellung.

Das oben stehende DOIF mit CmdState Winter|Sommer  funktioniert

Code: [Auswählen]

Internals:
   CFGFN     
   DEF        (([02:00] or [03:00]) and $isdst) DOELSE
   NAME       SommerzeitWinterzeit
   NR         5808
   NTFY_ORDER 50-SommerzeitWinterzeit
   STATE      Sommer
   TYPE       DOIF
   READINGS:
     2018-03-06 18:26:49   cmd             1
     2018-03-06 18:26:49   cmd_event       set_Sommer_cmd_1
     2018-03-06 18:26:49   cmd_nr          1
     2018-03-06 17:34:06   mode            enabled
     2018-03-06 18:26:49   state           Sommer
     2018-03-06 17:33:18   timer_01_c01    07.03.2018 02:00:00
     2018-03-06 17:33:18   timer_02_c01    07.03.2018 03:00:00
   Regex:
   condition:
     0          (DOIF_time_once($hash,0,$wday) or DOIF_time_once($hash,1,$wday)) and $isdst
   days:
   devices:
   do:
     0:
       0         
     1:
       0         
   helper:
     DOIF_Readings_events
     DOIF_eventas
     globalinit 1
     last_timer 2
     sleeptimer -1
   itimer:
   localtime:
     0          1520384400
     1          1520388000
   realtime:
     0          02:00:00
     1          03:00:00
   time:
     0          02:00:00
     1          03:00:00
   timeCond:
     0          0
     1          0
   timer:
     0          0
     1          0
   timers:
     0           0  1
   triggertime:
     1520384400:
       localtime  1520384400
       hash:
     1520388000:
       localtime  1520388000
       hash:
   uiState:
   uiTable:
Attributes:
   cmdState   Sommer|Winter

Aber wie sollte das DOIF aussehen für die Neu Initialisierung der Timer? Würde das so funktionieren und Sinn machen? Geht es besser? Ich hab zum Testen mal einen Dummy angelegt.

Code: [Auswählen]

Internals:
   CFGFN     
   DEF        ([SommerzeitWinterzeit] eq "Winter") (set SommerWinter.Dummy Winter )
DOELSEIF
([SommerzeitWinterzeit] eq "Sommer") (set SommerWinter.Dummy Sommer )

   NAME       WinterSommer_Initialisierung
   NR         7421
   NTFY_ORDER 50-WinterSommer_Initialisierung
   STATE      cmd_2
   TYPE       DOIF
   READINGS:
     2018-03-06 18:44:44   Device          SommerzeitWinterzeit
     2018-03-06 18:44:44   cmd             2
     2018-03-06 18:44:44   cmd_event       SommerzeitWinterzeit
     2018-03-06 18:44:44   cmd_nr          2
     2018-03-06 18:44:44   e_SommerzeitWinterzeit_STATE Sommer
     2018-03-06 18:43:48   mode            enabled
     2018-03-06 18:44:44   state           cmd_2
   Regex:
   condition:
     0          InternalDoIf($hash,'SommerzeitWinterzeit','STATE') eq "Winter"
     1          InternalDoIf($hash,'SommerzeitWinterzeit','STATE') eq "Sommer"
   devices:
     0           SommerzeitWinterzeit
     1           SommerzeitWinterzeit
     all         SommerzeitWinterzeit
   do:
     0:
       0          set SommerWinter.Dummy Winter
     1:
       0          set SommerWinter.Dummy Sommer
     2:
   helper:
     DOIF_Readings_events
     DOIF_eventas
     event      cmd_nr: 1,cmd: 1,cmd_event: set_Sommer_cmd_1,Sommer
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   SommerzeitWinterzeit
     timerevent cmd_nr: 1,cmd: 1,cmd_event: set_Sommer_cmd_1,Sommer
     triggerDev SommerzeitWinterzeit
     timerevents:
       cmd_nr: 1
       cmd: 1
       cmd_event: set_Sommer_cmd_1
       Sommer
     timereventsState:
       cmd_nr: 1
       cmd: 1
       cmd_event: set_Sommer_cmd_1
       state: Sommer
     triggerEvents:
       cmd_nr: 1
       cmd: 1
       cmd_event: set_Sommer_cmd_1
       Sommer
     triggerEventsState:
       cmd_nr: 1
       cmd: 1
       cmd_event: set_Sommer_cmd_1
       state: Sommer
   internals:
     0           SommerzeitWinterzeit:STATE
     1           SommerzeitWinterzeit:STATE
     all         SommerzeitWinterzeit:STATE
   itimer:
   readings:
   trigger:
   uiState:
   uiTable:
Attributes:

Vielen Dank für den Input.

[Damian]

Ich denke, den Aufwand kannst du dir sparen. Ich habe die Zeitumstellung im Modul berücksichtigt