For those with a dynamic up, webhooks can be problematic. Does rachio support ipv6? For now my webhook is pointed to my aws account but I could remove that requirement if I can point the hook to http://[203:d928…]/hook
I don’t mind challenges, and I certainly understand the need to adapt to scaling issues. What I do mind is having them forced on me without any warning and without any ability to schedule/predict when I need to get them done by.
Of course, all this could be avoided if we could just talk directly to the controller - no cloud infrastructure required and communication stays within the local network.
Considering how little time you Jay and Seth have spent on the forum, I doubt they would have noticed any official messages about upcoming API changes. As a fellow developer I would like to sympathize with your situation, but in reality, thanks to your over-enthusiastic code, all of the developers (not just you) are effected. Rachio has exposed the upcoming schedule information via API, you do not have to poll to figure out when it would run next.
I recommend that you make it clear for your users that if they wish to get the most accurate information via your application, they should use your application to start / stop their Rachio(s), otherwise (should users decide to use Rachio’s official app), just tell them that real-time information on their actions via competing interfaces are not supported and stick with reasonable updates of 1 update for every 5 minute normally and 1 per minute near / during the schedule run.
You should always develop with the least impact in mind. I’m sure even 1700 calls / day is not sustainable if more and more users will start taking advantage of your applications and god forbid that you share one user which means you would now need to split the 1700 limit between the two of you (+ anyone else who wishes to interface with that user).
Gene
With all due respect making no effort to communicate what is a breaking change to, as you put it, “all developers” is in any way acceptable. Even now there is still no mention of the API limit on rachio.readme.io and the Support Link at the bottom to this forum, where I came to find out what was going on, is broken.
What I don’t need a lesson in product design. What I do need communication and documentation. If those are correct I can make my product work just fine.
Well, Gene, a company that publishes an API (particularly a cloud-based one) has some implicit if not explicit responsibilities, not the least of which is to let users know if there are backend changes that may effect their operation. Each of our customers (and probably other integrations as well) use their own API key as published in the Rachio app(s), so Rachio knows from whom API calls are originating. They have the information needed to contact customers that are using offending integrations.
Saying that it’s the responsibility of an integration creator to continually monitor a forum looking for stuff that might break an integration is not practical. And since there was nothing documented about rate limits, it was left up to developers to interpret what that meant in the first place. It’s utterly ridiculous to make any claims about how “little time” we spend on the forums here.
In summary, I reject the assumptions you so unadvisedly made in your post. This problem lies solely with Rachio and their failure to think through the ramifications of implementing rate limits without any thought of communication to those who would be effected.
I would like to suggest a couple of things for Rachio to consider:
- Implement some sort of integration developer notification mechanism. This could be as easy as allowing anyone who wants to know about API changes to sign up for an email. Correcting the issues Seth points out (broken links, incomplete docs) would also go a long way.
- When making potentially breaking changes, contact users who are using API keys that are going to be effected. Even if I hadn’t gotten notification, I can guarantee that if any of our shared customers received such an email from Rachio they would have very quickly let us know and we could have reacted appropriately.
- Consider opening up the API for direct communication to the controller. They could significantly mitigate scaling issues for the API if it wasn’t necessary to contact their cloud-based servers for all communication to the controller. Even if it were just for direct control commands (turn on zone, stop watering, etc) then at the very least those calls could never fail due to network or capacity issues.
Rachio makes great hardware, as many of our customers have found out. We even recommend it when customers ask about irrigation solutions. Implementing a few relatively simple things could help harden integrations and make Rachio an even better product.
1 Like
Not a BIG dev guy here, but have to agree with this one.
“Consider opening up the API for direct communication to the controller. They could significantly mitigate scaling issues for the API if it wasn’t necessary to contact their cloud-based servers for all communication to the controller. Even if it were just for direct control commands (turn on zone, stop watering, etc) then at the very least those calls could never fail due to network or capacity issues.”
The lack of direct control worries me that this could easily become a forced subscription device in the future…
Holding on to my old controller just in case.
It is easy to be dismissive when it comes to feedback. Could Rachio have handled it better? Yes. @mckynzee even apologized for missing the opportunity to inform everyone about upcoming changes, but implying that API comes with any sort of grantees… I’m afraid you are in for a shock. I could go on about how Rachio has a section within their TOS about reasonable load, but I really do hope that you will take this event as a lesson about what could happen with any of your other integrations which leave it completely up to end user about how often they should refresh the data.
You raise good points. Would it be nice for Rachio to provide a local interface? YES! I’d love to see this feature, especially for times when unit operation is essential, but internet infrastructure may be compromised (such as during the wild wire). Is it easy to implement? No, exposing services on a local network includes a higher risk that something will go wrong. Will Rachio ever develop this functionality? I hope so, but it will be much more likely that they do so in case we (as the developers) can prove that they will not be dealing with overwhelming amount of traffic, just because it is local.
I come from a different type of development. Thought out my carrier I was dealing with embedded programming, and now I dabble with web programming. In either application, resources are always limited and loads are not easily dismissed. I’m not a Rachio employee, nor do I have any reason to defend their position, but I do have a good idea of why they had to do what they’ve done.
Be nice to your service providers, would your code have been reasonable to being with, you may not have even noticed the reduction in API allowance. As is, treat this as a lesson and revisit some of your other code to reduce the load where it matters.
Gene
I see similar issues with network connectable thermostats.
Some thermostats are ‘closed’ to any local interaction. You ‘talk’ to the cloud to ‘talk’ to the tstat, or you don’t talk to the tstat at all. There’s a variety of reasons why some manufacturers do this, including marketing reasons.
Some thermostats are ‘interfaceable’ via local LAN connection, You’re going to ‘talk’ to the tstat without ever using the WAN.
Tstat manufacturers are very watchful on subjects like polled or non-polled. And if they’re polled, the manufacturers limit how often - typically the best you can get is once per minute ‘handshaking.’
It’s been interesting to read all you developers comment about need and philosophies for ‘talking’ to a sprinkler controller. They all remind me of the same subjects with tstats.
My observation is I don’t think you’ll ever get a local interface to the Iro. The architecture just isn’t set up to support this. It’s the cloud or nothing.
Interestingly, my network connected tstats are local to the LAN (controllable without need for a cloud), and polled. And I’m limited to polling no faster than 1 per minute.
Good luck you guys! And be nice to the manufacturer!
Best regards,
Bill
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.
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.
+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!
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.
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.
4 Likes
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…
1 Like
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.
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.
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).
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.
1 Like
@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.
1 Like
@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 →
3 Likes