[73_AutoShuttersControl] Jalousien:Lamellen steuern -Version 0.9.x Beta

[GU!DO]

Viiilen Dank!

[Beta-User]

@Beta-User
Du machst es einem ja nicht leicht nein zu sagen. Generalisierter Code klingt gut. Sofern Du Zeit hättest mich zu coachen, könnte ich in den Abendstunden mal damit spielen (sofern meine Regierung mich läßt!).

"Mein Problem" (für CUL_HM) scheine ich erst mal soweit gelöst zu haben :

Das ganze ist einigermaßen flexibel und so aufgebaut, dass jetzt "nur" noch jemand  je eine dispatch-Routine für HCAN, ROLLO, MQTT2_DEVICE beisteuern müßte...

Code Auswählen Erweitern

sub myASC_slat_command {
  my $target = shift // return;
  my $slatlevel = shift // return;

  my $type = InternalVal($target,'TYPE','');
  return if !$type;

  my $dispatch = {
    CUL_HM => \&myASC_slat_CUL_HM,
  };
  ref $dispatch->{$type} eq 'CODE'
  ?   $dispatch->{$type}->($target, $slatlevel)
  : Log3($target, 3, "$target: No dispatch routine for setting slats to >$type< available");
}

sub myASC_slat_CUL_HM {
  my $target = shift // return;
  my $slatlevel = shift // return;
 
  my $target_pct = ReadingsNum($target,'state',100);
  my $direction = ReadingsNum($target,'pct',100) < $target_pct ? "up" : "down";
  #get the difference in pct rounded to .5 values
  $slatlevel = $direction eq "up" ? 100 - $slatlevel : $slatlevel;
  my $turn_pct = int(AttrVal($target,"myASC_Turn_Pct",2.3)*$slatlevel/50)/2;
  my $intermediate = $direction eq "up" ? $target_pct + $turn_pct : $target_pct - $turn_pct ;
  my $sleepname = qq(myASC_slat_$target) ;
  CommandSet(undef, "$target pct $intermediate");
  CommandDefMod(undef,"-temporary $sleepname notify $target.motor..stop.$intermediate set $target pct $target_pct");
  $attr{$sleepname}{ignore} = 1;
  #Log3($target, 3, "$target (CUL_HM): slat $slatlevel, start $start_pct, target $target_pct, dir $direction");

}

Zur Erläuterung: Jeder TYPE kann eine eigene sub bekommen, die wäre als Funktion in "$mydispatch" einzubauen. An die wird dann automatisch weitergegeben, was das Device ist und was der slatlevel, den Rest müßte die Routine dann selber machen.

Hoffe, der Beispielcode für CUL_HM ist dann recht einfach auf den betreffenden Anwendungsfall anzupassen, aber die Events bzw. die Readings, die man auswerten muß, sind eben vermutlich unterschiedlich, und ob ROLLO z.B. mit 0.5-er Prozentwerten klarkommt, weiß ich auch nicht...

(Falls das gut läuft, müßte man CoolTux ggf. fragen, ob er die dispatches und den Umweg über notify+dummy irgendwie einsparen will/kann. Meine Lösung hat nämlich den Nachteil, dass das temporäre notify im Hintergrund immer aktiv bleibt und jeweils geändert wird, was wieder eigentlich unnötige Events auslöst. Verwaltet man das modulintern, geht es ggf. eleganter; ansonsten könnte man mittelfristig auch überlegen, das in ein eigenes Zusatz-Hilfsmodul auszulagern).

[GU!DO]

Ich finde es immer bewundernswert wenn das jemand augenscheinlich so locker herunterschreibt!  RESPEKT!

Hab jetzt nur keine Ruhe es zu verstehen. Sehe es mir heute Abend mal an. Auf jeden Fall: Danke schön! 

[Beta-User]

"so locker" war das nicht...

Es war nur so, dass ich grade sowieso dabei war verstehen zu wollen, wie das mit "dispatch" funktioniert und die ganzen Events für CUL_HM noch halbwegs gegenwärtig waren von einem sehr viel länger zurückliegenden Versuch, die Mist-Dinger irgendwie in den Griff zu bekommen .
Aber trotz der "Vorarbeiten" hat es eine gewisse Zeit gebraucht, bis mir im Eregebnis dann klar war, wie man es generalisiert und flexibel auch für andere TYPE zusammenbauen kann... Zum Glück hat es hier heute morgen immer mal wieder geregnet . Jetzt sind es nur noch Feinheiten, an denen man ggf. @CUL_HM schrauben muß....

Ansonsten: laß' dir Zeit und du darfst gerne nachfragen, wenn was unklar ist...

[Typ1er]

kommen in der aktuellen Version die set-Commands jetzt etwas verzögert?

[CoolTux]

Welche Version genau. Habe vor 2 Stunden eine neu hochgeladen, aber nur weil ich den aktuellen Stand festhalten wollte.

Aber davon ab sollte sich kein set Befehl irgendwie verzögern.

[GU!DO]

@Beta-User
Sorry, heute wird das leider nix mehr.
Ich hab mir heute Nachmittag den Weatherman gebaut, damit ich die Raffstores und Glasdachbeschattung vernünftig steuern kann. Das muß ich jetzt erst abhaken. Ich denke dann morgen Abend oder spätestens übermorgen. Gelegenheiten gibts ja, dank Corona, mehr als gewöhnlich.

