LBS 19000707 - Beschattungssteuerung-Rollo

[starwarsfan]

Hi

Danke, das wars. Neuer Aktor sendet die Werte anders. Vielen dank dir.

Wenn das ein neuer Aktor ist, dann hast Du nicht zufällig den falschen DPT-Subtyp eingestellt? Das sieht verdächtig nach 5.004 oder höher aus, sollte aber 5.001 sein.

[elkomaster91]

Ok, dann liegt es sehr wahrscheinlich daran, dass Du auf E9 keinen %-Wert sondern dessen Int-Entsprechung einspeisst. Dort liegt ja der Wert 230 an, was in etwa 90% von 255 entspricht. Somit gehört eine Division durch 2.55 vor den Eingang E9.

Danke, das wars. Neuer Aktor sendet die Werte anders. Vielen dank dir.

[starwarsfan]

Ok, dann liegt es sehr wahrscheinlich daran, dass Du auf E9 keinen %-Wert sondern dessen Int-Entsprechung einspeisst. Dort liegt ja der Wert 230 an, was in etwa 90% von 255 entspricht. Somit gehört eine Division durch 2.55 vor den Eingang E9.

[elkomaster91]

Klar, ein Klassiker, war schon sehr oft Thema hier, die Suche hätte Dir das auch gezeigt...

Das ist ja genau das Problem. Der Rollladen ist seit mittags zu. Aufgefallen ist es mir weil er nicht mehr losfährt, wenn die Sonne weg ist. Hatte sogar extra vorher die Sperre zurückgesetzt und es kam einfach wieder.

Gruß

[starwarsfan]

Hallo Hardi

Hallo, kann mir jemand sagen, warum der Baustein zwischen diesen beiden Schritten sich sperrt. Der Rollladen ist ganz sicher nicht gefahren.

Klar, ein Klassiker, war schon sehr oft Thema hier, die Suche hätte Dir das auch gezeigt...

Deswegen:

2025-07-30 17:08:56;757721;876;INFO: ;LBS disabled through external height change (230 vs 82/98)

Das passiert entweder, wenn der Behang manuell verfahren wird oder der Aktor noch während der Bewegung den aktuellen Stand zurück meldet. In diesem Fall musst Du vor die Positionseingänge einen Verzögerer schalten und auf einen Wert einstellen, welcher der maximalen Fahrzeit Deines Behangs entspricht. Damit kommt die Positionsrückmeldung erst dann zum LBS "durch", wenn diese auch der angefahrenen Position entspricht.

[elkomaster91]

Hallo, kann mir jemand sagen, warum der Baustein zwischen diesen beiden Schritten sich sperrt. Der Rollladen ist ganz sicher nicht gefahren.

