LBS 19000145 - Beschattungssteuerung-NG

[crewo]

Ich stimme hier zu, das wäre auch für mich sinnvoll, was ich hier so lese

[starwarsfan]

N'abend

grundsätzlich dachte ich das auch erst, aber beim zweiten Überlegen kam ich zu dem Schluss daß das kaum etwas bringt, da der WorstCase bzgl. CPU ja der Fall ist in dem alle Bausteine tatsächlich aktiv sind und das wird wohl bei sehr sonnigen Tagen immer der Fall sein. Und macht wirklich wer eine Logik um über E12 abhängig von hoher CPU Last einige Bausteine abzuschalten?!

Wie gesagt, ist einfach ein möglicher UseCase und ich mag nicht darüber diskutieren, ob der nun Sinn macht oder nicht. Mit dem Entfernen von Features sollte man aber sehr vorsichtig sein, da es ja durchaus noch ganz andere Anwendungsfälle gibt, welche auf der entsprechenden Funktionalität basieren.

das sehe ich wieder aus Anwendersicht kritisch, da
a) man dann wieder Logik braucht um Stati 1-3 aufzulösen.

Nicht wirklich. Im ganz einfachen Fall lässt es sich direkt mit ein oder zwei Ausgangsboxen erschlagen. Braucht man die Unterscheidung, ist's halt noch ein Filter dazwischen. Wenn das für Dich schon "Logik" im Sinne von "Logik" ist, gut. Aber sonst?

b) frage ich mich auch was ich mit der Detailierung machen soll. Gesperrt ist gesperrt, da ist es mir eigentlich egal über welchen Eingang.
c) man in der Visu vermutlich auch keine zwei verschiedenen Stati darstellen würde sondern nur gesperrt oder freigegeben.

Du solltest mal über den Tellerrand schauen! Es gibt nicht nur Deine Anwendungsfälle...

Wenn's wirklich gebraucht wird: ganz konsequent wäre zwei Ausgänge anzulegen, jeweils passend und mit gleichen Wertebelegungen (0 und 1). Dann könnte man diese auch leichter mit (Binär)Logiken weiterverarbeiten. Ich halte Stati mit 2 oder 3 immer für schwierig(er) in der Weiterverarbeitung...

Das sehe ich eben genau nicht so, wobei das vermutlich durchaus Ansichtssache ist.

Vielen Dank schon im Voraus für Deinen unermüdlichen Einsatz für diesen hochkomplexen Baustein

Immer gern.

[starwarsfan]

N'abend miteinander,

kurzer Zwischenstand:

Der Umbau macht Fortschritte. Den De-/Aktivierungseingang sowie -zustand des LBS gibt es nicht mehr. Stattdessen ist dieser Eingang nun die einfache Sperre, also ohne Positionierung des Behangs und hat Vorrang vor dem Sperr-Eingang mit Zwangspositionierung.

Hier die Doku dazu:

• E12: Bausteinsperre (0/1)
  Beim Wert 0 auf diesem Eingang arbeitet der Baustein ganz normal, also mit Aktualisierung der Ausgänge (sofern nicht durch E13 gesperrt).
  Wird auf diesen Eingang 1 geschrieben, so wird der Baustein gesperrt. Dabei arbeitet der Baustein intern normal weiter, die Positionsausgänge werden lediglich nicht aktualisiert. Damit wird erreicht, dass der Baustein beim Entsperren sofort die nun gültige Position anfahren kann. Default: 0
• E13: Bausteinsperre mit Zwangsposition (0/1)
  Beim Wert 0 auf diesem Eingang arbeitet der Baustein ganz normal, also mit Aktualisierung der Ausgänge (sofern nicht durch E12 gesperrt).
  Wird auf diesen Eingang 1 geschrieben, so wird der Baustein gesperrt und die mit den beiden Eingaengen E14/E15 definierte Position angefahren. Dabei arbeitet der Baustein intern normal weiter, die Positionsausgänge werden lediglich nicht aktualisiert. Damit wird erreicht, dass der Baustein beim Entsperren sofort die nun gültige Position anfahren kann. Default: 0
  Die Sperre via E12 hat Vorrang vor der Sperre via E13. Wird also sowohl E12 als auch E13 auf 1 gesetzt, wird der Behang nicht auf die Werte von E14/E15 positioniert!
• E14: Hoehe bei Sperre (%)
  Anzufahrende Hoehe bei Bausteinsperre. Default: 0
• E15: Winkel bei Sperre (%)
  Anzufahrender Winkel bei Bausteinsperre. Default: 0

[rene.z]

Hallo starwarsfan

Top!

Wenn der Baustein sich nach wie vor sperrt wenn der Behang manuell verändert wird (und trotzdem intern weiter rechnet, sodass bei einer 0 auf E12 die jeweils aktuell errechnete Position angefahren wird) ist der Baustein perfekt.

