Help with Water Consumption Tracking - Only showing 1GPM all the time...?

Emoncms
1

So I have added three water meters to our house and have got two of them up and running and dumping the pulse data into emoncms.

I am reporting back to my emonpi once per minute when the water is not flowing and once per gallon while the water is flowing. My emonhub conf is reporting back to emoncms at 5 second intervals of bulk data.

Here is what I would like to do:

  1. Monitor, (in near real time) water usage. I realize that I am only reporting every 1 gallon, so this is enough of “near real time” for me.

The problem that I am having is that regardless of how much water I am using, my feed shows only 1 gallon per minute. I have verified that the pulses are making it to emoncms as they report correct, but the Rate of Change graph and the realtime graph of the same show a max of 1 gallon per minute when it actually varies between 10 and 30 gallons per minute. I did convert pulses to gallons as the first rule on my feed, not sure if that is causing issues.

  1. Track my exact meter reading. I thought this would be easy, simply add my meter reading to the beginning of my feed and I’m done. The problem is that every time I want to make a change to my sketch, the pulses reset themselves and I have to recalculate my total again off the meter. I am SURE I am missing something simple.

  2. Track daily and monthly usage. I thought the power to kWh/d or kWh to kWh/d would be the way to go, but each time I add those feeds, they end up turning red with ERROR and not doing anything at all.

My meters are 10 pulses per gallon, so here is what I did:

  1. X .1 (=gallons instead of pulses)
    • Current Meter Reading
  3. Log to Feed
  4. Rate of Change

I think I have the rate of change working, the graphing sees to go up and down based on water flow so that looks pretty good.

What I need help with is the daily and monthly totals as well as a running meter total regardless of how many time I reprogram my emonTHs!

Thanks

2

I’m a relative newbie here, but I have been learning a lot, especially about monitoring my gas feed. It has some useful parallels with your water metering, as it uses a meter triggered pulse measured on an emonTxShield on an Arduino Uno, with a local serial connection to an adjacent Raspberry Pi running the 20Feb2016 image. The Shield reports as Node 5, just as the EmonPi expects.

My gas meter pulses once for every cubic foot of gas, and is never faster than about one pulse every 32 seconds, and pulses can be hours apart, especially overnight, so my pulse rates are similar to your expected pulse rates, as you would be expecting at most a pulse every 20 seconds, and presumably long gaps while no water is flowing.

How to get a meaningful rate of consumption in as near real time as possible?

My solution was to have the sketch in the Arduino track not just the number of pulses, but to measure the durations between them. I do this in the pulse ISR on the Arduino, and limit any duration longer than two hours to two hours, and pass that to emoncms in the bulk serial data as an additional measurement, emonPi.pulsegap, in seconds. The bulk serial data is sent every 5 seconds, so having a non-zero pulsegap to send is relatively rare, as even at the fastest rate of consumption, there will be at least five transmissions to emoncms with zero seconds for every pulsegap with something interesting in it.

When there is a non-zero pulsegap, it is sent on two consecutive serial transmissions, then it is reset to zero, and zero is sent on all subsequent transmissions until the next pulse is detected. So emoncms gets pulsegaps ranging between 0 up to 7200 seconds. My processlist for this Input limits the pulsegap further to 10 minutes, then divides the Joules content of 1 cuFt (1146052.8J) of gas (1 pulse worth) by the pulsegap value, thus giving me the average flat rate of consumption in Watts over the time since the previous pulse to this one. In your case, you would divide your 10 gallons per pulse by the duration since the previous pulse to give your gallons per second, or gallons per minute if you multiply your pulsegap by 60.

The resulting Watts are logged to a feed. In my case, I use a special log to feed process called log to Rfeed. This logs data as usual, but if the value is non zero, it is then copied into earlier datapoints in the feed, as far back as the previous pulse, or to 10 minutes ago as per the limit applied at the start of the processlist. I do this because the flat rate just calculated applies to the whole pulsegap, not just at the time the pulse was detected, and having just one solitary measurement at the time of each pulse and nothing at all in between is grossly unrepresentative of the actuality, and leads to very inaccurate aggregations as shown in the web apps.

