OpenSprinkler with advanced environment sensing and water management

[paravis]

Hello,

We have a Davis Vantage Pro2 Plus, which measures evapotranspiration (ET), and also soil moisture and leaf wetness. All of this data is streamed to our network and stored in a MySQL database.

I’ve seen in the FAQ that there is some future plan to eventually incorporate soil moisture data into OS. Any update on this?

And as far as ET and leaf wetness is concerned, these pieces of data make for an extremely capable enhancement to OpenSprinkler (in my opinion).

For starters, I know that here in California, we do have a map created by CIMIS (www.cimis.water.ca.gov) that provides the average monthly evapotranspiration for each particular zone. So, for example, in our area during the month of December, we have an average ET of 1.86″, and then in July, the ET is 6.51″. In our case, since we have the data available locally for our exact location, it would be great to use that. But for those who do not have their own sensors, at least in the state of California, there is a list of static numbers to pop into the OS for decision-making — maybe other states or countries provide this data for their locality too.

(PS, I would be willing to do the leg-work to provide geospatial monthly data for OS purposes, at least with the provided data for California.)

Separately (or together with ET), leaf wetness could provide an extremely important and powerful addition to OS — especially in the summer months. In a perfect world, this could be combined with soil moisture levels, and zones could be made available for “emergency watering” during low-water periods of the year. The end result would be that we would be saving a very significant amount of water (here in California, that is very important) while keeping our plants and trees as healthy as possible.

I don’t exactly have the technical expertise or knowledge to really provide any code. In fact, that would be a huge disaster. But I am more than willing to provide anything that I do have (sensor data, data entry, grunt work, reaching out to tech people who specialize in agriculture and irrigation) in order to contribute.

Anyone else interested?

Thanks!
~Laz

[ShawnHarte]

About 5 months ago I released a working version of the OS that would calculate ET and adjust watering times accordingly. The ET is calculated using data from WU weather data (the primary script is hosted on my server), this way no one has to work out every reporting method for ET. The method also uses an hourly calculation so it will adjust for real world conditions that vary from predicted. It also adjusts for predicted values so that it will withhold water if rain is predicted in the near future. Having used it all of the 2016 watering season I had great results with only 2 days of over watering amounting to a total ‘waste’ of about 25 gallons of water, compared to the near 500 gallons saved versus the previous year (adjusted for vastly differing weather patterns–I averaged and subtracted deviations of outliers). The entire program is available on my fork of opensprinklers main github if you wish to use it as a starting point. I don’t support it anymore as it seems interest in the product is high, but interest in integration to the primary firmware is low, essentially I do not have the time to support the project as it takes away too much time from my job.

Most of the firmware matches the 2.1.6 version of the firmware and as it sits is compatible with all devices. Please be aware of the use of code from other authors as I did not start from scratch. You can see the information HERE.

[paravis]

Awesome, thanks Shawn! Your work sounds really cool.

I’ll definitely check that out. It’s too bad though … It would be so great to see it merged into the main firmware.

We live out in a semi-arid environment, and have temperature ranges from about 29ºF up to maybe 116ºF each year. So water management is extremely complicated, to say the very least. And being from California, we’re pretty much always subject to water conservation efforts (which is always a good thing). Every little bit helps!

Thanks again for the head’s up on your work.
~Laz

[Ray]

We do plan to integrate ShawnHarte’s awesome ET algorithm into the official firmware. I’ve been juggling with many tasks and haven’t had time to get it done, but maybe the upcoming holidays are a great time to get this finished 🙂

[paravis]

Cheers to that one, Ray!

So, currently we are (obviously) pulling our data from Weather Underground. That’s totally fine, since it is from our own personal weather station that sits in the yard. I’ve been talking with the developers over at WU and they are also working on receiving ETo data from PWS such as ours. Good news there as well.

Here’s my question … With Shawn’s algorithm being based off of available data from WU (I believe — I looked at it and it’s WAY over my head ha ha), will you make sure to have this number be taken from WU when they are ready with the data through their API?

