LBS 19000145 - Beschattungssteuerung-NG

[harry7922]

N'abend zusammen,

kann es sein, dass der Dämmerungs-Timer nicht korrekt funktioniert?
Der LBS blinkt nun schon seit 10 min, befindet sich in Status -6 und E62 ist auf Default 300 eingestellt. Die Jalousien schließen aber nicht.

Danke für die Hilfe.

Grüße
Hardy

[starwarsfan]

Hi

Ich erinnere auch nochmal

Jo danke. Ich schau mir das auf jeden Fall an, bin aber im Moment ausser Gefecht. Der Jahreswechsel hat sich leider völlig anders gestaltet als erwartet...

[g0bi]

Ich erinnere auch nochmal

[starwarsfan]

Hi

starwarsfan
Eine Feststellung, wenn die Dämmerungssteurung AN ist, schaut er immer noch ob die Fassadein "IN SUN" ist. Das ist meiner Meinung nach nicht korrekt.

Das Eine hat mit dem Anderen nichts zu tun. Der InSun-Check stellt lediglich fest, ob die Sonne noch im Bereich der Fassade ist oder nicht. Die Dämmerungssteuerung ist davon unabhängig.

Deshalb gehen die Lamellen nicht auf 100% sondern auf 50%.

Betrifft meine WEST-Fassade, im Süden ist alles ok.

Kann das sein?

Unwahrscheinlich aber ohne Screenshot der Logik und dem Log-Auszug lesbar in Code-Tags (!) kann ich zunächst nichts genaueres dazu sagen.

[Teutone]

starwarsfan
Eine Feststellung, wenn die Dämmerungssteurung AN ist, schaut er immer noch ob die Fassadein "IN SUN" ist. Das ist meiner Meinung nach nicht korrekt.

LOG DATEI:

2018-01-08 22:15:04	018755	4150	INFO:	===== === = LBS finished = === ===============================================
2018-01-08 22:15:04	125479	4150	INFO:	===== === = Brightness, Elevation or Azimut changed and LBS is active, starting it (v3.10) = ===
2018-01-08 22:15:04	125808	4150	INFO:	===== === = LBS was triggered = === ==========================================
2018-01-08 22:15:04	125948	4150	INFO:	<Input>: <Refreshed>|<Value>
2018-01-08 22:15:04	126364	4150	INFO:	Trigger: 0|1 Trigger changed output: 0| Brightness: 0|3 Brightness dawn: 0|17 Elevation: 0|-49.848592501094 Azimut: 1|303.92720103094 Activationstate: 0|1 Lockstate: 0|0 Internal timer: 0
2018-01-08 22:15:04	126930	4150	INFO:	Virtual depth and height of sun position in 90° to the facade: 0.79939952034839, -1.185377931822, effective Elevation: -56.004916688941
2018-01-08 22:15:04	127495	4150	INFO:	Previous value of A1 equals new value 1, skipping update of A1
2018-01-08 22:15:04	127754	4150	INFO:	Real azimut 303.92720103094° and facade at 267° -> IN SUN (from 177° to 357°), effective elevation -56.004916688941° for given elevation of -49.848592501094° -> NOT in min-max-range (0-90)
2018-01-08 22:15:04	127933	4150	INFO:	Storing current shutter state 0 and updating output if necessary
2018-01-08 22:15:04	129537	4150	INFO:	Previous value of A10 equals new value 0, skipping update of A10
2018-01-08 22:15:04	130068	4150	INFO:	Handling current shutter state NEUTRAL (0)
2018-01-08 22:15:04	130340	4150	INFO:	Values to write to outputs for height and angle: 100%/50%
2018-01-08 22:15:04	130889	4150	INFO:	Previous value of A2 equals new value 0, skipping update of A2
2018-01-08 22:15:04	131485	4150	INFO:	Previous value of A3 equals new value 100, skipping update of A3
2018-01-08 22:15:04	131915	4150	INFO:	Previous value of A5 equals new value 255, skipping update of A5
2018-01-08 22:15:04	133398	4150	INFO:	Previous value of A4 equals new value 50, skipping update of A4
2018-01-08 22:15:04	133958	4150	INFO:	Previous value of A6 equals new value 128, skipping update of A6
2018-01-08 22:15:04	134180	4150	INFO:	Shutter angle 50% = 0°
2018-01-08 22:15:04	134613	4150	INFO:	Previous value of A7 equals new value 0, skipping update of A7
2018-01-08 22:15:04	137988	4150	INFO:	Timer already finished
2018-01-08 22:15:04	141791	4150	INFO:	Storing current shutter state 0 and updating output if necessary
2018-01-08 22:15:04	143249	4150	INFO:	Previous value of A10 equals new value 0, skipping update of A10
2018-01-08 22:15:04	144455	4150	INFO:	===== === = LBS finished = === ===============================================
2018-01-08 22:30:04	712075	4150	INFO:	===== === = Brightness, Elevation or Azimut changed and LBS is active, starting it (v3.10) = ===
2018-01-08 22:30:04	712450	4150	INFO:	===== === = LBS was triggered = === ==========================================

Deshalb gehen die Lamellen nicht auf 100% sondern auf 50%.

Betrifft meine WEST-Fassade, im Süden ist alles ok.

Kann das sein?

[crewo]

... zumal auch einfach mit internen KOs arbeiten kann als Variablen pro Fassade.

[starwarsfan]

Hallo Thorsten,

diese Frage kam ganz am Anfang bereits auf und ich habe mich damals recht lange damit beschäftigt. Dabei stellt(e) sich sehr schnell die Frage, wo man die Trennung zwischen zwei (oder mehr) Bausteinen macht und ich habe den Gedanken wieder verworfen.

