Kamstrup Multical 403 Stops Working During Hot Water Cycle (Interference?)

I’ve recently switched to an ASHP from a boiler and, as part of the installation, OpenEnergyMonitor level 3 heat pump monitoring has been fitted.

I’ve consistently had problems with the monitoring equipment, but I’ve managed to work through most of them (details at the end of this post). The only remaining issue seems to be that the heat meter, a Kamstrup Multical 403, consistently stops functioning properly during a hot water cycle.

The only thing I can think of is that there is some kind of interference issue when the 3-port valve is energised, because there seem to be no issues at all during space heating cycles. I’ve tried tidying the cables more diligently, and temporarily moving the mains wiring for the valve further away from the heat metering equipment, but I’m struggling with this one.

Here’s an example of a hot water cycle where the meter seems initially fine, and then drops out. This is very repeatable, and the same thing is happening every day.

Notice that the flow sensor drops out completely; and the temperature readings become very jagged, which I’m interpreting as the meter not updating the readings internally for lengthened periods of time. The electrical power input to the ASHP indicates that it is still running during these dropouts.

The same thing is happening during the afternoon cycle; again, every day.

For reference, here’s everything seemingly working properly during a space heating cycle.

I’ll try to remember to get some photos of the physical layout of the equipment this evening.

Has anyone else had similar problems and managed to solve them?

Additional info - getting everything to this stage

Initially I had far more issues. The USB M-Bus adapter and the USB RS485 adapter for the electricity meter would drop out, resulting in errors being logged by Emonhub. As an experiment, I switched from a Pi4B to a Pi3A+ and an external USB hub, which dramatically improved the reliability. Then cable tidying fixed the remaining occasional drop-outs of the M-Bus adapter.

