According to @tyler , if a smartapp uses a custom device type which has not yet been approved to run locally, it will still run in the cloud.
No details yet on how or why device types would get approved. or not. I use the smarten IT three toggle because it has a physical form factor that both my service dog and I can use. But my understanding is that this means it will not run locally at the present time.
Thatâs correct. For a SmartApp to run locally, all devices it is using must also be executing locally. So, if you are using a SmartApp that can execute locally, but configure it to use a device with a custom device type handler, it would not run locally.
The catalog of what is available to execute locally will be growing in the near future, and we know that developers will want to be able to have more control and information about what is executing locally (including custom SmartApps and device types). Expect more discussion around this in the coming weeks.
My family has already voted to rip this out if I lose lights and switches from dashboard. They donât want 4-5 clicks just to look at lights room by room. Smart tiles wins again.
I like rooms, but not for a quick global view of what lights are on around the houseâŚyou know, something usefulâŚlike a dashboard!!
A long time ago, ST promised developers that theyâd get some ability to add groups to the dashboard and do things similar to the old âlights & switchesâ module themselves.
I wonder if that might still happen now, or if itâs another casualty of âa few weeksâ turns into ânever.â @Jim?
Does it also mean that anything that sends notifications cannot run locally? Or does it just mean that the notification itself doesnât get sent?
That is, say I set up a routine whose only purpose is to change the mode to âparty modeâ and it also sends A notification that says âparty timeâ to me and my housemate.
If the SmartThings cloud is unavailable, or the Internet is down, does that mean that routine will not run at all? Or does that mean it will run and change the mode to party mode, but the notification just wonât get sent?
That pretty much kills the âlocal executionâ feature for most of us, âpower usersâ, who have at least one custom device. Very disappointing⌠
I get the impression from a number of recent posts (i.e. in the last day) that they are looking at giving developers (a.k.a. power users) the ability to run their own smartapps and devicetypes locally on their own hub (provided, of course, they meet all the other technical criteria for local running.
This ability is, of course, very necessary for developers to properly develop and test smartapps and, perhaps even more importantly, devicetypes, which are expected to run locally after receiving SmartThingsâ blessing.
I expect this ability would overcome your concerns re: the SmartThings final tick of approvalâ˘
How is this even a reality? I canât believe that a hub v2 that advertises local execution wonât execute anything written by the community locally.
If its ok to execute in the cloud, why the heck isnât it ok to run locally?
I certainly hope we get solid answers on Wednesdays dev call. Weâve been waiting a year for this thing and now we find out none of our code will run local.
Only approved, blessed code will run local? I need a good reason why this is. From where I sit, it seems like its just about control. (double entendre for the win)
Absolutely! Dashboard for a quick look in every application is a must for the summary not just home automation! A quick glance and you are done.
That wouldnât be so bad if they actually approved/blessed code once in a while. As it stands right now, the chance of getting a device type approved is about⌠ZERO.
I suspect it is more about ensuring peoplesâ hubs arenât brought to their knees by poorly written third party code, sullying SmartThingsâ reputation in the process.
It seems fairly clear that SmartThings are trying to institute a controlled release of this functionality, with more freedom coming as experience and knowledge matures.
Whilst the concept of automated checking and validation of code for execution in the local hub is an excellent goal, I can understand SmartThings wanting a human in the loop for that decision in these early days. In this light, it also makes sense that they intend to give developers the ability to run their own code on their own hub some time in the near future.
STâs rep isnât doing too good right now anyway. The fact that theyâve been making promises for the past year (recently using the v2 hub as an excuse not to deliver) and now we find out that the v2 is more empty promisesâŚ
EDIT: Actually, I should correct that to be more accurate. The v2 is more than full of promise. Iâm sure it has plenty of potential, but STâs track record over the past year in fulfilling potential has been poor.
Chuckles, I find it hard to believe that my local hub is more of a risk then my access to the cloud.
How hard is it to add a box that says, I understand that by allowing this code to run local I could need to reset my hub or whatever needs to be done to remove any bad code.
Why is the local hub so much more âunstableâ than the cloud appengine?
Whilst I can understand your concerns on many issues, I donât understand nor agree with your seemingly increasingly vitriolic stance.
When I compare SmartThings to just about any other commercial tech operation, I find them to have been remarkably open, honest and clear in their communications.
The need for code to be flagged as suitable for running locally has been called out previously; the only new element is that, for now, this flag will be set by SmartThings staff after a review.
They have said they will be giving developers the ability to do this for their own code on their own hub in the near future. This should seemingly ameliorate the majority of concerns in this space of any âpower userâ.
They have also said they want as much code to run locally as possible, so I expect this review/approval process will get streamlined and automated as much as, and as quickly as, they can.
They have also said, for quite some time, that V2 is not a panacea for all ills and not to expect everything to be delivered on day one (viz: a device migration tool, etc.).
I still have faith that SmartThings will deliver on this larger picture. I also understand their cautious approach to rolling out this new functionality.
I am beginning to think that the platform is trying to run things locally on the V1 hub. All of my devices that are running fine right now are ones using custom device types or smartapps (i.e. things they have stated would run in the cloud on V2). Everything that isnât working is using the stock device types and smartapps (i.e. things they have stated would run locally in V2).
I think the key issue here is you keep viewing it from the perspective of a skilled technician who understands the technology and is capable of diagnosing faults, understanding system constraints, etc. Youâre not viewing it from the perspective of somebody who has to support this system when it is in the hands of the dreaded âEnd Userâ 
Users will tick any box put in front of them which stops them from
running their latest toy. Any such agreement will not, however,
hinder or filter their complaints and demands when something goes
awry from their perspective.
I imagine SmartThings have very detailed instrumentation of their cloud
infrastructure and can very easily identify, quarantine and âdeal
withâ any errant third party code executing therein. I would not
expect them to have the same level of view or control of the hub
environment.
This is why I understand the cautious approach they are taking in these early days.
Theyâve also said that they would document more of the z-wave commands. Theyâve also said that devs would get access to dashboard groupings. Theyâve said that they would add something to standardize a way for device types to alert on critical issues. Theyâve said that they would expand or allow extending device type capabilities. Theyâve said that theyâd review user submitted device types. Theyâve said a LOT of things that have never come to pass.
This is only a very tiny fraction of the things that theyâve said just over the past 8 months or so⌠that have never happened.
At what point does optimism give way to giving up hope and just moving on? For me, Iâm an idiot: Iâm still trying to hang on in hopes that ST will eventually deliver some of what theyâve promised. Iâll tell you, though, that itâs very, very hard.
No I hear what you are saying.
It would be a simple opt in / we told you so type thing.
But still, I need a good answer why the local hub appengine is so vulnerable compared to the cloud.
The cloud can take down not only my hub / location, but many others potentially.
My local hub can only take down my local hub.
The rational right now, is BS. I need a better reason, or at least a reasonable reason, like we just didnât do it yet.
My opinion is that I think the rational is deeper. The plan was to never allow it. Now they are scrambling to adjust the plan.
ST needs to prove they are open and not just a slogan.
I know people like Ben will say, it will be coming soon. But until I see it, the last year has proven that you canât believe it.
The list of things that were promised about hub v2 that may never get delivered is growing long. The walls are closing in on this platform.
I really hope I am wrong, I really hope things are just locking down for release and in a few weeks things start opening up again.
Right now my wife canât even access my account. All because of a mobile app rollout? Wow.
If you go back IN THIS THREAD and read what @Ben had to say about local execution of SmartApps and Device Types, there is no resemblance whatsoever to what is being said now. For many many of us, local execution is the holy grail, not because of internet outages, but because it would remove STâs cloud from the equation for basic functions. Even this morning, after returning from being gone for about a month, I see app failures that can only be caused by the cloud â lights that donât come on from motion, for example. This has happened all along with ST. It functions fairly well most of the time, but there are times where things just donât execute as they should. Without local execution, this will continue to be the case, and it will continue to suck because of that. How does one explain to the wife that ST only works some of the time, when itâs just turned the lights off on her while sheâs in her closet? Iâve been facing low WAF all along, and thatâs evidently going to continue indefinitely.
Hey, at least your wife can access the app. Mine canât even do that.
Patience⌠But not silence. Keep pushing the issue. Local hub execution was NEVER stated it would be only SmartThings published apps and devicetypes
Letâs just hope this is a temporary situation and will be fixed soon. If not, well, until something better comes along, I guess we just have this forum to complain about it 