Introduction

This document provides the "Delft Smart Meter Requirements" (DSMR), a fictional standard for an Automatic Meter Reading (AMR) system for electricity and gas meters.

The scope of this standard is the end-consumer interface (P1¹) for:

Residential electricity meters
Residential gas meters

This standard focuses on the interface for gas meters.

Figure 1.1: Meter interfaces overview

The goal of this standard is to reach an open, standardized protocol implementation and functional hardware requirements related to the communication between several types of Service Modules and a Metering System. Any specification in this standard is intended to encourage suppliers to develop their hardware and software in a common direction. Standardised protocols and hardware specifications are referred to as much as possible. This companion standard is the result of a combined effort of the major Delft grid operators.

See Figure 1.1

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and " OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Devices and Telegrams

DSMR data is generated by DSMR supported devices such as various kinds of smart meters. Smart meters are connected to each other like a tree. Each DSMR supported device MAY have up to 3 ports through which they connect to other meters, sub meters. A device SHALL NOT have more than 3 ports.

DSMR Version 1.2 and up reflects this tree-like structure, while Version 1.0 data must be flat. DSMR data is sent in telegrams. Sequences of telegrams start with a version header, followed by at least one telegram.

When a sub-meter sends a Telegram, it will pass through a parent device. The parent device then outputs a new telegram, with inside it the sub-telegram from the sub-device. The parent SHALL ALWAYS add more information to the combined telegram since parents are meters themselves too. That means that the top level device will often send a packet with zero or many sub-packets associated with the sub-devices.

Sub-devices MAY be the same kind of device as a parent or another sibling. For example, it is possible that there are two electricity meters and a gas meter connected to a top-level electricity meter.

For historical reasons, the top level device MUST be an electricity meter device (not gas).

Representation

Example Telegram(s)

Below we show an example of a DSMR telegram message. In the following text, we will define the structure of each part of this and other DSMR messages.

/v10\
1.1.0#(START)
2.1#(23-Jul-05 15:26:41 (S))
3.1.1#(H)
3.2.1#(506f776572204661696c757265)
3.3.1#(23-Jul-02 13:12:00 (S))
3.1.2#(L)
3.2.2#(566f6c7461676520746f6f206c6f77)
3.3.2#(23-Jul-05 13:37:00 (S))
4.1#(E)
7.1.1#(0241.7*V)
7.1.2#(0240.6*V)
7.1.3#(241.92*V)
7.2.1#(01.*A)
7.2.2#(10.*A)
7.2.3#(0.5*A)
7.3.1#(+001.00*kW)
7.3.2#(-05.010*kW)
7.3.3#(+02.500*kW)
7.4.1#(0011454892.*kWh)
7.4.2#(0000001245.*kWh)
1.2.0#(END)

Representation of primitive protocol values

Value format	Example	Meaning
`Fn(x,y)`	`F7(3, 3) - YYYY.YYY`	Floating decimal number with a fixed number of decimals behind the decimal point (in this case 3)
`Fn(x,y)`	`F7(0, 3) - YYYY.YYY` or `YYYYY.YY` or `YYYYYY.Y` or `YYYYYYY.`	Floating decimal number with a variable number of decimals behind the decimal point (with a minimum of 0 and a maximum of 3). A Floating point number must have a decimal point.
`In`	`I4 - YYYY`	Integer number with n digits
`Sn`	`S6 - CCCCCC` and `S2..4 - CC` or `CCC` or `CCCC`	Alphanumeric string, number of characters defined by the number or range that follows. If hexadecmial, double the number of characters follow (2 hex-digits per character)
`DATE`	`YY-MMM-dd hh:mm:ss (X)` - `23-Jul-05 15:26:41 (S)`	ASCII presentation of Time stamp with Year (0-99), Month (name), Day (1-31), Hour (0-23), Minute (0-59), Second (0-59), and an indication whether daylight savingstime (DST) is active (X=S, UTC+2) or DST is not active (X=W, UTC+1). Dates are always strictly after 1970-01-01 00:00:00 (W). Month codes are Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

IMPORTANT NOTE: Time is hard! To help you, there is a function exposed in tudelft-dsmr-output-generator called date_to_timestamp. If you parse dates correctly and use this function, you don't need to worry about timezones at all.

