LBS 19000145 - Beschattungssteuerung-NG

[franzo]

Hallo

kann sein dass sie Min/Max Elevation immer noch nicht korrekt ausgewertet wird?

Unbenannt21.jpg

[starwarsfan]

kann sein dass sie Min/Max Elevation immer noch nicht korrekt ausgewertet wird?

Hm, da scheint sich wieder ein Fehler eingeschlichen zu haben. Ich schau's mir an...

Achja, RC4 ist aktuell!

[starwarsfan]

Hallo Franz

kann sein dass sie Min/Max Elevation immer noch nicht korrekt ausgewertet wird?

So, gefixt. Hier die RC5 mit folgenden Korrekturen:

3.3.RC5 (2017-04-22)

• Min-Max-Elevation wird wieder korrekt ausgewertet
• Fehler bei Berechnung der effektiven Sonnen-Elevation korrigiert
• Interne Performance-Optimierung

3.3.RC4 (2017-04-16)

• Alle Timer werden beim Entsperren kurzzeitig auf 1s gesetzt, um ohne nennenswerte Verzoegerung zum aktuell gueltigen Status zu gelangen.
• Handling der Sperre korrigiert. Ist der LBS gesperrt, kann er nur noch via E1 oder E2 direkt getriggert werden. Alle anderen Trigger werden ignoriert.
• Aktueller Status E11 wird nun immer ausgewertet, nicht nur beim ersten Lauf nach Edomi-Neustart. Ist E11 leer, wird beim ersten Lauf von NEUTRAL ausgegangen und bei allen weiteren Laeufen der intern gespeicherte Status vom letzten Lauf des LBS verwendet.

3.3.RC3 (2017-04-13)

• Fehler beim Uebergang von Daemmerungshandling zu Beschattungshandling korrigiert

3.3.RC2 (2017-04-12)

• Fehler im Daemmerungshandling korrigiert

3.3.RC1 (2017-04-12)

• Status-Namen normalisiert
• Zwei neue Status eingefuehrt: SHADOW_NEUTRAL und DAWN_NEUTRAL fuer den Zustand jeweils nach Beschattung bzw. nach Daemmerung
• Min-Max-Elevation wird korrekt ausgewertet
• Eingang E13 Sperre repariert
• Ausgang A2 Beschattungsstatus repariert
• Lamellenwinkelberechnung korrigiert
• Trigger-Eingang E2 implementiert
• Baustein-Reaktivierung ueberarbeitet

Viel Spass und immer her mit dem Feedback!

[baumhaus123]

Viel Spass und immer her mit dem Feedback!

Hallo Yves,

Danke für das Update. Hast du denn mal versucht, das Szenario wie auf meinem Screenshot in diesem Beitrag ersichtlich ist, nachzustellen, ob bei dir das gleiche Verhalten auftritt? Wie schon geschrieben wurde bei Projekt-Neustart in diesem Fall die Höhe 0 angefahren und ich weiß nicht, woher diese Höhe kommen soll, da alle Nachwerte immer die Höhe 100 haben. Danke für ein Feedback!

[starwarsfan]

Hi

Hast du denn mal versucht, das Szenario wie auf meinem Screenshot in diesem Beitrag ersichtlich ist, nachzustellen, ob bei dir das gleiche Verhalten auftritt? Wie schon geschrieben wurde bei Projekt-Neustart in diesem Fall die Höhe 0 angefahren und ich weiß nicht, woher diese Höhe kommen soll, da alle Nachwerte immer die Höhe 100 haben. Danke für ein Feedback!

Jo, hab's eben hier nachgestellt. Muss aber auch erstmal suchen, wie das zustande kommt. Hat vermutlich etwas mit dem Einstieg in das State-Handling beim Edomi-Neustart zu tun...

[baumhaus123]

Hi

Jo, hab's eben hier nachgestellt. Muss aber auch erstmal suchen, wie das zustande kommt. Hat vermutlich etwas mit dem Einstieg in das State-Handling beim Edomi-Neustart zu tun...

Alles klar. Beruhigt mich zumindest, dass du es reproduzieren konntest. Vielen Dank für deine Mühen! Falls ich irgendetwas testen soll, lass es mich wissen...

[starwarsfan]

Hallo Matthias, hallo miteinander,

das Problem rührt daher, dass der Baustein beim initialen Lauf nicht weiss, in welcher Position sich der Behang befindet, geht daher vom Default "offen" aus um sich selbst intern in einen validen Zustand zu bringen und fährt den Behang auf 0%/0%. Dabei bleibt der Baustein im gleichen Status, in dem er sich vorher befunden hat.

