Hi All
I’m trying to implement pulse counting on my water meter and I’m struggling to get daily feed totals and also I want to measure how much water I use for showers but for the logic that I’ve attached below, once someone uses the shower, it will add the previous water use for that day.
Dave - Sorry I have no solutions just wanted you to know you are not alone! I’m struggling with the same water challenges. My input is not a pulse but a running total. I’ve only been able to do these two types or graphs:
EDIT: In your Water Meter (Node 8) I seem to remember the Accumulator should appear first. I think this had to do with power outages and dropping the count. I am trying to find a reference. I am wrong.
Also, what is the “x .0001” in line 4 calculate? Is each pulse a Liter? or a 1000th of a Liter?
Yeh with the pulse input it will be just a count of the usage, the x0.0001?? My water metre pulses every litre, so the above value converts it into cubic meters, I.E. 2000 litres used is 2m3.
TBH the only real use of pulse is for gas and water as they are measured by volume but I do agree that I’m struggling to find the right processors in EmonCMS.
Regards
Dave
Surely 1000 litres per cu.m, not 10,000?
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.