Setzen einer Systemvariablen wird "verschluckt" (bei verlangsamter Programmausführung)

[mule]

Folgendes Problemszenario:

Vorweg: Bei den beigefügten Programmen handelt es sich um Testprogramme, um das Problem zu reproduzieren, also bitte nicht auf "Schönheit" achten.

Im Programm "Licht aus" werden diverse Aktoren ausgeschaltet, so auch der Aktor "WOHNEN.WasserspielTerassenleuchte:Terassenleuchte".
Außerdem wird die Systemvariable "Beschattung Szenarien" auf den Listenwert "S: Küche" gesetzt.
Durch das Ausschalten des Aktors "WOHNEN.WasserspielTerassenleuchte:Terassenleuchte" wird der 1. Dann-Zweig im Programm "Sync" getriggert, da die Variable "Rolladen Nachtmodus" auf "aktiv" steht. In diesem Dann-Zweig wird dann die schon zuvor genannte Variable "Beschattung Szenarien" erneut gesetzt (auf "S: Garten-LichtAus"). Außerdem wird zu Prüfzwecken, dass auch wirklich der 1. Dann-Zweig durchlaufen wird die Variable "Test" auf "Wert 2" gesetzt.
Zusammenfassend wird die Systemvariable "Beschattung Szenarien" also durch das Starten des Programme "Licht aus" und das anschließend getriggerte Programm "Sync" nacheinander auf zwei unterschiedliche Werte gesetzt ("S: Küche" und "S: Garten-LichtAus").
Das funktioniert solange, solange im Programm "Licht aus" nur Aktoren enthalten sind, die reachable sind, denn dann läuft dieses Programm innerhalb kürzester Zeit durch. Ist aber ein Aktor "unreachable" (in meinem Problemfall steckt hinter dem Aktor "GARTEN.Grillhuetteleuchte:2" ein HmIP-FSM welcher nicht am Strom angeschlossen ist), dann verzögert sich die Programmausführung des Programms "Licht aus" erheblich (laut Systemprotokoll benötigt das Ganze dann ca. 22 Sekunden) und es geschieht Folgendes:
Die Systemvariable "Beschattung Szenarien" wird nicht mehr auf zwei unterschiedliche Werte gesetzt, sondern nur noch auf einen Wert ("S: Garten-LichtAus"). Der Wert "S: Küche" wird einfach "verschluckt". Siehe Screenshot des Systemprotokolls.

Noch "witziger" wird es, wenn man noch ein drittes Trigger-Programm hinzufügt, welches ebenfalls die Systemvariable "Beschattung Szenarien" setzt. Auch dann wird die Systemvariable nur 1x gesetzt und zwar mal auf dem Wert aus dem ersten Trigger-Programm und mal aus dem letzten.

Meine Vermutung ist, dass das Ganze mit dem Single-Threading der Rega zusammenhängt. Aber dennoch hätte ich nicht erwartet, dass Änderungen an Systemvariablen einfach ignoriert/verschluckt werden, wenn die Ausführung von Programmen sich verzögert und zudem es anscheinend reine Willkür ist, welcher Wert anschließend in der Systemvariable landet.

Hat jemand irgendeine Idee? Ist das schlicht ein Bug oder per Design so?

Systemprotokoll

Systemprotokoll.png (15.11 KiB) 422 mal betrachtet

Programm "Sync"

Programm "Licht aus"

[Matsch]

Zunächst mal triggerst du insgesamt 3mal auf das gleiche Ereignis, das ist schonmal Quatsch.
Es reicht völlig, auf den Schaltzustand im WENN mit "bei Änderung" zu reagieren. Dann sollte in allen anderen WENNs nur noch geprüft werden.

Aber auch diese Abfragen sind fragwürdig, weil ja wohl nur die beiden Zustände Ein und Aus möglich sind und im Aus-Fall immer zum SONST-WENN gelaufen wird. Eine erneute Bedingung dort "Testen auf Aus" ist also überflüssig, genauso wie das vielfache Triggern des Programms.

[MichaelN]

Und warum ist das DANN leer?

Und "nur prüfen" triggert nichts

Kurz gefasst : das was du beschreibst und was du zeigst passt nicht zusammen.

Und für ein vereinfachtes test Programm ist es noch viel zu komplex. Wer soll sich die komischen Bezeichner merken?

[Matsch]

Und warum ist das DANN leer?

Durchaus korrekt, mache ich auch oft so, wenn ich unzulässige Zustände gleich mal aussortieren will, bevor es zu den eigentlichen Bedingungen geht.
Wenn man natürlich SONST_WENN nicht nutzt, wird es nicht gebraucht.

