UK Smart Meter DLMS Optical Port Binding

Add-ons Bindings
1

There is a Smart Meter binding in OH that supports reading of smart meter data via an IEC 62056-21 optical read head and using the German SML optical port protocol.

In UK Smart Meters use a different technical standard than Germany. (Presumably BSI versus DIN). The UK overall standard is called SMETS-v2 whereby the optical port hardware is the same IEC 62056-21 as in Germany, but the protocol is called DLMS/COSEM (vs SML in Germany).

I am thinking of developing binding support for DLMS/COSEM via IEC 62056-21 on SMETS-v2

Questions:

  1. Does anyone know if there is any similarity between SML and DLMS/COSEM?
  2. And if so, do you think it would be easier for me to extend the existing Smart Meter binding, or
  3. alternatively would it be better to start from scratch with a new binding for DLMS/COSEM?
2

Same situation over here in (Lower) Austria.
We use KAIFA MA309 smartmeters which use the DLMS/COESM protocol as well.

Imho there’s not much overlap between DLMS and DSMR or SML protocols so a new binding would make more sense.

Theres a guy who wrote a crude python script which decrypts/decodes DLMS data and can post it to an mqtt broker. It works but isn’t as nice as a native plugin.

It’s in german but maybe of some use:

https://github.com/greenMikeEU/SmartMeterEVNKaifaMA309

Spec (in german) from our energy provider: https://www.netz-noe.at/Download-(1)/Smart-Meter/218_9_SmartMeter_Kundenschnittstelle_lektoriert_14.aspx

3

Might not be much overlap protocol wise, but from openHAB perspective these are all smart meter readers connected to your main power meter.

Personally I would opt to make a short assessment on how it could fit in the current binding to support multiple protocols.

If the model exposed by openHAB is very similar I would opt to add it. It is just a matter of selecting the right protocol data parser

4

The history is not fully clear but as far as I can tell the SML and DLMS protocols were once both sourced by a group called “OpenMuc”.

However it seems that in the meantime OpenMuc does not exist ??

In the meantime the OH binding has imported the SML library (probably from OpenMuc) into an OH third party library module here openmuc/jrxtx.

Apropos 'jrxtx` there seems to be a repo for that hosted by @Kai .. although I don’t know if that is related to the Smart Meter binding.

By contrast the code for the DLMS is here xdom/jdlms..

5

Digging further into this..

  • The OSI levels 1, 2, 3 could probably be shared across bindings.
  • And OH would provide OSI levels 6, and 7
  • However the levels 4, and 5, are provided by SML and DLMS libraries which even if they might have external similarities, appear to have been written by different people and to a very different architecture.

So my conclusion is that it is probably easier to write a new binding from scratch. And perhaps in a second phase I could add the ThingHandler and ThingHandlerFactory code from the one to the other. (This is essentially what I did with the Hue binding API v1 and v2 where essentially we have two completely different bindings appearing under the same umbrella).

6

It is still a work in progress but the initial code is here..

7

it’s pretty much pointless excercise in uk, unless you buy your own meter it will be passwortd protected. I spent days trying to talk to my supplier meter, and got 0 signals back, not even a blip, bought the same make an model from electrical distributor and i had a basic handshake, didn’t go any further as what’s the point. BG, Octopus, EDF, all lock their optical ports.

8

Yeah. I wrote the binding. Then I discovered that the meter does not answer any queries via the optical port. It is basically blocked..