LBS 19000141 - Beschattungssteuerung

[starwarsfan]

Guten Abend miteinander

Um 20:38:11 habe ich die Lamellen in der Visu auf 26 % geöffnet, woraufhin sich der Baustein deaktiviert hat.
Um 20:38:11 habe ich via Button in der Visu den Baustein händisch wieder aktiviert. Allerdings schreibt er dann ja, dass Previous values == current values seien, was ja nicht stimmt, denn der Raffstore ist ja immer noch auf 26%.

In der ersten Zeile meinst Du sicherlich 20:37:49, ja?

Anyway, es ist in der Tat so, dass die externen Werte nur zum deaktivieren des Bausteines verwendet, aber nicht persistiert werden. Damit ist auch klar, warum die Meldung besagt, dass die vorherigen Werte den aktuellen Werten entsprechen. Muss da mal noch ein wenig draufrumdenken, es könnte andere Seiteneffekte haben, das intern zu ändern...

[starwarsfan]

OK, die Ursache habe ich gefunden. Der von tger977 in #188 beschriebene Change löst das Verhalten aus.

Bin am überlegen, wie das nun sauber gelöst wird...

tger977: Kannst Du das von baumhaus123 beschriebene Verhalten reproduzieren?

[Crimson]

Ich habe am Code nichts geändert, also die Änderungen aus #188 nicht ausgeführt.
Bei mir verhält sich der LBS genau wie bei baumhaus123.
Hat mich auch schon ein paar mal verwirrt, warum denn jetzt keine neue Position angefahren wird.

Viele Grüße,
Tim

[tger977]

Bei mir funktioniert das einwandfrei seit ich die beiden Zeilen auskommentiert habe.... Ich glaube diese Änderung ist genau richtig.

[starwarsfan]

Crimson und baumhaus123 : Könnt ihr das bitte mal mit den entsprechenden Änderung testen?

[Crimson]

Ich habe die beiden Zeilen auskommentiert. Das funktioniert bei mir aber nicht wie erhofft.

Folgendes habe ich gemacht:
1. Den LBS aktiviert. -> Raffstore fährt in neu errechnete Beschattungsposition
2. Raffstore von Hand verfahren -> LBS deaktiviert sich
3. Ich aktiviere den LBS über E32 wieder.

Da sich der Sonnenstand nicht verändert hat, steht jetzt im Log, dass die errechneten Werte mit den aktuellen Werten übereinstimmen.
Mein Raffstore bewegt sich also nicht in die gewünschte Beschattungsposition.

Viele Grüße,
Tim

[tger977]

Habe nun auch nochmal experimentiert. Ich habe das Verhalten nur dann reproduzieren können wenn auch über dieselbe zentral GA die der Baustein Ausgang bedient "lokal" gefahren wird. Wenn ich jedoch wie bei mir eingerichtet den Baustein alleinig auf die Zentral GA des Aktors hänge und alle anderen lokalen Taster über die zweite Lokalbefehl GA des Aktors verknüpft werden, wird nach einem Lokalbefehl der Baustein gesperrt und wenn der Baustein dann wieder aktiviert wird fährt die Jalousie wieder in die alte Position. Scheint somit leider auch noch vom Aktor abzuhängen.

[Crimson]

Nachtrag:
Nachdem der LBS die nächste Berechnung vorgenommen hat (Veränderung der Elevation) haben sich nur die Lamellen verstellt. Die Höhe hat sich nicht verändert. Der Baustein dachte wohl, der Raffstore sei schon bei 100%.

Könnte man nicht grundsätzlich nach Änderungen an den On/Off Eingängen (Baustein ein, Beschattung ein, Dämmerung ein,...) eine Neuberechnung forcieren?
Produziert vielleicht in manchen Fällen etwas mehr Buslast, aber das sollte sich ja in Grenzen halten.

Viele Grüße,
Tim

[tger977]

Könnte man nicht grundsätzlich nach Änderungen an den On/Off Eingängen (Baustein ein, Beschattung ein, Dämmerung ein,...) eine Neuberechnung forcieren?
Produziert vielleicht in manchen Fällen etwas mehr Buslast, aber das sollte sich ja in Grenzen halten.

