LBS 19000145 - Beschattungssteuerung-NG

[starwarsfan]

Hi

Schöner wäre natürlich eine beeinflussbare Dynamik für die Berechnung wie bei einer Dimmkurve.

Jo, das ist klar. Die Frage ist aber nach wie vor die, wie genau die Kurve beeinflusst werden soll und vor allem, wie ich das anstelle, dass das auch noch verständlich ist, was da genau passiert resp. was man dort ggf. konfigurieren kann.

[crewo]

starwarsfan guter Hinweis mit dem Abstand, ich habe definitiv den technischen Abstand bei mir drin (80er Lamellen, 70er Abstand). Ich hatte da aber auch schon einmal mit den Werten gespielt und soweit ich mich erinnere war bei kleinerem Abstand die Auswirkung in den Grenzbereichen (vormittags und nachmittags) schlechter. D.h. es kam noch mehr Sonne in den Raum. Momentan fahre ich mit dem 70er ganz gut, bei der Ost und West Seite habe ich zusätzlich einen fixen Offset von 5° - das ist vom Ergebnis nun schon recht gut. Schöner wäre natürlich eine beeinflussbare Dynamik für die Berechnung wie bei einer Dimmkurve. Probleme macht für mich nur der Bereich wenn die Sonne < ca. 45° hat, hier reicht der Lamellenwinkel vom LBS nicht mehr aus, um eine Blendung zu verhindern.

[starwarsfan]

An alle mit Problemen bzgl. der Lamellennachführung und doch hindurchscheinender Sonne:

Bitte prüft, ob Eure Settings bzgl. Lamellenbreite und Lamellenabstand wirklich richtig sind! Es geht insbesondere nicht darum, welchen technischen Abstand die Lamellen haben, sondern wie der Abstand der Lamellen hinsichtlich Durchsicht ist! Es kommt also explizit auf den roten Wert in folgender Skizze an:
2017-03-26_Lamellenabmessungen.png


Ich werde die Doku dahingehend ergänzen.

Genaugenommen wird der rote Wert mit zunehmender Verstellung der Lamellen immer kleiner, bis er bei komplett geschlossenen Lamellen 0 ist. Wie sich das allerdings abbilden lässt, bin ich noch am grübeln...

[starwarsfan]

Hallo Nico

Welchen Faktor meinst du? Kann es sein das du meine Excel-Datei mit der von crewo verwechselst?

Ich meine die Excel-Datei am Posting #272 von Dir hier in diesem Thread. Also nehme ich an, die Datei ist von Dir!? Die Datei von crewo hat gar keine Formeln enthalten sondern nur fixe Werte...

Mit "die" meine ich die Lichstreifen. Wenn das Raffstore komplett runter gefahren ist, habe ich noch Lichtstreifen auf dem Boden.

Ah ok. Der Lichtstreifen im Sinne des Bausteines ist etwas anderes und wird via E31/E32 konfiguriert.

[Teutone]

Hallo Nico
Soweit, so gut. Allerdings kann ich nicht so recht nachvollziehen, was Du darin mit diesem Faktor bezweckst!? In der Tabelle ist in einem gewissen Range die Formel eine andere. Warum? Und was genau berechnest Du da?

starwarsfan Welchen Faktor meinst du? Kann es sein das du meine Excel-Datei mit der von crewo verwechselst? In meiner Tabelle habe ich nur deine Funktion nachgebaut, um die Ergebnisse nachvollziehen zu können!

Was meinst Du mit "die"? Wer soll bei 100% Behanghöhe nicht da sein? Und welche Rolle spielt an dieser Stelle der Lichtstreifen? Der Lichtstreifen hat mit der Winkelberechnung überhaupt nichts zu tun!?

Mit "die" meine ich die Lichstreifen. Wenn das Raffstore komplett runter gefahren ist, habe ich noch Lichtstreifen auf dem Boden.

Kann es sein, dass Du hier zwei verschiedene Dinge miteinander vermischst?

