@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.
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 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 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.
[ 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 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…
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.
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.
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.
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.