@chris Are you saying that with the latest builds that after deleting mapdb the bindings are still only starting properly sometimes but beforehand were not starting at all, or that after deleting they are now starting consistently?
I have been running a build from 6/30 and it’s definitely been taking me several startups to get the bindings initialized but I haven’t been updating because it sounded like things may have gotten less reliable in the meantime.
From todays build, if I remove the userdata/mapdb folder, it is working ok again for me. It seems to be reliable - although I’ve only started 4 or 5 times, but it has been fine every time for me.
If your system started ok occasionally, then maybe you’ll be lucky and won’t need to delete the mapdb folder.
I did a complete reinstall of my test system, then copied in my items, rules, sitemaps, etc. At this point, I’m not convinced the problem is gone. I continue to see initialization issues.
Ok, similar experience unfortunately. Followed my normal update procedure and frankly I dont see any difference with respect to bindings restarting after the update.
I did not in the end get much time to do more today so have not tested a clean install, i.e. Deleting mapdb and then having to reinstall all my things.
To be honest I am struggling to understand what is being stored in the mapdb database that might cause this problem. Can anyone give more info on this?
I will try a clean install tomorrow evening.
I have just installed the “offline” snapshot #402 following my normal update procedure and I am still running with my old mapDB instance.
Note: I was going to do a clean install if the above failed.
After the installation I had to restart once to get everything running. However after that I have now done 6 consecutive restarts without the issue we have been seeing re: bindings not restarting.
Not sure what has changed, but definitely nothing at my end.
Please let me know if there is anything I can provide to help work out what was going on.
UPDATE: I spoke too soon - we still have a problem…
I have just done around 14 more restarts and the success rate for bindings starting looks like 1 in every 2-4 restarts. I have not changed anything from the earlier tests.
This is weird!! Is there some sort of timing issue where openHAB sometimes takes longer to restart and is not ready for the starting of the bindings??
So will you do tests with a clean install now?
I honestly also have no idea what could be inside the database that causes the problems - after all, it should only hold similar infos as you would otherwise have in the *.things files. But as it made a difference for Chris, we should really do the testing on a clean installation to rule out any side effects.
OK, I will do that tomorrow as it getting a bit late here now.
To summarize the three different test cases I’ve done:
And what are the results of these tests? All three behave the same way?
What of the exceptions/issues listed above in this topic is still relevant?
Is https://github.com/eclipse/smarthome/issues/1847 the only issue that you come across or is there more (exceptions in the log, etc)?
Yes, sorry, the behavior is identical in all three test cases. On average, I would say unsuccessful startups occur about 30-40% of the time.
I have three separate systems all running Ubuntu 16.04. Two of the systems are “production” (i.e. they run the automation in my homes), and the other is a system I use for testing. The production systems are typically a few builds behind the test system. The startup issue occurs on all three systems.
In addition to the startup issue, I’ve seen the following issues occur on all my systems.
This is the one you just logged today.
This one occurs periodically on multiple bindings.
https://github.com/openhab/openhab2-addons/issues/819
Hi @Kai
I did a fresh install after removing the mapDB folder and using build #404 today. For a while it looked like it was more reliable with respect to the binding starting but after multiple restarts I am now seeing some of the same issues. This is similar to my experience yesterday so not sure what changes after multiple logout/restarts.
One thing I did notice is that if you don’t allow a reasonable delay, say at least 30 seconds, after the Karaf console closes that it is more likely to have a problem restarting the bindings.
I will continue to test tonight to see if I can reach any conclusions, but I do not think the problem is with the mapDB database. That said, it gave me to opportunity to clean up a few redundant links from my earlier testing.
Let me know if you want any log files etc…
Update: after restarting every 15 to 30 minutes since my earlier post - on most occasions everything started OK.
However, on my last test I have just had to restart 4 times before I could get the bindings to start.
Haha, I have stopped, but I was hoping I might see a log message that might give a clue to the problem.
Cheers,
Mike
Ok, let me tell you the most important thing to do when debugging problems in ESH: Type this in the console:
log:set DEBUG org.eclipse.smarthome
The logs will be so much more helpful afterwards 
Ok, I will save that for next time 
Ok, build 407 should finally fix this issue - please test and report back!
Build 407 looks really good on my test system. Twelve restarts in a row and not a single startup issue. Startup also seems quicker, which I think you said might be the case.
I’ll install on my two other systems tomorrow morning.
Nice work!!!
I confirm that build #408 is working well and no issues with starting the bindings.
Thank you very much for your efforts and support!!
Cheers,
Mike
Since updating to build #408 there are a couple of minor issues:
The obvious value that is missing is the Moon Phase which normally was only updated after the first 60 second period.
If I uninstall and then reinstall the binding from the Paper UI, I get refreshed values, but no further updates.
Restarting OH2 also gives refreshed values, but then no further updates.
if I then uninstall and then reinstall the binding from the Paper UI, I get a value and this updates every 60 seconds (unlike the Astro values)
Both of the above behaviours are new today following the update to build #408.
Mike
p.s. the debug log from startup can be seen at the following link:
