I am not sure I am following exactly, the API does have a stop watering command in the API: /public/device/stop_water (readme.io)
The stop-water is at the device level which will then stop across all zones on that device.
The start is at the zone level.
My analogy and use case is that if I can start at the zone level I also expect and need to stop just that zone.
Oh, in other words, you are trying to stop the current zone and go to the next zone?
Not necessarily the next. I’d like on and off control of any zone.
My analogy is like my person is a breaker panel, device is like a circuit breaker, and zone like an individual light on that breaker circuit.
I want to be able to independently turn on zones regardless of the other zones. Just like turning a light switch on and off. I don’t turn off the entire circuit just to turn off a light.
Zones need a start AND a stop.
In my opinion, the analogy of a breaker kind of does not quite fit for me, but maybe I am still missing something. Since only one zone may be turned on at a time, the analogy is more light I can turn on ANY one light switch in the house and then have a universal way (Okay Google, turn off lights) of turning off any light switch. If I were to shut off the breaker, I could not turn on any switch.
What does it mean to turn off a zone if it is not on? I suppose it could be a noop. I do have a water feature that I can turn on or off through IFTTT. Obviously, on would turn it on and off would turn anything off. I just would not tell it to turn off if it was not on. Ooops, come to think of it, I only have it do a quick run for the specified number of minutes, so I do not have a off function.
So now I’m hearing that only one zone can be running at any given time. That’s good to know.
Then stop_water may suffice.
I’ll look into using it that way.
Is there an endpoint that will return which zone is active? That way I know what stop_water will apply to.
I believe the only public way of knowing which zone is running is with a webhook.
That in and of itself surprises me. I’m a software engineer and objects like this lend themselves to properties like their current state. Having a Boolean property isWatering or wateringActive seems like it would be another given.
While I applaud the fact that there is an API with JSON formatted data, it seems the architects may not have thought it through in terms of real life usage and what could be provided from the endpoints.
Obviously just my opinion if it’s survived a while in the current state it is.
You are correct that is Boolean property would be nice. I think I understand too that somewhere in the process are limits to number of queries to the database. If one was polling very often, the limits would be hit pretty quickly. Webhooks on the other hand are not restricted and do not require polling of the data. With that said, I too am a software engineer and would love to make quite a few changes to the API if I could.
I was wondering the same thing, while I am not at that point yet, I was going to see if “running” the zone for 0 minutes would actually stop it. As previously mentioned, if that didn’t work I was just going to use the “Stop_Water” request.
I did exactly that. My UI has separate buttons on each zone to activate that zone. Then I added a single stop button that applies to all zones. It sends the stop_water command.
I think that’s what this endpoint is for.