[Typ1er]

die letzten 2 Tage ist schon aufgefallen das 2 von 3 Jalousien mit den Lamellen auf 30% fahren, Heute mal alle bewusst manuell verstellt. am Ende standen die 2 Jalousien wieder zur Nacht auf 0:30 das ist bei mir die Beschattungsposition, statt der 0:0


Einziger Unterschied ist 2x wird gefahren über positionBlinds/positionSlat
hier wird zur Nacht die 0:30 angesteuert (Beschattung)

meine dritte wird über pct/positionSlat gefahren.
diese führt am Ende den Slat-befehl nicht aus, diese bleibt beim wert der vorher war.

Version ist: v0.9.16

[Beta-User]

@Beta-User
Sorry, heute wird das leider nix mehr.

Kein Ding!

Ab hier machst du das ja für dich . Mir ging es erst mal drum, "mein Problem" (CUL_HM) zu lösen, und das eben so zu machen, dass man das im Prinzip - auch in beliebiger Kombination - mit anderen Typen generisch nutzen kann.

@CoolTux:
Sollen wir die Diskussion/weitere Entwicklung eigentlich in einen eigenen Thread auslagern? Hat ja "nur noch am Rande" was mit dem Modul zu tun (bzw. dem Code _im Modul_)?Oder gibt es Chancen, ein "drittes Argument" für das Attribut zu bekommen, in dem dann ein Perl-Funktionsaufruf stehen könnte - mit Übergabe von Aktor, Zweitaktor, Zielposition, Lamellenzielposition, (Fahranlaß)? (Wobei es mit hoher Wahrscheinlichkeit in diesen Spezialfällen immer so sein wird, dass es nur einen Aktor gibt).

[CoolTux]

die letzten 2 Tage ist schon aufgefallen das 2 von 3 Jalousien mit den Lamellen auf 30% fahren, Heute mal alle bewusst manuell verstellt. am Ende standen die 2 Jalousien wieder zur Nacht auf 0:30 das ist bei mir die Beschattungsposition, statt der 0:0


Einziger Unterschied ist 2x wird gefahren über positionBlinds/positionSlat
hier wird zur Nacht die 0:30 angesteuert (Beschattung)

meine dritte wird über pct/positionSlat gefahren.
diese führt am Ende den Slat-befehl nicht aus, diese bleibt beim wert der vorher war.

Version ist: v0.9.16

Nein noch keine Verzögerung. Die werde ich aber die Tage einbauen.

[CoolTux]

Kein Ding!

Ab hier machst du das ja für dich . Mir ging es erst mal drum, "mein Problem" (CUL_HM) zu lösen, und das eben so zu machen, dass man das im Prinzip - auch in beliebiger Kombination - mit anderen Typen generisch nutzen kann.

@CoolTux:
Sollen wir die Diskussion/weitere Entwicklung eigentlich in einen eigenen Thread auslagern? Hat ja "nur noch am Rande" was mit dem Modul zu tun (bzw. dem Code _im Modul_)?Oder gibt es Chancen, ein "drittes Argument" für das Attribut zu bekommen, in dem dann ein Perl-Funktionsaufruf stehen könnte - mit Übergabe von Aktor, Zweitaktor, Zielposition, Lamellenzielposition, (Fahranlaß)? (Wobei es mit hoher Wahrscheinlichkeit in diesen Spezialfällen immer so sein wird, dass es nur einen Aktor gibt).

Welches Attribut würde es genau betreffen?

[Beta-User]

Das Attribut "ASC_SlatPosCmd_SlatDevice".

Dem Gefühl nach sollte es reichen, wenn man da statt der Textangabe/n für "setter" bzw. "2. Zieldevice" nur noch eine Perl-Funktion angeben würde, und dann die externe Funktion auch den eigentlichen Fahrbefehl übernehmen kann/soll (also ASC den nicht selbst sendet). Man muß den nämlich modifizieren, also zuerst "zu weit" fahren...

Ich würde auch vorschlagen, mit einer festen Abfolge der zu übergebenden Argumente zu arbeiten, so dass du da nicht innerhalb ASC viel extrapolieren mußt. Was in der Funktion nicht benötigt wird, wird eben verworfen.

Gibt da sicher noch ein paar Randbedingungen, über die man nachdenken muß (super wäre es z.B., wenn auch übergeben werden könnte, ob die Richtung up oder down ist), aber eigentlich sind das m.E. lösbare Feinheiten (z.B.: für ganz offen/ganz zu ist das Verhalten der CUL_HM-Aktoren ok, da reicht der "normale" Fahrbefehl ohne Modifikationen, es gibt da dann aber auch keine zweite Angabe in den Positionsattributen.

[CoolTux]

Ich denke da lässt sich was machen. Ich muss mir das mal in Ruhe anschauen und durch spielen.

[Beta-User]

  Danke vorab!

Nachbrenner: statt up/down fände ich grade die aktuelle Position gut, die ASC ermittelt hat. Dann kann man selber vergleichen und uU. noch besser reagieren, wenn sich die Positionen nur geringfügig unterscheiden...

(Im Zweifel nachfragen, wenn es mehrere Varianten gibt, bin aber den Tag über eher nicht online...).

[Typ1er]

Marco meine fahren zur Nacht (brightness) immer in die Beschattungsposition.

Kann ich das irgendwo nachvollziehen? Das Log ist jeden Tag ca 600MB groß.