Message Queuing Telemetry Transport (MQTT) is a publish/subscribe messaging protocol for constrained, low-powered embedded Internet of Things devices. Think of it as the M2M (machine-to-machine) messaging protocol for low-bandwidth, high-latency, and unreliable network environments. This gives IoT developers a solid communication option when specifically working with embedded devices, which are expected to perform in “the wild,” while still needing to remain small, light, and have a high performance battery life.
Design and History Behind MQTT
MQTT was first developed in 1999, but has seen a massive explosion in growth and adoption with the surge of the Internet of Things. We now need a way to communicate, signal, and connect between low powered smart devices, and that’s where MQTT comes in. Built as a low-overhead protocol with strong considerations towards bandwidth and CPU limitations, MQTT has found its place in the embedded environment.
In terms of design, MQTT is a publish/subscribe M2M protocol for embedded devices. It enables clients to connect as a publisher, subscriber, or both, and connect to a broker that handles message passing. There is plenty of documentation and open source client implementations if you wish to dive further into the protocol itself.
The Core of MQTT is the Topic
The ‘topic’ is at the core of using MQTT as an M2M communication avenue for embedded devices. It’s a simple idea, and it’s not unique to MQTT. However, the MQTT protocol harnesses the ‘topic’ fairly well. The ‘topic’ does several things, it’s most important being to ensure that a message is delivered to the correct subscribers. MQTT treats the ‘topic’ as a file path. Overall, think of the ‘topic’ as a simple communication filter, which makes the path application very powerful.
topic = "user/path/topic"
You could be interested in a particular higher level of the path or the leaf element. Without explicitly saying so, MQTT filters messages based on where you subscribe in the tree path. A simple idea, that can be used very effectively.
Technical Specifications of MQTT
Looking a little deeper into the technical aspects of MQTT, the M2M protocol runs on the top of a TCP/IP networking stack. When a client connects for publish/subscribe, MQTT begins the handshaking process. The MQTT header is two bytes, and the first byte is constant. In the first byte, you specify the type of message being sent, as well as the QoS level, retain, and DUP flags. The second byte is the remaining length field. There is more information you can glean from the MQTT specification if you are interested.
Building MQTT on a Data Stream Network
With PubNub now supporting MQTT over our realtime, global data stream network, we wanted to give an overview of the protocol and why you might or might not use it from our perspective. We just went through some of the inner workings, features, and the value the protocol. We’ll now take a look at why you might want to use MQTT with PubNub, or PubNub native exclusively.
To utilize PubNub, our gateway is
mqtt.pubnub.com and we’ll handle all the broker services and provide you access to our network. First, you publish to a topic (at PubNub we call them channels). Anyone who is subscribed to that topic will receive the message that was published.
If you want to read more and see a more in-depth tutorial, check out our blog post on using MQTT with the PubNub Data Stream Network here.
You may be wondering what the advantage is of using PubNub Native over MQTT?
from Pubnub import Pubnub def callback(message, channel): print(message, channel) pubnub = Pubnub('demo', 'demo') pubnub.subscribe('my_channel', callback=callback) - See more at: http://www.pubnub.com/blog/what-is-mqtt-use-cases/#sthash.Fm9tmkN5.dpuf
MQTT targets low-powered embedded device environments where resources are scarce. PubNub solves the problems of large-scale connectivity for realtime apps and IoT devices. If you’ve already deployed MQTT-based infrastructure, it makes sense to take advantage of this new PubNub gateway to facilitate scaling and maintenance of your embedded device connectivity layer.
If MQTT is not part of your current infrastructure, you might consider leveraging the PubNub Realtime Data Stream Network directly along with PubNub’s numerous IoT SDKs for all of your Internet of Things connectivity. To start, we provide over 50 client SDKs to use, extensive PubNub documentation and our blog where we showcase useful tutorials with open source code, demos, and other write ups on all things realtime technology.
MQTT does have many open source client implementations and documentation, and is a great publish/subscribe messaging protocol for low-powered devices. The protocol has a small footprint and has some great MQTT use cases.
import paho.mqtt.client as mqtt def on_message(client, userdata, message): print(msg.topic, str(msg.payload)) def on_connect(client, userdata, flags, rc): client.subscribe('my_topic') client = mqtt.Client() client.on_message = on_message client.on_connect = on_connect client.connect('mqtt.pubnub.com', 1883) client.loop_forever()
Arduino + MQTT = Two Peas in a Pod
There are several Arduino-MQTT implementations and resources available today, and the two go hand in hand for developers working on embedded device projects. As a user, if you are looking for a very small publish/subscribe protocol, MQTT may be for you. If you need more features, or need to scale to hundreds or thousands of connected devices, that’s where PubNub comes in. The transition from MQTT to PubNub in both code and ideology is a quick, exciting process.
Pingback: 5 IoT Challenges for Connected Car Dev | Bits & Pieces from the Embedded Design World
Pingback: Calling all Makers, visionaries and innovators are up for a (IPSO) Challenge! | Atmel | Bits & Pieces
One question is sending message from mqtt client to pubnub client is possible? I tried doing so but no success.