I plan to switch to an M-Bus adapter hat for the Pi (https://www.packom.net/product/m-bus-master-hat-ds/), when it arrives, to avoid USB woes.

1 Like

Hi Ben - welcome to the forum.

One quick question: where is the flow meter fitted with respect to the 3-port valve? It sounds like it might be on the wrong side of it.

1 Like

I’ve had similar flow rate reporting with my Sharky during hot water runs.

The Sharky goes the other way and sends out crazy high numbers when it errors.

I think it’s due to placement and turbulence caused by the hot water run on a shorter circuit than the heating circuit.

You have to adhere to the instructions for placement, ie not near bends. See the Sharky thread for examples.

Can you take a photo of how your meter is placed/installed?

Does the Kamstrup show any errors during the DHW run? What flow does it report on the screen during this time?


Looks like your 403 is configured for “adaptive integration” mode.

It will be checking how quickly the flowrate changes. If the flowrate doesn’t change much it switches to a slower measurement cycle for temperature in order to extend batteery life on the meter.

I would hazard a guess that:

  1. You have air in your system and the higher flowrate during hot water production shoves this through the flow sensor causing it to cease functioning

  2. You have insufficient static pressure in the system and you’re seeing cavitation at higher flowrates that again cause the flow sensor to cease functioning

The meter will flag this as an “info code” in the m-bus telegram if you look.

From memory there needs to be a static pressure at the flow sensor outlet of AT LEAST 1 bar to avoid cavitation. The flow sensors are often fitted on the supply side of a system for this reason (pump pressure adds to the static system pressure in this scenario)

The Sharky 775s don’t give “crazy high” numbers when there are errors. They give NO numbers at all. The contents of the M-Bus telegram will change (“err-value” rather than “inst-value”) so your parser, if it is looking for the inst-value of energy, shouldn’t pick up any crazy numbers.


Thanks for the quick responses!

I’ll get some pictures and confirm measurements this evening regarding the location of the flow meter.

It’s installed on the primary 28mm flow from the ASHP. It’s installed in a vertical orientation, with the flow going in the upwards direction. I’d say there’s around 0.5m of straight run on either side of the meter, after which there are 90 degree solder bends. I’m confident it’s in the right place w.r.t. the 3-port valve (i.e. before the valve).

Looking at that Sharky thread, I’d only need 280mm straight run before the meter, and 140mm after the meter, which reasonably I’m confident I have.

Perhaps I just need more pressure though? The installer only filled to (and said to fill to) approx 1.25 bar, which I now realise is below the Kamstrup minimum of 1.5 bar. I’ve just checked the manual for the ASHP (Daikin Altherma 2 monoblock, EDLQ07CV3), which says to to fill to 2 bar. I’ll give this a go.


USB can be a real bugger at times!

I need to double check the raw numbers coming out of my local heatpump hat when i get home.
Perhaps the way emoncms handles the errors/figure coming out of the heat meter could be better?

1 Like

@EvaporatingTime that’s a nice location and whilst cavitation is possible it feels more likely for you to still have air in the system. Any high spots it can get trapped in withing the DHW circuit? (and once trapped/entrained by the high water veloity it just goes round and round and round) Auto air vents on these? Look at the physical meter when in this mode and see what info-codes are displayed?

@Zarch It’s a common issue with M-Bus parsing - many just look for “the Nth field” in a telegram or one labelled “energy” then call it good without checking if it’s an “inst-value” or a “err-value” etc.

1 Like

I filled the system up to 2 bar yesterday evening, and that seems to have sorted it! Hopefully it will stay working now, so I’m guessing that cavitation was indeed the issue here.

I also took some pictures of the cylinder cupboard, marking the flow in red and return in blue. The primary flow and flow meter are a bit hidden behind the return pipe.

A close up of the flow meter and length of straight pipe before the inlet.

Thanks everyone for your help on this.


Now that is how it should be insulated!


@Zarch - could this be your problem / solution?

Thanks Brian, i’ll look at what my pressure is.

1 Like

Seems I spoke too soon… Whilst the pressure increase did make an improvement, it’s since dropped out a couple more times over the past few days.

I’ll have to investigate further when I have time. I still like the cavitation hypothesis because I’m seeing good flow readings at the start of the DHW cycle, then some time into the cycle it’s dropping out completely, and I’ve read that cavitation increases as the temperature of the liquid increases.

I’m also reasoning that this extends to any tiny air bubbles in the flow, potentially causing them to expand and cause issues (I’m no expert on this). In the left graph above, there’s a bit of a “wobble” in the flow reading right at the start - I’m guessing this is likely air?

1 Like

I’d say air.

Air and dirt get entrained in the flow at certain pipe velocities and will move around the system.

They settle upwards when flowrate drops or stops. They can persist for an age I’d you’ve no way of flushing them out into radiators or purging from the DHW loop.

Cavitation is indeed a bigger issue at higher temperatures.

I’ll try running the automatic de-aeration cycle for a few more hours when I get a chance.

There are 2 high points in the system: top of the DHW cylinder coil (in pictures previously) and the top port of the volumiser in the loft. Both have automatic air vents.

I have a feeling that the arrangement of the filling loop could be causing issues though

Any air trapped there will get flushed back into the system if I need to top up the pressure. Seems overkill to add another automatic vent, or re-plumb it, so I guess I’ll crack the flexi joints loose and manually bleed them when filling is required.

AAV is well positioned and ought to eventually purge air in that DHW loop even if entrained. Assuming there aren’t high points elsewhere.

Flipping the fill loop to point down would perhaps have been nicer such that it fills “upwards”

Any luck with the Packom Pi Hat? Am toiling with getting it set up.
New to all of this.

Just seen your other thread. I’ll head over there and reply!

I have a new ASHP installation together with level 3 emonHP solution using the Kamstrup Multical 403 heat meter. This works well except when the ASHP switches to Domestic Hot Water (DHW) mode . After a few mins the flow readings go haywire - see picture

I am wondering whether this turbulent flow is the same as described in this thread?
I suspect the heat meter has been installed too close to the tap (it’s about 10cm away):

Should I ask the installer to move the heat meter?

Any thoughts/advice would be welcomed.

Here are a couple of other threads that discuss similar issues:
Kamstrup Multical 403 Erratic flow readings - Hardware / Heatpump - OpenEnergyMonitor Community
New emonHP install with strange readings - Hardware / Heatpump - OpenEnergyMonitor Community

In my case it eventually resolved itself, especially after space heating started to run more often as we went into Autumn so it was probably dissolved air that was being released at higher temperatures when doing DHW runs. Hasn’t been a problem since.