LBS 19000145 - Beschattungssteuerung-NG

[tger977]

Man o mann! So schnell komm ich gar nicht hinterher!

Vielen Dank Yves.

Werde wohl erst morgen zum testen kommen.

[baumhaus123]

Hi Yves,

Danke für das Update! Habe eben aktualisiert, aktiviert und getestet. Beschattungs-Tests sind aktuell naturgemäß schwer möglich. Deswegen habe ich einfach die Lamellen händisch bewegt, Baustein deaktiviert sich. Nach Triggern von E12 mit einer 1 werden nun sofort die Dämmerungswerte angefahren (E63 und E64). Fazit: geil geil geil! Genauso wollte ich es ich immer haben, ein Klick in der Visu, LBS ist wieder scharf und die aktuelle Position nach LBS-Einstellung wird angefahren. Werde hoffentlich morgen mal dazu kommen, das ganze im Beschasttungds-Szenario zu testen.

Viele vielen Dank für die viele Zeit und Nerven, die du in den tollen Baustein steckst!

[crewo]

Das ist großartig, vielen Dank auch für die schnelle Reaktion hier!

[starwarsfan]

N'abend@all,

so, die 3.0.RC3 ist online. Die Ausgänge werden jetzt beim Trigger via E1 sowie bei Änderungen an den Aktivierungsstatus auf jeden Fall beschrieben. Das betrifft auch das direkte Anfahren der konfigurierten nach-Dämmerung- bzw. nach-Beschattung-Position, wenn der jeweilige Status zum Zeitpunkt der Deaktivierung ein Dämmerungs- bzw. Beschattungs-Status war.

Bin gespannt, wie es damit nun bei euch aussieht.

[tger977]

Dass der Trigger-Eingang E1 den Baustein unabhängig von dessen Status auf jeden Fall triggert, wurde erst mit einem der letzten Changes implementiert. Nun fehlt sozusagen noch eine Art Unterscheidung, was den Baustein ausgelöst hat. Wurde der Baustein also bspw. durch einen Change der Elevation oder des Azimut getriggert und die errechneten Ergebnisse sind identisch mit denen der vorherigen Berechnung, so werden die Ausgänge nicht neu geschrieben. Wurde der Baustein aber explizit durch den Trigger-Eingang angestossen, so sollen die Ergebnisse auf jeden Fall auf die Ausgänge geschrieben werden, egal ob sie identisch mit den vorherigen Resultaten sind oder nicht.

Diesen Ansatz finde ich interessant!

Ggf. könnte man damit dann auch die anderen Wünsche mit etwas Logik (oder weiterem Vorschalt-LBS, Szene, etc.) ausserhalb des Beschattungs-LBS umsetzen:
- erst alle nicht triggernden Eingänge setzen: andere Schwellen, Timerzeiten, Jalousiepositionen (einschliesslich einer Möglichkeit Timer z.B. mit einer 0 auch ausschalten oder zumindest auf ein kaum wahrnehmbares Minimum reduzieren zu können).
- dann zum Schluss per E1 einen Trigger des kompletten LBS zu setzen, der dann auch die Werte der Ausgänge schreibt.
- ggf. müssten dann E40/E60 auch nicht mehr triggern. Man kann dann selbst bestimmen ob eben direkt eine Änderung/Reaktion erfolgen soll in dem man dann entweder den E1 noch setzt (sofortige Reaktion entsprechend restlichen Eingängen) oder eben nicht (erst Reaktion beim nächsten Event/Änderung durch Wetterstation)
- über evtl. SBC an den Ausgängen kann man dann auch noch selbst eingreifen, je nachdem was der JAL-Aktor hergibt. Mein Aktor fährt z.B. bei einer Sperrungsaufhebung (Sperrobjekt im Aktor nicht der Sperreingang des LBS!) automatisch die letzte bekannte Automatikposition an. Wenn jedoch der aktuell eingestellte Wert durch den LBS neu geschickt wird fährt er diese Position erneut an (Lamellen gehen einmal unnötig auf/zu)

was aber hier entscheidend ist ist die Möglichkeit daß in jedem Zustand der Baustein auch tatsächlich jederzeit und auf alle geänderten Eingänge "reagiert". Ob das nun implementierungstechnisch auch eine größere Änderung ist oder heute so schon weitestgehend funktioniert kann ich grad nicht überblicken. Zumindest bei laufenden Timer geht das glaube ich aktuell nicht, die werden nach meinen Beobachtungen immer hart durchlaufen (was denke ich kaum so gewollt sein kann, oder doch?).

