Did "number" items change from integer to decimal in 2.4?

Setup, Configuration and Use Beginners
1

I recently upgraded from OH 2.3 -> 2.4. I ran into some small issues and solved most.

One thing I noticed is that I started getting lines like the following in my log:

 2019-05-09 07:19:49.856 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '3.0' with the file 'dehumid.map' : Target value not found in map for '3.0'

I have a state machine that monitors my dehumidifier’s current and transofrms that into a state.

It is declared in my .items file like this:

Number  dehumidState                            "Dehumidifier [MAP(dehumid.map):%s]"                            <humidity>

dehumid.State then is set to a number 0-3 dependant on the current level in a rule

Then I transform that number into a human readable state in the following map file:

0=Off
1=On/Idle
2=On/Running
3=Auto/Off
NULL=Unknown
null=Unknown
-=Unknown

It looks like a number item now contains 1 decimal where in OH 2.3 it was 0 decimals? I fixed this by modifying my .map file to add a “.0” to each state. Just curious should I instead be using a different item type than number?

2

I do not understand the inner workings of Number Items, but yes the string version of a state that is mathematically 3 can come out as 3 or 3.0 in different circumstances. (MAP uses strings for conversion)

As an example of weirdness, an Item state 3 will get restored-on-startup to 3.0

I do not know any ‘fix’, only making sure you get you what you want e.g. use of intValue in rules.

In your case, you might be able to use a SCALE transform instead, which does the comparison on a numeric basis.

3

Must your Item even store the state as an Integer? What if the state were the human readable String to begin with?

4

Good point Rich. I’ll take a look at that.