Die Logik von WebUI - Programmen

[PeterAC]

Hallo,

möglicherweise bin ich auf einen Fehler in der Logik gestoßen. Die Logik-Verarbeitung wird ja so erklärt, dass bei Auslösen oder Aktualiserung einer Triggerbedingung das Programm ausgelöst wird, dann aber vom Anfang her abgearbeitet wird, wobei die angetroffenen Bedinungsblöcke wie "nur prüfen" ausgewertet werden, also so, dass Veränderungen dabei keine Rolle spielen und nur der aktuelle Zustand von Bedeutung ist. Weil eine Lüftersteuerung partout immer mit unerwartetem Verhalten überraschte, habe ich versucht mit einem Testprogramm der Sache auf den Grund zu gehen.

Die erste Version besteht aus drei aufeinenanderfolgenden Abfragen, ob ein Wert _X oberhalb eines oberen Schwellwertes (A, 70) ist, danach ober unter einem unteren Schwellwert (B, 30) liegt und, wenn das auch nicht zutrifft, ob er unter einem mittleren Schwellwert (C, 50) liegt. Zuletzt wird noch eine Bedingung geprüft, ob eine weiterer Wert _Y einen Schwellwert (D, 2) erreicht oder über schritten hat.

Beim Test den Programms ergab sich das folgende, weitgehend erwartungsgemäße Resultat:

HM-Logik 1 Resultat.PNG (12.22 KiB) 4299 mal betrachtet

Beim Auslösen der jeweiligen Schwellwert A,B,C in die festgelegte (aktive) Richtung wird die zugehörige Aktion ausgelöst und folgende Teile werden nicht mehr bearbeitet. Wird der Schwellwert entgegen der Richtung (passiv) ausgelöst, läuft das Programm bis zum Test der zweiten Variable weiter. Hat diese statisch den Schwellwertbedingung erfüllt, wird auch hier die zugehörige Aktion ausgelöst. Ist der Schwellwert nicht erreicht, wird die SONST-Aktion ausgelöst. Wird _X verändert , ohne dass sich eine zugehörige Bedingung ändert, oder nur aktualisiert wird überhaupt keine Aktion ausgeführt, also auch nicht die SONST-Aktion.
Bei Veränderungen der Variable _Y werden zunächst statisch die Schwellwertbedingungen für _X geprüft. Nur wenn keine davon erfüllt ist, im Bereich C<X<A gelangt die Abarbeitung bis zum Test von _Y, der dann entsprechend ausgewertet wird. Unerwartet ist, dass diese Bearbeitung aber auch stattfindet, wenn _Y nur aktualisiert wird und dabei keine Schwellwertbedingung von _Y verändert wird (letzte Ergebnisspalte). Die Prüfung auf Veränderung findet also nicht vor dem Aufruf des Programmes statt, sondern anscheinend erst im zugehörigen Bedingungsblock.

Nun werden die beiden letzten SONST-WENN-Blöcke getauscht, d.h. zuerst erfolgt der Test der Variable _Y, danach erst der Schwellwert C:

Auch hier wieder das Ergebnis, das an einer Stelle überrascht:

HM-Logik 2 Resultat.PNG (13.65 KiB) 4299 mal betrachtet

Erwartungsgemäß wird das Auslösen der Schwellwerte A und B in der aktiven Richtung erkannt (findet vor dem Test von _Y statt). Bei passiver Richtung gelangt das Programm zum Test von _Y und verarbeitet auch diesen korrekt.

Wird aber der Schwellwert C ausgelöst wenn die Bedingung _Y>=D erfüllt ist, sollte auch hier die zughörige Aktion ausgelöst werden, denn es ist ja eine statisch erfüllte Bedngung. Tatsächlich wird aber überhaupt keine Aktion ausgelöst, also auch nicht die SONST-Aktion. Wenn _Y>=D nicht erfüllt ist, gelangt die Verarbeitung aber zum Test von _X auf den Schwellwert C.

