Enhancement request (?)

I am not sure if the following is even a good idea... but, I think it would solve an issue I have been working around in a plugin, and, if implementable, might help others.

Description:

Extend the RESTful API _method=execute command for Action Groups to include the ability to pass properties and values.
For example:

http://127.0.0.1:8176/actions/cooking%20scene?_method=execute&prop_foo=True&prop_bar=some%20text&propx=1
These property values would then be used to set the values of properties with matching names in the action group to be executed.
It might be allowable to replace any existing values, or only replace a value of None. Perhaps that choice could be an action option.

<Action id="readApcupsd" deviceFilter="self.apcupsdServer" allowReplaceValues="true">
Where valid values might be: true, false none (replace all values, do not allow value replacement, replace only properties with a value of None).

It might also be possible to allow the included properties to be simply passed to the Action Group -- not sure about that.

This functionality would somewhat mirror the executeAction method: executeAction(actionId, deviceId, props).

Benefit:

The plugin could then use the property values to determine the actual action to take: change a state, trigger an event, update some settings, etc. This would allow a single action to act as a gateway for RESTful calls into a plugin and avoid having to create a one-to-one mapping of RESTful calls and actions. In effect, the added properties would be arguments to the action group.

Use case.

Allow processes not running under the same UID as the Indigo Server, or running on different machines, to more easily initiate plugin actions. For now, the plugin user would have to create the interface Action Group. However, when the IOM allows the creation of Action Groups, that part could be done by the plugin.

[matt (support)]

I'm not sure about the exact implementation or semantics yet, but we do need to improve the communication pipeline for actions in general (script actions and plugin actions).

By that I mean actions should have access to data about what triggered them (schedule, incoming INSTEON/Z-Wave command, user control click, etc.) as well as access to arguments such as you describe (RESTful API arguments). The latter also involves openning up plugin communication via the RESTful API at some level. Lots of work to do.