DSMR binding suitable for Belgium Smart Meters

Which version of openHAB are you running? Does it autodetect the things? (it should).

actually I did this in the paper ui.

following steps are needed:

  1. go to mijnverbruik.fluvius.be and enable the P1 port
  2. plug in the cable
  3. install the DSMR binding (at least 2.5.1)
  4. you should find the bridge (and I think also the meter itself)
  5. change in the bridge the channel id to -1.

and all works like a charm for me.

  • Can you confirm current compatibility with the Fluvius meter?
    I captured in the document https://www.fluvius.be/sites/fluvius/files/2020-01/dmk-demo-v2.1-rtc.pdf
    DSMR P1 V5.0.2 protocol is used, while the binding documentation mentions DSMR V4.0 DSMR - Bindings | openHAB
    (or do you advise jar file from github?)

  • can you give some advise on the P1 cable / connection to RPI?
    I found follow P1 cable: Slimme Meter Kabel - 1 Meter (P1 kabel)
    “De kabel is ook geschikt voor de Landis + Gyr E350 met DSMR4 en 5 en ook op andere DSMR4 en 5 apparaten!” but this doesn’t explicitly mention the fluvious meter.
    Any experience that it will work (or where did you find your cables)
    (out of interest: as this is serial, there is a chipset in the cable to convert usb to serial?)
    And this works “out of the box” / auto recognised within openhab/with the binding?
    (if yes: super development team!!!)

…Looking forward to integrate GAS & ELEKTRICITY measurements in my setup…

Hi Maarten

This exactly the same cable from the same vendor I’ve bought. So yes this works for me.
Together with the dsmr binding version 2.5.1 (before that you have some issues)

And do the steps I described above. So especially the channel ID and enabling the port in mijnverbruik.fluvius.be

Kind regards

Jan

Does anyone know if the current Ampère (channels emeter_instant_current_l1/2/3) can be shown as a decimal?
With the whole upcoming change in Belgium regarding capacity tariff, I would like to know how much A my house is using.
More context : instead of paying a tariff per kWh, they will look at the average peak of your current/Ampère.
For digital meter owners, this starts with a minimum of 2.5A, analog owners at 3.25A.
Now I only see integers. Thanks.

Hi Teams,

I had to reinstall/reboot. Currently running: openHAB 2.5.12 (Release Build)
openhab> version 4.2.7
openhab> bundle:list | grep dsmr
257 | Active | 80 | 0 | wrap_file__var_lib_openhab2_tmp_kar_org.openhab.binding.dsmr-3.1.0-SNAPSHOT_org_lastnpe_eea_eea-all_2.2.1_eea-all-2.2.1.jar

Unfortunately I can’t get all the measurements, tried several channels …
Spotted below error in the log though, any idea’s?

2021-03-25 21:32:05.382 [WARN ] [internal.service.FeaturesServiceImpl] - Can’t load features repository mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.1.0-SNAPSHOT/xml/features

java.lang.RuntimeException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.1.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:3.1.0-SNAPSHOT] : mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/3.1.0-SNAPSHOT/xml/features

at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:116) ~[bundleFile:?]

Hi,

If you are making use if .items files and configure as “Number” … you receive input with 3 digits after the decimal value.

Number:ElectricCurrent SlimmeMeter_InstantCurrentL1 “Instant current l1” {channel=“dsmr:electricity_emucs_v1_0:0:1:emeter_instant_current_l1”}

This looks like you are trying to run a openHAB 3 binding on openHAB 2, which is not going to work as it’s not binary compatible. You need to have a openHAB 2 version of the binding.

Hi, you’re right … removed the dsmr-3.1.0 tried to install the latest version in the hope the additional channels would appear. Current situation is with 2.5.12 binding version and 3 channels … tried serveral channel/kanaal settings, but I never get the others (3-fase A, V and production)

please find combined screenshot below … maybe the fluvios meter (P1 Versie 50213) is causing the limitation?

Hi guys,
I want to connect my siconia to openhab as well, how exactly did you make the physical connection between openhab (on a Pi) and the smart meter?

Hi Roel

Like already described above. Slimme Meter Kabel - 1.8 Meter (P1 kabel) is the one I used

1 Like

UPDATE - FIXED!

Main electricity meter:

  • Use the “show advanced” checkbox to add all the things
  • Set channel: 0

Delete the second smart meter thing with the connection error.

Hi,
I’m having the same issue as @Midwave ,missing some electricity channels, and I have a second smart meter thing that has a configuration error "serial port does not exist, it has the same value in the serial port (/dev/ttyUSB0) as the working smart meter thing.

I am using the lastest openhab 3 version and latest binding version, the meter is a siconia T211 and uses DSMR P1 5.0.2

These are the channels I could add from the working things:

And I don’t even get the readings for the different tariffs…

Hi,

Just to let all know, for me (Fluvious Smart meter) it’s working for both OH2.5.x and 3.x
To be honest, not 100% sure what fixed it (also changed USB port, rebooted, etc)
(and till now working 100% stable / even after multiple reboots and weeks in production)

Great development !

