DaveL17 wrote:...Of course, we can always create a trigger that runs on server startup which loads a Python script. This script will presumably run `forever` (I used a `while True`). But this method requires the startup Trigger to activate it. I don't believe that this script is made available to other processes, but I don't know that for sure. So a server startup Trigger could be a workaround for Background Scripts.
One issue with the Startup Item approach is killing/restarting the script is not straight forward. You have to figure out the pid (logging it will work, but it could be waaaay back there) and then do a command line
kill or use the
Activity Monitor . By using the Background process approach you can restart by doing
Reload Libraries and Attachments.
then, DaveL17 wrote:Regarding a standard set of functions for import, if I'm thinking about this right, you could put your script with the functions you want to call into any location that's in the Python path, so a workaround would be to add Indigo's Scripts, Attachments and Background Tasks folders to the Python path. Another option would be to use the `imp` library which should allow the import from any location that Indigo can see, I believe....
According to the
docs,
You may install Python modules/libraries in a special location to make them available to Indigo scripts and plugins, but not to generic Python. This is particularly useful if the module/library includes references to the IOM (since it will only be loaded by processes that know about the indigo module). This location is:
/Library/Application Support/Perceptive Automation/Indigo 7.3/Scripts folder.
So, it sounds like we can, more-or-less, accomplish shared objects as long as we import them.
I am hoping Matt or Jay chimes in here with a discussion of their plans re: Attachments and Background tasks. OTOH, every time they do chime in, my items on the feature wish list fall further back.
FWIW, what I am working on is a monitor script for a Wi-Fi plug that does not broadcast changes in state, it must be polled. To avoid too much chatter, the polling code should only update the plug's state variable for the Indigo Virtual Device (via RESTFul API or IOM) when the state changes. However, the Indigo script that manages the plug synchronously updates the state variable whiner it sends an on/off command. So, if the plug were changed by Indigo, the next poll would see the change and also do an unnecessary update. Not a big issue, but also not real clean. Ideally, the polling script should be interruptible and there Virtual Device script shout signal the polling script whenever a change is made. Thus, all Indigo update would come from the polling script. Yeah, I know there are probably easier ways, but then, what's the challenge.