OBIS codes mismatch between GXDLMSDirector and Landis+Gyr Map110

By L0uisc_iot, 6 June, 2025
Forums
DLMSDirector

Hi everyone!

We have noticed that the OBIS of the capture objects differ between the Map110 and GXDLMSDirector tools.

The Map110 UI scales the values, while GXDLMSDirector does not. However, if the scalars for each of the registers are read and applied to the GXDLMSDirector values, you'll see that the values are identical. The active and apparent power registers have a scalar of 0.1, which is further scaled by 0.001 to get kW and kVA instead of W and VA in Map110. Current and voltage both have a scalar of 0.01.

We need to confirm the following:

1. Are the values for power (active and apparent) the current average (.4) or last average (.5)?
2. Are the values for voltage and current the instantaneous value (.7) or last average (.5)?
3. Why does the capture objects' OBIS codes differ between the two tools? How is it possible that the same meter has different capture objects on the same profile register?

I don't see a way to attach images, else I would have added screenshots.

Kurumi

2 weeks 2 days ago

Hi,

Screenshots are not possible to add at the moment due to spam. I hope it's possible again later when spamming is causing less work.

GXDLMSDirector reads the scaler from the meter and uses it. DLMS standards define that W and VA are used, not kW and kVA. The values are the same.

The profile generic values depend on how the meter is configured.
You can see saved values in the header field.

OBIS codes are the same. Map 120 just uses its own format to show them.

BR,
Mikko

L0uisc_iot

2 weeks 2 days ago

The OBIS codes are not the same though. The Map110/120 ones are .5 (Last average according to DLMS spec) while the Gurux ones are .4 (Current average) or .7 (Instantaneous).

The W and VA vs kW and kVA was my comment/explanation to make sure that the person reading my email (which had screenshots) would not be confused by that. I don't have an issue with the W vs kW and VA vs kVA.

Kurumi

2 weeks ago

Hi,

If I remember right, your client address is different in Map 120 and GXDLMSDirector.
Your meter returns different objects based on the authentication level and client address. The meter returns the OBIS codes (logical names), which are displayed on the UI as the meter returns them.

BR,
Mikko

L0uisc_iot

4 days 4 hours ago

Hi Mikko

We have been in contact with a Landis+Gyr representative about this issue. He pointed out that the value for Active Energy in our load profile comes from the ME7 +A measured quantity. The value in the load profile is shown as

"1-1:1.5.0 Last Average Demand ME7 +A"

in Map120.

This measured quantity ME7 +A includes

- 1-1:1.4.0 (Current Average Demand CAD7)
- 1-1:1.5.0 (Last Average Demand LAD7)
- 1-1:1.8.0 (Energy Total ET7)

OBIS codes.

In the GXDLMSDirector tool, the column heading for this item in the load profile shows

"1.1.1.4.0.255 Last Average Value Ch. 1 Sum Li Active power+ (QI+QIV) Current avg. 1 rate 0 (0 is total)"

This human readable name seems to include all three of the registers in ME7 +A.

Can you explain how we can confirm whether what we read is the current average value or last average value for this quantity?

Additionally, there is also ME8 +VA, ME3 +A - L1, ME4 +A - L2 and ME5 +A - L3 which shows similar behaviour.

Then we also have
- 1-1:32.5.0 Voltage L1
- 1-1:52.5.0 Voltage L2
- 1-1:72.5.0 Voltage L3
- 1-1:31.5.0 Phase Current L1
- 1-1:51.5.0 Phase Current L2
- 1-1:71.5.0 Phase Current L3

In Gurux, we see

- 1.1.32.7.0.255 Ch. 1 L1 Voltage Inst. value
- 1.1.52.7.0.255 Ch. 1 L2 Voltage Inst. value
- 1.1.72.7.0.255 Ch. 1 L3 Voltage Inst. value
- 1.1.31.7.0.255 Ch. 1 L1 Current Inst. value
- 1.1.51.7.0.255 Ch. 1 L2 Current Inst. value
- 1.1.71.7.0.255 Ch. 1 L3 Current Inst. value