Die Änderung von _Y zeigt nun, dass erwartungsgemäß bei _X die Schwellwerte A und B statisch ausgewertet werden und Vorrang vor dem Test von _Y haben. Nur im Bereich von C<_X<A erreicht das Programm den Test von _Y. Der SONST-Teil wird nur bei Triggern des Schwellwertes D durch _Y in passiver Richtung erreicht. Wie zuvor, wird das Programm auch von der Aktualisierung von _Y ausgelöst, hier erkennbar aber nur bis zum Test von _Y verarbeitet. Die Feststellung, dass _Y sich nicht verändert hat findet offenbar hier statt und der restliche Teil des Programms wird nicht mehr verarbeitet:

Zusammengfasst:

• Programme werden grundsätzlich von jeder Aktualisierung eines Signals, dass in Auslösebedingungen verwendet wird, ausgelöst. Die Bedingung "Bei Veränderung" spielt dabei keine Rolle.
• Das Programm wird (wie bekannt), vom Anfang her abgearbeitet, wobei die Signale, die nicht das Programm ausgelöst haben (d.h. nicht aktualisiert wurden), wie statische Bedingungen behandelt werden.
• Das Programm wird abgebrochen sobald erkannt wird, dass sich der Zustand der Bedingung des auslösenden Signal nicht verändert (!) hat und alle Bedingungen für dieses Signal das Merkmal "Bei Veränderung" haben. Anscheinend findet dies im ersten Block statt, in dem das auslösende Signal getestet wird.
• Passiv ausgelöste Triggerbedingungen werden wie eine statisch nicht erfüllte Bedingung behandelt, so dass das Programm mit dem folgenden Block fortgesetzt wird.
• Es gibt in diesem Konzept keine Erklärung dafür, warum bei Auslösen der Schwelle C im 2. Programm die Bedingung _Y>=D nicht erkannt wird.

Legende:
Die Zeilen der Tabellen repäsentieren den jeweiligen Programmblock, die Spalten die ausgelöstgen Triggerbedingungen. Die grünen Felder stehen in der Zeile mit der ausgelösten Aktion. Im Feld ist dabei vermerkt, welche Bedingung die jeweils andere Variable dabei haben muss. Die Spalten mit drei Übergangssymbolen bedeuten, dass der Wert beliebig aktualisiert wurde, ohne dass dabei ein Schwellwert ausgelöst wurde.

Legende.PNG (4.81 KiB) 4294 mal betrachtet

Hoffe, dass es nützlich ist.

[Gluehwurm]

Hab nicht alles durchgelesen. Wenn ich mir aber die Programme anschaue, dann macht <=30 und <=50 keinen Sinn. Das ist ein doppelter Auslöser.

Gruß
Bruno

[PeterAC]

Auf die Reihenfolge kommt es an.

Erst >70, dann < 30, falls das nicht anspricht < 50.

Ob es klug ist, solche Programme überhaupt zu machen ist noch eine andere Frage. Das hier solte dazu dienen die ablaufenden Mechanismen sichtbar zu machen und zu verstehen.

VG,
Peter

[JRiemann]

Hallo!
Es ist sehr lobenswert das Du Dir mit diesem Beitrag viel Mühe gemacht hast. Aber leider ist es sehr sehr viel Text welcher zum Teil auch noch sehr unverständlich formuliert ist. Die meisten Helfer werden das alles nicht lesen und höchstens überfliegen. Aber selbst beim Überflug ist zu erkennen das Du die Logik der CCU noch nicht komplett verstanden hast. Zumindest lese ich das aus Deinen teils komplexen Beschreibungen heraus. Als Beispiel Deine Zusammenfassung:

Programme werden grundsätzlich von jeder Aktualisierung eines Signals, dass in Auslösebedingungen verwendet wird, ausgelöst. Die Bedingung "Bei Veränderung" spielt dabei keine Rolle.

Diese Aussage ist in dieser Form grundsätzlich falsch.
Wird im WENN bei einem Objekt "bei Aktualisierung" gesetzt, dann führt jede Aktualisierung der Bedingung dieses Objekts zum Durchlauf des Programms. Dabei spielt es keine Rolle ob die Bedingung der Zeile (z.b. Temperatur 25 Grad) sich bei der Meldung verändert oder nur ein bestehender Wert erneut gemeldet wird. Temperatursensoren senden z.B. ca. alle 6 Minuten den aktuellen Status. Dies wird dann als "bei Aktualisierung" behandelt und der Programmdurchlauf angestoßen.