Fände ich auch sehr sinnvoll und würde sicher robuster funktionieren. Habe den Fall bei weiteren Tests heute auch gehabt....

[tger977]

hier mal noch ein Vorschlag für evtl. Weiterentwicklung:
mich stört im Moment ein wenig das Timerverhalten: Man kann derzeit nur einen Timer für öffnen und einen für Schliessen angeben. Diese beiden greifen aber wohl nach meiner jetzigen Erkenntnis immer, d.h. sowohl bei aktiver Beschattung wie auch bei Dämmerung.

Mit der derzeitigen Bausteinumsetzung mit nur einem einstellbaren Timerwert bekomme ich das mit der Dämmerung und der Beschattung irgendwie nicht sauber hin. Wenn ich auf Beschattungsverhalten optimiere (sprich größere Timerwerte >15-30min) fährt die Jalousie abends zu spät runter und morgens zu spät rauf. Wenn ich auf die Dämmerung optimiere, ist das Verhalten bei Beschattung mit wolkigerem Wetter nicht optimal und die Jalousie wechselt zu oft zwischen Beschattung und offen und fährt dann sehr oft...

Zum Vergleich war bei meiner Quadra ein sehr angenehmes Verhalten implementiert:

- bei Beschattung konnte man einen Timerwert angeben nachdem bei unterschreiten einer Helligkeit (Wolke) erstmal auf "durchsichtsposition" (sprich die Lamellen aufgingen aber ohne Höhenänderung) gefahren wurde (typisch hatte ich hier 10min). Dann konnte man einen zweiten zusätzlichen Timerwert angeben der dann ab Durchsichtsposition startete und nach dessen Ablauf dann erst die Jalousie komplett hochgefahren wurde (typisch hatte ich hier 30min).
- bei Dämmerung konnte man ebenfalls einen separaten Timerwert angeben (hier habe ich deutlich geringere Zeiten eingestellt um ziemlich genau bei den Dämmerungsschwellwerten auch die Jalousie zu verfahren, typisch 3-5min)

[tger977]

Habe nun auch nochmal experimentiert. Ich habe das Verhalten nur dann reproduzieren können wenn auch über dieselbe zentral GA die der Baustein Ausgang bedient "lokal" gefahren wird. Wenn ich jedoch wie bei mir eingerichtet den Baustein alleinig auf die Zentral GA des Aktors hänge und alle anderen lokalen Taster über die zweite Lokalbefehl GA des Aktors verknüpft werden, wird nach einem Lokalbefehl der Baustein gesperrt und wenn der Baustein dann wieder aktiviert wird fährt die Jalousie wieder in die alte Position. Scheint somit leider auch noch vom Aktor abzuhängen.

hier noch eine Anmerkung: Bei mir ist im BMS MCU 09 die Funktion "letzte Zentralposition nach Automatiksperre anfahren" aktiv, sprich der Aktor sorgt damit selbst für das Anfahren der letzten Zentralposition des Bausteins...

[starwarsfan]

Nabend miteinander,

alles interessante Punkte, nur auf keinen Fall mal so eben implementiert. Muss ich wohl mal ein paar Experimente machen und genauer drüber nachdenken...

[starwarsfan]

Hallo und guten Abend

mich stört im Moment ein wenig das Timerverhalten: Man kann derzeit nur einen Timer für öffnen und einen für Schliessen angeben. Diese beiden greifen aber wohl nach meiner jetzigen Erkenntnis immer, d.h. sowohl bei aktiver Beschattung wie auch bei Dämmerung.

So ist es.

Mit der derzeitigen Bausteinumsetzung mit nur einem einstellbaren Timerwert bekomme ich das mit der Dämmerung und der Beschattung irgendwie nicht sauber hin. Wenn ich auf Beschattungsverhalten optimiere (sprich größere Timerwerte >15-30min) fährt die Jalousie abends zu spät runter und morgens zu spät rauf. Wenn ich auf die Dämmerung optimiere, ist das Verhalten bei Beschattung mit wolkigerem Wetter nicht optimal und die Jalousie wechselt zu oft zwischen Beschattung und offen und fährt dann sehr oft...