I actually did a few queries to Shawn’s Python script, and it pretty much matches up (almost exactly) with the ET data that our Davis station is calculating. So his work is most definitely on point. But will OS pull the data from this WU data source as opposed to calculating, *if* it is available?

And also, how about the currently available soil moisture/temperature and leaf wetness data from WU? Is that possible to be incorporated as well? I know it’s getting complicated at this point — but my goodness how amazingly powerful this could be.

By the way, your product is so unbelievably awesome. It’s most definitely my most favorite gadget of the entire year! Thanks again, Ray.

[Ray]

If WU provides ET data, then we definitely would like to make use of it directly. I don’t think it’s currently provided though, is it? At least the last time I checked, WU does not provide ET data. Or is this location-dependent?

Same with soil moisture data — I have never seen this provided through WU API, but maybe I missed this?

Thanks for your kind words about OpenSprinkler 🙂

[paravis]

ET data is not yet provided from WU, but I did get confirmation from their developers that it is something on their priority list for 2017. I am not sure if they are going to be simply calculating it on their end, or receiving it from (for example) our Davis Vantage console, but they definitely said they are adding it.

Regarding the WU API, I have not really looked at it to see what data it provides. But our WU station does have soil moisture and temperature, as well as leaf wetness data there. So I would hope that their API is able to provide that data to us. It is extremely valuable!

I will check on it and see what we can get … Possibly the API does not return any data if it does not exist as a measurement for that area?

[paravis]

Hey there Ray!

I just checked the API from WU for our weather station and the soil moisture/temperature and leaf wetness data is indeed there.

Do you think it would be possible to also integrate this data (when available) to OpenSprinkler’s water management?
~Laz

[Ray]

That’s interesting, that the data includes soil moisture and temperature. I didn’t know it existed before. Will definitely look at this as soon as possible to see what’s the best way to integrate it into the weather algorithm. Thanks for the information.

[paravis]

My pleasure!

Also, don’t forget about leaf wetness.

Not entirely sure what to do with that as well, but what I’ve noticed is that when we have mornings where the leaf wetness is 10+ (generally 0 by about 9a), the soil is pretty much damp and nothing needs water at all. Someone with more understanding about these measurements would know a lot more legitimate truth about the value of these …

But they said they are also adding evapotranspiration this year. So that should make things even more interesting.

A question about solar radiation too … If solar radiation is low (i.e., cloudy day), that would mean that any moisture in the soil or irrigation would most definitely stick around longer. So a cloudy day in summer should be taken advantage of. No idea how this could be implemented, but this type of sensor would have to be very close by the OpenSprinkler user’s location to be relevant. But for us out in the California desert, this could be unbelievably valuable.

Anyway, we are REALLY looking forward to the summer time with OpenSprinkler. We started in December, so we are getting to see the lower water levels. Summer should be fun.

Is there anything in the algorithm that can detect “ultra dry conditions”, and increase the water level over 100%? Last summer, our entire grass got fried and the whole lawn died. The issue was a combination of very high solar radiation and very low humidity. And we were already watering a lot more than normal … so that was a huge bummer!

Anyway, OpenSprinkler is one of my top 5 toys and tools right now. Cheers for the beautiful product. Take care Ray.

[Ray]

“Is there anything in the algorithm that can detect “ultra dry conditions”, and increase the water level over 100%?” — yes, the weather algorithm can output a water level above 100% (though it’s clamped to 200%) depending on the weather. For example, under very high temperature and / or low humidity, it can calculate a water level above 100%.

Maybe you were asking about if the ET algorithm can output more than 100%. That I don’t have enough knowledge to tell. In general it should, because the assumption is that 100% water level corresponds to the water time of an average day so it should be possible to go beyond that.

[ShawnHarte]

When I started making the firmware changes for calculating and using ET the base firmware was quite different than it is now. Some of the “visuals” are left over artifacts that had no bearing on the final outcome of watering based on ET. Let me try to explain the crazy complicated process of watering asked on ET and hopefully it will answer a couple of questions and wonderings, as I like to call them.

ET is basically plant sweat for all intents and purposes. Like people the plants/grass will sweat out water based on the environmental conditions to help maintain a livable temperature. Some water is also lost in chemical reactions while the plant makes the food it need to survive and grow. All ET calculations are based on 100% simply because we are calculating total water lost. The percentage is an artifact of the older system. Here’s what I did in a nutshell to adapt watering requirements.

First get the current conditions and calculate how much we have lost so far today. Then take a quick look at how we did yesterday, and sum up the 2 days worth of data. This gives us ET. Now we need to know what the future looks like. If it’s going to rain a ton tomorrow and we don’t need much water today, we can wait. However, if it’s super hot and dry, with a tiny chance of rain in 3 days, let’s give her all we’ve got. So it is like balancing a checkbook and paying bills. We know our balance, and what bills are coming up, so we can make subtle adjustments and get everything paid without going in the hole, or over watering.

The data used is dependant upon the data available, if ET is sent by WU it will be used first. If not we need to calculate it on our own. Things already looked at are, leaf wetness, humidity, solar radiation, temperature, precipitation, wind, air and soil saturation. The soil type and plant height have to be user provided as WU won’t know that. If a piece if information is missing, like solar radiation often is, we use the next best calculation based in things we can acquire. For instance cloud cover, latitude, and time of day. Using those bits we can get to within less than 1% of actual by calculation. If some of that is missing we go to the next best thing using averages based on recent days. This continues for 7 iterations or until we have what we need, each level down introduces some error, but can still be 30% better than just setting for 10 min and calling it watered even at the lowest level of accuracy.

Next up we see how much time it takes to water the amount we figure the plants need. This is straight forward so no need for detailing the process.

Then after we know how long we need to water to balance out the requirements calculated, we do a quick sanity check to make sure watering is effective, wind speed must be less than 7kph, temp above freezing, and not currently raining. If everything checks out it waters. Then the process starts over. What will happen on screen is a number showing how much water in mm of precipitation is needed. Negative means we over watered, and positive is needed. When it gets over 5mm needed it will water, anything less and it will hold off.
This keeps the plants at their drought protective state. Essentially the grass and plants will be trained to save water by closing pores, growing at cooler times of day, and sending roots deeper into the ground.

I’ve used this for 2 seasons now and biggest change was about 40% reduction in water use compared to the old 10 min twice a day method. Next I noticed the grass was much healthier, I guess it doesn’t like drowning any more than not being watered. Finally I had to mow less because the grass was staying short and densely packed together. I live in a part of Colorado that sees some crazy weather, and never watered when it was raining, and only saw over watering twice, by about 4mm due to a crazy thunderstorm.

So tldr: ET is just a required amount of water, there is no percentage. The sprinklers will only water what is needed and reasonable.
Any information provided by WU is used first, if it isn’t enough to get an ET value it will be calculated, or even approximated if very little info is available.
Accuracy is quite high using the Penmann-Monteith method so it is used first. If it can’t be used, then the Hargreaves method is used. After that statistical data is used as a last effort. The data is available online so I won’t bother with the mile long maths problems.

The project fork I posted on github is usable and functional, but may be a touch rough around the edges. She ain’t pretty but she knows what she’s doin’.

If you have any other questions let me know, I’ll try to answer.

Side Note: WU provides different amounts and types of data based upon device. For instance the iDev app gives indoor temps and videos. The Android app does not, but has 10 days of history vs 7 the iDev app gets. I have petitioned WU, weather.com, and the weather company to provide all relevant ET data for Opensprinkler. They are currently adding more points to the API for Opensprinkler.

[Anonymous]

My take on Opensprinkler using pre-programmed decisions to calculate evapotranspiration (ET) to run irrigation, sure, that’s all fine but what about actual water flow being monitored and recorded using flow sensors?

Suppose one of your irrigation valves is stuck on and is running 24-7 and you’re not there to
notice it. A master valve set to shut off for HI FLOW would do the trick and I would definitely want this feature which is what Hunter I-Core does with FlowSync sensors.

