No, that isn’t the best way to replace the event bus.
I’m looking into it and will post a tutorial when I get it to work but my current idea for an approach is:
Outgoing:
- Create a Group
- Add all the Items you want to publish to the event bus to this Group
- Create the following two Rules (or only one depending on how you have the event bus configured):
a. triggers on Member of MyGroup received command
b. triggers on Member of MyGroup received update
- The body of the Rule is pretty simple. Call the new MQTT Action along the lines of
a. actions.publishMQTT("openhab-1/out/"+triggeringItem.name+"/command", receivedCommand.toString)
b. actions.publishMQTT("openhab-1/out/"+triggeringItem.name+"/state", triggeringItem.state.toString)
That’s it for outgoing.
I haven’t thought much about the incoming side of things but I think it will require creating a separate Channel for those topics on the receiving OH and linking those channels to the Items that represent the remote Items. Perhaps two Channels as I don’t know if Channels are one way or not.
Like I said, I haven’t fully thought this through but as far as I can see we are looking at the addition on one new Group, two three line Rules, and creating Thing Channels for all the topics you care about in a remote OH instance. It’s not zero extra work but it is far less work than you make it out to be.
If there were a way to learn the topic that an event comes in on it would be even simpler. And I believe this IS possible in the NGRE and MQTT Rule triggers, but I haven’t got that far yet. But if I’m correct then you just need one Channel that subscribes to “openhab-2/out/+/command” and inside the Rule you can figure out which Item the new state needs to be sent to.
Yes everyone, the cheese has moved. It is going to be some work. And the roll-out of this new binding could have been managed better (hopefully lessons learned are being taken, especially when the HTTP 2.x version binding starts to roll out). But David is doing his best to give us the same capabilities we have with the MQTT 1.x version binding while remaining compliant with the architecture and constraints of OH 2.x.
And assuming I can make it work like I think I can in the NGRE, I can publish a library on github (maybe someday the IoT Marketplace) so you don’t have to implement anything yourself. Just import the Rules and you are good to go.
OH 2 works very differently from OH 1 which is why bindings have to be rewritten for OH 2, not just simply modified and ported. Many things that are possible and make sense in OH 1 are not possible in OH 2, or have to be done in radically different ways.
The event bus hasn’t been just willy nilly abandoned. Access to the event bus in the ways necessary to make it work is not allowed in OH 2.x, or at a minimum not encouraged.
For everything there is a price to pay. This is part of the price we have to pay to get automatic discovery of devices and many of the other and growing benefits that we get through the use of Things.
I don’t think this would be all that hard. One would need to write a parser that can extract the mqtt=
from Items and create the appropriate Channels or Things. It’s just a text to text conversion really with maybe a REST call if the script is to store the Things/Channels in JSONDB instead of .things files.
Someone has to step up to do it though. It won’t be me. But it won’t be hard I think.