Hose timer web hooks

@dane @franz
Webhooks are desperately needed for hose timers. This request has been pending for quite some time. Can you please provide an update?

If no webhooks are forthcoming, then please consider bumping up the 1700 API call limit. That limit is shared by some API calls across irrigation controllers and hose timers, so it has become difficult to abide by because I now have many zones and multiple hose timers.

I’ll keep polling this :slight_smile:

1 Like

I’m also noticing that rate limiting is not being reset for me at midnight UTC. I exceeded the API call count yesterday (UTC), but today I am still blocked out early in the morning?

Do you have an example of a call from the sprinkler controller that’s affecting your hose timer rate limit? I’ve not seen that. Again, all for webhooks but I’m wondering how often polling is happing that you’re always hitting limits.

It’s not just the polling rate that impacts the limit. It’s also how frequently commands are sent to the timers. I am using the hose timers to dynamically control deer sprinklers to turn off when a person is nearby. This means I turn the deer sprinkler hose timers on and off fairly frequently during parts of the day. That eats into API calls a lot, regardless of the poll rate, and prevents the hose timers from being used for such a case. Not to mention the fact that each poll on top of that takes multiple API calls in and of itself (not just one API endpoint to get all the info).

1 Like

I’m not sure what Hubitat ( I think that’s what you said you use) is all polling for, but you can hit just one endpoint per base station for everything except schedules.

How do you figure?

get base station updated status with /valve/getBaseStation/{id} (including updated connection state)

get valves with /valve/listValves/{baseStationId}

get day views with /summary/getValveDayViews

get schedules with /program/listPrograms/{entityId}

At an absolute minimum, that’s 4 calls per poll.

EDIT: oh, well actually listPrograms is per valve, so that must be called for each valve. So it’s 4 + # of valves per poll.

I guess it depends on how much info you need to get every poll. This is how the HA integration does it, but of course your needs may be different.

List Base Stations only needs to be hit once at startup, actual polling only hits List Valves, and that gives you everything about the valve state.

Get Valve Day Views we hit less often since that info doesn’t change as often ( and actually this isn’t implemented yet officially but I’ve been testing a calendar view for a bit)

List Programs isn’t used because in my opinion it doesn’t provide anything that can’t be gathered from Get Valve Day Views.

So one call every 2 min (or longer if there’s more base stations) plus one extra every 30 min to update day views.

But webhooks would certainly be nice, polling isn’t ideal by any means, just trying to show that it can be done.

Hubitat implements a calendar view dashboard already. Sounds like HA doesn’t need as many calls because it doesn’t do that yet.

I read your docs on Hubitat, it sounds like you have the dashboard displaying upcoming runs for the sprinkler controllers? I didn’t know that was possible, I thought only past results were returned. How are you making that work?

I will PM you separately so as not to derail this thread from its intent as a request for webhooks.

Well. I discovered a bug in my code that caused excessive polling. Oops, sorry Rachio. It’s fixed now. I still believe that webhooks are needed, and mutually beneficial, but maybe not as dire of a situation as previously thought. Will update once I’m able to see how much cushion on the rate limit I have without the polling bug.

1 Like

For webhooks, what type of events are you polling for?


Thanks for asking:

Valve open/closed (including info indicating with which program the event is associated)
Flow detected/not detected
Program started/stopped/completed
Manual Rain skip activated/deactivated
Weather intelligence events akin to irrigation webhooks

Ok thanks, I will look into these with the engineering team.

Appreciate the input!


1 Like