You can publish all item changes to mqtt via the new rule engine.
To convert an incoming stream of published item changes back to item state updates you would use a script and the trigger channel of the mqtt broker.
I think you can satisfy all mentioned use cases with what is there already if Iām not mistaken.
It is at least not necessarily to touch the event bus directly anymore.
I rebuild the thning from scratch, this should not the problem
I donāt see an easy way to do this without something like the MQTT publish Action.
If have to create a rule two rules (one in the remote OH and one in the āmasterā for each and every item that needs to be mirrored.
I donāt think anyone is arguing that it canāt be done. But right now I mirror 50+ items with three lines of config code. Iām going to have to generate 100+ rules to replace that with MQTT 2.x. Itās going to be a whole lot of work and a nightmare to maintain.
If I had the publish Action, I could just write one rule and use the event.topic variable as the topic to publish to. Iām not sure how to replicate the behavior of the subscribe part. I know if no way to subscribe to the using * and get both the message and what topic the message was posted to do I need manually configure 100 items with MQTT publish and subscribe.
So at best Iām going from three lines of config to 100 painfully point and click created Rules, or 100 manually configured MQTT Items.
The loss of the event bus doesnāt break this per se, but it generates a massive amount of work to maintain just what I have working now.
What if you just use the clustering capacities of the MQTT-Broker? I use VerneMQ, with this one itās dead simple.
the āproblemā is more related to the OH2 configs and the ease of configuration using the existing MQTT<->Event Bus integration.
The alternative is a big pain (it works but it takes much more time to setup and debug) = define multiple Items in both OH2 instances and configure them in a way to exchange info between them (using MQTT). The Broker setup doesnāt affect this (or at least, I donāt see how it will help).
It is coming 
And it will allow to publish to a topic based on the rule action inputs (for example item name, item value).
In your case you would setup a new-rule-engine rule that triggers on an item change and perform the mqtt action to publish for example to āmyfirstinstance/{item_name}ā->{item_value}
You can. Create a trigger channel on the MQTT broker, subscribed to āmyfirstinstance/#ā.
The trigger payload at the moment is the value only, but I will extend the payload to contain the topic name as well separated with a custom character.
You only need one new-rule-engine rule that fires on the mentioned trigger channel and executes a script that does a postCommand or so.
So all in all: You are right it is not possible right now, because Iām waiting for another framework feature to arrive, but it will be. There should be no reason to need the mqtt-eventbus binding anymore or did I overlook a use-case?
Cheers,
David
OK, then this isnāt so bad. A couple of Rules that I can later distribute as a library or a template isnāt so bad at all.
Nothing I can think of. I think as long as we can subscribe to a tree of topics using # and get the topic as well as the message itself and we have a way to publish to arbitrary topics from a Rule (using event.topic as the MQTT topic will probably be the most natural) I think we have all the bases covered.
@David_Graeff, in the documentation on GitHub there are some limitations:
When I try to add a light component, the only found channel is a color channel.
Thatās not correct, because my config payload is:
{
"name":"test light",
"state_topic":"homeassistant/light/testlight/onoff/state",
"command_topic":"homeassistant/light/testlight/onoff/command"
}
It would be great if you can support also the brightness, color and color temperature(as a dimmer) channels for light components.
I do not intend to advance the homeassistant support at the moment. But the mentioned bug will be fixed.
@David_Graeff maybe a trivial question, but after reading some comments (here and in github): Is there a reason for all this urgency with regards to bringing this MQTT v2 binding to the next release?
No not at all. It is available in Eclipse framework and collide with the old mqtt binding. It is shining through to openHAB here and there, so it either needs to be hidden from openHAB in one way or another or be rock solid to really replace the old binding.
Can someone answer me some questions about mqtt?
IĀ“m on oh2.4 snapshot and now i will starting my first work with mqtt. I bought some esp8266 modules and want to integrate them now.
Which version is recommended to start with? I didnĀ“t use mqtt. This is my first start with it.
Should i still use mqtt 1 or should i use mqtt 2?
All what i did so far: i installed mosquitto (with apt-get install mosquitto) on my debian serverā¦
Try the Homie-Implementation, but take the fork from bodiroga, he implemented Homie V3.
This implementation is as I said a fork, pull request to the original is pending I think
Was this answer for me?
I need help with the server side mqtt (on my debian server running openhab), not with my esp-devices.
The question was about mqtt binding version 1 or version 2.
Start with mqtt1. The mqtt2 binding is not quite ready and youāll get plenty of support in the forum.
What ESP modules did you get?
Thanks.
I bought some nodeMCU and Wemos D1 mini to start.
I will install some temp/humidity-sensors around my house, rfid-wiegand-reader for my frontdoor, ferraris-reader for the powermeter of my parents house (sending data with mqtt over vpn to my openhab server, because my parents donĀ“t have an own server), reading out a BG eTech SDM 630 powermeter with modbusā¦
Do i need the mqtt action too? Or is mqtt1 binding enough for me?
thatās some cool stuff! We wait for updates 
No. Just the binding. The action is used to send mqtt messages using rules.
By the way: Enable auth on your Mosquitto. Itās really easy and you canāt go wrong with having some extra security in place.
Ehm, this topic is about MQTT 2.4. Please stick to the topic please 
I already did that. I made some mqtt tests some time ago with owntracks and so mosquitto was already installed and configured for external access. But now i only use it internal.
user/password is already enabled in mosquitto.conf
@David_Graeff
Ok, will open another thread if i have any further questions.
Will I be able to use MQTT v1 ongoing or will I be forcibly migrated to v2.4 which Iām a bit wary of as everything currently works really well? I do use the eventbus on MQTT.
Even better would I be able to use both?