[WebThing] Initial contribution

[grro]

Signed-off-by: Gregor Roth gregor.roth@web.de

This merge request includes a WebThing binding for openHAB. It replaces the earlier PR #9185 which has been closed due to underlying git problems.

The WebThing binding supports an interface to remote devices implementing the Web Thing API. The Web Thing API is specified by the W3C Consortium (draft). The specification describes how a device or thing can be discovered and linked based on web technologies.
Essentially, a Web Thing API is a RESTful interface including WebSockets support to provide real-time notifications of events as soon as they happen.

Please refer to the readme.md for more detailed information

[andrewfg]

@grro this is very interesting. It occurs to me that this binding is really only half the story; it is something that imports WoT things into OH. The other half of the story would be something that exports OH Things as WoT things. Probably such an WoT exporter would need to be implemented as part of the OH core rather than as an OH add-on (since for example it would need to access the Thing registry). It might for example be an extension of the REST server. So I wonder if your WoT import binding needs any extensions or adaptions to its architecture to prepare the way for a future WoT export add-on? Do you have any thoughts about this?

[grro]

@grro this is very interesting. It occurs to me that this binding is really only half the story; it is something that imports WoT things into OH. The other half of the story would be something that exports OH Things as WoT things. Probably such an WoT exporter would need to be implemented as part of the OH core rather than as an OH add-on (since for example it would need to access the Thing registry). It might for example be an extension of the REST server. So I wonder if your WoT import binding needs any extensions or adaptions to its architecture to prepare the way for a future WoT export add-on? Do you have any thoughts about this?

Hi,

this PR supports consuming WebThings (as a client) only. My main motivation behind this was to reach a better integration of my pi-based hardware solutions that provides the WebThing API. Providing a WebThing binding could help makers to make their solutions more interoperable by implementing a lightweight standard, for instance, such as in my case.

Providing openHAB artifacts via the WebThings API would also be nice. However, my impression is, that the need for consuming support is higher. Exposing WebThings may be a second step behind this PR. I would prefer to implement features step by step in an iterative, incremental way.

Essentially, this binding implements (1) a client-side interface similar to https://www.w3.org/TR/wot-scripting-api/#the-consumedthing-interface, (2) the WebThing discovery, (3) the (semantic) mapping of WebThing properties <-> openHAB channels as well as (4) the integration into the openHAB infrastructure. At least (3) the (semantic) mapping of WebThing properties <-> openHAB channels should be reusable by providing the server-side support. I have tried to keep the implementation design as clean (-> separation of concerns, encapsulation dependencies, etc) as possible which may help

[andrewfg]

^
Very interesting. Thank you.

[fwolter]

There are some checkstyle warnings left. You could take a look at target/code-analysis/report.html.

[grro]

There are some checkstyle warnings left. You could take a look at target/code-analysis/report.html.

The warning are NullAnnotationsCheck warnings.

I understood that this check does not make sense for classes such as WebThingConfiguration. Additionally, the NullAnnotationsCheck for test classes seems to be a slight exaggeration in my opinion. What do you think?
I have also tried to suppress the checkstyle rules for these cases without success

[fwolter]

The null annotations can be omitted for DTOs. The configuration should be annotated as the values can be null if the user forgets to specify a parameter in textual configuration.

The annotations are also missing for PropertyAccessException, WebSocketConnectionImpl and UnknownPropertyException.

[grro]

The null annotations can be omitted for DTOs. The configuration should be annotated as the values can be null if the user forgets to specify a parameter in textual configuration.

The annotations are also missing for PropertyAccessException, WebSocketConnectionImpl and UnknownPropertyException.

checkstyle warnings are fixed now

[fwolter]

LGTM

Since this is a new binding, another maintainer needs to review your code before it can be merged.

[grro]

LGTM

Since this is a new binding, another maintainer needs to review your code before it can be merged.

Thank you

[grro]

LGTM
Since this is a new binding, another maintainer needs to review your code before it can be merged.

Thank you

Do I have to do anything regarding the second reviewer?

[fwolter]

You don't need to as the "cre" tag signals a pending second review, but you can additionally request a review from openhab/add-ons-maintainers.

[grro]

You don't need to as the "cre" tag signals a pending second review, but you can additionally request a review from openhab/add-ons-maintainers.

I have provided a bugfix commit. It turned out that there are webthing descriptions that include several "alternate" links.

Furthermore, I noticed that my local build reports "Header line doesn't match pattern ^ * Copyright (c) 2010-2020 Contributors to the openHAB project$" errors. These errors have not appeared in my local build of the previous commit (9 days ago).

[fwolter]

Your changes look good. To fix the build, you need to rebase your code to get the latest checkstyle rules.

Here are the commands for rebasing your branch:

If not already done, add the upstream openHAB addon repo as a remote to your local repo and fetch it:

git remote add upstream https://github.com/openhab/openhab-addons.git
git fetch upstream

Then, you can rebase your PR's branch onto main:

git rebase upstream/main

Finally force-push the rebased branch to this PR's branch:

git push origin [your branch name of this PR] --force-with-lease

[fwolter]

will there be a second review? is there no interest in contributing this?

You could request a review from @openhab/add-ons-maintainers.

[grro]

will there be a second review? is there no interest in contributing this?

You could request a review from @openhab/add-ons-maintainers.

Unfortunately, the link returns 404.

[bobadair]

Unfortunately, the link returns 404.

That's weird. If you click on "reviewers" in the upper right corner and start typing "openhab" you should see openhab/add-ons-maintainers come up. You shouldn't really need to do that, though. It just takes a while for another review sometimes. It looks like there are a lot of new bindings in the queue right now, which is good news for openHAB but a lot of work for the maintainers!

[moonthug]

Will this PR be reviewed anytime soon? Interested in this functionality in OpenHAB

[fwolter]

Due to lack of review capacity, the rules for new bindings were weakened. New bindings need only the approval of one reviewer instead of two from now on.