Inhalt dieser Seite

Einführung

Als Beispiel diene folgende einfache Aufgabenstellung: Es soll auf eine KNX-Adresse TRUE gesendet werden, sobald mindestens eine von drei Türen geöffnet wird.

Für diese Logik kann ein OR-Logik-Modul verwendet werden, es gibt TRUE aus, sobald an einem seiner Eingänge TRUE anliegt. Die fertig erstellte Logikzelle wird im Logikeditor wie folgt dargestellt:

Die Logik verwendet die drei KNX-Objekte K-1186, K-1187 und K-1187 als Eingänge, verarbeitet die dort erhaltenen Informationen in der Form einer ODER-Verknüpfung und gibt das Resultat an das KNX-Objekt K-1196 weiter.

Für den Anwender besteht eine Logik somit auf den ersten Blick aus drei Elementen:

• Eingang resp. Auslöser (wird auf der linken Seite dargestellt): im Beispiel die drei KNX-Objekte, welche die drei Türzustände (offen/geschlossen) repräsentieren und an die drei Variablen “Input 1”, “Input 2” und “Input 3” übergeben werden; jede Wertänderung an einem dieser Eingänge löst die Abarbeitung der Logik aus.

• Kernfunktion (ist bei bei einem Logikmodul fest vorgegeben oder wird bei einer Custom-Logik individuell vom Anwender codiert): im Beispiel die logische ODER-Verknüpfung.

• Ausgang (wird auf der rechten Seite dargestellt): im Beispiel die Variable “Output”, welche an das KNX-Objekt für den gesammelte Türzustand (offen/geschlossen) übergeben wird.

Dieses Grundwissen reicht grundsätzlich aus, um erste Logiken anzulegen. Zusätzliche Informationen zu diesen Themen finden sich unter →Kernfunktion einer Logik, →Eingänge, →Ausgänge und →Triggerfunktion.

In einem nächsten Schritt sollte sich der Anwender mit der Frage auseinandersetzen, in welchen Schritten die Bearbeitung einer Logik intern abläuft, damit er weiss, wie er allenfalls auf den →Bearbeitungsprozess Einfluss nehmen kann. Wichtigster Merkpunkt für das Verständnis des Bearbeitungsprozesses ist die Erkenntnis, dass eine Logik (nur) abgearbeitet wird, wenn sie ausgelöst wird. Sie benötigt somit einen →Trigger. Im obigen Beispiel “triggert” jede Wertänderung an einem der drei Eingänge die Logik; dies genügt in vielen Anwendungsfällen.
Zweiter wichtiger Merkpunkt in diesem Zusammenhang ist, dass die Berechnung der Logik und alle daran anschliessen Bearbeitungsschritte über einen auf TRUE gestellten Inhibit-Eingang, resp. genauer über die dadurch ausgelöste →Abbruchfunktion gestoppt werden können.

Wer sich später vertiefter mit der Logikfunktion des TWS auseinandersetzen wird, wird rasch erkennen, dass der Logikeditor als Erweiterung der beiden Hauptelemente Eingang und Ausgang zusätzliche Funktionen, resp. Einstellungsmöglichkeiten zur Verfügung stellt. Diese werden unter →Weitere (optionale) Funktionen der Ein- und Ausgänge vorgestellt.

Bearbeitungsprozess einer Logik

Übersicht

Aus Anwendersicht - und daher vereinfacht dargestellt - vollzieht sich die Bearbeitung einer Logik in sechs Prozessschritten:

[Intern: Power-Point-Datei, in der die Grafik erstellt worden ist

]

Erläuterung

Aktivierungsfunktion (und Gegenüberstellung mit der Abbruchfunktion)

Nicht zum eigentlichen Bearbeitungsprozess der Logik gehört die Aktivierungsfunktion. Diese wird in der GUI in der unteren rechten Ecke der Logikbox über die nachfolgenden Symbole bedient. Der Aktivierungsstatus wird ebenfalls in der Logikbox (oben in der Mitte) angezeigt.

