Clock & Device ID abstraction

[aselviar]

When the clock or Device ID with obis code below are not pushed from the smart meter because they are configured not to push them (depends on the standard CII configuration of each DSO), the dlms parser does not parse the data and the data are not saved in the influx db for the demo. This was the case when we tried to read out the AEW smart meter with different configuration as that of EKZ.

The reason is that the id and clock obis codes are hard coded. Possible work arounds:

• when the clock is not pushed, take the linux time instead
• if the device id is not pushed, add alternative obis id codes to choose from or hardcode as "smartmeter1", "smartmeter2" and so on

id_obis="0.0.42.0.0.255",

93 | clock_obis="0.0.1.0.0.255",

[tom-ch1]

See tom-ch1/smartmeter-datacollector@7a3b34a for the patch we used to make this work for an AEW smart meter (same brand and model as EKZ, just different config).

[tom-ch1]

It would be useful to have configuration-style files to specify the properties of a certain model. The AEW smart meter, for instance, just uses a different obis id for the smart meter id:

• EKZ: id_obis="0.0.42.0.0.255"
• AEW: id_obis="0.0.96.0.0.255"

Something like lge450_EKZ.conf or lge450_AEW.conf instead of lge450.py

[aselviar]

@Montellese @tom-ch1 @raymar9
I would not go with different configuration files for the different utilities, as there are too many to create a conf file for each one of them.

A more abstract way to solve this is:

• clock: if no clock_obis is pushed from the smart meter --> use linux time instead
• for id_obis check if one of the following is pushed:

1. 0-0:96.1.0;2
2. 0-0:96.1.1;2
3. 0-0:96.1.2;2
4. 0-0:96.1.3;2
5. 0-0:96.1.4;2
6. 0-0:96.1.5;2

if none of them pushed --> generate a generic id

[tom-ch1]

Fair enough, that's a good point, Angelos. One configuration file per utility company would definitely be an overkill.

However, a configuration file instead of a python file would still be preferrable. Imagine some user wants to use the library but something has to be adapted for his smart meter. He won't touch a python file, but he might adapt a config file if it is well documented.
As for the id: I don't quite understand the notation, but it seems to me that your proposal won't match neither EKZ nor AEW

[aselviar]

Sorry, there was a confusion here.

What the EKZ Smart Meter pushes is the COSEM logical device name with the OBIS Code: "0.0.42.0.0.255"

The AEW Smart Meter does not push this but pushes insted Device ID 1: "0.0.96.1.0.255"

The notation is different in the code as in the OBIS structure since the OBIS Code is represented with this notation in the GuruX library (dot instead of -,:,; and 255 in the end).

As ID of the smart meter for the code I would search the following OBIS codes - if they are pushed - :

0-0:42.0.0;2 - COSEM logical device name
0-0:96.1.0;2 - Device ID 1
0-0:96.1.1;2 - Device ID 2
0-0:96.1.2;2 - Device ID 3
0-0:96.1.3;2 - Device ID 4
0-0:96.1.4;2 - Device ID 5
0-0:96.1.5;2 - Device ID 6

If none of them is pushed, the create a generic ID.

The above OBIS Codes are universal and should apply for all smart meters.