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

[CoolTux]

@Beta-User
Als Attributnamen für das Slatdevice

ASC_Slatdevice ?

[Beta-User]

@Beta-User
Als Attributnamen für das Slatdevice

ASC_Slatdevice ?

"An sich" würde das passen, ABER:

Vor dem Hintergrund der gestrigen Diskussion hier (und dem dimPosition (?)-Hinweis aus dem anderen Thread) komme ich immer weniger von dem Gedanken weg, dass wir für das ganze genau zwei Attribute ein oder zwei Attribut(e) benötigen sollten würden,  die z.B. heißen könnten:
ASC_SlatPositions
ASC_SlatCommandPattern

In "ASC_SlatPositions" sollten dann nur Zuordnungen nach dem Motto "shading:30 close:0 open:99 ...", in "ASC_SlatCommandPattern" dann der jeweilige Befehl bzw. die Befehle reinschreiben zu lassen (FHEM-Befehl, aber auch Perl zulässig).
Vor der Übergabe an fhem.pl würde ich dann die Ersetzung von ein paar Varablen zulassen, nämlich $NAME (oder $name, für den Namen des aktuellen Devices), $position (für den Ziellevel), $slatPosition (für die Lamellenstellung) und $reason (für den Fahrtanlass). Eventuell könnte man das noch ergänzen durch die Hex-Umrechnung (@HMCCU.*), aber scheinbar ist das nicht zwingend. Das Zieldevice für die Lamellen (so es denn erforderlich ist), müßte der User dann eben da "vermosten", aber das ist eine einmalige Sache, die man mit ein paar Beispielen m.E. ganz gut in den Griff bekäme.

Am Vorhandensein der "ASC_SlatPositions" (während des Schreibens für besser befunden: am Vorhandensein des anderen Attributs) kann man erkennen, dass es sich um eine Jalousie handelt.

"ASC_SlatPositions" muß mMn. auch nicht "vollständig" sein, also für jeden Fahranlass eine Zuordnung enthalten; z.B. für auf oder zu wäre es ein "Service", einfach die Zielposition auch als SlatPositon zu verwenden, falls nichts anderes angegeben ist... Damit würde sich die "notwendige Angabe" auf den CommandPattern reduzieren, alles andere ist Feinjustage.

Setzt halt voraus, dass die Endverarbeitung erst beim Fahrbefehl stattfindet, ich habe jetzt nicht in den Code gesehen, wie du das umgesetzt hast und kann daher nicht sagen, ob das noch viel Aufwand wäre.

(Ist denn der Gedanke verständlich formuliert?)

[CoolTux]

Ich versuche es aus Sicht des bisherigen Anwenders zu sehen und versuche meine Logik mit ein zu bringen

Wir haben doch schon für jede Position ein Attribut, wieso soll man das nicht nehmen und einfach erweitern.

In "ASC_SlatPositions" sollten dann nur Zuordnungen nach dem Motto "shading:30 close:0 open:99

Genau das meine ich, wieso doppelt machen. Verstehst was ich meine?
Einfach einen zweiten Wert hinter den schon vorhandenen Positionswert für die Lamellenwinkel (oder wie man das nennt) und dann wird das ausgewertet.

Kann man davon ausgehen das sofern der Slat im selben Device statt findet der Command der selbe ist wie beim normalen fahren? Also pct oder dim??

[CoolTux]

Noch was anderes. Für Deine Lamellen hast Du ja zwei Fahrbefehle.
Müssen die Nacheinander kommen oder kann der zweite Befehl ausgeführt werden während der erste noch abgearbeitet wird?

[Beta-User]

Ich versuche es aus Sicht des bisherigen Anwenders zu sehen und versuche meine Logik mit ein zu bringen

Wir haben doch schon für jede Position ein Attribut, wieso soll man das nicht nehmen und einfach erweitern.

Weil es teils nicht nötig ist, und wenn man das so macht, ist es relativ umständlich zu ändern.