The real aggregation is in the cumulative pulsecount that is still being sent and presumably logged separately, and I also add my meter reading to the pulsecount to make it match the meter, and will have to amend this if the Arduino is ever reset, or the meter gauge rolls over.

3

Mike -

That sounds a bit over my head, but interesting. Any chance you would share your sketch so I can see if I can manipulate it to help out in my situation?

4

I don’t think I have sufficient privilege here to do that, unfortunately, being a basic user. I’ll try to summarise the key elements first, and try including some code that way. The ISR is very short, but relies on some additional variables in the main firmware file, which is very heavily commented now.

I may be a little while! :slight_smile:

Meanwhile, perhaps a moderator might suggest a means.

5

I’ve elevated you to Member (2). You should be able to post now.

6

Many Thanks, Robert, I’ll try not to break anything!

7

Ok, I have a zip of the Arduino sketch I use here. It is used with an EmonTxShield, and the calibrations for electrical measurements are for that, not the actual emonpi, though it reports to emonhub as node 5 emonpi.

firmwareGasv2.zip (12.5 KB)

My system has no LCD, and no RF, and no temp sensors, and has a direct serial connection to an adjacent raspberry Pi 2, and the firmware.ino file is based on the Continuous Sampling version in the 20Feb2016 emonpi image.

The relevant emonhub config is below:

[nodes]

[[5]]
nodename = emonpi
[[[rx]]]
names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount,pulsegap
datacodes = h, h, h, h, h, h, h, h, h, h, L,h
scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p,S
etc

This should be plenty to get your teeth into.

8

Mike -

Thanks…I will grab this and take a look!

9

Mike -

Looking over your code is helpful, might have more questions. For now, I think I like the idea of Max6816, cheap and easy enough to see if the problem I am having (which I doubt) is a bounce of the reed switch. I’ll keep you up to date on what I find out.

10

Can you confirm the 10 pulses per gallon figure, Richard? I think I misread that as 1 pulse for 10 gallons.

And are you sending an incrementing pulsecount? What do you send every minute when there is no flow? The current total pulsecount, indefinitely every minute until flow starts? And when flow does start, you send the new pulsecount every time it gets 10 higher than the last sending?

Or something different?

11

Hi Mike -

Yes, my meters outputs 10 pulses per gallon. If there are no pulses, I send back the last pulse reading. I am attempting to use the Rate-of-change feature as well to not only get a reading of total consumption, but also consumption by time, basically when someone takes a shower, I want to see a graph go from “0” water usage, to some number of Gallons per minute, and then back down to “0” (provided no other water is running).

I have two problems right now - the first is that the sketch that I am using (which actually works with my meters and return the correct number of pulses/gallons) does not really do much other than kick out pulses. I can crank it up so that I can send a reading every 1 gallon, and emon keeps up with the updates for the most part, but then I am only seeing 1 GPM on my graphs, and I am sure I am missing something simple.

The other sketch that I was trying to work with that someone suggested tracks not only pulses, but calculates GPM and gallons per last minute, but unfortunately I cannot get that sketch to work with my setup, it is showing 3 x the amount is usage regardless of what I set in the sketch.

So I am scratching my head and just trying to figure it out, looking for a way to make it work!

I was hoping your code would give me some insight into what I was doing wrong.

Screenshot 2016-05-18 12.09.43.jpg2848×382 83 KB

12

Richard, you said that “regardless of how much water I am using, my feed shows only 1 gallon per minute.” Both id228 and 229 show a max of 1 gallon/minute?

Can you take a csv extract of both feeds for the same time period that includes a good flow of water? And what are the feed intervals you used when setting up the feeds?

I’ve been trying to understand how the numbers work out, and can’t really see any problem with your processlist. The [RoC] should record between 0 and 30 gallons per minute if the pulses are getting through, and as long as the pulsecount is a continuously incrementing counter of pulses, it shouldn’t make much difference when exactly you send them, even if an individual value falls through a gap, the next value would cover the gap anyway.

So if your [RoC] feed interval is one minute, every datapoint will contain a value between 0 and 30 gallons. Perhaps you could take a screenshot of the relevant Input process for that Input?

13

Mike -

I took your suggestion and integrated the MAX6816 into my circuit. WOW! that is all I can say…those things are SMALL!! I didn’t realize it when I ordered them, but in the end I was able to get wire soldered onto them and tie them into my circuit. That did the trick with one of my issues I was having on a sketch showing more pulses then there really were.

I have another sketch someone sent me that calculates (in the fly) the GPM, gallons for last 60 seconds and total gallons. Now that I integrated the MAX6816s, these sketches now read correctly. I need to integrate them into a sketch for my emoncms, but with an output of GPM, I should no longer need ROC, nor all of the converting pulses to gallons, etc. It will all be done in the new sketch.

I’ll update you once I update the sketch for emon and let you know how it is working out!

Thanks for the help!

14

I knew it was small when I bought it, but hadn’t really understood how small. But it actually gave me no trouble at all to solder it in place on a small piece of veroboard. I just took my time to prepare everything properly in advance, worked out how I was going to place it, made sure everything was cleaned and tinned, how the switch would connect to it, how the veroboard would connect to the emonTxShield, and the whole process just went swimmingly.

I was fortunate, I had an ex-laptop modem cable with the correct connector for the gas meter, with the correct pins, and the far end had a BT type 631 plug on it, and it was easily long enough to reach the Shield. So I actually added a BT socket to the veroboard and just plugged the BT end of the cable into it.

For such a tiny device with no requirement for any external components it is very effective indeed. I have been using it for several weeks now and my pulses have been flawless, not a single spurious trigger to my ISR.

15

Yeah, it looked a lot harder than it turned out to be. When I first saw them I had no idea how I was going to make it work. But with my son’s help, a good magnifier and a steady soldering hand, I was able to make it work without a problem. Then I just added a nice piece of shrink wrap over it and it worked like a charm.

Did you end up adding in the capacitor like they suggested? I did for both of mine and they worked, just wondering if I really needed to use one in the circuit.

Cheers

16

Actually, I didn’t. I thought the supply from the Shield would be entirely adequate, and that I could add the capacitor later if I was having any problems, and I left room on the veroboard for it, but it has been completely problem free since minute 1.

Possibly relevant to your monitoring issue, is that I now have a way of deriving pulsegap durations from the standard accumulating pulsecount, using a couple of custom process functions in the Input process page. The key one is “Now” which just replaces the current value with the current time, and that combined with a “Rate of Change” or my feedless version, “Difference n”, lets me calculate the average usage rate between two pulses.

The advantage over pulsegap is that pulsecount is a standard Input, is sent continually, and so is less vulnerable to the occasional missed reading. I would occasionally find that a feed was missing a pulse, but that a different feed in the chain had recorded it, so somehow, perhaps due to a timing mismatch in feed intervals? a reading could fall in a gap.

So having two feeds showing the same data, but derived from different Inputs allows each to be a check on the other.

17

Mike -

Take a look at the attached sketch, I handle all of the math within the sketch itself and just output gallons (pulses / 10 in my case), gallons per minute and gallons last minute. When water flows, I kick out GPM reading pretty fast, pretty much as fast as I can, but I am logging to a feed every 5 seconds within emoncms.

I am sure it can use some more work, but for now it does exactly what I need and want it to do!!

Thanks for the help!

screen 2016-05-26 at 9.22.03 PM.jpg1796×2160 282 KB

motenio_RFM69HW_Pulse_RJS_Irrigation_Meter.ino (19.9 KB)

1 Like
18

That’s a very clean-looking sketch, and nicely documented, Richard. It certainly looks like you have solved your problems. Given the rapidity that your pulses can reach, I don’t think you would see much benefit in monitoring the durations between pulses as well, as you already get good time resolution.

19

Well, I am going to run these sketches for awhile (I monitor three meters, one for house, one for irrigation and one for our pool fill) and match them against the meters and see just how accurate they end up being. I’ll let you know how it turns out. I am hoping with only transmitting while water is running to keep my power utilization down as well, but I guess we will see how that goes. The 6816 uses a very small amount of power as does reading and writing to the flash.

20

One good reason I like the 6816 is that it keeps the voltage and current levels on the reedswitch contacts well below the stated limits on the gas meter dial.