When a Bluetooth WiFi Gateway sends data to a server via HTTP, the gateway has to connect to the server to start a connection and then use that connection to send the data. The connection part starts a new TCP connection with handshaking. Starting a new connection every time data needs to be sent to the server uses network data and creates work for the server.
Some gateways such as the IGS01s have a ‘keep-alive’ setting that allows the connection to be re-used across HTTP requests. This reduces the amount of data used on metered networks such as cellular, reduces possibly metered data throughput at the server and also reduces server loading thus improving performance.
Having said all this, you should consider MQTT if you are really concerned about efficiency and performance.
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.
If you are rolling out many gateways, there comes a time when you start wondering if all of them are working and connected. While it’s possible to write a server side script/code to detect whether or not data has been received from the gateway in the last n seconds/minutes, this doesn’t work when there aren’t any Bluetooth devices in the vicinity of some gateways which won’t be sending payloads.
The INGICS gateways have a way of setting up a heartbeat that’s a dummy payload used to indicate a gateway is working and connected. It’s set up by telnet to the gateway and issuing the following command followed by a reboot:
> SYS HEARTBEAT 1 > REBOOT
The ‘1’ signifies every 1 minute and allows setting up to 255 minutes. A $HBRP data payload is to the server in the form:
The heartbeat functionality is available on firmware IGS01-v2.0.0 and IGS01S-v2.0.0 or later.
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.
The majority of beacon-based solutions are app-based and trigger information to be displayed to the user in response to being near specific beacons. If you read many platform provider sites you might think that’s all beacons can do. However, beacons are a technology and not solution. Beacons provide for many types of solution.
Another type of solution is the accounting for things (with beacons attached) within a larger system. Examples include class registration, stock checking, asset tracking, security and lone worker positioning. In these cases the thing that detects beacons can be can be an app or hardware.
The app can be relatively simple and scan for particular beacons and save information to a file and/or send them on to server. We recently implemented such a system for Malvern Instruments, with custom pre-configured beacons, that also allows search for particular ‘lost’ beacons:
In the cases where the beacon detection doesn’t or shouldn’t move around, it’s possible to use gateways to forward on detected beacon data to a server.
IGS01 Wifi Beacon Gateway
Several of our clients are using this type of architecture to provide for automatic human registration/rollcall type solutions.
We believe even greater opportunities exist for IoT scenarios where sensor data in beacon advertising can be automatically forwarded on to servers.