Current month used issue / Sollentuna Energi (Sweden)

[zelbanna]

Hi, I am using the MQTT integration with HA and since morning on the 14th my current month used value follow current hour used value so went down from 300kWh something to exactly whatever the current hour is showing(!)

same in the web UI. The daily graph of export and import is however correct

I don’t know what kind of bug I hit but I upgraded 2.3.5 to 2.3.8 this morning and it is the same.

[ArnieO]

Strange error!

• Do you see any other issues in the recorded historical data around the time when the accumulated value dropped?
• Do I understand correctly: Is the value you have in Real time calculations/Consumption/Month now always identical to Real time calculations/Consumption/Hour ?

Can you post a screenclip of what you have in Real time calculations?

[zelbanna]

I didn't see anything. But I cleared the data and rebooted to see if that would resolve it but actually now the history is still empty

[Sopis67]

Hi,
I also have problem, but for me it's the daily used and daily cost which resets every hour.
This started on the morning off the 12th for me.

[ArnieO]

Definitively a bug - but what could be the trigger?

@zelbanna is on a Pow-K, presumably on a meter that sends HAN-NVE payloads. Which meter are you on?

We have "only" received these two error messages, and I don't see this issue on my installation (Pow-K, firmware v2.3.8).

Can I ask you to help us by running a Telnet debug at the passing of whole hour, to see if there is a debug message there that could help us figure out what is going on? Ensure you run it in "Verbose" mode.

[Sopis67]

I'm also using Pow-K but i'm using HAN-P1 i think (RJ12, not RJ-45)

I will try a Telnet debug later today, when i'm home after work.

[ArnieO]

HAN-P1 i think

Take a look at the baud rate on the config screen. If it is 115 200, your Kamstrup is P1-configured.

This could be a clue! We do not have that many Pow-K on P1-configured meters, which could explain why we're not getting many bug messages on this.

The P1 payloads have kWh in each message - so there is no need to do anything at passing of whole hour.

EDIT:
From our records, I believe @zelbanna has a board v1.5.1, which cannot read P1-configured meters (unless he has modified it - which is not impossible). So: waiting for @zelbanna to return to the thread!

[Sopis67]

According to my grid company i'm using RJ-12 but the configuration is not 115 200.

[ArnieO]

Then your meter is not configured as "RJ12", or "Svenska porten", as it is called here: https://hanporten.se/svenska/porten/
If your meter is configured as "RJ12", it will transmit at 115 200 baud - so yours must be configured as HAN-NVE, or "Norska porten".

Which grid company is this? I believe some grid companies in Sweden are in the process of upgrading firmware in their meters, it could be that your meter is still configured as "Norska porten".

We will easily see that from the content of a payload when you do a Telnet debug later.

[ArnieO]

It looks like you have two slightly different symptoms:

• @zelbanna: Current month and Current day are reset each hour
• @Sopis67 : Current day is reset each hour

[zelbanna]

Do you want me to collect any data? (posted current stats further up in the thread)

[ArnieO]

Thank you!
OK, so this is also a HAN-NVE configured meter (2400 baud). No need to check the model of the Kamstrup, they all behave the same.

Looking forward to Telnet debug later this evening! 👍

[zelbanna]

Hi - an update: both current day and current month is reset every hour - checked home assistant which logs data points for the 3 measurements and all graphs are the same. So this might be the same issue as @Sopis67

[ArnieO]

Thank you for the update.
@Sopis67 : Is your symptom identical?

[Sopis67]

It looks like my current month also resets but not all the way to zero.

From my Telnet debug, not sure how much data you need but from line 1183 the problem starts i think.
AMS Reader Sopis67.txt

[zelbanna]

My log file, I ran it from 21:58 to 22:00:18 to be sure I got 2 readings after the hour shift

putty.log

@Sopis67 - think I had the same as you, but if you clear old data in the logs in the AMS reader you will see a reset to zero

[ArnieO]

Thank you both.

I have analyzed your input and identified the problem; here we go:

The "HDLC frame" sections of the debug can be decoded using https://www.gurux.fi/GuruxDLMSTranslator (paste, then click "To XML").
The "translated" XLM format is something like this:

<DataNotification>
  <LongInvokeIdAndPriority Value="00000000" />
  <!--2024-09-18 20:00:10-->
  <DateTime Value="07E809120314000AFF800080" />
  <NotificationBody>
    <DataValue>
      <Structure Qty="19" >
        <String Value="Kamstrup_V0001" />
        <!--1.1.0.0.5.255-->
        <OctetString Value="0101000005FF" />
        <String Value="5706567324791363" />
        <!--1.1.96.1.1.255-->
        <OctetString Value="0101600101FF" />
        <String Value="6841131AN245101090" />
        <!--1.1.1.7.0.255-->
        <OctetString Value="0101010700FF" />
        <UInt32 Value="000000E2" />
        <!--1.1.2.7.0.255-->
        <OctetString Value="0101020700FF" />
        <UInt32 Value="00000000" />
        <!--1.1.3.7.0.255-->
        <OctetString Value="0101030700FF" />
        <UInt32 Value="0000001A" />
        <!--1.1.4.7.0.255-->
        <OctetString Value="0101040700FF" />
        <UInt32 Value="00000052" />
        <!--1.1.31.7.0.255-->
        <OctetString Value="01011F0700FF" />
        <UInt32 Value="00000006" />
        <!--1.1.51.7.0.255-->
        <OctetString Value="0101330700FF" />
        <UInt32 Value="00000030" />
        <!--1.1.71.7.0.255-->
        <OctetString Value="0101470700FF" />
        <UInt32 Value="00000056" />
        <!--1.1.32.7.0.255-->
        <OctetString Value="0101200700FF" />
        <UInt16 Value="00EB" />
        <!--1.1.52.7.0.255-->
        <OctetString Value="0101340700FF" />
        <UInt16 Value="00EA" />
        <!--1.1.72.7.0.255-->
        <OctetString Value="0101480700FF" />
        <UInt16 Value="00ED" />
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

For each data point here you see the OBIS code identifiers, which you find in the definition of the payloads in the Interface spec (see below).

The Interface specification, section "5.1 HAN-NVE", describes the two payloads that are sent:

• Push data list 1, sent every 10 seconds
• Push data list 2, sent every hour

The column "Logical name" is the OBIS code identifier for each data point, which you'll find in the decoded message (see above).

Only List 2 contains accumulated energy (Wh), and should be sent in between the List 1 messages at xx:00:00 and xx:00:10. As indicated in Interface spec section "5.1.2.1 Time trigger setup", the List 2 is normally sent at xx:00:05.

Debug from @Sopis67

• First data point at 19:58:10
  Starting at line 638, you received payloads at
• 19:59:50
• 20:00:00
• 20:00:10
  ...with no Push List 2 at 20:00:05

However, I find a List 2 in the DLMS frame starting at line 1081, received at 20:00:55 (!)
You can see it when scrolling, as the List 2 payload is larger.

**Debug from @zelbanna **
Your file contains payloads received at

• 21:58:10
• (a number of payloads I did not look at)
• 21:59:30
• 21:59:40
• 21:59:50
• 22:00:00
• 22:00:10
• 22:00:20 (the last payload in the file)

I do not see any List 2 in this file, but I assume it arrives very late also in your case (your file does not go all the way to 22:00:55).

Conclusion
Receiving Push List 2 at xx:00:55 is highly unusual, we have never seen this before.
EDIT: Investigations show that this is normal now. The meters seem to have changed behavior a bit since I last looked at this in detail some years ago.

However, I see this in the Interface spec:

This indicates that the delay could be caused by a timer collision in the meter - and that Kamstrup will not consider the late List 2 to be an error.
We will discuss (ping @gskjold) whether the firmware could be modified to handle this situation correctly.

While waiting for a solution, I recommend both of you to try to reboot your meters - which could potentially reset them to "normal" operation. In Norway the main breaker is on the "street side" of the meter, so pulling the main breaker for 10 seconds will reset the meter. Is that possible also on your installations?

The situation is highly unusual. We have more than 1600 Pow-K running on Kamstrup meters in several countries - and have not seen this before.

I'm wondering: Are you two in the same region / with the same grid company?

[ArnieO]

Could be a coincidence, of course - but @zelbanna is also located in Sollentuna.

[zelbanna]

I am also with SEOM - they must have been pushing some update to their Kamstrups

[ArnieO]