Mit dem letzten grossen Refactoring der State-Machine hat sich ja nun einiges intern geändert, so dass das gesamte Init-Handling nach diesen Betrachtungen meiner Meinung nach nicht mehr so recht sauber ist. Ich bin mir im Moment nicht so recht im klaren, wie das genaue Verhalten beim ersten Lauf nach Edomi-Neustart am besten sein sollte. Es gibt da ja mehrere Sichtweisen und dementsprechend unterschiedliche Möglichkeiten. Tendentiell würde ich sagen, dass beim initialen LBS-Lauf gar nichts mit dem Behang gemacht werden sollte aber auch das hat gewisse Seiteneffekte.

Was meinst Du bzw. was meint ihr?

[vento66]

im ersten Lauf nichts auf die Ausgänge senden? Müsste natürlich noch einer genaueren Betrachtung unterzogen werden, was das dann für Auswirkungen auf den LBS hat.

[baumhaus123]

Hallo Yves,

ich fände es am besten, wenn der Baustein möglichst genau da weitermacht, wo er aufgehört hat.

Beispiele:
- Baustein war im Zustand Timer für Beschattung läuft --> Neustart --> Timer beginnt von vorne, da die bereits abgelaufene Timerzeit nicht mit über den Neustart gerettet wird (und werden muss)
- Baustein war im Zustand Beschattung --> Neustart --> Nachführung macht weiter (evtl. direkte Berechnung nach Neustart, s.u.)
- wichtig wäre mir auch (und ich weiß nicht genau, wie er sich aktuell verhalten würde): Baustein ist inaktiv --> Neustart --> Baustein ist weiterhin inaktiv

Allgemein fände ich es toll, wenn der Baustein nach Neustart direkt die Berechnung ausführen würde - genauso, wie der Baustein bei Aktivierung auch direkt die Berechnung vornimmt ohne auf einen externen Trigger warten zu müssen (Helligkeit, Azimut etc.).

[tger977]

ich fände es am besten, wenn der Baustein möglichst genau da weitermacht, wo er aufgehört hat.

kann Matthias hier nur recht geben, so wäre das am schönsten.

Tendentiell würde ich sagen, dass beim initialen LBS-Lauf gar nichts mit dem Behang gemacht werden sollte aber auch das hat gewisse Seiteneffekte.

Da wäre ich sehr dafür daß der Baustein ohne Änderung auch beim Init nichts an die Positions-Ausgänge sendet, bzw. dauert es in der Regel auch nie lange bis sich an den Eingängen auch mal wieder was ändert und der Baustein dadurch wieder normal getriggert wird. Momentan werden alle Jalousien die einen Lamellenwinkel >0 eingestellt haben bei einem neuen Projektaktivieren immer einmal zu und wieder aufgefahren (der BMS Aktor macht das leider so...). Wäre schön wenn sich das vermeiden lies, überblicke aber die Konsequenzen und auch den Aufwand dahinter sicher nicht komplett...

Jetzt hoffe ich daß das Wetter mal wieder besser wird und sich die Beschattungsfunktion mal wieder ausgiebig testen lässt

[starwarsfan]

ich fände es am besten, wenn der Baustein möglichst genau da weitermacht, wo er aufgehört hat.

Das ist klar nur eben genau das ist nicht so ganz einfach...

• Baustein war im Zustand Timer für Beschattung läuft --> Neustart --> Timer beginnt von vorne, da die bereits abgelaufene Timerzeit nicht mit über den Neustart gerettet wird (und werden muss)
• Baustein war im Zustand Beschattung --> Neustart --> Nachführung macht weiter (evtl. direkte Berechnung nach Neustart, s.u.)
• wichtig wäre mir auch (und ich weiß nicht genau, wie er sich aktuell verhalten würde): Baustein ist inaktiv --> Neustart --> Baustein ist weiterhin inaktiv

Bei allen drei Beispielen stellt sich die gleiche Frage: Was passiert, wenn sich in der Zwischenzeit die Rahmenbedigungen geändert haben? Keine Sonne mehr auf der Fassade? Keine Dämmerung mehr? Oder oder oder...

Allgemein fände ich es toll, wenn der Baustein nach Neustart direkt die Berechnung ausführen würde - genauso, wie der Baustein bei Aktivierung auch direkt die Berechnung vornimmt ohne auf einen externen Trigger warten zu müssen (Helligkeit, Azimut etc.).

Vermutlich wird sich das nur dadurch sauber lösen lassen, indem weitere Zustände eingeführt werden, also bspw. LOCKED, DEACTIVATED etc. Muss ich (mal wieder) drüber nachdenken...

[tger977]

Bei allen drei Beispielen stellt sich die gleiche Frage: Was passiert, wenn sich in der Zwischenzeit die Rahmenbedigungen geändert haben? Keine Sonne mehr auf der Fassade? Keine Dämmerung mehr? Oder oder oder...

warum reicht es da nicht auf den ersten normalen Trigger durch geänderte Werte zu warten? 99% der Fälle sind doch wahrscheinlich nur ein neues Projektaktivieren (mit max. ein paar Sekunden Zeitraum) da man wieder mal was an einer Logik oder Visu geändert hat --> aus meiner Sicht dort dann unkritisch bis zum nächsten Trigger zu warten. Oder wer macht freiwillig EDOMI für Minuten oder länger aus?

[vento66]

Sehe ich genauso, wenn halt gerade in der Zeit die Sperre gesetzt wird, muss sich der User was überlegen...

[starwarsfan]

Hallo miteinander

warum reicht es da nicht auf den ersten normalen Trigger durch geänderte Werte zu warten? 99% der Fälle sind doch wahrscheinlich nur ein neues Projektaktivieren (mit max. ein paar Sekunden Zeitraum) da man wieder mal was an einer Logik oder Visu geändert hat --> aus meiner Sicht dort dann unkritisch bis zum nächsten Trigger zu warten. Oder wer macht freiwillig EDOMI für Minuten oder länger aus?

Sehe ich genauso, wenn halt gerade in der Zeit die Sperre gesetzt wird, muss sich der User was überlegen...

Jo, das ist schon klar. Die obige Frage ist auch eher sekundär.

Der Punkt ist der initiale Lauf des LBS aber wie es scheint habe ich auch dafür schon eine Lösung gefunden. Ist gerade im Testbetrieb...

[tger977]

Hallo Yves,

irgendwie war grad total der Wurm drin nach einer Projektaktivierung. Alle Jalousien sind auf Durchsicht (100% Höhe und Lamelle auf Durchsicht) gefahren (obwohl alle vorher im Status -1 waren und komplett offen). Bei zwei Jalousien wurde alle 5-10s die Lamelle von auf nach zu und zurück gefahren... Am A8 Ausgang sah ich im Livelog immer wieder ein Toggeln. Irgendwann nach einigen Minuten sind dann wieder alle JAlousien hochgefahren und seit dem ist wieder Ruhe.

Hier mal das Log von einer der beiden Jalousien die in dem Zeitraum ständig die Lamellen gewendet haben:


Vermutlich war auf den Eingängen E68/69 die Durchsichtsposition, sicher rekonstruieren kann ich das nicht mehr. Das würde zumindest das Runterfahren erklären.

Warum nun aber das ständige Bewegen der Lamellen zustande kam versteh ich nicht:
- zuerst Status -1 im Init --> korrekt
- dann erfolgt deaktiverung über External Height change ("LBS disabled through external height change (0 vs 85/115)" Was bedeutet hier 0 vs 85/115?
- 2s später wird der LBS Reaktivert --> von wem/wodurch? (Zeile 27)
- In selbem Lauf kommt es nochmal zu Reaktivierung? --> von wem/wodurch? (Zeile 52) --> irgendeine Schleife im LBS?
- Zeile 77+78 wird der LBS zweimal disabled --> von wem/wodurch?
- Zeile 79 dann direkt im selben Lauf wieder aktiviert?

Irgendwie geht das dann immer wieder so weiter... Für mich alles nicht wirklich nachvollziehbar, vielleicht hilft Dir das Log etwas mehr.

noch eine Idee zum Logfile um die Fehlersuche zu vereinfachen:
Vielleicht macht es Sinn im Log noch die Ausgaben an den Ausgängen zu loggen? Dann kann man da leichter sehen was wirklich durch den Baustein passiert. Ggf. sogar pro Lauf die Eingänge loggen. Dann entfallen auch die Screenshots und man kann genau analysieren wann welcher Eingang/Ausgang wie gesetzt war/wurde und was in welcher Folge wodurch beeinflusst war. Auch entfällt dann ein mühsames KNX Log analysieren und man hat alle Infos zentral im Logfile.