Ja, es stehen nicht alle Variablentypen als Primitive zur Verfügung.
Andererseits sollte man ohnehin immer Objekte verwenden, solange es keinen zwingenden Grund für ein Primitive gibt.
Das ganze Konstrukt ließe sich vermutlich einfacher programmieren
Aber zunächst mal: Dir ist bewusst, dass das empfangene Kommando keinesfalls mit dem Status eines Items gleichgesetzt werden kann?
In Rules stehen implizite Variablen zur Verfügung, beispielsweise
triggringItemName enthält den Namen des Items, welches die Rule getriggert hat (sofern der Trigger
Item ... lautet). Diese Variable ist vom Typ String, das .toString ist also unnötig.
Eine weitere implizite Variable wäre
newState, diese ist bei Rules gesetzt, die auf
received update oder
changed getriggert haben, aber es gibt auch
receivedCommand, welches den empfangenen Befehl beinhaltet (und das wäre hier vermutlich der gesuchte Wert,
nicht der Status). Zu bemerken wäre hier noch, dass newState (genau wie
previousState bei
changed Ereignissen) einen
Status enthalten, während
receivedCommand ein
Command enthält. Beide wären streng genommen mittels .toString zunächst in einen String zu wandeln, bevor man sie mit Stringoperationen verwendet. openHAB wird aber an vielen Stellen stillschweigend die Konvertierung selbst vornehmen..
Die Namenszuordnung (wenn man das denn überhaupt bräuchte) könnte etwas hübscher aussehen:
Code: Alles auswählen
var String _txt = ""
switch(_src) {
case "Durchsage_Buero" : _txt = Durchsage_Buero.state.toString
case "Durchsage_Aussen" : _txt = Durchsage_Aussen.state.toString
case "Durchsage_OG" : _txt = Durchsage_OG.state.toString
case "Durchsage_EG" : _txt = Durchsage_EG.state.toString
}
aber selbst das ginge wesentlich eleganter, vorausgesetzt, man hat alle Items zu einer Gruppe zusammengefasst:
Code: Alles auswählen
rule "Durchsage"
when
Item Durchsage_Buero received command or
Item Durchsage_Aussen received command or
Item Durchsage_EG received command or
Item Durchsage_OG received command
then
//Quelle identifizieren
var string _src = triggeringItemName
logInfo("durchsage", "Quelle: {}",_src)
//Text bestimmen
var String _txt = ""
_txt = gDurchsage.members.filter[i|i.name == _src].head.state.toString
Wobei man dann auch gleich die Gruppe als Trigger verwenden kann:
Code: Alles auswählen
rule "Durchsage"
when
Member of gDurchsage received command
then
//Quelle identifizieren
var string _src = triggeringItem.name
logInfo("durchsage", "Quelle: {}",_src)
//Text bestimmen
var String _txt = ""
_txt = triggeringItem.state.toString
Wie gesagt, vermutlich möchtest Du
eigentlich receivedCommand verwenden...
Kleines Detail: bei
Member of gibt es die implizite Variable
triggeringItem (ohne Name), und diese Variable ist vom Typ genericItem, d.h. sie verhält sich exakt wie das Item, welches die Rule ausgelöst hat. Man kann auf alle Aspekte dieses Items über die implizite Variable zugreifen, ohne noch weiteren Aufwand zu treiben.
Was die logInfo() Action betrifft: Bitte, bitte... openHAB hat eine äußerst leistungsfähige Logger Engine verbaut.
logInfo("durchsage","Meine Meldung") erzeugt einen Logeintrag des Levels
INFO (nicht DEBUG), und zwar mit dem Logger
org.openhab.core.model.script.durchsage und dem Text
Meine Meldung. Bitte im ersten String keine Sonderzeichen verwenden, bitte keine Leerzeichen verwenden, es handelt sich um den letzten Teil des Loggernamens.
Es gibt die Möglichkeit,
im laufenden Betrieb den
Loglevel pro Logger zu beeinflussen. Das geht zunächst mal über die Karaf Konsole, aber sobald der Logger einmal explizit genannt wurde (über die Karaf Konsole...), kann man den Loglevel in openHAB4.3.0stable auch direkt in der neuen UI Log Konsole umschalten, von INFO (das ist der default Wert) z.B. auf
WARN (damit wäre logInfo für den betreffenden Logger dann "abgeschaltet"), aber auch auf
DEBUG. Es gibt nämlich nicht nur
logInfo(), sondern auch noch
logDebug(),
logWarn() und
logError(). Die verschiedenen Level werden dann nicht nur unterschiedlich in der Log Ausgabe dargestellt, sondern gar nicht erst erfasst, wenn man das LogLevel entsprechend einstellt, alles unterhalb des gewählten Levels wird ignoriert.
Außerdem substituiert die Action die geschweiften Klammern {} im zweiten String mit den nachfolgenden Parametern, im Bespiel oben also dem Inhalt von _src, das ist besser, als einfach die Variable so zu übergeben.
Zusammengefasst: Es lohnt sich, den Logger so zu verwenden, wie es vom System gedacht ist.
EDIT: Da sich der Inhalt des Beitrags etwas gedreht hat, hab ich den Titel angepasst. 
Direkt eine Frage: Ich verwende VisualStudioCode mit dem Openhab Plugin
