Event decoding frustration

post by findaway on Jul 24, 2025

The Get Device Events response does not include zone number or zone ID as a property, neither does it include the runtime as a property, so the only way to get zone or watering duration is by string processing the Summary text. These Summary messages are all in nicely-worded English for human readability but not so much for programming readability.

a) Zone Name appears at the start of the Summary string but is truncated at 19 characters in some types of event messages.

b) To get the actual watering time (ex to correlate with Flume or meter usage data) requires detecting ZONE_STARTED and the matching ZONE_COMPLETED (or ZONE-STOPPED) events’ timestamps for the decoded Zone to then do the math. The duration-in-words SUMMARY data (“…for x minutes”) may include soak times - and may have minutes and seconds in the text - depending on the Event type. Note that Zone starts can overlap (one Zone can start before the running Zone stops, because the first Zone is soaking (CYCLING). This all just makes for more programming work because the API isn’t fully explicit.

REQUEST to RACHIO: All this could be avoided if the Event data included Zone No or ZoneID and a property for watering duration OR if there was a settable “Known GPM rate” property on a Zone (folks could measure the actual flow rate and set it in the Zone profile so that usage data didn’t rely on the fancy but often wrong or too-hard-to-use consumption-estimating method Rachio uses (Nozzle inches/hr etc…) to determine water “usage”). For a lot of customers the cost of water is why they bought the Rachio in the first place.

Tips:

1. Use some structured < 19 character Zone Names to make decoding easier, ex: “01-Lawn”.
2. Build a Zone Table, loop between water start/end to aggregate time/duration (and aggregate the Flume gallons for each minute of those events).
3. Fancy: compute/retain the average consumption rate for that Zone and check for say 10% variation from subsequent event analysis to alert yourself if a zone consumption rate has materially changed (ie has developed a leak or a critter chewed through a drip line or whatever)

I am stumbling through coding all this to provide readable summaries in google sheets for what the Zone events were and how much water that used. I’ll post it if /when it actually works consistently and isn’t a hack-fest.

post by findaway on Jul 25, 2025

Another (related) issue: Zone names not re-mapped:

The Event History Summary text includes the zone name AT THE TIME of the event: ie if the zone name has been changed since the Event, it’s Summary wont have been updated. . Similarly, the (undocumented) REST api includes a Zone reference in its Event response, but doesn’t populate it.

This appears to be because the system isn’t actually using ZoneID when it records events - this is certainly awkward for api users, debatably a little dumb; ZoneID only useful to get its magic properties.