[Roger]

Also, see this thread: https://opensprinkler.com/forums/topic/opensprinkler-drops-wifi-regularly/

[Roger]

I, too, had this problem and found that the only solution was to reboot OpenSprinkler. I also run HomeSeer, and developed an event to recognize when OS was offline to warn me.

I tried any number of approaches, including an access point that was just 10 feet away. I finally gave up and switched to OpenSprinkler Pi. The Pi has a much more robust TCP/IP stack. Haven’t had the problem since, and the access point is now 20′ and two walls away. (My original OS installation had a wired ethernet connection to a TP-Link powerline connection. That worked just fine, although I really dislike using powerline for communications.)

Incidentally, I’m impressed by the reliability of the wifi connection on the OSBee. I have two of those, both out-of-doors, one of them using solar power and the other powered by the 24VAC sprinkler power (bucked down). Even in the worst of winter here, -20 degrees F in the early morning, both of these continue to communicate.

Rog

[Roger]

After burning up several transformers (due to a short in a valve), I switched to one of these: https://www.amazon.com/dp/B083R621RV. Overkill, for sure, and I fused the circuit to OS at 1 amp. I don’t know what the safe current for the OS module is. For the one situation in which I have more than two valves in a zone, I added a small relay that switches current from the same transformer, but fused at 4 amps.

Rog

[Roger]

The watering level is the result of the weather over the previous 24 hours and has nothing to do with whether or not you watered. It’s always about the evotranspiration that occurred in the prior 24 hours, which doesn’t change just because you watered. Watering just makes up for what was lost.

The baseline detect does a lookup of your location in a huge table. The result is the average worst case day in the worst month of the year for your location. If you’re in the U.S., you can lookup the historic ETo by month for your zipcode at http://www.rainmaster.com/historicET.aspx. Once looked up by the OS weather-server, it should not change. Basically, it’s what you should calibrate your sprinkler system to deliver. More correctly, it’s what you watering program should deliver at 100%, evenly across all zones. You can use just about any other number, as long as you calibrate your sprinkler system and your default watering program to deliver that much. Using the baseline value detected means you are unlikely to ever need to run at 200%.

187% is a pretty high value. Has it been unusually hot and dry? I’m at 6300 feet outside of Denver, an area that is known as “high desert.” The baseline ETo is 0.2 inch. Those are the kinds of losses we have in July and August, when the temperature may exceed 100F, there’s no rain, the humidity is very low, there’s a fast, dry wind, and the solar radiation is off the charts. Unless you’re in a similar area, it’s blazing hot, the humidity is close to zero, there’s been no rain, and the solar radiation is intense, 187% is suspicious.

And, yes, I need, and a lot of other people need, a method that accumulates watering level and has some logic about when to water. Unfortunately, having studied the problem, I believe there are too variations in logic requirements to be practical to implement on a system that runs on a chip in a small device; the user interface would be extremely complex.

Rog 

[Roger]

I believe OpenSprinkler does exactly what you want it to.

The ETo method takes into account the previous 24 hours weather (temperature, humidity, rainfall, and solar radiation) to compute the “water level” required to replace the net deficit, if any. The resulting water level can be zero. (It’s also capped at 200%.) Note that the assumption is that the system is watering every day. OS doesn’t have to take into account the watering during the previous 24 hours because it’s always simply replacing the ETo loss, if any. Also note that the implementation expects that you have calibrated your sprinkler system so that it delivers “baseline ETo” at 100% water level.

The daily watering requirement is problematic for many of us. (Note: the Zimmerman method has essentially the same requirement.) Unfortunately, daily watering is prohibited in many parts of the western U.S. It’s also not appropriate for some types of grasses, e.g., Kentucky Bluegrass.

I’ve been working on a method to “accumulate” ETo loss, i.e., water level, and use the accumulated value to decide whether to water today and how much while staying consistent with various regulations, e.g., only water on specified days, don’t water within x days after a rain of .xx inches, etc. This is far more complex than I anticipated (catastrophic requirements creep).

I’m backing down to just my requirements: 1) accumulate the water level over multiple days (capturing the water level at the same time each day), 2) decide whether or not to run the lawn watering program (ignore all others) based on the accumulated water level (reasoning: I don’t want to water the lawn more often than every two days or less often than every four days, which is optimal for my clay ground and bluegrass), 3) force OS to use a specified water level when running the lawn program, and 4) run the lawn watering program twice on one day (if the accumulated water level would require watering more in a single session than the ground can absorb).

[The last requirement is because I live in a “high desert” area where the ETo baseline is .2 inches. If we have two “high” ETo days in a row, where the accumulated water level exceeds 150%, that much water in a single session would result in some just running off and not being absorbed, so it’s necessary to split that into two 75% sessions.]

Having a traditional green lawn in this climate is a luxury. I’d be smarter if I plowed it under, tossed out some native grass seed, and didn’t water at all 🙂

Rog

[Roger]

I’m working on something similar to what you are requesting. I run HomeSeer, which has a plugin module that can communicate with OpenSprinkler. HomeSeer also has an extensive scripting language. However, I also operate my own weather server (that feeds the data from my personal weather station); I’ll explain why that’s important after a few sentences. I built a test script to see if I could accomplish what you wanted, and it’s not very complex. Note that OpenSprinkler updates the water level every two hours. which turns out to be important.

I wrote a small node.js application that intercepts the call from OS to the weather server, and I push the desired water level to that (but at 9 p.m. every night that application resets itself so it no longer interferes with the delivery of the data from the weather server, allowing time for the latest water level to be pushed to OS, so my script can fetch it just after midnight.)

My test script runs at 12:01 a.m. and retrieves the latest water level from OpenSprinkler and adds it to an accumulator.

Then, if the accumulated water level is less than 50%, the script sets the water level in OS to 0 and also pushes that to the intercept application.

If the accumulated water level exceeds 50%, and is less than or equal to 200%, I push that to OS and to my application that intercepts the weather data call, and I zero the accumulator. If the accumulated water level is greater than 200%, I push 200% to OS and the intercept application and subtract 200% from the accumulator.

[I understand this is what is technically known as a kludge, but I’m sort of prototyping a solution to a more complex issue, which is how to make ETo work when you can’t water every day.]

Seems to work in test mode. (It’s the dead of winter here. The low this morning was close to zero F and the high won’t make it much past 40F, so my sprinkler system is off, but I can still run OS and review the logs.)

This was a good exercise for me to understand what I will have to do to make ETo work when daily watering is impractical or inefficient. Eventually I would like to move this logic into the intercept application. However, for ETo, I may have to run the sprinkler programs multiple times in a single day to get sufficient water without runoff, so the problem is a little more complex. I think I may have a way around this which was triggered by your suggestion of a minimum threshold.

[Roger]

I have the same problem with DarkSky — the precipitation amounts are wildly different than what my PWS reports (and the station apparently used by DarkSky is less than one mile away). I often see DarkSky reports of small amounts of precipitation when I know there has been absolutely none. This may be caused by morning dew accumulating on that weather station’s rain sensor. I stuck with Zimmerman and the data from my local PWS (delivered locally through a local instance of weatherserver).

[Roger]

Thank you, Ray. What I’ve been doing is having OS drive the Bee, using the HTTP variant of a valve zone. I’ll look at changing that to use an external script. I probably want to do that anyway, because I want to accumulate ETo over multiple days (since I don’t run any zone every day).

Rog

[Roger]

jet11x — thank you for figuring out how to do this. I have a similar situation and was wondering how to get this to work. What I’d really like is to be able to use some kind of variable to insert the run time into the “On” command, so I can take advantage of the ETo calculation to drive the timing.

