As we’re moving towards a more connected and smarter tomorrow, a plethora of existing communication protocols, as well as new and developing protocols are paving the way for millions of new potential devices in the ever-expanding IoT world. The problem we are faced with is that these devices often don’t have the capabilities to connect to the Internet directly themselves.
So, how to bridge the communication gap between a device without IP connectivity and the Cloud?
On WolkAbout IoT Platform, we created a separate device type called gateway that is responsible for providing connectivity to an unlimited number of devices that pass information through them. These gatewayed devices often have a different business logic role, which is why only the gateway is registered directly on WolkAbout IoT Platform, while gatewayed devices are registered on the Platform by the gateway itself. The gateway handles registration and deletion requests from its subordinate devices, routes data between devices and the Cloud, and is also responsible for updating the platform with the current state of all devices. Furthermore, if a gateway changes to an offline state, the offline state will be propagated to all subordinate devices.
Our solution was to introduce an IP-enabled gateway that communicates with modules. These modules are fitted with the means to talk to non-IP-enabled devices via their supported network communication protocol, such as Bluetooth, Modbus, Z-WAVE, etc. The information is routed from the Cloud to the gateway, and then through a local bus to a module that will establish a link to the device. This gateway is also suitable for the cases where a single exit point for a group of devices is preferable. This solution provides scalability as well as higher system distributability, as modules can be easily added to or removed from an existing gateway infrastructure. We named this solution WolkGateway.
Fig.1 - WolkGateway Architecture
WolkGateway is our open-source software library meant to speed up anyone who wants to connect their gateway to WolkAbout IoT Platform. The library is essentially divided into two parts:
Main Connectivity Module with its bus - this part of the library is responsible for handling registration and deletion of requests from its subordinate devices and handling all traffic through the use of its local broker. It also buffers readings it receives from its modules before sending them to the Platform, and handles the process of device firmware update. This module can also have its own data that it will send to the Platform.
Modules - enable communication with any number of subordinate devices by implementing the device’s network communication protocol on one end and parse data between the MCM’s local broker on the other end. The user is responsible for providing the implementation of the device’s network communication protocol, but all the communication that is directed towards the MCM is already contained in this SDK.
Fig.2 - WolkConnect - Gateway Module Architecture
So how would a potential use case look like? Let’s say there is an existing working process, maybe a manufacturing process. These kinds of processes often have an industrial PC to which the main connectivity module of our library could be deployed. PLCs would require an external PC or something of the sort in order to communicate with them. What’s left is to implement a module that will extract valuable information from the process and forward them to the bus, thereby giving a direct insight into the state of the process, or even control over it from the Cloud.
If you need more information on this topic, feel free to contact us at this link.