2025-07-30 17:08:00;181619;876;INFO: ;===== === = LBS was triggered (v0.7) = === ==========================================
2025-07-30 17:08:00;181653;876;INFO: ;<Input>: <Refreshed>|<Value>
2025-07-30 17:08:00;181751;876;INFO: ;Trigger: 0| Trigger changed output: 0| Brightness: 0|14336 Brightness dawn: 0|9920 Elevation: 1|37.163684223426 Azimut: 0|253.81625194513 Lockstate: 0|0 Lockstate with position: 0|0 Internal timer: 1
2025-07-30 17:08:00;181821;876;INFO: ;===== === = Elevation refreshed, starting LBS = === ==================================
2025-07-30 17:08:00;182852;876;INFO: ;UpdateAlways == false, previous value of A5 equals new value 0, skipping update
2025-07-30 17:08:00;182915;876;INFO: ;No lock state detected, set explicit to unlocked
2025-07-30 17:08:00;183258;876;INFO: ;===== === = Brightness, Elevation or Azimut changed = === ====================
2025-07-30 17:08:00;184063;876;INFO: ;=== Validating input values... ===
2025-07-30 17:08:00;184139;876;INFO: ;=== Finished validation of input values ===
2025-07-30 17:08:00;184170;876;INFO: ;=== Checking if facade is in sun... ===
2025-07-30 17:08:00;184478;876;INFO: ;UpdateAlways == false, previous value of A1 equals new value 1, skipping update
2025-07-30 17:08:00;184542;876;INFO: ;Virtual depth and height of sun position in 90° to the facade: 0.97364363541996, 0.75804278634414, effective Elevation: 37.903000645917
2025-07-30 17:08:00;185295;876;INFO: ;UpdateAlways == false, previous A9: 38.059890498288, updating with 37.903000645917
2025-07-30 17:08:00;185899;876;INFO: ;UpdateAlways == false, previous value of A8 equals new value 1, skipping update
2025-07-30 17:08:00;185944;876;INFO: ;=== Finished facade check, real azimut 253.81625194513° and facade at 267° -> IN SUN (from 177° to 357°), effective elevation 37.903000645917° for given elevation of 37.163684223426° -> in min-max-range (5-80) ===
2025-07-30 17:08:00;185977;876;INFO: ;=== Calculating shutter state... ===
2025-07-30 17:08:00;186209;876;INFO: ;Handling current shutter state SHADOW_HORIZONTAL_NEUTRAL_TIMER_RUNNING (4)
2025-07-30 17:08:00;186250;876;INFO: ;Facade is in sun
2025-07-30 17:08:00;186682;876;INFO: ;Updating outputs out of SHADOW_HORIZONTAL_NEUTRAL_TIMER_RUNNING with previous values if necessary
2025-07-30 17:08:00;187092;876;INFO: ;positionShutter(...), Value for height: 90%
2025-07-30 17:08:00;187561;876;INFO: ;UpdateAlways == false, previous value of A2 equals new value 1, skipping update
2025-07-30 17:08:00;187686;876;INFO: ;UpdateAlways == false, previous value of A3 equals new value 90, skipping update
2025-07-30 17:08:00;187916;876;INFO: ;UpdateAlways == false, previous value of A4 equals new value 230, skipping update
2025-07-30 17:08:00;188395;876;INFO: ;positionShutter(...) for height 90% finished
2025-07-30 17:08:00;188462;876;INFO: ;Storing current shutter state 4 and updating output if necessary
2025-07-30 17:08:00;189259;876;INFO: ;UpdateAlways == false, previous value of A7 equals new value 4, skipping update
2025-07-30 17:08:00;189671;876;INFO: ;===== === = LBS finished = === ===============================================
2025-07-30 17:08:00;189711;876;INFO: ;===
2025-07-30 17:08:00;189732;876;INFO: ;===
2025-07-30 17:08:56;755904;876;INFO: ;================================================= =====================================
2025-07-30 17:08:56;755976;876;INFO: ;===== === = LBS was triggered (v0.7) = === ==========================================
2025-07-30 17:08:56;756012;876;INFO: ;<Input>: <Refreshed>|<Value>
2025-07-30 17:08:56;756139;876;INFO: ;Trigger: 0| Trigger changed output: 0| Brightness: 0|14336 Brightness dawn: 0|9920 Elevation: 0|37.163684223426 Azimut: 0|253.81625194513 Lockstate: 0|0 Lockstate with position: 0|0 Internal timer: 1
2025-07-30 17:08:56;757395;876;INFO: ;UpdateAlways == false, previous A5: 0, updating with 1
2025-07-30 17:08:56;757721;876;INFO: ;LBS disabled through external height change (230 vs 82/98)
2025-07-30 17:08:56;757963;876;INFO: ;===== === = Timer running, starting LBS = === ========================================
2025-07-30 17:08:56;758054;876;INFO: ;===== === = LBS locked, disabling update of position outputs = === ===================
2025-07-30 17:08:56;758238;876;INFO: ;=== Validating input values... ===
2025-07-30 17:08:56;758281;876;INFO: ;=== Finished validation of input values ===
2025-07-30 17:08:56;758301;876;INFO: ;=== Checking if facade is in sun... ===
2025-07-30 17:08:56;758492;876;INFO: ;UpdateAlways == false, previous value of A1 equals new value 1, skipping update
2025-07-30 17:08:56;758531;876;INFO: ;Virtual depth and height of sun position in 90° to the facade: 0.97364363541996, 0.75804278634414, effective Elevation: 37.903000645917
2025-07-30 17:08:56;758716;876;INFO: ;UpdateAlways == false, previous value of A9 equals new value 37.903000645917, skipping update
2025-07-30 17:08:56;758899;876;INFO: ;UpdateAlways == false, previous value of A8 equals new value 1, skipping update
2025-07-30 17:08:56;758934;876;INFO: ;=== Finished facade check, real azimut 253.81625194513° and facade at 267° -> IN SUN (from 177° to 357°), effective elevation 37.903000645917° for given elevation of 37.163684223426° -> in min-max-range (5-80) ===
2025-07-30 17:08:56;758954;876;INFO: ;=== Calculating shutter state... ===
2025-07-30 17:08:56;759140;876;INFO: ;Handling current shutter state SHADOW_HORIZONTAL_NEUTRAL_TIMER_RUNNING (4)
2025-07-30 17:08:56;759180;876;INFO: ;Facade is in sun
2025-07-30 17:08:56;759483;876;INFO: ;Updating outputs out of SHADOW_HORIZONTAL_NEUTRAL_TIMER_RUNNING with previous values if necessary
2025-07-30 17:08:56;759932;876;INFO: ;positionShutter(...), Value for height: 90%
2025-07-30 17:08:56;760035;876;INFO: ;LBS locked, not updating outputs
2025-07-30 17:08:56;760390;876;INFO: ;positionShutter(...) for height 90% finished
2025-07-30 17:08:56;760426;876;INFO: ;Storing current shutter state 4 and updating output if necessary
2025-07-30 17:08:56;760921;876;INFO: ;UpdateAlways == false, previous value of A7 equals new value 4, skipping update
2025-07-30 17:08:56;761233;876;INFO: ;===== === = LBS finished = === ===============================================​

[Marino]

Intern kann die GMA das ja anders regeln, aber sie gibt es halt so an den KO’s aus.

Ich habe die so angeschlossen.
Zuvor in meiner Wohnung hatte ich mehrere zusammen geschaltet. Da hatte ich dann 2x das Problem, dass einer der Sensoren nicht geschaltet hat und ich musste dann mit Magnet suchen, welcher das ist. Einmalige Sache, Sensoren neu ausrichten, ich weiß.

Dann hat der Fensterbauer hier im Haus die Sensoren eingebaut. Falsch herum, nicht nach Vorgabe die Öffnung erstellt zum verstellen, Kabel zu kurz und und und. Musste dann gedreht und nachbearbeitet werden an der Hälfte der Fenster.
Daher wollte ich nicht mehr viel zusammen schalten und da es auch nur 2 Fenster mit 2 Flügeln gibt, habe ich die einfach einzeln angeschlossen. Waren dann halt 4 Eingänge mehr.
Da die GMA eine extra Verteilung hat, könnte das zur Not aber auch Icon veändert werden, falls es notwendig sein sollte.

[starwarsfan]

Hallo Nils

Je Fenster gibt es zwei Sensoren. Einer überwacht die Verriegelung, der andere an der Unterseite die Flügelöffnung.
Geschlossen heißt also, dass beide Sensoren kein Signal haben.

Es gibt natürlich eine ganze Menge verschiedener Kombinationen und Konstellationen, wie sich die beiden Fensterstatus überwachen lassen...

Die Gefahrenmeldeanlage (ABB GM/A8.1) sendet die angeschlossenen Sensoren auf den KNX-Bus. Dass der unsichere Zustand eine 1 und keine 0 ist, kann nicht eingestellt werden. Würde man sonst ja auch eher machen. Kabelbruch = Öffnung = nicht sicher.

Ok, dann ist deren Herangehensweise wohl offen = Gefahr = 1

In der Logik oben ist gleichzeitig berücksichtigt, dass 2 Flügel vorhanden sind und eine Fenstermarkise und diese auch in Öffnungsposition fährt, wenn das andere Fenster noch geschlossen ist.

Also unterscheidet die GMA zwischen dem rechten und dem linken Flügel? Warum? Wurde einfach so gemacht oder hat das einen tieferen Sinn? Denn eigentlich ist es ja ausreichend, die beiden Reeds jeweils in Reihe zu schalten.

[Marino]

Je Fenster gibt es zwei Sensoren. Einer überwacht die Verriegelung, der andere an der Unterseite die Flügelöffnung.

Geschlossen heißt also, dass beide Sensoren kein Signal haben.
Drehe ich den Griff aus der Verschlussposition ca. 5-10° heraus, hat der Verriegelungssensor eine 1, da entriegelt wurde. Ob er gerade eben nur nicht vollständig verriegelt ist, auf Öffnungs- oder Kippposition steht, weiß ich damit nicht. Es kann also noch geschlossen sein, aber auch zugeweht oder gekippt.

Löst der Sensor unten aus, wurde das Fenster geöffnet. Das geht zwangsweise einher mit dem anderen Sensor, denn ohne entriegelt zu haben, kann ich nicht öffnen.

Hat also der nur Verriegelungssensor ein Signal, wird wohl das Fenster wohl gekippt sein. Haben beide Sensoren ein Signal, ist das Fenster entriegelt und nicht im Rahmen.

Die Gefahrenmeldeanlage (ABB GM/A8.1) sendet die angeschlossenen Sensoren auf den KNX-Bus. Dass der unsichere Zustand eine 1 und keine 0 ist, kann nicht eingestellt werden. Würde man sonst ja auch eher machen. Kabelbruch = Öffnung = nicht sicher.

In der Logik oben ist gleichzeitig berücksichtigt, dass 2 Flügel vorhanden sind und eine Fenstermarkise und diese auch in Öffnungsposition fährt, wenn das andere Fenster noch geschlossen ist.



Momentan lasse ich übrigens das Positionssignal nur durch, wenn der Behang nicht verfährt. Steht er anschließend, wird die Position durchgereicht und 2s später wird einmalig E2 getriggert. So funktioniert es augenscheinlich, aber irgendwann sperrt der LBS dann doch. Und sei es nach 5-10x hin und her fahren. 2s reichen da wohl nicht. Muss ich später mal testen, aber ersteinmal muss ich meine Tochter abholen...

[starwarsfan]

Klar, macht Sinn.