Wird im WENN bei einem Objekt "bei Änderung" gesetzt, dann führen Änderungen der Bedingung dieses Objekts zum Durchlauf des Programms. Hierbei ist aber auch die Formulierung der Bedingung entscheidend.
WENN > Temperatur größer 25 Grad --- Auslöseschwelle ist hier 25 Grad. Ausgelöst wird sobald diese Schwelle in irgendeine Richtung übersprungen wird. Also z.B. Wechsel von 24 auf 26 oder Wechsel von 26 auf 24 Grad. Somit ergibt die Bedingung dieses Beispiels 2 mögliche Auslöser!
Werden Wertbereiche als Bedingung definiert (z.B. Temperaturbereich 20 bis 30 Grad) dann bilden der obere und der untere Wert jeweils eine eigene Auslöseschwelle ab. Somit ergibt die Bedingung dieses Beispiels 4 mögliche Auslöser!
Nicht ausgelöst wird bei Änderungen der Temperatur unterhalb oder oberhalb der Schwelle sowie innerhalb des definierten Bereichs (20 Grad bis 30 Grad).
Meine Beispiele zeigen allerdings nur einen Teil der möglichen Definitionen.

Wird im WENN bei einem Objekt "nur prüfen" gesetzt, dann führt diese Zeile niemals zu einem Durchlauf des Programms.

Das Programm wird (wie bekannt), vom Anfang her abgearbeitet, wobei die Signale, die nicht das Programm ausgelöst haben (d.h. nicht aktualisiert wurden), wie statische Bedingungen behandelt werden.

Das ist zum großen Teil richtig.
Ein Programmdurchlauf startet immer in der ersten Zeile des Programms. Dabei ist es absolut egal in welchem Bereich des Programms der Auslöser sich befindet! Somit könnte z.B. die letzte Zeile im Programm einen Auslöser enthalten.
Sobald der Durchlauf startet werden alle Zeile in allen WENN-Blöcken des Programms behandelt als wären sie auf "nur prüfen" gesetzt.
Geprüft wird jetzt nur ob die Bedingung einer Zeile zum Prüfzeitpunkt erfüllt ist. (z.B. Temperatur größer 25 Grad).
Ist die Bedingung der geprüften Zeile richtig (also z.B Temperatur größer 25 Grad) dann wird der Durchlauf in der nächsten Zeile fortgesetzt. Sollte die Bedingung einer Zeile im Block aber nicht erfüllt sein, dann wird die Überprüfung dieses WENN-Blocks beendet. Der Programmdurchlauf wird nun im nächsten SONST-WENN-Block fortgesetzt. Folgt aber statt eines SONST-WENN-Blocks nur ein SONST, dann wird dieses SONST ausgeführt. Sind alle Bedingungen des aktuell zu prüfenden Blocks erfüllt, dann wird das folgende DANN abgearbeitet.
Der Programmdurchlauf wird beendet falls kein WENN-Block gefunden wird in dem alle Bedingungen erfüllt sind. Ein ausgeführter DANN-Block oder SONST-Block führt auch zu Beendigung des Programms. Dabei ist es egal welche weiteren noch nicht durchlaufenen Blöcke das Programm noch enthält!!

Das Programm wird abgebrochen sobald erkannt wird, dass sich der Zustand der Bedingung des auslösenden Signal nicht verändert (!) hat und alle Bedingungen für dieses Signal das Merkmal "Bei Veränderung" haben. Anscheinend findet dies im ersten Block statt, in dem das auslösende Signal getestet wird.

