Das bezieht sich auf die Erklärung aus https://forum.fhem.de/index.php/topic,99980.msg963669.html#msg963669 Es geht darum, dass ich nur absent, gone und home bei den Roommates nutze. Wurde das Rollo jetzt in der Nacht manuell bewegt und ein vorher nicht anwesender Roommate kehrt heim, wird das Rollo in die ASC_Closed_Pos gefahren. Anders herum gefragt, in welchem Fall ist es denn sinnvoll hier eine Aktion auszulösen? Wenn ASC_Mode_Down auf always steht, wurde das Rollo ja auf jeden Fall durch ASC heruntergefahren. Daher ist doch dann ein erneutes Herunterfahren beim heimkommen eines Rommates nicht erforderlich, oder übersehe ich hier etwas?
Schließe mich mal an, siehe Threadschubser.
Zu der nachfolgenden Anmerkung gleich eine Frage an @Freneato: ist es für KNX ok, wenn der Lamellenbefehl gleich mit dem Fahrbefehl kommt, oder muß die Jalousie erst an die Zielposition?
Als Merkposten mein Kommentar im Thread:
Was die konkrete Umsetzung angeht, war mal der Gedanke, den Drehwinkel jeweils als weitere Angabe hinter den Ziellevel zu schreiben. Aber das ist zum einen schwerer zu pflegen (die readingsGroups mögen das nicht...), und zum anderen würde die Auswertung der Attribute dadurch erschwert.
Wäre es nicht ein Ansatzpunkt, die ganze Jalousie-Geschichte in EIN Attribut zu packen, und dort dann alle Einstellungen reinzupacken? Dann könnte man entweder so machen, dass man dort neben dem Namen und set-Befehl (bei meinem ZWave-Aktor ist das ein anderes Device, und dort "dim") die Attributnamen der dazu passenden Levelangaben nimmt, oder einfach nur nummerischen Zielleveln einen festen Drehwinkel zuordnet.
Beispiele:
Für die Verwendung der Attributnamen: Code: [Auswählen] attr DEVICE ASC_Venetian_Settings {{'Name'=>'mein_Lamellengerätename'},{'setCommand'=>'dim'},{'ASC_Open_Pos'=>'99'},{'ASC_Closed_Pos'=>'0'},{'ASC_Ventilate_Pos'=>'35'}}
Für die Verwendung der nummerischen Werte: Code: [Auswählen] attr DEVICE ASC_Venetian_Settings {{'Name'=>'mein_Lamellengerätename'},{'setCommand'=>'dim'},{'99'=>'99'},{'0'=>'0'},{'30'=>'35'}}
Vermute, die zweite Variante ist viel einfacher umzusetzen, denn von den Fahrbefehlen her müßte man dann nur "setDriveCmd" so erweitern, dass nachgesehen wird, ob es einen passenden Lamellen-Hash gibt und den dann zusätzlich absetzt. Zumindest bei den ZWave-Geräten ist es auch egal, wann der Lamellenbefehl abgesetzt wird, das darf dort direkt mit (oder auch schon vor) dem normalen Fahrbefehl gemacht werden.
Sonst müßte man "setDriveCmd" (und dessen Aufrufe...) so aufbohren, dass das erkennen kann, welcher Fahrbefehl gesendet wurde. Auch das ist vermutlich ein überschaubarer Aufwand, die Suche listet 28 Vorkommen des Textes, da sind aber log-Funktionen dabei.
Da der Vorschlag hier sehr auf eine bestimmte Gerätetype zugeschnitten ist: wäre es sinnvoll, dazu nochmal einen separaten Thread aufzumachen und um Rückmeldung von "Betroffenen" zu bitten? Macht aber nur Sinn, wenn das Thema noch einigermaßen zeitnah auf der Agenda steht? Ansonsten könnten wir auch mit dem nummerischen Vorschlag mal starten; eine spätere optionale Verzögerung wäre vermutlich recht einfach nachträglich einzubauen, und m.E. ist es auch kein Beinbruch, eine so komplexe Attributeingabe (ist eine einmalige Aktion) vornehmen zu müssen; der Kreis der Interessenten scheint ja überschaubar zu sein, und wenn man mal ein Beispiel hat, ist es auch nicht unmöglich...
