Resolution of Energy register

[SkyumP]

Hi

the information I read from the energy register is in KWh with no decimals value.

This is not a very good resolution when energy consumption is around 5-20 KWh in the summer period.

In HA it gives this result in the energy dashboard:

But when I look at my suppliers statistics they have better resolution in my energy data:

Therefore I assume that the data is available in the Multical but not stored in the Energy register…

Any ideas which register (if any) would store more detailed energy data?

[htvekov]

EDIT: After some hours of testing it seems that the last 2 digits in my energy register doesn't have any significance and apparently are somewhat random (usually 00, 01 or 99). So the proposed solution below simply won't work IRL. Perhaps the digits actually have significance with your MultiCal 403 meter, as your register reports in kWh and not in MWh as my MultiCal 602 meter ?

My Multical 602 delivers the energy register in MWh with 5 decimals precision. My initial, default ESPHome config returned the sensor value with 3 decimals -> 1 kWh resolution.

If you want better sensor resolution in HA, you need to change the number of decimals in ESPHome to 4 ( 0.1 kWh resolution ) or even 5 ( 0.01 kWh resolution ). Assuming that your Multical energy meter actually provides that kind of resolution ?

# Multical Custom Sensors
- name: "Multical Energy"
  platform: template
  id: m_energy
  icon: "mdi:lightning-bolt"
  unit_of_measurement: MWh
  accuracy_decimals: 5
  state_class: "total_increasing"
  device_class: "energy"

10:05:42 | [D] | [sensor:093] | 'Multical Energy': Sending state 157.09401 MWh with 5 decimals of accuracy

[htvekov]

I've done some testing with the high resolution energy register (0x009B = 155 with 10mWh resolution). Seems to work (correlates with the 'normal' energy register) and reports a total increasing value. This could be used as base for a calculated hourly delta value. And the delta value could be used together with the low resolution energy register to calculate a more precise consumption by the hour.

This could be done in the code but should also be doable in ESPHome yaml.

Not sure if it's just pure luck that I actually can read the register ? According to documentation the register should only be enabled when the device is put into calibration mode.

I've now calculated my delta and will over some time (72 hours or so) compare the calculated value with the 'normal' register value. I have an idea that the high resolution register will be reset, when/if I remove the optical head for an unknown period of time (30 minutes perhaps ?). I'll test that later as well.

[htvekov]

Use of high resolution register on the Multical 602 seems to be working ok. Got a fine granular consumption graph in HA since last night. I've managed to keep the needed changes in the ESPHome yaml. Except for the change in the kmp.h and multical402.h regarding the extra register to be read.

I'll continue with my tests for a couple of days. Will also try and figure out what action actually resets the highres energy register ? I've removed the optical IR head for some 45 min. without any reset. Perhaps more time is needed ?

When done testing I'll revise my fork with the needed changes for utilizing the highres register.

[SkyumP]

The response I get in ESPHome when asking for the 009B looks like this:

I think that it replies but without data if I understand the data correctly.

Perhaps I am unfortunate that mine doesn’t respond to enquiry on that register. It just annoys me since data is there and it is being send to the company 🙂

Perhaps I should try your code when you’re done and see if I get a different result. I’m an absolute beginner at this 😅

[SkyumP]

Are you sure that hires is being reset?

couldn’t it just be same exact data as energy but just “hires”. And then by default it is disabled to discourage constant polling which would drain the battery if not connected to mains power?

[htvekov]

Are you sure that hires is being reset?

Yep quite sure. My HiRes register is at 271,21 kWh where my 'normal' energy register is at 150+ MWh (Energy Highres sensor below is the calculated highres sensor) So I guess the highres register has been reset some 6-10 day ago where I also fiddled around with the IR sensor and had it detached for a longer period of time

[htvekov]

The response I get in ESPHome when asking for the 009B looks like this

Doesn't look promising I'm afraid...

I get the highres register response without doing anything else than you're doing:

>>> 80:3F:10:01:00:9B:77:52:0D
21:26:12    [D] [sensor:093]    
'Energy delta': Sending state 0.27121 MWh with 5 decimals of accuracy
<<< 40:3F:10:00:9B:01:04:41:00:29:62:31:A0:EC:0D

According to the datasheet I shouldn't be able to readout the highres registers without putting the meter in verification mode. But apparently it works. At least here on my Multical 602

[htvekov]

Forgot to ask earlier.

According to the datasheet for the Multical 403, you should actually have one significant decimal in your 'normal' kWh register value. That would give you a 0.1 kWh resolution value. Have you checked that ?

[htvekov]

The response I get in ESPHome when asking for the 009B looks like this

You also get a 'no reply' for your 0x0060 register request, jst before you request the 0x009B register value. What happens to the 0x009B request if you remove the 'no reply' 0x0060 request ?

