Demo Purpose
🔤 Acronyms? See the Glossary
DLMS to HES Communication​
This third use case illustrates an end-to-end communication from a DLMS metering device to a DLMS Head-End System (HES).
At both ends of the communication, an IP tunnel (IP/tun controller) is required to establish a network communication channel between IP and the other protocols and create a Linux interface on the computer.
Acklio FullSDK is embedded into the AT Modem application.
Class A and Class C devices are supported by this use case.
In this Demo example, in order to avoid routing issues, the combination "DLMS server and tun controller" must be running on a different machine than the combination "VPN agent and HES".
Recommendations​
- Python 3
- DLMS library by Gurux with Java support and Maven
- Tun controller
- AT Modem by NET with serial port terminal (such as minicom)
- Board – Use either:
- Shield Semtech LR1110DVK1TBKS with development kit or sx1261
- A LoRa Network Server and a LoRa gateway
- Ubuntu 20.04 LTS to run Acklio Software
- Acklio IPCore and Acklio VPN Agent
Demo Functioning​
The Gurux DLMS example demonstrates how a DLMS Head-End System can request values to a DLMS server and get responses.
This Demo repository provides a device application (the DLMS server) simulating the DLMS meter and a DLMS client simulating the Head-End System.
The DLMS Client periodically starts sending a series of DLMS requests in order to get information from the device application. The example demonstrates how Acklio FullSDK allows the device application to exchange IPv6/UDP/DLMS frames with the Head-End System through the use of AT commands.
In this example the IPv6, UDP, and DLMS wrapper headers are compressed, limiting over-the-air transmission to the DLMS payload. This represents 56 bytes (40 + 8 + 8) less for each message.
In the case when fragmentation is also necessary, Acklio FullSDK uses the Ack-On-Error mode, as described in the SCHC template configured in Acklio IPCore.
