Why/when to use IoT publish/subscribe protocols rather then RESTful HTTP?

Question

I am sending data (GPS coordinates) from Arduino once a minute with HTTP POST request to REST API (in OpenShift PaaS). Data is then stored to MySQL db.

Would so called "IoT" publish/subscribe protocols (XMPP, MQTT) be better? Why?

When exactly do you use those two protocols rather than Restful HTTP? Would I really save a significant baterry energy using them?

AFAIK in those protocols machine would "publish" a data to broker and my app would subscribe to it. If I would like to gather data every minute in my app I guess that I would got to have some CRON job that would subscribe to data every minute? Or how would data gathering be achieved?

Answer 1

In my experience ReST is good for real-time data transfer and processing but has a lot of overhead for simple message passing. Plus, there's no queuing in it so store-forward configurations are troublesome.

MQTT is a message queue transport system where the message can be placed on the channel by the publisher and will stay there until the subscriber picks it up. So you can have some rudimentary store-forward capabilities with this. Also MQTT is more transparent and multicast so communicating to many nodes is no different than communicating to one.

With that, each have their place and use and ReST is great for sending large items (JSON blobs), sending data for calculation and getting it back, and for requesting a specific dataset. MQTT is more for "here's my sensor data every second, enjoy".

Answer 2

Basically, MQTT reduces latency where there's relatively high latency like Wi-Fi by keeping the TCP connection alive so that data can be published and received very quickly. It uses port 1883 and not 80. As I understand it, the publishers and subscribers connect once to the broker and then ping the broker regularly to keep the connection alive; how often the broker is pinged depends on the pre-agreed keep-alive period. MQTT packets are also significantly smaller than HTTP requests. If the connection is somehow broken, the client repeatedly tries to re-establish the connection and when successful, the subscribers re-subscribe.

Subscribers define callbacks that are called after a topic has has been updated by some publisher. MQTT is best for time-critical jobs where HTTP requests would just take too long and where quick notification of changed topics is desired. I'm not sure but it will probably consume more battery power, since there's that matter of a constant TCP link to the broker.

Since you're only expecting data updates every minute, I think it makes more sense to connect and GET the feed data from the server every 60 seconds. You can use the feed's Last-updated time-stamp (if it doesn't exist, create one) to check if the feed has been updated by the Arduino yet. An MQTT technique would just spend most of the time connected to a broker for no reason since you already know that the update events occur every minute; that is a significant amount of time and power spent waiting for predictable data.

However, you could wait for about 55 seconds, subscribe to the topic and when you get the new data, you disconnect and then wait for 55 seconds again, though I dont know if this will be much of an improvement over REST. If you use this method, you can also set the keep-alive period to be just about 10 seconds, so that the Arduino has enough time to update the feed before your app is notified and there's no need for regular pings.

If you decide to go with MQTT, check out this Arduino library.

Answer 3

(shameless self-promotion) I did a talk on iot stuff this year at our local code camp. Notes are here: https://github.com/adbacker/bcc2016/blob/master/2016bcc-iotonthecheap.pdf

Super simplified per my limited experience: (experts correct at will :-) )

MQTT protocol:

requires a broker

maintains a connection to the broker (which allows for push notifications back to the device)

was specifically designed for "small footprint" applications (read: limited RAM and processing power)

MQTT is optimized for sending simple data. GPS coordinates would be a good fit. I'm sure MQTT could be used to send complex data (ie: large json objects) but that doesn't seem to be what it's designed for.

You're not looking for push notifications back to the device, nor are you maintaining a connection to the REST server so (from a practical standpoint) I'm guessing your battery life improvement would be minuscule at the very best converting the solution to mqtt.

Adafruit has a pretty good mqtt tutorial and libraries, as well as a beta service that provides broker services: https://learn.adafruit.com/adafruit-io/mqtt-api

Also, for super-duper-easy IOT setups (that admittedly use a custom protocol), let me recommend blynk. ( www.blynk.cc ) It's free and so easy I rewrote my entire presentation around it. Additionally, there are (free) blynk ios and android apps that allow creation of custom dashboards that communicate (via the also-free blynk broker) with your device of choice. If you host the broker server (also free) yourself, it has it's own REST api that allows data access to/from your device.

Answer 4

In my applications, the biggest power drain is turning on the radio to transmit data. I often keep the radio off, collect data points, and then turn on the radio to send multiple pieces of data together as one request using a RESTful HTTP call. For my case, RESTful HTTP is way more efficient since I do not need an always on connection.