[SOLVED]parameter passing to a Run Shell Script action

6.0.8 is now available for download.
In addition to the major 6.0 improvements this update includes:
... ...
Added parameter passing to the Run Shell Script action including device state and variable value substitution.

YES!

Matt (or Jay): could you provide a little detail on how the arguments are specified and accessed. I would assume they are specified using the same syntax as variable/state substitution in log messages. I.e.

/usr/bin/foo %%v:12345%% %%d:987654:onOffState%%

And referenced by positional variables. I.e.

#!/bin/sh
VARVAL=$1
DEVSTATE=$2

But, It would be good to verify that. Also, is the device name or device ID number available? And, if so, how is it referenced?

And, THANKS for a great new tool. This will open up all kinds of possibilities.

[jay (support)]

Yes - args are passed exactly the same way they're passed on the command line so you process them in your script however is appropriate for the shell/scripting language you're using. The substitution syntax is the same as in all other places where we do variable and device substitution.

When you construct your action command line, you already know the ID, right (it's what you put inside the substitution string)? So to pass the ID just don't put it in the substitution syntax and to pass the name (which you know at construction time) just pass it:

Code: Select all

/usr/bin/foo 12345 "my device name"

Remember, this isn't passing an IOM object to the script - that's not possible. It's only passing the specified string/numeric values - just like any command line that you type into a bash session (etc).

...When you construct your action command line, you already know the ID, right (it's what you put inside the substitution string)? So to pass the ID just don't put it in the substitution syntax and to pass the name (which you know at construction time) just pass it:

Thanks for the confirmation. On the question of the device-ID or name, I was thinking of the case where such information might not be known in advance. For example, trigger Type: INSTEON Command Received, From: Any device

In this case, there is no way to know the device specifics, or for that matter, its states. I was hoping there might have been a catch-all wildcard that would have simply picked the triggering device and, possibly, some default state (onOffState). Such a mechanism would be equivalent to a plug-in subscribing to device changes, but could be done within the existing Indigo Trigger context.

I realize such a generalized interface is probably beyond what you had the resources to do right now. But, I thought I'd check, and at least get it in the feature request queue.

[jay (support)]

That is really a completely different problem. No data is ever passed from a trigger/schedule to an action - it's something we've heard requested before and is something we'd like to do sometime, but it's a large, pervasive change in the core server functionality. It's something that would go into a major release and be one of the selling points of that release.

So it's quite beyond scope for a simple addition to an existing Python action (that doesn't require any change to the server itself).

...No data is ever passed from a trigger/schedule to an action - it's something we've heard requested before...

By me, for one

The current change is already quite useful. Given this new capability I should be able to call a shell script that in turn invokes indigohost -x and passes the key args. Thus, it will be possible to use one script/action for multiple triggers invoking a Python script inside the IOM. Not exactly passing data from the trigger to the action, but a close approximation.

Thanks.