New SmartThings Alexa skill (2020)

Its all or nothing for me, all in last week, sensors, contacts and simulated contacts, its came back a few times, this morning had a few random messages come though that were triggered from the night before, then its all stopped again now, all was working great before that.
Cheers Dave

1 Like

I could never get one Alexa device to respond to another saying “Alexa I’m Home”.

Here here!

For example, without the DTH, there is effectively zero support for the GE Motion-Dimmer. I have different modes for different times of the day and location mode. Losing the ability to have those automations for the motion-dimmer would probably be a deal breaker for me.

Introducing a new platform should not cause regressions in functionality. That’s the first rule of software development and delivery. If it is going to take time to deliver it in the new platform, so be it. But in the interim, run the two in parallel until there is feature parity (or at least 99%).

1 Like

How can we help you figure out what is broken in the integration? Are there diagnostics, logging, etc we can provide you? Do you have an instrumented version of the skill that can provide you more detailed information that we can deploy to zero in on the issue?

1 Like

So this morning I saw the notice in the new app about SmartThings discontinuing Echo Speaks. At first, I was surprised and a little bummed. But after reading a bit on the forums I can certainly understand their reasoning.

Well without reading much more into it, I went ahead and updated my SmartThings skill in the Alexa app. Then several of my key automations stopped working. But fear not! After spending way too long reading and typing (this original comment was a plea for help), I managed to get it straightened out. So I wanted to share!

First, here is the specifics of the issue:

Everything appeared fine in ST. The app would show a device “On”/“Open”, and then “Off”/“Closed” when I toggle it from any source. But I was seeing the same device in the Alexa app only as a switch (although it was responding to toggle). Even though it would give me the ability to assign it to a new routine as a trigger device (i.e. Alexa saw it as a sensor), it would not activate any routine activation on toggle. The Alexa app did, however, remove the “old” trigger devices and warn me I needed to assign a trigger to enable this routine.

So here's what I did:

So I disabled both the new ST skill and the Classic ST skill in my Alexa account. I then re-enabled the Classic ST skill, discovered devices, reassigned the “new” devices to routines as triggers. And most importantly had to switch the toggle at the top of the routine page in the Alexa app (yeah, the one labeled “Disabled” :man_facepalming:) back to “Enabled”. Good as new! Or at least as good as yesterday…

Here is the DTH I have been using. And actually now that I look at it closely, the one I have installed on the IDE is an old version (it still has health checks and other unnecessary features). And I’m wondering now if that could be the source of the compatibility issues with the new ST ecosystem/Alexa skill. I’ll look into it soon and report back. Although I’m a little apprehensive to mess with anything now!

1 Like

Right now the older ST skill is scheduled to disappear on September 8. :disappointed_relieved: so only the new skill will be available after that time.

Updates to the SmartThings Platform

1 Like

Yes, definitely keep us posted. Earlier today I created a new Simulated Alexa Switch using the same DTH you linked to (I have done this many, many, many times and continue to every so many days to see if it has been fixed, lol)… my newly created routine with the newly created virtual switch worked 2 times and then it didn’t work anymore after that. My experience has been that sometimes they don’t work, sometimes they do work, and sometimes they work but the action is delayed. (I know this because I use them for announcements and sometimes the announcements will go off hours later.)

Personally, I do not think it has anything to do with the DTH… I think it has something to do Alexa being pissed off at Samsung too. :grin:


I just uninstalled the old classic smartthings skill and I installed the new one.
After finishing discovery I notice that not all my devices are be discovered by Alexa.
Some motion sensors are not showing up on available devices. I installed/uninstalled the skill twice.

Can we please get support for smartthings cam and vision in Alexa. I can’t believe this wasn’t included in the new skill.


1 Like

I think you’re right. And actually I just pulled this post up again to check on replies and to reply to myself: so far all those Alexa routine triggers appear to still be working but every device, scene, and automation appears to now be non-responsive inside the ST app. It’s not giving me any errors though. Definitely some growing pains since I didn’t he migration

What DTHes do the missing devices have ?Regular motion sensors should not be an issue.

I updated my smartthings app yesterday and noticed that my virtual contact sensors that I setup on smartthings are not triggering Alexa routines anymore even though alexa can “see” and registers the opening and closing of the virtual sensors. Any solutions to this? I really hope there is a solution to this, please for the love of god !!!

We are working on it, and finally have some leads thanks to the community assisting with our investigation.


Even if you get this fixed, is there going to be a way to create virtual contact sensors with switch capabilities in the future?

I need to be able to trigger an Alexa routine when something happens in SmartThings (I have a SmartButton that when pressed, turns on a virtual switch, and I want to have my Echo devices make an announcement when that virtual switch is turned on. Alexa routines can’t currently trigger based on the status change of a switch.)

