Having helped you some with your Rules in the past, I think I can safely say that your overall approach is somewhat unique. I can’t comment on whether my event bus would work for you but I have pretty thoroughly tested it for the more typical way most of us create our configurations.
For an example, let’s say we have a Switch named Foo on the remote OH instance that we want to see the status of and control from a local OH.
First of all, it’s important to understand that the the key assumption is that the remote OH is autonomous. The Foo on the local OH instance is merely a proxy to an Item on the remote OH but the “real” action takes places on the remote OH instance. Therefore, we do not want to process commands on local Foo that originate from the remote OH instance. Similarly, we don’t want to send updates on local Foo to remote OH. This is what avoids the infinite loop (I may need to make this more clear on that posting for the Event Bus tutorial).
Remote OH:
- publishes all updates to the Switch Item to a well defined (and configurable) topic as a retained message:
remote/out/Foo/state
- subscribes for commands on that Item at
remote/in/Foo/command
(NOTE: the subscriptions are done using a Channel trigger on the MQTT Broker Thing with a wild card subscription to remote/in/#, messages trigger a Rule and the Item name is parsed out of the topic and the Item updated or commanded based on the message).
If you are using the Rules I wrote, to configure an Item to be shared in this way simply add that Item to the right Group on the remote OH. Depending on the Group membership you can set this up to be one way (e.g. remote only publishes) and handle only updates or only events.
Local OH:
- publishes all commands to Foo to
remote/in/Foo/state
- subscribes to updates to Foo from
remote/out/Foo/state
- has a proxy Item named Foo of the same type as Foo on the remote OH
Again, add Foo to the right Group on local OH. It’s a good idea to configure local Foo with autoupdate=false as well but not required. That way when you send local Foo a command, it will not change state until remote OH processes the command and publishes it’s update.
So if Foo on the local OH receives a command ON:
- local Foo receives command ON
- “ON” is published to
remote/in/Foo/command
- remote OH receives ON message and triggers event bus Rule
- event bus Rule parses “Foo” from the topic and calls sendCommand(“Foo”, “ON”)
- autoupdate, or the device connected to Foo updates the Item to ON
- the event bus Rule triggers from the update and publishes ON to
remote/out/Foo/state
- local OH gets the message and triggers the event bus Rule
- event bus Rule parses “Foo” from the topic and calls postUpdate(“Foo”, “ON”)
Thus there are no loops and the local OH Item can control and remain in sync with the remote OH instance. Configuring which Items are published and subscribed to is all controlled by Group membership.
The ability to easily control which Items publish and subscribe to what updates and events was the big reason why, IMHO, the event bus configuration with the MQTT 1 binding was unworkable and resulted in infinite loops easily.
If, for some reason, you do want to process commands from the remote OH on the local OH or you want to receive updates from the local OH on the remote OH instance than you will need to modify the event bus Rules to not update or command an Item that is already in a state that matches the received message. That too should avoid infinite loops, though it won’t work for all Item types as there are some commands that do not translate into an Item’s state.
