openhabforum.de

Hallo zusammen,

zu dem Thema habe ich nun schon einige Beiträge im Netz gefunden - vor allem im englischsprachigen OpenHab Forum. Allerdings ist das Problem für mich noch nicht so ganz gelöst. Wer weiß, vielleicht geht das ja auch gar nicht.

Ganz allgemein möchte ich eine Funktion mit Parameter definieren können und diese Funktion in jeder beliebigen Rule mit Übergabe eines Items aufrufen.

Konkret hätte ich hier ein sehr einfaches Beispiel:
In meinem Haus habe ich Taster statt Schalter verbaut. Klickt man einen Taster, schaltet er er den aktuellen Status einer Lampe um (ON --> OFF oder OFF --> ON).

Aktuell habe ich das über diesen Zweizeiler im DSL Script gelöst. Den konte ich einfach in die einzelnen Rules kopieren und statt MyItem den konkreten Item-Namen der entsprechenden Lampe eintragen.

Lieber wäre mir, ich könnte eine Funktion vordefinieren und diese dann in den Rules aufrufen. Dann könnte ich zum einen die Funktion erweitern, wenn mir danach ist und zum anderen reduzieren ich die Gefahr von Tippfehlern.

Ich habe auf meiner Suche die Lambda-Funktion gefunden und geglaubt, das könnte der richtige Weg sein. bin aber noch nicht wirklich weiter gekommen.
Quelle: https://community.openhab.org/t/reusab ... otes/15888

Hier ist die Lambda Funktion allerdings in einer *.rules Datei verwendet worden. Damit ist die Funktion in allen Rules dieser Datei verfügbar.

Aber wie mache ich das in der GUI in OpenHab4. Ich müsste die Funktion val log... in einem Rule DSL Script eintragen. Aber wie rufe ich die Funktion dann in einer Rule auf?

Die kurze Antwort: openHAB unterstützt keine Funktionen.
Lambdas sind eine Option, das Problem zu umgehen, aber es handelt sich nicht wirklich um Funktionen. Außerdem bestehen Einschränkungen wenn man mit Lambdas arbeitet.
Für die beschriebene Aufgabe (Toggeln eines Items wenn ein anderes Item auf ON wechselt) wäre die "korrekte" openHAB Lösung aber ohnehin eine andere.
Du definierst zwei Group Items (man könnte es auch mit einer Group lösen, aber so ist es einfacher), z.B. gTaster und gRelais.
In die Gruppe gTaster kommen alle Taster-Items (ach...) und in die Gruppe gRelais kommen alle zu schaltenden Items.
Dabei verwendest Du ein Namensschema für beide Item-Sorten, z.B. Licht1_Taster und Licht1_Relais, Licht2_Taster und Licht2_Relais und so weiter.
Es gibt also in der jeweils anderen Gruppe ein Item, welches zu einem Item der einen Gruppe passt und im ersten Namensteil identisch beschriftet ist.
Nun legst Du eine (!) Rule an: Eine Rule. Für alle Taster. Und wenn Du noch mehr Taster einbauen willst, musst Du nur die Itemnamen passend setzen und die Items den Gruppen zuordnen, die Rule bleibt wie sie ist.

udo1toni hat geschrieben: ↑3. Nov 2023 01:56 Die kurze Antwort: openHAB unterstützt keine Funktionen.

etwas länger

rlkoshak hat geschrieben:In every rules language except Rules DSL (even Blockly) you can access Item metadata and have rules that call other rules.

Sorry, konnte ich mir einfach nicht verkneifen. Duck und weg

Ja, aber das ist keine Funktion

Doch, solange kein Rückgabewert benötigt wird. Na gut, ist eine Frage der Definition. Bei JS können zusätzlich #Libraries mit eigen Funktionen erstellt werden. Die Block Libraries, welche man auch selbst basteln kann, sind imho auch nichts anderes als Funktionen. Für Toggle (in Collection of common blocks enthalten) gibt es das sogar schon, zu mindestens wenn man die Funktion noch selbst auf GraalJS anpasst.

Aber egal, viele Wege führen nach Rom. Dein Lösungsvorschlag mit den Gruppen ist (selbstverständlich) alles andere als eine Notlösung.

Der Punkt ist, wenn ich eine Rule aufrufe, dann ist das eben eine Rule, keine Funktion.
Man kann in der DSL mit callScript(scriptname) auch Code ausführen lassen, der an anderer Stelle gespeichert ist. Man kann halt leider keine Parameter übergeben, was diesen Code dann recht starr macht. Allerdings kann man vor dem Aufruf die Parameter in Items schreiben, welche dann in dem Script ausgelesen werden können. Nur ist das absurd kompliziert und man gewinnt fast sicher nichts dabei, außer dass man am Ende des Tages dutzende Zeilen Code geschrieben hat, statt die drei Zeilen, die es gebraucht hätte.

Und Item Metadaten als Wertübergabe erscheint mir jetzt nicht als vollwertige Funktion.
Für Blockly kann man eigene Funktionsblöcke erstellen, das sind tatsächlich Funktionen. Das geht auch mit anderen Scriptsprachen, aber eben nicht in der DSL, und schon gar nicht sprachübergreifend.

Klevere Lösung.
Danke

... auch wenn es schade ist, dass echte Funktionen nicht funktionieren.

Viele Grüße,
Alexander

udo1toni hat geschrieben: ↑3. Nov 2023 01:56 Die kurze Antwort: openHAB unterstützt keine Funktionen.
Lambdas sind eine Option, das Problem zu umgehen, aber es handelt sich nicht wirklich um Funktionen. Außerdem bestehen Einschränkungen wenn man mit Lambdas arbeitet.
Für die beschriebene Aufgabe (Toggeln eines Items wenn ein anderes Item auf ON wechselt) wäre die "korrekte" openHAB Lösung aber ohnehin eine andere.
Du definierst zwei Group Items (man könnte es auch mit einer Group lösen, aber so ist es einfacher), z.B. gTaster und gRelais.
In die Gruppe gTaster kommen alle Taster-Items (ach...) und in die Gruppe gRelais kommen alle zu schaltenden Items.
Dabei verwendest Du ein Namensschema für beide Item-Sorten, z.B. Licht1_Taster und Licht1_Relais, Licht2_Taster und Licht2_Relais und so weiter.
Es gibt also in der jeweils anderen Gruppe ein Item, welches zu einem Item der einen Gruppe passt und im ersten Namensteil identisch beschriftet ist.
Nun legst Du eine (!) Rule an:

Code: Alles auswählen

rule "toggeln was das Zeug hält"
when
    Member of gTaster changed to ON
then
    val chan = triggeringItem.name.split("_").get(0)
    val swItem = gRelais.members.filter[i|i.name.startsWith(chan)].head
    swItem.sendCommand(if(swItem.state != ON) ON else OFF)
end

Eine Rule. Für alle Taster. Und wenn Du noch mehr Taster einbauen willst, musst Du nur die Itemnamen passend setzen und die Items den Gruppen zuordnen, die Rule bleibt wie sie ist.

AlexT hat geschrieben: ↑6. Nov 2023 21:49 auch wenn es schade ist, dass echte Funktionen nicht funktionieren.

Na ja, Du kannst auf andere Programmiersprachen ausweichen. Es ist nur so, dass oftmals die Funktion gar nicht der elegante Weg ist