Anhalten

Starten

Über diese Funktion lässt sich jede der angelegten Logiken unabhängig von allen anderen Logiken einzeln anhalten und starten. Nach dem Aktivieren ist die Logik unmittelbar scharf und reagiert auf an den Eingängen eintreffende Daten entsprechend dem gewählten Ausführungsverhalten des jeweiligen Einganges.

Es ist selbsterklärend, dass der Bearbeitungsprozess nur durchgeführt wird, wenn die Logik aktiviert (d.h. gestartet) ist. Zwischen dem Anhalten auf der Aktivierungsebene und dem Abbruch im Rahmen der Abbruchsfunktion besteht jedoch ein ganz wesentlicher Unterschied: Eine pausierte Logik liest keine Daten an den Eingängen, bei einer abgebrochenen Logik bleiben die die Eingänge weiterhin aktiv und lesen die Daten mit; eine abgebrochene Logik wird somit nach ihrer Freischaltung mit den zwischenzeitlich aktualisierten Werten weiterarbeiten, eine pausierte Logik kennt diese zwischenzeitlich erfolgten Wertänderungen nicht.

An- und Abkoppeln von Ein- und Ausgängen

Über die Funktion “Abkoppeln” kann in der GUI vorübergehend die Datenübernahme, resp. die Datenübergabe gestoppt werden; die Logik wird mithin von der Aussenwelt isoliert.

Jeder Ein- und Ausgang kann durch einen Klick auf das Stecker-Symbol vom Quell- oder Zielobjekt abgekoppelt werden.

Gekoppelt:	Zum Wechseln der Zustände auf das Symbol klicken	Abgekoppelt:

Damit kann Beispielsweise das Verhalten der Logik im Doktormodus beobachtet werden, ohne dass das Ergebnis der Logik auf das Zielobjekt geschrieben wird.
Gleiches gilt für abgekoppelte Eingänge. In diesem Fall triggert ein eintreffender Wert die Ausführung der Logik nicht und der empfangene Wert wird auch nicht in die Logik übernommen.

Kernfunktion einer Logik

Beim Anlegen einer Logik muss sich der Anwender entscheiden, ob er entweder eines der auf dem TWS fix installierten Logik-Module verwenden will, oder ob er eine eigene Custom-Logik codieren will.

Verwendung eines Logik-Modul

Aktuell stehen über 45 Logik-Module zur Verfügung; sie werden unter Eingebaute Logik-Module vorgestellt. Weil sie mit den Zusatzfunktionen der Ein- und Ausgänge kombiniert werden können, geht ihr Funktionsumfang wesentlich weiter, als dies im ersten Moment aufgrund der blossen Funktionsbeschreibung zu erahnen wäre. Auf diese Weise erhält bspw. bereits ein einfaches “AND”-Logik-Modul ein äusserst breites und umfassendes Einsatzfeld. Dies wird unter https://wiregate.atlassian.net/wiki/spaces/TSKB/pages/397803554/Die+Verwendung+der+Bausteine+am+Beispiel+des+AND-Moduls) anhand von Beispielen dargestellt.

Weitere Umsetzungsbeispiele finden sich unter Mit Logik-Modulen gelöste Aufgabenstellungen (Beispiele).

Erstellung einer Custom-Logik / Verwendung einer zur Verfügung gestellten Custom-Logik

Reicht die Funktionalität der Logik-Module nicht aus, erstellt sich der Anwender eine Custom-Logik; diese setzt sich aus Modulbausteinen, welche ähnliche Funktionen aufweisen wie die Logik-Module, zusammen.
Zudem werden aus der Community Fertige Custom-Logiken (Beispiele) zur Verfügung gestellt.

Eingänge

Eine Logik kann zwischen 0 und einer beliebigen Zahl von Eingänge verfügen; dabei wird zwischen drei Arten von Eingängen unterschieden:

