Hi, i am developing a gas-meter following the newly italian directive unit-ts 11291-14-2.
It states that Start of Convetional Gas Day on attribute 2 requires time data type (id=27), but in you implmentation you expect a date-time (id=25): https://github.com/Gurux/Gurux.DLMS.cpp/blob/master/development/include…

In your opinion, is this a change affceting only the newly italian normative, or new dlms/cosem sepcification?

Thank you,
Alessandro

Hi Kurumi,

I’m using Gurux DLMS with HDLC and based part of my receive logic on the examples in the Gurux repository. In particular, I copied the pattern here (https://github.com/Gurux/Gurux.DLMS.Net/blob/751914f4a9a6fd504e5b8c6430…) where a reply is treated as “no data yet” when:

reply.Error == 0 && reply.Data.Size == 0

Hello, i wanted to get more information about pre-established connection, because i want to use DLMS with smart water meter on NB IoT.

We are writing Passive TOU day profile which have 4 day table and 8 rate in each table, when we write all 4 day table with 8 rate in all table and it start transfer success for 2-3 packet and post this next command failed and getting error "Service Not Allowed", but when we reduce the data means select only few rate in all table so getting all success.
We analyse that if Payload size is <512 Byte able to write successfully in block transfer, but if no. of payload >512 byte this scenario regenerated using library as well as DLMS director.

Hi,
i have l&t meter(ER300P) 2016 make it working in both optical and rs485 but it take to much time for InitializeConnection around 4 min for both GXDLMSDirector and gurux dlms client example

Hello All,

I was trying to parse an HDLC frame(not DLMS) using GXDLMS DLMS translator.
I found that the online version of the tool parses the frame in a different manner than the offline tool, specifically the HDLC payload.
The online version always deducts the first byte of the payload while the offline tool shows the whole payload as expected.
I'm using HDLC type format 3 which shows that the payload starts right after the 2-bytes Header Check Sum (HCS).

Is there a reason why the offline parsing mechanism differ than the online one ?

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!

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.

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.

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: