Zur Frage "spielt es eine Rolle" kann man eine ganz klare Antwort geben: Das kommt darauf an.
Grundsätzlich sollte es erst mal keinen Unterschied machen, ob Du eine Rule über UI oder über Text generierst. Wenn Du eine DSL Rule in der UI anlegst, definierst Du den when-Teil der Rule über den When-Block in der UI, der Then-Block der UI-Rule (mit DSL als Sprache) enthält dann exakt die Befehle, welche im then-Teil der Rule definiert wurden-
Allerdings gibt es eine Sache, die in der UI nicht zur Verfügung steht, das sind globale Variablen. Und es gibt bestimmte Rules, welche darauf angewiesen sind, globale Variablen zu nutzen. Ein Workaraound für einen Teil dieser Rules kann sein, zum Speichern und einlesen jeweils Items zu nutzen, das kann sogar von Vorteil sein, weil man ein Item leicht persistieren kann und so der Wert einer Variablen sogar über einen Programm Neustart hinaus erhalten bleiben kann. Aber durch das asynchrone Design handelt man sich auch Nachteile ein, weil man z.B. nicht einfach ein Item zum Speichern und anschließendem Auslesen verwenden darf z.B.:
Code: Alles auswählen
Item.postUpdate((Item.state as Number) + 10)
if((Item.state as Number) > 100)
// mach was bestimmtes
Außerdem ist ein globale Variable viel einfacher nutzbar. Funktionsgleicher Code:
Und bei der Verwendung von Timern gibt es keine Möglichkeit, die globale Variable zu vermeiden. Wenn Du also eine Zeitverzögerung einbauen willst, musst Du entweder auf expiration ausweichen oder eine DSL Rule in einer Textdatei definieren.
Und die expration arbeitet mit fixen Zeiten, es gibt keinen einfachen Weg, die Verzögerung zu manipulieren (also z.B. warte tagsüber 15 Sekunden, aber abends 10 Minuten, oder: beim ersten Mal direkt, danach für eine halbe Stunde alle 5 Minuten, danach alle 30 Minuten, oder, oder, oder)
Du kannst beliebig viele Rules in einer Datei anlegen - das wird auch durch den Dateinamen angedeutet... *.rule
s <-
Wenn Du Rules über mehrere Dateien verteilst, musst Du bei Verwendung globaler Variablen darauf achten, dass alle Rules, die eine globale Variable nutzen gemeinsam in einer Datei definiert sind, das hängt mit der strikten Definition der Variablen zusammen (der Interpreter wird meckern, weil er keine Definition der Variablen innerhalb der Datei findet - andererseits darf die Variable aber auch nicht mehrfach definiert werden...)
Eine ganz wichtige Sache: DSL Rules bieten mächtige Funktionen, um sich viel Arbeit zu ersparen, insbesondere, wenn man mehrere fast identische Rules hat, die sich nur durch Itemnamen unterscheiden. Ich habe z.B. Raumtemperaturregler, welche leider beim Setzen des Modus einen anderen Wert benötigen als beim Lesen geliefert wird (geschrieben wird ein Wert i = 1 bis 4, gelesen wird ein Wert 32 + 2^i, also 33, 34, 36 oder 40). Ich habe neun gleichartige RTR und müsste nun neun Rules schreiben, um beim Hochfahren des Systems (oder wenn ich die Bedienung lokal am Gerät vornähme) in openHAB jeweils den Status passend umzurechnen. Es reicht aber eine einzige Rule, in der nicht mal ein konkreter Itemname verwendet wird
.
In der UI sind solche Rules aber genauso möglich, das ist kein Alleinstellungsmerkmal der DSL Text Rules.
