Scheduled jobs failing (again) (again 😥) (Ongoing Known Issue)

To be more transparent and clear, this is a complex piston, but it rebuilt fine prior to the recent issues.

It is 100% repeatable. Every time it fails. This happens on a bunch of other pistons also.

@ady624 - Another question, what is a reasonable memory usage for CoRE? Mine sits between 25% and 45%.

BTW - I noticed a CoRE update. Same issue, new line number.

c0ddeb9a-7e1c-4d64-9b6e-739042b53ead 2:01:51 PM: error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds: 166945835485021 @ line 3468

Each SmartApp gets about 100kB of state space. 45% means it’s using 45kB of data. All is good as long as it doesn’t get too close to 100%.

You may be suffering from read timeouts, a problem @vlad knows about - ST has implemented some changes yesterday to help with that, maybe Vlad knows more?

Try the new update and let me know if things improve please.

I updated prior to my last post. Still didn’t work…

BTW - I am curious about the numbers you posted. None of my execution times are anywhere near yours. Mine are way less.

But I can also tell you it took 18 seconds to open the screen below from the previous screen.

1 Like

Trust me, update again :smiley: mwahahaa

I’m intrigued.

@bago, as far as the ecobee connection is concerned, my custom DTH now uses the asynchronous http requests to regulary polls ecobee…

This has reduced the stress on the ST platform, and there is less and less timeout issues.

For details on the latest version, refer to



I was referring to the timeout issues. S2D2!


As indicated above, it has reduced the timeout issues.

1 Like

True, but I made no reference to your DTH. Please let the conversation stay on track and not deviate. I wasn’t talking about your app, but all cloud to cloud connections. BTW, asynchronous or not, they can still fail (as stated above).

Success! Thank you. I am going to go on a rebuilding spree! j/k…

I believe that you brought the ecobee cloud-to-cloud integration topic in a previous post as stated above in this thread.

So, what I’m saying is that for the ecobee integration, there is less timeouts now because of the async http requests. I’ve been testing them at different user locations, and I’ve noticed less timeouts with my custom DTH.

So, this is on track about what you said earlier.

I think the point being made in the reply to the above was that SmartThings has very recently implemented a platform change which allows devices, including the ecobee, which use a cloud to cloud communication To third-party services to go to asynchronous contact, meaning the time spent waiting for the ecobee cloud to answer is not counted against the smartapp’s execution time. This change was completely independent of the change that @vlad has been discussing with regard to the database errors. But it has a similar end result, in that there will be fewer time outs. :sunglasses:

@yvesracine was verifying that he has changed his ecobee smartapps ( which are quite popular in the community) to use the new asynchronous method.

SmartThings is a very versatile system, but that also means it can fail in many different ways. A fix to one doesn’t always fix another.

Since ecobee was mentioned specifically, I think it reasonable to bring up that people can see improvements in timeouts for that device if they have switched to any device type handler that now use the asynchronous method. :sunglasses:


Fine. I give. But I wasn’t looking for a plug of your app.

Thnx @JDRoberts, you’re always to the point.


I may be biased; but I think Yves’s efforts and contributions (whether or not they are for a reasonable free), justify an occasional “plug”.

With how tolerant we need to be of SmartThings’s ups & downs, I would hope that an occasional email along these lines is hardly a major nuisance. IMHBO (in my humble biased opinion).

Thanks, John (& @yvesracine).


@vlad : whatever SmartThings did on its cloud, congratulations, it worked for me : the SmartApp which had been failing with timeouts for the last 3 weeks executed again this morning without any problem ! :smile:
Note that my SmartApp is read-only (accessing about 500 events history records of 11 temperature sensors), so I probably see a greater improvement compared to SmartApps which write also, according to what you wrote.
PLEASE, try not to break anything again, at least for a few more months… :wink:

PS : just in case it was only a lucky glitch, I did not tempt fate with trying to execute my SmartApp twice : would have been foolish, right ? :wink:


Weird things going on. App slow. Accessing modes excruciatingly slow.

Anyone else?

Same here.

I had zwave devices dropping likes flies. The app became unbearably slow. Schedules were running, just behind. Automations were running, but seriously delayed. Even turning something on with the app had an huge lag. Hopefully today will be better.

My motion sensors were significantly lagging to turn on the lights in the hallways last night. I’ve not seen them that slow in the near year I’ve had them. I thought they were running local since they were previously so fast, but I haven’t dug into my account to verify (aeon6, st sensors with GE dimmers)

1 Like