ioBroker: Blockly-Scripte optimieren und Logik-Kurzformen anwenden

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.