Vorstellung: Projekt zur Beschattungssteuerung für fixe Schattengrenzen

[Matsch]

Mein Vorhaben war es, die Rollläden so zu steuern, dass die Hell-Dunkel-Grenze (Schattenwurf) mitten im Zimmer immer genau an einer bestimmten Linie im Raum verbleibt und nicht in der Höhe wandert.
Wozu soll das gut sein?

Zwei Beispiele:

1. Der PC-Arbeitsplatz soll zwar tagsüber möglichst viel Licht haben, aber die Sonne soll nie auf den Monitor scheinen können. Es soll also geregelt werden, dass die Schattengrenze ohne eigenes Zutun immer in Höhe des Arbeitstisches unterhalb des Monitors liegt.
2. Eine Bank mit Orchideen im Wohnzimmer. Auch dort soll möglichst viel Licht vorhanden sein, aber die Pflanzen dürfen nie direkte Sonne abbekommen. Die Schattengrenze soll etwa in Höhe der Töpfe liegen.

Das soll unabhängig vom Sonnenstand und der Jahreszeit funktionieren.

Es gibt verschiedene Gründe, mit dem Positionieren von Rollladenaktoren unzufrieden zu sein. Manch einem stört es aus Prinzip, dass der Rollladen bei einer 50%-Anweisung deutlich weiter zu macht als er soll. Bei mir ist es konkret der Einsatz in einer o.g. Art der Beschattung, die nur möglich ist, wenn sich die Behänge physikalisch hinreichend präzise positionieren lassen.

Ich stelle hier das Projekt in 3 Abschnitten vor:

1. Wie erhöhe ich die Positionsgenauigkeit des Behangs, Grundvoraussetzung für das eigentliche Vorhaben. Sicher gibt es dafür auch weitere Einsatzfälle
   -> UP für die Transformation der Sollwerte
2. Wie kann ich trotz „gefakter“ Stellwerte die Rollladenposition als Normalwerte weiterverarbeiten und anzeigen (z.B. in einer App)? Das wird nicht jeder brauchen und kann optional genutzt werden.
   -> UP für die Rückgewinnung der Sollwerte zu Anzeigezwecken
3. Die eigentliche Beschattungsregelung. Wie errechne ich die nötige Behanghöhe, um die Schattengrenze an einer gedachten Linie im Raum konstant zu halten? Das ist sozusagen ein konkreter Einsatzfall für die verbesserte Positionierung nach 1.
   -> UP zur Berechnung der notwendigen Behanghöhe

1. Verbesserung der Positionsgenauigkeit von Rollladenantrieben

Jeder der einen Rollladenaktor betreibt, weiß, dass die physikalische Position des Behangs in vielen Situationen deutlich vom zugewiesenen Sollwert abweicht. Die Prinzip bedingten Ursachen sind bekannt:

• Die Walze dreht sich mit konstanter Geschwindigkeit, die Positionierung erfolgt zeitgesteuert. Je weiter aufgewickelt ist, umso größer wird der Wickeldurchmesser und damit die Fahrgeschwindigkeit des Behangs. D.h. bei voll ausgefahrenem Behang bewegt sich dieser relativ langsam, mit zunehmender Höhe aber immer schneller. Die Bewegung ist nichtlinear.

• Die Lamellen (insbesondere bei Kunststoff) haben untereinander ein nicht unerhebliches Längsspiel. Das führt dazu, dass bei einer internen Position von 12 ... 20 % der frei hängende Behang bereits auf dem Fensterbrett aufstößt und der Rest der Bewegung nur noch zum Zusammenschieben der Lamellen führt. Auch dieses Verhalten soll in die Korrektur eingehen.

1.1. Vorarbeiten

Um die mathematische Funktion der Behangbewegung zu formulieren, benötigen wir 3 Punkte der Kurve.
Die beiden Endpunkte stehen fest, bei 0% Sollwert ist auch die physikalische Position 0. Das analoge trifft auf 100% zu. Für den dritten Punkt suchen wir uns die Mitte des Fahrwegs aus.
Das Ganze funktioniert umso genauer, je präziser die Fahrzeiten des Antriebs ermittelt und in die Gerätekonfiguration eingetragen sind (ich benutze hier die automatische Kalibrierfahrt bei meinen „dummen“ Antrieben).

Für den dritten Punkt müssen wir die vollständige gestreckte Länge des Rollladens zwischen den beiden Endpunkten des Antriebs kennen. Die zu messen wird meist nicht möglich sein, also müssen wir eine Näherung benutzen.
Wir fahren den Rollladen nach unten, bis kurz vor dem Aufstoßen. Das kann mit der Aktorwippe/-Taste oder auch im Gerätestatus im WebUI geschehen.

Achtung! Nicht mehrfach hin- und herfahren, das verringert die Genauigkeit. Am besten, vor jedem Versuch erneut die Endlagen anfahren zum Rekalibrieren.

Nachdem wir die gewünschte Lage erreicht haben, lesen wir die Istposition im WebUI aus dem Statuskanal (reale Position in %). Diesen Wert werden wir auch noch für den zweiten Korrekturvorgang brauchen, also notieren.

Nun berechnen wir aus dem Wert die wahrscheinliche Gesamtlänge des Fahrwegs, indem wir den Abstand zwischen der jetzigen Behangunterkante zur Position bei voll eingefahrenem Behang messen (also quasi knapp die Fensteröffnung) und prozentual verlängern.

Beispiel: An meiner Balkontür messe ich einen Abstand zwischen den beiden Punkten von 196 cm und eine Ist- Position unten von 16% (Gerätestatus). Dann liegt die Länge also bei etwa:

L = 196 cm * (1 + 0,16) = 228 cm.

Die Mitte (50%) liegt daher bei s_50% = 228 cm/2 = 114 cm.

Diesen Wert markieren wir jetzt ebenfalls am Rahmen, von der Unterkante des voll eingezogenen Behangs aus gemessen. Danach fahren wir den Rollladen an genau diese markierte Stelle. Bezüglich der Genauigkeit gilt wieder das oben gesagte. Mit dem Auslesen der dazugehörigen Istposition aus dem Gerätestatus haben wir nun die Koordinaten des dritten Punktes auf der Kurve. In meinem Beispiel beträgt der Wert 57 %.


1.2. Das Unterprogramm

Anmerkung: Ich arbeite in meiner Anwendung mit Prozentpunkten, also Werten von 0 … 100. Ich speichere das Ergebnis auch so in eine SV und muss den Wert bei Ausgabe an den Aktor noch durch 100 dividieren.
Wer statt auf eine SV direkt auf den Aktor ausgeben will, sollte dann generell mit den reellen Zahlen arbeiten, also im Wertebereich 0 … 1.

1.2.1. Funktionsprinzip der Unterprogramme

Die wichtigen Algorithmen sind als Unterprogramme angelegt, so dass nur ein einziges Programm vorhanden ist, das für alle vorhandenen Rollläden verwendet werden kann.
Zu jedem UP ist eine Systemvariable vom Typ Zeichenkette definiert. In diese wird der Aufruf samt Parametern als String eingeschrieben. Sobald sich der Inhalt der SV ändert, wird das UP getriggert und ausgeführt. Dabei werden die Übergabeparameter wieder aus dem String extrahiert.

Damit keine Aufrufe verloren gehen, muß jeder neue Datensatz/Aufruf an den Inhalt der SV angehängt werden und darf nicht direkt zugewiesen werden!

Das UP ist so aufgebaut, dass es, falls sich inzwischen mehrere Datensätze/Aufrufe in der SV vorfinden, diese nacheinander in einer Loop abarbeitet.
Die Parameter sind durch ‘,‘ getrennt, der Datensatz wird abgeschlossen mit ‘|‘ .

Bsp.: "56.8,SV_WZ_Rolllade_Tür_Höhe_Soll,18,55|"




1.2.2. Bestimmung der quadratischen Funktion

