The Last Samurai

Posted on
Sat Nov 23, 2019 2:44 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

The Last Samurai

They were great warriors, but there is only one remaining! The last AppleScript I can't figure out how to work around. I mentioned in another post I'd be hitting you all up for a solution to this one...

I control my irrigation system with Schedules that trigger Action Groups. Those Action Groups turn on outputs of my old EZIO8T, wired to irrigation valves. Because my old EZIO8T is not 100% reliable, I use Python to loop through turning one of the individual outputs on, and then testing to see if it's really on, continuing to loop until Indigo verifies that the output is really on. Same for turning outputs off.

When I start an irrigation cycle, I set up all the valves to go on one after the other, an hour apart, using delayed actions. When I need to cancel all of those delayed actions, I rely on an AppleScript to rifle through the entire list of Schedules, filtered by delayed actions, and then further filtered by those delayed actions that will execute an Action Group that will turn on an EZIO8T output. Like this:

Code: Select all
using terms from application "IndigoServer"
   repeat with timeDateAction in (time date actions whose name contains "delayed_action")
      try
         repeat with tActionStep in action steps of timeDateAction
            if action type of tActionStep is executeGroup then
               if group name of tActionStep contains "Irrigation 1 On" then delete timeDateAction
               if group name of tActionStep contains "Irrigation 2 On" then delete timeDateAction
               if group name of tActionStep contains "Irrigation 3 On" then delete timeDateAction
               if group name of tActionStep contains "Irrigation 4 On" then delete timeDateAction
               if group name of tActionStep contains "Irrigation 5 On" then delete timeDateAction
               if group name of tActionStep contains "Irrigation 6 On" then delete timeDateAction
               if group name of tActionStep contains "Check That Irrigation Is OFF" then delete timeDateAction
            end if
         end repeat
      end try
   end repeat
end using terms from


So, because you guys haven't yet allowed access to Action group steps, as in:

Property Type Writable Description
actions list of Action Yes a list of Action objects (action steps in AS) that are executed for this trigger Not yet implemented

I can't figure out how to filter the delayed actions schedules to delete the ones I need to. I can't just blast all delayed actions, because I might have some running for some other purpose. I use delayed actions a lot. And your tools for deleting select delayed actions, for some reason, don't allow deleting delayed actions of type Action Groups. (Which is somewhat ironic!) Why is that?? I can get at Triggers, Devices and Schedules, but not Action Groups. :(

I've worked around this in other instances, by using Triggers that initiate delayed actions, so I can later delete those, but that's pretty funky, and I don't think I want to use that MO in this case, if I even could.

All of this means I can't upgrade past 7.3 without a solution. So...

Why doesn't Remove Delayed Actions include an option for Action Groups? And will it ever?
For that matter, why not an option for Scenes, too? I have a use for that as well.

And how can I use Python to filter out a Delayed Action that executes an Action Groups as one of its steps?

Or can anyone offer an alternative for cancelling my irrigation schedules?

Posted on
Mon Nov 25, 2019 1:29 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: The Last Samurai

Does this:

indigo.device.removeDelayedActions(yourEZIO8TdevID)

not delete all of the delayed actions that target the device? Or is the problem that the actions aren not direct Turn On/Off actions targeting the device but rather scripts that have your additional logic (of checking valve states)?

I'm not sure there is going to be a python solution in 7.4 that will allow you to have the exact same logic you are doing with the AppleScript. You might have to re-think the approach in this case, for example having a single script that manages all of the valve durations for a single run (which would use self.sleep() calls to do the delays between the valve changes).

Image

Posted on
Wed Nov 27, 2019 12:47 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

No, that python line doesn't delete the delayed actions I need to target. But that's because they are delayed Action Groups, not delayed script executions or delayed EZIO8T actions. What's being delayed is the execution of a script which will close an EZIO8T output, so I can't remove a delayed actions for the EZIO8T, because the EZIO8T action hasn't occurred yet.

Which was why I had asked: why doesn't the Remove Delayed Actions include an option to remove delayed actions that execute Action Groups? That would solve the problem. As would python access to the steps of an Action Group, or the steps of a Delayed Action (I was accessing both with that AppleScript).

Running the schedule as an external script would not be a great solution, nor an easy implementation. The Action Groups rely on variables for sprinkler duration, and companion Actions and delayed actions report status back to Indigo every minute, so I can see at a glance what station is running and now many minutes it has left to run, among other niceties. Plus, how would that solve for cancelling the irrigation run? How would I stop an external Python script from running?

