MQTT Embedded broker advantages


could someone explains the advantages of the Embedded MQTT Broker?

Is it better to migrate the existing mosquitto (which is more than stable) to the embedded?


Most will recommend not to use the embedded broker, don’t remember the exact reason but it has some issues. Stick with mosquitto.:wink:

Thanks, you are saving me a lot of time

but what is the point of the embedded?

I think it’s one of those things that was added to OH long ago and mostly forgotten about (lacking support?). Not sure why it’s still an option but some do use it. I have never used it b/c I don’t need any extra headaches.:laughing:

I think it is not maintained anymore.

1 Like

Your explination ^^ and the words I couldn’t seem to come up with at the time.:upside_down_face:

Mine ^^.:rofl:

Merry Christmas @sihui and @nakh_Home

1 Like

I just want to note that it isn’t us that are no longer supporting Moquette. The original developers of Moquette appear to have abandoned the project.

The original intent was to eliminate the need to install and configure a separate program in order to use MQTT. But the embedded broker is somewhat limited and there are some known issues so I think almost everyone will recommend using an external broker, Mosquitto being the most popular but not only choice.

In fact, the MQTT 2.5 binding has switched client libraries from Paho to HiveMQ so it would not be a bad idea to give their community edition of HiveMQ a try.

Aah, the old “it’s easier!” meme! :roll_eyes:

This is how we ended up with one button interfaces on everything. :smiley:

My intuition told me as much when I was looking into it, glad I decided to follow Unix philosophy of “Do One Thing and Do It Well” (I installed mosquitto).

I did not even realize at the time that it was unmaintained, so that didn’t even enter into my decision.

/makes air quotes

What could possibly go wrong? :smiley:

1 Like

It’s as open source as Mosquitto is. And it’s a business model followed by:

  • Grafana
  • InfluxDB
  • Red Hat (numerous products including Ansible Tower)
  • Docker
  • Kubernetes
  • MySQL
  • Chef
  • Puppet
  • NextCloud
  • OwnCloud
  • pfSense
  • Redis
  • MongoDB

I could go on. In every case they are very up front about what is part of the open source community edition and what is part of the paid for enterprise editions.

What could go wrong? The company can drop support for the community edition and the community will (or may not) take up the code and continue development, just like any open source project.

1 Like

I use the embedded broker, it is easier to install and I knew nothing about mqtt brokers so click click done. Also, Moquette may no longer be actively developed but Jan has fixed a couple problems with it recently so it is still supported/maintained/ here in OpenHAB

And in some cases, exactly where that line is drawn can tend to drift over time. Particularly when said technology / project begins to corner its’ respective market.

Funny you would pick those as examples, as the entire reason that NextCloud was forked off from OwnCloud was because the OwnCloud “Community Edition” kept drifting further and further behind the “Enterprice Edition.” In other words, exactly the point I was trying to make. So thank you for giving examples to support my position. :smiley:

I was just having a bit of a laugh, Rich, at a marketing term I’ve seen bandied about far too often. Look, as long as the project leaders / company behind it stay true to the community and the ideals of F/LOSS, then great. But we always have to keep our eyes open and pitchforks sharp, you know, just in case. :wink:

And the fact that Nextcloud was forked and became it’s own vibrant project and community when things started to “go wrong” is exactly my point. BTW, I run Nextcloud.

and the community will (or may not) take up the code and continue development, just like any open source project.

You could point at pfSense and nextSense as another example if you like.

I used to be a FLOSS zealot. But at the end of the day it’s just too tiring. I’m far more practical these days. I’ll choose what ever makes the most sense at the time. If that means getting something I need to flash new firmware on so be it. If that means I have something completely closed but perfectly meets my requirement, I’ll buy it. If the company pulls support for it later (looking at you Nest) well, semper gumby. Nothing is forever.

I suspect I’m unlike a lot of home automation enthusiasts based on a lot that gets written here but I have no expectation that what I’ve working now will work always and forever unchanged. I fully expect to rebuild each and every part of my home automation system, sometimes because something better comes along and sometimes because something I use pulls a Google and shuts down support. The other day someone posted something along the lines of “is it good to move my Rules to Scripted Automation? Once it’s working I never want to have to touch them again.” That’s such a foreign concept to me it took me a bit to figure out how to respond.