[SkyumP]

0x0060 was added when I was randomly searching for a register with better resolution.

I have now tried to remove 0x0060 but it doesn’t change the reply on register 0x009B unfortunately.

[SkyumP]

I don’t get any decimals in my reply:

Perhaps there are different configurations in the meters.

[htvekov]

I have now tried to remove 0x0060 but it doesn’t change the reply on register 0x009B unfortunately.

I was worth a shot...

[htvekov]

I don’t get any decimals in my reply

Clearly not. 00:00:0A:9A = 2714 decimal. Four bytes unsigned integer. Haven't got a clue in what register your Multical 403 stores the energy consumption with decimals ?

[htvekov]

EDIT: I've added an additional yearly average cooling sensor to the yaml config in my fork. Some district heating distributors have introduced penalty tariffs for customers not able to sufficiently cool the return water. My local distributor has a defined YEARLY average cooling at min. 30 degrees C to be eligible for the best tariff.

I've updated my fork for anyone that want to test the HiRes energy register on their Multical 402/403/602 devices 🙂

Confirmed working here on a Multical 602 device

[htvekov]

Perhaps there are different configurations in the meters.

Do you get a reply with content for register 223 dec. = 0x00DF (High Resolution Volume register) ? If your supplier gets the data, it must be stored somewhere. If the HiRes data is not available in a direct register, then hourly data must be stored in the log entries and read from there. Can't find any online examples though on how to read specific log entries and how they are organized

[htvekov]

I've googled a bit and finally came up with something new. Try and read register 266 dec = 0x010A According to my clip, this should be the E1 HiRes register for Multical 403 meters. UOM should be Wh.

Reference site where this HiRes register is also mentioned for Multical 403 meters

[SkyumP]

This looks like the jackpot!

Register 0x010A is read into my hi-res entity:

My unit of measurement is wrong (kWh and not Wh) but it definitely looks like energy register with 3 more decimals precision.

Thank you for spending time on hunting this. I did a fair deal of googling but the description of the kmp protocols I found was for the 602 and they don’t mention 0x010A.

[htvekov]

EDIT: DONE - Fork revised @SkyumP I would appreciate if you would test my fork so I know it's working as expected 🙂

You're welcome 😎

I'll revise my fork as well to cope with the 'special' HiRes handling for the Multical 602 as well as regular HiRes register read for the 403 meter. Almost done...

[bobvandevijver]

@htvekov I'm using your fork now for a 603 model reader (using the 602 setting), but it seems the hires register only returns plain zero. I did change the unit of measurement to GJ by the way.

Anything I might be missing?

[htvekov]

@htvekov I'm using your fork now for a 603 model reader (using the 602 setting), but it seems the hires register only returns plain zero. I did change the unit of measurement to GJ by the way.

Anything I might be missing?

@bobvandevijver Not really. Unfortunately public register information for some models are scarse or non existing. So it's a bit trial and error I'm afraid.

I guess there's a fair chance that the 603 share HiRes register with the 403 model as both are latest version in their respective meter series. Try and configure with the 403 model settings instead. This will expose the 403 HiRes register to HA and hide the 'special' 602 HiRes register.

[bobvandevijver]

It indeed seems to be in the 403 equivalent register! Even though it is in MWh while my meter is configured to show GJ, it seems to be completely correct when converted. It does have 5 decimals instead of what you have for the register, so I've adjusted for that.

See my fork for the changes I have made for my 603 model in the Netherlands, using GJ as unit: https://github.com/bobvandevijver/esphome_multical402

[cenobitedk]

Hi @SkyumP @htvekov and @bobvandevijver

I wish I had seen this thread earlier, for some reason I get absolutely no notifications from this repo, except the issues I have participated in. Sorry I haven't been helpful, but thanks you @htvekov for really helping out here!

So, just to add my 2 cents:

• The 402, 602, x02 seem the share the same hardware generation, and thus the same registers. Same applies to 403, 603 and x03. The is in line with my findings.
• Finding the register ID's is not easy, as @htvekov mentions the public information is really sparse. However the 402 technical documentation have this, which should apply to 602 as well:

Actually, here's the complete list for the 402 model:

[cenobitedk]

@htvekov @bobvandevijver Since you already have forks, I wanted to direct your attention to this PR: https://github.com/esphome/esphome/pull/4200

It's not my PR but by @cfeenstra1024. This going into the official esphome release, but I believe the component could be improved with your contributions to support a wider range of hardware models in regards to register ID's.

[htvekov]

Hi' @cenobitedk

Sorry about the late reply. Just added a comment (issue) to get @cfeenstra1024 attention 🙂

https://github.com/cfeenstra1024/kamstrup-multical-hardware/issues/1