What we see from the Telnet debug is not really an error, so we want to find out why the firmware does not accept that List 2 message (code analysis ongoing).
It is, however, strange that both your meters have started behaving differently around the same time - which indicates that the cause could be a firmware upgrade.
Please try to restart your meter as indicated above, to see if that helps (while waiting for our next firmware release where we'll try to remedy this).

[zelbanna]

I saw those messages at every x6 or x7 second of a minute, e.g.: 07, 17, 27 etc, so either debugging output is a bit late... or processing is slow. Could it be that you checked the output against system clock and decided the packet came out of time? I checked my firewall and it is typically <1ms error

[ArnieO]

Could it be that you checked the output against system clock and decided the packet came out of time?

Good comment - as there are two clocks here: Timestamp from the meter (which could be out of sync) and device time on the Pow-K (synced from internet). We discussed this, but do not think it is the root cause.

There should have been a message in the debug immediately after the List 2 payload that indicates hourly data update. There is no such message in the debug from @Sopis67, which means the payload was for some reason ignored.

[gskjold]

I have a theory, so here is a tests version you guys could try:
esp32s2.zip

[ArnieO]

OK but... it does not look like you have solar panels, as your accumulated value for export kWh is zero?

[ArnieO]

Ah... the 8 kWh is @Sopis67 - not @zelbanna !
I did not receive log from you @zelbanna that included a List 2 message, so I do not have accumulated kWh for your meter.

[Sopis67]

My meter is now at 21202


8kwh is normal for me during summer (living in a small house with no solar panels).

[ArnieO]

OK, we're closing in on the problem:
Your meter says 21202 kWh and the gauge says 2120 kWh.

Do you have a modified setting on Config page / Meter / Multipliers?
Your raw data shows you receive the same number of digits as me, and I have no modification on the multipliers, they are all set to 1:

[Sopis67]

Yes, my multiplier was set to 0,1 so that explains the difference in kwh.
I also did a meter reboot but still the month and day resets on the hour.

[ArnieO]

I did a Telnet debug on my meter, and see that I too now receive List 2 at xx:00:55 - so something has happened since I last looked into this some years ago. I also did a side-by-side comparison (end of post) with @Sopis67 List 2.

Here is my frame that updates data storage:

(V) HDLC frame:
(V) 7E A1 2C 2B  21 13 FC 04  E6 E7 00 0F  00 00 00 00
(V) 0C 07 E8 09  13 04 0C 00  37 FF 80 00  00 02 23 0A
(V) 0E 4B 61 6D  73 74 72 75  70 5F 56 30  30 30 31 09
(V) 06 01 01 00  00 05 FF 0A  10 35 37 30  36 35 36 37
(V) 32 37 37 36  35 36 36 37  32 09 06 01  01 60 01 01
(V) FF 0A 12 36  38 34 31 31  33 31 42 4E  32 34 33 31
(V) 30 31 30 34  30 09 06 01  01 01 07 00  FF 06 00 00
(V) 0C D0 09 06  01 01 02 07  00 FF 06 00  00 00 00 09
(V) 06 01 01 03  07 00 FF 06  00 00 00 00  09 06 01 01
(V) 04 07 00 FF  06 00 00 01  ED 09 06 01  01 1F 07 00
(V) FF 06 00 00  00 A2 09 06  01 01 33 07  00 FF 06 00
(V) 00 03 EE 09  06 01 01 47  07 00 FF 06  00 00 01 3B
(V) 09 06 01 01  20 07 00 FF  12 00 F3 09  06 01 01 34
(V) 07 00 FF 12  00 F2 09 06  01 01 48 07  00 FF 12 00
(V) F3 09 06 00  01 01 00 00  FF 09 0C 07  E8 09 13 04
(V) 0C 00 37 FF  80 00 00 09  06 01 01 01  08 00 FF 06
(V) 01 0E F2 DE  09 06 01 01  02 08 00 FF  06 00 00 00
(V) 00 09 06 01  01 03 08 00  FF 06 00 02  72 61 09 06
(V) 01 01 04 08  00 FF 06 00  16 EC 4F C3  16 7E
(V) LLC frame:
(V) E6 E7 00 0F  00 00 00 00  0C 07 E8 09  13 04 0C 00
(V) 37 FF 80 00  00 02 23 0A  0E 4B 61 6D  73 74 72 75
(V) 70 5F 56 30  30 30 31 09  06 01 01 00  00 05 FF 0A
(V) 10 35 37 30  36 35 36 37  32 37 37 36  35 36 36 37
(V) 32 09 06 01  01 60 01 01  FF 0A 12 36  38 34 31 31
(V) 33 31 42 4E  32 34 33 31  30 31 30 34  30 09 06 01
(V) 01 01 07 00  FF 06 00 00  0C D0 09 06  01 01 02 07
(V) 00 FF 06 00  00 00 00 09  06 01 01 03  07 00 FF 06
(V) 00 00 00 00  09 06 01 01  04 07 00 FF  06 00 00 01
(V) ED 09 06 01  01 1F 07 00  FF 06 00 00  00 A2 09 06
(V) 01 01 33 07  00 FF 06 00  00 03 EE 09  06 01 01 47
(V) 07 00 FF 06  00 00 01 3B  09 06 01 01  20 07 00 FF
(V) 12 00 F3 09  06 01 01 34  07 00 FF 12  00 F2 09 06
(V) 01 01 48 07  00 FF 12 00  F3 09 06 00  01 01 00 00
(V) FF 09 0C 07  E8 09 13 04  0C 00 37 FF  80 00 00 09
(V) 06 01 01 01  08 00 FF 06  01 0E F2 DE  09 06 01 01
(V) 02 08 00 FF  06 00 00 00  00 09 06 01  01 03 08 00
(V) FF 06 00 02  72 61 09 06  01 01 04 08  00 FF 06 00
(V) 16 EC 4F
(V) DLMS frame:
(V) 0F 00 00 00  00 0C 07 E8  09 13 04 0C  00 37 FF 80
(V) 00 00 02 23  0A 0E 4B 61  6D 73 74 72  75 70 5F 56
(V) 30 30 30 31  09 06 01 01  00 00 05 FF  0A 10 35 37
(V) 30 36 35 36  37 32 37 37  36 35 36 36  37 32 09 06
(V) 01 01 60 01  01 FF 0A 12  36 38 34 31  31 33 31 42
(V) 4E 32 34 33  31 30 31 30  34 30 09 06  01 01 01 07
(V) 00 FF 06 00  00 0C D0 09  06 01 01 02  07 00 FF 06
(V) 00 00 00 00  09 06 01 01  03 07 00 FF  06 00 00 00
(V) 00 09 06 01  01 04 07 00  FF 06 00 00  01 ED 09 06
(V) 01 01 1F 07  00 FF 06 00  00 00 A2 09  06 01 01 33
(V) 07 00 FF 06  00 00 03 EE  09 06 01 01  47 07 00 FF
(V) 06 00 00 01  3B 09 06 01  01 20 07 00  FF 12 00 F3
(V) 09 06 01 01  34 07 00 FF  12 00 F2 09  06 01 01 48
(V) 07 00 FF 12  00 F3 09 06  00 01 01 00  00 FF 09 0C
(V) 07 E8 09 13  04 0C 00 37  FF 80 00 00  09 06 01 01
(V) 01 08 00 FF  06 01 0E F2  DE 09 06 01  01 02 08 00
(V) FF 06 00 00  00 00 09 06  01 01 03 08  00 FF 06 00
(V) 02 72 61 09  06 01 01 04  08 00 FF 06  00 16 EC 4F
(V)
(D) Received valid DLMS at 29
(V) Using application data:
(V) 02 23 0A 0E  4B 61 6D 73  74 72 75 70  5F 56 30 30
(V) 30 31 09 06  01 01 00 00  05 FF 0A 10  35 37 30 36
(V) 35 36 37 32  37 37 36 35  36 36 37 32  09 06 01 01
(V) 60 01 01 FF  0A 12 36 38  34 31 31 33  31 42 4E 32
(V) 34 33 31 30  31 30 34 30  09 06 01 01  01 07 00 FF
(V) 06 00 00 0C  D0 09 06 01  01 02 07 00  FF 06 00 00
(V) 00 00 09 06  01 01 03 07  00 FF 06 00  00 00 00 09
(V) 06 01 01 04  07 00 FF 06  00 00 01 ED  09 06 01 01
(V) 1F 07 00 FF  06 00 00 00  A2 09 06 01  01 33 07 00
(V) FF 06 00 00  03 EE 09 06  01 01 47 07  00 FF 06 00
(V) 00 01 3B 09  06 01 01 20  07 00 FF 12  00 F3 09 06
(V) 01 01 34 07  00 FF 12 00  F2 09 06 01  01 48 07 00
(V) FF 12 00 F3  09 06 00 01  01 00 00 FF  09 0C 07 E8
(V) 09 13 04 0C  00 37 FF 80  00 00 09 06  01 01 01 08
(V) 00 FF 06 01  0E F2 DE 09  06 01 01 02  08 00 FF 06
(V) 00 00 00 00  09 06 01 01  03 08 00 FF  06 00 02 72
(V) 61 09 06 01  01 04 08 00  FF 06 00 16  EC 4F
(V) DLMS
(D) Updating data storage (internal clock 11:00:59 UTC, meter clock: 11:00:55)
(D) Day is not happy
(D)  - normal
(I) Saving data

Decoded DLMS:

<DataNotification>
  <LongInvokeIdAndPriority Value="00000000" />
  <!--2024-09-19 12:00:55-->
  <DateTime Value="07E80913040C0037FF800000" />
  <NotificationBody>
    <DataValue>
      <Structure Qty="23" >
        <String Value="Kamstrup_V0001" />
        <!--1.1.0.0.5.255-->
        <OctetString Value="0101000005FF" />
        <String Value="5706567277656672" />
        <!--1.1.96.1.1.255-->
        <OctetString Value="0101600101FF" />
        <String Value="6841131BN243101040" />
        <!--1.1.1.7.0.255-->
        <OctetString Value="0101010700FF" />
        <UInt32 Value="00000CD0" />
        <!--1.1.2.7.0.255-->
        <OctetString Value="0101020700FF" />
        <UInt32 Value="00000000" />
        <!--1.1.3.7.0.255-->
        <OctetString Value="0101030700FF" />
        <UInt32 Value="00000000" />
        <!--1.1.4.7.0.255-->
        <OctetString Value="0101040700FF" />
        <UInt32 Value="000001ED" />
        <!--1.1.31.7.0.255-->
        <OctetString Value="01011F0700FF" />
        <UInt32 Value="000000A2" />
        <!--1.1.51.7.0.255-->
        <OctetString Value="0101330700FF" />
        <UInt32 Value="000003EE" />
        <!--1.1.71.7.0.255-->
        <OctetString Value="0101470700FF" />
        <UInt32 Value="0000013B" />
        <!--1.1.32.7.0.255-->
        <OctetString Value="0101200700FF" />
        <UInt16 Value="00F3" />
        <!--1.1.52.7.0.255-->
        <OctetString Value="0101340700FF" />
        <UInt16 Value="00F2" />
        <!--1.1.72.7.0.255-->
        <OctetString Value="0101480700FF" />
        <UInt16 Value="00F3" />
        <!--0.1.1.0.0.255-->
        <OctetString Value="0001010000FF" />
        <!--2024-09-19 12:00:55-->
        <OctetString Value="07E80913040C0037FF800000" />
        <!--1.1.1.8.0.255-->
        <OctetString Value="0101010800FF" />
        <UInt32 Value="010EF2DE" />
        <!--1.1.2.8.0.255-->
        <OctetString Value="0101020800FF" />
        <UInt32 Value="00000000" />
        <!--1.1.3.8.0.255-->
        <OctetString Value="0101030800FF" />
        <UInt32 Value="00027261" />
        <!--1.1.4.8.0.255-->
        <OctetString Value="0101040800FF" />
        <UInt32 Value="0016EC4F" />
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

This is the decoded List 2 from @Sopis67 :

<DataNotification>
  <LongInvokeIdAndPriority Value="00000000" />
  <!--2024-09-18 20:00:55-->
  <DateTime Value="07E8091203140037FF800080" />
  <NotificationBody>
    <DataValue>
      <Structure Qty="23" >
        <String Value="Kamstrup_V0001" />
        <!--1.1.0.0.5.255-->
        <OctetString Value="0101000005FF" />
        <String Value="5706567324791363" />
        <!--1.1.96.1.1.255-->
        <OctetString Value="0101600101FF" />
        <String Value="6841131AN245101090" />
        <!--1.1.1.7.0.255-->
        <OctetString Value="0101010700FF" />
        <UInt32 Value="000000F3" />
        <!--1.1.2.7.0.255-->
        <OctetString Value="0101020700FF" />
        <UInt32 Value="00000000" />
        <!--1.1.3.7.0.255-->
        <OctetString Value="0101030700FF" />
        <UInt32 Value="0000001B" />
        <!--1.1.4.7.0.255-->
        <OctetString Value="0101040700FF" />
        <UInt32 Value="00000053" />
        <!--1.1.31.7.0.255-->
        <OctetString Value="01011F0700FF" />
        <UInt32 Value="00000006" />
        <!--1.1.51.7.0.255-->
        <OctetString Value="0101330700FF" />
        <UInt32 Value="0000002F" />
        <!--1.1.71.7.0.255-->
        <OctetString Value="0101470700FF" />
        <UInt32 Value="00000064" />
        <!--1.1.32.7.0.255-->
        <OctetString Value="0101200700FF" />
        <UInt16 Value="00EB" />
        <!--1.1.52.7.0.255-->
        <OctetString Value="0101340700FF" />
        <UInt16 Value="00EA" />
        <!--1.1.72.7.0.255-->
        <OctetString Value="0101480700FF" />
        <UInt16 Value="00ED" />
        <!--0.1.1.0.0.255-->
        <OctetString Value="0001010000FF" />
        <!--2024-09-18 20:00:55-->
        <OctetString Value="07E8091203140037FF800080" />
        <!--1.1.1.8.0.255-->
        <OctetString Value="0101010800FF" />
        <UInt32 Value="002056DE" />
        <!--1.1.2.8.0.255-->
        <OctetString Value="0101020800FF" />
        <UInt32 Value="00000000" />
        <!--1.1.3.8.0.255-->
        <OctetString Value="0101030800FF" />
        <UInt32 Value="00032908" />
        <!--1.1.4.8.0.255-->
        <OctetString Value="0101040800FF" />
        <UInt32 Value="00047D5A" />
      </Structure>
    </DataValue>
  </NotificationBody>
</DataNotification>

Side by side comparison of the two; I cannot spot any specific difference:

[zelbanna]

I don’t have any multipliers? Should I enable and set to 1/1/1/1?19 sep. 2024 kl. 18:34 skrev ArnieO ***@***.***>: OK, we're closing in on the problem: Your meter says 21202 kWh and the gauge says 2120 kWh. Do you have a modified setting on Config page / Meter / Multipliers? Your raw data shows you receive the same number of digits as me, and I have no modification on the multipliers, they are all set to 1: image.png (view on web) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ArnieO]

When multipliers are not activated, they are all 1.

If you see the same as @Sopis67 (meter LCD is 10x more than the gauge display) you (and @Sopis67) can set the multiplier for kWh to 10 - and see if that fixes the issue.

However, we still do not understand why this happens, as the number of digits @Sopis67 has is the same as me - so it should not be necessary to use the multipliers.

It would be great if you could run a Telnet debug around whole hour, and include at least 1 minute after whole hour - so that I can decode the raw data you receive. Use the "-f" argument to save to a file (I have updated the article).

[zelbanna]

Here you go. what is weird is that the meter showed the right import 31xxx kWh something, but after restarting (after debug session) the meter looks like it is starting from 0

putty.log

[ArnieO]

In the log you sent, the raw data for kWh is 3186478 (hex 309F2E).
If your meter (too) sends two decimals, you should see 31864 on the LCD screen of your meter.

The log shows that the payload with accumulated energy (kWh) is not accepted. Exactly the same as in the log from @Sopis67.

We must wait for @gskjold to look further into this.

[ArnieO]

Summary

Two Pow-K users with the same Swedish grid company (https://www.seom.se/) have identical problem, that started last week:

• Counters for Daily and Monthly values are reset at each passing of whole hour
• As a consequence, Daily and Monthly graphs are not populated
• Raw data from the meters show that they DO send the "List 2" payload hour at xx:00:55 that includes accumulated energy (Wh)
• The firmware seems to not recognize / accept those frames. We do not know why.
• This message should be shown immediately following the "List 2" frame in the Telnet debug
  (@ArnieO running same firmware on a Kamstrup Omnipower in Norway):
  
• Instead, both users get this Telnet debug messages after the subsequent "List 1" frame at xx:01:00
  
• @gskjold issued an attempted fix that does not remedy the issue. Current month used issue / Sollentuna Energi (Sweden) #843 (comment)
• Rebooting the meter does not remedy the issue.
• Side-by-side comparison of @ArnieO and @Sopis67 List 2 frame content does not reveal anything abnormal. Current month used issue / Sollentuna Energi (Sweden) #843 (comment)
• We have at least four other Pow-K customers with postal address Sollentuna.

[Sopis67]

I updated to 025c556 2 day ago, to af6ecc5 this morning and everything seems to be working fine.
My day graph looked the same as @fredriklin before update to 025c556.

[ArnieO]

My day graph looked the same as @fredriklin before update to 025c556.

You meant af6ecc5 ?

@fredriklin : Which fix version are you running?

[fredriklin]

I am running af6ecc5 since 01:30 22/9. Before that I was on stock 2.3.8.

[ArnieO]

I am running af6ecc5 since 01:30 22/9. Before that I was on stock 2.3.8.

I edited my previous message to you, as I have realized that the plot is perfectly normal.

When it passed midnight, and was missing many days of data, it averaged the total consumption over the days since its latest registered "passing of midnight" - which was fra 12th to 13th Sep. It should behave correctly from now on.

[fredriklin]

You are correct, using version af6ecc5 after a full day it shows correct data on the dashboard.

[ArnieO]

The published fix (#843 (reply in thread)) seems to work as intended.
We'll keep the thread open until firmware v2.3.9 is released, which will incorporate the fix.

[StarkJohan]

I'm having some strange issues since around 06:00 Monday with my Omnipower in Sweden. Found this discussion and thought that it probably was related. Now I'm not so sure anymore.

I suspect that the power company has changed some setting of the meter or have done some update to the meter but I haven't yet confirmed this. While waiting for them to answer please tell me if I'm thinking correctly.

With DLMS data there's full output every 10s. With "ordinary" HAN-NVE there's full data every 60s and current import/export every 10s.
The Web UI shows hourly and daily usage but no "live" data at all. Surely this must mean that my meter now only sends data once every hour? I've been watching the telnet data for roughly 20 minutes now and there is no HAN data output at all. It's currently 08:30 so I guess I will have to wait and see what happens around 09:00. If there is no output at all, the hourly data shouldn't be visible.

What kind of strange data output setting is only once an hour???

[ArnieO]

1. The original issue of this thread seems to be only related to https://www.seom.se/ : Are you also with SEOM (Sollentuna)?
2. Please help me understand these sentences: "With DLMS data there's full output every 10s. With "ordinary" HAN-NVE there's full data every 60s and current import/export every 10s."
3. Please post a screenshot of your config screen.
4. Please run a Telnet debug and share the output file.

[ArnieO]

What kind of strange data output setting is only once an hour???

Good question - and if confirmed, this sounds like a meter error.
I would have tried to reset the meter (easy to do if you have a main breaker on the "street side"), to see if that does the trick.
See this article: https://www.amsleser.no/module/ets_blog/blog?id_post=33

[StarkJohan]

Ok. Issue confirmed and resolved. Answering the questions in case if may be helpful to other users in the future. They're not relevant to my issue.

1. I'm not with SEOM.
2. DLMS sends total sum of the meter and momentary wattage every 10s. HAN-NVE sends momentary wattage every 10s but the total sum is only sent once an hour, slightly after the hour, which is problematic with home assistant statistics.
3. 
4. (I t:3473619ms) Clearing data that have not been updated
   (D t:3473623ms) Type 0, not updating
   (W t:3476203ms) No HAN data received last 30s, single blink

At 06:00 on Monday the power company did some kind of change to the meter. Probably an update of some kind and that locked up my HAN output. Thanks to ArnieO's suggestion I simply cut the power to the meter and when it was rebooted the HAN port started up again. This is of course the oldest trick in the book but as I haven't had any similar issue in 7 years it didn't cross my mind...

[ArnieO]

1. OK
2. OK, I understand now. Yes, some grid companies in Sweden (and maybe Norway) will be willing to change the configuration of your meter from the default HAN-NVE format to DLMS format (which is the default in Denmark - and a better solution). Your typo "60s" confused me! 😅
3. Thanks - but not really relevant since you solved your issue.
4. Ditto

Rebooting the meter is easy if you have the main breaker on the "street side". Unfortunately that is often not the case on installations in Denmark and some other European countries (we have seen such cases in Switzerland), ref information in https://www.amsleser.no/module/ets_blog/blog?id_post=33

I had HAN-port reader on my Kamstrup Omnipower meter for 6 years before needing to restart it - to get the port working again. These things seems to happen "out of the blue", and we have not been able to see anything systematic reason. We have so many readers in operation now, that I believe we would have received error reports from several users at the same time if this was related to firmware rollout in a way that affected all meters receiving it. It seems more like random "glitches" - that may of course have been triggered by an upgrade but if so: only on a very small number of "unlucky" users.