Habe ich das richtig verstanden, dass du nur aus dem Vorhandensein des zweiten Werts jeweils ablesen willst, dass es eine Jalousie ist? (Dann wird der user gezwungen, das wirklich überall zu pflegen und kann unsere schönen readingsGroups nicht nutzen... Wäre ggf. ok, wenn es eine andere GUI dafür gäbe, so ist es "lästig".).

Genau das meine ich, wieso doppelt machen. Verstehst was ich meine?

Einfach einen zweiten Wert hinter den schon vorhandenen Positionswert für die Lamellenwinkel (oder wie man das nennt) und dann wird das ausgewertet.

Wie gesagt: Es muß m.E. nicht doppelt (oder bei deiner Lösung: zwingend mehrfach) sein, sondern eben genau an einer Stelle, wobei wir sogar eine der zwei "überflüssig" (optional) machen können, und die zweite in irgendeiner Form "sowieso" brauchen (Command oder was auch immer).

Kann man davon ausgehen das sofern der Slat im selben Device statt findet der Command der selbe ist wie beim normalen fahren? Also pct oder dim??

Wenn ich das richtig verstanden habe, ist es genau umgekehrt: Dasselbe Device bedeutet zwingend, dass  der Befehl unterschiedlich ist (z.B. slatLevel bei CUL_HM, afaik).

Noch was anderes. Für Deine Lamellen hast Du ja zwei Fahrbefehle.
Müssen die Nacheinander kommen oder kann der zweite Befehl ausgeführt werden während der erste noch abgearbeitet wird?

Die können miteinander abgesetzt werden, Reihenfolge ist sogar beliebig.



Zu eventuellen zeitlichen Abhängigkeiten noch: In anderen Fällen mag das anders gelagert sein, und wenn du Perl zulassen würdest, kann das der User erledigen. Z.B. würde ich für meine "nicht-lamellenfähigen" CUL_HM-Geräte eigenen Code zwischenschalten können und z.B. über benannte sleep (mit notify-Logik) passende Fahrbefehle zusammenbauen, die zeitliche Abhängigkeiten berücksichtigen . In dem anderen (Ideen-Sammel-) Thread hatte ich das ja mal erläutert.

[CoolTux]

Ok ich versuche es erstmal mit einem zusätzlichen Attribut. Hinzufügen ist immer einfach, wegnehmen oder sogar ändern schon bei weitem schwieriger.
ASC_SlatPosCmd_SlatDevice = pct:RolloKuecheLinksSlat

Die Positionen werden als zweiten Wert hinter des Positions Attributen angegeben. Ist nichts angegeben wird die Lamelle auch nicht verstellt.
Soweit die Idee. Die Umsetzung wird zeigen ob es klappt. Mittlerweile ist der Code so flexibel das der Aufwand einer Änderung gering aus fällt.

[Beta-User]

...bin nicht 100% damit glücklich, aber du bist der Maintainer, also darfst du das so entscheiden. Werde also ab heute abend bzw. Bereitstellung mal testen, ob das klappt. Link ist wieder https://git-tuxnet.ddns.net/FHEM/mod-AutoShuttersControl?

Bzgl. nicht glücklich: https://forum.fhem.de/index.php/topic,110263.0.html (ich habe den Beitrag nicht bestellt...). Bei den Helligkeitswerten hatten wir das btw. mit dem Argument akzeptiert, dass der user das ja typischerweise nie mehr ändert; da sehe ich bei Leveln einen großen Unterschied. (Und war es nicht so, dass da Perl-Code stehen kann für den Ziellevel bei Beschattung?)

[CoolTux]

Ja der Link wäre der selbe.
Das mit Readingsgroup habe ich gelesen und verstehe das es doof ist. Aber aktuell geht Funktion vor Schönheit.

Das mit Readingsgroup bekommen wir später hin. Können wir dann dann mit den gettern und settern der ASC API machen.

Lass uns testen wie es funktioniert. Umbauen geht immer noch wenn es total doof ist.

[Beta-User]

Testen ist ok, kein Ding, bin ja froh, dass es vorangeht!

