[73_AutoShuttersControl.pm] Workaround Jalousien:Lamellen steuern -Version 0.8.x

[Beta-User]

Nur damit ich dazu nochmal deutlich meine Meinung gesagt habe:

Es macht für mich keinen Sinn, erst Komplexität zu erhöhen, indem man überall weitere Angaben erzwingt (einzeln bei allen Positionsangaben), und dann für die Lösung auf eine Einrichtungs-GUI zu verweisen, die letztlich auch nur dazu dienen muß, alle diese (unnötigen!) Angaben zusätzlich zu pflegen...

Da das Eröffnen eines neuen Threads auf mich wirkt, als wäre dazu im Moment keine weitere Diskussion erwünscht, werde ich das beherzigen und mich auch an einem Test nicht beteiligen, der einen Dummy als Zwischendevice braucht.
Bin mal auf das Endergebnis gespannt, ob das dann einfacher ist, als ich das grade befürchte...

[CoolTux]

Der Threadtitel hieß Workaround und ich habe eine Version welche nun Lamellen unterstützt, das hat halt nicht gepasst. Daher neuer Thread.

[Beta-User]

Der Threadtitel hieß Workaround und ich habe eine Version welche nun Lamellen unterstützt, das hat halt nicht gepasst. Daher neuer Thread.

YMMD ...

Wir nennen es preAlpha, und schon ist die Zwischenschaltung eines Dummy kein workaround mehr? Wieder was neues gelernt...

Im Ernst: Das mit den zusätzlichen Argumenten in den Pos.-Angaben ist und bleibt keine gute Lösung.

Leider sind diese Änderungen in dem Commit für mich nicht auf die Schnelle nachvollziehbar, sonst würde ich versuchen, da "in Perl" was dazu zu sagen.

Vielleicht ein Argument noch in dem Gesamtzusammenhang: Wenn du am Ende einen in einem Argument enthaltenen Command-Pattern zulassen würdest (und erst darüber entscheiden, ob der "normale" interne Fahrbefehl verwendet werden soll), den mit ein paar Variablen extrapolierst und dann an AnalyzeCommandChain() übergibst, machst du evtl. auch den einen oder anderen (KNX?)-User glücklich, der eigentlich gar nichts mit Jalousien und Lamellendrehwinkeln am Hut hat .

[CoolTux]

YMMD ...

Wir nennen es preAlpha, und schon ist die Zwischenschaltung eines Dummy kein workaround mehr? Wieder was neues gelernt...

Im Ernst: Das mit den zusätzlichen Argumenten in den Pos.-Angaben ist und bleibt keine gute Lösung.

Leider sind diese Änderungen in dem Commit für mich nicht auf die Schnelle nachvollziehbar, sonst würde ich versuchen, da "in Perl" was dazu zu sagen.

Vielleicht ein Argument noch in dem Gesamtzusammenhang: Wenn du am Ende einen in einem Argument enthaltenen Command-Pattern zulassen würdest (und erst darüber entscheiden, ob der "normale" interne Fahrbefehl verwendet werden soll), den mit ein paar Variablen extrapolierst und dann an AnalyzeCommandChain() übergibst, machst du evtl. auch den einen oder anderen (KNX?)-User glücklich, der eigentlich gar nichts mit Jalousien und Lamellendrehwinkeln am Hut hat .

Verstehe ich nicht. Wieso Dummy? In meiner Version benötigt man keinen Dummy. Bin irritiert.

Vielleicht ein Argument noch in dem Gesamtzusammenhang: Wenn du am Ende einen in einem Argument enthaltenen Command-Pattern zulassen würdest (und erst darüber entscheiden, ob der "normale" interne Fahrbefehl verwendet werden soll), den mit ein paar Variablen extrapolierst und dann an AnalyzeCommandChain() übergibst, machst du evtl. auch den einen oder anderen (KNX?)-User glücklich, der eigentlich gar nichts mit Jalousien und Lamellendrehwinkeln am Hut hat .

Da ich keine Ahnung vin KNX habe versteheh ich auch nicht was Du mir damit mitteilen willst.

[Beta-User]

Verstehe ich nicht. Wieso Dummy? In meiner Version benötigt man keinen Dummy. Bin irritiert.

