Without further information what am I supposed to assume? But none of the suggestions above are limited to running only one instance. I’ve run up to four instances of OH at the same time, each linked to the others. Nothing I describe above excludes that use case and much of it ius driven by that use case.
Which is the exact use case that caused me to write the MQTT EventBus in the first place.
But the “official” way to do this would be to use the Remote openHAB add-on through myopenhab.org. Each instance would have their own account on myopenhab.org. You’d create a Thing for each remote instance providing the credentials for each one on each OH instance. I would set up a special account for the Remote openHAB addon to use rather than your regualr account.
The Thing will create a Channel for each Item on that remote OH instance which you can link to a local Item. The local Item will receive the same updates and commands as the remote Item does.
No MQTT and bridged brokers are required. Just OH instances talking directly to each other using the native OH APIs.
A rule you don’t have to write though. You can install it like any binding. But a rule is not required either even when using MQTT.
Using a rule, you can find a rule template here: MQTT Event Bus [4.0.0.0;5.9.9.9]. I don’t have telemetry on it but based on views and downloads it’s been installed thousands of times.
It requiresthe JS Scripting add-on as it’s written in JS and I think it requires OHRT which can be installed through openhabian-conf or through a separate rule tempalte or manually using npm. See the post for details on how it works and prerequisites and such.
You install it from MainUI → Add-on store → Automation. Once installed create a new rule from MainUI → Rules → + and choose MQTT EventBus from the list of templates to base it on. Fill out the properties based on what you want (you’ll need two Groups and the Broker Thing) and you are done. The rule will publish commands and updates to <what ever you choose as the root topic>/<item name>/command and <what ever you choose as the root topic>/<item name>/state based on membership to the two Groups.
The rule subscribes to those topics. For example, if a message is posted to richsoh/MyItem/state and the rule template is configure to listen on richsoh and MyItem exists locally, MyItem will be updated based on the contents of the message. Commands are handled the same way. Publishing is based on Group membership but it’s easy to change the rule trigger to trigger on all Items updates and commands.
And this is what the follow profile is for and how you can do this still using MQTT without any rules. The MQTT channel follows what the modbus channel is publishing. So when the modbus channel posts an update, that gets sent to the MQTT Channel and published to the topic configured on the MQTT Channel. No rule involved.
But having this all work without any work on your part is never going to happen. There is no one-size-fits-all approach that will work for all users. But in summary, OH offers the following to solve this use case:
