Aaaalso
Ein Item hat verschiedene Eigenschaften. Eine der Eigenschaften ist
.state. Wie der Name schon sagt, handelt es sich dabei um den Status des Items.
Achtung! Ein Status ist ein Status, nichts anderes.
openHAB ist an vielen Stellen sehr gnädig und konvertiert stillschweigend den Status in ein passendes Format, z.B. wenn man den Status in einen String einbaut. In Wirklichkeit wird aber nicht der Status eingebaut, sondern openHAB ergänzt die Methode
.toString, um aus
.state eben einen String zu zaubern.
Wenn Du einen Status hast, der eine Zahl enthält (z.B. ein Number Item Status) wird openHAB ebenfalls automatisch Konvertierungen ausführen, z.B. wenn Du in einer Bedingung den Status einfach mit einer Zahl vergleichst.
Du rufst allerdings eine Methode
.floatValue auf.
.state hat keine Methode
.floatValue.
Um also die Methode
.floatValue anwenden zu können, brauchst Du ein Objekt, welches diese Methode kennt, das wäre z.B. Number. Du musst also zunächst den Status in ein Objekt Number überführen, das geht am einfachstem mit dem Type casting
.state as Number
Aber Achtung, beim Type casting wird der Wert ohne Rücksicht auf Verluste dem neuen Objekt zugewiesen. Wenn der Wert nicht zum neuen Objekttyp passt, kommt es zu einer NullPointer Exception. Du tust also gut daran, zunächst zu prüfen, ob der Status tatsächlich einen Wert vom Typ Number enthält.
Number Objekte kennen die Methode
.floatValue, weshalb man anschließend eine Fließkommazahl hat.
Oftmals ist das Type Casting nicht unbedingt nötig, hier aber schon, denn nehmen wir an, Du hast zwei Status,
1.2 und
3.4. Wie gesagt handelt es sich um Status, nicht um Zahlen (auch wenn es sich um Status zweier Number Items handelt). Nun kommst Du mit dem Operator
+ um die beiden Status zu addieren, aber wie soll openHAB die beiden Status addieren? Soll es jeweils
.state.toString ausführen und anschließend einen String
1.23.4 abliefern, oder soll es die Status als Zahl interpretieren?
Es kann z.B. ausreichen, einen weiteren Wert zu addieren, also
0.0 + status1 + status2 (oder vielleicht muss die 0.0 auch als letztes addiert werden?), durch das Objekt
0.0 wird die Berechnung als Float Wert erzwungen.
Sauber ist das aber nicht, und vor allem wird man sich vermutlich nach ein paar Monaten oder gar Jahren nicht mehr daran erinnern, die 0.0 weg löschen und sich anschließend wundern, warum die Rule nicht mehr funktioniert.
Deshalb lieber sauber arbeiten:
Code: Alles auswählen
val lxSued = if(LSSuedLux.state instanceof Number) (LSSuedLux.state as Number).floatValue else -1
val lxWest = if(LSWestLux.state instanceof Number) (LSWestLux.state as Number).floatValue else -1
var lxAvg = 0.0
var count = 0
if(lxSued > 0) {
count += 1
lxAvg += lxSued
}
if(lxWest > 0) {
count += 1
lxAvg += lxWest
}
if(count > 1)
lxAvg = lxAvg / count
LUX_Mittel.postUpdate(lxAvg)
Huch...
Zunächst werden beide Items ausgelesen. Falls ihr Status einem NumberType entpricht, wird der Wert als Number interpretiert und als Floatwert in die lokale Konstante übernommen, ansonsten wird dort -1 hineingeschrieben.
Nun werden zwei lokale Variablen definiert, lxAvg (Float) und count (Integer).
Wenn lxSued größer als 0 ist, wird es zu lxAvg addiert und count um eins erhöht. Das gleiche passiert anschließend für lxWest.
Abschließend wird lxAvg durch count geteilt, falls count größer als 1 ist.
In der Folge steht in lxAvg entweder 0, der Wert aus lxSued, der Wert aus lxWest oder das Mittel aus beiden Werten, je nachdem, ob keines der Items, eines der Items oder beide Items einen gültigen Wert liefern.
Natürlich kannst Du auch darauf vertrauen, dass die Sensoren immer einen gültigen Wert liefern und entsprechend einfach
Code: Alles auswählen
LUX_Mittel.postUpdate(((LSSuedLux.state as Number).floatValue + (LSWestLux.state as Number).floatValue)/2)
schreiben, aber das kann halt schnell mal schief gehen.
Der Code ist ungetestet
aber das wäre mein Ansatz dazu...
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
