M-Bus Meter Data Collection


I will be installing a number of meters to monitor different aspects of resource usage:

  • Water Meters
    • The mains water supply is metered on Snelsmoor Lane, which is 600m from the house. That’s a long length of pipe and any small leaks would not be immediately obvious so I want another water meter to compare with the main meter, so I can investigate any discrepancies. The AECB “Good Practice” Water Standards also call for a meter inside the building, in a convenient-to-read location.
    • In a Passivhaus, it’s common to use more energy for hot water than for space heating, so I want to monitor the hot water usage. There will therefore be a separate meter tracking the volume of hot water used (on the cold feed to the hot water cylinder). This is also specified in the enhanced AECB “Best Practice” Water Standards.
    • One of the open questions is whether it would be worthwhile to install a rainwater harvesting system in the future, and one factor which influences that decision is the proportion of water that would be supplied from such a system. There is a separate supply pipe coming into the house for (potential future) harvested rainwater, so this will bypass the mains water sub-meter and hence needs its own meter in order to monitor total consumption anyway. The AECB “Good Practice” Water Standards call for a sub-meter on the outside tap(s), and those will be fed from the “rainwater” supply.
      • This meter won’t differentiate water usage via the outside taps from water usage for the internal fittings connected to the “rainwater” supply (WC cisterns and washing machine) but that’s not too much of a compromise. I could always add a fourth water meter later.
  • Heat Meters
    • I’m interested in monitoring the real-world performance of the Ground Source Heat Pump. While the NIBE F1145 monitors a lot of temperature data it doesn’t itself monitor water flow and heat output, so an external meter is required to do that. Since the GSHP unit has separate pipes for the heating flow and the hot water flow, separate meters are required on each (and it’s good to monitor those outputs independently anyway).

I don’t really want to have to keep going around reading the meters and recording the usage manually so I want some way to collect the data automatically. For simple water meters it’s customary to use a basic pulse-counting sensor and there are various options for collecting readings from those, but for the heat meters where there are many different parameters being monitored (flow rate, flow temperature, return temperature. heat transfer etc.)  something more sophisticated is required. I did some research a while back and settled on using Meter-Bus (usually abbreviated to M-Bus) to link the meters into a data collection system.

The meters act as M-Bus “slaves” and they need to be connected to an M-Bus “master” which supplies them with power and presents the M-Bus via a more standard computer interface. Then it’s a question of finding some software which will be able to interrogate the meters (via the Master) on a regular basis to collect the readings.


Product Selection – M-Bus Meters

For the water meters, I have specified Itron Aquadis+ meters with a Cyble M-Bus module on the basis that:

  • I want meters which will accurately measure low volumes of water usage, which means they need to have a high accuracy class (C or D)
  • Two of the meters are likely to be installed in a vertical orientation, which tends to cause problems for “turbine” type meters
  • The local water company (Severn Trent Water) uses Itron meters with Cyble modules for their radio-readable meters, which is something of an endorsement of their reliability and accuracy

For the heat meters, I have bought two Kamstrup Multical 302 meters, on the basis that:

  • Kamstrup seem to be the leading manufacturer of heat meters, so their devices are relatively common (and hence well-tested)
  • The Multical 302 is the simplest and cheapest model in their range, but adequate for my purposes
  • The Multical 302 won the Red Dot Product Design Award – not necessarily an indication that it is perfect but it’s generally a good indication of a solid design
  • The good people at OpenEnergyMonitor.org have had success reading a Kamstrup Multical 402 with a simple M-Bus Master circuit, and the 302 will (presumably) use similar M-Bus interface logic


Product Selection – M-Bus Master

There’s quite a large choice of M-Bus Master devices which power the meters and convert the M-Bus protocol to something more standard. The main problem with most of them is the ridiculous price – hundreds or even thousands of GBP.

It’s best to consider the options in terms of the interface technology they convert the M-Bus to.


Initially I thought I would use a KNX-to-M-Bus gateway, since I’m using KNX elsewhere in the house. There are some KNX gateways available, such as this one from arcus-eds, but they only support a maximum of 3 M-Bus devices – so I’d need at least two – and they’re not cheap (around £170 + VAT). Over time I’ve gone off the idea of using KNX for this – KNX is great for controlling devices based on events and simple rules (e.g. turn on the lights when motion is detected and it’s dark outside) – but it’s difficult to imagine needing to react to the meter data (at least not in real time).


There are various M-Bus gateways which present an “Ethernet” or TCP/IP interface. Under the covers these all seem to go via RS-232, and connecting via TCP/IP seems to be more of a commercial approach (= expensive) so I’m more inclined to build my own RS-232 to TCP/IP converter using an Arduino or Raspberry Pi, or to use one of the Lantronix RS-232 to TCP/IP device servers I already own.


