Archived Forum

You should have no problem with the newer emonTH, which does have a pulse input, but you might need to add a terminal block to the pcb (I'm not sure whether it comes with one - if you're worried, ask The Shop).

Does your meter have a pulse output (unlikely) or do you intend to add an external sensor? If the latter, what did you have in mind?

Depending on how you intend to get the data from your gas meter, you might have problems with the pulses themselves. There are several threads on here that deal with the various sensors that you can use, from reed switches (that need contact de-bouncing) to Hall effect devices. If you're using the emonTH with a battery supply, you might find your options are limited due to power constraints and battery life.

Hi Robert,

Thanks for the reply.  I have ordered a reed switch - I'll wait until I know that it is working before ordering the emonTH.

Does the software debouncing work reliably?  If so, it is presumably a better bet than hardware debouncing?  I can run my emonTH on a power supply if necessary.

Many thanks.

The polled approach controlled by an interrupt-driven timer that I developed (for Eric?) seemed pretty reliable, but as the processor never sleeps, it's not for battery operation. It's not totally bullet-proof but it is fairly simple. It's a lot cheaper and simpler than hardware!

(That was an emonTx of course - you'll need to merge that with the emonTH sketch.)

So my reed switch arrived today and seems to work (when connected to a multimeter)  (I'll post all the details when I have a bit more confidence that everything is as it should be).

However, I have had a re-think about how to send the data back to my Raspberry pi (which is running emoncms).  Instead of purchasing another emonTH, I am thinking of using a spare Raspberry pi that I have, together with a spare "ethernet over the mains" adapter that I have.  I am lucky in that my gas meter is located close to a mains socket.  That won't cost me anything (given that I already have the parts).

Any thoughts on this approach?  I assume that I will need to write some software to do the debouncing?  I want to run this from the SD card (rather than a hard drive) - so I will need to find a way of avoiding too many writes to the card.

Many thanks for any suggestions.

I've attached a python script that may get you started. I wrote it a while back as a fore runner to a pulse interfacer for emonhub, it was originally intended to use with a magnetic switch but I have only tested it as a led pulse counter.

There are some notes at the beginning about adding a socket interfacer to emonhub to receive the data. This script won't actually write anything to disc it just counts and sends, all in ram.

I will be interested in how you get on with this as I do intend adding pulse counting to emonHub in the future.

Paul