The MQTT standard was originally invented by IBM to efficiently transfer data between embedded systems. In 2010, IBM released a royalty-free version of the MQTT standard. The MQTT 3.1.1 standard became an OASIS standard in 2014. Today, developers routinely use MQTT for connecting IoT devices.
Why Use MQTT? Why Not HTTP?
HTTP and MQTT were designed to accomplish different tasks: MQTT is optimized for data. HTTP is for documents.
HTTP uses a request-response method to transmit documents. Both the server and the client must be available. HTTP is extendable and you can adapt it to your needs, but the flexibility often becomes a burden on mobile or IoT devices where power usage, efficiency, and limited connectivity are concerns.
MQTT uses a publish-subscribe method to send data. Clients can publish messages to topics and subscribe to receive updates as they happen. MQTT requires an intermediary, called a broker, to handle queuing and transmitting messages. Clients can come and go without disrupting the ability for messages to be transmitted and MQTT is designed to be lightweight.
MQTT is perfect for limited connectivity situations commonly encountered with IoT.
PubNub provides an MQTT gateway that allows you to use all the features of our Data Stream Network, like Functions and wildcards, with MQTT. PubNub replaces using a broker for transmitting data with MQTT. PubNub maintains synchronized global Points of Presence (data centers) that can transfer data anywhere in the world with an internet connection in under 0.25 seconds. PubNub is great for latency sensitive applications.
Serverless IoT with PubNub Functions
PubNub offers a serverless environment to execute functions on messages as they route through the PubNub Network. You can incorporate logic like re-routing, augmenting, filtering, transforming, and aggregating data.
The Blocks Catalog is a growing collection of prebuilt microservices for enhancing your Internet of Things deployments.
PubNub has partnered with dozens of leading companies to provide easily integrable partner Blocks. You can initiate image recognition, visualize data, analyze sentiment, and more.
Getting Started with MQTT and PubNub
- First, you’ll need to sign up for a PubNub account. Once you sign up, you can get your unique PubNub keys from the PubNub Admin Dashboard. Sign up using the embedded form below:
Next, download MQTT.fx. We’ll use MQTT.fx to examine how the PubNub MQTT gateway works. This client simulates a device. Any other MQTT client would also work.
Add a new connection profile with the following:
1. Use a broker address of
mqtt.pndsn.com. Use the standard ports for MQTT – for unsecured connections use
1883, for TLS secured connections use
8883 – both are supported.
2. Use a client ID composed like this:
<publish_key>/<subscribe_key>/<actual device ID>
Go back to the ‘Publish’ tab and enter “test” for the topic. Enter some text in the text area. Click ‘Publish’. If you go back to the ‘Subscribe’ tab you’ll see your message.
Channel / Topic Wildcards
PubNub’s MQTT support includes topic wildcard support.
If you have not already, enable the Stream Controller add-on, then click the ‘Enable Wildcard Subscribe‘ checkbox.
When you use Wildcards with MQTT and PubNub, you must use
/, but in PubNub you use
.. If you want to provide access across the a channel / topic, you would type
a/# in the MQTT client, but
a.* in the PubNub Admin Dashboard or any applications using the Data Stream Network SDKs. The single-level and multi-level wildcards are the same, respectively
Wildcard subscriptions examples:
// Single-level wildcard will be translated to: .* /+/sensor // Multi-level wildcard will be translated to: .house.sensor.* /house/sensor/#
Like this post? Check out How Industrial IoT and PubNub Can Be the Future of Predictive Maintenance.
Have suggestions or questions about the content of this post? Reach out at firstname.lastname@example.org.