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

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

At small scale (not many sensors) or when the sensors have plenty of power (CPU and electrical), or communication cost is low then there's less reason to use MQTT. Conversely at large scale, or for CPU/electricity-limited sensors or when comms cost is high then MQTT or similar IoT protocol has advantages. You can implement MQTT in a very simple embedded CPU, more complex to implement HTTP.

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

You would save battery power using e.g. MQTT over e.g. 3G because there is less protocol overhead from publishing MQTT data over a persisting TCP connection from MQTT client to broker then there is for every REST POST which usually requires establishing an SSL connection, posting the data using verbose HTTP, then deleting the SSL connection.

An MQTT connection is inherently bidirectional (although your app doesn't have to use it) - so you natively get the ability to send commands to your sensors. To do the same using REST/HTTP you have to configure your server for long polling.

There is a comparison of long-polling HTTPS vs MQTT over SSL here http://stephendnicholas.com/posts/power-profiling-mqtt-vs-https which shows ~4.1% battery power/day saved using MQTT compared to slow-polling HTTPS So yes, you can save significant battery energy.

With MQTT you can send very small messages e.g. a few bytes of binary data, with low overhead. With REST/HTTP the data gets wrapped in a lot of HTTP protocol with much higher overhead. If you have lots of devices those overhead bytes add up to a lot more data being sent, which costs money. So at large scale using a compact protocol like MQTT and designing the data transfers carefully saves you money.

gather data every minute

With MQTT your app usually has a persistent subscription to the topics and is automatically notified of updates. If you want a summary every minute your app will save the updates to e.g. a DB and report from the DB. DB is usually needed to store all the data anyway. You can subscribe to wildcard topics - this means you design your topics so your app subscribes to e.g. all solar sensors and the broker will send data for all the connected devices without your app having to poll the individual sensors.