[FoRK] MQTT : Exploring the Protocols of IoT - News - SparkFun Electronics
J. Andrew Rogers
andrew at jarbox.org
Thu Feb 26 23:14:38 PST 2015
I can say that MQTT is not that useful for the Internet of Things use cases
for which it is touted, despite having "telemetry" in the name. Web
technology derived protocols are generally unsuited to that use case. For
generic PubSub, there are a lot of other standards/designs, so I am not
sure what MQTT brings. I do not see a use case.
Sensor source PubSub is interesting in that an appropriate protocol does
not already exist that can meet elementary requirements. It really needs a
purpose-built protocol designed from scratch but for now everyone seems
happy to put a veneer of IoT on whatever badly engineered protocol they
happen to use. The reason there are so many protocols is that they all suck
in important ways. I have been threatening to design a proper protocol for
at least a year now, in my copious spare time.
A modern, universal PubSub is needed but does not exist. The physical world
has a more complex set of constraints than the virtual world. As an
engineering problem, it is pretty cool.
On Thursday, February 26, 2015, Dr. Ernie Prabhakar <
drernie at radicalcentrism.org> wrote:
> 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
> > 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
> > <
> > What really makes MQTT perfect for small embedded electronics is its
> lightweight packet structure - the entire protocol is documented on a
> single page <
> 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.:
> > 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
> > <
> > CoAP header packet structure adapted from the published CoAP standard <
> > 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!
> FoRK mailing list
More information about the FoRK