Ok, da war ich auf dem falschen Dampfer, weil neben einem Gerät TYPE Dummy wohl auch HMCCUDEV einen Befehl mit fester Zuordnung kennt... Das ist aber m.E. die Ausnahme, oder habe ich "substitute" als allg. Attribut übersehen?

Code Auswählen Erweitern

attr HM_WohnzimmerJalBar substitute LEVEL,LEVEL_SLATS!#0-0:Geschlossen,#1-2:Sichtschutz,#3.1-5:Lichtschutz,#100-100:Offen

Da ich keine Ahnung vin KNX habe versteheh ich auch nicht was Du mir damit mitteilen willst.

Das bezieht sich auf das hier:

Hallo Wolfgang,

Es tut mir leid aber ich verstehe gerade nicht wieso Du da einen (fast) leeren String für KNX zu weist. Welchen Mehrwert hat es?
Du kannst das Attribut ASC_Pos_Reading setzen welches gleichzeitig das Reading zum auslesen der Position sein soll und der Command zum fahren der Rollos. Also pct oder dim oder was auch immer.
Ich kenne KNX nicht, mir wurde gesagt das man da vieles konfigurieren kann. Auch mit welchen Befehl das Rollo fahren soll. Also entweder mit der Angabe eines die Datenpunkte (Adressen) oder mittels einen Commands der dann auf die entsprechenden Datenpunkte verweist.


Grüße
Marko

Ich habe verstanden: der Befehl geht auf das Gerät selbst, das (zusätzliche) Leerzeichen ist nur ein Trick, um den Fahrbefehl irgendwie auf das Gerät selbst umzuleiten. Weiter scheint es so zu sein, dass das Position-Reading in diesem Fall "state" ist.

Wenn der User also als Postion-Reading-Attribut "state" angeben kann, am Ende aber ein "set $NAME $position" als Command zugelassen wäre, wäre auch dieser "Fisch geputzt".

Nochmal: Warum übergibst du nicht den Fahranlass (= aus welcher Unterfnktion von ACS kommt die Anweisung) ZUSÄTZLICH an deine Fahrroutine und entscheidest dann erst in dieser, welche Variante am Ende stattfindet?
Das kann dann sein:
1. ein normaler Fahrbefehl wie bisher ODER
2. eine durch den User festgelegte Routine, die folgende Varianten ermöglicht:
-- feste Zuordnung über das Gerät (HMCCUDEV) (set $NAME $festeZurodnung);
-- beliebige Anweisung als "normaler FHEM-Befehl" (je nach Bedarf mit Übergabe einiger Variablen, die du ja kennst bzw. - was die Lamellenstellung angeht - ggf. über ein weiteres Attribut oder wenn nicht vorhanden über $position=>$lamellaPosition ermittelt)
-- Perl-Command (wieder mit denselben Variablen).

