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:
https://github.com/openhab/openhab-addons/issues/14279

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.

Hello,
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"] {
    Things:
        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"] {
    Things:
        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?

Sceppi

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?

Hi Hilbrand,

Thanks for the clarification. When I scan with discovery it finds eMUCS 1_0 devices. It actually finds 3 of them:
electricity_emucs_v1_0
device_emucs_v1_0
gas_emucs_v1_0

So I guess I need to switch over to using the emucs Thing.

Hilbrand,

I would like to come back to the refresh rate topic. Currently I get values every 10 seconds, except for gas which only pushes values every 5 minutes. I fully understand the difference between the refresh of the meter and the binding.

However, the Belgian meter allows data points every second for electricity (which I’ve read in the documentation). I checked this using cu -l /dev/ttyUSB0 and effectively every second I see new values for my electricity usage. However, as the refresh rate of the binding is only every 10 seconds, I only receive new values every 10 seconds. This is fine for almost all use cases, except for the case where you want to control your car charger using your smart meter data. Here 10 seconds is long… actually too long. (I can explain this in a separate post if you are interested, but it boils down to openWB changing the amperage but in case the refresh is too long it will assume another change of amperage is needed which leads to overshooting and undershooting values … it’s really annoying).

Hence my question: can the binding be upgraded to allow a refresh rate every second? Or maybe this can be set as a propery for each individual to modify according to his own needs. In fact, in my case I would only need these fast 1s refresh rates for the channels ‘emeter_actual_delivery’ and ‘emeter_actual_production’.

OK, forget my previous post. I just saw that there is a refresh parameter which allows to set the refresh rate.

Can’t understand I overlooked this … I guess I was too focused on this table in the readme which stated the refresh rates and assumed these were fixed…

This is great, made my day! :slight_smile:

@sceppi Created a pull request for OH4 on these channels
I upgraded to JAVA17 and can now prepare my own environment and this is part of it :slight_smile:

1 Like

Great! I also upgraded to OH4 & JAVA 17 without issues.

I see another feature request coming up in the future. A number of water companies (in my case Pidpa) are starting to roll-out digital water meters. It seems that they will likely integrate with the DSMR meter (the values will be pushed to the DSMR meter from which they can then be read out). When this will be implemented, we’ll also have to add the channels to read out the water consumption values.

Ow yes, heard that as well.
Waiting for the specs to become available, will add them if possible

Hello, any idea when this change will be implemented?
Is there a possiblility to implement it myself?

Kim