How to tell when an event was triggered by the current app instance

Hi All,
I am trying to keep a set of switches in the same on/off state. In order to do that, I need to not act on events that come from my own app or else suffer from an infinite loop storm of on/off events… I’m betting someone out there has a simple way to do this.

def initialize()
{
    subscribe(SyncedSwitches, "switch", SwitchHandler)
}
def SwitchHandler(evt)
{
    if(!triggered_by_my_app(evt))
    {
        switch(evt.value)
        {
            case "on":
                SyncedSwitches.on()
                break
            case "off":
                SyncedSwitches.off()
                break
        }
    }
}

def triggered_by_my_app(evt)
{
    //TODO hmmmmm ????
}

Unsubscribe from each switch before you send a Command to it, then resubscribe?

According to

http://docs.smartthings.com/en/latest/ref-docs/event-ref.html

Looks like checking for installedSmartAppId in the event might work. Maybe. Of course I have no idea how you find the current SmartApp’s app id.

Perhaps logging the evt.installedSmartAppId would give you an idea of what to look for.

1 Like

Current SmartApp’s ID is $app.id

Give this a try as an if statement:

if( !evt.installedSmartAppId || evt.installedSmartAppId != app.id){
      //do this thing
}

This should effectively say if the app that sent the command does not equal this apps ID then continue on… If the ID that sent the command is the same as the current App’s ID then don’t. But it also checks to see if there is an app ID passed with the evt… incase this comes from the physical switch or something like that. :smile:

I haven’t tested this, so it may not work as I expect but on paper the logic seems sound.

1 Like

Thanks Tim. I saw the Event.installedSmartAppId field but it always seems to be null. Further the documentation says the signature is actually String installedSmartApp. Mistake??
Event.installedSmartApp however seems to always have the name of the app (not the GUID) no matter where the event came from… I get the feeling there are a few bugs in the API here.

log.debug "evt.deviceId=${evt.deviceId}; evt.isPhysical()=${evt.isPhysical()}; evt.installedSmartApp=${evt.installedSmartApp}; app.id=${app.id}"

Log from tapping the on/off button in the mobile app:

evt.deviceId=289eb9b9-da76-4695-b2ca-8d7ddb562721; evt.isPhysical()=false; evt.installedSmartApp=Dining Room Sync; app.id=0a78b2a7-f5fe-4c0e-b433-47464b73b352
evt.deviceId=50d9597a-86cc-4698-a844-d35884441691; evt.isPhysical()=false; evt.installedSmartApp=Dining Room Sync; app.id=0a78b2a7-f5fe-4c0e-b433-47464b73b352

Unsubscribing and resubscribing might work. I hadn’t considered that. I will give it a try tonight as a work-around and let you know how it goes.

1 Like

So I tried an unsubscribe/subscribe work around, but it did not work. The true order of operations is still such that the events from the app’s own .on() and .off() commands are still being received.

For now I am just doing evt.isPhysical() until the API’s app.id detection is working properly. I hope an ST developer sees this and throws it on the tail end of a backlog for me. :smile:

I guess I should simulate this to try to understand. I know that SmartThings spins up multiple threads for each callback, so they really need to provide some more real-time sync options (semaphores, queues) to facilitate these complex scenarios.

Thanks for the discussion here, I have been looking for the same answer. I made some progress and figured a write up needed a new thread as this one seems pretty stale. Please take a look at what I have found here as it may help you: