Wrong accumulated active energy on Kamstrup Pow-K reader

[BjoernSelander]

Hi, Bought a Pow-K a few days ago, and everyting looked ok until I´ve collected some date from the meter. The accumulated kWh on the AMS-reader is of by the power of 10, both in the MQTT-feed and the webpage. Se attached images bellow. I´m using an avarage of about 30 kW / hour. If that was true, my fuses would burn out. ;-)

• Meter: Kamstrup
• AMS reader: Pow-K
• M-bus adapter (if applicable):

Relevant firmware information:

• Version: 2.0.10
• MQTT: yes
• HAN GPIO: GPI12
• HAN baud and parity: 2400 8E1
• Temperature sensors NONE

[ArnieO]

Interesting error! We do not have many readers in Sweden yet, but quite a number in Denmark and Norway. So your feedback is valuable. Maybe a deviation on the data format used in Sweden? I double checked on my own Kamstrup now, and the accumulated value is correct.

Could you switch on Telnet debugging / verbose and copy back here the output you get (in command window on PC, write: telnet <IP address>)?

Are you sure parity you use is 8E1? Both in Norway and Denmark it must be set to 8N1.

[BjoernSelander]

Hi. The parity was 8N1. Sorry for specifing it wrong.

Here is a frame-dump from telnet for the 10sec message. (D) (readHanPort) Frame dump (228b): (D) 7E A0 E2 2B 21 13 23 9A E6 E7 00 0F 00 00 00 00 (D) 0C 07 E6 02 11 04 16 21 32 FF 80 00 00 02 19 0A (D) 0E 4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31 09 (D) 06 01 01 00 00 05 FF 0A 10 35 37 30 36 35 36 37 (D) 33 33 31 33 32 33 35 32 36 09 06 01 01 60 01 01 (D) FF 0A 12 36 38 34 31 31 33 31 42 4E 32 34 35 31 (D) 30 31 30 39 32 09 06 01 01 01 07 00 FF 06 00 00 (D) 0D AF 09 06 01 01 02 07 00 FF 06 00 00 00 00 09 (D) 06 01 01 03 07 00 FF 06 00 00 06 1A 09 06 01 01 (D) 04 07 00 FF 06 00 00 00 00 09 06 01 01 1F 07 00 (D) FF 06 00 00 02 45 09 06 01 01 33 07 00 FF 06 00 (D) 00 02 30 09 06 01 01 47 07 00 FF 06 00 00 01 BE (D) 09 06 01 01 20 07 00 FF 12 00 F3 09 06 01 01 34 (D) 07 00 FF 12 00 F2 09 06 01 01 48 07 00 FF 12 00 (D) F3 05 1D 7E (D) (readHanPort) Valid data, start at byte 29 (V) (AmsDataStorage) Time is: 1645133632 (V) (AmsDataStorage) It is only 1995 seconds since last update, ignoring

[ArnieO]

No problem for the parity, thank you for confirming.

Thank you for data dump, please be patient until @gskjold finds time to decode it.

[gskjold]

Interesting indeed, I wonder what could cause that. This looks like same as Norwegian Kamstrup data. Your debug does not contain the accumulated values, if you start logging just before top of an hour, you can catch the larger payload at xx:00:10 which has the full information and maybe we can spot anything different there.

[ArnieO]

To be exact, the longer "List 3" payload that contains accumulated values comes between shorter "List 2" payloads at xx:00:00 and xx:00:10.

[BjoernSelander]

Hi. Here is the long list (At least there are some more bytes).. Received 22:00:XX