• Wertübergabe-Eingänge (in einer Logik meist als “Input” bezeichnet): Sie übergeben der Logik die zu verarbeitenden Werte

• Sperr-Eingänge (“Inhibit”): Über ein TRUE auf diesem Eingang kann die Ausführung der Logik gesperrt werden, näheres dazu unten unter →Sperrfunktion)

• Trigger-Eingänge (“Trigger”): Sie definieren weitere Elemente, die dieser Logik als Trigger dienen; näheres dazu unten unter →Triggerfunktion.

Die Eingänge haben für die Abarbeitung einer Logik folgende Funktionen:

• sie übergeben Werte an die Logik (→Wertübergabefunktion)

• sie lösen die Abarbeitung der Logikzelle aus (→Triggerfunktion), resp.

• sie beeinflussen das Startverhalten der Logik (→Startfunktion),

• sie können einen vom einem Objekt des Obkektsystem übergebenen Wert vor der Bearbeitung in der Logik logisch negieren (→Negationsfunktion),

• sie können einen von einem Objekt des Objektsystems stammenden Wert umwandeln (→Konvertierungsfunktion über “Innerhalb Bereich”),

• sie können einen von einem Objekt des Objektsystems stammenden Wert mit einer Vorgabe vergleichen (→Vergleichsfunktion).

Ausgänge

Eine Logik muss mindestens einen Ausgang haben, je nach Kernfunktion der Logik stehen u. U. auch mehrere Ausgänge zur Verfügung. Weil der der Anwender einem Ausgang mehrere Objekte des TWS-Objektsystems zuordnen kann, ist es faktisch möglich, mit einer Logik gleichzeitig mehrere Objekte zu bedienen.

Die Ausgänge haben für die Abarbeitung einer Logik folgende Funktionen:

• sie übergeben Werte an Objekte des Objektsystems (→Wertübergabefunktion),

• sie bestimmen,

  • bei welchem Ereignis die Ausgabewerte an das Objekt des Objektsystems übergeben werden soll (→Sendefunktion), und

  • ob diese Übergabe unmittelbar oder verzögert erfolgen soll (→Verzögerungsfunktion)

• sie können einen Wert vor der Übergabe an das Objekt des Objektsystem logisch negieren (→Negationsfunktion),

• sie können einen von einem Objekt des Objektsystems stammenden Wert umwandeln (→Konvertierungsfunktion über “Mapping”).

Triggerfunktion

Eine Logik wird nur ausgeführt, wenn sie von einem Trigger dazu aufgefordert (d.h. “ausgelöst”) wird. Umgekehrt wird eine Logik jedes Mal ausgeführt, wenn ihr Auslöser gegeben ist; die kann nicht gewünscht sein, wenn bspw. während einem bestimmten Zeitraum (bspw. in der Nacht) ein bestimmter Zustand erhalten bleiben soll. Dementsprechend hat die Beeinflussung der Auslösefunktion eine wichtige Bedeutung; für diesen Zweck werden Trigger verwendet.

Als mögliche Trigger stehen zur Verfügung

• ein 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 äusseren Ereignis die Logik 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 blosser Trigger dient (“Data Value”);

• ein Trigger, welcher innerhalb einer Custom-Logik (bspw. über den Logikbaustein → Clocksignal) codiert wurde.

Triggerfunktionen über einen Wertübergabe-Eingang

Funktionsbeschreibung

Jeder Wertübergabe-Eingang kann zwei unterschiedliche Triggerfunktionen annehmen. Es ist aber auch möglich, die Triggerfunktion des Eingangs auszuschalten:

• Einstellung “A” (always): Der Eingang funktioniert jedesmal als Trigger, wenn man Eingang ein Wert empfangen wird.

• Einstellung “C” (on change): Der Eingang funktioniert nur als Trigger, wenn sich der soeben empfangene Wert vom letzten empfangenen Wert unterscheidet.

