Category Archives: Plot

Posts relating to the building plot

M-Bus Water Meter Readings

Posted on by
Reply

In addition to the usual supply meters, there are a set of sub-meters in the house to report on particular aspects of resource consumption:

  • Water Meters, to assess how the water usage is broken down (e.g. hot water versus cold water)
    • One on the incoming cold water main
    • One on the separate incoming cold main which supplies the WCs, washing machine and outside taps and might, in future, be connected to a rainwater harvesting system
    • One on the cold supply pipe to the domestic hot water cylinder
      • This measures hot water usage based on the cold water used to top-up the cylinder as the hot water is used (it is generally better to meter  cold water than hot water)
      • This water also flows through the “incoming cold water main” meter so needs to be subtracted from that to calculate the cold water consumption
  • Heat Meters, to enable the real-world Coefficient of Performance of the Ground Source Heat Pump to be measured
    • One on the Central Heating output from the GSHP
    • One on the Water Heating output from the GSHP (likely to be a lower CoP because of the higher temperatures required)
  • Electricity Meters, to assess the consumption of some high-usage appliances

While it’s perfectly possible to read these meters manually (which is what I have been doing, on the first day of every month) the plan was always to read them automatically and to log the usage on a much more frequent basis. In line with my policy of using non-proprietary standards with good Open Source software support I settled on using the Meter-Bus standard (usually abbreviated to M-Bus, not to be confused with Modbus) to do this and hence specified / purchased meters with M-Bus interfaces.

(Actually, most of the Electricity meters don’t have M-Bus interfaces since those only seem to be available on the higher-capacity meters – 80A or so – and they attract a very high price premium. For the low-current sub-meters I used small DIN-Rail mounting meters with S0 pulse outputs rather than M-Bus interfaces, on the basis that it was better to have a simple meter than no meter at all.)

I cover a lot of the technical aspects of M-Bus on my M-Bus Meter Data Collection Page so see that for more details. The event that prompted this Post is that I’ve just got the water meter data collection working. It took me an embarrassingly long time to spot that the Itron Aquadis water meters were initially supplied with Pulse-Counting Cyble modules rather than M-Bus Cyble modules and once that was corrected it took a while to get the right version of the software needed to configure those. Kudos to the team at MWA Technology in Birmingham for helping me out (and no thanks to Itron for being thoroughly unhelpful – they only seem to want to deal with their big distributors).

I’ve found the best way to talk to an M-Bus meter from Linux is using the libmbus software. Basically this provides two data access mechanisms:

  • Using the generic mbus-serial-request-data utility to dump out all the data from a meter to an XML data string
  • Using the libmbus C API functions directly in your own code to grab the relevant subset of the data

I briefly toyed with the idea of writing a Perl module to map the C API to Perl so I could call it directly from a Perl script and then I wrote a simple C program to grab a limited set of data using the C API. However, in the end, I decided it was better to go down the XML route and to parse the full XML output string to extract the necessary data fields. I’ve written a Perl script which runs continuously (on the Raspberry Pi connected via an RS-232 interface to the M-Bus protocol converter) and extracts the data from all the M-Bus meters every few minutes. It then publishes the readings as messages using MQTT from where they follow the same route of logging and graphing used for other monitoring (Telegraf -> InfluxDB -> Grafana).

Some observations:

  • The request to read the M-Bus data seems to fail on a fairly regular basis (10-20% of the time) so the script needs to check for that and re-run the query until a response is received from each meter
  • The water meters report usage units of whole litres only (listed as milli cubic metres in the M-Bus response) which seems like quite a”chunky” response compared to some of the other meter readings
  • I found it was best to subtract the hot water reading from the cold water reading within the script and to create a further virtual meter for the difference (i.e. the actual cold water consumption)
  • I’m still working on how often to grab the data (currently every 2 minutes) and how best to present it (currently graphed as a “derivative” value of litres / minute)

An example of the full XML response from one of the Itron Aquadis water meters with an M-Bus Cyble communications module installed is shown below. Only the block highlighted in bold is really of interest (and actually it’s only the Value of 20312 which changes – that’s the same as displayed on the meter readout).

