Ich wollte statt dst() gerne ein richtiges Reading nutzen können und habe mir dafür dieses DOIF erstellt:
define DST DOIF
(
([02:00] or [03:00]) and
$isdst
)
DOELSE
Folgende Attribute wurden gesetzt:
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
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..! :D
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:
define DST DOIF ([DST])
OK gute Idee, hatte ich bisher auch noch nicht gemacht..! ;) :D
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
Zitat von: Loredo am 13 Oktober 2015, 10:28:47
Ich wollte statt dst() gerne ein richtiges Reading nutzen können und habe mir dafür dieses DOIF erstellt:
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:
define DST DOIF (([02:00] or [03:00]) and $isdst) DOELSE
Gruß
Damian
das ist ja noch geiler! Und damit zähle ich jetzt bei mir 23 DOIF :) 8)
Hallo,
ich habe nun folgendes DOIF angelegt um die Sommerzeit/Winterzeit abzufragen.
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
Zitat von: tik-tak-tok am 29 März 2017, 21:06:02
Hallo,
ich habe nun folgendes DOIF angelegt um die Sommerzeit/Winterzeit abzufragen.
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.
DOIF ([SommerzeitWinterzeit] eq "summer") (set bla on)
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
Zitat von: tik-tak-tok am 30 März 2017, 18:39:23
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.
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 :-)
Zitat von: tik-tak-tok am 30 März 2017, 20:33:28
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 ;)
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
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.
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.
Ich denke, den Aufwand kannst du dir sparen. Ich habe die Zeitumstellung im Modul berücksichtigt ;)
Zitat von: Damian am 06 März 2018, 19:25:24
Ich denke, den Aufwand kannst du dir sparen. Ich habe die Zeitumstellung im Modul berücksichtigt ;)
Ah ok, schon länger? Danke! :)
Schon immer.
Bsp.:
DOIF ([07:00) (...)
Das Modul triggert immer um sieben Uhr vor und nach der Zeitumstellung.
Zitat von: Damian am 06 März 2018, 22:02:27
Schon immer.
Bsp.:
DOIF ([07:00) (...)
Das Modul triggert immer um sieben Uhr vor und nach der Zeitumstellung.
Guten Morgen,
ich hab gestern nicht richtig über deine Antwort nachgedacht.
Genau das ist in meinem Fall nämlich das "Problem" am Tag der Zeitumstellung.
Meine Jalousienautomatik läuft nicht mit Festen Uhrzeiten sondern z.B. mit Twilight (Sunrise) in einem Bestimmten Zeitrahmen. D.h. am Tag der Zeitumstelllung Würde nach alter Zeit der Timer auf z.B. 6:50 generiert, aber da ist es noch Dunkel, weil nach neuer Zeit müsste dann die Jalousie erst um 7:50 Uhr Hochfahren. Abends fährt sie dann um 17 Uhr runter, obwohl Sie nach Zeitumstellung erst gegen 18 Uhr runter fahren müsste. Ist klagen auf Hohem Niveau, da es genau 2 Tage im Jahr betrifft wo meine Jalousienautomatik nicht Sauber läuft.
Daher müsste ich entweder die DOIFs nach der Zeitumstellung neu Initialisieren oder FHEM neustarten lassen (dann werden vermutlich ja auch alle Timer neu generiert?).
Der Fehler entsteht wohl im twilight Modul.
Zitat von: Xell1984 am 07 März 2018, 08:04:49
Guten Morgen,
ich hab gestern nicht richtig über deine Antwort nachgedacht.
Genau das ist in meinem Fall nämlich das "Problem" am Tag der Zeitumstellung.
Meine Jalousienautomatik läuft nicht mit Festen Uhrzeiten sondern z.B. mit Twilight (Sunrise) in einem Bestimmten Zeitrahmen. D.h. am Tag der Zeitumstelllung Würde nach alter Zeit der Timer auf z.B. 6:50 generiert, aber da ist es noch Dunkel, weil nach neuer Zeit müsste dann die Jalousie erst um 7:50 Uhr Hochfahren. Abends fährt sie dann um 17 Uhr runter, obwohl Sie nach Zeitumstellung erst gegen 18 Uhr runter fahren müsste. Ist klagen auf Hohem Niveau, da es genau 2 Tage im Jahr betrifft wo meine Jalousienautomatik nicht Sauber läuft.
Daher müsste ich entweder die DOIFs nach der Zeitumstellung neu Initialisieren oder FHEM neustarten lassen (dann werden vermutlich ja auch alle Timer neu generiert?).
Der Fehler entsteht wohl im twilight Modul.
Wenn du nach der Zeitumstellung andere Zeiten haben willst, als vorher, dann wirst du dich selbst drum kümmern müssen, in dem du indirekte Zeiten benutzt, die du, wie auch immer anpassen musst, dann wird automatisch die Zeit im Modul neuberechnet.
Hallo,
ich habe auf der Suche nach der Bedeutung von "istdst" brav in der ComandRef gesucht und habe (nur) das hier gefunden:
IsDST = 1 if running on daylight savings time, 0 otherwise
Ich bin auf der Suche nach einer Möglichkeit, innerhalb eines DOIFs nach Sommer- und Winterzeit abzufragen.
Was ist "daylight savings time"?
Gruß Chris
Zitat von: chq am 16 Mai 2021, 09:21:52Was ist "daylight savings time"?
Sommerzeit.
ZitatDaylight Saving Time, siehe Sommerzeit (https://de.wikipedia.org/wiki/Sommerzeit)
https://de.wikipedia.org/wiki/DST (https://de.wikipedia.org/wiki/DST)
$isdst müsste 1 wiedergeben, wenn Sommerzeit (DST) gesetzt ist.
@Damian: hängt das von den Systemzeiteinstellungen oder DOIF ab?
Zitat von: yersinia am 16 Mai 2021, 13:26:48
Sommerzeit.https://de.wikipedia.org/wiki/DST (https://de.wikipedia.org/wiki/DST)
$isdst müsste 1 wiedergeben, wenn Sommerzeit (DST) gesetzt ist.
@Damian: hängt das von den Systemzeiteinstellungen oder DOIF ab?
$isdst wird vom System bestimmt.
Hallo zusammen,
ich habe seitdem es "Winterzeit" ist folgendes Problem.
Ich nutze den Codeschnipsel zur Ausgabe ob Winter- oder Sommerzeit schon seit ein paar Jahren, jetzt ist es allerdings so, dass er nach der automatischen Abfrage auf "Sommer" steht, wenn ich aber ein manuelles "Checkall" mache, wird es wieder Winter.
Kann mir dabei jemand helfen??
VG Felix
Immer ein List vom vermeintlich falschen Zustand des Moduls posten.
Hallo Damian,
hier der Auszug aus der fhem.cfg
define SommerzeitWinterzeit DOIF (([02:00] or [03:00]) and $isdst) DOELSE
setuuid SommerzeitWinterzeit 5e83080c-f33f-64a8-2ab9-528ef299b3ddef2f
attr SommerzeitWinterzeit cmdState summer|winter
attr SommerzeitWinterzeit event-on-change-reading state
attr SommerzeitWinterzeit eventMap winter:Winter summer:Sommer initialized:---
attr SommerzeitWinterzeit icon time_clock
attr SommerzeitWinterzeit room Kalender,Rollladen
und hier das list
Internals:
DEF (([02:00] or [03:00]) and $isdst) DOELSE
FUUID 5e83080c-f33f-64a8-2ab9-528ef299b3ddef2f
MODEL FHEM
NAME SommerzeitWinterzeit
NOTIFYDEV global
NR 276
NTFY_ORDER 50-SommerzeitWinterzeit
STATE Sommer
TYPE DOIF
VERSION 24905 2021-09-01 18:35:54
READINGS:
2021-10-14 02:00:00 cmd 1
2021-10-14 02:00:00 cmd_event timer_1
2021-10-14 02:00:00 cmd_nr 1
2021-10-13 16:26:37 mode enabled
2021-10-14 02:00:00 state summer
2021-10-14 02:00:00 timer_01_c01 15.10.2021 02:00:00
2021-10-14 03:00:00 timer_02_c01 15.10.2021 03:00:00
Regex:
accu:
collect:
attr:
cmdState:
0:
summer
1:
winter
wait:
waitdel:
condition:
0 (::DOIF_time_once($hash,0,$wday) or ::DOIF_time_once($hash,1,$wday)) and $isdst
days:
do:
0:
0
1:
0
helper:
DEVFILTER ^global$
NOTIFYDEV global
event timer_2
globalinit 1
last_timer 2
sleeptimer -1
timerdev
timerevent timer_2
triggerDev
timerevents:
timer_2
timereventsState:
timer_2
triggerEvents:
timer_2
triggerEventsState:
timer_2
interval:
intervalfunc:
localtime:
0 1634256000
1 1634259600
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:
1634256000:
localtime 1634256000
hash:
1634259600:
localtime 1634259600
hash:
uiState:
uiTable:
Attributes:
cmdState summer|winter
event-on-change-reading state
eventMap winter:Winter summer:Sommer initialized:---
icon time_clock
room Kalender,Rollladen
Hallo Damian,
ist bei mir ähnlich, im Moment ist ja noch Sommerzeit, aber ein 'set SommerzeitWinterzeit checkall' ergibt "Winter" für heute:
defmod SommerzeitWinterzeit DOIF (([02:00] or [03:00]) and $isdst) ({fhem("\"cp /opt/fhem/www/pgm2/station-clock.js.sommerzeit /opt/fhem/www/pgm2/station-clock.js\"")}) DOELSE({fhem("\"cp /opt/fhem/www/pgm2/station-clock.js.winterzeit /opt/fhem/www/pgm2/station-clock.js\"")})
attr SommerzeitWinterzeit cmdState summer|winter
attr SommerzeitWinterzeit comment (([02:00] or [03:00]) and $isdst) DOELSE()
attr SommerzeitWinterzeit event-on-change-reading state
attr SommerzeitWinterzeit eventMap eventMap summer:Sommer winter:Winter initialized:---
attr SommerzeitWinterzeit room System,Weather
setstate SommerzeitWinterzeit Winter
setstate SommerzeitWinterzeit 2021-10-14 19:03:15 cmd 2
setstate SommerzeitWinterzeit 2021-10-14 19:03:15 cmd_event SommerzeitWinterzeit
setstate SommerzeitWinterzeit 2021-10-14 19:03:15 cmd_nr 2
setstate SommerzeitWinterzeit 2021-10-14 19:03:15 state winter
setstate SommerzeitWinterzeit 2021-10-14 02:00:00 timer_01_c01 15.10.2021 02:00:00
setstate SommerzeitWinterzeit 2021-10-14 03:00:00 timer_02_c01 15.10.2021 03:00:00
Internals:
DEF (([02:00] or [03:00]) and $isdst) ({fhem("\"cp /opt/fhem/www/pgm2/station-clock.js.sommerzeit /opt/fhem/www/pgm2/station-clock.js\"")}) DOELSE({fhem("\"cp /opt/fhem/www/pgm2/station-clock.js.winterzeit /opt/fhem/www/pgm2/station-clock.js\"")})
FUUID 5c42ee3e-f33f-97bf-ef38-fbfe31549a9430d7
MODEL FHEM
NAME SommerzeitWinterzeit
NOTIFYDEV global
NR 45
NTFY_ORDER 50-SommerzeitWinterzeit
STATE Winter
TYPE DOIF
VERSION 24905 2021-09-01 18:35:54
READINGS:
2021-10-14 19:03:15 cmd 2
2021-10-14 19:03:15 cmd_event SommerzeitWinterzeit
2021-10-14 19:03:15 cmd_nr 2
2021-10-14 19:03:15 state winter
2021-10-14 02:00:00 timer_01_c01 15.10.2021 02:00:00
2021-10-14 03:00:00 timer_02_c01 15.10.2021 03:00:00
Regex:
accu:
collect:
attr:
cmdState:
0:
summer
1:
winter
wait:
waitdel:
condition:
0 (::DOIF_time_once($hash,0,$wday) or ::DOIF_time_once($hash,1,$wday)) and $isdst
days:
do:
0:
0 {fhem("\"cp /opt/fhem/www/pgm2/station-clock.js.sommerzeit /opt/fhem/www/pgm2/station-clock.js\"")}
1:
0 {fhem("\"cp /opt/fhem/www/pgm2/station-clock.js.winterzeit /opt/fhem/www/pgm2/station-clock.js\"")}
helper:
DEVFILTER ^global$
NOTIFYDEV global
event timer_2
globalinit 1
last_timer 2
sleeptimer -1
timerdev
timerevent timer_2
timerevents
timereventsState
triggerDev
DOIF_eventa:
cmd_nr: 2
cmd: 2
cmd_event: SommerzeitWinterzeit
winter
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: SommerzeitWinterzeit
state: winter
interval:
intervalfunc:
localtime:
0 1634256000
1 1634259600
perlblock:
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:
1634256000:
localtime 1634256000
hash:
1634259600:
localtime 1634259600
hash:
uiState:
uiTable:
Attributes:
cmdState summer|winter
comment (([02:00] or [03:00]) and $isdst) DOELSE()
event-on-change-reading state
eventMap eventMap summer:Sommer winter:Winter initialized:---
room System,Weather
Zitat von: Jamo am 14 Oktober 2021, 19:06:11
ist bei mir ähnlich, im Moment ist ja noch Sommerzeit, aber ein 'set SommerzeitWinterzeit checkall' ergibt "Winter" für heute:
Abfrage per checkall macht bei dieser Definition keinen Sinn, denn Zeitpunkttrigger [02:00] bzw. [03:00] sind ja nur zu diesem Triggerzeitpunkt wahr und sonst nicht, daher ergibt die AND-Verknüpfung logischerweise false, was zu cmd_2 führt und damit "Winter".
Zitat von: Doogy am 14 Oktober 2021, 16:43:00
und hier das list
Internals:
DEF (([02:00] or [03:00]) and $isdst) DOELSE
FUUID 5e83080c-f33f-64a8-2ab9-528ef299b3ddef2f
MODEL FHEM
NAME SommerzeitWinterzeit
NOTIFYDEV global
NR 276
NTFY_ORDER 50-SommerzeitWinterzeit
STATE Sommer
TYPE DOIF
VERSION 24905 2021-09-01 18:35:54
READINGS:
2021-10-14 02:00:00 cmd 1
2021-10-14 02:00:00 cmd_event timer_1
2021-10-14 02:00:00 cmd_nr 1
2021-10-13 16:26:37 mode enabled
2021-10-14 02:00:00 state summer
2021-10-14 02:00:00 timer_01_c01 15.10.2021 02:00:00
2021-10-14 03:00:00 timer_02_c01 15.10.2021 03:00:00
...
hier funktioniert alles richtig. Um 02:00 Uhr wurde der Zustand cmd_1 also "Sommer" gesetzt.
Zitat von: Damian am 16 Oktober 2021, 11:14:45
Abfrage per checkall macht bei dieser Definition keinen Sinn, denn Zeitpunkttrigger [02:00] bzw. [03:00] sind ja nur zu diesem Triggerzeitpunkt wahr und sonst nicht, daher ergibt die AND-Verknüpfung logischerweise false, was zu cmd_2 führt und damit "Winter".
Ja, stimmt, sorry das war Unsinn was ich da gemacht habe. Mea Culpa!