Getting started

Read latest DLMS/COSEM specific documentation from here.

This documentation is old and will be removed.


Gurux DLMS/COSEM component is designed to simplify communication with DLMS/COSEM devices. With the component you can easily communicate between DLMS/COSEM devices, by using the data connection, and the manufacturer of your choice.
At this moment we have libraries or components for ANSI C, ANSI C++, .C#, Java and Delphi.

More technical details you can find here.

The components, interfaces and methods are described more precisely later in this document.

Connection Initialization

The connection initialization depends on the connection type and the device. Some devices require IEC62056-21 protocol handshake before starting to communicate using DLMS protocol.

IEC62056-21 Handshake

In serial port connection default IEC62056-21 settings are: Bitrate 300, 7E1.

"/?" + deviceSerialNumber + "!\r\n"
Send query to the device containing "/?!" and a new line (0x0D 0x0A) without the quotations. This requests the identity information from the device.

The device responds with serial number and the maximum connection speed. The reply data is formatted as follows:
/XXXZ Ident and a line change
XXX is the manufacturer name
Z is the maximum baud rate
Ident is the Identification info of the device.

Z is the most important part of the device and is defined in single number:
0 - 300 Bd
1 - 600 Bd
2 - 1 200 Bd
3 - 2 400 Bd
4 - 4 800 Bd
5 - 9 600 Bd
6 - 19200Bd
7, 8, 9 - reserved for later extensions.

Send request to change to DLMS mode. Packet is formatted as follows:
0x06 "0" Z "2" 0x0D 0x0A without the quotations.
Z is the requested connection speed.

The device might respond to this but not all of them do. It is safe to continue with connection initialization even without reply.

If device is DLMS/COSEM compliant and meter do not answer anything it is in DLMS mode.

Serial/Modem handshake

This is done only with serial and modem connections. Direct tcp/ip doesn't need this. If IEC62056-21 handshake is used it is done before this.

This handshake uses SNMR request to gather packet and window size information from the device.

Before generating the packet ClientID, ServerID and UseLogicalName must be set in the GXCOSEM Component. After that is done the packet is generated from SNRMRequest method. Send this request using data handling methods described in Sending and receiving data.

If the device does not reply to this message see possible causes here.

Once the full reply data is received call ParseUAResponse method to set configure GXCOSEM Component with correct settings.

AARE request

This is the first command that is mandatory for all connections and device types. This command tells the device if authentication is used and wheter Long Name or Short Name reference is used. The packet can be generated with AARQRequest method and it uses UseLogicalName and Authentication properties so make sure these are set to correct values.

If password is defined all data do not nesessary do not fit to one message so data must be split to multible messages with SplitDataToPackets method.

Send this command using data handling methods described in Sending and receiving data.

Once the full reply is received parse it with ParseAAREResponse method. This method sets the relevant settings to the GXCOSEM component and return a collection of manufacturer specific tags if there was any.

Now the connection is established.

Association View

Association View describes what kind of objects meter offers. Structure of Association View varies by used Authentication.

The association view is requested using data from GetObjects method. Send this request using data handling methods described in Sending and receiving data.

The reply data is very large so this can take very long time (even hours with slow connection like terminal and if the connection is bad). Because this takes so long it is recommended to save this information for future use as it doesn't change unless meter software is updated. The data structure varies between manufacturers and device models.

The reply data is parsed using ParseObjects method in GXCOSEM Component. The method returns a collection of DLMS Objects.

Some of the data object may be typed as Profile Generic. These are special objects that have columns and rows instead of single value. You can think Profile Generic as a Table.

To get the column information generate message using method Read with following parameters:
Long or Short Name, 1, 1, ObjectType.ProfileGeneric, 3
The reply data is parsed with ParseObjects method and it returns the collection of data objects that are the columns.


Reading is generally split in two. Reading of "regular" data objects and profile generic objects.

General Data Objects

Data objects are read using Read method. The parameters are defined as follows:
Data: Logical or short name
Packet Position: Always 1
Total Packet Count: Always 1
Interface Class: Object Type of the requested item, ex. Clock.
Attribute Ordinal: The ordinal number of the requested attribute. For basic Data object type the first attribute contains Logical Name and the second attribute contains value.

The data is parsed using GetValue method that returns the value in the format that the device provided, ex. integer or string. In some cases the format is not usable, ex time is provided as byte array. In these cases use ChangeType method to parse the value.

object data = m_Cosem.Read(baseName, 1, 1, objectType, attributeOrdinal);
data = ReadDataBlock(data);
object val = m_Cosem.GetValue(data);

Profile Generic objects

There are two ways to read Profile Gereric data. By Entry or Range. In entry parameters tell where read is started (Zero index) and how many items are read. In range parameters tell starting and ending time.

All meters do not support read by entry or range.

The request is generated using ReadRowsByEntry or ReadRowsByRange methods. ActiceX component uses ReadProfileGenericData.

The paramters for ReadProfileGenericData are as follows:
Name: Logical or short name
ClassID: This is always Clock (8) if we want to read data between days.
LogicalName: The logical name of the first column.
Type: The Attribute Index of the first column.
Version: The version of the first column.
From: The start date or row index of the requested period*
To: The end date or row index of the requested period*

*If row indices are used the logical name of the first column must be null.

The reply data is parsed using GetValue that returns a two dimensional table of values.


The disconnect message must be sent always before disconnecting even if the device doesn't reply to it.
Disconnect message is generated using Disconnect method and might not get a reply.

Sending and receiving data

Before sending request it's important to be sure that it can fit in packet sizes. To ensure this there is a SplitDataToPackets method that returns the data as an array of byte arrays to be sent.

When receiving data use GetDataFromPacket to strip unwanted header data from it. There can also be EOP bytes in the middle of the packet so to be sure that the packet is really complete use IsDLMSPacketComplete method before continuing.

After receiving the full packet use CheckReplyErrors to check that there wasn't any errors.

When a full packet is received and free of errors check if there is more data available using IsMoreDataAvailable method. If there is more data, generate a new read message using ReceiverReady method and check remember to check for partial packets and errors again.


1. If your meter do not answer anything make sure that there is DLMS label on the cover of the device.
2. Server or Client Address is wrong. Server and Client address are device manufacture debended. You can ask Server and Client address from the manufacturer.

If you have any DLMS/COSEM device, and you're facing problems to use Gurux DLMS Component with it, read our Forum to get more information how to get over it.

Technical details

Gurux DLMS component supports HDLC Addressing by 1, 2, 4 Bytes and can communicate using HDLC, TCP/IP or UDP. It supports Lowest, Low and High Level authentications. Both Long and Short Name Association Types are supported.

Gurux DLMS Component is based on the following Electricity metering - Data exchange for meter reading, tariff and load control standards

  • IEC 62056-21 Direct local data exchange
  • IEC 62056-42 Physical Layer Services and Procedures for Connection-Oriented Asynchronous Data Exchange
  • IEC 62056-46 Data link layer using HDLC protocol
  • IEC 62056-47 COSEM transport layers for IPv4 networks
  • IEC 62056-53 COSEM application layer
  • IEC 62056-61 OBIS Object identification system
  • IEC 62056-62 Interface objects

Supported Conformance Block

  • Read
  • Write
  • Unconfirmed Write
  • Attribute 0 with SET
  • Priority Management Support
  • Attribute 0 with GET
  • Block Transfer with GET
  • Block Transfer with SET
  • Block Transfer with READ
  • Block Transfer with WRITE
  • Multiple References
  • Information Report
  • Parameterized Access
  • Selective Access
  • GET
  • SET