Aber wie gesagt: An sich finde ich es fast schon doof, dass ich überhaupt die Attribute anfassen muß. Für meine Zwecke ist es ausreichend, wenn die Jalousie bei geschlossen=0=>slat=0, offen=99=>slatlevel=99, lüften=60=>slatlevel=60 machen würde. Dafür muß ASC eigentlich wirklich nur wissen, dass es eine Jalousie ist...

[Wscheff]

Ich habe nun eine erste Version für die Unterstützung von "festen Zuordnungen"

Voraussetzung ist das das Rollo mit set ROLLONAME "feste Zurodnung" fährt.

Hi CoolTux, kurze Verständnisfrage:
Geht wirklich nur ventilate/shading und ich muss fürs testen manuell wieder zu fahren?
=> Wo kann ich die Open und Close Anweisungen eintragen: ASC_Sleep_Pos und ASC_Open_Pos?

oder gibt's da eine Logik zwischen Shading_Pos und Ventilate_Pos?

[Typ1er]

diese set Befehle stehen zur Verfügung:

-positionBlind (beim Fahren wird die Lamelle nicht verändert, 0-99)
-positionSlat (Lamelle, 0-99)
-dim (hier tritt ein eigenartiger Fehler auf, beim öffnen auf 99, wird die Lamelle am Ende auf 99 gesetzt, was beim nächsten Fahrbefehl bewirkt das die Lamellen am ende offen stehen, da Slat 99 ist).

Reading kommt über position rein:
position Blind 0 Slat 0

ich splitte das dann auf per userReading auf:
position_blind 0
position_slat 0

Da wir das grade im anderen Thread diskutieren: Kann man den Aktor auch "in einem Aufwasch" beide Werte mitgeben, also

Code Auswählen Erweitern

set <aktor> positionBlind 0 positionSlat 0
(Dass es mit zwei Befehlen auch geht, ist klar, und ich gehe mal davon aus, dass man die auch "gleich" loswerden kann und nicht erst warten muß, bis "blind" erreicht ist, bevor man "slat" setzen darf).

(for the records: Das ist ein FGR-222, oder? @CoolTux: Wenn ja, ist der ist noch ein "Einheitsdevice", aber Fibaro hat beim Nachfolger dann der "Norm" den Vorzug gegeben und das aufgesplittet, deswegen habe ich als FGR-223-Nutzer 2 bzw. 3 Geräte für den einen Aktor).

das klappt nicht beide Befehle mit einmal, bekomme diesen Fehler:
set positionBlinds needs one parameter

ja ist der Model FIBARO System FGRM222 Roller Shutter Controller 2

[CoolTux]

Hi CoolTux, kurze Verständnisfrage:
Geht wirklich nur ventilate/shading und ich muss fürs testen manuell wieder zu fahren?
=> Wo kann ich die Open und Close Anweisungen eintragen: ASC_Sleep_Pos und ASC_Open_Pos?

oder gibt's da eine Logik zwischen Shading_Pos und Ventilate_Pos?

Es ist ja erstmal nur zum testen. Ich will nur wissen ob meine Logik in der Praxis Bestand hat. Der Rest kommt dann noch.

Das mit OpenPos und ClosePos verstehe ich nicht.

Es gibt ASC_Open_Pos und ASC_Close_Pos

[Wscheff]

Ich wollte heute Ein wenig testen und stelle mir das so vor:

Fenster auf - jalo geht in ventilate

Fenster zu - nix passiert (weil das close command noch nicht umgesetzt ist), also muss ich ,,manuell zumachen"

Shading kann ich nachts nicht machen, ventilate Tags nicht. Oder übersehe da was?

Könntest du nicht bitte noch das close umsetzten?

Dann kann man Fenster auf/zu testen

[CoolTux]

Das Close sollte eigentlich auch funktionieren. Aber halt nur auf das fahren beschränkt, also keine Lamellenverstellung.
Am Tag kannst Du testen in dem Du dem Rollo einen Roommate zu weist und diesen dann schlafen legst.

[CoolTux]

Alles weitere zum Thema ASC und Lamellenfunktion bitte im neuen Thread
https://forum.fhem.de/index.php/topic,110277.0.html