Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I took me several days to figure out that the client was running into a race condition on a slower system that resulted in subscriptions to topics silently being ignored which caused the associated callbacks to malfunction despite following their documentation 100%. Overall, this has been one the messiest experienced I have ever had with a protocol, certainly one that isn't that old.
MQTT is being used a lot more in recent years inside of factories for sharing data between machines. Historically it's been used in Oil & Gas for SCADA (getting data from remote well sites).
10+ years ago we added it to Kepware (OPC server) and streamed tag values to "the cloud". I was at a conference giving a presentation on it when Arlen Nipper, one of the creators of MQTT, came up after the presentation and said I did a "decent job". It was humbling :). Fast forward to today, and we have a new company (HighByte) modeling factory data at the edge and sending it via MQTT, SparkplugB (protocol over MQTT), direct to S3, Azure Blob, etc, etc.
All that to say, MQTT is a big driver in Industry 4.0, and it's cool to see it so heavily used all these years later.
About 15 years ago, Andy Stanford Clark's house became something of a news item, in the days before tweeting IoT devices were a thing:
https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
The core protocol, devised in the days when 1 byte over a satellite link cost $1, is incredibly efficient and simple to implement.
Reposting my comment from five years ago:
I once had a client where the only port available for me to use on their firewalls was for MQTT (1883) because that's how we were getting sensor data from them. They would not open anything else for us no matter how we implored them so I wrote a live TCP wrapper over MQTT to get around it. It was a local multithreaded TCP daemon that listened for outbound requests on a certain port, wrapped them in MQTT and then published them using a unique topic. The server daemon would detect these topics and unwrap them before forwarding to our server processes. So the client machine thought it was making a live TCP connection to our server but in the middle was a funky invisible MQTT wrapper. It was really elegant once it worked but my goodness was it a pain to debug - a couple of months before I got the whole thing right because of all the blind alleys I went down.
Fun fact: at the same time, the most famous C++ library, Boost, is reviewing the `async-mqtt5` implementation (https://github.com/mireo/async-mqtt5) to be included in Boost as Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.php
It's such a great little protocol, and besides being "small enough" for hobby projects, it also scales enough to be used for something like Facebook Messenger [1]
[1]: https://engineering.fb.com/2011/08/12/android/building-faceb...
I don't buy the b.s. around MQTT being so lightweight/efficient/etc. It's just using TCP/IP. Maybe by the standards of the day that was comparatively special, but I've never seen any real evidence for the claim besides this constant bragging.
I guess it's nice that MQTT is a standard and so you have a way to connect to off-the-shelf devices that are enabled. I still think there are better options for pub/sub and message queues, esp. if you need to failover on the consumer side.
I have been using MQTT for years in my IoT courses – it has proven to be a very versatile tool, and it is convenient that it is also supported over web sockets.
I had a lot of fun on an embedded systems project recently where I used MQTT as an interprocess messaging system. Broker and clients on the same machine.
If I needed to sniff or debug something it was as easy as putting the device on the network and using MQTT Explorer to record or inject messages. I could even let coworkers that were working remotely work with the system by opening the port outside the LAN.
The cool thing about MQTT is there's so many servers for it that are completely public -- and intentionally so. You can use it for real time messages but I think it also has quality modes that allow for some persistence.
Some of these servers have stat pages that show how much data they transfer. Usually phenomenal amounts of data. It's pleasing to me as someone doing a lot of stuff with open source networking to have such an establish protocol (instead of say -- 10 crappy ones.) MQTT works and it works well.
I discovered MQTT with Home Assistant (a home automation solution, no, sorry, THE home automation solution).
It helped me to understand pubsub philosophy and I ended up using it for my personal development - to the point where I was misusing it (which is the typical path with technologies one discovers)
It is a great protocol for home automation but quickly gets annoying for more complex scenarios.
There aren’t many telemetry transfer protocols suitable for IoT besides MQTT (especially for resource constrained systems). It is incredibly simple to implement, has numerous libraries available in various programming languages, is supported by major cloud providers and is designed to operate over TCP (meaning you avoid DTLS).
We have shipped many products that use MQTT for telemetry transfer to various different vendor servers and it always just worked. It was never a pain-point in stark contrast to CoAP or some proprietary protocols.
My most recent foray into MQTT was using the MQTT 3.1.1 compatibility mode in NATS, which was pretty easy to set up once I got the permissions sorted out.
Works great for my smart home needs while also letting me explore latency and throughput load testing if I want to have a little fun.
I remember one of the annoying things I found about actually using MQTT was that many clients didn't implement any sort of connect/disconnect callback and expected you to handle reconnection logic (e.g. exponential backoff) yourself. Also it didn't support RPC style requests for some reason.
Also since MQTT is TCP-based you can't natively speak the protocol from a webbrowser without the broker also listening on a websocket.
Ended up switching to WAMP-proto [0], which checked all my boxes and just did everything over websockets by default.
Most of my home automations depend on it, it’s been great honestly. Cheers to mqtt!
I'm wondering if someone tried https://mqtt-udp.readthedocs.io/en/latest/
Sounds like a very good idea on paper, which can even be brokered if needed
A heap of dead "replacements" at the feets - what more can a communication standard want.
I never understood why we don't use MQTT for simple systems monitoring, with a push model.
I mean it was almost designed for this use case.
Also if using NATS things become very simple to setup.
What do you think about LwM2M in comparison with MQTT?
I think my first project that's still "in production" and used daily was taking an existing SVG map of a water distribution system (snowmaking and fire suppression pipelines/pumps/valves/etc at a major ski resort). I made a MQTT topic for each pump, valve and section of pipe along with some state for each (water direction, pump or valve on/off, pressures, etc). It's a website, so I used mqtt.js and jQuery to update the colours and fills of the SVG to represent the various states. It's statically hosted and there's a mqtt broker that's been running in a container, untouched for nearly 10 years now. Mqtt.js is running over a web socket, so if the state is updated, it just magically updates for everyone else.