I basically decided that using units of measure might be a good idea but not for me. For the last 2 days something that should be as easy as evaluating in a rule if the temperature outside is higher than a set threshold became a saga of frustration and trial by errors.
The problem root cause was that the temperature item was defined as a Number:Temperature type and I could not find an easy way to strip the UM from the item state in order to evaluate it against a plain numeric value.
So in the end I thought that I really don’t need this aggravation eating my free time and do what I used to do prior to 2.3, meaning getting and storing the temp sensor results as simple numeric values, which makes everything much simpler in rules and using the sitemap to format the temperature symbol. It works perfectly well that way, but that’s probably because I’m an idiot.
Can someone explain to me why do I really need UM in the items definition and if I really need it, how can I strip the extra text from the item state so that something as simple as deciding if 25 is really higher than 20 will not become a chore?
It’s a netatmo weather station. When UM are active the result might come as 30.12345678 ? (? being the symbol for Celsius). This is stored as a text and good luck trying to revert it back into a numeric value.
Yo are right, I don’t need it if it turns simple tasks such as deciding if 25C is higher than 20C into a chore. Other who might need to decide if 25C is higher than 68F might find it interesting but I’m not one of them and I seriously doubt this kind of calculation is performed more often than mine.
I just implemented UoM in my binding and like it a lot (Home Connect addon: Looking for beta testers). The binding is fetching values from a cloud service - The problem is that this API is able to return °C or °F values. With UoM I can easily process the values, regardless of the passed unit.
Another point I like is the unit conversion. The following example is converting seconds to minutes: Text item=GeschirrspLer_RemainingProgramTime label="Restliche Programmlaufzeit [%d min]" icon="time".
Heres a example of evaluating UoM states in rules:
var power = Waschmaschine_Leistung.state
if (power < 0.2|"W") Washingmachine_OpState.postUpdate(MODE_OFF)
else if (power > 9|"W") Washingmachine_OpState.postUpdate(MODE_ACTIVE)
else if (power < 4.4|"W") {
I think I tried that too and it also didn’t work. The thing is that I’m using and playing all the time with OH because it’s my hobby and hobbies are supposed to be fun and educative.
Struggling with UM was neither of them, so while I appreciate the argument of Udo, that UM have some value for converting units, it’s a value that is completely irrelevant in rules where it just add a layer of complexity.
If you don’t like units. AFAIK UoM is backwards compatible.
So when you define your items you could also try using Number instead of Number:Temperature
But in case you didn’t notice this backward compatibility isn’t obvious. When 2.3 was released the UM were presented in such a way that I believed it was mandatory to define an item with temperature as Number:Temperature.
Just came accross this yesterday. Using *state as Number used to be enough even with UoM
But since a recent snapshot, the *.state as QuantityType<Number>).doubleValue as become mandatory.
Any change to revert back to what it was. Much easier for everyone, especially newbies.
Hi!
I’m stuck with the UoM’s. I have a rule that reacts when a thermostat is changed from a certain temperature.
Since the UoM’s is no longer “4.5” but “4.5 ° C”.
Here is my (old) rule:
My solution was to strip and delete all the UoM from the items definition which brought back the simple report of numerical values only. I found UoM to be a pain in the butt to deal with and completely unnecessary for my purposes.
This can be a workaround but not what I want. I’m sure the developers have thought of something and also a solution for it. Unfortunately, the documentation is not (yet) the best. Generally I would like to use the UoM’s.
