Minimal MQTT: Building A Broker

In this short series, we’re going to get you set up with a completely DIY home automation system using MQTT. Why? Because it’s just about the easiest thing under the sun, and it’s something that many of you out there will be able to do with material on-hand: a Raspberry Pi as a server and an ESP8266 node as a sensor client. Expanding out to something more complicated is left as an exercise to the motivated reader, or can be simply left to mission creep.

We’ll do this in four baby steps. Each one should take you only fifteen minutes and is completely self-contained. There’s a bunch more that you can learn and explore, but we’re going to get you a taste of the power with the absolute minimal hassle.

In this installment, we’re going to build a broker on a Raspberry Pi, which is the hub of your MQTT network. Next time, we’ll get an ESP8266 up and running and start logging some data. After that, we’ll do some back-end scripting in Python to make the data speak, and in the last installment, we’ll explore some of the useful frills and fancy bits. Let’s get started!


MQTT is a pub-sub, store-and-forward, IoT-enabled, machine-to-machine connectivity protocol juggernaut. As you can see, it’s fully buzzword-compliant. That doesn’t necessarily mean that it’s super complicated, though. You can read up on MQTT until you’re blue in the face. Here’s the bare minimum you need to know to be comfortable.

The network has clients (called “clients”) and servers (called “brokers”). Clients, whether it’s your temperature sensor node or the graphing application that’s going to use the data, use the broker as a central hub. Data are arranged in “topics”, which use a directory-like structure. So the temperature node in my bedroom is called “home/bedroom/temp”. When I add a light sensor to my bedroom node, I’ll set up a topic called “home/bedroom/light” and so on.

When a client gets some new data, it “publishes” it to the topic — sends the data to the server. The server then forwards the data along to all of the other clients that have “subscribed” to the topic. In my example, the bedroom node publishes to “home/bedroom/temp” and then a databasing program which is a subscriber to “home/bedroom/temp” automatically receives it. And so does any other client that’s subscribed to the topic.
Often a given physical device will subscribe to some topics and publish to others.  My heating controller will want to act on the temperature sensors, and display its status on an LED in the bedroom, for instance. There’s naturally more to say, but let’s get our broker up and running first and explore the details later.

Build a Broker

attachment_69370628OK, “build” is a little bit overstated. We’re just going to download mosquitto, which is the most widely-used broker. If you’ve got a Raspberry Pi (or other spare computer) lying around, you’ve got an MQTT broker-in-waiting. Unfortunately, Raspbian comes with an old version of mosquitto by default, so we’ll have to do a tiny bit more typing to get the most recent version. Here’s how I set up a fully-featured MQTT broker on a brand-new Raspberry Pi (Jessie Lite):

curl -O
sudo apt-key add mosquitto-repo.gpg.key
rm mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo curl -O
sudo apt-get update
sudo apt-get install mosquitto mosquitto-clients

Et voilà. Later, when we need to access the broker from the outside world, we’ll need to know the Raspberry Pi’s IP address, but that’s it. You’re up and running. If you’re using an older version of Raspbian, substitute “wheezy” for “jessie” in the fifth line. If you’re using anything other than a Raspberry Pi, you can probably find what you need, including Windows binaries, here. (I haven’t tested Windows or Mac.)

Playing Around

Now that our broker is set, let’s do some quick experiments to get a taste of how MQTT works in practice. The astute among you noticed that I also installed mosquitto-clients. Let’s try them out.

Open up a window and type mosquitto_sub -h localhost -t "test/topic". Congratulations, you’ve just subscribed a client to the “test/topic” topic. -h localhost connects you to an MQTT server on the local machine, rather than on the broader Internet. If we weren’t setting up our own server, I’d have you point to the MQTT test servers. As it is, I’ll just let you know that they’re out there when you need them.

OK, let’s publish our first data. Open up another window and type mosquitto_pub -h localhost -t "test/topic" -m "hello!" Same server, same topic, but now we’re sending a message. You should see the message pop up instantly in the subscribed window.

Try opening up multiple subscriber windows, subscribed to the same topic. You’ll see that they all get the message. Try sending messages to topics that don’t exist yet. What happens?

