Decrpytion not working

[Cartoon-Dude]

I finally received the key to decrypt the meter data, but it isn't doing anything.
Without putting the key: HAN: Unknown data received, check meter config
After putting the key: no message but HAN still red.
In debug:

(W) No HAN data received last 30s, single blink
(D) Received valid DLMS at 46 +73

Also why is there 2 fields to put the key in? Must put 2 times the same? Let one empty?
Thanks

Pow-P1 v2.4.7

[Cartoon-Dude]

Also the raw data received
debug.txt

[ArnieO]

Which country is this?

[Cartoon-Dude]

Switzerland, we already discussed there: #984

[ArnieO]

OK, I was about to guess Austria. :-)
Try with the "Authentication key" field empty (delete the default zeros that are there as placeholder).

Use the key in the first field.
If the provided key starts with "0x", do not include it.
After entering the key, double check it is entered correctly (all digits are there).

There are two fields because some meters need both Encryption and Authentication keys.

What is the mark and model of your meter?

[Cartoon-Dude]

Iskraemeco AM550
Also if the data is readable in the log attached before, does that mean the decryption was successful?

[ArnieO]

Also if the data is readable in the log attached before, does that mean the decryption was successful?

Sorry, I did not have time earlier to study it.
But the answer is Yes - the decryption is successful.
The section "DLMS frame" can be converted to somewhat readable XML format using this tool: https://www.gurux.fi/GuruxDLMSTranslator

For your first frame, this gives:

<DataNotification>
  <LongInvokeIdAndPriority Value="00CB31B5" />
  <!--2025-09-09 10:38:55-->
  <DateTime Value="07E90909020A263700FF8880" />
  <NotificationBody>
    <DataValue>
      <Structure Qty="0F" >
        <UInt32 Value="01A78D92" />
        <UInt32 Value="017C742B" />
        <UInt32 Value="002B1967" />
        <UInt32 Value="010EE26D" />
        <UInt32 Value="002DDA31" />
        <UInt32 Value="00E1083C" />
        <OctetString Value="" />
        <!--2025-09-09 10:38:55-->
        <OctetString Value="07E90909020A263700FF8880" />
        <UInt32 Value="000004D3" />
        <UInt32 Value="00000000" />
        <UInt16 Value="0088" />
        <UInt16 Value="00CC" />
        <UInt16 Value="00BA" />
        <UInt16 Value="0946" />
        <UInt16 Value="0942" />
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

This is just a listing of 0F (=15) parameters, without OBIS codes to identify them.
In order to decode this, we need to information on the list of parameters.

I'm not the code person here, it is possible that this list is already in our code, we have implemented quite a number of different payload formats now. ( -> Ping @gskjold !)
But the debug shows that the payload is decrypted without error messages.

So what is your situation - do you not see any data in the user interface?
Can you provide a screenclip?

[Cartoon-Dude]

Exactly, nothing at all, so was a bit confused if it was the encryption or something else.

And the technical info that was shared in the other post: https://www.lausanne.ch/en/dam/jcr:6acc5266-c7d9-4457-9a71-86d554462b73/notice-interface-client-compteur-intelligent.pdf

[ArnieO]

Great, we have all the information we need then - and will implement this payload format.
@gskjold : There is work for you here!

We might publish a patch version here before it is included in next firmware revision.
Please allow us a week or two, depending on @gskjold capacity.

[Cartoon-Dude]

It's been two weeks, is there any update?
I can also provide the direct mail and phone of the electric company if needed.

[ArnieO]

It's been two weeks, is there any update?

It's certainly on our list - but focus last few weeks has been on the transition to 15-minute pricing, which is due to be implemented these days.

[gskjold]

Have been looking into this today, but the format does not match anything described in that document...
I can make some wild guesses on the format, but it is not enough to implement a parser:

<DataNotification>
  <LongInvokeIdAndPriority Value="00CB31B5" />
  <!--2025-09-09 10:38:55-->
  <DateTime Value="07E90909020A263700FF8880" />
  <NotificationBody>
    <DataValue>
      <Structure Qty="0F" >
        <UInt32 Value="01A78D92" /> ?
        <UInt32 Value="017C742B" /> ?
        <UInt32 Value="002B1967" /> ?
        <UInt32 Value="010EE26D" /> ?
        <UInt32 Value="002DDA31" /> ?
        <UInt32 Value="00E1083C" /> ?
        <OctetString Value="" />
        <!--2025-09-09 10:38:55-->
        <OctetString Value="07E90909020A263700FF8880" /> (1.0.0 meter timestamp)
        <UInt32 Value="000004D3" /> (1.7.0 active import: 1235w)
        <UInt32 Value="00000000" /> (2.7.0 active export: 0w)
        <UInt16 Value="0088" /> (31.7.0 L1 current: 1.36A)
        <UInt16 Value="00CC" /> (51.7.0 L2 current: 2.04A)
        <UInt16 Value="00BA" /> (71.7.0 L3 current: 1.86A)
        <UInt16 Value="0946" /> (32.7.0 L1 voltage: 237.4V)
(L2 voltage missing?)
        <UInt16 Value="0942" /> (52.7.0 L3 voltage: 237.0V)
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

[ArnieO]

Have been looking into this today, but the format does not match anything described in that document...

You're right, that payload does not correspond to any of the tables in the documentation, which say:

Transmitted once per minute (at 00 sec):

Transmitted each 5 second:

@Cartoon-Dude : Can you contact the grid company and request updated documentation that shows what your meter is actually transmitting? 😐

My guess is that the tables show what is transmitted by only one of the meter brands listed in the start of the document - but not the one you have. Sadly, payload formats are not standardized, each manufacturer tend to have their own format.

[Cartoon-Dude]

Ok, i call them tomorrow, they should at least respect the documentation they wrote, particularly if before it was encrypted there was the OBIS objects included, feels like a downgrade.
Won't be the first error, baudrate is also wrong.
I think the objects must be sent too, in the documentation it said to be sure the DLMS/COSEM objects are correctly read.