I want to read terminal cover status using GXDLMSDirector with logical name 0.0.97.97.2.255 (Error object #3). Before I open the terminal cover, the value is 000000000000. After I open the terminal cover, the meter go to tamper condition, but the value doesn't change, still 000000000000. Why the value doesn't change? Is there any alternative way to get terminal cover status?
I'm using EDMI MK7MI meter and GXDLMSDirector.
Thank you.
I have tried to read from profile generic (historical) value, but I will keep using logical name 0.0.97.97.2.255 (Error object #3) because I will read that using Arduino client example code.
Here I attached the table of error object's bitstring from my meter's documentation. From the table, I need to read the bit (1) for terminal cover status. I suspect that maybe you are taking data from MSB, so that I can't see the change of bit (1). By using Arduino client library, is it possible to read all the 16 bitstring instead of 12 bitstring?
Can you read this with GXDLMSDirector and add a trace to here or pastebin.net and share the link? I can verify this for the bytes. Add only read and reply messages.
This is the trace before terminal cover opened :
08:44:42 Read object type Data index: 2
TX: 7E A0 2D 02 47 09 DC 54 13 E6 E6 00 C8 1E 30 00 00 00 BE 32 0A EE 3D 03 E1 81 D1 63 5B 66 0A E9 C7 20 2C D0 95 FC B8 51 CF F7 2B 96 2B 57 7E
08:44:43
RX: 7E A0 28 09 02 47 FC AA 37 E6 E7 00 CC 19 30 00 00 00 BD CC EF 5B 00 D0 B3 34 F7 C7 42 F4 4F 34 3A F1 CD 62 3E 85 65 C4 8E 7E
And this is the trace after terminal cover opened :
08:48:33 Read object type Data index: 2
TX: 7E A0 2D 02 47 09 98 74 17 E6 E6 00 C8 1E 30 00 00 00 EC D7 0D 27 1B E5 AA 87 9E 96 A0 F2 BB 9C DF B7 70 FD E5 21 30 29 FE DA 6E B4 3A 22 7E
08:48:34
RX: 7E A0 28 09 02 47 B8 8A 33 E6 E7 00 CC 19 30 00 00 00 EB 02 61 BC 23 03 A1 12 B1 F1 C6 D4 F7 38 87 BB 19 1D 1B E7 A3 AB 0C 7E
I have shared the block cipher and auth keys to your email with subject "Credentials For Error Objects #3 Analysis"
Thank you for your help!
I just notest that there is an error on the bit-string of the meter. DLMS standard defines that LSB is coming first and your meter is sending MSB first. You need to ask the meter manufacturer to fix this.
I have asked the meter manufacturer, for the error object #3, they said they follow the Indonesian Electricity Company Standard. The bit-string follow the attached table below. By using your Arduino client library, is it possible to read all the 16 bit-string instead of 12 bit-string? Or how to read the bit-string according to MSB coming first?
This is a really bad idea. What if you want to add new bits later? This is not possible if MSB is coming first. If you add new bits to the beginning, all bits afterward lost their meaning.
This will also break the compatibility with the DLMS standard and I believe that conformance bits in AARQ and AARE are still using DLMS standard way, not Indonesian Electricity Company Standard. You can't read the meter with any Gurux library if conformance bits are not using LSB first order.
Meter says that there are only 12 bits in the data, so the client doesn't know how to handle this. If you can send the Indonesian Electricity Company Standard to me by email, I can check if it's possible to add support for this.
I just share the document to your email with subject "Indonesian Electricity Company Standard". For error objects #3 (tamper), you can go to page 56 -57.
The bit-string size must be 14 If the Most Significant Bit is coming first. Now it's 12. This will cause that Bits 12, 13 and 14 are added, but bits 1 and 2 are excluded.
Hi,
Hi,
Have you tried to read profile generic (historical) value? Is that changed to the error log?
BR,
Mikko
Hi Mikko,
Hi Mikko,
I have tried to read from profile generic (historical) value, but I will keep using logical name 0.0.97.97.2.255 (Error object #3) because I will read that using Arduino client example code.
Here I attached the table of error object's bitstring from my meter's documentation. From the table, I need to read the bit (1) for terminal cover status. I suspect that maybe you are taking data from MSB, so that I can't see the change of bit (1). By using Arduino client library, is it possible to read all the 16 bitstring instead of 12 bitstring?
Hi,
Hi,
In DLMS LSB is coming first in bit-string.
Can you read this with GXDLMSDirector and add a trace to here or pastebin.net and share the link? I can verify this for the bytes. Add only read and reply messages.
BR,
Mikko
Hi Mikko,
Hi Mikko,
This is the trace before terminal cover opened :
08:44:42 Read object type Data index: 2
TX: 7E A0 2D 02 47 09 DC 54 13 E6 E6 00 C8 1E 30 00 00 00 BE 32 0A EE 3D 03 E1 81 D1 63 5B 66 0A E9 C7 20 2C D0 95 FC B8 51 CF F7 2B 96 2B 57 7E
08:44:43
RX: 7E A0 28 09 02 47 FC AA 37 E6 E7 00 CC 19 30 00 00 00 BD CC EF 5B 00 D0 B3 34 F7 C7 42 F4 4F 34 3A F1 CD 62 3E 85 65 C4 8E 7E
And this is the trace after terminal cover opened :
08:48:33 Read object type Data index: 2
TX: 7E A0 2D 02 47 09 98 74 17 E6 E6 00 C8 1E 30 00 00 00 EC D7 0D 27 1B E5 AA 87 9E 96 A0 F2 BB 9C DF B7 70 FD E5 21 30 29 FE DA 6E B4 3A 22 7E
08:48:34
RX: 7E A0 28 09 02 47 B8 8A 33 E6 E7 00 CC 19 30 00 00 00 EB 02 61 BC 23 03 A1 12 B1 F1 C6 D4 F7 38 87 BB 19 1D 1B E7 A3 AB 0C 7E
I have shared the block cipher and auth keys to your email with subject "Credentials For Error Objects #3 Analysis"
Thank you for your help!
Hi,
Hi,
The bit string is empty in both cases. There are 12 bits and they are all zero. You need to ask the meter manufacturer why it's not set.
<!-- Decrypt data: C4 01 C1 00 04 0C 00 00
<GetResponse>
<GetResponseNormal>
# Priority: High, ServiceClass: Confirmed, Invoke ID: 1
<InvokeIdAndPriority Value="C1" />
<Result>
<Data>
<BitString Value="000000000000" />
</Data>
</Result>
</GetResponseNormal>
</GetResponse>
BR,
Mikko
Hi,
Hi,
I just notest that there is an error on the bit-string of the meter. DLMS standard defines that LSB is coming first and your meter is sending MSB first. You need to ask the meter manufacturer to fix this.
A good example of this is the conformance block.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I have asked the meter manufacturer, for the error object #3, they said they follow the Indonesian Electricity Company Standard. The bit-string follow the attached table below. By using your Arduino client library, is it possible to read all the 16 bit-string instead of 12 bit-string? Or how to read the bit-string according to MSB coming first?
Hi,
Hi,
This is a really bad idea. What if you want to add new bits later? This is not possible if MSB is coming first. If you add new bits to the beginning, all bits afterward lost their meaning.
This will also break the compatibility with the DLMS standard and I believe that conformance bits in AARQ and AARE are still using DLMS standard way, not Indonesian Electricity Company Standard. You can't read the meter with any Gurux library if conformance bits are not using LSB first order.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thanks for the explanation. How about to read all the 16 bit-string? Is it possible using your Arduino library?
Hi,
Hi,
Meter says that there are only 12 bits in the data, so the client doesn't know how to handle this. If you can send the Indonesian Electricity Company Standard to me by email, I can check if it's possible to add support for this.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I just share the document to your email with subject "Indonesian Electricity Company Standard". For error objects #3 (tamper), you can go to page 56 -57.
Thank you for your support.
Hi,
Hi,
The bit-string size must be 14 If the Most Significant Bit is coming first. Now it's 12. This will cause that Bits 12, 13 and 14 are added, but bits 1 and 2 are excluded.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Could you like to guide me how to handle MSB coming first? so that bits 1 and 2 are not excluded
Hi,
Hi,
Can you re-send the authentication and block cipher keys to me by email? I can show the problem from the decrypted bytes.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I have sent the authentication and block cipher keys to you by email.
Hi,
Hi,
Bytes that the meter returns.
C4 01 C1 00
04 //BIT-STRING
0C //Count: 12 . This is wrong.
00 02 //BIT-STRING:0000 0000 0000 0010
The size is wrong. It must be 16. This must fix for the meter.
BR,
Mikko