Getting Item value without unit

Setup, Configuration and Use Scripts & Rules
1

Hi.
This feels like a question that could be answered by reading documentation and forum, so apologies in advance, but I can’t seem to find it…

I have some Items that I’ve been keeping in .items files because I needed Expire for them. Since upgrading to 3.0 I thought I might as well move them in to the gui instead. It’s just that since doing that I can’t seem to get the value from them without also getting the unit.

When having them in .items files I could set their label to something like “Utetemperatur [%.1f °C]” and the value I got out was simply “7.2” for Utetemperatur.state in my rules (though I never really understood the logic of the label controlling the format of the value), but now that doesn’t seem to work any more.

When doing something like “(Utetemperatur.state as DecimalType).doubleValue” now I get “Could not cast 7.3 °C to org.openhab.core.library.types.DecimalType”.

Anyone could tell me what I’m missing?

1 Like
2

Can you show your Item configurations (old and new)? Sounds like your new Item is of type Number: Temperature rather than just Number…

3

If you add unit to the item than is no longer a DecimalType but a QuantityType - so please try with

(Utetemperatur.state as QuantityType<Temperature>).doubleValue

EDIT: yeah, typing answers from my phone :roll_eyes: - QuantityType is a generic type and one needs to provide unit as well - update code above.

3 Likes
4

Indeed, you are correct. Changing the type to just Number and including the [%.1f °C] in the label seems to do the trick.

This feels a bit like a workaround though, is there a way having it as Number:Temperature and still getting just the value in the rules?

5

Ah… That’s much better!

I get a warning in the log though, any idea why?

10:42:48.391 [INFO ] [del.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'temp.rules', using it anyway:
QuantityType is a raw type. References to generic type QuantityType<T> should be parameterized

edit: I think it should be QuantityType<Temperature>. Testing and reporting back :slight_smile:

6

The reason for having Temperature is the units. OH can then convert the device’s reported units to your familiar ones should they differ.

1 Like
7

There are situations where it makes sense to strip the units, but rather than stepping backwards, why not modify your rules to take advantage of QuanityType? If you post a rule example using DecimalType, we could show you how to migrate it.

1 Like
8

That’s exactly what I did :sunglasses: After the suggestion from @crnjan above I changed DecimalType to QuantityType<Temperature> and after that everything works nice again.

9

I guess what others are trying to point out is that there is more than meets the eye with QuanityType - if you “strip” out just the doubleValue as an example, you are loosing the unit - consider having

if((Utetemperatur.state as QuantityType).doubleValue > 20)

vs

if (Utetemperatur.state > 20|°C)

both works fine if Utetemperatur has temperature in °C, but you will see strange results if Utetemperatur would have °F for first example above, while the second one would take unit into account and convert values before comparing them.

3 Likes
10

Ah… Good points. I guess the core learning of this is that if the system knows more about my value than just a pure digit it can do smarter stuff :sunglasses:

However, in this particular case I need the pure value in order to send it to a rest api that only accepts a number. Converting it to a double is perfect for that.