Yeh it is 0.001 on my logic, there’s an extra zero that’s crept in 
The error was mine. The image in the first post is 0.001.
Dave - There is a well written guide written by Steve @smitt1979 in the old forum that may help → Water Meter Guide Updated v2.0
The issue mentioned in that linked thread, at reboot, when using a WhAccumulator will probably be due to emoncms not knowing what the last raw pulsecount was since it is not persisted, as far as i know it is only held in RAM using redis.
Rather than use a WhAccumulator, try using a “Total pulse count to pulse increment” (Tpctpi) followed by a regular accumulator. The Tcptci will record each raw pulsecount,That way at reboot it can calculate the correct pulse increment regardless of whether it is a quick reboot or a prolonged outage as the increment will always be based on the value used to calculate the last increment, This is not data that can be used for anything else except debugging so some may argue it’s a waste of diskspace, but I say it’s a small price to pay for reliable data with a built-in debugging tool.
The main issue with your your processing (reboot issues aside) is the feeding of one “ratchet type” processor into another. Both the Tcptci and WhAccumulator will only process increases in the input values as expected a lower value will not, A WhAccumulator just discards the first lower value and bases the next calc on that new lower value where as a Tpctpi will still process the first lower value and also base the next calc on it. since a pulsecount will fluctuate up and down there will be a significant amount of data ignored if these are daisy chained…
for example passing values 2,4,2,4,2,4 into a “WhAccumulator” process one after the other would give you 2+2+0+2+0+2 = 8, passing the same the totals into a Tcptci would give you 2+2+2+2+2+2 = 12, should be 18 if they are individual increments rather than an incrementing total.
On the first “shower” processlist changing #21 to a straight Accumulator should work ok, including the kWh to kWh/d which is effectively a simple “daily total” accumulator, the second “water meter” would translate to
- Total pulse count to pulse increment “WaterMeterRawPulse” (much more useful than a “log to feed”)
- Max daily value “WaterMeterMaxDailyLitres” (assuming one pulse is one litre)
- Accumulator “WaterMeterTotalLitres” (replaces the first WhAccumulator)
- x 0.001 (scale to cubic meters)
- Accumulator “WaterMeterTotalM3” (replaces the second WhAccumulator)
- Max daily value “WaterMeterMaxDailyM3”
This only applies to self hosted emoncms as unfortunately the Tpctpi process is not available if using emoncms.org so you have to use the WhAccumulator, but as the server is “rebooted” less it should be less of an issue. The ignored first lower values could still be an issue though.
Thanks Paul
I’ve adjusted the logic but I seem to be having the WaterMeterCost feed counting up without any pulses?
Max daily value must go before the accumulator as the accumulator returns an ever increasing total rather than the increase, so for that same reason we can’t daisy chain accumulators for different scales (sorry didn’t spot this as I haven’t tried it) swapping out the second and subsequent accumulators to log to feeds will get all the accumulating totals working correctly as it will blindly scale the value returned by the preceding process and record it. eg
- Total pulse count to pulse increment “WaterMeterRawPulse”
- Max daily value “WaterMeterMaxDailyLitres”
- Accumulator “WaterMeterTotalLitres”
- x 0.001 (scale to cubic meters)
- Log to feed “WaterMeterTotalM3” (replaces the second accumulator)
- x 3.13 (price per M3?)
- Log to feed “WaterMeterTotalCost”
but that will remove the ability to record the daily max’s, so you need to find another way of doing it eg
- Total pulse count to pulse increment “WaterMeterRawPulse”
- Max daily value “WaterMeterMaxDailyLitres”
- Accumulator “WaterMeterTotalLitres”
- x 0.001 (scale to cubic meters)
- Total pulse count to pulse increment “WaterMeterM3Raw”
- Max daily value “WaterMeterMaxDailyM3”
- Accumulator “WaterMeterTotalM3”
- x 3.13 (price per M3?)
- Total pulse count to pulse increment “WaterMeterCostRaw”
- Max daily value “WaterMeterMaxDailyCost”
- Accumulator “WaterMeterTotalCost”
or perhaps to avoid 2 more semi-redundant Tpctpi feeds you could subtract the last accumulated feed value before logging the max daily and accumulating the increment.
- Total pulse count to pulse increment “WaterMeterRawPulse”
- Max daily value “WaterMeterMaxDailyLitres”
- Accumulator “WaterMeterTotalLitres”
- x 0.001 (scale to cubic meters)
-
- feed “WaterMeterTotalM3” (to give you an increase in M3)
- Max daily value “WaterMeterMaxDailyM3”
- Accumulator “WaterMeterTotalM3”
- x 3.13 (price per M3?)
-
- feed “WaterMeterTotalCost” (to give you an increase in cost)
- Max daily value “WaterMeterMaxDailyCost”
- Accumulator “WaterMeterTotalCost”
Thanks Paul
I’ve updated the logic as attached, I’ll have a play about with it tonight to make sure that it works as it should do. I’m still getting issues with bouncing from the meter, I’ve put a resistor and a capacitor in to try and cure it but no joy. There is a sketch about that Robert Wall produced to provide a software debounce but it doesn’t work on my EmonTX v3.4?
You mean this one? It was for the V3.2, In the V3.4, the pulse input has moved from DIO2 to DIO3 and changed from IRQ0 to IRQ1, and you’ll need to change RFu_JeeLib back to the standard JeeLib, and if you’re using the RFM69CW you’ll need to add the line for that too.
I think that’s all that needs to be changed, but I could well have missed something.
Hi Robert
Yes, that is the one, I’ve been fiddling with it this evening and managed to make the emontx run, but I’ve been unsuccessful in getting it to transmit or set the pulse pin to No.3.
If you’ve fiddled, I can’t help because I don’t know what you have changed. As the sketch “runs”, my first guess is you have JeeLib correctly changed, it should transmit if you’ve got the right radio set (12B or 69CW).
Looking again at the sketch, it might be easier to transplant the pulse bits from that sketch into a modern V3.4 sketch, (but take out any existing interrupt-driven pulse counting first) because a lot of other things have changed since that was written.
Basically, the bits you need are:
-
The piece at the beginning of setup( ) that sets up the Timer 1, down to and including “interrupts();”
-
The piece towards the bottom of loop( ) that accumulates the count of pulses, again down to and including “interrupts();”
-
The interrupt service routine immediately after the end of loop( ) function.
Of course, you’ll still need to change the input pin in the ISR to whichever one your switch is connected to, which is probably 3.
Thanks Robert
I think from my experience last night its a little over my head, TBH I couldn’t even work out where I needed to change the IRQ pin. I would be happy thou to slip you some cash for your time if your willing to update the code and of cause share with the wider community.
Oh dear. I’m desperately trying to get back onto sorting out the problems with the CM Library. If nothing else goes belly-up on me, I’ll try to do something over the next few days, but no promises.
Keep an eye on this thread, because I customised a sketch for someone a few weeks ago, and they’ve not acknowledged it, so that could have been a complete waste of time, and the thought of that rather puts one off offering again.
Here you are. It seems to work for me:
emonTxV3_4_DiscreteSamplingPolledPulse.ino.zip (7.2 KB)
Thankyou very much @Robert.Wall I’ve just uploaded the sketch and it appears to be working. I’ll drag the freezer out of the way to get to the water meter tomorrow to confirm that its resolved the bouncing issue.
I owe you a beer!
Dave
Hi Robert
I’ve been playing about with it this morning but the pulse is not counting up.
I currently have a pulse of one, Ive disconnected the meter and shorted the Gnd and Pin3 manually to make sure that pulses under 300ms arnt causing a problem but with no avail.
It won’t work on battery power and requires the ac adapter (you did read the comments?). The minimum on and off times are 400 ms, if either is shorter, it won’t be counted. But after that, the input can stay high or low indefinitely. The underlying assumption is that switch bounce will last less than 100 ms. If the maximum time that contact bounce can last is known, the clock rate of Timer1 can be changed (line 164, e.g. 3124 for 20 Hz / 50 ms) and that will alter the times proportionately (i.e. the minimum pulse and minimum space are both always 4 × the maximum time allowed for contact bounce).
Hi Robert
OK i see, not being an expert on reed switches, can I assume that the bounce time will always be significantly shorter than a pulse from the water meter, baring in mind that my water pressure here could potentially deliver 1 litre a second so I can also assume that the pulse time is approx 100ms?
The setup I have here is 4x CTs, 1x Pulse, AC & USB power.
At the moment I cant seem to register any pulses, I can physically short out ground and pin 3 for one second but still nothing registers.
What do you mean by Pin 3? The input is DIO3, which is pin 4 on the green screw terminal strip, or pin 6 on the RJ45 connector.
Do you see anything with a multimeter across the water meter output, and a low flow rate?
I don’t think you can assume anything about the reed switch. If you get one pulse per litre, and the meter’s rated maximum flow rate is 1 l/s, then I think all you can say with certainty is you’ll then have 1 pulse per second. I would expect the switch to open and close when the fastest (or maybe not!) dial hits the same position each time round, and I’d expect that angle between closing and opening to be about 60° - 90°, giving a m/s ratio of 1:5 - 1:3. But those numbers are pure speculation.
I’ve got a push-button switch here wired 3 - 4 on the terminal strip, and if I try hard, I can register 10 pulses per reading (= 1 per sec). But there’s almost no latitude in there - if one pulse or space is slightly short, it misses a pulse. If I sit with my finger on the button, I get 1 pulse on the first reading after I closed the switch, then 0 pulses until after the switch has been opened and closed again. And that’s exactly the behaviour that I expect.
[Edit]
I’ve taken OCR1A = 6249; down to 200 (~ 3 ms polling interval) and all that proves is it can be reduced and my switch doesn’t bounce much. (The interrupt-counting sketch consistently records 2 counts per operation.) It doesn’t appear to have affected the calibration significantly, which it shouldn’t (though at that rate, it could well have reduced the number of samples per cycle).
If you want this sketch to behave the same way as the interrupt-counting sketch, i.e. to report each time the accumulated count over all time, rather than the number counted over this reporting interval, then you need to change line 419 to read:
emontx.pulseCount += pulseCount;
The present behaviour is the same as my original V3.2 sketch.
[Edit 2]
In the sketch comments, I wrote “Pulses are counted by a reed switch connected between digital input 2 and GND.”. That should of course be between digital input 3 and GND. The top silk screen on my emonTx V3.4 is wrong, and the blob of ink on top of the wrong legend has worn off!
Apologies, I should have said pins 3 & 4.
I’ve changed line 419 and it now counting again, I’ll test it later tonight to see if its still bouncing, I’ll let you know how I get on.
Spot on Robert! Thankyou very much for your help.
The changes I made were…
Change line 419 to read: emontx.pulseCount += pulseCount;
Reduce the polling interval: OCR1A = 804;// = (1610^6) / (10256) - 1 (must be <65536)
I’ve ran through 500 litres of water at various flow rates and its accurate to one pulse over the 500 litres pulled through, thou this is questionable depending on where the dial was part way through a litre when I started the test.
I understand now what you meant about the reasoning for changing line 419 for accumulated counting, I didn’t understand originally and I noticed that I was getting random 1s or 2s on the input feed and my input feeds were setup to expect a accumulated feed.
Those weren’t random 1s & 2s, they were 1 & 2 litres recorded during that 10 s period!
I’m a bit concerned that you found it necessary to push the polling rate up quite that far. According to my sums, you’re polling the switch every 12.86 ms, so you’re hoping - apparently justifiably - that the contact bounce is over in that time. It also means that you’ll see a maximum pulse rate of nearly 10 pulses per second.
I don’t think I’d worry about 1 pulse in 500, that’s more accurate than the meter itself. (I found a figure of ± 6% at low flow rates and ± 2.5% at higher flow rates, but no definition of high and low.)