WienerNetze meter reading

By tofuSCHNITZEL , 3 September, 2019

Forums

Hi!

I received a smartmeter from the local powercompany and recenently they allowed me to enable the (IR) userinterface to read out data.

The problem is that they are not very forthcoming with information regarding this interface so I'm not 100% sure how to implement the readout of the meter.

Here are the facts and what I know so far:

Hardware:
ISKRA (Iskraemeco) AM550
It has an optical interface (IR LEDs)
I have a USB to Serial to IR LED interface Cable

Infos:
This is the only information I received from the powercompany:
– Protocoll: IEC 62056 – 21
– optical interface (IR)
– DLMS IDIS CII

Additional Info I could gather from the webinterface where you can enable the customerinterface:
"Information is sent every second over the IR Interface"
and also a 32 char HEX encyption key

If I use e.g. Hterm with "9600 Data 8 Stop 1 Parity None" I see that every second I receive data over the IR-Serial Adaper. (sending the DLMS handshake does nothing)

I would like to create a python script (with the help of the gurux-dlms library) to gather and decode/decrypt the data to read the meter values.

Could you please give me some directions because it seems this meter does not use the regular way of handshake etc but instead just sends bursts of (encrypted)data.

Thanks a lot!

Hi,

I believe that your meter is sending push messages and you can use that encryption key to decrypt received push message.

It might be possible that you are not allowed to make a connection to the meter. You can only receive push messages. This is for security reasons.

If you can post one push message in hex here, I can check that received data is correct.

BR,

Mikko

Hi Mikko,

this is one of the push messages in hex:

7EA067CF022313FBF1E6E700DB0849534B697456F2C34F20001E7C7084747ABDE06AFD9D573972A26FB7E03E19D13366C43B72A212BA089F79B3EC074F474E1EA9C86E445EC8156D8C0EC33B9953FA58200768FDCCD633933B4453BF53C990C241E538C3320D01E27E

Image

Hi,

Below is source code. Update keys that you have received from the power company and you should see received data in XML.

BR,

Mikko

from gurux_dlms.GXByteBuffer import GXByteBuffer
from gurux_dlms.GXDLMSTranslator import GXDLMSTranslator
from gurux_dlms.GXReplyData import GXReplyData
from gurux_dlms.secure.GXDLMSSecureClient import GXDLMSSecureClient
from gurux_dlms.TranslatorOutputType import TranslatorOutputType

reply = GXReplyData()
notify = GXReplyData()
data = "7EA067CF022313FBF1E6E700DB0849534B697456F2C34F20001E7C7084747ABDE06AFD9D573972A26FB7E03E19D13366C43B72A212BA089F79B3EC074F474E1EA9C86E445EC8156D8C0EC33B9953FA58200768FDCCD633933B4453BF53C990C241E538C3320D01E27E"
cl = GXDLMSSecureClient(True, 0, 145)
cl.ciphering.authenticationKey = cl.ciphering.blockCipherKey = GXByteBuffer.hexToBytes("UPDATE CORRECT KEY")
if cl.getData(GXByteBuffer.hexToBytes(data), reply, notify):
if len(notify.data) != 0:
#Handle notify.
if not notify.isMoreData():
#Show received push message as XML.
t = GXDLMSTranslator()
cml = t.dataToXml(notify.data)
notify.clear()

Hi,

I forget to say that update to the latest version from gurux-dlms. We fixed a few issues.

BR,

Mikko

Hi Mikko,

wow, thank you very much!
I have been playing aroung with the c sharp library all morning because I thought that there is no secureclient in python (the documentation said so) - but with python it will be way easier.

I've entered my encryption key but using gurux-dlms 1.0.19 "cl.getData(GXByteBuffer.hexToBytes(data), reply, notify)" always returns false

I received only one key (32 characters) - is it the case that it is auth and block cipher key? or do we split it in half?

do I maybe need to do something with the hex string? (prepending 0x only gives invalid hex string)

Hi,

Secure client in python is newer functionality. Doc is updated at some point. :-)
Remove 0x from a hex string. Key size is 16 bytes. Are there 32 chars in hex string?

