openHAB3 -> CronJobs ?

[Steinspiel]

Moin,

Habe endlich damit angefangen von OH2 auf 3 um zu steigen...

Ich habe vor alle Rules in OH3 neu an zu legen, trotzdem ne kleine Nebenfrage:
wie ich in der Rules/Codeansicht sehe scheint die Syntax von der in OH2,

Code: Alles auswählen

rule "rule name"
when    
then
end

ziemlich ab zu weichen (wie heißt die neue "Programmierung" überhaupt?). Kann man die "alten" Rules trotzdem noch in OH3 verwenden?

Nun zu meiner eigentlichen Frage: in OH2 habe ich ziemliche viele virtuelle Schalter, die über CronJobs gesteuert wurden, genutzt:

Code: Alles auswählen

rule "einschaltzeit_morgens"
when
        Time cron "0 25 4 ? * MON,TUE,WED,THU,FRI *"	// Werktags 04:25 Schaltzeit
then
        UHR_morgen.sendCommand(ON)
end

Wie gehe ich da in OH3 vor:
Wie lege ich das ITEM "UHR_morgen" an, und
wie die dazu gehörige Rule?
Und kann ich in einer Rule mehrere CronJobs mit mehreren ITEMS eintrage, ähnlich wie in OH2?

Ich hoffe ich habe mich nicht zu verworren ausgedrückt...
Danke und einen schönen Abend noch.

[udo1toni]

Tu Dir einen Gefallen und gib den Plan auf, alles komplett neu zu machen. Die DSL Rules laufen unter OH3 genauso wie unter OH2 (aus den *.rules Dateien heraus).
Es gibt eigentlich nur zwei Dinge, die angepasst werden müssen, die eine Sache ist nicht weiter kompliziert und betrifft die implizite Variable triggeringItem. Diese stand bisher in allen Rules zur Verfügung, die durch ein Item getriggert wurden.
Unter OH3 steht diese Variable nur noch zur Verfügung, wenn die Rule auf Member of ... triggert. In allen anderen Rules, die auf Item ... changed oder ... received update/command triggern, musst Du stattdessen triggeringItemName verwenden und erhältst auch nur einen String, eben den Namen des triggernden Items. triggeringItem ist aber ein generic Item mit allem, was dazu gehört, Methoden und Eigenschaften, z.B. kann man mit triggeringItem.name auch den Namen abrufen, aber auch mit triggeringItem.state den Status holen, ...

Die andere Sache hat es dafür in sich, das ist die Umstellung von Joda Time auf JavaTime. Hast Du bisher now.plusMillis(x) geschrieben, musst Du nun now.plusNanos(1000000 * x) schreiben. Die höhere Genauigkeit besteht nur in der Theorie und nutzt uns in der Praxis genau nichts, man benötigt nur zusätzlich jede Menge Nullen für den Job (wie im richtigen Leben halt...) Und es gibt noch jede Menge andere Unterschiede mit JavaTime, die einem den letzten Nerv rauben, bis man sie gefixt hat.
Allerdings spielt es da keine Rolle, ob Du die Rule neu schreibst oder umschreibst, denn solange Du die Funktion als solche nicht änderst, musst Du sie ja doch in der neuen Version hinschreiben.

Du erlangst auch keinen Vorteil, indem Du die Rule in der UI erstellst, außer, dass Du sie über die UI bearbeiten kannst, aber mal ehrlich: wer will das denn?

Der Code einer DSL Rule, die keinen Bezug auf Joda Time verwendet, ist identisch in der UI.

Der Code, nicht die komplette Rule!

Die Rule beinhaltet nämlich noch eine Liste der auslösenden Trigger (der when-Part), dieser wird nun getrennt verwaltet. Die Code-Ansicht einer UI Rule zeigt die Konfiguration in yaml an (Achtung: yaml nutzt Indentations - Einrückungen, es ist also nicht egal, wie viele Leerzeichen zu Beginn einer Zeile stehen. Damit ist es zwingend, dass Code auch als Code markiert gepostet wird, ansonsten geht der Code kaputt.)

In der UI erstellte Rules können keine globalen Variablen verwenden! Allein diese Tatsache ist ein Rückschritt, auch wenn man natürlich an vielen Stellen ungebundene Items als Ersatz verwenden kann (aber z.B. var Timer myTimer = null geht überhaupt nicht...)

[Steinspiel]

Tu Dir einen Gefallen und gib den Plan auf, alles komplett neu zu machen.
[...]

Ursprünglich dachte ich auch so, sah aber dann wie unterschiedlich die Rules für mich aussehen...

die auf Item ... changed oder ... received update/command triggern, musst Du stattdessen triggeringItemName verwenden und erhältst auch nur einen String, eben den Namen des triggernden Items.

Das ist (hoffentlich noch) ziemlich verwirrend. Wie soll ich da ein OH2 Rule verwenden?

Code: Alles auswählen

rule "oh2_test_AN"
when
    Item Test_A changed to ON
then
    Hue_Play1_Power.sendCommand(ON)                           
end

und

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Testschalter_A
      state: ON
      previousState: ""
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: HuePlay1_Color_Temperature
      command: ON
    type: core.ItemCommandAction

machen so ziemlich das gleiche: beide Virtuellen Items schalten eine Hue Lampe ein. Nur habe ich den OH3 Code mir "mühsam" zusammengeklickt...
Will damit sagen, so ich wüsste nicht, wie ich praktisch so ne einfache OH2 Rule in OH3 übernehmen sollte.

Die andere Sache hat es dafür in sich, das ist die Umstellung von Joda Time auf JavaTime. Hast Du bisher now.plusMillis(x) geschrieben,
[...]

Da habe ich mich wohl missverständlich ausgedrückt: Ich hatte keine echten CronJobs gemeint. Vielmehr habe ich, wenn eine mit "time cron" definierte Zeit eingetreten ist, ein Item geschaltet. Wie oben in meinem zweiten Codebeispiel.

Das jetzt ist überhaupt ein gutes Beispiel für die Integration: in der UI habe ich obiges zweiten Codebeispiel nachgebaut:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      time: 04:25
    type: timer.TimeOfDayTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: Uhr_morgen
      command: ON
    type: core.ItemCommandAction

Das Item schaltet um 04:25 UHR, nur täglich...
Wie stell ich das auf Wochentags...? Oder besser noch, wie migriere ich meine vorhanden "OH2 Zeitschalt Rule" in OH3 ?

Ich denke ich fange erst mal so an bevor ich auf die Probleme stoße die mir wirklich den letzten Nerv rauben!

Danke für Deine ausführliche Antwort, auch wenn sie, im Moment, mehr Fragen bei mir bewirkt hat als Antworten ...

[int5749]

Danke für Deine ausführliche Antwort, auch wenn sie, im Moment, mehr Fragen bei mir bewirkt hat als Antworten ...

Verstehe ich im Moment nicht. Mit ....

Tu Dir einen Gefallen und gib den Plan auf, alles komplett neu zu machen. Die DSL Rules laufen unter OH3 genauso wie unter OH2 (aus den *.rules Dateien heraus).

... hatte Udo schon schon erklärt, dass Du (bis auf die Anpassung mit Joda Time) Deine Rules-Dateien aus OH 2 weiterhin verwenden kannst.

Habe und mache ich ganz genau so.

Natürlich kann man weiterhin mit der UI "spielen" und Erfahrungen sammeln, aber es ist keine Notwendigkeit umzustellen.

VG

[Steinspiel]

Nabend,

[...]
... hatte Udo schon schon erklärt, dass Du (bis auf die Anpassung mit Joda Time) Deine Rules-Dateien aus OH 2 weiterhin verwenden kannst.
Habe und mache ich ganz genau so.

