Action Execution

This may sound rather convoluted but
is it possible to introduce an element of indirection when generating an indigo action from a python script.

i.e. 1. from a python script, call indigo with a delay and data indicating a device and an action required on the device

2. when the delay expires, for indigo to run a user script passing the device and action required (from step 1)

3. the user script then generates the action on the device (with some extra processing, or possibly does something else entirely)

[matt (support)]

I'm not sure I am following exactly the requirements of what you need, but one approach that might work better would be for the script itself to handle the delay (versus Indigo). That might keep the amount of data that needs to be passed around to a minimum which would simplify the problem?

Thanks for your response Matt.

Having read through the Indigo docs, I am wondering if I take the following approach :

Create a custom plugin which receives, as an action argument, a device id and action to be sent to that device.

My script would always call, with a delay, the plugin passing the target device and action in the property dictionary.
The plugin would then initiate an immediate action on the target device

e.g in my script

action to custom plugin, delay = ?, property dictionary : somedeviceid=n, action=turnon

in custom plugin action method

extract the somedevice id and action from the property dictionary and generate an action, with no delay to somedevice n, action turnon


Clearly, the above example does not require the extra level of indirection but the plugin action would include processing that may affect whether the device action is actually performed etc.

I have yet to run any code in Indigo yet so if there is any possibility of the above working, I will need some advice on how to construct the plugin.

Let me know if I haven't been clear.

[matt (support)]

I believe what you outlined above is possible, but can you give the specific use case you (or multiple if you have them) for what you are trying to accomplish? There might be an easier way to implement it but I'm not sure without knowing exactly what you are trying to accomplish.

One scenario would be for a simulated occupancy process. This is one I have written for Vera from where I am moving to Indigo. When the system is set to 'Unoccupied' via a virtual switch, set a variable within Indigo and run a script. The script schedules a set of actions with delays (conditioned by a file the script reads). If the actual actions (after the delay expires) occur in a central routine, the individual actions can be logged to an 'unoccupied action log', if the the system has been reset to occupied, any remaining delayed actions can be ignored in the central routine by checking the value of the occupied variable. There could be scenarios where other processing might be actioned according to the conditions current at the time the delayed action is actioned e.g. if a light is to be switched it would be possible to check a lux sensor and ignore the action if above a value. The Vera/Lua environment provides this mechanism which is very useful as a control point when device actions occur. In a general sense, it is the ability to schedule a delayed action but retain the ability to reconsider whether the action should occur, or attach additional processing to it, when the action actually takes place. If you think the idea about using a custom plugin is viable, I guess it wouldn't take too much effort to try it out?

[matt (support)]

Got it. I think.

Your proposed plugin solution should work, I think. You won't be able to re-use the native action UI for turn on/off, set brightness, etc., since using that UI creates a native action that won't be called in your plugin *unless* the target is a plugin defined device. That may not be an issue if you just need basic turn on/off, brightness functionality but duplicate the UI for thermostats, sprinklers, etc., would start to get cumbersome. If you wanted to use the native action UI, then the trick would be to have your plugin define its own devices and the action would then target those devices. So the user would have to create additional plugin virtual devices, which I presume you would then have linked to real/physical devices (the plugin device UI could have a popup for choosing which device it is linked against, similar to Indigo's virtual devices plugin). That approach may not be what you are after though since you would then be restricted to the native action UI (adding additional action arguments/parameters wouldn't be possible).

Thanks Matt. I will play around with this and see how far I get. Can you recommend a basic plugin that I can look at to get me started.

[matt (support)]

Definitely take a look at the example plugins in the SDK download.