• Einstellung “U” (update): Der Eingang funktioniert nicht als Trigger, d.h. sein Wert wird einzig an die dem Eingang zugeordnete Variable übergeben; die Berechnung der Logik erfolgt erst, wenn ein Trigger ausgelöst wird.
  Die Einstellung "U" ist eigentlich selten notwendig, insbesondere aber, wenn ein Objekt mehrfach an eine Zelle angeschlossen ist zB. Eingang + Inhibit. Ausführlicheres siehe hier: https://forum.timberwolf.io/app.php/kb/viewarticle?a=120

In der GUI (am Eingang einer Logikbox) und im Input-Array einer Custom-Logik kann die Trigger-Funktion des jeweiligen Wertübergabe-Eingangs festgelegt werden.

Einstellung in der GUI

Die GUI stellt die aktuell eingestellte Triggerfunktion des jeweiligen Eingangs dar und lässt diese auch ändern. Über die GUI kann auch die in einer Custom-Logik vorgenommene Definition übersteuert werden.

Einstellung in einer Custom-Logik

Bei der Definition im Input-Array einer Custom-Logik werden die entsprechenden Kleinbuchstaben verwendet (also “a”, “c” oder “u”):

  "Input": [
    ["Eingang 1 ","(mit Triggerfunktion always)","$In1","a" ],
    ["Eingang 2 ","(mit Triggerfunktion on change)","$In2","c" ],
    ["Eingang 3 ","(ohne Triggerfunktion)","$In3","u" ]
  ]

Triggerfunktion über einen Zeitintervall-Auslöser

Oft ist es gewünscht, eine Logik regelmässig in einem bestimmten Rhythmus durchlaufen zu lassen. In solchen Fällen muss ein Zeitintervall-Trigger angewendet werden; damit wird 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”.

Einstellung eines Zeitintervall-Triggers in einer Custom-Logik

In einer Custom-Logik verwendet man für einen einfachen Zeitintervrall den Modulbaustein →Clocksignal. Zeitbezogene Intervalle können über den Modulbaustein →Cron erreicht werden, in dem in einem Feld über “/” ein Intervall angegeben wird; näheres dazu unter →Cron Syntax.

Triggerfunktion zu einem bestimmten Zeitpunkt

Grundsätzliches

Will man ein Logik 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 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.

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 äusseres 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. [--------- Sorgfältig prüfen, habe dies noch nicht ausprobiert ----]

Abbruchfunktion

In bestimmten Situationen soll die Ausführung einer Logik abgebrochen werden, resp. die Logik soll schon gar nicht ausgeführt werden. Erfolgt ein Abbruch, wird nichts mehr an die Ausgänge gesendet.

In der GUI wird ein Abbruch erreicht, indem man einen Inhibit-Eingang erstellt. Sobald auf diesem ein TRUE eintrifft, wird die Ausführung der Logik abgebrochen oder umgekehrt, solange an allen Inhibit-Eingängen ein FALSE anliegt, wird die Logik ausgeführt.

In einer Custom-Logik verwendet man für einen Abbruch den Logik-Baustein → Break. Sobald einer seiner Eingänge - er kann mehrere haben - auf TRUE gesetzt wird, bricht auch hier die Ausführung der Logik ab.
Beim einem Abbruch werden die im Code nachfolgenden Logik-Bausteine nicht mehr ausgeführt. Es wird auch kein Ausgang gesendet, selbst wenn die eine Variable, die einem Ausgang zugeordnet ist, bereits gesetzt worden ist.
Die Verwendung von ["Break", ["$VAR<Inhibit?>"]] erlaubt es, in der GUI beliebig viele Eingänge hinzuzufügen, die den Abbruch einer Custom-Logik triggern können.

Weitere (optionale) Funktionen der Ein- und Ausgänge

