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.
We have a new INGICS gateway, the iGS02, in stock that uses Ethernet rather than WiFi. This allows it to be used where WiFi isn’t present or where it’s considered that data needs to be sent via a more reliable wired connection. The use of Ethernet also allows for a greater throughput detection of up to 70 beacons per second (with MQTT).
The iGS02 comes with a POE adapter allowing it to be powered from the Ethernet connection for networks providing POE. Alternatively, it can be powered via the USB connection.
The MQTT/HTTP output is the same as the WiFi-based iGS01 allowing these devices to be used interchangeably.
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 IGS01 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.
Our Bluetooth WiFi gateways offer MQTT and 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.
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.
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.
We have the new iGS01 Bluetooth WiFi gateway in stock. This gateway automatically detects iBeacon and Eddystone beacons and passes on the raw advertising data via WiFi to your desktop, server or cloud service. It can be used to create systems that do things when they detect beacons or when beacons are no longer present. Alternatively it can be used to monitor beacon battery levels or sensor data where these are present in the Bluetooth advertising data.
Advertising data can be filtered by RSSI and advertising data pattern. The data can be sent via HTTP (POST), TCP or MQTT. The unit is powered by standard micro-USB.
The iGS01 provides a software-free way of getting beacon sensor data into the cloud for IoT applications.