I have three OH 2 installations which currently communicate using MQTT (from OH 1). Keeping the configuration of the three instances in sync is a problem, and I would like to get away from the dependency on MQTT 1.
I’m just starting to experiment with Karaf Cellar, which seems to address the above two issues. I’d be interested to hear from anyone else with an interest in these matters or can provide tips.
It would also be interesting to know whether OH 3 will have any support for clusters of collaborating OH instances.
I’ll try to update this topic as I find stuff out. My initial experiment will be to examine how much Cellar can provide without making any changes to OH code.
Hey @stephen_winnall, nice to see someone asking about such a feature!
In terms of Cellar and what you can achieve with it I can guarantee you can synchronize configurations which are stored/processed using OSGi configuration admin. This means that service configurations such as addons.cfg will get in sync.
If you seek a mechanism which will allow you to copy over Things, Items and Links it won’t be able to help as these are processed as regular files and get pushed into runtime services such as ThingRegistry and so on.
The good news is that Cellar (as you possibly already noticed) is build on top of Hazelcast. This means that you can plug pretty much anything into it. I believe that with valid set of framework listeners and callbacks you will be able to sync your instances. It is a matter of how much work (and code) you are able to invest into it.
Cheers,
Łukasz
PS. Feel free to tag your topic with karaf so it will get properly categorized.
Thanks for the feedback. I’m really just starting out with Cellar. I installed a pristine Ubuntu 19.10 server on VirtualBox and installed the openhab-2.5.1-2 packages on top of that. I then installed Cellar using the Karaf console. Finally I cloned a second instance and renamed it, and edited both instances so they are in the same cluster. So far so good. They can see each other.
What I would like to be able to do initially is to enable OH add-ons (I’m using Systeminfo as a guinea pig) on one instance and have it be enabled automatically on the second instance. Using PaperUI, if I use the webUI to install Systeminfo, it appears as a local bundle on the machine I installed it on, but not at all on the other machine (because it isn’t installed into the cluster). So my next step is to find out how to make a local bundle into a cluster bundle… I suspect I need to look at bundle listeners.
I don’t want the Things to be sync’ed: the reason I have multiple instances is because they deal with different things in different spaces.
This functionality is possible with Karaf feature listeners. In this case Cellar is attached to Karaf core and broadcast feature state changes to Hazelcast cluster where other nodes listen for them.
Cellar also provides a feature listener, disabled by default as you can see in etc/org.apache.karaf.cellar.node.cfg configuration file:
feature.listener = false
The listener listens for the following local feature changes:
add features repository
remove features repository
install feature
uninstall feature
For bundle level updates there is bundle.listener option which needs to be set to true. My advice would be to start just from config.listener set to true and watch whats gonna happen. There are additional settings which can be useful such as property excludes. Some of config parameters might be relative to install location.
If you set config.listener = true in etc/org.apache.karaf.cellar.node.cfg, installing or uninstalling an OH binding on one machine in a cluster will result in the same happening on the other machine in the cluster. Cool
I initially enabled bundle.listener and feature.listener too. The same happened as above, but the webUI on the machine I did the install/uninstall did not refresh.
I can’t speak to Cellar. But I can speak to the MqTT Event Bus. The equivalent of the MQTT Event Bus for the 2.5 version of the MQTT binding can be found at Marketplace MQTT Event Bus. My understanding is the access to the Items required to implement this in the binding is not allowed for 2.x bindings which is why the author did not include it in the binding itself.
I’m exploring options to convert this to a Rule Template using JavaScript instead of Python and other options to make installation and use of it easier (i.e. just import a Rule template). For now, I’ve a Rules DSL and Python version that works quite nicely and is surprising little code:
reports online/offline status of OH instances through a retained LWT message
publishes updates and events separately and individually controllable
All that is required on the receiving OH instance is to have an Item of the same type and name
state updates are published retained, commands are not
can control which Items publish what events through Group membership
And I’ve a backlog of improvements including:
automatic creation of Items on the subscribing side (optional)
automatic discovery of the remote OH instances and creation of Things/Channels (not sure if it’s possible yet)
option to publish all Items (right now you have to add them to a Group)
better error handling
have a better way to import and use the Rule but that depends on what the NGRE will look like so I can’t make any changes there yet
All I can say is that the vote by the AC to remove support for OH 1.x bindings pointed to this post and the option to run an older OH instance with OH 3 to retain the ability to use 1.x binding as justification for removing the support in OH 3.
I’m trying to work out how to make channels available to other members of a cluster, bearing in mind the remarks of Łukasz above. What I’m thinking is to use DOSGi and CXF to create a proxy on the remote cluster member which can then be used in a link to an item.
Unfortunately, I don’t really know my way around the OpenHAB sources. Could someone please point me at the project that implements links between items and channels?
