LBS 19000145 - Beschattungssteuerung-NG

[vento66]

Hi Yves!

Die Automatische Sperre funktioniert jetzt wieder.
Eine kleine Anmerkung hätte eich noch. Wenn der LBS über Zwangsposition gesperrt wird, sperrt er sich dann natürlich auch über die Höhenänderung. Um das zu verhindern müsste die Zeilen 19998 bis 2005 wie folgt geändert werden:

    if ($E[LB_LBSID_INPUT_Height]['refresh'] == 1 && !getLogicElementVar($GLOBALS["LB_LBSID_id"], LB_LBSID_INTERNAL_LockState )) {
        LB_LBSID_debug(true, "===== === = Input height refreshed, starting LBS = === ===============================");
        $GLOBALS["LB_LBSID_PERFORM_COMPUTATION"] = true;
    }
    if ($E[LB_LBSID_INPUT_Angle]['refresh'] == 1 && !getLogicElementVar($GLOBALS["LB_LBSID_id"], LB_LBSID_INTERNAL_LockState )) {
        LB_LBSID_debug(true, "===== === = Input angle refreshed, starting LBS = === ================================");
        $GLOBALS["LB_LBSID_PERFORM_COMPUTATION"] = true;
    } 

@harry7922Wenn Du die Zeile 1940 auskommentierst funktioniert der LBS ohne Ausgabe an A8 bei Sperre über E13

[starwarsfan]

Hallo miteinander,

nachdem ich doch gestern Abend noch eine Lösung gefunden habe, sind die manuellen Tests mit externer Behang-Manipulation für meine Begriffe erfolgreich verlaufen. Somit hier also eine neue Version, der RC4.

Happy testing und immer her mit dem Feedback!

[starwarsfan]

Hallo miteinander,

also den Fehler bzgl. Sperre bei externer Behang-Modifikation habe ich gefunden, nur weiss ich noch nicht so recht, wie ich das nun sauber löse. Es hat mit dem Umbau hinsichtlich dauerhafter Positionsberechnung ohne Update der Ausgänge zu tun und ist (wie zu erwarten) nicht ganz trivial...

[starwarsfan]

Hi

Ja klar! Nur hatte ich halt in meinem jugendlichen Leichtsinn erwartet, das sich die Funktion des A8 nicht ändert

Die ursprüngliche Idee war aus dem Grund ja auch, dass über den Wert an A8 festgestellt werden kann, auf welche Art und Weise der Baustein gesperrt ist. Da das aber auch auf keine Gegenliebe gestossen ist, hab' ich's wieder ausgebaut.

Wie man's macht...

[vento66]

tger977 wohl wahr!
starwarsfan Ja klar! Nur hatte ich halt in meinem jugendlichen Leichtsinn erwartet, das sich die Funktion des A8 nicht ändert.... Ist ja kein Beinbruch zur not bau ich mir den LBS halt um....

[tger977]

ich glaube wir zwei kommen da auf keinen grünen Zweig und die Argumente sind ausgetauscht... Mal sehen was Yves draus macht.

[starwarsfan]

Hallo miteinander

Jetzt heisst der Ausgang neuerdings LBS gesperrt (vielleicht eine unglückliche Namenswahl), warum soll sich an der Funktion des Ausganges was ändern?

Naja, Du hast selbst in #742 geschrieben, dass es die De-/Aktivierung nicht mehr braucht, wenn der Baustein intern immer weiterrechnet, die Ausgänge aber nicht aktualisiert. Daraufhin kam dann ja der Umbau, dass es zwei verschiedene Sperren gibt: Zum Einen gesperrt ohne Positionsänderung und zum Anderen gesperrt mit Zwangsposition.

[vento66]

Weil es einfach nicht der KNX Statusobjektlogik entspricht. Ein Aktor sendet auch eine Statusinfo gesperrt oder eben nicht. Warum soll ein LBS wenn er eigentlich gesperrt ist ein "nicht gesperrt" senden???

Der LBS soll ja gar nichts senden, wenn er über E13 gesperrt wird... somit sendet er ja auch nichts falsches

und per zusätzlicher Logik könntest Du ebenfalls Deinen Status selbst bilden, wie ich oben auch schon geschrieben habe...

Du wirst lachen, da hab ich mir seit der Entstehung dieses LBS schon Gedanken darüber gemacht, und genau diese Funktion bei mir intern implementiert. Yves hat sie dann dankenswerter weise übernommen. Mal kurz zur Historie:
- In den ersten Versionen hat sich der LBS komplett deaktiviert, wenn über die Höhe eine Änderung durch den LBS erkannt wurde. Der Ausgang heist auch deshalb LBS aktiv (nicht gesperrt!)
- Jetzt heisst der Ausgang neuerdings LBS gesperrt (vielleicht eine unglückliche Namenswahl), warum soll sich an der Funktion des Ausganges was ändern?

[harry7922]

Wenn ich mich in die Diskussion nochmal einhaken darf.
Meiner Meinung nach, wäre ein zusätzlicher Ausgang für „Gesperrt durch manuelle Änderung“ am Besten.
Dadurch ist der generelle Status auf A8 ersichtlich - wer es benötigt kann zusätzlich auf die manuelle Änderung reagieren.

Erst wenn nach einer manuellen Änderung die Sperre wieder aufgehoben wurde, sollte der neue Ausgang auf 0 zurückgesetzt werden.

Das wäre zumindest mal mein Wunsch an Yves

Grüße
Hardy

[tger977]

und per zusätzlicher Logik könntest Du ebenfalls Deinen Status selbst bilden, wie ich oben auch schon geschrieben habe...

[tger977]

Weil es einfach nicht der KNX Statusobjektlogik entspricht. Ein Aktor sendet auch eine Statusinfo gesperrt oder eben nicht. Warum soll ein LBS wenn er eigentlich gesperrt ist ein "nicht gesperrt" senden???

[vento66]

Warum? Ich hab Dir doch schon oben beschrieben, wie Du den Status "gesperrt" darstellen kannst... Das KO von E13 und das von A8 auf ein Oder, und den Ausgang dann auf die Visu. Du brauchst Doch nur den Status der Sperre auf A8, den Du nicht selbst ausgelöst hast. Einen zusätzlichen Ausgang finde ich unnötig.

[tger977]

korrekt?

Ja, das auf jeden Fall.

Und dann ist noch die Diskussion ob E13 den A8 setzen soll oder nicht. Ich bevorzuge dies mit dem Argument daß ich einfach nur eine Info (0|1) haben möchte ob der LBS gesperrt ist oder eben nicht (egal durch was) um das in der Visu darzustellen und auch um den Aktor zu sperren. Desweiteren kann man über diese Statusrückmeldung per Visu (Wertänderung mit Statusobjekt) auch einfach die Sperre(n) wieder aufheben.

Um die Anforderungen von Micha und Harry nach detailierterer Info zu manuellen Sperren abzudecken könnte man ja einen zusätzlichen Ausgang definieren "manuelle Sperre durch externes Verfahren über E9/10 oder E13".

[vento66]

Genau! Und das im RC2 Der Ausgang A8 auch auf 1 ging, wenn über E13 gesperrt wird, was in meinen Augen nicht sein soll.

[starwarsfan]

Hallo miteinander,

vielen Dank für die zahlreichen Feedbacks. Also wenn ich's richtig verstehe ist das Hauptproblem im Moment, dass die automatische Sperre bei manueller Behangmanipulation nicht mehr funktioniert, korrekt?

Muss ich wohl im Dev-System genauer unter die Lupe nehmen, da ich diese Funktion selbst nicht verwende...