MDT JAL-0410M.02R6.0: Verzögerungszeiten bei den Schwellwerten zur Beschattung

[dupre1967]

Hi,

ich habe mir die Beschattungsfunktion ein wenig genauer angesehen und ich bin mir nun nicht sicher, wie ich den Parameter "Verzögerung der Helligkeitsschwelle 2 nach 1" verstehen soll.
Parametriert sind die Standardwerte (30000lx/45000lx/10000lx) und 10/25 Minuten. Der Aktor bekommt jede Minute den Helligkeitswert vom Lichtsensor.
Ich habe das Ganze heute mal per Symcon mitgeloggt und komm auf folgende Beobachtungen:

1) Überschreitet die Helligkeit den Schwellwert 1 so wird im Diagnoseobjekt S0 -> S1 mitgeteilt (in der Symcon werden hier dann 30klx angezeigt).
2) Unterschreitet die Helligkeit den Schwellwert 1 minus Hysterese, so wird sofort wieder S1 -> S0 gesetzt.
3) Überschreitet die Helligkeit den Schwellwert 2, so wird nach 10 Minuten S1 -> S2 gesetzt (in der Sim nach 9 Minuten wegen der Granularität von einer Minute)

Soweit meine Erwartungen.
Überrascht war ich jedoch 14:46, wo der Helligkeitswert von ca. 52klx (S2) auf 18klx abgestürzt ist. Hier erfolgt sofort der Übergang S2 -> S0.
Ich hätte hier erwartet, dass zuerst S2 -> S1 gesetzt wird und dann erst nach 25 Minuten S1 -> S0 erfolgt.
Mir erscheint es nun so, dass die 25 Minuten nur dann zählen, wenn die Helligkeit unter S2 - Hysterese fällt und dann zwischen S1 und S2 liegt, fällt die Helligkeit jedoch unter S1 - Hysterese, so wird sofort S0 gesetzt.
Ist das so von Euch erwartet, oder hab ich irgendwo einen Denkfehler oder Konfigurationsfehler?

[hjk]

Das Verhalten tritt auf, weil zu wenig Helligkeitswerte gesendet werden. Wenn die Zwischenwerte gesendet werden, wird es wie erwartet funktionieren.
Einen derartigen Helligkeitssprung gibt es nicht ohne Zwischenwerte.

[trollvottel]

Naja, Werte können auch nur rein zyklisch gesendet werden, da kann es solche Ausreißer schon geben. Also in dem Fall halt umstellen auf prozentuale Änderung.

[dupre1967]

Interessant, das hatte ich nicht auf dem Schirm.
Mein Ziel war eigentlich gewesen, nicht zu viele helligkeitswerte auf dem Bus zu haben, daher die eine Minute als Zyklus.
Wenn der Aktor also zwischen den 52klx und den 18klx auch nur einen weiteren Wert z.B. 33klx im Bereich S1 bis S2 bekommen hätte, dann hätte es funktioniert und der Timer wäre aktiviert worden?

[hjk]

So ist es.

[ralfs1969]

hjk
Oben im Threadtitel wird beim JAL-xxxxM.02 die Revision R6.0 erwähnt. In der Funktionsübersicht-PDF (Stand 11/2020) von eurer Homepage steht jetzt ganz am Ende dass die Aktoren ab R6.0 per DCA updatefähig sind. Sind die aktuell von euch ausgelieferten Geräte schon R6.0?

[trollvottel]

Mein Ziel war eigentlich gewesen, nicht zu viele helligkeitswerte auf dem Bus zu haben, daher die eine Minute als Zyklus

Das ist auch eine vollkommen valide Vorgehensweise und sehr zu empfehlen. Gerade die Helligkeit ändert sich quasi ständig.

Für den JAL-Aktor musst hier als Workaround für dieses Problem (IMO Bug) halt ne Ausnahme machen. Vielleicht wird's auch gefixt.

[hjk]

hjk
Oben im Threadtitel wird beim JAL-xxxxM.02 die Revision R6.0 erwähnt. In der Funktionsübersicht-PDF (Stand 11/2020) von eurer Homepage steht jetzt ganz am Ende dass die Aktoren ab R6.0 per DCA updatefähig sind. Sind die aktuell von euch ausgelieferten Geräte schon R6.0?

Das steht in der Funktionsübersicht der JAL M mit Fahrzeitmessung.

[ralfs1969]

Ja genau da hatte ich es ja entdeckt. Die Frage war ob die schon ausgeliefert werden.

[hjk]

Die JAL M haben alle R6.0 und sind updatefähig.

[dupre1967]

So ist es.

Kann ich leider nicht bestätigen.

Ich habe nun mal die Helligkeitswerte manuell per ETS gesetzt.
Im Aktor habe ich die Kanalparameter für Beschattung ein / aus auf jeweils 2 Minuten gesetzt, Beschattungsposition 1 ist 10% und Position 2 ist 20%.
Im Aktor habe ich allgemeinen Parameter für S1 -> S2 und S2 -> S1 auf jeweils 5 Minuten gesetzt.

Im Bild Capture2 sind nun zwei Simulationen zu sehen.
Orange ist der vorgegeben Helligkeitswert, Blau ist bei S0 = 0, bei S1 = 30klx und bei S2 = 45klx und Grün ist die Position des Rollos (rechte Skala).

In der ersten wird zuerst die Helligkeit von 19klx auf 40klx gesetzt, wie erwartet S0 -> S1 und zwei Minuten später fährt das Rollo auf 10%.
Dann Helligkeit auf 50klx und 5 Minuten später sehe ich S1 -> S2 und das Rollo fährt auf 20%.
Dann habe ich mehrer Helligkeitswerte unterhalb des Bereiches S2 - Hysterese (35klx) gesendet.
Sobald ich aber einen Wert unterhalb S1 - Hysterese, also 19klx im Beispiel sende, geht sofort S2 -> S0 und zwei Minuten später fahren die Rollos hoch.