[mule]

Wie schon geschrieben geht es hier nicht um die "Schönheit" der Programme, sondern um das beschriebene Problem, dass es durch die verlangsamte Ausführung eines Programmes dazu kommt, dass eine Systemvariable sozusagen "parallel" beschrieben werden soll, was anscheinend in einen mehr oder minder undefinierten Zustand führt.

Durch die Rega wird im Übrigen nicht "3-Mal" getriggert. Der Code ist so für mich schlicht besser lesbar. Aber wie gesagt ist der Aufbau der Programme für das Problem irrelevant und das Ganze ist so nur zur Reproduktion des eigentlichen Problems entstanden.

[MichaelN]

Aber wie gesagt ist der Aufbau der Programme für das Problem irrelevant

Da wäre ich nicht so sicher.

Der Code ist so für mich schlicht besser lesbar

Für mich nicht. Daher mein Vorschlag das Beispiel so weit abzuspecken, dass es leicht nachvollziehbar ist und immer noch das Problem auslöst.

Ich meine, du willst doch vermutlich eine Lösung. Also sollte es in deinem Interesse sein die Anzahl der Rezipienten zu maximieren.

[MichaelN]

Also was du beobachtest ist eine "race condition". Eher typisch für parallel arbeitende Systeme. Denn dann kannst du nie garantieren welcher Thread zuerst fertig ist. Das musst du per Design berücksichtigen.

D. h. dafür sorgen das solche Situationen nicht eintreffen oder die Reihenfolge eben egal ist.

Was würde ich machen? Ich würde zum einen den problematischen Aktor ans Ende der Reihenfolge stellen, evt sogar indirekt über verzögerte Systemvariable schalten.

Du kannst auch versuchen die Szene durch Verzögerung zu einer definierten Reihenfolge zu zwingen.

Oder ganz brutal, du schreibst die Szenen per Skript fortlaufend in eine Text Variable und arbeitest diese (mit passenden Skript) Stück für Stück ab.

[MichaelN]

Ach ja, ganz Vergessen

Als erstes würde ich den Haken für "retriggern" raus nehmen. Der führt nämlich definitiv dazu das verzögerte Befehle gelöscht werden.

[mule]

Danke für Deine Tips. Klar kann ich das Ganze umgehen, mir geht es in diesem Thread aber eigentlich um die Ursache und ob es eher ein Bug oder schlicht per design so ist?
Auch wenn die Rega single threaded arbeitet würde ich eigentlich erwarten, dass derartige Dinge per Queues gelöst werden. Es sollte beim triggern von Programmen eigentlich nicht sein, dass Informationen verloren gehen oder es zu undefinierten Zuständen kommt.

Und schon gar nicht sollte Folgendes passieren:
- Programm A setzt Variable X auf 1 (und läuft sehr langsam)
- Dies triggert Programm B, welches Variable X auf 2 setzt
- Dies triggert Programm C, welches Variable X auf 3 setzt
- Ergebnis in Variable X nachdem Programm A durch ist: Mal 2 und mal 3.

Ich könnte es ja noch verstehen, wenn die Queue so aufgebaut ist, das innerhalb eines bestimmten "Command-Queue-Fensters" immer nur der letzte/aktuellste Wert genommen wird, aber mal ein Zwischenwert und mal der letzte/aktuellste macht schlicht keinen Sinn, da dies ein undefinierter Zustand wäre.
Es gibt im obigen Beispiel eine klare Trigger-Hierarchie und gerade bei einer single threaded Rega würde ich da klar erwarten, dass X nacheinander die Zustände 1,2,3 annimmt. Bei komplett paraller Verarbeitung könnte es natürlich anders sein. Für mich sieht es irgendwie nach einem Mix aus paralleler und nicht paralleler Verarbeitung aus.

p.s.: Das Entfernen von Retriggern hatte ich auch als "verzweifelten" Versuch getestet. Hat aber nichts geändert, was eigentlich auch klar ist, da dies ja nur dann zum Tragen kommt, wenn das identische Programm mehrfach läuft, da sich das Retriggern ja auf den jeweiligen Zweig im jeweiligen Programm bezieht. Aber keines der Programme läuft ja mehrfach und so kann auch auch nichts retriggern.

[MichaelN]

Hat aber nichts geändert, was eigentlich auch klar ist, da dies ja nur dann zum Tragen kommt, wenn das identische Programm mehrfach läuft, da sich das Retriggern ja auf den jeweiligen Zweig im jeweiligen Programm bezieht.

Falsch.

schlicht per design so ist?

Die Rega ist Trigger gesteuert. Und der Design Fehler steckt in deinem Konstrukt.