Da würde mich interessieren, wie genau das hardwareseitig am Fenster aussieht. Also woher genau kommen die Statusmeldungen, welche Du in Deinem zweiten Screenshot verarbeitest?

[Marino]

Danke schon einmal für Deine Hilfe.

Es liegt anscheinend zum Teil daran, dass beim Drehen des Griffes bereits AJAR gesendet wird, bevor man es schafft, den Flügel aufzuziehen. Dadurch sperrt sich der LBS. Verzögere ich das Umschalten auf AJAR, geht er nicht in Störung, da nicht CLOSED>AJAR>OPEN gesendet wird, bevor der Behang überhaupt fährt, wodurch er 100%>90%>65% fährt, sondern direkt CLOSED>OPEN, also 100%>65%.

AJAR wird momentan 2s verzögert. Das alleine ist nun überhaupt nicht schlimm. Doof ist nur noch, dass eine Änderung Flügel-/Griffposition während des Verfahrens den LBS sperrt, was nicht selbsterklärend für die Benutzer ist und eine anschließende Handlung bedarf.

Ich werde dann da noch weiter suchen müssen, was ich machen kann, damit alles ohne große Verzögerung und trotzdem sicher funktioniert. Wenn der LBS sich durch einen neuen Befehl sperrt, wenn dieser beim verfahren kommt, muss der neue Befehl halt verzögert werden, bis nicht mehr gefahren wird. Also Positionsänderung nur bei Stillstand weitergeben.


Viele Grüße
Nils

[Marino]

Wenn ich geöffnet 4-5 Sekunden warte und dann verriegel (E9 ist dann schon 65%), sperrt er auch. Wenn er runter fährt und ich öffne wieder, sperrt er aber nicht und fährt wieder auf 65% zurück.

Ich habe dann das Fenster geöffnet und er fährt (ca. 6s) von 100% auf 65%. Dann kam der Status 65% auf E9. Anschließend habe ich 60s gewartet und das Fenster dann verriegelt. LBS sperrt und fährt nicht mehr.

Ich teste mal mit Verzögerungen weiter und melde mich später nochmal. Der LBS scheint sich beim hoch fahren zu sperren, weil beim Öffnen kurzzeitig AJAR anliegt, bevor der Flügel geöffnet wird. Fahren tut er dann aber noch in die OPEN-Position...

[Marino]

Dachte ich auch erst, aber ich sende die Position erst am Fahrtende. Bis dahin ist es also noch die vorherige Position.
Und sperren tut der LBS ja auch, wenn ich in den Positionen warte, die aktuelle Position also auch am LBS anliegt und dann z.B. verriegel. Bei den 3 Szenarien oben habe ich nur bei 1 während der Fahrt die Fensterposition geändert. Bei 2 & 3 hingegen bewegte sich der Behang nicht mehr. Das Beispiel (Diagnose) oben zeigte ja, dass er bei 65% (OPEN) stand, der LBS den Wert kannte und er beim Verriegeln dann sich gesperrt hat.
Aus dem Grund hatte ich E9 dann nicht mehr in Verdacht, da der den aktuellen Wert beim Erreichen der Position bekam.


Bildschirmfoto 2024-07-29 um 13.00.20.png

[starwarsfan]

Hi

Ich gehe schwer davon aus, dass das Problem die Rückmeldung Deines Aktors ist, welche bereits zur Verfahrzeit beim Baustein ankommt. Das ist bei derartigen Fällen wie Deinem hier so gut wie immer so.

Du musst in dem Fall vor E9 einen Verzögerer einbauen und diesen mindestens auf die Zeit einstellen, welche das Verfahren des Behangs von ganz offen auf ganz zu dauert.

[Marino]

Tatsächlich untergegangen.

1155 schalten 1122 1/0 und senden damit auf iKO 1123 eine 100 oder 150000. Könnte direkt verbunden sein, ist aber noch historisch, da früher noch was zwischen den Logiken war.
Normalerweise beginnt dann Dämmerung <100 Lux, wenn ich es Tagsüber nutzen machte, ist es ein Wert, der Höher liegt, als die Wetterstation liefert, um es zu erzwingen. Dann hatte ich E40 jeweils in Edomi live auf 1 und 0 gesetzt, zum testen. Normalerweise ist E40=1.
Bildschirmfoto 2024-07-29 um 12.36.55.png


Hier die Fenster. Da es zwei Flügel sind, wird unterschieden, ob CLOSED, AJAR oder OPEN, was hier an den Ausgangsboxen geschrieben wird auf das iKO 2635.
Bildschirmfoto 2024-07-29 um 12.36.46.png





Bausteinsperre ist hier ein einmalig genutztes, Remanentes iKO 2643.
Bildschirmfoto 2024-07-29 um 12.36.24.png




Bildschirmfoto 2024-07-29 um 12.36.32.png