A server, also called broker is not provided within this binding
I would like to know why :
is this only a bad idea because resilience, etc ?
or
is this technically a bad idea ? Compatibility, etc
or
is this something no one take the time to do because “meh, why doing it, mosquitto is good” ?
I managed to avoid MQTT in my home for now but I may need it sooner or later (more sooner than later). I hate having many pieces of software (yes I know I should not but please don’t try to make me change on this I even made a signal binding and a sms binding to avoid having software like gammu and signal-cli), and so I’m considering the idea above.
Is moquette broker suitable ? And if so, has a PR integrating moquette into the binding a chance to be merged ? It could be labelled as a “build-in MQTT broker” type of bridge.
EDIT : oh I see it was something in openHAB 2 (system MQTT broker) ! So I will try to find why it has been discontinued.
As you’ve found, OH had an embedded broker for a while but it was removed because upstream stopped maintaining it and it never really worked that well.
That was the specific reason. However, for a more generic discussion on this, having seen how it worked when we had Moquette available in OH it primarily caused confusion and from my perspective ended up causing more work in the long run than it would have had we simply left it out in the first place.
Mosquitto is super easy to install and it has a reasonable configuration out of the box. When it takes less work for the end users to get a better/more capable system by deploying a separate service, the whole value of having the embedded service becomes suspect at best.
Thank you Rich for your reply.
I wasn’t aware of so much usability differences between the two brokers.
So, this doesn’t seem a good idea to bring it back, understood !
I even made a signal binding and a sms binding to avoid having software like gammu and signal-cli), and so I’m considering the idea above.