Regeln <-> Scripte

[manes]

Moin,
nachdem ich wieder einmal ein wenig in der Doku gelesen habe würde mich eines mal interessieren:
Wie handhabt ihr das mit den Regeln und Scripten? Mittlerweile ist mein Eindruck, das man Scripte schreibt für irgendwas und die dann "nur" über die Rules ausführt. Die Rules selbst bekommen keinen Scriptcode. Das wäre jetzt für mich eigentlich der vernünftige Weg.
Zumal ich Probleme habe alles mögliche in die Rules einzubauen, was m.E. in Scripten wesentlich einfacher gehen sollte?
Wenn ich hier im Forum Beispielcode für Scripte sehe, dann meine ich auch immer erkennen zu können, das es nicht aus Rules stammt. Irgendwie fehlen dort immer die Header, die zu Anfang in den Rules Scripten vorhanden sind, wenn man sich über den Reiter Code anschaut was abgelegt wurde.

[udo1toni]

Nö.



Wenn wir von openHAB3 sprechen, hast Du verschiedenste Möglichkeiten, Automationen anzulegen. Neben Vorlieben für die eine oder andere Form spielt auch eine Rolle, was Du in der Automation erledigen willst, bzw. was drumherum vorhanden sein muss.

Ein Beispiel: globale Variablen (ruleübergreifend!) stehen nur über Rules zur Verfügung. Hier führt kein Weg an der DSL vorbei.
Aber selbst eine Variable, die ihren Wert nur über den Durchlauf eines Scripts hinaus erhalten soll (und nur in diesem Script zur Verfügung steht), muss auf eine bestimmte Art verwendet werden (und das ist vergleichsweise umständlich, da die Variable trotzdem initialisiert werden muss, aber nur dann, mit dem Default Wert gefüllt werden darf, wenn sie noch nicht existiert, ansonsten muss sie mit ihrem alten Wert wiederbefüllt werden).
Beispielcode dazu ist vor allem im englischen Forum zu finden, mit der DSL nutze ich die Variable einfach (nachdem ich sie global definiert habe).

Ein Timer kann sich selbst neu planen (wichtiges Feature für verzögerte Schleifen), dazu muss er aber eine globale Variable für seinen Zeiger nutzen. Es bleibt also nichts außer Thread::sleep() zu verwenden, was zwar in openHAB3 nicht mehr so kritisch ist wie vor openHAB3 (jede Rule hat ihren exklusiven Thread), aber im Vergleich zum Scheduler höchst ungenau werden kann.

Es gab relativ lange das Damoklesschwert, dass die Rules DSL als veraltet markiert wird und dann nicht mehr zur Verfügung steht. Das ist (Stand heute) nicht mehr der Fall. Ich empfehle also immer, sich damit auseinanderzusetzen, es sei denn, man hat eine Vorliebe für eine andere Scriptsprache, die von openHAB unterstützt wird.

Die Rules über die UI anzulegen hat durchaus Vorzüge, jedoch habe ich bis jetzt noch keine zwingenden Gründe dafür gesehen.

[manes]

hm,
ich dachte mir eigentlich folgendes:
Ich habe ein Rollo, was nur unter bestimmten Bedingungen fahren darf. Also lege ich für diese Rollade ein eigenes Skript an in dem dann alle Möglichkeiten abgefragt werden, ob sie erfüllt sind oder nicht. Das liegt dann zentral. Dieses Skript wird einfach von einer Rule o.ä. aufgerufen und entscheidet dann erst, ob und wenn ja wie reagiert wird. Deshalb meine Vermutung oben, das es auch so geplant wäre. War dann wohl eine falsche Vermutung.

[udo1toni]

Ja, das kannst Du natürlich so machen. Sinnvoll natürlich nur dann, wenn das Rollo von unterschiedlichen Rules aus den Fahrbefehl bekommt (und an dieser Stelle sollte man dann genau hinschauen, ob das so sinnvoll ist).

[manes]

siehst Du da ein Problem? Weil Du "sinnvoll" erwähnst.
Ein einfaches Beispiel wäre Filmeabend. Ein Icon (das Spiel beginnt). Rolladen fahren runter, Beamer geht an, Leinwand fährt aus, Musikanlage geht an. Bis hier hin alles klar. Alles vorbei. Jetzt ein ICON für Ende. Beamer geht aus, Leinwand fährt ein, Musikanlage geht wieder aus. Rollade fährt... halt, das darf sie nicht mehr. Es ist dunkel draußen, also muß sie unten bleiben. Jetzt gibt es aber eine weitere Regel, die bei Abenddämmerung nur die Rolladen herunterfährt. Und eine andere Regel, die bei Morgendämmerung wieder hoch fährt. Das könnte doch alles ein einziges Skript regeln, das evtl. sogar Parameter mitbekommt und daran erkennt, was gerade gefordert ist. Oder, wenn man über Tag schaut und evtl. feuert zwischendurch der Sonnenschutz und will auch zwischendurch wieder hochfahren, weil die Sonne weg ist. Da fallen mir noch einige weitere Szenarien ein, die mich dazu verleiten ein Skript für mehrere Rules zu bauen.
Aber vielleicht gibt es dafür eine andere Lösung und Du bist deshalb skeptisch?

[udo1toni]

Genau der Punkt "Parameter" ist nicht möglich. Scripte lassen sich nur "as it is" ausführen.

