Problem: 15 second execution limit

General Discussion
1

I was trying to subscribe to about a dozen event handlers from various sensors when I ran into this error:

Execution time exceeded 15 app execution seconds

This implies that subscribing to channels is synchronous and slow.

Does anyone know a way around this?

P.S. I’ve been spending the last half week or so across christmas and new year trying to get my home setup running. One of the things I wanted to have was an energy monitoring dashboard. Considering that there is virtually no UI on smartthings, it has to be driven from an external server. However getting all the events piped out is a pain given these glitches and limitations. On hindsight should have went with veralite and get this over and done with.

2

I don’t have a solution, but I saw someone else respond to you in another forum post about a possible workaround. If you get one and it works, could you repost here? I’m also having a lot of problems with scheduling/subscriptions/state, so anything you find that’s useful would be appreciated.

3

Earlier this week I was getting this problem and thinking it was something wrong with my code - eventually tried an example app instead, and it gave me the same error. Both apps were trying to schedule one event - I assumed it was a temporary system issue since it worked a few days later.

4

I did think about it, but I do not think a workaround on our part is the right approach.

I tried to use closures with scheduling. They were surprisingly not compatible with the scheduling functions, which were too rigid in definition and only accepting named functions. Without closures, one is forced to have many chained functions, miss out on parameter binding, etc.

We could create a chain of scheduled events, slowly executing each iteration in succession.

However, this does not address the fundamental problem that the “15s limit” implementation may be flawed. My code was simply doing iterations calling “subscribe”. Should the subscribe function, being an api call, take a long time to complete, would it be the developer’s problem? Definitely not, especially when one expects that function to return almost immediately. If the time limit is desired to limit abuse of api calls, then a cost based weight should be used and made clear to developers. e.g. each subscribe call would eat <= 10ms of execution time.

As highlighted by Alex, the current time limit appears to affect the reliability of apps written.

5

Yes moving unnsubscribe and unschedule out of install function does remove that silly null clear() error.

Now, my init calls runIn(10, taskSubscribe)
which takes in a list of devices from the state map and iteratively subscribes to events.

But my simulator is now stuck whenever I install/update. Arghhh. (╯°□°）╯︵ ┻━┻

6

I think this will work (below) to reduce the overhead of iteration thru the devices: (code snip add the detail you want). Then parse in the event handlers as to what you want to get from the event.

Example, now instead of creating a subscription to each device with a battery attribute, you create one subscription to the group.

I’ve not actually tried this so let me know if it is successful for you or not.

Twack

section("Choose things..."){
		input "tempSensors", "capability.temperature", title: "Motion Detectors", required: false, multiple: true
		input "contactors", "capability.contactSensor", title: "Contactors", required: false, multiple: true
		input "switches", "capability.switch", title: "Switches", required: false, multiple: true
		input "presences", "capability.presenceSensor", title: "Presence Sensors", required: false, multiple: true
	}

some code ......

def installed() {
     unsubscribe()
     def allDevices = tempSensors + contactors + switches + presences
     subscribe(allDevices, "allDevices?.battery", batteryEventHandler)  //check battery changes
     subscribe(allDevices, "allDevices?.temperature", temperatureEventHandler)  //check temperature changes
}

def batteryEventHandler(evt)
{
     //do some event stuff here
}
7

Thanks! I’ll hold off spending more time on this until I get a word back from their devs. Some other users were also wondering what their roadmap was, its hard to proceed with much uncertainty.