The Rain Bird WR2 receives weather data every 45 seconds and has three modes of operation to handle Rainfall:
- Accumulation - Collects water up to 6 preset levels ranging from 1/8th" up to 1/2"
- Quick Shutoff - Suspends irrigation immediately whenever Rain is detected(no accumulation required)
- Manual delay/bypass - Delays watering 72hours after an event or bypass Rain sensor altogether.
Rachio can use item one with user input set points to determine both if a Rain event occurred and at least the set point amount of rainfall occurred. They could compare data to the forecast and know that the forecasted event occurred and adjust the schedule accordingly. If the set point amount of Rain was never achieved (Rain sensor not triggered) then Rachio would not adjust the scheduled irrigation. This would be a semi-quantitative test.
Rachio using item two would be just confirmation that the forecasted Rain event occurred. They could use this solely as a qualitative test.
With various users in the area having mixed combinations of 1 and 2, Rachio could gather a significant amount of predictive data and use it to adjust schedules.
Now, in item one, to handle the Clik sensor limitations of the unit filling up, some water evaporating, and other accuracy issues associated with similar issues, Rachio would have to incorporate a simple tank evaporation rate model using temp and humidity and air flow data. This would be simpler than the sophisticated evapotrans scheme used for vegetation and can be found here:
With the rate of evaporation calculation and use of point one as a semi-quantitative method, Rachio could track the amount of accumulation over time. For instance, received 1/2" on Tuesday and sensor was triggered. That 1/2"=X. Wednesday, experienced high temperatures and humidity which cause the sensor to dry below the set point, sensor triggers again that rain delay is suspended. The Delta X = X - (Calculated evaporation taken place up to that point of sensor trigger). Now, if another Rain event occurs late Wednesday, we look for when the sensor triggers and calculate the difference between Delta X - any additional evaporation that should have occurred between the last two sensor events, add to that the additionally calculated rain fall (we know the estimated rate because we use the times between sensor triggers), we now have another rainfall accumulation amount. We can then use this data along with our predictive model to determine when the sensor should dry out. If it takes longer to dry out and it wasn’t due to temperature humidity, it had to be due to additional rainfall. We can compare this to our forecast and do other nifty things. If coupled with data from many sensors in the region you now have a very powerful verification and schedule adjustment tool.
Finally, you can use this data to determine irrigation savings. Rainbird claims up to 35% savings through use of the WR2 alone. We have to be seeing greater than this amount of savings. Rachio is just not using the data. The way to use the sensor trigger data to determine water savings with any of the schedules is to setup a separate placeholder table to capture every Rain sensor event period. An event period is defined as the time between initial trigger of the sensor up to to that of the sensor off state being triggered. Then, allow the existing Rachio schedule to work based on the forecast just as it does now. However, whenever a sensor is triggered, they must then compare the forecasted schedule to the duration of the sensor event period. If the Rachio would have watered based on the forecast, but didn’t due Rain sensor event period, that precipitation amount saved due to rain fall should go into the bank as a water savings. The comparison should occur for the duration of the event period and savings applied accordingly. Further, all of the accumulation data from scenarios one or two above should be used in comparison to the forecast to reduce or increase the amount of irrigation that Rachio provides.
Hope this all makes sense…