(D) (readHanPort) Frame dump (302b): (D) 7E A1 2C 2B 21 13 FC 04 E6 E7 00 0F 00 00 00 00 (D) 0C 07 E6 02 12 05 16 00 23 FF 80 00 00 02 23 0A (D) 0E 4B 61 6D 73 74 72 75 70 5F 56 30 30 30 31 09 (D) 06 01 01 00 00 05 FF 0A 10 35 37 30 36 35 36 37 (D) 33 33 31 33 32 33 35 32 36 09 06 01 01 60 01 01 (D) FF 0A 12 36 38 34 31 31 33 31 42 4E 32 34 35 31 (D) 30 31 30 39 32 09 06 01 01 01 07 00 FF 06 00 00 (D) 08 DD 09 06 01 01 02 07 00 FF 06 00 00 00 00 09 (D) 06 01 01 03 07 00 FF 06 00 00 00 00 09 06 01 01 (D) 04 07 00 FF 06 00 00 01 90 09 06 01 01 1F 07 00 (D) FF 06 00 00 01 1F 09 06 01 01 33 07 00 FF 06 00 (D) 00 02 57 09 06 01 01 47 07 00 FF 06 00 00 00 6A (D) 09 06 01 01 20 07 00 FF 12 00 F1 09 06 01 01 34 (D) 07 00 FF 12 00 F0 09 06 01 01 48 07 00 FF 12 00 (D) F3 09 06 00 01 01 00 00 FF 09 0C 07 E6 02 12 05 (D) 16 00 23 FF 80 00 00 09 06 01 01 01 08 00 FF 06 (D) 01 E8 7F 4E 09 06 01 01 02 08 00 FF 06 00 00 00 (D) 00 09 06 01 01 03 08 00 FF 06 00 58 71 8B 09 06 (D) 01 01 04 08 00 FF 06 00 10 60 23 B8 1C 7E (D) (readHanPort) Valid data, start at byte 29 (V) (AmsDataStorage) Time is: 1645218037 (D) (AmsDataStorage) Last day update: 1645214437 (V) (AmsDataStorage) Clearing hour: 20 (D) (AmsDataStorage) Last month update: 1645138837 (I) (AmsDataStorage) Usage for hour 20: -31072 (I) (readHanPort) Saving day plot

There is some strange behavior in the daily consumption graph also, but I´ll guess it´s because of the error in accumulated energi sent every XX:00:XX (I don´t produce any energy)

[ArnieO]

Thank you! Looks strange, indeed! Should not happen. You get valid data. Looking forward to se the decoding of that (@gskjold ).

[gskjold]

Kamstrup gives me a headache.. It is the exact same format as Norwegian meter, but with different scaling on accumulated values, why...

In Norway it is scaled wh/10, so we divide it by 100 to get kwh. But apparently your data it is purely wh and should be divided by 1000. I see no real identifier I can use to detect it either. We need that inside guy from Kamstrup ;)

Maybe the meter type can be used to detect this? Kind of doubt it, but it reports as: 6841131BN245101092

[ArnieO]

This is not OK at all.

This meter is non-conformant to Kamstrup documentation, see bottom of page 3 here: https://koce1-kamstrup.ocecdn.oraclecloud.com/content/published/api/v1.1/assets/CONT7C375532814E46B7B899A32A9CD74052/native/58101493_GB.pdf?channelToken=ed241bbb18f444908a8fc9ed97ca5d5b

This should be fixed by firmware correction of your Kamstrup meter, @BjoernSelander . Which grid company are you with?

[risto-m]

Hi, For what its worth, i am in Sweden and i have also a Kamstrup energy meter (Kamstrup Omnipower) I am using Kamstrups own P1 interface (RJ12) thought that i seem to have HAN data!? i am using the pins according to P1 but i am using the HAN speed (2400baud and 8N1) and it works as intended for eight days now. I have FW 2.0.10 and ESP32 directly coupled to RX2 pin and inverted data checked in configuration (with a 5V to 3.3V divider) /Risto

[ArnieO]

Hi, For what its worth, i am in Sweden and i have also a Kamstrup energy meter (Kamstrup Omnipower) I am using Kamstrups own P1 interface (RJ12) thought that i seem to have HAN data!? i am using the pins according to P1 but i am using the HAN speed (2400baud and 8N1) and it works as intended for eight days now. I have FW 2.0.10 and ESP32 directly coupled to RX2 pin and inverted data checked in configuration (with a 5V to 3.3V divider) /Risto