Und wie machst Du das Praktisch, erstellst in der UI eine neue Rule und kopierst dann die OH2 Rule in die Codeansicht von OH3 /settings/rules/*** ?
Das ging bei mir nicht!

Danke,

Ach ja, das "Problem" mit dem schalten von Items zu bestimmten Uhrzeiten an bestimmten Wochentagen, da habe ich eine Lösung gefunden:

Code: Alles auswählen

***
    configuration:
      cronExpression: 0 25 04 * * 7 *
    type: timer.GenericCronTrigger
***    

[KellerK1nd]

Du nutzt die alte Vorgehensweise über VisualStudioCode einfach weiter.

[peter-pan]

Und wie machst Du das Praktisch

Das geht ganz einfach so wie @udo1toni und @int5749 das ja schon beschrieben haben. Du legst die Rule wie gesagt mit einem Editor (z.B. VSC) ganz genau wie früher als xxx.rules-Datei an(oder kopierst sie einfach). Den Yaml-code dazu kannst du dir dann über die MainUI (Einstellungen/Rules) anschauen. Du musst nur wissen, das jede Rule in einem Rules-File, das mehrere Rules beinhaltet, extra angezeigt wird, und zwar in alphabethischer Reihenfolge des Rule-Namens. Intern werden die einzenlen Rules eines Rule-Files durchnummeriert.

DSL-Rule:

Code: Alles auswählen

rule "WasserSensor"
   when 
    Member of gWatAlTrig changed from OFF to ON
   then 
    val SensorName  = triggeringItem.label.toString
    logWarn("wasseralarm", "Achtung WasserSensor hat ausgelöst {}", SensorName)
    val mailActions = getActions("mail","mail:smtp:tonline-smtp")
        mailActions.sendMail("nick.knatterton@t-online.de", "Wasseralarm ELW", "OH3 - Wassersensor meldet Alarm " )
    DotPeterTextToSpeechVolume.sendCommand(60)
    DotPeterTextToSpeech.sendCommand("Wassersensor meldet Alarm")
    DotPeterTextToSpeechVolume.sendCommand(0)
end 

wird dann in der MainUI so angezeigt:

Code: Alles auswählen

// Triggers:
// - When a member of gWatAlTrig changed from OFF to ON

// context: homematic-18

   val SensorName  = triggeringItem.label.toString
   logWarn("wasseralarm", "Achtung WasserSensor hat ausgelöst {}", SensorName)
   val mailActions = getActions("mail","mail:smtp:tonline-smtp")
       mailActions.sendMail("nick.knatteron@t-online.de", "Wasseralarm ELW", "OH3 - Wassersensor meldet Alarm " )
   DotPeterTextToSpeechVolume.sendCommand(60)
   DotPeterTextToSpeech.sendCommand("Wassersensor meldet Alarm")
   DotPeterTextToSpeechVolume.sendCommand(0)

[Steinspiel]

Moin,

Du nutzt die alte Vorgehensweise über VisualStudioCode einfach weiter.

Das geht ganz einfach so wie @udo1toni und @int5749 das ja schon beschrieben haben.
[...]

Aber warum sagt das denn niemand!!!
Die Welt sieht jetzt völlig anders aus!

Scherz beiseite: Das habe ich nicht gewusst und was Udo geschrieben hat, habe ich letztendlich auch nicht so richtig geschnallt!

VSCode läuft inzwischen mit API Token usw. Aus den angezeigten Things im openHAB Bereich habe ich mir meine eigene *.ITEMS erstellt, nur die angezeigten ITEMS bekomme ich nicht in meine ITEMS Datei, aber das brauch ich auch nicht, denn sie funktionieren trotzdem.
Zwei erste kleine Rules sind erstellt und funktionieren und sie werden mir (mit einem-Schloss Symbol versehen) in der MainUI angezeigt!
Also soweit alles bestens fürs erste.

Allerdings habe ich da noch ein ziemlich "großes" Problem:
auf einem zweiten Raspi läuft natürlich noch OH2.5x. In der VSCode settings.json habe ich diese Einträge auskommatiert und die Einstellungen für OH3 eingetragen. Der Verzeichnissbaum für die OH2 Files wird mir zwar noch angezeigt (ist in Win10 als NetzLW verbunden), nur werden mir, logischer Weise, auch für jede Rule zig Error Meldungen angezeigt.
Lass ich beide Konfigurationen in der settings.json, so habe ich auch Fehlermeldungen...
Wie ist das, muss ich jedesmal die settings.json wechseln, je nach dem mit welchen openHAB ich arbeiten will?

Danke, schönen Sonntag noch und ich werde noch etwas basteln...

[udo1toni]

Du hast bei VSCode verschiedene Möglichkeiten der Konfiguration.
Entweder Du nutzt Arbeitsbereiche (Datei -> Arbeitsbereich speichern, bzw. das Gegenstück, Arbeitsbereich aus Datei öffnen. Die zuletzt verwendeten Arbeitsbereiche werden ebenfalls zus Auswahl angeboten.) oder Du hinterlegst die Einstellungen im Arbeitsordner.
Es gibt 4 verschiedene Quellen für jede Einstellung, eben die Default Werte, die User Einstellungen, die Arbeitsbereichseinstellungen XODER die Ordnereinstellungen (XODER -> entweder oder, nicht gleichzeitig)
VSCode zeigt an, wenn ein Wert in mehreren Bereichen gesetzt ist (bis auf den Default Wert natürlich)

Wählst Du den Arbeitsbereich, kann VSCode sowohl den geöffneten Ordner umschalten als auch die passenden Einstellungen für das openHAB Plugin laden. Dabei kannst Du Werte, die für alle Instanzen gleich sein sollen auch als Usereinstellungen speichern und nicht in den Arbeitsbereichseinstellungen setzen, übersichtlicher ist es allerdings, die Einstellungen nur an einer Stelle vorzunehmen.

Achtung: Meiner Erfahrung nach (kann aber sein, dass das nicht mehr aktuell ist...) muss man nach dem Wechsel des Arbeitsbereichs (oder auch des Ordners...) VSCode einmal schließen und wieder öffnen, damit das Plugin auch den korrekten Server nutzt.

[peter-pan]

VSCode läuft inzwischen mit API Token usw. Aus den angezeigten Things im openHAB Bereich habe ich mir meine eigene *.ITEMS erstellt, nur die angezeigten ITEMS bekomme ich nicht in meine ITEMS Datei, aber das brauch ich auch nicht, denn sie funktionieren trotzdem.

Also das hab ich jetzt nicht ganz verstanden . Du generierst Items und kannst sie nicht sehen, aber benutzen ???

Was den VSC-Editor betrifft, bevorzuge ich die Ordnereinstellungen (openHAB-conf). Hier lege ich ein Unterordner ".vscode" mit der spezifischen "settings.json"-Datei an.
Beispiel mit zwei geöffneten Fenstern (OH2 und OH3)

vsc.jpg

Ausserdem habe ich auch noch unter C:\Users\.... eine "settings.json". Ich nehme an, das ist die "Standard-Version":

Code: Alles auswählen

{
  "openhab.languageserver.remoteEnabled": true,
  "openhab.languageserver.remotePort": 5007,
  "openhab.connection.host": "192.168.178.24",
  "openhab.connection.port": 8080,
  "openhab.useRestApi": true,                    
  "openhab.connection.authToken": "",
//  "openhab.remoteLspEnabled": true,                     // alt
//  "openhab.host": "192.168.178.75",                     // alt
//  "openhab.port": 8080,                                 // alt
//  "openhab.remoteLspPort": 5007,                        // alt
//  "openhab.sitemapPreviewUI": "basicui",                // alt
  "openhab.connection.basicAuth.username": "",   
  "window.zoomLevel": 0,
  "editor.fontSize": 12,
  "editor.renderWhitespace": "none",
  "editor.renderControlCharacters": true,
  "breadcrumbs.enabled": true,
  "workbench.startupEditor": "newUntitledFile",
  "editor.minimap.enabled": false,
  "workbench.statusBar.visible": true,
  "workbench.activityBar.visible": true,
  "workbench.sideBar.location": "left",
//  "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\cmd.exe",
  "terminal.integrated.defaultProfile.windows": "Command Prompt",        // neu, anstelle von "terminal.integrated.shell.windows"
  "workbench.iconTheme": "openhab",
  "editor.fontLigatures": false,
  "workbench.editor.untitled.hint": "hidden",
    
 }