Diese Aussage ist komplett falsch.
Ist ein Programmdurchlauf gestartet werden die Merkmale "bei Aktualisierung" und "bei Änderung" absolut irrelevant für den weiteren Durchlauf. "bei Aktualisierung" und "bei Änderung" werden nun wie "nur prüfen" behandelt. Ausschließlich die Bedingung der geprüften Zeile (z.B. Temperatur größer 25 Grad) ist nun wichtig für den weiteren Ablauf. Ist die Bedingung der geprüften Zeile erfüllt wird die Prüfung mit der folgenden Zeile fortgesetzt. Ist die Bedingung nicht erfüllt wird der aktuell WENN-Block verlassen und die Prüfung im folgenden SONST-WENN-Block fortgesetzt. Folgt statt eines SONST-WENN-Blocks ein SONST, dann wird dessen Aktion ausgeführt. Die Merkmale "bei Aktualisierung" und "bei Änderung" haben keinerlei Einfluss darauf ob ein Programm beendet wird oder nicht.
Der Programmdurchlauf wird beendet falls kein erfüllter WENN-Block/SONST-WENN-Block gefunden wird. Ein ausgeführter DANN-Block oder SONST-Block führt auch zu Beendigung des Programms. Dabei ist es egal welche weiteren noch nicht durchlaufenen Blöcke das Programm noch enthält!!

Passiv ausgelöste Triggerbedingungen werden wie eine statisch nicht erfüllte Bedingung behandelt, so dass das Programm mit dem folgenden Block fortgesetzt wird.

Diese Aussage verstehe ich absolut nicht! Was ist damit gemeint?
Passive Auslöser gibt es nicht!
Programmdurchläufe werden im nächsten SONST-WENN fortgesetzt sobald im aktuell zu prüfenden Block eine Bedingung nicht erfüllt ist.

Es gibt in diesem Konzept keine Erklärung dafür, warum bei Auslösen der Schwelle C im 2. Programm die Bedingung _Y>=D nicht erkannt wird.

Irgendwie sehe ich den Sinn dieser Programme nicht. Die Objekte sind auch extrem "unleserlich" benannt. Aussagekräftige Namensgebung würde das lesen der Programme sehr erleichtern!
Außerdem bearbeitest Du zwei unterschiedliche Aktionen (setzen und prüfen x und setzen und prüfen y) in einem Programm. Das führt zwangsläufig sehr schnell zu unerwünschten Abläufen. Getrennte Programme für x und y mindern das unerwünschte Verhalten beträchtlich. Die Erklärung warum Zeile 3 nicht erreicht wird könnte folgende sein: Das Programm 2 erreicht die Zeile Y größer oder gleich 2 nur wenn zum Zeitpunkt des Durchlaufs X einen Wert zwischen 30 und 70 hat. Ist das der Fall?
Denn: Wenn bei Programmdurchlauf ab er ersten Zeile Block 1 oder Block 2 eine wahre Bedingung enthält wird das dazugehörige DANN ausgeführt und der Programmdurchlauf beendet. Zeile 3 wird also nicht mehr überprüft.
Beim schreiben von Programmen kann die Reihenfolge der WENN-Blöcke extremen Einfluss auf das Ergebnis haben. Darum werden komplexe Programme auch schnell unübersichtlich und unberechenbar. Außerdem machen viele verschiedene Auslöser in einem Programm den Ablauf nochmals komplizierter. Gerade als Anfänger sollte man lieber auf kurze überschaubare Programme bauen.

Grüße!
Jörg

[PeterAC]

Hallo Jörg,

vielen Dank für Deinen noch längeren Artikel. Es ist sicher am besten, nicht alles auf einmal zu beantworten, sondern Schritt für Schritt vorzugehen.

Programme werden grundsätzlich von jeder Aktualisierung eines Signals, dass in Auslösebedingungen verwendet wird, ausgelöst. Die Bedingung "Bei Veränderung" spielt dabei keine Rolle.

Diese Aussage ist in dieser Form grundsätzlich falsch.

Beide Beispielprogramme enthalten keine Bedingungen mit "Bei Aktualisierung auslösen". Vielleich habe ich etwas übersehen, aber dann kann man sicher zunächst das Verhalten des 1. Beispielprogramms in Bezug auf das Signal Y (letzte Spalte der Tabelle) erklären (ich lasse jetzt mal die _Unterstriche weg):

