DSMR binding suitable for Belgium Smart Meters

Thanks for the info @sceppi I was not aware of this.
You can create an issue on github for this.
Although my coding skills are low, when I find the time, I will have a look.
I need this one as well :slight_smile:

1 Like

Issue request has been added in github, see:

Appreciate your help. My coding skills are also low. I can read easy code and modify if not too difficult, but that’s about it. I’ll have a look into it as well.

1 Like

I think I have it working after playing around with the code. The only problem was the integrated tests, I had to delete those.
Will further look into this next week.

I have create a module (with ESP8622) to connect the port1 on belgium counter

it create a telnet server and you can connect it with openhab.

@sceppi With the help of @hilbrand I could compile a binding without errors.
It is build on the 3.4.2 snapshot and you can find it here
It works for me.
Don’t forget to install the feature serial as this is not included in the JAR.
Hope it works for you.

1 Like

Hey @BeanzBE,

Thanks, great progress, and I can confirm it’s working!
Just 1 side question. I’m using textual config and my things file was configured as following:

Bridge dsmr:dsmrBridge:mysmartmeter [serialPort="/dev/ttyUSB0"] {
        electricity_v5_0 electricityV5 [channel=0, refresh=10]
        gas_emucs_v1_0 gasv1 [channel=1]

As you can see, I am using the thing electricity_v5_0 electricityV5 and not the e-MUCS V1.0 Device ( device_emucs_v1_0).

In the code you have uploaded, I see that you have edited the meter_electricity_emucs_v1_0.xml file, however I am using the meter_electricity_dsmr_v5.xml.
I resolved this by adding a third Thing “electricity_emucs_v1_0 emucsv1 [channel=-1]”, which contains the 2 additional items you have added.

Bridge dsmr:dsmrBridge:mysmartmeter [serialPort="/dev/ttyUSB0"] {
        electricity_v5_0 electricityV5 [channel=0, refresh=10]
        gas_emucs_v1_0 gasv1 [channel=1]
        electricity_emucs_v1_0 emucsv1 [channel=-1]

Question: Are you using the Emucs_V1 for all the dsmr items you are reading? Why not the V5? Perhaps it doesn’t really matter, but I wonder if you should also not make these 2 additional items available in the meter_electricity_dsmr_v5.xml file?


The question is why did you choose for the v5 version? Because there is much overlap between versions it likely doesn’t matter what thing you manual configure as long as the channels you want to use match. It therefore doesn’t make sense to randomly add these channels to any other thing without some logical reason. To be able to aswer the question if it would make sense: If you would not configure anything and than run discovery what thing does it detect?

Why is use v5? Because according to the technical specifications, the dsmr meters in Belgium are v5.0.2 (see: fluvius dsmr). Hence I used the v5 version and this works fine.

On top of that - and even more importantly - the DSMR v5 allows a much higher refresh rate. The refresh rate, according to the dsmr binding readme - is every 10 seconds. For e-MUCS V1.0 Device the refresh rate is stated as ‘?’. Now using the e-MUCS V1.0 for the peak values, I can see that these are only updated every minute.

You may ask if this refresh rate is that important, but for me it really is. I use the actual injection/offtake data to steer my electric car charger in combination with my solar panels. My charger adapts the amperage according to how much electricity is injected. Especially on half cloudy days, I need a quick read out value and response of the charger in order to maximize solar charging. (I’m using the OpenWB software).

Hence, yes I believe there are valid reasons for also adapting the meter_electricity_dsmr_v5.xml file and using this version (although I must admit that for the 2 peak values which have now been added it doesn’t really matter to receive them every 10s of every minute).

I think there are some misconceptions (probably due to the binding documentation not clear on these points).

First the v5 is for meters conforming to the v5 standard. The fluvius does not as described in the document you linked:

Because certain data objects from the minimum amount of data made available are not described in section 6.12 of DSMR 5.0.2 P1, this section was expanded. This expansion and a number of other nuances, referring to European standards like DMSR and DLMS, are described in the international specification document (eMUCS – H), which can be downloaded via the link below

Therefor a specific thing is available the emucs thing that contains all objects. And yes because it’s based on the v5 a v5 thing will also work. But v5 is specific for version 5 and should not be extended with additional objects that are not part of the v5 standard.

The misconception about the refresh is that the refresh refers to the refresh rate of the data send by the meter, not by the refresh rate of the binding. The refresh rate in the binding operates independent of the refresh rate of the meter. That way the user is in control on when the data is updated. However, for example, if the data is only updated once every minute it doesn’t make sense to set the refresh in the binding to a lower value, because there won’t be any new data anyway. Therefor this refresh rate was included in the documentation. Thus you can just set the refresh to 10 seconds for the emucs thing. But if your meter would only update the data every minute you will only see changed data every minute. In summary you should be able to use the emucs thing just like the v5 thing.

Therefor I’m interested in what the binding finds if you would remove the thing and run discovery. What thing does it detect?