guten abend,
nach dem ich letzte woche mit fhem und homematic angefangen habe und heute beim einbau der ersten rolladenmotoren zufällig der fenstergriffkontakt per post gekommen ist (der eigentlich für etwas anderes vorgeshen war) habe ich kurzerhand beschlossen das es eigentlich ganz nett wäre wenn man beides kombiniert und den rolladen ein paar sinnvolle dinge machen lässt wenn man das fenster öffnet. z.b. wenn das fenster nachts gekippt wird den rolladen ein stück zum lüften hochfahren lassen, tagsüber aber ganz hoch und beim ganz auf machen immer ganz hoch. abends beim fenster schließen ganz runter. im prinzip funktioniert es in einer ersten version. es sind aber einige fragen aufgetaucht:
1) warum kommen alle events vom fenstergriff doppelt:
2013-01-12 21:41:09 CUL_HM FensterLinks open
2013-01-12 21:41:09 CUL_HM FensterLinks contact: open (to cul2)
2013-01-12 21:41:11 CUL_HM FensterLinks tilted
2013-01-12 21:41:11 CUL_HM FensterLinks contact: tilted (to cul2)
2013-01-12 21:42:05 CUL_HM FensterLinks closed
2013-01-12 21:42:05 CUL_HM FensterLinks contact: closed (to cul2)
2) der code für das notify schaut bisher so aus:
FensterLinks {
my $value = Value( "Rolladen" );
Log 4, "Griff: Event: >%EVENT<, Zustand: >".$value."<";
if( "%EVENT" eq "open" && $value eq "down" )
{ fhem( "set Rolladen up" ); }
elsif( "%EVENT" eq "tilted" && $value ne "up" && $value < 20 )
{
if( isday() ) { fhem( "set Rolladen up" ); }
else { fhem( "set Rolladen 20" ); }
}
elsif( "%EVENT" eq "closed" && !isday() )
{ fhem( "set Rolladen down" ); }
}
leider liegt der offen status auf dem weg zwischen zu und gekippt. es kommt also vor dem gekippt event auf jeden fall das offen event. das ist im code oben soweit berücksichtigt. nur wenn ich den griff recht schnell drehe passiert es manchmal das die status led rot wird. was bedeutet das die kommunikation mit fhem nicht mehr geht und kein ack gekommen ist. ich vermute das liegt daran das genau dann die anweisung für den rollo gesendet wurde oder das rollo über den fahren rückmeldung gibt. das der griff dann noch mal sendet verstärkt den traffic natürlich noch. ist es eventuell sinnvoll die anweisung für das offen event nicht direkt zu senden sondern eine sekunde verzögert und nur dann wenn bis dahin kein weiteres event vom griff gekommen ist? gibt es hierzu schon einen vorgesehenen mechanismus ?
3) wenn man so eine steuerung auf mehrere fenster und rolläden erweitern will kommt recht schnell der punkt an dem man sich wünscht irgendwie eine zuordnung von fenstergriff zum rolladen und umgekehrt zu haben. dann könnte man das notify ganz generell halten und über den griff der das event ausgelöst hat auf den zu steuernden rolladen schließen. und umgekehrt beim automatischen schließen eines Rollladens am abend vorher schauen ob der zugehörige griff auch zu ist. gibt es hierzu einen vorgesehenen weg?
ich hoffe ich habe nicht etwas offensichtliches übersehen das schon irgendwo dokumentiert ist.
andre
Hi!
Ich könnte mir das so vorstellen:
in der Fhem.cfg
define Rollo dummy
attr Rollo setList state: Zu Auf
attr Rollo eventMap on:Auf off:Zu
attr Rollo room Experiment
define Griff dummy
attr Griff setList state:open,tiled,closed
attr Griff webCmd state
attr Griff room Experiment
(Die Dummy's dienen nur der Simulation deines speziellen Falles)
define n_Rollo notify Rollo {FensterLinks("Rollo", "Griff")}
define n_Griff notify Griff {FensterLinks("Rollo", "Griff")}
und in der 99_MyUtils.pm:
sub
FensterLinks($$) {
my ($Rollladen, $Griff) = @_;
my $Rollo_Status = Value("$Rollladen"); # on(Zu):off(Auf)
my $Griff_Status = Value("$Griff"); #open,tilted, closed
Log 1, "Griffzustand: $Griff_Status, Rollo_Zustand: $Rollo_Status";
if( $Griff_Status eq "open" && $Rollo_Status eq "Zu"){
fhem( "set $Rollladen Auf" );}
elsif($Griff_Status eq "tilted" && $Rollo_Status eq "Auf" || $Rollo_Status < 20 ){
if(isday()) {fhem("set $Rollladen Auf"); }
else {fhem("set $Rollladen 20"); }
}
elsif( $Griff_Status eq "closed" && !isday()){fhem("set $Rollladen Zu");}
}
Damit könnte man universell FensterLinks("<Rollladendevice>", "<Griffdevice>") mit dem jeweiligen Devicenamen für verschiedene Rollläden per entsprechenden "notify"-Definitionen nutzen. Man kann das Ganze sicher durch Zusammenfassen verkürzen. So wie es jetzt ist kann ich aber auch später den Zusammenhang leichter Wiedererkennen ;o)....
MfG, MisterEltako.
hallo,
ja. das ist eine lösung die möglich ist. was hierbei nicht geht bzw. dann wieder extra gemacht werden muß ist die umgekehrte zuordnung von griff zu rolladen um beim automatischen schließen abends zu prüfen ob der griff auch wirklich zu ist. fenster mit zwei flügeln und somit zwei griffen brauchen auch wieder eine sonderbehandlung. das könnte man zwar auch mit einer structure lösen. aber die ist dann auch wieder an einer eigenen stelle definiert.
gefühlsmäsig gefällt mir die idee mit einer zuordnung von zusammengehörenden dingen immer noch besser. und je mehr ich nachdenken um so mehr anwendungsfälle komme mir in den sinn. aber wenn es mit bordmitteln noch nicht geht ist dein vorschag schon mal gut.
Hi!
Also in der Simulation hat das durch das 2.notify auch mit dem Rollo schließen am Abend unter Berücksichtigung der jeweilige Fenstergriffstellung funktioniert.
Zusammenfassen kann man, wie schon geschrieben. Ebenso wie Erweitern (2 Flügel)...
Ganz nach Belieben :-) ...
MfG, MisterEltako.
Hi,
ich werde nicht ganz schlau, habe den Code so übernommen.
Und beim dummy Auslösung bekomme ich die Fehlermeldung
n_Griff return value: Undefined subroutine &main::FensterLinks called at (eval 74) line 1.
Wo muß ich suchen?
Hallo
War ein copy + paste Fehler
Alles ok.
Gruß Otto
Hallo,
da auch meine Terrassenrollläden oben bleiben sollen, wenn die Türgriffe der Terrassentüren nicht zu sind, habe ich auch etwas gebastelt. Es funktioniert, dass die Terrassenrollläden oben bleiben, wenn einer der Griffe nicht zu ist. Und nach dem Schließen des Griffes, wenn beide Griffe zu sind, fahren die Rollläden zu.
Dafür habe ich in meine Funktion "Rollo_runter" einfach folgende Bedingung eingefügt:
elsif ($Rollo eq "WZ_Terasse_Rolladen" || $Rollo eq "K_Rolladen") {
if (Value("WZ_Terasse_Fenstergriffsensor") eq "geschlossen" && Value("K_Fenstergriffsensor") eq "geschlossen") {
fhem ("set ".$Rollo." runter");
}
else {
fhem ("set Rolloverzoegerung_Terasse aktiv");
Und nach dem Schließen des Griffes, wenn beide Griffe zu sind, fahren die Rollläden zu. Dazu habe ich ein neues Notify angelegt:
define Fenstergriffsensornotify1 notify .*Fenstergriffsensor:contact.* {Fenstergrifffunktion($EVENT,$NAME)}
welches die Funktion aufruft:
sub Fenstergrifffunktion($$) {
my ($Event,$Griffname) = @_;
my @Namensarray = split(/_Fenstergriffsensor/,$Griffname);
my $Fenstername = $Namensarray[0];
my $Rolloname = $Fenstername."_Rolladen";
if (Value("WZ_Terasse_Fenstergriffsensor") eq "geschlossen" && Value("K_Fenstergriffsensor") eq "geschlossen" && Value("Rolloverzoegerung_Terasse") eq "aktiv") {
fhem("set Rolloverzoegerung_Terasse passiv");
if (defined($defs{Terassenrollos_runter})) {
fhem("delete Terassenrollos_runter");
}
fhem('define Terassenrollos_runter at +00:05:00 {Rollo_runter($we,"K_Rolladen,WZ_Terasse_Rolladen")}');
}
elsif (Value($Griffname) eq "offen" && Value($Rolloname) eq "runter") {
fhem("set ".$Rolloname." hoch");
}
}
Nun ist ja hier auch der Teil von MisterEltakos Lösung enthalten, die Rollläden wieder hoch zu fahren, wenn der Griff geöffnet wird und der Rollladen unten ist. Allerdings möchte ich das Schließen des Rollladens nach Schließen des Griffes davon abhängig machen, wie der Status des Rollladens vor Öffnen des Griffes war und nicht von "IsDay".
Wie kann ich den Status des Rollladens speichern, den er hatte bevor er durch das Auslösen des Griffnotifys hochgefahren wurde?
Gruß
Christian