I’ll look into adding that or something like that to the library. However, there is now a binding that does this in OH 3 (and OH 2.5 I would imagine) which is probably a better way to go when/if you can use it. A binding will always be easier to use and it will be better maintained in the long run.
Edit: I’ve added your “hacnish” change to the code in the repo. It works. Thanks!
I’m a bit confused right now! 
Do you mean a “Eventbus”-Binding or a “Umlauts”-Binding? I’d like to prepare for my main openHAB to migrate to OH3, so I’ll need to have some kind of eventbus-logic there to include my other instances (two of which must stay in OH2, because of legacy 1.x bindings)
EventBus binding, called Remote openHAB. It links OH instances without the need to use MQTT.
So how is this implemented, does it use the REST API via HTTP/HTTPS?
It uses the REST API to send updates/command between instances and SSE to get the Item events.
oh! Thanks! Remote openHAB Binding ist also talking about it - but I seem to can’t find it in my OH3-MS3 test instance or in the official 2.x bindings? Do I miss something obvious? or do I have to download a jar for this?
It is a OH3 binding only, included in the official distribution since milestone 2.
sorry - the update to MS2 was faulty, I was still on MS1. now I see it! thanks!
@rlkoshak, I’ve been trying to implement the eventbus in openhab 2.5
The publishing part works fine but when I try to add the channel in PaperUI (almost idendically to your example), I always get ERROR: 409 - Conflict. nothing in Karaf or any of the logs.
The added channel is nowhere to be found in PaperUI.
How can I debug the creation of the channel ?
Can you provide an example of how the channel can be configured in the mqtt.things config file ?
409 means there is something about the state of the server preventing the creation of the Channel.
There should be something in the logs about that. I’m not sure how to debug this. Perhaps restart openHAB and see if it persists. If so look in the REST API Docs at the Channel creation endpoint and see if the docs provide any additional information about what the 409 means.
No, nothing in the logs.
I had tried to restart openhab. the problem persists.
What Karaf command can I use to view the created MQTT channels ?
Any chance you can hint to the correct syntax to create the channel in the things config fil e ?
After increasing the debug level on the MQTT binding I get this in the Karaf interface
20:22:13.176 [INFO ] [est.core.internal.thing.ThingResource] - Received HTTP PUT request for update at 'things/mqtt:broker:local' for an unmanaged thing 'mqtt:broker:local'.
In the end. I found the solution here
Bridge mqtt:broker:myUnsecureBroker [ host="192.168.0.42", secure=false ]
{
Channels:
Type publishTrigger : myTriggerChannel "Receive everything" [ stateTopic="allItems/#", separator="#" ]
}
Sorry to hijack this topic. I have a scenario that a master OH3 is sitting in a cloud with openhabcloud. All the remote servers will connect to openhabcloud via cloud connector, and could be behind firewall or proxy servers. In such a case, master OH3 will not able to communicate with remote servers unless it punches through openhabcloud. Any thoughts on how to resolve this scenario? Thanks
I don’t think it can be done. But you should open a new thread so people who use (and perhaps the developer) the remote binding can answer.
Hi Rich
Im trying to set this up , on the local instance I can see the command sent, and received on the remote instance. The remote instance has a Zwave light, and its console log shows it being switched on but it doesnt actually switch on. Instead, the remote instance log fills with this:
16:01:08.710 [INFO ] [smarthome.event.ChannelTriggeredEvent] - mqtt:broker:2eee62e3:House-updates triggered Garage/out/BedRoom1Sw1/state#OFF
16:01:08.722 [INFO ] [smarthome.event.ChannelTriggeredEvent] - mqtt:broker:2eee62e3:House-updates triggered Garage/out/BedRoom1Sw1/state#OFF
16:01:08.769 [INFO ] [smarthome.event.ChannelTriggeredEvent] - mqtt:broker:2eee62e3:House-updates triggered Garage/out/BedRoom1Sw1/state#OFF
16:01:08.770 [INFO ] [smarthome.event.ChannelTriggeredEvent] - mqtt:broker:2eee62e3:House-updates triggered Garage/out/BedRoom1Sw1/state#OFF
I have two instances
Garage (Main instance, with mosquitto running locally)
House (remote instance, with Zwave and local devices)
Here is the Broker on the Garage (Main) instance:
Here is the Broker on the House (client) instance that has the ZWave light
When the real light switch is removed from the two groups, I dont get the infinite logs but the light also doesnt switch on (despite it showing an update)
Its really not clear from your tutorial what is done to what device, ie whats done to the Local and Remote instances. In ’ Setting up the Subscriptions’ your screenshot doesnt really align with what your talking about so to me, I’ve no idea what channels go on what device.
ie: is there a broker per machine? then is there a channel per broker, per machine? are the rules required on both. Sorry, but its really really confusing.
Thanks
One of the OH instances needs to be the main one. This instance only publishes commands and only subscribes to updates. The remote instance is the one that is actually connected to the device. This instance only publishes updates and only subscribes to commands.
If both instances subscribe to both commands and updates and both instances publish both commands and updates you’ll end up with an infinite loop. So you should never have an Item that is a member of both PubItems_CMD and PubItems_UPD on the same OH instance.
The entire first few hundred lines of the tutorial is intended to make this point.
The “owner” of the device subscribes for commands and publishes updates. The other instance of OH subscribes to updates and publishes commands.
Pay attention to the tables. Pay particular attention to to the topics in the tables.
I’m not sure how to correct this. That section has a screen shot for the subscription Trigger Channel and then spends the whole section describing what each of the parameters mean and what should go in there.
But the discussion about what subscription goes on what device happened earlier. But this is really complicated. It’s not just a simple one-to-one configuration. If you want that you are better off using the Remote openHAB add-on.
There is some additional discussion about the various topologies that is possible with the event bud (one-way, one-to-one, hub and star, etc) at the links to the github repo. Looking at those might be helpful.
But in general, this tutorial is an advanced tutorial and not something to be taken on lightly unless there is no other option. The code is deceptively simple but understanding the message flows is vital.
I should add that if you have any suggestions to make the tutorial more clear I’m open to them. I’ve rewritten that thing three times now and plan on another rewrite at some point.
Also, if it’s still not clear I’ll try to draw another diagram to help.
Thanks Rich, it makes more sense after your first few sentences. Best to break it up like so:
Main Instance (Publishes only)
Also, setting the groups as string gave me errors with OnOff Types FYI.
Question, so this would not work if the remote instance was sending commands? Lets say the remote instance has a ZWave scene controller physically in the house - you push buttons etc so it sends commands back to the Main instance which runs rules from those commands. So not only On/Off commands but numbers such as power metering readings and scene numbers etc, even OPEN/Closed from Contacts
Effectively, totally bi-directional. This bidirectional works just fine with MQTT 1.x event bus using all item types
Cheers
There is no basic rule. It all depends on which openHAB instance is actually connected to the device, how many openHAB instances are connected to each other, and the nature of the device. That’s why it’s important to make sure to understand the data flows.
The thing you need to avoid are infinite loops. Infinite loops occur when you subscribe to both the update and the command channel for a given Item on both OH instances.
But you wouldn’t need to publish updates from that scene controller right? All you care about are publishing the Commands. And you wouldn’t be commanding this Item from the openHAB that isn’t connected to the controller. All you care about is subscribing to the commands.
So those Items are members of PubItems_CMD only on the machine connected to the controller. The other openHAB instance subscribes to the commands only and publishes nothing for that Item. You don’t care about the updates at all for that Item. It’s only the command that are generated by physically pressing the buttons on the controller.
These are sensors. So for these Items you don’t care about commands. In the case of Contacts you can’t command them if you wanted to. So the instance of openHAB actually connected to the device puts those Items into PubItems_UPD. The other openHAB instance only subscribes. It doesn’t own the device and the device is a sensor. You wouldn’t be updating that device in the other openHAB instance anyway so don’t publish anything at all for those Items.
Even in the MQTT 1.x event bus if you didn’t get these settings right an infinite loop occurred. I fought against many such loops in the past with MQTT 1.x.
But, the above is by design more flexible and more capable than the MQTT 1.x event bus. It was never intended to be a mere reimplementation. I had plans to create a simpler version that more closely mimicked the old event bus only even simpler but that became redundant when the Remote openHAB add-on was released. So this tutorial is mainly kept around to handle those cases that are too complicated to be implemented by the Remote openHAB add-on.
If you want simple mirroring that’s the tool to use. If you are on OH 2 and want simple mirroring of everything, the MQTT 1.x event bus is what you want to use. If you want to have control over how the Items are mirrored on an Item by Item basis then this tutorial is for you. But that means you have to understand the data flows on an Item by Item basis.
The only real difference here from the 1.x EventBus is that in order to allow the control and flexibility I can’t just hide these details like the 1.x binding did. But make no mistake, it worked pretty much the same way to avoid infinite loops.
Which openHAB instance “owns” the Item (i.e. is connected to the actual device)? That will usually be the one that publishes the state updates, unless the Item is commanded from the binding (e.g. a motion sensor, remote controller, etc) in which case only the commands are published.
The openHAB instance that has a proxy for the Item usually wants to know what state the device actually is in. So in that case it will subscribe to updates. But for actuators it also wants to remotely control them so it will publish commands.
You never want a case where you both publish and subscribe to commands on the same OH instance at the same time. When that happens:
The same occurs if you both publish and subscribe for updates on the same OH instance at the same time.
It’s still two way.
Thanks Rich, I’m going to have another stab today at doing this - all makes sense. I had used MQTT1.x successfully for some time to do what I needed but the implementation confused me using MQTT2
Very detailed response, thank you! I cant use the Remote OpenHab binding because I’m not using OH3 - have no desire to do that yet. For now, it’s about getting off the legacy 1.x bindings which I’ve all but done except for MQTT
Thank you!
