OH 2.1 requires manual start of bindings (karaf)

Good Morning everybody,

I just upgraded my Raspi2 running an older openhabian (using ua-netinst) and the stable release from 2.0 to 2.1 stable.

I did not have kernel panic issues (potentially because this issue happens on RPi3 only???).
(https://github.com/openhab/openhabian/issues/147)

However, I have (had?) the issue, that I needed to start almost all the bindings
(including PaperUI) manually in the karaf console. All bindings I used previously are mentioned in addons.cfg and seemed to be installed.
All my things seem to be there as well.

Even after a whole night there are still some parts in “Resolved” Mode and they cannot be started manually:
169 | Resolved | 80 | 2.1.0 | openHAB Sound Support, Hosts: 111
207 | Resolved | 75 | 2.1.0 | openHAB Basic UI Fragment, Hosts: 187
210 | Resolved | 75 | 2.1.0 | openHAB Paper UI Theme Fragment, Hosts: 188

Now my questions:

  1. Why didn’t the bindings start?
  2. What happens after a reboot? Do I need to do the manual stuff again?

Thanks in advance.

I, too, had those issues (not on openHABian but Raspian Jessie).
Exactly those 3 bindings are still in Resolved state in my installation, too, but they have been so since I moved to 2.1 (snapshots) months ago, and most important: they do work, at least I don’t see any impact.
Still I, too, would like to have someone competent to explain that state. I’d suggest to open a GitHub issue.

Regarding manual installation, I encountered this once or twice .
For me, it helped to delete he ESH cache (/var/lib/openhab2/cache).
But still had some other issues after that (bindings started but suddenly ignored items) and ended doing a purge and (re)install of the OH packages.

I have the same on my PC running Debian Jessie with OH2 S#976:

openhab> list -s |grep -i resolved
169 | Resolved |  80 | 2.2.0.201706290942     | openHAB Sound Support, Hosts: 111                      | org.openhab.io.sound
211 | Resolved |  75 | 2.2.0.201706290942     | openHAB Basic UI Fragment, Hosts: 197                  | org.openhab.ui.basicui
214 | Resolved |  75 | 2.2.0.201706290942     | openHAB Paper UI Theme Fragment, Hosts: 198            | org.openhab.ui.paperui

I think this is normal (the bundles are working)

openHAB Basic UI Fragment, Hosts: 197

openhab> list -s 197
START LEVEL 100 , List Threshold: 50
 ID | State  | Lvl | Version            | Name                                       | Symbolic name
---------------------------------------------------------------------------------------------------------------------
197 | Active |  80 | 0.9.0.201706270841 | Eclipse SmartHome Basic UI, Fragments: 211 | org.eclipse.smarthome.ui.basic

openHAB Paper UI Theme Fragment, Hosts: 198

openhab> list -s 198
START LEVEL 100 , List Threshold: 50
 ID | State  | Lvl | Version            | Name                                       | Symbolic name
---------------------------------------------------------------------------------------------------------------------
198 | Active |  80 | 0.9.0.201706270841 | Eclipse SmartHome Paper UI, Fragments: 214 | org.eclipse.smarthome.ui.paper

I think that this is related to OSGi hosts and fragments

Thanks, I will give this a try.

By the way, did you have the issue after reboot as well?
Means, do I need to start the bindings manually again after reboot?
Thanks

Reboot does not make any difference, it either happens on OH start or not.

So, I need to start them manually again whenever I reboot my system?

And deleting the cache would help to avoid this in the future?

which bundles?

the 3 that you mentioned (openHAB Sound Support, openHAB Basic UI Fragment & openHAB Paper UI Theme Fragment) are fine the way they are (Resolved). I don’t think that you need to do something with these 3.

No, I mean almost ALL bindings I have had in the OH 2.0 stable version.
At least around 20 different bindings.

I saw this twice with the #96*'s builds. Once starting them manually and then rebooting solved the problem.

Alright - I will give it a try
Thanks!