And for the curious, I have a HestiaPi coming to replace my Nest thermostat (which was free from my power company in the first place) and I don’t really need the Nest Hello integrated with anything. It natively does all I need, no integration necessary. But should that ever change, I’ll seek out a replacement. I don’t expect it to last forever. If I get three years out of it I’ll be happy.

Oh, shut up with your “facts!” :smiley: (That’s what my wife and I say to each other when we know the other one has us dead to rights in an argument discussion.) :smiley:

I used to also. Now I am moving further down the rabbit hole into “Unix Philosophy” and instead use Radicale and Syncthing to do the main parts of NextCloud that I needed. Plus I have fallen in love with small inexpensive Single Board Computers and all the services I run are lightweight and run flawlessly on them. I understand NextCloud use case, but found it heavy for my needs, personally. Not trying to take away from it. I think their target user is still on Google but wants to get off, so, more power to them!

Funny you mention that, as the thought crossed my mind at some point during our various exchanges recently of changing my avatar to the StarCraft character, probably because my nephew has been bothering me lately to join him online and I just got the very latest version of the original (it’s free now! (as in cost, lol)) working in Wine with Lutris. :smiley:

Besides, F/LOSS is the middle of the road compromise (I figured, when in Rome… :wink: ). The real zealots talk about Free Software (which I do too, sometimes). But this is pretty clearly an open source operation around here, so I try and keep my head down as much as I can. But I’m into my second beer now. :smiley:

I dunno man, I just don’t care about what is easy nor convenient. I care about what is right. What do they say is the definition of a cynic? A disappointed idealist? That’s the definition I like. Or alternatively the one, about ~“having accurate observations, by those who have not got it.” :smiley: I’m sure the world will wear me down too at some point, but I’m not there yet. I really hope that doesn’t come across as condescending towards you, because I don’t intend it that way. I am speaking only for myself and my own choices. You do a lot of great work around here man, you help a lot of people. There is wisdom in your words, but I (so far) continue to consciously choose the road less traveled. There is less traffic. :wink:

People actually say this? I mean, I get the sentiment, but I view this as a hobby activity, in which there will be endless tinkering, for various reason as you so correctly point out (sometimes better things come along, etc.).

But I think there is a huge difference between technology evolving, and choosing to move towards newer / better things, vs being forced to change because of (what I consider to be stupid) reasons like vendor lock in, abandonment of platform, etc. After you see the same story play out enough times (and especially when it happens to you) you start to just avoid certain ecosystems and products. You know, fool me once, shame on you, fool me twice…

This was one of the main things I thought of integrating from the beginning. I keep reading about “solutions” and “products” but in my mind all you would need are a few relays and a microcontroller (and some temperature sensor(s), either at the device or elsewhere throughout the home; plus of course some hysteresis(sp?) logic with the various temps in the case of multiple distributed sensors). To me this is a pretty dead simple thing to implement, why is everyone spending >$100 on these devices? I figure I must be missing something, maybe you can clue me in on what that might be?


i will keep the MQTT server hosted in another PI

i have installed 2.5 release from scratch and the mqtt bindings

the service is starting but nothing is happening. i mean the incoming mqtt changes do not trigger openhab items changes
it was working in 2.4

Openhab is installed on
mqtt server is installed on

in the mqtt.cfg

i set :


broker.url=tcp:// commented

my item:

Contact mqtt_sensor_door "S1-Door Sensor [%s]" (gHistory,gPresence,gDoor) ["object:door"] {mqtt="<[mosquitto:broadlink/mqtt_S1_1/door:state:default]"}

my mqtt server is well running

What i am missing

This is the syntax for the 1.x mqtt binding. Need to use syntax for the new 2.4 binding.

Here’s a guide to help with the changes. Sonoff Tasmota with MQTT Binding 2.4 (using config files)


@nakh_Home: Have you created a generic Thing in PaperUI for all your mqtt things? Most recommend using PaperUI to config all mqtt Things and files for items. This helps prevent syntax errors and misconfigurations.

Did you mis-click on my post when marking it as solution? Perhaps you meant to like it instead? :smiley:

1 Like

:+1: as I almost didn’t recheck the topic b/c it was marked solved.:upside_down_face:

@nakh_Home I can post a few of my mqtt things and items as examples if you think it will help with your config. BTW I’m a bit hard headed and use files for both Things and Items.:shushing_face:

Thanks, i will appreciate if you you can share it. have an excellent day!

Meantime, to finish the upgrade to 2.5, iam sticking to the old format.

