Sadly, I seem to be going backwards with OpenHab

Setup, Configuration and Use Installation
1

hi folks,

Just upgraded to 3.0.2 and, well, more regression it would seem.

I’ve come to accept the rules don’t work due to the rules-breaking-when-editing-item bug
I’ve come to accept that cron no longer works or just randomly stops working (not since 2.5 in docker)
Now I upgrade to 3.0.2 and mapdb stops working too :frowning:

This was working ok before the upgrade to 3.0.2 and now it’s not.

Is this seen by others too or something else unique to my install? (docker on rpi4 4GB)


08:04:12.555 [ERROR] [tence.internal.PersistenceManagerImpl] - Exception occurred while querying persistence service 'mapdb': data were not fully read, check your serializer
java.lang.AssertionError: data were not fully read, check your serializer
        at org.mapdb.Store.deserialize(Store.java:299) ~[?:?]
        at org.mapdb.StoreDirect.get2(StoreDirect.java:486) ~[?:?]
        at org.mapdb.StoreWAL.get2(StoreWAL.java:336) ~[?:?]
        at org.mapdb.StoreWAL.get(StoreWAL.java:320) ~[?:?]
        at org.mapdb.Caches$HashTable.get(Caches.java:246) ~[?:?]
        at org.mapdb.EngineWrapper.get(EngineWrapper.java:58) ~[?:?]
        at org.mapdb.BTreeMap.get(BTreeMap.java:602) ~[?:?]
        at org.mapdb.BTreeMap.get(BTreeMap.java:589) ~[?:?]
        at org.openhab.persistence.mapdb.internal.MapDbPersistenceService.query(MapDbPersistenceService.java:195) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor119.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:834) [?:?]
08:04:12.653 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method 'QueryablePersistenceService.query()' on 'org.openhab.persistence.mapdb.internal.MapDbPersistenceService@18056aa': data were not fully read, check your serializer
java.lang.AssertionError: data were not fully read, check your serializer
        at org.mapdb.Store.deserialize(Store.java:299) ~[?:?]
        at org.mapdb.StoreDirect.get2(StoreDirect.java:486) ~[?:?]
        at org.mapdb.StoreWAL.get2(StoreWAL.java:336) ~[?:?]
        at org.mapdb.StoreWAL.get(StoreWAL.java:320) ~[?:?]
        at org.mapdb.Caches$HashTable.get(Caches.java:246) ~[?:?]
        at org.mapdb.EngineWrapper.get(EngineWrapper.java:58) ~[?:?]
        at org.mapdb.BTreeMap.get(BTreeMap.java:602) ~[?:?]
        at org.mapdb.BTreeMap.get(BTreeMap.java:589) ~[?:?]
        at org.openhab.persistence.mapdb.internal.MapDbPersistenceService.query(MapDbPersistenceService.java:195) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor119.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:834) [?:?]
08:04:12.660 [ERROR] [tence.internal.PersistenceManagerImpl] - Exception occurred while querying persistence service 'mapdb': data were not fully read, check your serializer
java.lang.AssertionError: data were not fully read, check your serializer
        at org.mapdb.Store.deserialize(Store.java:299) ~[?:?]
        at org.mapdb.StoreDirect.get2(StoreDirect.java:486) ~[?:?]
        at org.mapdb.StoreWAL.get2(StoreWAL.java:336) ~[?:?]
        at org.mapdb.StoreWAL.get(StoreWAL.java:320) ~[?:?]
        at org.mapdb.Caches$HashTable.get(Caches.java:246) ~[?:?]
        at org.mapdb.EngineWrapper.get(EngineWrapper.java:58) ~[?:?]
        at org.mapdb.BTreeMap.get(BTreeMap.java:602) ~[?:?]
        at org.mapdb.BTreeMap.get(BTreeMap.java:589) ~[?:?]
        at org.openhab.persistence.mapdb.internal.MapDbPersistenceService.query(MapDbPersistenceService.java:195) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor119.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:834) [?:?]
2

If you want help, don’t throw everything into the same bag and be comprehensive and precise in what
you post. Name the pre-upgrade version, show logs, describe how you migrated, how you access files and what you have done so far.
Least thing we expect is you reference the posts and issues you have opened.

How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community

Cron is not known to stop working. I’d guess this is a symptom not a cause. If you have a rule triggered from cron but the rule has a bug and fails to execute, cron is not the reason.
Rules dealing with time written for OH2 often need to be reworked for OH3 due to Joda time changes
as you should be aware of if you have read the OH3 release notes.

There’s also not “the” known edit bug.

Debug your issues (enable karaf debug to see if rules start execution, add debug lines into your rules to see where they stop).

On your mapdb issue, delete all mapdb persistence files.

And finally yes since you deliberately chose to run in docker on a rpi that can cause issues for you that others do not have because they didn’t choose to install that weird combo.
So now your problem is that most users cannot follow or reproduce your issues because of your choice.
Granted, that’s just my $0.02 as the openHABian maintainer but still a valid point, but just for example openHABian deletes mapdb files on upgrade so running it would have avoided you run into this issue.

3

Info for other readers, “edit Items file stops file rule triggers working” is recorded here.

It can be managed by “not editing Items” which sounds stupid but you might have your Items split into different files to limit the damage. Editing Items is not an everyday activity.
Recovery can be made by making a pretend edit of affected rules files to force a rules reload.

4

I have not upgraded to OH, yet.
But here are my thoughts:

And finally yes since you deliberately chose to run in docker on a rpi that can cause issues for you that others do not have because they didn’t choose to install that weird combo.

I do not understand that.
Actually I was recommending a friend of mine to switch to the Raspi+Docker combination.
The whole purpose of Docker is to have a defined working environment regardless of the host the container is running on.
Why should it not work on a Raspi?

Editing Items is not an everyday activity.

It is when you just stared using OH3 and are migrating all your Items to OH3.
At least that would be my workflow.

Recovery can be made by making a pretend edit of affected rules files to force a rules reload.

But this sound like a reasonable work around until the issue is solved. :slight_smile:

I hope this issues will be solved by the time I am starting to migrate to OH3. :wink:

5

FWIW, I think that item-edit-breaks-rules is a spiteful little bug. It’s not clear who is affected, but it’s probably limited to the dwindling number of people using xxx.items files in OH3.
Many of those affected are probably unaware of the issue, and just get frustrated with stuff not working seemingly “at random” and “fixing itself” when they start poking around.

6

Not saying it won’t work.
What I’m saying is it is unnecessarily adding overly complexity on an already pretty much resource constrained platform (and IMHO adds no value, but on that YMMV).
Either way that’s two additional (potential) reasons for issues with OH.
Also saying that you’re mostly on your own when it comes to debug the stuff as only very few use this combo and those who don’t will not know what it does to your system so they don’t know if it behaves the same as theirs w.r.t. to the issue.