Wenn ich nichts übersehe wäre das sehr flexibel. (aber vielleicht nicht ganz selbsterklärend und man müsste auch prüfen ob immer der E1 auch tatsächlich sicher als letzter Befehl abgesetzt wird...)

Hoffentlich habe ich nun nicht irgendwas übersehen.

[crewo]

Lieber Yves, das klingt perfekt! Danke für deine Mühen hier.

EDIT: Hab mir bis dahin jetzt beholfen mit einem Wertauslöser, der hat an E2 die Höhe bzw. Winkel anliegen und an E1 die gleichen Auslöser wie der NG an E1, A1 schickt nun nach ersten Tests zuverlässig die aktuellen Werte auf den Bus, sobald der Trigger kommt.

[starwarsfan]

Hi

im Prinzip würde mir genügen, wenn du einfach an den Ausgängen bei Trigger die aktuell sowieso schon vorhandenen Werte (der Baustein läuft ja ganz normal durch) noch einmal ausgibst. Somit könnte man "jederzeit" durch Triggern die aktuell gültigen Werte für Höhe und Winkel vom Baustein abfragen, welche die Jalousie eventuell verpasst hat während diese gesperrt war. Aktuell hätte ich mir auch beholfen mit Baustein deaktivieren/aktivieren, aber auch das schreibt leider die Werte nicht neu in den Bus.

So einfach ist es leider nicht. "Sowieso schon vorhanden" nützt an dieser Stelle gar nichts, da der Trigger-Eingang explizit dafür gedacht ist, eine Berechnung auszulösen, egal in welchem Zustand sich der Baustein befindet. Das Problem ist, dass der Baustein nichts ausgibt, wenn sich nichts ändert und das ist im Moment explizit so gewünscht resp. so implementiert.

Aber das heisst natürlich nicht, dass es das nicht geben wird!

Dass der Trigger-Eingang E1 den Baustein unabhängig von dessen Status auf jeden Fall triggert, wurde erst mit einem der letzten Changes implementiert. Nun fehlt sozusagen noch eine Art Unterscheidung, was den Baustein ausgelöst hat. Wurde der Baustein also bspw. durch einen Change der Elevation oder des Azimut getriggert und die errechneten Ergebnisse sind identisch mit denen der vorherigen Berechnung, so werden die Ausgänge nicht neu geschrieben. Wurde der Baustein aber explizit durch den Trigger-Eingang angestossen, so sollen die Ergebnisse auf jeden Fall auf die Ausgänge geschrieben werden, egal ob sie identisch mit den vorherigen Resultaten sind oder nicht.

[crewo]

starwarsfan im Prinzip würde mir genügen, wenn du einfach an den Ausgängen bei Trigger die aktuell sowieso schon vorhandenen Werte (der Baustein läuft ja ganz normal durch) noch einmal ausgibst. Somit könnte man "jederzeit" durch Triggern die aktuell gültigen Werte für Höhe und Winkel vom Baustein abfragen, welche die Jalousie eventuell verpasst hat während diese gesperrt war. Aktuell hätte ich mir auch beholfen mit Baustein deaktivieren/aktivieren, aber auch das schreibt leider die Werte nicht neu in den Bus.

Die Anforderung von Andi ist da komplexer, da sehe ich es ähnlich wie du, dazu muss vermutlich gründlicher nachgedacht werden.

[starwarsfan]

Hallo miteinander

Ja, genau via E1, ich würde erwarten ich bekomme dann auf den Ausgängen A3 bis A6 die Werte ausgegeben. Oder wie kann ich vorgehen um z.B. nach Sperre über Nacht (absolute Position gesperrt über Szene im Aktor) die Lamellenführung zu starten ohne auf Witterungsänderung zu warten?

Wenn ich die Beschattungsautomatik beende würde ich erwarten daß der Baustein dann auch die Positionen nach Beschattungsende anfährt und ab dann eben nichts mehr über das Beschattungsprogramm macht. Wenn ich das Hochfahren zusätzlich zur Deaktivierung des Beschattungsprogramms manuell mache ist der Baustein ja über external height / angle sofort ganz aus und dann geht auch kein Dämmerungsprogramm mehr...

