Binding for managing items of remote Openhab2 instance

Hello everybody.

I’m relatively new to openHAB (first heart of it April this year) and I am currently developing, together with some other students, a binding for managing items from remote Openhab2 instances as a project for my university. We already accomplished the prove of concept and now I would like to collect some opinions from the community about our approach, before attempting to distribute our binding to openHAB or continuing the development and fine tuning.

What’s the idea and what did we try to accomplish:
We want to give the openHAB user an easy way to read, manipulate and virtualize items from a remote openHAB instance in his local openHAB instance via GUI.
How does the binding work currently?

  1. Reading/sending data from/to remote openHAB instance
    a. The network data transfer of the item data is accomplished via the REST API of Openhab

  2. Storing remote items data in local instance
    a. We use the openHAB mechanism for managing items via *.items files. The binding generates an *.items file (1 per binding instance) where it stores the item information of the remote items.
    b. State changes in remote items are written directly into the ItemRegistry of the local openHAB instance.
    c. The user must configure a time interval for checking the remote openHAB instance for new items or changed item states.

  3. Virtualizing and manipulation of the remote items
    a. Our binding generates a basic *.sitemap file for the user where all items (or less, depends on user configuration) from the remote openHAB instance are represented.
    b. Alternatively, the user can create his own sitemaps to virtualize the remote items. He could easily create a single sitemap to display items from several remote openHAB instances.
    c. The user can set new states for the remote items via the GUI (only tested with Basic UI).

  4. What has the user to configure?
    a. Currently, the user has to create a new instance of our binding for every remote openHAB instance he wants to manage.
    b. The user configures the IP address and port and some further options to set up the binding.
    c. The user can define which items should be pulled from the remote openHAB instance. He can just pull all items, items referenced by sitemaps or items referenced by specific sitemaps.

So far, I found the following links to this topic inside this forum:

I understand that openHAB is not designed to be linked with several other openHAB instances and manipulate Items/Things on remote instances. We also did hit some barriers, when implementing the feature for updating the states of remote items.
I would like to have your input or questions about our approach.
Is there even any demand for this functionality inside the openHab Community?
I will provide the source code for our binding in Github as soon as possible.

I would have expected:

  • the binding would automatically discover the Items on the remote OH and add Things to the Inbox.
  • the user would accept those Things from the inbox they care about.
  • the user would link the Channels on those Things to local Items.

Having a Binding that creates .items files is very much not the approach one expects from a 2.x style binding and for this to be useful to the community at large I would expect it to be a 2.x style binding.

At a minimum, create the Items using the REST API, don’t create .items files.

There is a websocket that can be used to subscribe for events, if I understand correctly. You shouldn’t need to poll for updates.

How does the user do this? Through entries in the binding’s config or on the config page in PaperUI for the Binding?

While true, the MQTT binding has this ability in the MQTT EventBus config.

One advantage your binding has over that is that it doesn’t require a separate MQTT Broker to be running and set up. The disadvantage your binding has over it is the MQTT Event Bus will push Item event updates as they happen, you don’t have to poll and potentially get stale info or miss events because of the polling period.

For example, let’s say we have a 5 second polling period. If my Item changes from ON to OFF and then back to ON again before the polling period then that middle OFF event will be lost on the central OH server. That missed event could be really important.

There is a lot to be said to have a binding that does this that doesn’t require a separate server. Though if the MQTT 2.x binding every gets completed that problem will be solved too (it will come with it’s own MQTT broker).

But in order for your binding to useful to me I would require:

  • ALL remote events need to be received by the central server. We can’t miss any events that occurred faster than the polling period. I’d like to see the polling period done away with and either have the remote OH push events as they occur or use the websocket to get the events as they occur. Any polling period that is slow enough not to cause problems on the remote OH server will be too slow to guarantee timely receipt of events on the central OH server.

  • The binding should be a 2.x style binding meaning it should work with Things and Channels, not .items files. Configuring the binding should be possible through PaperUI. As it stands this binding is completely unique in how it is configured and how it works and what it does. No other bindings create Items automatically nor do other bindings create sitemaps and they shouldn’t, it’s not their job. There is the Home Builder add-on that does this, but it is not a binding. So perhaps it would make sense to set up something as an add-on rather than a Binding that builds up the Items using the HTTP binding or the like to do these tasks. But I’m uncomfortable having a binding do this.

That’s my two cents worth. The tl;dr is I like the idea a lot. But I’d rather see it use OH 2.x binding concepts and approaches.

There is and to date it has been met with the MQTT Binding with the MQTT EventBus. I currently use this now to manage a remote OH instance that is over 70 miles away.

@rlkoshak thank you for your response.

The approach to use openHabs discovery functionality sounds really nice and I will discuss this with my colleagues.

I understand your point in not using older file mechanism. I’m guess our approach to synchronize on item level and not on thing level is the major flaw here.:confused:

Well. Knowing this before would have saved a lot of time I guess.

The user configures the binding on the config page in PaperUI.

That is correct. We miss events between the polling. In the current state, our binding would only be useful for simple use cases and setups.

That sounds very useful.

Here I absolutely agree. For use cases, where timing is important our approach is inappropriate.

The binding does provide its own channels and links the generated items to them. This is also configured inside the .items file. As I said above the configuration of the binding is done on the PaperUI.

I understand the problem with the generated items. As I said above, the flaw in our approach is the synchronization of items and not things. The created sitemap is more or less just part of our prove of concept to test the synchronization. We could skip this feature.

Or spit it out into it’s own add-on. The feature is a nice one, it just doesn’t belong in a binding. It’s not an unheard of feature either. The Hone Builder add-on does something similar.