After upgrading to 2.4, persistence values (rrd4j) are init to floating point

Setup, Configuration and Use Items & Sitemaps
1

Upgrading from 2.3 to 2.4, I noticed upon restart, my persistence values restored from rrd4j are initialized to floating point rather than integer.

For example I have this item.

Number Light_tmr_minutes “Auto-Off [%d]”

And it is persisted with this configuraiton:

Light_tmr_minutes : strategy = everyChange, restoreOnStartup

And set this way in the UI:

Selection item=Light_tmr_minutes icon=time mappings=[0=“Off”,5=“5min”,15=“15min”,60=“1hr”]

Prior to 2.3, if I set this timer to 15 in using the sitemap UI, the value would be exactly 15 upon startup. In 2.4 if I print out the value it is 15.0. For example upon startup:

2019-01-01 16:17:07.234 [INFO ] [clipse.smarthome.model.script.Lights] - Outdoor lights changed. Timer is 15.0

Now if I again set it in the UI, it will go back to the integer 15.

2019-01-01 16:18:48.090 [INFO ] [clipse.smarthome.model.script.Lights] - Outdoor lights changed. Timer is 15

But If I restart openhab it is back toa floating point.

This is causing all sort of issues in my rules files. The problem seems to exist for all values restored from rrd4j that I have defined internal state items for. Looking through the release notes under breaking changes I couldn’t find anything about this, or scanning around the forums. Is there a workaround? Thanks.

1 Like
2

A number item is a Number (A Float with more functions) not an int
The fact that it is showing on the log as 15 or 15.0 make no difference
What rules are causing the problem?

3

It has always been good practice to force a Number value to integer, where ints are needed
... now.plusMinutes((myItem.state as Number).intValue) ...

4

Well there are two problems.
First problem, with the timer that I mentioned, is that the basicUI itself will not show the set value. So for the example above, [0=“Off”,5=“5min”,15=“15min”,60=“1hr”], that corresponds to an int. Now when openhab 2.4 restarts, the value is not longer an int, as far as that selection is concerned. So the UI shows no value selected at all when it is restored as 15.0 instead of 15.

The second situation is when I use state to control other things, and was looking for an int. e.g.

                            switch (LockAndArm.state)
                            {
                                case 1 :  // 2 = arm away, 1= arm stay
                                {
                                    logInfo("org.openhab","Door Locked: , arming stay")
                                    AlarmCommand.sendCommand("1")
                                }
                                case 2 :
                                {
                                    logInfo("org.openhab","Door Locked: , arming away")
                                    AlarmCommand.sendCommand("2")
                                }

Upon restore, LockAndArm.state is 1.0 or 2.0. I see, from rossko57’s comment above that I can cast or force it. That still doesn’t solve the problem where the UI was using the value to show a menu item, unless I am supposed to have a light timer menu with values 0.0,5.0,15.0,and 60.0, which seems a little user-unfriendly.

Regardless of the best practice, it seems this behavior was changed in 2.4.

5

It’s certainly changed. Affecting switch/case and sitemaps is a really nasty effect.

As I understand it, OH Number Items are all DecimalType internally, so how it manages to remember whether it was set by integer or decimal baffles me.

Given the use cases, it is reasonable to expect the “same thing” to be restored from persistence services. I’d guess it’s a knock on effect of Units of Measurement changes?

6

I experienced the same thing… changed my rules to cast .intValue where needed solved the problem.

1 Like
7

I did the following startup rule to correct them, but it fires three times :slight_smile: First time I get errors saying the variables don’t exist, and the next two times it executes. I think this is when the .items and .rules containing the content is loaded or reloaded – I see some discussion about this elsewhere… If anyone knows of a cleaner way let me know :slight_smile: Thanks for your help.

rule “Fix startup vaules to ints”
when
System started
then
logInfo(“org.openhab”,“Correcting floating point persistence variables”)

 logInfo("org.openhab","Lock State before: "+LockAndArm.state)     
 logInfo("org.openhab","Light timer before: "+Light_tmr_minutes.state)

 LockAndArm.postUpdate((LockAndArm.state as DecimalType).intValue)
 Light_tmr_minutes.postUpdate((Light_tmr_minutes.state as DecimalType).intValue)

 logInfo("org.openhab","Lock State after: "+LockAndArm.state)     
 logInfo("org.openhab","Light timer after: "+Light_tmr_minutes.state)

end

8

I tested this with mapdb, and 1 gets recovered as 1. That’ll be why I hadn’t noticed it with restore on startup myself.
@billfor using mapdb for restore on startup wold be a neater solution. You can still use rrd4j as well for historic/graphing data for same Items.

With rrd4j, 1 gets recovered as 1.0. Can anyone confirm this is really a recent change? I’ve seen things suggesting rrd4j always works in decimals.

1 Like
9

Thanks @rossko57. I moved all my rrd4j state/mode vars into mapdb and that works fine.

10

Please tick the solution post, thanks

11

I would call it workaround more than solution … we haven’t resolved if rrd4j behaviour has changed with release 2.4

12

Approved. It’s only fixing the result instead of the issue itself.

13

Just for information. If an item file was changed values are shown also as float numbers instead of integer. In this case rule “System started” wont affect.