Thank you for sharing! What a mess... The P1 interface should normally be associated with data at 115200 baud. I think we need to extend the overview on this page to cover Sweden. Situation in Sweden is a bit complex, as you have both HAN-NVE (2400 baud) and P1 interface (supposedly at 115200 baud) - and apparently (your case!) some "mixed race bastards". Maybe we need to index by grid company and meter manufacturer, as I assume each grid company has their own contract with for instance Kamstrup. Which grid company are you with?

EDIT: Corrected from 9600 to 115200 baud

[gskjold]

I think Kamstrup is the most mentioned meter in this repo. They sure bring some interesting issues to the table :popcorn:

[BjoernSelander]

Hi, For what its worth, i am in Sweden and i have also a Kamstrup energy meter (Kamstrup Omnipower) I am using Kamstrups own P1 interface (RJ12) thought that i seem to have HAN data!? i am using the pins according to P1 but i am using the HAN speed (2400baud and 8N1) and it works as intended for eight days now. I have FW 2.0.10 and ESP32 directly coupled to RX2 pin and inverted data checked in configuration (with a 5V to 3.3V divider) /Risto

Thank you, but i don’t think its the hardware. It’s probably the meter that sends the data in an other format as @gskjold mentions.

[BjoernSelander]

Hi, For what its worth, i am in Sweden and i have also a Kamstrup energy meter (Kamstrup Omnipower) I am using Kamstrups own P1 interface (RJ12) thought that i seem to have HAN data!? i am using the pins according to P1 but i am using the HAN speed (2400baud and 8N1) and it works as intended for eight days now. I have FW 2.0.10 and ESP32 directly coupled to RX2 pin and inverted data checked in configuration (with a 5V to 3.3V divider) /Risto

Thank you for sharing! What a mess... The P1 interface should normally be associated with data at 9600 baud. I think we need to extend the overview on this page to cover Sweden. Situation in Sweden is a bit complex, as you have both HAN-NVE (2400 baud) and P1 interface (supposedly at 9600 baud) - and apparently (your case!) some "mixed race bastards". Maybe we need to index by grid company and meter manufacturer, as I assume each grid company has their own contract with for instance Kamstrup. Which grid company are you with?

The grid company i Dala Energi (situated in the norrh of Dalarna County)

[gskjold]

I agree, the module in the module bay does not affect the data format, it only changes the interface. But it is really interesting that there are Kamstrup meters in Sweden with different output. You would think that this would be somewhat coordinated between grid companies.

[risto-m]

My grid company is Gävle Energi. and the meter was installed c:a march 2020. And i hade some contact with them before i ordered the interface module, because i was confused about which one to buy but did not get any real good answer, so i bought the P1 interface. Yes i agree that the hardware is not the problem for Björn, i looked inside the RJ12 interface and it only contained two optocouplers and some glue logic, I just wanted to chime in and comment on a working configuration.

[ArnieO]

I just wanted to chime in and comment on a working configuration.

Thank you @risto-m ! Are you using same parameters as @BjoernSelander on your P1 interface (2400/8N1)?

[risto-m]

This is my configuration:

[ArnieO]

This is my configuration:

Yup, this is the same; another "mixed race bastard"! The way I understand the Swedish "standard" for the RJ12 interface, the bit rate should be 115 200 (I will update to correct error in my earlier postings in this thread), interface according to IEC62056-21 Mode D. See for instance https://hanporten.se/svenska/protokollet/

What you and @BjoernSelander have are meters that seem to follow the NVE data protocol (IEC 62056-7-5), while having physical interface according to IEC62056-21 Mode D.

[risto-m]

The physical interface mixup is propably my fault! Because i was (stil are?) very confused about what interface to obtain, and did not get any usable info from the grid company i just asumed i would get the RJ12 (P1?) interface but the RJ45 (HAN?) interface would have been the right one? But anyway it works, it seems to only route the signal to different pin in the connector, and it seems to also ignore the datarequest pin (pin 2 on RJ12) it dont matter if i connect it to GND or 5V, it always sends data every 10sec.

[ArnieO]

The physical interface mixup is propably my fault!

💡 In fact - you might be right! Although I do not blame you at all.

I believe the RJ12/P1 adapters are meant to be used with meters following the "Swedish standard" protocol (IEC62056-21 Mode D). While the HAN-NVE (RJ45) adapters are meant to be used with meters following the NVE standard.

