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.
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.
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.
Ok guys, this is the reason I create this post…
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…
We are leaving the EU so you may want to think again.
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.
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.
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.
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.
Because you have a newer account, you probably need to use a different link. That’s why I always refer people to the community created wiki page which has all six of the possible links. If you go to one of the other links, you can still login there, but the local list will be empty. There’s no easy way to check which link you’re on, so you just need to try all of them until you find one for your devices show up.
The link previously given in this thread will work for most people who added their smartthings account before September 2015. UK accounts are at a different link. And North American accounts added in 2016 are at yet another.
That link doesn’t work for all accounts. If your transaction stream is not assigned to that particular shard, you just get a blank list.
The community-created wiki page has all the different possible links, so I usually just direct people there. That way as more transaction streams are added in the future, the forum posts will still be accurate.
Ok, about 40 of my devices are running local, but none of my SmartApps are.
The only smart apps which are eligible to run locally at the present time are the official smart lighting automations, and then only if they are limited to devices which are eligible to run locally. (For example, if you have a Hue bulb in the lighting automation, it can’t run locally even though that’s an official device type. Same if you have any device that uses a custom device type handler.)
A small number of SHM features can also run locally with the same restriction on device types., but I’m not sure if they show up in the list of local smartapps are not. They might not.
No custom Smart apps (including core) and no custom device type handlers run locally at the present time.