LBS 19000145 - Beschattungssteuerung-NG

[starwarsfan]

N'abend miteinander,

sodele, acht Monate vor Weihnachten. Zeit für ein Release!

Die v3.3 ist draussen.

[starwarsfan]

Hi

Ok, Asche auf mein Haupt, ich hab tatsächlich in der externen Vorschaltlogik einen Kopierfehler bei diesen beiden LBS gefunden, der dazu führt daß bei einer Änderung an A8 ein sofortiges Schreiben an E12 erfolgt...

Ach, na schau einer an...

Sorry für die Verwirrung, da war ich zu schlampig bei der Loganalyse!

Macht nix, ist ja auch nicht so ganz trivial...

Wo finde ich denn das Text-Log? Ich hab mir damit auch schwer getan und wär über ein einfaches Textfile ebenfalls dankbar. Ich finde aber im Verzeichnis /usr/local/edomi/www/data/log nur das htm file...

Das musst Du in der Edomi-Hauptkonfiguration aktivieren. gaert würde jetzt vermutlich sagen, "steht auch in der Hilfe":

# ---------------------------------------------------------------------
# Protokollierung
# ---------------------------------------------------------------------
...
# Individual-Logs
# 0 = deaktiviert
# 1 = Text-Format
# 2 = HTML-Format
global_logCustomEnabled=1

[hx5]

Wo finde ich denn das Text-Log?

Ich mach das über Verwaltung->Logdateien->Individuallog mit dem Browser öffnen und dann einfach mit copy&paste...

[tger977]

Hi Yves,

Die "0" ist der am Eingang empfangene Wert. 85/115 gibt den erlaubten Range an, welcher via E16/E17 konfiguriert wird. Du hast also den Wert 0 gesendet. Wäre es ein Wert im Range von 85% bis 115%, hätte sich der Baustein nicht deaktiviert. (115% macht hier nicht wirklich Sinn, ist aber einfach der Ergebnis der Rechnung mit dem vorgegebenen Wert von E16/E17)

Ok, das ist eine gute Info. Da aber über external height nur einmalig der LBS gesperrt wurde ist das nicht das eigentliche Problem.

Du hast also einen der Aktivierungseingänge beschrieben.

Der Deaktivierungseingang E12 wurde zweimal mit 0 beschrieben.

Der Deaktivierungseingang E12 wurde mit 1 beschrieben. Das ist die gleiche Funktion wie bei der vorherigen Meldung, nur der Else-Zweig. Das heisst, Du musst zwangsläufig den Eingang erneut mit einem anderen Wert beschrieben haben, sonst würde dieser Code nicht durchlaufen und die Meldung im Log stehen.

Ok, Asche auf mein Haupt, ich hab tatsächlich in der externen Vorschaltlogik einen Kopierfehler bei diesen beiden LBS gefunden, der dazu führt daß bei einer Änderung an A8 ein sofortiges Schreiben an E12 erfolgt...

Warum ich hier (nun fälschlich...) auf den LBS getippt hatte war die Tatsache, daß das laut log alles in derselben Zeitspanne (in sekunden) passiert. Es ist ja nie in dem Block ein "LBS finished" zu sehen ist (Zeilen 77-103) und das war für mich der Grund der Vermutung daß das im LBS selbst alles im selben LBS Lauf passiert. Wahr wohl falsch von mir interpretiert, da bei LBS deaktivierung nur die eine Logzeile "Disabled LBS" ins Log geschrieben wird, alles weitere sind dann doch neue LBS Durchläufe.

Sorry für die Verwirrung, da war ich zu schlampig bei der Loganalyse!

Wenn Du das Text-Log und nicht das unsägliche Html-Log geschickt hättest, wäre es noch einfacher gewesen.

Wo finde ich denn das Text-Log? Ich hab mir damit auch schwer getan und wär über ein einfaches Textfile ebenfalls dankbar. Ich finde aber im Verzeichnis /usr/local/edomi/www/data/log nur das htm file...

Ich bin mit dem Log auch noch nicht so recht glücklich. Das ist irgendwie auch immer ein Spagat zwischen Log-Menge und dem tatsächlichen Nutzen. Danke für den Input, ich werd' drüber nachdenken.

Ok, danke schon mal für Deine Mühen!

[Teutone]

Danke dir, ich werde wieder testen. Ich versuche mal nicht so kritisch zu sein und die Fehler bei mir suchen;-)

[starwarsfan]

Hallo und guten Abend miteinander

und weiter gehts! Hier die RC6 mit folgender Korrektur:

3.3.RC6 (2017-04-23)

• Handling des initialen LBS-Lauf nach Edomi-Neustart ueberarbeitet. Es werden dabei nun keine Hoehen- bzw. Winkel-Ausgaenge gesetzt.

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!

[starwarsfan]

Hi Andi

- zuerst Status -1 im Init --> korrekt

OK.

- dann erfolgt deaktiverung über External Height change ("LBS disabled through external height change (0 vs 85/115)" Was bedeutet hier 0 vs 85/115?

Die "0" ist der am Eingang empfangene Wert. 85/115 gibt den erlaubten Range an, welcher via E16/E17 konfiguriert wird. Du hast also den Wert 0 gesendet. Wäre es ein Wert im Range von 85% bis 115%, hätte sich der Baustein nicht deaktiviert. (115% macht hier nicht wirklich Sinn, ist aber einfach der Ergebnis der Rechnung mit dem vorgegebenen Wert von E16/E17)

- 2s später wird der LBS Reaktivert --> von wem/wodurch? (Zeile 27)

Das steht doch in der nächsten Zeile:

One of the activation states was refreshed, stoping timer if running and starting LBS to update outputs

Du hast also einen der Aktivierungseingänge beschrieben.

- In selbem Lauf kommt es nochmal zu Reaktivierung? --> von wem/wodurch? (Zeile 52) --> irgendeine Schleife im LBS?

Dito.

- Zeile 77+78 wird der LBS zweimal disabled --> von wem/wodurch?

Der Deaktivierungseingang E12 wurde zweimal mit 0 beschrieben.

- Zeile 79 dann direkt im selben Lauf wieder aktiviert?

Der Deaktivierungseingang E12 wurde mit 1 beschrieben. Das ist die gleiche Funktion wie bei der vorherigen Meldung, nur der Else-Zweig. Das heisst, Du musst zwangsläufig den Eingang erneut mit einem anderen Wert beschrieben haben, sonst würde dieser Code nicht durchlaufen und die Meldung im Log stehen.

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

Wenn Du das Text-Log und nicht das unsägliche Html-Log geschickt hättest, wäre es noch einfacher gewesen.

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.

Ich bin mit dem Log auch noch nicht so recht glücklich. Das ist irgendwie auch immer ein Spagat zwischen Log-Menge und dem tatsächlichen Nutzen. Danke für den Input, ich werd' drüber nachdenken.

[baumhaus123]

@Andi: hast du eventuell eine Logik hinter dem Baustein, die den LBS automatisch wieder aktiviert? Hört sich irgendwie so an...

@Yves: die sofortige Berechnung nach Projektaktierung muss tatsächlich nicht unbedingt sein. Ich hätte nur vermutet, dass es womöglich einfacher zu implementieren ist, da das der Baustein nach Reaktivierung ja auch sofort durchführt. Nur können bei Deaktivierung und Re-Aktivierung ja Stunden liegen, bei Neustart gehts ja ratzfatz...
Das mit neuen Status (Deactivated, locked etc) fände ich klasse...

[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.

[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...

[vento66]

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

[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?

[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]

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

[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.).