Common IoT Integration protocols: MQTT, WebSockets, and APIs
In previous articles, we've discussed what makes IoT tick at the physical and MAC layers. That provided a good overview of where they should be applied — but is only one part of the overall puzzle of your IoT deployment.
As engineers, it's important to have a good overview of the entire system, not just one part. We don't have the luxury of saying "Well, it's transmitting, it's (X department's) problem now." To that end, let's talk about what happens AFTER that gateway into the network. Your 802.15.4 device uses the same protocol to transmit up until it hits the gateway, but then what governs it after?
MQTT Means MQTT
MQTT has had a bit of a fraught naming convention. We won't go into the details here, but you can read about it here instead. What you need to know is that the name, since 2013 anyway, is just a name and you don't have to worry about what it stands for. What it IS, however, is a publish-subscribe model protocol that's specifically intended for bandwidth-constrained networks.
MQTT is useful in that it will "ride" on just about any modern transmission medium, even though it usually functions via IP. MQTT functions with a central server, called a "Broker" publishing messages to a single, or group, of clients that "subscribe" to certain categories of messages referred to as "topics". This is generally the publish-subscribe model as used in other similarly architected solutions, but is important to understand in MQTT.
Interestingly, the publishing entity (The one who SENDS the first message to the Broker) has no logical connection with the receiving Subscribers. It is completely destination-agnostic and at no point receives the information from the Subscribers. The message instead goes to the Broker, who then checks against a list of who has subscribed to that topic. The message is then sent to the clients who subscribed to it.
An easy example of this would be in home automation- imagine your phone sending "Alexa" a message "lights on". The message goes from you to Alexa, who then would send it on only to "lights" with the message "on". The lights, then, do not NEED to respond, only to process the message.
They also absolutely do not care where the message came from, only that it exists. They see only something like [If they receive message "On", then set "light power" to "1"] or something similar.
They can, however, also generate a NEW message set to send to the "managers" group. The contrast here would be you flipping the light switch, which would be more analogous to you simply sending a direct, unacknowledged message to the light to turn on.
MQTT has a fairly simple set of "message" actions to facilitate this, repeated and iterated across publishers and subscribers.
Connect. A request to build a connection for communication. Followed by a "ConnAck" to acknowledge.
Publish. Sends data on the thread to the broker to be distributed. This can ALSO be management data. The broker can and does subscribe to management topics. Unlike wifi, there isn't a dedicated "packet" for this, it uses the architecture that is already in place.
Disconnect. Informs the receiving agent that it would like to close the connection, and after receiving a reply, the TCP/IP (or equivalent) connection closes.
Websockets: HTTP+!
Websockets, as you may have guessed from the title, is a protocol that is widely used from HTTP or HTTPS. It provides a way for a computer to talk to a different computer through a more friendly and less specialized (from the user POV) interface. Chances are that you've used websockets many times without even realizing it. It will most of the time just kind of… work in the background.
Websockets use a bit of the HTTP packet called the HTTP Upgrade header to enable itself, creating a consistent, persistent connection between the two devices. Usually a web server and your computer, but it can be linked otherwise if you're clever. The important takeaway from websockets is that it contrasts with MQTT that we just discussed. MQTT is publish-subscribe and closes the connection when the message is done, Whereas websockets is a polling-based protocol and keeps the connection open, enabling real-time content transfer.
It sounds simple, to provide, say a real-time chat or streaming video, but there are intensely interesting applications. Also, remember if the data is being streamed to your device, you get to throw that data away into the digital void when it's done. Imagine if you had to store every movie you ordered on Netflix on your computer and manually delete them.
Here are some common websockets use cases:
Social media feeds. Constantly updating feeds attached to HTML. It would be chaos if every single post was a push request.
Live chat, such as for games or companion apps. You don't want to wait for an update cycle to know that you're being flanked. We require more instant updates.
Collaboration applications. It's so much more useful to have a document with multiple editors updating NOW. Imagine spending an hour writing an article about wireless IoT and someone deletes your middle paragraph.
APIs: What ISN'T an API?
Okay, APIs are a fun one. Everything these days has, or is, an API it seems. Part of the problem is definitional. API stands for application programming interface. The problem arises when you apply that definition exactly: it's just an interface. Not a user interface (UI), but an interface.
Twitter operates an API to get your tweets, Doordash has an API to be embedded into web pages, Outlook has an API to check your calendar, fill your calendar, and serve you alerts about that meeting you're totally, for sure, definitely going to be there for.
APIs are interesting in that they primarily connect things, and enable all kinds of crazy use cases. If you need to grab data from something, and put it somewhere else, you can use an API. Think of it kind of like the front desk person at a mechanic's.
They don't want you in the mechanic's bay where they're working, but you also want to know what's going on. Ideally, you ask the desk for status, and they go ask the mechanic and report back. The mechanic wants to know what you want to do, so they ask the desk, and the desk asks you. Say you want to know how much it costs, the front desk finds out from the manager.
The front desk here is your API, connecting you to resources it may be less convenient or impossible for you to access by yourself. It's much more convenient for you to simply request something (or it is automatically shown to you) than manually sorting through all the data.
MIST systems have a fantastic relationship with APIs in the access points and controllers. If you want data, They have an API for that, and they support you pulling just about any metric they generate down to display it, however, and however often, you like. We highly encourage new WLAN and IoT engineers to try to give MIST a shout and get a trial access point simply to be able to play in such an available API sandbox.
delivered to your inbox.
By submitting this form you agree to receive marketing emails from CBT Nuggets and that you have read, understood and are able to consent to our privacy policy.