New Package Options


There are again a few updates in the latest distro #611 worthwhile to mention:

First of all there were many fixes in ESH that people were waiting for:

  • Yahoo Weather displays the correct pressure now
  • Groups of color lights are correctly working again
  • Paper UI shows 24h for datetime values
  • hue binding now supports Osram on/off plugs

In openHAB 2 addons, we recently:

  • added the Exec 2.0 binding
  • added the Minecraft binding
  • had a major update of the Netatmo binding

For the distro itself the biggest change is within the handling of the selected add-ons - especially the issue that the information about installed add-ons was lost during upgrades has been addressed.

There are now a few new package types to choose from - they are now only meant as a starting point (so you cannot change it anymore through the Paper UI), but you are free to add or remove any other number of add-ons now; in the past, you e.g. could not remove a binding that was installed through the demo package - now this works.
If you wonder, WHERE this information is stored when you e.g. add new bindings through the Paper UI: It all ends up in the file userdata/etc/org.openhab.addons.cfg (which is kept in place during upgrades).

To get this in place was a huge refactoring - I hope I didn’t break too much with it. If you come across problems with this mechanism, please report back!



Is this now a full replacement for /conf/services, is it now possible to set ALL Configuration-Options for oH2 via Paper UI?

Do i then have to backup userdata/etc/org.openhab.addons.cfg instead of /conf/services/addons.cfg before copying the latest snapshot to my oH2-folder?

1 Like

Lot’s of good stuff happened here - thanks!

However, I notice one peculiarity (that I am pretty sure tagged along with this update).

If I have the following in the addons.cfg file:

binding = astro,network,mqtt,zwave 
ui = habmin,paper,basic

… the bindings and UI’s are correctly downloaded and installed (I am using the online version).

However, if I do the following:

binding = astro, network, mqtt, zwave 
ui = habmin, paper, basic

(notice a space-character after the comma)

… then all but the first entry in each line (astro and habmin, respectively) are uninstalled!

2016-11-25 17:13:27.024 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-binding-mqtt'
2016-11-25 17:13:36.051 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-binding-zwave'
2016-11-25 17:13:41.344 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-binding-network'
2016-11-25 17:13:45.722 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Stopped Paper UI
2016-11-25 17:13:45.732 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-ui-paper'
2016-11-25 17:13:49.405 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
2016-11-25 17:13:49.426 [INFO ] [core.karaf.internal.FeatureInstaller] - Uninstalled 'openhab-ui-basic'

Now, I happen to have a thing for “space-after-comma”, so this hit me hard, :wink:

Granted, the workaround is pretty simple and straightforward, but I think this could lead to some confusion for people.

1 Like

The /userdata folder and it’s content don’t get overwritten through an update, so if you do a backup, it’s good for an emergency repair if your operating system crashes during the update, but otherwise it is not necessary … but I’m doing that too, just for safety :slight_smile:

That still sounds good, i’m still waiting for “hue binding supports the new hue motion sensors” - meanwhile i’m working with the http-binding and a hue.items file and Javascript Transformation :wink:

@Kai, has the new exec binding any kind of influence on existing environments? I recently updated from #572 to #612 and have noticed that my presence detection (based on the exec binding launching a script) doesn’t work anymore. A debug log shows no information at all.

With #572, I used of course the 1.9 binding. What happened through the update? Has OH2 switched automatically to the 2.0 binding, as the 1.9 now is a “legacy binding”? In my installation, legacy bindings are deactivated.

Oddly, when I install the 2.0 binding through PaperUI in #612, I get this “installation circle” for the 1.9 binding, which is below the 2.0 binding. And Habmin doesn’t even offer the OH2 2.0 exec binding for installation, only the OH1 1.9 exec binding.

Is there anyone else having problems with the new binding?

Same here …

My PR hadn’t been merged in time, that’s why the distro contains both the exec1 and the exec2 binding with the same id, which causes issues when trying to install it. I just merged the PR myself, so the next build should be fine. If you used the exec 1.x binding so far, you will need to adapt your addons.cfg from “exec” to “exec1” as otherwise you will get the new binding now. (I wonder if it might be a good idea to change ALL OH1 add-ons to have a “1” suffix, so that we can keep the id if a version 2 appears…)

1 Like

Agreed, that is a bit unexpected - should be fixed with in the next distro build!

As long as Philips does not offer a push mechanism on the bridge, I think this is if of very limited value…

conf/services its meant for people who wish to have a static definition on which they can rely and be sure that they are not edited automatically. The userdata/etc data should rather be regarded as a (textual) database of the runtime.

See for the upgrade (and thus also backup) process.

Thank you for the informations.

So my hue.items and my sandbox iTunes.items are the last “things” i have to keep in mind with the “old” folders /addons and /conf.

Meanwhile i deleted my old addons.cfg, started from scratch with latest snapshot, installed all Bindings via PaperUI and everything works very fine :smile:

Great job from all oH2-Maintainers :thumbsup: :thumbsup: :thumbsup:

1 Like

Thanks Kai. I updated again this morning and now I get the option to use exec and exec1. Unfortunately, my installation still doesn’t work with the new exec binding. If I switch over to the old 1.9 binding (“exec1”), the presence detection immediately starts to work properly again.

I have to dig a little deeper to find the reason for that…

You should note that the new binding of course requires a different kind of configuration - see here for details.

Ahhh…I took a look at the documentation two days ago just to find exactly this document for the new binding. But either I was blind or the document wasn’t there yet.

However, I will have a look now. Thanks Kai!

When moving to a new build I am still struggling to preserve the habpanel configuration.
Basically I always have to start from the scratch.
It seems that this ui is saving its state not in conf folder but probably in the userdata.

Additionally the persistance data in the userdata, so I have have to copy this folder as well.
It would be great, if everything I want to config and preserve could be within one folder.

This should now be fixed with this latest distro - these were exactly the issues I worked on.

You can keep everything from userdata with the exception of “cache” and “tmp” folders, see here.


A little improvement would be if the conf of the distribution would only contain empty folders.
But since it contains e.g. addon.cfg I cannot just unzip the distribution zip and tell the unzip to overwrite everything.

Should I also delete runtime folder or better to overwrite existing folder ?

Instead of empty folders another option could be to deliver the config files with a special extension (like other software on Linux is doing it), e.g. addons.cfg.dist.