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
2 Likes
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.
1 Like
@David_Graeff, in the documentation on GitHub there are some limitations:
- The following HomeAssistant MQTT Components are not implemented: Camera, Climate, Fan, Cover. The light component only supports a on/off switch and no color or brightness changes.
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.
3 Likes
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 
3 Likes
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.
1 Like
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?
Do not enable both.
There is no forced migration. I suspect that the MQTT 1.x version binding will still be around for as long as it continues to work. However, realize that there will likely be little to no continued development on the MQTT binding and at some point there will be a change to OH, the MQTT specification, or some library the 1.x version relies upon that will break it and there will be no one willing to spend the time to fix it.
So eventually you will want to migrate to the 2.x version of the binding. But I suspect that you will be able to continue using the 1.x version for years.
Personally, I think the 2.x version is a huge improvement over the 1.x and would encourage you to not wait until you have to migrate. It’s also always less stressful and easier to migrate when you have time then it is to migrate because you have to.
If you see the discussion above between myself and David, you will see that there will be an easy way to replicate the MQTT Event Bus using a couple of simple Rules. As I continue to figure out the Experimental Next Gen Rules Engine, I expect that these will be made available as a library as the NGRE matures and we come up with a good library distribution mechanism.