LBS 19000145 - Beschattungssteuerung-NG

[baumhaus123]

Habe aktuell leider schon wieder ein Problem: Im Wohnzimmer ist soeben der Store auf 100% / 50% gefahren, obwohl es stockfinster draußen ist und die Nach-Dämmerungsposition eigentlich wie immer auf 100 /100 steht. Diese Position wurde auch angefahren, nachdem heute die Helligkeit unter den Schwellwert gesunken ist. Gerade kann ich den Store verfahren, wie ich will, er sperrt sich nicht, da ein Timer läuft, Status ist -6:

Bildschirmfoto 2017-04-19 um 21.57.32.png

Nachdem der Timer nun abgelaufen ist, verhält sich der Baustein wieder normal, also Deaktivierung nach manuellem Verfahren und Anfahren von 100/100 nach Reaktivierung.
Danke fürs Kümmern!

[baumhaus123]

Hi Yves,
habe eben bei Status -1 das Projekt aktiviert, da ist der Behang bisher immer hochgefahren. Mit RC4 bleibt er nun wie konfiguriert auf Höhe 100, vielen Dank für den Fix!

Hi Yves,
leider muss ich meine Aussage relativieren. Ich habe eben das Projekt aktiviert, Raffstore war zuvor korrekterweise auf 100%/50% Durchsichtsposition, keine Beschattung aktiv. Nach Aktivierung sind nun die Storen hochgefahren und ich bekomme sie auch nicht runter, ohne den Baustein zu deaktivieren. Hier die aktuellen Settings:
Bildschirmfoto 2017-04-19 um 19.57.33.png

Zweites Thema, das mir aufgefallen ist: Vor Projektaktivierung waren in einem Zimmer zwei Bausteine inaktiv, nach Projektaktivierung sind diese wieder aktiviert worden. Ist das so gewollt?

[starwarsfan]

Hi Nico

Punkt1: Wenn ich die Position, der Raffstores um mehr als 8% (Manueller Eingriff) verändere, bleibt der Baustein AN.

Funktioniert wie gewünscht hier bei mir!? Relevant ist die Änderung gegenüber der vom Baustein ermittelten Position! Also wenn der auf 100% steht, wird er sich bei 8% Toleranz erst bei 91% deaktivieren.

Punkt2: Wenn bei einem guten Wetter (Beschattung AUS) das Raffstore auf Position 0% steht und ich die Sperre AN mache (Öffnen der Tür), fährt er die Position der Sperre an. Macht meiner Meinung nach keinen Sinn oder was spricht für dieses Verhalten?

Das habe ich schon mehrfach erklärt. Die Sperre hat mit dem restlichen Verhalten des Bausteines nichts zu tun. Wird der Baustein gesperrt, wird die Sperrposition angefahren. Das wird sich auch nicht ändern, da diese Funktion genau dafür da ist und der Sperr-Eingang vor jeglicher Status-Logik ausgewertet wird.

Wer das nicht will, kann den Baustein deaktivieren. Dann bleibt der Behang dort wo er sich zu diesem Zeitpunkt befindet.

Punkt3: Wenn ich innerhalb der Dämmerungszeit den Baustein aktiviere fährt auch nicht mehr auf die Dämmerungseinstellungen sondern auf Position 0%, ich würde erwarten das die Raffstores dann auch 100% fahren.

Kann ich aus diesen Angaben nicht nachvollziehen. Was genau hast Du zu welchem Zeitpunkt gemacht? Wie waren dabei die Eingänge des Bausteines belegt? Bitte Screenshots dazu machen!

[Teutone]

Ich habe heute etwas die Beschattung beobachtet. Mein Fazit: Verhalten war gefühlt schlechter als bei den Vorgängerversionen.

Punkt1: Wenn ich die Position, der Raffstores um mehr als 8% (Manueller Eingriff) verändere, bleibt der Baustein AN.

Punkt2: Wenn bei einem guten Wetter (Beschattung AUS) das Raffstore auf Position 0% steht und ich die Sperre AN mache (Öffnen der Tür), fährt er die Position der Sperre an. Macht meiner Meinung nach keinen Sinn oder was spricht für dieses Verhalten?

Punkt3: Wenn ich innerhalb der Dämmerungszeit den Baustein aktiviere fährt auch nicht mehr auf die Dämmerungseinstellungen sondern auf Position 0%, ich würde erwarten das die Raffstores dann auch 100% fahren.

Punkt4: Wenn ich jetzt meine Tür öffne und schließe (Sperre auf AN beim Öffnen), fährt er die Sperrposition an, obwohl die Sperre wieder auf 0 steht.

[starwarsfan]

Hi Matthias

Mit RC4 bleibt er nun wie konfiguriert auf Höhe 100, vielen Dank für den Fix!

Cool, danke für das Feedback.

[baumhaus123]