And the grid companies may lack the competence to properly guide you. But it is a positive discovery that the Kamstrup RJ12 module works with a meter set up for Kamstrup NVE protocol!

The RJ12 module is technically a better option, as you have much more power available for your device.

While the HAN-NVE module is a better option if you need a very long cable from the meter to an external reader. A farmer told me he has the meter in the farm building, and dug down a long cable to his house to have the reader there. RJ-12 module will most probably not work in such a case. But the HAN-NVE module will not work on meters running the "Swedish protocol" at 115 200 baud.

Note that this confusion is only possible on Kamstrup meters, as they manage the interface by a plug-in module.

[BjoernSelander]

Here are some info about the swedish standards that might be usful. Http://www.hanporten.se It’s in swedish but you are norwegians, right? So you should be able to read it.

I’ve fixed this bug myself in HA by creating a te mplate sensor wish devide the mqtt-status by ten. It’s ok for now but would anyway be interested in a real solution.

[ArnieO]

Yes, I linked to http://www.hanporten.se/ a bit higher up in this thread this morning. 😉

I recommend/propose that you to contact your grid company and inform them that your meter outputs the wrong format on the HAN-port (according to the HAN-module specifications, here and here), and ask if they can provide a solution. Either by replacing your meter or by requesting a firmware update from Kamstrup.

[e-bits]

Hi,

I think the same issue applies for Kamstrup Meters located in Switzerland. My grid provider is called EWS which basically is CKW. I wondered why my calculated costs in Home-Assistant are that high. Then I realized that the Meter Display and AMS is not providing the same output. Current usage in Watts or KiloWatts are correct and matches the Meter Display but total usage is wrong.

MeterDisplay = 3585kWh AMS = 35850.8kWh

I'm running v2.0.11 on a ESP32-Wroom.

This is my output from data.json:

{
  "im": 25097,
  "om": 0,
  "mf": 63,
  "i": 238,
  "e": 0,
  "ri": 0,
  "re": 202,
  "ic": 35850.8,
  "ec": 0.000,
  "ric": 17.140,
  "rec": 11670.645,
  "u1": 236.00,
  "u2": 234.00,
  "u3": 235.00,
  "i1": 0.04,
  "i2": 0.18,
  "i3": 1.51,
  "f": 0.00,
  "f1": 0.00,
  "f2": 0.00,
  "f3": 0.00,
  "v": 0.000,
  "r": -70,
  "t": -127.00,
  "u": 253635,
  "m": 233652,
  "em": 1,
  "hm": 1,
  "wm": 1,
  "mm": 0,
  "me": 0,
  "p": null,
  "mt": 3,
  "ds": 1,
  "c": 1647610147
}

And here are some photos and screenshot which are outlining my issue:

Can I do some additional tests or provide more details?

[ArnieO]

I think the same issue applies for Kamstrup Meters located in Switzerland.

Hi Remo, thank you for your feedback!

Due to several reports of this issue we have decided to introduce correction factors in a coming firmware version. In addition to your issue, it would also enable correct presentation of data from meters with current transformers (used on some large installations).

Not sure if @gskjod will have it ready for v2.1.0 (testing ongoing in another thread), but it will surely come when he is ready to implement it.

[gskjold]

I have added support for multipliers in latest beta firmware posted in #247 . You will find these in Config -> Meter -> Multipliers

[BjoernSelander]

@gskjold Nice that you add a multiplier. I have had it working for about a month now. Added a multiplier in HA where I collect the data and store it in the new Energy-tab. But it´s always better to correct the error at the source.

By the way, I´ve filed a ticket at my grid company, but I dont think they understood the problem. Have waited for a response for a while but I guess they don´t have the competence to understand and solve this kind of errors.

[e-bits]

I have added support for multipliers in latest beta firmware posted in #247 . You will find these in Config -> Meter -> Multipliers

@gskjold many thanks for providing this beta firmware. I tested it and set the Multiplier for Accumulated to 0.1 and it works as expected for my usecase here in Switzerland.