getData returns false because there is no reply. len(notify.data) is not zero if there is notify message.
It's possible that sometimes there is a reply and notify in received data. This might happen when we communicate over the air. Usually, that is not happening when we are using TCP/IP or serial port connection.

BR,
Mikko

Hi,

Change this:
if cl.getData(GXByteBuffer.hexToBytes(data), reply, notify):
to
if not cl.getData(GXByteBuffer.hexToBytes(data), reply, notify):

BR,

Mikko

Yes its 32chars long so it is

Yes its 32chars long so it is 16 bytes.
I get the following error now:

Traceback (most recent call last):
File ".\testdecode.py", line 19, in <module>
cml = t.dataToXml(notify.data)
File "C:\Users\TobiasPerschon\AppData\Local\Programs\Python\Python35-32\lib\site-packages\gurux_dlms\GXDLMSTranslator.py", line 1674, in dataToXml
_GXCommon.getData(data, di)
File "C:\Users\TobiasPerschon\AppData\Local\Programs\Python\Python35-32\lib\site-packages\gurux_dlms\internal\_GXCommon.py", line 289, in getData
value = cls.getDouble(data, info)
File "C:\Users\TobiasPerschon\AppData\Local\Programs\Python\Python35-32\lib\site-packages\gurux_dlms\internal\_GXCommon.py", line 591, in getDouble
cls.setData(tmp, DataType.FLOAT64, value)
File "C:\Users\TobiasPerschon\AppData\Local\Programs\Python\Python35-32\lib\site-packages\gurux_dlms\internal\_GXCommon.py", line 1249, in setData
buff.setDouble(value)
File "C:\Users\TobiasPerschon\AppData\Local\Programs\Python\Python35-32\lib\site-packages\gurux_dlms\GXByteBuffer.py", line 280, in setDouble
self.setDouble(value, self.size)
File "C:\Users\TobiasPerschon\AppData\Local\Programs\Python\Python35-32\lib\site-packages\gurux_dlms\GXByteBuffer.py", line 283, in setDouble
self.set(struct.pack("d", value))
struct.error: required argument is not a float

Hi,

Can you post notify.data hex string? I'll check this.

BR,

Mikko

05 18 E0 D2 20 A2 15 5A 83 C8

05 18 E0 D2 20 A2 15 5A 83 C8 85 03 7D EF 76 0B D8 67 D5 21 5F 32 4A BB D4 AE 15 77 6A 1F 04 59 DE E8 0F AB 5D F1 D1 97 49 03 95 9A 58 8A 73 CD D9 B0 FC 4E A3 86 37 DC 7F 26 F5 76 F6 6E AB 1F 91 D2 5F 2E DE 2A 8A EA 29 55

Hi,

Data is invalid. Usually it means that key is not correct. Python version is quite new. We'll test this.

BR,
Mikko

Hi!

Is there an example how this is done using c and arduino?
That would be great to hear for one of my projects ;-)

Regards
Steve

Hi Steve,

You can do this with ANSI C. There is a client example that can do this, but there is no XML support. You need to save received data by yourself.

BR,
Mikko

thank you for the info mikko!

I try to develop a converter from smart meter to homematic system. I use an arduino with serial connected IR reader for the meter and Asksin++ library.
The hardest part is decryption but maybe i can use your lib depending on how much space it needs on the arduino.

Currently i can receive the smart meter push message but it seems to be wrong. Maybe there is something missing between E6 E7 and DB?

7E A0 67 CF 02 23 13 FB F1 E6 E7 DB 08 49 53 4B 69 74 92 ED 66 4F 20 02 B2 FD FE 7C 38 36 B7 17 25 49 D0 A3 A8 99 D3 8F F1 37 21 DA A0 BB 58 96 EF 55 E2 84 8C 15 58 BF 71 5C 7E 53 7E F3 9D 49 53 C2 94 68 F4 B5 B4 01 B0 6E 10 BE 31 89 AD 59 08 55 A5 36 96 FA 7B 7D 76 A4 93 CC AD 8D 98 E2 98 84 7E

I have a 32 character key, but when i put it in your DLMS Translator nothing happens.
Do you have an idea why?

