Karaf Addon binding naming conventions

I’m the maintainer of the Viessmann and Glowmarkt API bindings, which are built out-of-tree. These bindings are distributed as .kar archives. Recently I updated them to work with OH 4. I found that users weren’t able to add any things for the binding, due to code in the CommunityMarketplaceAddonService which assumes a specific naming pattern convention, namely that the addon file is named something like


where bindingid has to be the same as the binding id reported in the binding.xml - and this is used as the filter on the add things page, thus preventing my users from using the binding.

So, I dutifully renamed my binding file as that seemed the path of least resistance.

Then, I find that something else has changed, not sure what exactly, but previously before OH4 I was able to test my binding in development by just dumping it into the addons/ folder, and it would just work. Now, it seems that for whatever reason, KarafAddonService decides to uninstall my binding at startup because it is not in addons.config

Also, fine, annoying but I can update the properties in karaf. But there also seems to be code in there that does things with filenames and addon ids, which I don’t pretend to understand. However it does seem to require that the feature name is openhab-binding-foo, and make assumptions about the author of the binding being OpenHAB.

I now note that when my binding is installed from the marketplace, it appears in both “OpenHAB Distribution” as a binding with a blue OpenHAB tick (albeit with broken links), and also as an installed binding in “Community Marketplace” where I expect. I could be wrong, but I’m pretty sure that didn’t happen previously.

Q: Is/are these bugs in OpenHAB, or am I doing something wrong? Do other marketplace binding maintainers have these problems? I had a quick look, but it seems most people are distributing as jars and/or SNAPSHOT builds which might avoid these pitfalls. How are people installing their bindings for development?

Try removing openhab- from your Karaf feature names. IIRC that is used to determine if they are part of OH itself. I ran into similar issues with my LOG4J2 Extra add-on.

I see you use:

Can I ask, how do you install your binding locally when testing it? I install mine in the addon folder and find that if it is not named as such then FeatureInstaller removes it.

Mh, for my eBus binding I’ve changed it to “openhab-” feature name for OH4. It was not loading anymore.
In OH3 it was automatically removed if I use “openhab-” as feature name.

1 Like