Inhalt dieser Seite

Einführung

Eine Logik-Zelle wird nur ausgeführt, wenn sie von einem Trigger dazu aufgefordert (d.h. “ausgelöst”) wird. Umgekehrt wird eine Logik-Zelle jedes Mal ausgeführt, wenn sie ausgelöst wird. Dies kann aber unerwünscht sein, z.B. wenn während einem bestimmten Zeitraum ein bestimmter Zustand erhalten bleiben soll. Dementsprechend haben Trigger eine wichtige Bedeutung denen sich der Nutzer bewusst werden sollte

Mögliche Trigger sind:

• jeder Wertübergabeeingang (in Logiken meist mit “Input x” bezeichnet), sofern seine Triggerfunktion auf A (always) oder C (on Change) gesetzt ist (näheres sogleich);

• ein spezieller Triggereingang, der abhängig von einem äußeren Ereignis die Logik-Zelle triggert; als solche Trigger dienen können

  • ein Zeitintervall (bspw. alle 30 Sekunden),

  • ein Zeitpunkt (bspw. 08:25 Uhr) oder

  • ein zusätzliches Eingangsobjekt, dass als bloßer Trigger dient (“Data Value”);

• eine Sendeverzögerung an Ausgängen, diese triggern die Logik-Zelle ebenfalls nach Ablauf der eingestellten Verzögerungszeit.

• jeder Ablauf eines Timers führt zum Triggern der Logik. Dadurch wird bei den Bausteinen Timer/Taktsignal auch nach Ablauf der Verzögerungszeit die Logik-Zelle neu getriggert. Das gleiche gilt für alle Zeitfunktionen, die in Custom Logiken verwendet werden.

Triggerfunktionen über einen Wertübergabe-Eingang

Funktionsbeschreibung

Jeder Wertübergabe-Eingang kann drei unterschiedliche Triggerfunktionen annehmen:

• Einstellung “A” (always): Der Eingang triggert jedesmal die Logik-Zelle, wenn am Eingang ein Wert empfangen wird (auch wenn es ein wiederkehrender Wert ist).

• Einstellung “C” (on change): Der Eingang triggert die Logik-Zelle nur, wenn sich der soeben empfangene Wert vom letzten empfangenen Wert unterscheidet.

• Einstellung “U” (update): Der Eingang triggert die Logik-Zelle nie, d.h. sein Wert wird einzig an die Logik-Zelle (genauer gesagt an die dem Eingang zugeordneten Variable ) übergeben; die Ausführung der Logik-Zelle erfolgt erst, wenn ein Trigger an anderer Stelle dies auslöst.
  Die Einstellung "U" wir zum Beispiel dann verwendet, wenn der Ausgang einer Logik nur periodisch gesendet werden soll (zeitlicher Trigger) oder wenn ein Objekt mehrfach an eine Zelle angeschlossen ist (siehe weiter unten FORTGESCHRITTENE).
  

Einstellung des Triggerverhaltens in der GUI

Die GUI stellt die aktuell eingestellte Triggerfunktion des jeweiligen Eingangs dar und lässt diese auch ändern.

Triggerfunktion über einen Zeitintervall-Auslöser

Oft ist es gewünscht, eine Logik-Zelle regelmäßig in einem bestimmten Rhythmus durchlaufen zu lassen. In solchen Fällen muss ein Zeitintervall-Trigger angewendet werden. Damit wird in Kombination mit der Sendeoption “t” (on timer) ein “zyklisches Senden” erreicht.

Einstellung eines Zeitintervall-Triggers in der GUI

In der GUI kann dies erreicht werden, indem ein Trigger-Eingang erstellt wird und diesem die Quelle “Intervall“ zugeordnet wird. Als Intervall kann eine beliebige Zahl von Sekunden eingegeben werden.

Will man das Zeitintervall nur zu bestimmten Zeiten (bspw. nur am Sonntag) laufen lassen, wählt man in der GUI als Source nicht “Intervall”, sondern “Zeit” und dort den Typ “Intervall”.

Triggerfunktion zu einem bestimmten Zeitpunkt

Grundsätzliches