OTOH suppose you accidentally cut an irrigation wire when planting a shrub, and your irrigation doesn’t
run anymore with a LOW or NO FLOW state. Then your lawn dries up and starts to die, but your irrigation controller is still functioning, all is fine and well in the ET world and the network controller. Except for one minor thing: it’s not putting water on your lawn now. Hunter’s I-Core and FlowSync can’t react to NO FLOW because there not SMS function send out text alerts to your cell phone of a NO FLOW or HI FLOW state.

Basically, with water flow being monitored and recorded, a smart controller can react via master valve and flow sensor if your irrigation valves is stuck on and is running 24-7 and you’re not there to
notice it. However NO FLOW situations are also important.

[ShawnHarte]

Warning the user about no flow conditions is not inherently tied to the ET function. This would have the same result in a set it and forget type setup as well. However, the OS firmware does have the ability to send messages out when certain alarm conditions are met. If you wish to have an SMS message sent with High, Low or No flow conditions this can be done and is still included in the base firmware. The ET calculation has nothing to do with this function, and has neither removed nor changed its abilities. The one side effect is should the water somehow run longer or less than needed it will adjust in the following days hopefully negating the issue.
As always checking for proper function of the system is still the responsibility of the end user. As myself or any other programmer can not be present to correct physical faults in your personal system. Hopefully that explains things a bit. Please don’t take anything as me being rude but some problems rely on an owner fixing them. If you would like for me to add a “master” valve as a protection to the actual valves running, that is something that could probably be done. Just note that the ET function is not a fail-safe for physical fault or destruction of your system.

[pbecchi]

Hey guys

I know i am popping in this discussion a little late, ….but i may have what you are looking for!

Regarding ET0 , have a look to this thread https://opensprinkler.com/forums/topic/opensensor-logger-controller-for-opensprinkler-networks/ .

Sensor Server is a SW that run on ESP8266 and can log sensor data , does local computations like ET0 and control Opensprinkler units.
This way you can have a separate unit that using Hygro Temperature sensor and a small solar panel compute ET0 based on local values or, if you prefer, on WU datas. I have a unit like that that run im my garden since last july : ET0 calculated values are correct and reliable. The unit also run an interpreter like language (bitlash derived) and , with it, you can fully customise it to control local or remote GPIO lines and/or send API commands to a OpenSprinkler unit.

Regarding Flux detection and OpenSprinkler supervision I have also started a code that read pulses from a water flow sensor mounted on the main water line. The code read from OpenSprinkler units ( it is running with 5 units now) all watering schedules and measure flow used by each zone.
This flow is checked then for all following operations to be as the one recorded; if not a warning is issued so that you can check that zone or if all zone of a OS unit are not working the OpenSprinkler itself. So with a single unit a can check watering of all units!
This flow values are also very useful for ET based valve control : it is sufficient to know the zone surface to derive the equivalent mm of rain!

This OpenSprinkler WaterManager SW will be available soon or as an addition to OpenSensor or as a separate code!

[adamrecht]

Hello – I’m new to OpenSprinkler so please be gentle if this is a stupid question. I’m right in the middle of setting up a 4-zone system based around OSPi, with a master valve and then a flow meter on the manifold input.

Earlier in this thread Shawn said “the OS firmware does have the ability to send messages out when certain alarm conditions are met. If you wish to have an SMS message sent with High, Low or No flow conditions this can be done and is still included in the base firmware”. This is exactly what I want! Can someone point me in the right direction on how to set it up? Is it to do with IFTTT or something else? All the fancy ET calculations are probably more than I need at the moment.

My holiday home just got flooded because my (dumb, pre-OSPi) irrigation system had no way of knowing a pipe had sprung a leak and was showering the back door every time the water got turned on, so I’m keen to sort it out to prevent this kind of thing happening again.

Thanks for any steer you can offer…

Adam

[Ray]

Assuming you are running the latest firmware 2.1.7, it supports IFTTT, and you can use it to send notifications to you for certain events that are supported. We have a couple of support articles about how to use IFTTT:
https://openthings.freshdesk.com/solution/folders/5000099525
because IFTTT changes pretty rapidly, some of the screenshots may be outdated, but the basic idea is there.

[Author]

Posts