Hallo zusammen,
hab ein Problem mit einer DOIF Definition:
Ich möchte die Fussbodenheizung zu bestimmten Zeiten ein bzw ausschalten wenn ein Dummy auf "automatic" steht;
Komischerweise bekommt er auch den trigger (timer_3 in diesem Fall) nimmt aber (aus meiner Sicht) den Falschen Befehl:
(([07:30-08:30] or [18:00-19:30]) and [fbh.auto] eq "Automatik") (set bad.fbh on;) DOELSEIF ([fbh.auto] eq "on") (set bad.fbh on;) DOELSE (set bad.fbh off;)
Readings:
cmd_event
timer_3
2014-09-22 18:00:00
cmd_nr
3
2014-09-22 18:00:00
state
cmd_3
2014-09-22 18:00:00
timer_1_c1
23.09.2014 07:30:00
2014-09-22 07:30:00
timer_2_c1
23.09.2014 08:30:00
2014-09-22 08:30:00
timer_3_c1
23.09.2014 18:00:00
2014-09-22 18:00:00
timer_4_c1
22.09.2014 19:30:00
2014-09-21 20:28:24
Kann mir jemand erklären auf welchem Schlauch ich stehe? :-)
Danke schonmal
achso, morgen einschalten ging :-) Auch der Wechsel fbh.auto = on bzw bfh.auto = off tut
Zitat von: kupfermuetze am 22 September 2014, 18:35:43
achso, morgen einschalten ging :-) Auch der Wechsel fbh.auto = on bzw bfh.auto = off tut
Zitat aus der Doku von DOIF:
"Die Angaben werden immer von links nach rechts abgearbeitet. Es wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist.
Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch ein Device beinhalten (Angaben in eckigen Klammern)."
Wenn um 18:00 der Timer_3 zuschlägt, dann wird die zweite Bedingung nicht überprüft, weil kein Ereignis dazu stattgefunden hat und dein DOELSE-Fall wird ausgeführt.
Tipp:
Statt DOELSE, DOELSEIF mit Bedingung für set bad.fbh off definieren. Übrigens, du brauchst kein Semikolon jeweils am Ende anzugeben.
Gruß
Damian
So sollte es, wie du es erwartest, funktionieren:
(([07:30-08:30] or [18:00-19:30]) and [fbh.auto] eq "Automatik") or [fbh.auto] eq "on") (set bad.fbh on) DOELSE (set bad.fbh off)
Hier ist der Tipp aus der Doku:
"Mehrere Bedingungen, die zur Ausführung gleicher Kommandos führen, sollten zusammengefasst werden. Dadurch wird ein unnötiges Schalten aufgrund verschiedener Zustände verhindert."
Gruß
Damian
ok, dein Teil mit
ZitatHinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch ein Device beinhalten (Angaben in eckigen Klammern)."
Wenn um 18:00 der Timer_3 zuschlägt, dann wird die zweite Bedingung nicht überprüft, weil kein Ereignis dazu stattgefunden hat und dein DOELSE-Fall wird ausgeführt.
hab ich nicht verstanden (bedeutet das, dass ich immer ein Device dabei haben muss - also nie allein Uhrzeiten als Bedingung verwendet werden können?)
Ich hab das jetzt aber mal wie in deinem letzten Post geändert und werds morgen mal beobachten.
danke schonmal :-)
Zitat von: kupfermuetze am 22 September 2014, 20:28:24
(bedeutet das, dass ich immer ein Device dabei haben muss - also nie allein Uhrzeiten als Bedingung verwendet werden können?)
Nein, das heißt das nicht. Die Aussage bezieht sich nur auf devices und nicht auf Zeiten. Es gibt ja genügend Beispiele in der Doku, wo nur Uhrzeiten vorkommen.
Beispiel:
DOIF ([DEVICE1] eq "on")(set ...)DOELSEIF([DEVICE2] eq "on")(set..)DOELSE(set ...)
Wenn Device1 "off" sendet, dann wird DOELSE ausgeführt, auch wenn und Device2 "on" ist. Der zweite Fall wird nur ausgeführt, wenn Device2 "on"
sendet.
Gruß
Damian
AHHH :-) Got it :-) Danke!
Ähm habs wohl doch nicht verstanden.
Drum deshalb mal das einfachste denkbare Beispiel:
([20:40-20:41] or [20:42-20:43]) (set bad.fbh on) DOELSE (set bad.fbh off)
aber wieder - für mich - unlogische Zustände:
state
cmd_1
2014-09-23 20:41:00
timer_1_c1
23.09.2014 20:40:00
2014-09-23 20:39:26
timer_2_c1
23.09.2014 20:41:00
2014-09-23 20:39:26
timer_3_c1
23.09.2014 20:42:00
2014-09-23 20:39:26
timer_4_c1
23.09.2014 20:43:00
2014-09-23 20:39:26
Ist doch so wie in der Doku :-\
Zitat von: kupfermuetze am 23 September 2014, 20:41:59
Ähm habs wohl doch nicht verstanden.
Drum deshalb mal das einfachste denkbare Beispiel:
([20:40-20:41] or [20:42-20:43]) (set bad.fbh on) DOELSE (set bad.fbh off)
aber wieder - für mich - unlogische Zustände:
state
cmd_1
2014-09-23 20:41:00
timer_1_c1
23.09.2014 20:40:00
2014-09-23 20:39:26
timer_2_c1
23.09.2014 20:41:00
2014-09-23 20:39:26
timer_3_c1
23.09.2014 20:42:00
2014-09-23 20:39:26
timer_4_c1
23.09.2014 20:43:00
2014-09-23 20:39:26
Ist doch so wie in der Doku :-\
mach mal list von deinem DOIF-Modul
CFGFN
DEF ([20:40-20:41] or [20:42-20:43]) (set bad.fbh on) DOELSE (set bad.fbh off)
NAME di_dummy
NR 6513
NTFY_ORDER 50-di_dummy
STATE cmd_1
TYPE DOIF
Readings:
2014-09-23 20:43:00 cmd_event timer_4
2014-09-23 20:43:00 cmd_nr 1
2014-09-23 20:43:00 state cmd_1
2014-09-23 20:40:00 timer_1_c1 24.09.2014 20:40:00
2014-09-23 20:41:00 timer_2_c1 24.09.2014 20:41:00
2014-09-23 20:42:00 timer_3_c1 24.09.2014 20:42:00
2014-09-23 20:43:00 timer_4_c1 24.09.2014 20:43:00
Condition:
0 DOIF_time($hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") or DOIF_time($hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"")
Days:
Devices:
Do:
0 set bad.fbh on
1 set bad.fbh off
Helper:
last_timer 4
sleeptimer -1
Internals:
Readings:
Realtime:
0 20:40:00
1 20:41:00
2 20:42:00
3 20:43:00
State:
Time:
0 20:40:00
1 20:41:00
2 20:42:00
3 20:43:00
Timecond:
0 0
1 0
2 0
3 0
Timer:
0 0
1 0
2 0
3 0
Timerfunc:
Timers:
0 0 1 2 3
Attributes:
Merkwürdig, ich habe es bei mir nachgestellt und es funktioniert bei mir wie erwartet.
Hat er denn zwischendurch cmd_2 ausgeführt?
Gruß
Damian
ja, hat um 20:40 auf cmd_2 gestellt
Zitat von: kupfermuetze am 23 September 2014, 21:57:55
ja, hat um 20:40 auf cmd_2 gestellt
Da scheint bei dir ein Zeitversatz zu sein. Ich muss überlegen wie man das testen kann.
sehr seltsam das alles :-/
was meinst du denn mit Vesatz?
timer_1_c1 24.09.2014 20:40:00 2014-09-23 20:40:00
timer_2_c1 24.09.2014 20:41:00 2014-09-23 20:41:00
daraus würde ICH interpretieren, dass am 23. um 20:41 das Reading Timer_2_c1 auf 24. 20:41 gestellt wurde (entsprechend für timer_1).
was liefert bei dir auf der console:
define di_test DOIF ([22:40])({print "$hms\n"})
Zeit kannst du natürlich anpassen.
zumindest macht er cmd_1 :-) aber kommt eine Fehlermeldung
CFGFN
DEF ([22:04])({print "$hms\n"})
NAME di_test
NR 9783
NTFY_ORDER 50-di_test
STATE cmd_1
TYPE DOIF
Readings:
2014-09-24 22:04:00 cmd_event timer_1
2014-09-24 22:04:00 cmd_nr 1
2014-09-24 22:04:00 error {print "$hms\n"}: 1
2014-09-24 22:04:00 state cmd_1
2014-09-24 22:04:00 timer_1_c1 25.09.2014 22:04:00
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"")
Days:
Devices:
Do:
0 {print "$hms\n"}
Helper:
last_timer 1
sleeptimer -1
Internals:
Readings:
Realtime:
0 22:04:00
State:
Time:
0 22:04:00
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Attributes:
Zitat von: kupfermuetze am 24 September 2014, 22:05:16
zumindest macht er cmd_1 :-) aber kommt eine Fehlermeldung
Dass cmd_1 kommt ist klar und die Fehlermeldung ist auch für mich normal. Aber welche Zeit steht auf der Konsole? Das ist jetzt entscheidend für die Fehleranalyse. Wenn du da nicht nachschauen kannst, dann kannst du statt ({print "$hms\n"})
({Log (3,"Die Zeit beträgt: $hms")}) eingeben, dann wird die Zeit im Log erscheinen.
Gruß
Damian
2014.09.25 05:47:00 3: Die Zeit beträgt: 05:47:00
Zitat von: kupfermuetze am 25 September 2014, 05:47:38
2014.09.25 05:47:00 3: Die Zeit beträgt: 05:47:00
Die Frage ist: Was hast du bei DOIF definiert?
Wenn auch 05:47:00, dann müssen wir größere Geschütze auffahren. Ich werde mal eine Version mit Testausgaben für dich basteln.
Gruß
Damian
Ja auch um 5:47
Seltsam das alles
Zitat von: kupfermuetze am 25 September 2014, 21:09:17
Ja auch um 5:47
Seltsam das alles
Ich habe mal ein paar Testausgaben, die im Log erscheinen, eingebaut. Du kannst die angehängte Version bei dir einspielen und einen einfachen Test mit einem Zeitintervall [von-bis] laufen lassen und die Logausgaben posten.
Gruß
Damian
so, nach langer Zeit ohne Zeit zum Testen hier die Logausgaben aus deiner Spezialversion:
2014.10.02 20:45:00 2: begin: 20:45:00, end: 20:47:00, wday: 4, hms: 20:44:59, days
2014.10.02 20:45:00 2: return 0
2014.10.02 20:47:00 2: begin: 20:47:00, end: 20:48:00, wday: 4, hms: 20:46:59, days
2014.10.02 20:47:00 2: return 0
2014.10.02 20:47:00 3: CUL_HM set bad.fbh off
2014.10.02 20:48:00 2: begin: 20:47:00, end: 20:48:00, wday: 4, hms: 20:47:59, days
2014.10.02 20:48:00 2: return 1
2014.10.02 20:48:00 3: CUL_HM set bad.fbh off
Doif definition:
([20:47-20:48]) (set bad.fbh off) DOELSE (set bad.fbh off)
Grüße
Stefan
Zitat von: kupfermuetze am 02 Oktober 2014, 20:49:44
so, nach langer Zeit ohne Zeit zum Testen hier die Logausgaben aus deiner Spezialversion:
2014.10.02 20:45:00 2: begin: 20:45:00, end: 20:47:00, wday: 4, hms: 20:44:59, days
2014.10.02 20:45:00 2: return 0
2014.10.02 20:47:00 2: begin: 20:47:00, end: 20:48:00, wday: 4, hms: 20:46:59, days
2014.10.02 20:47:00 2: return 0
2014.10.02 20:47:00 3: CUL_HM set bad.fbh off
2014.10.02 20:48:00 2: begin: 20:47:00, end: 20:48:00, wday: 4, hms: 20:47:59, days
2014.10.02 20:48:00 2: return 1
2014.10.02 20:48:00 3: CUL_HM set bad.fbh off
Doif definition:
([20:47-20:48]) (set bad.fbh off) DOELSE (set bad.fbh off)
Grüße
Stefan
Das, was ich befürchtet habe - bei dir läuft die Zeit "auseinander". Der Interne FHEM-Timer ist auf 20:45 gesetzt worden, ausgeführt wurde das Kommando aber um 20:44:59. Das sind fhem.pl-Mechanismen und liegen außerhalb meines Codes. Da müsste der Chef-Entwickler etwas dazu sagen können.
Gruß
Damian
ok, hab jetzt mal die FritzBox neu gebootet und beim ersten Test scheint's zu gehen
;D Problem für den Moment gelöst :-)
ABER: wie kann ich das denn für die Zukunft verhinder? Fritzbox regelmäßig neu starten ist seit dem neuesten Firmware-Update ja auch doof (da dann ja FHEM nicht mehr automatisch startet)
Zitat von: kupfermuetze am 02 Oktober 2014, 21:07:25
ok, hab jetzt mal die FritzBox neu gebootet und beim ersten Test scheint's zu gehen
;D Problem für den Moment gelöst :-)
ABER: wie kann ich das denn für die Zukunft verhinder? Fritzbox regelmäßig neu starten ist seit dem neuesten Firmware-Update ja auch doof (da dann ja FHEM nicht mehr automatisch startet)
Wie schon gesagt, das müsste sich Rudi anschauen. hms habe ich mit localtime ermittelt
nachdem die Funktion vom Internaltimer getrigger wurde.
Gruß
Damian
OK, Vielen Dank auf jeden Fall schonmal! :-)
Zitat von: kupfermuetze am 02 Oktober 2014, 21:39:53
OK, Vielen Dank auf jeden Fall schonmal! :-)
Ich habe die Bestimmung der Zeit intern auf eine andere Routine umgestellt (gettimeofday), das sollte das Problem beheben. Kannst du schon mal mit der angehängten Version testen, bevor ich es später einchecke.
Gruß
Damian
Danke :-) Sieht erstmal prima aus (hab ein paar DOIFs getestet); werd mir morgen nochmal die FBH ankucken.