Verstehe und kann ich auch nachvollziehen.

Zum Vergleich war bei meiner Quadra ein sehr angenehmes Verhalten implementiert:

- bei Beschattung konnte man einen Timerwert angeben nachdem bei unterschreiten einer Helligkeit (Wolke) erstmal auf "durchsichtsposition" (sprich die Lamellen aufgingen aber ohne Höhenänderung) gefahren wurde (typisch hatte ich hier 10min). Dann konnte man einen zweiten zusätzlichen Timerwert angeben der dann ab Durchsichtsposition startete und nach dessen Ablauf dann erst die Jalousie komplett hochgefahren wurde (typisch hatte ich hier 30min).
- bei Dämmerung konnte man ebenfalls einen separaten Timerwert angeben (hier habe ich deutlich geringere Zeiten eingestellt um ziemlich genau bei den Dämmerungsschwellwerten auch die Jalousie zu verfahren, typisch 3-5min)

Kannst Du (oder wer auch immer eine Quadra hat) dazu einige Screenshots machen? Ich habe noch keine schlaue Idee, wie ich das im Rahmen des Bausteines umsetzen könnte. Die Leute werden ja jetzt schon von der Funktionalität mehr oder weniger erschlagen und ich möchte mir dazu zunächst ein genaueres Konzept überlegen. Damit würden ja noch eine ganze Menge mehr Eingänge dazu kommen...

Aktuell experimentiere ich nach der Idee von MrMirror mit einem zweiten LBS, welcher verschiedene Vorab-Settings je nach Situation ermittelt. Damit wird der eigentliche Beschattungs-LBS schlanker und damit sowohl einfacher in der Anwendung als auch robuster im Code. Aber das wird eine Weile dauern und braucht dementsprechend auch noch etwas Hirnschmalz...

[baumhaus123]

Crimson und baumhaus123 : Könnt ihr das bitte mal mit den entsprechenden Änderung testen?

So, ich habe es nun auch mal getestet und die beiden Code-Zeilen auskommentiert (nur zur Sicherheit, weil ich das bisher noch nie gemacht habe: ich habe im EDOMI-Editor die beiden Zeilen auskommentiert, habe die LBS neu eingelesen und das Projekt aktiviert, dann sollten die Änderungen wirksam sein, korrekt?).

Leider hat es nicht den gewünschten Effelt erzielt: gerade eben dieselbe Ausgangslage wie bei meinem beschriebenen Test, es ist dunkel, Raffstores sind auf 100/100. Nach Verstellen von Lamellenwinkel oder -Höhe deaktiviert sich der Baustein korrekterweise. Nach Reaktivierung auf E1 verfährt er aber nicht mehr in die 100/100 Position. Das Log sagt ja, dass

Previous values == current values

sein soll - kann es nicht sein, dass der Baustein nach Deaktivierung durch manuelles Verstellen die "verstellten Werte" nicht mehr mitbekommt und intern speichert, so dass er fälschlicherweise bei der Reaktivierung mit den ursprünglichen Werten vergleicht und so keinen Unterschied Ist/Soll erkennt?

[starwarsfan]

Hi

kann es nicht sein, dass der Baustein nach Deaktivierung durch manuelles Verstellen die "verstellten Werte" nicht mehr mitbekommt und intern speichert, so dass er fälschlicherweise bei der Reaktivierung mit den ursprünglichen Werten vergleicht und so keinen Unterschied Ist/Soll erkennt?

Genau das sollte ja durch die Änderung passieren bzw. korrigiert werden. Aber grundsätzlich ist das eher schon ein Henne-Ei-Problem, welches je nach Anwendungsfall zu Problemen führt. Es gibt Fälle, da braucht es diese Code-Zeile und es gibt Fälle, da braucht es diese Code-Zeile explizit nicht.

Aber in Anbetracht der oben aufgeführten (sehr coolen!) Verbesserungsvorschläge, wird das wohl eher auf ein erneutes grösseres Refactoring hinauslaufen...