One last stupid MQTT trick before we get to the important stuff. MQTT can use two different types of wildcards in the topic names. So my network has “home/bedroom/temp” and “home/cellar/temp” topics. I can read all the temperatures by subscribing to “home/+/temp” and get all the values from my bedroom node from “home/bedroom/#”. (“+” matches one hierarchical level, while “#” stands for everything deeper in the tree.) Once you start using wildcards, you’ll want to know which topic is reporting, so try subscribing in verbose mode mosquitto_sub -h localhost -v -t "test/#" and send yourself some test messages to different topics.

Quality of Service

Here is MQTT’s killer feature for a low-power home automation sensor network: it’s a “store and forward” protocol with a couple levels of quality of service (QOS) guarantees. If your node has already registered with the broker and it’s offline when a new message comes in, the broker can take care of delivering that message to the node as soon as it reconnects. This means that your nodes can spend most of their lives in a deep sleep, conserving battery power, and when they do finally connect, they haven’t missed anything.

Three things are needed for the QOS feature: the subscribing clients need to be previously registered by ID with the server, and they need to disable the (default) clean-slate behavior otherwise all stored messages are erased when you log back in. Both the subscriber and the publisher need to be using quality-of-service level one or two so that the server knows it’s a stored message. (QOS level one usually suffices, but feel free to read up.)

Here’s an example:

    mosquitto_sub -h localhost -v -t "test/#" -c -q 1 -i "james bond"
    mosquitto_pub -h localhost -t "test/topic" -m "wowie" -q 1
    mosquitto_pub -h localhost -t "test/topic" -m "zowie"

To demonstrate what QOS does, run the subscriber’s command in one window and send the other two messages to it. You’ll get them both. Now stop the subscriber with ctrl-c and resend both messages. Now, when you subscribe again, you’ll only get “wowie” because it was the message sent with QOS enabled.

One gotcha with IDs is that you’ll only get whatever has happened between IDed logins. You have to be previously registered with the server so that it saves messages for you. You can’t just walk in, give it a new ID, and say “what have I missed?” because it doesn’t know you yet.

Also note that the subscriber must do three things to enable receiving messages with QOS. The ID and QOS levels are obvious. The one I always forget is to disable clean-slate logins with the -c flag. Don’t forget.

Retained Messages

If you don’t need to get the full history of messages since your node was last online, consider the “retain” flag. When messages are sent as retained, the last such message gets automatically transmitted to any client that subscribes to the topic. Retained messages are great for things like status reports. Any time that you want to log in and see just the last value without having to wait for an update, you’ll wish you had retain set. And note that retained messages and QOS aren’t exclusive — just be careful because you’ll get one message (the most recent one) delivered twice.


This was just a taste of the power of having your own MQTT server running. Next, we’ll connect some small devices to the network, and then we’ll build up some back-end processing. If you’ve gotten this far and just can’t wait, try playing around with mosquitto_sub -h -t "hackaday/new_articles" -c -q 1 -i "your_name_here". The stream is published with QOS=1 and retains the last message. Feel free to play around and show us what you build in the comments.

