LBS 19000707 - Beschattungssteuerung-Rollo

[crewo]

blakystarwarsfan : Warum nicht einfach den Aktor "richtig" konfigurieren und z.B. das Senden von Positionswerten während der Fahrt zu deaktiveren? Falls das am Aktor nicht geht hat der eventuell ein "Fahrt läuft" Objekt? Dann fände ich es smart den LBS zu erweitern um einen Eingang "Behang fährt", ist der auf 1, wird sämtliche Positionsmelderei ignoriert bis dieser wieder auf 0 ist, dann wird der letzte empfangene Wert für Position verarbeitet (um dem vorzubeugen, dass der Aktor erst die Endposition schickt und erst dann sein Fahrt-Objekt auf 0 stellt.

Sonst kann man das auch einfach mit einer Sperre selbst lösen vor dem LBS! Wäre ja für einen Versuch in 2 min erledigt.

[starwarsfan]

Hi

ich habe den NG Thread durchflügt, konnte aber keine richtige Lösung zu diesem Problem finden. Ein Verhalten des Aktor schliese ich aus da meine aktuellen % Werte nicht von einem Aktor kommen ;-).

Das spielt keine Rolle. Wenn sich die Prozentwerte unterscheiden, sperrt sich der Baustein. Das ist ja explizit so gewünscht.

Zumal vom logischen her eine Verzögerung an E9 die Sache ja noch verschlimmern würde.

Nein, würde sie nicht und tut sie auch nicht, da das von verschiedenen Usern ja so gemacht wird.

Es geschieht doch folgendes:

- an E9 liegt 0(%) an da der Rollo oben ist
- der LBS entscheidet jetzt muss beschattet werden auf z.B. 80% Ergo A3 wird von 0 auf 80 gesetzt
- der Rollo beginnt zu fahren und die aktuellen Prozente werden an E9 geschickt
- der Rolle hat sagen wir bereits die Hälfte der Strecke zurückgelegt (E9 steht auf 40%)
- Plötzlich ändert sich der Lux Wert und der LBS wird getriggert
- also wird A3 mit E9 verglichen und bums ist der LBS gesperrt

wenn das Update von E9 verzögert würde, würde beim triggern durch den Lux Wert trotzdem die Sperre zuschlagen, weil E9 noch auf 0 steht und A3 auf 80

Da hast du einen Denkfehler. Die Idee ist, vor die beiden Positionseingänge jeweils einen Verzögerer zu platzieren, dessen Verzögerung mindestens die maximale Bewegungszeit des Behangs ist. Wird nun der Behang wie von Dir beschrieben bewegt, kommt die Positionsmeldung erst nach Ablauf der maximalen Laufzeit des Behangs zum LBS durch. Der Verzögerer wird durch jeden weiteren Wert neu getriggert, so dass die von Dir geschilderte Situation nicht auftreten kann, da erst nach Ablauf des Verzögerers die Werte zum LBS durch kommen und dann zur Position am entsprechenden Ausgang passen.

Wird der Behang manuell verfahren, wird sich der LBS damit natürlich auch erst nach Ablauf des Verzögerers sperren.

Für mich wäre die einzigste Lösung, wie auch im NG Thread vorgeschlagen, einen Guard Timer einzuführen.
Sprich:
- wird A3 mit einem neuen Wert beschrieben -> startet der Guard Timer
- solange der Guard Timer aktiv ist wird nicht E9 mit A3 verglichen

Da muss ich mal drüber nachdenken, hört sich auf jeden Fall nicht unmöglich an.

[blaky]

Hallo Yves,

ok verstanden das mit dem Verzögerer werd ich einbauen.. und löst das Problem sicher erstmal

eleganter wäre es aber sicher mit dem Timer (ein simpler Timestamp Vergleich würde ja reichen) und hätte den Vorteil das, daß Sperren durch manuelle Bewegung nicht verzögert wird.
Überlegs dir mal

[starwarsfan]

Hallo miteinander,

hier der RC7 des Bausteins, welcher ein Problem beim Handling der Sperrung in Verbindung mit externer Höhenmodifikation löst. Weiterhin wurde die Verwendung des Höhenoffset (E25) implementiert.

Viel Spass beim Testen und wie immer her mit dem Feedback!

[jonofe]

Hi Yves,

bei mir wird scheibar E30 ignoriert. E30 ist auf 1 gesetzt, ich fahre die Rolläden manuell halb runter, der LBS sperrt sich. Beim Entsperren und Triggern von E1 fahren die Rolläden wieder hoch obwohl E30 auf 1 steht. Hab ich da was übersehen? Oder liegt es am expliziten Triggern via E1? Wird dabei E30 ignoriert? Wenn ja, soll das so sein? Meine Erwartung wäre gewesen, wenn E30=1 dann gehts nur noch in eine Richtung, egal was passiert, nämlich abwärts. Danke für eine kurze Erklärung...

[Janncsi]

Hallo Yves,

kann das Verhalten von jonofe nachvollziehen. Ab 16.30 Uhr schalte ich ebenfalls auf 1 und erwarte, dass lediglich weiter abwärts gefahren wird. Sobald im Laufe des Abends E40 auf 0 schaltet, fahren alle Rolläden hoch....

Weiteres Problem, was ich bei der RC4 nicht hatte, wenn die Rolläden unten sind, E30 auf 1 ist und ich auf E12 die Sperre mit 1 aktiviere und E13 als Höhe eine 0 hat, dann zucken die Rolläden 0,5sec nach oben, sofort wieder nach unten. Setze ich E30 auf 0 funktioniert die Zwangssperre tadellos.

