Our clients are reading L+G E450 and there should be no problems. It might be that meter has been configured by electricity utilized and you can only receive push messages and are not able to connect to the meter without block and authentication keys.
If you connect the optical head to the meter you probably start to receive push messages right away.
Hi Mikko, many thanks for your quick answer.
Actually there are push messages (e.g. 7E 50 AD 6E D2 7B EE 8F 50 1F 01 09 7E), but they cannot be decoded.
Therefore my question, whether anyone been successfull in reading the data from Landis+Gyr E450 (specifically from Wiener Netze, IR) and could give me some hints, how he did so.
Kind regards, Georg
Once again thanks for the answer. https://www.gurux.fi/node/18620 is for RJ12, but Wiener Netze provides only IR. https://www.gurux.fi/node/13801 is for Iskraemeco, but I have L+G E450.
Does this mean, that nobody in this forum has been successfull in reading the data from Landis+Gyr E450 (specifically from Wiener Netze, IR)?
Regards, Georg
I can say that our clients are reading Landis+Gyr E450, so it's possible when you have set the correct settings. It might take some time before someone from Wiener is reading this topic and answers it.
Thanks for this. Now I know the reason. smartmeter-datacollector is using parsePushObjects. That can be used when the meter sends capture objects of the push message as a first parameter.
Your meter doesn't send capture objects as a first parameter and that is causing this.
Because the content of the data can be anything, there are two ways to solve this.
#1. Data can be shown as a hex string. It's easy to add, but there is no information from the scalers, etc.
Ad #1: Do I understand correctly, that this is something, that would have to be implemeted in "GXDLMSClient.py"?
Do you plan to do this? There is at least some type information available ("OctetString", "UInt32", ...). So a "UInt32" need not be treated as a hex string, but as a 32-bit-unsigned integer.
Ad #2: Do I understand correctly, that this is something, that would have to be implemented/configured in the SmartMeter.
I don't think, we can convince "Wiener Netze" to do this.
Maybe there could be a #3:
"GXDLMSClient.py" could provide a possibility to tell "parsePushObjects", which objects it shall expect in the messages.
Of course this can only work, when all messages contain the same objects (which is the case for the "L+G E450 from Wiener Netze").
This needs to be configured for the ha-server smartmeter-datacollector.
You need to add a push object list for the Push Setup object that handles this message.
At the moment this is not done and the data collector doesn't know what kind of data is received.
Do you have a list of the COSEM objects that are sent in the push message? The first one is clock object, but what are the 8 other items in the list?
You should add them to the push object like this:
p = GXDLMSPushSetup()
p. pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
#Add other objects.
After that, you can parse the received push message.
Oh, I thought, that GXDLMSPushSetup is only for configuring the SENDING of the messages, not for RECEIVING them.
E.g. the second object is a "UInt32" containing the "Positive active energy (A+) total [kWh]" (OBIS code 1.8.0).
How has this to be expressed in "p.pushObjectList.append(...)"?
GXDLMSPushSetup needs to be filled if the meter is not configured to send a push object list as a first parameter.
You can add register objects this:
p = GXDLMSPushSetup()
p. pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
p. pushObjectList.append(GXDLMSRegister("OBIS_CODE"), GXDLMSCaptureObject(2, 0))
OBIS_CODE is 6 bytes long value in DLMS, ex. 1.0.0.7.0.255.
It seems, that my text was misleading.
I did not mean, that the smart meters sends 6-byte-OBIS-codes.
It sends 4-byte-values like e.g. <UInt32 Value="0004FE3D" /> = 327229 Wh, to be interpreted as "Positive active energy (A+) total" (corresponding to the OBIS code 1.8.0).
How has this to be expressed in "p.pushObjectList.append(...)"?
You will add a clock and the eight register objects for the push object list. The framework will handle everything automatically for you.
p = GXDLMSPushSetup()
p. pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
//Multiply this by 8.
r1 = GXDLMSRegister()
p. pushObjectList.append(r1, GXDLMSCaptureObject(2, 0))
When you call getPushValues it will handle everything for you. Values are updated for those register objects and you can get them there like this
sprint(str(r1.value))
Many thanks for this info, but I get an error message:
p.pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
TypeError: append() takes exactly one argument (2 given)
Index value 2 is the attribute index value. For example, for the clock, it's the date and time and for the register, it's the current value. Zero is a data index that is used with complex data types. You don't need it.
I´m trying to translate the message from Landis+Gyr E450 Rj12 Mbus Adapter.(Provider E-Netzte Steiermark Austria)
i receive data, and they looking so far i understand OK.
Additionally i have a 128Bit GUEK Key: 3AB2DFD6A58981FE626AA6DEC4D566EE
And a GAK Key: BC37F8C87AEB07DA23393F4CAB3D70DA
So far i know, the raw data are consisting of:
Header, StartByte, Systemtitle, Framecounter, Authentication Tag,....
Only a part of the message needs to be encrypted with the key.
I was not able to get this raw datas translated and encryped,..
May be anyone knows the exact structure of the raw datas or even translated with what settings in the translator,..
Hi,
Hi,
Our clients are reading L+G E450 and there should be no problems. It might be that meter has been configured by electricity utilized and you can only receive push messages and are not able to connect to the meter without block and authentication keys.
If you connect the optical head to the meter you probably start to receive push messages right away.
BR,
Mikko
Hi Mikko, many thanks for
Hi Mikko, many thanks for your quick answer.
Actually there are push messages (e.g. 7E 50 AD 6E D2 7B EE 8F 50 1F 01 09 7E), but they cannot be decoded.
Therefore my question, whether anyone been successfull in reading the data from Landis+Gyr E450 (specifically from Wiener Netze, IR) and could give me some hints, how he did so.
Kind regards, Georg
Hi Georg,
Hi Georg,
This looks like HDLC framing, but the content is invalid. Check your serial port settings. You can also check this if it will help you.
https://www.gurux.fi/node/18620
There are other topics from Wiener Netze, but they are using Iskraemeco meters.
https://www.gurux.fi/node/13801
BR,
Mikko
BR,
Mikko
Once again thanks for the
Once again thanks for the answer.
https://www.gurux.fi/node/18620 is for RJ12, but Wiener Netze provides only IR.
https://www.gurux.fi/node/13801 is for Iskraemeco, but I have L+G E450.
Does this mean, that nobody in this forum has been successfull in reading the data from Landis+Gyr E450 (specifically from Wiener Netze, IR)?
Regards, Georg
Hi Georg,
Hi Georg,
I can say that our clients are reading Landis+Gyr E450, so it's possible when you have set the correct settings. It might take some time before someone from Wiener is reading this topic and answers it.
BR,
Mikko
In the meantime I found out,
In the meantime I found out, that the L+G E450 from Wiener Netze can be read with 9600 bps.
Then I get valid HDLC frames. The data can be decoded with the key provided by Wiener Netze.
Then they can be decoded to this:
<!-- IDIS system title:
Manufacturer Code: LGZ
Device type: IDIS package2 IP polyphase meter
Function type: Disconnector, Load Management, Multi Utility
Serial number: 58992622
-->
<!-- Invocation Counter: 1053652 -->
<!-- Decrypt data: 0F 00 10 13 D4 0C 07 E6 04 0E 04 0F 31 02 FF
80 00 00 02 09 09 0C 07 E6 04 0E 04 0F 31 02 FF 80 00 80 06 00 04
FE 3D 06 00 00 00 00 06 00 01 C6 CB 06 00 00 01 5C 06 00 00 02 92
06 00 00 00 00 06 00 00 01 40 06 00 00 00 00
<DataNotification>
# Invoke ID: 1053652
<LongInvokeIdAndPriority Value="001013D4" />
# 2022-04-14 15:49:02
<DateTime Value="07E6040E040F3102FF800000" />
<NotificationBody>
<DataValue>
<Structure Qty="09" >
# 2022-04-14 15:49:02
<OctetString Value="07E6040E040F3102FF800080" />
<UInt32 Value="0004FE3D" />
<UInt32 Value="00000000" />
<UInt32 Value="0001C6CB" />
<UInt32 Value="0000015C" />
<UInt32 Value="00000292" />
<UInt32 Value="00000000" />
<UInt32 Value="00000140" />
<UInt32 Value="00000000" />
</Structure>
</DataValue>
</NotificationBody>
</DataNotification>
-->
Hi,
Hi,
So it looks like your meter is sending push messages. Can you share the whole message, because what you shared before is not a push message?
https://www.gurux.fi/comment/23764#comment-23764
BR,
Mikko
The data I posted in https:/
The data I posted in https://www.gurux.fi/comment/23764#comment-23764 were, what I got with the wrong baud rate (2400 bps). With 9600 bps I got a correct HDLC frame:
7E A0 67 CE FF 03 13 38 BD E6 E7 00 DB 08 4C 47 5A 67 73 84 27 EE 4F 20 00 10 13 D4 CC B4 B4 D6 C5 58 2C EB 97 4D 58 18 E2 5A 99 9B 76 BF E6 F6 29 19 FA 11 63 7C 92 48 6D 90 03 B7 5B 97 7C 38 2F FB 35 04 91 21 BA 08 48 BA 3D F0 77 9B 47 64 C6 37 59 8B 61 02 B2 F8 ED CE 1E 20 B1 8A F8 58 8F E3 6E 6C 28 51 97 C2 7E
It can be decoded and the data can be decrypted to this:
0F 00 10 13 D4 0C 07 E6 04 0E 04 0F 31 02 FF 80 00 00 02 09 09 0C 07 E6 04 0E 04 0F 31 02 FF 80 00 80 06 00 04 FE 3D 06 00 00 00 00 06 00 01 C6 CB 06 00 00 01 5C 06 00 00 02 92 06 00 00 00 00 06 00 00 01 40 06 00 00 00 00
These data can be decrypted by thy "DLMS Translator" of the "Gurux GXDLMDDirector", see https://www.gurux.fi/comment/23808#comment-23808
But the https://github.com/scs/smartmeter-datacollector using the GURUX DLMS decoder crashes:
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: Traceback (most recent call last):
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/bin/smartmeter-datacollector", line 14, in <module>
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: app.main()
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/smartmeter_datacollector/app.py", line 69, in main
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: asyncio.run(build_and_start(app_config), debug=debug_mode)
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/lib/python3.7/asyncio/runners.py", line 43, in run
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: return loop.run_until_complete(main)
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: return future.result()
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/smartmeter_datacollector/app.py", line 29, in build_and_start
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: data_collector.process_queue())
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/smartmeter_datacollector/smartmeter/meter.py", line 46, in start
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: await self._serial.start_and_listen()
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/smartmeter_datacollector/smartmeter/serial_reader.py", line 45, in start_and_listen
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: self._callback(data)
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/smartmeter_datacollector/smartmeter/meter.py", line 57, in _data_received
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: dlms_objects = self._parser.parse_to_dlms_objects()
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/smartmeter_datacollector/smartmeter/hdlc_dlms_parser.py", line 84, in parse_to_dlms_objects
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: parsed_objects = self._client.parsePushObjects(self._dlms_data.value[0])
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: File "/usr/local/lib/python3.7/dist-packages/gurux_dlms/GXDLMSClient.py", line 1257, in parsePushObjects
Jän 09 23:28:02 ha-server smartmeter-datacollector[20895]: classID = tmp[0]
Hi,
Hi,
Thanks for this. Now I know the reason. smartmeter-datacollector is using parsePushObjects. That can be used when the meter sends capture objects of the push message as a first parameter.
Your meter doesn't send capture objects as a first parameter and that is causing this.
Because the content of the data can be anything, there are two ways to solve this.
#1. Data can be shown as a hex string. It's easy to add, but there is no information from the scalers, etc.
#2. All pushed objects need to be added for the Push object list.
https://www.gurux.fi/Gurux.DLMS.Objects.GXDLMSPushSetup
#2 is better, but it needs that you need to configure the smartmeter-datacollector for this push message.
BR,
Mikko
BR,
Mikko
Hi and thanks for your answer
Hi and many thanks for your answer!
Ad #1: Do I understand correctly, that this is something, that would have to be implemeted in "GXDLMSClient.py"?
Do you plan to do this? There is at least some type information available ("OctetString", "UInt32", ...). So a "UInt32" need not be treated as a hex string, but as a 32-bit-unsigned integer.
Ad #2: Do I understand correctly, that this is something, that would have to be implemented/configured in the SmartMeter.
I don't think, we can convince "Wiener Netze" to do this.
Maybe there could be a #3:
"GXDLMSClient.py" could provide a possibility to tell "parsePushObjects", which objects it shall expect in the messages.
Of course this can only work, when all messages contain the same objects (which is the case for the "L+G E450 from Wiener Netze").
Regards, Georg
Hi,
Hi,
This needs to be configured for the ha-server smartmeter-datacollector.
You need to add a push object list for the Push Setup object that handles this message.
At the moment this is not done and the data collector doesn't know what kind of data is received.
Do you have a list of the COSEM objects that are sent in the push message? The first one is clock object, but what are the 8 other items in the list?
You should add them to the push object like this:
p = GXDLMSPushSetup()
p. pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
#Add other objects.
After that, you can parse the received push message.
BR,
Mikko
Oh, I thought, that
Oh, I thought, that GXDLMSPushSetup is only for configuring the SENDING of the messages, not for RECEIVING them.
E.g. the second object is a "UInt32" containing the "Positive active energy (A+) total [kWh]" (OBIS code 1.8.0).
How has this to be expressed in "p.pushObjectList.append(...)"?
Please be so kind to help me.
Please be so kind to help me.
Hi,
Hi,
GXDLMSPushSetup needs to be filled if the meter is not configured to send a push object list as a first parameter.
You can add register objects this:
p = GXDLMSPushSetup()
p. pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
p. pushObjectList.append(GXDLMSRegister("OBIS_CODE"), GXDLMSCaptureObject(2, 0))
OBIS_CODE is 6 bytes long value in DLMS, ex. 1.0.0.7.0.255.
If you can't read values from the meter, you can find possible values with GXDLMSTranslator.
https://www.gurux.fi/GuruxDLMSTranslator
BR,
Mikko
It seems, that my text was
It seems, that my text was misleading.
I did not mean, that the smart meters sends 6-byte-OBIS-codes.
It sends 4-byte-values like e.g. <UInt32 Value="0004FE3D" /> = 327229 Wh, to be interpreted as "Positive active energy (A+) total" (corresponding to the OBIS code 1.8.0).
How has this to be expressed in "p.pushObjectList.append(...)"?
Hi,
Hi,
You will add a clock and the eight register objects for the push object list. The framework will handle everything automatically for you.
p = GXDLMSPushSetup()
p. pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
//Multiply this by 8.
r1 = GXDLMSRegister()
p. pushObjectList.append(r1, GXDLMSCaptureObject(2, 0))
When you call getPushValues it will handle everything for you. Values are updated for those register objects and you can get them there like this
sprint(str(r1.value))
BR,
Mikko
Many thanks for this info,
Many thanks for this info, but I get an error message:
p.pushObjectList.append(GXDLMSClock(), GXDLMSCaptureObject(2, 0))
TypeError: append() takes exactly one argument (2 given)
Hi,
Hi,
My bad. The correct line is:
p. pushObjectList.append((r1, GXDLMSCaptureObject(2, 0)))
You need to add parentheses.
BR,
Mikko
Many, many thanks! This is my
Many, many thanks! This is my setup code, which works very well:
self._p = GXDLMSPushSetup()
self._p.pushObjectList.append((GXDLMSClock(), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.1.1.8.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.1.2.8.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.1.3.8.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.1.4.8.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.0.1.7.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.0.2.7.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.0.3.7.0.255"), GXDLMSCaptureObject(2, 0)))
self._p.pushObjectList.append((GXDLMSRegister("1.0.4.7.0.255"), GXDLMSCaptureObject(2, 0)))
Just one question:
What is the specific meaning of the index values 2 and 0 in all calls to GXDLMSCaptureObject()?
Hi,
Hi,
Index value 2 is the attribute index value. For example, for the clock, it's the date and time and for the register, it's the current value. Zero is a data index that is used with complex data types. You don't need it.
https://www.gurux.fi/Gurux.DLMS.Objects.GXDLMSRegister
BR,
Mikko
Many thanks!
Many thanks!
Hello, I´m trying to…
Hello,
I´m trying to translate the message from Landis+Gyr E450 Rj12 Mbus Adapter.(Provider E-Netzte Steiermark Austria)
i receive data, and they looking so far i understand OK.
Its always 332 Bytes and start with "E7"
<
7EA08BCEFF0313EEE1E6E700E0400001000077DB084C475A67737C51BD8201033
00000AEF6B3C58438A427A7968A15363ABAA06D40638AE61787EF0F11AD074214
E0F546927259BA41CB095232AA77A33658F467D650CB7D5798DFEBD045E1748A9
74C782B8AA38E21EFC4FEA628EBA9BDB54B84F86AB18E4ADA071DC4073055CE6
66A67A3D20C594C1C42167E7EA08BCEFF0313EEE1E040000200007AA34BBFD575
8A2950AC9416A18551051CF3D020315880C3EA849F04E2C475C825F011B7C680724
598CFC09FC405D710416BE3A2A0F7B7DB076A1AE826042D241C37ED9C87ABBA16
B90426F495C10A97A5E7E7D84E3A54ADD779BED2A91198521EF9A14AB838BACA2
683E1B823CC71E051FEA9FDE4C26E6DB03A149F4B7E7EA030CEFF031386F8E0C00
00300001F88EEFC7881CA66F8851B13AFD6AC1A1D303D98B1CB03C2129B3F4495118
889B23E7E
Additionally i have a 128Bit GUEK Key: 3AB2DFD6A58981FE626AA6DEC4D566EE
And a GAK Key: BC37F8C87AEB07DA23393F4CAB3D70DA
So far i know, the raw data are consisting of:
Header, StartByte, Systemtitle, Framecounter, Authentication Tag,....
Only a part of the message needs to be encrypted with the key.
I was not able to get this raw datas translated and encryped,..
May be anyone knows the exact structure of the raw datas or even translated with what settings in the translator,..
Thank you