Only allow selected devices to be added to alexa

I would like to know if its possible to only add desired devices to alexa, its looks like we just can add all devices. Is there a driver or something that could allow this? This way we have a lot of duplicate in alexa app.

A very requested feature of the Alexa skill that links ST to Alexa. It is currently not possible to filter what devices end up in Alexa.

Unfortunately SmartThings doesn’t have location or device level permissions for its cloud integrations. It’s all or nothing. The best work around is to disable (do not delete!) the unwanted devices in the Alexa app.


I ll try that, but the device will still be visible in alexa app? If so, I could create a room dedicated to those devices so it could be sorted…

Yes, they will still be visible. I seem to recall they drop to the bottom of the All Devices, but it would probably be better to group them as you suggested.

1 Like

Just for context

Echo device inclusion control used to be a standard feature

Samsung removed it, im sure someone else will remember why exactly, i think it was to do with Amazon wanting control of all devices or ability to see all devices

And ST folks are on record in here saying they were working on bringing it back. But that was some time back and it never happened. Updates on the subject stopped without explanation. At this point I would guess it’s not going to happen.


I don’t think it was an Amazon requirement. I think it was Groovy vs oauth/token cloud authorization design. Groovy let you pick specific devices. The new architecture doesn’t for ANY outbound integration :-1:t2:


We don’t really know how the relationship between SmartThings and Alexa works (and the same for Google). Who is the customer? Or isn’t there one?

Looking at other connected services that use an OAUTH login like ActionTiles, it does seem like the current platform may have foregone the location and device level authorisation that seemed to be a feature of the legacy platform (and still exists for other types of SmartApps). Not a completely bad thing as it could be a right pain in the backside (though it was always noticeable that the Alexa and Google legacy integrations could opt to have access to all devices in a way not seen elsewhere).

I’ve never been clear why solving the problems this caused in Alexa (and Google) seemed to involve changing SmartThings to restrict the availability of locations and devices at source rather than allowing choice at the other end.

I always figured it comes down to UI changes and support costs on the Alexa side. Much easier if you put configuration pathways and “why doesn’t my device show up” support calls on another company. Hell, Alexa still doesn’t support controlling its OWN non-light devices by its OWN rooms.

The ability to expose only individual devices was lost for Alexa and IFTTT at the same time, and SmartThings staff said then it was due to a change in their authorization process AND they first said they were going to work on “fixing” it. Then after a few months of community questions and “we’re working on it” answers (including a paragraph on the official support pages) they just quietly stopped talking about it.

Meanwhile, some other home automation platforms with Alexa integrations continued to be able to selectively enable devices. I believe Hubitat still allows you to selectively enable both hubs and individual devices, for example.

So it wasn’t a change on the Amazon side. But it wasn’t an easy fix either. :thinking:

That one’s easy. (The explanation, not the fix.)

If you don’t want some household members to have access to some devices, you can’t put the devices on a selectable list in an unsecured app.

Say I want to make sure a housemate doesn’t accidentally turn off my medical monitoring system.

They do have access to the household Alexa account and the Alexa app that goes with it.

They don’t have the SmartThings app. (We use ActionTiles or SharpTools and a custom dashboard for them instead.)

I have devices that I want to NEVER show up in the Alexa app. Full stop.


yes, can confirm that hubitat works as you said, I just asking myself if with the new drivers system it could be fix? But if its an autentification question it would be from the dev side…

1 Like

Indeed. So why do it? Just because it seems Smartthings doesn’t limit access at the Location or Device level, why does the integration have to greedily suck in every device it possibly can? Can’t it just build its own list within the integration?

I am more familiar with the Google integration. It only supports a subset of the devices in SmartThings so only imports those ones. So why can’t it be more selective in other ways?

I’ve shared my thoughts on this before as I originally had the same feeling that the integration could add its own filter on the device list… then as I started looking at implementing it, I realized it was masking the reality of what was happening which could be misleading from a UX perspective.

On the SharpTools side of things, Dashboard Sharing would be the main way to limit what devices someone else in your home has access to. You can pick and choose what you put on a dashboard and whoever you share it with only has access to those items (restricted through ACLs).

Of course for dashboards that you have wall-mounted, there’s a variety of other options through tile security including requiring a PIN code to perform critical actions.


In the case of Alexa and Google I just feel like masking the reality actually does very nicely. Certainly with Google where there is already filtering by device type going on anyway and the person linking to SmartThings has to place the devices in homes to give others access so is applying more filtering.

This is a belated follow up. Having twigged how to access installed API_ONLY apps in the API, it finally registered that apps like the CLI and Google have the principal type USER_LEVEL and appear in the ‘Linked Services’ in the mobile app under the ‘All locations’ section. However ActionTiles has the principal type LOCATION and is listed in ‘Linked Services’ under the individual Location names it is working with. Do you know what is actually going on there? I have no experience of API_ONLY.

The main difference is in the scopes that are alluded to in their names. The USER_LEVEL scope gets authorized at the user level and has access to all locations that the user has whereas LOCATION scopes require the user to select which location they want to authorize while going through the authorization flow.

That’s what I assumed. Only I thought a significant part of the hoo-ha around the Google and Alexa integrations is that they not only can’t authorise at a device level, but they can’t integrate at the location level either. It sounds like it is less can’t and more that they choose not to.

And you can tell which is which in the ST app in the Linked Services menu.

1 Like