Ach so: Cool wäre natürlich folgendes Verhalten: manuelles Verfahren ---> Sperre --> 1 auf E13 (Fenster auf) --> Zwangsposition wird angefahren --> 0 auf E13 (Fenster zu) --> manuell angefangene Position wird wieder eingestellt --> 0 auf E12 aktuell errechnete Position wird angefahren.

Anwendungsfall: Nachmittag, Behang im Schlafzimmer ist (korrekterweise) geöffnet --> manuelles Schließen des Behangs (Krankheit, Mittagsschläfchen, ...) --> Öffnen der Balkontür --> Behang wird geöffnet --> Schließen der Balkontür --> Behang wird auf die manuell eingestellte Position gefahren (anstatt geöffnet zu bleiben) --> nach dem Mittagsschläfchen 0 auf E12 --> Automatik übernimmt wieder.

vG,
René

[ak68]

Hallo Yves,
auf die Abschaffung der beiden Ein- Ausgänge habe ich lange gewartet.
Nur: Was passiert nach manueller Behangverstellung oder nach Windalarm durch die Wetterstation? Wird der LBS weiterhin gesperrt? Dies waere sinnvoll 1. Bis zum Über- bzw. Unterschreiten der Daemmerungsschwelle und 2. Bis zu einem Neuem Auslösen der Beschattungsfunktion!
Bei diesen beiden Situationen sollte (aus meiner Sicht) wieder eine automatische Aktivierung erfolgen- ohne externe Logik!

Andreas

[rene.z]

Hallo starwarsfan,

mir ist heute morgen eine weiteres Feature aufgefallen, welches den Baustein (aus meiner Sicht ;-)) noch besser werden lassen würde:

Kannst du bei der Dämmerungssteuerung einen weiteren Eingang "Zwangspositionierung Dämmerung" hinzufügen - bei einer 1 sofort die Dämmerungsposition anfahren, bei einer 0 berechneten Wert der Dämmerungsposition sofort anfahren.

Anwendungsfall: Zeitschaltuhr gibt die Schließzeiten des Behangs vor: 1 von der ZSU führt am Abend zum Schließen des Behangs auch wenn die Dämmerungsschwelle noch nicht unterschritten ist und hält den Behang am Morgen bis mindestens SS:MM (dann nämlich, wenn die ZSU eine 0 sendet) auch wenn die Dämmerungsschwelle schon überschritten ist geschlossen.

Achtung: die Zwangspositionierung von E13 sollte weiterhin Vorrang vor der "Zwangspositionierung Dämmerung" haben (d.h. auch in der Nacht, öffnet sich der Behang, wenn ich auf E13 eine 1 sende).

Was meinst du?

vG,
René

[rene.z]

Hallo starwarsfan,

wenn ich schon dabei bin Vorschläge zum LBS zu machen, noch eine eher kosmetische Anmerkung:

Ich könnte mir vorstellen, dass nahezu alle Anwender des LBS die beiden Ausgänge A1 und A12 (Sonne Azimut und Sonne Elevation) ver-unden um festzustellen, ob sich die Sonne im definierten Fenster befindet oder nicht.

Um ein "und-Gatter" im Logikeditor zu sparen wäre es super wenn A1 zu "Sonne ja/nein" (mit bereits ver-undeten Azimut und Elevation) würde und - für alle die die Info getrennt benötigen - einfach ein zusätzlicher Ausgang A13 mit "Sonne Azimut" hinzukommen würde.

Was meinst du?

vG,
René

P.S.: ... und ja, ich weiß, dass sich dadurch die Bedeutung der Ausgänge verändern würde.

[vento66]

Um ein "und-Gatter" im Logikeditor zu sparen

Das ist jetzt nicht Dein ernst oder?

[rene.z]

Das ist jetzt nicht Dein ernst oder?

...doch, mein voller Ernst.

Wenn ich mir für 22 Fenster im ganzen Haus jeweils ein "und-Gatter" erspare sind das immerhin 22 Stellen weniger, an denen man Fehler einbauen kann und außerdem macht es die jeweiligen Seiten im Logikeditor übersichtlicher und damit einfacher zu warten.

Ganz abgesehen davon, dass es ganz genau die Idee eines LBS ist, Logik die an mehreren Stellen verwendet wird, an einer Stelle zu zentralisieren.

[starwarsfan]

Hallo Rene

Kannst du bei der Dämmerungssteuerung einen weiteren Eingang "Zwangspositionierung Dämmerung" hinzufügen - bei einer 1 sofort die Dämmerungsposition anfahren, bei einer 0 berechneten Wert der Dämmerungsposition sofort anfahren.

