Meter access over TCP/IP (WRAPPER)

By chavar , 16 October, 2017

Forums

I am working with an Iskra MT382 with the latest (2.2.12) version of the gurux.dlms.java library. I am using the GXDLMSClient class for programmatic access to the meter. The desktop application GXDLMSDirector works just fine over TCP/IP (WRAPPER) with the meter, while the programmatic access does not work at all. There is no response from the meter.

I have noticed a one-byte difference (3d byte from the end) between the AARQ packet sent by the GXDLMSDirector and the one created by the GXDLMSClient:

GXDLMSDirector: 00010001000100386036a1090607608574050801018a0207808b0760857405080201ac0a80083132333435363738be10040e01000000065f1f0400401e1cffff
GXDLMSCient:
00010001000100386036a1090607608574050801018a0207808b0760857405080201ac0a80083132333435363738be10040e01000000065f1f0400401e1dffff

Hi,

Your conformance bits are different. It's interesting if this is the reason why your meter is not reply.
Proposed conformance should tell what services client wants to use.

Try to remove Action bit like this.

cl.ProposedConformance &= ~Conformance.Action;

Let me know what happened.

BR,

Mikko

Response

The messages are switched in my previous post. The "1d" is from the GXDLMSDirector, the "1c" is from the "GXDLMSClient". So the Action bit was missing instead of not being present. Looking throught the source code for the java library, the constructor for the GXDLMSSettings calls the GXDLMSClient.getInitialConformance method with a false flag. This method is used to set the proposed conformance, and the flag is set for Serial Name referencing.

I changed the default from Serial Name referencing conformance to Logical name referencing conformance and the messages are the same now (the 3rd byte from the end is "1d" for both"). The meter does not respond still.