HMIP-BROLL Rolladensteuerung Logikproblem nach Update?

[Germa]

Hallo zusammen,
seit einigen Wochen will mein Rolladensteuerungsprogramm nach manuellem Eingriff nicht mehr so richtig.
Das Programm funktioniert eigentlich zuverlässig. Morgens (Astrofunktion) in Kombination mit Überschreiten der eingestellten Helligkeitsgrenze fährt der Rolladen hoch, abends mit Astrofunktion und Dunkelheit wieder runter. So weit so gut. Die Bedingung Behanghöhe kleiner gleich 0 ist für heiße Sommertage. Fahre ich also den Rolladen durch Tastendruck am Gerät runter ab beispielsweise 40%, soll das Programm nicht auslösen, sonst würde er ja direkt wieder hochfahren.
Genau DAS passiert aber seit einiger Zeit. Warum?

Jetzt kommts: Stelle ich den Wert im Gerät in der CCU Web-UI auf 40%, passiert das nicht und das Programm löst nicht aus!

Was mache ich falsch?

[MichaelN]

Was mich etwas wundert ist, daß ds Rollo morgens überhaupt hochfährt.
Das Programm wird ja nur durch den Trigger "Sonnenaufgang" ausgelöst. Wenn es dann noch dunkler als 20 lx ist, sollte nichts passieren.
Wenn es dann heller wird, passiert auch nichts, da die Hellgiekit auf "nur prüfen" steht.

Aus dem gleichen Grund kann das Programm auch nicht aktiv werden, wenn Du das Rollo zwischenzeitlich verfährst. Es gibt schlicht keinen Trigger, der das Programm startet.

Bitte genauer analysieren, Tips dazu in meiner Signatur unter Debugging.

[Xel66]

Was mich etwas wundert ist, daß ds Rollo morgens überhaupt hochfährt.

Das Programm hat zwei Trigger. Einer im WENN und einer im SONST WENN. Die Bedingungsprüfung eines Programms wird von oben nach unten ausgeführt. Und somit triggert dann die Helligkeit im WENN trotzdem das zugehörige DANN. Der gleiche Pfad fährt vermutlich auch den Rollladen wieder hoch. Mit diesem Programm müsstest Du auch einen erhöhten Duty Cycle haben und die Relais im Aktor regelmäßig (immer dann wenn die Helligkeit aktualisiert wird) klicken. Gegensätzliche Aktionen mit den gleichen Triggern (vor allem mit welchen, die zyklisch gesetzt werden) in einem Programm geht meistens nicht gut. Ein Auftrennen in zwei Programme dürfte helfen.

Gruß Xel66

[MichaelN]

Das Programm hat zwei Trigger. Einer im WENN und einer im SONST WENN

Der löst ja nur bei <5 lx aus. Tagsüber wenig plausibel.

EDIT: manchmal kann ein "bei Änderung" wie "bei Aktualisierung" wirken. Das würde aber eine gründlicher Analyse auch zeigen.
So oder so kann es nicht schaden aus dem SONST-WENN ein eigenes Programm zu machen.

[Xel66]

Der löst ja nur bei <5 lx aus. Tagsüber wenig plausibel.

Die Prüfung auf "bei Änderung" ist entgegen der Darlegungen im Handbuch Teil der Bedingungsprüfung des Programms und wird nicht im Vorfeld geprüft. Wird dieser Wert nun aktualisiert, versucht das Programm einen Vergleich vermutlich mit .LastValue() und trifft bei der normalen Bedingungsprüfung auf die Abfrage auch < 20, die im WENN tagsüber erfüllt sein sollte. Solche Problematiken stellen sich häufig, wenn aus den gleichen Triggern mit unterschiedlichen Werten gegensätzliche Schaltbefehle ausgelöst werden sollen. Klingt nicht logisch - ist aber so.

Gruß Xel66

[Gluehwurm]

Irgendwie hat <= 0 doch immer wieder Probleme gemacht, oder habe ich das falsch in Erinnerung?

[Germa]

vielen Dank für Eure Ausführungen. Mir ist aber schon ganz schwindelig.
Es gab Zeiten, da dachte ich, ich hätte das mit den Triggern und den "wann wird ein Programm ausgeführt" nach endlosen Recherchen kapiert. Wenn ich das von Euch hier so lese, zweifel ich daran aber wieder.
Mir ging es aber eigentlich auch darum, warum der manuelle Eingriff in den HMIP-BROLL per Tastendruck vom Programm ignoriert wird, wo hingegen die Werteänderung der Behanghöhe in der WEB-UI tadellos funktioniert.* Zumal ich ja auch eigentlich noch nie Fehler in der Funktion des Programms hatte (klappt eigentlich jeden Tag zuverlässig).

* edit: was natürlich nicht heißen soll, dass ich nicht gerne Tipps annehme, wie man das Programm logisch sauberer und vor allem für den DC optimaler aufbaut

[Matsch]

Mir ging es aber eigentlich auch darum, warum der manuelle Eingriff in den HMIP-BROLL per Tastendruck vom Programm ignoriert wird, wo hingegen die Werteänderung der Behanghöhe in der WEB-UI tadellos funktioniert.

Wie sollte denn das Programm auf einen "manuellen Eingriff per Wippe" reagieren? Du triggerst doch gar nicht darauf (man kann auf das Tastenereignis in Kanal 1 und 2 triggern!).
Mir ist außerdem nicht wirklich klar, warum du in der WENN-Bedingung einen der 3 Sollwerte (Kanal 4) benutzt und nicht den Istwert in Kanal 3.
Gerade bei Verwendung der virtuellen Kanäle oder Bedienung per Wippe entspricht der Wert in Kanal 4 oft gar nicht der wirklichen Position.

[MichaelN]

entspricht der Wert in Kanal 4 oft gar nicht der wirklichen Position.

Nicht nur oft, sondern in der Regel.

[Germa]

Mir ging es aber eigentlich auch darum, warum der manuelle Eingriff in den HMIP-BROLL per Tastendruck vom Programm ignoriert wird, wo hingegen die Werteänderung der Behanghöhe in der WEB-UI tadellos funktioniert.

Wie sollte denn das Programm auf einen "manuellen Eingriff per Wippe" reagieren? Du triggerst doch gar nicht darauf (man kann auf das Tastenereignis in Kanal 1 und 2 triggern!).
Mir ist außerdem nicht wirklich klar, warum du in der WENN-Bedingung einen der 3 Sollwerte (Kanal 4) benutzt und nicht den Istwert in Kanal 3.
Gerade bei Verwendung der virtuellen Kanäle oder Bedienung per Wippe entspricht der Wert in Kanal 4 oft gar nicht der wirklichen Position.

falsch ausgedrückt. Ich betätige die Wippe und fahre den Rolladen damit manuell auf 30%. Ein paar Sekunden später sorgt das Programm dafür, dass der Rolladen wieder auf 100 fährt. Das sollte aber nicht passieren, da das Programm ja eigentlich genau in dem Fall nicht triggern dürfte, da Bedingung (Behanghöhe <=0 nicht erfüllt ist). Wenn ich aber in der WebUI im Gerät den Wert auf 30% stelle, fährt er dort hin und bleibt da, das Programm greift also nicht ein.

Ich kann im Programm Kanal 3 gar nicht auswählen