Representation of `Sn`

Strings are represented with the Sn format. When the format specifies a field which can have an arbitrary string as value, string characters are represented with hexadecimal characters, two characters per byte. However, sometimes the format specifies that a string can only be one or multiple exact values. In that case, those values are not encoded as hexadecimal, and are the exact value specified.

The length of a string is implicit, but all fields are delimited by parenthesis so the length can be deduced from the format.

(AABB...CC)
 1 2    3

AA: hexadecimal characters representing the first character of the string
BB: hexadecimal characters representing the second character of the string
CC: hexadecimal characters representing the last character of the string

(strings are always in ASCII, unicode is not supported)

Example

The following is the string "Hello, World!", S13, encoded according to this format:

48656C6C6F2C20576F726C6421

Representation of a Telegram

A top-level telegram always starts with a version number. The format for such a version number is as follows:

/	`S3`	\	+	`S0..10`
ascii 0x2F	"v", followed by 2 digits	ascii 0x5C	ascii 0x2B, if extensions follow	unordered list of extension codes²

After which, the content of a telegram follows. Note: the header MUST NOT contain any whitespace or characters other than those defined above.

See Extension code reference

Version number reference

Version	Notes
`v10`	Version 1.0 doesn't support any extensions and MUST reject telegrams that have extensions. MUST also reject sub-telegrams.
`v12`	Version 1.2 supports both the gas and recursive extension, though only when specified, and MUST reject any invalid extensions

Each version increase only adds to the standard. For example, parsing of v1.2 packets does not fundamentally change how v1.0 packets are parsed. When no extensions are present then there MUST be no + after the version number.

Extensions code reference

Extension code (case sensitive)	Description
`g`	Gas
`r`	Recursive (supports subtelegrams)

Other extension codes and duplicate extension codes are considered invalid and MUST be rejected.

Example of version

The following is an example of a version header of a telegram. It is a version 1.2 with extensions for recursion and gas.

/v12\+gr

Representation of Telegram content

The following table holds the structure of the content of a Telegram. The fields of a telegram can be sent in any order, unless otherwise noted, and MUST always start with a field id. Every field implicitly ends with a newline character \n (0x0A) and on some operating systems also a carriage return \r.

Description	Field ID	Value format	Unit	Note
Start of Telegram	1.1.0	`S5` (always: `START`)		MUST be first
Date of the Telegram	2.1	`DATE`		MUST occur exactly once per telegram or sub-telegram
Eventlog Severity	3.1.n	`S1`		MAY repeat, n is the event id. MUST be H for high or L for low
Eventlog Message	3.2.n	`S0..1024`		MAY repeat, n is the event id (arbitrary, hex string)
Eventlog Date	3.3.n	`DATE`		MAY repeat, n is the event id

Information type	4.1	`S1`		"G" (gas), "E" (electricity). SHOULD come before the information itself, and MUST only appear exactly once in a telegram.

Electricity:
Voltage	7.1.n	`F5(1,2)`	`V`	n is the phase (1, 2 or 3)
Current	7.2.n	`F2(0,1)`	`A`	n is the phase (1, 2 or 3)
Power	7.3.n	`(S1) F5(0,3)`	`kW`	n is the phase (1, 2 or 3). Sign (+ or -) is optional.
Total consumed	7.4.1	`F10(0, 0)`	`kWh`	(cumulative)
Total produced	7.4.2	`F10(0, 0)`	`kWh`	(cumulative)

Only in V1.2 and up:
Start Child Telegram	1.1.n	`S5` (always `START`)		MAY repeat a maximum 3 times, n is the child id (`>0` and `<=3`)
End Child Telegram	1.2.n	`S3` (always `END`)		MAY repeat a maximum 3 times, n is the child id (`>0` and `<=3`)

Gas extension:
Total gas delivered	5.2	`F8(3,3)`	`m3`	(cumulative)

End of Telegram	1.2.0	`S3` (always: `END`)		MUST be last

Note: The order of event log entries is only decided by their date. n is simply a unique id.

Representation of fields

A field is always represented on a single line and its format is as follows

