If you are working with a String, what’s the problem? Whether it has the units or not you can’t do math with a String anyway?
If you are doing math, then show us what you are doing. Usually the best approach is to stay working the units. But sometimes it isn’t but we need to see your broken rule to tell.
I managed to convert the rule eventually but it wasn’t very straightforward, so doubting whether I will adopt this UOM broadly.
I changed it to the following but maybe there is a more elegant and intuitive way to achieve the same.
I could get rid of the creation of the variable but this way I could at least print the variable in the logs to see what the output was during the whole journey.
Don’t over specify the types of variables in Rules DSL so you don’t need var String temptosendliving but instead just var temptosendliving.
@JimT is correct, you should make sure the units are right for what your API expects. This temperature so it could be storing °F, °C or °K. Calling toBigDecimal is just going to give you what ever units the Item happens to be storing. You’d use toUnit() for that.
(TempLivingTarget.state as QuantityType).toUnit('°C')
That’s kind of the point of QuantityTypes in the first place. Even if you are given °F, you don’t care and you don’t have to do anything special to convert to °C. You just need to tell OH that it’s °C that you want.
After that point there are a number of options available to you to strip off the units. They are all pretty much the same in terms of length.
If you were doing math or comparisons, in Rules DSL, you can add units to a number with | <unit>. For example MyTemp.state < 20 | °C.
You have to be careful when doing math with temperatures because 0 °C and 0 °F are not the same so some calculations do not work as expected.