Regards Stefan

Hi. Same question here.

Hi. Same question here.
A sample data packet from my AM550:

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 d9 16 c2 0d ea cb d1 33 48 b0 7a 7b 3a 85 0a c5 c1 ce 55 a7 0e a5 7a 15 c2 84 c6 ba 47 32 6e 2a 59 8f 32 76 b7 a4 a1 5c 03 93 c4 49 2c a8 3a 56 0b 3b 53 5d 15 8a 22 05 5f 89 a1 11 7c aa 91 89 5f cf 63 c5 05 b4 20 7b 16 a9 a3 f6 79 7e

From octet 1 til 27 ("b1" in above example) it is same in all messages.
Octet 28 ("d9") increases by 1 every message or second (I get 1 message each second, so hard to tell if it's sequence or seconds)
From octet 29 ("16 c2...") until last but one the content changes each packet.

I have the 32char/128bit key from Webportal.
What enc-algo is used?
How to build the IV?
What part of that message is the encrypted part?
Where to fill "00"?

Hi Stefan,

There are bytes missing from the message. There should be 105 bytes and now there are only 99.
What IR reader you are using?

DLMS is a large protocol and there are a lots of features that you don't need if you are only receiving push messages. If you remove all non-needed features you might get this work in Arduino.

You don't receive any output because the data is invalid. Check why you are not receiving the correct data.

Set 32 char keys to block cipher and authentication keys and it will start to work when your data is correct.

BR,
Mikko

Hi,

Set 32 char key to block cipher and authentication key and you can get XML output.
Used encryption debends from the meter. You can get more information from here:
http://www.gurux.fi/Gurux.DLMS.Secure
Your meter is using AES-GCM-128.

BR,
Mikko

Thanks for your hint. In

Thanks for your hint. In Gurix-DLMS-Translator I have set:

Ciphering -> Security=Encryption, BlockCipherKey and AuthKey=may 32char hex key.

With this The translations results in:

1: 7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 6C 83 B4 4F 20 00 03 B1 D9 16 C2 0D EA CB D1 33 48 B0 7A 7B 3A 85 0A C5 C1 CE 55 A7 0E A5 7A 15 C2 84 C6 BA 47 32 6E 2A 59 8F 32 76 B7 A4 A1 5C 03 93 C4 49 2C A8 3A 56 0B 3B 53 5D 15 8A 22 05 5F 89 A1 11 7C AA 91 89 5F CF 63 C5 05 B4 20 7B 16 A9 A3 F6 79 7E
<HDLC len="66" >
<TargetAddress Value="67" />
<SourceAddress Value="91" />

<FrameType Value="13" />
<PDU>

<GeneralGloCiphering>
<SystemTitle Value="49534B69746C83B4" />
<CipheredService Value="200003B1D916C20DEACBD13348B07A7B3A850AC5C1CE55A70EA57A15C284C6BA47326E2A598F3276B7A4A15C0393C4492CA83A560B3B535D158A22055F89A1117CAA91895FCF63C505B4207B16A9A3" />
</GeneralGloCiphering>
</PDU>
</HDLC>

So first: it is not decrypted.
And second: the "CipheredService Value" appers to be to be one octet too short. I caputred 40+ packets and all have the same length. So I feel this is not an IRDA/hw-interfacing issue, but rather a data issue?

You think this is due to a firmware version issue?
The meter shows:
1.0.0.2.0 (Core FW) = 302002
1.5.0.2.0 (APL FWLR) = 302008

Another interesting thing: byte 5 of ciphered-block (here: "d9") increments by 1 each packet. For that reason this byte is unlikeley part of the cipheredblock. I can't imagine that an imcremeted value like "second" will also appear as an incrementing byte after encryption.

Here an example 9 packets in sequence, where as octed 28 increments from "d9" to "e1":

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 da c0 b0 52 5d a1 3d 5d 20 f3 ff c5 34 fd 60 87 d7 e3 31 22 70 eb 06 b1 82 86 b3 32 bb e2 c5 c5 fe dc ed c4 0a 3f b3 f8 0c ae 04 92 d1 3d 08 9f 64 f6 18 26 75 dd cb 22 c0 06 e3 fa e8 a5 dc b4 83 17 d5 7b 57 39 6c e1 a2 26 6f ae 53 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 db 45 e7 e7 68 91 fb de 03 9d f9 36 87 20 16 7f 1a fa b0 a9 d3 68 df 2c ff 94 b7 ed aa 44 81 17 03 9e f5 d8 d4 0b 55 89 63 49 16 3a 38 f5 4d a3 77 17 17 71 b6 d8 0d ac a0 44 30 e5 e4 b1 0e 88 cf 20 f9 ba 31 ed 7a 8c 23 7d db f4 28 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 dc 7d d7 62 23 c6 0e 62 87 eb 53 84 1d 22 e2 03 f0 a0 e8 64 2e b6 8e 4e 2a 31 d9 7a 37 24 1f e8 c8 13 be cc 1d cc 15 b5 2b be db b6 fe 41 f1 17 17 ce e0 aa c9 20 ff 91 c0 ba cc 41 14 ea b9 d2 d3 f7 98 85 f0 a2 3f 02 b5 3b d1 7e 51 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 dd 06 0c fa 1b c3 3d 65 6a 1f 16 b6 51 e5 56 6d 23 d6 e5 0d fa a9 80 b1 18 a8 a4 9c c7 7c 44 df dd 57 4f e0 72 ce 14 db 07 e1 86 c9 b8 19 ac 56 e8 61 54 ff 8a 13 65 c9 c6 9e 91 81 bd f5 35 35 aa 4b 73 e0 b2 e9 29 f3 79 5d 0e f9 57 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 de 4d a9 86 79 07 a6 e0 2a 48 67 c2 e3 bf a6 6f 22 2f 95 b2 61 e7 af 98 08 47 ce 8b 6e 4f 65 db 6a 29 d0 93 ed d1 3c cd 41 22 f4 84 d1 e3 42 e9 1e 39 70 e6 c1 8a ac 9b 4a 97 95 2a e7 6f 76 68 cc b7 f1 3d c9 e2 65 39 ad c9 ef e2 bd 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 df a8 59 ab 1a 55 be 95 a4 50 f2 c2 18 71 72 0f 92 f1 d2 d4 93 2e 5d ca 26 b3 0f c4 ea 8d 15 f3 d2 1b 02 da 37 5f d2 12 f8 ae 6b 5e 4a e1 6f 43 80 27 11 8f c5 a2 aa b3 2d 5e de d5 62 b3 93 cf fe 21 db 89 40 0e 5f 72 1a 2c 7c 7e 25 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 e0 c4 9c 7d e4 47 89 f4 87 e9 59 5a 2a 9c e6 b3 be 0c ff 8a 3f 89 fa e3 08 28 9a 8c 1e ec f2 de 9b a1 64 7a f5 28 39 40 61 3c 04 ad 38 1e 90 00 76 75 31 92 ee 83 e6 25 22 66 8c 50 96 ee 8a 1b ff 8e 90 f8 4f 92 2b ff 56 b2 c1 9f 45 7e

7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 e1 8c c9 c0 b5 18 6b 62 1c d1 6d 02 0b b9 14 5a 79 01 17 59 20 68 38 d2 15 83 7b af f7 eb 96 67 8f 9a 1f d5 00 ba 67 07 82 71 a7 4d 66 af 80 12 97 4e 43 7d d3 ec 13 e3 db c3 ac 8a 0d dc 75 b9 d1 b5 e0 fa c9 ec 5d dc a7 9f 37 0e 02 7e

Hi,

#1. Check your keys. Data is not shown because decrypt fails. There was a firmware update that fixed one ciphering issue, but I can't remember the firmware version. Check your keys first.

#2. That D9 is invocation counter value. It's increased for each PDU (data packet).

BR,
Mikko

Thx, I asked my power

Thx, I asked my power provider on that: firmware and possible ciphering-bug.
In addition I plan to disable and re-enable that interface. By doing that I hope for:
-) a new (and working) key for the new interface activation maybe
-) a reset of invocation counter. If the key kept unchanged, I maybe can get a second frame with identical invocation counters: Assuming that the decrypted payloads start with the same data (i.e. headers, year/month) there could be a chance of brute-forcing IV and/or the key...?

