18

Assume that there are numerous weak sensors (e.g., Arduino level devices) which rely on BLE as means of communication and that these devices are connected to a more powerful gateway (e.g., Raspberry pi level of devices).

I would like to know if MQTT is considered an appropriate protocol for transmitting their readings (short, frequent bursty messages).

A number of blogs/documents consider MQTT appropriate for "IoT applications" because it is light(er) weight when compared to HTTP and conserves power. However, to my understanding it requires a connection be be kept open which is not the case with BLE or other communication protocols appropriate for IoT. BLE does not maintain the connection open for prolonged periods of time to reserve energy. Apparently, MQTT is appropriate when a MAC layer protocol such as WiFi is used. This almost breaks the rationale behind using MQTT in the first place (i.e., if the device computably handles a protocol such as WiFi then it might not need a protocol such as MQTT). Do you see a flaw in this logic?

Is there any alternative application layer protocol for that purpose? What is the most frequently seen structure of these type of messages (e.g., raw binary data, JSON, XML) when they communicate with a gateway and when they communicate with a server directly?

dr.doom
  • 281
  • 1
  • 2
  • 4

2 Answers2

16

MQTT has to run over TCP/IP (I can't remember if it's actually in the spec or if just enough assumptions are made to make it so) but its sister protocol MQTT-SN can be run over nearly any protocol that can pass data, I've seen implementations in UDP and serial.

Having said that I'm not sure what you gain by running either over BLE, BLE's built in Characteristics offer much of the same benefit (if only on a 1 to 1 basis) with things like notification.

I think one of the important thing to remember is what the "I" stands for in IoT, it's implies access to the Internet at some point (even if it's a gateway device or phone). At that point MQTT can be very useful, but it doesn't necessarily mean all the way to the (bleeding) edge.

Aurora0001
  • 18,520
  • 13
  • 55
  • 169
hardillb
  • 12,813
  • 1
  • 21
  • 34
11

Arguably, you'd be better off doing a simple mapping of the data from BLE paradigms to MQTT, rather than trying to literally send MQTT over BLE.

BLE generally exchanges data in the form of characteristics. These have various BLE-unique mechanisms for discovering value change that you may find useful. But they have a maximum data length of 20 bytes.

It is possible to stream serial data over BLE, moving 20 bytes at a time. This is sometimes done to implement a virtual serial port, and you could tunnel full MQTT through this.

But you'd probably do better to use a collection of BLE characteristics to carry the data of different topics, and have a bridge which maps the characteristic identity to an MQTT topic and maps the value to the MQTT payload.

BLE has its own sense of ongoing connected sessions vs. non-connected ones. Likely you should figure out what usage of BLE is best for your application, and then map this to the MQTT sense of maintaining a connection.

You should be able to do this in either or both directions: BLE->MQTT and MQTT->BLE

Chris Stratton
  • 1,898
  • 8
  • 18