Wir haben jetzt 3 Kurvenpunkte (im Folgenden soll der zur physikalischen Mitte gehörenden Istpositionswert
h_m genannt werden) . Der Parameter h_m ist einer der Parameter, die beim Aufruf des UPs mit übergeben werden müssen.

P1(0|0), P2(100|100), P3(50|57)

P1 und P2 gibt es so in jedem Anwendungsfall, nur P3 wird von Tür zu Fenster und unterschiedlichen Behangdicken individuell ausfallen.

Die Jüngeren unter uns greifen jetzt einfach zum Taschenrechner und tippen die Punkte ein – fertig ist die Lösung.
Alle anderen erstellen daraus folgendes Gleichungssystem der allg. Form f(x) :

F_01_.jpg (10.29 KiB) 3333 mal betrachtet

Aus der ersten Gleichung ist zu sehen, dass c = 0 sein muß. Damit haben wir die erste Unbekannte und die erste Gleichung kann entfallen.
Die verbleibenden Gleichungen dividieren wir durch je einen gemeinsamen Faktor so, dass b den Faktor 1 erhält, also Gleichung 2 durch 100 und Gleichung 3 durch 50:

F_09.jpg (6.37 KiB) 3279 mal betrachtet

Nun ziehen wir die Gleichungen voneinander ab, um b zu eliminieren:

F_03.jpg (6.96 KiB) 3333 mal betrachtet

Diesen Wert in die obere Gleichung eingesetzt ( b = 1 – 100a ) ergibt die Lösung für b.
Damit haben wir die benötigte Gleichung

F_04_.jpg (14.36 KiB) 3333 mal betrachtet

Damit kann jetzt im UP der Wert errechnet werden, der an den Aktor ausgegeben werden muß, damit der Behang auf der korrekten Position steht.

Für das obige Beispiel des Rollladens einer Tür ergebe sich also:

F_05.jpg (5.85 KiB) 3333 mal betrachtet

Für meine Fenster ergibt sich auf diesem Weg der Punkt P3(50|55) und damit die Formel

F_06.jpg (5.59 KiB) 3333 mal betrachtet

1.2.3. Berücksichtigung des Lamellenspiels

Wir wissen aus den ersten Messungen, dass für die Bewegung zwischen offen und Aufstoßen auf dem Fensterbrett ein Stellwertebereich von beispielsweise nur 100 … 16% erforderlich ist. Um das zu kaschieren, muß der Bereich der Vorgabe linear gestaucht werden. Ich habe dazu folgende Variante umgesetzt:

Da ich im Normalfall nur bis zum Aufstoßen ( h_r = 16% ) fahren möchte, aber auch die Möglichkeit des kompletten Verschließens nicht vermissen will, habe ich folgende Festlegung getroffen:
Reale Positionswerte kleiner als h_r (hier <16 %) sind kaum sinnvoll, denn was nützt mir ein teilweise voll verschlossener Rollladen? Ich lege also fest, dass alle Vorgabewerte von 100% … 2% in den Fahrweg von 100% .... h_r(16%) transformiert werden sollen, alle Werte < 2% aber sollen immer zum vollständigen Verschluss führen (0%). Der Stellwertebereich h_r … 1% wird also gar nicht benutzt.

Der oben errechnete Stellwert muß also noch einmal gestaucht werden.
Der dazu nötige Faktor errechnet sich aus

F_07.jpg (9.43 KiB) 3333 mal betrachtet

Der Stellwert berechnet sich dann mit Hilfe von Faktor F:

Stellwert = (Vorgabewert – 100) * F + 100


Im Beispiel mit 16% als kleinstem Stellwert und 2% als kleinstem Vorgabewert:

F_08.jpg (5.51 KiB) 3333 mal betrachtet

So ergibt sich ein Stellwert = (Vorgabewert – 100) * 0,857 + 100

[Matsch]

1.2.4. Umsetzung in Script-Code

Ich persönlich schicke das Stellwertergebnis nicht direkt auf den Aktor (wobei das gut möglich wäre), sondern speichere es in eine Systemvariable, die nur dann an den Aktor geschickt wird, wenn der Rollladen gerade automatisch gesteuert werden soll. So kann diese Berechnung immer laufen, auch wenn die Rollladensteuerung sich nicht im Automatikmodus befindet und kann beim Wechsel in den Automatikmodus sofort wirksam werden.