Nein, sicher nicht. M.M.n. ist das überflüssig und macht den Baustein sowohl im Code als auch für den User wesentlich komplexer als er jetzt schon ist.

Ich würde das eher in die Richtung angehen, via ZSU bspw. -5 (DAWN_FULL_CLOSED) auf das E11-iKO zu schreiben und dann den Baustein zu sperren. Am Morgen hebst Du die Sperre via ZSU wieder auf und schreibst ggf. -1 (DAWN_NEUTRAL) auf das E11-iKO. Da muss sicher etwas experimentiert werden...

Um ein "und-Gatter" im Logikeditor zu sparen wäre es super wenn A1 zu "Sonne ja/nein" (mit bereits ver-undeten Azimut und Elevation) würde und - für alle die die Info getrennt benötigen - einfach ein zusätzlicher Ausgang A13 mit "Sonne Azimut" hinzukommen würde.

Der Baustein soll sich einzig und allein um die Beschattung kümmern und alles was es dafür braucht, ver-/bearbeiten. Dazu gehört aber sicher nicht, weitere Logikbausteine einzusparen.

Wenn ich mir für 22 Fenster im ganzen Haus jeweils ein "und-Gatter" erspare sind das immerhin 22 Stellen weniger, an denen man Fehler einbauen kann

Sry, aber wenn Du soetwas 22 mal machst ohne es ein einziges Mal zu testen und Dir einen Fehler einbaust, dann bist Du selber schuld!

Ganz abgesehen davon, dass es ganz genau die Idee eines LBS ist, Logik die an mehreren Stellen verwendet wird, an einer Stelle zu zentralisieren.

Das sehe ich etwas anders. Ein LBS ist dafür da, ganz konkrete Anwendungsfälle zu vereinfachen, indem er die jeweilige Businesslogik kapselt. Die Art und Weise der weiteren Verarbeitung der Resultate obliegt dem Anwender.

Ich werde aber dennoch mal drüber nachdenken. Hängt stark davon ab, wann welcher Teil validiert bzw. berechnet wird...

[harry7922]

Hallo Yves,

ich habe den aktuellen 3.12 LBS im Einsatz.
Ich verwende E36 (BWG Höhe einschränken) wenn die Balkontür offen ist, damit wir uns nicht ausperren. Dazu setze ich E36 auf den Wert 2.
Wenn der Status nun aber von 6 auf 5 (Switching from SHADOW_FULL_CLOSE_TIMER_RUNNING to SHADOW_FULL_CLOSED) ändert, fährt mir die Jalousie dennoch runter und scheint E36 zu ignorieren.
Nutze ich E36 falsch und es war so nicht gedacht, oder könnte es sich um ein Bug handeln?
Solltest Du den Log des Statuswechsels benötigen, gib bitte Bescheid.

Danke und Grüße
Hardy

[starwarsfan]

Hallo Hardy

Ich verwende E36 (BWG Höhe einschränken) wenn die Balkontür offen ist, damit wir uns nicht ausperren. Dazu setze ich E36 auf den Wert 2.
Wenn der Status nun aber von 6 auf 5 (Switching from SHADOW_FULL_CLOSE_TIMER_RUNNING to SHADOW_FULL_CLOSED) ändert, fährt mir die Jalousie dennoch runter und scheint E36 zu ignorieren.
Nutze ich E36 falsch und es war so nicht gedacht, oder könnte es sich um ein Bug handeln?

Ein Bug? Völlig unmöglich!

Nein, im Ernst, es ist natürlich durchaus möglich, dass da etwas klemmt. Gerade in Hinblick auf die letzten Refactorings. Ich werd's mir in meiner Dev-Umgebung ansehen. Danke für die Info!

[g0bi]

Hallo Yves,

wenn ich die Jalousien manuell hochfahre (0/0) und die Dämmerung tritt ein, werden diese nicht heruntergefahren obwohl ich 100% Änderung zulasse und der LBS die aktuelle Position zurückgemeldet bekommt. Bei der Beschattung verstehe ich es, aber bei der Dämmerung sollten sie doch runterfahren?

Oder mach ich doch was falsch?

Gruß Stefan

[harry7922]

Hallo Stefan,

was meinst Du mit 100% Änderung? Meinst Du die Toleranz bei Höhe und Winkel?

Gruß
Hardy

[starwarsfan]

Hallo Stefan

wenn ich die Jalousien manuell hochfahre (0/0) und die Dämmerung tritt ein, werden diese nicht heruntergefahren obwohl ich 100% Änderung zulasse und der LBS die aktuelle Position zurückgemeldet bekommt. Bei der Beschattung verstehe ich es, aber bei der Dämmerung sollten sie doch runterfahren?

Daraus kann ich mir grad nicht viel nehmen. Bitte Screenshot der Logik sowie allfällige Werte an den Eingängen posten.