[FoRK] MQTT : Exploring the Protocols of IoT - News - SparkFun Electronics

Dr. Ernie Prabhakar drernie at radicalcentrism.org
Thu Feb 26 17:56:36 PST 2015


What do all your PubSub groupies think of MQTT?  And why do we have to keep reinventing this stuff every decade?!?

— Ernie P.

> https://www.sparkfun.com/news/1705 <https://www.sparkfun.com/news/1705>
> 
> Exploring the Protocols of IoT
> 
> I've been learning a lot about IoT protocols lately. Come learn the wonders of MQTT and CoAP!
> 
> by Jimb0 <https://www.sparkfun.com/users/69916> January 05, 2015 08:10 PST 8 <https://www.sparkfun.com/news/1705#comments>Favorite 0
> Happy New Year! Have you made any new resolutions? One of my goals this year is to broaden my understanding of the ever-growing IoT world. Among a variety of subjects, I’m studying web development (learning to love JavaScript), security solutions, and communication protocols.
> 
> The protocols that rule over how a device transmits and receives data can be a critical component behind how the rest of its resources are managed. Arduino and Arduino-like IoT “things” especially, with their limited flash and SRAM, can benefit from specially crafted IoT protocols.
> 
> There are a quite a few IoT protocols out there to choose from. XMPP <http://xmpp.org/> is a popular, proven, XML-based service, but it’s not as lightweight as other alternatives. DDS <http://portals.omg.org/dds/> is a powerful device-to-device service that offers high performance data distribution, but still a little bit too resource intensive. There are a handful more, but the two that have caught my eye the most these days are MQTT and CoAP.
> 
> MQTT - Multi-Client Publish/Subscribe Messaging
> 
> MQTT <http://mqtt.org/> (Message Queue Telemetry Transport) is my IoT protocol of choice right now. It was created nearly 15 years ago with an eye towards remote sensor nodes (“remote” as in space), so it was designed to conserve both power and memory. It’s a message queuing protocol that uses a publish/subscribe methodology to allow multiple clients to post messages and receive updates from a central server. For example, using MQTT, a connected device can subscribe to any number of topics hosted by an MQTT broker (a server equipped with MQTT). Any time a different device publishes data to one of those topics, the server sends out a message to any-and-all connected subscribers of those topics alerting them to the new data.
> 
>  <https://cdn.sparkfun.com/assets/home_page_posts/1/7/0/5/mqtt-explanation.png>
> What really makes MQTT perfect for small embedded electronics is its lightweight packet structure - the entire protocol is documented on a single page <http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html>. Simply set up a session with a MQTT broker, tell it what topics you want to subscribe to, and maintain that session as long as you need.
> 
> There’s a really solid Arduino library to help implement MQTT – knolleary’s pubsubclient <https://github.com/knolleary/pubsubclient>. An Arduino with an Ethernet Shield <https://www.sparkfun.com/products/9026>/WiFi Shield <https://www.sparkfun.com/products/12071>/etc., or just a bare Yun <https://www.sparkfun.com/products/12053> or Edison <https://www.sparkfun.com/products/13024>, can utilize the pubsubclient library for all of its MQTT-publishing-and-subscribing needs.
> 
> If you’re trying to find an application for MQTT, look no further than our own data.sparkfun.com <https://data.sparkfun.com/>, which supports the protocol! You can subscribe to specific topics on your Phant data stream, or use MQTT to publish your sensor readings. Check out this GitHub topic <https://github.com/sparkfun/phant/issues/55> for help getting started. Plus, since Phant is open source, you can install the phant-server-mqtt <https://github.com/sparkfun/phant-server-mqtt>, phant-input-mqtt <https://github.com/sparkfun/phant-input-mqtt>, and phant-output-mqtt <https://github.com/sparkfun/phant-output-mqtt> modules to enable MQTT on your own Phant server.
> 
> To test MQTT out, I decided to try to use Phant to “control” an Arduino, not just host its sensor readings. I whipped up a quick sketch and threw it on a Arduino/Ethernet Shield combo. Here’s an example of how easy the library makes MQTT:
> 
> Now whenever data is posted to my stream <https://data.sparkfun.com/streams/roE6z8QZq5iyEdrMGwdG>, the RGB LEDs on my Arduino are updated too. The poster to Phant can be anything from another Arduino (publishing with MQTT?!) to a customized web URL (e.g.: https://data.sparkfun.com/input/roE6z8QZq5iyEdrMGwdG?private_key=jklEy4DG75TY1lzm6nl6&blue=1024&green=42&red=66 <https://data.sparkfun.com/input/roE6z8QZq5iyEdrMGwdG?private_key=jklEy4DG75TY1lzm6nl6&blue=254&green=42&red=66>).
> 
> One last note on MQTT: if you’re looking to give the protocol a try sans Arduino, I’ve found Mosquitto <http://mosquitto.org/> to be a great, command-line-based tool to test it out.
> 
> CoAP - Lightweight Alternative to HTTP
> 
> CoAP (Constrained Application Protocol) caught my attention because it’s billed as something of a lightweight version of HTTP. If you’ve done any HTTP with an Arduino, you may be familiar with what a memory sink those verbose messages and responses can be. Instead of messing about with strings, CoAP packets are mostly based around bit mapping.
> 
> To compare the two, a simple HTTP GET header may look like this:
> 
> GET /output/roE6z8QZq5iyEdrMGwdG/latest.txt HTTP/1.1
> Host: data.sparkfun.com
> Connection: close
> …very human-readable, but also very “stringy.” It may not look like much, but that’s almost 100 bytes, and they can grow to be much more than that. On the other hand, CoAP headers take on a bit-mapped structure like this:
> 
>  <https://cdn.sparkfun.com/assets/home_page_posts/1/7/0/5/coap_packet.png>
> CoAP header packet structure adapted from the published CoAP standard <https://tools.ietf.org/html/draft-ietf-core-coap-03#section-3.1>.
> 
> As few as 4 bytes (ignoring all of the options)! You can’t pass as much information through, but it gets the job done. Also as a bonus, at least as far as resource requirements go, CoAP, by default, operates over UDP instead of TCP.
> 
> If you’re too stubborn to swap horses, or if the Arduino’s just all you have on your desk, CoAP is an interesting alternative to HTTP. There are a few Arduino implementations out there, like microcoap <https://github.com/1248/microcoap>, if you’d like to check it out further.
> 
> Both of these protocols, and all of the rest of the “IoT protocols” hold a lot of potential and power in the encroaching IoT world. MQTT is a great choice for multi-device networks, and CoAP is well-suited for point-to-point connections when resources are limited. I’m excited to find some projects to put them to use in 2015!


More information about the FoRK mailing list