Forum Replies Created
-
Posts
-
The logic is the same but where the calculations are completed is different. My original script did everything its self, off controller. Now the adjustment is made on the controller using the output of the script similar to how the Zimmerman method works in the current firmware (216)
I’m provided the firmware above as is…it may not work correctly, but at least some other eyeballs on it may lead to a better end result.
I attached a mostly working…no guarantees…zip containing firmware that incorporates ET directly into it.
To use it you have to have an SD card installed on your controller. It will not work with OSPI, I don’t have one and didn’t bother to make the changes for it.compile and upload the firmware to your controller
After it is loaded and running things will change a bit for creating and loading programs. As the current APP/UI will not work with it for a lot of features.
1) Connect to the IP of your controller and change your password
2) set your time zone and location
3) add your weather key
4) hit submit
5) browse to h t t p ://OS-IP/cp?pw=MD5-Password&pid=-1&v=[195,127,0,[20540,16444,12318,8252],[60,60,60,4,5,6,7,0],[0,0,0,1,0,0,1,0],[50,150]]&name=Weather1mmthis will make a program to run everyday using et with starttimes based on sunrise and set after the duration is plant height 0= <4″ 1= >4″ following that is min and max mm to water per cycle
6) go to the controller turn off the power, hold down B3, and turn it back on.
7) click B3 until you reach weather algo: and set it to 3after that you should be running, if you want to see the python script I can make that available, right now it is messy but works fine and is used as default. Use /su to change back to weather.opensprinkler.com and use another weather algo.
Everything should work but I make no promises, use entirely at your own risk, and modify as you see fit. I do not have the time to support this…I will respond to general questions but it may take a while.
You have everything worked out correctly…one note the ET, 8mm in your example, would cause your system to run for 8min, not 4.
ET*(timeTo1mm)=water run time
For the distances you should use ac equipment. Pushing low voltage dc over those distances would require pretty large wire. For ac the standard multistrand sprinkler wire will work fine. The pump can be wired just like a valve with a starting relay near the pump end. In opensprinkler set it as a master. It will then start the pump when tha valves open. You can set positive or negative timing delays for the master to make sure you don’t air lock the pump or valves.
1″ valves are pretty good for drip lines, beyond that size the price will take a large jump upwards because they are not the “common” type used.
Make sure the pump relay can use an ac signal to trigger, if it can’t full wave rectifers are cheap and common, just add one right at the relay.
Other than that it seems like you have the idea and hardware in place to run just fine with OS. You will need expansion boards to run 24 zones, and the master(pump) will use a zone, just keep that in mind when purchasing.
Hey Ray not to thread Jack but I have a lot of experience in the garage door industry, if you need any pointers on legal requirements for remote operating systems shoot me an email. At the very least UL325 compliance in the US will help fast track any commercially available product virtually worldwide. Light and sound alarms are usually the part that slows residential acceptance. I also have a lot of experience installing accessory devices on all major opener brands, so I could also provide help with how-tos and directions.
Just shoot me an email, or private message if I can be of assistance.
You can do anything you wish with the code, please note portions are directly copied from other contributers on the forums here, and external libraries are used, so please respect their work and leave credit where credit is due. I have not uploaded the firmware changes yet, as I bricked one controller with it. I was able to recover it after a couple days of trial and error, but I really would prefer not to leave others in the same situation. I have very little time to mess with my own, I more than likely would be unable to help others.
Honestly the concept is to take everything program related in the nvm and move it to the sd card. Then use the python script to work in a manner similar to the Zimmerman method.
Here is the link to the files posted
Hope that helps
Search for penmon monteith eto on the forums, I made up a script a while back for handeling the python/server side and a hack to make it work with 2.1.4 firmware. I have personally made an effort to recompile the firmware, for having it run internally, but I don’t want to release it publically for fear it may brick someone’s hardware because they believe it is plug and play ready. If you are interested in testing knowing it may ruin your unit I can email the firmware to you.
I use a setup similar to what I described to fill a pond when the water gets low using a dry contact switch on a float and a hall effect flow meter, in the 3 years it has been runnning I never had the flow meter stop in a open position. I honestly hadn’t even thought about it till now.
I may have to rethink that setup, but I’m also intrigued by the fact it hadn’t happened. I wonder if the magnetic pickup causes it to stop in a certain position every time. I’ll tear in to it since winter is on its way in and I wont need to fill the pond.
As far as the rain sensor masking the flow sensor I don’t think it would be a problem since rain would inherently prevent flow, we would only loose the ability to detect leaks when it is raining.
Would it be possible to run the rain and flow sensors on the same wire then in firmware count puleses while a program is running and look for a constant high for rain while no program is running. A diode on the sensor wires should take care of backfeeding either sensor, and we would get the benefit of both sensors without the need for messing with the board directly.
This would also allow an alarm condition for leaks, or open valves while a program is not running because a pulse detected outside prescribed times would indicate unplanned watering. It would also allow for stopping a program if the ‘pulse’ goes solid indicating way too much flow or rain.
Sorry about the long delay and no responses, life has been quite hectic. I’ll get back to working on this project later this week. I should have something useful by the weekend. The few test runs I’ve made look okay, now I just have to work on polishing everything up, and remove some of the debugging portions of the code, as it is quite verbose and annoying.
According to the text at the top of every file in the OS project GNU General public license v3 or later.
I didn’t see anything for the app so on that I’m not sure.
Min and max combined take less cpu time than ‘if’ so:
if(max(min(flow,max_threshold),min_threshold))!=flow){stop};
would be faster, and easier (clock cycles not readability) on the arduino based systems. Even though I don’t know how close everything is running to max capability of the chip, allowing for future features is nice.
@tom how would the OS know while scheduling that it could place several zones together? Or were you thinking A) run a test and then schedule them, B) have it continue to add zones till capacity is reached?You could do this by placing expansion boards in the valve boxes, they would of course have to be sealed for water intrusion. You may have to boost the signal on the wire as well which would require a bit of electronics knowledge.
The problem you will need to overcome for a bus system is a processor on the valve end to receive the signal and open the correct valve.
Samer after midnight the data for daily averages resets on the weather sites, though historical data should balance this out it may be a factor. Also there is a brief period after midnight and before the first update where some of the data is absent or null. If you are checking once per hour this may allow invalid data to persist for the first hour of each day.
Just a couple hypotheses, but looking at your code and the Zimmerman calculations, I don’t see where it should water at 0%…unless maxemanuel is seeing the 0% after it watered, and it watered based on another percentage/data set, which of course the log data would reveal.
In the ‘defines’ file station names are set at 16 bytes, the front-end may be restricting them furthur or certain characters could use more than one byte. If you don’t need as many programs you could change the value and compile the firmware yourself. Just note that on the arduino based OS your stored data looks like this:
/** 2KB NVM data structure: * | | | |---STRING PARAMETERS---| |----STATION ATTRIBUTES----- | | * | UID | PROGRAM_DATA | CON | PWD | LOC | URL | KEY | STATION_NAMES | MAS | IGR | MAS2 | DIS | SEQ | OPTIONS | * | (8) | (996) | (8) |(32) |(48) |(64) |(32) | (6*8*16)=768 | (6) | (6) | (6) | (6) | (6) | (62) | * | | | | | | | | | | | | | | | * 0 8 1004 1012 1044 1092 1156 1188 1956 1962 1968 1974 1980 1986 2048 */You may have to look at defines on github to see that formatted correctly.
Anyway anything you add in one place will take from another till you reach the 2048 byte limit.
As far as PROGRAM name size it is defined in program.h, you could change the number to something higher there but this would cause you to run into the 996 byte limit for program data with fewer programs. If you don’t need as many programs this is fairly safe to modify slightly. Just be very mindful of how it increases the size in program data. Currently it is 14×12 or 196 bytes, 20 byte names would drop you to 9 programs. So not a lot gained by creating longer names.
Evaporation is the larger of the results of the following equations
E0 = 290Dw((Dr-Dw)^(1/3))(Ww-Wr)
E0 = 0.0346(pw-pr)where:
E0 = evaporation from pool, pounds per hour per square foot of exposed surface area
Dw = density of air saturated at water temperature, pounds per cubic foot of dry air
Dr = density of air saturated at air temperature, pounds per cubic foot of dry air
Ww = humidity ratio, air saturated at water temperature, pounds per pound
Wr = humidity ratio, at air temperature, pounds per pound
pw = water-vapor pressure in air, air saturated at water temperature, inches of mercury
pr = water-vapor pressure in air, at air temperature, inches of mercuryThe above I got from somewhere to calculate pool evaporation for indoor pools and adpapted it slightly. If you account for rain filling, it actually works quite well for running a fill system. You will of course have to convert the volume measurements, to run on the sprinkler controller, but that should handle the majority of the ground work. I personally had a dedicated pump controller that used those measurements.
Hope it helps a bit.
Sorry I missed the triple = comparison. You are absolutely correct that should compare value and type. So the problem isn’t there, and after a second look, that function is checking weather data, not the values of the weights. I read way too fast.
We would need all of the weights and the temp, humidity,and precip values from weather to figure it out.
I think the validateValues function used by the weather.js has a flaw where it invalidates 0 when it is compared to null…then when the scale is calculated an invalid value causes the scale to result in 100. This would be the only cause I can find for the issue.
I have modified the script to search backwards for the most recent ET file, it a will also create a base 0’d file if the directory is empty. Currently I’m working on modifying the OS firmware to work entirely off the SD card allowing for more accurate programs, more programs, and better history from which trends can be recognized and adjustments could be made. I haven’t posted it to github yet because I don’t want to brick anyone’s hardware. Currently it is a pseudo functional alpha version. Another week or 2 and I should have a version worth posting.
I’ve noticed this same behavior, it doesn’t seem to affect the actual performance (as in it doesn’t run), however, you will be unable to set a start time through the app if you wanted to change it for some reason you would need to use the api commands.
Since it calculates nearly everything based on yesterday’s data I run it about 10 minutes after midnight, to account for time differences. The running every 15 minutes does nothing after about 1 am. My best guess as to why this happens is data and averaging being finalized by WU. Their data will vary slightly for the “yesterday” portion of the JSON for about an hour.
The only other time to run anything would be just before a set run time to make sure the wind, temp, and conditions (precipitation), are still acceptable for watering.The -1 is the start times in minutes from midnight if a start time is needed. -1 means disabled. This matches the JSON output when viewing the programs using http://os-ip/jp?pw=xxx
Crop is a 0 or 1 for grass or shrubs respecticvely. If a zone is primarily flowers 1 should be used for that zone. Primarily grass or low growing plants (less than about 4 inches high) should use 0. This will denote which ETo value to use.
Ya I’m sure my drip emmiters had the L/hr listed on them at one point, but at 15 years old, it has escaped me, and measuring the up and coming subsurface irrigation systems will prove difficult. But someone has already figured out the code for water flow meters, so I’ll give that a look for inclusion.
I wasn’t meaning to sound rude with the joules thing, it’s just a small measurement and would make for some really large number calculations. But being base 10, kilo-joules could be used like kilocalories on a cereal box.If you look at the script in the first post it has a library in the zip for PM-ETo, solar radiation has 3 calculation methods available each with varying degrees of accuracy. The main script uses them in order from measured to least accurate, depending on data available.