BR, Pocki

Hi,

We have tried to solve the keys with brute-force. :-) If you have time and powerful PCs, it is possible,
but it'll take a long time.

IC is not usually reset when keys are changed.

BR,
Mikko

Hi, you're right:

Hi, you're right:
I disabled the interface and re-enabled it a day after:
-) Key is the same as before (thus still unusable because either wrong or suffering from firmware bug)
-) IC did not reset. The counter continued from where it stopped the moment when the infrared interface was switched off.

Currently I am still waiting for a reply from my power company.
BR

when your energy provider is

when your energy provider is wiener netze then you will geht the same key after disabling and enabling the customer interface

Yes, my privider is "Wiener

Yes, my privider is "Wiener Netze".
And yes, it happened to way you told: after re-enabling the customer interface I got the same key again.
In addition I realized, that its invocation counter was stopped when customer interface was disabled and continued from that counter value on when re-enabled.
BR, Pocki

Hi,

Let me know what happened.

BR,
Mikko

They told that "they have

They told that "they have supplied the encryption key successfully and that is all they can do.
I shall contact the manufactor of the reading device" (what I am myself).

Any idea how to get further?

yes its horrible. they

yes its horrible. they shipped a system they don't understand themselves... I already called e-control and asked them if there is any way to force them to give you a working interface but they just said that legally they are not required to provide a working interface

