Hydrawise 12 Zone Wifi Irrigation Controller

Well I had been planning to get a Rainmaker, but their continual delay in releasing an API has put me off. Then today I came across these new 6 and 12 zone units [url=https://hydrawise.com/new-controller-comparison/]https://hydrawise.com/new-controller-comparison/[/url] that it looks like Hydrawise just released, and it already has an API [url=https://hydrawise.com/support/using-api/]https://hydrawise.com/support/using-api/[/url].

Has anyone picked one of these up yet?

Never heard of hydrawise until you posted. Do they have their API documented publicly?

I have opensprinkler. There are so many new network capable controllers now that I don’t think anyone has a good idea how they compare. I’m always looking at who has done the best software for my needs and interest. How these devices should be integrated with Vera is an interesting issue.

Personally I wouldn’t put a irrigation controller into “production” until it’s been on the market and there’s substantial public evaluation. The feedback on the few controllers that look forward using weather forecasts is not particularly good. New companies really have no idea if they will be successful at doing predictive irrigation until they have substantial real world use of their device.

The API link I included above says to contact them for the API documentation. I suspect that they, like a few of the other players, are trying to protect the document. Obviously not an effective security tool on their part. One of the reasons I am looking at these guys is the feedback on their meters. It appears that the meters have been very well received.

They do allow the creation of an account without purchase of a controller so you can see how the system works. Once you create the account you can generate an API key and request the documentation. I just did that. The integration that they’ve done with Weather Underground is pretty interesting. It’s worth creating an account just to check that out.

I went ahead and took a chance and ordered a 12 zone unit. I’ll post back once I get it and the documentation on the API.

I opened a test account, and I like the software. It’s not too ambitious with it’s weather monitoring. It intends user involvement for best results, which I like.

They seem to be using Weather Underground, same as the weather plugin in Vera. Since hydrawise is a commercial WU user, they need to pay for the service. That’s probably one reason for their $5/month charge for more advanced features.

I think someone wanting significant integration with Vera would probably use opensprinkler. I think someone wanting a finished product with weather forecasting already integrated may prefer hydrawise.

The hydrawise api may not add much Vera functionality in actual use. Any changes from Vera may conflict with the hydrawise cloud programing. Vera and the hydrawise cloud can’t both be running logic to perform functions such as setting the rain flag or ramping up irrigation. The API might allow an easy way to show hydrawise status on vera screens, however.

I don’t see Vera as usually being the appropriate place to do valve control with any net-enabled controller.

Good thoughts. Keep in mind that the base service is free.

I just got a copy of the API document. I emailed back and forth with the writer of the document and he said it would be okay if I posted the doc to the forum so everyone could get a look.

He said: “We’re happy to help with any questions that might come up from anyone doing the integration.”

I’m not a dev, but after going through the doc, it does look like it’s possible to do a good bit more than just pull config and usage stats.

Hopefully a few folks who are more capable can take a look as see what kind of work effort would be required to build an app.

Looks like the hydrawise API talks to their cloud service. The opensprinkler api talks to the controller.

The hydawise api is probably designed to be used with their free “home” service subscription. They don’t seem to have enabled a way to control to the hydrawise controller directly from Vera.

Agreed, that’s what it appears to be. I’ve asked if there is any way to directly access the controller. I’ll post back when I get a response.

I don’t necessarily have a problem with the API going through their cloud service, or with the $5 charge for the enhanced service since (as you pointed out) they’re having to pay WU for access (and I don’t mind funding stuff like this a bit since it ensures that they would continue enhancing the services), though I would prefer having the ability access to the controller directly in the event of service outage on their side and internet outage on my side.

Hi all,

It’s Cameron from Hydrawise here. I’ve attached a copy of the API for you.

If anyone wants any help understanding it please let me know.

Our preference is for you to talk to our API via the cloud. This allows us to easily update it without requiring controller software updates.

cheers,
Cameron

I am able to integrate these API in scenes for Running each zone, stoping current zone, getting last water information for all zones and getting schedules as per API document.
The output is json formatted string and I have parsed using akb-json parser and http.request library to get all attributes you are looking for.

Hey Cameron,
Welcome to the board, and thanks for publicly posting the API.

You’ve indicated a preference for folks use your cloud API, but do you have any plans (with timeframe) to expose a local/non-cloud API?

There are a number of folks here (myself included) that prefer local-control, over-or-augmented by cloud-control. Typically because of one or more of security, privacy, availability, uptime or long-term support.

Having a local API would help draw in that part of the audience (currently serviced by openSprinkler), and potentially provide a competitive edge against the newcomers (Iro, Lono, and eventually Edyn).

Our local API is in beta at the moment. The commands will be a subset of the API I posted before but in the initial version you’ll be able to query zone status and manually start/stop zones which is probably the majority of what you’d want to do anyway.

Cameron

Yup, that’d be what an initial Vera plugin (or openHAB Binding) would want to cover, along with the need to express to either disable or delay the schedule for some period of time (if the HA Controller detect the right weather conditions, or switching to “Party mode”, as examples)

Do you need new Beta testers? More than happy to buy a controller to participate in that type of program.

Sure - you’re welcome to test it out! If you order through our website then you’ll get free shipping.

Ordered a 12 Zone unit and a flow meter.

I read through the API doc and the main questions I have so far:

a) Do you have an expected min/max rate of polling?
Some services don’t like it when you poll too often, so do you have a min spec on how often we’re allowed to poll the service?

