Suggestions for OpenHAB

61

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.

62

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
63

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.

64

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
65

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
66

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.

67

I’ll summarize:

  1. 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.

  2. 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.

  3. 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.

68

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.

69

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
70

I have now :smiley:
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.

71

That’s bass-ackwards for smarthome system. Our system or server would want to issue commands to remote devices. and receive states or status from remote devices or services.
Getting that the wrong way round would indeed make MQTT configuration a confusing thing.

We have exactly the same conversations about other technologies.
“Modbus is hard to use!”
Yes, it is. If you don’t have a rudimentary grasp of what’s going on, it is practically impossible to configure the openAB binding.
“Then we need a Modbus primer!”
The web is full of them, making another is wasted effort.

Find out roughly what it is you are trying to achieve with Modbus, You don’t need to be an expert. This part is not openHAB specific.
Then, previously baffling binding settings begin to acquire purpose.
Of course there is always room for improving the bindings ease of use and docs, but don’t waste precious effort reinventing readily available wheels.

2 Likes
72

As far as I understand, the MQTT broker (server) only pass through whatever messages (topics) beeing added to its subscripers. MQTT broker do not command anything.
But…

When using words like server in this particular case you need to be very carefull, cause:
MQTT broker is a server.
Openhab is a MQTT client. Openhab is a server too, but not regarding MQTT. It can however run the MQTT broker, which therefore makes it a MQTT server and a MQTT client.
MQTT devices who are setup in openhab as things are MQTT clients. Openhab is a MQTT thing as well.
If you split these terms (server and clients) into each physical machines/devices, it makes alot more sense.

You´re right the situation is close to the same regarding modbus. Maybe much of the could be used in a upcoming teaching/tutorial for modbus as well. But lets stick to one protocol at a time.

I will try to explain how I understand MQTT in basic and where I lost it.
In another thread/tutorial it can go deeper in a try to actually makes things more understandable for anyone from even more specific situation, with screenshot etc… But I cant participate unless I feel cormfortable with MQTT myself… My hope is the other new thread will become somekind of tutorial/teaching MQTT untill a certain stage (not most advance use). Targeting openhab use.

But first lets me put some identification on the terms insted and think of them as individual physical devices/mashines: (remember, this is MY understanding. And I may be wrong somehow).

MQTT broker (the server)
MQTT client1 (some MQTT device, lets says its a outlet plug).
MQTT client2 (Openhab)

Client1 can send status update (topics as far as I know) as well as receive commands (ON/OFF).
It can not receive updates or send commands. Its in this case just a simple device.

Client2 can receive updates, as well as send commands.
(Client2 can send updates as well as receive commands as well, but its not important in this particular situation, since Client1 cant use updates from Client2, and Client1 cant send commands to Client2).

MQTT broker deal with all the messages (status and commands) and pass them through to where they´re suppose to go depending on subscripers and their topics.

What I want to archive is how to understand and configure:
Openhab to receive status updates of the outlet plug as well as beeing able to control it (switch it on/off):

As far as getting status updates from Client1 to Client2, this is easy enough (for me).
Client1 connects to the Broker, adds a topic which contains the information of status update.

Client2 connects to the Broker as well. Client2 subscripe to the topic of Client1.
Now the Broker will pass through all the messages of the topic from Client1 to Client2 whenever its updated.

Summary first part:
Openhab now receives the status of the outlet plug through the Broker.
To me this is very simple and understandable. I have no issue understanding this part (I hope).

But I wanted openhab (client2) to be able to control (switching it on/off) the outlet plug (client1) as well.
This is where MY knowlegde ends… I do understand there has to be a command topic somehow, and the Client1 will have to add this to the broker. (It may be part of the original topic). But exactly how client2 (openhab) is suppose to be set up, ie which topic/channels etc, and how to send the command, is very unclear for me. And to my understanding, this is where alot of people fail, simply because there is a lack of documentation somewhere which explain how to and specially why.

Again, remember, this is my situation and my case… I may have got all this wrong, and I may have missed some information somewhere… But I do have tried quite a few times.
I made a terrible mistake in using a finshed setup which I found in the forum from a specific device I have. This is where I ended up. My devices (almost) works, and beside the status update, I have no idea why.
Whats not working is the actual control of my device from openhab, because there were no teaching/information in the eaxmple I used. And the setup part for controlling this device fails.
Fortunatly, in MY situation, I really dont need to control my device. Its a Sonoff POW R2 (Tasmota firmware), which is used for power monitoring only. But it could have been a user who wanted to control it. Thats why I picked the situation above.

Really hope this makes just a little sense and shows where/why I believe things are becoming difficult to understand, and maybe what could be done to make things better - from an openhab user perspecitive!

73

@Kim_Andersen

You’re almost there, but before I (or someone else) try to help you understand it, do we want to discuss this inside this topic/thread though, or should you open a separate topic?

1 Like
74

Thanks Jim. I´m glad you´d ask :smiley:

Help (explanation/teaching) in general is exactly what I want to be in a new thread, which will focus on: explanation, how to and why…
The goal is to get the basic understanding of MQTT so anyone with interest in MQTT, knows exactly, how MQTT works, and will be able to set it up to be used with openhab in a readable, easy and very clear understandable way.

I´m still thinking how to start this new thread exactly…

The reason I wrote my experience was because this thread became a thread about the difficulties in MQTT and why the Event Bus is a problem. None of it actually belongs in here from OP´s original post. So we need to filter out the useable stuff into the new thread, somehow…
Maybe Rich (who have done lots of great turtorials) have an idea.

So to answer in short - Hold on with your help for my particular situation, at least for now, untill we (I) have an idea how to use it in a the (hopefully) new upcoming thread. I really do appreciate your help though. But, if I´m able to use this new thread to solve my problems by myself afterwards. We have succeeded in some way I would say.

Does this make any sense?

75

That link Rich gave you is a very good one. I too learned from that same page when I first encountered MQTT about a year ago.

  • Understanding of how mqtt works
  • Reading the OpenHAB MQTT Binding documentation about how MQTT is used in OpenHAB

should get people up and running with it. That and a little experimentation and trial and error.

Don’t overthink it. Just copy paste what you wrote in the previous post and start a new topic.

76

I been thinking about the problem today and I am not sure if we even need a MQTT. It should be sufficient to use HTTP api of openhab to push states and commands between instances.

Another idea which come to my mind is implementation of rfc 2217 server which would solve the problem with ser2net setup and assigning of constant port ids.

Best,
Łukasz

2 Likes
78

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.