It's somewhat complicated, but all I need to finish my AppleScript-to-Python conversion is a way to delete the delayed actions should I need to cancel an Irrigation run...

And for that I need a way to examine and/or target delayed actions: those that execute Action Groups, or a way to examine the steps of an Action Group or Delayed Action, or a way to name or notate in some way a delayed action before it runs.

Delayed actions are a big part of my setup in general, and are a very valuable and powerful aspect of Indigo programming. Unfortunately, they all appear in the Schedules list as "delayed_action_xx" which is not particularly useful for observing them, troubleshooting them, or in this case filtering them. Even naming them with some sort of time stamp would provide some identification. That random number identifier is nothing I can use...

Is there some way I could snag a Delayed Action's schedule ID as it comes into existence? I have seven Action Groups that get delayed at the start of an irrigation schedule run. They all get initiated at the same time, one after the other. If, as each delayed action gets added to the Schedules list, I could capture it's ID, I could store those in an array in a variable, that I could later use to target them for deletion? Can you delete a Delayed Action by ID? And if so, how could I capture the ID of a delayed action at the same moment I create one?

Posted on
Wed Nov 27, 2019 12:49 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

PS... I realize I may be pushing the boundaries of your intentions for programming Indigo, or at least your support of it, but pushing those boundaries is what I do!! :D

Posted on
Wed Nov 27, 2019 1:40 pm
FlyingDiver offline
User avatar
Posts: 7189
Joined: Jun 07, 2014
Location: Southwest Florida, USA

Re: The Last Samurai

Given that Indigo won't do what you need to do, I would suggest you try a different tack.

Instead of using delayed actions to start your zones, I would suggest using Timer devices. The basic flow of your control system will be the same, and you can cancel the timers to stop an irrigation run.

joe (aka FlyingDiver)
my plugins: http://forums.indigodomo.com/viewforum.php?f=177

Posted on
Wed Nov 27, 2019 1:58 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

It's not that Indigo won't do what I need, it's that Matt and Jay won't rewrite its code just for me!!! :D

