Upgrading and bindings in addons folder

On any upgrade, the tmp and cache folders need to be cleaned. Then the runtime won’t have any info about the old versions anymore and the ones from the addons folder will be used.

Do you also the docker image or did you experience this with another installer?

Yes I did, I updated the opening post to reflect this, I followed the openHAB docker manual for this:

http://docs.openhab.org/installation/docker.html#updating-the-image

Ok, then this exception does not make any sense to me :frowning:
Could you try the following please: Change userdata/etc/org.apache.felix.fileinstall-deploy.cfg to have

felix.fileinstall.start.level   = 100
felix.fileinstall.active.level  = 100

(instead of 80).
Do the upgrade process again and see if it makes any difference.

I install using apt-get but this also happened when I reset the cache and tmp folders.

This time (with the changes suggested by @Kai ) it did not fail, I’ll try reverting the change tomorrow and trying again.

When reverting the change (back to 80) it stills works…

Reverting and upgrading again or just reverting with leaving the rest untouched?

Reverting and upgrading again

Then it is now up to you to figure out what is the difference to before :sunglasses:

I’ll keep upgrading daily

I think it’s a combination of bad luck and that order, I have the problem again. I’ll change to 100 and try again.

edit: And with 100 it works

If I have more time anywhere this weekend I will try to repeat it like 5+ times, but I also have some visitors over this weekend so it might be hard to find the time…

I did that this morning and my bundle:list still looks like this:

  9 | Installed | 100 | 2.1.0.201706182030     | ZWave Binding
 10 | Installed | 100 | 2.0.0.201612122156     | Animated Climacons Iconset
 11 | Active    |  80 | 5.3.1.201602281253     | OSGi JAX-RS Connector
 12 | Active    |  80 | 2.3.1                  | Gson
 13 | Active    |  80 | 18.0.0                 | Guava: Google Core Libraries for Java

and doing a stop/start on bundle 9 (zwave) gives me this:

Error executing command: Error executing command on bundles:
        Error starting bundle 9: Could not resolve module: org.openhab.binding.zwave [9]
  Unresolved requirement: Import-Package: com.google.common.collect

I fixed it like this:

  • Deleted the .jar files
  • bundle:uninstall 9
  • bundle:uninstall 10
  • stopped the openhab2 service
  • dropped the .jars back in
  • started the openhab2 service
  • re-added the serial transport bundle because I always forget that
  • all seems to work now

221 | Active   |  80 | 1.5.8.v20160511-1038   | swagger-jersey2-jaxrs (wrap)
222 | Active   | 100 | 2.1.0.201706182030     | ZWave Binding
223 | Active   | 100 | 2.0.0.201612122156     | Animated Climacons Iconset

Ok, so my idea does not seem to help. Sorry, I am out of ideas on how this happens - would need to invest more time to investigate…

Off-topic: What is this iconset that you are using there?

Should be the animated icons from this thread:

1 Like

Thats it!

I also have some bindings depending on the serial transport bundle, but I also have some other bindings installed via the normal path which require the serial transport bundle, so that is why it worked for me to change this :thumbsup:

So it crashed/failed while installing from the addons folder because there was an error and in my case it was automatically resolved if we did it at the end because then the serial-transport was was present.

That is it, though it doesn’t seem to work anymore since I upgraded. No errors aside from the 404 that is returned by the icon path now.
edit: bah… the super important breaking change from i18nProvider to TranslationProvider strikes again.

Maybe, my errors persisted after installing the serial bundle until I removed and reinstalled the zwave .jar. Then the “Unresolved requirement: Import-Package: com.google.common.collect” error stopped.

What do you mean? Is there already an issue for this?

Here is the pull request that references the change, ESH renamed the i18nProvider and it breaks bindings that references it by the old name

A I knew of the discussion but was not aware that the changes already happened. So the problem is that older versions of esh are not compatible with newer bindings and vica versa indeeed not user friendly. I do definitely support this decision. But I agree that we should limit such changes to the minimum