Free up to 1MM monthly messages. No credit card required.
At PubNub, we’ve learned a lot from IoT customers like Samsung, August Home, Wink, and Logitech about the types of features they require. We’re excited to announce that we have taken all our expanded PubNub Data Stream Network (DSN) features, like Functions, topic wildcard support, and simple setup, and have made them available to our customers with MQTT devices.
It is now super easy to integrate MQTT devices into the PubNub DSN. No code changes are required; simply put your pub/sub credentials into your device identifier, and PubNub takes care of the rest. This blog will walk you through the steps involved in this integration.
If you aren’t familiar with MQTT, the Message Queuing Telemetry Transport (MQTT) is a publish/subscribe protocol aimed specifically at low-powered embedded devices. MQTT targets low-powered embedded device environments where resources are scarce, and strives to reduce battery, CPU, and bandwidth consumption.
Originally developed at IBM, MQTT has picked up a lot of traction in the IoT industry, especially for its lower power requirements. There are plenty of documentation and open source client implementations if you wish to dive further into the protocol itself.
You may already have deployed MQTT-based devices. Or you may be considering a new IoT deployment. Either way, the question arises, “When should I use MQTT, and when should I use PubNub?” And when does it make sense to use both? If you are considering robust, bi-directional communication options for your MQTT-based devices, PubNub provides enterprise-grade security, scalability and reliability, and many value-added features too, like functions-as-a-service and message storage and playback. The PubNub DSN is available worldwide with <100ms latency, and can scale to support all your Internet-connected devices.
Like the proverbial peanut butter and chocolate, PubNub and MQTT together can elegantly solve many embedded device use cases. You can leverage PubNub with MQTT to satisfy use cases like low-latency, efficient anomaly detection, and integrating to machine leanring services.
If MQTT is not part of your current infrastructure, you might consider leveraging the PubNub DSN directly along with PubNub’s numerous IoT SDKs for all of your Internet of Things connectivity. Or the PubNub DSN with MQTT can be a great choice for low-powered devices.
So let’s dive into the details. How do you use MQTT with PubNub? We have recently built out a much more scalable MQTT interface, with support for TLS security, topic wildcards, and more. In the steps below, we use MQTT.fx to simulate an embedded MQTT device, but any MQTT-supported client would work.
You’ll first need to sign up for a PubNub account, and get your unique publish and subscribe keys. You can get your keys in the PubNub Admin Dashboard. When using PubNub, you simply create channels (aka, “topics” in the MQTT world) and publish messages across those channels with those keys. You’ll do the same with MQTT.
The only two things you need to do to connect your device to the PubNub Network are:
1. Use a broker address of mqtt.pndsn.com. Use the standard ports – 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>
Once you’ve set up your MQTT client, initiating a “Hello World” demo should be pretty straightforward. If you’re using MQTT.fx, you can connect to the PubNub Network at mqtt.pndsn.com, and publish a “Hello” message from the client in the “Publish” tab. If you then go to the PubNub Admin Dashboard, you will see “Hello” published.
View from MQTT.fx
View from PubNub Admin Dashboard
Composing Message Back to MQTT Client
If you are experiencing any problems with this Hello World-type initialization, check the channels in the PubNub Admin Dashboard to ensure they match the topic set up in the MQTT client.
PubNub’s MQTT support includes topic wildcard support, so developers can leverage the application flexibility within the MQTT protocol.
When you set up wildcard support in MQTT, you use “/”, but in PubNub you use “.”. So 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. The single-level and multi-level wildcard nomenclature remains the same, respectively “+” and “#”.
Here are examples of wildcard subscriptions from the PubNub Admin Dashboard:
// Single-level wildcard will be translated to: .* /+/sensor
// Multi-level wildcard will be translated to: .house.sensor.* /house/sensor/#
Note that PubNub only supports QoS level 0 at this time. Good luck with your IoT/ MQTT initiative!
A Notice of Privacy Practices (NPP) is one of the requirements of HIPAA and helps patients understand their personal data rights.
HIPAA violations can be financially expensive and devastating to a brand. Examine some examples of HIPAA violations, and learn...
HIPAA covered entities must follow the five technical safeguards to achieve HIPAA compliance and prevent data corruption.