b) statusschedule.php/running/water is documented as a String, is this correct?
Also, what is the baseline “date” that’s used for the water consumed? Is it the total amount of water used ever, or each day/week/month?

c) statusschedule.php/master is documented as type “seconds”, I think it should be “integer”

d) statusschedule.php/running/water is the only place to ‘read’ the flow meter.
So it looks like I can only read the attached flow meter when a watering cycle is in process. How do I go about reading it when the cycle isn’t running.
ie. Water leaks due to broken valves (etc) - since a single flow meter will cover all of my valves

This is my primary reason for replacing the system (a $400 water bill a few yrs back, due to a stuck valve)

e) Some of the time fields are EPOCH (integer) and some are string, is this intentional?
If they’re String, what TZ and format are they? In some cases, the units are seconds, and in others they’re minutes or something else.

eg. run, time, timestr, nicetime, last_contact, watering_time, time_left

Do you have some sample JSON output that can be used as a reference? I can work off the live stream, but prefer to work against a documented (vs observed) behavior for this type of stuff - esp when i18n might come into play.

f) Where’s the best place to provide API feedback?

a) Do you have an expected min/max rate of polling?
We don’t but we are considering adding this just in case there are bugs in people’s code :slight_smile:

b) statusschedule.php/running/water is documented as a String, is this correct?
That’s correct. It will say something like “50 gallons” or “50 litres” depending on your location. It is the amount of water used for the currently running zone.

c) statusschedule.php/master is documented as type “seconds”, I think it should be “integer”
Correct - cut and paste error :slight_smile:

d) statusschedule.php/running/water is the only place to ‘read’ the flow meter.
This functionality isn’t exposed at the moment. If you email support@hydrawise.com then we will explain how to get this.

e) Some of the time fields are EPOCH (integer) and some are string, is this intentional?
Yes it is intentional - one is just a local representation of the other. String is in your local timezone. I find string useful if you don’t want to have to convert timezones, etc - we do this for you :slight_smile:

e0) Do you have some sample JSON output that can be used as a reference? I can work off the live stream, but prefer to work against a documented (vs observed) behavior for this type of stuff - esp when i18n might come into play.
We don’t - we assumed people would work off the live stream :slight_smile:

f) Where’s the best place to provide API feedback?
Best to open a support case at support@hydrawise.com - that way things won’t get lost in my email inbox.

ok, thanks! I’ve made the request made to your support addr.

I also added the request in there to have a language-neutral representations of the data values, alongside the existing display-only form (in all cases), so I can avoid having to parse the data out for graphs and HA Scripts (etc). 8)

BTW: It looks like once you create an account, you cannot change the email address of that account. I’ve tried a bunch of different ways (using latest Chrome) and can’t get the editor to pop on the field. I ended up just creating a whole new account to handle the email-address change (I’ll let the other age-out)

camryan
If I can make a few comments, suggestions for capturing a ton of the DIY HA market… which IMO no one has done properly.

The ‘smart irrigation’ market is becoming very crowded. Specific to the DIYers, they all seem to have fatal flaws in one way or the other.

In general, here’s what DIYers want…

No Subscription fee

  • this is why were are DIYers

No requirement for internet/cloud connectivity

  • it needs to be able to completely run (and updated) without a the internet

Full featured API for local apps/devices

  • people want to integrate it seamlessly into what they use to run their entire home (Vera, Homeseer, etc)
  • don’t gimp the API
  • allow users to provide whatever internet weather service, sensors, etc they want

What most regular users want…

Start/Stop watering based on local sensors and internet weather service

  • Rules to tell the controller not to water that day & X number of days after depending on the amount of rain. e.g. if it just rained 5 inches, don’t water for 3 days after.

All schedules stored and controlled locally, no need for smartphone/web or internet connectivity.

  • this helps greatly when you have a yard maintenance person, requiring smartphone access is not going to happen.

Hold/Skip modes

  • this allows users to specify specific zones to be bypassed for a specified amount of days.
  • Several uses like… having a party in your back yard (say 3 zones) and don’t want those watered the day before (so it is not wet) and the day of (so people don’t get blasted with water)… but you want all other zones to act normally.

I?m thinking of trying to integrate my Hydrawise into my HA system. Did anyone write a plugin for the Hydrawise?

Not a plugin but the below lua scripts should help other people control their Hydrawise zones using virtual switches.

Fetch All Zone Data - Used to get the relay_id’s for each zone, just use this in your browser.

https://app.hydrawise.com/api/v1/statusschedule.php?api_key=<YOUR_API_KEY>&tag=hydrawise_all

From the above, use the relay_id’s to trigger events on your watering zones. Eg.

local status, result = luup.inet.wget("https://app.hydrawise.com/api/v1/setzone.php?api_key=<YOUR_API_KEY>&action=run&relay_id=<ZONE_RELAY_ID>&custom=<WATERING_TIME_IN_SECONDS>", 10)

Stop watering a zone:

local status, result = luup.inet.wget("https://app.hydrawise.com/api/v1/setzone.php?api_key=<YOUR_API_KEY>&action=stop&relay_id=<ZONE_RELAY_ID>", 10)

I’ve used a virtual switch and created a scene that fires this lua code to turn it on for 20 minutes, i also included a delay action to send the STOP watering API request 25 minutes after starting, obviously it would have turned off already but this will bring the switch back into line (off position).

I then created another scene to issue just the stop API request when the switch was turned off so i could turn it on and off whenever i wanted.

Hopefully that helps someone.

Greg, thanks for these! They work perfectly!

Sent from my iPhone using Tapatalk