The DSMR component connects to Dutch Smart Meters which comply to DSMR (Dutch Smart Meter Requirements), also known as ‘Slimme meter’ or ‘P1 port’.
This integration supports plain non encrypted telegrams and also encrypted as used in Luxembourg. In case your equipment has encryption you must get a 32 character long encryption key from your energy company.
This component is passive, it does not transmit any data to your equipment, the equipment always transmits data which this component decodes and updates the configured sensors at the pace the data is received.
For official information about DSMR refer to: DSMR Document
For official information about the P1 port refer to: P1 Companion Standard
# Example configuration entry dsmr: decryption_key: !secret decryption_key sensor: - platform: dsmr energy_delivered_tariff1: name: Energy Consumed Tariff 1 text_sensor: - platform: dsmr identification: name: "DSMR Identification" p1_version: name: "DSMR Version"
decryption_key (Optional, string, templatable, 32 characters, case insensitive): The key to decrypt the telegrams. Used in Lux only.
gas_mbus_id (Optional, int): The id of the gas meter. Defaults to
crc_check (Optional, boolean): Specifies if the CRC check must be done. This is required to be set to false for older DSMR versions as they do not provide a CRC. Defaults to
max_telegram_length (Optional, integer): The size of the buffer used for reading DSMR telegrams. Increase if you are reading from a smart meter that sends large telegrams. Defaults to
uart_id (Optional, ID): Manually specify the ID of the UART hub.
request_interval (Optional, Time): The minimum time between two telegram readings. Defaults to
0ms, meaning that the pace at which the smart meter sends its data determines the update frequency. This works best in combination with a
request_pin, but this option will work without one too.
receive_timeout (Optional, Time): The timeout on incoming data while reading a telegram. When no new data arrive within the given timeout, the device will consider the current telegram a loss and starts looking for the header of the next telegram. Defaults to
id (Optional, ID): Manually specify the ID of the DSMR if you have multiple components.
Not all sensors are available on all devices.
Country specific sensors are listed last.
energy_delivered_tariff1 (Optional): Energy Consumed Tariff 1.
energy_delivered_tariff2 (Optional): Energy Consumed Tariff 2.
energy_returned_tariff1 (Optional): Energy Produced Tariff 1.
energy_returned_tariff2 (Optional): Energy Produced Tariff 2.
power_delivered (Optional): Power Consumed.
power_returned (Optional): Power Produced.
electricity_failures (Optional): Electricity Failures.
electricity_long_failures (Optional): Long Electricity Failures.
voltage_l1 (Optional): Voltage Phase 1.
voltage_l2 (Optional): Voltage Phase 2.
voltage_l3 (Optional): Voltage Phase 3.
current_l1 (Optional): Current Phase 1.
current_l2 (Optional): Current Phase 2.
current_l3 (Optional): Current Phase 3.
power_delivered_l1 (Optional): Power Consumed Phase 1.
power_delivered_l2 (Optional): Power Consumed Phase 2.
power_delivered_l3 (Optional): Power Consumed Phase 3.
power_returned_l1 (Optional): Power Produced Phase 1.
power_returned_l2 (Optional): Power Produced Phase 2.
power_returned_l3 (Optional): Power Produced Phase 3.
gas_delivered (Optional): Gas Consumed.
gas_delivered_be (Optional): Gas Consumed Belgium.
energy_delivered_lux (Optional): Energy Consumed Luxembourg
energy_returned_lux (Optional): Energy Produced Luxembourg
identification (Optional): DSMR Identification
p1_version (Optional): DSMR Version
timestamp (Optional): Timestamp
electricity_tariff (Optional): The current tariff. According to the specs value ‘0001’ means ‘normal tariff’ and value ‘0002’ means ‘low tariff’. Your meter may report differently.
electricity_failure_log (Optional): Electricity Failure Log
message_short (Optional): Message Short
message_long (Optional): Message Long
gas_equipment_id (Optional): Gas Equipment ID.
water_equipment_id (Optional): Water Equipment ID
sub_equipment_id (Optional): Sub Equipment ID
gas_delivered_text (Optional): A text sensor which unformatted gas data. You need to apply a custom parsing of this value depending on your meter format.
Older DSMR meters support¶
Version 2.2 is supported with the following configuration:
# Custom uart settings for DSMR v2.2 uart: baud_rate: 9600 data_bits: 7 parity: NONE stop_bits: 1 dsmr: crc_check: false sensor: - platform: dsmr energy_delivered_tariff1: name: dsmr_energy_delivered_tariff1 energy_delivered_lux: name: dsmr_energy_delivered_tarifflux text_sensor: - platform: dsmr identification: name: "dsmr_identification" p1_version: name: "dsmr_p1_version" gas_delivered_text: name: "gas delivered raw"
P1 Data Request pin¶
From the P1 companion guide: The P1 port is activated (start sending data) by setting “Data Request” line high (to +5V). While receiving data, the requesting OSM must keep the “Data Request” line activated (set to +5V). To stop receiving data OSM needs to drop “Data Request” line (set it to “high impedance” mode). Data transfer will stop immediately in such case.
Advantages when using a request pin:
After reading a telegram, the dsmr component will stop the data transfer until the telegram has been fully processed. This separates retrieving and processing data and can thus be seen as a form of hardware flow control.
The interval at which sensor readings must be updated can be controlled cleanly by only starting a data transfer when needed. This configuration option
request_intervalcan be used to define this interval.
Required hardware support
Many DSMR reader circuits link the +5V pin of the P1 port directly to its Data Request pin. Doing this will
make the smart meter send telegrams at a pace as defined by the smart meter firmware. For example many
DSMR v5 meters will send a telegram every second.
Circuits that use this type of wiring cannot make use of the
However, when a circuit is used that allows switching the Data Request pin between +5V and high impedance
mode from a GPIO, then this GPIO can be configured as the
Best results have been achieved by using an optocoupler circuit to handle the switching. Direct GPIO output or a transistor-based circuit are not feasible options. Here’s an example circuit design:
Improving reader results¶
When telegrams are sometimes missed or when you get a lot of CRC errors, then you might have to do some changes to get better reader results.
It is recommended to set the
rx_buffer_size option of the UART bus to at least the maximum telegram size,
which defaults to 1500 bytes. The default UART read buffer is quite small an can easily overflow, causing
bytes of data getting lost.
# Example configuration uart: pin: D7 baud_rate: 115200 rx_buffer_size: 1700 dsmr: max_telegram_length: 1700
It’s best when a hardware UART is used for reading the P1 data. Whether or not hardware UART is used can be checked in the config dump that you get when connecting to the API logger. Example logging output:
[02:38:37][C][uart.arduino_esp8266:095]: UART Bus: [02:38:37][C][uart.arduino_esp8266:097]: RX Pin: GPIO13 [02:38:37][C][uart.arduino_esp8266:099]: RX Buffer Size: 1500 [02:38:37][C][uart.arduino_esp8266:101]: Baud Rate: 115200 baud [02:38:37][C][uart.arduino_esp8266:102]: Data Bits: 8 [02:38:37][C][uart.arduino_esp8266:103]: Parity: NONE [02:38:37][C][uart.arduino_esp8266:104]: Stop bits: 1 [02:38:37][C][uart.arduino_esp8266:106]: Using hardware serial interface. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When using an ESP8266, then GPIO13 (e.g. pin D7 on a D1 Mini) can be used for hardware RX. However, to actually make it work, serial logging must be disabled to keep the hardware UART available for D7.
# Example configuration for ESP8266 logger: baud_rate: 0 level: DEBUG uart: pin: GPIO13 baud_rate: 115200