Kamstrup multical 403/MBus no teperature readings?

Emoncms
1

I’ve been trying to get my Kampstrup Multical 403 hooked up to my emonPi. I have some success, but I’m not getting all of the data out of it I need.

Physically I have two temperature probes attached to the Kamstrup 403. On the unit itself I can see sensible looking flow and return temps (well, they are labeled “t1” and “t2”, so interpretation depends on which way round they have been connected up).

After some battles, I now have some data coming out into emonCMS (I needed to update the software on the emonPi for it to work).

In the log, I can see messages such as:

2022-12-22 11:30:21,037 DEBUG    MBUS       Invalid MBUS data received 204 bytes 1026.1 ms
2022-12-22 11:30:21,047 DEBUG    MBUS       Decoded MBUS data: {"Energy": [29, "kWh"], "Volume": [348.82, "m3"], "Power": [0, "W"], "Power_Max": [-12100, "W"], "FlowRate": [0.0, "m3/h"], "FlowRate_Max": [2.121, "m3/h"], "Record20": [0, ""]}
2022-12-22 11:30:21,049 DEBUG    MBUS       24 NEW FRAME : 
2022-12-22 11:30:21,049 DEBUG    MBUS       24 Timestamp : 1671708620.010800
2022-12-22 11:30:21,050 DEBUG    MBUS       24 From Node : MBUS
2022-12-22 11:30:21,051 DEBUG    MBUS       24    Values : [29, 348.82, 0, -12100, 0, 2.121, 0]
2022-12-22 11:30:21,051 DEBUG    MBUS       24 Sent to channel(start)' : ToEmonCMS
2022-12-22 11:30:21,052 DEBUG    MBUS       24 Sent to channel(end)' : ToEmonCMS

It’s receiving some data, but not receiving any flow temperature data.

I’ve been trying to understand the EmonHubMBUSInterfacer.py source code to try and understand why not.

If I change the “type” in the configuration to “standard” rather than “kamstrup403” I seem to get more plausible information:

2022-12-22 11:59:11,038 DEBUG    MBUS       Invalid MBUS data received 204 bytes 1026.7 ms
2022-12-22 11:59:11,041 DEBUG    MBUS       Decoded MBUS data: {"Energy": [29, "kWh"], "Record2": [12328, ""], "Record3": [13274, ""], "Volume": [348.82, "m3"], "Volume2": [0.0, "m3"], "Volume3": [0.0, "m3"], "Ontime Hours": [289, "h"], "Ontime Hours_error": [201, "h"], "FlowT": [22.09, "C"], "ReturnT": [23.34, "C"], "DeltaT": [-1.25, "C"], "Power": [0, "W"], "Power_Max": [-12100, "W"], "FlowRate": [0.0, "m3/h"], "FlowRate_Max": [2.121, "m3/h"], "Record16": [0, ""], "DateTime": [752233506, ""], "Energy2": [0, "kWh"], "Record19": [0, ""], "Record20": [0, ""], "Volume4": [0.0, "m3"], "Volume5": [0.0, "m3"], "Volume6": [0.0, "m3"], "Power_Max2": [0, "W"], "FlowRate_Max2": [0.0, "m3/h"], "Record26": [10948, ""], "Record27": [6657, ""], "FabNo": [71271245, ""], "Record29": [2100101, ""], "Record30": [11851201, ""], "heat_calc": [-0.0, "W"]}
2022-12-22 11:59:11,041 DEBUG    MBUS       44 NEW FRAME : 
2022-12-22 11:59:11,041 DEBUG    MBUS       44 Timestamp : 1671710350.011856
2022-12-22 11:59:11,042 DEBUG    MBUS       44 From Node : MBUS
2022-12-22 11:59:11,042 DEBUG    MBUS       44    Values : [29, 12328, 13274, 348.82, 0, 0, 289, 201, 22.09, 23.34, -1.25, 0, -12100, 0, 2.121, 0, 752233506, 0, 0, 0, 0, 0, 0, 0, 0, 10948, 6657, 71271245, 2100101, 11851201, 0]
2022-12-22 11:59:11,042 DEBUG    MBUS       44 Sent to channel(start)' : ToEmonCMS
2022-12-22 11:59:11,043 DEBUG    MBUS       44 Sent to channel(end)' : ToEmonCMS