Die zweite Simulationn ist so wie es sein soll. Hier warte ich beim Verringern der Helligkeit auf 32klx so lange, bis S2 -> S1 passiert und die Rollos wieder die 10% anfahren. Schreine ich dann 19klx auf den Helligkeitswert, so geht wiederum S1 -> S0 sofort und nach zwei Minuten ist die Beschattung beendet.

Im Bild Capture3 habe ich simuliert, was passiert, wenn ich die Werte ähnlich wie im ersten Beispiel setze, dann aber in den zwei Minuten zum Beschattungsende die Helligkeit wieder ansteigen lasse.
Hier sehe ich, dass sofort wenn die Schwelle für S1 (30klx) erreicht ist, das Rollo auf 10% (naka, hier war es dann inzwischen durcheinander und hat 9% gemeldet) fährt.
Es werden hier also weder die Zeit von 5 Minuten für S2->S1 abgewartet (was ich vermutet hätte), noch wird durch den S0->S1 Übergang die zwei Minuten für Beschattungsstart berücksichtigt.

Mein vorläufiges Fazit ist somit, dass es für die Helligkeitswerte egal ist, ob sie nur minütlich oder bei Änderung gesendet werden.
Einzig die Verzögerungszeit zum Beschattungsende verhindert, dass das Rollo sofort von Pos. 2 komplett hochfährt. Komme ich in dieser Zeit wieder in den Bereich S1 bis S2, so wird sofort Pos 1 angefahren.

[hjk]

Ich müsste mal klären, ob das Verhalten so gewollt ist oder eben nicht. Wir schauen uns das bei Gelegenheit mal an.

[dupre1967]

Bei den Schwellwerten bzw. bei den Timern zur Verzögerung scheint zumindest in der R6.0 Version der Wurm drinnen zu sein.

Der Timer für die Verzögerung von S2 zu S1 wird nicht zurückgesetzt, wenn nach Auslösung die Helligkeit wieder über den Schwellwert für S2 steigt!

Dies bedeutet, dass die Verzögerung nicht den gewünschten Effekt hat, kurzzeitige Verschattungen auszufiltern (die berühmte Wolke am klaren Himmel) sondern nur zu verzögern.

Folgendes habe ich heute morgen simuliert:

Schwelle S1: 30k / Schwelle S2: 60k / Hysterese = 10k
Verzögerung S1 zu S2: 5 Minuten / Verzögerung S2 zu S1: 10 Minuten

In der Simulation steigt zuerst die Helligkeit auf 70k, folglich wird der Timer S1S2 (5 Minuten) gestartet, da kurz darauf es wieder dunkler wird und die Helligkeit unter S2-Hyst. = 50k fällt, wird dieser zurückgesetzt und folglich wird S2 nicht aktiviert und S1 bleibt. Erwartetes Verhalten.
Danach steigt die Helligkeit wieder auf 70k (Start vom Timer S1S2) und fällt danach zwar unter die Schwelle S2, bleibt aber innerhalb der Hysterese. Daher wird nach 5 Minuten S2 aktiv. Erwartetes Verhalten.

Im dritten Abschnitt bleibt die Helligkeit im Bereich S2-Hysterese und S2, von daher findet keine Änderung statt, S2 bleibt, weiterhin erwartetes Verhalten.

Im vierten Abschnitte fällt die Helligkeit von 70k auf 45k, also unterhalb von S2-Hysterese (um 10:06) um dann um 10:10 wieder auf 70k zu steigen.
Hier hätte ich erwartet, dass um 10:06 der Timer S2S1 (10 Minuten) startet und um 10:10 wieder zurückgesetzt wird, da die Helligkeit nun wieder größer als S2 ist.
Stattdessen scheint dieser weiter zu laufen und nach 10 Minuten wird um 10:16 S1 aktiviert, obwohl in den 6 Minuten davor die Helligkeit über S2 ist!.
Da die Helligkeit weiterhin bei 70k bleibt startet wieder der S1S2 Timer und nach 5 Minuten wird wieder S2 aktiviert (10:21).
Ergebnis: Die kurze "Wolke" um 10:06-10:10 führt dazu, dass um 10:16 die Rollos bei nun voller Sonne hochfahren und 5 Minuten später wieder herunterfahren...

Als Workaround bleibt nun fürs erste, entweder nur eine Helligkeitsschwelle zu verwenden und auf S2 zu verzichten, oder über externe Logiken dies nachzubauen und die Schwellwerte in den Aktor zu geben und nicht die Helligkeitswerte.

hjk, könnt ihr Euch das mal anschauen?

[hjk]

Wir schauen uns das an.

[dupre1967]

Einen habe ich noch, leider ☹:

Ich habe nun die Aktoren so konfiguriert, dass die Helligkeitsschwellen von Extern über zwei Gruppenadressen vorgegeben werden.
Wechselt nun der Helligkeit1 Eingang auf "1", so sehe ich im Diagnoseobjekt für die Beschattung S1, passt.
Wechselt nun auch Helligkeit2 auf "1" (also nun beide "1"), so wechselt nach der konfigurierten Zeit (Verzögerung S1 nach S2) im Diagnoseobjekt S1 nach S2, passt.

Wechselt nun aber wieder Helligkeit2 auf "0" (Helligkeit1 weiterhin "1"), so wird die Verzögerungszeit S2 nach S1 nicht beachtet und im Diagnoseobjekt wechselt sofort S2 nach S1 und die Läden bewegen sich. Sollte doch so nicht sein, oder?