Die GUI des Logikeditors stellt bei den Ein- und Ausgängen verschiedene Optionen zur Verfügung. Diese Optionen stellen - funktional betrachtet - Erweiterung der Kernfunktion des jeweils gewählten Logik-Moduls um weitere Funktionen dar. Oder mit Worten ausgedrückt. Jede dieser Optionen fügt der betreffende Logik - neben ihrer Kernfunktion - eine zusätzliche Funktion hinzu; damit wird das Programmieren einfach gemacht oder - wieder mit anderen Worten - es können mehrere prozedurale Funktionen miteinander kombiniert werden- ohne dass eine Custom-Logik erstellt werden muss.
Die Leistungsbreite dieses Konzepts wird unter https://wiregate.atlassian.net/wiki/spaces/TSKB/pages/397803554/Die+Verwendung+vom+Logik-Modulen+am+Beispiel+des+AND-Modulsvorgestellt.

Wertübergabefunktion

Ein- und Ausgänge stellen die Schnittstellen eine Logik zum Objektsystem des TWS dar.
Über diese Schnittstellen können Werte an die und von der Logik übergeben werden. Voraussetzung ist, dass die Datentypen der Objekte und der Logik übereinstimmen. Ist dies nicht der Fall, stellt der Logikeditor →Konvertierungsfunktionen zur Verfügung. Im Rahmen der Wertübergabe können im Logikeditor gleichzeitig auch →Vergleichsfunktionen hinzugefügt werden.

Jedem Ein- und Ausgang können mehrere Objekte des Objektsystems zugeordnet werden. Auf diese Weise kann bspw. das Resultat einer Logik gleichzeitig an mehrere Objekte gesendet werden.

Bei Eingängen können die übergebenen Werte

• entweder als dynamische Variable von einem Objekt des TWS-Objektsystems stammen,

• oder als feste definierte Variable (“Konstante”) vorgeben werden; in der Logikbox wird eine Konstante über die Verwendung der Funktion “Parameter” definiert.
  [------- Achtung: Der als Parameter zugewiesene Wert wird nur beim Abspeichern in die Berechnung übernommen; es muss somit explizit ein Trigger definiert werden, damit die Logik erneut ausgeführt werden kann --------].

Konvertierungsfunktion

Jede Datenübergabe in der Informatik setzt voraus, dass die Datentypen übereinstimmen. Der Objektsystem des TWS (und damit auch die Logikfunktion) arbeitet mit folgenden Datentypen:

• Boolean

• Integer

• Float

• String

Bei der Datenübergabe an Eingängen

Bei Eingängen, denen intern eine Boolean-Variable zugewiesen ist

Beispiel: Das AND-Logik-Modul arbeitet mit Boolean-Daten. Soll es mit einem Wert vom Typ Float bedient werden, muss bei der Übergabe an die Logik eine Datenkonvertierung erfolgen.
Für diesen Zweck kann man in der GUI einem Eingang die Funktion “Innerhalb Bereich” zuordnen. Diese Funktion prüft, ob der Eingangswert im angegebenen Bereich liegt; falls ja, erhält der Eingang den Zustand TRUE, anderenfalls FALSE.

Bei Eingängen, denen intern eine Integer-Variable zugewiesen ist

Soll eine Glättung der am Eingang übergebenen Werte vorgenommen werden, steht die “Tiefpass”-Funktion zur Verfügung; sie dient der Glättung der Eingangswerte über einen bestimmten Zeitraum hinweg. Die Funktionsweise der Tiefpassfunktion wird beim entsprechenden Logik-Modul beschrieben → Tiefpass (Logik-Modul).

Bei der Datenübergabe an Ausgängen

Bei Ausgängen stellt die GUI die Funktion “Mapping” zur Verfügung. Sie erlaubt es, Werte umzuwandeln. Dies kann beispielsweise sinnvoll sein, wenn ein AND-Logik-Modul ein Objekt bedienen soll, welches vom Typ Integer ist. So kann bspw. ein Dimmwert von 60% an eine Leuchte gesendet werden, wenn das Ergebnis der Logik TRUE lautet.

