Add-on categories

[J-N-K]

I just came across a question that I could not answer myself. According to the documentation we have the following add-on types: automation, binding, misc, persistence, transform, ui and voice. In openhab-addons we use the following bundle-prefixes: org.openhab.automation, org.openhab.binding, org.openhab.io, org.openhab.persistence, org.openhab.transform, org.openhab.voice (and org.openhab.ui in openhab-webui). Except misc there is a match in a repository, but in the repository we have io.

I am currently developing a new add-on which is a CurrencyProvider, which is not a binding (no things) and would fit in the misc category. But org.openhab.io feels wrong, because it contains add-ons that integrate other eco-systems like HomeKit or Alexa.

My question is: should we introduce org.openhab.misc and eventually re-factor the existing org.openhab.io add-ons to that?

[kaikreuzer]

I would actually tend to say that the referenced documentation is not correct; Instead of misc, the category really is io (as a technical package name), which is then called "System Integrations" on https://www.openhab.org/addons/. This is the category for all add-ons that expose openHAB in a certain way to allow integration into other systems.

I'd therefore say that your request is rather to define a new add-on category as you rightly say that a currency provider does not really fit into any of the existing ones.
The question is whether or not we could make it fit somewhere. Does it get exchange rates from an external service? Then we could probably have an "account bridge" and maybe even think of some things that might provide interesting information; the currency provider would then be yet another service that is provided, once the account bridge is set up.
In case there is no external dependency at all, I would even consider the currency provider to be a core service that be easily provided by default.

Wdyt?

[J-N-K]

Well, we also use the same categories (including misc instead of io for the addon.xsd, the additional add-on services, the Main UI and some other places.

This has been at least the case since openhab/openhab-core#2508, it was named io before and changed because UI and forum used misc instead. It would be a bit difficult to now change that back again.

[kaikreuzer]

Hm, ok, so despite openhab/openhab-core#2508 claiming to fix inconsistencies, we still have quite some inconsistencies...

But to come to a solution for your problem at hand: What do you think about my reasoning above for the currency provider?

[J-N-K]

Yes, a simple thing would be possible with (extensible) channels for the current exchange rate between two currencies (both configuration options of the channel). The required API key could be a binding-configuration parameter (used for the service), because it makes no sense to have two different API keys for retrieving the exact same data.

[andrewfg]

Then we could probably have an "account bridge" and maybe even think of some things that might provide interesting information

We already have such bridges, things and channels for astronomical events, weather, and solar forecasts. IMHO an exchange rate provider is no different from those.