Most of the available M-Bus Master devices provide an RS-232 interface. The leading manufacturers seem to be:

  • Relay who are specifically mentioned on the OpenMuc jMBus page and
  • ADFweb who offer a wide range of devices, including TCP/IP Masters
  • Solvimus who make a neat unit in a single-unit-width DIN rail module with a D-Sub 9 connector
  • TECHBASE who get repeated mentions for having sensible prices, notably for their mBus 10 (around €70)

Most of the Master devices are available in different variants depending on how many meters are going to be connected – typical break-points being 3, 10, 20 and 60.


The best option for a new purchase appears to be the TECHBASE mBus 10 which has an RS-232 interface.

The home-brew approach using the circuit documented on the OpenEnergyMonitor thread looks quite appealing but is predicted to max out when handling 3 meters. The update by Caver_Mike on Mon, 25/01/2016 – 17:04 might be interesting if that bears fruit within the next few months.

Update 2015-03-15: I managed to pick up a used Relay PW20 for 39 GBP from eBay. (The German word for Level Converter is PegelWandler, hence the PW.) This has an RS-232 interface and will support up to 20 meters. Initially had some problems getting it to respond over an RS-232 connection (user error, most likely) but it’s working fine using an FTDI USB to RS-232 cable connected to a Raspberry Pi.


Product Selection – M-Bus Software

I’m a big fan of Open Source software so I always look for a good Open Source solution in preference to commercial, proprietary options.

Most other people collecting meter data from M-Bus devices seem to use the Open Source libmbus library from Raditex Control AB. In particular, that is what is being used for OpenEnergyMonitor so I’m going to plan on using that.

(Another option would be jMBus, part of the OpenMuc suite of smart metering software tools. The J is for Java, since the OpenMuc framework is written in the Java language.)

Using libmbus

The libmbus software is easy enough to compile and install on Linux. It wouldn’t be that difficult to call the C functions directly from another program but it’s too easy to just use the supplied mbus-serial-request-data utility, which generates an XML data stream. The command to do that is something like this (one of my meters has Primary M-Bus Address 92; the Kamstrup meters use the last two digits of the serial number as the M-Bus Address):

$ mbus-serial-request-data -b 2400 /dev/ttyUSB0 92 > meter92.xml

The generated XML has a fairly simple structure:



    <DataRecord id="0">


    <DataRecord id="8">
        <Function>Instantaneous value</Function>
        <Unit>Flow temperature (1e-2 deg C)</Unit>



All of the DataRecord entries have the same sub-components (Function, Unit, Value etc.)

My current plan is to extract these using a Perl script based on the XML::LibXML module. Seems to work OK from a quick test:

use XML::LibXML;

my $dom = XML::LibXML->load_xml( location => 'meter92.xml' );
my $DataRecords = $dom->findnodes( '/MBusData/DataRecord' );
foreach my $DataRecord ( $DataRecords->get_nodelist ) {
    my $Unit = $DataRecord->findnodes( './Unit' );
    my $Value = $DataRecord->findnodes( './Value' );



My thinking was heavily influenced by this thread on OpenEnergyMonitor.org which includes pointers to the TECHBASE RS-232 Master.

See also this Domotiga M-Bus page for some hints on getting libmbus working.


Update 2017-05-21

Note that many of the M-Bus meter modules require the use of specific software to initially commission the units – especially where the M-Bus communication aspects are not physically integrated with the rest of the meter:

  • To set a unique M-Bus Primary Address
  • To allow the current meter reading to be set within the module
  • To associate the M-Bus module with a particular meter serial number (optional, but useful for audit purposes)

It would be wise to ensure you have access to any necessary configuration software before deciding on a particular brand and model of meter, since without the configuration it’s difficult / impossible to remotely read them using M-Bus.

My experience has been as follows:

  • The Kamstrup Multical meter “just worked” with no commissioning – but then these are fully-integrated units.
    • The default M-Bus Primary Address is the last 2 digits of the meter serial number
  • The Relay PadPuls M1 (S0 to M-Bus Converter) module required the use of the Relay MBCONF software which is a free download from the Relay website (http://www.relay.de/en/produkte/software/mbconf.html) and which posed no particular problems.
  • The Itron Cyble M-Bus module required the use of Itron software which proved difficult to source.
    • Each module is set with a default M-Bus Physical Address of 0, so new modules need to be connected to the bus and commissioned one-by-one otherwise you can’t tell which one is which (and the comms will clash with each other)
    • The Cyble technology uses the Actaris brand name and the M-Bus manufacturer code shows up as ACW
    • The Itron documentation mentions their “M-Bus Field Tool” but there’s also the (older?) Cyble M-Bus Configuration Tool (CMCT) which is what I used thanks to good support from MWA Technology

My recommendation is for the person commissioning the M-Bus meter reading system to source the meters directly from metering specialists rather than through intermediaries who aren’t likely to understand the technology.

CC BY-SA 4.0 M-Bus Meter Data Collection by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Leave a Reply

Your email address will not be published. Required fields are marked *