In OH2, formatting could occur at the Sitemap level - so it didn’t actually affect the value of the item’s state.
But in OH3 this now seems to be at the Item state level. I’ve used the State Description metadata to set formatting for a power value as “%d W”, so that (for example) a value of 4 is displayed as “4 W”. The item is tagged in the Semantic Model as Type of “Number:Power” and Class an Property as “Measurement” and “Energy” respectively.
But this seems to affect the item state in rules. So, for example, "Washer_Energy.state " now seems to have a string value of “4 W” rather than a numeric value of 4.
This means that any arithmetic comparison operators are now working on alphanumeric precedence of the full string, rather than the numeric value - which makes a nonsense of my Rule logic.
Picking the numeric value out of the string will mean I have to have Rules code that’s dependent on the exact State Description formatting, which seems dumb as I’d have to keep to different things in step.
Have I fundamentally misunderstood something here?
For the moment, I’ve just removed the State Description formatting. But ideally I’d like to show this as “4 W” rather than just “4”.
This is the important part.
The Item is of a Quantity type, and has units.
Even if you don’t give a [state description],it will assume system default units for that type.
Do comparisons with other quantities. yourItem.state > 1|kW
And just to make it clear, the State Description does indeed only affect how the Item is displayed. It does not change the Item’s actual state, just as it worked in OH 2. When using QuantityTypes in rules, you must supply the units for your numeric values like rossko57 demonstrates.
The item is bound to a generic MQTT thing. As I understand it, the MQTT binding doesn’t (yet) implement Quantity Types.
If include State Description metadata to format the item as “%d W”, then a logInfo debug line in my rules clearly shows that “Washer_Energy.state” is a string value of “4 W”, not a numeric 4.
What’s the correct configuration here? Should I not have it as Type of “Number:Power”?
OK, I have a solution but I still think the behaviour is a little odd.
Having it as type of “Number:Power” with no State Description formatting just displayed as a plain number, ie “4” rather than “4 W” as the docs suggest it should. But the rules logic worked, even without a comparison like: yourItem.state > 1|kW
Adding a State Description of “%d W” displayed it as “4 W” but broke the rules logic. The state value as displayed by a logInfo line was “4 W”. This is directly opposite to what @rlkoshak said in post 3.
Changing it to type “Number” with no State Description worked fine, but just displayed as “4” as expected.
Adding a State Description of “%d W” displayed it as “4 W” but the rules worked fine and logInfo shows the state value as “4”. So that’s what I’ve gone with.
The MQTT number type channel includes a units option.
This allows you to correctly link the plain number channel to a Number:Quantity type of Item, assuming that you know the units your remote device is guaranteed to report in.
Example, MQTT payload "1234" and channel units="mW" linked to Number:Power type Item.
The Item’s default unit comes into play; some subtypes have system defaults, not sure about power.
But if your Item has a state description like "%d W" I’d expect the Item to actually get updated to "1.234 W" i.e.the incoming number is made into a quantity using the channel units, but then converted to the Items default units.
You should be able to see what happened to you with a Number:Power type Item linked to a channel with no given units.
