I totally agree AND would like to add don’t assume or take a suggestion or wish to discuss something as a complaint or an attack. I am saying to all and not aiming it at you or anyone else.
A) don’t attack the devs or anyone willing to help out.
B) don’t attack a passionate user that loves openhab for trying to understand and suggest ideas.
I would like both to happen and sorry I won’t get drawn into arguments, I have better things to do.
Yes, as I said, at some point he (someone) would need to involve those who are going to do the job (file an request).
But its still a suggestion here on the forum, where we can debate for/against/changes of the suggestion itself. There is simply no need to attack him for doing this.
If you dont like his suggestion, you´re free to not participate in the debate, or argue for whatever reason you may have for beeing against.
But by telling him there already is an option, which you know he dont like, cause he is suggesting something he believe is better. (He´d actually mention the MQTT option). That´s not really doing any good.
Right now, I see a few people who rather wants to avoid (sabotage) the debate, twisting its contents to suit something I really cant get my head on to, why, except their personal needs.
If you dont like the suggestion, thats totally fine. But if you do, maybe you should back up the suggestion, maybe even help gettting the real request filed as clear as possible to be better accepted by the developers. Insted of these pointless discussions about, how OP present his suggestion, your personal needs, and whats already possible. That doesnt change anything, except killing the debate. And the idea will probably never reach the developers, cause its killed with the attitude he´s meeting from some people here on the forum.
Thats very sad when the idea is a great idea! (which it is in my opinion wether or not I´m ever going to use it. Which is why I´m taking part, backing up dastrix80).
But debating a idea/suggestion could be usefull for OP and the rest of us, before actually making the final request.
Again, try not to focus on how he present it and your personal needs, but insted focus on the idea itself from an over-all point of view.
It seems to me, you rather prefere each and every individual user filing requests all by themselves not involving any part of the community on their ideas?
Sometimes people just want to debate the idea first, before going through to the actual request, even though they may present the idea as a suggestion.
I´m pretty sure, if we all stood together in a specific matter, a suggestion would probably be reached more positive, (more seriuos) by the developers when filing the final request, rather than one individual personal requests. Thats where the commnuity (forum) come in hand, and can become very powerfull and benefit openhab! You should not try ruin or ignore that part.
All this is not only pointed at you Rich… Its an request to those who´s acting up each an every time someone mention an idea/suggestion.
Bang! 
Kris didnt!!
What you tend to read as complaints, I read as suggestions, ideas, whishes to make things become better/easier for all, based on an experience from an individual person. Dont pick on him, because you dont wish the same, have a need of what he´s suggesting, or even have the same experience.
And please, as Matt just wrote…
When you do, you kill the idea as well as kill the passionate user, which in time will kill openhab, leaving you with absolute nothing.
Maybe thats what you want, but I´m sure, the rest of the community, developers, maintainers as well as the foundation do NOT share your idea!
Its unfortunate that both the idea and my enthusiasm for openhab after this is very much tarnished. What some people think is a selfish request for ME was actually a suggestion to benefit all by the number of posts I see in similar issues. Any way I’m over it. Carry on.
We are now 45 posts into this thread. Are we any closer to any sort of resolution? Is anyone going to work on this?
I’m willing to do what I can to make the 2.5 MQTT Event Bus simpler if I’m given actionable suggestions. I’ve asked for suggestions more than once on this thread. I’ve also defended the need for this feature. But so far all I’ve got is “that’s to complicated, it uses yuck icky MQTT 2, Rules are too hard”. No actionable suggestions for what I could make simpler. No recommendations for what could be improved. Just “it sucks and needs to be redone.”
You all have rejected the considerable amount work I’ve done to address this problem in its entirety without even the decency to suggest what I could do to make it meet your needs better. I think it’s a rather elegant solution frankly and it works fantastically well and I’ve explained why I can’t figure out how to make it simpler. So again I ask, who do you have lined up to replace what I’ve done? I did the best I can and you all reject it out of hand. My best isn’t good enough for you to even make suggestions for improvements so I sure as hell am not going to work on replacing it. That won’t be good enough for you either.
As for the people arguing against the requirement, they have a point too. Federating multiple OH instances should be a little hard. You have to understand how OH works, how updates and commands are processed, and be careful how to configure the pub/sub for individual Items or else you end up in infinite loops very easily. Once you do have this understanding, setting up the Event Bus isn’t all that hard. But I can’t give you a short cut. You have to understand these things. But since I’m clearly wrong, who is going to work out the technical details?
Regarding Kris´s suggestion, no. Regarding the attacks on him, hopefully this has come to an end!
I can only supply with ideas, since I´m not a developer.
I know you are, Rich!
Working/optimizing the MQTT event bus is a very good idea. But I do not feel certain enough about MQTT and rules to help you in how to make things more clear and easier. And I just dont see this as your job teaching me MQTT and rules through the event bus, but insted me who needs to step up and learn MQTT and the rules alot better.
Question is - Is an event bus/linked systems suppose to have this kind of requirement?
You do have a point in the user would need to know some basic stuff when dealing with a server/client system, like the Velbus way I mentioned. A simple thing as having each systems updated to be using the same basic setup (binding in this situation). But thats really isnt rocket science, at least not regarding Velbus. Stuart have done a great job with a very little script for keeping the systems up to date in an very easy way…
But the Velbus example is just a small brick in the pussle of openhab. It´s probably alot easier when only dealing with that brick only.
I would never reject any of the work you have done. It has never been my intention to even indicating such a thing. I´m very sorry if thats the impression I gave you.
I know you worked very hard for this and in general here on the community. You do this for the right reasons. And I know you´re highly appreciated among several users in here, including me, because of your help all the time.
Then question is - which requirements do you feel the MQTT Event bus should have? Which users are you targeting? Which users do you want to target?
Would you be able to do the same, targeting new users, or users who dont know MQTT and rules? Would it make sense? Or would that require totally different way of doing an event bus?
Thats probably the best way I can answer your main question, while not having enough experience on MQTT and rules, yet. I know there are lot of question in my answering, but I can only see this with a very limited experience in whats really matters. I wish my situation were different.
It’s not a requirement but given the technologies OH supports, MQTT is the most appropriate technology to use for this.
The user of such a system must fully understand what happens when an Item receives and update verses when it receives a command (this is the complex part).
The user must understand Items and how to add Items to Groups.
The user must be able to install bindings.
The user must be able to configure the MQTT binding or at least be able to follow the step-by-step instructions (complete with screenshots) using PaperUI (if you want .things files you are largely on your own) that covers all those steps.
The user must be able to copy and paste Rules code or if using Scripted Automation Community Contributions to the Helper Library (maybe someday which will be install able as an add-on). The Rules work as written, there is no customization required.
Except for specifics about MQTT, and requiring a deeper understanding of updates and commands, there is nothing in that list isn’t required of all users of OH. And for the deeper understanding of commands and updates and specifics for MQTT I tried to cover through extensive documentation.
Intermediate to advanced users who know enough to justify the decision to run more than one instance of openHAB. openHAB is hard enough to learn for new users to greatly complicate things by trying to run more than one federated together.
I agree with several on this thread, new users should not be doing this. If a user can’t copy and paste some Rules, they don’t yet know enough to assess the implications nor deal with the complexities involved with running multiple federated OH instances. It’s far too easy to end up with an infinite loop. the additional complexity adds greatly to their already steep learning curve.
I don’t think it does make sense. Because ultimately you need to know when to duplicate an event on one OH instance on the remote instance and when to duplicate a command on one instance on the remote instance. And knowing when to do which requires a nuance of understanding that many experienced OH users even now struggle with. There isn’t a blanket “always publish commands on one instance and always publish updates on the other” configuration. The user needs to pick and choose and choose correctly.
One of the great limitations of the 1.x MQTT Event Bus is that it only provides a blanket configuration. All updates to all Items get published here. All commands to all Items get published there. All subscriptions for all events is here. All subscriptions for all events are there. Such blanket configurations do not work for all use cases. And any Event Bus configuration must work for all event bus use cases. It supports just a couple of relatively simple use cases (e.g. reporting all the sensor readings from a remote OH instance, only supporting commands that match the Item’s state (e.g. you can’t reliably sendCommand(INCREASE) to a Dimmer)).
No matter what technology is used to actually send the messages, this is where the challenge lies. It’s the fact that not all commands can be processed as an update.
If instead of using MQTT this were a binding that used the REST API and websocket this complexity would not go away (not to mention that only commands and changes get published to the websocket I think so you couldn’t really reliably set up an event bus without changes to how that works anyway). Configuration over all could be slightly simpler but only moderately so.
Having worked on this and spent a huge amount of time thinking through all the angles, it is my assertion that what I’ve done with the MQTT 2.5 event bus is as simple as is possible to achieve in OH 2.5 that handles all the event bus use cases. I have high hopes that installation and configuration may become a little easier in OH 3 but won’t know that until OH 3 matures a bit more. Perhaps once OH 3 comes out and more people have a need for the event bus to support 1.x bindings we can make the installation and configuration of the Rules and connection to the openHABian MQTT Broker automatic (Marcus probably wouldn’t like that) but that doesn’t really address the root of the complexity. It’s like turning off the lights to save energy when 90% of your energy usage comes from the heater. And setting up MQTT to do this is really pretty simple. The steps are pretty easy to follow.
Maybe you could go through the steps on the link and provide feedback on what I can make more clear or perhaps automate some more. All I have from this thread is:
I can’t do anything with that.
If you do, please comment on that thread.
The first point is hopefully what you (we) want to archive 
The second point is useless…
The third point is the troubblemaker, in my opinion.
Before I go and mess up the thread of the MQTT Event Bus tutorial, I´ll do a comment here, which will explain why I find the MQTT Event Bus is a problem.
MQTT is a hell, in my opinion. Its far from clear exactly how to install it. It has been a total mess for long, with lots of issues and hickups as vel as confusions. Noone seems to know exactly what broker to install, and how. Mosquitto (from openhabian-config) is no longer maintained (as far as I read somewhere not long ago). The embedded broker fails for many. And even when you try to get started with MQTT, you end up with a list of MQTT addons, which requires you to already know, to be able to distinguish them from eachother.
This is what happens when entering the addons directory and searching for MQTT:
Given you have no idea of how to install MQTT. All you want is to have a bus running between two OH systems. Is this what should be presented to you?..
To me this is a problem, because…
There are more than one MQTT binding, two of them even look the same and are named the exact same!!!
There is a MQTT actions and MQTT persistence. (Whats that? All I wanted was MQTT) There is a MQTT broker, and last there is a blue ikon of something just called binding. I have no idea what it is.
Reading the text below just makes things worse… Nice to know that the mentioned things are covered by the MQTT binding. But which binding is covering that? What the he*** do I need to install.
So before I even get started, I´ll need to figure out which one to install…
I turned to the docs insted. The only place I found something regarding MQTT is under Persistence Services…Well, at least now I know what MQTT Persistence binding is…
And thats it… No more about MQTT in the docs, (except when searching I end up in the bindings again).
Lets try the forum then…
The forum is filled with tons of posts with issues regarding MQTT and it didnt make things better when MQTT went from old setup to new setup. Now, I need to find those without issues.
I tried a search for “How to install MQTT”, only to find tons of tutorials of how to install from a specific device or people having issues, and even more posts regarding installation of V1.
This is where things gets highly complicated, to me!
I know, this has nothing to do with your MQTT Event Bus. It´s not your fault, and not you to blame.
But in order to use your event bus, you (we) have to face the fact, that the requirement is an issue. That mean, any problems regarding MQTT will becomes a problem for your event bus, just as well.
I promised you some help and suggestion… I´m not sure if it really belong in the tutorial thread… We can move it afterwards if you really want to…
You need to read my suggestion in the best manner. I dont want to sound like I blame you, cause I really dont. My idea is to start from the very beginning of the tutorial…
“How to get started with the MQTT Event Bus”.
You have mentioned a few times its piece of cake installing MQTT. What will happen if you did cover installation of MQTT, or a link from your tutorial to a working tutorial of “How to get started with MQTT”, (if it exsist).
A link to a broker and a binding could become handy as well.
Since there are more than one broker, maybe an recommendation in the tutorial, of which broker to use, with focus on the Event bus only ofcouse. As far as I understand, not all brokers are alike.
Maybe also covering the situation of a user who already do have MQTT installed on his “main” system… Whats required on the “remote” system… I read you´re tutorial a coupple of times, but this part is quite unclear to me. Maybe its due to I´m struggling understanding MQTT as well.
These are just my suggestions of what could make it easier to get started with the Event bus, taken from my experience.
This post sums up why its hard, exactly. Well done Kim!
Thanks Kris… But its one of these post I really wish I didnt have to make.
Have you actually tried any of this yourself? Or have you just read threads on the forum which is going to provide a negative impression for any binding because only people who are having problems post about it.
Installation is pretty straight forward.
Install an MQTT broker. Contrary to what you remember reading, Mosquitto is well maintained and is the broker that pretty much everyone uses, not just with OH but across all home automation systems and openHABian still supports it and does so very well. It’s Moquette, the embedded broker that appears not to be maintained any longer and I expect sometime soon it will be removed.
Install the 2.x binding. There is only one in the list in PaperUI.
There are multiple pages of docs because the binding supports multiple modes of use and each mode was written up as a separate document which messes up the search. When you look at the list on the left, and in PaperUI there is only one.
Deprecated OH 1.x add-ons that are going away.
Just the two steps I list above. If using openHABian, select Mosquitto from the list. If not sudo apt-get install mosquitto. Then select the only MQTT 2.x binding in the list of add-ons in PaperUI.
You don’t find anything about any specific binding in the docs. Do the same search for Zwave, or KNX or any one of the other very popular bindings. Information about bindings are in the binding READMEs.
It seems to me that it only got really complicated because you didn’t just look in PaperUI. There is only the one in the list. No confusion there. The confusion between Moquette and Mosquitto will go away, The problem is that it works just fine for some users and it’s a pretty significant breaking change to yank it away without warning so I wouldn’t expect to see Moquette to go away until an OH 3 release. I’ll file an issue to discuss it with the developers.
Regardless, I will add the two paragraphs max required to describe these two steps to install and configure the add-on and the MQTT Binding Thing.
Not through PaperUI… because of two reasons.
As said - This is very difficult for me. I made the typical “mistake”. I followed a guide, it worked, and I dont know why.
Since then I really have tried to get an overview of this, but as mentioned, there are limited useable docs available, and the forum is filled with tons of post with issues and problems. The only thing I know for sure is, that I have a broker running, and there is a connection between openhab and my few Sonoff (tasmota) devices. It works… Everyone is happy… At least untill I have to make any changes, then hell starts all over. MQTT is actually one of the reason why I´m still on openhab 2.5.0 (stable). I read the release notes, and if something has changed regarding MQTT, I leave my system as is, at least untill I get my head onto this.
I get the basic idea of MQTT system from a server/client(s) point of view, but thats where my knowlegde stops. Everything around topics are still quite confusing…
I know, thats my situation and I have to step up to learn.
Unfortunatly somebody forgot to mention, from where, and how 
As just mentioned… I found Mosquitto as a recommendation on the forum by coincidence. I wasnt even aware of a MQTT broker in openhabian-config, (or at least didnt pay attention to it) untill I had a need to install MQTT.
Not really… At first It got complicated because I followed a guide, not knowing what the heck I was doing.
When trying to figure it out, I took the most obvious way, by using the docs. That didnt help. When that part didnt help, I turned to the forum only to discover the massive bunch of posts, which unless I hit the one and only, wouldnt do much good either…
To me, this could have been a bit more easier, if there were a doc or something beeing easily found. But I understand you do agree, there are no docs, and the forum is useless… Then whats left… PaperUI.
The Binding in PaperUI doesnt really help much. It links to external pages of the brokers, and even worse, it mention the embedded broker, (which is no longer there or will be removed, as far as I understand). This is a small quote from the first few lines:
A server, also called broker is not provided within this binding. You can use any of the freely available MQTT Brokers like [Mosquitto](https://mosquitto.org/) or [Moquette](https://moquette-io.github.io/moquette/) or install the [included Moquette broker](https://www.openhab.org/addons/integrations/mqttembeddedbroker/) as add-on.
But the best option for openhabian users is actually as simple as just use openhabian-config, right?
Unfortunatly, thats not part of the choices. And no where easily found.
I agree, its not easy to remove something many users are using. And it actually dont have to be remove in a long time. But when it has been decided to abandon it, its highly important not to mention or recommend it…Which you can see from the binding, isnt really the case. Its actually mentioned two times in that quote I just gave 
I really do believe it could help others which may find MQTT scary. So its highly apreciated from me.
But I also acknowlegde, the MQTT installation doesnt really belong in that tutorial… It should be covered in its own, and then you can link to it.
Your benefit by doing it yourself is, you dont rely on others and their doings (fuck ups) in your tutorial
I’m not the only person on this forum who can file an issue to recommend changes to the docs.
I reworked the tutorial to include step-by-step-by-step with lots of screen grabs covering everything including installing the broker, configuring the broker, the binding, and all the Things.
I welcome constructive and actionable recommendations on that thread.
Whether you (the generic you, not you personally Kim) like it or not, that will be the only way to federate OH instances unless someone (not me) implements it some other way. Is it a lengthy tutorial? Yes because I fully explain everything. If I removed the explanations it’d be very short:
One very recent option might be the finally working direct connection from OH via RFC2217. See this thread [SOLVED] [Zwave, Zigbee, ...] RFC2217 remote serial port HowTo? - #30 by wborn
I’ve already linked there a couple posts up.
But I merely got the impression that most people on this thread are not interested in real solutions to real problems…
True, and I dont expect you to do it everything in here, (even though I know alot of people would probably enjoy it, because they consume all your doings with great appreciation)…
This was just to show why things sometimes gets confusing, and perhaps why lots of people end up with issues and problems regarding MQTT.
I´ll take a look later.
Explaining whats going on in a turtorial has a great influence in understanding whats going on, and be able to do changes later without the need of another tutorial… I know, because specially regarding MQTT I made the stupid mistake of following a guide, which didnt explain… Now I have a working MQTT system, and I dont know why 
If something breaks, I will have a huge problem recreate it. Doing changes is out of the question… I really cant recommend doing like me in general.
The backside of explaining is, like you said, the length… But I´m sure those who really has the interest wouldnt mind the lenght, due to the positive effect they will gain.
Question is how the explaining is beeing presentet. If the users dont understand it anyway, it wont make a difference. But I would rather prefere explanations than none.
For sure if you are serious about security, you do not want to use any cloud…of any kind
I been told to take a look on this topic and to be fair - it is terrifying to me what happened here. We have someone who brought an idea how to improve user experience. He clearly stated WHAT problem he has and WHY existing answers do not satisfy him.
I get that such a request was repeated number of times but doesn’t it trigger a bell for you? If multiple people ask about similar thing over and over and they struggle with same problem, maybe it is a time to consider that as a missing feature and not an anti pattern?
We need to acknowledge that OH might not be perfect and some things could (or should) receive an improvement. Let be less religious about the project. If we will keep shouting on every “non allowed” idea, soon we will be alone at this forum. Without newbies, who we could teach and who could help. Eventually if they become contributors they will help to drive things forward.
