Tag Archives: mqtt

MQTT not IoT “god protocol,” but getting closer

One protocol, and its descendants, drove the success of the World Wide Web. IP, or Internet Protocol, is the basis of every browser connection and the backbone of IT data centers. Some assumed that the Internet of Things would follow suit, with the thought that having an IP address would be a sufficient condition to connect.

The problem on the IoT isn’t IP – the problem is all the stuff layered on top of it. Running protocols such as HTTP, SSL, and XML requires significant compute power and memory space. The average PC, smartphone, or tablet has enough horsepower today to do that, but the average sensor running on a smaller microcontroller does not. (ARM Cortex-M7 notwithstanding.)

To combat that, the industry has spawned a huge list of alternative, mostly non-interoperable IoT protocols. A partial list: 6LoWPAN, AllJoyn, AMQP, ANT+, Bluetooth, CoAP, DASH7, DDS, INSTEON, KNX, MQTT, NFC, RFID, STOMP, Thread, Weightless, XMPP, ZigBee, and Z-Wave. New consortia are popping up weekly with more ideas.

Searching for an IoT “god protocol”, one unifying end-to-end protocol serving all things, is silly. At one end, sensors have different requirements such as range, RF spectrum, security, topology, and power consumption. At the other, any successful IoT strategy will ultimately need to integrate with an IP-based cloud in some form. Greenfields of any scale rarely exist. IoT applications need to connect and exchange data.

The answer is building a multi-protocol bridge between sensors and actuators, mobile devices, and the cloud. Ideally, code would be open source, and would provide scalability to span a wide range of devices in large numbers. Additionally, transport would be reliable, surviving brief intermittency in wireless connections.

IBM Internet of Things Foundation

More and more organizations are embracing MQTT as part of the bridge. MQTT offers a full-up version running over TCP/IP, and a slimmed down version MQTT-SN for non-IP devices. Its publish/subscribe model allows topologies to scale while retaining real-time characteristics and configurable quality of service.

IBM started the whole MQTT movement as a message broker for mainframes and servers, with integration into WebSphere for web services. They then opened it up for embedded use in a release to OASIS and the Eclipse Foundation.

A big piece of IBM Bluemix is the IoT Foundation, a cloud-based instance of MQTT with predefined topic structures and message formats. Mobile apps are already using MQTT, with applications such as Facebook Messenger and Salesforce.com. IBM also has an e-book on MQTT in mobile.

Other recent developments to consider:

  • ARM’s mbed device server seeks to replace a generic web server with one tailored for the IoT. Built from technology in the Sensinode acquisition, ARM has brought HTTP, CoAP, and MQTT together in one platform.
  • 2lemetry has taken that a step further with ThingFabric, integrating protocol actors including MQTT, CoAP, and STOMP, along with extensibility.
  • PubNub has taken a websocket connections approach running over MQTT, focusing on low latency, reliable delivery from a cloud implementation. There is a good PubNub guest post on Atmel Bits & Pieces describing the approach.
  • Speaking of Atmel and Arduino, IBM has several recipes for leveraging Arduino with the IoT Foundation, such as an Arduino Uno connection example, and a series on implementing a cloud-ready temperature sensor.
  • Open source motivates many folks, and one of the more interesting individual projects out there is a bridge for AllJoyn to MQTT. If successful, the implications could be significant, such as controlling home entertainment devices directly from Facebook on a mobile device.

Again, I don’t think there is a “god protocol” that will take over the IoT once and for all, satisfying each and every use case. The winners are going to integrate multi-protocol bridges to serve as wide a range of use cases as possible. The ability of MQTT to connect sensors and mobile devices to big data systems in real time is drawing more participants in.

This post has been republished with permission from SemiWiki.com, where Don Dingee is a featured blogger. It first appeared there on November 5, 2014.

MQTT: M2M messaging for low-powered IoT devices

mqttMessage 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.

SmartDevice

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.

EmbeddedWatchPubNubTo 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.

Happy Hacking!