D2000 and IoT

Image Description

Peter Humaj

June 16 2021, 5 min read

Does the D2000 work with the Internet of Things? How can data from different sensors get into your system? We'll talk about that in this blog post.

The blog post is a fresh translation of an original Slovak text written some time ago. Even though it describes mostly news in the D2000 version 12, it is still very much relevant and shows how to use our platform for IoT.

IoT utilizing the low-energy intermittent data transmission standards

At the moment, there are two of the most common standards for low-energy intermittent data transmission: LoRaWAN and Sigfox. We’ll briefly introduce both.

LPWAN Class Protocols

Both protocols belong to the LPWAN (Low-Power Wide Area Networks) protocols - in fact, not only is it a definition of the protocol, but also of the physical and link layers and other parameters providing the required properties.

These protocols are designed for the occasional, energy-efficient wireless transmission of a small amount of data called payload (typically several bytes) over long distances (in open space even more than 10 km) between interconnected objects (typically battery-powered sensors) and a gateway (this direction is called uplink). If the sensors send only a few messages a day, the battery can last for several years. The opposite channel (dowlink) is supported as well - in a short time after sending the message, the data could be sent (optionally) to the device, as it is (could be) accessible.

LoRaWAN Protocol

The LoRaWAN protocol was developed by the French company Cycleo - the company was later acquired by the Californian company Semtech. The protocol itself is proprietary. Devices (in protocol terminology motes) send data asynchronously, as much as it is necessary. The maximum payload size is 255 bytes. The data can be received by one or more gateways and is usually sent to the cloud, from where it is subsequently downloaded by consumers.

Why usually? There is nothing that would prevent anyone from purchasing and configuring one or more of these gateways and retrieving data from them. It is possible to build your own network and not be dependent on the infrastructure of any cloud provider. When implementing LoRaWAN in D2000, we also supported this option. We tested our own gateway - IoT Station 868 from Kerlink. The price of such a gateway is around one thousand Euros. After placing the antenna on the elevator shaft of the 6-storey building in which we reside, we were able to receive messages of the test equipment from Teplička (a village 5 kilometers away from our company).

An alternative - especially advantageous if it is needed to cover a larger area that would require more gateways, therefore, higher investments - is to use cloud services and share costs with other users. In Slovakia, we tried clouds such as Slovanet, Loriot and TheThings.network. We obtained data from these clouds using the MQTT (Message Queuing Telemetry Transport) protocol, which is an open protocol for exchanging (mostly) telemetry data. Interesting fact: the implementation of MQTT  as a separate protocol in the D2000 was a by-product of the implementation of IoT communication.

Sigfox Protocol

The Sigfox protocol is closed similarly to LoRaWAN. It was again developed by a French company - Sigfox.

The Sigfox protocol allows a maximum of 12 bytes of payload to be transmitted in a message, with one device being allowed to send a maximum of 140 messages per day (i.e., approximately one message in ten minutes). In the opposite direction, it is possible to receive a maximum of four messages per day, each up to 8 bytes in size.

Sigfox and its partners have created a network of receivers with worldwide coverage - in Slovakia, its partner is SimpleCell (Slovakia's coverage map is directly on their website). Unlike LoRaWAN, there is not the option to create your own infrastructure, but the data from your sensors are downloaded using the REST API from the backend.sigfox.com cloud.

Implementation in D2000

The D2000 version 11 has already included the IoT over LoRaWAN protocol. It is available in both stable and supported production releases 11.0.53 and 11.2.57. Communication was tested:

· directly against the Kerlink IoT Station 868 gateway (communication uses the UDP messages)

· against the cloud TheThings.Network, to which our gateway sent messages and from where the D2000 KOM process read them (communication via TCP connection using JSON messages in MQTT protocol)

· against the Loriot.io cloud, which forwarded the data via the MQTT protocol to iot.eclipse.org, from where the D2000 KOM process read the data (the communication again via TCP connection using JSON messages in the MQTT protocol)

· against the Slovanet cloud - except for configuration details, the same principle as the two previous clouds

All clouds using the MQTT protocol and JSON messages differ in the structure of the JSON message and the names of the individual fields. The data itself (payload) could be found in the field named dataHex, data, or payload_raw, depending on a specific cloud and a communication path.

In the D2000 version 12, we implemented data acquisition from the Sigfox cloud. Good news for the indecisive (and frugal): you need not think about purchasing LoRaWAN or Sigfox when buying a D2000 license, the Sigfox communication is already implemented in the same protocol (the decision can be postponed until later or can be changed in time)! At the same time, this protocol was renamed to "IoT over LoRaWAN/Sigfox".

Figure 1 – The configuration of the line parameters of the protocol in D2000. Notice the indexing without specifying an index (zero index) meaning that all the elements in the data field are to be processed.

The Sigfox cloud supports access to its REST API via HTTPS protocol. The simplest and most flexible way was to support downloading data via an external utility (we used a freely available curl) - so that it is not necessary to solve e.g. all possible complications associated with authentication, proxy servers, etc.

At the same time, the Sigfox cloud supports not only the download of the current payload value, but also the history (up to 100 values within one query). We also supported this feature - e.g., after a long shutdown of the KOM process, it is possible to modify the batch file to download the current value as well as several values from the history. After the initial download of data from all devices, just adjust the file to its original state with the downloading of one value.

Figure 2 – The station configuration - device type selection and command setting to download data. It is apparent from the syntax that the KOM process is running on Linux. The command contains symbolic constants for application directory (#APPDIR#) and station address (#ADDR#).

Payload

Both LoRaWAN and Sigfox have in common that they do not address the structure of the payload - from their point of view, it is binary data. Their parsing must be implemented in the KOM process for each device separately and therefore the addressing of the measured points depends on the device. On the other hand, the payload analysis of each of the devices supported so far is a simple procedure for several tens of lines. And if you are interested, it is possible to add support for new devices to already released versions.

Conclusion

LPWAN class protocols make it possible to transfer data from remote devices (gas meters, water meters, etc.) energy-efficiently and using a shared infrastructure. It is already clear that in addition to solutions based on mobile networks, they will find their customers, whom they will impress with their technical possibilities and price.

Ing. Peter Humaj, www.ipesoft.com

Subscription was successful

Thank you for submitting form.

Image Description

Your message was successfully sent.

Thank you for submitting the form.

Image Description

Your message was successfully sent.

Thank you for submitting the form.

Image Description

Your message was successfully sent.

Thank you for submitting the form.

Image Description