Home / Technology / Device Hub / Gateway
IoT Gateway
Our plug-and-play gateways are a robust solution to automatically capture data from Bluetooth devices, connect devices in locations with bad mobile reception, or to minimize required user interaction. The Linux based software can be deployed on any compatible hardware.
Deploy Anywhere
Run the Linux-based gateway software on your existing hardware, off-the-shelf Raspberry Pi boards or integrate it with your mobile application.
Plug-And-Play
The Rapsberry Pi gateways only need to be plugged in and get access to your local Wifi network - that's it. Everything else is automatically managed by the Device Hub.
Self-Recovering
Gateways will recover themselves after potential power losses. In combination with buffering data on devices, this will minimize the risk of losing any data.
Over-The-Air
The bootloader is ready for firmware-over-the-air distribution to stay updated. The gateway works seamlessly with the Device Hub for monitoring and remote configuration.
Roaming
In combination with the Device Hub, our gateways are capable of roaming. The Device Hub will coordinate connections while a device travels through the gateway network.
Interested? We integrate our gateway software for your devices and mobile applications.
Deployment.
Stand-alone Hardware vs. Mobile Application
The flexibility to deploy our software as part of a mobile application or on stand-alone hardware allows you to choose the best solution for your specific use case.
Stand-alone hardware is a great solution for cost efficient, reliable and automated data collection – no mobile phone settings, user mistakes, software updates or battery life can interfere.
Mobile applications provide a communication channel, which can be a requirement for journaling, notifications or consultations. You can cut down on hardware cost by allowing users to bring their own phone. However, this will increase your software maintenance cost significantly, since you need to ensure compatibility with a multitude of hardware models and ever-changing operating systems. In any case, you will have to rely on users to keep their phone charged and to enable all functions required for a seamless data transmission.
Deployment on Stand-alone Hardware
For many applications, we recommend to use off-the-shelf hardware like the Raspberry Pi Zero W to deploy the gateway software. This is a very cost-efficient way to create a bi-directional connection between Bluetooth devices and a Wifi network within buildings.
In combination with the Device Hub, this allows Bluetooth devices to automatically receive updates or send data as soon as they come within reach of a gateway. While it is out of reach, data needs to be buffered on the device. If there are multiple gateways within reach of a device, the Device Hub will coordinate the roaming.
Integration with Mobile Applications
If your use case requires a mobile phone for user-device interactions or as a communication interface for alerts and statistics, it makes sense to use that mobile application as a gateway.
We can integrate our gateway software with your existing mobile application. This allows you to distribute firmware updates to your device via the mobile phone without the need to update the mobile application itself. At the same time, you can monitor your devices and route device data to your database.
As best practice, we recommend sending data end-to-end encrypted from the device via the mobile phone to your secure database. From there, data and analytics results can be shared back to the mobile application as far as required.
How It Works.
Standalone gateways need to be setup once with the local Wifi network.
A lean mobile app for the setup workflow is available. Alternatively, this workflow can be integrated with your existing mobile application.
Users scan for gateways within reach and select the gateway to be set up. Next, they scan for available Wifi networks, select their network, and provide the network credentials. After this, the gateway will re-connect automatically after an eventual power loss.
Everything else is set up on the Device Hub, which includes device-gateway assignment and roaming.
The Device Hub monitors gateway activity and data streams to ensure reliable connectivity for your devices.
For each gateway, an event log is kept for trouble shooting and customer support. You can set notifications in case a gateway does not connect for a certain time to intervene and prevent data loss.
Other than gateway activity, you can check gateway-device connections, connection errors, visible devices to connect with and the gateway firmware version.
The gateway software is ready for secure firmware-over-the-air updates, including version roll-back when an update fails.
In case the gateway functionality is integrated with a mobile application, that application will have to be updated itself to update the gateway software.
Gateways can be used to update the devices connected to them. Those devices can reach the Device Hub via the gateway to request and download updates. This also works, if the gateway is part of a mobile application, meaning that the mobile application itself doesn’t have to be updated to update a connected device.
As a consequence, you can implement automatic and secure over-the-air updates to complete bluetooth device fleets e.g. by placing a gateway at the device maintenance site.
In combination with the Device Hub, gateways create a powerful network to automatically capture, coordinate and enrich data streams from devices, which would otherwise not be able to communicate via the internet.
We recommend to implement end-to-end encryption between the device and the database. For Bluetooth devices, this means to dispend with standard Bluetooth protocols and implement custom encryption e.g. based on TLS. The gateway only serves as a pipe and is completely interchangeable, allowing devices to roam between an unlimited number of gateways. Standard Bluetooth features only allow secure point-to-point connections, meaning the device would need to maintain a list of credentials for all gateways it wants to connect with.
Once data can be interchanged with the Device Hub, all related features become available. Enrich data with metadata (e.g. which settings were used for the measurement), data gapping and real time analytics.
- Size: 8cm x 4cm x 1cm
- Connectivity: 802.11 b/g/n wireless LAN, Bluetooth 4.1, Bluetooth Low Energy (BLE)
- Hardware: 1GHz single-core CPU, 512MB RAM
- Interfaces: Mini HDMI, USB On-The-Go, Micro USB power in, status LED
The following requirements need to be fulfilled to deploy the gateway software:
- Supported platforms:
- Linux
- MS Windows
- MacOS
- RAM:
- 100MB (python scripts only, no data storage -> stateless)
- Software:
- Python 3.5 or later
- Temporary files (can be backed to tmpfs)
- Supervisor to launch and keep the software running (we use supervisord, but any other supervisor should work)
- External script that can be triggered to install updates
- Access to a network to communicate with the Device Hub (LAN, WLAN, …)
- Watchdog to reboot the system, if it gets stuck (e.g. due to interrupted WiFi connection)
- Software Lifecycle Management:
- Over-the-Air updates are supported via the Device Hub (given the system allows for it) and can be delivered in a container (e.g. Docker)
- BLE Backend – One of the following needs to be available:
- Native Linux: DBUS, python3-gi (required to access DBUS), access to Bluetooth radio via bluez 5.43 (using DBUS interface of bluez)
Note: Only bluez version 5.43 has been tested - Cross-platform BLED112 Dongle: The BLED112 is an inexpensive dongle that implements the BLE stack on-chip and provides a USB serial interface. It works with Linux, MS Windows and MacOS. It has a generic USB serial driver in the kernel, which works out of the box in standard distributions provided the access permissions for the serial device are given.
- Native Linux: DBUS, python3-gi (required to access DBUS), access to Bluetooth radio via bluez 5.43 (using DBUS interface of bluez)
- Interface for WiFi configuration mobile app (Native Linux):
- DBUS
- python3-gi (required to access DBUS)
- Access to Bluetooth radio via bluez 5.43 (using DBUS interface of bluez). Note: Only bluez version 5.43 has been tested
- Bluetooth radio must support peripheral role
- Access to wpa_supplicant via DBUS to configure the WiFi interface
- NetworkManager must be disabled
- Note: Alternatively, the WLAN can be pre-configured during gateway commissioning
- Note: If certificates for network authentication are required, they need to be pre-installed during gateway commissioning
Adding Value To Your Business.
Explore implemented use cases of our technologies and services and how they are making a difference today.