I am working on a Meta-Sprinkler controller that would allow multiple 'real' sprinkler controllers to be managed as one. One of the key functions of the plugin is to turn-on the appropriate zone on the real controller and then turn it off after some pre-determined period of time.

I was wondering if there are any special plugin 'tools' for this, and if not what might be a good way to go about it. My first idea was to just send the On event, start a timer, and then send the off event. That would work, since there is nothing else the plugin needs to, or should, be doing while a zone is active. But, somehow it also seems like a poor idea to block like that, and I have no idea how to stop the timer if the plugin gets a shutdown request.

Ideas?

Handling sprinkler schedules can be tricky because the user might re-execute the same schedule while it is running, stop the schedule, or want to pause/resume it, or skip forward/backward zones. IndigoServer handles all of that for the native devices, so I think the optimal solution might be to just use the indigo.sprinkler.run(), stop(), etc. commands. You'll still have to come up with the special logic/timer that calls the run() commands as the correct times, but I would suggest leaving the scheduling to Indigo Server if possible.

support wrote:...so I think the optimal solution might be to just use the indigo.sprinkler.run(), stop(), etc. commands. You'll still have to come up with the special logic/timer that calls the run() commands as the correct times...

That is what I am doing. I am not trying to duplicate the functionality of the real controllers, just let users easily manage systems with more than 8 zones as though they were one. (The plugin will make sure that two zones on different controllers cannot run at the same time). Also, this plugin will offer the ability to schedule each zone independently, so, some zones could be watered every 4 days, some on Mon, Wed, Fri, - with different times on each day, etc. That would be useful with 8 or less zones too.

So, regarding my first question, I guess I can just "sleep" while the a given zone runs. But, I now have another question, is there a way to schedule a plugin to run at certain times?

In this case, I would like the plugin to start every day at some pre-set hour, run the scheduled zones for that day, and quit. I guess I could just "sleep" for the right number of seconds until it was time to restart, but that seems kind of lame.

berkinet wrote:The plugin will make sure that two zones on different controllers cannot run at the same time.

I am working on something similar at the moment, with the exception that sometimes I DO want the ability to overlap zones; now that Jay showed me the concise Python Tutorial reference that I had not found (THANK YOU, btw), I'm trying to do it by setting up a series of control pages, each with it's own indigo schedule (giving the days and time to trigger) and set of durations. I'm prototyping it using my own 1 EZFlora 5 zone system, but the eventual plan is for my sister and mother's common yard that includes 38 zones, which they wish to water 3 at a time to keep the well pump loaded to the point where it will not cycle. Unfortunately, I can't test the more than one zone at a time section, since I have only one unit. The only other thing that I wonder about is why the Python segment has the Max times as RO; clearly Indigo has the ability to set them, since I can do it from the dialog, but that was deliberately excluded from the scripting UI.