Alle Varianten 2 - mit Ausnahme der Ermittlung der Lamellenwerte - müßten stressfrei über AnalyzePerlCommand "abzufackeln" sein... Du brauchst m.E. also gar keine großen Klimmzüge zu machen oder Userängste zu schüren (bezieht sich auf https://forum.fhem.de/index.php/topic,110280.msg1043269.html#msg1043269).

[CoolTux]

Ich habe verstanden: der Befehl geht auf das Gerät selbst, das (zusätzliche) Leerzeichen ist nur ein Trick, um den Fahrbefehl irgendwie auf das Gerät selbst umzuleiten. Weiter scheint es so zu sein, dass das Position-Reading in diesem Fall "state" ist.
Wenn der User also als Postion-Reading-Attribut "state" angeben kann, am Ende aber ein "set $NAME $position" als Command zugelassen wäre, wäre auch dieser "Fisch geputzt".

Soweit mir bekannt kann man im KNX Device konfigurieren welcher Befehl zu welchem Ziel führen soll.
Man kann konfigurieren das
set DEVICENAME 100
geht. Aber auch das
set DEVICENAME pct 100
geht. Wenn das wirklich so ist wie ich denke wer entscheidet dann für den User was besser ist. Deiner will die erste Variante der andere die zweite weil es eindeutiger ist. Der dritte will set DEVICENAME schließen als Unterstützung. Das mache ich nicht. Sofern meine Annahme stimmt!

Nochmal: Warum übergibst du nicht den Fahranlass (= aus welcher Unterfnktion von ACS kommt die Anweisung) ZUSÄTZLICH an deine Fahrroutine und entscheidest dann erst in dieser, welche Variante am Ende stattfindet?
Das kann dann sein:
1. ein normaler Fahrbefehl wie bisher ODER
2. eine durch den User festgelegte Routine, die folgende Varianten ermöglicht:
-- feste Zuordnung über das Gerät (HMCCUDEV) (set $NAME $festeZurodnung);
-- beliebige Anweisung als "normaler FHEM-Befehl" (je nach Bedarf mit Übergabe einiger Variablen, die du ja kennst bzw. - was die Lamellenstellung angeht - ggf. über ein weiteres Attribut oder wenn nicht vorhanden über $position=>$lamellaPosition ermittelt)
-- Perl-Command (wieder mit denselben Variablen).

Alle Varianten 2 - mit Ausnahme der Ermittlung der Lamellenwerte - müßten stressfrei über AnalyzePerlCommand "abzufackeln" sein... Du brauchst m.E. also gar keine großen Klimmzüge zu machen oder Userängste zu schüren (bezieht sich auf https://forum.fhem.de/index.php/topic,110280.msg1043269.html#msg1043269).

Der Fahranlass ergibt sich aus der gewählten Position welche angefahren werden soll. Das kann ich auch nicht ändern weil man mit Fahranlässen "Strings" keine Positionsabfrage auf einfache Weise hinbekommt um festzustellen ob das Rollo nicht schon in dieser Position ist ob es unterhalb dieser Position ist oder Oberhalb.
Es gäbe da vielleicht etwas aber das muss ich erst testen und das dauert.

Der User kann in der derzeitigen Variante bereits entscheiden wie sein Fahrbefehl zusammen gesetzt wird.
Die feste Zuordnung war ein Test den ich schnell umsetzen könnte und der mir zeigen sollte ob meine generelle Überlegung tatsächlich funktioniert. Daher geht das jetzt schon.
Das andere ist auch schon fertig und wird aktuell von mir getestet.

[Beta-User]

OK, KNX ist verstanden, man muß nicht jede mögliche Konfigurationoption für eine Technik "abfackeln" können. Sehe ich auch so.

Der Fahranlass ergibt sich aus der gewählten Position welche angefahren werden soll.

Das ist etwas, das nicht nur ich vermutlich nie verstehen werde und für einen Webfehler halte. Aus gegebenem Anlass würde ich empfehlen, genau aus dieser Denke irgendwann auszusteigen und dafür eben die Tür jetzt aufmachen (das waren afaik gerade mal 5-7 Stellen im Code, die man anfassen müßte, und keine grundlegenden Dinge).

Das kann ich auch nicht ändern weil man mit Fahranlässen "Strings" keine Positionsabfrage auf einfache Weise hinbekommt um festzustellen ob das Rollo nicht schon in dieser Position ist ob es unterhalb dieser Position ist oder Oberhalb.

Deswegen hatte ich "zusätzlich" geschrieben. Und welcher Anlaß es ist, muß eigentlich imo nicht im Attribut selbst stehen, weil du den Anlaß ja kennst (oder woher weißt du welches der Attribute du brauchst?).

Es gäbe da vielleicht etwas aber das muss ich erst testen und das dauert.

Kein Ding. Es eilt nicht, ich hatte (und habe immer noch) die große Sorge, dass das in eine unnötig komplizierte Richtung geht und wollte dies rechtzeitig mitteilen.

Der User kann in der derzeitigen Variante bereits entscheiden wie sein Fahrbefehl zusammen gesetzt wird.
Die feste Zuordnung war ein Test den ich schnell umsetzen könnte und der mir zeigen sollte ob meine generelle Überlegung tatsächlich funktioniert. Daher geht das jetzt schon.
Das andere ist auch schon fertig und wird aktuell von mir getestet.

Dann bin ich jetzt mal ruhig und lasse dich in Ruhe testen!