Auto‑Connect class

By NordicRelay , 21 January, 2026
Forums
Gurux.Net

I would like to ask about the implementation of the Auto‑Connect class in Gurux. Is it possible to simulate this class in the Gurux DLMS Simulator? My goal is to create a program that can simulate GPRS‑style sending and receiving, and I am specifically interested in the byte‑level packet behavior.

I also have a question regarding Protocol‑E communication. After the meter switches to the new baud rate, I am not receiving the expected ACK frame. Could you clarify what might cause this issue or what the correct sequence should be?

Thank you.

Kurumi

4 months 3 weeks ago

Hi,

Yes, it's possible, but it needs some work. At first, add the Auto Connect object.

Then add connection logic here:

https://github.com/Gurux/Gurux.DLMS.Net/blob/751914f4a9a6fd504e5b8c6430…

You need to establish the connection to the meter and create a new instance from GXDLMSMeter. This is needed because settings might be different than the current connection. Call HandleRequest when meter is receiving data.

Are you using the simulator or a real meter with a Mode E problem?

BR,
Mikko

NordicRelay

4 months 3 weeks ago

Hi,

Thank you for your answer!

So it is not possible to configure GURUX.Director in that way. I mean, it was possible to add the auto‑connect class into the simulator, but it probably won’t respond automatically.

I am using a real meter for protocol‑E.

Kurumi

4 months 3 weeks ago

Hi,

GXDLMSDirector can only establish the connection to the meter. Auto connect requires that there is TCP/IP server that is listening for incoming connections, and then starts a new connection when the meter connects to the server.

There are multiple parameters that must be correct to make this work. Implementing an app that can work with different meters is not an easy task.

Some meters don't work correctly with Mode E. What reply does the meter send?

BR,
Mikko

NordicRelay

4 months 3 weeks ago

Hi,

Thank you for your answer!

Regarding protocol‑E:
The meter is not responding at all, or at least it appears that way in the Gurux program. The ACK at the new baud rate is not shown in the log, although in some cases part of the packet appears, and the original software shows that it was received. This makes me wonder whether the issue is related to timing in the Gurux program or some delay. In other words, the ACK is not detected, but the HDLC communication works later, which is confusing.

NordicRelay

4 months 2 weeks ago

Hi,

Regarding the Protocol‑E question — yes, I checked it. I also noticed that the driver configuration differs between software implementations. There might be difference in the Flow control for example even if it the protocol e specifies mostly baudrate number of bits and parity.

Also When I use the connect/disconnect functions in the electric power meter simulator on the local network, the simulator does not always send the same packet. For example, when I try to connect from the meter, Gurux sends a disconnect request:

7E A0 08 02 03 03 53 09 B1 7E

I expect to receive something like:

7E A0 08 03 02 03 1F 06 7F 7E

Most of the time I do get this response.
However, sometimes the simulator sends back the following instead:

7E A0 1F 03 02 03 73 F0 52 81 80 FD 05 01 80 06 01 80 07 04 00 00 00 01
08 04 00 00 00 01 CF 99 7E

According to the parser, this is a UA frame.
Is this correct? Shouldn’t the simulated electric power meter always send the disconnect‑mode packet?
Or are there exceptions — for example, after a connection request, reading the clock object, and then sending a disconnection request — where the simulator is allowed to send a UA frame instead?

I’m a bit confused.

Kurumi

2 months ago

Hi,

The DLMS standard defines that the meter returns a UA frame for the disconnect message.

BR,
Mikko