First i want to thank you for your work on Gurux library.
It is not an easy task to make it work with all kind of meter.
And it helps a lot of people.
I am now able to read my meter register as I want.
But when i finished reading the value, a disconnect request is sent and the meter do not respond and keep the connection alive.
Here is the disconnection request and logs with Gurux Java (based on the sample client demo) :
==========================
Attribute 3
==========================
<- 09:34:48.246 7E A0 1A 02 23 03 32 75 62 E6 E6 00 C0 01 C1 00 03 01 01 01 08 00 40 03 00 BA 2E 7E
-> 09:34:48.543 7E A0 19 03 00 02 00 23 52 56 47 E6 E7 00 C4 01 C1 00 02 02 0F 06 16 1E B8 02 7E
Scaler: 1,000,000 Unit: ActiveEnergy
==========================
Attribute 2
==========================
<- 09:34:48.600 7E A0 1A 02 23 03 54 45 64 E6 E6 00 C0 01 C1 00 03 01 01 01 08 00 40 02 00 62 37 7E
-> 09:34:48.928 7E A0 18 03 00 02 00 23 74 B7 9C E6 E7 00 C4 01 C1 00 06 00 02 E1 E8 C2 36 7E
1.88904E11
==========================
FINISHED
==========================
DisconnectRequest
<- 09:34:48.971 7E A0 24 02 23 03 76 3C D3 E6 E6 00 62 15 80 01 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D 21 34 60 F1 7E
-> 09:34:49.227 7E A0 18 03 00 02 00 23 96 AB 58 E6 E7 00 62 15 80 01 00 BE 10 04 0E 1F 61 7E
<- 09:34:49.238 7E A0 08 02 23 03 53 32 B2 7E
Data send failed. Try to resend 1/3
<- 09:35:49.251 7E A0 08 02 23 03 53 32 B2 7E
Data send failed. Try to resend 2/3
<- 09:36:49.264 7E A0 08 02 23 03 53 32 B2 7E
Data send failed. Try to resend 3/3
<- 09:37:49.274 7E A0 08 02 23 03 53 32 B2 7E
The problem does not come from the meter SL7000 because i made a custom Application that send raw bytes requests (I have captured them with a serial listener when using "ACE pilote" application) and it managed to close the connection.
Here is the logs of my custom application :
-> 7E A0 21 00 02 00 23 03 93 9A 74 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 07 65 5E 7E
<- 7E A0 21 03 00 02 00 23 73 7B 7F 81 80 12 05 01 80 06 01 80 07 04 00 00 00 07 08 04 00 00 00 01 9E 63 7E
-> etc.....
<- etc...
->7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E
<- 7E A0 0A 03 00 02 00 23 51 6A 68 7E
-> 7E A0 0A 00 02 00 23 03 53 97 A7 7E
<- 7E A0 0A 03 00 02 00 23 73 7A 6A 7E
The disconnect requests look like the same in the 2 cases...
I am still struggling with the disconnection :(
I tryed to remove the request that is just before the request of disconnection but it is not working.
I tryed to send the raw request that worked, but no result... This is quite strange.
Should something be done after reading a register and before closing the connection ?
Now I don't have any ideas of what is blocking the disconnection...
Can anyone help me please ?
Thank again for your response and your great work.
I have disabled the "releaseRequest" and when the "disconnectRequest" is sent, the meter does not respond any thing at all. The RX led of serial port of my linux box does not light up.
Here is the Gurux Librairies frames exchange with the SL7000 meter after disabling the release request:
SNRM request:
<<< 7E A0 0A 00 02 00 23 03 93 9B 61 7E
>>> 7E A0 21 03 00 02 00 23 73 7B 7F 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E
AARequest :
<<< 7E A0 47 00 02 00 23 03 10 41 3E E6 E6 00 60 36 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D FF FF 19 02 7E
>>> 7E A0 53 03 00 02 00 23 30 13 29 E6 E7 00 61 42 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 AA 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 08 00 06 5F 1F 04 00 00 0C 1D 21 34 00 07 DE B4 7E
Reading register 1.1.1.8.0.255:2
<<< 7E A0 1C 00 02 00 23 03 32 1C 38 E6 E6 00 C0 01 C1 00 03 01 01 01 08 00 FF 02 00 E7 F7 7E
>>> 7E A0 18 03 00 02 00 23 52 83 D8 E6 E7 00 C4 01 C1 00 06 00 02 E1 E8 C2 36 7E
Closing the connection...
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
Data send failed. Try to resend 1/3
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
Data send failed. Try to resend 2/3
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
Data send failed. Try to resend 3/3
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
I found something strange:
- With the Ace Pilote SL7000 frame sequence, when i remove the request "7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E" before the request "7E A0 0A 00 02 00 23 03 53 97 A7 7E", connection was NOT CLOSED.
- With the Gurux frame sequence when i replace the "releaseRequest" by the request frame "7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E", then the SL7000 meter responded this frame "7E A0 0A 03 00 02 00 23 51 6A 68 7E", and the connection is CLOSED after the "disconnectRequest" frame is sent.
It looks like that the frame "7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E" is NEEDED by the SL7000 meter before the "disconnectRequest".
I don't what kind of frame it is.
It does not looks like the Gurux "ReleaseRequest" frame (7E A0 26 00 02 00 23 03 54 31 01 E6 E6 00 62 15 80 01 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D 21 34 60 F1 7E)
I have no idea why. Just read data before release if this works. Something like:
GXDLMSData d = new GXDLMSData("0.0.142.1.1.255");
cl.Read(d, 2);
//Release
I tried your solution but it is not working. The generated frame "7ea01c0002002303542c3ee6e600c001c1000100008e0101ff020083077e" is not the same than the one i have found. The FrameType and InvokeIdAndPriority are not the same.
The meter responded this :
7ea0190300020023746203e6e700c401c10002021103115b470e7e
Is there a way to create a request with the frameType 76 ?
What is the InvokeIdAndPriority ?
Thank you again for your responses. That help me a lot :) !!
Hello,
Hello,
I am still struggling with the disconnection :(
I tryed to remove the request that is just before the request of disconnection but it is not working.
I tryed to send the raw request that worked, but no result... This is quite strange.
Should something be done after reading a register and before closing the connection ?
Now I don't have any ideas of what is blocking the disconnection...
Can anyone help me please ?
Hello all,
Hello all,
I am still stucked with this issue for while. Can you help me plase ?
Thank you.
SL7000 unable to disconnect
Hi,
Sorry for slow reply. We were a little bit busy last week.
Don't call ReleaseRequest. Some older meters can't handle release. I believe that is causing the problem.
Just call DisconnectRequest.
BR,
Mikko
Hi Kurumi,
Hi Kurumi,
Thank again for your response and your great work.
I have disabled the "releaseRequest" and when the "disconnectRequest" is sent, the meter does not respond any thing at all. The RX led of serial port of my linux box does not light up.
Here is the Gurux Librairies frames exchange with the SL7000 meter after disabling the release request:
SNRM request:
<<< 7E A0 0A 00 02 00 23 03 93 9B 61 7E
>>> 7E A0 21 03 00 02 00 23 73 7B 7F 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E
AARequest :
<<< 7E A0 47 00 02 00 23 03 10 41 3E E6 E6 00 60 36 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D FF FF 19 02 7E
>>> 7E A0 53 03 00 02 00 23 30 13 29 E6 E7 00 61 42 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 AA 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 08 00 06 5F 1F 04 00 00 0C 1D 21 34 00 07 DE B4 7E
Reading register 1.1.1.8.0.255:2
<<< 7E A0 1C 00 02 00 23 03 32 1C 38 E6 E6 00 C0 01 C1 00 03 01 01 01 08 00 FF 02 00 E7 F7 7E
>>> 7E A0 18 03 00 02 00 23 52 83 D8 E6 E7 00 C4 01 C1 00 06 00 02 E1 E8 C2 36 7E
Closing the connection...
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
Data send failed. Try to resend 1/3
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
Data send failed. Try to resend 2/3
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
Data send failed. Try to resend 3/3
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
And here is the frame I have saved from the ACE Pilote Application of the SL7000 meter:
<<< 7E A0 21 00 02 00 23 03 93 9A 74 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 07 65 5E 7E
>>> 7E A0 21 03 00 02 00 23 73 7B 7F 81 80 12 05 01 80 06 01 80 07 04 00 00 00 07 08 04 00 00 00 01 9E 63 7E
<<< 7E A0 47 00 02 00 23 03 10 41 3E E6 E6 00 60 36 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 1E 3D 00 00 EA 32 7E
>>> 7E A0 53 03 00 02 00 23 30 13 29 E6 E7 00 61 42 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 AA 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 08 00 06 5F 1F 04 00 00 0C 3D 21 34 00 07 4F D4 7E
<<< 7E A0 1C 00 02 00 23 03 32 1C 38 E6 E6 00 C0 01 41 00 11 00 00 29 00 00 FF 02 00 E0 E1 7E
>>> 7E A8 8C 03 00 02 00 23 42 1C B9 E6 E7 00 C4 01 41 00 01 06 02 02 12 00 01 0A 10 53 4C 42 37 36 31 4D 41 33 33 30 35 31 30 38 33 02 02 12 00 11 0A 10 53 4C 42 37 36 31 45 4C 33 33 30 35 31 30 38 33 02 02 12 00 12 0A 10 53 4C 42 37 36 31 47 41 33 33 30 35 31 30 38 33 02 02 12 00 13 0A 10 53 4C 42 37 36 31 48 45 33 33 30 35 31 30 38 33 02 02 12 00 14 0A 10 53 4C 42 37 36 31 57 41 33 33 30 35 31 30 38 33 02 02 12 00 F4 38 7E 7E A0 1F 03 00 02 00 23 54 AD 7A 15 0A 10 53 4C 42 37 36 31 43 55 33 33 30 35 31 30 38 33 CC EE 7E
<<< 7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E
>>> 7E A0 0A 03 00 02 00 23 51 6A 68 7E
<<< 7E A0 0A 00 02 00 23 03 53 97 A7 7E
>>> 7E A0 0A 03 00 02 00 23 73 7A 6A 7E
I found something strange:
- With the Ace Pilote SL7000 frame sequence, when i remove the request "7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E" before the request "7E A0 0A 00 02 00 23 03 53 97 A7 7E", connection was NOT CLOSED.
- With the Gurux frame sequence when i replace the "releaseRequest" by the request frame "7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E", then the SL7000 meter responded this frame "7E A0 0A 03 00 02 00 23 51 6A 68 7E", and the connection is CLOSED after the "disconnectRequest" frame is sent.
It looks like that the frame "7E A0 1C 00 02 00 23 03 76 3C 3C E6 E6 00 C0 01 41 00 01 00 00 8E 01 01 FF 02 00 98 95 7E" is NEEDED by the SL7000 meter before the "disconnectRequest".
I don't what kind of frame it is.
It does not looks like the Gurux "ReleaseRequest" frame (7E A0 26 00 02 00 23 03 54 31 01 E6 E6 00 62 15 80 01 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D 21 34 60 F1 7E)
Do you have any idea ?
SL7000
Hi,
SL7000 Meters what we have read don't need this. I have to say that most of the meters client are reading using TCP/IP connection.
This is interesting. What you do is just read one data value.
http://www.gurux.fi/GuruxDLMSTranslator?translate=7EA01C0002002303763C3…
I have no idea why. Just read data before release if this works. Something like:
GXDLMSData d = new GXDLMSData("0.0.142.1.1.255");
cl.Read(d, 2);
//Release
BR,
Mikko
Thank you Kurumi :)
Thank you Kurumi :)
I tried your solution but it is not working. The generated frame "7ea01c0002002303542c3ee6e600c001c1000100008e0101ff020083077e" is not the same than the one i have found. The FrameType and InvokeIdAndPriority are not the same.
The meter responded this :
7ea0190300020023746203e6e700c401c10002021103115b470e7e
Is there a way to create a request with the frameType 76 ?
What is the InvokeIdAndPriority ?
Thank you again for your responses. That help me a lot :) !!