Thanks Kris… But its one of these post I really wish I didnt have to make.
2 Likes
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.
1 Like
1 Like
Not through PaperUI… because of two reasons.
- Long time ago (at least too long to remember eactly what I did) I installed Mosquitto. As far as I remember, I installed it through openhabian-config, cause it was recommended to use Mosquitto and install it from openhabian-config. At the time I think that was the only way. But I´m not sure.
In paperUI I have the binding installed as well. Under service section I have a MQTT manager. I have no idea why and what exactly they´re doing. I probably installed the binding, and the service came along… (wild guess). In my things I have a mqtt broker thing. This is the mosquitto broker connection, I believe - Since 1, I havnt touched it. It works, and I dont know why. But know, when things are working, dont try breake them. I still have no idea what I have the binding installed though… Probably some of the mix up with fromt embedded, which I also tried, and maybe havn´t cleaned up well enough.
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:
- setup and configure MQTT
- copy the rules as written
- Add the two Groups. Add the Items you want to share to those Groups
- Create a trigger Channel on the MQTT Broker
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.
8 Likes
No IMHO he didn’t. And at least to me his explanation in turn is not satisfying either. He is unwilling to make use of the MQTT event bus solution because he tried somewhat but failed.
Granted it’s cumbersome and noone wants to take on complicated setups or even admit he’s not clever enough to get such a setup to work. But that alone does not make the proposed alternative a good suggestion.
What easily gets overlooked is that this is the nature of the problem that the OP wants to address. That means that any other solution such as the incriminated master/slave he aims for will be more or less equally cumbersome and complicated because it has to address and take care of all the complexity of OH on functional as well as on code level. Maybe that just isn’t obvious enough at this idea-only stage.
It’s a little bit like the flowers in your neighbour’s garden. They look pretty from a distance but make you forget it takes a lot of work, dedication, patience and more to grow them.
Let alone that any master/slave solution such as the one he wants is overkill if it really was about solving the original problem only … ser2net and the new rfc2217 feature I referenced are simpler, safer solutions to the original problem as well. That makes the master/slave proposal an unneeded, unnecessarily risky one.
Yes, if that was the case. But there are not multiple people asking for master/slave - only the OP does. He tried to turn up the heat to make it sound a widely-wanted and -welcomed idea, but the references he gave were about a different problem that does not require a master/slave feature to get solved. The OP is mostly on his own with his assessment. Carefully read the full thread again if you don’t believe.
Sure. I don’t think anyone here has a problem with doing that when it’s for the right reasons
But when OH does provide solutions (multiple ones even) for a task, this is not the appropriate place. (and remember we’re also just users not the devs who could feel blamed).
We don’t. We just say this particular idea is not a good one because
- a number of experienced people disagrees
- it’s not needed, there are features available to accomplish the very same thing
- it’s painful and risky to implement
- there’s no developer willing to take on the work it takes
- even if he did it would mean a wasteful allocation of precious developer resources better spent
elsewhere in OH
Eventually. But the only two to advocate for this made clear they are no developers able to contribute to code. Maybe if they were devs they’d have a more realistic view on the downsides of the proposal.
I also suggested anyone without dev capabilities but willing to contribute can still set up a bounty but seems noone is interested so far.
Actually, I would count myself as an advocate for this approach. I never once argued there wasn’t a need for it. And I did provide an approach to solve the problem (the 2.5 MQTT Event Bus). And thanks to constructive feedback from Kim I was able to improve the write-up to make it easier for less experienced users to follow (I hope).
@splatch, my main sense of consternation was OP simply rejected my attempt to solve this problem out of hand. “Too complex, I prefer MQTT 1.x” is about as close to constructive feedback as it got. The original post implies there is not now a solution to the problem. When pointed to the solution the feedback was “too complex.” When I explain why that complexity is there and why, in my experience, it cannot be eliminated my explanation is flat out ignored.
As far as I’m concerned I have solved this problem already in about as simple manner as can be managed given how OH itself works. And I explained above why it can’t be made simpler. “Bring me another rock!” shouts the OP. Well, I won’t do it. I did my best but my rock isn’t pretty enough. Someone else can haul a rock from the quarry and see if that passes scrutiny.
I can’t speak for anyone else on this thread. But this is my perspective.
1 Like
That’s a misunderstanding then. I didn’t mean to say there’s no need either.
What I meant is there’s no need for yet another master/slave implementation because your MQTT event bus does the trick.
Personally I think it’s a good idea. I think the bigger question is not if there’s someone who could contribute the code, but if the code would actually be allowed. It’s actually extremely difficult to get significant changes contributed to openHAB.
2 Likes
Just to clear a few things up, because clearly words are being put in my mouth
Wrong. I never said this
Keep your personal insults out of the forum, you just look unprofessional.
Rich, the ‘solution’ of MQTT 2.5 is EXTREMELY complex. The forum is littered with hundreds of posts of users struggling to get it working. Note I said MQTT 2.5, NOT the event bus. The event bus relies on an underlying complexity that quite frankly is a pig. The documentation is sparse/non existent. Evidence of this is clear just doing a search on the forum and reading Kim’s post above. Whilst your solution I grant is great, for someone setting it up from scratch to link two openhabs is expert level.
I’ve never thrown rocks thank you, just offered some friendly suggestions which clearly are taken out of context but the select few.
1 Like
Now you’re putting words in my mouth. I completed your citation. I didn’t say or mean to say you are not clever enough. Just that nobody including myself wants to feel like that. My apologies that you felt insulted, that was not my intention but I’m not a native speaker.
I’ll summarize:
-
There is no currently existing mechanism built into openHAB that can do this job except MQTT. The web socket only publishes changes and commands, not updates. Someone could write a binding to support some other messaging protocol but it won’t end up being any simpler. Before I wrote the tutorial, discussions among the maintainers were looking to use MQTT for this job because MQTT is the right technology to use. This is the sort of thing it was created to do.
-
The reason that the MQTT 2.5 Event Bus isn’t built into the MQTT binding itself, as it was explained to me, is because bindings are not allowed to sit on the event bus like they were with 1.x version bindings. This is a policy decision from the core maintainers. So unless and until that policy is changed, there is no add-on that can provide this capability. It would either need to be a core capability or the policy would have to change. And given 1 above, that some sort of messaging technology is the right tool for the job, it really doesn’t make a whole lot of sense to add it to the core as you wouldn’t want to tie the core to any specific messaging protocol like that.
-
I added to the tutorial everything a user would need to install and configure everything needed to make it work. Which broker to install and how to install it (multiple different ways for both Windows and Linux), how to install and configure the binding, and how to create and configure the Things. You no longer need to know or gather information from anywhere else but that one tutorial. No longer is there any assumption of any prior MQTT knowledge. Someone should be able to start from no knowledge of MQTT and have the event bus set up and running from this one tutorial now.
The updates to the tutorial do not include .things files though. When you search the forum for MQTT problems, 90%+ of those posts are because people are fighting with the .things file syntax. That’s less a problem with the complexity of MQTT than it is with people making assumptions about how .things files should work.
Anyway, I welcome any constructive feedback on the tutorial for anything missing or ways I can make it simpler I may not have thought of. It’s long but that’s because I try to explain everything. But it’s also not a generic MQTT tutorial. It only explains just enough to get the Event Bus up and running. But it’s thorough in covering that just enough and it no longer expects any knowledge beyond openHAB basics.
Thats the next step in all this, if MQTT is ever going to be used as its really meant to…
Shot note…
I have read about MQTT quite a few times. I understand the basic concept and its advantage. Its a server with clients subscriptions, who suscripe to available topics. MQTT is very powerfully, use very little resources, and its fast as hell… Thats why millions of IoT devices uses MQTT…
Thats basicly what I know. I actually think it was an Australian guy (Superhouse) who has a very good (but short) video explaining the concept of MQTT, which originally got me interested in MQTT.
As a background in server administration, (Windows, mail, web and sql database). I know the concept already, beside the part about subscriptions to topics. But when it comes to MQTT, things simply wont fit in my head, for some reason… Maybe I´m just getting too old for this… And its killing me, because I believe MQTT should be alot easier to get, at least in its principal manner. And way more easier than a Windows server, mail server, DNS server etc which I´m was used to some years ago.
When I saw Rich´s changes to his event bus, I was very pleased, because lots of the struggle with MQTT is actually installing the damn thing, (at least here on openhab). That part has been eliminated now. But MQTT in its general manner is way too confusing, specially since it changed from V1 to V2. The forum is a very bad place to seek any help. Its filled with tons of posts about V1, and yet another ton regarding how to get from V1 to V2 and its troubble. The docs are no good either. And the reason is a bit logic, cause users wont learn MQTT from the docs of openhab. In those docs (mainly binding) you will learn to use it, from a openhab devices aspect.
This means, to actually learn MQTT, one will have to look outside openhab. At least how it looks rigth now…
With Rich´s changes, installing and setting up MQTT has become alot easier. But it wont help much in understanding and getting used to MQTT. That part needs to be taken care of, elsewhere. As I have said before, I will not expect Rich to teach the users MQTT through his Event bus. Thats not where its suppose to be. MQTT learning has to be done from else where. If not through openhab, then somewhere else. Rich´s changes is a big step in the right direction, in my opinion.
I still believe a build-in master/slave (server/client) system would be a great feature in openhab. Wether its through MQTT or another protocol doesnt really a matter. What matters is, its beeing easy to understand, setup and use, and ofcouse working as fast and realiable as possible. Thats what really matters. Server/client in its principal manner is not for expert users only. But it do (and should) require some knowlegde and experience ofcouse.
Untill we see such a solution in openhab (if ever), maybe we should focus on gettting the general understanding of the Event Bus optimized as much as possible. And maybe we should focus on getting the MQTT understanding better descriped. (This will require some one who has the knowledgde and the time to actually make something really usefull). Or maybe start with the focus on MQTT and then the Event bus afterwards, if its needed at that time. Then all whats left in the Event bus is the rule part, which is the third and last step, and like MQTT will require some knowlegde as well.
These are just suggestions based on my opinion, that a server/client system do have lots of potentials in a smarthome system like openhab. And I´m certain, the easier it is to get, setup and use, the more it will be used by the users.
Have you looked at the HiveMQ tutorial? I find it to present a good explanation of all the core MQTT concepts.
I’m happy the changes helped.
One of the big problems with the MQTT binding is that it’s a relatively low level general purpose binding. It’s hard to use all such bindings (Exec, TCP/UDB, Serial, HTTP, etc.) because their general nature means they have to support too many use cases. What if my device sends “75 degrees F” and I want to put that into a Number:Temperature? What if my device only speaks { deviceid=123, status=7 } to turn on the switch? What if my device publishes red, green, blue and I want to use a Color Item? The binding has to handle all of those cases and more and as a result there are lots of options. Lots of options make for lots of choices and the feel of complexity for less experienced users. If the MQTT 2.5 binding is more complex than the 1.x binding in this respect, it’s because it handles far more such use cases, i.e. it’s much more capable.
I think, as a general rule, explaining the ins and outs of how a specific technology works is considered out of scope for OH docs. The Exec binding isn’t asked to fully document how Discretionary Access Control work on Linux file system and Windows file systems or all the options for sudo (the most common source or problems for people who try to use Exec and executeCommandLine). The HTTP binding isn’t required to reproduce all the IETF RFCs that define how HTTP works. Zwave isn’t required to explain everything there is to know about how Zwave works. Similarly, I don’t think it’s OH’s job to fully document the basics of how MQTT.
Hopefully, to use the event bus, you don’t need to know this stuff either. Just follow the instructions and it should work. If it doesn’t, ask for help. But if you want to extend beyond the event bus and automatically discovered devices (Homie, Home Assistant), you’re going to have to learn you some MQTT.
Think about it using this simile. The MQTT Broker is like the SQL database. The MQTT publisher is like the software that issues INSERT commands on the database. The MQTT subscriber is like the software that issues SELECT commands on the database. The topic is like the table/row/column where the data is stored.
The difference is MQTT has only the one value and the subscriber has a standing query so any new values are automatically and immediately received by the subscriber rather than requiring the subscriber to request the data with a pull.
1 Like
I have now
It is indeed usefull, though I already knew most of it.
But my problem is more related to openhab/setting up the actual client subscriptions and the topics, which is where I simply fail to get the idea…
This should not become a thread of “learn MQTT”. I do really appreciate any effort, advices and suggestions you´re given me. But maybe we should start as new thread, (which perhaps could lead to an actual tutorial of, how to understand MQTT topics, subscriptions, pulisher etc. which I gladly would participate in, whenever I feel comfortable enough to add to it). I can start a new thread by posting an example of where things goes wrong in my head. I´m almost certain there is a logic explanation somewhere…
I understand that. But if we could just get it down to some basic use, (ie sending states/receiving commands) which would be the most obvious use in a smarthome system.
Normally I would agree with you. But on the other hand, if openhab/community can do it, it would benefit alot of openhab users to become more comfortable with MQTT insted of their struggling.
Which is why my suggestion is to try make a small doc/tutorial/whatever about MQTT from its basic use in openhab. I know there will be some advance using as well. But I dont feel that part is needed. Just basic use… After that, I´m sure the event bus will look as a piece of cake for everyone, regarding MQTT that is.