By Naman_Shandilya , 23 July, 2026

Help Needed: Interfacing Saral 100 Energy Meter with Microcontroller via RS232

Forums
Gurux.Serial

Hi everyone,

I am new to the DLMS and energy meter domain. I am working on interfacing a Saral 100 energy meter (Secure Meters) with my microcontroller over the RS232 protocol. I’ve received some initial details from the vendor, but I want to confirm what exact parameters and values are required from the manufacturer to ensure proper communication and data reading.

Here’s what I have so far:

Voltage Levels – RS232 standard voltage levels (3–5 V depending on signal type).

Serial Communication Settings – Baud rate: 9600 bps, Parity: None, Stop bits: 1.

By Frank , 20 July, 2026

Connecting Meter to Agent via serial

Forums
Gurux.DLMS.AMI

Hi,

I have tried to use the AMI4 and connected to a meter. the connection was via tcp and it worked.

Now im trying to connect to the meter via serial but i can't seem to initialized the serial connection to meter even with the correct serial parameters.

Do i need to make/use the scripts to connect to the meter? if so what does the script expect as an output and i am assuming that the script is in c#

Thank you very much for your support

By Jayaraj , 18 July, 2026

Reading block profile with Compact array

Forums
General discussion

Hi, am trying to read meter that supports compact array for load profile reading. I have following observation with Compact array.

- Whenever I read few entries that fit in single window, all works fine.
- Whenever I try reading more entries that triggers block transfer, director throws exception

By eriktrif , 17 July, 2026

Incorrect LastBlock handling in multi-block ActionRequest

Project
Gurux.DLMS.Python
Status
Active

multipleBlocks() in GXDLMS.py

Current code:
len_ += p.attributeDescriptor.size

Should be:
len_ += p.attributeDescriptor.available()

Reason:

For the second and following PDU blocks, attributeDescriptor has already been consumed in the first block.

At this point the buffer position is already at the end, so:
p.attributeDescriptor.available()
returns 0.

However:
p.attributeDescriptor.size
returns the full buffer size (9 bytes in this case), which incorrectly increases the calculated PDU length.

Because of this, for some boundary data sizes multipleBlocks() calculates an incorrect PDU size and the final block is generated with:
LastBlock = 0
instead of:
LastBlock = 1

This causes the receiver to wait for another block even though all data has already been transferred.

Priority
Normal
Category
Bug report

Kurumi

2 months 2 weeks ago

Hi,

Thank you for pointing this out. This is still being tested because it affects all communication. The new version should be released this week once all tests are complete.

Regards,
Mikko

eriktrif

2 months 1 week ago

Hi, Thank you for taking on this issue!
While you are testing this area before the release, I noticed another related boundary issue in GXDLMS.getLNPdu().

When calculating whether the remaining data fits in the current PDU:

totalLength = len_ + len(reply)

totalLength does not account for the byte count header added right after by _GXCommon.setObjectCount(len_, reply).

Because of this, at the exact boundary where len_ + len(reply) == p.settings.maxPduSize, totalLength > p.settings.maxPduSize evaluates to False. The data is not truncated, and setObjectCount() adds 1 extra byte, resulting in a PDU that exceeds maxPduSize by 1 byte (e.g. 101 bytes instead of 100) while LastBlock is set to 0.

Proposed fix for both issues in GXDLMS.py:

1. In multipleBlocks():

Current code:
len_ += p.attributeDescriptor.size

Should be:
len_ += p.attributeDescriptor.available()

2. In getLNPdu():

Current code:
totalLength = len_ + len(reply)

Should be:
totalLength = len_ + len(reply) + _GXCommon.getObjectCountSizeInBytes(len_)

Hope this helps

By eriktrif , 17 July, 2026

Incorrect timezone offset calculation

Project
Gurux.DLMS.Python
Status
Closed (fixed)

Incorrect timezone offset calculation in setDateTime() in _GXCommon.py

Current code:

d = int(dt.value.utcoffset().seconds / 60)

Should be:
d = int(dt.value.utcoffset().total_seconds() / 60)

Reason:

timedelta.seconds does not preserve the sign of the timedelta. It returns only the seconds component in the range 0...86399.

For example, for UTC-3 offset:
timedelta(seconds=-10800).seconds
returns 75600 instead of -10800.

As a result, negative UTC offsets are encoded incorrectly.

total_seconds() correctly preserves the sign of the offset.

Priority
Normal
Category
Bug report

Kurumi

2 months 2 weeks ago

Hi,

Thank you for pointing this out. It was easy to verify with the current time and a negative time zone.

dt = datetime(2026, 8, 17, 12, 0, 0,tzinfo=timezone(timedelta(hours=-3)))

This is fixed in version 1.0.202, and your name is added to the credits.

Regards,
Mikko

By Dmitry , 16 July, 2026

CGXDLMSProfileGeneric::SetValue for attribute 3. Possible memory leak

Forums
Gurux.DLMS

Hi, Mikko!

In CGXDLMSProfileGeneric::setValue() in else if (e.getIndex()== 3) calls m_CaptureObjects.clear(); but there is no memory release, like in the destructor.
After m_CaptureObjects.clear(); in the loop, calls AddCaptureObject(), where it calls the new operator: CGXDLMSCaptureObject* pCO = new CGXDLMSCaptureObject(attributeIndex, dataIndex);

Thanks!

By craqdi , 14 July, 2026

Clou

Forums
General discussion

I want to put a simulator in clou format how should it be done?