MaxFlowDate_M (and other Date parameters) shown incorrectly "230,207.0 yy:mm:dd"

[Kugelfang666]

Did you read the instructions?

• [X] I have read the README.

The problem

Ever since I'm using this integration for a Kampstrump 402 all parameters read that are supposed to hold a date are not shown correctly in HA.

as is: "MaxFlowDate_M" holds "230,207.0 yy:mm:dd" as value

expected: 23-02-07 (or in a other date format that makes sense)

All other Parameters that are holding dates exhibit the identical issue

What version of this integration has the issue?

2.2.0

What version of Home Assistant Core has the issue?

latest

Home Assistant log

No response

Diagnostics

No response

Additional information

No response

[golles]

Well spotted, everything is considered as a number right now. I will fix it and parse them as date times soon.

[HAEdwin]

Hey Sander, noticed this also... just got my 403 installed yesterday (you might remember me from the MC66C) and found a bug in the Kamstrup. From what I've evaluated until now, all values including their unit (or explain) of measurement are received as data packages and have indeed to be transitioned sometimes. I made a pull request with first quick changes.

Then there is this incorrect unit of measurement for Tempdiff in K(elvin) which translates to celcius with temperatures below -200°C! Wonder how many developers have a workaround for that not informing Kamstrup.

Any idea if the Kamstrup Meter Protocol (KMP) is available anywhere? I read somewhere that they don't want to give the protocol details to private individuals. Most important is the Info-event parameter that will inform us of an nearly empty battery or other issue in the circuit. There will be some human logic in the protocol.

[golles]

Hi @HAEdwin

Your issue/question doesn't have much to do with the original issue, please create a new issue next time.

Then there is this incorrect unit of measurement for Tempdiff in K(elvin) which translates to celcius with temperatures below -200°C! Wonder how many developers have a workaround for that not informing Kamstrup.

According to the technical description document, the unit for tempdiff is K https://koce1-kamstrup.ocecdn.oraclecloud.com/content/published/api/v1.1/assets/CONT46E54F336D7047A7907749B26DD3576C/native/55121689_M1_EN.pdf?channelToken=ed241bbb18f444908a8fc9ed97ca5d5bpage page 2

The reason why K is correct, is defined in the SI Brochure: https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf/2d2b50bf-f2b4-9661-f402-5f9d66e4b507?version=1.11&t=1671101192839 page 133, quote:

The unit of Celsius temperature is the degree Celsius, symbol ○C, which is by definition equal in magnitude to the unit kelvin. A difference or interval of temperature may be expressed in kelvins or in degrees Celsius, the numerical value of the temperature difference being the same in either case. However, the numerical value of a Celsius temperature expressed in degrees Celsius is related to the numerical value of the thermodynamic temperature expressed in kelvins by the relation t/ ○C = T/K − 273.15

If you don't change the unit in HA, it should remain the correct value.

Any idea if the Kamstrup Meter Protocol (KMP) is available anywhere? I read somewhere that they don't want to give the protocol details to private individuals. Most important is the Info-event parameter that will inform us of an nearly empty battery or other issue in the circuit. There will be some human logic in the protocol.

AFAIK the protocol isn't available and only reverse-engineered by Poul and then shared all over the web, more info: https://github.com/golles/ha-kamstrup_403/tree/main/custom_components/kamstrup_403/pykamstrup

[golles]

@Kugelfang666 I've implemented the change in PR #75 would you be able to test these changes locally? The branch name is 70-maxflowdate_m-and-other-date-parameters-shown-incorrectly-2302070-yymmdd I'll also test it in the coming days, you can see some screenshots in the PR from my prod instance.

[Kugelfang666]

Thanks for the quick fix! I just tried the branch and can confirm its also working for me!

[golles]

This has just been released in 2.3.0