[rrd4j] QuantityType unit is lost when restoring values on startup

[robnielsen]

When restarting see events like this in events.log:

2020-10-14 17:01:21.804 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'iMeter1Kwh' changed from 26.1861 to 26.1861 kWh
2020-10-14 17:01:21.810 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'iMeter1Watts' changed from 0.0 to 0 W
2020-10-14 17:02:15.159 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'iMeter2Kwh' changed from 0.0 to 0.0000 kWh
2020-10-14 17:02:15.188 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'iMeter2Watts' changed from 0.0 to 0 W

Later on, it's logged correctly:

2020-10-15 03:22:15.208 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'iMeter2Watts' changed from 1 W to 0 W
2020-10-15 03:27:15.141 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'iMeter2Watts' changed from 0 W to 1 W

[robnielsen]

I uninstalled rrd4j and the errors went away.

[wborn]

It's related to #8806.

Because of these issues with restoring values on startup I personally use mapdb which has no issues restoring any state. IIRC rrd4j also cannot store strings for instance.

[kaikreuzer]

Right, rrd4j can only handle numbers - it thus also sends raw numbers upon restoreOnStartup.
What we could possibly do is to use the default unit defined for the item. That might not be correct in all cases, but a best guess that's likely right.
Alternatively, we could convert the value to the default unit when storing it - but this might give problems when rendering charts from it...

[wborn]

Did you ever look into creating a more generic solution to the problem that there are many persistence add-ons which may not always be able to store the unit and precision in the backing database?

I.e. it could be derived from the Item in org.openhab.core.persistence.internal.PersistenceManagerImpl.initialize(Item). I haven't looked into if the add-ons always store the state using the same unit as the item or with the unit produced by the ThingHandler. It could also add these derived values to some fields in the FilterCriteria which can be used as fallback. Or we could implement some service that persistence add-ons can use to obtain such details for an item if they cannot store be stored.

Another way could be to provide some helper classes in Core that a persistence add-on could use to store the last known unit/precision information in a file when it's not possible to store this in the database itself.

[kaikreuzer]

Having had another look at the code, I'd think that we could actually use NumberItem.getUnit() for determining the unit when persisting values and when reading them again. Unless the user changes the unit in the state description, that should be a stable solution and changing it would be similar to changing the item type and then everything is screwed up in any case.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/new-version-of-dynamodb-persistence-testing-needed/116854/1