Du musst also dafür Sorge tragen, dass alle Variablen (also was die Sollposition beeinflusst) aus dem Script heraus ausgelesen werden können. Im Fall der Rolläden wäre es im Zweifel einfacher, ein Item abzufragen, ob die Läden offen oder geschlossen sein sollen (z.B. isNight, welches beim Zufahren auf true gesetzt wird und beim Auffahren auf false gesetzt wird.)
Beim Auffahren der Läden musst Du natürlich prüfen, ob cinemaIsActive gerade aktiv ist (und diese Variable bei aktivieren des Kino-Modus auf true, sowie beim Beenden des Kino-Modus auf false setzen).

So oder So musst Du zusätzlichen Aufwand treiben, je mehr Stellen zu berücksichtigen sind, desto aufwändiger wird es (und zwar in jeder Rule, die da steuern soll...)

[manes]

Das stimmt. Aber wie ich jetzt sehe, scheint der Weg ja nicht verkehrt zu sein, den ich vor habe. Mich würde allerdings dann jetzt interessieren, wie das mit den Variablen klappt. Wo setzt man die global? Weil irgendwo müssen die ja bekannt gemacht und gesetzt werden. Eine weitere Frage wäre dann, wenn ich ITEMs benutze, was nimmt man da? Switches, die man ON oder OFF schaltet? Oder was ist für sowas in OH vorgesehen? Weiter wäre noch eine Frage, kann man die irgendwie zusammenfassen, also Gruppieren (von der Sortiererei her gesehen)? Wenn man sowas für die Steuerung benutzt, dann wird sicherlich irgendwann der Überblick schwinden, was man wo und wie benannt hat.

[udo1toni]

Du kannst beliebig Items anlegen (die sind dann ungebunden, das heißt, es gibt keinen Link zu einem Addon bzw. Binding). Items haben den Charme, dass man sie einfach in der UI sichtbar machen kann. Außerdem lassen sie sich leicht persistieren (mit mapdb) und beim Systemstart wieder herstellen, falls das wichtig sein sollte.

Variablen haben den Charme, dass sie sehr viel schneller in der Verarbeitung sind. Globale Variablen kannst Du (ruleübergreifend) ausschließlich über *.rules Dateien verwenden. Alle Rules, die auf die Variablen zugreifen sollen, sollten auch in der gleichen *.rules Datei gespeichert sein. Über die UI geht da nichts.

Welche Art Items und/oder Variablen Du verwendest, kannst Du selbst entscheiden (da kommt es ja auch drauf an, ob die Information binär ist oder es mehrere Möglichkeiten zur Auswahl gibt).
Für binäre Informationen bieten sich Boolean Variablen an, weil der Code extrem kompakt wird:

Code: Alles auswählen

var Boolean bNight = false

rule "System Start"
when
    System started // beim Systemstart aktuellen Stand ermitteln
then 
    bNight = now.getHourOfDay<7 || now.getHourOfDay>21 || (now.getHourOfDay==21 && (now.getDayOfWeek<5 || now.getDayOfWeek==7)) || (now.getHourOfDay<9 && now.getDayOfWeek>5) 
    // weitere Berechnungen, die beim Systemstart vollzogen werden müssen
end

rule "Nacht" // Umschaltung auf Nacht
when
    Time cron "0 0 21 * * SUN,MON-THU" or // Sonntag bis Donnerstag um 21 Uhr
    Time cron "0 0 22 * * ?" // spätestens um 22 Uhr
then
    bNight = true
end

rule "Tag" // Umschaltung auf Tag
when
    Time cron "0 0 7 * * MON-FRI" // Montag bis Freitag
    Time cron "0 0 9 * * ?" // spätestens um 9 Uhr
then
    bNight = false
end

rule "irgendeine Rule"
when
    // iregendein Ereignis
then
    if(bNight) {// Falls Nacht
        //tu irgendwas
    }
    if(!bNight) {// Falls Tag
        //tu irgendwas anderes
    }
end

Es sind also 4 Rules nötig. Dafür hast Du aber die Variable bNight, welche Du in allen Rules nutzen kannst und die Nutzung ist (siehe letzte Rule) denkbar einfach. Natürlich könnte man die zweite Möglichkeit auch mit einem else abbilden, ich habe hier aber bewusst die Negierung verwendet, um zu zeigen, wie das geht

Gegenstück:

Code: Alles auswählen

rule "irgendeine Rule"
when
    // iregendein Ereignis
then
var Boolean bNight = now.getHourOfDay<7 || now.getHourOfDay>21 || (now.getHourOfDay==21 && (now.getDayOfWeek<5 || now.getDayOfWeek==7)) || (now.getHourOfDay<9 && now.getDayOfWeek>5) 
    if(bNight) {// Falls Nacht
        //tu irgendwas
    }
    if(!bNight) {// Falls Tag
        //tu irgendwas anderes
    }
end

Eine Rule. Die Berechnung kann man natürlich auch direkt in die Bedingung einbauen, aber ich bin faul.

Sobald Du viele Stellen hast, wo Du auf die Information bNight zugreifen musst, spielt die erste Variante ihre Stärken aus.
Wenn Du lieber Astro als Quelle der Tag/Nacht Umschaltung nutzen willst, geht das natürlich genauso, dann musst Du als Berechnungsgrundlage in der Systemstart Rule halt die Elevation nutzen.

[manes]

aus einer Rule kann man ja ein Skript aufrufen. geht es auch aus einen Skript ein anderes Skript aufzurufen? Wenn ja, wie müßte man das schreiben?

[manes]

ich habe irgendwie nichts dazu gefunden. Kann man jetzt ein Script aus einem Script aufrufen, oder muß man das über ITEM Steuerung machen? Ich habe ein DSL Script.