Hello,
I have an Iskra AM550 meter from electricity provider "Romande Energie" in Switzerland. I want to read data from the meter (power and energy)
It has a P1 port and I can see 1 push message every 5 sec. Serial settings are 115200-8-N-1
I tried example "Gurux.DLMS.Push.Listener.Example.python" ...and got it working !
Now I want to figure out how to extract only the useful bytes from the push message.
In my case, 1 push message seems to be 3 hdlc frames - see complete raw data at the bottom of this post.
For example, the Python script displays :
{
01 00 01 08 01 FF
82426
{
0
30
}
}
I can understand that this is OBIS 1.8.1, and it confirms the reading of the meter's display (82.426 kWh). Data "01 00 01 08 01 FF" is in the frame, so this can help me extract in a simple way the desired value.
-QUESTION # 1 : What are values 0 and 30 ?
Going on, I can read 1.8.2 :
{
01 00 01 08 02 FF
179501
{
0
30
}
}
And this is 179.501 kWh. Data "01 00 01 08 02 FF" is in the frame, I can also extract energy value in an easy way.
Still going on, getting to 2.8.1 :
{
01 00 02 08 01 FF
50647
{
0
30
}
}
-QUESTION #2 :
I can't find data "01 00 02 08 01 FF" in the frame.
In place, I can read "13 71 7C 08 01 FF".
? Data shown here is not exactly the same as in the frame ?
How can I be sure to read and decode 2.8.1 ?
And then for 2.8.2, everything is readable again.
Sorry for the dumb question... Maybe you want to reply that I can just use the listener as is. But code for getting values and HDLC format both seem sooooooooo complicated.... And knowing the fact that the frames to decode should always contain the same information, I wanted to make it simpler and just access the desired bytes !
Thanks.
------------------------------------------
Sample received message (3 frames) :
7E A8 A4 CF 02 23 03 99 96 E6 E7 00 0F 00 00 26 EB 0C 07 E7 04 01 06 15 20 23 00 FF 88 80 02 10 02 02 09 06 00 00 60 01 00 FF 09 08 38 34 38 39 35 31 32 36 02 02 09 06 00 00 60 01 01 FF 09 06 31 36 30 34 35 36 02 03 09 06 01 00 01 07 00 FF 06 00 00 00 B6 02 02 0F 00 16 1B 02 03 09 06 01 00 02 07 00 FF 06 00 00 00 00 02 02 0F 00 16 1B 02 03 09 06 01 00 01 08 00 FF 06 00 03 FF 27 02 02 0F 00 16 1E 02 03 09 06 01 00 02 08 00 FF 06 00 00 F9 58 02 02 0F 00 16 1E 02 03 09 06 01 00 20 07 00 EB 33 7E
7E A8 A4 CF 02 23 03 99 96 FF 12 09 3C 02 02 0F FF 16 23 02 03 09 06 01 00 34 07 00 FF 12 09 28 02 02 0F FF 16 23 02 03 09 06 01 00 48 07 00 FF 12 09 42 02 02 0F FF 16 23 02 03 09 06 01 00 1F 07 00 FF 12 00 3F 02 02 0F FE 16 21 02 03 09 06 01 00 33 07 00 FF 12 00 59 02 02 0F FE 16 21 02 03 09 06 01 00 47 07 00 FF 12 00 44 02 02 0F FE 16 21 02 03 09 06 01 00 01 08 01 FF 06 00 01 41 FA 02 02 0F 00 16 1E 02 03 09 06 01 00 01 08 02 FF 06 00 02 BD 2D 02 02 0F 00 16 1E 02 03 09 06 01 00 02 B0 83 7E
7E A0 2D CF 02 23 13 71 7C 08 01 FF 06 00 00 C5 D7 02 02 0F 00 16 1E 02 03 09 06 01 00 02 08 02 FF 06 00 00 33 81 02 02 0F 00 16 1E 58 C0 7E
Hi, #1. For me it looks like…
Hi,
#1. For me it looks like your meter is confiqued to send register scaler (0) and unit (30).
#2. 0100020801FF is in the data. Check it again.
#3. DLMS is a complicated protocol. You need only to accept that. :-)
BR,
Mikko
Thanks ! #1 Good ! #3 :-(…
Thanks !
#1 Good !
#3 :-( for me
#2 I'm very sorry, I must do something wrong.
I can see 0100020801FF data in the listener output. But I cannot find these raw datas in the received bytes.
Hi, 0100020801FF is coming…
Hi,
0100020801FF is coming is two frames. "01 00 02" is coming in the end f 2th frame and 0801FF is coming in the begin of the 3rd frame.
BR,
Mikko