Inhaltsverzeichnis
Bedingungen einkürzen
Nehmen wir an, du nutzt zum Schalten eines Geräts ein Blockly-Script mit einem Trigger und einer „falls“-Logik, die prüft, ob der Datenpunkt des Triggers auf „wahr“ oder „falsch“ geändert wurde. Dein Blockly-Script könnte dann wie folgt aufgebaut sein:
Ausgangssituation

Wenn der Trigger also geändert wurde, prüft der erste „falls“-Block den Wert der Objekt ID, die du auch für den Trigger verwendest auf „wahr“. Der zweite „falls“-Block prüft den Wert der gleichen Objekt ID auf „falsch“.
Optimierung
Die „falls“-Logik arbeitet nach folgendem Schema: Ist die angesteckte Bedingung „wahr“, wird „mache“ ausgeführt. Andernfalls „sonst“.
Ein Wert, der auf <false> steht, ungleich „0“ ist oder Text (auch Leerzeichen) enthält, gilt also als „wahr“. Ansonsten wird er automatisch als „falsch“ interpretiert:

Über das blaue Zahnrad kannst du den „falls“-Block um ein „sonst“ erweitern. In diese Bedingung hängst du die Aktion, die bei „falsch“ ausgeführt werden soll.
Das „falsch“-Prüfung analog zum Beispiel ist wie folgt aufgebaut:

Wert von Trigger nutzen
Im obigen Beispiel triggert das Blockly-Script auf einen Datenpunkt, welcher unter „falls“ durch den System-Block „Wert von Objekt ID“ erneut abgefragt wird, um diesen auszuwerten:
Ausgangssituation

Diese Abfrage kannst du einsparen, da der Trigger die Änderung (und somit auch den Wert) des Datenpunktes bereits ausgelesen hat. Ziehe dir also statt dem „Wert von Objekt ID“-Block (Bereich „System“) den „Objekt ID“-Block aus dem Bereich „Trigger“, hänge diesen an den „falls“-Block und stelle ihn auf „Wert“:
Optimierung

Löst der Trigger aus, prüft der „falls“-Block den vom übergebene Wert auf „wahr“. In diesem Fall wird das Gerät geschaltet.
Das „falsch“-Prüfung analog zum Beispiel ist wie folgt aufgebaut:

Triggerzustand anpassen
Trigger ist wahr
Ausgangssituation

Ausgehend vom letzten Beispiel kannst du die „falls“-Abfrage einsparen, indem du die Zustandsabfrage des Triggers auf „ist wahr“ stellst. Dadurch reagiert der Trigger nur, wenn der überwachte Datenpunkt auf <true> springt:
Optimierung

Trigger ist unwahr
Das „falsch“-Prüfung analog zum Beispiel ist wie folgt aufgebaut:

Trigger ist größer als letztes
Möchtest du hingegen prüfen, ob ein Wert größer ist als vorher, könnte das dazugehörige Blockly-Script so aufgebaut sein:
Ausgangssituation

Wenn du die Zustandsabfrage des Triggers auf „ist größer als letztes“ änderst, kannst du auch hier wieder die „falls“-Abfrage einsparen:
Optimierung

Alternative zu „ist wahr“
Da <true> immer größer ist als <false>, kannst du mit dem Zustand „ist größer als letztes“ auch auf einen Logikwert eines Datenpunktes reagieren. Der Trigger wird dadurch einmalig aktiviert, wenn der Datenpunkt auf <true> gesetzt wird.

Trigger ist kleiner als letztes
Die Prüfung, ob ein Wert kleiner ist als vorher, ist wie folgt aufgebaut:

Alternative zu „ist unwahr“
Da <false> immer kleiner ist als <true>, kannst du mit dem Zustand „ist kleiner als letztes“ auch auf einen Logikwert eines Datenpunktes reagieren. Der Trigger wird dadurch einmalig aktiviert, wenn der Datenpunkt auf <false> gesetzt wird:

Datenpunkte verknüpfen
Zurück zum obigen Beispiel: Der Trigger prüft also nun, ob ein Datenpunkt wahr ist und schaltet in diesem Fall dein Gerät auf wahr:
Ausgangssituation

Durch den „binde object mit“-Block aus dem Bereich „System“ kannst du diese beiden Datenpunkte auch direkt miteinander verknüpfen, sodass „Object ID “ immer mit dem gleichen Wert gesteuert wird, wie „Object ID 1“:
Optimierung

Hierfür eignet sich auch der sogenannte „Alias“-Datenpunkt. Wie du diese einrichten kannst, erfährst du im Artikel: Alias-Datenpunkte anlegen und verknüpfen.
6 Kommentare
Kommentieren[…] Zum Stoppen des Timers schreibst du einfach eine „0“ in den Datenpunkt. Dadurch ist die Bedingung der „falls“-Logik negativ — Intervall und der Timer werden gestoppt. Mehr über Kurzformen im Logikblock kannst du in diesem Artikel nachlesen. […]
[…] ein. Dadurch reagiert der Trigger nur, wenn der Datenpunkt einmalig auf <true> gesetzt wurde (mehr dazu erfährst du in diesem Artikel). Als Objekt ID wählst du den State deines Fenstersensors, der anzeigt, ob dieser geöffnet oder […]
[…] Den Trigger selbst stellst du auf “ist kleiner als letztes”, somit reagiert er nur, wenn ein Datenpunkt von <true> (= 1) auf <false> (= 0) wechselt (mehr zu “Logik-Kurzformen” erfährst du in diesem Artikel): […]
[…] Den Trigger selbst stellst du auf “ist kleiner als letztes”, somit reagiert er nur, wenn ein Datenpunkt von <true> (= 1) auf <false> (= 0) wechselt (mehr zu “Logik-Kurzformen” erfährst du in diesem Artikel): […]
[…] Zum Stoppen des Timers schreibst du einfach eine „0“ in den Datenpunkt. Dadurch ist die Bedingung der „falls“-Logik negativ — Intervall und der Timer werden gestoppt. Mehr über Kurzformen im Logikblock kannst du in diesem Artikel nachlesen. […]
[…] Weitere Zustandsänderungen des Triggers findest du in diesem Artikel: Blockly-Scripte optimieren und Logik-Kurzformen anwenden. […]