For Smartthings Staff: App development plan

@troy_owens I haven’t done a pure test of this, but in general this is good idea. If only to prevent future devices from enrolling and typing to something outdated (or not enrolling at all due to a “stale” DTH) and reducing the latency in the call to produce your list of SmartApps (Home > Main Menu > SmartApps).

1 Like

Thanks Garrett. This is something that had never crossed my mind.

1 Like

Garrett, first, thanks for entertaining this thread :slight_smile:

Can you elaborate on why this would make a difference? As far as I know the app communicates with the ST cloud. So why would a hub connected device being cloud vs local make a difference since the app is making calls to the cloud and not the hub?

1 Like

I debated entering this one, and when the Bama/OSU game turned into a blowout, I figured why not.

To be clear, this will have a minimal impact on an individual device tile being loaded. When we’re talking about the above example, and 40+ lights are cloud-executing when they could be local, the actual actuation/control of these devices via the App will be quicker and more accurate. Since in this use case (and most) we’re talking about time elapsed between App Launch -> the device I want to control has verified to me via the App that it has been controlled, this matters. This will also of course benefit actuations that occur while viewing the App, through like someone adjusting the light or switch locally, providing faster/more accurate current state while viewing/controlling. Add this up on many devices and on the cascading impact across your entire Location setup, there will be a performance bump.

There is also the concern of DTHs that have not been touched in awhile in terms of being outdated/borderline obsolete, which I feel like is a good description of any old IKEA DTHs (and many I observe on accounts on a daily basis) that were previously needed. If they haven’t been optimized for the new App (a lot of developers are actively doing this or have done this and I’m not talking about those) they’re going to be clunky and slow. They may not have correct data to show in the plug-in (which results in fallback data being fetched to populate the plug-in, etc) which impacts latency in the case of going from App Launch -> Click Device tile -> Device plug-in.

I won’t claim to have all the answers for improving speed, and obviously there is still work being done, but I have never not used the new SmartThings App. I used Classic a few times just to see what the fuss was about. I have 91 devices on my Location (including the Hub).

People who have been around for awhile are generally those who have serious speed issues. The suggestions I mention above, when taken and performed as a whole, should have noticeable benefits. Individually probably less so (unless we’re talking a complete re-org of your Home page).

I’ve seen many people on here and on Facebook mention that Factory Resetting their Hub and starting from scratch with a new Location has helped resolve many of their issues. What’s done when you follow that procedure (provided you also delete your Location separately or as part of Hub Reset) is that:

  • Old/unused DTHs are removed and everything you re-enroll is typed appropriately according to what is currently offered and being actively maintained. Many things that used to require custom DTHs can run locally now.
  • Old/unused SmartApps are deleted.
  • You are then using the newest C2C integrations instead of legacy/custom SmartApps.
  • Maybe some mesh networking benefits that I’m not really sure how to properly articulate. This shouldn’t have App Loading impact, but instead have actuation/status/control/Automation execution benefits.

(Disclaimer: Not saying you should Reset your Hub and start over, just that those who have mention this has helped them. The same items I mentioned above are what is actually happening to achieve these benefits).


Hi Garrett,

Thank you for all your advices, excluding swapping to Android - That will never happen!

Understand / agree with everything you are talking about except light grouping. Have some questions and comments. The way i manage a group of light bulbs is by creating a virtual dimmer switch and then use Smart Lighting to have a group of bulbs mirror the virtual dimmer switch. Will changing this affect performance?

Both options sadly lack Color Temperature control, which is kind of surprising.

Have also tried setting up one of the bulb as “master” bulb and then have the others mirror, thinking i could get temperature control, but that also does not work.

At some point I also tried Trend, but that also was problematic.

Light grouping has its own set of issues. You cant move them into rooms, you cant call upon them via virtual switches, and when dimming the slider often jumps around.

So changing from using virtual switches and mirroring behavior has high cost in terms of usability.

Also, for your information then on my homepage i am only showing the light switch and virtual dimmer switch for each room. Everything else is hidden.

I will try these changes and test after each change. Will report back my findings.

