it can be unlocked in a routine in alexa if you turn on unlock privileges via Smart Home items in routines. No PIN code needed unless you require one. That said, I have a few routines that change the staus of a contact sensor / switch in Alexa … but changing the status of a lock in Alexa DOES NOT trigger the Alexa routine … it does trigger in ST
Also a virtual lock can trigger a “relock” if lock is triggered and it was already locked ( or vise versa). The good thing about virtual contact switches is that opening a contact that was already opened would not trigger a “reopen”. In other words it would respect the state that it was already reported to be in. This matters because I use contact switches to keep sync on rf devices that do not natively keep their state. For example, a fireplace.
All my virtual contact sensors are used in a uni-directional manner:
- In ST, turn on/off switch and in Alexa check for contact open/close
- In Alexa, turn on/off switch and in ST check for contact (or presence) open/close
As I said previously, Alexa->ST works every time and ST->Alexa works intermittently for any virtual device that is a switch/sensor like contact sensor, momentary button, etc. ST->Alexa works consistently for a vLock.
Trivial perhaps, but virtual locks also cannot be suppressed from smartthings native SHM status tiles . So if I want to check at a glance what doors, locks or windows are open I have to sort through a bunch of virtual locks which are only in use to make the former contact switch routines reliable again.
3 Likes
Plus they also show up in SLGA as well.
For those having Alexa integration reliability problems:
I’ve whipped up a new driver to test a theory that the combination switch+contact sensor could be problematic now for some reason. This driver takes a different approach so we can test if a contact-only device is more reliable as an Alexa trigger. It will take several of you trying this over a period of time to see if it proves to be more reliable. For those willing to give this a shot, instructions below:
Go to my test driver channel and choose to install ‘Alexa Multi-Trigger v0.1’.
Once available on your hub, do an Add device / Scan for nearby devices and a new device called “Alexa Multi-Trigger” will be created. Open this new device and you’ll see slots for 19 triggers - each with a name you can edit and a switch. Once you change the name to something other than ‘<unused>’ a new contact-only device will be created with that label. The switch controls the open/close state of the created contact device (on=open, off=closed). Configure one or more triggers then create Alexa routines to trigger off these contact devices. You’ll note they show up as true contact devices in Alexa.
In addition to the 19 trigger slots in the Alexa Multi-Trigger device, you notice at the top of the details screen there is also a button to ‘Create new device’. This is to create additional Multi-Trigger devices in case you need more than 19 triggers.
Caveats/Limitations
- This is a rush-job for testing only. Little testing has been done, so you could run into problems.
- This is a one-way solution for triggering Alexa routines only. If you really want to try using this to initiate an action from Alexa then you’d need to use a separate virtual switch-only device that you could control from Alexa and if desired, tie that switch device to the specific component switch in the Alexa Multi-Trigger device via an automation.
Please try this out and let me know your findings on reliability.
11 Likes
Following up, I asked the team and they mentioned it should be verified if there are no issues with those specific device types because it’s not happening for every device.
Also, it is important to note that custom integrations are not officially supported by the Alexa integration, so, they might appear there but their functionality isn’t guaranteed. I don’t know if there’s a limitation on the Alexa side for the triggers it accepts for the type detected for a device. A device that has the capabilities of contactSensor and switch isn’t a common case. So, it’s helpful that @TAustin created a new version to test that theory.
While that may be true, virtual devices of this type have been created by the smartthings community and used successfully as triggers for Alexa routines since February 2018, over 5 years now. There’s nothing new about this construct.
And the community FAQ on this method has been one of the most popular topics in the forum, with almost 63,000 views since it was first created.
So something has changed, either on the SmartThings side or on the Alexa side of the integration. 
4 Likes
@nayelyz Someone at SmartThings must have a relationship with the someone on the Alexa team, right? I think we have demonstrated a problem with some significance. This issue is only going to get resolved with both sides working together to resolve it.
This is my first post about this issue, as I have not had anything to add. But I, too, have experienced this problem.
Can we please get the 2 companies both working on resolution?
Eureka!!! Is working 100%… Never failed to trigger Alexa routine… Miss option to revert to previous state. And trigger the Alexa routine Faster than before… You are on the correct Path… Thank you for your amazing work…
5 Likes
So in order to implement this workaround, we would need one “switch only” virtual device and one “contact only” virtual device for each combo switch that we used to have?
Hi, @danhvos
I shared the comments above and yours with the team and they mentioned they can investigate the case, for that, we need someone with the issue to share this with us:
- SmartThings account email, if it’s different than the one you use here in the Community, send it over DM or to build@smartthings.com
- Enable support access to your account:
- Go to the SmartThings Web (my.smartthings.com)
- Log in to your Samsung Account
- Select Menu (⋮) and choose Settings
- Toggle on Account Data Access
- Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
- Device ID - it can be retrieved with the CLI, or the API directly, there are some tools published by other Community devs that help you interact with the API through the browser
- If possible, remove one of the devices from Alexa and trigger the discovery again by saying “discover my devices” for Alexa - This is to get the logs of that process, we can only get that info if it was done in less than 30 days
- Create your Alexa Routine again and share its configuration - The purpose is to understand the expected behavior
- Describe the current behavior only of that specific Routine
a. If it’s only that it triggers sometimes and others it fails, share the timestamp of when it was successful and when it wasn’t - This is to compare in the logs the commands received from Alexa.
2 Likes
Confirmed. The contact only virtual switch works consistantly, as a backup option.
2 Likes
@nayelyz Thank you!
Is anyone willing to work with SmartThings to get this resolved without having to change all of our switches? @sdbg @h0ckeysk8er I would, but my experience is intermittent.
Yes, if you also need to control a SmartThings switch from within an Alexa routine. But for some, all they need is just the contact for triggering an Alexa routine from SmartThings.
2 Likes
Thanks for feedback. Keep monitoring for a while to see if it remains consistent.
Adding an auto-revert would be fairly trivial.
I just tested my groovy virtual Alexa switch that wasn’t working at all yesterday and was inconsistent before yesterday, and it’s working well. So this may have been fixed by Amazon today?
Nevermind. It’s just less inconsistent than yesterday. Please disregard.
I am getting consistent results using the multi-trigger device where I’m still getting inconsistent results switching back to the switch/sensor device.
However, controlling multiple devices with a single switch is not particularly useful for situations where I’m controlling the behavior of a single device (or perform a single action) with a scene or a Routine. For example, I have multiple virtual momentary buttons to represent the different inputs of my home theater and when one is triggered, it causes Alexa to issue a custom action to change to that particular input. I wouldn’t want to trigger all the virtual devices from one switch because I don’t want to all the different input commands to be run, only a specific one. So, can this model of having a switch in ST and only the sensor in Alexa work with a 1 switch to 1 sensor setup?
Also, auto-revert is really needed otherwise you can’t replicate the behavior of the momentary button without creating a Routine to turn off the sensor.
Thanks for setting this up for us to test!
I can try. I’m not really familiar with the CLI but let me take a look at see if I can follow the steps.
You can get the device IDs and other info from the API Browser+ which is a web interface to the ST APIs and don’t have to download the ST CLI.
1 Like