Das braucht jetzt offenbar eine ganze Portion mehr Hirnschmalz. Das sind alles Fälle, welche nach einem mehr oder weniger konkreten Schema den Durchlauf der Statemachine verändern. Vereinfacht gesagt ist es aktuell so, dass es einen genauen Ablauf zwischen den einzelnen Status gibt, welcher durch die Statemachine definiert und abgearbeitet wird. Die möglichen Status und deren Ablauf-Reihenfolge sieht so aus:

• SHADOW_FULL_CLOSE_TIMER_RUNNING (5)
• SHADOW_FULL_CLOSED (4)
• SHADOW_HORIZONTAL_OPEN_TIMER_RUNNING (3)
• SHADOW_HORIZONTAL_OPEN (2)
• SHADOW_OPEN_TIMER_RUNNING (1)
• OPEN (0)
• DAWN_OPEN_TIMER_RUNNING (-1)
• DAWN_HORIZONTAL_OPEN (-2)
• DAWN_HORIZONTAL_OPEN_TIMER_RUNNING (-3)
• DAWN_FULL_CLOSED (-4)
• DAWN_FULL_CLOSE_TIMER_RUNNING (-5)

Im Ablauf aktuell so:
2017-03-20-StateMachine01.png

Nun kommen aber eben weitere Statusübergänge hinzu und ich bin mir noch nicht so recht im klaren, wie ich diese modelliere resp. nachvollziehbar abbilde.

Aber wird schon, keine Sorge...

[crewo]

starwarsfan "hx5" hat nicht ganz unrecht, auch wenn das aktuell sicher auch ein Geben und Nehmen ist zwischen uns Testern und dir, trotzdem an dieser Stelle noch einmal vielen vielen Dank für die ganzen Mühen. Eine Liste kann nie schaden, dann weiß man auch was du überhaupt umsetzt und was nicht - und kann sich damit auf die eigene Lösungssuche machen

Und kurz rückgefragt: Wie löst du (oder würdest du lösen) bei dir den Fall, wenn eine Jalousie z.B. Nachts gesperrt werden muss und erst nach dem es am Morgen schon hell ist (aber keine Beschattung nötig), entsperrt wird? Dafür wird nicht die Bausteinfunktion "Sperre" verwendet, diese verwende ich für "Tür auf". Problem ist dann, der Baustein führt keine Änderung durch, auch nicht beim Triggern über sämtliche relevanten Eingänge, d.h. die Jalousie verbleibt im Modus "Dämmerung". Ich würde aber erwarten, das die Werte für "Nach Dämmerung" gesetzt werden. Könntest du dir das bitte einmal ansehen?

[hx5]

Also ich hab nicht einmal bitte gelesen, außer von Yves selbst......

[starwarsfan]

Hallo miteinander,

ok, verstehe die Problematik. Ob ich auch so eine Liste wie gaert anfange?

[tger977]

also nach weiterem Testen habe ich fast die Vermutung daß generell wenn ein Timer läuft der LBS auf gar nichts mehr reagiert bis der timer abgelaufen ist...

[tger977]

Nur wäre mir nicht so wichtig das Einstellungen beim deaktivieren zurückgenommen werden, denn zurück zu was? Könnte man doch mit externer Logik prima selbst managen.

Die externe Logik ist nicht das Problem aus meiner Sicht. Nur wo speise ich die neue, gewünschte Jalousieposition dann im LBS ein? Wenn ich eine Position ohne den LBS direkt einstelle deaktiviert sich der Baustein ja selbst. Hatte ja auch noch meinen post oben genau um diesen Punkt ergänzt, kurz bevor Du geantwortet hast.

Wichtig wäre allerdings, dass bei Aktivierung oder generellem Trigger der Baustein die aktuelle Lage prüft und die Ausgänge einmalig neu beschreibt mit den passenden Werten zur Situation - das wäre wirklich extrem hilfreich

full ack!

[crewo]

tger977 ich denke unsere Anforderungen sind recht ähnlich. Nur wäre mir nicht so wichtig das Einstellungen beim deaktivieren zurückgenommen werden, denn zurück zu was? Könnte man doch mit externer Logik prima selbst managen. Wichtig wäre allerdings, dass bei Aktivierung oder generellem Trigger der Baustein die aktuelle Lage prüft und die Ausgänge einmalig neu beschreibt mit den passenden Werten zur Situation - das wäre wirklich extrem hilfreich