Hallo zusammen,
irgendwie verzweifele ich doch noch so manches mal bei der Definition der DOIFs.
Ich steuere beispielsweise mit folgendem DOIF einen Rollo in der 1. Etage.
((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and ([du_Tageslicht] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
({if (ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "off") {fhem("set OG_ki1_RO_Garten off")}})
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]))
({if (ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "on") {fhem("set OG_ki1_RO_Garten on")}})
Bei meiner Steuerung habe ich einen Dummy, wo ich dir Art der Steuerung einstellen kann.
Bislang gibt es diese Werte für du_Rollo_Art:
Normal, Urlaub und Weihnachten
Da momentan Schulferien sind, dachte ich an noch einen Status "Schulferien".
Sofern dies gewählt ist, wollte ich die Rollos in der 1. Etage nicht automatisch zu der definierten Zeit der Arbeitstage öffnen lassen.
Also habe ich dies einfach mal so definiert.
Also im DOELSEIF den Status des Dummys abgefragt.
((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and ([du_Tageslicht] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
({if (ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "off") {fhem("set OG_ki1_RO_Garten off")}})
DOELSEIF (([?du_Rollo_Art] ne "Schulferien") and ([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]))
({if (ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "on") {fhem("set OG_ki1_RO_Garten on")}})
Dies hatte aber zur Folge, dass der Rollo zwar morgens nicht hoch geht, aber abends auch nicht mehr runter, da ja kein Zustandswechsel stattfindet.
do always kann mMn keine Lösung ein, da ansonsten bei jedem Wechel der Lichtstärke hier doch cmd_1 im dunkeln ausgeführt würde.
Ich bin ein wenig verwirrt und bräuchte mal Hilfe.
In der CommandRef sind zwar etliche Beispiele, nur auch die helfen hier nicht wirklich, auch wenn Damian da vermutlich irgendwo die Lösung notiert hat. ???
Ich habe das nun mal so gelöst, dass ich einfach im cmd-Teil noch den Dummy abgefragt habe.
Das habe ich ja eh schon drin, um unnötige Schaltbefehle zu unterbinden, wenn der Rollo schon oben ist.
Kann aber eigentlich nicht im Sinne des Erfinders sein oder?
((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and ([du_Tageslicht] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
({if (ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "off") {fhem("set OG_ki1_RO_Garten off")}})
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]))
({if ((ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "on") && (ReadingsVal("du_Rollo_Art", "state", "---") ne "Schulfereien")) {fhem("set OG_ki1_RO_Garten on")}})
du hast einen Tippfehler drin...
"Schulfereien"
Zitat von: moonsorrox am 03 April 2015, 13:30:19
du hast einen Tippfehler drin...
"Schulfereien"
Danke Dir Rene.
Dann würde mein neuer Plan auch nicht funktionieren. >:(
Habs mal berichtigt.
Ändert aber ja an meinem ursprünglicher Frage/Problem nichts.
Vielleicht hat ja noch jemand eine Idee dazu?
Moin,
ich steuere meine vorderen Jalousien (incl. Kinderzimmer) in Abhängigkeiten von Wochenende, Schulferien,Normal, und ob der RolloMasterDummy eingeschaltet ist.
Dazu habe ich eine Schulferien.holiday die NICHT mit Holiday2we verheiratet ist.
In dem einen DOIF sind die Hoch u. Runterfahrzeiten definiert. Funktioniert tadellos.
Ist es sowas was Du brauchst ?
Du kannst ja mal ein wenig mehr erklären, wann bei Dir die Rollos hoch und runter gehen.
Vielleicht kann ich da ja etwas übernehmen :)
Meine Steuerung habe ich mal hier incl Code verewigt.
http://www.fhemwiki.de/wiki/Rolladensteuerung_mit_Eingabemöglichkeiten
Klappt soweit auch gut. Bis ich halt auf die Idee der Schulferien gekommen bin.
Wo der Rest der Familie ausschlafen kann, während ich arbeiten muss.
Damit das klappt, sollten die Rollos auf dem 1. OG halt unten bleiben.
Und da klemmt es momentan halt, wie ich die DOIFs (pro Rollo gibt es ein DOIF) anpasse, damit der Status "Schulferien" beachtet wird.
Aber ich vermute mal, dass es mit der momentanen Definition klappen wird.
Warten wir mal ab....
Zitat von: maxritti am 03 April 2015, 12:24:23
Ich habe das nun mal so gelöst, dass ich einfach im cmd-Teil noch den Dummy abgefragt habe.
Das habe ich ja eh schon drin, um unnötige Schaltbefehle zu unterbinden, wenn der Rollo schon oben ist.
Kann aber eigentlich nicht im Sinne des Erfinders sein oder?
((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and ([du_Tageslicht] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
({if (ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "off") {fhem("set OG_ki1_RO_Garten off")}})
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]))
({if ((ReadingsVal("OG_ki1_RO_Garten", "state", "---") ne "on") && (ReadingsVal("du_Rollo_Art", "state", "---") ne "Schulfereien")) {fhem("set OG_ki1_RO_Garten on")}})
Die Frage ist ob du dein Rollo noch von woanders schaltest, wenn nein dann reicht ja:
((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and ([du_Tageslicht] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
(set OG_ki1_RO_Garten off)
DOELSEIF ([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7])
(set OG_ki1_RO_Garten on)[/quote]
Denn ohne do always wird ja ohnehin nur nach Zustandswechsel geschaltet, da kannst du dir die if-Anweisungen sparen.
Gruß
Damian
Zitat von: Damian am 03 April 2015, 14:20:13
Die Frage ist ob du dein Rollo noch von woanders schaltest, wenn nein dann reicht ja:
Es gibt halt die HM Schalter, wo auch mal gerne der Taster betätigt wird.
Also ist die Antwort "ja".
Zitat von: maxritti am 03 April 2015, 14:24:28
Es gibt halt die HM Schalter, wo auch mal gerne der Taster betätigt wird.
Also ist die Antwort "ja".
Ist er direkt mit dem Rollo gepairt?
Gruß
Damian
Vielleicht dient das als Aufklärung.
Folgender HM Jallousieaktor ist an die Motoren der Rollos angeschlossen.
http://www.elv.de/homematic-funk-rollladenaktor-fuer-markenschalter-1fach-unterputzmontage.html?refid=SEM_30003&gclid=CjwKEAjw9PioBRDdpqy0-ofG3DgSJAACe5NE4o2Imhlzj_LspYeiWiIhIe6Op9ILom37-u4ny5VRfRoCG1Pw_wcB
Zitat von: maxritti am 03 April 2015, 14:53:34
Vielleicht dient das als Aufklärung.
Folgender HM Jallousieaktor ist an die Motoren der Rollos angeschlossen.
http://www.elv.de/homematic-funk-rollladenaktor-fuer-markenschalter-1fach-unterputzmontage.html?refid=SEM_30003&gclid=CjwKEAjw9PioBRDdpqy0-ofG3DgSJAACe5NE4o2Imhlzj_LspYeiWiIhIe6Op9ILom37-u4ny5VRfRoCG1Pw_wcB
Die habe ich auch. Mit Taster meinst du offenbar den Schalter direkt. Dann sollte das ausreichen:
(([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and [du_Tageslicht] eq "dunkel" or [[du_Rollo_Zeit_ru]]) and [?OG_ki1_RO_Garten] ne "off")
(set OG_ki1_RO_Garten off)
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]) and [?OG_ki1_RO_Garten] ne "on")
(set OG_ki1_RO_Garten on)Gruß
Damian
Zitat von: Damian am 03 April 2015, 15:12:26
Die habe ich auch. Mit Taster meinst du offenbar den Schalter direkt. Dann sollte das ausreichen:
(([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and [du_Tageslicht] eq "dunkel" or [[du_Rollo_Zeit_ru]]) and [?OG_ki1_RO_Garten] ne "off")
(set OG_ki1_RO_Garten off)
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]) and [?OG_ki1_RO_Garten] ne "on")
(set OG_ki1_RO_Garten on)
Gruß
Damian
Das werde ich mal ausprobieren.
Und das mit dem Dummy dann auch einfach logisch and verknüpfen?
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]) and [?OG_ki1_RO_Garten] ne "on") and [?du_Rollo_Art] ne "Schulferien"[EinWenigOffTopic]
Wiki sagt zu einer Taste, dass dies ein Bedienelement ist, welches nicht in seiner gedrückten Postion verharrt, sondern in die Ursprungsstelle zurück kehrt.
Ein Schalter dagegen hat zwei definierte Zustände. Offen oder geschlossen und verbleibt in eben einer der Stellungen.
MMn sind das dann eben Taster :D
[/EinWenigOffTopic]
Zitat von: maxritti am 03 April 2015, 17:03:56
Das werde ich mal ausprobieren.
Und das mit dem Dummy dann auch einfach logisch and verknüpfen?
DOELSEIF (([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]) and [?OG_ki1_RO_Garten] ne "on") and [?du_Rollo_Art] ne "Schulferien"
[EinWenigOffTopic]
Wiki sagt zu einer Taste, dass dies ein Bedienelement ist, welches nicht in seiner gedrückten Postion verharrt, sondern in die Ursprungsstelle zurück kehrt.
Ein Schalter dagegen hat zwei definierte Zustände. Offen oder geschlossen und verbleibt in eben einer der Stellungen.
MMn sind das dann eben Taster :D
[/EinWenigOffTopic]
ja, die Wippe stellt physikalisch zwei Taster dar. Die ganze HM-Einheit könnte man logisch betrachtet auch als Schalter betrachten, da es im jeweiligen Zustand verharrt.
Gruß
Damian
Ich vermute mal, dass der Rollo, wo ich nun das and [?OG_ki2_RO_Garten] ne "on") and [?du_Rollo_Art] ne "Schulferien") implementiert habe heute abend nicht runter gehen wird, da state mit cmd_1 also dem runterfahren gestern abend angegeben sind.
Alle anderen Rollos stehen brav bei einem anderen state, da diese auf die Zeiten heute morgen "reagiert" haben.
Internals:
CFGFN
DEF ((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and ([du_Tageslicht:state] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
({if (ReadingsVal("OG_ki2_RO_Garten", "state", "---") ne "off") {fhem("set OG_ki2_RO_Garten off")}})
DOELSEIF ((([[du_Rollo_Zeit_ho]|8] or [[du_Rollo_Zeit_ho_WE]|7]) and [?OG_ki2_RO_Garten] ne "on") and [?du_Rollo_Art] ne "Schulferien")
(set OG_ki2_RO_Garten on)
NAME di_OG_ki2_RO_Garten
NR 106
NTFY_ORDER 50-di_OG_ki2_RO_Garten
STATE cmd_1
TYPE DOIF
Readings:
2015-04-03 20:26:34 cmd_event EG_dr_TS_Terrasse
2015-04-03 20:26:34 cmd_nr 1
2015-04-04 09:59:21 e_EG_dr_TS_Terrasse_luminosity 136
2015-04-04 06:36:10 e_du_Tageslicht_state hell
2015-04-03 20:26:34 state cmd_1
2015-04-03 22:15:00 timer_1_c1 04.04.2015 22:15:00
2015-04-04 06:40:00 timer_2_c2 05.04.2015 06:40:00|8
2015-04-04 09:30:00 timer_3_c2 05.04.2015 09:30:00|7
Condition:
0 ((ReadingValDoIf('EG_dr_TS_Terrasse','luminosity','') < InternalDoIf('du_Rollo_Luminosity_ru','STATE','') and (ReadingValDoIf('du_Tageslicht','state','') eq "dunkel")) or DOIF_time_once($hash->{timer}{0},$wday,""))
1 ((DOIF_time_once($hash->{timer}{1},$wday,"8") or DOIF_time_once($hash->{timer}{2},$wday,"7")) and InternalDoIf('OG_ki2_RO_Garten','STATE','') ne "on") and InternalDoIf('du_Rollo_Art','STATE','') ne "Schulferien"
Days:
1 8
2 7
Devices:
0 EG_dr_TS_Terrasse du_Rollo_Luminosity_ru du_Tageslicht
all EG_dr_TS_Terrasse du_Rollo_Luminosity_ru du_Tageslicht
Do:
0 {if (ReadingsVal("OG_ki2_RO_Garten", "state", "---") ne "off") {fhem("set OG_ki2_RO_Garten off")}}
1 set OG_ki2_RO_Garten on
Helper:
last_timer 3
sleeptimer -1
Internals:
0 du_Rollo_Luminosity_ru:STATE
all du_Rollo_Luminosity_ru:STATE
Itimer:
all du_Rollo_Zeit_ru du_Rollo_Zeit_ho du_Rollo_Zeit_ho_WE
Readings:
0 EG_dr_TS_Terrasse:luminosity du_Tageslicht:state
all EG_dr_TS_Terrasse:luminosity du_Tageslicht:state
Realtime:
0 22:15:00
1 06:40:00
2 09:30:00
State:
Time:
0 [du_Rollo_Zeit_ru]
1 [du_Rollo_Zeit_ho]
2 [du_Rollo_Zeit_ho_WE]
Timecond:
0 0
1 1
2 1
Timer:
0 0
1 0
2 0
Timerfunc:
Timers:
0 0
1 1 2
Trigger:
Attributes:
disable 0
room LichtRollo
Hast Du noch einen Tip, wo es hier nun klemmt?
Hm, wenn ich mal recht überlege passen die Bedingungen auch gar nicht darauf, wie ich es gerne hätte.
Der Rollo soll ja bei dem "Normal-Modus" Wochentags um du_Rollo_Zeit_ho hoch gehen.
Am Wochenende oder bei Modus "Schulferien" soll er um du_Rollo_Zeit_ho_WE hoch gehen.
Müsste dann ja mMn so aussehen:
((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and [?OG_ki2_RO_Garten] ne "off" and ([du_Tageslicht:state] eq "dunkel")) or [[du_Rollo_Zeit_ru]]))
(set OG_ki2_RO_Garten off)
DOELSEIF ((([[du_Rollo_Zeit_ho]|8] and [?du_Rollo_Art] ne "Schulferien") or [[du_Rollo_Zeit_ho_WE]|7]) and [?OG_ki2_RO_Garten] ne "on")
(set OG_ki2_RO_Garten on)
Aber ob das dann etwas an dem Problem "Rollo geht gar nicht mehr runter" am Wochentag ändert?
Ich werde mal testen. Und berichten...
Eine Möglichkeit, solche Logik-Bedingungen zu definieren und zu testen, ist das DOIF aufzuteilen.
Z.B.:
define di_central_heating DOIF (([[tc_begin_am]-[tc_end_am]] and [office_heating] eq "on") or
([[tc_begin_pm]-[tc_end_pm]] and [local_weather:temperature] < 15))
({if (Value("central_heating") ne "on") {fhem("set central_heating on")}})
DOELSE ({if (Value("central_heating") ne "off") {fhem("set central_heating off")}})
attr di_central_heating do always
lässt sich wie folgt aufteilen:
define di_central_heating_cond1 DOIF ([[tc_begin_am]-[tc_end_am]] and [office_heating] eq "on")
attr di_central_heating_cond1 cmdState on|off
define di_central_heating_cond2 DOIF ([[tc_begin_pm]-[tc_end_pm]] and [local_weather:temperature] < 15)
attr di_central_heating_cond2 cmdState on|off
define di_central_heating DOIF ([di_central_heating_cond1] eq "on" or [di_central_heating_cond2] eq "on")
({if (Value("central_heating") ne "on") {fhem("set central_heating on")}})
DOELSE ({if (Value("central_heating") ne "off") {fhem("set central_heating off")}})
attr di_central_heating do always
Damit kann man den Zustand von di_central_heating_cond1 und di_central_heating_cond2 anzeigen und prüfen.
Die Bedingung if (Value("central_heating") ne "on") integriere ich in diesem Fall lieber in perl, das ist klar und verständlich.
Gruss
flurin
Zitat von: flurin am 04 April 2015, 12:46:46
Eine Möglichkeit, solche Logik-Bedingungen zu definieren und zu testen, ist das DOIF aufzuteilen.
Z.B.:
define di_central_heating DOIF (([[tc_begin_am]-[tc_end_am]] and [office_heating] eq "on") or
([[tc_begin_pm]-[tc_end_pm]] and [local_weather:temperature] < 15))
({if (Value("central_heating") ne "on") {fhem("set central_heating on")}})
DOELSE ({if (Value("central_heating") ne "off") {fhem("set central_heating off")}})
attr di_central_heating do always
lässt sich wie folgt aufteilen:
define di_central_heating_cond1 DOIF ([[tc_begin_am]-[tc_end_am]] and [office_heating] eq "on")
attr di_central_heating_cond1 cmdState on|off
define di_central_heating_cond2 DOIF ([[tc_begin_pm]-[tc_end_pm]] and [local_weather:temperature] < 15)
attr di_central_heating_cond2 cmdState on|off
define di_central_heating DOIF ([di_central_heating_cond1] eq "on" or [di_central_heating_cond2] eq "on")
({if (Value("central_heating") ne "on") {fhem("set central_heating on")}})
DOELSE ({if (Value("central_heating") ne "off") {fhem("set central_heating off")}})
attr di_central_heating do always
Damit kann man den Zustand von di_central_heating_cond1 und di_central_heating_cond2 anzeigen und prüfen.
Danke Dir für den Tip mit cmdState.
Das habe ich schon ein paar mal gelesen, aber wohl nicht den Nutzen zuordnen können.
Macht jetzt aber Sinn. ;)
Zitat von: flurin am 04 April 2015, 12:46:46
Die Bedingung if (Value("central_heating") ne "on") integriere ich in diesem Fall lieber in perl, das ist klar und verständlich.
Gruss
flurin
Ich denke auch, dass ich zu dem if wieder übergehen werde.
Ansonsten landet das meist in Fällen, die ich nicht so recht nachvollzogen bekomme.
Zitat von: maxritti am 04 April 2015, 13:51:24
Ich denke auch, dass ich zu dem if wieder übergehen werde.
Ansonsten landet das meist in Fällen, die ich nicht so recht nachvollzogen bekomme.
Wenn die Logik stimmt und getestet wurde, dann kann man immer noch optimieren. Vermutlich ist mit der Aufteilung-Variante die if-Bedingung überflüssig.