Wie gesagt, von Java verstehe ich nichts und mit der Syntax kenne ich mich nicht aus, aber die von dir zuerst beschriebene Warnung kommt schon mal nicht mehr.
imports müssen, genau wie globale Variablen, zu Beginn der Datei angegeben werden. Die normale Reihenfolge ist dabei:
Zuerst imports, dann globale Konstanten, dann globale Variablen, dann Lambdas, zum Schluss die rules. Diese Reihenfolge ist aber sicher nicht zwingend, zumindest funktioniert bei mir das wilde mischen von Konstanten, Variablen und Lambdas ohne Probleme. Imports hab ich aber immer ganz oben.
Für das eigentliche Problem habe ich aber keine Idee. Vielleicht weiß im englischen Forum jemand Rat. Ansonsten bliebe immer noch der normale Weg über ein externes Script (oder mehrere davon).
openHAB5.1.2 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox VE 9.1.5 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte
Da bin ich ganz bei dir (wenn, dann externe Scripts, etc.).
Wenn ich das richtig verstanden habe was Rich und Scott im englischen Forum geschrieben haben , geht das mit JS223 und NGRE mit Helper-Libraries bzw. ab OH3.
Nachdem ich mich eine Weile mit dem Exec-Binding rumgeschlagen have, das wie executeCommandLine() nicht erwartungskonform mit Pipes umgehen kann, um den Befehl "env | grep ^OPENHAB_CONF= | cut -d= -f2" abzusetzen, habe ich eine einfache Lösung implementiert.
Einfach deswegen, weil sie etwa nicht mit mehrzeiligen Environmentvariablen umgehen kann.
val getenv = [ String envvar |
val line=executeCommandLine("env",1000).split('\n').findFirst[ s | s.startsWith(envvar+"=") ]
return if (line!==null) line.split('=').get(1)
]
...
val openhab_conf_dir=getenv.apply("OPENHAB_CONF")
liefert das gewünschte Ergebnis. Vermutlich muss unter Windows in der Lambda das "env" durch "set" ersetzt werden.