I have a DLMS server running on a 32-bit MCU and a DLMS host also running on a 32-bit MCU, communicating via PLC. Both work correctly: I have created several objects on the server and can successfully connect, get the association view, perform read/write operations, and close the connection properly.
I'm building a DLMS/COSEM client on Android using custom USB serial communication (no GXSerial/GXMedia). I send an SNRM request and receive a UA response that starts and ends with 0x7E, but the Gurux Java parser treats it as malformed.
Works:
Genus and Landis+Gyr meters: UA parsed correctly.
Fails:
HPL and L&T meters: UA response appears malformed.
The same configuration (client address, baud rate, etc.) works fine in the Gurux DLMS demo app.
For single metering manufacturing company should same logical device name for all meters or different. as stated in blue book in clause no. 4.1.8.2 that
Each COSEM logical device can be identified by its unique COSEM LDN. The LDN is defined. as a string of up to 16 octets.
i am mentioning example in both way that which one is correct.
I’m using GXSerial (USB) without GXMedia to read DLMS meter data. During Association Response, I receive all OBIS codes in one large response frame, like this:
I have successfully established the Bluetooth connection and completed both the SNRM and AARQ stages. However, during the Association View phase, I'm facing an issue where the full HDLC response is not being received consistently. Despite requesting the maximum MTU size of 517, the response often gets truncated.
For example, sometimes the Association View responses complete up to the 9th continuation request, while at other times, it stops at the 3rd or 4th request, resulting in an incomplete frame and a parsing failure.
when I am trying to communicate with the meter, I am facing issue at 7th transmission I am getting error code response from the meter as read write denied.
