Archived Forum

Does the 'fast' dial also have a magnet in it? Mine has and it will operate a small reed switch. This thead http://openenergymonitor.org/emon/node/1732 has a lot about this - and a reed switch in position is shown in the picture here http://openenergymonitor.org/emon/node/1732#comment-10911. If yours is the same or a similar meter, it is worth checking. An ordinary magnetic compass held in front of the register will show the presence of a magnet.

Theres also info on the Building Blocks > Pulse counting > Gas Metering page  which includes a link to the following page

https://github.com/Bra1nK/HomeMonitor/tree/master/Gas%20Meter%20Pulse%20Creator.

But I would also support Robert's comment of checking to see if there's a magnet first ;-)

Good shout. I didn't think my meter had a magnet because the profile of the section with the dials is not relieved (i.e. nowhere that you'd fit a sensor, as I see in many photos).

However, a compass held up to the meter does a lazy 360 twirl as the gas is being used.

Reed switch to be picked up tomorrow!

OK.. last little thing that's bothering me - I seem to be able to crash the emonTH sketch if I interrupt it just as it's hitting the DHT sensor in the loop():

Pulse
Pulse
Pulse
Pulse
Pulse
Read failemonTH payload:
  Battery voltage: 0.20V
  Pulses accumulaüe

No further activity can be got from the emonTH without a reset. "Read fail" is only contained in DHT.cpp

I guess the nature of interrupts is that this sort of thing can happen. Means that an emonTH with DHT22 wouldn't be suitable for a gas monitor though?

Sorry, another schoolboy error:  http://forum.arduino.cc/index.php?PHPSESSID=np8octjlbdvvc8jugimnedbij0&topic=89059.msg683360#msg683360

Bah. So, my sketch works nicely and if I use a magnet I can generate pulses by hand and they appear in emonCMS, so very close.

Unfortunately the reed switch is completely lifeless in the presence of my gas meter - I tried holding it against the dial (closest possible approach) in various orientations, and nothing.

Clearly I need a more sensitive switch (I picked up this switch from Maplin on the way home - I can't find the AT sensitivity but I have to get quite close with a rare earth magnet to trip it, so it's obviously not good)

I see from this discussion that the Standex ORD324-1015 was the only one Jérôme could get to work. I can't seem to find anywhere selling this online. Does anyone have a recommendation for something I can order up that is more likely to work?

Hi,

I am monitoring my gas meter as well. I have a reflective filled  number 6, and setup a photo sensor as well to count the number of rotation on my gas meter.

I ordered a photo reflective sensor incl. comparator at DX:

http://dx.com/p/diy-ir-infrared-reflection-sensor-module-blue-160655

The only disadvantage I am experiencing is sometimes the sensor is sometime double counting the numbers, because there is a impurity of the reflecting material. I changed the script to check if a pulse is generated two times within a second, because it is not rotating that fast. If I count two pulses within the same second, it is not counted because it is false.

I do have a gas meter like yours with a magnet in it. To avoid the situation described as above; I ordered:

http://dx.com/p/lm393-3144-hall-sensor-module-blue-221287

I didn't have time to test it with the Hall Sensor, but will let you know when I have the results.

Best regards,

Edwin

Hi Edwin - thanks for that. Are you able to get a clean enough signal just now to use an interrupt, or do you check the value on an analogue pin?

The reed sensor approach is nice because you can sleep and wake on interrupt. Do you run with battery power, and if so what sort of life are you getting with the IR solution?

I did say this one http://spiratronics.com/magnetic-reed-switch-en.html worked for me.

Thanks - I think I'm failing to keep track of where everything I've read is...

I've ordered that part, and also the paired IR LED / sensors in case of reverting to optical detection (at 20mA, I'd need to organise mains power though).

The hardware side of this may be cryptic to me but it's nice that you don't have to waste much money on parts if they don't work out :)

I am using the interrupt input on the emontx3 and not a analogue input. For powering i use the 5V USB and do not use the ACAC as a power supply because i do have 4 emontx boards and this will require to much current and will influence the Vrms measurement.

As mentioned the problem in my case was that reflecting part was not always reflecting (impurity of the reflecting part) so I was counting 2 pulses when it the counter was rotating. I fixed this in the code of Interrupt routine of the arduino.

One step forward, another step back... 

The reed switch mentioned up-thread doesn't work - I tried every possible orientation while the boiler was on full, and no dice.

I quickly combined the IR LED and phototransistor with a sketch which toggles the emonTH's on-board LED on a change interrupt on IRQ0.

It will detect a piece of paper easily and it will detect when I pass it in front of the plastic enclosure of the meter dials, but it's absolutely unresponsive to the passage of the silver reflective zero digit itself.

Next option is to use analogue... it will be worth it in the end (or I guess I can ask my supplier to fit me a modern smart meter).

OK, got somewhere last night, finally:

