For JSR223 Python users, I’ve checked in a reusable library implementation of the below at https://github.com/openhab-scripters/openhab-helper-libraries/pull/257. I’ll update this thread when it gets merged. In the mean time check it out and give it a test and report back here if you have any problems.
This keeps coming up so here is a quick tutorial on how to set up an event bus configuration using the MQTT 2.5 M1 binding. I don’t know if all of these features exist for the 2.4 Release version.
Setting up the binding and MQTT Broker Thing is beyond the scope of this tutorial.
What’s an Event Bus?
There are times when one may have more than one OH instance that needs to have some or all of it’s Items synchronized across all the instances. In the MQTT 1.x binding there was a special configuration that enabled this that no longer exists in MQTT 2.x.
The event bus will have two parts, the subscription and the publishing.
We will use the following conventions:
| topic | purpose |
|---|---|
<openHAB name>/out/<Item>/command |
Topic where all commands that occur on <openHAB name> are published |
<openHAB name>/out/<Item>/state |
Topic where all state updates that occur on <openHAB name> are published |
<openHAB name>/in/<Item>/command |
Topic where commands that occur in another openHAB instance are published that should be reflected in <openHAB name>. You can have more than one of these groups of topics that you subscribe to if you have three or more openHAB instances to synchronize. |
<openHAB name>/in/<Item>/state |
Topic where state updates that occur in another openHAB instance are published that should be reflected in <openHAB name>You can have more than one of these groups of topics that you subscribe to if you have three or more openHAB instances to synchronize. |
<openHAB name> is a name you chose to uniquely identify each openHAB instance. <Item> will be replaced with the Item name.
Note that you will want to use the same name for all Items that need to be synchronized across the OH instances.
One important thing to note is that the synchronization can be one way. For example, one OH instance can just subscribe to another OH instance without publishing their own commands and updates. This raises a little bit of confusion as to which OH instance needs to publish to which set of topics and which to subscribe. Unfortunately the answer depends on how you are doing the synchronization.
Let’s say we have two OH instances that we want to synchronize: openHAB-main and openHAB-remote.
Then for commands openHAB-main would publish to openHAB-main/out/<Item>/command and subscribe to openHAB-remote/out/<Item>/command. openHAB-remote would publish to openHAB-remote/out/<Item>/command and subscribe to openHAB-main/out/<Item>/command.
Now let’s say that we have a bunch of OH instances and the are all just publishing sensor reading to openHAB-main. In that case openHAB-main would not publish at all and openHAB-main would subscribe to openHAB-main/in/<Item>/command. All the other instances would publish to that same topic.
Publishing
The first step to publish commands and updates to the out topics is to create a Group. Be sure to give the Group a Type. It doesn’t matter what type we choose because we will not be aggregating the states of it’s members, but without a Type the Group will not receive events that are necessary to drive Rules [NOTE to self: Is this the case for Member of triggers?]. For this tutorial I’ll use:
Group:String PubItems
All Items that need to be published to the “event bus” need to be a member of this Group.
Next we will need two Rules.
rule "Publish commands to the event bus"
when
Member of PubItems received command
then
val mqttActions = getActions("mqtt","mqtt:systemBroker:embedded-mqtt-broker") // use your broker Thing ID
mqttActions.publishMQTT("main-openHAB/out/"+triggeringItem.name+"/command",receivedCommand.toString)
end
rule "Publish updates to the event bus"
when
Member of PubItems received update
then
val mqttActions = getActions("mqtt","mqtt:systemBroker:embedded-mqtt-broker") // use your broker Thing ID
mqttActions.publishMQTT("openHAB-main/out/"+triggeringItem.name+"/state",triggeringItem.state.toString)
end
NOTE: I show them as separate Rules to make it easier to only partially implement (e.g. only synchronize updates). They could be combined into one I believe.
That’s all there is to it. All commands to all members of PubItems get published to the command topic and all updates get published to the state topic.
Subscribing
For subscription we need to create a publish trigger Channel on the MQTT Broker Thing and configure it to subscribe to the output topics from the other openHAB, or the input topics for this openHAB instance. You can use the wild card subscription to use this one Channel for all the Items. Be sure to define a separator character so we can get the MQTT topic from the event in our Rule.
The screenshot above only subscribes to the command topic. If you want both commands and updates you can use openHAB-remote/out/# as the topic.
With the Channel in place we only need a single Rule.
rule "Subscribe for commands and updates from the event bus"
when
Channel 'mqtt:broker:broker:main-openHAB' triggered
then
val itemName = receivedEvent.split("/").get(2)
val type = receivedEvent.split("/").get(3)
val state = receivedEvent.split("#").get(1)
if(type == "command") sendCommand(itemName, state)
else postUpdate(itemName, state)
end
Note that the above handles both commands and updates.
Future work
As OH 3 comes closer and closer and a distribution mechanism is built to distribute Rule templates, the Rules above will become available as an installable Rules template so you don’t need to type it all in. The JSR223 versions of these Rules should look very similar. If someone codes them up I will happily add them to the OP.