thanks for your time

i will soon get some tuya items that i want to integrate with mqtt

maybe i will integrate them directly with the new mqtt binding

thanks anyway

@nakh_Home Here are a few mqtt configs as an example:


Bridge mqtt:broker:pibroker "pibroker" [ host="", port=1883, secure=false, username="xxxxxxxx", password="xxxxxxxx" ]
    // Sonoffs
    Thing topic sonoff11 "Living Room Light" @ "Living Room" {
        Type switch : power       "Power"         [ stateTopic="stat/sonoff11/POWER", commandTopic="cmnd/sonoff11/POWER" ]
        Type number : temperature "Temperature"   [ stateTopic="tele/sonoff11/SENSOR", transformationPattern="JSONPATH:$.SI7021.Temperature" ]
        Type number : humidity    "Humidity"      [ stateTopic="tele/sonoff11/SENSOR", transformationPattern="JSONPATH:$.SI7021.Humidity" ]

    Thing topic sonoff2 "Couch Light" @ "Couch Light" {
        Type switch : power        "Power"         [ stateTopic="stat/sonoff2/POWER", commandTopic="cmnd/sonoff2/POWER" ]

    Thing topic sonoff55 "Office Light" @ "Office" {
        Type switch : power        "Power"         [ stateTopic="stat/sonoff55/POWER", commandTopic="cmnd/sonoff55/POWER" ]


Switch LivingRoom_Light "Living Room Light" <light>  ["Lighting"] { channel="mqtt:topic:pibroker:sonoff11:power" }
Number LivingRoom_Light_Temp "Temperature [%.1f °F]"      <temp>             { channel="mqtt:topic:pibroker:sonoff11:temperature" }
Number LivingRoom_Light_Humidity    "Humidity [%.1f %%]"    <humidity>       { channel="mqtt:topic:pibroker:sonoff11:humidity" }

Switch CouchLight "Couch Light" <light>  ["Lighting"]  { channel="mqtt:topic:pibroker:sonoff2:power" }

Switch OfficeLight "Office Light" <light>  ["Lighting"]  { channel="mqtt:topic:pibroker:sonoff55:power", expire="180m,command=OFF" }

Depending on what the mqtt topic is you may need to use a transformation service. If you run into issues just post the mqtt topic and error in logs.

1 Like

I thought you had to with MQTT? Or at least those were the sort of examples I found that seemed to work for me, so I went that way also.

I suppose it might be useful to see a couple different configs and then you can start to figure it out. Man I recall reading so much stuff to get this working. Too much to give you any links. I think the MQTT binding page was helpful, but I seem to recall there being others as well. It’s been a little while though. And normally I try and take down notes about things like that, but it must have been one of those cases where I was so tired and frustrated by the time I got it working that I didn’t have the energy or focus left to do so. :smiley: Anyway…

Looking at this again now I guess I ended up somehow with a separate broker.things and mqtt.things files (I am running mosquitto broker on same machine as openHAB, installed standalone thru Debian repositories):

$ cat /etc/openhab2/things/broker.things 

Bridge mqtt:broker:mosquitto "Local Mosquitto" [ host="localhost", port=1883, secure=false, clientID="OpenHAB2" ]

$ cat /etc/openhab2/things/mqtt.things

Thing mqtt:topic:mosquitto:dafang0 "dafang0 IP Camera" (mqtt:broker:mosquitto) {
		Type switch : motion "dafang0 motion" [ stateTopic="dafang0/motion", commandTopic="dafang0/motion/set" ]

Thing mqtt:topic:mosquitto:rhasspy "Rhasspy voice control" (mqtt:broker:mosquitto) {
                Type string : intent_lights "Rhasspy Intent Lights" [ stateTopic="rhasspy/intent/Lights" ]

But still only one .items file:

$ cat /etc/openhab2/items/mqtt.items 

Switch dafang0_motion "dafang0 Motion" { channel="mqtt:topic:mosquitto:dafang0:motion", expire="30m,command=OFF" }

String rhasspy_intent_lights "Rhasspy Intent Lights" { channel="mqtt:topic:mosquitto:rhasspy:intent:Lights" }

Incidentally, I think this ended up with me having 2 items for the Rhasspy intent for the lights, one from the thing channel (called intent_lights), and another from the separate item created (called rhasspy_intent_lights). So, don’t feel bad, I barely have gotten my own head around it by now. :smiley: