[Frage] Trigger und Sendeverhalten nach Restart

[Robert_Mini]

Hallo @S. Kolbinger!

Ich möchte deine Erklärung aus diesem Thema (viewtopic.php?f=8&t=2276&p=25354&hilit= ... uhr#p25354) kurz diskutieren.

Die Zeitschaltuhr an sich hat funktioniert, das Problem war die Sendeoption "C" (on change).
Nach dem Reboot hat der "Ausschalt-Timer" getriggert. Der Ausgang war aber nach dem Reboot auf "false" (default nach Neustart).
Da sich der Zustand nicht geändert hat, wurde auch nichts nach aussen gesendet.

Lösungsvarianten:

1. Persistenz einschalten (Ausgangszustand wird gemerkt)
2. Sendeoption am Ausgang auf "A" setzen (Ausgangswert wird jedesmal gesendet)

Ich verstehe dieses Verhalten zwar, sehe da aber eine Parallele zum ursprünglichen Verhalten des KNX-Stacks.

Ich hatte heute nämlich ein ähnliches Problem: Restart des logic-Services (warum weiß ich nicht??), und die Beschattung hat gestreikt => Ausgang war durch den Restart auf "false" und hat daher das spätere Umschalten auf "false" nicht gesendet => Persistenz muss aktiviert werden.

Bedeutet aber, dass bei allen rein Event-basierten Logiken, die ebenfalls nur auf "on change" senden, Persistenz erforderlich ist.

Ich weiß nicht, ob das realistisch ist, aber korrekterweise sollten die Ein-/Ausgänge der "nicht persistenten" Logiken nicht mit false (bzw. 0 bei float) sondern n/a initialisiert werden, so dass auch bei Empfang von "false" bzw. Ergebnis "false" getriggert bzw. gesendet wird. Gleiches gilt für float 0.0

lg
Robert

[StefanW]

Ich weiß nicht, ob das realistisch ist, aber korrekterweise sollten die Ein-/Ausgänge der "nicht persistenten" Logiken nicht mit false (bzw. 0 bei float) sondern n/a initialisiert werden,

Eine Initialisierung mit "nichts" ist keine Initialisierung. Logiken brauchen einen Startwert. Immer.

Die Entscheidung, welches der Startwert haben soll, haben wir in die Hand des Nutzers gelegt.

1. Entweder der Nutzer gibt einen fixen Startwert vor oder

2. Der Nutzer etzt den betreffenden Eingang auf "inhibit before initialized", dann wird die Logik erst berechnet (das erste mal getriggert) bis ALLE so markierten Eingänge einen Wert von außerhalb erhalten haben.

Auf diese Weise gibt es IMMER klare Verhältnisse. Sei es fest vorgegeben oder die Logik muss darauf warten was passiert. Mit unklaren Verhältnissen "initilaisierung mit nichts" ist gar nichts gewonnen bzw. entspricht dann ohnehin einem impliziten "inhibit before initialized". Ein solches Standardverhalten würde nur dafür sorgen, dass der Nutzer den entsprechenden Haken nicht mehr setzen muss.

lg

Stefan

[Robert_Mini]

Hallo Stefan!

Danke für deine Erläuterung.
Man sieht, es gibt immer noch was zum dazulernen und ich gebe dir hinsichtlich Eingänge absolut recht, da hab ich nicht bis zum Ende gedacht.

2. Der Nutzer etzt den betreffenden Eingang auf "inhibit before initialized", dann wird die Logik erst berechnet (das erste mal getriggert) bis ALLE so markierten Eingänge einen Wert von außerhalb erhalten haben.

Das muss ich doch glatt mal detailliert testen. Meiner Erinnerung nach griff dies nur bis zum trigger des ersten so gesetzten Einganges, das "ALLE einen Werten erhalten" wäre perfekt.

"Vorsichtig" widersprechen muss ich bezüglich Ausgänge. Dort wäre ein n/a bis zum ersten durchrechnen der Logik sehr wohl richtiger, als ein "false", insbesondere im Zusammenspiel mit "sende on change". Ich muss des öfteren Logiken an den Eingängen manuell umsetzen, damit die Logik das false sendet. Heißt im Detail: Ausgang steht nach dem Speichern auf false, Logik wird getriggert und errechnet false, wird aber nicht gesendet, weil gegenüber dem init "false" keine Änderung passiert ist.

Das ist sicher Jammern auf hohem Niveau, aber man schreibt sich so gelegentlich Müll in die Zeitserien usw. => kann man aber durch Abkoppeln etc. vermeiden. Bei größeren Logiken muss man dann auch mehrere Eingänge umsetzen (und nicht vergessen sie zurückzusetzen), damit man eine true-false provoziert. => Beispiel: 8fach UND mit "send on change" => man muss alle 8 Eingänge umsetzen, damit das erste FALSE gesendet wird, und dann wieder zurück.

Persistenz löst das Problem zumindest nach einem Reboot, beim Erstellen und insbesondere Ändern von Logiken aber nicht.

lg
Robert

[StefanW]

Das muss ich doch glatt mal detailliert testen. Meiner Erinnerung nach griff dies nur bis zum trigger des ersten so gesetzten Einganges, das "ALLE einen Werten erhalten" wäre perfekt.

Ich habe es so gewünscht, dass für jeden Eingang, für welches DIES als Eigenschaft gesetzt ist, gewartet wird, bevor die Logik das erste Mal getriggered wird.

Beispiel:

- Logikzelle mit fünf Eingängen

- Bei drei dieser Eingänge ist das "Inhibit before Trigger", also das Warten darauf dass der Wert das erstemal korrekt gesetzt wird, gesetzt

- Logik wird gestartet. Erst wenn beim letzten dieser drei Eingänge ein Wert angekommen ist (Reihenfolge egal) wird die Logik durchgerechnet (sofern nicht parallel noch Sperrobjekte aktiv sind) und je nach eingestelltem Triggerverhalten. Weil wenn beim letzten dieser drei so gesetzten Eingänge zudem festgelegt wäre, dass dieser nicht zum Triggern führen soll, dann wird zwar die initiale Triggersperre für diesen Eingang aufgehoben, aber damit noch nicht die Berechnung getriggert.

===> Daher auf Triggerfähigkeit eines Einganges und den Triggersperren achten.

Den Rest lese ich mir am Abend nochmal durch.


lg

Stefan

[Robert_Mini]

Hallo Stefan!

Hab das grad getestet. In der Tat funktioniert die Startoption inhibit so, dass ALLE Eingänge einen Wert empfangen haben, bevor der Ausgang beschrieben wird.
ABER: Auch hier funkt das "on change" aufgrund des default "false" dazwischen. Testlogik Screenshot unten, AND mit 3 Eingängen auf "i" und "c".

Mit diesem Setup (Ausgang invertiert) schaltet der Ausgang erst auf true, wenn jeder Eingang auch mal true war. Ein false auf alle 3 Eingänge nach dem Speichern triggert den Ausgang nicht auf true! D.h. die Option "on change" ist da stärker als das inhibit, nicht wie du beschrieben hast, dass i das on change beim ersten Aufruf ignoriert.

Wie du es beschrieben hast wäre es perfekt, so wie ich es jetzt getestet habe, ist das aber ein eher ein kleiner Bug.

Das Thema Ausgänge einfach bei Gelegenheit noch in Ruhe lesen. Das ganze eilt nicht.

Anmerkung 2020-07-23 213351.png

lg
Robert