Is there any way to submit bug reports? I was on there today going through the cloud lightbulb example and it crashed at one point
There are a few different feedback forms for each portion of the work space
and one general form located here
Great, but reading through, I’m left with loads of questions and concerns, both as an end-user, and someone learning how to develop device handler code for non-officially supported devices.
On AWS Lambda, what will be the language of choice? Node.js, Python, Java and C# through .NET Core are all officially supported, so will existing Groovy code still be valid?
AWS-L charges for usage, so I wonder who’s hosting the code? SmartThings / Samsung? Device / SmartApp developers? End-users? All three? And if all three then how are end user AWS-L accounts handled?
Also, when I read about things like the new Rate Limits for SmartApps, I really want to know in plain English how they may affect me as an end-user.
Great questions, @veeceeoh Keith!
Ummm… their track record is something other than stellar. I could easily see them leaving us behind, while screwing up this ‘promised’ integration. Good that there are no concrete promises yet, as they suck at living up to them.
Endpoint Apps and Cloud to Cloud devices that run on AWS Lamda will able to utilize any language supported by AWS.
Groovy apps would need to be ported to a supported language for AWS-L, but the code could be hosted using a webhook smartapp on an endpoint server that supports the groovy language.
For an officially approved SmartApp that gets listed in our catalog, it would be up to the SmartApp provider to cover hosting costs. There could be a scenario where published Lamda apps are running in the SmartThings AWS instance but we have not resolved that aspect of the app approval life cycle yet.
There are existing examples of how “self-published” AWS app could work today and there is a free developer tier on AWS
As an end user there should be no apparent difference in the way a SmartApp behaves once installed. The installation, configuration, and update cycles all look very similar to the old style apps you are used to with a quite a few new enhancements like being able to subscribe to all devices of a capability or having the select all feature that was previously only available to internal apps.
The new APIS allow for much more robust access to the platform to do things like rename/create devices and locations.
From a developer’s perspective this will open up a completely new category of SmartApps and integrations.
I am sure @tgauchat already has a lot of ideas about things Actiontiles could do with the new API.
Indeed, we’re in design mode already; especially determining the overall impact, potential, and brainstorming for the optimal ways to transition.
ActionTiles has been (is!) incredibly reliable, though, with fewer outages than fit on one hand, and with only a couple “edge case” extreme power-user environments having any sort of persistent issues or noticeable performance latency.
While the new API / paradigms will likely solve those edge cases, we’re not quite as enthused about the normal risks and expected complications that are inherent in any such major evolutionary step.
yup, and i’ve given up using either of these because they are a PITA to keep updated. Will there be github integration? I’m guessing not since SmartThings/Samsung doesn’t host the code.
I’m also curious the definition of an app with regards to rate limits. In our current terms, is a child app an “App”? i.e. Is one WebCore piston = one app? Or is WebCore as a whole one SmartApp?
I hope this overhaul includes a more reliable platform because I’m getting tired of the monthly outages. I still don’t understand how ST still can’t stay up even for a single month without going down after all these years.
You’re mixing two radically different concepts or statistics here.
The new “SmartThings Cloud”, which will likely improve in stability with the use of the new APIs because a lot of SmartApp processing load is off-loaded, constrained, rate-limited, etc… Well designed and published APIs also give SmartThings more flexibility in developing and deploying arbitrary upgrades, as there is less likelihood of breaking complex SmartApps. But don’t expect overnight miracles.
SmartThings consists of many, many components. More components mean more points of potential failure. It doesn’t mean that the same component keeps failing, or failing due to the same root cause. The status report you link to shows failures across a range of areas - some of which had very minimal, short, or isolated impact. Of course, Community Members are more likely to be using a great portion of the overall system and thus more likely to experience the full range and variety of outages to some degree or another.
If Groovy custom smartapps and device handlers are going away I hope that SmartThings will do a better job of supporting more devices out of the box.
I had to go to a custom solution by the community in order to add codes to my two Kwikset locks. You’d think the handler built into SmartThings could have done that, but it errored out on both of them (a 910 and a 912).
There are others that I use that make life simpler too.
Unlikely in the extreme. Remember this is Samsung… and it’s virtually guaranteed they will, in this overhaul, do their level best to drive you to Samsung products where possible by making use of other products inconvenient. Because to Samsung revenue stream is everything, and service of existing customers unimportant as it is a cost center rather than a profit center.
I would hope they would, in this process, purchase and include some of the better community solutions. Lock managers in particular; both the other lock managers are superior to ST’s Manager.
I notice that Java is missing from that list, even though Amazon’s FAQ lists it as a supported language.
With all due respect, I don’t see these as good examples of self-published AWS apps, because the AWS Lambda account end-users are required to establish is in order to run a user-hosted Alexa skill built with Amazon’s ASK NodeJS SDK. The main SmartThings SmartApp code is still completely written in Groovy.
Additionally the installation of these SmartApps is anything but trivial, additionally involving setting up a Amazon Developer account, with all kinds of code-pasting and editing involved, and preferably setting up GitHub Integration with the SmartThings IDE.
Now I understand that the authors of Echosistant are working on a way to vastly simplify the installation process, but it remains to be seen if it’s for anyone beside the most dedicated and technically competent ST users. If consolidation of all aspects of IoT with a user interface focusing on ease-of-use is Samsung’s goal with this overhaul, then SmartApps which thrust the same requirements on end-users as these examples probably won’t fit or be well received by “the masses.” Don’t get me wrong - they are fantastic apps and push well past the normal boundaries of what people expect with voice-control integration with SmartThings.
I only asked questions relating to SmartApps, but I also wonder about the shift of development (both professionally and by “grass-roots” end users) of IoT device handlers - or are they called “plug ins” now?
From what I read, integrating IoT devices will require a SmartThings “Connector” which is actually a SmartApp with a REST endpoint. So as an end-user who’d like to be able to make customizations to existing device handlers for direct to hub-connected (ZigBee / Z-Wave) devices, or write new ones for devices that haven’t started to penetrate the U.S. market, it feels like a higher barrier to entry.
I also don’t see a way in the new platform to look at logs for my hub and devices.
It sounds like are starting to read the tea leaves… This move is a clear step away from enabling the copy and pasting of code by end users. This new paradigm will be far more complex than simply pasting some Groovy code in the IDE, or configuring the IDE to pull from github.
Yes I understand that, however even if you count only the main “platform” (North America Platform or Platform) outages/instability without any of components you still get 14 outage/instability in 2017.
In 2018 we already experienced two platform outages this month.
I don’t know about others but for me things are getting worse not better.
Looks like there’s another one going on right now
What was the outage count in 2016 (of the same or similar duration and severity)?
It doesn’t have everything, but you can always check the first bug reports page in the community – created wiki:
I didn’t do an exact count, but 2017 doesn’t look obviously better to me than 2016.
Just a mistake on my part. I will update the list.
The goal is the opposite. The goal is to make it easier for the actual developer to get their app to the end user with less effort on the enduser’s part. One of the problems we have with the old model is that we are basically allowing arbitrary code execution inside of a SmartApp that runs on the SmartThings Platform. This means that most apps are never approved and the approval process was long a error prone. With developer hosted apps there is a very straightforward set of rate limits and guard rails (which will be expanded from those available in the beta test) that will allow publication of apps with much less review. The net positive for the end user is that they will be able to browse the catalog and install the app and keep it updated via the catalog and the developer update process.
Yes. This is a move away from SmartThings hosting arbitrary code but SmartApps will be more discoverable and accesible in the long run. End users needing to copy and paste code is a bad user experience.
We are taking all of this feedback carefully and seriously. The main goal is to reduce the friction for both the developer and the end user. Please feel free to send me PMs, respond to this thread, and submit feedback on the developer site.