Funktionen / Methoden in rules

[haiko]

Hallo zusammen,

ich habe eine Regel geschrieben, die aus mehreren sehr gleichförmigen Abschnitten besteht. Ich würde das jetzt gerne etwas vereinfachen, indem ich den sich wiederholenden Abschnitt in eine Funktion/Prozedur/Methode auslagere. Frage: wie stelle ich das am besten an. Was ist "Best Practice"?

a) Gibt es eine spezielle Syntax, um Funktionen in einem *.rules-File zu definieren
b) Muss man die doch etwas kryptische Lambda-Definition verwenden?
c) Gehören solche Funktionsbausteine in den Ordner .../openhab2/scripts/? Und wenn ja, wie ruft man die dann auf?

Dabei fällt mir noch die Frage ein: Wozu gibt es überhaupt den Ordner .../openhab2/scripts/?

Danke für die Hilfe
Haiko

[udo1toni]

Es kommt etwas darauf an was die Rule nun genau macht.

Gewöhnlich geht es oftmals um gleichartige Items, da böte sich eine Rule mit Gruppenitem an, aber wie gesagt, es kommt auf die Aufgabenstellung an.

Es gibt verschiedene Scripte, die man in den skripts Ordner legen kann. Auf jeden Fall kann man Scripte aus Rules heraus aufrufen. Das Blöde: Man kann keine(!) Parameter übergeben, womit Scripte eigentlich nur dann interessant sind, wenn man aus verschiedenen Rules heraus identischen Code ausführen muss, diese Rules aber nicht zu einer Rule zusammenfassen kann.

Ein Stück weit ist der scripts Ordner aus historischen Gründen vorhanden Man kann hier aber auch z.B. bash-Scripte ablegen. Mit executeCommandLine(scriptname) wird dann das Script ausgeführt. Liegt es im scripts Ordner, muss man keinen Pfad angeben.

Gesendet von iPad mit Tapatalk

[haiko]

Puh... OpenHAB schleppt ziemlich viel Historie mit sich rum...

Wie meinst Du das mit dem Gruppenitem?

[Tokamak]

Es ist tatsächlich so, dass in den .rules-Files nur Lambdas genutzt werden können, um Code aus einer Rule auszulagern. Diese Code-Fragmente sind auch nur aus dem einem .rules-File zugreifbar.

Generell würde ich kurz vor dem Release von OH 3.0 jedem OH-Neunutzer raten, die Rules links liegen zu lassen und direkt mit Python loszulegen, die in OH 3 zum Standard werden.
Hier hat man den großen Vorteil, alle Fähigkeiten von Python nutzen zu können, Funktionen, Klassen und Module.

[haiko]

Okay, das mit Python klingt interessant. Allerdings bin ich ein alter Java-Hase und da lagen mir die Rules mit dem Java-ähnlichen Code.

Bedeutet das, dass es in OH3 keine rules mehr geben wird? Wie programmiert man denn Regeln mit Python und wie verknüpft man dann die Items mit seinem Code?

[Tokamak]

Ich kann auch einigermaßen Java. Aber Xtend ist kein Java, vor allem nicht ohne Klassen. Python musste ich lernen, ist aber relativ einfach. Eine sehr pragmatische Sprache.

OH3 wird weiterhin Xtend-Rules unterstützen. So, wie jetzt OH2 noch V1-Bindings unterstützt, würde ich sagen. Soll heißen, dass es möglicherweise irgendwann nicht mehr geht, etwa mit OH4.
Im Hauptforum gibt es die klare Empfehlung, Python zu nutzen. Ich denke, es ist nicht mehr sinnvoll, mit Rules zu beginnen, wenn man neu startet.

Bei OH2 ist der Einsatz der Next Rule Engine noch mit ein bisschen Aufwand verbunden. OH3 habe ich mir noch nicht angeschaut.

Mit Hilfe der Helper Libraries können, den Xtend-Rules sehr ähnlich, Python-Rules geschrieben werden. Das notwendige findet sich hier.

[udo1toni]

Puh.

Python mag zwar nett sein und alle möglichen tollen Sachen bieten, die die Rules Engine nicht hat, aber bei näherer Betrachtung ist Vieles davon für die meisten Aufgaben auch gar nicht notwendig.
Es kommt natürlich auch sehr darauf an, wie jemand programmiert. Ich bin hier eher Laie (auch wenn ich schon das eine oder andere kleine Programm geschrieben habe - aber ich bin kein eben Informatiker und habe mir mein Wissen komplett selbst beigebracht). Ich nehme die Tools, welche zur Verfügung stehen, statt darauf zu bestehen, die Tools meiner Wahl zu verwenden.

Die Rules Engine steht auch unter OH3 zur Verfügung und ist bisher entgegen erster Ankündigungen noch nicht mal "zukünftig deprecated".

Ein kleines Beispiel, was ich mit Gruppen meine:

Code: Alles auswählen

