Since there’s is no such thing as a %% unit, I don’t see how that can change how it appears in the UI that way. So that’s weird.
These are after OH processes them.
One thing you can do is link this channel to just a Number Item and see what the Channel is delivering. I’m willing to bet it’s sending a number between 0 and 1 and you need to apply an Offset Profile to multiply that by 100 and tack on the unit before it gets to OH.
Without the unit, which modbus doesn’t add on it’s own, OH is just going to spend the unit to what ever number it’s sent.
I misunderstood. I thought the Item’s state showed %%. I That would be weird. But I would expect the unit field to show exactly what it’s set to.
That’s not how units work. If an Item with a unit (e.g. %) is updated with a number without a unit (e.g. 0.5) the defined unit is assumed (i.e. 0.5 %). It only does anything to the number if both the update and the Item have units, in which case the update is converted to the units of the Item.
If you want to convert 0.5 to 50%, you have to apply the offset profile and either multiply by 100 and set the unit to %, or leave the number unmodified and set the unit to ONE.
Hmm, somehow I am still failing at this. The offset profile does not yet seem to support multiplication (at least according to the docs). I instead tried a JS toItemScript but that also does not yield the desired result:
(function(i) {
console.log("value: "+ i );
return i*100;
})(input)
I guess I somehow need to do something more fancy than just multiplying the value by 100?
Profiles #modbus:gainOffset
This profile is meant for simple scaling and offsetting of values received from the Modbus slave. The profile works also in the reverse direction, when commanding items.
In addition, the profile allows attaching units to the raw numbers, as well as converting the quantity-aware numbers to bare numbers on write.
Profile has two parameters, gain (bare number or number with unit) and pre-gain-offset (bare number), both of which must be provided.
When reading from Modbus, the result will be updateTowardsItem = (raw_value_from_modbus + preOffset) * gain. When applying command, the calculation goes in reverse.
See examples for concrete use case with value scaling.
If you set the pre offset to 0 and the gain to 100 you should get your answer.
what result does it give? As written, since i is a String, I’d expect an error.
All transforms, including JS, receive Strings and produce Strings. If it’s not a String before it gets to the transform, it’s converted to one. It’s it’s not a String returned by the transform, it’s converted to one.
Later on the Item will pase it into what ever type the Item requires.
