March 7, 2015 at 5:15 pm #35868
I was able to interface an existing netafim flow sensor to the rain sensor input on the OS, and modify the main.cpp to display the flow rate when valves are turned on. It was amazingly stable (see attached picture GPM display.jpg). the 6.36GPM varied from about 6.32 to 6.40GPM (once the line fill event occurred, which could take 1-2 minutes). During the line fill event you can see a much higher flow rate until the line is pressurized and stable (so the algorithm to record and detect leaks should wait until after 2 minutes before recording the actual flow rate and checking for leaks etc.
Two other images are also attached if you want to look at the reed switch output from the flow sensor. The pulse is around 50% duty cycle (I thought it would be more of a narrow pulse but isn’t). The rise time is pretty slow since the pull-up is weak, however I didn’t observe any weird GPM readings or multiple interrupts for each pulse.
The log files seem to be recording rain sensor events, so if this input is used for flow we should insert flow rate in the log once the valve is turned off instead of a rain sensor event for every pulse (fills up the log with those quickly). I haven’t done that yet.
Ideally the system would know if all valves are off, and after a predetermined time (lets say 1 hour) it see’s a couple pulses then it would email or text alerts to someone that there is a water leak. Our faucets outside are on the same lines so when we wash the car etc we may want it to only alert if a leak is detected for at least a certain amount of time.
If a valve is turned on, and if run >2 minutes, then the flow rate would be recorded and compared to perhaps a user defined range. If it goes outside that range, email/text alert would be sent out that the zone has a problem. This is great not only for water line breaks or heads that break, but also if the valve doesn’t turn on then you could detect underflow too.
Here is a summary of the lines of code I added to test the flow sensor. I’m using one from NETAFIM but just about any flow sensor that handles the flow rate of your irrigation system with a reed switch output should work. A good irrigation system flow sensor will cost a couple hundred bucks but well worth it.
Here’s the code additions. If interested I can post the .cpp file.
#define FLOWSENSOR 1 // if flow sensor installed – RAH
void flowsensor(); // ISR to handle flow sensor interrupt RAH
attachInterrupt(1,flowsensor,RISING); // INT1, flowsensor() ISR, rising edge trigger
volatile long flow_stop,flow_start = 0; // RAH used for flow sensor
volatile float flow_gpm = 0; // RAH used for flow sensor
void flowsensor() // ISR to handle flow sensor interrupt
flow_stop = millis();// get time in ms for stop
flow_gpm = (float) 60000/(float)(flow_stop-flow_start);// calculate GPM, 1 pulse per gallon
flow_start = flow_stop;// set new start time to last pulse
// process LCD display
#if defined(FLOWSENSOR) // put GPM on display when valve is on
os.lcd_print_pgm(PSTR(” GPM “));
Attachments:March 7, 2015 at 7:21 pm #35873
Really glad to see that you got a flow sensor to work with OS, and thanks for sharing the code. I’ve done a bit of research myself a while back, and the flow sensor I tried (it’s a very cheap one like this: http://www.amazon.com/1-60L-Effect-Sensor-Counter-FS300A/dp/B00HR6BTYQ) sends out pulses very quickly and I didn’t think it was feasible for an interrupt pin (i.e. may be losing a lot of pulses). The one you used seems to pulse at a much slower rate and it’s perfect for an interrupt pin. Now that the signal can be read reliably to OS, the rest (display, logging etc) is just a matter of software changes. So I think this is a big step towards having flow sensor officially supported by OS firmware.
One quick question: where did you buy the NETAFIM meter? I would like to get one to test as soon as possible.
In terms of the hardware, my plan is to remove the power switch currently on OS and use that opening to fit a small connector wired to the flow meter. In the new batch of OS enclosures, the silkscreen above the power switch opening has been removed, particularly for this purpose 🙂March 7, 2015 at 8:20 pm #35879
It has been a few years, I think I bought mine from a local irrigation company and I can’t remember the name.
For almost everyone I would think they want 1 gallon per pulse. And choose reed switch/gallon (not the photo diode). Meter size would be based on your max flow rate.
This website shows pricing on some : (might want to google search and compare prices though)
Note the 3/4″ water meters go from .9-14GPM. Some of my valves are running with around 20GPM and I have a 1″ meter (spec’d to 30GPM. With a larger meter your accuracy down to <1GPM suffers a little.
Here is the 1″ meter:
There are plastic ones too but I recommend the metal ones unless you just want to play with it in the lab and it won’t have to survive outdoors for a while. (metal one’s aren’t much more expensive anyway).
If someone knocks off a sprinkler head or something i usually see quite a few GPM increase (~5GPM) and it’s pretty obvious.
It is a fantastic tool to determine how much money you are spending per zone. I had perl scripts run to output cost of each zone. Then I focused on the most expensive zones first and figured out how to minimize water usage there. The zones on the longest aren’t always the ones using the most water 🙂 It would be great if we could come up with a strategy to capture flow rates, and generate report(s) and alerts . I just tried modifying the write_log function and now I realize I can’t write out a string like I hoped with that (was going to put in the logfile the flow rates). Might create a new function that just logs it and another file I’ll put in for flow rates for each zone (min and max) so it triggers if it’s outside those ranges… not sure how easy it will be to send out an email automatically or if there is enough memory.
You may wish to keep the protection circuit input to ground (for the flow sensor, from your rain input circuit) since there will be a long wire from outdoors (flow meter) into the OS. There are IC’s out there that could clean up that slow moving signal too. I’ve only been playing with it on the OS device for today but so far it looks repeatable. I compared the flow rate measurement on the OS to the Cyberrain logs I have and they are well within +/-0.3 GPM.
I will probably be installing another OS device and a neat feature would be for it to get the flow rate from the main OS device as an option (I have one pressure regulator and one flow sensor for all of my 30+ zones).March 18, 2015 at 11:55 pm #36103
I have been playing around with this in Python with these meters… http://www.dwyer-inst.com/Product/Flow/WaterMeters/SeriesWMT2 the meters seem very sound, the cap is a bit flimsy and the sensor wires probably need to be protected better. They are delivering a very good square wave over 200 feet of cat-5 cable. (I’ll dig out an oscilloscope trace if folks want to see it) The prices seem to be pretty good, too. A 3/4″ meter for $87.50.
I would love to see the log contain the actual number of gallons delivered per zone activation. The average flow rate is very interesting to see for tracking gushers, drip system problems, pressure problems, etc. deviations in flow rate at a certain level should trigger some action… perhaps shutting down the master valve.
I also want to see the flow meter’s data even when the OS circuits are not running… the automatic pool filler (which I may want to switch on or off with its own sprinkler circuit), or other things.
I have a 1 1/2″ 100 GPM flow meter that pulses per 10 gallons… too much for my application. I also have a 3/4″ model that pulses per .1 gal. This gives a much nicer flow, and allows detection of the end of the session much better.
I don’t need the big meter, and would be happy to sell it at a discount, if anyone needs to work with the higher flow rates. (the meter isn’t rated for pool water, I found out after purchasing )March 19, 2015 at 6:39 pm #36116
@munnecke, the link you included seems to be a page that doesn’t exist. Are you referring to this meter:
I was actually thinking of buying this meter a while back but it was out of stock. Just found that it’s still available so I will be getting my hand on one to try out.March 19, 2015 at 6:54 pm #36120
I have implemented flow rate sensing and logging. The basic algorithm is the following:
ISR to run on rising edge of flow sensor (ran it into the rain sensor input).
Right when the valve is turned on, the time is captured. After 90 seconds, the first rising edge time is captured in msec. once the valve turns off, the last rising edge time is subtracted from the first rising edge (after the 90 seconds) and this is divided by the # of pulses between the two edges (minus 1) for the # of gallons (mine is 1 pulse = 1 gallon). Averaging across the time works best and gives extremely accurate flow rates, and removing the first 90 seconds or so is very beneficial due to the large flow rate right as the valve is turned on (if the pipes are empty).
The latest code modifications are storing the information to the SDHC card in a new directory and file, and I’ve modified the server.cpp to handle sending out the global variables as well as sending out the log data from the SDHC card (SDHC card logfile output still debugging).
The logfile I plan on storing the following:
valve #, start time, total flow time, total # gallons this valve, flow rate (gpm)
I have researched how to send email and so far haven’t found an example that I could dive right into yet for the OS, but ideally, if a leak is detected or too low of flow rate is detected, an alert would be sent out. If that isn’t too easy I’ll write a script on my droid phone to check it daily and alert me that way by pulling the logs. Detecting flow rates when the valves are off is also beneficial for detecting if a leak or other item is running.
If this information would be added to the existing logfiles that would be ideal, I’d rather not implement something that will remain custom and not be part of the standard. Ray any suggestions on how you would like to implement it in the future, and how can I help?
The meter you suggest Munnecke looks neat, similar to my netafim one but lower in cost. Looks like the sensor for the GPM pulse is very similar too , just a magnet/reed switch.March 19, 2015 at 8:47 pm #36124
Ray: yes, this is the sensor family I am using http://www.amazon.com/Dwyer%C2%AE-Multi-Jet-Pulsed-Output–C-03-1/dp/B00D2ME5MC I am a little ticked at them that after talking with their tech support, they ended up recommending a meter with a 10 gal pulse rate. This is way too slow of a rate (some times one pulse every 90 sec) but they won’t exchange or restock it for a 1 gal rate. So 1 gal (or even .1 gal) is the way to go. It’s hard to figure out when the flow has stopped with the longer pulses. I’ve attached a DSO trace of the pulse wave form over 200 ft of cat 5 cable. I seem to get some spurious interrupts that I don’t understand or can trace on my Bitscope.
My configuration is that my irrigation master line branches off from my house water line just after the main meter. I am installing a Dywer flow meter on the irrigation line so that can measure all of my backyard water usage (including an auto pool fill valve, vegetable gardens, hose bibs, etc. I am using two OS controllers for my main sprinklers. It would prefer to use just one controller and slave the other circuits to an extension box, but that would be a 300ft run. In the past, I’ve been sprinkling odd days on one controller, even on another. But with the California water shortage, I’m supposed to water only on certain days. So, now I have to figure out how to synchronize the two controllers.
So, I would like to see my flow data on both controllers, and also to see what is happening when the circuits are off (very important for leak detection.)
Attachments:March 19, 2015 at 9:05 pm #36126
Rhillman: I like where you are going with your flow logging. Have you considered how to report flow that’s not associated with a specific valve? (i.e. a slow leak or gusher, or other sources drawing water through the meter?)
Have you considered publishing your flow rates via MQTT? http://mqtt.org/ this is a very simple and lightweight publish/subscribe framework and would allow integration with other devices. For example, you could publish your rows of data to topic “Rhillman/home/sprinklers” and then have your phone (or another OS controller) subscribe to the same topic to trigger an alert.
It would also be nice to track the actual cost of the water for logging. This can get complicated with tiered water rates, but I’m happy to count all water usage at the highest rate for the billing cycle, and not worry about the cheaper water at the beginning of the cycle.March 20, 2015 at 12:03 am #36130
Munnecke: Our hose faucets/bibs are on the same main lines with the flow sensor, so for example if we are washing the car, the flow sensor registers flow rate. I was thinking about having a timer such that after a predetermined amount of time, if the flow rate doesn’t go down then it would trigger and send a message. I actually had a hose hit by something falling in the wind at night and it broke a hose connection and had some damage to my driveway and $200 in water bill increase from just one day. Would have been nice to be notified within an hour for example (via text etc). I’ll look at MQTT but I don’t know how easy it would be for the OS to communicate with MQTT. As for your flow rate sensor, you should ask the company what wire to use. I’m using a shielded wire where the shield is ground, and the inner is the signal and I don’t seem to get any glitches, although the length is only maybe 25 feet. Did you connect it to the rain sensor input? perhaps the pull-up is too strong, or a series term resistor may help. Looks like there is a lot of noise on the cat5 cable. I think cat5 is usually for differential signals and is UTP (probably unshielded twisted pair) and unless your receiver is subtracting the two wires I’d go with a shielded cable with shield grounded.
I have a similar scenario where i’d like my main controller to communicate via TCP/IP to the secondary controller… Since I have one flow sensor covering both OS’s.
Once the data is logged and a computer can access it, then we can run perl scripts etc and grab the data. I have a script that shows all my zones and how much each one costs per zone based on actual water usage and flags which zone may have trouble (outside of set thresholds).March 20, 2015 at 12:11 am #36131
Ray: the log data stores
program index, station index, duration(sec), end time ,proposed add-on GPM
I’d like to add the element being the flow rate in GPM. What do you think about this, and it’s compatibility with the APP’s, website, etc?
I was going down a path of storing similar data in another file, along with GPM but it would be more straightforward to add it to this one. The # would be a floating point number like 19.28 for 19.28 GPM. Also I’d like to avoid going in a different path than however the formal release would be- can you provide some insight/suggestions and i’m not sure who would be implementing it and how i can be of help?March 21, 2015 at 10:33 pm #36175
Ah, sorry, just came to this thread after replying to you in a different thread. Will definitely consider adding the support for flow measurement in future firmware code. If you want, you can post your suggestions/proposals here, or email me directly at [email protected] to discuss how to proceed further.March 25, 2015 at 1:00 am #36251
I am very interested on the flow sensing feature, if you are willing to work on it Ray I can send you a data industrial flow sensor as soon as you let me know. I would also like to see the progress of the E.T based system and I can help with it, I am very knowledgeable with that.March 27, 2015 at 1:52 am #36296
Sure, I’d be happy to receive a flow sensor for testing. Please contact me directly at [email protected] Thanks.March 28, 2015 at 12:17 am #36317
Attached is the two files modified for the flow sensor SW mods using the rain sensor input and an ISR to trigger on the rising edge of the sensor pulses. It seems to work pretty well so far.
I tried to put my initials in the comments // RAH so that you could easily find the changes. Essentially the main.cpp is changed to add the ISR, update the LCD display if GPM is measured, and added to the write_log function so it writes the GPM as an additional field in the normal log file.
To calculate GPM for the LCD display it just takes the last pulse minus the previous pulse time to determine how long it was for one gallon and calculates GPM. For the logfile it calculates the average GPM starting after 90 seconds of the valve being on (the max time it should take to fill the line typically), until the valve is shut off, for greater accuracy in measurement.
The opensprinkler::set_station_bit was modified so that when a valve turns on, we clear some variables, and when we turn off the station, we calculate the logfile gpm average, which later gets written to the logfile.
Any questions or suggestions please let me know.
As for how to detect leaks, not implemented but brainstorming here: need to detect slow leaks which would look like a certain # of pulses every hour (i.e. no hour in 24 hours without some flow rate pulses). For a faster leak, for 60 consecutive minutes in the day, each minute had at least one pulse with no valves on. So if you were washing your car, it wouldn’t detect an error as long as at least one minute in 60 minutes there was no flow.
Perhaps the harder thing will be to somehow get a text or email from the OS without running RPi etc.March 28, 2015 at 12:21 am #36318
Ray, Looks like the file attachments were not permitted so I’ll just email you the files.April 2, 2015 at 3:11 pm #36438
Ray, I emailed you some days ago, I dont know if you got the message or not; please let me know. Thanks.
My email is the same as my user name, gmail is my server. in case it went to spam.April 4, 2015 at 10:10 am #36463
Yes, I got your email! Sorry about the delay, this has been a very busy week. I will reply this weekend. Thanks.
- You must be logged in to reply to this topic.