[Janncsi]

Bin wieder zurück auf die RC4, da ich hier, selbst bei E30 auf 1, jederzeit mit der Zwangssperre arbeiten kann.

[starwarsfan]

Hallo Andre

bei mir wird scheibar E30 ignoriert. E30 ist auf 1 gesetzt, ich fahre die Rolläden manuell halb runter, der LBS sperrt sich. Beim Entsperren und Triggern von E1 fahren die Rolläden wieder hoch obwohl E30 auf 1 steht. Hab ich da was übersehen? Oder liegt es am expliziten Triggern via E1? Wird dabei E30 ignoriert? Wenn ja, soll das so sein? Meine Erwartung wäre gewesen, wenn E30=1 dann gehts nur noch in eine Richtung, egal was passiert, nämlich abwärts.

Das Verhalten ist so korrekt, zumindest mit den oben vorhandenen Infos.

Der Baustein verwaltet die Positionierung des Behangs vollständig intern und sperrt sich selbst, wenn der Behang manuell von extern verfahren wird. Wird nun die Sperre aufgehoben, wird die letzte gültige Position angefahren, welche der Baustein errechnet hat. Wird die Richtung der Bewegung eingeschränkt, so wird das hier auch berücksichtigt. Das hat aber mit der manuellen externen Höhe absolut nichts zu tun und kann damit auch nichts zu tun haben. Wieso sollte auf einmal eine extern vorgegebene Höhe gültig sein resp. in die interne Berechnung passen?

Der korrekte Weg wäre, den Baustein ggf. situationsabhängig dahin zu bringen, dass er die gewünschte Position anfährt. Im obigen Fall ist es für den Baustein kein "Öffnen" des Behangs, sondern die Wiederaufnahme des normalen Betriebes nach einer Sperre. Die Position hat sich rechnerisch nicht geändert und wird deshalb explizit erneut angefahren.

Ansonsten unabhängig vom Thema noch ein Hinweis in eigener Sache.

[starwarsfan]

Hallo Jan

kann das Verhalten von jonofe nachvollziehen.

Wie oben schon geschrieben ist das so korrekt.

Weiteres Problem, was ich bei der RC4 nicht hatte, wenn die Rolläden unten sind, E30 auf 1 ist und ich auf E12 die Sperre mit 1 aktiviere und E13 als Höhe eine 0 hat, dann zucken die Rolläden 0,5sec nach oben, sofort wieder nach unten. Setze ich E30 auf 0 funktioniert die Zwangssperre tadellos.

Das ist auch korrekt, da beim Deaktivieren der Sperre explizit neu positioniert wird. Wenn das in Deinem Fall ein Problem ist, dann musst Du einen SBC-Baustein dazwischen schalten.

[Janncsi]

Hi Yves,

danke für die Antwort.

Ich glaube du hast den Sachverhalt missverstanden, da du bereits am 01.06. mal drauf eingingst und den Baustein eigentlich auf meine gewünschte Funktion vom 15.05. angepasst hattest.

Mir geht es nicht um eine externe Positionierung, es geht mir lediglich um die Sperre mit Zwangsposition. Diese sollte, meiner Meinung nach, doch auch funktionieren, wenn ich die Richtung einschränke. Wie gesagt, in der RC4 funktioniert es tadellos...

[starwarsfan]

Hallo Jan,

ah ok, verstehe. Mea culpa.

Ist schon korrigiert und kommt dann mit dem nächsten RC.

[Janncsi]

Super! Danke dir

[blaky]

Rückmeldung:
E25 funktioniert

[starwarsfan]

Hallo miteinander

Sodele, die neue Version v0.6 ist released. Die Changes:

• Sperre mit Zwangsposition auch wenn Bewegungsrichtung eingeschränkt.
• Verwendung des Höhenoffset (E25) implementiert.
• Handling externer Behang-Modifikation korrigiert.
• Fehler beim Update der Winkel-Ausgänge korrigiert, wenn sich nur die Höhe geändert hat.
• Fehlende Variableninitialisierung hinzugefügt.
• Update der Höhen-Ausgänge verbessert, wenn LBS explizit getriggert wird.
• Neuer Eingang E31 zur Konfiguration des Sperrstatus-Ausganges A5
• Vereinheitlichung resp. Zusammenfassung der Eingänge De-/Aktivierung und Sperre
  • E11 - Bausteinsperre ohne weitere Positionierung des Behangs
  • E12 - Bausteinsperre mit Zwangspositionierung des Behangs
• Beschreiben von A5 nur bei Änderung des Wertes gegenüber letztem LBS-Lauf
• Alten, nicht länger verwendeten Code aus früheren Versionen entfernt
• Kein Starten des LBS während der Edomi-Startphase
• Refresh-Handling der Eingänge überarbeitet, um unmittelbar doppelte Ausführung des LBS zu verhindern
• Log-Output vereinheitlicht und reduziert
• Default-Zweig für Handling von unbekanntem Status hinzugefügt

Weiterhin viel Spass mit Edomi und dem LBS und wie immer her mit dem Feedback!

[blaky]

Hallo Yves,

bei mir läuft noch die 0.6rc7 und ich hatte heute das Problem das 2 Bausteine mir Edomi abgesägt haben mit 100%CPU Load.
Ausschlaggebend war ein ständiges wechseln des Behang statuses zwischen 4 und 2 in immens hohem Takt. Mir war so dies im NG Threat schon mal gelesen zu haben.