The Internet of Things is just around the corner, and somehow or another, all these bits of intelligent dust and juice bag squeezers will have to talk to one another. One of the better ways to get IoT bits talking to each other is MQTT, Message Queuing Telemetry Transport, a protocol designed for small code footprints and limited network bandwidth. It gets a lot of IoT hype, but it’s a great alternative to HTTP for your own small projects, so that’s what we’re talking about during this week’s Hack Chat.
MQTT is a machine-to-machine connectivity protocol, very useful in remote locations, where a small code footprint is required, where bandwidth is at a premium, or for turning a lamp on and off from your phone, while sitting in the same room. It’s ideal for mobile applications, and in the twenty or so years since its creation, MQTT has made inroads into all those ‘smart’ devices around your house.
MQTT is based on a very simple publish and subscribe model with ‘topics’ that allow you to configure where messages should be sent. It is an extremely simple protocol, but with MQTT, you can set up a complete home automation system that opens the garage door, turns on a lamp, or pings a few weather sensors.
For this week’s Hack Chat, we’re going to be discussing MQTT with the entire Hackaday.io community. There are dozens of people who have built MQTT-based projects that frequent the Hack Chat, and hundreds more that want to learn. Want to get in on the ground floor of the Internet of Things? This is the Hack Chat you want to check out. It’s a community pow-wow around connected devices.
Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This week the crew is going to sit down around the campfire around noon, Pacific time, Friday, April 13th (oooh, spooky). Want to know what time this is happening in your neck of the woods? Have a countdown timer!
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io.
You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.
8 thoughts on “Friday Hack Chat: Talking MQTT With The Community”
Alternative protocols include the Advanced Message Queuing Protocol (AMQP), Streaming Text Oriented Messaging Protocol (STOMP), the IETF Constrained Application Protocol, XMPP, DDS,OPC UA, and Web Application Messaging Protocol (WAMP).
I’m not familiar with the others, but XMPP is a frickin’ overcomplicated mess! MQTT is simple and efficient and can be used on MCUs with very limited resources, making it great for remote sensors and stuff, but XMPP? Only a masopig would use it voluntarily!
I use MQTT extensively for IOT communications. Its ease of use and widespread support are the main draws. The main issue is that, in its standard form, it relies on TCP/IP transport which is rather heavyweight for simple sensor to controller comms. Something like CoAP is better for that as it normally uses UDP. The key to using any of these protocols is to create message semantics that does not depend on the messaging layer so that different protocols can be used where appropriate.
I would say that MQTT is horrible for IoT! especially if you need to limit your data usage. You need to send ping even if you send data on the topic. You need to append topic name in every message…
TLDR: “MQTT is an old, recycled, and often weirdly inconsistent mess. It’s not a good protocol, and certainly not a good protocol for the Internet of Things where we will look connect devices with long-haul links with unpredictable network conditions, and I believe it’s unfixable without becoming something different entirely. We ought to know better, and OASIS also ought to know better.”
I use MQTT extensibly at home with home assistant and it works perfectly, to say it’s a mess is only correct if you’re communicating over the internet and not within a private. Over the internet using mqtt without an ssl secure link would be more than stupid and asking for trouble. I think we still need something like mqtt but more secure and still light weight with broad support for different architectures. But until that arrives people will stick with mqtt.
Early in 2017 I started converting my somewhat unique home automation code to MQTT. While I wrote most of the peripheral services in Java, I wrote the central control part in SWI-Prolog. There was actually mostly working native MQTT binding code already out there, I made some changes to support binary messages and the result is on Github here: https://github.com/sprior/swi-mqtt-pack. In addition to other command and status messages I also pass JPG images from cameras which are then routed through the Prolog code for other processing. I have ESP8266 based devices for some temperature/humidity sensors and output devices (Neopixel and LCD display).
Early in 2017 I started converting my somewhat unique home automation code to MQTT. While I wrote most of the peripheral services in Java, I wrote the central control part in SWI-Prolog. There was actually mostly working native ..thanks for the share some very important news with us..
Please be kind and respectful to help make the comments section excellent. (Comment Policy)