Hi all – in case this is of any assistance to anyone else, I am sharing the success I have had with monitoring my gas meter.
My gas meter is a Krom Schroder BK-G4 (also badged as Elster, I think).
I used a reed switch which I got from Farnell: http://uk.farnell.com/standexmeder/mk03-1a66b-500w/reed-sensor/dp/1079476?ost=1079476 and attached this to the meter using blutac. (See the attached photo)
The reed switch is not entirely symmetrical (the wires enter the switch closer to one edge) – I found that I needed to rotate the switch so that the wires were closest to the top of the meter to get the most reliable switching.
I chose to use a spare Raspberry Pi to collect the pulses, and sent these back to my emoncms running on my main Raspberry Pi, using a pair of Ethernet powerline adapters (I had a spare adapter, which I used to connect to my existing adapter).
I started by writing a Python script using the RPi.GPIO library, but found that I could not debounce the switch sufficiently despite playing with lots of different settings (I was using the debounce option provided by the library).
So I chose to do the debouncing in hardware, using this device, again from Farnell: http://uk.farnell.com/maxim-integrated-products/max6816eus-t/debouncer-switch--25v-4sot143/dp/2085162?ost=2085162 If you go down this route, have a close look at the physical dimensions – it’s really tiny which makes it difficult to work with. The results so far have been very reliable. I've attached a diagram of the circuit I used (I used 3.3V from the RPi as the Vcc). I've also attached pictures of the debounce components.
I have written some Python 3 scripts to capture the pulses and send these off to the emoncms. The local RPi needs to store all pulses it receives (in case the main Pi is down) and so I chose to set up a file containing the meter reading on the SD card, and to increment this value and send the actual meter reading to the emoncms, rather than just the pulses.
I also chose to send a daily pulse to the emoncms, so that I could calculate the standing charge (cost per day, regardless of the gas usage) in the emoncms.
I have attached my scripts in case anyone is interested (I am new to Python so please be forgiving!).
Re: Success with monitoring a gas meter
I am interested in the Gas Monitor. Is there any plan to integrate Gas Monitoring into the emonpi?
Cheers
Phil
Re: Success with monitoring a gas meter
A word of warning - if you're writing to the SD card with every pulse, you need to bear in mind the probable life of the card. There's plenty of information here about that. It was SD card life that triggered the creation of the "low write" RPi software.
Re: Success with monitoring a gas meter
Yes - I am concerned about that. The only write that I am doing is once a minute to a small (7 byte) file, so there should be plenty of spare space on the card, but I can't decide if the SD card will automatically do some wear leveling or not. The other idea that I had was to create a copy once a day (say), and switch to using the copy. Any thoughts?
Re: Success with monitoring a gas meter
You need to know whether the file is written in place, or a new file is written and the old deleted. Either way, the directory entry is probably being updated every minute anyway.
My thoughts are how critical is it that you know the exact reading after a power failure (either RPi of course!) and how much gas are you prepared to lose, unaccounted for, if you save the reading in RAM for somewhat longer than a minute - maybe an hour or two?
The obvious 'best' way would be to write to the SD card only every couple of hours or every day even, but detect the mains power and write immediately a low mains voltage was detected, having made sure the 5 V supply would hold up long enough for that to complete. I don't know if that's practical, though. I'm fairly certain one of the usual suspects - it must have been Martin Harizanov or J-C Wippler - did that with the EEPROM on an Arduino, but I've never been able to find it again.
Re: Success with monitoring a gas meter
Ahh - I hadn't realised about the directory entry being updated. In that case, I think I will change the write to once an hour - that's 8,760 per year - hopefully it will be able to cope with that (and I could live with having to buy a new SD card once a year!)
I might even try and get fancy, and when the monitoring script starts, query my emoncms for the latest reading, and use that if it is greater than the value held on the card.
Re: Success with monitoring a gas meter
I think the accumulators in emonCMS do something like that - I understand they are able to correctly keep track of the incrementing reading even though the counter behind the incoming reading might have been reset. In your case, it seems to me that you might have the problem in both directions - either RPi might have missed something, so that complicates it considerably.
Re: Success with monitoring a gas meter
Because I am sending the meter reading (rather than the pulses), I am not using an accumulator in emoncms. So if the emoncms misses something, it's not a problem, because the next input will correct the emoncms.
(That's not true for the one pulse per day that I am using for the standing charge - in that case, I am sending repeatedly until I get an 'ok' reply. However, I've just realised that I could do something similar to the meter reading, and send the number of days since the epoch as an input, and then do away with the accumulator in emoncms).
Re: Success with monitoring a gas meter
"because the next input will correct the emoncms."
Yes, but only if it hasn't gone backwards! Which it will if you've sent the up-to-the-minute readings but not stored them prior to sending, and it's that situation that you need to address. It's exactly the same with the "kWh" emonTx sketches that accumulate the energy locally and then send the total. That total is reset if the emonTx restarts, emonCMS can handle that (which is what I meant above but didn't explain properly, so you misinterpreted - I meant the inputs from the accumulators).