Hallo,
ich wollte DOIF dazu benutzen, um mir eine Urlaubsteuerung für meine Jalousien zu schreiben. Da ich nicht immer Urlaub habe :(, wollte ich die Definition dann per Attribute disable = 1 inaktiv schalten. Soweit funktioniert alles, aber wenn ich disable = 0 setzte, wird die Urlaubssteuerung nicht ausgeführt.
Zum Nachvollziehen habe ich die Definition aufs Wesentliche reduziert:
define RollosTEST DOIF ([08:25])\
({Log 3, "Rollos TEST"})\
DOELSEIF ([21:25])\
({Log 3, "Rollos TEST"})
attr RollosTEST do always
Nachdem ich das Gerät gestern mal wieder aktiviert habe, wurden folgende Readings angezeigt:
Readings
state initialized 2015-05-10 19:05:33
timer_1_c1 04.05.2015 08:25:00 2015-05-03 08:25:00
timer_2_c2 03.05.2015 21:25:00 2015-05-02 21:25:00
Was auffällt sind die timer-Readings, die in der Vergangenheit liegen, daher ist es kein Wunder, dass nichts ausgeführt wird. Auch ein nochmaliges setzen des Attributes disable ändert nichts an den timer-Readings. Wenn ich aber die Definition im Frontend neu speichere, also "modify RolloTEST" ohne Änderung, werden die Readings neu berechnet:
Readings
state initialized 2015-05-11 09:04:45
timer_1_c1 12.05.2015 08:25:00 2015-05-11 09:04:45
timer_2_c2 11.05.2015 21:25:00 2015-05-11 09:04:45
Ab jetzt funktioniert wieder alles. Ich erwarte doch aber, dass ein disable = 0 ausreicht, um die Definition wieder zu aktivieren.
Das sieht für mich nach eine Bug im DOIF aus oder?
Viele Grüße
Zitat von: vuffiraa am 11 Mai 2015, 12:57:25
Hallo,
ich wollte DOIF dazu benutzen, um mir eine Urlaubsteuerung für meine Jalousien zu schreiben. Da ich nicht immer Urlaub habe :(, wollte ich die Definition dann per Attribute disable = 1 inaktiv schalten. Soweit funktioniert alles, aber wenn ich disable = 0 setzte, wird die Urlaubssteuerung nicht ausgeführt.
Zum Nachvollziehen habe ich die Definition aufs Wesentliche reduziert:
define RollosTEST DOIF ([08:25])\
({Log 3, "Rollos TEST"})\
DOELSEIF ([21:25])\
({Log 3, "Rollos TEST"})
attr RollosTEST do always
Nachdem ich das Gerät gestern mal wieder aktiviert habe, wurden folgende Readings angezeigt:
Readings
state initialized 2015-05-10 19:05:33
timer_1_c1 04.05.2015 08:25:00 2015-05-03 08:25:00
timer_2_c2 03.05.2015 21:25:00 2015-05-02 21:25:00
Was auffällt sind die timer-Readings, die in der Vergangenheit liegen, daher ist es kein Wunder, dass nichts ausgeführt wird. Auch ein nochmaliges setzen des Attributes disable ändert nichts an den timer-Readings. Wenn ich aber die Definition im Frontend neu speichere, also "modify RolloTEST" ohne Änderung, werden die Readings neu berechnet:
Readings
state initialized 2015-05-11 09:04:45
timer_1_c1 12.05.2015 08:25:00 2015-05-11 09:04:45
timer_2_c2 11.05.2015 21:25:00 2015-05-11 09:04:45
Ab jetzt funktioniert wieder alles. Ich erwarte doch aber, dass ein disable = 0 ausreicht, um die Definition wieder zu aktivieren.
Das sieht für mich nach eine Bug im DOIF aus oder?
Viele Grüße
So wie es jetzt programmiert ist, sollten eigentlich die Timer weiter laufen. Das sieht dann nach einem Bug aus. Dann wollen wir mal hoffen, dass sich das Verhalten nachstellen lässt.
Gruß
Damian
Zitat von: Damian am 11 Mai 2015, 13:16:55
So wie es jetzt programmiert ist, sollten eigentlich die Timer weiter laufen. Das sieht dann nach einem Bug aus. Dann wollen wir mal hoffen, dass sich das Verhalten nachstellen lässt.
Zu mindestens auf meinem System kann ich es gut nachstellen. Im Original und in der abgespeckten Variante, wie hier gepostet.
Gruß Ulf
Zitat von: vuffiraa am 11 Mai 2015, 15:40:12
Zu mindestens auf meinem System kann ich es gut nachstellen. Im Original und in der abgespeckten Variante, wie hier gepostet.
Gruß Ulf
tja, wie so oft, bei mir funktioniert alles, wie es soll:
nternals:
CFGFN
DEF ([+00:01]) (set bla on) DOELSEIF([+00:00:15])(set bla off)
NAME di_test
NR 4494
NTFY_ORDER 50-di_test
STATE disabled
TYPE DOIF
Readings:
2015-05-11 15:56:51 cmd_event timer_2
2015-05-11 15:56:51 cmd_nr 2
2015-05-11 15:56:51 error set bla off: Please define bla first
2015-05-11 15:57:03 state disabled
2015-05-11 15:57:06 timer_1_c1 11.05.2015 15:58:06
2015-05-11 15:57:51 timer_2_c2 11.05.2015 15:58:06
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"")
1 DOIF_time_once($hash->{timer}{1},$wday,"")
Days:
Devices:
Do:
0 set bla on
1 set bla off
Helper:
last_timer 2
sleeptimer -1
Internals:
Itimer:
Readings:
Realtime:
0 15:58:06
1 15:58:06
State:
Time:
0 +00:01
1 +00:00:15
Timecond:
0 0
1 1
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0
1 1
Attributes:
disable 1
do always mit disable 1, disable 0 und mit gelöschtem disable wird immer die Zeit weitergeführt.
Hast du die letzte Version des Moduls?
$Id: 98_DOIF.pm 8432 2015-04-13 19:34:11Z damian-s $
Gruß
Damian
Zitat von: Damian am 11 Mai 2015, 16:02:50
tja, wie so oft, bei mir funktioniert alles, wie es soll:
Hast du die letzte Version des Moduls?
$Id: 98_DOIF.pm 8432 2015-04-13 19:34:11Z damian-s $
Ja, genau diese Version habe ich.
Ich habe dein Beispiel mal bei mir eingefügt und es die Timer wurden aktualisiert ... erst mal ...
Du hast mich etwas ins Schwitzen gebracht, da jetzt bei allen meinen DOIF-Geräten die Timer aktualisiert wurden, egal wie
disable gesetzt war.
Mein Idee war dann ein
shutdown restart, dann war das beobachtete Verhalten wieder da:
Internals:
DEF ([+00:01])
({Log 3, "Rollos 00:01"})
DOELSEIF ([+00:15])
({Log 3, "Rollos 00:15"})
NAME RollosTEST2
NR 306
NTFY_ORDER 50-RollosTEST2
STATE initialized
TYPE DOIF
CHANGETIME:
Readings:
2015-05-12 08:51:45 state initialized
2015-05-12 08:29:38 timer_1_c1 12.05.2015 08:30:38
2015-05-12 08:16:38 timer_2_c2 12.05.2015 08:31:38
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"")
1 DOIF_time_once($hash->{timer}{1},$wday,"")
Devices:
Do:
0 {Log 3, "Rollos 00:01"}
1 {Log 3, "Rollos 00:15"}
Helper:
last_timer 2
sleeptimer -1
Itimer:
State:
Time:
0 +00:01
1 +00:15
Timecond:
0 0
1 1
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0
1 1
Attributes:
DbLogExclude .*
do always
room ZentralGruß Ulf
Zitat von: vuffiraa am 12 Mai 2015, 08:56:40
Ja, genau diese Version habe ich.
Ich habe dein Beispiel mal bei mir eingefügt und es die Timer wurden aktualisiert ... erst mal ...
Du hast mich etwas ins Schwitzen gebracht, da jetzt bei allen meinen DOIF-Geräten die Timer aktualisiert wurden, egal wie disable gesetzt war.
Mein Idee war dann ein shutdown restart, dann war das beobachtete Verhalten wieder da:
Internals:
DEF ([+00:01])
({Log 3, "Rollos 00:01"})
DOELSEIF ([+00:15])
({Log 3, "Rollos 00:15"})
NAME RollosTEST2
NR 306
NTFY_ORDER 50-RollosTEST2
STATE initialized
TYPE DOIF
CHANGETIME:
Readings:
2015-05-12 08:51:45 state initialized
2015-05-12 08:29:38 timer_1_c1 12.05.2015 08:30:38
2015-05-12 08:16:38 timer_2_c2 12.05.2015 08:31:38
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"")
1 DOIF_time_once($hash->{timer}{1},$wday,"")
Devices:
Do:
0 {Log 3, "Rollos 00:01"}
1 {Log 3, "Rollos 00:15"}
Helper:
last_timer 2
sleeptimer -1
Itimer:
State:
Time:
0 +00:01
1 +00:15
Timecond:
0 0
1 1
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0
1 1
Attributes:
DbLogExclude .*
do always
room Zentral
Gruß Ulf
Ok. Damit kann ich was anfangen. Mal schauen, ob ich kurzfristig etwas ändern kann. Langfrist will ich den Mechanismus ändern, dass ein Modul bei disable komplett stillgelegt wird und bei enable die Timer neuaufgesetzt werden. Es soll auch einen Befehl set disable/enable geben.
Gruß
Damian
Die Aufgabe lässt sich auch wie folgt lösen:
define du_holiday dummy
attr du_holiday setList on off
define RollosTEST DOIF ([08:25] and [du_holiday] eq "on")\
({Log 3, "Rollos TEST"})\
DOELSEIF ([21:25] and [du_holiday] eq "on")\
({Log 3, "Rollos TEST"})
attr RollosTEST do always
Das hat den Vorteil, dass man du_holiday im Frontend setzen und darstellen kann.
Gruss
flurin
Zitat von: flurin am 12 Mai 2015, 09:42:30Das hat den Vorteil, dass man du_holiday im Frontend setzen und darstellen kann.
Gutes Argument für deine Lösung. Bisher fand ich das
disable im Gerät gar nicht so schlimm, aber so kann ich es meiner Regierung auch viel besser verkaufen.
Gruß Ulf
Zitat von: vuffiraa am 16 Mai 2015, 13:17:41
Gutes Argument für deine Lösung. Bisher fand ich das disable im Gerät gar nicht so schlimm, aber so kann ich es meiner Regierung auch viel besser verkaufen.
Gruß Ulf
Wie schon bereits gewünscht, wird es auch ein set disable/enable geben. Das hat den Vorteil im Gegensatz zum Attribut, dass die Konfiguration nicht gespeichert werden muss nach Änderung. Auf der anderen Seite kann man auch ohne Dummys jederzeit ein Modul aktivieren bzw. deaktivieren.
Gruß
Damian
Hallo,
gibt es was neues zum enable beim DOIF? Ich habe auch das Problem, daß meine Beschattungssteuerung sich zwar disablen lässt aber eben nicht mehr enablen... oder wäre da ein initialize eine Lösung?
Hier mein Code:
zuerst das DOIF für die Beschattung
define SW_Rollo_Sommer_Beschattung DOIF (\
[TC_Twilight:azimuth] > 110 and \
[TC_Twilight:azimuth] < 270 and \
[TC_Twilight:elevation] > 25 and \
[MeinWetter:condition] =~ /sonnig|heiter|klar|heiß|teilweise wolkig|wolkig/ and \
[MeinWetter:fc1_high_c] >= 23 and \
[HomeStatus] eq "1"\
) (set SuedWestRollo schlitz, set fhem_marco_bot message Sonnenschutz hinten schlitz) \
DOELSEIF (\
[TC_Twilight:azimuth] > 110 and \
[TC_Twilight:azimuth] < 270 and \
[TC_Twilight:elevation] > 25 and \
[MeinWetter:condition] =~ /sonnig|heiter|klar|heiß|teilweise wolkig|wolkig/ and \
[MeinWetter:fc1_high_c] >= 23 and \
[HomeStatus] ne "1"\
) (set SuedWestRollo geschlossen, set fhem_marco_bot message Sonnenschutz hinten geschlossen) \
DOELSE (set SuedWestRollo offen, set fhem_marco_bot message Sonnenschutz hinten aus)
jetzt noch das disablen:
define SW_Rollos DOIF (\
[16:00-23:00] and \
[TC_Twilight:twilight]<61\
) (set SuedWestRollo geschlossen, set SW_Rollo_Sommer_Beschattung disable 1) \
DOELSEIF (\
(\
[06:00-10:00|8] or \
[8:30-11:00|7]\
) and \
[TC_Twilight:twilight] > 46\
) (set SuedWestRollo offen, set SW_Rollo_Sommer_Beschattung disable 0)
Oder wie würdet ihr das lösen?
(Die Idee ist, daß die Rolläden nachts runterfahren- abhängig von Wochentag, Uhrzeit und Twilight und die Beschattung in Abhängigkeit vom Wetter runterfährt aber nur komplett wenn niemand zuhause ist. Ist im Beschattungszustand jemand zuhause oder kommt nach Hause bitte nur auf Position Schlitz)
Danke und Gruß,
Marco
Zitat von: MarcoE am 24 Mai 2016, 12:51:42
Hallo,
gibt es was neues zum enable beim DOIF? Ich habe auch das Problem, daß meine Beschattungssteuerung sich zwar disablen lässt aber eben nicht mehr enablen... oder wäre da ein initialize eine Lösung?
Hier mein Code:
zuerst das DOIF für die Beschattung
define SW_Rollo_Sommer_Beschattung DOIF (\
[TC_Twilight:azimuth] > 110 and \
[TC_Twilight:azimuth] < 270 and \
[TC_Twilight:elevation] > 25 and \
[MeinWetter:condition] =~ /sonnig|heiter|klar|heiß|teilweise wolkig|wolkig/ and \
[MeinWetter:fc1_high_c] >= 23 and \
[HomeStatus] eq "1"\
) (set SuedWestRollo schlitz, set fhem_marco_bot message Sonnenschutz hinten schlitz) \
DOELSEIF (\
[TC_Twilight:azimuth] > 110 and \
[TC_Twilight:azimuth] < 270 and \
[TC_Twilight:elevation] > 25 and \
[MeinWetter:condition] =~ /sonnig|heiter|klar|heiß|teilweise wolkig|wolkig/ and \
[MeinWetter:fc1_high_c] >= 23 and \
[HomeStatus] ne "1"\
) (set SuedWestRollo geschlossen, set fhem_marco_bot message Sonnenschutz hinten geschlossen) \
DOELSE (set SuedWestRollo offen, set fhem_marco_bot message Sonnenschutz hinten aus)
jetzt noch das disablen:
define SW_Rollos DOIF (\
[16:00-23:00] and \
[TC_Twilight:twilight]<61\
) (set SuedWestRollo geschlossen, set SW_Rollo_Sommer_Beschattung disable 1) \
DOELSEIF (\
(\
[06:00-10:00|8] or \
[8:30-11:00|7]\
) and \
[TC_Twilight:twilight] > 46\
) (set SuedWestRollo offen, set SW_Rollo_Sommer_Beschattung disable 0)
Oder wie würdet ihr das lösen?
(Die Idee ist, daß die Rolläden nachts runterfahren- abhängig von Wochentag, Uhrzeit und Twilight und die Beschattung in Abhängigkeit vom Wetter runterfährt aber nur komplett wenn niemand zuhause ist. Ist im Beschattungszustand jemand zuhause oder kommt nach Hause bitte nur auf Position Schlitz)
Danke und Gruß,
Marco
Kurzfristiges Disablen kann man per set ... diable realisieren, das Gegenstück ist set ... initialize.
Steht aber alles hier:
http://fhem.de/commandref_DE.html#DOIF_disable
Hallo,
die commandref hatte ich schon gelesen- nur in den Posts hier in diesem Thread stand eben was von einer Weiterentwicklung mit einem enable (16.5.2015). Daher hatte ich gedacht, daß dies vielleicht besser passen würde als der initialize.
Danke und Gruss, Marco