Measuring Gas Consumption

Continuing the discussion from emonPi + connecting reed switch for gas pulse counting:

@Simsala @mozster I see you both have managed to setup gas consumption monitoring. Would you care to share how you did it, parts used, photos, input/feed processing and any code you might have used?

Really interested in doing this (as are others I guess) but have never managed to find a solid example of it working.

Hi Brian

I’ve only just got my setup running, so I’m still working out the quirks in the system. I’m using a single emonPi for all measurements and I’m using this reed switch -

I’ve connected it along with a temp sensor via some cat5 cable and the RJ45 sensor socket - it uses pins 5&6, here’s a pic:

A couple of things to note when using cat5 - there’s two ways if wiring the cable (T568A or B) so just need to be careful which strands are connected to which pin and also the RJ45 plug isn’t plug and play :slight_smile: you need to reboot the emonPi not just restart the Pi (I was pulling my hair out for a little while before I found that in the forums)

The reed switch itself is blutacked onto the meter, I’m not sure how secure this is, but I’ll hot glue it if it falls off…

I’ll post more details later once I’ve figured out if it’s reading accurately


1 Like

Many thanks.

I bought one of these hall sensors ages ago. I’ve managed to get it setup and it works with a magnet but not on the meter. I suspect it is not sensitive enough having read this item off the Forum archive. Yes I did try it both ways round as it is unipolar.

I am really after a 3 wire omnipolar, 3.3V sensor I can hook straight into a Pi clone I have lying about.

I’m going to try one of these as they seem really sensitive. I can always move it further away! Alternatively there is another one that is a little less sensitive if this does not work.

My reed switch appears to generate two pulses per rotation. I’m using the default emonPi pulse counting code in the Atmel for now and haven’t needed to make any changes to the way it debounces.

I was initially a bit concerned I might have some weird switch bouncing issue, but the pulses seem to be stable and occur when the least significant ring(?) is at 5 and 9… so I’ve adjusted my scaling calc to take it into account and will observe and compare to my meter readings for a bit.

The 2 pulses per rotation are most likely a result of contact bounce and do require a debounce correction to be trusted, the only time you would expect to reliably see 2 counts per rotation is if both the rising edge and the falling edge were being counted, which I do not think is the case in the stock sketches.

Beware - I saw a post some time ago where someone complained that the standard sketch did not count both rising and falling edges, and proposed a “correction”. I don’t know whether this was implemented or not.

I’m not sure. If the hall sensor is omnipolar, as the magnet gets to the bottom, the flux will be perpendicular to the sensor and could trigger it again.

You should be able to tell by timing the pulses as the rotation is pretty constant.

Oh! Now you say it, that sounds familiar but having just checked (what I think is) the current emonpi and emonTx firmwares it looks like they both count falling edges only, I haven’t checked emonTH.

[ :frowning: I wish we used reusable code files or a central library for these functions that are repeated so often in so many sketches ]

Would that mean it will always reliably trigger it twice or just that it might trigger it twice more often than not? Half or double the pulses is a pretty big swing if it’s not permanently in either the single pulse or double pulse camp.

I’ve checked my board too - it’s set to trigger on falling edge

I thought it might be doing something like this:

I observed it for a few mins and the count increments appeared to be consistently at the same point of rotation on counter (on 5 and 9), so I thought it would be safely and reliably triggering twice, though not sure if there’s an easy way to check? My plan was to observe for a few days and see if there was much drift…


If the switch is closing consistently on two places nearly 180° apart, then I think your diagram is correct.

My meter behaves as if the magnet turns about one end, so the switch is closed for about ⅓ - ½ of a revolution.

Depends if at the furthest point, the flux is sufficient to reliably trigger the hall sensor. If the flux strength is marginal, the reliability of the second pulse may be a problem.

Of course if it is a unipolar sensor this does not happen. Logically you therefore should use a unipolar for a rotating magnet and a omnipolar for a passing, or approaching magnet. In either case you do not want a latch.

Hi Brian,

sure here is my setup: I use the offiziell “sensor” for my gas meter (IN-Z61), so no need for a self hacked solution:

I connected it to the interrupt input and GND of a emonth2. Inside the “sensor” is a reed switch, so I needed to handle bouncing in software. With your hall sensor you should not be affected of bouncing afaik. Here is the modified emonth2 firmware I use: emonth2/src.ino at 73d6a9eacb4571cab572a90feb1bd3685340c891 · rexometer/emonth2 · GitHub

It is absolutely reliable for me.

For input/processing I recommend to use the following (@pb66 shared this, thanks to him):

  • Total pulse count to pulse increment
  • Accumulator

I had some strange, still not resolved issues with using the Wh_accumulator in this context, so I do not recommend that.

Interesting sensor but at £66 quite steep! Thanks for the info.

I’ve tried 2 different hall sensors, one was too sensitive the other not sensitive enough. Third time lucky.

I’ve been tracking my readings for a few days, I’m getting a few missed pulses so my setup isn’t completely accurate, here’s my data:

Pulsecount Meter reading Pulse diff Meter diff missing pulses error
1140 36628.10 - - -
1371 36629.24 231 1.14 3 1.30%
5760 36651.04 4389 21.80 29 0.66%
9346 36668.82 3586 17.78 30 0.84%
17793 36710.81 8447 41.99 49 0.58%

I could possible move the sensor further away from the dial and see if that makes a difference but I think I can live with the error rate, I guess there’ll be errors from the calorific value too… a quick scan of my bills shows it generally ranging between 39.4 - 39.6 with occaisonal rates as low as 38 and as high as 40.

1 Like

Hi guys,
does some of you managed to monitoring gas meters with digital display?
Do you know how it can be done? Which sensor do I need?

What do you mean by “digital display”? Is it a mechanical meter with a digital display like post no. 13 above, or an electronic meter with a LCD digital display?
If it is the second, then unless there is a connection provided or there is a part of the display that is always present, I think it is unlikely that it can be done.
If it is the mechanical type, then you use a magnetic compass (someone tried a Smartphone compass, it did not work) and you try to find a magnet, which the IN-Z62 sensor in the picture is detecting. The magnet is usually inside the ‘fastest’ wheel - in the picture 0.001 m3. Hold the magnetic compass close to the fastest register wheel. If it swings as a certain number goes past, it means there’s a magnet inside the wheel and you can use that. If you detect a magnet, then you can use a magnetic reed switch if you cannot buy the correct attachment for your meter.

Alternatively, there might be a reflective patch on the register which you can detect optically, though this tends to be harder and less reliable.

If you cannot detect a magnet, and don’t have a reflective patch, I have read of a camera & character recognition software that reads the display, but this is costly.

@Robert.Wall Do you have any details about this solution?

Sorry, no. It was a long time ago, but I’m reasonably certain it came from a search. It was a commercially produced device, I got the impression it was American but I could be wrong there.

This must not be confused with a home experimenter who’d used a mouse to recognise a pointer going round and round.

Have you tried a search for “ocr meter reading”?

Here’s an example of using OpenCV and C++ to do meter OCR.

Another that uses OpenCV and Python.