Bogus Precipitation Data in Rachio


#1

Racio is indicating 68" and 72" of rain the last couple days. I am using a profession weather station at an airport, KAFF, and via WU it shows 0" of rain on the same dates (6/28 and 6/29).
For the forecast today, I am seeing a reasonable number (i.e. <1" of rain).

  • Where is Rachio getting this data, it doesn’t match weather station KAFF?
  • As a work around, should I zero out the moisture level on each zone? All zones to not plan to water for several days due to these errors.


#2

@jcholpuch I know it’s not the end of times, will have development research this and report back.

:cheers:


#3

@jcholpuch We are correctly reporting the data that was returned to our system…(search for precip)

http://jsonblob.com/57753584e4b01190df7d6197

I’ll followup with our weather provider and report this station.

:cheers:


#4

Franz, thanks for the prompt feedback.
Sounds like an issue in the “cloud”.
Garbage in, garbage out.


#5

Are you guys absolutely sure that it didn’t rain 140" at the airport? Maybe there was a micro-burst? :cold_sweat:


#6

@jcholpuch Followup from our weather provider…

:cheers:

Franz,

I have confirmed it is bad data from the station, which is rare from official stations.

Specifically the station reported:
{
ob: {
dateTimeISO: “2016-06-28T22:58:00-06:00”,
precipMM: 609.6,
precipIN: 24
},
raw: “KAFF 290458Z AUTO 19005KT 10SM FEW002 SCT033 OVC150 16/12 A3038 RMK AO2 RAB28E50 TSB15E43 SLP199 P2400 T01570124”
},

The P2400 in the raw observation is the cause of the issue. Incorrect values were included in three update intervals.

This same issue is visible on the NOAA site as well:
http://mesowest.utah.edu/cgi-bin/droman/meso_base.cgi?product=&past=1&stn=KAFF&unit=0&time=LOCAL&day1=29&month1=06&year1=2016&hour1=0

We do have quality checks to catch these type of errors, that said, it does seem as something allowed this to go through. My initial thought is that while the data was marked as suspect versus caution or failed in the individual observations, it was still used within the observation summary.

I will update this afternoon after discussing with our data team.


#7

Another related issue and question.

The moisture level “empty” feature on the iOS app and web app are not functioning properly.
This is probably related to the previous excessive moisture data (feet not inches) but it is still an app issue. Good news is it has been raining the last couple days.

Looking for other suggestion to fix or reset my flex schedules:

  • Will disable and enable of schedules reset the moisture levels?
  • Should I disable flex and run manual for a few days?
  • Any other options? I don’t want to delete the schedules and start over.

#8

Can you explain what you are seeing? I did a code release this morning that fixes phantom irrigation events on the calendar for today if the zone is depleted and the simulator thinks it should water today.

I also modified zone fill/empty so that it adjusts for today, versus yesterday (as long as the flex scheduled run time for today has past).

IMHO to reset I would empty your zones, since it is currently raining (I live in Golden, CO so we are getting the same weather) I would put a rain delay on for a few days, or until the yard is starting to look a tiny bit stressed. When you turn the rain delay off the flex schedules will water the next day (since they will be depleted).

:cheers:


#9

Fantastic on both counts!!! LOVE your customer service!!!


#10

Thanks for the tips.

FYI, I was using an old link to flex-app.rachio.io and it was having the issue with the empty function just spinning and never completing.
When I went to app.rachio.io the empty function worked properly.
Maybe the flex*-app.rachio.io page should be obsolete at this point or re-route to the normal page/site.

Using your suggestion with the empty + rain delay.


#11

@jcholpuch One more followup from Aeris, they are crushing it this week.

Franz,

I wanted to update on this ticket. The value did make it through to the observation/summary endpoint due to the code it was given. The team has added a correction for this, which is currently being tested on staging. The fix should be applied to production this Tuesday July 5th.

I also just replied to your other ticket as well.

Again, I will provide additional updates on Tuesday.