yeah, the Cons of Lighting Groups really outweigh the Pros. Faster loading in the app and hub level group broadcast commands are nice, but thats about it. We’re over a year into having lighting groups and nothing has been done to get them added to Automations, scenes, adding color functions, exposing them to APIs, etc. They were exciting and first, but a pretty big flop at this point.


maybe you need a samsung/android phone :wink: :sunglasses:

I use a Samsung S8. The Classic app was fast and responsive. The new app is slow to start, slow to update, and slow to show things. Sometimes the history tab of a device lags behind actual event by seconds to minutes.

And you are saying it is worse on an iPhone?

This would be most common with Zigbee devices where lots of devices were added slowly over time and repeaters filled their child slots with the ones that joinEd the network earlier rather than the ones that would now be the most efficient. That is, the most efficient repeater was not available as a parent when a new device joined the network because it already had all the children it could handle. Rebuilding the mesh from scratch would fix this.

This is unlikely to be a problem with Z wave plus devices because over time the explorer frames will correct these kinds of issues and find new routes.


To add to this Garrett, in our tests here we found gigantic improvements in the response times when ghost/dead devices were removed from the mesh - to the tune of up to 30 seconds reducing in time in some bad cases, outlined here: FAQ: How to remove ghost devices from your z-wave and zigbee networks

I suspect resetting the hub may be doing that. I would recommend folks to try and clear out these ghost/orphaned devices from the mesh before resetting the hub.


Your note implies there is no easy way (I’m assuming outside of HUE) to synch color temperature across multiple devices. Is that true?

I would think controlling color temperature via Scene would be quicker for a group of bulbs than this, and would certainly load quicker on the Home page. There is some time invested in setting this all up the way I’m suggesting, and it will vary by setup size. Yours being definitely above average in size.

I totally agree and have provided this feedback internally previously, as well as @Automated_House comment about color.

In the scenario I’m describing Lighting Groups would encompass your Rooms, and no Rooms would be visible on Home screen (again just a suggestion).

I’d definitely love to hear how this works out for you, I’ve played around with various levels of this on my own Location.


Respectfully disagree on both those points. Since this post was about speed and he has pretty much entirely Zigbee IKEA Lights this will make a big difference. I wouldn’t have suggested this if he had a system of say, LIFX, or something.

I’ve passed this along (minus APIs because that really didn’t matter to me) before, I’ll follow up on it and add APIs to the list. Might already be on the roadmap and I’m just not already aware.

Overall, there is a ton of unrealized potential for Lighting Groups, no doubt or argument about that.


Any suggested reading on this? I have a pretty much entirely Z-Wave background and Zigbee still at times feels a bit foreign.

I use a lot of IEEE resources, but that’s because I am particularly interested in contrasting Zigbee with other protocols. They’re probably too theoretical for most people.

Zigbee Alliance has some good resources, in particular the following is aimed at developers which I think might match your perspective pretty well:

And the following is a really good textbook kind of approach, like if you were covering Zigbee in a college engineering course. It gives a high-level overview of the architecture and stuff like that.


I did this today before seeing this thread and my devices refresh instantly when opening the app. I am on a galaxy s20+ with Android 11.

I got rid of a bunch of old snartapps and device handlers. My devices used to sit there for a good 5-7 seconds before showing the current status.


Had intended to give an update earlier, but life got in the way.

What I have done is remove some unused DTH´s, change all my Ikea bulbs from using a local zigbee DTH, and some general housekeeping. Initially, this made some minor speed improvements but nothing drastic. Then about 10 days ago (roughly) I noticed a drastic speed improvement in the app - was there a software update because I hadn´t touched my setup for some days before this noticeable speed increase?

