How Do I Create Triggers with Actions Using Python

Hi folks.

I'm trying to figure out how to create a trigger (DeviceStateChangeTrigger) with at least one action using Python but can't seem to put the trigger creation and action creation steps together. The Triggers documentation on this page provides an example of how to create a DeviceStateChangeTrigger but makes no mention of how to add any actions to that trigger. The class properties listed at the top of that page lists "actions" as a property of type "list of Actions", but if I issue the Python command

Code: Select all

print indigo.tirggers["My Test Trigger with Actions"]

in the Indigo scripting shell I get a printout of all the trigger properties EXCETP the "actions" property which seems to be conspicuously absent. The Actions documentation on this page describes the Action class mentioned in the Triggers page but provides no examples of how to create any actions or associate them with a trigger, schedule, or action group. Am I missing something? Can anyone provide an end-to-end example of how to create a trigger with at least one action using Python?

[matt (support)]

Sorry, but you found one of the remaining missing spots in the Indigo object model. We do not yet have the action model glue created for all the actions. It is on our ToDo list and we are committed to getting it done, however, some higher priority items have popped up that we are working on at the moment. So no ETA yet, but it is definitely on our list.

Sorry, but you found one of the remaining missing spots in the Indigo object model. We do not yet have the action model glue created for all the actions. It is on our ToDo list and we are committed to getting it done, however, some higher priority items have popped up that we are working on at the moment. So no ETA yet, but it is definitely on our list.

Hey Matt. Thanks. At least I wasn't missing something.

Basically, what I'm trying to do is integrate the iMeter Solo into my eTrack attachment and Setup applet. In order to do that (without completely rewriting the entire eTrack setup), I need to find some way to script the process of creating a trigger to get the iMeter's total energy usage every time the total energy usage state changes so I can calculate the cost and update the eTrack variables accordingly. If the iMeter's states were visible from AppleScript I could use AppleScript to create the trigger with an embedded AppleScript, but those status values aren't visible as part of the device object properties. Thus, I need to use Python to grab that data. However, I can't use AppleScript (or Python, it seems) to create a trigger with a Python embedded script. Nor is it possible to specify a plug-in (like the Action Collection plug-in) as an action for any trigger.

Can you think of any way I can get the iMeter Solo's "accumEnergyTotal1" value every time it changes without having the user manually create a device state change trigger themselves? Is it possible to pickup the iMeter's status change within the AppleScript attachment using something like "on receive insteon event"? Would it be difficult to make the iMeter Solo's "energyInput1" and "accumEnergyTotal1" values visible to AppleScript from within the existing "analog inputs" device property?

[jay (support)]

You're not going to like the answer, but...

If you convert your eTrack system to a plugin then you can subscribe to device state changes. Then, whenever device states change you get notified and can act accordingly. No user viewable (therefore screw-uppable) triggers required.

You're not going to like the answer, but...

If you convert your eTrack system to a plugin then you can subscribe to device state changes. Then, whenever device states change you get notified and can act accordingly. No user viewable (therefore screw-uppable) triggers required.

Ha! I knew this was going to be your answer Jay.
/trolling

But seriously, would it be hard to make those values visible in the AppleScript "analog inputs" property for the device?

[matt (support)]

Yeah, anything dealing with extending the Applescript model is much harder than we like (and one of the reasons we switched to using python). Let me think for a bit to see if I can think of a hack workaround that doesn't involve extending the AppleScript model.

[jay (support)]

Yes. Adding anything to AppleScript is significantly more complex than any sane person would expect (and probably an order of magnitude more difficult than adding it to the IOM).

That's one reason why AppleScript is legacy.

[matt (support)]

Well, I thought of a *really* nasty hack but I'm not sure it will work:

Code: Select all

set cmdbase to "/Library/Application\\ Support/Perceptive\\ Automation/Indigo\\ 5/IndigoPluginHost.app/Contents/MacOS/IndigoPluginHost -e "
set cmdbase to cmdbase & "'"
set cmdbase to cmdbase & "return indigo.devices[\"iMeter Solo Device Name Here\"].states"
set cmd1 to cmdbase & "[\"energyInput1\"]'"
set cmd2 to cmdbase & "[\"accumEnergyTotal1\"]'"
set energyInput1 to do shell script cmd1
set accumEnergyTotal1 to do shell script cmd2

tell application "IndigoServer"
   log "energyInput1 is " & energyInput1
   log "accumEnergyTotal1 is " & accumEnergyTotal1
end tell

What it does: uses AppleScript to execute a shell script, which starts the indigohost python process in command mode (where it takes a single commands to execute), then have it return out the value from the device called "iMeter Solo Device Name Here." And it does this twice, once for energyInput1 and once for accumEnergyTotal1. I guess it could be made to return the two values comma delimited, so that it can be done in one call. Note this creates a lot of temporary processes and is slow. But if done infrequently it would work...

EXCEPT, you cannot execute the script code above inside an Embedded AppleScript action nor inside an Indigo Attachment script function. It has to be executed in a standalone AppleScript that is a separate process (using an Execute AppleScript that points to a script file would work). Why? Because otherwise the AppleScript is executed in the IndigoServer main thread (limitation of AppleScript). But that main thread will then be blocked with the python host process tries to connect, thus causing a nasty deadlock.

The best solution: write an Indigo plugin.

Let me think for a bit to see if I can think of a hack workaround that doesn't involve extending the AppleScript model.

Thanks Matt! That certainly goes above and beyond IMO.

Yes. Adding anything to AppleScript is significantly more complex than any sane person would expect...

Haha. That's unfortunate, but understandable. I've grown fond of AppleScript, despite Apple's continued crippling of its functionality. It's not as powerful as something like Python, but it's easier to read.

Well, I thought of a *really* nasty hack but I'm not sure it will work:
...

That's great Matt! Thank you! I was considering doing something like that but had hoped to avoid the resource overhead on my aging Mac mini. I'll try that code out, maybe tweak it some and let you guys know the results. I really do appreciate all the time you guys spend (just in general) on this forum helping us end users out.

The best solution: write an Indigo plugin.

Hahaha! Yea, yea. That seems to be a recurring theme with my threads.

Well, I tried out the solution you provided Matt. It works as advertised. On my aging Mac mini though, it's too slow for my tastes. So I've opted for providing written directions (in the installation completion dialog box) for users on how to add the proper Action Collection plugin action to eTrack's iMeter Solo triggers. This will have to do until I rewrite everything as a plugin. Using the Action Collection plugin with the Insert Device State into Variable action. The speed difference between using the Action Collection action compared to the AppleScript->shell->Python plugin host method is much too great to ignore, especially if multiplied by more than a few iMeter devices.

In any case, I really appreciate the awesome help you guys provide!

[matt (support)]

...This will have to do until I rewrite everything as a plugin.

Now you are talking!

In any case, I really appreciate the awesome help you guys provide!

You bet -- thanks for sharing your contributions with everyone.

[jay (support)]

I'm really looking forward to the plugin! I think you'll find that you can do some really great stuff (meta props on each device to store energy cost, etc.) that will make it a much less fragile solution and more user friendly.