Indigo Domotics

I'm writing an python action script to be run from an indigo trigger. I'd like to get to some custom fields in the trigger.pluginProps. I cannot figure out a way to get the trigger id or trigger device object from within the action script. Does anyone know how to do this?

Thanks,

David Krause

Full Trigger/Schedule/Action support is slated for a future Indigo release. At the moment there is only limited information available for Triggers. You can, however, get the following information:

Code: Select all

>>> my_trigger = indigo.triggers[123456789] # "KeypadLinc button 8 changes"
>>> print my_trigger
configured : True
description :
deviceId : 321654987
enabled : True
folderId : 987654321
globalProps : MetaProps : (dict)
id : 123456789
name : KeypadLinc button 8 changes
pluginProps : emptyDict : (dict)
remoteDisplay : True
stateChangeType : Changes
stateSelector : keypadButtonLed
stateSelectorIndex : 8
stateValue :
suppressLogging : False
upload : True
>>> my_trigger.id # Trigger's ID
777754145
>>> my_trigger.deviceId # ID of the device it's watching
536340739


This is a device state change trigger. The trigger ID is the id property and the device that it's watching is the deviceId property.

Thanks Jay. I understand how to access the data once I have the trigger name, id, or object reference. I'm writing an embedded script that will be used as the action for a number of triggers. The problem I have is that, when executed, the embedded script doesn't know which trigger called it. I know that I can put an extra line or two of unique code in each instance of the embedded script to hard code the trigger name into the script. I'd rather have the script discover which trigger called it. Maybe I'll code a single version of the response script and put it in a file rather than embed it for each trigger that calls it.

Is there any way to access the trigger name, id, or object reference from the embedded script?

Dave

No data is passed to actions concerning what called it (it's on the feature request list).

But you're right, the way to do it is to create a shared method that you can call from a trigger's action and specify which trigger (or schedule or whatever) by passing in an identifier of some kind to the function. That way you encapsulate the functionality in one place ( I have a couple of these in my production environment).

In fact, depending on the complexity and "sharedness" of the method, this might be a great place to use **kwargs so that you don't have to change the method signature, just how you call it and how you parse out the parameters.

Thanks again, Jay. I'll work around this.

Dave