Why I need to setup the OBIS list, when the meter sents a pushlist

[antonmeyer]

I wonder why I need to configure a OBIS list, when the push Messages containing the OBIS code.
So my approach would be: search for the push list, read the OBIS codes included there and than construct the pairs: OBIS code, values (scaler, unit)
It might be, that I want to setup a filter to Values of interests, but in the first step I would like to see all values sent by the meter.

[raymar9]

Hi antonmeyer
The problem is that not every meter sends a push list. It depends on the meter type and the meter configuration.
As an end-user, you do not require to setup an OBIS list. What leads you to this assumption? Especially with the rework of the data parsing from last month (version 1.1.0) it is not even required for new smart meter types - you can use the default list.
The default RegisterCosem() list in cosem.py is only required to map the OBIS code to the MeterDataPointTypes.

[antonmeyer]

I assume that I have downloaded the newest version last week. The OBIS codes I'v added has been missing in the output (with units) of the default sink. After adding the missing OBIS in cosem and meter it is shown there.
I guess it is because of the filter against the defined OBIS and MeterPoints.
And I agree, when you do not have a pushlist in the HDLC frames then you have to provide it manually.
But only then. I do not have an overview, how large the super-set of all energy meter and operators in the DACH region is, but that is what I would prefer. And then setting a filter via OBIS code is also ok. (in 1 file)
Please do not get me wrong. I profit a lot from your code to understand that gurux monster better. And as this project is founded by EKZ I assume your focus is on EKZ and not at DACH or the whole world.

[raymar9]

The OBIS codes I'v added has been missing in the output (with units) of the default sink. After adding the missing OBIS in cosem and meter it is shown there.

Yes, you are right here: These values are missing in the default list. You can, if you like, propose a change via Pull-Request. We just added the most used OBIS codes.

And I agree, when you do not have a pushlist in the HDLC frames then you have to provide it manually.
But only then. I do not have an overview, how large the super-set of all energy meter and operators in the DACH region is, but that is what I would prefer. And then setting a filter via OBIS code is also ok. (in 1 file)

We realized that we need to be very generic to allow the tool be used also by customers other operators (also of foreign countries). The superset of different meters and especially configurations is huge. Therefore, we decided that this was the better way. Additionally, I think, since OBIS, DLMS, COSEM are standards, they shall be valid for all different meters and contained in one location, in one list.
Further, having a list of OBIS codes for each meter and operator requires a tremendous amount of maintenance work and not every end user is able to generate such.

And as this project is founded by EKZ I assume your focus is on EKZ and not at DACH or the whole world.

Yes, the project is funded by EKZ and we based the software only on meters and configuration used by them at first. However in the meantime, we also integrated other meters and support meter-configurations that EKZ does not use (like messages without push list). We also received feedback from users in Austria who have the same meter but a different configuration and could first not use our toolkit.

[antonmeyer]

Regarding the extension, if you don't mind, copy the few lines. But if it is more comfortable I can do it via pull-request as thank you for your inspiration. I will go for esp32 and c++. (my design will be much purer as I'm lazy)

[raymar9]

Thanks, I can include them myself. :)

ESP32 and c++ sounds interesting. Just out of curiosity, do you plan to share this code on Github? Are you planning to use the gurux C library?

[antonmeyer]

2x yes, attached the doc from my operator
2020_12_Kundenschnittstelle_CII_OBIS.pdf

[antonmeyer]

Hi raymar9,
I make a pause reagarding grux lib.
I managed to get it run as c++ on a Mac.
I could also port it to the Arduino esp32 envoironment.
But there the free memory was eaten up within 1 day.
For the test I was using basicly 3 lines
len = getSerialBytes(readbuf); //reading from the UART
hdlc_buffer.Set(readbuf, len); // append the readbuf - ToDo could we avoid the multiple copy of buffer???
if (0 == gxclient.GetData(hdlc_buffer, dlms_data))

It might be that it is no memory leak but stack fragmentation.
Next I switched to the c Arduino of gurux.
But here I was stucked as the .GetData did not decode the frames.
So the loop was closed and I'm a bit frustrated because of the not so well documented gurux lib.
I could not figure out what the return value of gxclient.GetData(hdlc_buffer, dlms_data)) exactly mean,
and what the relation to dlms_data.IsComplete() and !dlms_data.IsMoreData() is.
I could guess it somehow, but in the good old days at least the meaning of the return values had been in the header files comment of a function.
In my case isMoreData returns always with true, with the same 3 test frames which has been decoded in c++.
So far I have no idea why the c++ lib differs at that point to the c lib.

So I switched back to the ugly but efficient approach of hoping for static frame structure and check for the length of a HDLC frame and copy the 10 or 12 values I need.
Could differ for every meter and firmware version, but I do not have the goal to support the whole world's meters.

There are enough other challenges left, like weak WiFi signals in the basement or new versions of the influxdb cloud.