However, this morning when the boiler came on, I only got a couple of pulses detected (I'd expect 3 per minute as above, from last night) so I wonder if my batteries have dropped enough to impact the calibration.

Still, it proves it's possible in principal. It looks like I got a shift of under 100 on the analogue pin (and it's power hungry too) so not one for battery operation perhaps - unfortunate since the meter is on the exterior of the building.

It's not a power-optimised sketch so has essentially been on full for 7 hours, could have been quite a drain (20mA LED IIRC)

Last night I was getting a reading of ~800 for the dial and ~700 for the reflective digit, but as mentioned above it's not reliable (I'll need to go back to the sketch which output the raw readings). As this is 10% of the ADC's reading range, I'm guessing that it means the voltage across the phototransistor only changes by ~0.5V between the two situations.

Without going crazy, is it possible to physically wire the phototransistor so that the 0-5V seen by the emonTH more closely matches this range? That is, my existing reading of 2.5V would be 0V and existing reading of 3.5V would take it right up to 5V? Or am I over-optimising with this idea, since I've proven already that I can detect it (sometimes!)

It would be nice to stick with AAs if possible, as the emonTH does report battery voltage so I can anticipate a change, and it would be massively less hassle. If I can get this to work with the power-saving features from the default firmware, waking up every second to take a reading rather than every minute, it should be better even if it won't last for years...

I think the optical route is doomed as far as batteries are concerned. The only way I can see to power-save is to determine the width of the pulse you're seeing at present, and then to use an output to turn on for the minimum amount of time (ms?) both the LED and photo-transistor at least this often in order to catch the reflector going past. But this still means the processor will be almost fully awake all the time, rather than being woken by an interrupt. But at least you might be able to get the LED current down by a significant factor.

I'm a little further on with this now and my sketch incorporates the default emonTH power-saving features.

