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.
Learn about Beacon Proximity and Sensing for the Internet of Things (IoT)
Read about Using Bluetooth Wireless Sensors
We now stock the iGS01 holder:
It allows the iGS01 to be easily mounted on a surface such as a wall. You push the iGS01 on and can prise it off again by inserting a flat screwdriver between the two.
Read about Beacon Proximity and Sensing for the Internet of Things (IoT)
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 consultancy and software development services.
Both the iGS01 and the Wireless iBeacon Receiver support MQTT. Brian Boucheron has written a recent article on How to Install and Secure the Mosquitto MQTT Messaging Broker on Ubuntu 16.04. It shows you how to install Mosquitto, retrieve SSL certificates from Let’s Encrypt and set the broker to use SSL to provide secure password protected MQTT communications.
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.
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.