Introduction
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.
KNX
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).
TCP/IP
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.
RS-232
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.
Conclusion
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:
<MBusData> <SlaveInformation> <Id>67354592</Id> <Manufacturer>KAM</Manufacturer> ... </SlaveInformation> <DataRecord id="0"> ... </DataRecord> ... <DataRecord id="8"> <Function>Instantaneous value</Function> <StorageNumber>0</StorageNumber> <Unit>Flow temperature (1e-2 deg C)</Unit> <Value>1779</Value> <Timestamp>2016-03-27T13:52:04</Timestamp> </DataRecord> ... </MBusData>
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' ); }
References
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.
M-Bus Meter Data Collection by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
“Each module is set with a default M-Bus Physical Address of 0″
This is an easy problem to solve. It is common, and if I remember well is also M-Bus standard, new units to come with primary address 0 by default. But they have as secondary address their serial number which is written on them. The free software (with limitations) MBSheet from relay.de will solve this issue. You search using ” Search by Id” and you will get all the meters, disregarding their primary address (could have all sam address). After this you set each, one by one, using “set primary address using secondary address”. As such you can set all primary addresses with all meters already connected to the bus.
Hope it helps
Thanks Vladi. I was not aware of MBSheet (http://www.relay.de/en/produkte/software/mbsheet.html).
The Kamstrup Multical 302 Heat Meters came with pre-set Primary Addresses (the last 2 digits of their serial number) which I think is a good approach, even if that is not the M-Bus standard.
David
hello !
i have bought a cyble mbus module to put on my water meter. and i found the cyble do not start counting until it is configured..
you talk about “Cyble M-Bus Configuration Tool”..
i’m searching the web since 2 days without success..
have you this software ? can you send it to me ?
thank you so much for help.
Eric.
Hi Eric,
I got a copy of the software from the company that supplied the meters to my installer. I will contact you via email.
David
Hi David,
I have a problem similar to Eric. Some cyble M Bus ini my workplace is now unable to connect, I think it must be reconfigured, but the supplier can’t help. Can you send “cyble MBus config tool” to me?
Thank you for your help.
Eko
Hi,
I came across your blog whilst looking for info on EVSE and EV charging.
Blatant advert time…
Have you got the M-Bus metering sorted to your satisfaction now?
If the flaky / failed readings are still an issue – or others are looking to do metering – can I recommend either:
The Elvaco CMe2100 (a GSM modem, an M-Bus master suitable for 8 meters, and a little JVM that can read the meters according to a cron schedule, parse the M-Bus telegram into human-readable fields, then spaff a CSV at an endpoint of your choice via email, ftp, or http/https JSON post. (the latter is preferable!) They’re about £300 and you’re done in half an hour.
THe Elvaco CMe3100 (a little Linux box including an M-Bus master suitable for 32 meters, the same JVM that can read the meters according to a cron schedule, parse the M-Bus telegram into human-readable fields, then spaff a CSV at an endpoint of your choice, an SQLite DB for storing the reads and optionally making them available via a REST API, and webserver for configuring the lot via a GUI. £450ish with an 8-meter licence.
In the past we’ve used beaglebones running our own code and level converters for commercial submetering but this Elvaco kit was so good out of the box that we just just use these now.
In terms of metering:
Kamstrup 302 (disposable version that you can’t change battery on) or 403 (16 year battery that can be changed) are a very good choice.
Ditto the positive-displacement Aquadis+ water meters. Most would try flog you a naff single-jet unit that just doesn’t do anything useful at low flowrates.
Well chosen!
Diehl 774 / 775 also worth considering in the heat metering space and can sometimes be more cost effective in low volumes.
This article was very good inspiration to me and thanks to that I moved my Kamstrup 403 project to the point I get xml response from the command: mbus-serial-request-data -b 2400 /dev/ttyUSB0.
Would it be possible for you to share idea for the next steps how you did graph presentation of collected data? I try with openhabian on rasberry pi and Modbus Binding but with no success so far.
Best regards
Leszek
Hi Leszek,
Sounds like you’ve got the difficult part sorted. In summary, I use a Perl script to execute ‘mbus-serial-request-data’ on a ‘cron’ schedule (every minute) then I parse the XML to extract the values of interest and then I Publish those as MQTT messages, to a ‘mosquitto’ MQTT server. (Basically I use MQTT as a standard way of sharing parameter readings, whether they’re sourced from an API, from M-Bus or elsewhere.)
openHAB listens to the MQTT messages and I also have influxDB which logs every message to a database where I can generate graphs and dashboards using Grafana (although openHAB and similar tools can do dashboards too).
I’ve been meaning to publish my Perl scripts to github.com so I will do that in the next day or two and you’ll be able to see more detail of what I’ve done – at least for publishing M-Bus readings as MQTT messages.
Regards,
David
The Perl script I use is now published to GitHub at https://github.com/davidMbrooke/MQTT-Perl-Scripts/blob/master/mbus2mqtt.pl
You’ll see it’s very much customised for my set-up – the logic to extract the relevant fields from the XML responses for the different types of meter will all need adjusting – but the basic logic should hold good.
Thanks a lot David, I appriciate that and I will try to follow that concept in my case. Hopefuly I can manage to do that.
Leszek
Hallo David,
thank you for your blog / post, you help me a lot about m-bus reading. I buy PW3 from Relay and it work great.
I would be grateful if you could send me the configuration software for cyble, because i stuck at this point.
Greetings from Bosnia and Herzegovina
Hi,
I fell into the same trap and bought a Cyble M-Bus module that does not work because the module has to be configured first. Unfortunately I cannot find the necessary configuration tool anywhere. If I understand correctly, Eric had the same problem almost five years ago and it seems you could have helped out with a copy of the configuration tool. Is there a possibility that you also send me a copy? Thank you very much for your help.
Stefan
Hi Stefan,
Mail sent with a download link.
David
Hey David,
I have the same issue to find the configuration tool.
Could you provide me the link, also?
Greetings
Jan
Hy David,
I have the same issue to find the configuration tool…Just tbought an Itron Aquadis with CYBLE mbus and was naively expecting a programming manual etc…
Could you provide me the link, also?
Kind Regards
Patrick