How to determine how a script was called?

I have a script that is called by a Server Action, and is triggered by several different trigger conditions and schedules (it's in an action group so everything points to the one python script).

Is there any way for me to learn which of the triggers definitively called this script? In some cases, a trigger and schedule occur within a second or two of each other, and the script ends up running twice. No big deal, but would be great if I could detect if the script were called as a result of a specific trigger, or a schedule. If I knew that, I could just end early if it's a lower-priority run.

One option is to make 2 copies of this script, one that deals with only trigger-related things, and the other for schedule-related things. But I'd rather have all the code in one place.

If there is no way to learn of the "call stack", then perhaps I could set a variable before the script runs and then examine the contents first-thing in the script. But that isn't foolproof. I could also have umpteen "yep, it was me" variables, but that also seems inefficient, plus there's no clean way to reset those variables.

[jay (support)]

Not directly. One option, however, is to implement the logic in an AppleScript function that's installed in an Attachment script:

Code: Select all

on handleEvent(sourceObject)
    -- do whatever based on what sourceObject is - name perhaps
end handleEvent

then you just call that function with a parameter that identifies the thing that's calling it:

Code: Select all

handleEvent("Trigger Name")

Untested code but it's pretty close I think.

[EDIT] - sorry, I just realized you said it was a Python script. You can do the same thing though: define the python method in a script file using the standard Python library locations and then call the method from an embedded script.

Thanks. Makes sense.

I think I'm going to use the shared function to post to a queue, and then have a handler that processes events pending in the queue. That way, I won't process an event twice, even if the trigger fires twice.

Thanks for making this framework actually usable and robust enough to support this kind of stuff!! When I tried pushing Vera beyond "wait for the switch, turn on the light", it would throw exceptions, have thread/mutex lockups and reboot itself constantly (at least they put their own code on a watchdog timer). Now, I have a full-on finite state machine running in each room, and it's great.