3.3.RC4 (2017-04-16)

• (...)
• Aktueller Status E11 wird nun immer ausgewertet, nicht nur beim ersten Lauf nach Edomi-Neustart. Ist E11 leer, wird beim ersten Lauf von NEUTRAL ausgegangen und bei allen weiteren Laeufen der intern gespeicherte Status vom letzten Lauf des LBS verwendet.

Hi Yves,
habe eben bei Status -1 das Projekt aktiviert, da ist der Behang bisher immer hochgefahren. Mit RC4 bleibt er nun wie konfiguriert auf Höhe 100, vielen Dank für den Fix!

[Teutone]

super! Morgen wird getestet;-)

[starwarsfan]

Hallo und frohe Ostern miteinander,

hier als kleine Osterüberraschung die 3.3.RC4:

3.3.RC4 (2017-04-16)

• Handling der Sperre korrigiert. Ist der LBS gesperrt, kann er nur noch via E1 oder E2 direkt getriggert werden. Alle anderen Trigger werden ignoriert.
• Aktueller Status E11 wird nun immer ausgewertet, nicht nur beim ersten Lauf nach Edomi-Neustart. Ist E11 leer, wird beim ersten Lauf von NEUTRAL ausgegangen und bei allen weiteren Laeufen der intern gespeicherte Status vom letzten Lauf des LBS verwendet.

3.3.RC3 (2017-04-13)

• Fehler beim Uebergang von Daemmerungshandling zu Beschattungshandling korrigiert

3.3.RC2 (2017-04-12)

• Fehler im Daemmerungshandling korrigiert

3.3.RC1 (2017-04-12)

• 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
• Lamellenwinkelberechnung korrigiert
• Trigger-Eingang E2 implementiert
• Baustein-Reaktivierung ueberarbeitet

[starwarsfan]

- während der Dämmerung darf "Beschattung ein/aus" nichts auslösen
- während der Sperre darf nichts passieren

So, ist in der nächsten Version korrigiert.

[starwarsfan]

Hi

ich habe Version 3.3 RC3 gleich mal für die Kinderzimmer installiert und muss feststellen, dass das mit der Sperre leider nicht richtig arbeitet:

Hm...

18:42 Sperre an, die Rollos fahren auf die gewünschte Sperrposition - super!
20:18 Dämmerung - die gesperrten Rollos bleiben wo sie sollen - super!

OK, bis hierhin gut.

um 20:49 es kommt bei mir ein Update der Außentemperatur, daraus errechne ich "Beschattung ist nötig = 0" und schreibe auf den Eingang E40 eine 0. Zu diesem Zeitpunkt ist bereits Dämmerung und trotz Sperre sind die Rollos hochgefahren - das ist ungünstig!

Mit hochgefahren meinst Du, sie sind auf die Position von E48/E49, also nach Beschattung gefahren, ja? Das ist auf jeden Fall ein Bug, konnte ich eben hier nachstellen.

Ich sehe folgende Fehler:
- während der Dämmerung darf "Beschattung ein/aus" nichts auslösen
- während der Sperre darf nichts passieren

Korrekt, so sollte es sein.

Ich hoffe das ist genau genug damit man das Problem nachvollziehen kann?

Ja ist es, siehe oben.

Ich bin dran, danke für's Feedback!

[schobi]

ich habe Version 3.3 RC3 gleich mal für die Kinderzimmer installiert und muss feststellen, dass das mit der Sperre leider nicht richtig arbeitet:

18:42 Sperre an, die Rollos fahren auf die gewünschte Sperrposition - super!
20:18 Dämmerung - die gesperrten Rollos bleiben wo sie sollen - super!

um 20:49 es kommt bei mir ein Update der Außentemperatur, daraus errechne ich "Beschattung ist nötig = 0" und schreibe auf den Eingang E40 eine 0. Zu diesem Zeitpunkt ist bereits Dämmerung und trotz Sperre sind die Rollos hochgefahren - das ist ungünstig!


Ich sehe folgende Fehler:
- während der Dämmerung darf "Beschattung ein/aus" nichts auslösen
- während der Sperre darf nichts passieren

Ich hoffe das ist genau genug damit man das Problem nachvollziehen kann?

[starwarsfan]

Hi

Dass die Sperre auch bei inaktiven Status wirkt, mag ja noch Sinn machen...aber dass die Sperrposition auch dann zieht, ist meiner Meinung nach schade.

Es gibt keinen "inaktiven" Status, da der LBS sich immer in irgendeinem Status befindet.

Wäre es nicht möglich, über einen Parameter zu definieren, ob die Sperrposition nur bei aktiven Status wirkt?
Oder einfach (um nicht einen weiteren Eingang zu verschwenden)...gibt man die Sperrpositionen und Sperrwinkel als Minuszahlen an, wirken sie NUR bei aktiven Status. Positive Zahlen wirken wie jetzt (auf alle Stati, auch inaktiv). Wäre zumindest eine Idee und gäbe gewisse Flexibilität, ohne den Baustein äusserlich aufzublähen. (Sozusagen ein hidden Feature) ;-)

Nein, das macht in dieser Form überhaupt keinen Sinn und würde die Logik des LBS nur völlig unnötig aufblasen. Ich seh' schon den nächsten kommen, der dann für die Dämmerung wieder anderes Verhalten der Sperre haben will. Nein, das wird es nicht geben.

Der springende Punkt ist, dass der Beschattungs-LBS nicht dafür gedacht ist, sämtliche mehr oder weniger sinnvollen Sonderfälle abzuhandeln. Der Beschattungs-LBS soll und wird sich ausschliesslich um die Steuerung des Behangs kümmern. Das was Du willst wird über Vorschaltbausteine resp. über den noch kommenden Beschattungsparameter-LBS abgehandelt werden können, siehe den entsprechenden Thread hier. Mit einem Vorschalt-LBS werden nun je nach gerade gewünschtem Anwendungsfall die Eingänge des Beschattungs-LBS modifiziert, so dass dieser aus seiner Sicht weiter seine Arbeit verrichten kann.

[rdeckard]

Nein, ist es nicht. Der Sinn der Sperre ist, den Baustein zu sperren, egal was dieser gerade macht oder in welchem Zustand er sich befindet.

ok, musste 3x lesen, bis ich den feinen Unterschied zu mir erkannt habe.
D.h. die Sperrposition wird IMMER angefahren, auch wenn der Baustein eigentlich inaktiv ist (keine Beschattung, Jalousien sind hochgefahren). Das ist natürlich (zumindest für mich) sehr doof.
Dass die Sperre auch bei inaktiven Status wirkt, mag ja noch Sinn machen...aber dass die Sperrposition auch dann zieht, ist meiner Meinung nach schade.
Wäre es nicht möglich, über einen Parameter zu definieren, ob die Sperrposition nur bei aktiven Status wirkt?
Oder einfach (um nicht einen weiteren Eingang zu verschwenden)...gibt man die Sperrpositionen und Sperrwinkel als Minuszahlen an, wirken sie NUR bei aktiven Status. Positive Zahlen wirken wie jetzt (auf alle Stati, auch inaktiv). Wäre zumindest eine Idee und gäbe gewisse Flexibilität, ohne den Baustein äusserlich aufzublähen. (Sozusagen ein hidden Feature) ;-)

[starwarsfan]

N'abend miteinander

Hmm...ist die Beschattung aktiv, dann unterbricht die Sperre sie. Das ist doch der Sinn einer Sperre.

Nein, ist es nicht. Der Sinn der Sperre ist, den Baustein zu sperren, egal was dieser gerade macht oder in welchem Zustand er sich befindet.

Wird die Sperre wieder aufgehoben, wird die Beschattung fortgesetzt. Nur, wenn die Beschattung eigentlich bereits inaktiv wurde, weil während der Sperre die Werte unterschritten wurden, dann sollte doch nach der Sperraufhebung nichts mehr passieren (Beschattung ist ja inaktiv). So mein Verständnis.

Wie das zusammen hängt und dass das nicht so einfach zu lösen ist, habe ich doch in #315 bereits geschrieben.

Könnte es daran liegen, dass während der Sperre A10 aktiv war und dies dann bei E11 als Initialwert mitgegeben wird? Ein Loop sozusagen...oder wird E11 wirklich nur bei Neuaktivierung ausgelesen und nicht beim Zurückkehren aus einer Sperre?

E11 wird nur bei Neuaktivierung ausgelesen. Aber das ist ein super Hinweis! Ich muss mal überlegen, welche Auswirkungen es hat bzw. haben könnte, wenn man den aktuellen Status immer aus E11 nimmt und nicht intern merkt. Rein theoretisch sollte man dann den Baustein jederzeit in einen beliebigen Status versetzen können, vom welchem beim nächsten Lauf des LBS dann ausgegangen wird. Gute Idee!

[rdeckard]

Hmm...ist die Beschattung aktiv, dann unterbricht die Sperre sie. Das ist doch der Sinn einer Sperre. Wird die Sperre wieder aufgehoben, wird die Beschattung fortgesetzt. Nur, wenn die Beschattung eigentlich bereits inaktiv wurde, weil während der Sperre die Werte unterschritten wurden, dann sollte doch nach der Sperraufhebung nichts mehr passieren (Beschattung ist ja inaktiv). So mein Verständnis.

Könnte es daran liegen, dass während der Sperre A10 aktiv war und dies dann bei E11 als Initialwert mitgegeben wird? Ein Loop sozusagen...oder wird E11 wirklich nur bei Neuaktivierung ausgelesen und nicht beim Zurückkehren aus einer Sperre?