In Custom-Logiken

In Custom-Logiken kann die Datenkonvertierung direkt im Code erfolgen. Dafür stehen - abhängig vom Anwendungsfall - verschiedene Modulbausteine (bspw. “Latch” oder “Multiplexer”) zur Verfügung.

Negationsfunktion

In der GUI des Logikeditors können Werte auch umgewandelt werden, indem sie negiert werden. Dies erfolgt indem das kleine Kreissymbol beim entsprechenden Ein- oder Ausgang angeklickt wird.

normal (nicht negiert)

negiert

In Custom-Logiken erfolgt die Negation, indem einer Variablen (vor dem $-Zeichen, aber innerhalb der Anführungszeichen) ein “-” vorangestellt wird, beispielsweise so "-$Out". Diese Negation ist aber nur innerhalb des Module-Array zulässig.

Vergleichsfunktion

In der GUI des Logikeditors kann festgelegt werden, dass die an den Eingängen übergebenen Daten einer Vergleichsoperationen unterzogen werden, bevor sie von der Logik verarbeitet werden. Der Eingang erhält so - je nach Anwendungsfall oder Betrachtungsweise - entweder eine Filter- oder eine Wenn-Dann-Funktion.

So kann bspw. geprüft werden, ob der übergebene Integer-Wert kleiner als “500” ist; trifft dies zu, wird der Logik ein boolean TRUE zur Verarbeitung übergeben.

In der GUI stehen folgende Vergleichsfunktionen zur Verfügung:

• “Innerhalb Bereich”: prüft, ob der Eingangswert im angegebenen Bereich liegt; falls ja, erhält der Eingang den Wert TRUE, anderenfalls FALSE. [--------- Hinweis: Werden der Min- und der Max-Wert auf den gleichen Wert gesetzt, kann damit eine “Ist gleich”-Prüfung des Eingangswerts vorgenommen werden ------------]

• “Schwellwert unter”: prüft, ob der vorgegebene Schwellwert unterschritten ist; falls ja, erhält der Eingang den Wert TRUE, anderenfalls FALSE.

• “Schwellwert über”: prüft, ob der vorgegebene Schwellwert überschritten ist; falls ja, erhält der Eingang den Wert TRUE, anderenfalls FALSE.

• “Schwellwert mit Hysterese”: vergleicht den Eingangswert gleichzeitig mit der oberen und unteren Grenze;

  • ist die obere Grenze überschritten, erhält der Eingang den Zustand TRUE,

  • ist die untere Grenze unterschritten, erhält der Eingang den Wert FALSE (Hinweis: die untere Grenze sollte so festgelegt sein, dass sie unterschritten werden kann: bspw. macht es bei einem Lux-Wert die untere Grenze auf 0 zu legen; dieser Wert kann nie unterschritten werden),

  • liegt der Wert dazwischen, verbleibt der Eingang im bisherigen Zustand.