Ich hoffe nicht ;-)

Der Offset mit ZSU wird wohl das beste sein.

[starwarsfan]

Hallo Nico

Ich habe mal ein Tool bzw: Exceltabelle gemacht um die Werte nachvollziehen zu können.
Die Excel macht genau das, was deine Funktion function LB_LBSID_calculateShutterAngle($E) macht.

Soweit, so gut. Allerdings kann ich nicht so recht nachvollziehen, was Du darin mit diesem Faktor bezweckst!? In der Tabelle ist in einem gewissen Range die Formel eine andere. Warum? Und was genau berechnest Du da?

Ich bin bei dir, allerdings ist meine Erwartungshaltung dann, wenn ich den Lichtsreifen auf 0 setze, das die dann auch bei 100% Behanghöhe auch nicht da sind.

Was meinst Du mit "die"? Wer soll bei 100% Behanghöhe nicht da sein? Und welche Rolle spielt an dieser Stelle der Lichtstreifen? Der Lichtstreifen hat mit der Winkelberechnung überhaupt nichts zu tun!?

In der Exceltabelle habe ich mal ein Beispiel blau markiert. da kommt 54% raus, benötige aber ca. 65-68 % um keine Lichtstreifen zu haben.

Kann es sein, dass Du hier zwei verschiedene Dinge miteinander vermischst?

Ich versuche damit uns allen zu helfen, indem man mit der Berechnung etwas herum spielen kann. Vielleicht hilft es dir auch.

Ich hoffe es, bis jetzt jedoch noch nicht so recht. Vielmehr möchte ich der Sache auf den Grund gehen, warum die Berechnung in den Grenzbereichen nicht sauber funktioniert, da das eigentlich nicht sein kann. Mit irgendwelchen Faktoren das Resultat zu modifizieren, löst vermutlich nicht das eigentliche Problem.

[starwarsfan]

N'abend miteinander,

sodele, die neue Version des Bausteins ist quasi fertig. Nach meinen Tests sehen die Change-Notes aktuell so aus:

3.3 (2017-04-??):

• Status-Namen normalisiert
• Zwei neue Status eingefuehrt: SHADOW_NEUTRAL und DAWN_NEUTRAL fuer den Zustand jeweils nach Beschattung bzw. nach Daemmerung
• Min-Max-Elevation wird korrekt ausgewertet
• Eingang E13 Sperre repariert
• Ausgang A2 Beschattungsstatus repariert

Nun schau' ich mir aber nochmal die letzten Postings hier im Thread an, insbesondere das Problem mit der Lamellenwinkelberechnung.

Stay tuned!

[schobi]

Noch ein weiterer Testcase bei dem die Sperre nicht richtig arbeitet (garnicht?)

Wenn die Kinder ins Bett gehen (nachmodus an), dann fahre ich per Sperre den Rollo auf 80% runter.
Dann kommt die Dämmerung und es fährt weiter runter (trotz Sperre)
Früh fährt der Rollo trotz Sperre dann hoch weil die Dämmerung zu Ende ist...

Mal Schaum was eine neue Version bringt!

[starwarsfan]

Hallo und guten Abend miteinander

Du solltest auf jeden Fall die nächste Version abwarten

Genau so ist es. Ich hoffe, dass ich mit dem Refactoring bald so weit bin, eine neue Version zu veröffentlichen. Aktuell bin am Testen des Bausteines mit meiner Dev-Instanz von Edomi.

Die Logik ist relativ komplex geworden

Das wird sich dann hoffentlich wieder entspannen...

[baumhaus123]

Du solltest auf jeden Fall die nächste Version abwarten, die Sperre scheint in manchen Szenarien noch nicht ganz rund zu sein.
Ich habe es bei mir mit Zusatzlogiken folgendermaßen umgesetzt:

• Raffstore an Terrassen-Schiebetür wird grundsätzlich normal beschattet
• Nach Öffnen der Tür wird der LBS deaktiviert. "Automatisch hochfahren" hatten wir auch mal, hat aber schnell genervt, weil wir manchmal lediglich die Katze reinlassen wollen, oder ich möchte mit der Frau durch die geöffnete Tür sprechen etc. Direkt neben der Tür ist ein Taster, mit der dann der Behang gefahren werden kann.
• Wird der Behang bei geöffneter Tür verfahren, so bleibt der Baustein immer inaktiv (Stichwort "Aussperren".
• Nach Schließen der Tür wird wie bei allen anderen Fenstern ein 2-stündiger Timer aktiviert, nach dessen Ablauf der Baustein reaktiviert wird (und dann eben beschattet oder was eben gerade anliegt)
• Ganz wichtig ist, dass nach Öffnen der Tür ein bereits laufender Timer deaktiviert wird, da ansonsten der Timer im Hintergrund weiterläuft und bei offner Türe der Behang schließt. Die Logik ist relativ komplex geworden, da der (re-triggerbare) Timer-Baustein sowohl bei Ablauf der Zeit als auch bei vorzeitiger Deaktivierung eine 0 sendet. Habe das ganze dann mit einer vorgeschalteten Sperre gelöst.

[rdeckard]

OK, dann warten wir mal ab, was Yves noch herzaubert.

Für meine Gartensitzplatztür würde ich gerne den Reed-Kontakt abfragen. Wird die Türe geöffnet, dann soll die Jalousie in die Sperrposition gehen. Das scheint auch zu funktionieren. Wenn ich die Sperre aber wieder aufhebe, passiert nichts. Es wäre gut, wenn die Jalousie sofort wieder in die vorherige Position geht (Winkel ist nicht so wichtig, der könnte auch einfach fix mitgegeben bzw. vom Sperrwinkel übernommen werden). Ich nehme an, dies geht im Moment auch noch nicht?

[vento66]

Der Baustein hat derzeit einen Bug. Setze vor den Helligkeitswerte eine Sperre, und Sperre den Wert mit deinem Sperr KO zusätzlich.

[rdeckard]

Hallo Zusammen

Für meine Dämmerungsschaltung im Schlafzimmer habe ich eine ZSU vorgeschaltet, damit die Jalousie am Morgen nicht raufgeht, wenn ich noch schlafe, obwohl es schon hell genug wäre.
Leider scheint der Baustein nicht auf die ZSU zu reagieren. Sieht jemand einen Fehler in meinen Einstellungen?

dämmerung_zsu.png

Ich habe ein iKO (LBS_Schlafen_Trigger) definiert, welches den Initialwert 1 besitzt. Dieses iKO ist mit E12 der Beschattung verknüpft. Somit sollte standardmässig der Baustein immer laufen (Wert=1).
In der ZSU setze ich den Wert ab 1 Uhr in der Nacht auf 0 und erst ab 10 Uhr Vormittags wieder auf 1. Somit müsste doch der LBS in dieser Zeitspanne aus sein.

Wenn ich aber am morgen vor 10 Uhr aufwache (es ist bereits hell!), so sind die Jalousien schon geöffnet.

Kann es sein, dass der Datentyp Variant nicht geeignet ist? (Ich dachte, gaert hat mal empfohlen, immer Variant zu verwenden.)

Oder hat es etwas mit E1 zu tun, dass der LBS immer läuft?

[hx5]

Hallo Yves,

wenn du da irgendwann dazu kommst, soweit ich das heute rausgefunden habe verhält es sich mit E12 genau so. Er meldet am Ausgang zwar schön das er nicht aktiv ist, berechnet aber munter weiter.
Der will wohl einfach keine Pause machen

Schönes und ruhiges Wochenende

[ak68]

In den nächsten Tagen müsst ihr aber leider damit leben, da ich mitten im Refactoring bin. Mal wieder...

Das werden wir wohl verkraften können ! Danke für Deine Mühe
Andreas