Hi
I realise that there are various posts littered around covering this topic (many of which are usefully referenced from here: http://openenergymonitor.org/emon/buildingblocks/gas-meter-monitoring) but I wanted to ask if anyone has successfully managed to get a gas meter fitted with a pulse block talking to emonTx/emonPi?
I have a UGI R5 which appears to have a built-in pulse block (RJ11 socket) so ideally I'd be able to connect this directly to my emonPi and then run some code to translate the signal into something useful (I guess this would be required, but not entirely sure - maybe there's a circuit which could do this instead).
Of course if there's no existing solution for this type of meter I can work on one but my electronics is very rusty, and coding at such a low level is not my normal field... happy to give it a go, though!
Thanks,
Josh
Re: Gas meter reading (again?)
If you can find out what is behind the RJ11 socket, then we might have a solution. This post http://openenergymonitor.org/emon/node/2001#comment-17569 says there's a switch on pins 3 & 4. If you can verify that, then we can take it from there.
Re: Gas meter reading (again?)
Hi, thanks very much for the reply.
Today I got round to testing the port and got a result. The switch (normally open) closes when the dial reaches 6 o'clock and opens again at about 10 o'clock.
Very much appreciate any further advice you can offer as to next steps...
Josh
Re: Gas meter reading (again?)
That's a good start. The bad news is the switch is probably a reed operated by a magnet, and as such it will be liable to contact bounce. Therefore, if you use one of the interrupt-driven pulse counting sketches, you are likely to record astronomical gas usage (because it will see multiple pulses per switch closing). You can either interpose a hardware de-bounce circuit, or try a sketch that ignores contact bounce.
http://openenergymonitor.org/emon/node/5022 has a very long discussion about contact bounce, about half way down I posted a sketch that is reported to work, there are also mentions of hardware debounce ICs in there.