I asked at

I asked at digitalgridsolutions.at for support on the topic "Wiener Netze encryption of HDLC payloads on Iskrae AM550 infrared interface". They are mentioned as the only local provider of Iskraemeco products.

I asked Wiener Netze how to

I asked Wiener Netze how to decrypt die Push Notifications from the energy counter with the Key provided in the Web Interface but I did'nt get an answer yet. World wide waiting for WN....

Well, please tofuSCHNITZEL:

Well, please tofuSCHNITZEL: keep pushing WN to fix it. Or to provide information on ciphering (key correct? iv building rule? disable encryption?), firmware, technical contact person to continue on expert support level.

As now we seem to be three people having the same issue, chances rise to get more attention there.
Keep updating us here on any news :-)

What firmware versions do

What firmware versions do your Iskraemeco AM550 show?
Mine (decrypt not working) shows:
1.0.0.2.0 (Core FW) = 302002
1.5.0.2.0 (APL FWLR) = 302008

Hi,

If you can send the push message as a hex string and the key I can try to check if I can find anything on Thursday. Don't give the key here, send it to me by email.

BR,
Mikko

Thank you - I forwarded data

Thank you - I forwarded data packets and my key to your mailbox (taken from gurux.fi/about).
Looking forward to receiving your findings... :-)

How can I find out the

How can I find out the firmware version? Is it part of the push message?

No, it's not part of the

No, it's not part of the messages.
You'll need to go outside and read it directly from the display of the smart meter.
I think you need to press the upper button a few times until it shows these values.

Hi !

I also send you an email with messages from my smart meter and the key. Hopefully you can take a look at it :-)

Regards Stefan

ok, got it!

ok, got it!
1.0.0.2.0 = 302002
1.5.0.2.0 = 302008

Maybe WienerNetze extracted

Maybe WienerNetze extracted/injected the aes-key in the wrong bit order (MSB instead of LSB, or opposit).
So, what about trying to bitmirror all bytes of the aes-key and decrypting with that?

tried that, did not change

tried that, did not change anything

Hi Mikko - have you been able

Hi Mikko - have you been able to find anyhing helpful so far?

Do the keys from different SmartMeters at WienerNetze differ?
Could it be that WienerNetze got the keys from the manufacturer in encrypted form and "forgot" to decrypt them? Thus, the presented key is not the key itself, but the ciphertext of the key?

BR, Pocki

I recieved an answer from e