So sieht nun das Unterprogramm dazu aus. Die Übergabe-SV ist zusätzlich zu erstellen:

Programmname: _UP_2_Rollladen_Sollwertlinearisierung
Übergabevariable: Param_UP_2 (Typ Zeichenkette)

Mit dem Script:

Code: Alles auswählen

!Ausgeben des korrigierten Sollwertes an den Sollwertpuffer            _

! Uebergabeparameter:
! 1. Vorgabehoehe in 0.0 ... 100.0% (real)
! 2. Objektname Ziel für Aktor-Sollhöhe in 0.0 ...100.0% (real)
!         SV oder Aktordatenpunkt (dann Wert vorher durch 100 dividieren!)
! 3. Aufstosshoehe Rolllade in % (etwa 15…20%)
! 4. Rollladen-Istwert bei 50% physikalischer Höhe

! Standardwerte
real KorrMitte = 55.0;
real MinHoehe  = 18.0;

string s;

if ((dom.GetObject("Param_UP_2").Value()).Length() > 0)
{
  foreach (s, (dom.GetObject("Param_UP_2").Value()).Split("|"))
  {
    real Sollhoehe = (s.StrValueByIndex(",",0)).ToFloat();
    object objKorrSollhoehe = (dom.GetObject(s.StrValueByIndex(",",1)));
    if ((s.StrValueByIndex(",",2)).Length() > 0)
    {
      MinHoehe = (s.StrValueByIndex(",",2)).ToFloat();
    }
    if ((s.StrValueByIndex(",",3)).Length() > 0)
    {
      KorrMitte = (s.StrValueByIndex(",",3)).ToFloat();
    }
    real neuerSollwert;
    real F;

    ! Bestimmen der Formelkonstanten 
    real a = (50.0 - KorrMitte) / 2500.0;
    real b = 1.0 - (100.0 * a);

    ! Korrektur des Wickeldurchmessers
    ! f = a*x*x + b*x

    neuerSollwert = (a * Sollhoehe.Pow(2.0)) + (b * Sollhoehe);

    ! Positionsverschiebung zum Ausgleich des Lamellenspiels

    if (Sollhoehe >= 2.0)
    {
      F = (100.0 - MinHoehe)/98.0;
      neuerSollwert = (((neuerSollwert-100.0) * F) + 100.0);
      neuerSollwert = ((neuerSollwert*2).Round(0))/2;
      if (neuerSollwert > 100.0) {neuerSollwert = 100.0;}
      elseif (neuerSollwert < 0.0) {neuerSollwert = 0.0;}
    }
    else
    {
      neuerSollwert = 0.0; ! Sollwerte < 2% gelten als "vollständig geschlossen"
    }

    ! Ausgabe an Aktor oder SV

    objKorrSollhoehe.State(neuerSollwert);  ! neuen Wert in Sollwertpuffer schreiben
  }
  dom.GetObject("Param_UP_2").State("");
}

Im Code enthalten sind auch Standardwerte für den Punkt P3 und für die Istposition beim Aufstoßen am unteren Ende. Diese sind für alle gleichartigen Fenster ja identisch und können auf die vorhandenen Fenster angepaßt werden.
Bei mir sind alle Fenster gleicher Art und nur die Tür weicht ab. Deshalb habe ich die Standardwerte für diese Fenster gesetzt. Für alle diese Fenster müssen dann beim Aufruf des UPs diese Parameter nicht mit übergeben werden, es werden die Standardwerte benutzt.

Beispiele für den Aufruf aus einem Programm heraus

1. Parameter: gewünschte physikalische Höhe ( in %)
2. Parameter: Objekt-Bezeichner für Ergebnis-SV
3. Parameter: Aufstosshöhe des Rollladens in % (optional)
4. Parameter: Aktor-Istwert bei 50% physikalischem Fahrweg in % (optional)

