OH3 Deserialisation error with mapdb on startup

Tags: #<Tag:0x00007efeddc78d90> #<Tag:0x00007efeddc78cc8>

Hi everyone,

in OH3 i created a standard mapdb persistence. Just every item is persited with mapdn und values are restored at startup.

The persistence file loke like this:

Strategies {
    everyMinute : "0 * * * * ?"
    everyHour   : "0 0 * * * ?"
    everyDay    : "0 0 0 * * ?"
    default = everyUpdate
}

Items {
    * : strategy = everyChange, restoreOnStartup
}

When staring OH3 i get the following error with differnet types: DecimalType, DatetimeType, OnOffTyp

2020-10-03 18:00:54.178 [WARN ] [ence.mapdb.internal.StateTypeAdapter] - Couldn't deserialize state 'org.openhab.core.library.types.DecimalType@@@100': org.openhab.core.library.types.DecimalType cannot be found by org.openhab.persistence.mapdb_3.0.0.202010010808

Has anyone else these errors? Oh by the way, i am in build #1951

1 Like

Hey @Dibbler42 !

Just wanted to tune in and say that you are not alone. Mapdb seems to be broken. I just set up a brand new OH 3.0M1 installation (no imports, did everything manually) and my logs are littered with the deserialization errors you mentioned. The states of the items are not restored on startup as well.

My persistence file looked like this:

Strategies {
    default = everyUpdate
}

Items {
    * : strategy = everyUpdate, restoreOnStartup
}

Like you I got these in openhab.log:

2020-10-30 08:38:40.009 [WARN ] [ence.mapdb.internal.StateTypeAdapter] - Couldn't deserialize state 'org.openhab.core.library.types.OnOffType@@@OFF': org.openhab.core.library.types.OnOffType cannot be found by org.openhab.persistence.mapdb_3.0.0.M1
2020-10-30 08:38:40.014 [WARN ] [pdb.internal.MapDbPersistenceService] - Deserialized invalid item: [FAILED toString()]
2020-10-30 08:38:40.017 [WARN ] [ence.mapdb.internal.StateTypeAdapter] - Couldn't deserialize state 'org.openhab.core.library.types.StringType@@@HEAT': org.openhab.core.library.types.StringType cannot be found by org.openhab.persistence.mapdb_3.0.0.M1
2020-10-30 08:38:40.020 [WARN ] [pdb.internal.MapDbPersistenceService] - Deserialized invalid item: [FAILED toString()]
2020-10-30 08:38:40.028 [WARN ] [ence.mapdb.internal.StateTypeAdapter] - Couldn't deserialize state 'org.openhab.core.library.types.QuantityType@@@21 °C': org.openhab.core.library.types.QuantityType cannot be found by org.openhab.persistence.mapdb_3.0.0.M1
2020-10-30 08:38:40.029 [WARN ] [pdb.internal.MapDbPersistenceService] - Deserialized invalid item: [FAILED toString()]
2020-10-30 08:38:40.033 [WARN ] [ence.mapdb.internal.StateTypeAdapter] - Couldn't deserialize state 'org.openhab.core.library.types.OpenClosedType@@@CLOSED': org.openhab.core.library.types.OpenClosedType cannot be found by org.openhab.persistence.mapdb_3.0.0.M1
2020-10-30 08:38:40.036 [WARN ] [pdb.internal.MapDbPersistenceService] - Deserialized invalid item: [FAILED toString()]
2020-10-30 08:38:40.042 [WARN ] [ence.mapdb.internal.StateTypeAdapter] - Couldn't deserialize state 'org.openhab.core.library.types.OpenClosedType@@@CLOSED': org.openhab.core.library.types.OpenClosedType cannot be found by org.openhab.persistence.mapdb_3.0.0.M1
2020-10-30 08:38:40.045 [WARN ] [pdb.internal.MapDbPersistenceService] - Deserialized invalid item: [FAILED toString()]

etc. etc.

I also got tons of these NPEs on the console:

SLF4J: Failed toString() invocation on an object of type [org.openhab.persistence.mapdb.internal.MapDbItem]
Reported exception:
java.lang.NullPointerException
	at org.openhab.persistence.mapdb.internal.MapDbItem.toString(MapDbItem.java:69)
	at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:299)
	at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:271)
	at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:233)
	at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:173)
	at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124)
	at org.ops4j.pax.logging.slf4j.Slf4jLogger.warn(Slf4jLogger.java:752)

I then set RRD4J as my default persistence in the UI and uninstalled mapdb. I then restarted openHAB and there were no more of these logs. The item states got restored.

I had one problem with a Number item, though. It had the value 4 and got restored as 4.0 (which caused a transformation .map lookup to fail immediately after the restart because there only was a mapping for 4 (not 4.0). This corrected itself, presumably because the rule got triggered that updates this. Never had this problem before and will monitor it.

2020-10-30 09:09:34.275 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '4.0' with the file 'daylightLevel.map' : Target value not found in map for '4.0'

EDIT: openHAB 3.0M1 @ MacOS Catalina

Jens

I use the nightlies and with the latest the mapDB error is gone, so i assume that in M2 it will work. The transformation waring occurs on my system as well.

Currently i have no time to open an issue in github.

Thomas

2 Likes

Hey, thanks! Maybe this will help others who (like me) are not yet brave enough to switch to the nightlies. :wink:

Be aware even the Milestone are openhab 3 in a very early stage but there are more stable that the nightlies. and the nightlies are definetly not for production unless you can accept serious problems now an then.

To be honest i had very seldom serious problem with the nightlies, but they are happening.

:+1:

Friendly reminder: Would you flag your reply to my initial reply as the solution? Thanks!! :slight_smile:

1 Like

My openHAB 2.5.x installation was beginning to show signs of wear. I have had to rename a couple of item groups in the past because the aggregation function was broken (which somehow got persisted). Also - and more severe - many items suddenly started to no longer handle value changes / updates correctly. My whole installation started to break down because of this. Heating modes no longer got changed, etc. It started when I updated to 2.5.9. But I am not sure this was the trigger.

Anyway - I had to do something. I did not want to set up a new installation using the backup process because I felt that that would potentially carry over the problems I had. Since I did not want to go through all the trouble of setting up a new 2.x installation with OH 3 on the horizon I went for the switch to OH 3 Milestones, well aware of the risks.

So far it is going quite well!

1 Like