For my case, i managed to solve it. after hours of smashing my head on the wall 
So for me, i didn’t assign a room to my hub when i set it up, that lead to devices not adding into rooms automatically.
i did reset my hub ( at this point it’s easier to re configure all my devices) and now it shows up !
Thanks for the help Y’all !
The vEdge virtual switches I created in the hub has been working great up until a week ago. They don’t seem to operate anymore. It switches over in the Amazon Alexa app every time but it only runs the alexa routine sometimes. Mostly about 20% of the time. Has anyone else had this problem?
Yes, posted about this yesterday. Something is up for sure. Totally unreliable as of late. I’m not sure if it’s Alexa or Smartthings but there is a disconnect somewhere. I’d open a ticket with support@smartthings.com
I’ve been wondering: should we be creating virtual switches using this community driver, or doing something that’s ST provided? What’s the down/up-side of each? I’ve got another hub that I need to create more virtual switches, and just wondering for futureproofing what I should be doing.
I had started using the virtual switches by ST but the API Browser+ listed them as being cloud-executed, so I changed to vEdge. It seemed weird that the transition to Edge was for local execution but the ST virtual switches were executed in the cloud. Up/down side is a relative question; dependent on whether you care about where they’re being run – locally or the cloud.
If you’re using virtual devices to control local physical devices, then vEdge virtual devices make more sense as they are run locally on your hub and aren’t dependent on the ST cloud.
If you are simply using virtual devices to trigger actions/events in other clouds, then I’m not sure it really matters. vEdge driver-> ST cloud-> Alexa or Virtual device in ST cloud->Alexa. I suppose one advantage of a vEdge virtual device is that I can get a driver log from the hub to see what the device is doing. No such option for cloud virtual devices.
Remember that edge drivers require a hub and the vast majority, likely over 90%, of smartthings users don’t have any hub. They have a galaxy device or a Samsung smart appliance or television. Many still use virtual switches, in particular for integration with Alexa or ifttt. So it makes sense that Samsung would offer a virtual switch version that doesn’t require a hub.
Edge is only one part of the new architecture: it’s still largely cloud dependent.
Same problem here. Sometimes they work but most of the time doesn’t do anything.
I could include the pause command for the virtual shade device, but how would you use it? You could issue a pause command from the app or via an automation, but then what? You cannot have an automation get triggered by tapping the pause button in the app.
You can set the virtual device shade % with an automation.
Just a thought, but have you tried disconnecting, then reconnecting the Alexa service to SmartThings?
I try to explain better my situation, but excuse me for my english…
Well, I have a real curtain switch that doesn’t work well with the actual edge drivers. I can command properly up an down the curtain and i get the percentage of the curtain but after some time the percentage goes to 0 without any reason… I’m trying to fix this problem with mariano but i would found an exit strategy, and I created a virtual curtain to control the real. I do some automations (15) to get the percentages during the movement. Now i’m able to command up and down and know the percentage with a good approximation, now I need to have the pause button on the ui, and would be tiny if i could set the open percentage from the virtual device, but to do this i will need to create other 10 automations according my actual knowledge…
I have 8 curtain in my home and using this method for each curtain i will do approx 150 automations manually…
I hope that’s my explanation is clear.
Thanks for your time
7 posts were split to a new topic: Unlinking Alexa?
Glad I asked. So this is 100% not an option. I have countless routines that would require not only rebuilding, but a concise log of how they are constructed now to get back to this point.
I’ll ask on the off chance anyone else is having this issue, but dosen’t have a hundred Alexa routines in jeopardy of being broken. If so, I would love to know if unlinking and relinking fixes the issue.
Iy is Alexa for sure
I created a routine with a virtual button that says Alexa says “on” when on, “off” whrn off.
When triggering the switch via Alexa app, only like 20-30 percent time it works.
Especially if it’s in quick succession. If ON succeeded, then ON > OFF does nothing. But OFF >ON will be registered. And vice versa.
If i wait a few mins, the behavior returns.
It seems like one one State (open or close) registers, the opposite state doesn’t register for sometime.
Exactly what I see. I had mentioned in this thread (or a similar one) that it seem to be worse in quick succession. But also unreliable out of the blue when not in succession. I will call Amazon today. If others can do the same it might help.
I am having the same problem with intermittent deliver of Alexa messages using the Alexa Switch in ST. The problem is definitely on the Amazon side.
We had similar problem 2-1/2 years ago using the old Groovy Virtual Alexa Switches became unreliable. So some of us switched over to using Voice Monkey to trigger Alexa routines. ST triggered an WebCore piston, the piston made and http call to Voice Monkey and Voice Monkey triggered and Alexa Routine.
The problem today is that WebCore is gone. I suppose SharpTools Premium or @TAustin Web Requestor (requires a constantly running server) could be used instead of WebCore to make the http calls.
Voice Monkey uses a virtual Door Bell to trigger the Alexa routines and it worked reliability. After several months Amazon fixed the problem and there was no reason to use Voice Monkey.
The Tasker “Auto Voice” plug-in also uses virtual Door Bells to trigger Alexa Routine.
@TAustin is any chance you could add a Virtual Door Bell with integral Switch to your virtual device creator. If this works it would be an easy solution.
Since even the Alexa app is not triggering its routines when toggling the virtual device state in the Alexa app, I’m not sure that looking for a different integration other than ST->Alexa is going to be the right answer. It follows that those integrations could experience a similar lack of consistency if the problem lies in the Alexa cloud or app.
I posted on another similar thread last week that I had no problems with the virtual switches but my Third Reality motion sensors (plugged directly into an Echoflex) seemed to be running sluggishly. Today they are failing sometimes to trigger Alexa routines i.e. I am convinced that the problem is 100 % with Alexa.