[In my situation I have an extensive sprinkler and drip irrigation system covering several acres. Since the original installation 15-20 years ago, lots of landscaping and paving have been added. The result is that I have no feasible way to run new zone wiring to additional valves. OSBee came to the rescue! I’m using what was the wiring for one of the zones to carry 24VAC (continuously on) to a 24VAC->5VDC step down power convertor (https://www.amazon.com/gp/product/B00RE6QN4U) to power the OSBee. Both devices are mounted in a small Bud box that sits on top of a 3′ piece of plastic conduit. The old valve was replaced with three DC latching valves, allowing me to add two more zones. I intend to do this again to split another zone. Fortunately, I have an overabundance of wifi signal covering the entire property. The importance of your work is that I can control the entire system from a single interface in OpenSprinkler. Again, thank you for sharing your work with all of us!]

Rog

[Roger]

I started this thread and am now able to use data from my local PWS for the Zimmerman calculation, thanks to some excellent help. If this is a high priority for you, then I suggest you visit https://github.com/OpenSprinkler/OpenSprinkler-Weather and consider implementing a local weather-server. In my case I managed to feed data from my Davis Vantage Pro2 to a weather-server instance, where it is used to compute the desired water level.

[Roger]

I am not familiar with the Ambient Weather devices. However, I have been working with some really smart OpenSprinkler collaborators and have found a way to get the data from my Davis Vantage Pro2 fed to OpenSprinkler for the Zimmerman calculation of water level. This involves implementing weather-server on some device, such as a Raspberry Pi, (See https://github.com/OpenSprinkler/OpenSprinkler-Weather) and utilizing existing Davis WeatherLink software capabilities (see the end of this thread: https://github.com/OpenSprinkler/OpenSprinkler-Weather/issues/41. I don’t know whether an approach similar to this will work. There is also another approach, doucumented at the OpenSprinkler-Weather thread, that involves intercepting a TCP/IP feed.

[Roger]

The Zimmerman calculation is not working correctly, as evidenced that it changes throughout the day. Properly calculated, Zimmerman is based on the previous day’s average temperature and average humidity and the previous day’s total precipitation plus any rain today. If there’s no rain today, then the water level percentage should not change from midnight to 11:59 p.m. But it does, and it’s useless in a climate where night time temps drop significantly. There is no way that the current weather data source can work unless OpenSprinkler aggregates the hourly data calls and then computes the averages.

[Roger]

Zimmerman calculation is incorrect and changes throughout the day, which should only occur if there’s rain. The calculation is supposed to be based on the previous day’s average temperature, average humidity, and total precipitation, plus any precipitation today. If there’s no rain, then the water level should not change from midnight to 11:59 p.m. It’s actually changing with each weather call, which makes it useless in a climate where the night time temps differ radically from the day time temps. Zimmerman is intended to approximate evotranspiration, so that the amount of water applied is reasonably constant across varying weather conditions. The current calculation does not do that, particularly when watering at night. Furthermore, there’s no way that the current weather data source can provide the necessary data unless OpenSprinkler accumulates the data from the hourly weather calls and calculates the averages.

[Roger]

Much better, maybe. Diagnostics showing mean temp and yesterday’s precip (as today’s), although not accurate for my specific location. However, mean temp and humidity are changing with every weather call, so I’ll end up with the same problem in the middle of the night when the temps drop radically. Don’t yet know if precip changes ’cause we haven’t had any rain since midnight.

Dubious about the Zimmerman calculation, which should be zero but was 57%; just dropped to zero with latest weather call. (I have Zimmerman set to mimic the defaults of temp 70 and humidity 30, each weighted 100 and rain weighted zero.)

[Roger]

I am furious with what has happened to OpenSprinkler. I’ve been a customer for four years and OpenSprinkler has been “set and forget.” Now it’s useless. I’m in Colorado, and watering any time other than late at night is simply a waste of water. Between the wind and the evaporation rate, most of the water never makes it to the lawn. With the switch in weather providers, Zimmerman is completely useless, as shampeon pointed out. That eliminates one of the major features of OpenSprinkler, which I spent several months tuning for our situation. It took me several days to figure out why my expensive lawn was dying. I tested all the sprinklers, looked at the water level, increased the number of times the sprinklers ran at night, and the lawn is now a catastrophe. I woke up early this morning and noticed that the sprinklers were not running, but they should have been. The overnight temp was in the low 40s and the water level went to zero, which it has apparently been doing for a couple of weeks. I just spent a couple of hours reading the explanation in this forum, which makes logical sense, but the real impact is to make the OpenSprinkler device not worth much because I will have to do all the adjustments myself, probably daily. One of the great values of OpenSprinkler was that I could use the data from my own weather station via wunderground. I still have that access to that data, but OpenSprinkler no longer uses it. I want my money back!

[Author]

Posts