So what issues am I seeing?

  1. The Smartthings Home Monitor tile is still taking a long time (upto 15 seconds) to load at times. This does not happen consistently, but sometimes it slows everything down to a crawl.

  2. Scenes are the second slowest now to load. Both Scenes and Home Monitor were, and still are, at times slow to load up when you start the app.

  3. Switching the Ikea bulbs from a custom DTH to a generic Zigbee one has meant that I can no longer go below 2700K, but before I was able to set the bulbs to 2200K. Can´t really understand why the Zigbee one has a hard stop at 2700K. Actually, find it quite strange how little support, in general, there is to bulb color temperature in things like virtual dimmer switches given that most white bulbs have for a long time allowed you to control both temperature and dimming. This is obviously not a driver issue as my Scenes I had created before and set the color temperature to 2200K still work even though I am now using the Zigbee driver.

  4. Lighting Groups is definitely much faster but the usability is questionable since they are all in the same group and can not be moved forcing users to use two groups when controlling a room. So lighting groups is clearly better tech, but usability needs to be improved. Will keep my eye on those.

  5. What is probably the most annoying problem still and hasn´t really improved is that even though the home page is loading up faster when I go into a room and click for instance on a bulb (which is using a local driver) we have to wait for anything to appear and very often it loads up without the controls to control dimming and temperature loading and showing the cloud icon - as if there is no connection to the bulb. We then have to click and drag down to reload and then it appears - so it is like the interface is timing out and deciding there is no connection.

In summary, there has been improvement even though I think the biggest change happened not because of anything I did. I am still dealing with unhappy users - when they load up the app and it goes into a slow load mode because of Home Monitor and Scenes and they then also have to refresh something because it didn´t load properly they become unhappy. The fact is that many on this forum are very technical and are talking about advanced automations and my feeling is that there is too much focus there and too little on the general usability by users that don´t want to know anything. It is not just what I have talked about in this post. There are so many aspects of the user experience that could be improved by simple changes to the UI, but that is a thread of its own ;p

So @garrett.kranz thank you for giving this post your attention - it was appreciated.




Thanks for following up on this @MagnusBergs

It might be worthwhile to use the “Reset” option in your “Set response.” Your entire “config” is being loaded each time, which depending on complexity could be a decent load when the other services that provide this are experiencing sub-optimal performance. You could also consider the following if you are setting a large light-based response:

  • Create a “Master Switch” Virtual/Simulated and an Automation which turns on all your Lights based on “Master Switch” being on. This will greatly reduce the load on the “config” within your STHM, as only one “light” would be within it. This is all Cloud executing (for now) anyways so the difference in reliability or speed should be null.

At the time in which I suggested this I was only minimally aware of the impact Rules API migration might have, and was definitely not aware of adverse affects it might have on load time. The time spent loading Scenes should decrease in the days/weeks to come. My apologies.

Totally get this feedback, and I’d love to see them be added to Rooms as well (a la Google Home, etc.). In my suggestion, I was recommending no actual “Rooms” be on the Home screen. Only various Lighting Groups covering common use cases within each area of your Home. Here is an example of mine (your lighting system and needs seem to be more robust than mine, but again these were all just suggestions):

I totally understand what you mean here, and to be honest you are probably making matters worse by not just waiting for it to load. When you see the cloud with the line through it, it is almost loaded (and agree the choice of icon is not great). Refreshing it at this point will start the whole fetching of the Plug-In process over again. This load time in general is an obvious point of improvement, no arguments there from me.

I think here we (as in you and your family with me hoping to help lol) need to look at who is using what and who needs access to what quickly. The Home screen is configurable by device. For family members who need to get in and get out, Lighting Groups and Scenes (once they load as quickly as before again) being the only things on the Home page should be the best move. You have mentioned color temperature a lot, and I think frankly this should be automated by time of day. Automations like:

IF: Time period, Morning (whatever your preference). Device status, Light on.
THEN: All Lights in this Room or area, Set color temperature.

Lastly, you have set yourself up for future success with regards to local execution of Rules and Scenes with the changes made to your DTHs, the value of this will be extremely beneficial to the above suggestion about Automating color temperature, as well of course in the small benefits already achieved.

I think this post sparked a lot of good discussion and I thank you (and the others who chimed in) for that as well as the non-combative engagement, which is always appreciated. I’m still around if you (or anyone else reading this later) wants to do a deep dive into their Location and issues with load time.




Thanks goodness. When that happens you can close ticket 1140672 :wink:

1 Like

@garrett.kranz - just thought i update this older post. The new ios client has solved it seems all my issues. Everything loads and responds almost instantly - huge improvement. Like the updated interface.

So well done!