It fires up the LED at a low duty cycle, probably this could be optimised further (25ms on, 750ms off was simple for starters - at 15ms there was some instability in the readings, which I thought was surprising, but then I'm not so hot on the old electronics).

The LED is nominally 20mA (not sure what it actually draws from 2AA) so at a 3.3% cycle that's 0.66mA - still about six months operation if my guesswork is correct.

Since the emonTH can report its battery state, I'd be very pleased with such a long period of operation if it turns out to be the case. Perhaps someone with the necessary equipment could validate it in practice, but otherwise I'll just need to leave it on and report back.

I'm not so hot on visualising the pulses - just got a realtime chart for now and then the frequency of pulses denotes the rate of burn at the boiler / hob.

For low battery alerts you can use the event module to send you an email when the voltage drops to a set value.  Just pick a voltage value that's just above the brown out voltage of the emonTH.

Thanks - good tip.

I've been running the sketch all day and it's bang on the money - over 300 thousands / m³ have passed through the meter and the emonTH has reported exactly the right number of pulses.

I realised that I had poorly aligned the IR LED and transistor within their blu-tac "package" and re-stuck them together with extra care. This has achieved really good separation of the reflective digit - I get an average reading of ~600 but a low of just over 50 when the digit passes by.

A good next step would be to pot these components somehow  and make it look less homebrew should a meter reader drop by (since the meter is external to the property we wouldn't be there to explain). However, that's icing on the cake.

I'll push up the sketch when I've tidied it a little.

I'm looking to measure gas consumption through pulse counting to a emonTH and came across the following supplier as an example of pulse counting energy monitoring components.

     http://www.saveometer.com/store.aspx

They appear to offer a range of gas meter pulse counting sensors with fitting instructions for a range of gas meters.

Unfortunately they are bundled with a transmitter, unnecessary for me,  that bumps up the price

Has anybody had success ordering these or similar sensors separately?

From this company or similar that ship to UK addresses?

When I got back from work today I found my emonTH had dropped 6 pulses of gas - not too awful but still a bit disappointing though I suppose that could be one packet lost over the wireless (I haven't even thought about looking into retries and acks).

I then experienced a 30 minute outage where the emonTH wasn't calling in this evening. In the end I flipped out one of the batteries for a moment to kick it off again, and it seems to have been fine since then - now a total of 654 pulses recorded, actual meter reads 684, so a further 24 lost (that's not unreasonable, with the boiler often doing 5-8 pulses per 5 minute period and 6 lost reporting periods).

I'm not sure why the emonTH would just stop calling in. Perhaps a memory leak (although I see nothing obvious - not likely to be in one of the libraries as other people get these processors to run for months). It's only about 15 feet from the Pi through one brick wall, so should have good signal. If it happens again I'll do some more investigation.

I see some previous work's been done on transmitting pulses a bit more robustly. Although this first attempt is within 5% of the true value it could easily be improved even if a foolproof protocol is a bit hard to think of.

@3chooks, it's not clear what they're actually measuring - presumably magnetic as some of the example meters are surely too ancient for optical pulse.

You can pick up a reed switch for peanuts (less than it would cost me to mail you my unwanted one) and pair with an emonTH without too much trouble. My sketch is overkill for a reed switch (which has the big advantage of using an interrupt / digital pin) but could be adapted, if there's nothing more immediately suited.

I've submitted a pull request on my emonTH analogue pulse sketch: see https://github.com/openenergymonitor/emonTH/pull/2 for those who may be interested.

This now uses ACKs and attempts retries (with pulse count carried over if all retries fail) in an attempt to make the transport more robust.

I've now got an on-board D18B20 providing external temperature (since my gas meter is outdoors).

I was thinking some more about robustness of pulse submission and it occurs to me that a packet could be received (but the ack is corrupted) resulting in a duplicate packet being sent by my sketch. To guard against this, ideally the Pi would not forward on duplicate packets. I guess that means an update to the python script when I can get around to it.

That's a really difficult problem because you need to be able to detect a failure in both directions - the original data not received and the acknowledgement not received. I think the only practical safe way is to send a serial number - though of course if you accumulate energy in the transmitter, the energy itself functions as the serial number. But then you have the problem of power failure and resetting from zero that has to be detected and accommodated at the receiver unless you also store the last value in NVRAM, and then if you do that you have the problem of the NVRAM wearing out if you write to it too often....

Hopefully if the original data isn't received by the base, it will get one of the subsequent retries (I've considered having the retry delay be a product of the nodeID to avoid repeated collisions between multiple units).

Ignoring any transmission received within x seconds of the first would guard against a failed ack (but it would need to be flexible, in case someone wants to have a really rapidly updating sensor for some reason, on the same magnitude as the retry delay)

The approach I've taken in my sketch (now in the emonTH git repo) is to submit pulses since the last successful transmission only. This means if all retries fail because, say, the Pi is switched off, pulses will accumulate on the emonTH until the Pi is switched back on. Losing power on the emonTH would cause untransmitted pulses to be lost, but the impact is reduced because only pulses counted since the last transmission are unrecorded, and by default that's only the last five minutes.

Not perfect, but should be reasonable I hope.

This issue has been discussed in other related threads. The lead I'm following is to send a counter (which is homogeneous to an energy).

See a list of related posts here. I meant to sort them and didn't get the time. I added this thread to the list.

I power my TX with a LiPo, and added a step up that keeps the voltage 5V even if the LiPo delivers less.

The communication with the Pi used to work reliably, then with the cold I begun to lose samples at night. Then I added the step up to fight the voltage drop due to the cold, but I never got the communication to work again. I suppose I'm at the range limit and it relies on the position of the antennas... I must have been lucky the first time I installed the devices.

My next step is to try a lower bitrate to increase the range and finally get the communication channel to work reliably.

My other issue is the post-processing, from the pulse to the energy. You'll see that in the threads. Basically, the turn that is detected at time t accounts for energy consumed since last pulse. This time interval can be long. emoncms is not really made to work with this and I find it hard having a display that shows all the information I get from the sensor.

In practice, when it worked, I could clearly see the boiler switching on every 15 minutes for a few minutes. I'd like to keep this precision, but remove the ugly spikes. You can see the feed here: http://jolimont.fr/emoncms/vis/auto?feedid=12

I just ordered the RFM2Piv2 and hope to be able to try a lower bitrate soon.

I also ordered a TH to try pulse reading with it, eventually monitor my water meter. But this is another story...

Thanks for the links. There are quite a lot of discrete discussions around gas and it's helpful that there's at least a page tying stuff together. Quite a lot of emphasis on electricity (understandably) but with so many UK properties on gas, I think it's at least as important.

I got a second TH to dedicate to my gas supply, and because it needed soldering that took me a while to put together. I kicked it off at midnight last night and will follow the accuracy and battery life closely this time. Since the TH steps up from 2AA anyway it should be reasonably stable (I've considered a small solar LiPo to prevent me ever needing to change batteries but we'll see how it goes).

I'm not too worried about the appearance of the pulse feed on a reading-by-reading basis. My goal is to separate our gas use into space heating and water heating to understand the input side of the dwelling's thermal performance and have a number of temperature readings to calculate the output side. Since temperature is not closely coupled to the individual gas pulses it doesn't matter much to me if they are aggregated every five minutes, hourly, even daily - i.e. we only have the heating on for a few hours at a time but the house is above ambient round the clock.

I wonder how hard it would be to come up with a bar graph visualisation (one where the height of the bar is the number of pulses divided by the node's call in frequency, i.e. the correct area under the bar is preserved?). Sadly everything graphical is greek to me.

I spent the last half hour or so with my Pi offline while I imaged the SD card and HDD for the local emonCMS build.

When I switched on the Pi and configured the network group I got a call from my gas emonTH with 29 pulses - at least double the maximum I've previously seen, suggesting the pulses were carried over until a successful ACK was received.

I still need to look at ignoring false resubmissions at the Pi end. Seems promising though.

On the hardware front, blu-tacking the sensor to my meter is proving a little problematic in terms of getting a nice consistant reading - I dropped a bunch of pulses midweek when something shifted. I'm going to have to make a better holder for the apparatus, potentially secured to the meter cupboard door so that it always hits the same spot (I'm just paranoid of being accused of tampering with the meter, since it's not inside the property).