Unterm Strich macht es keinen Sinn, den LBS in mehrere LBS aufzusplitten. Wozu? Bisher konnte ich noch keine Vorteile entdecken. Ich verstehe durchaus den KISS-Ansatz und versuche auch wo immer es geht meine Logiken entsprechend aufzubauen. Beschattung ist aber alles in allem so komplex, dass es wesentlich komplizierter wäre, das gesamte Handling zwischen zwei (oder mehr) LBS abzugleichen. Zusätzlich muss dann der Benutzer auch noch wissen, welche Bausteine er für welche Fälle wie zu verwenden und zu verbinden hat, was es für beide Seiten komplizierter macht. Von daher ist die aktuelle Lösung in diesem Fall der beste Kompromiss.

Alles was Du nach Deiner Frage brauchst, kann der Baustein ootb und den Rest verwendest Du einfach nicht. Damit sollte Dein Anwendungsfall doch erschlagen sein oder nicht?

[Thorsten1970]

Hallo Yves,

wäre es möglich, den komplexen LBS aufzusplitten, so dass es einen allgemeinen Teil für eine Fassade gibt? In diesem wäre nur der Fassadenwinkel/Höhe, Beschattungshelligkeit und der Sonnenstand implementiert. Als Ausgang nur Sonne ja/nein und Beschattung ja/nein. Das wäre super!

Kannst du dies eventuell zur Verfügung stellen? Vielen Dank schon mal im Voraus.

Viele Grüße Thorsten

[starwarsfan]

N'abend

Yves? Passiert hier noch was?

Na sicher, auf jeden Fall. Nur wird es erst weiter gehen, wenn ich genügend Ruhe und Zeit habe, mich da hinein zu denken.

Habe mir #693 gerade nochmal durchgelesen. Das muss ich versuchen, im Detail nachzustellen, im Moment verstehe ich noch nichtmal genau, was Du da machst...

[g0bi]

Yves? Passiert hier noch was?

[g0bi]

Wäre nett...

[starwarsfan]

Dann erinner ich auch mal

Ja, das muss ich mir auch noch ansehen...

[starwarsfan]

Hallo Hartwig

Auf E7 kommt 17° an

Also ich gehe mal davon aus, dass Du hier 18° meinst oder unten den falschen Log-Schnipsel kopiert hast. Im Log wird der Wert von E7 ausgegeben, von daher kann der nicht von 17 auf 18 geändert worden sein.

E23: min Elevation steht auf 6
E24: max. Elevation steht auf 20

Azimut passt, denn Ausgang A1 geht auf 1

OK.

nun wird der Debug die folgende mir unverständliche Meldung raus:
Real azimut 221� and facade at 291� -> IN SUN (from 219� to 291�), effective elevation 43.531248601969� for given elevation of 18� -> NOT in min-max-range (6-20)

Das ist für meine Begriffe völlig korrekt.

Wenn ich die Range verändere und E24 auf 50 setze geht die Beschattung.

Jo, zwangsläufig, da nun ja die effektive Elevation im gültigen Bereich liegt.

Hier wird in der Bewertung die Elevation Range x 2,55 gerechnet!

Wie kommst Du darauf? Wenn hier eine Multiplikation ausgeführt werden würde, dann wäre das nicht 2,55 sondern 2,4184...

Aber anyway, es wird nichts multipliziert, sondern die für die Positionierung der Lamellen notwendige effektive Elevation ausgerechnet. Ich hole mal etwas weiter aus.

Die effektive Elevation ist die Elevation, mit der die Sonne im rechten Winkel auf die Lamellen scheint. Der einfachste und somit der Idealfall ist also der, wenn das Azimut der Fassade und der Sonne gleich sind. Dann ist die effektive Elevation gleich der Elevation der Sonne. Das ist aber vor und nach dem Azimut der Fassade nicht der Fall bzw. läuft theoretisch bis auf 90°, je weiter sich das Azimut der Sonne dem Azimut der Fassade +/- 90° nähert und die gegebene Elevation positiv ist.

Was die Berechnung also macht ist in Theorie folgendes: Die Fassade wird in Richtung Sonne so weit "verlängert", bis die Sonne im rechten Winkel auf die Fassade scheint. An dieser Position wird die effektive Elevation berechnet, welche zwangsläufig grösser ist, als die gegebene Elevation. Der springende Punkt ist, dass die Elevation der Sonne immer gegen den gleichen Punkt angegeben wird, da sich die Sonne durch die Erdrotation quasi auf einer virtuellen Kreisbahn "um die jeweilige Fassade herum" bewegt. Diese Rotation muss nun aber mit einer linearen Positionierung der Raffstore-Lamellen in Einklang gebracht werden.

Wenn diese Berechnung nicht gemacht wird hat man das Problem, dass die Lamellen am Anfang und am Ende des Fassadenoffset zu weit offen oder geschlossen sind, je nachdem in welche Richtung die Fassade gegenüber der jeweiligen Elevation positioniert ist. Ich habe ewig geübt, bis ich auf diese Lösung gekommen bin.

Aber nichts desto trotz besteht wohl noch eine gewisse Unschärfe im Grenzbereich der Fassadenoffsets. Wie sind denn Azimut von Fassade und Sonne, wenn das Problem auftritt? Bei welcher Elevation ist es am stärksten?

Das macht aber m.E. hier keine Sinn, oder ich verstehe es nicht?

Ist nun hoffentlich etwas klarer geworden. So ganz trivial ist es eben leider nicht...

[g0bi]

Dann erinner ich auch mal

[starwarsfan]

Hallo Hartwig,

bin gerade unterwegs. Das muss ich mir in Ruhe zuhause auf dem Dev-System anschauen. Bitte nochmal erinnern falls ich es vergessen sollte...