FlowT and ReturnT there look plausible (albeit the wrong way round).

I’m going to run it like this and see whether the values look plausible. Heat pump is not currently on, so flow rate would be expected to be zero. No ideal whether flow rate max is plausible. The PowerMax is negative presumably because the temperature sensors are the wrong way round, so I’ll probably require those the other way round to make the numbers better.

So I suppose my question is why there is a special setting for kamstrup multical 403 which appears to remove some of the data fields, and is using “standard” a sensible thing to do?

2

Hello Tom, sounds like you are almost there!

Yes the kamstrup403 type only returns a subset of all the values - though it seems that some 403’s have different content to others and so it may be that it’s best to revert to the standard type. This is something @glyn.hudson found yesterday I think when setting up a couple of systems for a customer.

Like you say, yes it would be a good idea to swap those temperature sensors around, you will get some more sensible results that way. 2.1 m3/hr ot 35 L/min is definetly feasible. What’s the max kW heat output of your heat pump? A deltaT of 5K at 35 L/min is about 12kW

3

I believe it’s a 12KW unit.
I seem to be getting sensible output at the moment:

image
image1043×701 125 KB

I’ve tried and failed to make sense of the kampstrup mbus datagram documentation. The mbus comms module is described as configurable, but so far I’ve been unable to work out how you configure it. I wondered whether I needed to configure the comms module at all before I used it, whether emonCMS made assumptions about the way in which it was configured. I was trying to correlate what I could see in the kamstrup documentation with the python source code, but the numbers don’t match, so I suspect I’m comparing apples with oranges. The data that’s coming out seems plausible though, including for the flow and return temps (and the delta temp). They seem to match what the unit itself reports for the temperatures.

So I think I’ve got this connected up and reading correctly now. The main stumbling block I had to begin with was that my emonPi software was something like July 2021. On my laptop screen the “admin” menu item in the emonCms software is completely hidden as it’s off the bottom of the menu. Once I worked that out and zoomed the browser out a bit I managed to update the software and it all started working.

2 Likes
4

Hi @tomq42, just stumbled across your post after finally getting my Kamstrup 403 installed today and I was initially missing the flow/return temp values. They just magically appeared in between me initally looking and reading your post! I presume you managed to sort your data out.

Two extra data feeds appeared also, delta t (self explanatory) and heat calc (not sure what this one is?).

I also had the issue with an outdated emonpi image (mine was from 2019!) and having failed to get the pi to detect the mbus usb adapter I too upgraded to the 2022 image which immediately sorted that issue.

5

The Kamstrup meters are SERIOUSLY customisable meters in terms of how they measure and what they report.

In an ideal world these would be ordered an official distributor (in the UK this is SAV Systems down in Woking or UK Metering up in Nottingham) with a known meter coding / M-Bus module coding.

The config you’ll get on eBay and from unofficial distributors (resellers of SAV systems / UK Metering or grey importers of random stock from whichever random EU distributor is prepared to risk their distribution agreement this week by selling to a reseller in the UK - Kamstrup really don’t like this) is a bit of a gamble.

There is also a known defect with the wired M-Bus modules shipped with some recent 403/603 meters. In theory you need special software to change the content of the M-Bus module telegram. In practice some meters are flipping the content of their M-Bus module randomly - we have dozens on district heating schemes that have decided all by themselves not to bother reporting flowrate. If you see this kind of behaviour don’t assume it’s a fault with emoncms!

We have had a support ticket open on this since the start of September. It looks like they’re all out of fudges to give - Kamstrup have yet to acknowledge the defect let alone offer an explanation or fix. That isn’t unusual for Kamstrup once they’ve made the sale and got their money.

The meter itself works absolutely fine though; it is recording energy correctly; and displaying the data locally. We think it’s an issue with the M-Bus module rather than the meter itself.

2 Likes