Flex schedule *change*, using crop coefficient from zone

In a couple of days we will be releasing code that will start using the true crop coefficient on the zone, versus a pre-determined monthly sliding coefficient. We now default crop coefficient to 70% for cool season grass (i.e. Colorado) and 65% for warm season grass (i.e. CA, TX, FL, etc.). This will ONLY affect new flex schedules, not pre-existing ones.

This topic gives a little more context:

I wanted to share a graph with the differences for Colorado, cool season grass. The left top/bottom images are the current flex settings using the pre-determined crop coefficient, the right top/bottom images are using the zone crop coefficient.

Notice the crop evapotranspiration pulls the graph down slower on the right since it is using 70% versus the pre-determined May setting (90%). I believe most warm season crop users will not see a difference, cool season crop users will probably see a bit less watering.

The great thing about moving to this one configurable value is that it is a very easy lever to move for adjusting watering frequency without affecting duration.

I’ve updated the flex adjustment documentation to reflect this change:


Please let me know if you have any questions.



So for existing Flex schedules, to bring them in line with the new format do we ONLY have to adjust the Crop Coefficient for each zone to the new default value? Or is there more to it? Easier to just create new flex schedules?

Is Crop Coefficient basically the amount of moisture the plant(s) use from the soil? If so, it could be used to say the bermuda is dormant in the winter?

@johnny2678 You will have to create a new flex schedule and move your zones over. No other work will be needed on your side.


@brkaus Crop coefficient is used in predicting evapotranspiration (ET). It’s basically used as an offset of ET.

For example, if ET for the day was .2 inches, and the crop coefficient is 70%, then we use .14 inches (.2 x .7) to subtract from the soil moisture for the day.


Would it be possible to get the Crop Coefficient in slide format % in the web app. It is a slider on the iOS app. I’d like that to be more consistent throughout the different ways of managing the system. Either the web or on a wireless device.

Also, if the easiest way to incorporate the new changes listed above are to create new flex schedules, I get a message stating that if I delete the current flex schedule I have, I will not be able to create a new one. Does that mean I have to use the specified Flex link that was posted previously on the forum? Or do I need to wait until 2.6 is pushed to all platforms?

I’ll let @Dan determine that :wink:

The only way…

Yes, sorry for any confusion. 2.6 coming out soon will have flex back as first class citizens. For now https://flex-app.rach.io is the only way to create flex schedules. That webpp will continue to run until we release our 2.6 software.


This change has been deployed to our servers. Any flex schedules created before 5/19/2016 will continue to use this mechanism for deriving crop coefficient. Any flex schedules created today or in the future, will use the crop coefficient that can be adjusted on Zone --> Advanced Settings. Please let me know if you have any questions.


@franz Can we experiment with a new schedule and just disable the existing one? The intention would be to go back to the old one and revert to those settings as they were before the experimentation.

@azdavidr I was trying to think how to do that. The software won’t allow you to have the same zone in two flex schedules.

I believe you will have to remove any zones you want from the existing flex schedule and add to the new one.

Personally, if you like having access to every lever, the crop coefficient is the most powerful in terms of modifying frequency.

IMHO I’d migrate to a new flex schedule.

So the answer is yes, but the same zone can’t exist in two flex schedules.


@franz Ok. I guess it’ll be a whole leap-of-faith thing. :wink: I’m looking forward to the ability to tweak the intervals ever so slightly. Thanks.

This is awesome! Seeing > .2 ET values in May/October was always crazy