What do you mean by Timer device? Some sort of virtual thing I don't know about, or are you suggesting replacing the actual physical device, like replacing the EZIO8T with a proper Insteon irrigation unit? The latter I've considered, but that EZIO8T is doing other things for my setup that only it can do. That's not to say I can't add a proper irrigation device... and I might have to. (I can't believe the EZIO8T is still running after all these years, so I'll be looking at replacing it eventually anyway, I'm sure. But it'll take about $200 of stuff to replicate what it is currently doing. They don't make it any more.)

There is a work-around, which I had to use elsewhere. If I initiate the delayed Action Groups from a trigger, say one that is watching for a variable change, then I can remove those delayed actions. Which is probably what I'm going to have to try.

But what would solve for those kludges is if the Removed Delayed Actions mechanism worked for Action Groups in addition to its current set of options...

Posted on
Wed Nov 27, 2019 2:07 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

I just went poking around in the webpage "Virtual Devices Interface" to see if there is something there I can use. When I try to create a new device, "Virtual Device" is greyed out...

Posted on
Wed Nov 27, 2019 2:08 pm
FlyingDiver offline
User avatar
Posts: 7189
Joined: Jun 07, 2014
Location: Southwest Florida, USA

Re: The Last Samurai

Indigo comes with a plugin called "Timers and Pesters". You might not have it enabled. When it's enabled, you can create Timer devices that have a default duration. And you can start a timer in any action group (like your "start irrigation run"). Then when the timer expires (fires), you can trigger on that and run an action group.

So, create a timer device for each irrigation zone, with a default value of the delay until it starts. Start all the timers when you start the run, then use the timer to start each zone.

joe (aka FlyingDiver)
my plugins: http://forums.indigodomo.com/viewforum.php?f=177

Posted on
Wed Nov 27, 2019 2:10 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

Oops, never mind, I missed the first sentence of that web page! :shock:

Posted on
Wed Nov 27, 2019 2:11 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

Thanks Joe, you've given me some good ideas. I'll explore...

Posted on
Thu Nov 28, 2019 9:14 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

SOLVED! I didn't try the "Timers and Pesters" plug in, but that did clue me into Virtual Devices. Which did, in fact, solve for this hold-out AppleScript. The Last Samurai is dead!

I created seven Virtual Devices (of Model: Virtual On/Off Device) that now execute the seven Action Groups that control my irrigation valves. I stack up turning on each of those Virtual Devices with Delayed Actions, one per hour: six for six valves (like I had done with the original Action Groups), the seventh Virtual Device/Action Group tidies up the process and makes sure all the valves are really off. Cancelling the irrigation run, and removing each of the delayed actions, is now a breeze using an Action Group of seven Server Actions of type Remove Delated Actions ("Remove for device:"), one for each of the seven Virtual Devices.

Perhaps "Timers and Pesters" would have done the trick, but I'm not super comfortable with the behind-the-scenes nature of plug-ins. When I can "roll my own" I can better understand what's going on and how to troubleshoot. Plus, I didn't have to rebuild the entire workflow, it was a pretty simple matter to just slip in the Virtual Devices where I was before executing Action Groups. The Virtual Devices execute the same Action Groups I had already built, so it all went pretty quick.

And I have to admit, it works better and faster. I actually had to repeat the AppleScript that was previously removing the delayed actions, because for some reason it would remove six and leave one. The repeated pass would snag the errant leftover. More weird AppleScript stuff I won't miss.

I'll admit when I'm wrong. I was disappointed about the deprecation of AppleScript support, and thought it was a mistake. I'm guessing I have more time invested and more lines of AppleScript code than 99% of Indigo users, so I thought I was going to be especially hard hit, even though I'm in the minority, use-case-wise. I've now been able to reproduce everything AppleScript was doing, mostly using Python internally and Restful URLs externally. While my brain has not yet fully wrapped itself around Python and its terms (methods? classes? importing? etc), between the provided examples, the excellent forum support and some internet Python code searches, I got'er done.

I certainly don't miss AppleScript errors and bugs, that's for sure...

Thanks to all of you who helped me! :D

Now I just have to wait until the rain stops to test it all out!

Posted on
Thu Nov 28, 2019 9:42 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

Oops! Spoke too soon? Another Samurai has emerged!! :shock:

I have one last AppleScript that is in an external file, which I execute using a Script and File Action of type "Execute Script-File). It's suffix is ".scpt". It doesn't' make any calls to Indigo, it just does some Finder file manipulation tasks (which I'm too lazy to convert to Python, if that's even possible).

Is that still going to run under 7.4, or should I convert that script to an AppleScript app and just open it using a Script and File Action of type "Open File"?

Posted on
Sat Nov 30, 2019 4:00 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: The Last Samurai

Sounds like that one will be fine as-is since it doesn't have a tell "IndigoServer" block in it. Indigo can still execute .scpt AppleScript files as long as they don't target Indigo.

Image

Posted on
Tue May 09, 2023 12:15 pm
SearchCz offline
Posts: 172
Joined: Sep 18, 2019

Re: The Last Samurai

matt (support) wrote:
Does this:

indigo.device.removeDelayedActions(yourEZIO8TdevID)

not delete all of the delayed actions that target the device? Or is the problem that the actions aren not direct Turn On/Off actions targeting the device but rather scripts that have your additional logic (of checking valve states)?

I'm not sure there is going to be a python solution in 7.4 that will allow you to have the exact same logic you are doing with the AppleScript. You might have to re-think the approach in this case, for example having a single script that manages all of the valve durations for a single run (which would use self.sleep() calls to do the delays between the valve changes).


Where would I be able to learn more about using Python scripts to create and/or clear delayed actions for specified devices? I am presently checking all of my [on] devices every minute to see if any have been left on longer then what I've allowed, and I want to rework all of that to use delayed actions instead. So ... create a delayed *off* action when the device is turned on, replace that with a new delayed *off* if a time extension is requested.

Posted on
Tue May 09, 2023 1:02 pm
Mark offline
User avatar
Posts: 262
Joined: Apr 21, 2005
Location: California

Re: The Last Samurai

Indigo still doesn't seem to have as robust support for removing delayed actions as it once did. I used to be able to use AppleScript to "peer into" a delayed action to see if that action contained an Action Group, and then target that for removal if it did. I got around this, at least for what I needed, by using virtual devices. I created virtual devices that trigger Action Groups. Instead of delaying the triggering of the Action Group, I delay the triggering of the virtual device (that triggers the Action Group). I can later target the delayed virtual device for removal.

I don't know if that makes sense to anyone other than me! But that's what I had to do to make up for what I used to be able to do with AppleScripts and removing delayed actions.

Who is online

Users browsing this forum: No registered users and 0 guests