Will man eine Logik-Zelle nur an einem bestimmten Zeitpunkt (bspw. jeden Tag um 08:15 Uhr ausführen lassen, kann ein Zeitpunkt-Trigger verwendet werden.

In der der GUI erstellt man hierfür wiederum einen Triggereingang und wählt als Quelle “Zeit”.

Die Eingabemaske erlaubt es, entweder eine Zeit einzugeben und über die jeweiligen Checkboxen die gewünschten Wochentage auszuwählen. Das obige Beispiel führt dazu, dass die Logik jeweils werktags um 08:15 Uhr “getriggert” wird.

Werden komplexere Anforderungen an die Definition des Zeitpunkts gestellt, kann dies mit Hilfe der Cron-Syntax realisiert werden. Zu diesem Zweck wählt man in der vorstehenden Eingabemaske als Typ nicht “Zeit“, sondern “Cron-Syntax”. Man erhält so ein Eingabefeld, in welches man einen String eingeben kann. Dieser String muss der Cron-Syntax entsprechen.

Cron-Syntax

Die Cron-Syntax baut auf 6 Feldern auf, welche jeweils durch eine Leerschlag voneinander getrennt sind. Die Reihenfolge der Felder ist wie folgt vorgegeben:

┌───────────── Sekunde (0 - 59)
│ ┌───────────── Minute (0 - 59)
│ │ ┌───────────── Stunde (0 - 23)
│ │ │ ┌───────────── Tag des Monats (1 - 31)
│ │ │ │ ┌───────────── Monat (1 - 12)
│ │ │ │ │ ┌───────────── Wochentag (0 - 6)
│ │ │ │ │ │

• *  *  *  * *

Das erste Feld repräsentiert somit, die Sekunden, das zweite die Minuten, dass dritte die Stunden und so weiter.

Weil intern im TWS immer die Cron-Syntax verwendet wird, werden auch alle über die GUI-Maske eingegebenen Zeitpunkt-Trigger in der Cron-Syntax behandelt. Dies sieht man in der obigen Eingabemaske. Dort wird unten das Ergebnis der Eingabe über die Felder wie folgt dargestellt: 0 15 8 * * 1,2,3,4,5 Dieser String lässt sich nun einfach übersetzen:

Weitere Erläuterungen zur Cron-Syntax (einer in der UNIX-Welt gebräuchlichen Notation) findet sich bspw. unter https://de.wikipedia.org/wiki/Cron. Zu beachten ist, dass die Cron-Syntax des TWS zusätzlich auch ein Feld Sekunden (ganz links) vorsieht.

Beispiele:

• 1 2 3 * * * täglich um 3:02:01

• 1 2 3-6 * * * täglich um 3:02:01, 4:02:01, 5:02:01 und 6:02:01

• 1 2 3 4 * * am 4. des Monats um 3:02:01

• 1 2 3 4 5 * am 4. des 5. Monats (Mai) um 3:02:01

• 1 2 3 * * 1 jeden Montag um 3:02:01 (Achtung Sonntag = 0!)

• 0/10 * * * * * alle 10sec beginnend bei 0 sec (0, 10, 20, 30, 40, 50 sec) unabhängig von Minuten, Stunden, Wochentag etc.

• 5/10 * * * * * alle 10sec beginnend bei 5 sec (5, 15, 25, 35, 45, 55 sec) unabhängig von Minuten, Stunden, Wochentag etc.

Zeitlich beschränkte Intervalle

Über die Cron-Syntax können auch Intervalle definiert werden: Der String 0 0/30 0-5,21-23 * * * führt dazu, dass der Trigger jeden Tag, im Zeitraum zwischen 21 Uhr bis 05 Uhr jeweils zur ganzen Stunden und dann in einem Intervall von 30 Minuten ausgelöst wird.

Wer zeitlich beschränkte Intervalle ohne Cron-Syntax (aber mit etwas eingeschränkterem Einstellungsmöglichkeiten) definieren möchte, kann im Eingabefeld “Source” den Typ Intervall wählen und erhält so eine Eingabemaske mit den Einstellungsmöglichkeiten.

Triggerfunktion über einen Wertveränderung am Eingang

Will man ein äußeres Ereignis als Trigger verwenden (bspw. die Öffnung einer Tür), erstellt man in der GUI einen Trigger-Eingang, weist diesem als “Source” Data Value zu und verbindet den Eingang mit einem Objekt des TWS-Objektsystems. In diesem Fall wird der Wert des Eingangs nicht an die Kernfunktion der Logik-Zelle übergeben. Abhängig von dem eingestellten Triggerverhalten (“A” oder “C”) wird die Ausführung der Logik-Zelle angestoßen.

Triggerverhalten wenn Objekte mehrfach an die gleiche Logik verknüpft sind FORTGESCHRITTENE

Grundsätzliches

Der Dispatcher (Verteilungsmechanismus über alle Systeme am TWS) verteilt laufend die empfangenen Werte gezielt an die Empfänger zB. KNX Objekte, Logikeingänge etc.. Je nach Einstellung an der Logik-Zelle wird deren Berechnung angestoßen und abhängig von den Sendeoptionen auch wieder an den Dispatcher zurück geliefert.

Gibt es mehrere Empfänger eines Objektes, dupliziert der Dispatcher dieses Telegramm und sendet es nacheinander an die Eingänge der Logiken bzw. Objekte. Daher spielt die Reihenfolge der Empfänger eine Rolle , die in manchen Anwendungsfällen zu beachten ist.

Beispiel 1: Ein Objekt wird mehrfach als Eingang einer Logikzelle verwendet:

• Der Dispatcher dupliziert das eintreffende Telegramm und sendet es nacheinander an die Eingänge, wobei die Sendereihenfolge der Eingangsnummerierung folgt.

• Die Logik wertet jedes Telegramm einzeln aus, d.h. der Wert wird an dem entsprechenden Eingang übernommen und abhängig von dem eingestellten Eingangs-Triggerverhalten wird die Logik ausgeführt - also eventuell sogar auch mehrfach.

• D.h. die Logik wird bei Triggeroption a oder c (also nicht bei u) zuerst mit neuem Wert am ersten Eingang berechnet (Eingang 2 hat da noch den alten Wert) und unmittelbar danach erneut am 2. Eingang getriggert und ausgeführt.
  Dies kann in Verbindung mit "Inhibit" durchaus gewünscht sein (daher ist inhibit auch immer der letzte Eingang). Die Logik wird mit dem Wert berechnet (inhibit hat dabei noch den alten Wert) und anschließend triggert der Eingang "Inhibit" mit dem neuen Wert und sperrt die Logik.

Ist obiges Verhalten nicht gewünscht, d.h. es sollen erst beide Eingänge den neuen Wert bekommen, bevor die Logik ausgeführt wird, gibt es zwei Möglichkeiten:

• Man setzt die Trigger-Option am ersten Eingang / an den ersten Eingängen auf "U" (update only). Hier übernimmt der Eingang / übernehmen die Eingänge nur den neuen Wert, die Logik wird aber nicht ausgeführt. Nur der letzte Eingang, der mit dem gemeinsamen Objekt verbunden ist, bekommt die gewünschte Trigger-Option "C" (on Change) oder "A" (Always). Die Logik wird dann nur einmal ausgeführt, wenn dieser Eingang das Telegramm erhält.
  
  Das folgende Beispiel sendet immer dann ein TRUE auf den Ausgang, wenn das Eingangsobjekt, welches auf beide Eingänge verknüpft ist, ein TRUE sendet. Ein FALSE wird jedoch nie auf den Ausgang gesendet!
  
  

  

In diesem Beispiel muss der Ausgang auf die Sendeoption auf "A" gestellt werden, weil er sich nie ändern wird.

• Oder der Nutzer erstellt sich eine Custom-Logik mit nur einen Eingang, den man dann intern mehrfach verwendet.

Beispiel 2: Ein Objekt wird in mehreren Logik-Zellen verwendet:

• Der Dispatcher dupliziert das eintreffende Telegramm und sendet es nacheinander an die Logik-Zellen, wobei die Reihenfolge der Logik_ID entspricht, die aber durch die Reihenfolge der initialen Erstellung der Logik-Zellen festgelegt ist und nachträglich nicht beeinflusst werden kann (oder nur durch Neu-Erstellung von Logik-Zellen).

• Die Logik-Zellen werden nacheinander abgearbeitet und senden ihre Werte.

• Ein Sonderfall entsteht wenn die Ergebnisse dieser Logik-Zellen wieder in einer gemeinsam-nachfolgenden Logik-Zelle z.B. AND-Logik verarbeitet werden.

• Um hier ein mehrfaches Triggern und ggf. vorzeitiges Senden mit falschen Werten zu vermeiden, sind in dieser gemeinsamen Logik-Zelle die ersten Eingänge alle mit "U" (Update Only) zu setzen und nur der letzte Eingang (der vom ursprünglichen Telegramm abhängt) auf "C" oder "A".

Nächster Schritt

Widmen Sie Ihren nächsten 5 Minuten nun den besonderen Funktionen an Ausgängen.