Clarification for API function

[paravis]

Hi,

I’ve been reading through the API documentation (v2.1.7) and was looking for a little bit of clarification.

On page 6, for manually starting a program … It says “all existing queued stations will be reset before launching the manually started program.” Does this mean that if I have my schedule for the day with any number of queued stations, those will all be cancelled? Or does this mean that if they are currently watering, they will be stopped?

In our case, we do want the manually started programs to be integrated with the existing queued programs, same as the way OS automatically schedules and queues a group of programs that are programmed to start at the same time, or that have overlapping times (for stations marked as sequential).

And also, if I were to manually start two separate programs at the same time (for example, if I have an event triggered on my Meteobridge to send HTTP request to OS for the two programs to run at the same time), how does this work? Will they both be queued for immediate irrigation? Or is the first one cancelled in place of the second?

The API capabilities are so awesome. We really do love it.

Thanks for any help!
~Laz

[Ray]

You are correct that when using the /mp (manual program) API, all existing running and queued stations will be reset before starting the new program. Technically this is due to this line of code:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/server.cpp#L559
Generally when you manually start a program, you want to stop the existing programs because it’s understood that you want to immediately run the manually started program. But to clarify: this only affect stations that are in the queue at the time when /mp is called. For example, if you have a program that runs multiple times during the day, say, at 8am, 10am, noon, 2pm, 4pm. And let’s say you are triggering a manual program run at 10:01am, it only affects the run that started at 10am and won’t affect the noon, 2pm, and 4pm runs. In other words, the scheduler only queues stations at the start time of each run — it does not queue the entire day’s schedule at once.

If you manually start two separate programs at the same time, whatever started later will override the previous one (i.e. the queue is reset before a new manual program is launched). This behavior can be changed by commenting out the ‘reset_all_stations_immediate()’ line (also in manual_start_program function). But this does require you to recompile the firmware yourself.

Another work-around is to leverage the /mp (modify program) API to change the start time to something immediate, like 1 minute from the current time. This way the scheduler will automatically run the program at the specified time (which is almost immediate), and programs started this way will not override the existing stations in the queue.

[paravis]

Great, thank you for the clarification.

I’m still trying to wrap myself around the amazing possibilities that OS can provide. Together with our Meteobridge and weather station, we are already getting warnings via SMS when certain weather events are happening in our area.

One example that doesn’t have anything to do with irrigation would be strong winds from the north. We recently had some new trees put in, and with any winds from the north greater than 10mpg sustained or gusts upwards of 20mph, one of the poor guys starts to lean a bit. So, unlike a weather event that could trigger an irrigation action, in this case, I have to go out with a strap and a pole, and anchor the tree down to support against the wind.

One approach could be to create programs specific for weather events (or any event, for that matter) that are not scheduled to run. Then, on demand, those particular programs could be run when necessary and comply with the current definitiosn to reset all stations.

However we are limited to what, 19 programs I think I read somewhere? Is it possible to increase that maximum without too much effort?

[Ray]

Event-driven program runs are tricky to add in the general firmware because the need for them is very customized. If you have programming skills, you can certainly modify the firmware to add such support. Another possibility is to make use of IFTTT — for example, have the ‘IF’ trigger be some kind of weather event (this depends on what type of weather events IFTTT supports, it may support wind but you will have to check), and define the action as a manual program run command to send to OpenSprinkler. A program can be set to ‘disabled’, that way it won’t run normally, but it can still be started manually using the /mp command.

About the number of programs, we are planning to add support to store programs in the on-board microSD card. Once this is done, the number of programs can be increased a lot.

[Author]

Posts