48 thoughts on “Minimal MQTT: Building A Broker

    1. The problem with IoT-security is that they connect to the Internet and often open up ports on your router using UPnP or whatever — this article is all about things happening inside your own network and as such your MQTT-clients or MQTT-broker won’t be accessible from the Internet unless you specifically set out to make them so! Authentication/encryption is much less of an issue in a local network, especially so if you’re already using a WPA2-secured WiFi or similar.

      1. Nice kid, Baaad judge of character … (The Grinch – 2000)

        First , I’m not the author . :-)

        Actually putting any kind of trust in an insecure source (even on your LAN) is the problem. Sorry I don’t have the answer to the problem. I’m finding that resource starved micro-controllers have some difficulty with any kind of useful encryption. Not that I’m not still trying. I haven’t been able to get the minimal MQTT security working with the Arduino Uno but I have had better luck with the Fubarino (PIC32) and the Teensy 3.2 (ARM). Still not quite stable but better. I do have my Pi talking to 2 Cloud MQTT services with encryption (AdaFruit and I think CloudMQTT). I’d love to have remote sensors be able to securely login to the Cloud MQTT and that be bridge back to my local MQTT.

        Note: I don’t have 1 working Arduino enviromment for 3 processors. Each still needs it own setup. I do a lot of cursing at the Arduino IDEs. It always seems to be something minor that tosses one of the other 2 processors into fits. At the moment I also can get the ESP8266 env to compile anything.

        1. Personally I think the Arduino Uno is a large part of the problem here.

          It’s time to officially deprecate the 8-bit 5V legacy and – for the “real Arduino” team or a third party – to settle on a modern replacement for the “standard entry-level Arduino”, to replace the ATmega328 Arduino Uno, at the same price point or lower, with a modern 32-bit microcontroller, proper support for that board target in the Arduino IDE without any third-party builds or “hacking” the IDE (this is a lot easier with the new board manager stuff) and move to modern 3.3V logic levels.

          Perhaps you can still call it the Arduino Uno 2.0 or something, and just have drop-in compatibility in the Arduino IDE with the same pin count, same pin mapping, same access to peripherals such as timers or ADCs or whatever on the same pins.

          1. The Arduino was meant to be a prototyping device to learn micro controllers, it was not designed to be the be all end all that it has turned out to be. We do not need to get rid of the Uno. We do need a better option for people wanting to build things that need network security. My automated dog food dispenser does not need to be internet enabled, and does not need TLS/SSL encryption. An 8bit 5v legacy micro controller does the job just fine.

            This week I set up MQTT and have been using Adafruit Huzzah boards with updated firmware to communicate. From what I understand it is suppose to be able to communicate via TLS/SSL (though I haven’t tried to set it up yet) which would be all the security you need. Just give each of your NEDs (network enabled devices (because IoT (internet of things) is a dumb fucking name)) Why not just use those instead of the Arduino?

        1. Not really. Your choices are a plaintext password login which is just there for anyone already snooping your network to steal / spoof, or actual encryption of which the typical certificate-based TLS is useless because a) it requires certificates, b) it only authenticates the server but not the client trying to connect to it and c) you won’t implement it in a small MCU, or the much simpler TLS-PSK symmetric encryption specifically targeting resource constrained MCUs which is useless because absolutely nobody implements it yet except Mosquitto itself (which does, and it works quite brilliantly with its own demo clients). Good luck using it in Python (nope, not implemented) or node.js (nope) or an Arduino (nope). But hey, you can always try implementing it yourself…!

          1. Quite a lot here isn’t true. Setting up a server with certificates is not hard. The ESP8266 is perfectly capable of certificate-based TLS1.1 encryption. It’s perfectly possible to give the client a certificate signed with your CA key, thereby authenticating the client as well.

          2. Thank heavens we have someone ready to set it right then. Except:
            a) ” Setting up a server with certificates is not hard.” [Citation needed] Taking a walk on the Moon isn’t hard either if you’re Neil Armstrong.
            b) The ESP8266 is not “a small MCU” in any sense unless “MCUs” start at 64-bit multi-core Cortex-As for you. Of course it can do that. Now let me see you do it on a Uno with an Ethernet shield…
            c) It may well be possible to nail certificates to everything until you’re blue in the face and “fully secure”, but 99.99% of the certificate-based solutions I’ve seen only ever checked that they’re connecting to the right cloud server, that’s it, end of story, full stop. If you wanted more, you’re on your own, also see a).

      1. We have a winner!

        Functionality first, security second, but we’ll get there too.

        And so far, things are reasonably secure. Everything is inside a (presumably firewalled) WiFi network. All of the people who _could_ hack you are within brick-throwing range. It’s a tiny attack surface, and of little value. Spend your worrying time keeping Adobe Acrobat up to date, IMO.

        The one way in, if you subscribe to my test Hackaday feed, is the possibility of someone putting a payload up there — it’s totally open. Which raises the question: is there an attack against the ESP8266 through the MQTT service? That’d be niche, but hella cool. I wouldn’t be totally surprised for something to be possible. POC if you got one.

        1. I still think this attitude is irresponsible. Someone googling “MQTT arduino” or whatever is going to come up with this post and it says exactly *nothing* about security. How hard would it be to have one sentence in it that basically said, “Security is important and we’ll look at it in a future post”? As it is, it takes exactly zero changes to this code to have it run *across* a firewall, send cleartext messages across a public network and accept messages from absolutely anyone who can find it. Do you really think no-one is going to try modding this configuration to connect to their VPS?

          To those complaining about microcontroller resources, note that the ESP8266 is perfectly capable of making an encrypted connection to a mosquitto server. There’s not even that much effort in setting it up. The only limitation is that there is no TLS1.2 support yet, AFAIK (though it’s supposed to be coming) which prevents you from connecting to some cloud services.

    2. IoT security is something I’ve been thinking about as I ponder expanding my home automation.In my case, I’m not using cloud services much (yet), so my WPA2 wifi offers *some* level of security. But I know that even that can be cracked. And what if I’m adding non-wifi devices (nRF24L01, Zigbee, 915Mhz, etc)?

      I’m not too concerned about the privacy of the data itself (so what if somebody knows that I turned a light on, or what the temperature is in my family room), but I definitely *don’t* want somebody else spoofing my sensors, and tricking my thermostat into running the heater in the summer, or flicking my house lights on and off all night.

      What I’m looking for is authentication/authorization protection. I’ve been pondering a 5-way handshake based on shared-secrets and hashed message tokens to 1) verify that communication is from a known client, and 2) verify that correct data was sent and received: START, ACK_S, DATA, ACK_D, END. The data would be passed from client to master, passed back again with the ACK, and *again* in the END packet, to fully verify data integrity. (I could reduce this to a 3-way handshake by including the data in the START message, I’m still weighing the pros and cons)

      I was thinking about using HMAC-SHA[1|256] and/or CRC32 for the verification tokens. A new token would be generated for each outgoing packet, based on information from the previous packet (and the shared secret).

      I’d welcome any advice on this, whether it’s “there’s already a library/algorithm for this” or “this is dumb for reasons”, or “cool, so write the code already”.

    3. In my home if I had it all ‘wired’ up with IoT devices and a would be hacker burgler tried to use the system to learn when the house is empty I wouldn’t worry much. They would learn that there is pretty much always somebody home and they are better off hitting the next house!

      A prankster could spoof the temperature sensor and cause our heat or AC to come on at the wrong time. Currently I see that as a low probability event. Were it to acually happen then well… like I said, the house is never empty. Somebody would just hit the hardware switch to turn the system off and go back to controling the house the old fashioned way. I would re-evaulate my asessment of what is a ‘low probabiltiy event’, add in some security, turn it back on and continue with life essentially unharmed.

  1. Thanks Elliot – Very helpful post. Thanks for doing this series.

    Wasn’t familiar w MQTT til just recently. Have just started to play with a couple free/OSS IoT platforms (Kaa and Losant). Have studied up thanks to good documentation. This was especially helpful Haven’t tried building my own broker.

    The HiveMQ reference was really helpful too. How does HiveMQ differ from an ‘IoT platform’ like a Kaa or Losant?

    Looking forward to ESP8266 installment of the series. Using a NodeMCU dev board? Would love to see what data streaming / dashboarding someone like you would come up with using a platform like that. Have an ESP8266 (Feather HUZZAH) builder kit I got from Losant and I’m looking for more ideas to work on.

    1. Hive, Mosquitto (I have this one), Node.js has one, there’s a Python script also out there. I suspect there are others also. Plus Cloud MQTT also.

      I currently have a couple of Chipkit boards running with sensors talking to my Mosquitto server (Debian but no security on Mosquitto). I have the Mosquitto server talking to a Pi with Mosquitto and Ubuntu with Mosquitto (for experiments). The Debian, Pi, and Ubuntu boxes also talk to AdaFruit (it has a Dashboard but I haven’t done anything with it and CloudMQTT. Both Adafruit and CloudMQTT are secure (TLS). I almost had a Chipkit board (Fubarino Mini) talking to CloudMQTT but I messed up the Arduino env and I’m working to fix it. MQTT is also talking to Misterhouse and Smartthings (local at the hub not direct from the cloud).

      While MQTT sits in the middle I have scripts (mostly for weather), Node.js and Node-Red push/pulling data. I have one Node-Red service displaying the weather to dials (Steel-series Canvas and web sockets).

      Like Elliot said, once you put MQTT into the mix, it’s pretty easy to use.

  2. I think the article should mention the limitations of store-and-forward. When there is storage, there is limitations. One can not expect MQTT broker to buffer millions of updates while the subscriber is out for lunch.

    1. Fair enough. Although I’m aiming at installations similar to mine, where the data is infrequent enough, and of small enough payloads, that the limitation is never going to bind. I haven’t tested what it takes to make a Raspberry-Pi broker choke, but I’m guessing that thousands of small in-flight messages like those we’re dealing with should be no problem.

      The point is taken though — the MQTT spec actually punts on the topic of what to do when you get too many QoS messages piling up on the server. Some messages may be dropped. The spirit of MQTT is more of minimalism and simple functionality than of ironclad guarantees of message delivery. If you’re looking for bazillions of stored messages, it’s probably the wrong system.

      OTOH, if you back it up with a subscriber that dumps everything directly to a database in real time, you’re getting back in the neighborhood of what you want.

      1. Elliot, I’ve pretty much stuck to the simplest send once (and pray ;-)). I’ve found that higher QoS starts to make for some really odd results with Home Automation. Of course this does mean that if I miss something I probably won’t know about it. I’ve been using commands like this:

        $ mosquitto_pub -h mozart.uucp -q 0 -r -t path/to/topic_b -s < /var/www/data/today.xml
        $ mosquitto_pub -h mozart.uucp -q 0 -r -t path/to/topic_a -m "strings-n-things go here"

        1. Odd how? Do you have high traffic? Or is it just that it’s difficult to code on your clients for handling the rush of messages when they reconnect? Out of order messages? (Man, there are a lot of caveats with QoS!)

          But yeah. The retain flag is perfect for a lot of situations — sensors and statuses in particular. It’s like QoS=1, but for one message, and applied to every client, whether they like it or not. :)

          1. I’m trying to recall what happened. I think it was a topic with a QoS different than 0 and every time I restarted the device it would be the old value (sounds like your QoS troubles described above). I’ve not experienced out of order messages as I tend to go with QoS 0 (don’t want queueing)

            I only have about 200 topics and it’s a 64 bit system. So server performance shouldn’t be an issue (even my Pi 2 can keep up).

  3. MQTT is just coming available on the esp8266 micropython project. Would be great to see you reach out to them and see the same code tomorrow in C and in Python on the esp8266. I think the security aspect may also be being addressed…. But state of MQTT on micropython is very very fresh.

    1. The “nodes” post, coming next, uses NodeMCU b/c it has the most robust/developed MQTT clients, short of writing in C with the ESP libs, which is a _lot_ more work. (We’re aiming for all gain, no pain here.)

      I’d have much rather written in Micropython than Lua — wrangling the callbacks and timers and so on when you really just want a sequence of events drives me crazy. But the micropython code isn’t quite there yet. (I’ll have another look when it is!) And NodeMCU gets a lot done with few lines of code, so it’s good for a web article.

      I’d have done something native on the ESP8266 Arduino, but they don’t support many MQTT features (QoS, encryption being the main ones) that we’ll eventually want.

  4. Hi, nice article to start with MQTT. Looks very familiar to me, as I started to dig into that in quiet the same favour.
    I have now two nodes in my house to monitor some environmental data. I use as a broker. And node-red on my raspberry that is also my 3D printer server.
    I put my project some days back on
    I will add my sources this evening after cleaning up WIFI credentials.

  5. Thanks Elliot for the article. I’ve also found MQTT quite interesting; I especially enjoy the “Last Will and Testament” feature, which the client can send to the broker so that if the client barfs, the broker blasts out the LWT message. Then the other clients can react correspondingly. Would enjoy seeing that touched upon in your series as well.

  6. interesting article. I’ve been noodling around with arduino + relay units to do lighting control with a central x86 server on the lan for more heavyweight stuff (its our mythtv/share server so already on 24/7), and currently they send a unique get request to a http server on my lan to log activity that I can parse for with grep/awk etc, and they have their own local server and can take a butchered form of xml for central control with a view to making a home automation network. The plan is to eventually end up with 4 of these autonomous units but present a local server as a place for remote central control
    Reading up I can use mosquito mq broker instead of my hacked together messages as the glue to hold that together, and just replace the snippet of code in the logging + input parsing modules, call the mq broker from a php page when required on the server etc. I was playing round with some java frameworks but they were just too heavy and full of bugs, so this looks lighter, more command line parseable and more hackable. Now to see if I have space left in the arduino after all my code is jammed in to include the mosquito client library!

    1. I’ve managed to squeeze in the DHCP, MQTT and my code into an Uno with a W5200 board. I have discovered that the board appears to need a few pull-ups added as the control lines to the SD seem to mess up. Also the board appears to be rather unstable and tends to crash every week or two. None too happy about that. I’ve been a bit busy with the other HA I have so I’ve not investigated the Uno problems. I have found that removing the DHCP (hard coded IP info) does make it more stable.

      1. I had random unstability when I was jamming it into a UNO and was getting near the mark on space, but I went to mega’s after the first 4 relay + ethernet unit because it got feature creep and I needed the extra IO to run the local touchscreen lcd, ethernet shield and up to 16 of the sainsmart relays per unit, and of course a external 5v regulator because thats too much current for a bare uno reg to cope with. And then it went away. I don’t really understand which change fixed it but it was a happy accident and its a lot more stable now, albiet in a deeper 3d printed box. For the amount of time I have invested in them, the extra cost of a mega over a uno is nothing, and compared to the amount I’ve wasted on commercial HA gear that didn’t work reliably its a flyspec.
        I’ve been on static ip since the first version, Its easier to have things where I configure them to be, not checking the server for leases. I think the MQ client will jam in some of the unused space there, or I’ll end up shifting some stuff to procmem or simiar to make enough space, but need to test on the bench one, see if its stable then upload to the ones now actually doing the control if its good. Have to preserve WAF on them which means no untested changes!

  7. @Luke Weston (sorry couldn’t reply to you message), 8 bit’rs are not going anywhere, they are still useful. Proper tool for the job thing. I come from an assembly language background and it’s still amazing to see what can be crammed into an Uno. :-) But, I agree with you’re main point. I almost had some security working on the Uno but needed more resources. With the cost of 32 bit processors being roughly the same for a Arduino like board. The Uno is starting to not make sense.

    I’ll skip the rant on the Arduino env, dang thing has a bad habit of giving me fits when I’ve changed just a single thing. I really need to get a better grasp of the Makefile needed for my setups.

    My favorite board are the PIC32 based boards though I do like the Teensy 3.2 as well.

  8. Before trying to connect to an external mqtt broker (Eclipse, Losant , etc), what would be involved in implenting the broker server on a beagebone? Can Mosquitto or VerneMQ fit? Eventually, I’d like to also have the BBB to host Node.js for a simple Node-Red application, instead of buying Bluemix support!

  9. As far as MQTT security goes, here is a very good series

    Its best read AFTER doing an intro to MQTT (such as this series) and BEFORE implementing anything of importance (i.e. your thermostat, garage door, door locks, etc.)

    You are probably more likely to be physically hacked by your kid or their friends (i.e. walk into your house and “examine” your dresser drawers.)

  10. I’m having a hard time Imagining why I would even need MQTT. I’ve been reading off and on about MQTT for the last year, or longer, and always hit the same points when thinking on it.

    There are many software technologies, and networking protocols, as well as tools that could be used in place of MQTT. Without all the hassle, awkwardness of using 3( three !) pieces of software to get data from point A to point B.

    So we’re talking Linux here, and I think it’s about time people who used Linux learned how to use it, and the tools available through it. For instance, “the Swiss army knife of networking”. Netcat. Too complex or difficult to learn ?

    How about Websockets, for “web apps” ? But maybe you do not always want to use a browser to collect data ? Fine, write a simple command parser on your remote device. It’s really not that hard ! What could be more lightweight ?

    Anyway, thanks for the article. I always like to read new technical articles, and just because I do not necessarily agree with what’s being said. It does not mean I think no one should use MQTT. I just have a really hard time drinking the cool-aide on this one.

    1. You mention websockets… If you’ve ever implemented a chat server using WS, that’s generally the same kind of publish/subscribe model that MQTT excels at. And it’s also great for a home automation or IoT model. You generally have various devices that need to send/receive data, maintain status, act on events, etc. You also generally have one or more “command and control” devices which people use to monitor those devices and to send them commands (“is the garage door closed or open?”, “what is the master bedroom temperature?”, “turn on the outside lights”, etc.).

      By using a common protocol like MQTT, you don’t have to do as much customization, and you get libraries that have already solved some of the common problems that you might have to deal with.

      1. I think its a brilliant piece of software that delivers open source enterprise level client server network fabric and full comm protocol. That’s powerful !!! Add anything else u want to it and it only gets better specific to your use case and probably others in time !!!! I’m going to trial it and see if we can make it makes sense to use it here at

  11. Hi,
    I am also using MQTT as home automation.
    In place of any main automation solution (jeedom, home assistant, openhab, …) I will truc to simply use thé Crouton dashboard. It is a vert light solution to then keep mosquitto and Crouton on a same ARM (RPi).
    And if its CPU Can still support it I will run a vocal assistant (kalliope or openjarvis) on it.
    Share your solution if you use my tools here above explained.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.