ID	#	(	Value	*	Unit	)
Field ID	ascii 0x23	ascii 0x28	Attribute according to value format	ascii 0x2a, if a unit follows	Unit if applicable	ascii 0x29

Note that units MUST be present when the protocol specification lists them. They MUST be the right unit for the value type to the protocol specification.

Example

As an example, the following is the representation of the current voltage on phase 1

7.1.1#(240.42*V)

Representation of child telegrams

Telegrams MAY contain data received from child devices. Such child data starts with Field id 1.1.n, with n representing which child device the data is from. Immediately after the start, fields from that child device will follow until a stop is received (Field id: 1.2.n, with n matching the start). A telegram MUST have at most 3 child devices, thus n can only be 1, 2 or 3. Children MAY have more children of their own, recursively.

The top level telegram MUST contain information for Electricity, and MUST not contain Gas information. Therefore, Gas meters MUST always be child devices.

An example is shown below of a telegram with gas data. Since gas data cannot be toplevel, it is included as a subtelegram, while the toplevel telegram is a telegram from a electricity meter.

/v12\+rg
1.1.0#(START)
2.1#(23-Jul-05 15:26:41 (S))
3.1.1#(H)
3.2.1#(506f776572204661696c757265)
3.3.1#(23-Jul-02 13:12:00 (S))
3.1.2#(L)
3.2.2#(566f6c7461676520746f6f206c6f77)
3.3.2#(23-Jul-05 13:37:00 (S))

; Start gas subtelegram

1.1.1#(START)
2.1#(23-Jul-05 15:26:41 (S))
4.1#(G)
5.2#(12345.123*m3)
1.2.1#(END)

; End gas subtelegram

4.1#(E)
7.1.1#(0242.7*V)
7.1.2#(0241.6*V)
7.1.3#(242.92*V)
7.2.1#(0.7*A)
7.2.2#(10.*A)
7.2.3#(0.5*A)
7.3.1#(+001.00*kW)
7.3.2#(-05.010*kW)
7.3.3#(+02.500*kW)
7.4.1#(0012454892.*kWh)
7.4.2#(0000001445.*kWh)

1.2.0#(END)

Requirements for Telegram content

A Telegram must have certain fields. Telegrams which do not follow the requirements are invalid and MUST be rejected.

Each Telegram MUST contain a start, an end, and date
A telegram MUST contain up to 3 child telegrams (0 is possible)
A telegram MUST only contain information from a single meter: Gas or Electricity. Fields with information of different meters cannot be combined in a single telegram.
A telegram MUST contain exactly one 4.1 information type field
The top level telegram MUST only be from an Electricity meter. Gas meters MUST only be child meters and their information is contained in child telegrams.
Empty lines and stray newlines MUST be ignored
In a telegram, all field IDs MUST be unique.
Every information type (Eventlog, Gas and Electricity) MUST be complete. For example, the electricity data MUST contain voltage, current and power of all three phases and the total consumed and produced power. Another example, every event log MUST have a date, message and severity.

Multiple Telegrams

In a single .dsmr file, multiple telegrams MAY be stored. The telegrams come, concatenated, with zero or more newlines in between. When multiple telegrams are concatenated, only one header MUST be present.

When multiple voltages are present of the same phase, you MUST only record the highest voltage per phase for purposes of the graphs. The same is true for current, that is to say, only record the highest. To repeat, all other quantities, for example power, should be summed.

Rejecting telegrams

When a telegram is malformed it MUST be rejected by any receiving node. If a single telegram in a sequence of telegrams is malformed, the entire sequence MUST be rejected. Rejected telegrams are thrown away, so parent meters do not need to spend time parsing such telegrams.

Comments

One MAY implement comments. That is to ignore any line that starts with a ; (0x3B). Do not that some example telegrams in this document use comments.

Example

; this is a comment

Acknowledgements

This (fictional) standard is largely inspired by the Dutch Smart Meter Requirements: P1 Companion Standard version 5.0.2. This can be retrieved at the following URL: https://www.netbeheernederland.nl/sites/default/files/2024-02/dsmr_5.0.2_p1_companion_standard.pdf

Software Fundamentals