Bluetooth WiFi gateways offer MQTT and/or HTTP for sending data to servers/cloud services. We are often asked which should be used. HTTP is what’s used by your web browser to fetch and send data to web servers. In very high level terms, MQTT accomplishes a similar thing but is better optimised for mobile devices and the Internet of Things.
HTTP is very ‘chatty’ which means it’s more complex, code wise, to implement at the sending end and wastes a lot of data and processing power getting information from sender to receiver. You can think of HTTP as wrapping the data within lots other data that gets sent backwards and forwards. MQ Telemetry Transport Protocol (MQTT) came out of IBM, is now an ISO standard and uses lightweight publish/subscribe messaging. It requires a smaller code footprint at the sender and uses less network bandwidth. This matters most when you are trying to get the maximum transactions per second or are being billed for data use.
Bluetooth WiFi gateways are powered via USB and have reasonably powerful microcontrollers so MQTT’s efficient processing doesn’t matter that much. The more efficient processing is more applicable to apps running on mobile devices. For example, Facebook uses MQTT which saves battery life.
However, being lightweight, MQTT offers faster response times and lower data use than HTTP that, while not necessarily being of much of an advantantage for the BLE WiFi gateway, benefits the communications medium and server side. The communications medium, that can sometimes be cellular or be data constrained, uses (and possibly bills) less data. More crucially, the server can process more requests in less time. MQTT tends to be better when connectivity is intermittent, bandwidth is at a premium and throughput is critical.
In summary, MQTT has lower latency and is more efficient. Whether these are required advantages depends on your actual project. If you need more help, consider our development services.
Cybele bridges Bluetooth Low Energy devices to MQTT on Linux devices. MQ Telemetry Transport Protocol (MQTT), invented by IBM, is an ISO standard that uses lightweight publish/subscribe messaging to send data to a server.
There’s a new Linux script called Monitor that scans for the presence of beacons and other Bluetooth devices and reports to a MQTT server.
The mechanism doesn’t just scan for beacons. It combines name requests, anonymous advertisements and beacon advertisements to determine when to issue a name request to determine if a device is present and when to issue a name request to determine if a device is absent.
The author, Andrew J Freyer, provides instructions how to set up on a Raspberry Pi Zero W.
The INGICS iGS01S (WiFi) and iGS02E (Ethernet) gateways support MQTT to send data to a server.
MQTT defines three levels of Quality of Service (QoS) that relate to whether requests are resent if not acknowledged:
0 – The broker/client will deliver the message once, with no confirmation.
1 – The broker/client will deliver the message at least once, with confirmation required.
2 – The broker/client will deliver the message exactly once by using a four step handshake.
The INGICS gateways only support QoS level 0. This is because these gateways have lower memory and processing capability. They don’t have enough memory to queue unacknowledged requests required of other QoS levels. The extra processing would also significantly impact the performance and hence throughput.
If you need a higher MQTT service level then try the Minew G1 that supports QoS levels 0 and 1.
Our article on What are Beacons shows the kind of data sent by beacons. While this might be iBeacon or Eddystone, both are a subset of all Bluetooth advertising as sent out by all Bluetooth LE devices such as smartphones, Fitbits and even industrial machines. The Bluetooth LE advertising advertising is just a short series of numbers.
Gateways look for Bluetooth advertising and send this on to a web server together with the signal strength of the detected device, the gateway’s own Bluetooth MAC address and MAC address of the detected Bluetooth device.
In some situations a very large number of devices can be detected, most of which aren’t the ones that need to be detected. This can cause either the gateway to become overloaded or too much extraneous data to be sent to the server.
All gateways have ways of filtering what advertising is sent to the server. This usually includes matching some or all of the advertising with a given hexadecimal string and the ability to ignore devices weaker than a given signal strength.
Even after filtering, it’s possible in extreme circumstances that a gateway processes too many beacons and becomes overloaded. In these cases it’s important to have a gateway that can support the highest throughput. Gateway specifications detail the typical maximum number of devices that can be detected which varies considerably between devices. Ethernet connected devices tend to be more performant than those connected by WiFi. Also consider setting the gateway to only detect beacons close by and use more gateways per given area. Consider using MQTT in preference to HTTP so as to cause the gateway to do less work.
We have the new INGICS iGS01S Bluetooth WiFi gateway in stock.
The iGS01S is a new version of the iGS01. It’s functionally compatible with the iGS01 in that you can replace an iGS01 with an iGS01S and it will behave similarly. Hence, it’s also compatible with BeaconServer™ and BeaconRTLS™.
iGS01 gateways allow you to scan for nearby Bluetooth devices and send the scanned data up to a server, including AWS IoT, via TCP, HTTP(S) POST or MQTT.
The main change is the case which the manufacturer has changed to allow commonality of parts with the Ethernet version, the iGS01E.
We have the new Minew G1 gateway in stock. The G1 gateway collects advertising data from iBeacon, Eddystone, Bluetooth LE sensor and other Bluetooth LE devices and sends it to your server by HTTP(S) or MQTT/ using WiFi or Ethernet.
Special features of this gateway are that that it supports both WiFi and Ethernet and has a high throughput of up to 200 Bluetooth LE devices detected per second.