This is probably a silly question but I couldn’t find the answer in the thread (or I missed it). When would you use the Sim Alexa Button vs Sim Alexa Switch? I don’t really understand the difference in the two.
So, ‘when’? It’s a matter of preference as #JDRoberts shows above.
The Alexa Momentary version handles the ‘Off’ since it is immediately turned Off so that it can be used to trigger something again later in SmartThings or Alexa.
On the other hand, the Alexa ‘Switch’ version will remain ‘On’ until either SmartThings or Alexa turns it ‘Off’ so that it can be used again later in SmartThings or Alexa.
So the Alexa Momentary version is the way to go in most situations. However, a use case for the Alexa Switch version is to have Alexa or SmartThings turn it ‘Off’ as that is a confirmation that the Alexa Routine was triggered or the SmartThings Automation, SmartApp, or the STHM was triggered, and it confirms that SmartThings and the Alexa connected service integration are communicating with each other probably between themselves.
Notice that I included the STHM in the Alexa Switch version. I included it since Alexa could have a sensor/system that can’t be integrated with SmartThings, so the Alexa Switch version could be the Open/Close sensor monitored by the STHM for an Alexa sensor/system. I don’t have a use case scenario of any sensor/system that’s only available through Alexa, but it is possible since these Alexa virtual devices work both ways.
Wyze sensors are a good example. These are super cheap sensors, about five dollars each for either motion or contact, But don’t connect directly with smartthings. So you use echo routines as an intermediary.
Some people also do this for the motion sensor on video doorbells. 
In many situations, I’m not sure I would say “most.” For example if you want to use Alexa to change location modes, You wouldn’t use a momentary. Or If you are using a virtual presence sensor. or even to represent security mode. You would change these again on the basis of other events, but you want them to stay on until those other events occur.
I think one of the original uses of these was for harmony activities, and again, you would want it to stay on until you switch to something else. If I’m watching ESPN, I’m watching ESPN until I change to Netflix. So I don’t want the virtual device to flick on and then off immediately.
Both are useful, both are popular, it just depends on the details of the specific use case.
Thank you for those explanations.
That sounds like a good case for the switch instead of the button. Remember that the whole point of the button is that it’s like a doorbell, it turns itself off again immediately. So if you use a momentary button at 11 PM at night, it will be off again by 11:01 PM. So it wouldn’t affect your morning routine that runs at, say, 7 AM.
If you want to turn on the virtual device at 11 PM and have that virtual device still be on at 7 AM, then it needs to be a switch not a button.
Just remember that you need to do something to turn the switch off again. It might be consciously by voice, it might be in automation based on something else happening. But at some point you have to turn it off so it will be available to turn on again the next time. exactly what you will do will depend on the details of the use case.
For example, you could turn that switch off at 7:15 every morning and then it would be ready to use again that night. It’s up to you. 
In the Classic app I was able to turn on the Alexa switch when the STHM was triggered. I recently moved to the new app and can’t select it (Set response -> Turn on lights). I could create a standard simulated switch and use Smart Lighting to mirror the 2 switches, but that just adds another layer of complexity.
Just for clarity…
The Classic app had SHM.
The new v3 app has STHM.
Similar purposes, but different code and somewhat different features.
Do your Alexa virtual switches work but sometimes they don’t. I have one that’s in a Alexa routine for my Lockly lock so when the lock is unlocked the status is then acknowledged and my STHM is disarmed automatically. It works but sometimes the switch doesn’t see the lock and unlock. Thoughts?
That’s been going on for months since they released the new skill. 
It’s mostly fixed, but not completely, so it is still happening sometimes for some people. Discussion in the following thread:
I figured it was that. Hopefully they fix this skill soon.
All of my Simulated Alexa Switch just stoped working. Anybody else with problem?
I just saw a report on a huge amazon AWS outage. My switch half works. Hopefully they’ll be back up soon.
Alexa is having problems along with AWS
I am having a recent problem with my Simulated Alexa Switches.
I am using ST app automations to turn of the switch after one or two hours. They have been working for a long time but now one doesn’t work. The automation does not turn off the switch after the elapsed time. (Alexa actions do work)
I noticed that the tile for some of my switches show “closed” and others show “off”
The Sleep One switch automation works and when you click the device tile,
it shows “Contact sensor - CLOSED”
Sleep Two automation fails and it does NOT show “Contact sensor” - only the word “Off”
Here is what the ST automations look like…
Not sure why the difference or how to resolve the problem.
Any help would be appreciated!!
It seems that the automation is the problem. When I shorten the time to 10 seconds, it works.
I set up a new switch and it doesn’t show as “Contact” either…
Is this code still working to create a virtual switch?
Here is the code I am attempting to use to create a new SmartApp from code on api.smartthings.com.
When I click “Create”, I get an error and cannot continue. Here is the error I am getting:
No signature of method: script_app_metadata_3b4f3cfe_ab7c_4b19_9cc2_b96287671c1e.metadata() is applicable for argument types: (script_app_metadata_3b4f3cfe_ab7c_4b19_9cc2_b96287671c1e$_run_closure1) values: [script_app_metadata_3b4f3cfe_ab7c_4b19_9cc2_b96287671c1e$_run_closure1@57ef41e5] Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure)
Thanks,
Mark
That code is for a DTH, device type handler, which you would paste into the “my device handler” section of the IDE.
By chance did you paste it in as a smartapp? That would generate that error.
If you are unfamiliar with custom code, the following FAQ will explain the terms and concepts. (The topic title is clickable link.)