Hallo zusammen,
ich nutze das DOIF seit kurzem für die Steuerung meiner Zirkulationspumpe. Hier der Code für das DI:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an") (set Zirkulationspumpe_WW on-for-timer 300)
attr Zirku_Pumpe_auto do always
attr Zirku_Pumpe_auto wait 3600
Ich möchte erreichen, dass wenn jmd daheim ist, man nicht im Urlaub ist und die Warmwasseraufbereitung überhaupt an ist, die Pumpe für 5 Minuten einschalten und dann 60 Minuten pausieren. Grundsätzlich funktioniert das ganze zwar, jedoch gibt es folgendes Problem:
Wenn die Pumpe abends das letzte Mal an war, läuft ja der Timer los. Dann geht der "Status_Warmwasser" auf "aus". Damit ist die Bedingung nicht mehr erfüllt und das DOIF macht die Pumpe auch nciht mehr an. Wenn jetzt jedoch am nächsten Morgen um z.B. 6 Uhr die Bedingung wieder erfüllt ist, läuft der Timer dann wieder von neuem los und das DOIF löst erst um 7 Uhr aus.
Was mach ich falsch?
Zitat von: Michi240281 am 13 März 2015, 14:51:39
Ich möchte erreichen, dass wenn jmd daheim ist, man nicht im Urlaub ist und die Warmwasseraufbereitung überhaupt an ist, die Pumpe für 5 Minuten einschalten und dann 60 Minuten pausieren. Grundsätzlich funktioniert das ganze zwar, jedoch gibt es folgendes Problem:
Nee, das funktioniert nicht. Was jetzt passiert ist: Das DOIF pausiert 60 Minuten und schaltet DANN die Pumpe für 5 Minuten an. Kleiner, aber feiner Unterschied.
Schau Dir mal das Attribut
cmdpause an. Damit kannst Du festlegen, dass eine Aktion frühesten nach x Sekunden wieder ausgeführt werden soll. Das geht eher in die Richtung. Zumindest bekommst Du dann morgens beim ersten Einschalten keine Verzögerung.
Aber auch so wird die Pumpe nicht jede Stunde für 5 Minuten eingeschaltet, falls das Deine Absicht ist. Das klappt nur, wenn eine der Bedingungen das DOIF regelmäßig triggert.
Zitat von: Michi240281 am 13 März 2015, 14:51:39
Hallo zusammen,
ich nutze das DOIF seit kurzem für die Steuerung meiner Zirkulationspumpe. Hier der Code für das DI:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an") (set Zirkulationspumpe_WW on-for-timer 300)
attr Zirku_Pumpe_auto do always
attr Zirku_Pumpe_auto wait 3600
Ich möchte erreichen, dass wenn jmd daheim ist, man nicht im Urlaub ist und die Warmwasseraufbereitung überhaupt an ist, die Pumpe für 5 Minuten einschalten und dann 60 Minuten pausieren.
Versuchs mal so:
define Zirku_Pumpe_auto DOIF ([+01:00] and [Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 300)
attr Zirku_Pumpe_auto do always
Gruss
flurin
Leider funktionieren die Vorschläge alle nicht! :(
Hab jetzt das "wait" Attribut durch "cmdPause" ersetzt. Dennoch wird morgens verzögert geschaltet! Alles irgendwie dumm!
Noch irgendwelche Tipps?
Poste mal ein list Zirku_Pumpe_auto, damit wird über denselben aktuellen Stand sprechen.
Zitat von: Brockmann am 17 März 2015, 14:22:32
Poste mal ein list Zirku_Pumpe_auto, damit wird über denselben aktuellen Stand sprechen.
define Zirku_Pumpe_auto DOIF ([+01:00] and [Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 300)
Das sollte auf jeden Fall funktionieren (ohne wait).
Gruß
Damian
Zitat von: Damian am 17 März 2015, 18:04:14
define Zirku_Pumpe_auto DOIF ([+01:00] and [Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 300)
Das sollte auf jeden Fall funktionieren (ohne wait).
Gruß
Damian
Leider nein! Es wird auch dabei morgens eine Pause eingelegt und nicht beim ersten Erfüllen der Bedingung geschaltet!
Hier das list:
Internals:
DEF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600)
NAME Zirku_Pumpe_auto_neu
NR 949
NTFY_ORDER 50-Zirku_Pumpe_auto_neu
STATE cmd_1
TYPE DOIF
Readings:
2015-03-17 21:58:09 cmd_event Abwesend
2015-03-17 21:58:09 cmd_nr 1
2015-03-17 22:28:08 e_Abwesend_state nein
2015-03-17 17:00:00 e_Status_Warmwasser_state an
2015-03-17 21:58:09 state cmd_1
Condition:
0 ReadingValDoIf('Abwesend','state','') eq "nein" and ReadingValDoIf('Urlaub','state','') eq "nein" and ReadingValDoIf('Status_Warmwasser','state','') eq "an"
Devices:
0 Abwesend Urlaub Status_Warmwasser
all Abwesend Urlaub Status_Warmwasser
Do:
0 set Zirkulationspumpe_WW on-for-timer 600
Helper:
last_timer 0
sleeptimer -1
Internals:
Itimer:
Readings:
0 Abwesend:state Urlaub:state Status_Warmwasser:state
all Abwesend:state Urlaub:state Status_Warmwasser:state
State:
Trigger:
Attributes:
cmdpause 3600
do always
room Garage,Haus Und dann noch ne andere Frage: Eine Idee, warum folgendes DOIF nicht schaltet?
Internals:
DEF ([{sunset_abs("HORIZON=-2",0,"16:00","22:30")}] and [HarmonyHUB:activity] ne "PowerOff") (set Alle_Steckdosen_EG:FILTER=STATE!=an an)
NAME Ambientelicht_TV_3
NR 954
NTFY_ORDER 50-Ambientelicht_TV_3
STATE initialized
TYPE DOIF
Readings:
2015-03-17 22:56:37 state initialized
2015-03-17 22:56:37 timer_1_c1 18.03.2015 18:51:41
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"") and ReadingValDoIf('HarmonyHUB','activity','') ne "PowerOff"
Days:
Devices:
0 HarmonyHUB
all HarmonyHUB
Do:
0 set Alle_Steckdosen_EG:FILTER=STATE!=an an
Helper:
last_timer 1
sleeptimer -1
Itimer:
Readings:
0 HarmonyHUB:activity
all HarmonyHUB:activity
Realtime:
0 18:51:41
State:
Time:
0 {sunset_abs("HORIZON=-2",0,"16:00","22:30")}
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Attributes:
group Automation
room Wohnzimmer
Ich will damit bezwecken, dass wenn ich eine activity starte (z.B. Dreambox) und die Sonne bereits untergegangen ist, dass dann geschaltet wird! Tut aber leider nix! Eigentlich sollte doch der Trigger über den HarmonyHUB ausreichen..........
Ahhhh, habe gerade nochmal getestet! Beim timer steht jetzt die Uhrzeit des Sonnenuntergangs von morgen!! Wieso denn das???
Internals:
DEF ([{sunset_abs("HORIZON=-2",0,"16:00","22:30")}] and [HarmonyHUB:activity] ne "PowerOff") (set Alle_Steckdosen_EG:FILTER=STATE!=an an)
NAME Ambientelicht_TV_3
NR 954
NTFY_ORDER 50-Ambientelicht_TV_3
STATE cmd_2
TYPE DOIF
Readings:
2015-03-17 23:05:00 cmd_event HarmonyHUB
2015-03-17 23:05:00 cmd_nr 2
2015-03-17 23:05:00 e_HarmonyHUB_activity Dreambox
2015-03-17 23:05:00 state cmd_2
2015-03-17 22:56:37 timer_1_c1 18.03.2015 18:51:41
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"") and ReadingValDoIf('HarmonyHUB','activity','') ne "PowerOff"
Days:
Devices:
0 HarmonyHUB
all HarmonyHUB
Do:
0 set Alle_Steckdosen_EG:FILTER=STATE!=an an
Helper:
last_timer 1
sleeptimer -1
Internals:
Itimer:
Readings:
0 HarmonyHUB:activity
all HarmonyHUB:activity
Realtime:
0 18:51:41
State:
Time:
0 {sunset_abs("HORIZON=-2",0,"16:00","22:30")}
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Trigger:
Attributes:
do always
group Automation
room Wohnzimmer
Zitat von: Michi240281 am 17 März 2015, 22:52:33
Leider nein! Es wird auch dabei morgens eine Pause eingelegt und nicht beim ersten Erfüllen der Bedingung geschaltet!
Dieses DOIF ist eigentlich ziemlich simpel. Wenn alle drei Bedingungen (gleichzeitig) eintreten, wird geschaltet. Danach wieder, wenn alle drei Bedingungen gleichzeitig eintreten, aber frühestens nach Ablauf von 3600 Sekunden. Aber es wird auch dann eben nur geschaltet, wenn das DOIF getriggert wird (durch ein Event, dass zu einer der drei Bedingungen passt). Ein Automatismus, der jede Stunde schaltet, solange bestimmte Bedingungen erfüllt sind, bekommst Du so nicht hin. Da musst Du Dir die Variante von Damian anschauen.
Warum das DOIF morgens nicht "pünktlich" schaltet, lässt sich schwer sagen, weil wir nicht wissen können, wie sich die drei Werte verhalten, die Du als Bedingung verwendest. Entweder sind nicht alle drei Bedingungen erfüllt oder aber sie waren in den 3600 Sekunden vorher schon mal erfüllt und die cmdpause ist noch nicht rum. Mach mal ein list in dem Moment, wo sich das DOIF nicht so verhält, wie Du erwartest.
Zitat von: Michi240281 am 17 März 2015, 22:52:33
Und dann noch ne andere Frage: Eine Idee, warum folgendes DOIF nicht schaltet?
...
Ich will damit bezwecken, dass wenn ich eine activity starte (z.B. Dreambox) und die Sonne bereits untergegangen ist, dass dann geschaltet wird! Tut aber leider nix! Eigentlich sollte doch der Trigger über den HarmonyHUB ausreichen..........
Dein DOIF prüft in dem Moment, wo der sunset_abs auftritt, ob HarmonyHub gerade auf PowerOff steht oder nicht. Das kann also nur genau einmal pro Tag passieren, und nicht jedes Mal, wenn Du eine Activity wählst. Anders wäre es, wenn Du einen Zeitraum angibst:
([{sunset_abs("HORIZON=-2",0,"16:00","22:30")}-{sunrise_abs()}] and [HarmonyHUB:activity] ne "PowerOff") (set Alle_Steckdosen_EG:FILTER=STATE!=an an)
Damit würde bei jeder Activity-Änderung zwischen Sonnenuntergang und Sonnenaufgang geprüft.
Dass der Timer auf morgen steht, ist logisch. Welches Sinn würde es machen, wenn der Timer auf einen Zeitpunkt in der Vergangenheit gesetzt wäre? Der Timer wird jeweils angepasst, wenn er getriggert wird. Also wenn heuite sunset_abs eintritt, wird der Timer auf den für morgen vorberechneten Zeitpunkt von sunset_abs gesetzt.
Zitat von: Brockmann am 18 März 2015, 08:28:13
Warum das DOIF morgens nicht "pünktlich" schaltet, lässt sich schwer sagen, weil wir nicht wissen können, wie sich die drei Werte verhalten, die Du als Bedingung verwendest. Entweder sind nicht alle drei Bedingungen erfüllt oder aber sie waren in den 3600 Sekunden vorher schon mal erfüllt und die cmdpause ist noch nicht rum.
Genau! Das DOIF schaltet abends ein letztes Mal und direkt danach sind die Bedingungen nicht mehr alle erfüllt, weil der Status_Warmwasser auf "aus" wechselt. Dann läuft der timer jedoch nicht weiter, wie ich es eigentlich dachte. Dann wäre er ja in der Nacht locker abgelaufen und morgens, wenn wieder alle 3 Bedingungen erfüllt sind, wird wieder geschaltet. Doch scheinbar wird der timer (cmdpause) eingefroren, wenn die Bedingungen nicht alle erfüllt sind. Daher kommt es dann morgens erst zu einer Pause von fast 60 Minuten! DAS ist das Problem!
Auch die von Damian gepostete Variante schaltet immer nur jede Stunde, wenn die Bedingungen erfüllt sind. Und da gibts dann dieselbe Verzögerung morgens.
Danke für den Hinweis bzgl. der Angabe eines Zeitraums bzgl. Sonnenuntergang! Ich denke, das müsste so funktionieren! :)
Zitat von: Michi240281 am 18 März 2015, 21:25:35
Doch scheinbar wird der timer (cmdpause) eingefroren, wenn die Bedingungen nicht alle erfüllt sind.
Das denke ich eher nicht. Es wäre immer noch hilfreich, wenn Du morgens direkt nach Status_Warmwasser auf "ein" ein list <DOIF> machen würdest. Dann sieht man genau, was los ist. So ist es ein bißchen Stochern im Nebel. Wann und wie werden beispielsweise Abwesend und Urlaub gesetzt?
In diesem Sinne, probier mal, ob Du hiermit ein anderes Verhalten erreichst:
attr Zirku_Pumpe_auto_neu cmdpause 3600:0
Zitat von: Brockmann am 18 März 2015, 22:59:45
Das denke ich eher nicht. Es wäre immer noch hilfreich, wenn Du morgens direkt nach Status_Warmwasser auf "ein" ein list <DOIF> machen würdest. Dann sieht man genau, was los ist. So ist es ein bißchen Stochern im Nebel. Wann und wie werden beispielsweise Abwesend und Urlaub gesetzt?
In diesem Sinne, probier mal, ob Du hiermit ein anderes Verhalten erreichst:
attr Zirku_Pumpe_auto_neu cmdpause 3600:0
Das muss aber so sein, dass die cmdPause eingefroren wird, denn sonst wäre sie ja über Nacht locker abgelaufen und morgens würde direkt wieder geschaltet.
Urlaub ist immer auf "nein" und Abwesend auch auf "nein". Es ändert sich nur morgens um 5:30 Uhr der Status_Warmwasser von "aus" nach "an". Geschaltet wird aber erst um 6:30 Uhr ca.!
Hier mal ein Auszug aus dem FileLog der Pumpe, die geschaltet wird:
2015-03-18_22:26:18 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-18_22:26:18 Zirkulationspumpe_WW Status: 1
2015-03-18_22:26:18 Zirkulationspumpe_WW level: 100
2015-03-18_22:26:18 Zirkulationspumpe_WW pct: 100
2015-03-18_22:26:18 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-18_22:26:18 Zirkulationspumpe_WW an
2015-03-18_22:26:18 Zirkulationspumpe_WW timedOn: running
2015-03-18_22:36:22 Zirkulationspumpe_WW level: 0
2015-03-18_22:36:22 Zirkulationspumpe_WW pct: 0
2015-03-18_22:36:22 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-18_22:36:22 Zirkulationspumpe_WW aus
2015-03-18_22:36:22 Zirkulationspumpe_WW timedOn: aus
2015-03-18_22:36:22 Zirkulationspumpe_WW Status: 0
2015-03-18_22:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-18_23:26:18 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-18_23:26:18 Zirkulationspumpe_WW Status: 1
2015-03-18_23:26:18 Zirkulationspumpe_WW level: 100
2015-03-18_23:26:18 Zirkulationspumpe_WW pct: 100
2015-03-18_23:26:18 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-18_23:26:18 Zirkulationspumpe_WW an
2015-03-18_23:26:18 Zirkulationspumpe_WW timedOn: running
2015-03-18_23:36:21 Zirkulationspumpe_WW level: 0
2015-03-18_23:36:21 Zirkulationspumpe_WW pct: 0
2015-03-18_23:36:21 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-18_23:36:21 Zirkulationspumpe_WW aus
2015-03-18_23:36:21 Zirkulationspumpe_WW timedOn: aus
2015-03-18_23:36:21 Zirkulationspumpe_WW Status: 0
2015-03-18_23:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_00:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_01:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_02:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_03:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_04:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_05:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_06:26:18 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-19_06:26:18 Zirkulationspumpe_WW Status: 1
2015-03-19_06:26:18 Zirkulationspumpe_WW level: 100
2015-03-19_06:26:18 Zirkulationspumpe_WW pct: 100
2015-03-19_06:26:18 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-19_06:26:18 Zirkulationspumpe_WW an
2015-03-19_06:26:18 Zirkulationspumpe_WW timedOn: running
2015-03-19_06:36:20 Zirkulationspumpe_WW level: 0
2015-03-19_06:36:20 Zirkulationspumpe_WW pct: 0
2015-03-19_06:36:20 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-19_06:36:20 Zirkulationspumpe_WW aus
2015-03-19_06:36:20 Zirkulationspumpe_WW timedOn: aus
2015-03-19_06:36:20 Zirkulationspumpe_WW Status: 0
2015-03-19_06:58:16 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-19_07:26:18 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-19_07:26:18 Zirkulationspumpe_WW Status: 1
2015-03-19_07:26:18 Zirkulationspumpe_WW level: 100
2015-03-19_07:26:18 Zirkulationspumpe_WW pct: 100
2015-03-19_07:26:18 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-19_07:26:18 Zirkulationspumpe_WW an
2015-03-19_07:26:18 Zirkulationspumpe_WW timedOn: running
2015-03-19_07:36:20 Zirkulationspumpe_WW level: 0
2015-03-19_07:36:20 Zirkulationspumpe_WW pct: 0
2015-03-19_07:36:20 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-19_07:36:20 Zirkulationspumpe_WW aus
2015-03-19_07:36:20 Zirkulationspumpe_WW timedOn: ausDas List mache ich am WE mal, denn morgens um 5:30 Uhr bin ich noch nicht wach! ;)
Danke für den Code, werde ich kommende Nacht testen!
Zitat von: Brockmann am 18 März 2015, 22:59:45
In diesem Sinne, probier mal, ob Du hiermit ein anderes Verhalten erreichst:
attr Zirku_Pumpe_auto_neu cmdpause 3600:0
Das tuts leider auch nicht! :(
Die CmdPause wird eingefroren, bis die Bedingungen wieder erfüllt sind!
Guten Morgen zusammen,
weiter gehts mit der Analyse.
Hier 2 lists! Einmal um 9:28 (2 Minuten bevor wieder alle Bedingungen wahr sind) und dann um 9:32 Uhr (2 Minuten nachdem alle Bedingungen wahr geworden sind:
Internals:
DEF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600)
NAME Zirku_Pumpe_auto_neu
NR 949
NTFY_ORDER 50-Zirku_Pumpe_auto_neu
STATE cmd_2
TYPE DOIF
Readings:
2015-03-22 09:28:09 cmd_event Abwesend
2015-03-22 09:28:09 cmd_nr 2
2015-03-22 09:28:09 e_Abwesend_state nein
2015-03-21 23:45:00 e_Status_Warmwasser_state aus
2015-03-19 23:33:43 e_Urlaub_state nein
2015-03-22 09:28:09 state cmd_2
Condition:
0 ReadingValDoIf('Abwesend','state','') eq "nein" and ReadingValDoIf('Urlaub','state','') eq "nein" and ReadingValDoIf('Status_Warmwasser','state','') eq "an"
Devices:
0 Abwesend Urlaub Status_Warmwasser
all Abwesend Urlaub Status_Warmwasser
Do:
0 set Zirkulationspumpe_WW on-for-timer 600
Helper:
last_timer 0
sleeptimer -1
Internals:
Itimer:
Readings:
0 Abwesend:state Urlaub:state Status_Warmwasser:state
all Abwesend:state Urlaub:state Status_Warmwasser:state
State:
Timerfunc:
Trigger:
Attributes:
cmdpause 3600:0
do always
room Garage,Haus
Internals:
DEF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600)
NAME Zirku_Pumpe_auto_neu
NR 949
NTFY_ORDER 50-Zirku_Pumpe_auto_neu
STATE cmd_2
TYPE DOIF
Readings:
2015-03-22 09:28:09 cmd_event Abwesend
2015-03-22 09:28:09 cmd_nr 2
2015-03-22 09:28:09 e_Abwesend_state nein
2015-03-22 09:30:00 e_Status_Warmwasser_state an
2015-03-19 23:33:43 e_Urlaub_state nein
2015-03-22 09:28:09 state cmd_2
Condition:
0 ReadingValDoIf('Abwesend','state','') eq "nein" and ReadingValDoIf('Urlaub','state','') eq "nein" and ReadingValDoIf('Status_Warmwasser','state','') eq "an"
Devices:
0 Abwesend Urlaub Status_Warmwasser
all Abwesend Urlaub Status_Warmwasser
Do:
0 set Zirkulationspumpe_WW on-for-timer 600
Helper:
last_timer 0
sleeptimer -1
Internals:
Itimer:
Readings:
0 Abwesend:state Urlaub:state Status_Warmwasser:state
all Abwesend:state Urlaub:state Status_Warmwasser:state
State:
Timerfunc:
Trigger:
Attributes:
cmdpause 3600:0
do always
room Garage,Haus
Geschaltet wurde (wieder, wie erwartet) nicht! Er steht sturr auf "cmd_2", obwohl die Bedingungen ja erfüllt sind. Es kann also nur an der cmdPause liegen, oder?
Hmm, da bin ich auch überfragt. Anscheinend kann man im list auch nicht ablesen, ob eine cmdpause aktiv ist oder nicht (ich jedenfalls nicht).
Da kann wohl nur Damian etwas zu sagen.
Ja offensichtlich kann man das echt nicht sehn!
Hier ein list von gerade:
Internals:
DEF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600)
NAME Zirku_Pumpe_auto_neu
NR 949
NTFY_ORDER 50-Zirku_Pumpe_auto_neu
STATE cmd_1
TYPE DOIF
Readings:
2015-03-22 10:28:09 cmd_event Abwesend
2015-03-22 10:28:09 cmd_nr 1
2015-03-22 10:58:09 e_Abwesend_state nein
2015-03-22 09:30:00 e_Status_Warmwasser_state an
2015-03-19 23:33:43 e_Urlaub_state nein
2015-03-22 10:28:09 state cmd_1
Condition:
0 ReadingValDoIf('Abwesend','state','') eq "nein" and ReadingValDoIf('Urlaub','state','') eq "nein" and ReadingValDoIf('Status_Warmwasser','state','') eq "an"
Devices:
0 Abwesend Urlaub Status_Warmwasser
all Abwesend Urlaub Status_Warmwasser
Do:
0 set Zirkulationspumpe_WW on-for-timer 600
Helper:
last_timer 0
sleeptimer -1
Internals:
Itimer:
Readings:
0 Abwesend:state Urlaub:state Status_Warmwasser:state
all Abwesend:state Urlaub:state Status_Warmwasser:state
State:
Timerfunc:
Trigger:
Attributes:
cmdpause 3600:0
do always
room Garage,Haus
Nun steht er auf "cmd_1", so wie es sein soll! Offensichtlich ist intern da wirklich noch die cmdPause aktiv!
@Damian:Kannst du helfen?
Zitat von: Michi240281 am 22 März 2015, 11:26:38
Ja offensichtlich kann man das echt nicht sehn!
Hier ein list von gerade:
Internals:
DEF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600)
NAME Zirku_Pumpe_auto_neu
NR 949
NTFY_ORDER 50-Zirku_Pumpe_auto_neu
STATE cmd_1
TYPE DOIF
Readings:
2015-03-22 10:28:09 cmd_event Abwesend
2015-03-22 10:28:09 cmd_nr 1
2015-03-22 10:58:09 e_Abwesend_state nein
2015-03-22 09:30:00 e_Status_Warmwasser_state an
2015-03-19 23:33:43 e_Urlaub_state nein
2015-03-22 10:28:09 state cmd_1
Condition:
0 ReadingValDoIf('Abwesend','state','') eq "nein" and ReadingValDoIf('Urlaub','state','') eq "nein" and ReadingValDoIf('Status_Warmwasser','state','') eq "an"
Devices:
0 Abwesend Urlaub Status_Warmwasser
all Abwesend Urlaub Status_Warmwasser
Do:
0 set Zirkulationspumpe_WW on-for-timer 600
Helper:
last_timer 0
sleeptimer -1
Internals:
Itimer:
Readings:
0 Abwesend:state Urlaub:state Status_Warmwasser:state
all Abwesend:state Urlaub:state Status_Warmwasser:state
State:
Timerfunc:
Trigger:
Attributes:
cmdpause 3600:0
do always
room Garage,Haus
Nun steht er auf "cmd_1", so wie es sein soll! Offensichtlich ist intern da wirklich noch die cmdPause aktiv!
@Damian:Kannst du helfen?
cmdpause ist im Normalfall nur bei zyklisch sendenden Sensoren sinnvoll, weil in der Pause Trigger einfach ignoriert werden. Für deinen Anwendungsfall also eher ungeeignet.
Gruß
Damian
Gibts denn eine Alternative?
Zitat von: Damian am 22 März 2015, 12:38:13
cmdpause ist im Normalfall nur bei zyklisch sendenden Sensoren sinnvoll, weil in der Pause Trigger einfach ignoriert werden. Für deinen Anwendungsfall also eher ungeeignet.
Die Frage ist, warum überhaupt eine Pause auftritt?
Um 09:28:09 ist cmd_2 eingetreten. Das Attribut
cmdpause 3600:0 sollte dafür sorgen, dass in diesem Fall KEINE Pause auftritt, oder?
"Cmd_2" tritt ja immer auf, wenn eine der Bedingungen nicht erfüllt ist.
Um 9:30 Uhr wechselte der Status_Warmwasser auf "an", damit wurden dann alle Bedingungen wahr. Der state hätte nun auf "Cmd_1" wechseln müssen. Ist er aber nicht, weil die CmdPause im Hintergrund noch aktiv war vom Abend zuvor, als das letzte Mal "Cmd_1" eingetreten ist. Also ich habe das jetzt nachvollzogen. Abends um 23:28 Uhr waren alle Bedingungen erfüllt. State wechselte auf "Cmd_1". Um 23:30 Uhr ging dann Status_Warmwasser auf "aus". Nun läuft jedoch im Hintergrund die CmdPause von 60 Minuten leider nicht weiter und damit komplett runter, sondern die verbleibenden 58 Minuten, die noch "fehlen", werden morgens, wenn wieder alle Bedingungen wahr sind, noch an das "Cmd_1" drangehängt! Also genau wie ich eingangs vermutete: Die CmdPause wird eingefroren, wenn Cmd_1 nicht anliegt! Das ist die Ursache!
Nun die Frage an Damian: Was kann ich da machen? Eigentlich hatte ich erwartet, dass die timer im Hintergrund einfach ablaufen, aber leider werden sie eingefroren! Kannst du da was am Model ändern oder ein andere Attribut einfügen?
Zitat von: Michi240281 am 22 März 2015, 14:45:23
"Cmd_2" tritt ja immer auf, wenn eine der Bedingungen nicht erfüllt ist.
Um 9:30 Uhr wechselte der Status_Warmwasser auf "an", damit wurden dann alle Bedingungen wahr. Der state hätte nun auf "Cmd_1" wechseln müssen. Ist er aber nicht, weil die CmdPause im Hintergrund noch aktiv war vom Abend zuvor, als das letzte Mal "Cmd_1" eingetreten ist. Also ich habe das jetzt nachvollzogen. Abends um 23:28 Uhr waren alle Bedingungen erfüllt. State wechselte auf "Cmd_1". Um 23:30 Uhr ging dann Status_Warmwasser auf "aus". Nun läuft jedoch im Hintergrund die CmdPause von 60 Minuten leider nicht weiter und damit komplett runter, sondern die verbleibenden 58 Minuten, die noch "fehlen", werden morgens, wenn wieder alle Bedingungen wahr sind, noch an das "Cmd_1" drangehängt! Also genau wie ich eingangs vermutete: Die CmdPause wird eingefroren, wenn Cmd_1 nicht anliegt! Das ist die Ursache!
Nun die Frage an Damian: Was kann ich da machen? Eigentlich hatte ich erwartet, dass die timer im Hintergrund einfach ablaufen, aber leider werden sie eingefroren! Kannst du da was am Model ändern oder ein andere Attribut einfügen?
Nochmal zum Verständnis: Im Gegensatz zu einem wait ist cmdpause
kein Timer. Beim Eintreffen eines Triggers wird die jeweilige Bedingung überprüft. Geschaltet wird allerdings nur, wenn der Zeitstempel des Status von DOIF (also die letzte Änderung) mehr als die Zeitspanne, die bei cmdpause angegeben wurde, zurückliegt - mehr steckt da nicht dahinter. Deswegen ist es für deinen Anwendungsfall ungeeignet, weil deine Trigger keine zyklische Wiederholung haben und daher verloren gehen können, bei Temperatursensoren dagegen, die zyklisch senden, ist das egal.
Gruß
Damian
Hi Damian,
ok, verstehe! Nur hast du einen Alternativvorschlag? Mit dem Wait Attribut hatte ich genau das gleiche Resultat! :'(
Zitat von: Michi240281 am 22 März 2015, 22:33:52
Hi Damian,
ok, verstehe! Nur hast du einen Alternativvorschlag? Mit dem Wait Attribut hatte ich genau das gleiche Resultat! :'(
ok, na dann so:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 300, sleep 3600;trigger Abwesend)
attr zirku_Pumpe_auto do alwaysGruß
Damian
Ok vielen Dank, werde ich testen!
Was bewirkt denn das "trigger Abwesend"? Wäre nämlich ungünstig, wenn er dann nur noch auf "Abwesend" triggered!
Hallo,
Vorschlag: bei ähnlichen Fällen habe ich es so gelöst:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "ja" or [Urlaub:state] eq "ja") ()
DOELSIF ([Status_Warmwasserpumpe:state:?an] or ([+01:00] and [Status_Warmwasser:state] eq "an"))
(set Zirkulationspumpe_WW on-for-timer 300)
attr Zirku_Pumpe_auto do always
Bei Abwesenheit oder Urlaub wird kein Befehl ausgeführt (leere Klammer), sonst beim Einschalten der "Status_Warmwasserpumpe" wird der Befehl sofort ausgeführt und dann im Stundentakt.
Diese Lösung hat jedoch einen Schönheitsfehler:
Die erste Zeitspanne kann kleiner als eine Stunde sein, danach jedoch regelmässig im Stundentakt.
Bei diesem Fall ist es vermutlich nicht so schlimm, wenn die Pumpe für 5 Min früher eingeschaltet wird.
Gruss
flurin
Zitat von: Damian am 22 März 2015, 22:56:18
ok, na dann so:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 300, sleep 3600;trigger Abwesend)
attr zirku_Pumpe_auto do always
Moin,
also grundsätzlich hat das heute Morgen funktioniert. Allerdings war die Pause viel zu kurz. Beim ersten Schalten ca. 3,5 Minuten, beim 2. Mal 20 Minuten und dann war die nächste volle Stunde da und es ging wieder mit 3,5 Minuten weiter. Hier mal ein Auszug aus dem log:
2015-03-24_04:14:07 Zirkulationspumpe_WW Status: 0 << addLog
2015-03-24_05:00:00 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_05:00:00 Zirkulationspumpe_WW Status: 1
2015-03-24_05:00:00 Zirkulationspumpe_WW level: 100
2015-03-24_05:00:00 Zirkulationspumpe_WW pct: 100
2015-03-24_05:00:00 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_05:00:00 Zirkulationspumpe_WW an
2015-03-24_05:00:00 Zirkulationspumpe_WW timedOn: running
2015-03-24_05:10:04 Zirkulationspumpe_WW level: 0
2015-03-24_05:10:04 Zirkulationspumpe_WW pct: 0
2015-03-24_05:10:04 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_05:10:04 Zirkulationspumpe_WW aus
2015-03-24_05:10:04 Zirkulationspumpe_WW timedOn: aus
2015-03-24_05:10:04 Zirkulationspumpe_WW Status: 0
2015-03-24_05:13:55 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_05:13:55 Zirkulationspumpe_WW Status: 1
2015-03-24_05:13:55 Zirkulationspumpe_WW level: 100
2015-03-24_05:13:55 Zirkulationspumpe_WW pct: 100
2015-03-24_05:13:55 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_05:13:55 Zirkulationspumpe_WW an
2015-03-24_05:13:55 Zirkulationspumpe_WW timedOn: running
2015-03-24_05:14:07 Zirkulationspumpe_WW Status: 1 << addLog
2015-03-24_05:23:59 Zirkulationspumpe_WW level: 0
2015-03-24_05:23:59 Zirkulationspumpe_WW pct: 0
2015-03-24_05:23:59 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_05:23:59 Zirkulationspumpe_WW aus
2015-03-24_05:23:59 Zirkulationspumpe_WW timedOn: aus
2015-03-24_05:23:59 Zirkulationspumpe_WW Status: 0
2015-03-24_05:43:55 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_05:43:55 Zirkulationspumpe_WW Status: 1
2015-03-24_05:43:55 Zirkulationspumpe_WW level: 100
2015-03-24_05:43:55 Zirkulationspumpe_WW pct: 100
2015-03-24_05:43:55 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_05:43:55 Zirkulationspumpe_WW an
2015-03-24_05:43:55 Zirkulationspumpe_WW timedOn: running
2015-03-24_05:53:58 Zirkulationspumpe_WW level: 0
2015-03-24_05:53:58 Zirkulationspumpe_WW pct: 0
2015-03-24_05:53:58 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_05:53:58 Zirkulationspumpe_WW aus
2015-03-24_05:53:58 Zirkulationspumpe_WW timedOn: aus
2015-03-24_05:53:58 Zirkulationspumpe_WW Status: 0
2015-03-24_06:00:00 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_06:00:00 Zirkulationspumpe_WW Status: 1
2015-03-24_06:00:00 Zirkulationspumpe_WW level: 100
2015-03-24_06:00:00 Zirkulationspumpe_WW pct: 100
2015-03-24_06:00:00 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_06:00:00 Zirkulationspumpe_WW an
2015-03-24_06:00:00 Zirkulationspumpe_WW timedOn: running
2015-03-24_06:10:04 Zirkulationspumpe_WW level: 0
2015-03-24_06:10:04 Zirkulationspumpe_WW pct: 0
2015-03-24_06:10:04 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_06:10:04 Zirkulationspumpe_WW aus
2015-03-24_06:10:04 Zirkulationspumpe_WW timedOn: aus
2015-03-24_06:10:04 Zirkulationspumpe_WW Status: 0
2015-03-24_06:13:55 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_06:13:55 Zirkulationspumpe_WW Status: 1
2015-03-24_06:13:56 Zirkulationspumpe_WW level: 100
2015-03-24_06:13:56 Zirkulationspumpe_WW pct: 100
2015-03-24_06:13:56 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_06:13:56 Zirkulationspumpe_WW an
2015-03-24_06:13:56 Zirkulationspumpe_WW timedOn: running
2015-03-24_06:14:07 Zirkulationspumpe_WW Status: 1 << addLog
2015-03-24_06:23:59 Zirkulationspumpe_WW level: 0
2015-03-24_06:23:59 Zirkulationspumpe_WW pct: 0
2015-03-24_06:23:59 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_06:23:59 Zirkulationspumpe_WW aus
2015-03-24_06:23:59 Zirkulationspumpe_WW timedOn: aus
2015-03-24_06:23:59 Zirkulationspumpe_WW Status: 0
2015-03-24_06:43:55 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_06:43:55 Zirkulationspumpe_WW Status: 1
2015-03-24_06:43:55 Zirkulationspumpe_WW level: 100
2015-03-24_06:43:55 Zirkulationspumpe_WW pct: 100
2015-03-24_06:43:55 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_06:43:55 Zirkulationspumpe_WW an
2015-03-24_06:43:55 Zirkulationspumpe_WW timedOn: running
2015-03-24_06:53:59 Zirkulationspumpe_WW level: 0
2015-03-24_06:53:59 Zirkulationspumpe_WW pct: 0
2015-03-24_06:53:59 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_06:53:59 Zirkulationspumpe_WW aus
2015-03-24_06:53:59 Zirkulationspumpe_WW timedOn: aus
2015-03-24_06:53:59 Zirkulationspumpe_WW Status: 0
2015-03-24_07:00:00 Zirkulationspumpe_WW set_on-for-timer 600
2015-03-24_07:00:00 Zirkulationspumpe_WW Status: 1
2015-03-24_07:00:00 Zirkulationspumpe_WW level: 100
2015-03-24_07:00:00 Zirkulationspumpe_WW pct: 100
2015-03-24_07:00:00 Zirkulationspumpe_WW deviceMsg: an (to HMLAN1)
2015-03-24_07:00:00 Zirkulationspumpe_WW an
2015-03-24_07:00:00 Zirkulationspumpe_WW timedOn: running
2015-03-24_07:10:02 Zirkulationspumpe_WW level: 0
2015-03-24_07:10:02 Zirkulationspumpe_WW pct: 0
2015-03-24_07:10:02 Zirkulationspumpe_WW deviceMsg: aus (to broadcast)
2015-03-24_07:10:02 Zirkulationspumpe_WW aus
2015-03-24_07:10:02 Zirkulationspumpe_WW timedOn: aus
2015-03-24_07:10:02 Zirkulationspumpe_WW Status: 0Irgendwas scheint mit dem sleep Kommando noch nicht zu stimmen! In der commandref steht, das seien Millisekunden?!?
Zitat von: flurin am 23 März 2015, 22:28:28
Hallo,
Vorschlag: bei ähnlichen Fällen habe ich es so gelöst:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "ja" or [Urlaub:state] eq "ja") ()
DOELSIF ([Status_Warmwasserpumpe:state:?an] or ([+01:00] and [Status_Warmwasser:state] eq "an"))
(set Zirkulationspumpe_WW on-for-timer 300)
attr Zirku_Pumpe_auto do always
Bei Abwesenheit oder Urlaub wird kein Befehl ausgeführt (leere Klammer), sonst beim Einschalten der "Status_Warmwasserpumpe" wird der Befehl sofort ausgeführt und dann im Stundentakt.
Diese Lösung hat jedoch einen Schönheitsfehler:
Die erste Zeitspanne kann kleiner als eine Stunde sein, danach jedoch regelmässig im Stundentakt.
Bei diesem Fall ist es vermutlich nicht so schlimm, wenn die Pumpe für 5 Min früher eingeschaltet wird.
Gruss
flurin
Danke für den Lösungsvorschlag! Habe dazu 2 Fragen:
Was bewirkt denn dann die erste Bedingung? Garnichts, oder? Dann kann man sie doch auch weglassen! Und die 2. Bedingung fragt ja dann nur noch den Status_Warmwasser ab! Aber es soll ja auch nicht geschaltet werden, wenn wir abwesend oder im Urlaub sind?!?
Zitat von: Michi240281 am 24 März 2015, 08:17:09
also grundsätzlich hat das heute Morgen funktioniert. Allerdings war die Pause viel zu kurz. Beim ersten Schalten ca. 3,5 Minuten, beim 2. Mal 20 Minuten und dann war die nächste volle Stunde da und es ging wieder mit 3,5 Minuten weiter.
Der Vorschlag von Damian geht davon aus, dass
Abwesend zwischendurch nicht anderweitig getriggert wird. Das scheint mir bei Dir aber der Fall zu sein.
Das Log legt nahe, dass alle 30 Minuten, nämlich jeweils um **:13:55 und **:43:55 der Abwesend-Status gesetzt wird.
Dadurch wird jedes Mal das DOIF getriggert und schaltet die Pumpe ein.
Zitat von: Michi240281 am 24 März 2015, 08:17:09
Was bewirkt denn dann die erste Bedingung? Garnichts, oder? Dann kann man sie doch auch weglassen! Und die 2. Bedingung fragt ja dann nur noch den Status_Warmwasser ab! Aber es soll ja auch nicht geschaltet werden, wenn wir abwesend oder im Urlaub sind?!?
Nicht ganz, die erste Bedingung (wenn wahr) führt einen leeren Befehl aus und bewirkt, dass das DOELSIF nicht ausgeführt wird.
Somit wird indirekt die Bedingung erfüllt, bei Abwesenheit oder Urlaub die Pumpe nicht zu schalten. Beachte die Abfrage auf "ja" sowie "or". Das ist wie "if, elsif und else" in Perl. Siehe auch die DOIF Dokumentation:
Zitat
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
Edit: es geht doch nicht! ... work-in-progress
Zitat von: flurin am 24 März 2015, 09:05:45
Nicht ganz, die erste Bedingung (wenn wahr) führt einen leeren Befehl aus und bewirkt, dass das DOELSIF nicht ausgeführt wird.
Somit wird indirekt die Bedingung erfüllt, bei Abwesenheit oder Urlaub die Pumpe nicht zu schalten. Beachte die Abfrage auf "ja" sowie "or". Das ist wie "if, elsif und else" in Perl. Siehe auch die DOIF Dokumentation:
Wenn Du bei Deinem Zitat der Commandref den anschließenden Satz nicht abgeschnitten hättest, würdest Du das Problem erkennen:
Zitat von: CommanrefHinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch das Device beinhalten.
Wenn morgens um 5:00 Uhr (oder wann auch immer) Status_Warmwasserpumpe auf "an" geht, würde bei Deinem DOIF gar nicht geprüft werden, wie Abwesenheit und Urlaub gerade belegt sind, weil die erste Bedingung gar nicht getriggert wird. Man müsste zumindest [Status_Warmwasserpumpe] schon noch mit in die Bedingung einfügen, damit diese auch getriggert wird.
Zitat von: Brockmann am 24 März 2015, 11:08:56
Wenn Du bei Deinem Zitat der Commandref den anschließenden Satz nicht abgeschnitten hättest, würdest Du das Problem erkennen:
Wenn morgens um 5:00 Uhr (oder wann auch immer) Status_Warmwasserpumpe auf "an" geht, würde bei Deinem DOIF gar nicht geprüft werden, wie Abwesenheit und Urlaub gerade belegt sind, weil die erste Bedingung gar nicht getriggert wird. Man müsste zumindest [Status_Warmwasserpumpe] schon noch mit in die Bedingung einfügen, damit diese auch getriggert wird.
Richtig! ich arbeite daran.
Zitat von: Brockmann am 24 März 2015, 08:53:10
Der Vorschlag von Damian geht davon aus, dass Abwesend zwischendurch nicht anderweitig getriggert wird. Das scheint mir bei Dir aber der Fall zu sein.
Das Log legt nahe, dass alle 30 Minuten, nämlich jeweils um **:13:55 und **:43:55 der Abwesend-Status gesetzt wird.
Dadurch wird jedes Mal das DOIF getriggert und schaltet die Pumpe ein.
Dann muss man es entkoppeln:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
attr zirku_Pumpe_auto state on|offund
define di_Zirku_Pumpe_on DOIF ([Zirku_Pumpe_auto] eq "on") (set Zirkulationspumpe_WW on-for-timer 300, sleep 3600;trigger di_Zirku_Pumpe_on)
attr di_Zirku_Pumpe_on do alwaysGruß
Damian
... work-in-progress > folgende Variante kann ich noch bieten:
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and
([Status_Warmwasserpumpe:state:?an] or [+01:00] and [Status_Warmwasser:state] eq "an"))
(set Zirkulationspumpe_WW on-for-timer 300)
attr Zirku_Pumpe_auto do always
Das DOIF wurde tatsächlich über Abwesend getriggert, aber unabsichtlich. Die Ursache dafür war addlog! Ich habe das jetzt mal folgendermaßen abgeändert:
define Zirku_Pumpe_auto_neu DOIF ([?Abwesend:state] eq "nein" and [?Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600, sleep 3600;trigger Abwesend)
Dann sollte nur noch der Status_Warmwasser zur Triggerung führen. Bin mal gespannt, ob das dann so funktioniert.
@Damian: Was bewirkt das "trigger Abwesend"?
@Flurin: Danke für deine Mühen, leider funktioniert dein Code nicht, er wird erst garnicht akzeptiert! Da scheint die Syntax nicht zu stimmen!
Zitat von: Michi240281 am 24 März 2015, 22:34:09
@Flurin: Danke für deine Mühen, leider funktioniert dein Code nicht, er wird erst garnicht akzeptiert! Da scheint die Syntax nicht zu stimmen!
OK, vermutlich liegt es am [Status_Warmwasserpumpe:state:?an], es müsste [Status_Warmwasserpumpe:?an] heissen.
Falls Du diese Lösung weiterverfolgen möchtest, kann ich immer noch meine Testversion posten.
Hier eine Testversion, die ansatzweise zur Lösung des Problems helfen könnte:
Es geht darum, einen Befehl nach einem Event sofort auszuführen und in einem Intervall zu wiederholen:
Dummy-Definition für den Test:
define du_event dummy
attr du_event setList on off
define du_interval dummy
set du_interval 00:00:05
DOIF:
define di_pulse DOIF ([du_event:?on] or [+[du_interval]] and [du_event] eq "on")
({Log(3,"command")}, set du_interval 00:00:05)
attr di_pulse do always
Einfach ausprobieren und nach Bedarf ausbauen/anpassen.
Gruss
flurin
Zitat von: Michi240281 am 24 März 2015, 22:34:09
define Zirku_Pumpe_auto_neu DOIF ([?Abwesend:state] eq "nein" and [?Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600, sleep 3600;trigger Abwesend)
Dann sollte nur noch der Status_Warmwasser zur Triggerung führen. Bin mal gespannt, ob das dann so funktioniert.
Nee, das wird so nichts werden. Das
trigger Abwesend bewirkt, dass das DOIF 3600 Sekunden nach Einschalten der Pumpe erneut getriggert wird. Sind die Bedingungen dann immer noch alle erfüllt, schaltet die Pumpe erneut für 5 Minuten ein. Wenn Du die Bedingung
Abwesend auf non-triggering setzt (mit dem Fragezeichen), dann klappt das nicht mehr.
Du könntest aber statt
trigger Abwesend einfach
trigger Status_Warmwasser verwenden, das hat denselben Effekt. Dann sollte es rundlaufen, sofern Status_Warmwasser nicht anderweitig getriggert wird.
ABER Seiteneffekt: Wenn Du nach Hause kommst (also Abwesend auf "nein" geht), springt die Pumpe nicht direkt an, sondern erst wieder, wenn Sie das nächste Mal durch Status_Warmwasser getriggert wird. Ist also vermutlich auch noch nicht ganz das, was Du willst.
Du solltest besser versuchen, dieses zyklische Triggern von Abwesend zu vermeiden. Das ist nämlich das, was Dir von Anfang an immer wieder Probleme eingebrockt hat.
Zitat von: Michi240281 am 24 März 2015, 22:34:09
@Damian: Was bewirkt das "trigger Abwesend"?
Mit trigger Abwesend wird ein Event für Abwesend erzeugt. Damit wird das DOIF-Modul getriggert, welches Abwesend abfragt - allerdings ohne Fragezeichenangabe.
Die Idee von Flurin mit indirekter Zeitsteuerung ist nicht schlecht. Damit kommt man ohne Sleep aus, kombiniert mit meinem letzten Vorschlag würde es so aussehen:
1. Dieses Modul soll nur den Zustand on bzw. off haben, abhängig davon ob die Pumpe zirkulieren soll oder nicht. Da kein do always gesetzt wird, ist hier egal wie oft Abwesend triggert.
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
attr zirku_Pumpe_auto state on|off2. Jetzt wird ein Dummy für die zeitliche Wiederholung definiert (hier eine Stunde)
define Intervall dummy
set Intervall 01:00 3. Und nun wird das Haupt-DOIF für das Schalten der Pumpe definiert:
define di_Zirku_Pumpe_on DOIF ([zirku_Pumpe_auto] eq "on" or ([+[Intervall]] and [?Zirku_Pumpe_auto] eq "on") ) (set Zirkulationspumpe_WW on-for-timer 300, trigger Intervall)
attr di_Zirku_Pumpe_on do alwaysDamit läuft die Pumpe sofort los, wenn der Status von Zirku_Pumpe_auto auf on geht, oder wenn das Intervall von einer Stunde abläuft und der Zirkulationsmodus auf on steht. Mit trigger Intervall wird das Setzen der nächsten Schaltzeit nach einer Stunde über die Intervallzeit provoziert.
Gruß
Damian
@Damian
Genau so! ich habe nur du_event wie folgt gesetzt:
define di_events DOIF ([du_absent] eq "off" and [du_holiday] eq "off" and [du_hotwater] eq "on")
(set du_event on) DOELSE (set du_event off)
aber das ist ein Detail.
Gruss
flurin
Zitat von: Damian am 25 März 2015, 13:34:17
Mit trigger Abwesend wird ein Event für Abwesend erzeugt. Damit wird das DOIF-Modul getriggert, welches Abwesend abfragt - allerdings ohne Fragezeichenangabe.
Die Idee von Flurin mit indirekter Zeitsteuerung ist nicht schlecht. Damit kommt man ohne Sleep aus, kombiniert mit meinem letzten Vorschlag würde es so aussehen:
1. Dieses Modul soll nur den Zustand on bzw. off haben, abhängig davon ob die Pumpe zirkulieren soll oder nicht. Da kein do always gesetzt wird, ist hier egal wie oft Abwesend triggert.
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
attr zirku_Pumpe_auto state on|off
2. Jetzt wird ein Dummy für die zeitliche Wiederholung definiert (hier eine Stunde)
define Intervall dummy
set Intervall 01:00
3. Und nun wird das Haupt-DOIF für das Schalten der Pumpe definiert:
define di_Zirku_Pumpe_on DOIF ([zirku_Pumpe_auto] eq "on" or ([+[Intervall]] and [?Zirku_Pumpe_auto] eq "on") ) (set Zirkulationspumpe_WW on-for-timer 300, trigger Intervall)
attr di_Zirku_Pumpe_on do always
Damit läuft die Pumpe sofort los, wenn der Status von Zirku_Pumpe_auto auf on geht, oder wenn das Intervall von einer Stunde abläuft und der Zirkulationsmodus auf on steht. Mit trigger Intervall wird das Setzen der nächsten Schaltzeit nach einer Stunde über die Intervallzeit provoziert.
Gruß
Damian
Hallo Damian,
vielen Dank für deine Ideen und den Code! Werde ich heute Abend ausprobieren. Ich habe es jetzt erstmal anders gelöst und es scheint zu funktionieren, und zwar habe ich folgenden Code verwendet:
efine Zirku_Pumpe_auto_neu DOIF ([?Abwesend:state] eq "nein" and [?Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
(set Zirkulationspumpe_WW on-for-timer 600, sleep 3600;trigger Abwesend)Das trigger Abwesend kann ich dann auch weglassen denke ich mal. Und dann habe ich dem Status_Warmwasser ein Addlog hinzugefügt, welches jede Stunde ein Event anlegt. Dadurch wird die Pumpe dann jede Stunde eingeschaltet. Kleiner Schönheitsfehler dabei, dass sie im schlimmsten Fall erst 1 Stunde nachdem Abwesend auf nein geht, anspringt, wäre jedoch zu verschmerzen.
Aber ich teste heute Abend/kommende Nacht auf jeden Fall deinen Code!
@Flurin: Besten Dank auch an dich für die Ideen!
Zitat von: Damian am 25 März 2015, 13:34:17
Mit trigger Abwesend wird ein Event für Abwesend erzeugt. Damit wird das DOIF-Modul getriggert, welches Abwesend abfragt - allerdings ohne Fragezeichenangabe.
Die Idee von Flurin mit indirekter Zeitsteuerung ist nicht schlecht. Damit kommt man ohne Sleep aus, kombiniert mit meinem letzten Vorschlag würde es so aussehen:
1. Dieses Modul soll nur den Zustand on bzw. off haben, abhängig davon ob die Pumpe zirkulieren soll oder nicht. Da kein do always gesetzt wird, ist hier egal wie oft Abwesend triggert.
define Zirku_Pumpe_auto DOIF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
attr zirku_Pumpe_auto state on|off
2. Jetzt wird ein Dummy für die zeitliche Wiederholung definiert (hier eine Stunde)
define Intervall dummy
set Intervall 01:00
3. Und nun wird das Haupt-DOIF für das Schalten der Pumpe definiert:
define di_Zirku_Pumpe_on DOIF ([zirku_Pumpe_auto] eq "on" or ([+[Intervall]] and [?Zirku_Pumpe_auto] eq "on") ) (set Zirkulationspumpe_WW on-for-timer 300, trigger Intervall)
attr di_Zirku_Pumpe_on do always
Damit läuft die Pumpe sofort los, wenn der Status von Zirku_Pumpe_auto auf on geht, oder wenn das Intervall von einer Stunde abläuft und der Zirkulationsmodus auf on steht. Mit trigger Intervall wird das Setzen der nächsten Schaltzeit nach einer Stunde über die Intervallzeit provoziert.
Gruß
Damian
Hallo Damian,
habe den ganzen Code bei mir eingebaut! Leider tuts das nicht! Hier ein list von allen 3 Einträgen:
Internals:
CFGFN
DEF ([Abwesend:state] eq "nein" and [Urlaub:state] eq "nein" and [Status_Warmwasser:state] eq "an")
NAME Zirku_Pumpe_auto
NR 6489
NTFY_ORDER 50-Zirku_Pumpe_auto
STATE on|off
TYPE DOIF
Readings:
2015-03-26 20:15:06 cmd_event Status_Warmwasser
2015-03-26 20:15:06 cmd_nr 1
2015-03-26 20:51:41 e_Abwesend_state nein
2015-03-26 21:30:00 e_Status_Warmwasser_state an
2015-03-26 20:12:34 e_Urlaub_state nein
2015-03-26 20:15:06 state on|off
Condition:
0 ReadingValDoIf('Abwesend','state','') eq "nein" and ReadingValDoIf('Urlaub','state','') eq "nein" and ReadingValDoIf('Status_Warmwasser','state','') eq "an"
Devices:
0 Abwesend Urlaub Status_Warmwasser
all Abwesend Urlaub Status_Warmwasser
Do:
0
Helper:
last_timer 0
sleeptimer -1
Bm:
Doif_attr:
cnt 4
dmx 0
max 74
tot 74
mAr:
set
Zirku_Pumpe_auto
disable
0
Doif_notify:
cnt 904
dmx 0
max 76
tot 368
mAr:
HASH(0x1293add0)
HASH(0xf544210)
Internals:
Itimer:
Readings:
0 Abwesend:state Urlaub:state Status_Warmwasser:state
all Abwesend:state Urlaub:state Status_Warmwasser:state
State:
Timerfunc:
Trigger:
Attributes:
disable 0
group Warmwasser
room Garage
state on|off Internals:
CFGFN
NAME Intervall
NR 6495
STATE 01:00
TYPE dummy
Readings:
2015-03-26 20:01:11 state 01:00
Helper:
Bm:
Dummy_define:
cnt 1
dmx 0
mAr
max 0
tot 0
Dummy_set:
cnt 21
dmx 0
max 21
tot 21
mAr:
HASH(0x127f8388)
Intervall
01:00
Attributes:
group Warmwasser
room GarageInternals:
CFGFN
DEF ([Zirku_Pumpe_auto] eq "on" or ([+[Intervall]] and [?Zirku_Pumpe_auto] eq "on") ) (set Zirkulationspumpe_WW on-for-timer 600, trigger Intervall)
NAME di_Zirku_Pumpe_on
NR 6509
NTFY_ORDER 50-di_Zirku_Pumpe_on
STATE cmd_2
TYPE DOIF
Readings:
2015-03-26 21:06:53 cmd_event timer_1
2015-03-26 21:06:53 cmd_nr 2
2015-03-26 20:15:06 e_Zirku_Pumpe_auto_STATE on|off
2015-03-26 21:06:53 state cmd_2
2015-03-26 21:06:53 timer_1_c1 26.03.2015 22:06:53
Condition:
0 InternalDoIf('Zirku_Pumpe_auto','STATE','') eq "on" or (DOIF_time_once($hash->{timer}{0},$wday,"") and InternalDoIf('Zirku_Pumpe_auto','STATE','') eq "on")
Days:
Devices:
0 Zirku_Pumpe_auto
all Zirku_Pumpe_auto
Do:
0 set Zirkulationspumpe_WW on-for-timer 600, trigger Intervall
Helper:
last_timer 1
sleeptimer -1
Bm:
Doif_notify:
cnt 831
dmx 0
max 40
tot 217
mAr:
HASH(0x129718f8)
HASH(0x1293add0)
Internals:
0 Zirku_Pumpe_auto:STATE
all Zirku_Pumpe_auto:STATE
Itimer:
all Intervall
Readings:
Realtime:
0 22:06:53
State:
Time:
0 +[Intervall]
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Trigger:
Attributes:
do always
group Warmwasser
room Garage Irgendne Idee? Was ich komisch finde, ist die Syntax bei dem State des ersten DOIFs "on|off"! Da kann ja dann die Abfrage im Haupt-DOIF garnicht wahr werden?!?
Zitat von: Michi240281 am 26 März 2015, 21:53:16
Irgendne Idee? Was ich komisch finde, ist die Syntax bei dem State des ersten DOIFs "on|off"! Da kann ja dann die Abfrage im Haupt-DOIF garnicht wahr werden?!?
ja, mein Fehler, es muss heißen:
attr zirku_Pumpe_auto
cmdState on|off
statt
attr zirku_Pumpe_auto state on|off
(das state-Attribut musst du wieder Löschen)
Bei der Vielzahl der Attribute, weiß ich inzwischen selbst nicht mehr, was ich mir mal ausgedacht habe ;)
Gruß
Damian