Hope you're doing fine. I am facing a gurux exception while trying to reconnect to a meter I was already connected to using a serial port. I am using the latest version of gurux.dlms package, I updated it recently, I haven't faced this kind of issue while I was using the older version.
I saw this kind of topic in the forum and I also tried the fix you recommended but my meter doesn't have invocation counter object and also the ciphering security is none for the time being, so that fix didn't help.
This is the exception it throws:
gurux.dlms.GXDLMSException: Connection is permanently rejected
No reason is given.
at gurux.dlms.GXAPDU.parsePDU2(GXAPDU.java:1136)
at gurux.dlms.GXAPDU.parsePDU(GXAPDU.java:867)
at gurux.dlms.GXDLMSClient.parseAareResponse(GXDLMSClient.java:924)
GXCommunicate is the class I am using to implement my logics. This is the log I get when trying to reconnect.
INFO GXCommunicate - -> 11:26:16.967 7E A0 08 02 21 09 93 F6 3C 7E
INFO GXCommunicate - -> 11:26:16.967 7E A0 08 02 21 09 93 F6 3C 7E
INFO GXCommunicate - Media
INFO GXCommunicate - true
INFO GXCommunicate - <- 11:26:16.994 7E A0 21 09 02 21 ... 08 04 00 00 00 01 CE 6A 7E
INFO GXCommunicate - -> 11:26:16.994 7E A0 45 02 21 09 10... 5D 00 64 2D C0 7E
INFO GXCommunicate - -> 11:26:16.994 7E A0 45 02 21 09...42 1E 5D 00 64 2D C0 7E
INFO GXCommunicate - Media
INFO GXCommunicate - true
INFO GXCommunicate - <- 11:26:17.073 7E A0 2E 09 02 21...04 04 0E 01 06 01 43 31 7E
gurux.dlms.GXDLMSException: Connection is permanently rejected
No reason is given.
at gurux.dlms.GXAPDU.parsePDU2(GXAPDU.java:1136)
at gurux.dlms.GXAPDU.parsePDU(GXAPDU.java:867)
at gurux.dlms.GXDLMSClient.parseAareResponse(GXDLMSClient.java:924)
I tried removing DeltaValueEncoding from the proposed conformance set and sending the request but it still does not fix the issue.
I face the issue when I try to reconnect, I can connect to the meter once but after disconnecting, I can not reconnect I have to reopen the application to connect. I found a difference in the AARQ request of the first connection request and the second request connection.
This is the AARQ sent at the first connection and the response I get and it connects fine once.
INFO GXCommunicate - -> 10:16:13.214 7E A0 45 02 21 09 ...1F 04 00 42 1E 5D FF FF B7 15 7E
INFO GXCommunicate - <- 10:16:13.288 7E A0 38 09 02...00 07 DA AA 7E
But When I try to reconnect, after a disconnect request or a timeout, I call the same initialize connection method but it generates a different AARQ request and gets a different response from the meter because of that.
INFO GXCommunicate - -> 10:17:44.942 7E A0 45 02 21 09...04 00 42 1E 5D 00 64 2D C0 7E
INFO GXCommunicate - <- 10:17:45.021 7E A0 2E 09 02 21...04 04 0E 01 06 01 43 31 7E
I am using the latest gurux.dlms version 4.0.38.
The problem was with the Max PDU size, I don't know why but it is affecting it. I have given it a fixed number and now I can connect and reconnect fine.
I believe that you don't call releaseRequest and disconnectRequest directly.
Because releaseRequest is not called the original PDU size is not recovered.
The proposed PDU size shouldn't basically affect the connection, but this is fixed for the next release.
Hi,
Hi,
There shouldn't be any changes to this in a very long time. Can you get a hex trace so I can try to find out what might be the reason for this?
BR,
Mikko
Thank you for the fast reply.
Thank you for the fast reply.
GXCommunicate is the class I am using to implement my logics. This is the log I get when trying to reconnect.
INFO GXCommunicate - -> 11:26:16.967 7E A0 08 02 21 09 93 F6 3C 7E
INFO GXCommunicate - -> 11:26:16.967 7E A0 08 02 21 09 93 F6 3C 7E
INFO GXCommunicate - Media
INFO GXCommunicate - true
INFO GXCommunicate - <- 11:26:16.994 7E A0 21 09 02 21 ... 08 04 00 00 00 01 CE 6A 7E
INFO GXCommunicate - -> 11:26:16.994 7E A0 45 02 21 09 10... 5D 00 64 2D C0 7E
INFO GXCommunicate - -> 11:26:16.994 7E A0 45 02 21 09...42 1E 5D 00 64 2D C0 7E
INFO GXCommunicate - Media
INFO GXCommunicate - true
INFO GXCommunicate - <- 11:26:17.073 7E A0 2E 09 02 21...04 04 0E 01 06 01 43 31 7E
gurux.dlms.GXDLMSException: Connection is permanently rejected
No reason is given.
at gurux.dlms.GXAPDU.parsePDU2(GXAPDU.java:1136)
at gurux.dlms.GXAPDU.parsePDU(GXAPDU.java:867)
at gurux.dlms.GXDLMSClient.parseAareResponse(GXDLMSClient.java:924)
Hi,
Hi,
Try to remove DeltaValueEncoding from the proposed configurations. It might be that the meter doesn't allow it's used.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I tried removing DeltaValueEncoding from the proposed conformance set and sending the request but it still does not fix the issue.
I face the issue when I try to reconnect, I can connect to the meter once but after disconnecting, I can not reconnect I have to reopen the application to connect. I found a difference in the AARQ request of the first connection request and the second request connection.
This is the AARQ sent at the first connection and the response I get and it connects fine once.
INFO GXCommunicate - -> 10:16:13.214 7E A0 45 02 21 09 ...1F 04 00 42 1E 5D FF FF B7 15 7E
INFO GXCommunicate - <- 10:16:13.288 7E A0 38 09 02...00 07 DA AA 7E
But When I try to reconnect, after a disconnect request or a timeout, I call the same initialize connection method but it generates a different AARQ request and gets a different response from the meter because of that.
INFO GXCommunicate - -> 10:17:44.942 7E A0 45 02 21 09...04 00 42 1E 5D 00 64 2D C0 7E
INFO GXCommunicate - <- 10:17:45.021 7E A0 2E 09 02 21...04 04 0E 01 06 01 43 31 7E
then the exception is thrown.
Thanks,
Adonay Eshetu
Hi,
Hi,
Are you closing the connection before connecting again?
https://github.com/Gurux/gurux.dlms.java/blob/250a86fda9ec481aabf485fca…
The only difference is Max PDU Size and that shouldn't affect it. What version you are using from gurux.dlms.java?
BR,
Mikko
Hi Mikko,
Hi Mikko,
I am using the latest gurux.dlms version 4.0.38.
The problem was with the Max PDU size, I don't know why but it is affecting it. I have given it a fixed number and now I can connect and reconnect fine.
Thank you.
Adonay Eshetu
Hi Adonay Eshetu
Hi Adonay Eshetu
Thanks for letting me know about this.
I believe that you don't call releaseRequest and disconnectRequest directly.
Because releaseRequest is not called the original PDU size is not recovered.
The proposed PDU size shouldn't basically affect the connection, but this is fixed for the next release.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Yes you are right, I was not calling releaseRequest before disconnectRequest. Now it is working fine even without setting the Max PDU size.
Thank you for the help and looking forward to the coming updates.
Sincerely,
Adonay Eshetu