I am using the Gurux DLMS pyton client inside a Kubernetes pod to connect to a DLMS meter using HLS SHA256 authentication.
The client is able to successfully establish a connection and read data from the meter under normal conditions.
However, I am facing an issue after the Kubernetes pod restarts:
Once the pod restarts, the client tries to reconnect to the meter.
The connection attempt fails consistently.
The error I receive is:
"Failed to receive reply from the device in given time."
1. Does the DLMS meter require a proper release/disconnect before allowing a new HLS session? (Meter is also not getting timed out)
2. Is there a recommended way in Gurux to handle abrupt disconnections (e.g., pod crash/restart)?
In addition to our pervious discussion, I have following questions:
I’m using **Gurux.DLMS.Simulator.Net** as my meter with the template `LN-v2-Sha256WithAuthenticationEncyption2.xml`. I start the simulator using:
```
dotnet run -S /dev/tnt0 -x ./Templates/LN-v2-Sha256WithAuthenticationEncyption2.xml -i HDLC -t Verbose
```
On the client side, I connect to the meter using **HDLC over TCP** by creating a serial-to-TCP bridge with `socat`.
In this setup, I’ve noticed that the server does not time out even after 30 minutes of client inactivity. I was expecting the connection/session to close due to inactivity, but that doesn’t happen. After this, I am trying to connect to meter again, but it fails as I mention earlier.
Am I missing any configuration or doing something incorrectly in this setup?
Hi, Yes, the client must…
Hi,
Yes, the client must close the connection. If the client does not close the HDLC connection properly, you must wait for the inactivity timeout, which is usually about 2 minutes.
You can read the inactivity timeout from HDLC setup object.
https://gurux.fi/Gurux.DLMS.Objects.GXDLMSIecHdlcSetup
BR,
Mikko
Hi, Thanks for your response…
Hi,
Thanks for your response.
As I mentioned earlier, in our case the meter is not reaching the inactivity timeout. We are running the client inside Kubernetes, and when the pod restarts, the application comes back up quickly and immediately attempts to reconnect.
Because of this, the meter likely still considers the previous HDLC session as active, and the new connection attempt fails with:
"Failed to receive reply from the device in given time."
From the meter’s perspective, it seems unable to differentiate between:
the previous (abruptly terminated) session, and
the new session initiated after pod restart
The client continuously retries connection in a loop, and on failure or restart, it attempts to reconnect without waiting for the inactivity timeout.
Also, during pod restart/crash scenarios, the close() method is not executed, so the HDLC disconnect (DISC) or release is never sent to the meter.
Given this setup, I have a couple of follow-up questions:
Is there any recommended approach in Gurux or DLMS to handle such abrupt client terminations where a proper disconnect cannot be guaranteed?
Is there any mechanism (e.g., client address variation, force SNRM, or session reset) that can help the meter accept a new connection immediately?
Hi, According to the DLMS…
Hi,
According to the DLMS standard, you must wait until the inactivity period has expired.
You must always call disconnect when the connection is terminated. If the disconnect is not called, you need to wait until the inactivity period expires.
Some meters can handle an SNRM message before the inactivity period expires, but most cannot.
BR,
Mikko