While designing an IoT device, there are multiple options to connect them. Once of the considerations should be the protocol being used to chat to other devices or to a server.
Previously, I would have easily chosen to make the interface REST based and have done so with Jeenode project a few years ago. But REST is not ideal as it is designed around a simple request/response model. So you ask “did my account balance change” and the response is returned “no it did not”. So you check again a few minutes later, and get the same response. Sound like a silly example? Actually we’ve learned that it is a very real issue that many customers obsessively check throughout the day, as many as 60 times inflicting a load on back-ends that they weren’t designed for.
REST via HTTP also wasn’t really designed to work on mobile networks. HTTP on mobiles is a bit heavy, fragile and slow and drains batteries quickly.
Andy Stanford-Clark and Arlen Nipper invented MQTT to solve a problem they had: how to do reliable messaging over unreliable networks? In an industrial environment with computationally ”challenged” devices, with restricted power due to solar or battery power, on extremely low bandwidth and often brittle RF communications including satellite. It had to work reliably, it had to use very few computational cycles, consume trivial power and could not hog what little bandwidth there was. And it had to be pub/sub so to break the cycle of violence being inflicted by heavy unnecessary workloads and bandwidth consumption due to all the request/response polling-based monitoring & control systems that were in place at that time.
So Arlen & Andy developed a very simple, extremely efficient publish/subscribe reliable messaging protocol and named it MQ Telemetry Transport (MQTT). A protocol that enabled devices to open a connection, keep it open using very little power and receive events or commands with as little as 2 bytes of overhead. A protocol that has the things built in that you need for reliable behavior in an unreliable or intermittently connected wireless environments. Things such as “last will & testament” so all apps know immediately if a client disconnects ungracefully, “retained message” so any user re-connecting immediately gets the very latest business information, etc.
Stephen Nicholas did a fascinating apples to apples comparison of MQTT vs HTTPS on Android, 3G and WiFi which you can read here. The 3G results are quite interesting:
- 93x faster throughput
- 11.89x less battery to send
- 170.9x less battery to receive
- 1/2 as much power to keep connection open
- 8x less network overhead
Initial versions of MQTT have been sending plain information over networks. In V3.1 you can also pass a user name and password with an MQTT packet of the protocol. Encryption across the network can be handled with SSL, independently of the MQTT protocol itself (it is worth noting that SSL is not the lightest of protocols, and does add significant network overhead). Additional security can be added by an application encrypting data that it sends and receives, but this is not something built-in to the protocol, in order to keep it simple and lightweight. These security features are especially meaningful when the IoT thing is running in e.g. a cloud scenario, in which the thing sends and receives data through the public internet.
SAP, eager to also claim its part in the IoT domain, unfortunately has not really shown any signs of offering MQTT on any of its services yet. It is currently being investigated, but nothing concrete has trickled down yet:
— ruinogueira (@ruinogueira) January 26, 2015
It is really a pitty that SAP is not supporting MQTT yet, as this would require a MQTT to HTTP bridge to collect messages from things into the SAP HANA Cloud. As the MQTT protocol is mature and secure enough to be used over the public internet, I think SAP should also support this IoT standard, especially given the fact that SAP wants claim a good chunk of the IoT domain. I could think of hooking up MQTT to e.g. SAP’s HCI, but perhaps this would also be a good business case to get ESP (Event Stream Processing) to run on the HANA Cloud Platform