API calls failing


#21

Gene, I honestly don’t need any lectures from you about development philosophy or load issues. I’ve been a VP of engineering at a high-volume payment provider, so I understand load issues. I also understood the responsibility we had to users of our API and the critical need to ensure uptime. While I understand the circumstances are different, my goal here is to hopefully get Rachio to think more holistically about their ecosystem. Saying “sorry we didn’t communicate well” is a start, but if they are serious about integrating with other systems they should use this as an opportunity to really listen what the community is saying. That was the goal of my post and suggestions.

As I’ve said multiple times in this thread, we are apparently barely hitting the threshold. Our users DO NOT have control over the polling interval. I do not believe that the plugin is violating any reasonable use statements in the TOS. Reasonable use is certainly in the eye of the beholder without documenting firm boundaries.

I’ve worked with thermostat providers and developers building plugins to them and, as Bill points out, have guided them to the right solution given their documented and/or declared limitations.

I hope you take this as a lesson that you may not, in fact, know everything about all circumstances around API usage.


#22

While we’re on the topic can someone at Rachio document the webhook responses and what each webhook event does?

[
{
    "id": 5,
    "name": "DEVICE_STATUS_EVENT",
    "type": "WEBHOOK"
},
{
    "id": 10,
    "name": "ZONE_STATUS_EVENT",
    "type": "WEBHOOK"
},
{
    "id": 6,
    "name": "RAIN_DELAY_EVENT",
    "type": "WEBHOOK"
},
{
    "id": 7,
    "name": "WEATHER_INTELLIGENCE_EVENT",
    "type": "WEBHOOK"
},
{
    "id": 9,
    "name": "SCHEDULE_STATUS_EVENT",
    "type": "WEBHOOK"
},
{
    "id": 11,
    "name": "RAIN_SENSOR_DETECTION_EVENT",
    "type": "WEBHOOK"
},
{
    "id": 8,
    "name": "WATER_BUDGET",
    "type": "WEBHOOK"
},
{
    "id": 12,
    "name": "ZONE_DELTA",
    "type": "WEBHOOK"
},
{
    "id": 14,
    "name": "DELTA",
    "type": "WEBHOOK"
}
]

Would be nice to know and not just guess if this is the recommend course of action.


#23

+1 for local device control. Going to the cloud when unnecessary is a fail. Let us use the API interfaced directly to the controller on our own networks…PLEASE!


#24

Just bought this thing on Amazon Prime Day and learning the API is not locally controllable, so it’s going back.

The reasons are obvious: Do you want to spend hundreds on a irrigation timer that would become a brick if the company went out of business? Let’s say sales tapered off. Where is the fresh money coming from to run the free site? It’s all good when sales are increasing, but controllers can last 20+ years. You guessed it: “Regrettably, Rachio must now charge a nominal fee for continued access to your irrigation controller.” or “After not locating a buyer, Rachio must shut down our site after July” We’re so sorry, but thanks for the revenue!

Also, I’m in a wildfire zone, and had intended on using it from home automation to water the surrounding area during a threatening fire. This isn’t going to work if I have to depend on my commands traveling to a cloud server over a live internet connection. Buh-bye Rachio.


#25

I’ve always assumed, as part of my purchase decision on IoTs, that IoTs will never be accessible directly from the local network. Which is why, as a security measure, they end up on a Guest network with no access to my LAN. It’d have been easier to ask the forum about the nature of access prior to spending time ordering and attempting to use the equipment.

It’s impressive that Rachio even offers some kind of API; they really don’t have to do that to sell these awesome devices since that’s pretty niche. It takes lots of time and money to implement an API. They could easily just trash it and focus on other areas with more impacts on more users.


#26

rainmachine does run offline, however i think (as far as i’m informed) lacking intelligence. i actually see api as one of the ways Rachio could beat competition, since the big shake-out among iot home irrigation, i will expect in a couple of years from now. Do your homework now as a company and there is nothing to worry about…


#27

I don’t know how long a Fixed schedule on Rachio is persisted if offline for long duration — at least a few weeks prior to reverting to default? But of course it would also have no “smart” features during that time.


#28

I just found IrrigationCaddy has a full local JSON API to schedule, control, and status the device, and a built-in web server interface, and either Wifi or wired LAN connection. It has nothing on Rachio’s intelligence to adjust schedules by itself.

I went ahead and installed the Rachio, set up the loam type, sprinkler type (rotary head), slope, and sun exposure. On the Rainbird I’m replacing, I kept the lawn green with 15-20 minutes per zone. The Rachio smart program is telling me 56 minutes per zone! At first I thought, that’s all the zones together (I have 5 for lawn), but that’s per zone. I don’t understand the 3-4x watering time. Doesn’t seem like a water saver to me, at least not on full auto.


#29

might be an idea to drop this question in the section flex daily? curious how this works…

if you have a custom weatherstation, a local api combines with flex setting should make “intelligence” offline possible (again irrigation caddy trick should be copyble by rachio).


#30

You’ll want to explore the Advanced Zone settings and make sure your precipitation rate is accurate, and check other settings. In the mean time, it is usually suggested to start with one zone on a Flex Daily or Monthly schedule, get the settings dialed in through a little bit of research and maybe catch cup test, then expand to other zones once you’re satisfied. All other zones should be put on a fixed schedule that you’re used to in the mean time. The defaults just get things started but almost always need adjustments. I’m not able to paste in the usual forum posts I reference for checking soil type and Flex daily info but they’re here and easy to find if you need more information. A smart irrigation controller is only as good as the user inputs. Rachio help pages are useful for understanding the advanced zone settings.

Must note there are smart features on the Fixed schedule that would save water too.


#31

@dzee, I believe this is the post the @Kubisuro was referring to:

Also confirm root zone depth and precipitation rate as those will have an impact on the run time. Not sure if there was any cycle and soak time in there as that can lengthen the total time, but not the actual watering time. As mentioned a catch cup test will document the actual precipitation rate and efficiency.

Also, Rachio will assume the water table is empty the first time it runs.


#32

@dzee - Three years ago when I was looking to replace the dumb (no intelligence) Rainbird irrigation controller (which had a manufacturing date code in 1996) that I had, I was similarly concerned about the lack of local control. What got me over the hump was how good the community is on this board and when I looked around to see how often I replaced other electronic equipment (e.g. WiFi router, WiFi modem, cell phone, work laptop, home computer, etc.). Don’t get me wrong, I’m of Scottish descent so I don’t spend money freely, but I figured that the potential savings would pay for a replacement irrigation controller if I guess wrong on Rachio (so far I my guess has been good and the other controllers I was looking at, well …).

On the second topic of wildfire protection, I can think of a couple of ways to accomplish this. If the goal is to run all the zones in a continual series, then I think a fixed schedule triggered hourly with a manual cycle and soak to get the watering time spread over the schedule might work. I’d also put the Raciho power supply on a UPS (uninterruptible power supply) so that if the electricity went out it would still run until there was no more water pressure or the batteries in the UPS are exhausted. This should last longer than powering both the home automation system and the Rachio on the UPS.

The other option would be to configure the Rachio to use a mobile hotspot in the event hardwired internet connectivity is lost. Again a UPS would be helpful to keep the Rachio and the hot spot running longer.

I don’t know if you saw this thread, but real life wildfire and Rachio ->