rule "Betriebsart RTR"
 when
    Member of GHeat_Mode changed
 then
    var Integer newMode 
    val mode = (triggeringItem.state as DecimalType).toBigDecimal.toBigInteger
    val iName = triggeringItem.name.split("_").get(0).toString
    logDebug("rtr","Name is: {}, Mode is: {}",iName,mode)
    switch (mode) {
        case mode.testBit(0) : newMode = 1
        case mode.testBit(2) : newMode = 3
        case mode.testBit(3) : newMode = 4
        default : newMode = 2
    }
    var myItem = GHeat_Set.members.filter[ f | f.name.startsWith(iName) ].head
    var Integer oldMode = 0
    if(myItem.state instanceof Number) oldMode = (myItem.state as Number).intValue
    if(oldMode != newMode) {
        logDebug("rtr","Name is: {}, oldMode is: {}, newMode is: {}",myItem.name,oldMode,newMode)
        myItem.postUpdate(newMode)
    }	
end

Diese Rule kümmert sich um alle Raumtemperaturregler in meinem Haus. Wenn die Betriebsart eines RTR geändert wird (und zwar am RTR selbst oder auch aus der Ferne z.B. durch openHAB), so liefert ein Item, welches zur Gruppe GHeat_Mode gehört den neuen Status. Daraufhin wählt die Rule das passende Item, welches auf der Sitemap dargestellt wird aus der Gruppe GHeat_Set und setzt den Status dieses Items passend. Dabei ist die Meldung des Status, die vom RTR kommt eine andere, als der zugehörige Status. Das Item, welches in der Sitemap dargestellt wird, sendet bei Wahl einer Betriebsart diese an den RTR. Die gesendeten Betriebsarten sind 1, 2, 3 oder 4. Die empfangenen Betriebsarten sind 33, 34, 36 oder 40. Die Bits 0-3 geben also die Betriebsart wieder und das Bit 5 steht für Heizbetrieb (das ist halt in der Hardware so gelöst) weshalb ich hier diese Rule brauche.
Der Punkt ist aber, dass es exakt diese eine Rule braucht. Es spielt keine Rolle, wie viele RTR ich im Haus habe, es müssen nur die jeweiligen Items mit passendem Namen in den jeweiligen Gruppen zugeordnet sein. Ich muss keine Funktionen auslagern um effizient zu programmieren

Es gibt massig andere Beispiele, z.B. eine Rule, welche eine Tendenzanzeige für diverse Luft/Temperatursensoren realisiert, eine Rule, welche meldet, wenn Fenster geöffnet sind, und, und, und...

Die Rules DSL ist vergleichsweise langsam, das ist für mich das einzige Problem, dessentwegen ich mich demnächst auch mit Alternativen beschäftigen werde, aber solange die Rules DSL die einzige komplett integrierte Engine ist, lehne ich mich erst mal zurück.

[Tokamak]

Mit den Helper Libraries lassen sich auf die gleiche Art und Weise mit Python Regeln erstellen, beispielsweise bei mir:

Code: Alles auswählen

@rule("IstStufeBestimmen")
@when("Item Pluggit_Schalter_Stufe_1 changed")
@when("Item Pluggit_Schalter_Stufe_3 changed")
def bestimmeIstStufe(event=None):
    if items["Pluggit_Schalter_Stufe_1"] == OnOffType.ON:
        ist_stufe=1
    elif items["Pluggit_Schalter_Stufe_3"] == OnOffType.ON:
        ist_stufe=3
    else:
        ist_stufe=2

    events.post_update("Pluggit_Stufe_Ist", ist_stufe)

Wie man sieht, unterscheiden sich Standard-Xtend-Rules und Python-Rules mit den Helper-Libraries nicht allzusehr voneinander.

Aber: Ich kann zusätzlich(!) alles tun, was Python kann. Klassen, Funktionen, Module für gemeinsamen Code. Rules wie die obige decken bei mir daher nur vielleicht 25% der Funktionaliäten ab.

Für Xtend-Rules spricht, dass sich 99,9% aller Fragen und Beispiele in Foren darauf beziehen. Es dürfte daher einem Laien noch schwerer fallen, in OH mit Python zu starten als mit Xtend.
Wer allerdings ein wenig programmieren kann, sollte Python erwägen, selbst dann, wenn sie oder er aus der Java-Ecke kommt. Denn die Rules-DSL ist schon sehr spartanisch.

[peter-pan]

Also wenn ich die Ankündigung von Kai Kreutzer im internationalen Forum richtig verstanden habe, dann wird NGRE die offizielle Rule-Engine.

Wie es mit Python weitergeht, scheint aber noch nicht so ganz klar, da die Jython-Schnittstelle ja auf Python 2.7 basiert und die Entwicklung von Python 2 zum Jahresende wohl endet. Hier ist glaube ich noch einiges an Diskussionsbedarf zwischen Kai Kreutzer und Scott Rushworth. Vielleicht müssen wir uns ja bald mit Groovy oder javascript rumschlagen

Nach anfänglichen Problemen mit Python, muss ich als "Nichtprogrammierer" sagen, dass es gar nicht so schwierig ist, wie ich mir das vorgestellt habe. Das mit den Funktionen geht aber definitiv einfacher als mit DSL. Und die Listen-Abstraktion (List Comprehension) find ich auch besser als Lambdas, Filter, Map und Reduce (gibt's aber auch in Python). Klassen und Objekte sind mir aber "zu hoch", brauch ich aber auch nicht. Ich glaube auch, dass die Verarbeitung mit Jython-Rules fixer ist als mit DSL-Rules.

Ich habe zwischenzeitlich mein System (OH2.5.9) komplett auf Jython umgestellt und es läuft ganz gut. Ich hab jetzt im Prinzip 2 Produktionssysteme.