Korrekte Timer in Openhab3

[Baumtasche]

Hallo zusammen,

ich bin vor Kurzem von openhab 2.5 auf openhab 3.2 umgestiegen und habe aktuell noch ein wenig Probleme mit Javaskript. Aktuell bin ich mir nicht sicher, ob folgender Code richtig ist, bzw. ob es nicht noch eleganter geht.
Ziel ist es die Rolläden von meinen Fenster zeitverzörgert runterzufahren. Ich habe dazu folgendes Javaskript in einer Rule eingebaut, das auch funktioniert, ich bin mir aber nicht sicher, ob das nicht ein wenig eleganter / einfacher geht.

Code: Alles auswählen

var scriptExecution = Java.type('org.openhab.core.model.script.actions.ScriptExecution');

var zdt = Java.type('java.time.ZonedDateTime');

if (typeof this.timers === 'undefined') {
  this.timers = [];
}


if (typeof this.timers['fenster1'] === 'undefined' || this.timers['Test'].hasTerminated()) {
  this.timers['fenster1'] = scriptExecution.createTimer(zdt.now().plusSeconds(10), function () {
    events.sendCommand('fenster1_level', 'DOWN');
    if (typeof this.timers['Test'] !== 'undefined') {
      this.timers['fenster1'].cancel();
      this.timers['fenster1'] = undefined;
    }
    if (typeof this.timers['fenster2'] === 'undefined' || this.timers['fenster2'].hasTerminated()) {
      this.timers['fenster2'] = scriptExecution.createTimer(zdt.now().plusSeconds(10), function () {
        events.sendCommand('fenster2_level', 'DOWN');
        })
    }
    })
}

In Openhab 2.5 war es jeweils nur eine Zeile

createTimer(now.plusSeconds(5), [| Fenster1_Level.sendCommand(DOWN)] )
createTimer(now.plusSeconds(5), [| Fenster2_Level.sendCommand(DOWN)] )

[peter-pan]

Warum nutzt du die alte DSL-Rule nicht mehr ?

[udo1toni]

Frage 1: Warum steigst Du überhaupt um?

Frage 2: Warum startest du zwei Timer, die zeitgleich enden (diese Frage gilt schon für den DSL-Code)?

Antwort zur Code-Frage: Der Code als solcher sieht in etwa so aus, wie ich ihn erwarten würde (bis auf die zwei Timer). Java Script mag in der Ausführung schneller sein. In der Praxis spielt das aber keine Rolle. Probleme mit der Geschwindigkeit treten erst dann auf, wenn das System regulär mehrere hundert Rules pro Sekunde ausführen muss. Ist das der Fall, gebe ich Dir Brief und Siegel, dass Du openHAB verkehrt einsetzt

Da die ganzen systemspezifischen Funktionen in keiner anderen Sprache außer der DSL zur Verfügung stehen, braucht es immer viel mehr Code als in einer DSL Rule.

[Baumtasche]

Hi,

vielen Dank an euch, da bin ich dann auch beruhigt, dass ich es richtig gemacht habe.

Zu euren Fragen:

1. da bei 2.5 einige Bindings nicht gibt, bzw. unterstützt werden und ich mein System gerne auf den neuesten Stand bringen wollte
2. ich habe hier im Forum gelesen das DSL früher oder später "sterben" wird, deswegen will ich gleich auf die Zukunft setzen.
3. das mit den Timer war natürlich Blödsinn, der zweite hätte nach 15 Sekunden starten sollen

[udo1toni]

Zu 1.: Der Umstieg auf openHAB3 ist vollkommen in Ordnung und sinnvoll, selbst wenn man nichts vermisst, denn openHAB 2.5.12 ist die letzte 2er Version. Es gibt keine Bugfixes, es gibt keine Erweiterungen. Irgendwann wird 2.5.12 abgekündigt, dann kann man es noch nicht mal mehr runterladen oder installieren. Das ist aber komplett unabhängig von der Wahl der Regelsprache.

Zu 2.: Das habe ich auch mal geschrieben. Diese Aussage muss man aber mindestens relativieren. Es gab vor der ersten Beta von openHAB3 die Aussage, dass es sehr schwer wäre, Textkonfiguration und DSL in openHAB3 beizubehalten, weshalb es abgekündigt wurde. Als die Beta von openHAB3 dann an den Start ging, war alles vorhanden und von einer Abkündigung nichts mehr zu sehen.
Es gibt nach wie vor Bestrebungen, die Textkonfiguration irgendwie loszuwerden, aber nicht mal die Hauptentwickler verzichten auf diese Form der Konfiguration. Und nachdem der Code für diese Teile unter openHAB3 wunderbar funktioniert, gibt es auch keinen Grund mehr, das auszubauen.
Es gibt sogar mindestens einen Thread im englischen Forum, in dem explizit erklärt wird, dass die DSL nicht mehr deprecated ist.
JavaScript ist nicht die Zukunft. JavaScript ist eine der möglichen Sprachen, mit der man Regeln für openHAB erstellen kann. Solange es aber keine offiziellen Helper Libraries gibt, die den bequemen und einfachen Zugriff auf Items erlauben (mit allem, was die DSL ebenfalls erlaubt), ist JavaScript kein Ersatz für die DSL, genauso wenig wie die anderen Sprachen. Blockly wäre an dieser Stelle sogar noch die leichtere Variante, da selbst dort bessere Unterstützung für die spezifischen Funktionen in openHAB vorhanden sind.

Allgemein kommen die meisten Beschwerden über die DSL von Programmierern, die eben ihre Sprache verwenden wollen, ohne jemals ernsthaft die Vorteile der DSL ausgelotet zu haben. Es gibt keine Funktionen -> DSL schlecht.
Dass man in openHAB keine Funktionen braucht, spielt keine Rolle, denn der Programmierer ist es gewohnt, mit Funktionen zu programmieren, Punkt.
Und genauso läuft es mit den anderen Kritikpunkten...