Sounds like you’re already doing it, based upon the data that you quoted.
All apps should have this accessible to all people (at least those that are shared). With all of the different versions installed, this will get tricky pretty quick.
1 Like
I’m going to go on a limb here and assume that it may have something to do with trade protection. Just my guess, not an official ST stance. But I think they don’t want the competition be able to size their business. And while this may shield them from marketing harms by competitors, it obviously doesn’t help us, the developers. I don’t have any other features or pages or anything other than anyone of us. I have been working closely with ST here and there to make sure this app stays under their limits. I can tell you that the number of piston executions per a 24 hours interval far exceeds my expectation of a beta, by at least a factor of 100.
2 Likes
That’s awesome, and I’ve only moved half my RM rules over. Maybe I’ll hold off to make sure we don’t blow up the machine! 
This is what IOT users want! Not to break it, this is the level of systems IOT providers need to build to in order to accommodate. CoRE is awesome. CoRE, or at least a lite version, should be CORE to IOT offerings.
Okay valid, but
-
A real competitive intelligence guy would dev or have a great app dev’d just to get this data if it were that valuable, so the delineation doesn’t necessarily protect them.
-
Nobody needs ST’s execution time to take them over, they just need to build a reliable and stable platform. That data is in the open!
You could hire an idiot to figure that out… ‘Say Guiz… do we need to beat 250ms execution time or just make lights turn on and off reliably to beat ST at their game?’ ‘Gee, I don’t know Fred, good question;’ LOL
1 Like
App execution is only part of the process. I don’t care how fast an app is if it takes 5, 10, or 30 seconds for everything to actually occur. Reliability requires the whole picture, not just a small subset. I would be curious what those “execution” times are.
Well… personally, I would simply the entire system… using the data that you have you know which pistons are most popular, trim some fat there. I’m sure that 2 or maybe even 3 of the options can go away… especially since it can most definitely be reproduced within the others… Ones that I would definitely keep… Basic, Simple, Latching, With the way you have designed the individual tasks pretty much everything else can be reproduced within those pistons… Though I’m sure that the And-If and Else-If are very popular…
Also, isn’t the Follow-up and Simple piston essentially the exact same? Both are If - Then - Else.
Literally, with the individual tasks and actions the different types of pistons are really becoming moot.
From my point of view, something like CoRE is needed to make SmartThings truly smart; right now it’s just a thing (I’ve told @ady624 this before when he was creating CoRE) . Without CoRE ST is not really providing something in addition to systems like Vera and a few others out there. Vera has the added benefit of completely local processing. Yes ST does support more devices, but when a company or system relies on its users to make it Smart, then place restrictions and not provide the right tools and information or stability, then the upper management really needs to rethink their end goal.
Either the system should have been smart to begin with, or users should be provided the necessary means to do it reliably; currently both are a long ways away.
1 Like
On top of that, ST, perhaps innocently but I am not sure of that, does not fully offer their full and unconditional support of these CRITICAL community provided components behind the scenes. Even so far as blaming or making comments that erode faith in them to users via private support dialog. Well, if it is broke - THEN DO IT YOURSELF ST, its obviously a core component to your commercial offering.
But no, they ride the fence. Enjoy community dev to keep them afloat, but fail to properly support the same. Incredibly convenient for them.
1 Like
I have harsher feedback on it… but it might end up changing the entire topic of this thread 
But back on topic, I haven’t noticed any significant time differences in execution between CoRE and my SmartLighting apps.
1 Like
Ok guys, this is the reason I create this post…
1 Like
I get the feeling you’d then be jumping from a crashing plane and land your parachute a$$ onto a sinking boat. Not that the US is crashing or the UK is sinking…
1 Like
We are leaving the EU so you may want to think again.
1 Like
Just going to interject something… In reading through this thread I saw a couple of assertions that Smart Lighting was the only thing that ran locally. I believe that’s not true. I believe that Smart Home Monitor runs locally.
Reason being, one of those times when there was a major connectivity issue and I couldn’t get the app to work, I had to “break in” to my house without disarming SHM. Sirens went off and lights came on as soon as the contact sensor went to open, and Scout called within the specified time despite the fact that neither the app nor the ide were available.
1 Like
It is true that some of SHM runs local. @JDRoberts Will probably have posted a 500 word essay with incredibly useful and informative links before I finish this. 
4 Likes
Indeed, parts of SHM run locally as well. Not the custom instances, to my knowledge.
Nope, you hit it. 
Originally Smart Lighting was the only thing that could run locally. Now a small part of SHM runs locally, but not all of it. For example, if you have SHM set up to notify you via text that will not happen if your Internet is not available. Also, I don’t think any custom alerts can run locally at this time, although features are changing all the time so it would be good to verify with support if that’s an important issue for you.
Perhaps most significantly for every day use , at the present time I believe there is no way to change SHM alarm status if your cloud account is not available. (The SmartThings mobile app cannot talk to your hub directly, it always has to go through your cloud account even if you still have local Wi-Fi access.) I’m sure they’re going to change this eventually, but it’s an issue that several community members have run into.
@slagle might know more.
You could have a piston and/or Alexa integration that somehow triggers the change in SHM status (I do this with a virtual light switch I control from the echo and a delayed action off of a piston to allow me to arm the alarm (after sixty second) from the Echo. No disarm equivalent, of course 
).
But none of that will work without connectivity to a functioning cloud, at least until some custom code runs locally. So, it’s not _ just _ connectivity to the mobile app.
There are certainly other ways to change the SHM alarm status then using the mobile app. But the issue raised was if SHM runs locally. Small parts do, but you can’t change arm/disarm status. Pistons do not run locally, so they don’t help with that. For that matter, as of this writing, routines do not run locally–and that’s an official feature, not custom code.
I have notifications setup using SHM to notify me when a door opens. When I say notify my I mean SHM to local siren (not push notifications). I was getting my internet upgraded and lost my connection for a couple hours. None of my SHM notifications happened.
Also @bamarayne mentioned a link above, none of my apps show up.
If that list is empty, then nothing is running local.
The smartapp must be in smart lighting only
The device must be using the stock st device handler.
The app rule can not use any function or device that is not running local.
Take a look at this link, it will give your devices that are able to run local.