johnpolasek wrote:[...I am working on something similar at the moment...

I would be glad to share my ideas with you, though I have not gone much behind defining a basic architecture...

I am creating 1 device per zone, then each device can have its own schedule... Here is a screenshot:

Each time the plugin runs (start time is set as a plugin config), it collects all the devices and then runs through the list starting and stopping the appropriate controller as needed.

In any case, I would be glad to collaborate, or just send you what I have done so far if you are interested.

berkinet wrote:So, regarding my first question, I guess I can just "sleep" while the a given zone runs. But, I now have another question, is there a way to schedule a plugin to run at certain times?

I wouldn't recommend a straight sleep call because you won't be able to cancel or override it. When Indigo Server wants to shutdown the plugin it will throw an exception (if you use self.sleep()) but that doesn't help you if you need to override or cancel the sleep.

Instead you should use the concurrent thread the plugin offers and handle the scheduling of the timers there. There are several ways to handle timers in python. You could calculate the fire time and just loop with self.sleep() calls of a couple of seconds (each time checking if the fire time has passed AND checking for cancels/overrides of the timer), or you could try using the Python Timer objects. They appear to support canceling.

Another approach would be to create Schedule actions in Indigo from your plugin. However, this part of the python plugin API isn't totally flushed out yet though, so that one won't quite work but it will some day.

this little bit works done for controlling a zone watering event:

Code: Select all

import time
from threading import Timer
 
def waterZoneStart():
   print 'watering started'

def waterZoneStop():
   print 'watering stopped'

waterZoneStart()
shutOff = Timer(10.0, waterZoneStop)
shutOff.start()

Though I have to trap any cancel or shutdown call and make sure waterZoneStop() is called before calling shutOff.Cancel() - and in this case, it is probably not necessary to actually cancel the timer if I just make sure it's action get executed before shutting down.

I am not sure (I.e. I can't see it) how this same timer could be used to put the plugin to sleep for some arbitrary long period - like until watering time tomorrow. So, unless someone else an idea other than Matt suggested, I'll probably just 'nap', check the clock, 'nap', check... etc.

That's exactly what the runConcurrentThread() method is for - polling with some amount of sleep in between. We intentionally created that method so it could run in it's own thread and loop like that.

Now, what you do inside runConcurrentThread() is entirely up to you - as Matt says there are a bunch of different ways to skin the cat. You can keep a list of timer objects and if the user cancels the run or you get a message that the server wants to shut you down then you call cancel on the appropriate timers.

berkinet wrote:I would be glad to share my ideas with you, though I have not gone much behind defining a basic architecture...

I am creating 1 device per zone, then each device can have its own schedule...
Each time the plugin runs (start time is set as a plugin config), it collects all the devices and then runs through the list starting and stopping the appropriate controller as needed.

In any case, I would be glad to collaborate, or just send you what I have done so far if you are interested.

You are further along than I (since I will not begin coding till I have the basic structure a bit more refined) , but I was thinking of creating a sort of "supersprinkler sequence" device containing a number of simultaneous zones to be run (called chains) and an array of "superzones", each of which consisted of an EZFlora (or EZIO) ID and zone, duration, and chain number. Once I had set one up, I could duplicate it as many times as I wished, setting different durations in each instance (most of them would have a lot of zero durations in them) and using different Indigo schedules to fire them off as desired. As long as they informed each other whenever one began running, only one of them could run at any time, insuring that a bunch of them wouldn't accidentally start all at once if one was on a MWF schedule while another was set to go every Friday. And if a cancel was sent to the running sequence, it would know which pending zones to remove delayed actions for. But after giving it a bit of thought, I like your idea of putting the schedule variables into each superzone and letting the supersprinkler simply loop forever as a dispatcher. And I'll probably add a "last time run" item to the zones as well. But I think that keeping them all in a single "box" is a good idea in terms of letting the sequencer deal with scheduling conflicts (probably by timeshifiting one of the zones to keep the right number of chains going) rather than trying to handle it by passing notes between 20 or 30 independent "devices".

johnpolasek wrote:...I was thinking of creating a sort of "supersprinkler sequence" device containing a number of simultaneous zones to be run...

I had considered something like that, but decided to go with the idea that One Zone = One Device. The main reason was that I tend to think in terms of watering a zone, independent of other zones. I know the soil, planting, etc. and would like to set that without thinking about anything else. There was also the aspect of complexity in trying to code the configuration interface for a super zone. Especially in determining the maximum number of real zones that would be included. However, I found I can still create the full schedule easily, even though the "schedule" is spread across multiple devices: When the predetermined start hour arrives, the plugin will request all of its device objects and build a schedule on-the-fly for the current day.

In fact, if we were able to schedule plugins to run, I would do so and have it run each day at the start hour, figure out the days schedule, water, and then just quit. The nice thing about going this route (when Indigo supports it) is that the plugin automatically gets fed all of its devices through deviceStartComm().

Of course, this approach does really not allow for multiple virtual system as you desire. But, I think there is a way to manage that... folders. Each irrigation folder would contain all of the devices for a virtual system. In the plugin it would be easy to create multiple schedules based on the device object's folderId.

This discussion seems to have branched beyond the original issue of managing timers in a plugin. For discussion of the sprinkler plugin that is in development, please use this new thread.

berkinet wrote:

johnpolasek wrote:...I was thinking of creating a sort of "supersprinkler sequence" device containing a number of simultaneous zones to be run...

I had considered something like that, but decided to go with the idea that One Zone = One Device. The main reason was that I tend to think in terms of watering a zone, independent of other zones. I know the soil, planting, etc. and would like to set that without thinking about anything else. There was also the aspect of complexity in trying to code the configuration interface for a super zone. Especially in determining the maximum number of real zones that would be included. However, I found I can still create the full schedule easily, even though the "schedule" is spread across multiple devices: When the predetermined start hour arrives, the plugin will request all of its device objects and build a schedule on-the-fly for the current day.

In fact, if we were able to schedule plugins to run, I would do so and have it run each day at the start hour, figure out the days schedule, water, and then just quit. The nice thing about going this route (when Indigo supports it) is that the plugin automatically gets fed all of its devices through deviceStartComm().

Of course, this approach does really not allow for multiple virtual system as you desire. But, I think there is a way to manage that... folders. Each irrigation folder would contain all of the devices for a virtual system. In the plugin it would be easy to create multiple schedules based on the device object's folderId.

That makes a whole lot of sense; And really, the folders wouldn't be necessary; If the plugin can be triggered to start each day, either by an Indigo Schedule sending something like a "Start Cycle" command to it or as a result of a very long sleep() in a repeat forever loop, it could simply check all the "Zone" devices, collect up all of them that are due to run, and then stick them in however many chains I have set; I have a cousin who is a PhD mathematician that I intend to hit up over Christmas about "knapsack packing" algorithms to automatically figure out which zones can be run simultaneously and how to sequence them to make all the chains run out as close to the same time as possible. And once that is done, all the plugin needs to do is generate a whole series of sprinkler device ID start zone x, delay = y duration = Z commands into the Indigo server and it's done for the day unless I send a cancel schedule command to it. And come to think about it, the necessity to be able to send that cancel command makes the sleep() not an option; we'd pretty much have to have a start command that gets triggered every day at a specific time...

berkinet wrote:In fact, if we were able to schedule plugins to run, I would do so and have it run each day at the start hour, figure out the days schedule, water, and then just quit. The nice thing about going this route (when Indigo supports it) is that the plugin automatically gets fed all of its devices through deviceStartComm().

Saying "schedule plugins to run" is a non-sequitur - Plugins "run" when they are started up by Indigo and stop running when Indigo shuts them down. So, what exactly do you mean by "schedule plugins to run"?

jay wrote:...So, what exactly do you mean by "schedule plugins to run"?

Currently, once a plugin is run, it stays 'alive' until disabled or told to stop by Indigo - presumably on shutdown. If there are other ways to stop a plugin, I missed them. It would be nice to schedule a plugin to run, and then let it die when it was finished.

Now that I think about it, I guess we can do that already. The plugin can be used to create/manage devices, but with an essentially empty plugin.py. Then, the actual work, in this case creating and running an irrigation schedule, could be in a script run by a SCHEDULE. The net effect is the same, but, leaving a plugin running and doing nothing seems somehow wasteful - but, probably doesn't really matter.

jay wrote:Saying "schedule plugins to run" is a non-sequitur - Plugins "run" when they are started up by Indigo and stop running when Indigo shuts them down. So, what exactly do you mean by "schedule plugins to run"?

I've been talking to him about that; I assume he means to cause the Plugin to look through all the zones needing to be run on a given day, build a sequence, and then start the sprinkler sequence at a set time each day, and I assume that it could be done by setting up a schedule with the action being am embedded script similar to

Code: Select all

devPlugin = indigo.server.getPlugin("com.perceptiveautomation.indigoplugin.supersprinklercontrol")
if devPlugin.isEnabled():
    devPlugin.executeAction("StartCycle")

Correct? Or am I completely off base?