Yeap same here
2 Likes
It used to work again yesterday but now it suddenly stopped working again. Very frustrating. Anyone else having this issue again?
1 Like
Yeap same shit again… 
i have a quite extensive automation setup and half the times it does not work
Mines stopped working again, its getting abit of joke now.
I thought my Simulated Alexa Switches were working but they are not!
So I went into the Alexa app under Devices/Switches.
When I turned on a switch in Smartthings it was reflected in the Alexa app BUT the Alexa routine did not work. So I started to setup a new test routine in the Alexa app.
In the process I noticed that most of simulated switches and some physical sensors APPEARRED TWICE in the “When this happens” section - NOT GOOD!
I contacted Amazon and a support rep said they are receiving similar complaints. We tried reinstalling the Alexa app, but no change.
He escalated my issue to the next level. He also said they made some recent updates.
Apparently they messed up some code …
EDIT: I cleaned up the duplicate devices mentioned in the strike thru text above by going to
Alexa Devices and removing the dups and then clicking the Discover button. It seems the ones that were labelled just “Smartthings” were the ones to keep and “Smartthings …” were the ones to delete…
EDIT: on a positive note, Alexa rtns using virtual switches are working (at least for now)
From Amazon support:
Thank you for taking the time to speak with me about your Alexa device.
I have relayed the info to the developer’s department for them to take a look on the routine issue that has arisen with the smart things skill.
Just got this email from
https://status.smartthings.com/incidents/p3b6pn6rt2b5
Issues with Device Control and Automation Execution
New incident: Investigating
Beginning at 7am EDT, some users in the Americas region may be experiencing delays or failures in device control from the mobile app and automations. Hubs and devices may also show an offline status. We are currently investigating and will provide updates as available.
Time posted
Aug 10, 12:41 EDT
Components affected
Americas - Hubs, Devices, and Automat…
1 Like
thanks for these ingenious virtual switches. I worked with you for 2 months without any problems, then unfortunately my Smartthings Hub broke and it lost the connection to all devices. It was a technical defect, in the meantime I have a new hub, reinstalled all devices, but the virtual Alexa Switch no longer works. I can create them using the Smartthings Groovy IDE, they also work perfectly in the Smarttings app. The VAS is also visible in the Alexa app, it also switches off and on, but it no longer triggers the routine, i.e. it changes the state but does not issue a command for the routine. I have already done everything imaginable, reinstalled the hub, created a new Alexa account, logged off and logged in … both Alexa and Smartthings, nothing helped.
Can you help me?
with best thanks in advance and
best regards
I’m sure most, if not all of you already know this but Hubitat Alexa virtual switches work to trigger routines.
I’ve never used a virtual switch for SmartThings to Alexa and I was just trying to do it the other week and it wouldn’t work (SmartThings door contact sensor wouldn’t work either), then I found post after post that this has been an issue for many for long awhile now.
From the emails, messages and posts I’ve done and read it doesn’t appear as these a timeline on when it will start working again, so I ordered a Hubitat, received it in 2 days to Canada from the USA and got an Alexa routine working in about 2 hrs (not knowing anything about Hubitat or how to use it).
I’ll be honest, for me the UI isn’t as nice as SmartThings nor is the automation. But it wasn’t all that hard (and I think it can do some pretty complex automations), but I still prefer SmartThings for now.
So right now it’s only acting as an automation hub to activate Alexa routines, not my SHM or antyhing else.
I now can trigger Alexa routines until SmartThings fixes theirs… and I have a backup automation hub when it breaks again 
2 Likes
Is this the code you are using in the Groovy IDE device handler? It is what I am using with no problem…
That what JD referred to as the dual device…and it is working. What he called the triple device, a momentary switch is what I’m having issues with.
I modified the Simulated Alexa Button DTH a bit so that it behaves more like a button.
Hiding information that I've since learned is not very good
in line 48, i added a statement to close the contact sensor immediately after it is opened. I did this because if you don’t, the contact sensor always stays open. i suppose i could leave it that way and write a piston to change that state some other way, but then i might as well just use the simulated switch instead.
notice below the order of events when the button is pressed. switch turns on, then turns off, then contact turns on then off, and momentary gets pushed. basically all doing the same type of action but with 3 different capabilities.
just add this at line 48, after the contact opens.
sendEvent(name: "contact", value: "closed", isStateChange: true)
the push() block should look like this:
def push() {
sendEvent(name: "switch", value: "on", isStateChange: true, display: false)
sendEvent(name: "switch", value: "off", isStateChange: true, display: false)
sendEvent(name: "contact", value: "open", isStateChange: true)
sendEvent(name: "contact", value: "closed", isStateChange: true)
sendEvent(name: "momentary", value: "pushed", isStateChange: true)
}
I also noticed that in webcore it just give me options for switch and contact. I set my piston to trigger when the switch changes to on. However, in the logs the Off event would show up first, and the On event would appear later after a semaphore. To fix this i turned on “Enable parallelism” in the piston settings so they can both execute together and avoid the semaphore.
edit: lessons learned. the order of events received by ST and WC varies every time. You cannot rely on them. Also, enabling parallelism doesn’t help when they’re being received in random order. By the time it compares the value, it’s already been changed. Don’t do that
Lastly, the ideal capability for this function in webcore is just “button”. Momentary just acts like a fast switch, and requires additional code to properly turn it off again. Seems annoying when all you want is in fact a single button press to trigger something. scroll down a bit more for a better DTH to use for virtual devices, webcore and alexa.
Hi,
What is the difference between this and Alexa Button/Momentary switch?
V
can you be more specific as to which DH you’re referring to?
i am using the DH from the start of the thread
and wondering how the update you recommend is different?
V
just the one line added to close the contact sensor, otherwise it’ll always read as open which seems counter-intuitive for a momentary switch/button
@orangebucket I’ve been looking at your DTHs for virtual momentary and virtual button, and think they’re both helpful, but I’ve found I need something that’s a bit of a combination. I noticed you addressed this by saying " This handler could have been combined with the Virtual Button, but testing suggested the tile in the mobile app would default to the contact status rather than the button and at the time there wasn’t anything that could be done about it, and also the device details screen was a bit too messy."
Despite the aesthetic issues you pointed out, I decided to attempt that combination anyway. This is my code for it. I also created an issue and pull request on github. https://github.com/steinauf85/Anidea-for-SmartThings/blob/addContact/devicetypes/orangebucket/anidea-for-virtual-button.src/anidea-for-virtual-button.groovy
In order to get full functionality of pressing a button in webCoRE and only sending that single event, the button capability seems to work best instead of momentary. I use this to activate some pistons when the button is pressed. I’ve had issues using momentary/switch because those will send an on and off command instantaneously, and it is unreliable which one ST/WC will read first. The second command will wait at a semaphore in WC, which adds unnecessary delays. So I’ve figured that buttons are the better option for this use. I’m also trying to avoid using a standard virtual switch as I don’t want to put any effort into turning it off again.
All the Momentary capability does is define a button in the app UI that runs the push() command, and also makes that command available to other apps for remote control.
I use it in my ‘virtual button’ to “push” the button, which I think is what it was always meant for.
The whole idea of having the push() command cycle a switch (or other sensor) on and off just sucks for exactly the reasons you describe, but I guess sometimes needs must. My ‘virtual momentary’ has an optional delay between the on and off. Using it just helps the events arrive the right way around more reliably and helps webCoRE avoid semaphores.
UPDATE: However, despite the above, if I think Momentary is meant to press a Button, it makes no sense in my having a handler where it doesn’t. So I’ll sort that.
1 Like
Does the delay actually work? I tried every version of a delay I could find in my own DTHs and as far as I can tell the feature is broken. All events processed at the exact same time.
As for your virtual button, it’s helpful for that function, but would be more helpful if it had the contact/switch capabilities too to enable full Alexa functionality. That’s essentially what I wrote up in my pull request.
It should do.
Yeah, I got there in the end.
I just noticed your updated code for Anidea for Virtual Momentary. Thank you for making those changes, as now this seems to be the most effective virtual device DH for someone looking to use it with webCoRE and Alexa.
So for anyone else looking for a great DH, try this one!