People have in the past worked around this by creating a “virtual contact sensor with switch capabilities” by pasting custom device handler code into the IDE. My understanding is that custom device handlers and the IDE are going away soon, so I don’t want to set something up that will just break and be unsupported.

1 Like

The IDE in its current form will go away with the sunset of the legacy platform but something will probably replace it. It is a way off yet.

Custom device handlers are not going away at all. Custom device handlers written in Groovy via the IDE are going away eventually, but so are standard device handlers written in Groovy. So whatever replaces it will be available for custom device handlers.

Yeah as long as Alexa is fine with a device that is both a switch and a sensor. There is no restriction for it in the SmartThings voice service.

Since August 2018 this has been handled on the smartthings side. A DTH was used which had both the capabilities of switch and sensor.

SmartThings Exposed this to echo as two different devices: one that was a switch and one that was a sensor.

When you turn on the switch, the sensor opened. When you turn off the switch, the sensor closed.

This worked fine up until April of this year in both the new V3 app and the classic app. And worked fine with Alexa.

1 Like

@JDRoberts your FAQ is exactly what I was referring to. I’ve been migrating everything to the new app recently, but haven’t set up the method you describe yet, as I’ve been concerned that it would be going away with the loss of the IDE, etc.

Also, I was hopeful that Samsung/SmartThings was working with Amazon/Alexa to make a more direct, supported way to have a SmartThings event trigger an Alexa routine via what can be accomplished within the app (perhaps via a typical virtual switch, not something that has to be set up in the IDE with custom code).

You make references in the past tense, that it worked until April. I know that there’ve been problems with Alexa routines not firing or being delayed, which has been happening to us. Is your impression that the method in your FAQ is going to continue to work once they identify and resolve those issues? Or do you think we’ll all have to find an alternative solution? Or be left abandoned?

I’m not sure, and don’t feel confident in predicting the future. There are multiple possibilities. :thinking:

Right now, the old Alexa skill is scheduled to go away in a month or so and the new Alexa skill has two known issues which are not actually bugs:

One) it exposes all smartthings connected devices— It doesn’t allow you to specify which ones, which the old skill did

Two) doing this creates duplicates for any devices which are also connected via their native integration.

Smartthings engineering is aware of this, and seems to consider 2) an issue that should be fixed, but 1) Less important. There was much discussion of this in existing threads so I won’t go into all of it again.

In addition, there are three known bugs that occurred with the new skill

  1. Child devices were no longer correctly exposed to Alexa, so that many devices stopped working with the integration. Fibaro dual switches are a good example.

  2. some customers, but not all, report that virtual sensors of many different kinds are no longer triggering Alexa routines. This is not all customers and has been erratic, with the devices not working then working again for a few hours or a few days, then failing again. :disappointed_relieved:

  3. at least some customers who have multiple locations reported under the new skill the devices are all mixed together, which they were not under the old skill.

I’m not sure what’s happening with 3). Engineering is aware of 4) and is working on it and just said this morning that they now think they are zeroing in on a diagnosis. I haven’t seen any official responses to the multi location issue yet.

There is one other additional Longterm issue, which is the one that you just raised:

  1. on the old platform it was very easy for an individual customer to create a virtual device using the IDE and a copy/paste method. Or the virtual device creator smartapp. These were simulating hub-connected devices. Groovy is eventually going away (probably not until 2021) and smartthings has not Yet released the exact procedure for creating a custom DTH for a physical device that is connected directly via zigbee or Z wave.

And they haven’t said anything one way or the other as to whether there will be an easy way for an individual customer to create a virtual device on the new platform or whether it will require setting up a developer account and hosting a device as though it were a cloud cloud connection instead of a direct. We just don’t know. ( I have asked, twice, but did not receive an answer.)

So… I feel confident that engineering is doing its best to try to get the old platform virtual sensors Which use groovy DTHs to work with Alexa routines again Under the new Alexa skill. (4 above.)

I can’t tell whether any work is being done on three or five above.

They have said they are going to work on the duplicate devices issue, but I’m not clear on the technical approach to that.

I do not feel confident that they are going to work on changing the “all or nothing“ integration approach.

And I do not feel confident, to respond to your specific question, that we will be able to create virtual switches as easily once the IDE goes away. But since that’s not till 2021, I am putting off worrying about that too much right now.

Meanwhile, I did create a thread to list some of the alternatives to virtual switches that might be used if they just never come back. I’m not saying any of these are good choices, but they might be worth it for some people:

Sorry, I know that’s a long response with more questions than answers, but that’s my understanding at the moment.


What I don’t understand is why it would be difficult to simply allow users to choose which devices are exposed to voice assistants? There are lots of different reasons WHY people want to selectively choose which devices/routines are exposed. Simply giving users a choice of which ones are exposed fixes ALL the problems, regardless of WHY each person wants that ability. No need for Samsung to understand the various reasons people want the choice, or to develop a different solution depending on what a user’s reason is. Just give people the option to select which devices are exposed.