Forum Replies Created
-
Posts
-
I agree with rjalex comment. I’ve had to modify the OS code down to 2% for each degree F, and prefer that. My last smart commercial irrigation controller used the predicted high temp and 1% for each degree F. The Zimmerman algorithm uses the MEAN/Average (not MAX) temperature and 4%. It seems to work pretty well with 2% on the mean temperature. I do believe it would be great if we could plug in scale factors for each weather parameter to adjust watering. The OS does get a few of the parameters, then you can code your own based on those parameters, but again it would be nice to have more flexibility on the OS to allow the user to configure it.
The zimmerman algorithm takes into account only one days data point for temp and humidity even though most people don’t water every day (i.e. water every 2nd or 3rd day). Uses average humidity, temp from previous day and precip from yesterday and today. Highly recommend we take into account (or have the option of) humidity, precip. and temp for yesterday, today and tomorrow with a percent chance of rain % threshold to not water for today and tomorrow (forecast).
So having each parameter roll over 3 days for example, with a baseline for each (like 80F or 70F) and a multiplier like 4% or in our case 2% for each degree F would support more customization and more accurate & water savings.
FYI wunderground kept returning summary data for MEAN temp incorrectly that OS was using (it appeared to return MIN temperature instead of MEAN temperature). I contacted wunderground via email and a few days later it seems to have stopped doing that. Not sure if anyone else observed this a few weeks ago, but having the MIN temperature for the MEAN, and having 4% scaling factor, it would get to 80F outside and decide almost not water because the low was 55 at night.
It would be helpful if the watering was disabled if rain is expected a day later also (above a certain % chance of precipitation for example). Don’t want to water today if it’s going to rain tomorrow.
The good news is that sunday I was able to generate a report using HTTP GET and show how many GPM each station is and how many total gallons, from the existing logfile. However when I ran the script again today to get the logfile from this morning’s run, it only displayed about 1/2 and only sometimes, other times it never returned anything. Perhaps the added field is causing some instability?
Attached is log 16516 which is sunday, and looks good along with my perl script report called “sunday report ok.txt” that just takes the logfile and formats it. In 16516 you can see the last field which is GPM.
Log file 16518.txt and “tuesday report cut off.txt”. You can see 16518.txt has all the data in there, but the HTTP GET at the top of the tuesday report stops early so my formatted script output also stops early.
The modification to add flow sensor data is pretty easy, just the ISR and of course adding the one additional field when it writes the data to the logfile. I can provide the code for that if you like.
The Min GPM is out of the entire report for that valve (over up to however many days the report was generated for) what the min value was, and the MAX GPM is the maximum GPM observed over the entire report run time for that valve. Last GPM is the last GPM measured on that valve, helpful to see if the underflow/overflow condition still exists. Might add a low threshold and upper threshold for the script to flag zones that are too wide – where last GPM is outside a set range. Also plan on calculating cost per month based on # of days in the report and scaling it with the tot gallons for each zone.
The actual #.txt logfiles I took out the SDHC card and read it on the computer which showed they look right even though the OS isn’t returning all the data.
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.
I think 2 days a week watering is only applied if your water supplier doesn’t already have a restriction plan in place. However, I do like the idea of adding this feature. It appears that although the watering percentage is performed on a server/script remotely, some of the other values are being passed back to the getweather_callback function. I haven’t tried this yet but this is what i coded up so far, essentially making it easy to modify the weather.cpp based on the watering algorithm you want (in my case I do not like the temperature to affect the watering percentage where 1F = 4%) so I’ve changed it to 2% so it’s less agressive based on temperature fluctuations (anyone else prefer a less sensitive temperature/% factor than 4% also)?
If the remote server could provide additional data to the OS then users could modify in the OS code for the watering algorithm….? If anyone see’s a problem or has a suggestion with the code changes attached please let me know. Alternatively it would be great to have a few settings we could change such as baseline temperature, and multiplication factor without having to change the code. My last irrigation controller allowed you to specify sensitivity of temperature and humidity along with the baseline values and that seemed to be flexible and work great.
HI Tom, Ray,
Our flow meter is a netafim flow meter we used for the cyber-rain irrigation controller. Most of these have what’s called a pulse reed switch that pulses the output after every gallon.
Should be able to just have a pull-up resistor connect to the switch such that the switch pulls the signal down when pulsed. If you count the pulses per time period you would know the flow rate.
With your newest design if you could have some area on the board to wire this in that would be great.The flow rate when the valve is just turned on is not a good indication for leak detection. You have to wait until all the lines fill up and the air is out. This depends on many factors in your system but is usually 20-90 seconds. Then the system can sample the flow rate once stabilized and give a very accurate flow rate. It won’t find a very small leak, but does tend to find if a head is broken off or a pipe has a crack in it. It has helped us tremendously and saved us a lot of money by detecting problems early on.
One of the other posts someone mentioned using a pressure sensor for detecting leaks. I don’t recommend this. Most irrigation systems have a pressure regulator and it’s primary goal is to maintain the water pressure even if you have higher or lower flow rate. Maybe there are some isolated situations where a pressure sensor works, but we have had great luck with the flow sensor.
To detect leaks the best way we have found is to use 1 good flow sensor installed before all your valves. Then when you turn on a valve you can check the flow rate for that valve. Also if your yard has hose connections and someone leaves that on, it should see it as well – so for example if it see’s a flow rate for more than X minutes after the last valve is off then it could email you. Also this helps detect leaks in the main lines BEFORE the valves. And if a valve fails to turn on, you would get an underflow condition so you would know one zone isn’t working properly.
Suggestions for the next OsPI version in order of interest:
1. The 74HC595 has a master reset input that looks like it’s not being used right now. Perhaps a watchdog timer IC connected to this such that if the Rpi freezes (doesn’t toggle the watchdog) it would at least reset all the valves to off. Future ext boards could include this reset signal.
2. Flow sensor input so we can record flow rates of all the valves and know if a leak occurs or valve isn’t working.
3. Someone else suggested a way in another post to feedback the serial data back to the Pi so we can verify the shifted data and connection to the valves.
4. current monitoring (could just monitor all the current through all the valves, so you would only need one current sensor). A little trickier with 24VAC.
5. For the RTC can’t it access the internet to get the latest time/date? (if internet is available?)If the rPI stops working (corrupt FLASH etc) is there any way to be notified or do we wait till the plants start looking scary?
Was thinking about having my droid phone daily ping it and alert if no response detected.Hi Ray I only see one relay and it looks like it’s connected to the 24VAC to switch that in or out? (or maybe I’m looking at the wrong schematic?)
Could you point me in the right direction where the relay is that will allow me to short two wires together on my garage door opener button? Thanks.Hi Ray, the concern about signal integrity is the rise time of 4ns that may ring quite a bit. Adjusting the frequency won’t help with the rise time or impedance mismatch, but if you haven’t observed any problems I may buy one and put a scope probe on it to see if my simulations match reality.
Thank you for the info on the relay, sounds great. As for current sensing – if we know the water flow rate is reasonable then the valve must be working. Flow rate is most important because I have a lot of area to cover and a busted pipe somewhere is important to fix quickly. I plan on having it check a certain flow rate for each valve and if it’s outside that range too low it would notify me, if too high it would notify and skip to the next valve.
I’ve observed the flow sensor connected to my cyberrain system and essentially when you turn on the valve you get a lot of water flowing until the line is full, and then it stabilizes once all the sprinklers have the air out. This could take up to 2 minutes in my case when you are dealing with longer /large pipes. So usually you can set how long it waits before it samples the flow rate.
Also the flow sensor is helpful when all the valves are off to let you know if you have a leak somewhere before the valves. I had a problem with one hose bib/faucet opening up full blast all night and it would have been nice for something to text/email me an alert if the water was on for more than a certain number of minutes while the valves are off.
For water conservation right now I’m exporting the reports from cyberrain and running a perl script to calculate how much water each zone uses and how much it costs per month, along with any deviation on flow rate compared to last month (in case a leak is starting to occur). I hope to integrate some of these features into your opensprinkler so it’s more automated and share if someone else is also interested.
Sorry for the long post – one more thing. Not sure if you considered perhaps having a second opensprinkler on the network that is a secondary along with a primary controller. So for example in my case I have two controller locations. It would be nice if one location was the primary with 32 valves, and the secondary location was another 32 valves. Then the secondary location could just take commands from the primary one in terms of open valve X etc. while the primary controller could run all the schedules and ‘control’ more than 32 valves. I suppose alternatively you could just run both opensprinklers separately instead of communicating together but this would allow a single schedule so you don’t have to worry about the two controllers watering at the same time and messing up the flow sensor readings etc (if they use the same flow sensor which mine do). Maybe not a lot of people wanting more than 32 zones or more controllers though…
Thanks for the reply and also for such a cool product. Looking forward to it!