Is there a way to confirm whether the voltage and current values are instantaneous or last average?

The numeric values in the load profile are identical in GXDLMSDirector and Map110. We are reading the same raw buffer values. The issue is one of data validity. I don't want to send running average values along and claim they are last average values.

Using Map110 is not a viable solution, since we're developing our own backend service to read 10k meters using Gurux .NET. I see the same OBIS codes in code as in GXDLMSDirector. If I try to read the 1.1.1.5.0.255 value e.g., I get an error in Gurux telling me the OBIS code does not exist. The Gurux library reads the same OBIS codes for the capture objects as in GXDLMSDirector.

Kurumi

3 days 11 hours ago

Hi,

The description of OBIS codes that you see in GXDLMSDirector comes from DLMS standards as they are. L+G is using its own descriptions.

The only way to confirm this is that it's defined in the meter documentation.
The meter documentation should describe what OBIS code is used.

You need to check that you are reading the same profile generic with GXDLMSDirector and Map120.

BR,
Mikko

L0uisc_iot

3 days 10 hours ago

Hi Mikko

I am sure it is the same load profile. The data is identical, just the OBIS codes of the capture objects differ. Even though the Landis+Gyr tool does not show the profile's OBIS code, it matches the column order and measured quantity types, etc.

My issue is not primarily the descriptions. My issue is that one tool uses 1.1.1.5 and the other tool shows 1.1.1.4 for the same column in the load profile. I need to confirm which value this is (current average vs last average) and why the Gurux tool differs from the Landis+Gyr tool.

Gurux reads capture objects with different OBIS codes from the Landis+Gyr tool. How can I find which tool/library is fudging the response values?

Kurumi

3 days 10 hours ago

Hi,

I don't have your meter, so I can't answer this question. Gurux libraries show read OBIS codes as meter returns them. They are not modified in any way.

Are you reading your meter with IEC or DLMS when you are using Map110? If you are using IEC it might explain this.

BR,
Mikko

L0uisc_iot

3 days 4 hours ago

Hi Mikko

I'm using DLMS via HDLC in both tools. I see options for HDLC, HDLC via IEC Mode E and WRAPPER, and then a separate option labeled "Standard" which has DLMS, Italy, Spain, India, Saudi Arabia and Idis as options on the Gurux side.

On Map110/120, I unticked the IEC checkbox, and I have DLMS link layer protocol set to HDLC.

Both tools also use TCP (instead of UDP).

I think that is identical, unless there is something very non-obvious which I'm missing.

We used the communication logs from both sides, with your DLMS Translator tool, and confirmed that the association view read reads the obis codes we see in the GXDLMSDirector UI. The meter uses short name referencing when communicating, so that might be the source of the discrepancy? Possibly MAP110 maps the short name internally without reference to the association values stored on the meter?

MAP110 reads the load profile differently. It seems to read the Buffer (Attribute index 2) and the Sort Object (Attribute index 6) when I request a read.

It also reads the scalar and unit attribute on the registers for the captured objects (presumably to scale the values read from the buffer).

I could not find where MAP110 reads the capture objects (attribute index 3 of the load profile) yet.

Thank you for the assistance thus far.

Kind regards
Louis

L0uisc_iot

2 days 11 hours ago

Hi Mikko

We think we have resolved the issue.

The meter uses short name referencing.

Gurux uses the Current association register to map between short names and OBIS codes.
Landis+Gyr showed that the OBIS code 1.4.0 (Demand Register), attribute index 3 is the "monitored value" configured for 1.5.0 (Extended Register).
That means the apparent discrepancy is resolved. The meter only uses short names, and the two tools map to two different aliased logical names for the same value.

Does this make sense to you?

Kind regards
Louis