Hi Mikko,
I am having a connection issue with this meter (Identification: IHM5\2Inhe Meder). The SNRM frame (03 03) is correct and works fine in other software.
The communication log reveals the exact problem during the IEC Mode E handshake:
1. Gurux sends the baud rate change command: 06 32 35 32 0D 0A
2. Gurux closes and reopens the COM port to change settings from 7E1 to 8N1 (takes ~110ms).
3. The Bug: After reopening the port, Gurux waits exactly 1000ms before sending the SNRM request:
• Log: 13:40:35.502 Info Open

Below, I put the log of a communication between GXDLMSDirector V 9.0.2508.2701.
My server is complaining of the expected next my frame sequence number. It should be 5, but a 7 was received. It made my Firmwate to stop.

Hi,
I am working with a DLMS meter that has 16 Class 7 (Profile Generic) OBIS objects.
I am able to read 12 out of the 16 Profile Generic objects successfully. However, when I try to read the remaining Profile Generic objects, I get the following error:
"Insufficient memory to continue the execution of the program."
The same meter and the same Profile Generic objects work correctly in the TALTECH/Renesas GUI, where I can read the data without any error.

Hello Mikko,

DLMS Director gives me an error message (something like Can't convert GXEnum to GXStructure) while reading Push Setup object.
I've made a little investigation.

Hello Mikko,

As written in Green Book:

"NOTE As specified in DLMS UA 1000-1 Ed. 13:2019, 4.1.2, manufacturers may add proprietary methods and/or attributes to any object, using negative numbers."

There is a lot of index positivity checks (for methods and attributes ) in GXDLMSClient.cs, so as far as I see proprietary methods or attributes will be blocked. Any way to change this behaviour?

Best regards, Andre

Hello Mikko,

I'd like to ask you about System title field structure.

As I know, Server system title is 8 bytes long, first 3 bytes is manufacturer code and 5 more are meter serial.

I never thought that System title must obey some rules too except 8 bytes long,
so I named it in my case as 'homepc08'

Recently I've noticed that DLMS Director in Translator dialog is trying to decode this field as

I'm testing an embedded LN-only DLMS/COSEM server with the GXDLMSDirector Application Conformance Test. 13 of 14 tests pass; the only failing one is T_APPL_DATA_LN_N1, and it always fails on subtest 3 ("Read non-existing object").

The tool sends a GET for a non-existing object (class 15 / Association LN,
OBIS FF FF FF FF FF FF, attribute 1):

C0 01 C1 00 0F FF FF FF FF FF FF 01 00

The overall result is always:

T_APPL_DATA_LN_N1 subtest 3 succeeded when Short Name referencing is used.
T_APPL_DATA_LN_N1 failed.

Hi,
currently waiting for my Optical Probe, but I need to read the data from my 3 phase meter & was wondering if anyone had any success?
Comment: In NSW, the meters are not open it seems. Other parts of Australia have open access, but some areas have no open access. In 2028 it is legislated that meters will have open access available, but existing meters may remain restricted.
By searching the net, I think the meter serial number is used as part of the access.

Hello Mikko,

Here is some strange case description:

- "Start receiving notifications" in Director enabled
- Push messages in meter enabled, so meter is constantly (10 retries) send same push message/data notification to the Director host via tcp/ip
-At the same time user trying to read simple data obis using the same Director instance

Result:

# Bug Name
**IndexOutOfRangeException when selecting version-dependent DLMS objects with unsupported attributes**

# Bug Description

## Summary
An `IndexOutOfRangeException` is thrown when selecting or reading certain DLMS objects (specifically `GXDLMSPushSetup`) that have version-dependent attribute counts, but whose UI views only implement controls for a subset of those attributes.