Hi SmartThings Community Members,
We appreciate your support and honest continual feedback for the incidents and service disruptions that have impacted many of you. We take the stability, reliability, and performance of the platform very seriously. Over the next few days, we will be rolling out some stability improvements that will improve the overall experience.
Before we go into the weekend, I wanted to take the opportunity to share with you a bit about what is happening and how we are resolving these issues.
At a high level, the incidents are classified into two categories.
1. Device Control & Hub Connectivity
Anytime you see an Incident on our status page (http://status.smartthings.com) that refers to Device Control or Hub Connectivity, it’s actually a reference to the Device Connectivity layer of our platform, which we call “Devconn”. Devconn’s job is to receive messages and events from the hubs and pass them along to the next layer in our cloud. In addition, Devconn sends commands like “Turn on the lights” down to the hub. And when we have an issue with one of the Devconn servers, it means that the subset of hubs connected to that server aren’t able to communicate with our cloud.
To resolve these issues, we just rolled out a new release of Devconn yesterday. We’ve modified the way in which Devconn communicates with the rest of our cloud, and our expectation is that this will solve the issues that have been so prevalent in recent months.
2. Scheduled SmartApps and Sunrise/Sunset
Another area that has been a significant problem area has been the scheduled execution of SmartApps, specifically at Sunrise and Sunset. This is because lots of customers use sunrise and sunset schedules and causes a huge spike of SmartApps execution in each timezone as scheduled SmartApps execute. We’ve experienced problems with both late SmartApp execution as well as some SmartApps that don’t execute at times.
Similar to Devconn, we’ve taken a new approach to how our scheduled SmartApps are handled. We are going to be rolling that into production next week. Once in production, we will migrate customers over to the new scheduler shortly after.
The bottom line here is that we believe the new scheduler will improve the efficiency on how these apps are handled, and we’ll get all customers migrated to it as soon as we can.
The Future and Hub v2
Finally, I wanted to give everyone some additional insight into the forthcoming Hub v2, and what it will mean to performance, reliability, and availability of the SmartThings platform.
As you may already know, Hub v2 will be able to run both SmartApps and Device Types (the device drivers that talk to each of your devices) locally in the hub. Roundtripping to the cloud will no longer be necessary (with the exception of cloud-dependant devices).
This means that automations (SmartApps, Hello Home Actions, etc) driven by Zigbee, Z-Wave, or LAN-Connected devices will continue to work even if you lose your internet connection. In addition, the local SmartApp execution on the V2 Hub includes a local scheduling engine that will handle things like sunrise/sunset locally and this will also no longer be dependant on the cloud. You’ll see a significant improvement in response times, and automations with the V2 Hub will be a whole lot faster.
We are working round the clock to get the experience to the point where it needs to be. From a customer experience perspective, my simple goal is that SmartThings should be the last thing you suspect as being the cause of a problem, not the first. We need to be more reliable than the devices that are connected to our platform, and we want our customers to expect that day after day, month after month, year after year.
Thank you for your continual support and enthusiasm for our platform.
