Forum Replies Created
-
Posts
-
Hi Ray, excellent idea about having your server host the custom scripts for weather adjustment. Perhaps some would use your Zimmerman default, some would design their own, and others might see a custom script they would like to use (in case they don’t want to design their own). Then you could have a list of the custom ones people submitted and see if others want to use those or modify for their own needs? If you could host the script I’d like to write one that takes into account the day before, the day of, and the day after for humidity, temperature, rainfall, etc. I looked at ET and it seemed quite complex and I’m thinking all that people need is a relative change of watering based on those 3 parameters typically (humidity, temp and rainfall, actual and forecast).
rjalex – perhaps you could modify your OS to check at a certain time of the day only when your wifi is on and remember that watering % for the whole day. Also having tomorrow’s forecast might be of benefit to you even more since you would only be checking the weather once a day instead of throughout the day. (i.e. if no rainfall yesterday or today yet, but it’s going to rain tonight or tomorrow you wouldn’t probably want to water anyway).
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.
I thought the GUI/App would not like the additional data but it ends up I was putting the data in the wrong order (epoch time spot instead of after it). So now that I placed it after it here is what it looks like, and seems to work on the HTTP GET for the log as well as the GUI/API seems to work and just ignore the extra GPM data. With the HTTP GET it passes all the data including the additional GPM info (see below partial data from the HTTP GET):
[99,4,10,1426886894, 8.23]
The 8.23 is the GPM measured.
If you think this will interfere in the future we can move it outside of this standard logfile. I tried creating a new logfile but then had to create utilities to get the data, etc and then moved it back to the existing logfile . So ideally if we can keep it in the same logfile to avoid duplication of data/functions I’d probably prefer that.
FYI allowing the logfile to have a couple more fields and display those in the GUI would make custom logging/mods easier for others also in case someone wants to log other items rather than just GPM for each station run (along with the standard data).
Samer: I have a flow sensor on the OS logging data. I’d like to add it to the existing log file so one entry would have the last run program, last run station, last run duration, and average GPM for that station. When I have it add the 4th field, the GUI and web access ignores the entire line. Could you please consider either displaying the 4th field as GPM (floating point) or at least make it so that it doesn’t ignore the logfile if a 4th field is in there? Or would you prefer the gallons per minute be logged in a different manner?
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?
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).
As a side note I had a program set to run Sunday at 1am (yesterday).
The program never ran. Perhaps related to the wrong day of the week? However since it occurred on a time change day:
I’m thinking for future reference, between 1am and 3am sunday morning start times might not be a good idea since time changes happen twice in a year then, although probably not what caused it to skip watering this time.
Would you consider a HILLMAN algorithm as an option people can choose too? 🙂
You don’t have to call it HILLMAN you can call it XYZ or whatever.
If the MEAN temp gets figured out then I’d just like 1 degree change = 1 percent change, and 1 % humidity equals 1% watering change.
where the temperature used is the MAX, for the day and not the min or MEAN.
I don’t have a server to run the script on.I agree that the Zimmerman algorithm as documented is working as documented (from the data it displays). However, Wunderground calls out my min temp of around 54F and the App is calling out my MEAN (i.e. average) temperature to be 54. I believe either Wunderground or the script is getting/giving the wrong temperature value(grabbing min instead of mean). Realize my high for the day is 83F. Mean temperature can’t be 54 (ok at least not in my city )
I hope you see the problem with having almost zero watering on an 80+F weather day. I hope it gets revised, otherwise i doubt anyone will use that feature without regrets.
Two of the main reasons I was interested in the OS design (ok 3) is 1. open source, 2. flow rate measurement/customization and 3. weather adjustments
For now I’m adjusting watering % manually so my plants don’t die 🙂
If that gets figured out then this blows away my previous ‘smart’ irrigation controller.
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.
http://www.netafimusa.com/agriculture/products/watermeters-m-order
This website shows pricing on some : (might want to google search and compare prices though)
http://www.irrigation-mart.com/default.aspx?page=item+detail&itemcode=FM-36M201T
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:
http://www.irrigation-mart.com/default.aspx?page=item detail&itemcode=FM-36M251T
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).