<?xml version="1.0" encoding="ISO-8859-1"?>
<MBusData>

 <SlaveInformation>
     <Id>17003877</Id>
     <Manufacturer>ACW</Manufacturer>
     <Version>20</Version>
     <ProductName>Itron CYBLE M-Bus 1.4</ProductName>
     <Medium>Water</Medium>
     <AccessNumber>23</AccessNumber>
     <Status>00</Status>
     <Signature>0000</Signature>
 </SlaveInformation>

 <DataRecord id="0">
     <Function>Instantaneous value</Function>
     <StorageNumber>0</StorageNumber>
     <Unit>Fabrication number</Unit>
     <Value>17003877</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="1">
     <Function>Instantaneous value</Function>
     <StorageNumber>0</StorageNumber>
     <Unit>cust. ID</Unit>
     <Value>0A        </Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="2">
     <Function>Instantaneous value</Function>
     <StorageNumber>0</StorageNumber>
     <Unit>Time Point (time &amp; date)</Unit>
     <Value>2017-06-30T09:02:00</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="3">
     <Function>Instantaneous value</Function>
     <StorageNumber>0</StorageNumber>
     <Unit>bat. time</Unit>
     <Value>5352</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="4">
     <Function>Instantaneous value</Function>
     <StorageNumber>0</StorageNumber>
     <Unit>Volume (m m^3)</Unit>
     <Value>20312</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="5">
     <Function>Instantaneous value</Function>
     <StorageNumber>0</StorageNumber>
     <Unit>Volume (m m^3)</Unit>
     <Value>0</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="6">
     <Function>Instantaneous value</Function>
     <StorageNumber>1</StorageNumber>
     <Unit>Volume (m m^3)</Unit>
     <Value>0</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

 <DataRecord id="7">
     <Function>Manufacturer specific</Function>
     <Value>00 01 1F</Value>
     <Timestamp>2017-06-30T08:03:19</Timestamp>
 </DataRecord>

</MBusData>

Mains Supply Voltage Adjusted

Posted on by
Reply

Whenever anyone has checked the mains supply voltage at the property it’s been higher than the expected 240V (and hence much higher than the nominal 230 V). While this isn’t a major problem in itself, the commissioning of the Solar PV installation (and its real-time monitoring) highlighted just how high the voltage can get and introduced the possibility of the Solar PV inverter tripping offline if the voltage gets too high.

Carbon Legacy (who installed the Solar PV system) were seeing the monitoring data from the SolarEdge inverter reporting up to 257 V and contacted Western Power Distribution (the local electricity Distribution Network Operator, DNO) to ask for the voltage to be adjusted and that work was completed today.

I’ve been consistently impressed by the team from Western Power Distribution and today was no different. Everyone involved has always been thoroughly professional and completely reasonable about the work to be done and the fees involved. Today’s work was free.

For those with a more technical interest in the subject, read on…

The electricity supply to the property comes from overhead 11 kV distribution lines via a dedicated, single-phase, pole-mounted transformer which reduces the voltage down to a nominal 230 V. The resistance of the cables causes a voltage drop on both the high- and low-voltage lines, with the result that the transformer is expected to see a bit less than 11 kV on the HV side and needs to deliver a bit more than 230 V on the LV side (to compensate for the voltage drop on the cables to the house). The exact details depend on the length and resistance of the two sets of cables, which in turn depends on the placement of the transformer within the distribution network and on the cable run from the transformer to the house. Due to this variability most transformers have a handful of different settings to switch in slightly different numbers of turns of transformer coils to change the ratios between the input and output voltages. In the case of “my” transformer (a 25 kVA Brentford Electric model dating from 1990) there’s a rotary switch with 5 settings ranging from -5% to +5% and it had been on the middle setting. The setting can only be changed with the transformer isolated.

In reality it’s all a bit more complex since the voltage drop varies with current (V = I x R and all that) so the actual voltages float up and down depending on the load on the network.  When consumption is high (e.g. 10 kW coming into the house) the voltage drop will be high – especially if other properties are also putting a high load on the network and tending to reduce the 11 kV on the distribution grid.

To make matters worse, adding on-site generation reverses the direction of current flow – and also the direction of the voltage drop. When generation is high (e.g. 5 kW going into the grid) the voltage will be raised at the house. This is especially true with Solar PV generation since all of the solar panels in one area tend to come on and go off together and so the voltage on the distribution grid will tend to rise and fall too. The voltage in the house will generally be highest when the Solar PV generation is at its maximum.

This is all well understood by the electrical engineering community and all of the installations are specified in such a way as to keep the voltage within acceptable limits and eliminate troublesome issues like lights flickering when big loads switch on and off (the worst culprits typically being big motors – like those in heat pumps, which is why the distribution network operator needs to be consulted about such installations). For the UK the limits are defined in national legislation and allow the voltage to vary between -6% and +10% of the nominal 230V, giving a minimum of 216 V and a maximum of 253 V. (The UK limits used to be -6% and +6% and the nominal voltage used to be 240 V but that’s a different story.)

One other item worth mentioning is that – in general – it’s better to have a supply at the bottom end of the permissible voltage range than the top end. Voltage optimiser technology works on the principle of monitoring the voltage and actively reducing it to the bottom of the permissible range – typically something like 220 V. For some types of electrical loads this can provide energy savings, but the general view seems to be that the savings are not large enough to warrant the installation of a specialist device for this purpose – especially not in a domestic property.

Update 2017-05-18

With the transformer switched to its lowest setting, the voltage reported by the Solar PV inverter is has reduced to about 240 V. The Immersun unit which diverts excess solar generation capacity to heat the hot water tank monitors the mains voltage and is reporting a minimum of 229 V and a maximum of 247 V.