I recieved an answer from e-control:
According law regulations, the power network provider needs to reply to complaints/requests within 5 working days.
And: ElWOG §84 specifies, that the power network provider must grant access to the smartmeter's customer interface, as well as a description of it. By failing in giving the appropriate working decryption key, this rule is not met. For such case the legislation specifies in §99 a fee of up to TEUR 75.

At digitalgritsolutions I

From digitalgridsolutions.at I received an info from a representativ of Iskraemeco:
First reply was quick but did not cover our problem (instead, it was about receiving that data with apropriate hardware settings).
Second reply from yesterday told, they realized our case to be different (i.e. it cannot even be decrypted using GXDLMSDirector) and are still investigating. I gave them a full (encrypted) data frame and the key I got from Wiener Netze. Hopefully they can check what's wrong: key or encryption.

didn't get an answer from

didn't get an answer from wiener netze so far..... my first request is a long time ago now and it seems that there won't be an answer in general.

nevertheless i reported another issue or bug or whatever of the ISKRA AM550 smart meter today to wiener netze including examples.

i logged a few push messages from the meter and found out that sometimes a message is received which is shorter than the others. see the following examples. first and third are correct or semi correct and second is shorter than the others:

7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 92 ED 66 4F 20 00 1D 27 DC 8B 31 1E CA 46 0B B4 0F 27 DF 9A 0F F3 E7 36 75 4B 7C D8 F3 35 47 49 9F E0 93 79 B7 87 E1 E3 22 67 AD 3A F0 4D B3 0F 42 C9 DE 2F 7F 10 FE 8A DF 86 BA 32 79 48 EC 5C FC 57 31 AF CA AF C2 AC 80 F9 E8 7F 62 1A 94 41 10 8E DE 09 F6 7E

7E A0 67 CF 02 23 13 FB 69 74 92 ED 66 4F 20 00 1D 27 DD BF 7C 47 94 EB 2C BA DF F8 CF 92 4A 33 64 EA E6 63 B5 8D B7 8C 4D 0E 1B 92 CD DE C7 25 CB 9F 17 7B C2 56 AE 83 AA 41 94 D4 62 9E 6B 3E 4C 9B 33 EC 46 74 06 DE B5 C8 40 4C 54 98 53 A2 B2 51 49 5C 2B 19 D6 7F B2 7B 98 CD 5C 3D 13 7E

7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 92 ED 66 4F 20 00 1D 27 DE 2F C7 C7 26 6C 39 B7 14 0F 33 16 CB 37 7C 44 FD 54 78 04 B3 53 BE 2E 57 D2 BB C8 ED FB 47 C1 B1 04 EF 9F 72 7D 81 16 75 86 E8 52 93 67 78 FD 70 BA 28 E4 9B 7E 53 03 83 88 A4 AE 5A 84 C7 2D E9 11 AB 50 71 2A 79 8E FA 07 D3 C1 FA 7E

It seems that there is a part from the HDLC header simply missing but the framecounter is correct. This makes the message unusable and simply seems to be a bug of the message creation in the meter.
I reported this issue and requested a firmware update to correct this problem.

Maybe that additional issue will produce some reaction or fixing at wiener netze.

Hi. Can you be sure that the

Hi. Can you be sure that the missing 9 bytes are not lost on your receiving side?
CRC on first and third message is ok.
CRC on second (shorter) message is wrong, indicating that the message broke between sender and receiver. In addition, the length byte (byte 3: "67") indicates the expected length to be the same on all of the 3 messages.

I put together this script to verify or calculate a crc16 sumo for a given hex string:
https://gist.github.com/pocki80/c4887c40abc11ed6df46e4aa0550e38f

I got some basic feedback to

I got some basic feedback to the specification directly from Wiener Netze:

According them, the interface follows these standards:
Protokoll: IEC 62056 - 21
Hardware interface: optical, infrared
DLMS IDIS CII

Following information is pushed each second:
Time and Date
Wirkenergie +A (Wh)
Wirkenergie -A (Wh)
Blindenergie +R (varh)
Blindenergie -R (varh)
Momentanleistung +P (W)
Momentanleistung -P (W)
Momentanleistung +Q (var)
Momentanleistung -Q (var)

That's it. No info about encryption, frame structure, field lengths, separators,...

Forum Rules