• X = 72 (z.B.), wird nicht verändert auch nicht aktualisiert
• Y = 1 (z.B.) wird aktualisert und dabei nicht verändert
• DANN-Block der 1. WENN-Bedingung (X>=70) wird ausgelöst.

Dasselbe passiert auch, wenn Y so verändert wird, dass dabei der Schwellwert 2 weder über- noch unterschritten wird.

Der allgemeinen Theorie folgend (die ich natürlich kenne), dürfte eigentlich nichts passieren, weil keine der definierten Bedingungen verändert wurde. Leider ist das Resultat anders, nämlich wie oben dargestellt.

Übrigens hatte ich im Orignal erläutert was ich abkürzend unter aktiv und passiv verstehe:
Aktiv: Ist die Bedingung z.B. X > 70 "Bei Veränderung auslösen", ist ein aktive ausgelöster Trigger der Übergang von <= 70 nach > 70. Da das Programm auch beim Übergang von >70 nach <= 70 ausgelöst würde, dabei aber der zugehörige DANN-Block nicht ausgelöst wird, nenne ich das einen passiv ausgelösten Trigger, der zum Fortschreiten zum nächsten Bedingungsblock führen sollte.

Das ist fürs erste mal genug, VG,
Peter

PS: Ich glaube hier liegt ein Missverständnis vor. Die Beschreibung und die angegebenen Tabellen sind nicht Ergebnis etwaiger "theoretischer Überlegungen", sondern die Ergebnisse mühsamer Tests, um herauszufinden, was die HM-Logic in bestimmten Fällen tatsächlich macht. Ich kann leider nichts dafür, wenn das nicht der allgemeinen Theorie entspricht.

[JRiemann]

• X = 72 (z.B.), wird nicht verändert auch nicht aktualisiert
• Y = 1 (z.B.) wird aktualisert und dabei nicht verändert
• DANN-Block der 1. WENN-Bedingung (X>=70) wird ausgelöst.

Dasselbe passiert auch, wenn Y so verändert wird, dass dabei der Schwellwert 2 weder über- noch unterschritten wird.

Bist Du Dir sicher das wirklich die y-Zeile den Programmdurchlauf auslöst?
Wenn x zum Zeitpunkt des Durchlaufs auf 72 stand und nicht geändert oder aktualisiert wurde, dann kann nur y den Programmdurchlauf ausgelöst haben. Das dürfte aber nicht passieren wenn der Wert 2 nicht erreicht oder überschritten wurde.
Es gibt häufiger Fälle bei denen die CCU "bei Änderung" mit "bei Aktualisierung" verwechselt. Oft sind dabei Temperatursensoren oder ähnliches beteiligt. Auch Systemvariablen als Auslöser in der ersten Zeile eines WENN-Block verursachen in seltenen Fällen Probleme.
"Alchy" hat vor einigen Tagen ein Skript veröffentlicht mit dem man den Auslöser eines Programms protokollieren kann. Das wäre für Deine Tests sicher hilfreich.
Das Programm löschen und identisch neu schreiben (nicht kopieren!) sollte eine verdeckte Fehlfunktion beheben. Ich würde außerdem für y ein eigenes Programm schreiben.
Das Programm 1 und Programm 2 sollten auch nicht gleichzeitig aktiv sein!

[PeterAC]

Ich bin ganz sicher. Man sieht es sowohl am Zeitstempel des Programms, als auch daran, dass DANN-Aktionen ausgelöst werden, bzw. am Zeitstempel der Variable die in der ausgelösten DANN-Aktion beschrieben wurde. D.h. mindestens ein Teil des Programms wird wie bekannt mit der Interpretation "Nur Prüfen" der Bedingungen durchlaufen, auch wenn sich keine Bedingungen verändert haben.

Das trifft aber nicht zu, wenn der Block eine Bedingung für das tatsächlich auslösende Signal enthält. Wird dabei festgestellt, dass sich die Erfüllung der Bedingung nicht verändert hat, wird an dieser Stelle das Programm sofort verlassen, ohne den DANN-Block auszuführen, und auch nicht den SONST-Block. Das scheint immer beim ersten Block zu passieren, der das auslösende Signal behandelt, wobei dabei auch Bedingungen von evtl. folgenden Blöcken, die dasselbe Signal betreffen, berücksichtigt werden.

