Unterstützung der Lamellenverstellung bei Jalousien #5

New Issue

marko · 2020-03-31T19:51:01Z

marko commented

2020-03-31 19:51:01 +00:00

Klasse wäre auch, wenn Jalousien mit Lamellenverstellung ins Modul vollständig eingebunden werden könnten. Die Lamellenverstellung hat bei mir bei KNX ebenso Positionsangaben von 0-100.

marko commented

2020-03-31 19:51:14 +00:00

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...

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...

marko added the

enhancement

label 2020-03-31 19:55:06 +00:00

marko closed this issue

2020-10-05 11:42:18 +00:00

Sign in to join this conversation.