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

[mule]

Was ist falsch und wo ist der Fehler im Konstrukt? Es gibt hier kein „Konstrukt“ von mir, sondern es geht um generelle Regeln im Zusammenhang mit single oder multithreading. Aber eventuell könntest Du erläutern was Du meinst?!

[MichaelN]

Ich habe dir einige Hinweise gegeben. Jetzt ist es an dir dies umzusetzen.

[Xel66]

Was ist falsch und wo ist der Fehler im Konstrukt?

Dein Programmaufbau, der eben Deinem Wunschdenken von der Funktionsweise der CCU entspricht aber nicht dem dokumentierten Verhalten.

... generelle Regeln im Zusammenhang mit single oder multithreading.

Ganz einfach, es gibt kein Multithreading und somit auch keine diesbezüglichen Regeln. Das System arbeitet ereignisorientiert und in der im Handbuch beschriebenen Funktionsweise (Prüfung der Bedingungen "von oben nach unten" nachdem getriggert wurde), mit (nach meiner Beobachtung) einer Abweichung in komplexeren Programmen, bei der Prüfung auf "bei Änderung". In einfachen Programmen arbeite die CCU wie beschrieben.

Gruß Xel66

[mule]

Entweder reden wir aneinander vorbei oder ich kann nicht richtig rüberbringen, wo das Problem liegt.

Ich versuche es daher nochmals von Vorne:
- Programm A setzt Variable B auf 1 und Variable C auf 10
. Programm B wird durch Programm A getriggert und setzt Variable B auf 2 und Variable D auf 20
Ergebnis: Variable B wird nie auf 1, sondern nur auf 2 gesetzt.

Bei einem single threading system mit ereignisorientierter Verarbeitung kann die Verarbeitung eigentlich nur streng sequenziell erfolgen.
Dies bedeutet wiederum auch, dass es nie zu einem Konflikt bezüglich des Setzens der Variable B kommen kann, was wiederum bedeutet, dass das Setzen der Variable B sowohl auf 1, als auch auf 2 erfolgen muss (mal die Reihenfolge, ob erst auf 1 und dann auf 2 oder umgekehrt außen vorgelassen).
Dies ist aber eben gerade nicht der Fall. Die Variable B wird nie auf 1 gesetzt, wenn sich Programm A verzögert.
Allerdings werden Variable C auf 10 und Variable D auf 20 gesetzt. Also scheint es doch zu einem Konflikt in Bezug auf Variable B zu kommen, was aber bei einem derartigen single threading system nicht sein kann. Weshalb wird das Setzen der Variable B auf 1 also ausgelassen?

[Matsch]

. Programm B wird durch Programm A getriggert

Durch die Variablenänderung in Programm A oder auf andere Weise?
Woher weißt du, dass die Variable nie 1 annimmt? Kann das auch ein Protokollierungsfehler sein? Warum wird trotzdem Programm B ausgelöst? Dann ja wohl nicht durch Änderung der Variable B!

[MichaelN]

Ein bisschen erinnert mich das an:
https://github.com/jens-maus/RaspberryMatic/issues/1734
Und
https://github.com/jens-maus/RaspberryMatic/issues/1278

[mule]

Programm B wird nicht durch die Änderung der Variable B in Programm A getriggert, sondern durch eine andere Änderung (im konkreten Anwendungsfall durch das Ausschalten eines Aktors).
Leider ist es nicht nur ein Protokoll-Problem, denn ich habe noch ein Programm, welches auf Basis der Variable B triggert und jeweils den Wert der Variable B in einer anderen Variable konkateniert. Der Wert 1 taucht auch hier nicht auf, wenn Programm A aufgrund eines unreachable Aktors verlangsamt ausgeführt wird. Wie gesagt nur wenn A verlangsamt ausgeführt wird. Wenn ich den unreachable Aktor entferne, dann läuft alles so wie es sein soll.

[mule]

Ein bisschen erinnert mich das an:
https://github.com/jens-maus/RaspberryMatic/issues/1734
Und
https://github.com/jens-maus/RaspberryMatic/issues/1278

Ich denke nicht, dass es damit etwas zu tun hat, denn die Programme werden ja ausgeführt/angetriggert, was man ja daran erkennen kann, dass die Variable C auf 10 gesetzt wird. Es wird nur die Variable B nicht auf 1 gesetzt (aber eben auch nur dann wenn Programm A länger braucht)

[MichaelN]

Bisschen unlogisch ist das schon. Da wir davon ausgehen können, daß die Rega immer nur ein Programm nach dem anderen abarbeiten, würde eine Verzögerung durch einen schlecht erreichbaren Aktor ja auch die Abarbeitung aller darauf folgenden Programme verzögern. Daher bliebe die Abarbeitung in der gleichen Reihenfolge. Ich habe aber auch noch nie davon gehört, daß ein Programm so lange "stehen bleibt", bis der Aktor reagiert hat.

Daher kann nihc nur nochmal wiederholen: Problem möglichst weit vereinfachen. So das es "jeder" nachvollziehen kann ohne besondere Hardware. Un dohne kryptische Bezeichner.

Btw: welche von meinen Vorschlägen hast Du schon mit welchen Ergebnissen umgesetzt?

[mule]

@MichaelN:
Ja, in der Tat ist es unlogisch. Ich war im Übrigen auch mehr als überrascht, dass ein unreachable Hm-IP-Aktor ein Programm derart stark verzögert/verlangsamt. Hintergrund ist, dass es sich um einen Aktor handelt, der nur für eine Weihnachtsbeleuchtung zum Einsatz kommt. Nach dessen Außerbetriebnahme bin ich dann auf das Problem gestoßen. Das ist noch eine zweite Baustelle, der ich auf den Grund gehen will.

Zu Deinen Vorschlägen: Ich werde die vorhandene Logik auf komplett anderer Ebene neu umsetzen (entweder baue ich mir einen eigenen TCL-Daemonprozess auf der Raspberrymatic bzw. erweitere einen bereits von mir entwickelten) oder ich setze es per Java-Script unter ioBroker um. HM-Programme und -Scripte sind mir da seit längerer Zeit zu "aufregend" mit ihren ganzen Einschränkungen und Besonderheiten, um noch weiter daran herumzudoktorn.

Ich habe das Ganze hier veröffentlicht, um andere darauf aufmerksam zu machen und weil mein Entwicklerherz solchen "Ungereimtheiten" unbedingt auf den Grund gehen will, um es zu verstehen.

Ansonsten greife ich Deinen Vorschlag gerne auf und werde das Ganze nochmals so simpel wie möglich zum Nachstellen dokumentieren.