Code: Alles auswählen

object p= dom.GetObject("Param_UP_2");
p.State(p.Value() # (dom.GetObject("SV_WZ_Rolllade_Tür_Höhe_Auto").Value()).ToString(1) # ",SV_WZ_Rolllade_Tür_Höhe_Soll,16,57|");

Code: Alles auswählen

object p= dom.GetObject("Param_UP_2");
p.State(p.Value() # "56.8,SV_WZ_Rolllade_Tür_Höhe_Soll,18,55|");

was mit obigem Script-Code identisch wäre zu:

Code: Alles auswählen

object p= dom.GetObject("Param_UP_2");
p.State(p.Value() # "56.8,SV_WZ_Rolllade_Tür_Höhe_Soll,,55|");

oder

Code: Alles auswählen

object p= dom.GetObject("Param_UP_2");
p.State(p.Value() # "56.8,SV_WZ_Rolllade_Tür_Höhe_Soll,|");

[Matsch]

2. Inverse Berechnung für Anzeige

In einigen Fällen braucht man die Angabe, welcher Vorgabewert denn der aktuellen Position entspricht, z.B. zur Anzeige der Rollladenhöhe in einer App, denn dort soll ja nicht der Aktor-Istwert, sondern die echte physikalische Position angezeigt werden, auch dann, wenn der Rollladen per Hand über Wippe verstellt wird. Insofern nützt es nichts, den ehemals vorgegebenen Sollwert aus einem Programm zu merken.
Hier muss quasi eine invertierte Berechnung aus dem Aktor-Istwert erfolgen.

Dazu müssen halt nur die bisher benutzten Formeln umgestellt werden. Die Lösung der quadratischen Gleichung dürfte bekannt sein:

F_10.jpg (4.94 KiB) 3195 mal betrachtet

(Hier ist nur eine der beiden Lösungen sinnvoll)

Die quadratische Gleichung

F_11.jpg (4.21 KiB) 3195 mal betrachtet

Wird nun umgestellt mittels Division durch a

F_12.jpg (6.31 KiB) 3195 mal betrachtet

Mit p = b/a und q = Istposition/a

Konkret für das o.g. Beispiel also:

F_13.jpg (14.99 KiB) 3195 mal betrachtet

2.1.1. Umsetzung in Form eines Unterprogramms

Auch diese Funktionalität ist wie oben beschrieben als Unterprogramm ausgeführt:

Programmname: _UP_1_Rollladen_Vorgabewert_rückrechnen
Übergabevariable: Param_UP_1 (Typ Zeichenkette)

Mit dem Script:

Code: Alles auswählen

! Rückrechnung Vorgabewert aus der Position     _

! Uebergabeparameter:
! 1. Bezeichner SV für korrigierte Isthöhe
! 2. Bezeichner Aktorkanal Status
! 3. Minimale Rollladenhoehe in % (12 … 20)
! 4. Rollladen-Istwert bei 50% physikalischer Höhe

! Bsp: dom.GetObject("Param_UP_1").State(dom.GetObject("Param_UP_1").Value() # "_Neo_AZ_Ost_RealeHoehe,AZ_Rollladenaktor_Ostfenster:3,18,55|");

string s;

! Standardwerte
real KorrMitte = 55.0;
real MinHoehe  = 18.0;

if ((dom.GetObject("Param_UP_1").Value()).Length() > 0)
{
  foreach (s, (dom.GetObject("Param_UP_1").Value()).Split("|"))
  {
    object objKorrSollhoehe =  dom.GetObject(s.StrValueByIndex(",",0));
    real Isthoehe        = (dom.GetObject(s.StrValueByIndex(",",1))).DPByHssDP("LEVEL").State() * 100.0;
    if ((s.StrValueByIndex(",",2)).Length() > 0)
    {
      MinHoehe = (s.StrValueByIndex(",",2)).ToFloat();
    }
    if ((s.StrValueByIndex(",",2)).Length() > 0)
    {
      KorrMitte = (s.StrValueByIndex(",",3)).ToFloat();
    }
    real alterSollwert;
    real F;

    ! Positionsverschiebung zum Ausgleich des Lamellenspiels rückrechnen
    ! Stellwert für normale Schließposition (Lamellen noch offen): 20%, soll 2% Vorgabe entsprechen

    if (Isthoehe > (MinHoehe-1.0))
    {
      F = (100.0 - MinHoehe) / 98.0;
      alterSollwert = ((Isthoehe - 100.0)/F) + 100.0;

      ! Rückkorrektur des Wickeldurchmessers

      ! Bestimmen der Formelkonstanten f(x) = a*x*x + b*x
      real a = (50.0 - KorrMitte) / 2500.0;
      real b = 1.0 - (100.0 * a);
    
      ! Funktion Isthoehe = a*x*x + bx, umgeformt in:
      ! 0 = x*x + (b/a)*x - (alterSollwert/a)
      real p = b/a;
      real q = 0-alterSollwert/a;

      ! allgemeine Lösung: x = -p/2 - Sqrt(Pow(p/2) - q) 
      alterSollwert = ((p/-2.0) - (((p/2.0).Pow(2.0) - q).Sqrt()));
      alterSollwert = ((alterSollwert * 2.0).Round(0)) / 2.0;
      if (alterSollwert > 100.0) {alterSollwert = 100.0;}
      elseif (alterSollwert < 0.0) {alterSollwert = 0.0;}
    }
    else
    {
      alterSollwert = 0.0;
    }
    objKorrSollhoehe.State(100.0 - alterSollwert);
  }
  dom.GetObject("Param_UP_1").State("");
}

Beispiel für einen Programmaufruf:

Code: Alles auswählen

object p= dom.GetObject("Param_UP_1");
p.State(p.Value() # "SV_AZ_Ost_KorrHoehe,AZ_Rollladenaktor_Ostfenster:3,18,55|");

[Matsch]

3. Anwendungsfall Beschattungssteuerung mit fixer Hell-Dunkel-Grenze

3.1. Theoretische Betrachtungen

Das Ziel ist es, die Schattengrenze durch entsprechende Steuerung des Rollladens immer entlang eines gedachten Punktes im Raum einzustellen, unabhängig von Sonnenstand und Jahreszeit. Dazu folgende theoretische Betrachtung:

Aus der Darstellung ergibt sich

F_15.jpg (5.68 KiB) 3200 mal betrachtet

Der prozentuale Sollwert ist dann für einen Verstellbereich 100 … 2%:

F_16.jpg (5.23 KiB) 3200 mal betrachtet

Bitte beachten: liegt der Schattenpunkt unterhalb des Fensterrahmens, dann ist der Wert dist_vert negativ!


3.2. Umsetzung in Form eines Unterprogramms

Auch diese Funktionalität ist wie oben beschrieben als Unterprogramm ausgeführt:

Programmname: _UP_3_Rollladen_Vorgabewert_rückrechnen
Übergabevariable: Param_UP_3 (Typ Zeichenkette)

Mit dem Script:

Code: Alles auswählen

! Höhe nach Sonnenstandwert setzen                                   _

!Parameterliste:
! 1: Objektname Sollwertspeicher
! 2: horizontaler Abstand des Schattenpunktes vom Fenster in cm
! 3: vertikaler Abstand des Schattenpunktes von Fensterunterkante in cm
! 4: Gesamthöhe Fensterausschnitt (h-max) in cm
! 5: untere Rahmenhöhe (Abstand Fensterbrett zur Fensteröffnung) in cm

! Beispiel:
! dom.GetObject("Param_UP_3").State(dom.GetObject("Param_UP_3").Value() # "SV_AZ_Hoehe_Ostfenster_Auto,140,-25,116,12|");

! Standardwerte:
real Rahmenhoehe = 12.0;   ! Standardwert untere Rahmenhöhe der Fenster in cm
real h_max = 116.0;        ! Standardwert Fenster in cm


string s;
object objSollhoehe;
real dist_hor;
real dist_vert;
real x;
real h;

if ((dom.GetObject("Param_UP_3").Value()).Length() > 0)
{
  foreach (s, (dom.GetObject("Param_UP_3").Value()).Split("|"))
  {
    objSollhoehe = dom.GetObject((s.StrValueByIndex(",",0)));
    dist_hor = s.StrValueByIndex(",",1).ToFloat();
    dist_vert = s.StrValueByIndex(",",2).ToFloat();
    if (s.StrValueByIndex(",",3).Length() > 0)
    {
      h_max = s.StrValueByIndex(",",3).ToFloat();
    }
    if (s.StrValueByIndex(",",4).Length() > 0)
    {
      Rahmenhoehe = s.StrValueByIndex(",",4).ToFloat();
    }

    !Rollladenhöhe aus Sonnenstand berechnen

    x = system.SunAltitude();
    x = (x/90.0) * M_PI_2;      ! Winkel Grad in Bogenmaß umrechnen
    h = (x.Tan() * dist_hor) + dist_vert + Rahmenhoehe ;     
    if (h < Rahmenhoehe) {h = Rahmenhoehe;}    ! Mindesthöhe, nicht ganz schliessen

    ! Rundung auf 2,5%-Schritte

    h = (h * 0.98) + 2.0;     ! Verfahrweg 100...2% = 98%
    h = ((h * 4.0)/ h_max)+0.05;     ! =  (h/110)*4;   
    h = h.Round(1) * 25.0;    ! = * 100 / 4  
    if (h > 100.0) {h = 100.0;}

    if ((objSollhoehe.Value() - h).Abs() >= 1)
    {  ! bei einer Ist-Soll-Differenz von mehr als 1%
      objSollhoehe.State(h);
    }
  }
  dom.GetObject("Param_UP_3").State("");
}

Beispiel für einen Programmaufruf:

Code: Alles auswählen

object p= dom.GetObject("Param_UP_3");
p.State(p.Value() # "SV_AZ_Hoehe_Ostfenster_Auto,140,-25,116,12|");

Anmerkung: Gegenwärtig bewegt sich die Schattengrenze in einem Bogen um das Fenster herum, weil der Azimut nicht berücksichtigt ist. Ich tüftele noch einer erweiterten Funktion, wo auch das noch beachtet wird. Hier ist es momentan schwierig, die Anforderung zu formulieren, da ja die Entfernung des Schattenpunkts gegen unendlich wandert, je spitzer der horizontale Winkel zwischen Fensterfläche und Sonne wird.


Schlußbemerkungen

Ich habe hier ausführlich erläutert, was genau in den UPs passiert. Nicht jeder wird das wissen wollen, aber für einige - hoffe ich - ist es interessant, das nachvollziehen zu können.
Wer das nicht möchte und trotzdem nutzen will, der erstellt einfach nur die UPs samt Script und nutzt sie analog zu den gezeigten Aufrufen. Die Ermittlung der beiden notwendigen Parameter nach Kapitel 1.1 kann ich ihnen aber nicht abnehmen.

[Patt]

Respekt, cooles Projekt!

[Patt]

Also ich muss mal meinen Senf dazu geben. Sicherlich wird dies nicht von vielen genutzt werden (meine Vermutung), aber ich wollte nur mal sagen wie krass ich das Projekt finde. Habe mich zwar noch nicht intensiv damit beschäftigen können, aber alleine das durchlesen fand ich klasse!

Ich finde es faszinierend, was man alles mit Homematic etc. anstellen kann aber noch besser finde ich,dass es Freaks wie dich @Matsch gibt die die skills haben, das ganze auch noch umzusetzen!

[nimmnenkeks]

Vielen Dank für die Vorstellung und den dataillierten Herangehensweisen!


Sicherlich nicht für viele User eine Anwendungsfall, aber z.B. bei TV-Beschattung und (sofern vorhanden) "oberster Heeresleitung ... menno ist das finster... o.ä.",
die TV-Beschattung bedarfsgerecht fahren zu lassen

Abdeckung Pflanzenschutz (Licht/Helligkeit UND Verbrennungsschutz) ist ja mit dieser Umsezung im Sommer und auch Winter (bei Nutzung von solaren Beifang & Wärmeschutz bei Abwesenheit) auch gegeben.

Komme leider erst am WE dazu, die Details auf meine Anwendungsfälle (gerade bei Erkerfenstern) konzeptionell umzusetzen.

BG .Keks

[MichaelN]

Das UP 3 ruft man dann alle paar Minuten auf, um das Rollo dem Sonnenstand nachzuführen? In der angegebenen SV findet man dann die Sollhöhe, die man dann wiederum an UP 2 übergibt?

Wie detektierst Du den Beschattungsbedarf? Bei meiner TV-Beschattung habe ich das generelle Problem, das sich aus der Kombination von Azimut und Sonnenhöhe jeden Tag andere Grenzen ergeben. Somit habe ich jahreszeitlich bedingt manchmal eine Beschattung, die nicht mehr notwendig ist. Ich bin mir nicht sicher, ob deine Steuerung das Problem zumindest minimiert.

[Matsch]

Das UP 3 ruft man dann alle paar Minuten auf, um das Rollo dem Sonnenstand nachzuführen? In der angegebenen SV findet man dann die Sollhöhe, die man dann wiederum an UP 2 übergibt?

In der eigentlichen Steuerung triggert die Aktualisierung der Elevation den Aufruf von UP3:

(die SVs für die Elevation sind nichts weiter als die gespiegelten Sonnenstandswerte aus dem System)

Mit dem Script:

Code: Alles auswählen

! Höhe nach Sonnenstandwert setzen                                        _

! Wenn keine Orchideen am Fenster stehen oder im Winter (Nov. bis März),
! dann nur PC-Abschattung, sonst stärkere Abschattung als Sonnenschutz 
if ((dom.GetObject("SV_AZ_Beschattung").Value() == false) ||
    ((system.Date("%m").ToInteger() >= 11) || (system.Date("%m").ToInteger() <= 3)) )
{     ! "PC": Beschattung für PC-Arbeitsplatz
  dom.GetObject("Param_UP_3").State(dom.GetObject("Param_UP_3").Value() + "SV_AZ_Hoehe_Ostfenster_Auto,140,-25,116|");
}
else
{     ! "Orchideen": stärkere Beschattung für Orchideen
  dom.GetObject("Param_UP_3").State(dom.GetObject("Param_UP_3").Value() + "SV_AZ_Hoehe_Ostfenster_Auto,10,5,116|");
}

Im Moment benutze ich die Helligkeit als Randbedingung und fahre den Rollladen ganz hoch, sobald der Azimut so flach wird, dass die Sonne nicht mehr ins Zimmer scheinen kann.
Hier ist dann noch der Unterschied eingearbeitet, ob am Fenster abzuschattende Orchideen stehen oder nicht, dann liegt der Schatten an einer anderen Stelle.

In meinem Fall wird das Ergebnis von UP3 in die als Parameter angegebene Systemvariable SV_AZ_Hoehe_Ostfenster_Auto eingetragen. Ein weiteres (nicht dargestelltes) Programm wird bei dieser Aktualisierung getriggert und ruft, wenn die Betriebsart Automatik aktiv ist, mit diesem Wert UP2 auf, das dann wiederum den gefakten Stellwert an den Aktor oder eine weitere zwischengelagerte SV ausgibt.

[dtp]

Schönes Projekt. Vielen Dank für die ausführliche Beschreibung.

Was mich aber ein wenig stören würde, ist, dass hier die tatsächliche Helligkeit nicht berücksichtigt wird. Sprich, der Rollladen wird unabhängig vom Wetter immer in die entsprechende Position gefahren, auch wenn dies nicht notwendig ist. Oder habe ich da evtl. was falsch interpretiert?

Aber wäre eine Lösung mit einem Lichtsensor auf Höhe der gewünschten Schattengrenze da nicht sinnvoller? Und je nach gemessener Helligkeit (da genügt ja sogar ein Binärwert) würde der Rollladen dann einfach nachgeführt oder eben nicht.