Before commenting read Forum rules
Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
Before commenting read Forum rules
Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
Hi Mikko
I tried to decode messages pushed from a Landis+Gyr E570 smart meter with a software that already works in the same way with L+G E450 & Iskra AM550 meter. The software is https://github.com/scs/smartmeter-datacollector which uses your Gurux DLMS Python library.
However, neither this software nor the Gurux DLMS-Translator manage to successfully parse the received serial messages. The data comes in fragments, but even after many received HDLC packets more data seem to be expected before the message can be parsed.
Here some sample data consisting of multiple HDLC frames and belonging to the same DLMS message:
7E A8 88 CE 21 03 13 6E 42 E6 E7 00 E0 40 00 01 00 00 74 DB 08 4C 47 5A 67 73 96 37 B8 82 01 C5 20 00 02 E0 30 7C E7 4E 27 2E 96 4B 8D 7B FB A3 26 01 50 0D 19 35 83 BF B0 40 CC 0A F6 80 16 C3 A9 91 CC 13 0E 1F 0A B4 A2 96 EF BB 0C F8 86 91 BD 69 06 F8 65 B9 52 5C C5 E4 61 1B 1A EB 0B A2 5D C8 8F D7 B4 17 41 CC 8D B7 E2 B8 E9 14 23 EB 92 D1 21 9A B0 80 30 09 89 18 66 24 B0 EA 0D B7 56 36 21 3E C6 EA 3C 30 0D 7E 7E A8 85 CE 21 03 13 1A 3E E0 40 00 02 00 00 74 94 2A 56 58 91 73 7B F1 24 79 26 65 2E 9C 3E A6 65 CD 5F 61 E6 A9 AB 5C 13 2A C7 7B EC 16 D9 14 08 D2 D3 61 B2 FC DE 77 1C A5 32 56 F5 B1 8B 92 B8 A2 ED A6 A9 18 D3 F9 72 59 8D 13 36 ED E6 80 C9 4C A4 6F CB BF B7 30 4C 43 9E 5B 6A 6F AA 03 E6 4D FD 84 C8 07 79 C2 91 66 DF 69 16 29 37 F7 19 25 94 06 99 AE 23 CE D3 3F 6F CB 1B 62 5F 6D 3E 2B F3 42 B0 61 7E 7E A8 85 CE 21 03 13 1A 3E E0 40 00 03 00 00 74 5C B7 73 1F D0 AA 53 85 95 73 7A 1B DB 29 5A 8A 4F 6A 27 68 0C A3 33 83 02 61 33 70 FD C2 11 80 E5 F3 C9 40 C5 D6 2B CC 7A 9B A9 63 8E C9 84 4C 52 80 0C 08 83 B9 81 7C 92 D2 B9 AB D5 18 56 9F 31 03 A0 09 1C 01 C8 04 06 A7 E1 7B A3 16 FB C8 0D 6C 2E 80 FF 16 BF 78 CB 33 7D BE E2 C3 E1 24 FB 81 F2 B7 78 FD D0 31 3E 97 56 33 24 22 38 0F 0E C4 A5 F5 15 BE 7E 7E A8 85 CE 21 03 13 1A 3E E0 40 00 04 00 00 74 A5 25 6A A8 0E AC 8B 37 94 5F 25 38 89 04 29 CC D7 A0 1B 28 FC 58 CB 74 72 6F AE 67 5F F3 AA 84 C0 F3 C2 68 E6 E1 FA E0 08 C5 B8 49 34 D3 51 82 E6 7F EF 80 87 FC 52 15 33 09 60 79 31 6A 69 C8 0F FC 21 B8 BC 9F 2C 13 27 66 8E 3E D2 1E A3 80 55 C2 04 5E 69 EE B3 97 AC 38 EB B8 E1 9F 16 63 7C 43 A0 EA 91 49 A1 87 99 FA 8F 69 45 FE 98 82 E5 71 94 FB D8 C0 7E 7E A8 13 CE 21 03 13 97 3B E0 C0 00 05 00 00 02 70 89 78 3C 7E
The APDU is encrypted. I will send you the decryption key by E-Mail.
Could you have a look at this data example? I'm really interested in your opinion. The fact that not even the DLMS-Translator is able to decode the data points to a more fundamental problem than just a bug in our software.
I would expect that some point a frame shall be received that starts with "7E A0" instead of "7E A8" like I've seen this with other meters that send data fragmented. Unfortunately with this meter I never received a frame starting with "7E A0". Do you support this finding?
The person who gave me the meter and asked me to integrate it in our software solution used a different software for testing (https://zeta-eng.ch/index.php?id=291&L=5) which was able to parse the data.
Thank you very much in advance!
Sincerely,
raymar
Hi raymar,
Hi raymar,
I received the decrypt key and was able to parse the data as you can see below.
There are five PDUs. Because PDU fits inside of the frame the frame should start with 7E A0 and not with 7E A8.
Ask if there is a firmware update available for the meter where this is fixed.
BR,
Mikko
<DataNotification>
# Invoke ID: 691132
<LongInvokeIdAndPriority Value="000A8BBC" />
# 4.7.2022 13.23.31
<DateTime Value="07E60704010D171FFF800000" />
<NotificationBody>
<DataValue>
<Structure Qty="12" >
<Array Qty="12" >
<Structure Qty="04" >
<UInt16 Value="0028" />
# 0.8.25.9.0.255
<OctetString Value="0008190900FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0028" />
# 0.8.25.9.0.255
<OctetString Value="0008190900FF" />
<Int8 Value="01" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0001" />
# 0.0.42.0.0.255
<OctetString Value="00002A0000FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0008" />
# 0.0.1.0.0.255
<OctetString Value="0000010000FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.1.7.0.255
<OctetString Value="0100010700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.2.7.0.255
<OctetString Value="0100020700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.3.7.0.255
<OctetString Value="0100030700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.4.7.0.255
<OctetString Value="0100040700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.1.1.8.0.255
<OctetString Value="0101010800FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.1.2.8.0.255
<OctetString Value="0101020800FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.1.5.8.0.255
<OctetString Value="0101050800FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.1.6.8.0.255
<OctetString Value="0101060800FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.1.7.8.0.255
<OctetString Value="0101070800FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.1.8.8.0.255
<OctetString Value="0101080800FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.31.7.0.255
<OctetString Value="01001F0700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.51.7.0.255
<OctetString Value="0100330700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.71.7.0.255
<OctetString Value="0100470700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
<Structure Qty="04" >
<UInt16 Value="0003" />
# 1.0.13.7.0.255
<OctetString Value="01000D0700FF" />
<Int8 Value="02" />
<UInt16 Value="0000" />
</Structure>
</Array>
# 0.8.25.9.0.255
<OctetString Value="0008190900FF" />
# LGZ1030760176312
<OctetString Value="4C475A31303330373630313736333132" />
# 4.7.2022 13.23.31
<OctetString Value="07E60704010D171FFF800080" />
<UInt32 Value="00004C09" />
<UInt32 Value="00000000" />
<UInt32 Value="00000000" />
<UInt32 Value="00001D43" />
<UInt32 Value="003C5001" />
<UInt32 Value="00000000" />
<UInt32 Value="00000000" />
<UInt32 Value="00000000" />
<UInt32 Value="00000000" />
<UInt32 Value="00171002" />
<UInt16 Value="005B" />
<UInt16 Value="0000" />
<UInt16 Value="0000" />
<Int16 Value="03A5" />
</Structure>
</DataValue>
</NotificationBody>
</DataNotification>
Hi Mikko
Hi Mikko
Thank you for your answer and sorry for the delay. I was on vacation.
Could you elaborate your solution further how exactly you modified the input data and which steps are required to come to the xml output above? I wasn't able to reproduce your solution with the DLMS Translator. Did you also use the DLMS Translator?
Best regards
Hi,
Hi,
I checked the bytes manually. DLMS certificate tests don't test push messages at the moment and it's causing so problems.
If you are using DLMS Translator you can see that there are four frames and that is correct, and each of the frame is PDU like this:
E0400001000074DB084C475A67739637B88201C5200002E0307CE74E272E964B8D7BFBA32601500D193583BFB040CC0AF68016C3A991CC130E1F0AB4A296EFBB0CF88691BD6906F865B9525CC5E4611B1AEB0BA25DC88FD7B41741CC8DB7E2B8E91423EB92D1219AB080300989186624B0EA0DB75636213EC6EA3C
Because the meter sends 7E A8 it means that PDU doesn't fit to one frame, but that is wrong. This causes that PDU header is not removed and PDU is added to the data and the output is wrong.
Because PDU fits inside of the frame the start should be 7E A0. Ask if there is a new firmware available where this is fixed.
BR,
Mikko
Hi rymar
Hi rymar
I have exatly the same problem with Push-message from L+G E570.
Did you find a solution to solve this problem, or did L+G deliver a new meter firmware.
Sincerely,
George
Hi George Sorry for the lateā¦
Hi George
Sorry for the late response. I did contact L+G and they accepted the bug-report and are going to fix it in a new FW-version. However, a new FW-version must first be certified and than handed over to the electricity provider which rolls out the update. That takes some time and not all electricity provider do firmware updates on the smartmeters of their customers. Therefore it is possible that you are stuck with the current version of the firmware.
Sincerely,
raymar