Exactly… Its for beginners like a friend of me. He has no clue about programming stuff. So we went directly in this trap. I think there must be a solution to compare if statements with UoM Strings.
Thanks.
Swen
Edit: Maybe another solution?
I have been struggling with the conversion to a number also. Your suggestion to use a multiply times one does the trick perfectly. Thanks for that 
1 Like
Hello,
I am running OH 3.4.5
I started play around with rules and Blocky
As first try, I basically tried to :
- retrieve a value from an item
- strip off the UoM from a measured value (W)
- save result to a virtual Item (still a W as UoM)
- show result in a widget
(please consider this is test only…)
It ended up in a null value shown
Can you give me any hint about?
Best Regards,
Leonardo
For OH 4+ users:
-
make your “virtual item” be just a
Numberand the units will be stripped off for you when you post update from the rule -
Or if you don’t want units in the first place, make the shellyem…Power_Consumption_1 Item be just a
NumberItem and the units will be dropped in the first place.
This doesn’t help with OH 3.4 but I wanted to make it clear for current and future OH 4 users that this is supported and much easier.
I believe 2 and 3 above will work in OH 3.4 too.
You have four logging lines. Which one showed null? What did the other ones show? Always share the logs. What about the code behind the blocks?
2 Likes
Get numeric state will do the trick to get an item without QT.
Just faced the same problem (thanks for the thread) when building a logic to convert dimmer values into dimmer values the LEDs can actually handle (flickering-problem).
I’m on OH 4.1, and both paths seem to work:
Going via the variable-path:
Going via the new UoM-route (requires OH 4):
Even though the latter is probably cleaner (is it?) I’ll go for the variable-path, since it looks way nicer in Blockly.
Update on what brought me here: Doing this…
… worked for a couple of checks (between 0 and 20, 20 and 40, and so on, but surprisingly not for the area between 80 and 100). Comparing numbers to strings appears to be not the most stable thing to do. 
There is no reason to use the Qty blocks unless at least one of the operands is a Quantity. If you are working with Dimmers, you are working with a PercentType, not a Number:Dimensionless so neither operand has units and the Qty blocks are superflous.
But I do see a problem with this version. “get state of item” returns the state of the Item as a String, always, no matter what type the Item is. If you want to compare the Item’s state to a number, use the `“get [name] of item” block and change the “name” to “numeric state”.
I worry that as written you might be doing a String comparison instead of a numerical comparison.
That settles that my concerns are founded, though the weird behavior is not expected.
Thanks for sharing your thoughts.
Surprisingly what I had at the beginning (comparing with Strings) did not work with the „80-100 behavior“. What I described above (working with variables) works great. So unless there’s another quick fix that’s neater, I‘d probably leave things as they are.
The quick fix is as I describe above. Use the “get [quantity type] of item” block.
and compare to numbers.
1 Like
This works great! Thanks a lot!