Having it in addons.cfg only controls whether or not it gets installed. If you have it listed in addons.cfg then the broker will be installed. If you try to uninstall it from PaperUI, it will get reinstalled because it is listed in addons.cfg.
I don’t know whether or how to configure the broker using a cfg file. @David_Graeff, is it possible to configure the embedded broker using a cfg file? If so what should it be named and is there anything written anywhere listing the parameters? I couldn’t find and README in the docs for the embedded broker.
Hm. I know that half of the audience will have strong feelings after reading this response:
The embedded broker is configured via Paper UI in the Services section.
Every option listed in Paper UI can also be configured via .cfg file. That is how openHAB works.
But: I will not document those key/values in the service documentation, because they are implicitly documented in the service xml file.
There was the plan that those .cfg file sections are auto-generated for each service and binding.
I thought is was more than a plan as ever since 2.0 a stub for the cfg file used to be created when the binding gets installed. I think that may no longer be the case as I don’t remember a nest.cfg file being created when I installed the Nest 2.x version binding.
So where is the service.xml file? How do I as a user figure out the key/value pairs to put in the .cfg file since it won’t be documented anywhere else?
Nah almost. The file name is irrelevant. The first line is important that looks like this: service.pid="org.openhab.mqtt". I don’t know the service pid of the embedded broker out of my mind though.
That would overrule any settings in Paper UI and therefore isn’t done.
In the openHAB / Eclipse Smarthome repository in the bindings directory under ESH-INF/config. Not for end-users. But end-users have Paper UI don’t they ^^.
My understanding based on experience is that a cfg file that is all comments does not override PaperUI configurations. Has that changed?
Yes but…
We have hundreds/thousands of users who have always configuired bindings in cfg files.
There has been nothing published, mentioned, or communicated in any way shape or form that I’m aware of (and I consider myself pretty well informed on all things OH) telling us that cfg files are no longer going to be documented or supported. Saying we have to go to github to pull out some XML file to figure out what fields go in a cfg file is essentially saying .cfg files are no longer supported.
Look, I’m OK with change. But DON’T surprise us. Don’t just change things without telling us and giving us instructions and/or tools to transition to the alternative.
Right now changes like this look like unilateral choices made without consideration for end user’s expectations that have been established based on years of experience. We must be told these changes. They should be explained why they are changed. And we need to be told how to transition.
Right now, a user who does not use PaperUI at all (may not even have it installed) would have nothing to even tell them there is any configuration possible on the embedded broker. There is no page in the docs that I can find. There is no cfg file. And there is no notification that the cfg file is not going to be supported.
IMHO this is why the users are angry in so many threads. It isn’t the changes themselves but the fact that the changes are just made, they violate established expectations, and they are not adequately communicated.
Personally, I’m OK with all of these changes, for the most part, but my hands are tied helping to back you up and helping the users on the forum because I don’t and can’t know the answers to basic questions like these without going back to you.
But since I’m on the topic of my opinion, I do think it is currently premature to insist on PaperUI only setup and configuration for something like this.
That’s just me And because I’m doing binding development, bindings from me don’t include those sections anymore. They will be auto generated anyhow at some point.
Paper UI is part of the default distribution. If you uninstall it, you are already an experienced user (perhaps from the OH1 days) and you have to go to the repository and find out yourself. It is a burden to create those readme.md sections that often run out of sync with the actual code.
But the lack of communication about it is still a concern, even if it is just your bindings.
Perhaps. An expert OH1 user is not necessarily a developer and able to find that file in the repository. I am a developer (not on OH obviously) and I’m not sure I would have known where to look had you not told me.
It’s a burden to write the readme.md files for bindings too, but that doesn’t mean they are not needed. I’m strongly of the opinion that there should be one for ALL add-ons. Building and maintaining the readme.md file IS part of the development. They should never go out of sync. If they do then it is a bug and a failure in the review process.
Otherwise why make any docs at all? Let’s just drop new add-ons and bindings and if you can’t figure it out go dig around in the source code. That’s not going to work.
Docs are just for explaining the binding in my opinion. It is a failure of the openHAB ecosystem that Things/Channels/cfg are not auto-generated. The review process is already at a high level but no reviewer has time to check in detail if the xml files, the code AND the readme are telling the same story.
And yes I have seen that those run out of sync in my own bindings and other bindings and even ESH extensions. It is a burden. And instead to invest time in fixing those again and again, an automatic generation system should be invented. That would help so much.
And until such time there is an automatic generation system the users are left with nothing. Ignoring the docs because some day there might be or should be something better does nothing for us now, except frustrate and scare away users. I’m all for Something Better TM but I live in the now (i.e. OH 2.4 Release). Future promises of something better doesn’t help me now and without the help now, I won’t be around for the better stuff in the future.
I would. I’d even file the PR. But I’m nowhere near qualified enough to write the readme.md for the embedded broker. I know just a little about brokers overall and pretty much nothing at all about the embedded ones. I can file the bug but don’t see the point if I’m the only one who will work it.
Just to see what I’d be in for I installed the broker and went to configure it. I see the usual standard parameters which are pretty self explanatory. Then there is “Add Parameter” which gives me a Name / Value pair. Where am I supposed to go to figure out what can be put there? Even experts need something more than Name and Value.
You mentioned somewhere that you are using an embedded library for the broker. So then at least put a link to that library’s docs somewhere in a doc or on the config page or something. That is perfectly fine and very much in the DRY approach to OH Docs.
Otherwise why bother with having the expert config in the first place? No one can use it without documentation. Can this embedded broker handle standard MQTT things like ACLs and such? Who knows? There is no way for users to know and no hint for where we can look to find out and certainly no hint what the parameters would need to be.
That is a Paper UI quirk. Don’t ever click on that.
There is an “advanced” button, you will see all parameters, but never click on the “expert” mode or “add parameter”. That is really just useless.
I’m using Moquette. But as a library, correct. So every parameter goes through the openHAB config system and only those that I handle are handed over to the broker. And all handled ones are available in Paper UI or via .cfg files with the key seen in Paper UI.
Yes it can, but I don’t provide any way to configure this. So for the end-user it can’t.
If only I had a document somewhere to tell me that.
Is there an issue open to fix this quirk?
So just the five parameters are supported.
Here is something else that would be nice to read before wasting time installing and using the embedded broker. What if I want ACLs, to use my own certificates, users with passwords, more than one listener? It sure would be nice to see somewhere what the embedded broker can/cannot do BEFORE I install it.
Hmmm. I do not see an “advanced” button over here. And the “expert” button was the one which showed me what the existing key names are. I do not see that otherwise.
The code in the embedded broker is prepared for that, but as a framework feature. The framework is gaining user credential support at the moment and the broker will build on that.
The code is prepared for that as well, but is waiting for official SSL certificate management. I started that as a PR a year ago, but Java 7 at that time wasn’t sufficient and now I do not have spare time to resurrect that.
Not sure how to provide that to a user, to be honest. The service config interface would need support for lists, not only strings and numbers.
The reason why MQTT2 took so long (over a year) was, because I try to only use framework features. If a feature is missing I was adding it to the core (including multiple review rounds, test suits etc). But Paper UI and .thing/.item files, the build system and many more stuff are more of a priority at the moment.
People can use Mosquitto for advanced stuff until openHAB core gained all required features.
I completely agree and don’t think I’m complaining that the embedded broker can’t do these things. I personally think it is probably unreasonable to expect a fully functional MQTT 3.whatever spec MQTT broker in this context.
But with no docs what-so-ever, there is no way I can know that until I’ve wasted a bunch of time and effort installing and trying to figure out how to configure it.
Here is the process I would have followed.
look for add-on docs . No docs
Install the embedded broker.
Randomly click around in the config folder since I have nothing to tell me where to go to configure the embedded broker. There it is.
OK, I don’t see an ACL option here, but that’s sort of an expert type of thing to do, let’s click on Expert.
Hmmmm, that’s no real help but it looks like ACLs might be possible if I just knew the right name/value pairs to enter as parameters.
Searching through ESH github I have no idea what to look at, where to look, or what I’d do with it once I found it. But I’ll spend a couple of hours looking.
Give up in frustration having wasted a few hours I could have better spend elsewhere.
I actually went through 1-5 and lost maybe 30 minutes.
If there were some documentation I would have spend 2 minutes to find the doc, read what the embedded broker can do and moved on.
Your time is valuable and you don’t want to spend it on documentation. But our time is valuable too, and there is only one of you and tens of thousands of us.
I guess that is because it is not common to write documentation for a “service” (this is not a binding). No reviewer complained that no documentation was there, so everybody involved seem to live with that fact? I honestly don’t know. I think that can be solved by adding a readme.md file to that services directory at some point, yes.
You are right here. I have a mosquitto up and running on another machine (Synology). But I am always very reluctant to make my home automation relying on too many different subsystems. So the broker should maybe run on the same system. This is openhabianpi for me. I ask myself if I should merge anything in one linux setup or if I should go towards dockerized isolation.
I have already two other “custom” services running on same raspi but outside of openhab (bluetooth presence detection and https reverse proxy with certs and stuff), and these are always an additional pain to setup side-by-side with openhab in the same filesystem.
The homematic integration already led to me setting up a second raspberry (i.e. total isolation). Only after that, the weekly crashes stopped. (And I have never found out if openhab or homegear were to blame for that, which is another reason for better isolation)
What is your suggestion, or, where in your opinion is the “broadest path” for mosquitto used by most other openhab users:
Separate hardware (raspi), or
Separate docker image on the same hardware, or
Setup “manually” merged in one raspian?
(The option “embedded” might be reconsidered later, when I would find ACL support)
And because I’m doing binding development, bindings from me don’t include those sections anymore. They will be auto generated anyhow at some point.
Anybody is invited to submit a PR to fix it, nobody would reject such a PR.