It has been a busy week for everyone at SmartThings. In the past several updates I have delineated changes into categories, but the effects of this week’s changes impact the entire platform. We are confident that you should be seeing marked improvements across the board.
This week we rolled out three main updates which were directly targeted at platform stability and latency. Since the dark morning hours of Wednesday we have been seeing very positive results from these changes, ranging from a wide range of backend metrics to user facing improvements such as dramatically decreased load times for Smart Home Monitor.
To give you a sense of the level of impact, I’d like to share just one of the metrics we use to assess the health of the platform. The graph below represents peak hub latency between the cloud and the hub in milliseconds (y-axis). In this case the lower the blue and yellow peaks the better.
This is just one of hundreds of metrics that we are tracking in real time as we plan our waves of improvements, and they’re all headed in a positive direction. We still have a long ways to go and many forthcoming updates in the pipeline, but believe that we’re now at the point where everyone should be seeing noticeable improvement in your everyday usage of SmartThings.
This week we also published version 2.1.2 of our iOS app. This update includes bug fixes as well as experience improvements. We fixed an issue with closing the slide out menu when Voiceover is used, fixed bugs around installation of SmartApps (specifically child-app installations), made some updates to the UX to allow for better readability of fonts, and added a new rooms editing experience. Detailed release notes can be found here.
Outside of the platform progress, we’re also working hard to ramp up engagement and transparency with you. If you weren’t able to make it, please watch our Developer Discussion with myself and Robert Parker where we answer as many questions as we can in 60 minutes.
I look forward to providing you with another update next week.
Thank you for the update. Can’t speak for anyone else, but I have been seeing pretty good stability over the past couple of weeks. Going in the right direction for me. Please keep it up.
I appreciate the efforts being made by the team on the platform. I know that any changes can have a ripple effect on other components of your architecture (I’m an enterprise/software architect).
However, as mentioned during the developers call, it would be better (for everybody, including ST) to involve some community developers before releasing any platform updates or even a new mobile app version (sort
of a beta program for developers as discussed during the conference call).
As an example, the latest platform updates introduced a new bug for the Community developers: every time, a child device is created, the following exception is generated:
error groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method physicalgraph.event.EventService#create.
Cannot resolve which method to invoke for [null, class java.util.LinkedHashMap] due to overlapping prototypes between:
[class physicalgraph.app.InstalledSmartApp, interface java.util.Map]
[class physicalgraph.device.cache.HubDTO, interface java.util.Map]
[class physicalgraph.device.cache.InstalledSmartAppDTO, interface java.util.Map]
[class physicalgraph.device.cache.LocationDTO, interface java.util.Map]
[class physicalgraph.location.Location, interface java.util.Map] @ line 408
[5:49]
So, this means that all Service Managers are no longer able to instantiate any objects. In fact, this affects not only the community developers’ devices, but also the ST stock devices as well.
The ST engineering team is aware of the issue: the exception shows up when addChildDevice() is called with a null hubId, and the fix will be implemented on Monday.
This is just an example of the difficulties we’re all facing with the platform…
Hopefully, we’ll be out of the woods soon. Your team deserves it for all the hard work…
Thanks @alex. I am too noticing improvements. Please please get mobile presence improvements somewhere on the short term roadmap. I spent all night last night setting up DD-WRT on my router with a script just to act as a backup for the ST mobile presence. This is in addition to having not much success with the ST presence tag or Life360 either.
2 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
9
Yup… I can tell you that I believe in substantial Beta periods. It is a lot of work to sort out feedback vs. bugs, but so grateful that there are always volunteers (too many, actually!). I bet SmartThings’s volunteer list is tremendously long; every time there is an offer here (e.g., for the new scheduler), volunteers show up like ants to a picnic.
When is ST going to make meaningful improvements to SHM, like an arm and disarm delay and a PIN to disarm? It’s great that ST is more reliable but, more useful would be great also.
We are focused on reliability and scalability (where we are making significant strides), but I’m hopeful we’ll be adding some of these desired features soon. We’re as excited to be in that mode as you are!
3 Likes
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
13
Alex, to @yvesracine’s point, it seems to contract your statement about reliability. How can a change be made to an API which breaks a rather fundamental functionality of existing apps. You had requested on the dev call that I tag you when I come across issues of retrogression or quality. This is a simple example, it isn’t a boundary condition but rather a system wide issue. Brings into question the SLDC QA processes.
Fully agreed. The hotfix went in quickly and I hope you and @yvesracine aren’t seeing the issue now. As we increase pace of updates to multiple releases per week, Robert and I are also looking closely at how to enhance QA and learning quickly from each issue (Android and iOS releases each contained bugs that needed to be fixed in hours after initial release too).
Generally, we are in the process of segmenting the platform into micro-services versus something more monolithic, which should make QA simpler as issues and changes will be more isolated.
Thanks for your patience and please keep flagging examples. We’re evolving quickly and are intensely focused on this.
5 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
15
This is hopefully a good strategy… I’m a bit old school and worry that full QA regression testing might then get “soft” and miss unanticipated integration issues. But that can be helped greatly with an in-the-wild voluntary customer/developer Beta channel pre-release. Regression testing by end-users is the perfect compliment to internal QA’s coverage maps.
Also…
As a published SmartApp developer, we would like the option of a Beta channel for a subset of our users or customers. One speedbump at the moment is the limited resources in your SmartApp Review & Publication area which bogs down the update cycle and our ability to be responsive. It’s been recommended that currently we should minimize release frequency and batch up changes, but this means we can’t follow the same best practices of isolated incremental updates that SmartThings is targeting.
On my side, I can confirm that the issue has been solved with the ''hotfix"…
As an enterprise architect by trade, I’m quite familiar with micro-services, and companies like NetFlix and AirBnB are good examples of successful micro-services implementation.
As you’re probably aware, micro-services are not only about technology, they are also a lot about empowering small & dedicated multi-functional teams -working on some specific functional components- during the whole SDLC (from design through deployment and even operations) …
As far as the enterprise architecture is concerned, micro-services can make it more complex as it is usually easier to maintain a monolithic architecture than a bunch of moving parts running independently from each other.
For a successful delivery of micro-services (and maximum ROI), this usually means changing the organizational structure and the processes…
I know that ST upper management probably knows all this, but it’s not always easy to cascade the message down to all the teams involved.
As we (community developers) want ST to succeed, we cannot resist giving our “point of view” on any issue facing ST… We probably should refrain as we obviously don’t know all the details of your challenges (and architecture)…Maybe, it’s just like a family member trying to help…
Fortunately, SmartThings is still relatively small (not a large bank or a tier-1 network operator), so the shift can be done quicker…
Thanks for all the feedback guys. We value it and read everything. One of my goals over the next month or two is to distill all the feedback, on these posts and others, so we can turn it into actionable items.
@Alex, thank you for participating in the forums and all the work done recently to SmartThings to improve the platform. I would like to please take a moment to make a suggestion which I feel is an important feature SmartThings is lacking.
I’m the main tech guru around the house and the one who purchased our SmartThings Hub (v2), devices, etc. I have the mobile app installed on my phone and use the app to control a couple of devices we have. One very important role that I use SmartThings for is the notification of when my daughter arrives home safely from school. To do this, I had to install SmartThings on her phone under my account. No problem so far.
I then proceeded, on my mobile device to add a SmartApps “Notifiy Me When” event for a family member (my daughter) to let me know when she arrives at home - which is a small radius I setup for my hub. Works great - when it does. Each time there seems to be a hub or mobile update, I have to go into this event and simply click “Done” to somehow update it on SmartThings servers or something. It never works after an update.
But here’s the real issue. WHY does my daughter have COMPLETE access to everything under my account!!? I had to install the app to use her phone as a device for location, but do NOT want her to be able to delete devices, add devices, change events, etc. This type of security should be selected for each family member added to an account by the primary account holder. As it is now, everyone has complete control and I believe this is a feature that can be improved in a future mobile build.
I hope you will please consider this. Thanks again.
This this this this this. 1000x … This! 