In einer Custom-Logik können für diese Zwecke die Modul-Bausteine “Comperator” und “Limiter” verwendet werden (siehe dazu auch https://wiregate.atlassian.net/wiki/spaces/TSKB/pages/397771178/Anwendungshilfen+f+r+Custom-Logiken+How-to+s#Vergleiche ).

Startfunktion

Die GUI bietet an den Eingängen unter dem Titel “Start-Verhalten” eine Einstellungsmöglichkeit mit zwei Optionen an.

• Standardmässig ist die Option “Startwert” ausgewählt: Damit kann dem Eingang ein Wert zugewiesen, mit welchem die Logik arbeitet, bis erstmals an diesem Eingang ein (externer) Wert eingetroffen ist.

• Stattdessen kann die Option “Logik sperren bis Input verfügbar ist” gewählt werden. Damit wird verhindert, dass die Logik ausgeführt wird, bevor dieser Eingang mit einem externen Wert bedient worden ist. Technisch gesehen wird über diese Einstellung für die Logik eine Abbruchsfunktion ausgelöst, die solange andauert bis der entsprechende Eingang erstmals mit einem Wert bedient wurde.

In einer Custom-Logik kann der Startwert im Level-Array über den “Init Value” festgelegt werden. Das Sperren bis der Variablen (hier $In) ein Eingangswert zugewiesen wurde, kann bspw. wie folgt erreicht werden ["Break",["-$In"]].

Sendefunktion

Funktion und Einstellungsmöglichkeiten

Die Sendefunktion, legt fest, unter welchen Bedingungen der in der Logik berechnete Ausgangswert an das (resp. die ) mit dem Ausgang verbundene(n) Objekt(e) übergeben werden soll.

Es stehen folgende Optionen zur Verfügung:

• "A": jedesmal (always)

• "C": nur bei Wertänderung (on change)

• "T": wenn ein Timer-Trigger abgelaufen ist (on timer);

• “CT”: sobald eine Wertänderung erfolgt oder ein Timer-Trigger abgelaufen ist ([---------- nur GUI -------].

Verwendung in der Logikbox der GUI des Logikeditors

In der GUI erfolgt die Einstellungam Ausgang über den entsprechenden Schalter

Verwendung in einer Custom-Logik

In einer Custom-Logik kann die Einstellung im Output-Array über die “Sende-Optionen” erfolgen. In Bezug auf die Option "T" ist bei Custom-Logiken zu beachten, dass diese nicht selektiv wirkt. Dies heisst, wenn werden mehrere Timer in einer Custom-Logik verwendet werden, führt jeder abgelaufene Timer dazu, dass der Ausgang gesendet wird. Dabei ist weiter zu beachten, dass bei Verwendung eines Timers die Berechnungen weiterhin durchgeführt werden (abhängig von der Optionen der Eingänge), nur eben nichts gesendet wird. Mögliche Timer-Modulbausteine sind:

• Monoflop (single shot timer): Triggert nach Ablauf der Zeitdauer

• Clock (zyklischer Timer) : Triggert jedesmal nach Wechsel des Taktzustandes

• Cron (Uhrzeit abhängiger Timer): Triggert jedesmal bei Erreichen der eingestellten Zeit(en)

Verzögerungsfunktion

Funktion und Einstellungsmöglichkeiten

Die Verzögerungsfunktion, legt fest, ob der in der Logik berechnete Ausgangswert erst mit einer zeitlichen Verzögerung an das (resp. die ) mit dem Ausgang verbundene(n) Objekt(e) übergeben werden soll. Damit kann beispielsweise eine sog. “Treppenhausschaltung” realisiert werden.

Es stehen folgende Optionen zur Verfügung:

• Einschaltverzögerung: Das Einschalten von 0 auf 1 wird um eine vorgegebene Anzahl Sekunden verzögert gesendet.

• Ausschaltverzögerung: Das Ausschalten von 1 auf 0 wird um eine vorgegebene Anzahl Sekunden verzögert gesendet.

• Ein- und Ausschaltverzögerung: Das Umschalten von 0 auf 1 und 1 auf 0 wird vorgegebene Anzahl Sekunden verzögert gesendet. Dabei können getrennte Verzögerungszeiten für das Ein- bzw. Ausschalten festgelegt werden.

Verwendung in der Logikbox der GUI des Logikeditors

In der GUI erfolgt die Einstellung am Ausgang über den entsprechenden Schalter

Verwendung in einer Custom-Logik

In einer Custom-Logik kann diese Funktion im Modul-Array mit einer entsprechenden Codierung vorgenommen werden; dazu steht u.a. der Modulbaustein [---------- Stopwatch ------------] zur Verfügung. In der Regel wird aber auch bei der Verwendung einer Custom-Logik die Verzögerungsfunktion über Einstellungen in der GUI definiert.

Ab hier Steinbruch (, d.h. blosse Grundlage für die weitere redaktionelle Bearbeitung)