New smartmeter binding

Hi all

I am writing a new binding that will communicate with the smartmeter that I have. (echelon 83331-3i meter).
I have some basic communication working and the idea is to publish the binding once it is a bit more polished. The protocol is C12.18 and C12.19 the details can be found here OSGP Alliance - MEP and Optical Interface · GitHub.

My first question is.
Would it be best to try in incorporate this in the existing smartmeter binding as a new thing or should I go with creating a new binding that I can publish on the community marketplace?

I guess it depends on if it is likely that a pull request will be accepted. So is the maintainer of the original smartmeter binding still active (Matthias Steigenberger) and is he the one that would be deciding this ?

1 Like

We do not centrally manage development up to a point of chasing people :slight_smile:
This is an all-volunteer project and sometimes people just stop contributing and vanish silently and there’s no plan B for that. So there’s no direct answer to your question I believe.
Didn’t you contact him?

I think it depends more on whether it makes sense to build a generalized binding (to potentially support yet more devices) or if they’re technically too different.

Having one binding with two maintainers would be preferred on everyone’s part I guess.

Yes they are. I used to work with smart meters and I know the echelon meter very well.
The protocol is very different, you need a “unique key” from the supplier so the meter will give you any information through the optical port.
Also there is no standardized OBIS Code. It can be different and depends on the configuration of the meter.
So not much concordance to the implemented SML protocol in the existing smartmeter binding.

I did not try to contact any developer of the existing smartmeter binding ( apart from this post🙂.)

Mostly because I do not think there will be much code sharing between the two protocols as Tuny says.

From an end user perspective it would make sense to have it in one binding, because the smartmeter binding name is very general.

But from a code maintenance perspective it does not and it would not make sense for him to have to approve a pull request for some code that does not relate to his.

So I guess the best approach is a new binding.

Any suggestions for the name?
I was thinking smartmeter-OSGP or something.
But I am a bit unsure about the names and what they actually cover.

To give some perspective on the names. The name is technically the package name of the binding. There are some limitations, for example it is lower case and - is not allowed. In general naming of the binding is either a brand name, brand product range or protocol name. In this case I would go for the protocol name osgp since it seems different brands would be covered by this binding.

On the smartmeter binding. That name is indeed a bit unfortunate as it is very generic and doesn’t cover all smart meters. Actually there is already a different smartmeter binding dsmr, which is supports meters supporting the dsmr protocol. (That protocol is actually a specialization of the DLMS/COSEM protocol supported by the smartmeter binding). The dsmr binding has a bridge that manages the connection and several things for different versions of dsmr for different meter types (electra, gas, …) and some meter specific things.