EnumerateDevices() / GetDeviceById() like APIs (& Authorize ALL Things option for SmartApps?)


Is there a way to enumerate or retrieve devices specific to the account? I cannot find it in documentation.

What I would like to do is to write a SmartApp that is specific to the devices I have at home and use that one app to contain all the rules for all devices. As a workaround I can certainly have the app “ask” for all devices during config, but as I am adding more and more devices it will be tedious.

Right now I have rules sitting in “Rule Machine” app (great app!), but maintenance/refactoring of these rules becomes complicated once there are more then 10 or so rules. Also I end up maintaining a state in “virtual switches” shared between rules and would much rather use API-provided “state” variable.


– Andrey

1 Like

Join the club. SmartTiles and many, many, many, … many, many, many, … other developers have no choice but to require their Users / Customers to face this very “tedious” method.

I think this feature may be coming. I went into my amazon echo smart app and there is now a toggle to now to use all devices

1 Like

Nice catch!

@slagle, @jody.albritton, @Jim: Is this available to all SmartApp developers? Any early docs?


I remembered that SHM is also allowing to select all sensors of some type…

1 Like

@625alex I think SHM is just subscribing to the location events for all sensors of that type. Like this:

subscribe(location, "motion.active", motionHandler)

def motionHandler(evt) {
   log.debug "Motion Event device: ${evt.device}, Motion Value: ${evt.value}"

Not sure how the Echo app is accessing all devices…


Good point!

I think this is a similar implementation to the SHM “Use Every” feature… except with Alexa, you will still need to discover the new devices on the Amazon side. I am going to be the bearer of bad news, but (similar to SHM) do not believe this will be available to developers - or at least not in the immediate future.

We are not getting the hopes up. We were only asking about this for the past 2.5 years.


That certainly is bad news, Aaron.

Respectfully, I’m sure you and your management know that if you reserve more and more of the development API “for internal use only”, then that will be increasingly discouraging to Community Developers.

And, as you know from a good proportion of posts in this Community, the last thing we (both high profile and more casual developers) need is any discouragement. :confounded:

I presume @joshua_lyon, @obycode, @ady624, @pstuart, @shawneric, @jrivera, @andremi, @Mike_Maxwell, and many, many more are very concerned.

If you could please escalate this to the extent necessary, I (and cohorts) would be very thankful.



Thank you @tgauchat for the tag,

I believe this has to do with an apparent sense of security? I.E. don’t let an app have access to all devices without the user knowing? If this is the case, perhaps adding an option similar to enabling OAuth in the App Settings where the user can give permissions to the app would be the way to go? Let the user decide if he wants an app “see” all of his devices, without having to manually select hundreds of them and then having to revisit every time he added a new devices? I think educating the user and giving him the option would be a smart thing to do.

1 Like

From a UX and a security / authorization access control there are two ways SmartThings could handle this feature request;

  1. As described, SmartApps could provide an option which allow the user to authorizes the SmartApp to access all his/her Things all the time, even new Things that are added. I’m not 100% certain, but it looks like this is what SmartThings has implemented and is using in the Amazon Echo Alexa connector SmartApp.

  2. or, less "risky’ than #1, but still pretty useful; SmartThings could offer a “select all” option (especially on the OAuth device list screen) so that users can still de-select the few Things they do not wish to authorize because they are particularly sensitive (e.g., perhaps cameras, locks, and a virtual switch they use to disable alarms). This would be a “front-end” implementation, and was the more “expected” way we figure the feature would first be offered. The inconvenience here is that each time a new Thing is added to the Location, the user would have to go back in an authorize it … but at least they could “select all” once again.

1 Like

Well, it’s a matter of white vs black listing. I like #2 but as a black list - allow all, but prohibit these. Any new device would fall under “allow all”, so the user would have to go and manually “blacklist” that device.

@Aaron is my assumption correct in that this has to do with security alone?

1 Like

Can’t speak for the others tagged here, but personally?, I’m about done chasing around this moving target ironically dubbed a “platform”.
As I was discussing the current mutual frustrations with the wife the other evening, it became obvious to me that my current lack of interest in ST development and even forum participation for the most part is the constant dinking around required to keep our automations running.

There was a reason I began developing on this platform, I was able to create apps for ourselves and others to use that didn’t exist and brought forth a unique and sophisticated experience to our home.

So I have no problem putting in the time to build these, however I do have a huge issue with do-overs that aren’t of my making…
Without these automations in our setup, there is little point to it from both of our perspectives.

So when faced with the following three choices (Leave, Suffer or Rebuild) involving 200+ devices, 100+ automations and 6 api integrations you can easily understand my current lack of interest in ST.

So, sorry to say @tgauchat, but I couldn’t possibly be more discouraged than I am currently…

Understood, and I empathize Mike. … Thanks for your thoughts.

Let’s try to keep additional posts focused on the topic at hand: “Authorize All Devices / Things” feature for SmartApps.

Yes-ish - there are a couple drivers for why this specific feature will not be surfaced:

  1. The security limitation around subscriptions… Many users just copy and paste cool sounding automations. We do not want a nefarious SmartApp developer to be able to leverage a subscribe to all option.
  2. We are working on new services that should help make subscriptions more manageable (the details are way over my head and I don’t know what details have been discussed publicly/elsewhere)

Rather than engineer a specific solution for #1, I think we are going to work through to #2.

Trying to think of a way to say this tactfully, but please just be assured this is just an observation, not meant as harsh criticism…

I think that deferring to Item #2, is very “typical SmartThings”. You put off the urgency of the issue (ahem… we’ve asked for more efficient ways to allow a SmartApp Customer to select a large number of Things for well over 3 years), by waiting until the resources are available to design, develop, test, and deploy “the perfect solution”.

I think there is a lot more value to addressing Item #1, because “users pasting cool sounding automations” into their IDEs is a concern with or without the Select All feature. There is plenty of risk from a pasted SmartApp even if granted access to a limited set of Things. For example, even without any Things authorized, a SmartApp can change location.mode … which can very likely trigger all sorts of messes in the household, including security / alarm related scenarios.

At what point do Customers have to take personal responsibility for willy-nilly “copying and pasting” of code into their environments? At what point does SmartThings expedite the submit, review, and publish process for SmartApps to make it fast enough that distribution via un-reviewed source code is no longer the primary option for hundreds of SmartApps and DTHs?


Brand power! That’s one way to get special access.

So apps submitted to ST for certification should be able to use this API as ST has power over approving or rejecting the app. Hence marketplace published apps should in theory be safe enough to access this restricted API?


That is an excellent point, RBoy, thanks!

It certainly undermines @Aaron’s #1 argument against sharing this functionality; since “submitted, reviewed, approved, and published” SmartApps are not “just a copy and paste of a cool sounding automation”. The approval process ensures that the published SmartApp is not “nefarious”.

But how does the developer well… develop and test the SmartApp using the restricted API before the app gets approved/published? They need some sort of trust level for accounts where certain developer accounts are granted such rights. The API call would work if any of the smartapp (published) or the account (trusted) allows it…

1 Like