Add more connection details to add-ons

[wborn]

Adds more connections details for add-ons I maintain, use or know a bit.

Related to #14885

[wborn]

I did wonder if we want to use a local connection for add-ons that do not make any connection at all like the Astro Binding or most persistence and transformation add-ons. 🤔

[jlaur]

I did wonder if we want to use a local connection for add-ons that do not make any connection at all like the Astro Binding or most persistence and transformation add-ons. 🤔

See also #14776 (comment) where we lack a clear definition for "hybrid" bindings running locally, but with some cloud extensions. Perhaps for this particular case none might be appropriate to add. WDYT, @wborn, @kaikreuzer and @J-N-K?

[jlaur]

Thanks for going through this many bindings and adding metadata!

[wborn]

I also think a none value makes sense so users know for sure that such an add-on keeps working without the cloud.

[lolodomo]

This can be discussed.
Yes it is local if your remote server is in the same network as your OH server but it would be cloud and you need an internet access in case you "connect" to a remote OH server not in the same local network.

[jlaur]

I was about to post a similar comment when first seeing this, but decided not to. It's an interesting case, but also gets kind of philosophical - what does cloud really mean? You could put any device outside your own network, even on the internet, but that doesn't make it cloud. To me "cloud" means "a service on the internet completely outside of my control", but that's probably opinionated. If it just means "a service on the internet", then we are back to the problem that anything can be put on the internet, so how do we distinguish? I could also expose a local service on the internet to a friend, which would be local for me, but "cloud" to him. 🙂

In this case, maybe we should look at the most common use-case. I don't know what that is, but might be a means of migrating to a new openHAB version while still running an older version alongside?

[wborn]

In this case, maybe we should look at the most common use-case.

I would go with that because you can also put your serial devices in the cloud and connect to them using a rfc2217 connection provided by the serial transport. 😉

[lolodomo]

I believe a common case could be that a user owns a secondary house and wants to monitor it with its main house.

Could we exclude the remote openHAB binding from this PR ?

[wborn]

Let's figure that one out another time. 🙂

[J-N-K]

none might be good for something like astro, where there is no network activity at all (might also apply for serial or USB connections). If cloud is used for discovery it's cloudDiscovery, if it accesses the cloud (or a remote service) during normal operation, it's cloud and otherwise it's local.

[lolodomo]

none might be good for something like astro, where there is no network activity at all (might also apply for serial or USB connections). If cloud is used for discovery it's cloudDiscovery, if it accesses the cloud (or a remote service) during normal operation, it's cloud and otherwise it's local.

The bindings relying on a serial connection often also supports a serial connection over IP, so it is not easy to choose th eright option.

[jlaur]

If cloud is used for discovery it's cloudDiscovery, if it accesses the cloud (or a remote service) during normal operation, it's cloud and otherwise it's local.

Sorry if the following can be perceived as pedantic. My intention is only to try to get this right, now that we have this box opened.

The original issue definition by @kaikreuzer (openhab/openhab-core#2058):

• local (for add-ons that) interacts locally
• cloud if it connects to an online service (seldom or continuously)

The documented definition (highlighting important words) by you (openhab/openhab-docs#1872):

• local for add-ons that only interact locally
• cloud for add-ons that require a cloud connection
• cloudDiscovery for add-ons that require a cloud connection for set-up

And what you just wrote:

• cloudDiscovery if cloud is used for discovery
• cloud if it accesses the cloud (or a remote service) during normal operation
• local otherwise (i.e. if it doesn't access the cloud during normal operation)

There are slight contradictions here, even between your own definitions. If it doesn't require cloud, but accesses cloud during normal operation, then according to your first definition it's inconclusive - it doesn't require cloud, but it also doesn't interact locally only. According to your new definition it would be cloud, even if it can run perfectly well locally without cloud.

For me as a user, the questions I would expect immediate answers for are:

• Can it run locally without being dependent on an internet connection or any external service?
• Even if it can, will it still call some external services, for example to provide extended functionality?

We cannot clearly answer that with the current options.

I would propose the following (explanations, not descriptions to be used):

• none if it runs locally in the openHAB instance without any network dependencies, even local.
• local if it runs entirely locally (LAN) and will never call external services.
• hybrid is it runs locally, but can optionally also use external (cloud) services for added functionality. This includes what is now called "cloud discovery" which cannot also be seen as "added functionality".
• cloud if entirely dependent on external cloud services.

[jlaur]

Btw, sorry to hijack this PR @wborn, my last comment is clearly out of scope here and could be created as an issue. We can merge this PR now IMHO, but would you prefer to continue discussion here, or in a new issue in openhab-core?

[wborn]

but would you prefer to continue discussion here

Perhaps it's best to create a new issue for resolving the ambiguities so all the tagged reviewers can optionally join it.