Wird das Signal bereits im ersten Block getestet und als inaktiv erkannt, auch in Hinblick auf entsprechende Bedingungen in späteren Blöcken, wird kein Programmteil ausgeführt, was so aussieht, als wäre es überhaupt nicht aufgerufen worden, entsprechend der allgemeinen Theorie. Der Zeitstempel zeigt aber an, dass es aktiviert wurde.

Ist es jedoch ein Signal, dass zum ersten Mal in einem Block weiter unten getestet wird, werden alle vorherigen Blöcke, die andere, nicht veränderte Signale testen, mit einer statischen Auswertung bearbeitet. Falls davon eine Bedingung erfüllt wurde, wir der zugehörige DANN-Block ausgeführt und das Programm regulär verlassen, der Test des inaktiven Signals findet gar nicht mehr statt. Das zeigen die Testergebnisse und dürfte nach bisherigem Verständnis der HM-Logik eigentlich nicht stattfinden.

Varianten mit "Bei Aktualisierung auslösen" habe ich bisher nicht getestet. Ich vermute aber, dass sie erwartungsgemäß auch in jedem Fall das Programm auslösen, wobei aber jeder WENN- und SONST-WENN-Block statisch ausgewertet wird, was das Nachvollziehen des Programmablaufs erleichtern dürfte.

Ich hatte gehofft, dass es mit einer aktualisierten Analyse der Logikverarbeitung (sozusagen die "Weltformel der HM-Logik") möglich sein könnte, auch komplexerer Programme zu beherrschen. Da ich aber auf einen Fall (rote Kästchen) gestoßen bin, der weder von der bisherigen noch mit meiner Logik-Interpretation beschrieben wird, sondern vermutlich auf einen Bug hinweist, werde ich es wohl wieder aufgeben, da es unsicher ist, ob es noch mehr solcher unerwarteten "Sonderfälle" gibt. Leider sind dabei selbst kleine Änderungen bei komplexeren Auslösebedingungen "unberechenbar".

Die sicherste Vorgehensweise ist bestimmt, wie auch beschrieben, in jedem Programm nur ein einziges Signal zu verarbeiten, am besten sogar nur eine Bedingung. Leider wird dadurch die Anzahl der Programme schnell groß, was ich vermeiden wollte. Bei mir laufen derzeit 104 Geräte mit 44 Programmen und CCU2-Auslastung von < 10%.

Ich werde dennoch wohl die Signalauswertung und die Durchführung der Aktionen auf getrennte Programme aufteilen. Eine Zahl kleiner Programme akualisiert auf das jeweilige Signal hin eine Code-Variable (ähnlich wie bei einer Windows-Message-Queue), die anzeigt, welche Bedingung getriggert wurde. Die Aktualisierung der Code-Variable triggert das eigentliche Aktions-Programm, in dem nur noch die Code-Variable ausgewertet wird. Das entspricht dann weitestgehend der CASE-Anweisung klassischer Programmiersprachen.

VG,
Peter

[manfredh]

Da ein (ergänzendes) Bild manchmal mehr sagt, als tausend Worte, hier mal ein kommentierter Screenshot, der die Logik des Starts und der Abarbeitung von WebUi-Programmen verdeutlichen soll:

[serial_123]

Hi,

ich verzweifle etwas an der Logik von Programmen. Ich möchte, dass bei anhaltender Öffnung einer Tür (hier 10 Sek) ein Hinweis über den mp3 Gong ausgegeben wird. Sofern die Tür jedoch vor Ablauf der 10 Sek wieder geschlossen wird, soll die Durchsage ausbleiben. Leider spielt der Gong beim angefügten Programm immer den Hinweis ab. Lediglich wenn die Tür im Moment des Abspielens geschlossen wird, wird auch die Durchsage abgebrochen.

Hat jemand einen Rat?

Danke
serial_123

[DrTob]

Das Setzen auf "aus" bricht die Verzögerung der "Kanalaktion" nicht ab. Das würde nur eine andere Kanalaktion.
Gehe über eine Systemvariable.