Because my OH instance is not next to my smart meter (Belgian, Fluvius) and I didn’t want to use an additional pi, I bought an already assembled ESP which can read the data.

This is working fine, telnet to the device gives this output:

/FLU5\253769484_A

0-0:96.1.4(50215)
0-0:96.1.1(3153414733313030333034353531)
0-0:1.0.0(211230165452W)
1-0:1.8.1(000049.918*kWh)
1-0:1.8.2(000047.885*kWh)
1-0:2.8.1(000000.010*kWh)
1-0:2.8.2(000000.150*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.711*kW)
1-0:2.7.0(00.000*kW)
1-0:21.7.0(00.195*kW)
1-0:41.7.0(00.235*kW)
1-0:61.7.0(00.280*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.000*kW)
1-0:32.7.0(235.2*V)
1-0:52.7.0(234.8*V)
1-0:72.7.0(237.7*V)
1-0:31.7.0(000.92*A)
1-0:51.7.0(001.23*A)
1-0:71.7.0(001.52*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(37464C4F32313230323134363539)
0-1:24.4.0(1)
0-1:24.2.3(211230165006W)(00012.765*m3)
!D6F6

The device also supports MQTT, so I have the data where I want, buy I know that it’s also possible to grab the data over the network (HA does :grinning:)
Should be great if this would also be possible here.

It’s already possible. Configure the binding over telnet with the rfc2217 prefix and host/port as follows:
Bridge dsmr:dsmrBridge:<bridge> [serialPort="rfc2217://<host>:<port>"]

ow, didn’t knew that. Is this only for OH3.2? Because I’m still on OH3.1 and getting this error:

2021-12-31 12:17:11.562 [WARN ] [r.internal.device.DSMRDeviceRunnable] - DSMRDeviceRunnable stopped with a RuntimeException
java.lang.IllegalArgumentException: Illegal character in scheme name at index 0: 192.168.0.15:23
	at java.net.URI.create(URI.java:883) ~[?:?]
	at org.openhab.core.io.transport.serial.internal.SerialPortManagerImpl.getIdentifier(SerialPortManagerImpl.java:72) ~[?:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.open(DSMRSerialConnector.java:113) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRSerialAutoDevice.start(DSMRSerialAutoDevice.java:152) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRDeviceRunnable.run(DSMRDeviceRunnable.java:75) [bundleFile:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.net.URISyntaxException: Illegal character in scheme name at index 0: 192.168.0.15:23
	at java.net.URI$Parser.fail(URI.java:2913) ~[?:?]
	at java.net.URI$Parser.checkChars(URI.java:3084) ~[?:?]
	at java.net.URI$Parser.checkChar(URI.java:3094) ~[?:?]
	at java.net.URI$Parser.parse(URI.java:3109) ~[?:?]
	at java.net.URI.<init>(URI.java:600) ~[?:?]
	at java.net.URI.create(URI.java:881) ~[?:?]

thing:

UID: dsmr:dsmrBridge:6f2da27fd6
label: Smart Meter
thingTypeUID: dsmr:dsmrBridge
configuration:
  receivedTimeout: 30
  serialPort: rfc2217://192.168.0.15:23

It should work in 3.1. It looks like it can’t parse it and miss something. Not sure what that causes. Either a typo (although it doesn’t look like it) or something wrong in the UI? It should work in a things configuration file.

Hello all,

I’m from Belgium and I use another open source project to read, store and transmit the telegrams sent on the P1 port of the smart meter. It’s called DSMR reader: dsmrreader/dsmr-reader: DSMR-protocol reader, telegram data storage and energy consumption visualizer. Can be used for reading the smart meter DSMR (Dutch Smart Meter Requirements) P1 port yourself at your home. You will need a cable and hardware that can run Linux software. Free for non-commercial use. A Docker implementation can be found here: https://github.com/xirixiz/dsmr-reader-docker

I run it as a docker container and have set it so the app publishes all data to MQTT. From there I read it into openhab. I think a dedicated system is more suitable for this kind of data then a binding. It also has a great dashboard, great support and documentation. Allows for easy integration in pvoutput and other third party tools. Plus, everything is available to be used in openhab as well through MQTT.

Hi,

I’ve been using the DSMR binding with succes. I’m living in Belgium and since beginning of this year, the government has introduced a new capacity tariff whereby the distribution tariff is based on the 15-min average peak load of power of each month. Recently, the DSMR meters have been upgraded to display this peak capacity load and the value can also be read from the P1 port.

I’ve checked this, and indeed using the cu -l /dev/ttyUSB0 command I can read the values. The average peak load can be read from value 1-0:1.6.0, see screenshot below.

Question I have is: can the DSMR binding be upgraded to also included this value as a channel type ID? Who could initiate such a request?

I realize that an alternative could be to read all values as explained by Mathias above and then pump them to openhab using MQTT, however I really like the simplicity of this DSMR binding, and including this as a separate channel would be much easier.

As an addition to my previous post, see also:
DSMR

On page 9 in yellow the newly added information of the DSMR meter is displayed:

  • Current average demand - Active energy import
  • Maximum demand – Active energy import of the running month
  • Maximum demand – Active energ import of the last 13 months