By nissi , 24 December, 2025

how to read multiple meters same serial connection

Forums
Gurux.DLMS

i am using C# Gurux DLMS.Client.Example and trying to write own based on that example now how can read multiple meters at a same time in single connection dose i know the we need Disconnect() for every new meters before go to next meter how to do that or this method is wrong!

By Bhaumik , 23 December, 2025

Time Conversion

Forums
Gurux.DLMS

HI Mikko,

I have received bytes from meter as 09 04 05 00 ff ff

Now while I am converting value it is coming as below:

-- 05:00:*.255

I want value like 05:00:*

Can you please provide sample code for that in c# so I can convert it.

By DLMSHexingDev , 22 December, 2025

DLMS Response Returns BCD value

Forums
Gurux.DLMS

Hi everyone. I am reading OBIS 1.0.1.6.0.255 from a Hexing HXE310KP meter via GSM using Gurux.DLMS. I receive the following response packet:

00-01-00-01-00-10-00-09-C4-01-41-00-0D-03-17-93-80

I can see that the last three bytes correspond to the value I obtain when reading the meter using HexView software. However, when reading the same OBIS via Gurux, the value returned is only the BCD value 3.

What could be the cause of this discrepancy?

Thanks in advance for your time and assistance.

By intellismartinfra , 19 December, 2025

writing TOU profile configurations: Error "Service not allowed"

Forums
Gurux.DLMS

We are writing TOU profile configurations, and it is getting success if payload size is less than 512 Byte, but if size of the payload is greater than 512 bytes so getting error that "Service not allowed".

Meter negotiated hdlc TX/RX = 128 Byte and MaxPdu Size 512 Byte

Below are the Two Payload, with one which is < 512 is getting Success:

1- Write Success:

By enemy235 , 17 December, 2025

Error parsing ASN1 CSR, keyUsage field

Project
gurux.dlms.java
Status
Closed (fixed)

There is a problem in parsing some CSR in GXAsn1Converter.java, when parsing a specific CSR (problematic CSR is added in HEX and PEM at the end).

The problem is probably in the keyUsage segment. This CSR defines the key ussage in slightly different way, but it is not incorrect way.

Usually it is defined as 03020080 10000000
but in this case uses 03020780 1 (using only 1 bit). From my understanding of ASN1, the 07 in previous segment, specifies, that last 7 bits are not used. When using other ASN1 parsers (eg. https://lapo.it/asn1js/ or openssl) it is decoded correctly there.

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 1 out of bounds for length 1
at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
at java.base/java.util.Objects.checkIndex(Objects.java:385)
at java.base/java.util.ArrayList.get(ArrayList.java:427)
at gurux.dlms.asn.GXAsn1Converter.getValue(GXAsn1Converter.java:341)
at gurux.dlms.asn.GXAsn1Converter.getValue(GXAsn1Converter.java:322)
at gurux.dlms.asn.GXAsn1Converter.getValue(GXAsn1Converter.java:307)
at gurux.dlms.asn.GXAsn1Converter.getValue(GXAsn1Converter.java:322)
at gurux.dlms.asn.GXAsn1Converter.getValue(GXAsn1Converter.java:322)
at gurux.dlms.asn.GXAsn1Converter.fromByteArray(GXAsn1Converter.java:536)
at gurux.dlms.asn.GXPkcs10.init(GXPkcs10.java:167)
at gurux.dlms.asn.GXPkcs10.<init>(GXPkcs10.java:126)

I tried to fix the issue, but I think, I only suppressed the problem with this additional if statement. But there is probably problem deeper in the ASN1 convertor.

case BerType.CONSTRUCTED | BerType.SET:
if (s != null) {
s.increase();
}
tmp = new ArrayList<Object>();
getValue(bb, tmp, s, false);
if (tmp.get(0) instanceof GXAsn1Sequence) {
tmp = (GXAsn1Sequence) tmp.get(0);

//Added check here
if( tmp.size() == 2) {
objects.add(new GXSimpleEntry<Object, Object>(tmp.get(0), tmp.get(1)));
} else {
objects.add(new GXSimpleEntry<Object, Object>(tmp.get(0), null));
}

} else ...

Error will occur for this CSR:
308201333081B8020100301B3119301706035504030C1035413530343130
3033423942394238463076301006072A8648CE3D020106052B8104002203
6200043B2781FC974699C1527048F958CBD9FB4DB06B7F4088054915C8DC
49C6B84271CF2DA634908BB36C4E025B25C77F3DF86BF6116181A73ECF5E
795731BE2457090A18A6EBD012FE54D85B2796BD8D18E1C9943FA189236F
88CCD82274B8174E46A01E301C06092A864886F70D01090E310F300D300B
0603551D0F040403020780300C06082A8648CE3D04030305000368003065
023056A28854C295777D88A077B6E82C299C06CE5CDBF471E47EAD65FB0D
F1CC600E4DB71639653FCBD3277A94BFB8BCD544023100A6C182F4FC7663
6133F48D2500D750C7E081B90EFFCD79DE64781443DD9AE2B1ED68AB6FAE
FA8C16E16B230705C9DAF0

-----BEGIN CERTIFICATE REQUEST-----
MIIBMzCBuAIBADAbMRkwFwYDVQQDDBA1QTUwNDEwMDNCOUI5QjhGMHYwEAYHKoZI
zj0CAQYFK4EEACIDYgAEOyeB/JdGmcFScEj5WMvZ+02wa39AiAVJFcjcSca4QnHP
LaY0kIuzbE4CWyXHfz34a/YRYYGnPs9eeVcxviRXCQoYpuvQEv5U2Fsnlr2NGOHJ
lD+hiSNviMzYInS4F05GoB4wHAYJKoZIhvcNAQkOMQ8wDTALBgNVHQ8EBAMCB4Aw
DAYIKoZIzj0EAwMFAANoADBlAjBWoohUwpV3fYigd7boLCmcBs5c2/Rx5H6tZfsN
8cxgDk23FjllP8vTJ3qUv7i81UQCMQCmwYL0/HZjYTP0jSUA11DH4IG5Dv/Ned5k
eBRD3Zrise1oq2+u+owW4WsjBwXJ2vA=
-----END CERTIFICATE REQUEST-----

Priority
Normal
Category
Bug report